Close

Инфраструктура как код

Как подход «инфраструктура как код» (IaC-обработка) помогает управлять сложными инфраструктурами

Фотография: Иэн Бьюкэнэн
Иэн Бьюкэнэн

Главный разработчик решений


Подход «инфраструктура как код» (IaC-обработка) — это процесс управления ИТ-инфраструктурой, при котором для управления ресурсами облачной инфраструктуры применяются рекомендации из сферы DevOps-разработки.

Развитие аппаратной виртуализации в середине 2000-х годов создало новые возможности облачного хостинга инфраструктуры. Поставщики облачного хостинга начали предлагать доступ к динамическим платформам облачной инфраструктуры (IaaS). По мере того как эти платформы развивались и предлагали все более сложные ресурсы инфраструктуры, нарастала и сложность традиционной роли системного администратора. Необходимость быстрой настройки сложных облачных инфраструктур и управления ими скоро стала серьезной проблемой.

Идею подхода «инфраструктура как код» (IaC), или моделирования инфраструктуры с помощью кода, повлек за собой успех непрерывной интеграции и непрерывной поставки. Подход DevOps доказал, насколько эффективно можно отправлять код в репозиторий Git, а затем использовать функциональные ветки и рабочие процессы на основе запросов pull. Принцип автоматизации этих рабочих процессов разработки программного обеспечения помог и в вопросе администрирования облачных систем.

Логотип Compass.

Попробуйте Compass бесплатно

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

Что такое инфраструктура как код?


Модель «инфраструктура как код» — это процесс управления ИТ-инфраструктурой, при котором для управления ресурсами облачной инфраструктуры применяются рекомендации из сферы DevOps-разработки. Подход применим к таким ресурсам инфраструктуры, как виртуальные машины, сети, балансировщики нагрузки, базы данных и другие сетевые приложения.

IaC-обработка — это способ управления конфигурацией, при котором инфраструктурные ресурсы организации зашифровываются в текстовых файлах. Затем эти файлы инфраструктуры помещаются в систему контроля версий, например Git. Репозиторий системы контроля версий позволяет использовать рабочие процессы с применением функциональных веток и запросов pull, лежащие в основе CI/CD.

IaC-обработка стала возможной благодаря распространению платформ хостинга облачной инфраструктуры, особенно платформ IaaS-инфраструктуры. IaaS-платформы позволяют выделять и использовать облачные ресурсы по требованию с помощью вызовов удаленных API, которые формируют шаблон свойств, переданных в файлах конфигурации инфраструктуры. Функции автоматизации IaC могут получать файлы конфигурации и исполнять их посредством вызовов удаленных API на IaaS-платформе.

Как только команда поместит конфигурацию инфраструктуры в систему контроля версий, к изменениям инфраструктуры можно будет применить методы CI/CD. Обновлять инфраструктуру можно в рамках рабочего процесса DevOps. Когда участник команды редактирует текстовый файл конфигурации, можно использовать рабочие процессы запроса pull и проверки кода для аудита и утверждения изменений. Кроме того, в системах IaC-обработки на основе DevOps применяется автоматическое развертывание инфраструктуры и откат к прошлой версии.

значок администрирования в облаке
Связанные материалы

Инфраструктура как услуга

Значок: три кольца
СМ. РЕШЕНИЕ

Улучшите процесс разработки с помощью Compass

Важность IaC-обработки


Развитие IaC-обработки помогло решить проблему отклонений среды. В облачных приложениях этапы жизненного цикла релиза обычно протекают в отдельных средах развертывания. Как правило, это среда разработки, раздел проиндексированных файлов и рабочая среда. Эти среды состоят из таких сетевых ресурсов, как серверы приложений, балансировщики нагрузки и базы данных. Отклонения среды возникают, когда синхронизация между инфраструктурами этих различных сред нарушается.

Без IaC-обработки управление инфраструктурой может быть хаотичным и ненадежным процессом. Системные администраторы вручную подключаются к удаленным поставщикам облачных услуг и используют API или сетевые дашбоарды для выделения нового оборудования и ресурсов. Такой ручной процесс не дает целостного представления об инфраструктуре приложений. Администраторы могут вручную внести изменения в одну среду и забыть повторить то же самое в другой. В результате в среде появляются отклонения.

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

Управление инфраструктурой вручную, без IaC-обработки, происходит медленно. Если изменение инфраструктуры потребовалось вследствие отклонений среды, всплеска трафика или других проблем, неизвестно, сколько времени понадобится системному администратору для реагирования и внесения исправлений. Это приводит к сбоям в работе и разочарованию клиентов. За счет IaC-обработки инфраструктура автоматически адаптируется к изменениям конфигурации и реагирует на повышение трафика с помощью автоматического масштабирования.

IaC-обработка обеспечивает больший контроль и прозрачность, чем администрирование систем вручную. Файлы конфигурации инфраструктуры передаются в центральный репозиторий с контролем версий, где любой участник команды может просматривать и редактировать данные инфраструктуры. Это позволяет проводить эффективный аудит. Например, если команда проходит аудит соответствия стандартам безопасности PCI, вам нужно будет знать, используется ли в соответствующей части инфраструктуры шифрование SSL. С помощью IaC-обработки можно быстро увидеть настройки SSL и выполнить код, чтобы убедиться, что действующая инфраструктура соответствует файлам конфигурации, определяющим использование SSL. История коммитов в системе контроля версий также служит журналом со сведениями о времени добавления или удаления настроек.

Принцип IaC-обработки


Изображение инфраструктуры как кода

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

Хостинг с удаленным доступом или платформа облачного хостинга IaaS

Самая первая и главная зависимость — это хостинг с удаленным доступом. Инструмент управления конфигурацией должен подключаться к удаленному узлу и изменять его. Если используется удаленная инфраструктура с самостоятельным управлением, команда должна обеспечить доступ к ней для инструмента управления конфигурацией. На платформах облачного хостинга с поддержкой IaaS-инфраструктуры доступен ряд API, которые позволяют пользователям автоматически создавать, удалять и настраивать инфраструктурные ресурсы по требованию. Эти API также доступны для инструментов управления конфигурацией, что делает возможным дальнейшую автоматизацию таких задач. Примеры популярных платформ IaaS — Digital Ocean, Amazon AWS, Microsoft Azure и другие.

Платформа управления конфигурацией

Следующим условием применения IaC-обработки является набор инструментов, который подключается к API IaaS-инфраструктуры и автоматизирует типовые задачи. Команда может самостоятельно сформировать набор скриптов и инструментов. Однако это требует серьезной работы и подразумевает дальнейшее техническое обслуживание. Скорее всего, такие инвестиции плохо окупятся. Эту проблему решает ряд готовых платформ управления конфигурацией с открытым исходным кодом, например Terraform, Ansible, SaltStack и Chef.

Система контроля версий

Для объявления выполняемых задач и последовательностей платформа управления конфигурацией использует человеко- и машиночитаемые текстовые файлы, написанные на языке разметки, например YAML. Такие текстовые файлы можно рассматривать как файлы кода приложений и хранить в репозитории с контролем версий. Репозиторий выступает в качестве центрального достоверного источника информации, позволяя выполнять запросы pull и проверку кода. Самая популярная система контроля версий — Git.

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

  1. Разработчик редактирует конфигурационный текстовый файл YAML на платформе для управления конфигурацией, например Terraform. Изменения описывают необходимость в новом хостинг-сервере.
  2. Разработчик выполняет коммит изменений в функциональную ветку репозитория Git. Проектный репозиторий Git размещен в Bitbucket, поэтому разработчик создает запрос pull. Другой участник команды просматривает запрос и узнает о новых изменениях в инфраструктуре. Он подтверждает запрос pull, и разработчик выполняет слияние коммита в главную ветку репозитория.
  3. На этом этапе для выполнения обновлений необходима платформа конфигурации. Обновление может запускаться разработчиком вручную. Команда использует Bitbucket, и потому у нее есть возможность автоматизировать эту операцию с помощью конвейера Bitbucket Pipelines.
  4. После выполнения изменения платформа Terraform взаимодействует с IaaS-инфраструктурой команды: отправляет ряд команд в адрес API IaaS-платформы, чтобы привести IaaS-инфраструктуру в соответствие с ожидаемой конфигурацией.

Заключение


IaC-обработка — очень эффективная форма управления конфигурацией, направленная на автоматизацию управления облачной ИТ-инфраструктурой. Средства IaC-обработки можно использовать для достижения уровней автоматизации CI/CD, способных менять инфраструктуру проекта. IaC-обработка позволяет получить множество полезных аналитических данных о коммуникативных процессах и обеспечивает прозрачность при изменении инфраструктуры. Для применения этого подхода требуется ряд зависимостей, например платформы хостинга и инструменты автоматизации, которые сегодня часто предоставляются поставщиками хостинга.

Ian Buchanan
Ian Buchanan

У Иэна большой опыт разработки на Java и .NET. Но гораздо больше он известен как специалист по применению agile-методик в крупных корпорациях. Сейчас он с головой погрузился в развивающуюся культуру DevOps и инструменты, улучшающие процессы непрерывной интеграции, непрерывной поставки и анализа данных. В течение своей карьеры он с успехом управлял корпоративными инструментами разработки ПО на всех этапах ее жизненного цикла. Он руководил на корпоративном уровне модернизацией процессов, которая приводила к улучшению производительности, качества и повышению удовлетворенности потребителей. Он создал международные команды, в которых ценятся саморегуляция и самоорганизация. Когда Иэн не выступает и не пишет код, он использует свои знания для создания парсеров, использования предметно-ориентированных языков и метапрограммирования. Подписывайтесь на Иэна: @devpartisan.


Поделитесь этой статьей

Рекомендуемые статьи

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

Рисунок: DevOps

Сообщество Compass

рисунок: преодоление препятствий

Обучающее руководство: создание компонента

Рисунок: карта

Начните работу с Compass бесплатно

Подпишитесь на информационную рассылку по DevOps

Thank you for signing up