Автоматизация развёртывания инфраструктуры (Terraform + Ansible)

Использовать Terraform и Ansible вместе — стандартный паттерн: Terraform описывает и создаёт облачные ресурсы (VM, сети, балансировщики, БД, IAM, S3 и т.д.), а Ansible — конфигурирует ОС и приложения на этих ресурсах. Ниже — практическое руководство с ключевыми концепциями, workflow и лучшими практиками.

Terraform — инфраструктура как код (declarative)

• Основные элементы: провайдеры, ресурсы, модули, переменные, outputs, state.

• Remote state + locking: храните состояние в S3/GCS/Terraform Cloud с блокировкой (DynamoDB для S3), чтобы избежать коллизий.

• Модули: вынесите повторяющиеся конструкции (vpc, db, k8s-cluster) в версиируемые модули.

• Workflow: terraform fmt → terraform validate → terraform plan → code review → terraform apply (желательно через CI/approval).

• Безопасность: не держите secrets в tfvars в репо; используйте Vault или cloud KMS; пометьте outputs как sensitive.

• Policy-as-code: используйте tfsec / checkov / OPA для проверки политик до apply.

• CI/CD: запускать plan в PR (показывать diff), apply — только после мержа или через автоматизацию (Terraform Cloud, Atlantis).

Пример простого output для Ansible inventory:

output "app_ips" {
value = aws_instance.app.\*.public_ip
}

Ansible — конфигурация и управление (imperative / procedural)

• Структура: inventory → playbooks → roles → tasks → handlers → templates.

• Idempotence: пишите idempotent-таски (yum/apt/module вместо raw commands).

• Secrets: Ansible Vault или external secrets (Vault/KMS) для паролей.

• Dynamic inventory: генерируйте inventory из terraform outputs, cloud inventory scripts или используйте terraform-inventory.

• Testing: molecule для unit тестов ролей; ansible-lint; CI запускает ansible-playbook --check и затем реальные прогрузы только после review.

Пример playbook (bootstrap):

\- hosts: app
become: yes
roles:
\- common
\- app

Как связать Terraform и Ansible

• Preferred: Terraform создаёт ресурсы, выводит IP/хэши в outputs. CI собирает outputs и запускает Ansible с dynamic inventory, передавая приватные ключи/учётные данные.

• Не рекомендую: полагаться на remote-exec provisioner в Terraform для сложной конфигурации — это удобно для простого bootstrap, но ухудшает идемпотентность и трассируемость.

• Лучше: использовать cloud-init/Packer для создания базовых образов (immutable images), а Ansible — для post-provision config/patching либо для CI-driven deployments.

CI/CD и организация

• Terraform: отдельный pipeline: plan on PR, apply on main (с approval). Используйте workspace/env per stage.

• Ansible: pipeline запускает playbooks после успешного apply. Можно интегрировать через AWX/Ansible Tower для RBAC, расписаний и истории выполнения.

• Secrets in CI: inject через secret store, не храните в репо.

Тестирование и валидация

• Статический анализ: terraform fmt/validate, tflint, tfsec.

• Интеграционные тесты: terratest (Go) или kitchen-terraform.

• Smoke тесты после deploy: healthchecks, e2e тесты, SLI проверки.

Практики для надёжности

• Immutable infra: образ + deploy → меньше drift.

• Tagging & naming: автоматические теги, чтобы мониторинг и billing работал корректно.

• Backups и state backups: версионируйте remote state и делайте бэкапы.

• Rollback: планируйте откат (blue/green, canary, terraform destroy/replace с осторожностью).

• Минимизируйте drift: запрещайте ручные изменения, фиксируйте audit, интегрируйте drift detection.

Примеры workflow (коротко)

1. dev ветка → terraform plan (preview infra changes)

2. PR ревью → approved → terraform apply в staging

3. CI читает terraform outputs → запускает Ansible playbook на новых хостах

4. Smoke tests → promotion to prod через тот же pipeline с approvals

Следуя этим практикам, вы получите предсказуемый, повторяемый и безопасный процесс развёртывания инфраструктуры и конфигурации.