Server Room by OliverWeiss97

Здравствуй, Хабр! Меня зовут Алексей Волков, я продуктовый менеджер Kubernetes как сервис в VK Cloud Solutions. Исторически сложилось так, что настройка серверов — это ручной труд. Однако по мере роста и усложнения инфраструктуры управлять ею все сложнее. 

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

Что такое Infrastructure-as-Code

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

Представьте два прокси-сервера Nginx, через которые постоянно проходят запросы клиентов. Администратор вручную меняет настройки на одном сервере, затем на другом. Уходит на перерыв, а по возвращении забывает о первом и перезагружает только второй сервер. В итоге половина клиентов видит одну информацию, а половина — другую. 

Это сравнительно безобидный пример. Иногда расхождения в настройках машин вызывают баги, которые отлавливают месяцами. Однако еще с 2009 года существует альтернативный подход: AWS Cloudformation предложила автоматизировать управление инфраструктурой при помощи Infrastructure as Code (IaC). Это описание конфигурации инфраструктуры в виде программного кода. Он обрабатывается специализированными инструментами, которые самостоятельно приводят инфраструктуру в нужное состояние.

Альтернативный IaC-подход имеет целый ряд преимуществ:

• Полная воспроизводимость. Описанная с помощью кода инфраструктура разворачивается, дублируется и переносится сколько угодно раз целиком. Для этого достаточно взять конфигурационный файл, отвечающий за параметры нужных машин, и просто запустить его.
  
• Удобное масштабирование. Чтобы создать 100 одинаковых серверов, необходимо просто отредактировать конфигурационный файл эталонного сервера: поменять в нем параметр, отвечающий за количество машин, которые нужно поднять.
  
• Простые откаты. С IaC проще возвращаться на предыдущую версию инфраструктуры, особенно если она хранится в какой-либо системе контроля версий. Для этого достаточно отменить последние изменения в конфигурационных файлах. То же касается и бэкапов: конфигурационный файл позволяет оперативно поднять копию утерянной инфраструктуры, и останется только восстановить данные.
  

Подходы к описанию развертывания

Чтобы IaC заработал, необходимо описать будущую инфраструктуру, интерпретировать код и распространить настройки. Это можно делать двумя способами.

• Декларативный подход. При декларативном подходе администратор описывает в виде кода конечное состояние системы. Остальное делает автоматика: интерпретирует конфигурационные файлы, определяет текущее состояние системы, сравнивает его с желаемым и приводит к нему инфраструктуру.
  
• Императивный подход. Императивный подход предполагает написание алгоритма — последовательность конкретных действий по настройке системы. Объем работы больше, но взамен вы получаете максимальный контроль над процессом развертывания.
  

Инструменты для развертывания и управления IаC

За автоматизацию развертывания инфраструктуры в IaC отвечает специализированное инфраструктурное ПО. Есть две наиболее популярные утилиты:

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


Так выглядит работа в Terraform

Ansible. Это, скорее, configuration management system — программа для управления готовой инфраструктурой, установки пакетов и изменения конфигураций. Она использует императивный подход.


Так выглядит работа в Ansible

Для описания конфигурации инфраструктуры используются специальные языки программирования. Ansible, как и многие другие инструменты IaC, использует YAML. Для Terraform HashiCorp разработала собственный язык — HCA. Это не полнофункциональные (полные, по Тьюрингу) языки, а, скорее, узкоспециализированные наборы инструкций, так что они проще в освоении.

Методы распространения изменений по инфраструктуре

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

1. Push-модель. Есть некий центральный сервер, из которого можно запускать применение конфигурации, по очереди обходить объекты инфраструктуры и приводить их в требуемое состояние. Такая модель не требует предварительной настройки инфраструктуры, но изменения распространяются медленнее, так как процесс зависит от одного сервера.
   
2. Pull-модель. На каждом объекте инфраструктуры устанавливается агент, который отслеживает появление новых конфигураций, забирает их с центрального сервера и применяет самостоятельно.
   

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

Terraform работает по Push-модели, Ansible поддерживает обе. Другие инструменты — Puppet, Chef или SaltStack — по большей части используют Pull-модель. Такое разнообразие нужно потому, что нельзя однозначно сказать, какой подход лучше. Выбор зависит от задач, предпочтений и навыков работы с конкретными инструментами.

IaC и VK Cloud Solutions

Облачные провайдеры, как правило, работают с одной или несколькими системами управления конфигурациями. Платформа VK Cloud Solutions построена на OpenStack, так что с нашим облаком можно использовать любой инструмент, который работает с OpenStack API. Однако мы сосредоточились на поддержке Terraform как одного из самых популярных и удобных инструментов. 


Наш Terraform-провайдер в Terraform Registry

У нас есть собственный Terraform-провайдер, предназначенный для работы с нашей PaaS-инфраструктурой, то есть с базами данных и Managed Kubernetes. Написана подробная документация по API.

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

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

Как переехать на IaC

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

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

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

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

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

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

Внедрение Best Practices. В IaC актуальны все те же принципы и Best Practices, что и в разработке ПО. Например, люди, которые пишут на Ansible, часто признаются, что не тестируют свою инфраструктуру. Они говорят, что их задачи невозможно протестировать, но с точки зрения разработки это признак плохого кода.

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

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

Модули (Terraform), таски, плейбуки и роли (Ansible) позволяют переиспользовать готовый проверенный код во многих местах. Это повышает читаемость кода и снижает вероятность ошибки. 

Очень полезен и опыт работы с репозиториями, Git, ветками, Review, пайплайнами, автоматизацией, CI/CD — всем этим можно и нужно пользоваться при написании инфраструктурного кода. В противном случае со временем конфигурационные файлы превращаются в нечитаемое полотно, в которое очень сложно вносить изменения. Так теряется большинство их преимуществ.

Сложности и подводные камни IaC

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

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

1. Специалисты по безопасности думают, что с инфраструктурой все хорошо, ведь ее проверяли год назад. А на деле инфраструктура изменилась примерно 365 раз и даже близко не соответствует их представлениям. 
   
2. Безопасники запрещают изменения без предварительной ручной проверки — принципы Infrastructure-as-Code и вообще принципы DevOps просто аннулируются и больше не работают.
   

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

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

Ошибки встречаются редко и связаны не с Infrastructure-as-Code как с подходом, а с особенностями работы облачной инфраструктуры.

Один из наших клиентов хотел описать конфигурацию в Terraform таким образом, чтобы на мастеры устанавливать инверс-контроллеры. Ему требовалось добавить API-серверы мастеров в наш облачный балансировщик. Тогда обнаружилось, что при конфигурации кластеров Kubernetes наш провайдер неверно отдает список IP-адресов мастер-ноде кластера. Клиент написал в техподдержку, и мы все исправили. Такие баги фиксятся в течение нескольких часов.

Будущее IaC

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

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

Кодовая база IaC постепенно развивается и все больше походит на полноценный язык программирования с многочисленными абстракциями. Инструменты вроде Terraform становятся умнее и удобнее.

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

Что почитать по теме

Если после этой статьи вы захотели попробовать IaC, прежде всего стоит заглянуть на сайт Terraform. Там опубликованы не только техническая документация, но и многочисленные статьи с инструкциями. Еще можно изучить документацию облака, в котором вы будете разворачивать инфраструктуру. Например, такая документация есть у VK Cloud Solutions.

На нашей платформе VK Cloud Solutions можно протестировать Terraform. Для этого при регистрации мы начисляем пользователям 3000 бонусных рублей — приходите, пробуйте и оставляйте обратную связь.