Infrastructure as Code

Infrastructure as Code (IaC, «инфраструктура как код») — подход, при котором инфраструктура — виртуальные машины, сети, балансировщики, базы данных, DNS-записи, права доступа — описывается в текстовых файлах, а не настраивается вручную через веб-консоль или по SSH. Эти файлы хранятся в Git, проходят ревью, тестируются и применяются автоматически, как обычный программный код.^[5]

IaC — одна из основ DevOps: она позволяет за минуты воспроизвести окружение, понять, кто и зачем изменил настройки, и выкатывать изменения инфраструктуры через тот же конвейер CI/CD, что и приложения.

Проблема, которую решает IaC

При ручной настройке серверы постепенно превращаются в «снежинки» — каждый уникален, никто точно не знает, как он устроен, а воспроизвести его после сбоя невозможно. Изменения не документированы, тестовое окружение незаметно отличается от продакшена (дрейф конфигурации), а повторение одних и тех же действий на десятках машин ведёт к ошибкам. С появлением облаков, где инфраструктуру можно создавать через API, стало естественным управлять ею программно.

Декларативный и императивный подходы

Ключевое свойство хороших инструментов IaC — идемпотентность: повторное применение той же конфигурации приводит к тому же результату и не делает лишних изменений. Ansible занимает промежуточное положение: сценарии пишутся как последовательность задач, но каждая задача (модуль) идемпотентна.

Классы инструментов

• Предоставление ресурсов (provisioning) — создание облачной инфраструктуры: Terraform и OpenTofu, Pulumi (на обычных языках программирования), AWS CloudFormation, Azure Bicep.^[2]
• Управление конфигурацией — настройка того, что внутри серверов: пакеты, файлы, службы. Ansible (подключается по SSH, без агентов), Puppet, Chef, Salt.^[4]
• Образы и контейнеры — вместо настройки работающих серверов собирают готовые образы: Packer для образов ВМ, Dockerfile для контейнеров. Это неизменяемая инфраструктура: сервер не обновляют, а заменяют новым.
• Описание приложений в кластере — манифесты Kubernetes, чарты Helm, Kustomize; в подходе GitOps агенты (Argo CD, Flux) непрерывно приводят кластер к состоянию из репозитория.

Пример: Terraform

# main.tf
terraform {
  required_providers {
    aws = { source = "hashicorp/aws", version = "~> 5.0" }
  }
}

provider "aws" {
  region = "eu-central-1"
}

resource "aws_instance" "web" {
  count         = 2
  ami           = "ami-0123456789abcdef0"
  instance_type = "t3.small"
  tags          = { Name = "web-${count.index}" }
}

output "web_ips" {
  value = aws_instance.web[*].public_ip
}

terraform init      # скачать провайдеры
terraform plan      # показать, что будет создано, изменено или удалено
terraform apply     # применить изменения

Команда plan — главная страховка: перед применением видно точный список изменений, и его можно приложить к pull request. Terraform хранит соответствие описания и реальных ресурсов в файле состояния (state); в команде его держат в удалённом хранилище с блокировкой, чтобы два человека не применяли изменения одновременно.^[6]

Пример: Ansible

# playbook.yml
- hosts: web
  become: true
  tasks:
    - name: Установить nginx
      ansible.builtin.apt:
        name: nginx
        state: present
        update_cache: true
    - name: Включить и запустить nginx
      ansible.builtin.systemd:
        name: nginx
        enabled: true
        state: started

Запуск ansible-playbook -i inventory.ini playbook.yml приведёт все серверы группы web к описанному состоянию; при повторном запуске Ansible сообщит, что изменений нет.

История

Идеи автоматизации конфигурации восходят к CFEngine (1993). Волна инструментов пришла вместе с облаками и DevOps: Puppet (2005), Chef (2009), AWS CloudFormation (2011), Ansible (2012), Terraform (2014). В 2023 году HashiCorp перевела Terraform с открытой лицензии MPL на Business Source License; в ответ сообщество создало открытый форк OpenTofu под эгидой Linux Foundation, совместимый с конфигурациями Terraform.^[3] Систематически подход описан в книге Кифа Морриса «Infrastructure as Code».^[1]

Хорошие практики

• Все изменения — только через код и ревью; ручные правки в консоли считаются инцидентом и устраняются.
• Модули для повторяющихся элементов и отдельные конфигурации для окружений (dev, staging, prod).
• Секреты — не в репозитории, а в хранилищах (Vault, менеджеры секретов облаков, SOPS).
• plan в CI для каждого pull request, apply — после слияния.
• Регулярная проверка дрейфа: не изменилось ли что-то в обход кода.

См. также

• Terraform и OpenTofu
• Ansible
• CI/CD
• Kubernetes
• Git

Источники

1. Kief Morris — Infrastructure as Code (O'Reilly)
2. Terraform Documentation — What is Terraform?
3. OpenTofu — документация
4. Ansible Documentation — Getting started
5. Martin Fowler — InfrastructureAsCode
6. Terraform Documentation — State