Infrastructure as Code (IaC) — это подход, при котором инфраструктуру описывают не в документах и скриншотах из облака, а в виде кода. Вместо того чтобы руками тыкать в консоль AWS или создавать VM через веб-морду, вы пишете конфигурационные файлы, а специальные инструменты уже создают все нужные ресурсы автоматически.
Идея в том, что инфраструктура становится таким же артефактом, как приложение: её можно версионировать, ревьюить, тестировать, катать через CI/CD. Серверы, сети, балансировщики, базы, права доступа — всё описывается декларативно и живёт в репозиториях.
Чаще всего для этого используют YAML, JSON, HCL (у Terraform), какие-то DSL. Код лежит в Git, на него запускаются проверки, он проходит review, а потом через pipeline попадает в прод.
Преимущества IaC #
- Повторяемость — одно и то же описание можно применить для dev, staging и prod и получить сопоставимые окружения;
- Скорость — окружение поднимается за минуты, а не через долгую ручную настройку;
- Контроль версий — видно, кто что поменял и когда, легко сделать diff или откатиться;
- Тестируемость — конфиги можно валидировать до применения, например, тем же
terraform plan; - Масштабируемость — меньше ручных ошибок, больше шаблонов: копируете проверенный модуль, а не настройки из памяти.
Популярные инструменты #
- Terraform — один из самых массовых инструментов для мультиоблачных сценариев и не только;
- Pulumi — тот же подход, но с использованием полноценных языков (TypeScript, Python и др.);
- CloudFormation — нативное решение от AWS для описания ресурсов;
- Ansible — чаще используется уже после создания ресурсов: настройка пакетов, конфигов и сервисов.
Безопасность #
Плюс IaC в том, что проверять безопасность можно до того, как что-либо попадёт в облако. Инструменты вроде Checkov, tfsec или OPA (Open Policy Agent) прогоняют ваши конфиги на соответствие политикам: нет ли публичных бакетов, включено ли шифрование, правильно ли настроены Security Groups и т.п.
Пример #
Допустим, в AWS вы хотите с нуля поднять окружение. Один Terraform-модуль может:
- создать VPC с нужной сетевой структурой;
- развернуть несколько EC2-инстансов;
- настроить IAM-роли и политики доступа;
- задать правила в Security Groups;
- включить логирование и мониторинг — и всё это без захода в веб-консоль, просто через запуск кода.
На практике IaC стал базой для современного DevOps-подхода: без него сложно поддерживать точность, масштаб и контролируемость инфраструктуры, особенно когда речь идёт о больших облачных платформах.
Пример Terraform-конфигурации (EC2 в AWS) #
Файл: main.tf
provider "aws" {
region = "us-east-1"
}
resource "aws_instance" "web_server" {
ami = "ami-0c55b159cbfafe1f0" # Amazon Linux 2
instance_type = "t2.micro"
tags = {
Name = "web-server"
Environment = "dev"
}
}
Что делает этот код #
provider "aws"говорит Terraform, что работать нужно с AWS и использовать регионus-east-1(или любой другой, который вы поставите).resource "aws_instance"описывает EC2-инстанс: какой образ взять, какой тип машины, и как его назвать.tagsдобавляют метки — полезно для поиска, мониторинга, отчётности по затратам.
Команды для работы #
terraform init
инициализирует проект: подтягивает провайдеры и модули.terraform plan
показывает, какие изменения будут внесены (создать, изменить, удалить ресурсы).terraform apply
применяет план — реально создаёт или меняет ресурсы.terraform destroy
удаляет всё, что было создано этим конфигом.
Пример базовой проверки безопасности (с Checkov) #
Команда вида:
checkov -d .
пройдётся по текущему каталогу с конфигами и укажет на типичные проблемы, вроде:
- используется старый или сомнительный AMI;
- для дисков не включено шифрование;
- слишком открытые правила в Security Group и тому подобное.
