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

Инфраструктура как код, выигрываем на масштабе (Кирилл Ветчинкин, TYME)

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

Инфраструктура как код позволяет управлять виртуальными машинами на программном уровне. Это исключает необходимость ручной настройки и обновлений для отдельных компонентов оборудования. Инфраструктура становится чрезвычайно «эластичной», то есть воспроизводимой и масштабируемой. Одни оператор может выполнять развертывание и управление как одной, так и 1000 машинами, используя один и тот же набор кода. Среди гарантированных преимуществ инфраструктуры как кода — скорость, экономичность и уменьшение риска.

Как раз об этом расшифровка доклада Кирилла Ветчинкина на DevOpsDays Moscow 2018. В докладе: переиспользование модулей Ansible, хранение в Git, ревью, пересборка, финансовые выгоды, горизонтальное масштабирование в 1 клик.

Кому интересно, прошу под кат.

Всем привет. Как уже говорили, я Ветчинкин Кирилл. Я работаю в компании TYME и сегодня мы с вами поговорим про инфраструктуру как код. Также поговорим о том, как мы научились экономить на этой практике, потому что она достаточно дорогая. Писать много кода, для настройки инфраструктуры достаточно затратно.

Вкратце расскажу о компании. Я работаю в компании TYME. У нас произошел ребрендинг. Сейчас мы называемся PaySystem — как видно из названия, мы занимаемся платежными системами. У нас есть как собственные решения — это процессинги, так и заказная разработка. Заказная разработка — это электронные банки, биллинги и тому подобные вещи. И как вы понимаете, если это заказная разработка, то это каждый год большое количество проектов. Проект идет за проектом. Чем больше проектов, тем больше однотипной инфраструктуры приходится поднимать. Поскольку проекты зачастую высоконагруженные, то мы применяем микросервисную архитектуру. Поэтому в одном проекте содержится еще много-много маленьких подпроектов.

Соответственно, всем этим зоопарком управлять без полноценного DevOps весьма сложно. Поэтому в нашей компании внедрили различные практики DevOps. Естественно, мы работаем по kanban, по SCRUM, все храним в git. После того, как закоммитили, идет непрерывная интеграция, прогоняются тесты. Тестировщики пишут на PyTest end-to-end тесты, которые каждую ночь стартуют. Unit-test стартуют после каждого коммита. Мы используем раздельный процесс сборки и деплоя: собрали, потом много раз деплоим на различные среды. Мы были на windows. На windows мы деплоили с помощью Octopus deploy, В этом году мы разрабатываем на DotNet Core. Поэтому мы имеем возможность теперь запускать ПО на Linux системах. Мы ушли от Octopus и пришли к Ansible. Сегодня мы поговорим об этой части, представляющей из себя новую практику, которую мы развили в этом году, то чего у нас раньше не было. Когда у вас есть тесты, когда вы умеете хорошо собирать приложение, деплоить его куда-то — все прекрасно. Но если у вас две среды настроены по-разному, то вы все равно упадете, причем упадете на production. Поэтому управлять конфигурациями это очень важная практика. Вот о ней мы сегодня будем говорить.

Вкратце расскажу как вообще строится экономика продукта по трудозатратам: 60 процентов у нас тратиться на разработку, аналитика занимает где-то 10 процентов, QA (тестирование) занимает около 20 процентов и все остальное как раз отводится на конфигурирование. Когда системы идут целым потоком, в них многие стороннее ПО, сами операционные системы настраиваются практически одинаково. Мы на это тратим лишнее время, делая по сути одно и тоже. Появилась идея это все автоматизировать и снизить издержки на конфигурирование инфраструктуры. Однотипные задачи автоматизированы, хорошо отлажены и не содержат ручных операций.

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

Два подхода как вы можете конфигурировать сервера: руками — если вы конфигурируете их руками, у вас соответственно может получиться такая ситуация, что у вас production настроен одним образом, тест другим, на тесте все зеленое, тесты зеленые. Вы деплоите на production, а там не стоит какой-то фреймворк — у вас ничего не работает. Другой пример: три Application сервера настроены руками. Один Application сервер настроили одним образом, другой Application сервер другим образом. Сервера могут работать по-разному. Еще пример: была ситуация, когда у нас один Stage сервер полностью перестал работать. Запустили создание нового сервера используя и через 30 сервер был готов. Еще пример: сервер просто перестал работать. Если настраивали руками, то нужно искать человека, который знает как его настраивать, нужно поднимать документацию. Как мы знаем, документация вряд ли бывает актуальной. Это большие проблемы. И, самое главное, — это аудит, то есть грубо говоря, у вас есть десять администраторов, каждый из них что-то руками настраивает, то не особо понятно корректно они это настроили или некорректно, и как вообще понять, нужно ли делать какие-то настройки, могли что-то лишнее поставить, открыть какие-то ненужные порты.

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

В качестве системы, которая вносит изменения, мы используем Ansible. Поскольку у нас нет огромного количества серверов, он нам вполне подходит. Если у вас там 100-200 серверов, то у вас будут небольшие проблемы, потому что он (т.е. Ansible) все-таки соединяется с каждым и по очереди их настраивает — это проблема. Лучше другие средства использовать, которые не пушат (push), а пулят (pull). Но для нашей истории, когда у нас много проектов, но серверов не больше 20 — нам это вполне подходит. У Ansible большой плюс — это низкий порог вхождения. То есть буквально любой ИТ-специалист за три недели может его полностью освоить. У него много модулей. То есть вы можете управлять облаками, сетями, файлами, установкой программ, деплоем — абсолютно всем. Если нет модулей, вы можете написать свой собственный, вы можете в конце концов написать что-то используя модуль Ansible shell или command.

В общем, вкратце рассмотрим как он вообще выглядит, этот инструмент. У Ansible есть модули, про которые я уже говорил. То есть их можно доставлять, самим писать, которые что-то делают. Есть inventories — это куда мы будем накатывать наши изменения, то есть это хосты, их IP адреса, переменные, специфичные для этих хостов. И, соответственно, роли. Роли — это что мы будем накатывать на эти сервера. И также у нас хосты группируются по группам, то есть в данном случае мы видим, что у нас есть две группы: сервера баз данных и сервера приложений. В каждой группе у нас по три машины. Они по ssh соединяются. Таким образом, мы решаем те проблемы, про которые мы говорили раньше, что у нас во первых сервера настроены идентично, поскольку одна и та же роль накатывается на сервера. И точно так же, если эту роль запустим на нескольких машинах, то на каждый тоже она отработает аналогично.

Если мы более глубоко посмотрим на то, как устроен проект Ansible, то здесь мы видим, что вот inventories хосты допустим для production. Вот эта группа указана и в ней два сервера. Если мы зайдем в конкретный сервер, то видим что здесь указан IP адрес этой машины. Также там могут быть указаны другие параметры — переменные, специфичные для этой среды. Если мы посмотрим на роли. То роль содержит несколько задач (task), которые будут выполняться. В данном случае это роль для установки PostgreSQL. То есть мы устанавливаем необходимое приложение, создаем базы данных. Здесь мы используем цикл. Их (базы данных) несколько создастся. Затем мы устанавливаем необходимое соединение — IP адреса, которые могут в этой базе авторизоваться. И, соответственно, настраиваем в самом конце firewall. Настройки будут применены ко всем серверам в группе.

Как раз подходим к самой проблеме: мы отлично научились конфигурировать сервера с помощью Ansible и было все прекрасно. Но, как я уже говорил, у нас множество проектов. Они почти все одинаковы. В каждом проекте участвуют примерно вот такие системы (k8s, RabbitMQ, Vault, ELK, PostgreSQL, HAProxy). Для каждой мы написали свою роль. Мы ее можем накатывать с кнопки.

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

У нас есть репозиторий с приложением, есть репозиторий с инфраструктурой для проекта. У второго проекта точно также. Продолжение инфраструктуры. И у третьего. Если мы будем одно и то же реализовывать, то по сути получится copy-paste. На одну и ту же роль в 10 местах сделаем. Потом, если будет какая-то ошибка, мы будем в 10 местах править.

Что мы сделали: мы каждую роль, которая общая для всех проектов и все ее конфигурации, которые приходят извне, вынесли в отдельный репозиторий и положили их в гит в отдельную папочку — назвали TYME Infrastructure. Там у нас лежит роль для PostgreSQL, для ELK, для развертывания кластеров Kubernetes. Если нам в какой-то проект понадобится поставить допустим тот же PostgreSQL, то просто включаем его как submodule, переписываем inventories, то есть, грубо говоря, конфигурацию куда эту роль накатывать. Саму роль мы не переписываем: она уже есть. И у нас по клику кнопки во всех новых проектах появляется PostgreSQL. Если нужно поднять кластер Kubernetes — то же самое.

Таким образом, получилось снизить издержки на написание ролей. То есть один раз написали — 10 раз использовали. Когда проект идет за проектом — это очень удобно. Но поскольку мы теперь работаем с инфраструктурой как с кодом, нам, естественно, нужны конвейеры, про которые мы говорили. Люди коммитят в git, могут закоммитить какую-то некорректность — нам нужно это все отслеживать. Поэтому у нас построен вот такой pipeline. То есть разработчик коммитит в git скрипты Ansible. TeamСity их трекает и передает в Ansible. Teamcity здесь нужен только по одной причине: во первых, у него визуальный интерфейс (есть бесплатная версия Ansible Tower — AWX, которая решает эту же задачу — прим. ред.) в отличие от Ansible бесплатного и, в принципе, у нас Teamcity как единый CI. Так-то в принципе Ansible имеет модуль, который сам может git трекать. Но в данном случае сделали просто по образу и подобию. И как только он его трэкнул, он передает весь код в Ansible и Ansible соответственно запускает их на integration сервере и меняет конфигурацию. Если этот процесс нарушился, значит мы разбираем что не так, почему плохо написали скрипты.

Второй момент, что есть специфичная инфраструктура, то здесь у нас инфраструктура деплоится отдельно, приложение деплоится отдельно. Но есть специфичную инфраструктура для каждого приложения, то есть которую нужно деплоить перед тем, как мы будем его запускать. Здесь, соответственно, нельзя выносить это в разный pipeline. У вас должно это развертываться в том же контейнере, что и само приложение. То есть, допустим, фреймворки — популярная вещь, когда вам нужно для нового приложения один фреймворк поставить, для другого другой фреймворк поставить. Вот как с данной ситуацией. Либо кэши надо почистить. К примеру, Ansible может также залезть, кэш почистить.

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

Очень важный момент — если вы катите инфраструктуру через какие-то скрипты, через код, то если у вас все же остаются ручные манипуляции серверами, то это потенциальная уязвимость. Потому что допустим, вы на тестовый сервер поставили java, написали роль ELK, накатили ее. Деплой в тест прошел успешно. Деплоите в production, а там java нет. А java в скрипте вы не указали — деплой в production упал. Поэтому нужно забрать права со всех серверов у администраторов, чтобы они руками туда не залезали и все изменения вносили через git. Весь этот конвейер мы сами проходили. Здесь есть одно но — не надо сильно закручивать гайки. То есть нужно внедрять такой процесс постепенно. Потому что он все еще необкатанный. В нашем случае мы оставили доступ до всех систем у самого главного руководителя администраторов на случай непредвиденных инцидентов. Доступ выдан с условием, что он не будет ничего руками настраивать.

Как происходит разработка? Выкатка в staging, production должна быть без ошибок. У нас что-то может сломаться. Если выкатка в integration окружение будет постоянно падать на ошибках — это будет плохо. Это похоже на отлаживать приложения на удаленной машине. Когда разработчик разрабатывает сначала все на машине, компилирует. Если все компилируется, потом отправляет в репозиторий. Здесь используется такой же подход. Разработчики используют Visual Studio Code с плагинами Ansible, Vagrant, Docker и т.д. Разработчики тестируют свой инфраструктурный код на локальном vagrant. Там поднимается чистая операционная система. Сами скрипты для поднятия этой машины тоже находятся в этом репозитории с инфраструктурой, про которую мы говорили. Разработчик начинает на ней устанавливать FTP-сервер. Если что-то пошло не так, он ее просто удаляет, заново загружает, и заново пытается на нее установить нужное ПО, используя скрипты развертывания. После отладки скриптов развертывания он делает Merge Request в основную ветку. После слияния Merge Request CI раскатывает эти изменения integration сервер.

Поскольку все скрипты это код, то можем писать тесты. Допустим, мы установили PostgreSQL. Хотим проверить работает он или нет. Для этого используем модуль Ansible assert. Сравниваем установленную версию PostgreSQL с версией в скриптах. Таким образом мы понимаем, что установлен, он вообще запущен, он той самой версии, которой мы ожидали.

Мы видим, что тест прошел. Значит наш playbook отработал корректно. Таких тестов можно писать сколько угодно. Они идемпотентные. Идемпотентность (операция, которая если применяется к любому значению несколько раз — всегда получается то же значение, как и при однократном применении). Если вы пишите свобственные скрипт по установке, настройке, то убедитесь что ваши скрипты всегда получает то же значение, если запускать их несколько раз.

Есть еще другой тип тестов, которые к тестированию инфраструктуры напрямую не относятся. Но они как бы косвенно затрагивают его. Это end-to-end тесты. У нас инфраструктура и сами приложения устанавливаются на один и тот же сервер, который тестировщики тестируют. Если мы накатили какую-то некорректную инфраструктуру, то у нас просто комплексные тесты не пройдут. То есть наше приложение будет работать как-то неправильно. В данном примере мы на production установили новую версию — приложение работает. Затем был сделан commit в git и end-to-end тесты, которые проходит по ночам, отследили, что вот здесь у нас отсутствует файл на ftp. Разбираем этот кейс и видим, что проблема именно в настройках ftp. Мы исправляем скрипты в коде, снова деплоим и все становится зеленым. Такая же история с кодом. Код инфраструктуры и инфраструктура так или иначе косвенно тестируется. Мы ее можем потом деплоить на production.

Когда мы этот подход внедрили, CI (Teamcity), который выкатывал изменения на integration сервер падал 8 раз из 10. Никто не обращал на это внимания, потому что не было обратной связи. У разработчиков эти процессы достаточно давно были внедрены, а до OPS (системных администраторов) сообщения не доходили. Поэтому мы добавили Dashboard со сборками данного проекта на большой монитор в самом видном месте в офисе. На нем различные проекты выделены зеленым — это значит, что с ним все в порядке. Если выделены красным значит, что с ним все плохо. Мы видим, что некоторые тесты не прошли. На презентации в левой стороне второй сверху видим результат инфраструктурых деплойных тасок. Инфраструктурные деплойные таски зеленые. Это значит, что все тесты пройдены, никаких дефектов не было, они успешно собрались. Оповещение: Допустим ИТ-специалист запустил скрипт и отошел. Если коммит все сломал. Ему в канал Slack приходит оповещение о том, что вот такой-то ИТ-специалист таким-то коммитом сломал наш проект.

Ok, мы сейчас говорили про то, как мы разрабатываем, как мы коммитим какие-то тестовые среды, как мы вообще выкатывает это дальше на другие среды. Мы используем trunk based подход. Поэтому здесь Master ветка — это основная ветка разработки. При коммите в Master ветку CI сервер (Teamcity) выкатывает изменения на integration сервер. Если таска в CI сервере зеленая, то тогда мы пишем тестировщикам что можно тестировать продукт на integration сервере. Формируем release candidate. На тестовом сервере эта конфигурация появляется. Ее тестировщики могут тестировать вместе с самими приложениями. Если все ок, если end-to-end тесты пройдены, мы уже можем саму конфигурацию и приложение выкатывать на staging окружение. Затем можем выкатывать на production. За счет таких вот разноуровневых барьеров мы достигаем того, что staging окружение у нас всегда зеленое.

Сравним управление инфраструктурой из кода и настройка инфраструктуры руками. Какая экономика? Данный график показывает, как мы устанавливали PostgreSQL. Управление инфраструктурой из кода получилось 5 раз дороже на раннем этапе. Все скрипты необходимо написать, оталадить руками. Этой займет 1-2 часа. Со временем появляется опыт написания этих скриптов. Сравним установку, настройку PostgreSQL час руками и используя скрипт развертывания. Поскольку скрипты разверывания и настройки PostgreSQL уже написаны, то деплоится на staging, production 4 минуты. Чем больше сред, чем больше машин, то вы начинаете выигрывать по трудозатратам в настройке инфраструктуре. И если у вас один проект и одна база данных, то вам дешевле это делать руками. То есть это интересно только когда у вас масштабные какие-то проекты.

Мы внедрили git submodule позволяем несколько раз использовать Ansible роль. Нам второй раз не писать не нужно, она уже есть. Добавляем git submodule с Ansible ролью добавляем в проект. Пишем в inventories сервера, куда эту роль деплоить. Это занимает 30 минут. В случае использования git submodule трудозатраты на написание скриптов развертывания сильно обогнал ручные операции.

Про идентичность сред: здесь я не готов сказать, сколько у нас было ошибок до этого и сколько стало потом. Но хочу сказать, что при соблюдении всех правил, про которые мы сегодня говорили, у нас staging настроен точно так же, как и тест. Поскольку, если тест разваливается, мы уничтожаем машину, заново пытаемся настроить, и только тогда, когда она становится зеленая, накатывается все дело на staging. Сколько руками ошибок делает ваша команда — вы можете сами подумать, посчитать, у каждого наверняка какой-то свой порог.

На графике видны итоги за 6 месяцев. Трудозатраты — сложность по 10 бальной шкале. Первые два месяца мы просто писали эти роли очень больно и долго. Потому что это была новая система. Когда мы их написали, график пошел вниз. Где-то в середине внедрили git submodule, когда мы уже написанные роли стали переиспользовать разных проектов. Это привело к резкому спаду трудозатрат. Если сравнивать с ручной настройкой проекта, по которому данная оценка делалась, то руками мы настраивали три дня, с помощью подхода инфраструктуры как код настраивал около месяца. В перспективе, использование подхода инфраструктура как код более эффективен, чем настройка серверов руками.

Выводы.

Во-первых, мы получили документацию, то есть когда приходит менеджер и меня спрашивает: на каком порту у нас слушает база данных, я открываю Ansible скрипт в git репозитории, говорю: “Вот смотри, вот на таком-то порту”. Какие у нас здесь настройки? Все это видно в git репозитории. Это можно аудировать, показывать менеджерам и так далее. Это 100% достоверная информация. Документация устаревает. А в данном случае ничего не устаревает.

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

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

Быстрое восстановление после аварии. Если вы упали, вам нужно искать человека, который может эту машину настроить, который знает, как ее настроить, который помнит, как ее настроить. В данном случае все настройки и скрипты развертывания находятся в git. Даже если человек уволился, перешел в другой проект — все находится в git, все в комментариях, все видно: почему он открывал такой порт, почему ставил такие-то настройки и так далее. Вы все можете легко восстановить.

Количество ошибок снизилось, потому что у нас появились разные барьеры, локальные среды для отслеживания, для разработки и плюс code review. Это тоже немаловажно, потому что разработчики просматривают то, что они делают. Таким образом, они еще продолжают обучаться. Возросла сложность, потому что это, соответственно, новая система, это конвейеры, людям нужно обучаться. Это не то, что как обычно привыкли: прочитали статью и по статье сделали. Здесь немножко другое. Но тем не менее со временем это достаточно легко осваивается. Если полностью посмотреть на освоение, то это где-то три-четыре месяца.

Вопрос задается через приложение, но вопрос не слышно.

Ответ: Роли мы используем последнюю версию, то есть роль выделяем в отдельный git submodule, только когда она уникальна для абсолютно всех систем. Если по ней произошли какие-то коммиты, то мы переходим на latest комит. А вся конфигурация приходит из inventories. То есть роль — это просто то, что будет выполняться. Название базы данных, логин, пароль и т.д. приходит снаружи. Роль — это просто исполняемый алгоритм. Вся конфигурация приходит из самого проекта.

Вопрос: Если у вас какие-нибудь между ролями Ansible транзитивные зависимости и как вы вытягиваете при деплое приложения (роль A зависит от B, B от C и вы когда выкатываете роль A, чтобы она зависимость все сама тянула)? Посредством каких инструментов, если у вас такой есть?

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

P.S. Предлагаю всем заинтересованным совместно на github переводить в текст интересные доклады с конференций. Можно сделать группу в github для перевода. Пока что я перевожу в текст у себя в github аккаунте — туда же можно отправлять Pull request на исправление статьи.

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

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

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

Каковы преимущества инфраструктуры как кода?

Автоматизация – ключевая цель каждой вычислительной среды. Инфраструктура как код (IaC) используется для автоматизации инфраструктуры для создания сред. Чаще всего IaC используется при разработке программного обеспечения для разработки, тестирования и развертывания приложений.

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

Простое создание дубликатов среды

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

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

Минимизация ошибок конфигурации

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

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

Итерация в передовых средах

Управление исходным кодом позволяет разработчикам программного обеспечения легко разрабатывать среды и расширять их. Представим, что приложение стало включать дополнительный модуль машинного обучения. Разработчик может разветвить IaC приложения, чтобы запустить, использовать и остановить высокопроизводительный инстанс эластичного вычислительного облака Cloud (Amazon EC2) Trn1. Кроме того, разработчик может определить регион развертывания как зависимый от региона развертывания приложения.

Каков принцип работы инфраструктуры как кода?

Подобно тому, как программный код описывает приложение и принципы его работы, инфраструктура как код (IaC) описывает архитектуру системы и принципы ее работы. Архитектура инфраструктуры содержит такие ресурсы, как серверы, сети, операционные системы и хранилища. IaC управляет виртуализированными ресурсами, обрабатывая файлы конфигурации как файлы исходного кода. Решение можно использовать для кодифицированного и повторяемого управления инфраструктурой.

Инструменты управления конфигурацией IaC задействуют разные языковые спецификации. Можно разработать инфраструктуру IaC, аналогичную коду приложения на Python или Java. Кроме того, разработчики пишут IaC в интегрированной среде разработки (IDE) со встроенной проверкой ошибок. Также стоит отметить возможность сохранить IaC под управлением исходного кода с коммитами при каждом изменении кода. Файлы IaC включены как часть более широкой кодовой базы.

Подходы к IaC

Существует два разных подхода к инфраструктуре как коду.

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

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

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

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

Какова роль IaC в DevOps?

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

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

Команды DevOps используют инфраструктуру как код для многих целей:

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

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

Как AWS обеспечивает соответствие требованиям к IaC?

Поскольку предложения Amazon Web Services (AWS) разработаны с учетом модели типа инфраструктура как код (IaC), можно безопасно управлять сложными облачными архитектурами, определяя и запуская их в коде.

Ниже описаны сервисы AWS, которые удовлетворят требованиям к IaC.

• С помощью комплекта для облачной разработки AWS (AWS CDK) разработчики могут определять ресурсы облачных приложений с помощью знакомых языков программирования и интерактивных инструментов настройки в IDE. Это позволяет обойтись без изучения новых языков и инструментов для управления облачными ресурсами.
• С помощью AWS CloudFormation разработчики могут создавать и масштабировать инфраструктуру за пределами AWS. Разработчики могут использовать IaC для определения облачных ресурсов, опубликованных в реестре CloudFormation, сообществе разработчиков и внутренних библиотеках, и управления ими.
• AWS CodeCommit – это безопасный масштабируемый сервис для хостинга частных репозиториев Git. Сервис предназначен для полностью управляемого контроля исходного кода IaC и всего кода приложения.

Создайте аккаунт и начните использовать инфраструктуру как код на AWS уже сегодня.

Инфраструктура как код: обзор и применение

Инфраструктура как код (Infrastructure as Code, IaC) – это методология управления и описания IT-инфраструктуры, основанная на принципах программирования и автоматизации. В данной статье мы рассмотрим концепцию инфраструктуры как кода, а также её применение и преимущества. Мы также рассмотрим различные инструменты и практики, которые помогают реализовать инфраструктуру как код в современных проектах.

Аннотация статьи
IT инфраструктура
инфраструктура как код
методология
Ключевые слова
Михельсон Олег Юрьевич
Дата публикации
17 мая 2023
Информационные технологии
«Актуальные исследования» #20 (150), май ’23
Поделиться
Цитировать
Актуальные исследования
# 20 ( 150 ), май ‘ 23

Введение

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

Определение и принципы Инфраструктуры как кода

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

Принципы Инфраструктуры как кода включают:

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

Преимущества Инфраструктуры как кода

Применение методологии инфраструктуры как кода предоставляет ряд преимуществ, включая:

• Повторяемость и надежность: Использование кода для управления инфраструктурой обеспечивает повторяемость операций. Конфигурация инфраструктуры может быть воспроизведена с высокой степенью точности, что уменьшает возможность ошибок, связанных с ручной настройкой [1].
• Масштабируемость и гибкость: Инфраструктура как код позволяет масштабировать инфраструктурные ресурсы с помощью автоматизированного управления. При необходимости можно легко добавлять или удалять компоненты инфраструктуры, а также изменять их конфигурацию.
• Контроль версий и управление изменениями: Использование системы контроля версий для кода инфраструктуры позволяет отслеживать изменения и вносить правки в инфраструктуру с учетом истории изменений. Это обеспечивает прозрачность и контроль над инфраструктурными изменениями.
• Быстрое развертывание и восстановление: Автоматизированное развертывание и восстановление инфраструктуры позволяют быстро создавать новые среды, восстанавливать предыдущие состояния и обеспечивать непрерывность бизнес-процессов в случае сбоев [1].
• Коллаборация и командная работа: Инфраструктура как код позволяет командам разработчиков и операционных специалистов, таких как системные и сетевые администраторы, администраторы баз данных, эффективно сотрудничать и делиться кодом, упрощая совместную работу и снижая риск ошибок.

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

Инструменты и практики Инфраструктуры как кода

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

• Конфигурационные системы: Например, Ansible [5], Spot [6], Pulumi, Chef и Terraform [7], позволяют описывать и развертывать инфраструктуру через код, обеспечивая автоматизацию конфигурации серверов, сетей и других инфраструктурных ресурсов.
• Системы управления контейнерами: Контейнерные платформы, такие как Docker и Kubernetes [8], позволяют описывать инфраструктуру в виде контейнеризованных приложений, упрощая развертывание и управление масштабируемыми и переносимыми средами.
• Интеграция с CI/CD: Инфраструктура как код интегрируется с процессами непрерывной интеграции и развертывания (CI/CD). Это позволяет автоматически развертывать инфраструктуру при изменениях кода, обеспечивая непрерывную доставку и развертывание приложений.
• Тестирование инфраструктуры: Как и в случае с программным кодом, инфраструктуру как код можно и нужно тестировать. Это позволяет обнаруживать ошибки и проблемы до развертывания инфраструктуры в боевой среде, повышая стабильность и надежность системы.
• Переиспользование компонент: Использование шаблонов и модулей позволяет создавать параметризованные и переиспользуемые компоненты инфраструктуры. Это способствует стандартизации, упрощает масштабирование и облегчает поддержку.

Будущее Инфраструктуры как кода

Концепция инфраструктуры как кода продолжает развиваться и привлекать все большее внимание к себе как в IT-сообществе так и за его пределами. Будущее Инфраструктуры как кода обещает более интегрированные и автоматизированные решения для управления инфраструктурой.

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

Кроме того, важным направлением развития является расширение поддержки различных облачных платформ и сервисов. Инфраструктура как код должна оставаться достаточно гибкой и универсальной для работы с различными облачными провайдерами, такими как Amazon Web Services (AWS), Microsoft Azure, Google Cloud и другими.

Инфраструктура как код становится неотъемлемой частью современной разработки и эксплуатации в сфере IT. Она позволяет компаниям более эффективно управлять и масштабировать свою инфраструктуру, сокращая затраты и снижая риски. Все больше организаций осознают преимущества и ценность применения этой методологии в своих проектах. По мнению исследователей Инфраструктура как код – неизбежно вызовет еще больший интерес в ближайшем и не очень ближайшем будущем, учитывая ее многочисленные разветвления [9].

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

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

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

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

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

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

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

Модель «инфраструктура как код» — это процесс управления ИТ-инфраструктурой, при котором для управления ресурсами облачной инфраструктуры применяются рекомендации из сферы 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

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