Введение: зачем автоматизировать развертывание Workflow Engine
Развернуть Workflow Engine вручную - значит потратить от 4 до 8 часов на установку ОС, настройку зависимостей, базы данных, очереди сообщений и самого движка. На втором окружении цифры повторяются. На третьем появляются расхождения в конфигурациях, которые приводят к трудновоспроизводимым ошибкам на проде.
Terraform и Ansible решают эту проблему через Infrastructure as Code. Terraform создаёт инфраструктуру: виртуальные машины, сети, диски, базы данных как услугу. Ansible настраивает каждую машину до целевого состояния: устанавливает пакеты, разворачивает конфигурационные файлы, запускает сервисы. Результат - идентичные окружения, разворачиваемые за 15-20 минут одной командой.
В этой статье вы получите готовую архитектуру IaC-проекта, примеры Terraform-модулей для AWS и bare-metal, а также Ansible-роли для PostgreSQL, RabbitMQ и самого Workflow Engine. Код проверен на Ubuntu 22.04 и Debian 12. Если вы ещё не определились с выбором инструментов, рекомендуем прочитать наше сравнение Terraform и Ansible - оно поможет понять разделение зон ответственности между оркестрацией и конфигурационным менеджментом.
Архитектура Workflow Engine: какие компоненты нужно развернуть
Типовой Workflow Engine состоит из четырёх компонентов. Сервер приложений выполняет бизнес-логику маршрутизации процессов. База данных хранит определения процессов, состояния экземпляров и историю выполнения. Очередь сообщений обеспечивает асинхронное взаимодействие между сервисами и гарантирует доставку задач. Хранилище файлов содержит артефакты процессов: документы, логи, временные данные.
Каждый компонент разворачивается на отдельной виртуальной машине или в контейнере. Такой подход упрощает масштабирование и изоляцию отказов. В облаке вы получаете управляемые сервисы для БД и очереди, на bare-metal - разворачиваете всё самостоятельно.
Сервер приложений и его зависимости
Workflow Engine написан на Java 17 и требует JRE не ниже этой версии. На сервере необходимы:
- ОС: Ubuntu 22.04 LTS или Debian 12
- Пакеты: openjdk-17-jre-headless, unzip, curl, jq
- Системный пользователь workflow с UID 1200 и домашней директорией /opt/workflow
- Systemd-юнит для управления сервисом
Движок слушает порт 8080 для HTTP API и порт 8081 для метрик Prometheus. Файлы конфигурации лежат в /etc/workflow/config.yml. Все пути и порты параметризуются через переменные Ansible, что позволяет адаптировать развёртывание под корпоративные стандарты.
База данных: выбор и конфигурация
PostgreSQL 15 - основной выбор для Workflow Engine. Причины: поддержка JSONB для хранения переменных процессов, транзакционная целостность состояний, развитая экосистема инструментов резервного копирования. MySQL 8.0 подходит для организаций с уже выстроенными процессами вокруг этой СУБД, но уступает в работе с полуструктурированными данными.
Перед запуском движка нужно создать отдельную базу данных workflow_db и пользователя workflow_user с паролем не короче 24 символов. Пароль генерируется через Ansible Vault и никогда не хранится в открытом виде в репозитории. Подключение настраивается через SSL с проверкой сертификата.
Очередь сообщений: RabbitMQ или Kafka
RabbitMQ 3.12 - выбор по умолчанию для Workflow Engine. Он обеспечивает гарантированную доставку сообщений через подтверждения publisher confirm и consumer ack. Этого достаточно для надёжной маршрутизации задач между узлами движка.
Apache Kafka нужна, когда количество событий превышает 50 000 в секунду и требуется долгосрочное хранение сообщений с возможностью повторного чтения. Для большинства внедрений Workflow Engine такая нагрузка нетипична, поэтому RabbitMQ остаётся оптимальным решением. Конфигурация включает создание vhost /workflow, пользователя workflow_mq с правами на запись и чтение, а также настройку политики high-availability для зеркалирования очередей.
Подготовка инфраструктуры с Terraform
Terraform создаёт все ресурсы, которые нужны Workflow Engine для работы. Серверы, сети, управляемые базы данных, балансировщики - всё описывается декларативно в HCL-файлах. После выполнения terraform apply вы получаете готовый к настройке набор машин с известными IP-адресами.
Полный цикл автоматизации с Terraform и Ansible мы разбирали в отдельном руководстве - там есть готовый скрипт Dynamic Inventory и настройка удалённого state-файла в S3.
Структура Terraform-проекта и модули
Проект организован по модульному принципу. Корневая директория содержит три файла:
main.tf- вызов модулей с передачей параметровvariables.tf- объявление всех входных переменныхoutputs.tf- экспорт IP-адресов и строк подключения для Ansible
Модули лежат в поддиректории modules/ и инкапсулируют логику создания типовых компонентов. Модуль compute создаёт виртуальную машину с заданными характеристиками, подключает её к сети и назначает теги. Модуль database разворачивает управляемый PostgreSQL в облаке или устанавливает СУБД на выделенный сервер. Модуль network описывает VPC, подсети и правила firewall.
Пример вызова модуля для сервера приложений:
module "app_server" {
source = "./modules/compute"
name = "workflow-app"
instance_type = var.app_instance_type
subnet_id = module.network.private_subnet_id
security_groups = [module.network.app_sg_id]
disk_size = 50
ssh_key_name = var.ssh_key_name
}Развертывание в облаке: AWS, GCP, Azure
Для AWS конфигурация провайдера указывает регион eu-west-1 и использует IAM-роль с правами на создание EC2, RDS и MQ. Security groups открывают порт 22 для Ansible, порт 8080 для API движка и порт 5432 для PostgreSQL только между серверами внутри VPC.
GCP требует включения Compute Engine API и Cloud SQL API в проекте. Terraform-провайдер google аутентифицируется через сервисный аккаунт с ролью roles/compute.admin. Azure использует провайдер azurerm с аутентификацией через Service Principal. Во всех трёх облаках результат одинаков: набор виртуальных машин, управляемая база данных и очередь сообщений, готовые к настройке Ansible.
Для быстрого старта в облаке подойдёт Timeweb Cloud - он предоставляет VDS с предустановленными ОС, управляемые базы данных и S3-совместимое хранилище, что сокращает объём Terraform-кода для типовых конфигураций.
Развертывание на bare-metal с помощью Terraform
На физических серверах Terraform управляет ресурсами через провайдер libvirt. Он создаёт виртуальные машины на KVM-гипервизоре, подключает их к бриджевой сети и выделяет дисковые образы из шаблона cloud-init. Альтернативный подход - использовать провайдер external, который вызывает Bash-скрипт для взаимодействия с IPMI или API серверного оборудования.
Особенность bare-metal - статическая конфигурация сети. IP-адреса назначаются вручную или через DHCP-резервации, VLAN настраиваются на коммутаторах до запуска Terraform. Модуль bare-metal-compute принимает MAC-адрес сервера и возвращает его IP после загрузки, что позволяет Ansible подключиться к целевой машине без инвентаризации вручную.
Конфигурация Workflow Engine с Ansible
Ansible получает инвентарь от Terraform и приводит каждую машину к целевому состоянию. Плейбук site.yml вызывает три роли последовательно: database, message-queue, workflow-engine. Порядок важен - движок запускается последним, когда БД и очередь уже принимают подключения.
Все секреты хранятся в Ansible Vault. Пароли БД, токены API, SSL-сертификаты шифруются AES-256 и безопасно лежат в репозитории. Переменные окружений (окружение dev/stage/prod) вынесены в group_vars и переопределяют параметры под конкретный стенд.
Ansible-роль для базы данных
Роль database выполняет шесть задач:
- Установка PostgreSQL 15 из официального репозитория apt.postgresql.org
- Настройка postgresql.conf: listen_addresses = '*', max_connections = 200
- Настройка pg_hba.conf: разрешение подключений с IP сервера приложений по SSL
- Создание базы workflow_db с кодировкой UTF8 и локалью en_US.UTF-8
- Создание пользователя workflow_user со сгенерированным паролем
- Назначение прав: GRANT ALL PRIVILEGES ON DATABASE workflow_db TO workflow_user
Идемпотентность достигается проверкой существования базы и пользователя перед созданием. Повторный запуск роли не приводит к ошибкам и не меняет пароль, если пользователь уже существует.
Ansible-роль для очереди сообщений
Роль message-queue устанавливает RabbitMQ 3.12 и выполняет настройку через модуль rabbitmq_parameter. Задачи:
- Добавление репозитория RabbitMQ и установка пакета rabbitmq-server
- Запуск сервиса и включение плагина rabbitmq_management
- Создание vhost /workflow
- Создание пользователя workflow_mq с паролем из Vault
- Назначение прав: configure, write, read на vhost /workflow
- Настройка политики ha-all для зеркалирования всех очередей на два узла
Для кластерной конфигурации роль поддерживает переменную rabbitmq_cluster_nodes. Если она задана, выполняется присоединение к существующему кластеру через rabbitmqctl join_cluster.
Ansible-роль для Workflow Engine
Основная роль workflow-engine выполняет развёртывание движка из архива дистрибутива. Порядок задач:
- Создание системного пользователя workflow с домашней директорией /opt/workflow
- Копирование и распаковка архива дистрибутива во временную директорию
- Перемещение файлов в /opt/workflow/current с атомарной заменой через симлинк
- Генерация config.yml из Jinja2-шаблона с подстановкой параметров подключения к БД и очереди
- Установка systemd-юнита workflow-engine.service с автоматическим перезапуском при сбое
- Запуск сервиса и проверка доступности через HTTP-запрос к /health endpoint
Шаблон config.yml параметризует все точки подключения. Переменные database_host, database_port, mq_host, mq_port берутся из инвентаря Ansible, который был сгенерирован из outputs Terraform. Это исключает ручное копирование IP-адресов и ошибки при переносе между окружениями.
Полный цикл развертывания: от кода до работающего движка
Связка Terraform и Ansible запускается одним скриптом deploy.sh. Он выполняет terraform apply с автоматическим подтверждением, извлекает outputs в JSON, генерирует инвентарь Ansible и запускает плейбук. Полный цикл для трёх серверов занимает 12-18 минут в облаке AWS и 8-12 минут на bare-metal с предварительно настроенным гипервизором.
Интеграция Terraform и Ansible
Скрипт генерации инвентаря использует команду terraform output -json. Из полученного JSON извлекаются IP-адреса серверов и строки подключения к управляемым сервисам. Результат записывается в файл inventory.ini в формате, понятном Ansible:
[database] db01 ansible_host=10.0.1.10 [message_queue] mq01 ansible_host=10.0.1.20 [workflow_engine] app01 ansible_host=10.0.1.30 [all:vars] ansible_user=ubuntu ansible_ssh_private_key_file=~/.ssh/workflow_key
Ansible запускается с флагом -i inventory.ini. Переменные подключения к БД и очереди передаются через group_vars/all.yml, сгенерированные тем же скриптом из outputs Terraform. Полная автоматизация этого процесса описана в нашем руководстве по IaC-стеку.
Проверка развертывания
После выполнения плейбука запускается smoke-тест. Bash-скрипт отправляет тестовый процесс через API движка:
curl -X POST http://app01:8080/api/v1/processes \
-H "Content-Type: application/json" \
-d '{"processDefinitionId": "smoke-test", "variables": {"test": true}}'Ожидаемый ответ - HTTP 201 с ID созданного экземпляра процесса. Дополнительно проверяются логи сервиса на отсутствие ERROR-сообщений и метрики Prometheus на эндпоинте :8081/metrics. Если все проверки пройдены, развёртывание считается успешным.
Типичные ошибки и их решение
Первая по частоте проблема - несоответствие версий. Terraform-провайдер AWS версии 5.x требует обновлённого синтаксиса для ресурса aws_instance: параметр security_groups заменён на vpc_security_group_ids. Решение: зафиксировать версии провайдеров в блоке required_providers и использовать terraform version constraint.
Вторая проблема - таймауты Ansible при подключении к только что созданным машинам. Облачные провайдеры назначают IP-адрес до завершения загрузки ОС, и SSH-сервер может быть ещё не готов. Решение: добавить wait_for_connection в плейбук с таймаутом 300 секунд и задержкой 10 секунд между попытками.
Третья проблема - отказ в подключении к PostgreSQL из-за неправильной записи в pg_hba.conf. Ansible-роль database использует модуль postgresql_pg_hba, который гарантирует корректный синтаксис. При ручном редактировании легко пропустить тип аутентификации scram-sha-256 или перепутать порядок правил.
Для отладки Terraform используйте план с флагом -target, чтобы применить изменения только к проблемному ресурсу. Для Ansible - флаг -vvv, который выводит полный вывод команд на целевой машине. Логи Workflow Engine находятся в /var/log/workflow/application.log и содержат детализацию ошибок подключения к БД или очереди.
Заключение: дальнейшие шаги и лучшие практики
Код инфраструктуры должен храниться в Git-репозитории отдельно от кода приложения. Ветка main соответствует production-окружению, ветка develop - тестовому стенду. Изменения проходят через pull request с обязательным запуском terraform plan в CI.
Внедрите CI/CD для инфраструктуры через GitHub Actions или GitLab CI. Пайплайн запускает terraform validate, terraform plan, ansible-lint и ansible-playbook --check на каждый коммит. Применение изменений на production происходит только после ручного approval. Подробный план перехода на IaC с примерами пайплайнов мы разобрали в руководстве по внедрению Infrastructure as Code.
Настройте мониторинг Workflow Engine через Prometheus и Grafana. Метрики количества выполняемых процессов, времени ответа API и глубины очереди RabbitMQ помогут обнаружить деградацию до того, как она повлияет на пользователей. State-файл Terraform храните в удалённом бэкенде S3 или Terraform Cloud с блокировками, чтобы исключить одновременные изменения от разных инженеров.
Предоставленные модули и роли - это фундамент, который сокращает время развёртывания с дней до минут. Адаптируйте их под свои требования к безопасности, сетевым политикам и версиям ПО. Делитесь опытом и улучшениями в комментариях - это помогает всей экосистеме IaC становиться надёжнее.