Блог DevOps → Полезные материалы по DevOps | OTUS

Курсы

Программирование
Выбор профессии в IT
-99%
Python Developer. Basic Специализация Python Developer Python Developer. Professional Golang Developer. Professional Базы данных iOS Developer. Basic Computer Science Android Developer. Professional Team Lead Android Developer. Basic Специализация Android-разработчик Vue.js разработчик Groovy Developer JavaScript Developer. Basic Специализация Java-разработчик C++ Developer. Basic Специализация Fullstack developer Unity Game Developer. Basic PHP Developer. Professional Agile Project Manager PostgreSQL для администраторов баз данных и разработчиков MS SQL Server Developer Unreal Engine Game Developer. Professional Web-разработчик на Python Cloud Solution Architecture Flutter Mobile Developer PHP Developer. Basic Специализация PHP Developer Rust Developer Буткемп Java Unity VR/AR Developer
Специализации Курсы в разработке Подготовительные курсы Подписка
+7 499 938-92-02
Ansible: формируем переменные на всех хостах с Custom facts

DevOps_Deep_21.08_site.png

Продолжим разговор о возможностях системы Ansible и поговорим о системной информации, которая собирается в виде фактов с помощью встроенного модуля setup. Правда, разговор наш будет проходить в несколько ином ракурсе.

Дело в том, что со сбором стандартных переменных по умолчанию всё предельно ясно. Но что делать, если мы хотим сформировать наши собственные переменные на всех хостах, чтобы в дальнейшем использовать их в нашем коде?

Модуль setup и Gathers facts в Ansible

DevOps_Deep_17.08_Site.png

В системе управления конфигурациями Ansible есть специальный модуль setup. Он выполняется первым, собирая информацию (Gathers facts) обо всех подключённых узлах (нодах). При выполнении модуля на хосте он собирает разные факты, включая дисковое пространство, версию и тип операционной системы, hostname машины, количество доступной памяти, архитектуру процессора, IP-адреса, сетевые интерфейсы и их состояние.

Trytravis: тестируем без коммитов и пушей в удалённый репозиторий

DevOps_Deep_LAST_11.07_1_site.png

TravisCI – популярный распределённый веб-сервис для сборки и тестирования кода. Многие используют его, т.к. для OpenSource-проектов он доступен бесплатно и обеспечивает удобную интеграцию с GitHub.

При этом отлаживать билды в Travis не всегда удобно. Для упрощения данной задачи Seth M. Larson разработал прекрасную утилиту trytravis. Она позволяет тестировать изменения в репозитории без коммитов и пушей в удалённый репозиторий.

Системы логирования

VKDevOpsDeep.png

photo_2021_10_07_15_37_01-1801-136f82.jpg

К логам сервисов и приложений обращаются абсолютно все: администраторы читают логи, чтобы выяснить причину сбоя сервиса; программисты ищут в них исключения; «безопасники» проверяют, что в них нет каких-нибудь необычных записей, характерных для взлома.

Пока у вас один сервер, всё хорошо: каждый специалист может открыть файлы в vim и посмотреть, что ему нужно. А что если серверов у вас много? А что если по этим серверам разбросаны кучи сервисов и приложений? Как людям читать логи со всего этого?

Придётся же читать логи каждого сервиса, каким-то сложным методом находить логи того запроса, что сломался, и искать где именно что-то пошло не так. Как решить эти проблемы?

Версионирование данных БД в рамках процесса непрерывной поставки. Часть 2

DevOpsDeep11.05_Site.png В первой части мы обсудили проблемы, которые решаются с помощью IaС-инструментов. Определив задачи и результаты их решения, в этой заметке я хотел бы рассказать о том, как можно управлять миграциями с помощью liquibase. Есть два способа: 1. Описывать и запускать их при помощи CLI liquibase в процессе деплоя; 2. Описывать миграции вместе с кодом приложений и запускать их применение во время запуска приложений.

Версионирование данных БД в рамках процесса непрерывной поставки. Часть 1

DevOpsDeep3Site.png

Используя IaС-инструменты, мы можем поднимать и деполитизировать окружения с необходимыми версиями приложений по кнопке. Но ряд приложений помимо изменений кода требуют изменения структуры данных или самих данных в БД. Работать с ручным выполнением миграций в рамках процесса непрерывной поставки неэффективно.

Zabbix: мониторинг дисковых хранилищ DELL MD36XX

DevOps_Deep_10.07_SITE.png

Задача

Необходимо настроить мониторинг нагрузки на дисковые хранилища DELL MD36XX. Есть проблема – полки не умеют отдавать данные по snmp. Кстати, подобные проблемы также встречаются у хранилищ IBM, HP и других вендоров.