# Infrastructure as Code

> Подход, при котором серверы, сети, базы данных и прочая инфраструктура описываются в виде кода, хранятся в системе контроля версий и создаются автоматически.

Источник: https://llmdocs.ru/wiki/infrastructure-as-code/ · обновлено 2026-11-09 · лицензия CC BY-SA 4.0

- **Сокращение**: IaC
- **Подходы**: декларативный и императивный
- **Предоставление ресурсов**: Terraform, OpenTofu, Pulumi, AWS CloudFormation
- **Управление конфигурацией**: Ansible, Puppet, Chef, Salt
- **Ключевые свойства**: идемпотентность, воспроизводимость, ревью изменений
- **Связанные практики**: GitOps, CI/CD, неизменяемая инфраструктура
**Infrastructure as Code** (IaC, «инфраструктура как код») — подход, при котором инфраструктура — виртуальные машины, сети, балансировщики, базы данных, DNS-записи, права доступа — описывается в текстовых файлах, а не настраивается вручную через веб-консоль или по SSH. Эти файлы хранятся в [Git](https://llmdocs.ru/wiki/git.md), проходят [ревью](https://llmdocs.ru/wiki/pull-request.md), тестируются и применяются автоматически, как обычный программный код.[5]

IaC — одна из основ DevOps: она позволяет за минуты воспроизвести окружение, понять, кто и зачем изменил настройки, и выкатывать изменения инфраструктуры через тот же конвейер [CI/CD](https://llmdocs.ru/wiki/ci-cd.md), что и приложения.

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

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

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

| | Декларативный | Императивный |
|---|---|---|
| Что описывается | желаемое конечное состояние | последовательность шагов |
| Пример | «должно быть 3 сервера такого размера» | «создай сервер, затем ещё два» |
| Повторный запуск | ничего не меняет, если состояние совпадает | может создать дубликаты |
| Инструменты | Terraform, OpenTofu, CloudFormation, манифесты [Kubernetes](https://llmdocs.ru/wiki/kubernetes.md) | скрипты на Bash, SDK облаков |

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

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

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

## Пример: Terraform

```hcl
# 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
}
```

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

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

## Пример: Ansible

```yaml
# 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](https://llmdocs.ru/wiki/terraform-opentofu.md)
- [Ansible](https://llmdocs.ru/wiki/ansible.md)
- [CI/CD](https://llmdocs.ru/wiki/ci-cd.md)
- [Kubernetes](https://llmdocs.ru/wiki/kubernetes.md)
- [Git](https://llmdocs.ru/wiki/git.md)

## Источники

1. [Kief Morris — Infrastructure as Code (O'Reilly)](https://www.oreilly.com/library/view/infrastructure-as-code/9781098114664/)
2. [Terraform Documentation — What is Terraform?](https://developer.hashicorp.com/terraform/intro)
3. [OpenTofu — документация](https://opentofu.org/docs/)
4. [Ansible Documentation — Getting started](https://docs.ansible.com/ansible/latest/getting_started/index.html)
5. [Martin Fowler — InfrastructureAsCode](https://martinfowler.com/bliki/InfrastructureAsCode.html)
6. [Terraform Documentation — State](https://developer.hashicorp.com/terraform/language/state)