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

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

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

От железа к облаку

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

С одновременным запуском и повсеместным внедрением AWS EC2 и Ruby on Rails 1.0 в 2006 году многие корпоративные группы столкнулись с проблемами масштабирования, которые ранее возникали только в крупных транснациональных организациях. Облачные вычисления и возможность без усилий запускать новые инстансы виртуальных машин принесли инженерам и предприятиям не только хорошую выгоду, но и дополнительные хлопоты. Теперь им приходилось следить за обслуживаемыми серверами, число которых постоянно росло.

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

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

Infrastructure as Code

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

С момента запуска AWS Cloudformation в 2009 году IaC быстро стал неотъемлемой практикой DevOps, незаменимой в жизненном цикле конкурентоспособной доставки программного обеспечения. Он позволяет командам инженеров быстро создавать и версионировать инфраструктуру тем же способом, что и обычный код, и отслеживать эти версии во избежание несогласованности между средами. Обычно команды осуществляют это следующим образом:

• Разработчики определяют и пишут инфраструктурные спецификации (infrastructure specs) на специфичном для предметной области языке

• Созданные файлы отправляются в API управления, мастер-сервер или репозиторий кода

• Затем инструмент IaC, такой как Pulumi, выполняет все действия, которые нужны для создания и настройки необходимых вычислительных ресурсов

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

Традиционно существует два подхода к IaC, декларативный или императивный, и два возможных метода, push и pull. Декларативный подход описывает конечную цель и определяет требуемое состояние ваших ресурсов. Этот подход отвечает на вопрос о том, что нужно создать, например, «Мне нужны две виртуальные машины». Императивный подход отвечает на вопрос о том, как нужно изменить инфраструктуру для достижения конкретной цели, обычно выдавая последовательность различных команд. Ansible playbooks — отличный пример императивного подхода. Разница между методом push и pull заключается в том, каким образом серверам сообщается информация о конфигурации. В pull режиме каждый сервер будет пулить свою конфигурацию из мастер-сервера, а в push режиме мастер-сервер сам распушивает конфигурацию по целевой системе.

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

• AWS CloudFormation (Feb 2011)

• Ansible (Feb 2012)

• Azure Resource Manager (Apr 2014)

• Terraform (Jun 2014)

• GCP Cloud Deployment Manager (Jul 2015)

• Serverless Framework (Oct 2015)

• AWS Amplify (Nov 2018)

• Pulumi (Sep 2019)

• AWS Copilot (Jul 2020)

 Это чрезвычайно динамичная вертикаль DevOps индустрии, где каждый год появляются новые конкурирующие инструменты, а старички постоянно внедряют инновации; например, CloudFormation в прошлом году получила замечательную новую фичу — Cloudformation modules.

Плюсы и минусы

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

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

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

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

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

Для отдельных сетапов существуют более конкретные преимущества, но в целом мы видим, что IaC оказывает очень большое влияние на рабочие процессы инженерных команд. Внедрение IaC в качестве подхода к управлению вашей инфраструктурой может стать решающим конкурентным преимуществом. Однако при обсуждении IaC многие упускают некоторые важные ограничения, которые все еще есть. Если вы уже внедрили IaC в своей организации или находитесь в процессе внедрения, вы, наверное, понимаете, что не все так гладко. В качестве наглядного (и смешного) примера трудностей с внедрением IaC, например Terraform, я настоятельно рекомендую ознакомиться со статьей Реджис Уилсон (Regis Wilson) The terrors and joys of terraform.

Также следует упомянуть о четырех ключевых ограничениях при внедрении IaC:

• Логика и соглашения: Вашим разработчикам все еще необходимо понимать IaC скрипты независимо от того, написаны ли они на языке конфигурации HashiCorp (HCL) или на обычном Python или Ruby. Суть в том, что они должны не столько разбираться в множестве разных языков, сколько понимать и применять общепринятую логику и соглашения. Если даже относительно небольшая часть вашей команды инженеров не знакома с декларативным подходом (мы часто можем наблюдать это на крупных предприятиях с устаревшими системами, например .NET) или любыми другими основными концепциями IaC, вы, скорее всего, окажетесь в ситуации, когда Ops и те, кто их понимает, становится “узким местом”. Если ваш сетап требует, чтобы каждый понимал эти скрипты для развертывания своего кода, на этапе адаптации и быстрого масштабирования могут возникнуть проблемы.

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

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

• Запаздывание фич: Инструменты IaC, не зависящие от поставщика (например, Terraform), часто запаздывают с фичами в сравнении с продуктами, привязанными к конкретному поставщику. Это связано с тем, что поставщикам инструментов необходимо обновлять провайдеров, чтобы полностью охватить новые облачные фичи, выпускаемые с постоянно растущими темпами. В результате иногда вы не можете использовать новую облачную фичу, если вы: 1) не расширите функциональность самостоятельно, 2) не дождетесь, пока поставщик покроет этот функционал, или 3) введете новые зависимости.

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

Будущее

Как уже упоминалось, рынок IaC постоянно эволюционирует, и уже сейчас проходят эксперименты по решению существующих проблем. Например, в настоящее время агенты открытой политики (OPA) являются хорошим ответом на отсутствие определенной модели RBAC в Terraform и используются по умолчанию Pulumi.

Однако самой большой сложностью остается необходимость для каждого члена инженерной организации понимать IaC (язык, концепции и т. д.) для практической реализации этого подхода. По словам нашего CTO Криса Стивенсона (Chris Stephenson): «Если вы не понимаете, как это работает, IaC — самый большой черный ящик из всех». В основном это разобщает между собой Ops, которые пытаются максимально оптимизировать свои сетапы, и разработчиков, которые часто боятся трогать скрипты IaC из-за страха что-то сломать. Это приводит к разного рода фрустрациям и простоям.

В настоящее время команда инженеров использует два основных пути для устранения этой проблемы:

• Каждый практикует IaC в индивидуальном порядке. Разработчику нужна новая база данных, и он выполняет свои задачи Terraform. Этот подход работает, если все хорошо знакомы с IaC. В противном случае вы делаете что-либо и молитесь, чтобы не случилось ничего плохого. Что иногда работает.

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

Ни один из этих подходов на самом деле не решает проблему разобщенности между Ops и разработчиками. Оба эти подхода по-прежнему неустойчивы или негибки. Забегая вперед, внутренние платформы разработчиков (IDP) могут преодолеть это, обеспечив дополнительный слой между разработчиками и скриптами IaC. Позволяя Ops устанавливать четкие правила и пути для остальной команды инженеров, IDP позволяют разработчикам удобно обслуживать инфраструктуру с помощью пользовательского интерфейса или командной строки, который обеспечивается внутренними скриптами IaC. Разработчикам нужно беспокоиться только о том, какие ресурсы (датабаза, DNS, накопитель) им необходимы для развертывания и запуска своих приложений, в то время как IDP заботится о вызове скриптов IaC через выделенные драйверы, чтобы вернуть инженерам требуемую инфраструктуру.

Мы считаем, что IDP — это следующий логический шаг в эволюции Infrastructure as Code. Humanitec — это платформа для создания собственной внутренней платформы разработчика. Вскоре мы опубликуем библиотеку драйверов с открытым исходным кодом, которую каждая команда может использовать для автоматизации сетапа IaC. Следите за обновлениями, чтобы узнать больше на https://github.com/Humanitec.

Материал подготовлен в рамках курса "Infrastructure as a code"