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

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

Сложность современной ИТ инфраструктуры уже не позволяет инженерам DevOps выполнять все настройки вручную. Если в прежние времена многие задачи по развертыванию и обслуживанию проще и быстрее было выполнить самому, то сейчас средства автоматизации позволяют существенно сэкономить время при работе с большим количеством элементов инфраструктуры.

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

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

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

Понятие Инфраструктура как код (англ. Infrastructure-as-Code; Iac) появилось уже довольно давно. В 2006 году был запущен сервис AWS Elastic Compute Cloud и появился фреймворк Ruby on Rails версии 1.0, которые позволили поднять вопрос масштабирования, с которой ранее сталкивались только огромные компании. С новыми инструментами для решения этой проблемы и появился подход Инфраструктуры как кода.

 IaC — это подход к управлению и описанию инфраструктуры ЦОД через конфигурационные файлы, а не через ручное редактирование конфигураций на серверах или интерактивное взаимодействие.

Чем так полезен подход IaC? У инфраструктуры как сервиса есть три основных преимущества. Это цена, скорость и уменьшение рисков. Понятие цены здесь рассматривается сразу в двух плоскостях CAPEX (капитальные затраты) и OPEX (операционные затраты). Если капитальные затраты предполагают закупку дополнительного оборудования и ПО, то операционные затраты это не только стоимость сопровождения системы, но и затрачиваемое время на рутинные операции. Принципы IaC позволяют не фокусироваться на рутине, а заниматься более важными задачами. Автоматизация инфраструктуры позволяет эффективнее использовать существующие ресурсы. Кроме того, правильно настроенная и качественно протестированная автоматизация позволяет минимизировать риск возникновения человеческой ошибки.

Такой подход пришел в DevOps как раз из практики разработки и стал наиболее популярен в направлении инфраструктура как сервис (IaaS). При этом, код для управления инфраструктурой может быть написан как в декларативном стиле (встречается чаще), так и императивном или интеллектуальных стилях.

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

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

Для применения готовых конфигураций IaC предполагает два метода применения: push и pull. Основная разница в том, кто инициирует изменение в конфигурации целевого хоста. В pull режиме целевой хост сам инициирует получение своей конфигурации. В push режиме конфигурацию ему присылает управляющий сервер.

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

Terraform

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

Terraform — это Open source решение для управления IaC от компании Hashicorp, разработанное в 2014 году. Решение придерживается декларативного стиля управления инфраструктурой, то есть, вы описываете в конфигурационном файле  финальное состояние инфраструктуры, а Terraform приводит её к этому состоянию. В качестве метода применения конфигурации используется PUSH. Решение написано на языке Go. При этом, для автоматизации работы с инфраструктурой Terraform использует собственный язык написания конфигурационных файлов Hashicorp Configuration Language (HCL).

Загрузить ПО terraform можно из репозитория https://github.com/hashicorp/terraform. Подробнее об этом решении мы будем говорить в следующей статье.

Ansible

Наверное, Ansible это наиболее известная система управления конфигурациями, применяемая инженерами DevOps. Данная система написана на языке программирования Python, с использованием декларативного языка разметки для описания конфигураций. Использует метод PUSH для автоматизации настройки и развертывания программного обеспечения. Проект поддерживается Red Hat, сайт https://www.ansible.com/.

В чем основные отличия Ansible от Terraform? Ansible - это многоцелевой инструмент автоматизации, с его помощью можно решать различные задачи, в то время как Terraform - это инструмент для выполнения задач "инфраструктура как код", то есть инструмент превращения конфигурационных файлов в действующую инфраструктуру. 

Соленый стек

Решение SaltStack несколько выделяется по сравнению с другими, представленными в этой статье. При создании SaltStack изначальной целью была высокая скорость работы. Для обеспечения высокой производительности архитектура решения построена на взаимодействии серверных компонентов Salt-master и клиентов Salt-minion, работающих в push-режиме при помощи Salt-SSH.  Проект разработан на Python и размещается в репозитории https://github.com/saltstack/salt\

Высокая скорость работы обеспечивается за счет асинхронного выполнения задач. Идея заключается в том, что Salt Master общается с Salt Minions через publish/subscribe модель, где мастер публикует задачу, а minion принимают ее и асинхронно выполняют. Для взаимодействия используется общая шина, в которую мастер отправляет одно сообщение с указанием критериев, которым должны соответствовать minion, и они начинают выполнение этой задачи. А мастер, зная от скольких minion ждать ответа просто ожидает получения информации от всех источников. В определенной степени это работа по принципу “отправил и забыл”.

При этом, в случае выхода из строя мастера работа на minion все равно будет выполнена и после возвращения мастер получит результаты.

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

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

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

Заключение

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

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

• Зарегистрироваться на бесплатный урок