Infrastructure as Code

Infrastructure as Code, или IaC, — это подход к управлению ИТ-инфраструктурой, при котором серверы, сети, виртуальные машины, балансировщики, хранилища и другие ресурсы описываются в коде или конфигурационных файлах.

Вместо ручного создания серверов через веб-интерфейс облачного провайдера инженер описывает необходимое состояние инфраструктуры в файле. Затем специальный инструмент автоматически создает или изменяет ресурсы в соответствии с этим описанием.

Infrastructure as Code широко используется в DevOps, SRE, облачной инфраструктуре, Kubernetes, CI/CD и автоматизации дата-центров. Подход помогает сделать инфраструктуру повторяемой, проверяемой и управляемой так же, как программный код.

Что такое Infrastructure as Code простыми словами

Представим, что компании нужно развернуть пять одинаковых серверов для нового приложения.

При ручном подходе администратор заходит в панель управления, создает каждую виртуальную машину, выбирает процессор, память, сеть, диск и правила доступа.

Если через месяц такую же инфраструктуру нужно создать в другом регионе, все действия приходится повторять. При этом легко забыть один параметр или настроить сервер немного иначе.

При Infrastructure as Code инженер один раз описывает требуемую конфигурацию в файле, а затем запускает автоматическое развертывание.

Главная идея IaC — инфраструктура должна быть описана в воспроизводимом виде, а не существовать только как набор ручных настроек.

Для чего нужен Infrastructure as Code

IaC решает проблему ручного управления инфраструктурой и расхождений между окружениями.

• автоматизация создания серверов;
• быстрое развертывание одинаковых окружений;
• управление сетями и правилами доступа;
• создание облачных ресурсов;
• стандартизация инфраструктуры;
• хранение конфигурации в Git;
• проверка изменений через Code Review;
• воспроизводимое восстановление инфраструктуры;
• сокращение количества ручных ошибок;
• интеграция инфраструктуры с CI/CD.

Как работает Infrastructure as Code

Типовой процесс состоит из нескольких этапов.

1. Инженер описывает инфраструктуру в конфигурационном файле.
2. Файл сохраняется в системе контроля версий.
3. Изменение проходит проверку.
4. IaC-инструмент читает описание.
5. Он сравнивает требуемое состояние с текущим.
6. Необходимые ресурсы создаются, изменяются или удаляются.
7. Результат можно проверить через мониторинг и другие средства контроля.

Например, в конфигурации указано, что приложению нужны три виртуальные машины. Если сейчас существует только две, инструмент создает третью.

Что можно описывать через IaC

Infrastructure as Code не ограничивается виртуальными машинами. Через IaC можно управлять значительной частью современной инфраструктуры.

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

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

Например, в конфигурации указано, что должно существовать три сервера определенного типа.

Инженеру не нужно писать последовательность команд создать первый сервер, затем второй и затем третий. Он описывает результат, который хочет получить.

Если один сервер уже существует, инструмент учитывает текущее состояние и создает недостающие ресурсы.

Императивный подход

Императивный подход описывает конкретную последовательность действий.

Например, создать виртуальную машину, подключить диск, настроить сеть и затем установить программное обеспечение.

Такой способ предоставляет больше прямого контроля над последовательностью операций, но может быть сложнее при повторном запуске.

Что такое идемпотентность

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

Например, если конфигурация требует один сервер и он уже существует с нужными параметрами, повторный запуск не должен создавать второй сервер без причины.

Это важное свойство Infrastructure as Code, поскольку автоматизация часто запускается многократно.

Infrastructure as Code и Git

Одна из главных особенностей IaC заключается в возможности хранить инфраструктурную конфигурацию в системе контроля версий.

Git позволяет видеть, кто и когда изменил настройки, сравнивать версии и обсуждать изменения через Code Review.

Например, инженер увеличивает размер виртуальной машины. Вместо ручного изменения в панели облака он меняет конфигурационный файл и создает запрос на проверку.

Другой специалист видит изменение и может оценить его влияние до применения.

Зачем нужен Code Review для инфраструктуры

Ошибка в инфраструктурной конфигурации может быть не менее опасна, чем ошибка в программном коде.

Например, неправильное правило доступа может открыть внутреннюю базу данных внешней сети, а случайное удаление ресурса привести к остановке сервиса.

Code Review позволяет проверить изменение вторым специалистом до применения.

В крупных организациях критичные инфраструктурные изменения обычно проходят дополнительные автоматические проверки.

Infrastructure as Code и CI/CD

IaC можно интегрировать с CI/CD.

После изменения конфигурации pipeline запускает проверки синтаксиса, анализирует потенциальные изменения и при выполнении условий применяет их к инфраструктуре.

Например, процесс может выглядеть так: инженер создает ветку, меняет конфигурацию, CI проверяет файл, другой инженер подтверждает изменение, после чего CD применяет его к тестовому или production-окружению.

Так инфраструктурные изменения становятся управляемой частью процесса разработки.

Infrastructure as Code и DevOps

IaC является одной из ключевых практик DevOps. Он помогает уменьшить границу между разработкой и эксплуатацией.

Разработчики получают предсказуемые окружения, а инфраструктурные команды — возможность автоматизировать повторяемые задачи.

Вместо инструкции на десятки страниц компания хранит машиночитаемое описание инфраструктуры, которое можно использовать повторно.

Infrastructure as Code и SRE

SRE стремится сокращать повторяющуюся ручную работу и делать эксплуатацию систем более надежной.

IaC помогает автоматизировать создание и изменение инфраструктуры, уменьшает toil и делает конфигурации воспроизводимыми.

Например, после аварии SRE-команда может развернуть новый экземпляр инфраструктуры из проверенной конфигурации вместо ручного восстановления каждого параметра.

Infrastructure as Code и облака

Облачная инфраструктура особенно хорошо подходит для IaC, поскольку большинство ресурсов управляется через API.

Виртуальные машины, сети, балансировщики и хранилища можно создавать программно.

Это позволяет быстро разворачивать целые окружения: development, test, staging и production.

При ручной настройке четыре окружения постепенно начинают отличаться друг от друга. IaC уменьшает такие расхождения.

Что такое Configuration Drift

Configuration Drift — постепенное расхождение фактической конфигурации с ожидаемой.

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

В результате окружения начинают вести себя по-разному, хотя формально должны быть идентичными.

Infrastructure as Code помогает снижать риск такого расхождения, если изменения выполняются через единый управляемый процесс.

Почему ручные изменения опасны

Если команда использует IaC, но продолжает регулярно изменять ресурсы вручную через панели управления, конфигурация перестает быть источником истины.

В файле указано одно состояние, а в реальной инфраструктуре находится другое.

Следующее автоматическое применение конфигурации может неожиданно вернуть ручные изменения назад или создать конфликт.

Поэтому в зрелом IaC-процессе ручные изменения либо запрещаются, либо обязательно отражаются в коде.

Что такое Source of Truth

Source of Truth — источник, который считается авторитетным описанием состояния системы.

В IaC таким источником обычно является репозиторий с инфраструктурным кодом.

Если возникает вопрос, сколько серверов должно существовать и с какими параметрами, ответ ищут в конфигурации, а не в памяти администратора.

Это особенно важно при смене сотрудников и росте инфраструктуры.

Популярные инструменты Infrastructure as Code

Для IaC используются различные инструменты. Они отличаются моделью управления, поддерживаемыми платформами и назначением.

Infrastructure as Code и Terraform

Terraform является одним из наиболее известных инструментов IaC.

Инженер описывает ресурсы в конфигурации, а Terraform определяет, какие изменения необходимо выполнить для достижения желаемого состояния.

Он может использовать providers для взаимодействия с различными облачными платформами и сервисами.

Например, одной конфигурацией можно создать виртуальную сеть, несколько серверов и балансировщик нагрузки.

Infrastructure as Code и Ansible

Ansible часто применяется для Configuration Management — настройки операционных систем и приложений после создания серверов.

Например, IaC-инструмент создает виртуальную машину, а Ansible устанавливает на нее Nginx, создает пользователей и изменяет конфигурационные файлы.

Граница между Infrastructure as Code и Configuration Management условна, и инструменты могут решать пересекающиеся задачи.

IaC и Configuration Management

На практике эти подходы часто используются совместно.

Infrastructure as Code и Kubernetes

Kubernetes также активно использует декларативный подход. Ресурсы кластера описываются в конфигурациях, после чего система стремится поддерживать заданное состояние.

Например, можно указать требуемое количество экземпляров приложения и параметры сервиса.

При этом сам Kubernetes-кластер также может создаваться через IaC-инструменты.

Таким образом, IaC может применяться как к инфраструктуре под Kubernetes, так и к ресурсам внутри кластера.

Infrastructure as Code и Docker

Docker не является IaC-инструментом в классическом смысле, но использует близкую идею воспроизводимого описания среды.

Dockerfile описывает, как должен быть создан образ приложения, а другие конфигурационные файлы могут описывать набор связанных контейнеров.

IaC располагается уровнем выше и может создавать серверы и сети, на которых эти контейнеры будут работать.

Что такое State

Некоторым IaC-инструментам необходимо хранить информацию о соответствии конфигурации реальным объектам инфраструктуры.

Такое состояние часто называют State.

Оно помогает понять, какой ресурс в конфигурации соответствует конкретной виртуальной машине, сети или другому объекту.

Повреждение или утечка state может создать серьезные проблемы, поэтому его необходимо надежно хранить и ограничивать доступ.

Почему State нужно защищать

State может содержать идентификаторы инфраструктуры, технические параметры и потенциально чувствительную информацию.

Кроме того, одновременное изменение одного состояния несколькими инженерами может привести к конфликтам.

Поэтому в командной работе state обычно хранится централизованно и используются механизмы блокировки.

Что такое Plan

Перед применением инфраструктурного изменения полезно увидеть, что именно собирается сделать инструмент.

План может показать создание нового сервера, изменение параметра сети или удаление ресурса.

Это дает возможность обнаружить неожиданное действие до его выполнения.

Особенно внимательно следует проверять операции удаления и замены критичных ресурсов.

Что такое Apply

Apply — применение запланированных изменений к реальной инфраструктуре.

После проверки плана инструмент вызывает API поставщиков и приводит ресурсы к состоянию, описанному в конфигурации.

В production-среде apply желательно выполнять через контролируемый pipeline или процесс согласования, а не произвольно с локального компьютера.

Модули в Infrastructure as Code

Повторяющиеся части инфраструктуры можно выносить в модули.

Например, компания создает стандартный модуль веб-сервера, который включает виртуальную машину, диск, сетевые правила и мониторинг.

Разные команды используют один модуль вместо копирования десятков строк конфигурации.

Это помогает стандартизировать инфраструктуру и упрощает обновления.

Переиспользование инфраструктурного кода

Одна из важных возможностей IaC — повторное использование проверенных конфигураций.

Например, шаблон для типового приложения можно использовать в нескольких проектах, меняя только параметры размера серверов, региона или окружения.

Это ускоряет запуск новых систем и снижает вероятность различий между проектами.

IaC и тестирование

Инфраструктурный код можно проверять до применения.

На базовом уровне выполняется проверка синтаксиса и структуры конфигурации.

Дополнительно можно автоматически анализировать правила безопасности, запрещенные типы ресурсов, обязательные теги и другие организационные стандарты.

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

Policy as Code

Policy as Code — близкий подход, при котором организационные и защитные правила также описываются программно.

Например, политика может запрещать создание публично доступной базы данных или требовать обязательного шифрования дисков.

Pipeline проверяет инфраструктурную конфигурацию и блокирует изменение, если оно нарушает установленную политику.

Это помогает масштабировать стандарты безопасности на большое количество команд.

Infrastructure as Code и безопасность

IaC позволяет применять одинаковые правила безопасности ко всем окружениям, но ошибки в коде также могут масштабироваться автоматически.

Если неправильная конфигурация сетевого доступа используется в модуле, проблема может появиться сразу в десятках проектов.

Поэтому инфраструктурный код необходимо проверять так же внимательно, как код приложения.

• Code Review;
• автоматические проверки;
• минимальные права для pipeline;
• защита state;
• контроль секретов;
• разделение окружений;
• журналирование инфраструктурных изменений.

Секреты в Infrastructure as Code

Пароли, API-ключи и другие секреты не следует помещать прямо в конфигурационные файлы и сохранять в Git.

Даже если секрет позднее удалить, он может остаться в истории репозитория.

Для чувствительных значений используют специальные системы управления секретами, переменные защищенного CI/CD или другие безопасные механизмы.

Infrastructure as Code описывает инфраструктуру, но не должен превращать Git-репозиторий в хранилище паролей и ключей доступа.

Infrastructure as Code и Disaster Recovery

IaC может значительно упростить восстановление инфраструктуры после крупной аварии.

Если конфигурация серверов и сетей хранится только в документации и памяти администраторов, восстановление может занять много времени.

При IaC проверенное описание позволяет повторно создать многие ресурсы автоматически.

Однако IaC не заменяет резервное копирование данных. Код может создать новый сервер базы данных, но не восстановит бизнес-данные, если их резервной копии нет.

Infrastructure as Code и резервное копирование

IaC и Backup решают разные задачи.

Для полноценного Disaster Recovery обычно нужны оба подхода.

Infrastructure as Code и Immutable Infrastructure

Immutable Infrastructure — подход, при котором уже развернутые серверы стараются не изменять вручную.

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

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

Это уменьшает накопление случайных ручных изменений.

Преимущества Infrastructure as Code

• воспроизводимость инфраструктуры;
• ускорение развертывания;
• меньше ручных ошибок;
• история изменений в Git;
• возможность Code Review;
• стандартизация окружений;
• быстрое масштабирование;
• автоматизированное восстановление;
• интеграция с CI/CD;
• упрощение аудита изменений.

Недостатки и риски IaC

Infrastructure as Code не устраняет сложность инфраструктуры, а переводит ее в управляемый код. Команде необходимо понимать как сами инфраструктурные технологии, так и используемый инструмент автоматизации.

• ошибка может автоматически затронуть множество ресурсов;
• необходимо защищать state и секреты;
• появляется дополнительный код, который нужно сопровождать;
• сложные зависимости затрудняют изменения;
• ручные изменения могут создавать drift;
• нужны процессы проверки и согласования;
• неудачный apply способен привести к простою.

Типичные ошибки при внедрении Infrastructure as Code

1. Хранить пароли и API-ключи в Git.
2. Применять изменения в production без просмотра плана.
3. Не использовать Code Review.
4. Продолжать регулярно изменять инфраструктуру вручную.
5. Создавать огромную монолитную конфигурацию для всех систем.
6. Не разделять production и test.
7. Не защищать state.
8. Не использовать переиспользуемые модули.
9. Считать IaC заменой резервного копирования.
10. Не тестировать процесс восстановления инфраструктуры.

Как внедрить Infrastructure as Code

Шаг 1. Выбрать ограниченный участок

Лучше начать с нового небольшого окружения, а не пытаться сразу перенести всю существующую инфраструктуру.

Шаг 2. Выбрать инструмент

Нужно учитывать облачную платформу, существующие компетенции команды и тип ресурсов.

Шаг 3. Создать репозиторий

Инфраструктурный код следует хранить в системе контроля версий.

Шаг 4. Настроить Review

Изменения критичных ресурсов должны проверяться до применения.

Шаг 5. Добавить CI-проверки

Полезно автоматически проверять синтаксис, формат и политики безопасности.

Шаг 6. Автоматизировать применение

Production-изменения желательно выполнять через контролируемый pipeline.

Шаг 7. Устранить ручные изменения

Команде следует постепенно перейти к правилу, при котором инфраструктура изменяется через код.

Шаг 8. Проверить восстановление

Нужно убедиться, что конфигурация действительно позволяет развернуть окружение заново.

Практический пример

Компания развивает SaaS-сервис. Для каждого нового проекта администратор вручную создавал виртуальные машины, сеть, балансировщик и правила доступа.

На развертывание уходило несколько часов, а тестовое и production-окружения постепенно начинали отличаться.

Команда перенесла описание инфраструктуры в IaC. Для типового приложения создали модуль, который автоматически разворачивает сеть, три сервера и балансировщик.

Теперь инженер меняет только параметры окружения и запускает pipeline. Перед применением команда видит список запланированных изменений.

Через несколько месяцев потребовалось создать аналогичное окружение в другом регионе. Вместо повторной ручной настройки использовали ту же конфигурацию с другими параметрами.

В результате время развертывания сократилось, а инфраструктурные изменения стали отслеживаться через Git.

Infrastructure as Code для бизнеса

Практическая ценность IaC особенно заметна при росте ИТ-инфраструктуры.

Если компания управляет двумя серверами, ручная настройка еще может быть приемлемой. При десятках проектов и сотнях ресурсов она становится источником ошибок и значительных трудозатрат.

IaC помогает уменьшить зависимость от знаний конкретного администратора. Конфигурация хранится в репозитории и доступна команде.

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

Когда нужен Infrastructure as Code

• компания активно использует облачную инфраструктуру;
• есть несколько одинаковых окружений;
• серверы регулярно создаются и удаляются;
• инфраструктура управляется несколькими инженерами;
• нужен аудит изменений;
• развивается DevOps или SRE;
• используется CI/CD;
• важно быстро восстанавливать инфраструктуру;
• нужно стандартизировать настройки между проектами.

Когда IaC может быть избыточным

Для небольшой компании с одним редко изменяемым сервером полноценный IaC-процесс может быть сложнее ручного администрирования.

Однако даже в небольших системах автоматическое описание критичных конфигураций может быть полезным для восстановления и документирования.

Чем чаще инфраструктура изменяется и чем больше специалистов с ней работают, тем выше ценность Infrastructure as Code.

Связанные термины

Краткий итог

Infrastructure as Code — подход к управлению ИТ-инфраструктурой, при котором серверы, сети, хранилища и другие ресурсы описываются в коде или конфигурационных файлах и создаются автоматически.

IaC делает инфраструктуру воспроизводимой, позволяет хранить историю изменений в Git, применять Code Review, интегрировать инфраструктурные изменения с CI/CD и уменьшать количество ручных ошибок.

Подход особенно полезен в облаках, DevOps, SRE и крупных инфраструктурах. При этом IaC требует дисциплины: конфигурацию необходимо защищать, проверять перед применением, не хранить в ней секреты и избегать ручных изменений, которые создают Configuration Drift. IaC также не заменяет резервное копирование данных, но значительно упрощает восстановление самой инфраструктуры.