В процессе разработки кода программистам не обойтись без инструмента по версионности и контролю изменений. Одна из наиболее известных и популярных систем контроля версий — git (изменение кода можно зафиксировать и у этого изменения будет специальная метка). В результате вся история процесса разработки видна программистам, что очень удобно.
Продолжим разговор о возможностях системы Ansible и поговорим о системной информации, которая собирается в виде фактов с помощью встроенного модуля setup. Правда, разговор наш будет проходить в несколько ином ракурсе.
Дело в том, что со сбором стандартных переменных по умолчанию всё предельно ясно. Но что делать, если мы хотим сформировать наши собственные переменные на всех хостах, чтобы в дальнейшем использовать их в нашем коде?
В системе управления конфигурациями Ansible есть специальный модуль setup. Он выполняется первым, собирая информацию (Gathers facts) обо всех подключённых узлах (нодах). При выполнении модуля на хосте он собирает разные факты, включая дисковое пространство, версию и тип операционной системы, hostname машины, количество доступной памяти, архитектуру процессора, IP-адреса, сетевые интерфейсы и их состояние.
В наш век всепоглощающих web-интерфейсов очень часто перед системными администраторами встаёт, на первый взгляд, непонятная с точки зрения объёмов задача: как проверять работоспособность сайта?
TravisCI – популярный распределённый веб-сервис для сборки и тестирования кода. Многие используют его, т.к. для OpenSource-проектов он доступен бесплатно и обеспечивает удобную интеграцию с GitHub.
При этом отлаживать билды в Travis не всегда удобно. Для упрощения данной задачи Seth M. Larson разработал прекрасную утилиту trytravis. Она позволяет тестировать изменения в репозитории без коммитов и пушей в удалённый репозиторий.
К логам сервисов и приложений обращаются абсолютно все: администраторы читают логи, чтобы выяснить причину сбоя сервиса; программисты ищут в них исключения; «безопасники» проверяют, что в них нет каких-нибудь необычных записей, характерных для взлома.
Пока у вас один сервер, всё хорошо: каждый специалист может открыть файлы в vim и посмотреть, что ему нужно. А что если серверов у вас много? А что если по этим серверам разбросаны кучи сервисов и приложений? Как людям читать логи со всего этого?
Придётся же читать логи каждого сервиса, каким-то сложным методом находить логи того запроса, что сломался, и искать где именно что-то пошло не так. Как решить эти проблемы?
В первой части мы обсудили проблемы, которые решаются с помощью IaС-инструментов. Определив задачи и результаты их решения, в этой заметке я хотел бы рассказать о том, как можно управлять миграциями с помощью liquibase. Есть два способа:
1. Описывать и запускать их при помощи CLI liquibase в процессе деплоя;
2. Описывать миграции вместе с кодом приложений и запускать их применение во время запуска приложений.
Используя IaС-инструменты, мы можем поднимать и деполитизировать окружения с необходимыми версиями приложений по кнопке. Но ряд приложений помимо изменений кода требуют изменения структуры данных или самих данных в БД. Работать с ручным выполнением миграций в рамках процесса непрерывной поставки неэффективно.
Необходимо настроить мониторинг нагрузки на дисковые хранилища DELL MD36XX. Есть проблема – полки не умеют отдавать данные по snmp. Кстати, подобные проблемы также встречаются у хранилищ IBM, HP и других вендоров.
