Сегодня бизнес-данные стали основой для принятия управленческих решений, а системы бизнес-аналитики и корпоративные хранилища данных (DWH) — ключевыми компонентами инфраструктуры по работе с данными.
Чем масштабнее система, тем выше требования к стабильности, скорости развёртывания и производительности, которые не могут обеспечить ручное управление. Для автоматизации процессов управления инфраструктуры в ИТ-проектах, включая DWH, используется инструмент Ansible.
В статье рассказываем, как Ansible может применяться в проектах: от автоматического развертывания и настройки компонентов до восстановления после сбоев и централизованного управления параметрами.
Сравним Ansible с другими инструментами для автоматизации управления инфраструктурой: Puppet, Chef, SaltStack.
Что такое Ansible?
Ansible — это open-source инструмент для автоматизации развертывания приложений, управления конфигурациями машин и оркестрации инфраструктуры.
Ansible помогает системным администраторам, DevOps-инженерам, разработчикам упростить поддержку сложной инфраструктуры, сократить время на рутинные операции и повысить надёжность всей системы.
При обычном администрировании для того, чтобы развернуть приложения, обновить системы, добавить пользователей или сделать бэкап, нужно вручную прописывать скрипты и копировать конфигурации для каждого сервера. По мере роста инфраструктуры поддерживать систему без инструмента автоматизации становится сложно и трудоемко.
С помощью Ansible все конфигурации можно прописать в одном файле, который затем будет отправлен программой на разные сервера.
Ansible поддерживает подход «инфраструктура как код» или IaC.
IaС - «инфраструктура как код»
Инфраструктура как код (Infrastructure as Code, IaC) — современный стандарт для управления ИТ-ландшафтом, который подразумевает предварительное создание декларативных конфигураций и автоматизацию развертывания приложений.
Идея проста: процессы и взаимодействия серверов, сетей, баз данных и прочих элементов инфраструктуры описываются в виде читаемых, версионируемых файлов YAML, JSON, HCL и других декларативных форматов. Эти файлы можно тестировать и автоматически применять как код.
IaС обеспечивает:
Простоту развертывания
Развернуть приложение можно нажатием кнопки или запуском скрипта
Отсутствие ошибок
Исключено ручное вмешательство девопсов и администраторов вне зависимости от количества серверов
Версионирование
Все изменения можно отследить в Git, при необходимости легко откатиться назад
Стабильность и легкое обслуживание
Подход исключает наличие уникальных конфигураций серверов, все приложения предсказуемо работают
Масштабируемость
Инфраструктура быстро масштабируется скриптами, а не руками
Компоненты Ansible
Ansible представляет собой CLI (интерфейс командной строки).
ПО устанавливается на компьютер администратора с Linux (управляющая нода) и подключается к удаленным серверам (хосты) через протокол SSH (Secure Shell).
То есть, в отличие от большинства других систем управления конфигурацией Ansible не требует установки агента на каждом целевом сервере, а использует безагентную архитектуру.
Ansible состоит из компонентов:
1. Inventory (инвентарь)
Файл, содержащий список серверов (хостов), которыми будет управлять Ansible. Может быть в форматах INI, YAML, JSON или скрипта (динамический инвентарь).
2. Playbook (плейбук)
Файл в декларативном формате YAML, где описываются шаги (tasks), которые нужно выполнить на целевых машинах.
Плейбук – это «сценарий» автоматизации, который позволяет структурированно и повторяемо описывать процессы — от установки ПО до настройки параметров. Один плейбук может управлять сотнями серверов.
Например, плейбук в примере ниже устанавливает Docker и Docker compose на группы виртуальных машин orchestrators и support.
3. Modules (модули)
Библиотеки, которые выполняют конкретные действия на серверах, прописанные в плейбуке. Ansible поставляется с сотнями встроенных модулей, но можно писать и свои.
4. Tasks (таски, задачи)
Отдельные шаги внутри playbook — действия, которые Ansible должен выполнить, например, установить пакет, скопировать файл, изменить конфигурацию. Задачи запускают нужные модули в нужное время.
Таск на примере ниже устанавливает необходимые зависимости (linux-пакеты), которые являются обязательными для дальнейшей установки Docker и Docker Compose
5. Variables (переменные)
Значения, к которым можно обращаться неоднократно.
Переменные можно задавать в отдельных файлах и потом использовать в плейбуках:
Содержимое файла openmetadata_vars.yml:
Или можно задавать переменные прямо в плейбуках:
6. Templates (шаблоны)
Текстовые файлы, в которых используются переменные и логика на языке Jinja2, чтобы динамически создавать конфигурации, скрипты или любые другие файлы.
7. Handlers (обработчики)
Специальные задачи, которые запускаются только при изменении системы, часто применяются для перезапуска сервисов.
Например, если при выполнении задачи ниже Ansible обнаружит, что хотя бы один файл конфигурации, указанный в цикле loop, отличается от того, что уже лежит на целевой машине, то он запустит обработчик для перезапуска службы СlickHouse.
Инструкция notify указывает, какой обработчик запустить.
8. Roles (роли)
Структурированный способ организации кода - набор файлов, шаблонов, переменных, задач и обработчиков, отвечающих за одну функцию.
Различные преднастроенные роли можно найти в open-source хранилище ролей Ansible Galaxy, которое регулярно пополняется членами сообщества Ansible.
Параметры для ролей можно задавать в переменных или в отдельном файле, а также в самих плейбуках:
Ansible устроен достаточно просто и логично, именно это делает его таким популярным инструментом автоматизации.
Как Ansible может применяться в проектах DWH
В проектах разработки и внедрения корпоративных хранилищ данных стабильность и предсказуемость инфраструктуры имеют первостепенное значение.
Ansible помогает достичь этого за счёт автоматизации типовых задач и управления сложными конфигурациями:
Установка и настройка компонентов
Ansible позволяет легко установить и централизованно управлять конфигурациями компонентов хранилища. Автоматизация уменьшает вероятность ошибок, упрощает сопровождение и обеспечивает прозрачность инфраструктуры.
В проектах DWH с помощью Ansible мы разворачиваем:
Категория | Инструмент | Способ установки |
|---|---|---|
СУБД | PostgreSQL | Роль geerlingguy.postgresql |
ClickHouse | Роль ansible-clickhouse | |
Greenplum | Роль gpdb-ansible | |
MySQL / MariaDB | Роль geerlingguy.mysql | |
Redis | Роль geerlingguy.redis | |
ETL / Оркестрация | Apache Airflow | Через Docker или pip |
dbt (core) | Установка через pip, настройка конфигов и переменных через Ansible | |
Airbyte | Развёртывание в Docker-контейнере, настройка .env, docker-compose.yml и параметров соединений через Ansible | |
Брокеры сообщений | Apache Kafka | Роль bitnami.kafka или Confluent, настройка кластеров и Zookeeper |
RabbitMQ | Роль rabbitmq_server, настройка пользователей, очередей, политик | |
Мониторинг | Prometheus | Роль cloudalchemy.prometheus из Ansible Galaxy. Настройка prometheus.yml,targets, alerts |
Grafana | Установка через роль grafana.grafana. Поддержка создания datasource, dashboard и users | |
Filebeat | Роли от Elastic (elastic.beat) или кастомные плейбуки. Настройка через beat.yml | |
Metricbeat | Роли от Elastic (elastic.beat) или кастомные плейбуки. Настройка через beat.yml | |
OpenTelemetry Collector | Установка бинарников или Docker-контейнеров, конфигурация otel-config.yaml, запуск через systemd или Docker | |
Zabbix Agent / Server | Community-роли (например, dj-wasabi.zabbix) или официальные Ansible-роли Zabbix | |
Secrets/Auth | HashiCorp Vault | Роли из Ansible Galaxy (например, ansible-community.hashicorp-vault), включая запуск сервиса, настройку vault.hcl, secrets engine, auth methods |
Автоматическое развертывание через пользовательский интерфейс
К Ansible можно подключить утилиты Ansible Semaphore, Ansible AWX или Ansible Tower, которые обеспечат графический интерфейс для более интуитивного использования инструмента, позволят управлять пользовательскими ролями, легко отслеживать логи и историю изменений.
В наших проектах мы используем Semaphore для небольших проектов и AWX для проектов, в которых требуется более продвинутый и гибкий функционал интерфейса.
Подключение веб-интерфейса можно применить в ситуациях, когда по политике безопасности клиента доступ к PROD-среде закрыт. Интегратор разворачивает систему на выделенных для него серверах, передает клиенту скрипты в Ansible, и клиент самостоятельно мигрирует с dev на prod буквально в пару кликов.
Также инструмент удобен при необходимости устранить неполадки в системе. Все настройки готовятся в Ansible, а клиенту для устранения ошибок нужно только нажать несколько кнопок по заранее подготовленной инструкции, без необходимости ручных настроек.
Восстановление после сбоев, автоматизация DRP (Disaster Recovery Plan)
Ansible можно применять для создания и тестирования процедур аварийного восстановления, что особенно важно для корпоративных хранилищ данных, работа которых критически влияет на принятие бизнес-решений.
Автоматизированные плейбуки обеспечивают быстрое переключение на резервные узлы или восстановление среды из бэкапа. Для этого достаточно указать резервные узлы в hosts и запустить плейбуки.
Если один из серверов вышел из строя, Ansible способен быстро развернуть его заново с нужной конфигурацией, подключить к общей системе и восстановить состояние.
Хранение чувствительных данных
Встроенный инструмент Ansible Vault позволяет шифровать и дешифровать файлы или отдельные переменные с логинами, паролями, токенами для безопасной работы с Git.
В примере, указанном в разделе "1. Inventory (Инвентарь)" пароли сохраняются в переменных окружения и подставляются в этот файл в момент выполнения скрипта Ansible.
Если использовать Ansible Vault, то данный файл будет выглядеть так:
Переменные vault_serv1_password и vault_serv2_password хранятся в файле inventory/group_vars/all/vault.yml. Файл зашифрован с помощью следующей команды (требуется указать пароль или сохранить пароль в файл password_file).
После шифрования файл выглядит таким образом:
Для его расшифровки при запуске ansible-playbook потребуется указать пароль, которым он был зашифрован, или сохранить пароль в файле password_file.
Таким образом, все чувствительные данные сохраняются в гите в зашифрованном виде, и их можно передавать другим коллегам в команде, достаточно переслать им password_file с паролем для шифрования.
Мониторинг и поддержка
С помощью ansible можно настроить системы мониторинга, например, Prometheus, Grafana. Или проверять состояния сервисов без дополнительных систем мониторинга с помощью ролей ansible.builtin.wait_for, ansible.builtin.service, ansible.builtin.shell.
Ansible автоматизирует рутинные задачи, ускоряет развертывание, обеспечивает отказоустойчивость и централизованное управление системой.
Чем Ansible лучше других инструментов управления инфраструктурой
Кроме Ansible существует еще несколько довольно популярных решений для автоматизации управления инфраструктурой:
Terraform – инструмент по модели управление инфраструктурой как кодом (IaC), используется для поднятия виртуальных машин в облаке, настройка виртуальных сетей, развертывание кластеров kubernetes (как сервис облака). Поддерживает AWS, GCP, Azure.
Chef - инструмент автоматизации развертывания и настройки многоуровневых приложений, использующий Ruby DSL для описания конфигураций и работающий по модели «агент-мастер».
Puppet - система управления конфигурацией инфраструктуры, основанная на архитектуре «агент-мастер» и собственном DSL-языке.
SaltStack - инструмент управления конфигурациями и оркестрации массовых операций, поддерживающий как модель «мастер-агент», так и безагентный режим (через SSH), с использованием YAML и шаблонов Jinja2 для описания состояний.
Кроме перечисленных инструментов CM (Configuration Management) для автоматизации используют python-библиотеку Fabric, Bash-скрипты, Make.
Они позволяют выполнять команды на удалённых серверах (обычно через SSH), но не предоставляют полноценного управления конфигурациями, идемпотентности и масштабируемости как Ansible или другие CM-инструменты.
Некоторые вендоры используют Ansible под капотом для автоматизации установки, обновления и настройки компонентов кластерных продуктов. Например, таким инструментом является оркестратор Arenadata Cluster Manager, который работает внутри экосистемы Arenadata. ACM используется при разработке DWH на базе платформы Arenadata с инструментами Arenadata DB, Arenadata Hadoop и др.
Приводим детальную таблицу сравнения инструментов:
Характеристика | Ansible | Puppet | Chef | SaltStack | Terraform |
|---|---|---|---|---|---|
Архитектура | Безагентная, подключается к хостам по SSH | Агент/мастер | Агент/мастер | Агент/мастер, но может работать и без агента (salt-ssh) | Безагентная, работает через API, pull-модель |
Язык описания | YAML | DSL на базе Ruby | Ruby | YAML + Jinja2 | HCL |
Кривая обучения | Низкая: YAML + SSH, понятная структура, хорошая документация | Средняя: требует изучения DSL и архитектуры агент-мастер | Крутая: требует понимания программирования, инфраструктуры и концепций Chef | Средняя: YAML и Jinja2 просты, но архитектура и модули могут быть непривычны | Средняя: HCL прост, но требует понимания принципов IaC, провайдеров и состояний |
CI/CD | Легко запускается из GitLab, Jenkins, GitHub Actions, ArgoCD и др. | Поддерживает CI через GitLab, но требует настройки Puppet Server/Agent, а также PuppetDB для хранения состояний | Chef Automate предоставляет мощную CI/CD инфраструктуру, но требует изучения Ruby DSL и настройки рабочих потоков | Можно интегрировать с CI/CD через REST API или SaltStack Reactor требует настройки пайплайнов вручную | Отлично интегрируется с GitLab CI/CD, GitHub Actions, Jenkins и др. через CLI |
Возможности интеграции | Поддерживает плагины, REST API, cloud-модули (AWS, Azure, GCP), Vault, Prometheus, CI/CD, Kubernetes | Требуют настроек: PuppetDB, API, внешние модули | Через Chef Automate и Ruby-код можно интегрироваться с API, Vault, Git и CI | Поддерживает REST API, cloud-интеграции, Vault, внешние event-шины (Redis, RabbitMQ) | Большое количество провайдеров: AWS, Azure, GCP, Kubernetes, GitHub, Datadog и др. Поддерживает REST API |
Идемпотентность (состояния применяются только при отклонении от нужного) | Поддерживает | Поддерживает | Поддерживает | Поддерживает | Поддерживает |
Шаблоны и переменные | Переменные на всех уровнях (host, group, global), Jinja2-шаблоны, фильтры, условия, циклы | Используются Ruby-переменные и шаблоны | Используются Ruby-переменные и шаблоны | YAML + Jinja2, можно использовать переменные, условия, макросы и многое другое | Поддерживает переменные, шаблоны через templatefile, условия, циклы через for_each, count, dynamic |
Механизмы шифрования | Есть утилита Ansible Vault + интеграция с внешними Vault-сервисами | Puppet Hiera + интеграция с внешними Vault-сервисами | Encrypted Data Bags + интеграция с внешними Vault-сервисами | GPG, HashiCorp Vault, Simple Data Bags (SDB), Kubernetes Secrets | HashiCorp Vault |
Установка и конфигурация сторонних BI/ETL-инструментов | Полная поддержка любых инструментов | Требуется написание manifests и шаблонов под каждый компонент, что увеличивает трудоёмкость | Высокая гибкость, но требует глубокого знания Ruby и устройства Chef-ресурсов | Требует составления state-файлов и pillar-структур, настройка — через Jinja2-шаблоны | Лучше подходит для развёртывания инфраструктуры и базовых компонентов |
Стоимость | Есть бесплатная open source версия и платная Red Hat Ansible Automation Platform (включает GUI (AWX/Tower), контроль доступа, аудит, CI-интеграции и поддержку) | Есть бесплатная open source версия и платная Puppet Enterprise (включает поддержку, визуальный интерфейс, отчётность, управление пользователями) | Есть бесплатная open source версия и платная Progress Chef (расширенный UI, поддержка, интеграции, комплаенс) | Есть бесплатная open source версия и платная в VMware Aria Automation Config | Open source-версия доступна бесплатно, версия Terraform Cloud/Enterprise включает расширенные функции, UI, контроль доступа, аудит, комплаенс |
Почему именно Ansible: преимущества для DWH-проектов
Простота и читаемость
Декларативный YAML-синтаксис позволяет быстро писать и понимать playbook'и, что удобно как для админов, так и для DWH-инженеров, даже без опыта в DevOps
Agentless (архитектура без агентов)
Для работы не нужно устанавливать дополнительное PKI-окружение, достаточно SSH-доступа, что упрощает администрирование и безопаснее для корпоративной среды
Гибкость и универсальность для проектов DWH
Ansible можно использовать и для настройки окружения (кластеры баз данных, ETL-инструменты), и для управления конфигурацией, и для оркестрации запуска процессов, при этом инструмент обеспечит единую точку управления всей инфраструктурой
Интеграция с Git и CI/CD
Инструмент прекрасно работает в связке с GitLab CI, Jenkins и др., что позволяет проще тестировать, откатывать версии и масштабировать системы
Активное сообщество, готовые модули и роли для любых задач
Роли и модули для PostgreSQL, Hadoop, Kafka, Airflow, Spark и другие DWH-компоненты можно найти в библиотеке Ansible Galaxy
Ansible, как правило, выигрывает другим инструментам для автоматизации развертывания и обслуживания компонентов DWH за счёт простоты и универсальности. Он особенно хорош, если инфраструктура гибридная (часть в облаке, часть on-premise), и нужно автоматизировать как развёртывание, так и управление конфигурациями.
В следующих статьях опишем конкретные кейсы использования Ansible.
