инфраструктура как код infrastructure as code iac
Что такое «Инфраструктура как код»?
Инфраструктура как код (IaC) — это управление инфраструктурой (сетями, виртуальными машинами, подсистемами балансировки нагрузки и топологией подключения) в описательной модели с использованием той же версии, что и группа DevOps, используемая для исходного кода. Подобно принципу, согласно которому один и тот же исходный код создает один и тот же двоичный файл, модель IaC при каждом применении формирует одну и ту же среду. IaC является ключевым DevOps методикой и используется в сочетании с непрерывной поставкой.
IaC решает реальные проблемы
Инфраструктура по мере развития кода для решения проблемы с отклонением среды в конвейере выпуска. Без IaC команды должны поддерживать настройки отдельных сред развертывания. Со временем каждая среда становится « _снежинка_», то есть уникальной конфигурацией, которая не может быть воспроизведена автоматически. Несогласованность между средами приводит к проблемам во время развертывания. Администрирование и обслуживание инфраструктуры связано с выполняемыми вручную процессами, которые сложно отследить и которые приводят к возникновению ошибок.
Идемпотентность является принципом инфраструктуры в виде кода. Идемпотентность — это свойство, которое команда развертывания всегда задает целевую среду в той же конфигурации независимо от состояния запуска среды. Идемпотентности достигается либо автоматической настройкой существующего целевого объекта, либо путем удаления существующей цели и повторного создания новой среды.
Соответственно, при использовании IaC команда вносит изменения в описание среды и версию модели конфигурации, которая обычно находится в хорошо документированных форматах кода, таких как JSON. Конвейер выпуска выполняет модель для настройки целевых сред. Если группе необходимо внести изменения, они изменяют источник, а не целевой объект.
IaC предоставляет реальные преимущества
Инфраструктура как код позволяет командам DevOps тестировать приложения в рабочих средах на ранних этапах цикла разработки. Эти команды предполагают, что несколько тестовых сред надежно и по требованию. Инфраструктура, представленная в виде кода, также может быть проверена и протестирована для предотвращения распространенных проблем развертывания. В то же время облако динамически подготавливает и слезами среды на основе определений IaC.
Команды, реализующие IaC, могут быстро доставлять стабильные среды и масштабировать их. Команды избегают ручной настройки сред и обеспечивают согласованность, представляя требуемое состояние своих сред с помощью кода. Развертывания инфраструктуры с IaC являются повторяемыми и предотвращают проблемы во время выполнения, вызванные отклонением конфигурации или отсутствием зависимостей. Команды DevOps могут работать вместе с единым набором практических рекомендаций и средств, позволяющих быстро и надежно предоставлять приложения и их поддерживающую инфраструктуру.
Предпочитать декларативные определения
Предпочтительный подход к IaC — использование файлов декларативного определения, где это возможно. В файле определения указывается, что требует Среда, а не обязательно. Иными словами, он может определить конкретную версию и конфигурацию серверного компонента в качестве требования, но не указывает процесс установки и настройки. Эта абстракция обеспечивает большую гибкость в середине, например оптимизированные методы, которые может использовать поставщик инфраструктуры. Кроме того, это позволяет сократить технические обязательства по обслуживанию императивного кода, такого как сценарии развертывания, которые могут начисляться со временем.
Для декларативного IaC не существует единого стандартного синтаксиса. Различные платформы поддерживают разные и зачастую несколько форматов файлов, таких как YAML, JSON и XML. В результате решение о выборе синтаксиса для описания IaC обычно сводится к требованиям целевой платформы.
Использование IaC в Azure
Azure обеспечивает собственную поддержку IaC с помощью Azure Resource Manager. Команды могут определять декларативные шаблоны, указывающие инфраструктуру, необходимую для развертывания своих решений.
Как подход «инфраструктура как код» (IaC-обработка) помогает управлять сложными инфраструктурами
Описание. Подход «инфраструктура как код» (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 применяется автоматическое развертывание инфраструктуры и откат к прошлой версии.
Важность 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-обработки.
Заключение
IaC-обработка — очень эффективная форма управления конфигурацией, направленная на автоматизацию управления облачной ИТ-инфраструктурой. Средства IaC-обработки можно использовать для достижения уровней автоматизации CI/CD, способных менять инфраструктуру проекта. IaC-обработка позволяет получить множество полезных аналитических данных о коммуникативных процессах и обеспечивает прозрачность при изменении инфраструктуры. Для применения этого подхода требуется ряд зависимостей, например платформы хостинга и инструменты автоматизации, которые сегодня часто предоставляются поставщиками хостинга.
Infrastructure as Code: Плюсы, Минусы и Будущее
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 постоянно эволюционировал, и, вероятно, потребовалась бы целая статья, чтобы дать исчерпывающий обзор всех различных вариантов реализации этого подхода в ее конкретной инфраструктуре. Однако мы составили краткую хронологию основных инструментов, перечисленных по дате релиза:
Инфраструктура как код. Введение для начинающих
Согласно отчету «State of DevOps 2019», 80% респондентов сказали, что основное приложение или служба, которую они поддерживали, было размещено на какой-то облачной платформе. 50% респондентов заявили, что их основное приложение размещено в публичном облаке.
Что такое инфраструктура как код?
Идея состоит в том, что вы относитесь к своей инфраструктуре как к программному обеспечению, а затем пишете, тестируете и выполняете код для определения, развертывания, обновления и уничтожения своей инфраструктуры.
Вы пишете код для управления своими серверами, базами данных, сетями, журналами, развертыванием и настройкой приложений. Когда вы хотите внести изменения в свою инфраструктуру, вы вносите изменения в код, тестируете его, а затем применяете его в своих системах.
Льготы
Инфраструктура как код предоставляет значительные преимущества по сравнению с ручной подготовкой:
Самообслуживание
Поскольку инфраструктура определяется как код, весь процесс и развертывание могут быть автоматизированы и могут быть запущены любым пользователем в команде DevOps. Пользователи инфраструктуры получают ресурсы, которые им нужны, когда им это нужно.
Идемпотентность
Идемпотентность означает, что вы определяете желаемое состояние, и независимо от того, сколько раз вы запускаете скрипт, результат будет одинаковым. Он проверяет текущее и желаемое состояние и применяет только те изменения, которые необходимы. Этого может быть чрезвычайно трудно достичь с помощью скриптов bash.
Такие инструменты, как Ansible и Terraform, имеют встроенные функции, которые делают ваш код идемпотентным.
Снижение затрат
Сокращает время и усилия, необходимые для предоставления, намного меньше, чем подготовка вручную.
Более быстрая доставка программного обеспечения
Быстрое предоставление инфраструктуры для разработки, тестирования и производства позволяет значительно быстрее доставлять программное обеспечение. Поскольку процесс развертывания автоматизирован, он также последовательный и повторяемый.
Самодокументирование
Состояние инфраструктуры определяется в коде, который легко читается любым человеком.
Контролируемая версия
Традиционно изменения в производственных системах считаются рискованными. Но тогда изменения неизбежны. Вам может потребоваться добавить новую базу данных при добавлении новой функции. Вам может потребоваться добавить новые серверы или хранилище в кластер. Инфраструктура как код уменьшает усилия и риск внесения изменений в инфраструктуру.
Вы можете проверить свои исходные файлы в системе управления версиями, что означает, что вы можете отслеживать все изменения, внесенные в инфраструктуру, и быстро возвращаться к предыдущей версии, если что-то сломается.
Валидация и тестирование
Инфраструктура как код позволяет постоянно тестировать и применять небольшие изменения. Поскольку все является кодом, вы можете проверять ошибки, используя статический анализ и автоматические тесты.
Улучшенная безопасность
Переход к инфраструктуре в виде кода позволяет встроить систему безопасности с самого начала, а затем вы можете надежно и безопасно применять изменения.
Инфраструктура как инструменты кода
Несмотря на то, что доступно много инструментов, выбрать один из них для работы может быть нелегко. Ниже приведены некоторые соображения, которые могут оказаться полезными:
Управление конфигурацией и инструменты обеспечения
В целом доступные инструменты подпадают под две категории:
Инструменты управления конфигурацией
Вы можете использовать инструменты управления конфигурацией для установки и обновления программного обеспечения на серверах.
Инструменты обеспечения
Terraform, CloudFormatio, OpenStack Heat, с другой стороны, являются инструментами обеспечения, т.е. Используются для создания серверов, серверов баз данных, балансировщиков нагрузки, очередей, подсетей, брандмауэров и всех других компонентов вашей инфраструктуры. Эти инструменты делают API-вызовы к провайдерам для создания необходимой инфраструктуры.
Изменчивая и неизменная инфраструктура
После многих обновлений каждый сервер, вероятно, будет немного отличаться от других, что приведет к смещению конфигурации. Например, некоторые изменения, которые отлично работают на тестовых серверах, могут не работать на производственных серверах.
Такие инструменты, как Terraform и CloudFormation, предназначены для того, чтобы каждый раз создавать новый сервер из образа машины или образа контейнера. Если необходимо обновить серверы, вы замените их новыми серверами.
Когда новые серверы работают, вы можете отключить старые. Каждое развертывание использует неизменяемый образ для создания сервера, что позволяет избежать смещения конфигурации.
Императивные и декларативные инструменты
Обязательные инструменты похожи на скрипты. Вы перечисляете шаги, которые необходимо предпринять для достижения желаемого состояния. Декларативные инструменты позволяют вам указать конечное состояние, и инструмент разрабатывает шаги для достижения этого состояния.
В то время как Chef является в первую очередь императивным инструментом, Ansible использует гибридный подход и поддерживает как императивные, так и декларативные методы.
Terraform, CloudFormation, Puppet, OpenStack Heat и SaltStack принадлежат к категории декларативных инструментов, в которой вы объявляете желаемое конечное состояние.
Использование нескольких инструментов вместе
Хотя каждый из этих инструментов может использоваться самостоятельно, общий подход состоит в том, чтобы использовать их вместе. Например, вы можете использовать Terraform для создания VPC, подсетей, интернет-шлюзов, балансировщиков нагрузки и виртуальных машин, а затем использовать Ansible для настройки и развертывания служб в этих экземплярах.