Infrastructure as code

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

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

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

Избегайте настройки вручную, чтобы обеспечить согласованность

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

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

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

Быстро доставить стабильные тестовые среды в большом масштабе

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

Использование декларативных файлов определений

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

Стандартный синтаксис декларативного IaC отсутствует. Синтаксис описания IaC обычно зависит от требований целевой платформы. Различные платформы поддерживают форматы файлов, такие как YAML, JSON и XML.

Развертывание IaC в Azure

Источник

Infrastructure as code: обзор опенсорсных инструментов

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

DevOps может подразумевать несколько разных вещей. DevOps несет культурную трансформацию, которая нацелена то, чтобы каждый инженер чувствовал себя продуктивным и гибким. DevOps также может означать достижение высокой частоты развертываний, при которой сохраняется стабильность. Для обеспечения автоматизации наиболее важной частью DevOps, вероятно, является создание потока ценности (value stream). Чтобы решить эту задачу, многие люди часто рассматривают возможность использования конвейера, такого как Jenkins или GitHub Actions. В то же время в современной экосистеме DevOps наблюдается быстрый рост относительно новой области под названием Infrastructure as Code (инфраструктура как код), так же известной в своей короткой форме — IAC.

IAC, или Infrastructure as Code, представляет собой процесс подготовки (provisioning) и управления компьютерными центрами обработки данных с помощью машиночитаемых файлов определений, а не физической конфигурации оборудования или интерактивных инструментов конфигурации. Хотя область IAC является относительно новой по сравнению с конвейером автоматизации DevOps, уже существует достаточно много IAC-инструментов, и новые технологии продолжают развиваться даже в этот самый момент. И я рад сообщить вам, что большинство из них — проекты с открытым исходным кодом. В этой статье я хочу представить вам некоторые из наиболее известных и широко используемых IAC-инструментов, распространяемых по опенсорсным лицензиям.

Прежде чем мы углубимся в эту статью, вот несколько терминов, которые могут нам пригодиться.

Agent vs Agentless

(с агентами/без агентов)

IAC-инструмент может требовать запуска агента на каждом сервере, который вы хотите настроить. Если нет, то такой инструмент называется «agentless».

Mutable vs Immutable

Некоторые инструменты, такие как Terraform, занимаются не изменением уже подготовленной (provisioned) инфраструктуры, а развертывают новый сервер, что означает, что они следуют парадигме неизменяемой (immutable) инфраструктуры. Другие инструменты, такие как Ansible, Chef, SaltStack и Puppet, могут изменять существующие ресурсы, а это означает, что эти инструменты следуют парадигме изменяемой (mutable) инфраструктуры.

Procedural vs Declarative

Процедурные языки, такие как Ansible и Chef, позволяют описывать с помощью кода поэтапное выполнение, в то время как декларативные языки, такие как Terraform, SaltStack и Puppet, позволяют просто указать желаемое состояние.

Master vs Masterless

(с мастером/без мастера)

Языки, такие как Chef, требуют, чтобы вы запускали отдельный главный сервер (master), чтобы обеспечить дополнительное управление и постоянные состояния. Другие языки, такие как Ansible и Terraform, не нуждаются в определении мастера.

Configuration vs Provisioning

Ansible, Chef, SaltStack и Puppet известны как инструменты управления конфигурацией, что означает, что их основная цель — настроить ресурсы. Другие инструменты, такие как Terraform и Pulumi, являются инструментами обеспечения (provisioning), а это означает, что их основная цель — предоставлять ресурсы. Однако по мере того, как инструменты развиваются, их функционал может начать пересекаться.

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

Источник

Что такое IaC и как Ansible помогает его построить

Зачем появляются такие инструменты, как Ansible? Почему возникают такие направления, как IaC? Ответы на эти вопросы кроются в ряде проблем: большой «зоопарк» серверов, серверы-снежинки, которыми тяжело управлять — как итог, админы постепенно начинают не справляться с ручным управлением.

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

Инфраструктурный код должен проходить коммиты, CI/CD, merge requests, code review. IaC использует высокоуровневый язык описания кода для автоматизации предоставления ИТ-инфраструктуры. Эта автоматизация избавляет разработчиков от необходимости вручную выделять и управлять операционными системами, серверами, подключениями к хранилищам, базам данных и другим элементам инфраструктуры каждый раз, когда нужно написать, протестировать или развернуть программное приложение.

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

Плюсы IaC

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

Сам подход IaC состоит из декларативного или императивного описания инфраструктуры. Первое более распространено. IaC наиболее популярен в cloud computing и поддерживает IaaS (infrastructure as a service).

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

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

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

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

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

Минусы подхода IaC

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

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

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

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

Ansible как инструмент для построения инфраструктуры

Предположим, что у вас есть тесты, вы умеете собирать приложение, деплоить его. И вроде бы все хорошо. Но представим, что две ваши среды настроены по-разному. Как итог, вы упадете. Мораль здесь довольна проста: среды нужно настраивать одинаково, а конфигурациями критически важно управлять.

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

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

Принцип работы Ansible

Нам наиболее важно то, что Ansible осуществляет четыре правила IaC:

Воспроизводимость всех элементов инфраструктуры.

Возможность избавления от ненужного элемента.

Согласованность данных инфраструктуры.

Отсутствие какого-то «финального» состояния у инфраструктуры.

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

Есть и другие системы управления конфигурациями серверов: Otter, DSC, SaltStack, Pulumi, Chef, Puppet, CFEngine и, конечно же, Terraform. Ansible и Terraform от всех остальных отличает безагентная модель работы. Проясним: Ansible подключается к серверам и работает на них по SSH.

Открытый порт SSH для Linux и Python 3+, Python 3+, Ansible Windows User и WinRM для Windows — все, что требуется для работы Ansible на удаленном сервере. Сам Ansible устанавливают на компьютер админа, который должен быть на Linux.

Прежде чем в двух предложениях рассказать о принципе работы Ansible, приведем три термина:

нода – это компьютер, где установлен Ansible,

хосты – это удаленные серверы, к которым подключается Ansible,

модули осуществляют все необходимые действия на удаленных серверах.

Теперь будет проще понять концепцию Ansible, которая заключается в следующем: хосты управляются по SSH контрольной нодой с Ansible. Вам не нужны агенты или какое-либо дополнительное ПО на удаленных серверах, если вы работаете на Linux. Для тех, кто предпочитает работать на Windows, есть WSL2.

Теперь об архитектуре. Она тоже достаточно проста и содержит всего четыре элемента.

Modules — скрипты или программы, загружаемые и исполняемые на удаленных серверах.

Inventory — файл, где хранятся данные и где нужно производить необходимые действия.

API — интерфейс взаимодействия с Ansible.

Plugins — расширяющие возможности Ansible сопрограммы.

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

На курсе «Ansible: Infrastructure as Code» от Слёрма вы разберете реальные кейсы, поймете, как Ansible встраивается в продакшен и как его правильно внедрить в команду. Автор курса – Всеволод Севостьянов, Lead Engineer в Vene. Вместе с Всеволодом вы погрузитесь в 8 тем, изучите 38 уроков, посмотрите 10 часов видеолекций, ознакомитесь с 78 тестовыми и 46 практическими занятиями. Кстати, там еще есть 36 часов стендов для выполнения практик.

Источник

5 принципов, о которых нельзя забывать, когда описываешь инфраструктуру в виде кода

Infrastructure as Code — это подход, который подразумевает описание инфраструктуры в виде коде с его последующим применением для внесения необходимых изменений. Но, как именно писать код, IaC не говорит, только даёт инструменты. Один из таких инструментов — Terraform.

21 мая в Слёрм пройдёт практический интенсив «Terraform Мега». Мы пообщались с его автором Павлом Селиванов, архитектором Yandex.Cloud. Он рассказал, каких принципов нужно придерживаться, когда описываешь инфраструктуру, чтобы на выходе не получить непонятный и плохо поддерживаемый код.

№1. Читаемость

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

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

№2. Стиль написания

Нужно придерживаться определённого стиля написания кода. Например, длина строки кода должна быть в пределах 80-120 символов. Если строки очень длинные, редактор начинает их переносить. Переносы рушат общий вид и мешают пониманию кода. Приходится тратить много времени, чтобы просто разобраться, где началась и где закончилась строка.

Хорошо, когда проверка написания кода автоматизирована. Для этого можно использовать пайплайн CI/CD. Одним из шагов такого пайплайна должен быть Lint — процесс статистического анализа написанного, который помогает выявить потенциальные проблемы ещё до того, как код будет применен.

№3. Работа с репозиториями

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

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

№4. Автоматизация

Инструменты Infrastructure as Code так или иначе ассоциируются с DevOps. А DevOps — специалисты, которые не только занимаются сопровождением, но и помогают разработчикам работать: настраивают пайплайны, автоматизируют запуск тестов и т.д. Всё это тоже относится к IaC.

В Infrastructure as Code должна применяться автоматизация: правила Lint, тестирование, автоматические релизы и др.

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

Когда всё находится в репозитории и контролируется автоматическим CI/CD-пайплайном, мы всегда можем посмотреть, когда был запущен пайплайн и как он отработал. Можем контролировать параллельное выполнение пайплайнов, выявлять причины сбоев, быстро находить ошибки и многое другое.

№5. Тестирование

Часто от специалистов сопровождения можно слышать, что они никак не тестируют код или просто сначала запускают его где-то на dev. Это не самый удачный вариант тестирования, потому что он не даёт никаких гарантий, что dev соответствует prod. В случае с Ansible или другими инструментами конфигурации стандартное тестирование выглядит примерно так:

запустили тест на dev;

на dev прокатилось, но упало с ошибкой;

исправили эту ошибку;

ещё раз тест не запустили, потому что dev уже находится в том состоянии, к которому его пытались привести.

Кажется, что ошибку поправили, и можно катить на prod. Что случится с prod? Это всегда вопрос везения — попали или не попали, угадали или не угадали. Если где-то на середине, что-то снова упадёт, ошибку поправят и всё перезапустят.

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

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

То же относится и к инфраструктурному коду: после написания вы должны суметь протестировать его. Тесты позволяют уменьшить число ошибок и облегчить работу коллег, которые будут дорабатывать ваши роли на Ansible или файлы Terraform.

Пара слов про автоматизацию напоследок

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

Все эти принципы применительно к Terraform разберём на интенсиве

21-22 мая Слёрм проведёт практический интенсив «Terraform Мега». За два дня активного участия вы узнаете:

зачем использовать IaC;

как работает Terraform и как с его помощью управлять инфраструктурой;

как писать инфраструктурный код, который будет сопровождаемым и тестируемым;

как лучше использовать Terraform в корпоративном масштабе.

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

Источник

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 постоянно эволюционировал, и, вероятно, потребовалась бы целая статья, чтобы дать исчерпывающий обзор всех различных вариантов реализации этого подхода в ее конкретной инфраструктуре. Однако мы составили краткую хронологию основных инструментов, перечисленных по дате релиза:

Источник

Infrastructure as Code: первое знакомство

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

Продолжение серии статей, написанных по мотивам выступлений на нашем внутреннем мероприятии DevForum:

Мы решили сделать команду SRE, воплотив идеи google sre. Набрали программистов из своих же разработчиков и отправили их обучаться на несколько месяцев.

Перед командой стояли следующие учебные задачи:

Вводим понятие Infrastructure as code

В обычной модели мира (классическом администрировании) знания об инфраструктуре находятся в двух местах:

Таким образом инфраструктура как код (Incfastructure as Code – IaC) – это описание всей имеющейся инфраструктуры в виде кода, а также сопутствующие средства по работе с ним и воплощению из него же реальной инфраструктуры.

Итак, мы решили подключить новых SRE-инженеров, но откуда их брать? Книжка с правильными ответами (Google SRE Book) говорит нам: из разработчиков. Ведь они работают с кодом, а вы достигаете идеального состояния.

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

Проблемы Infrastructure as code

Теперь давайте посмотрим примеры того, как инфраструктура может быть зашита в код. Код хорошо написан, качественно, с комментами и отступами.

Пример кода из Terraforma.

Пример кода из Ansible.

Господа, но если бы всё было так просто! Мы же с вами в реальном мире, а он всегда готов удивить вас, преподнести сюрпризы, проблемы. Не обходится без них и здесь.

1. Первая проблема состоит в том, что в большинстве случаев IaC – это какой-то dsl.

А DSL, в свою очередь, – это описание структуры. Точнее того, что у тебя должно быть: Json, Yaml, модификации от каких-то крупных компаний, которые придумали свой dsl (в терраформе используется HCL).

Беда в том, что в нём может легко не быть таких привычных нам вещей как:

Вполне реальная ситуация, когда баш с питоном запускает какой-то процесс, в который подсовывается Json. Вы его анализируете, потом еще какой-то генератор выдает ещё 30 файлов. Для всего этого поступают входные переменные из Azure Key Vault, которые стянуты плагином к drone.io, написанным на Go, и переменные эти проходят через yaml, который получился в результате генерации из шаблонизатора jsonnet. Довольно сложно иметь строго хорошо описанный код, когда у вас настолько разнообразная среда.

Традиционная разработка в рамках одной задачи идет с одним языком. Здесь же мы работаем с большим количеством языков.

3. Третья проблема – это тулинг. Мы привыкли к крутым редакторам (Ms Visual Studio, Jetbrains Rider), которые все делают за нас. И даже, если мы затупили, они скажут, что мы не правы. Кажется, что это нормально и естественно.

Но где-то рядышком есть VSCode, в котором есть какие-то плагины, которые как-то ставятся, поддерживаются или не поддерживаются. Вышли новые версии, и их не поддержали. Банальный переход к имплементации функции (даже если она есть) становится сложной и нетривиальной проблемой. Простой ренейм переменной – это реплейс в проекте из десятка файлов. Повезёт, если он то, что надо зареплейсит. Есть, конечно, кое-где подсветка, есть автокомплишн, где-то есть форматинг (правда у меня в терраформе на винде не завелся).

На момент написания статьи vscode-terraform plugin еще не выпустили для поддержки версии 0.12, хотя она зарелижена уже как 3 месяца.

Пришло время забыть о.

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

Как новичок вы пытаетесь познать терраформ, а IDE вам в этом нисколько не помогает. Когда есть документация – зашли, посмотрели. Но если бы вы въезжали в новый язык программирования, то IDE подсказала бы, что есть такой тип, а такого нет. По крайней мере, на уровне int или string. Это часто бывает полезным.

А как же тесты?

Вы спросите: «Как же тесты, господа программисты?» Серьёзные ребята тестируют всё на проде, и это жестко. Вот пример юнитеста для терраформ-модуля с сайта Microsoft.

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

Проблема unit-теста в том, что мы с вами можем проверить корректность Jsonа на выходе. Я кинул 5 параметров, мне выдалась портянка Json на 2000 строк. Я могу проанализировать, что здесь происходит, validate test result…

Сложно анализировать Json в Go. А надо писать в Go, потому что терраформ на Go – это хорошая практика того, что тестируешь в том языке, в котором ты пишешь. Сама организация кода очень слабая. При этом – это лучшая библиотека для тестирования.

Сам Microsoft пишет свои модули, тестируя их таким способом. Конечно, это Open Source. Всё, о чем я говорю вы можете прийти и починить. Я могу сесть и за недельку всё починить, заопенсорсить плагины VS-кода, терраформ, сделать плагин для райдера. Может быть, написать парочку анализаторов, прикрутить линтеры, законтрибьютить библиотеку для тестирования. Всё могу сделать. Но я не этим должен заниматься.

Лучшие практики Infrastructure as code

Едем дальше. Если в IaC нет тестов, плохо с IDE и тулингом, то должны быть хотя бы лучшие практики. Я просто пошёл в гугл-аналитику и провёл сравнение двух поисковых запросов: Terraform best practices и c# best practices.

Что мы видим? Беспощадную статистику не в нашу пользу. По количеству материала – то же самое. В C# разработке мы просто купаемся в материалах, у нас есть сверхлучшие практики, есть книги написанные экспертами, и также книжки, написанные на книжки другими экспертами, которые критикуют те книжки. Море официальной документации, статей, обучающих курсов, сейчас еще и open source разработка.

Что касается запроса по IaC: здесь вы по крупицам пытаетесь собрать инфу с докладов хайлоада или HashiConf, с официальной документации и многочисленных issue на гитхабе. Как вообще эти модули раскидывать, что с ними делать? Кажется, что это реальная проблема… Есть же комьюнити, господа, где на любой вопрос тебе дадут 10 комментов на гитхабе. Но это не точно.

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

Куда всё это движется и что делать

Можно всё бросить и пойти обратно на C#, в мир райдера. Но нет. Зачем вы вообще стали бы этим заниматься, если не найти решение. Далее я привожу свои субъективные выводы. Можете поспорить со мной в комментариях, будет интересно.

Лично я ставлю на несколько вещей:

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

Банальный пример: совместная работа через pair programming. Он сильно помогает разобраться. Когда у тебя есть рядом сосед, который тоже что-то пытается понять, вместе вы поймёте лучше.

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

Заключение

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

Источник

Много машин в облаке — это не больно: IaC для управления масштабной инфраструктурой

Server Room by OliverWeiss97

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 приведет к одной из двух ситуаций:

Важно учитывать еще один момент: названия сущностей в 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 бонусных рублей — приходите, пробуйте и оставляйте обратную связь.

Источник

Что я узнал, протестировав 200 000 строк инфраструктурного кода

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

Infrastructure as bash history

Предположим приходите вы на новый проект, а вам говорят: «у нас Infrastructure as Code«. В реальности оказывается, Infrastructure as bash history или например Documentation as bash history. Это вполне реальная ситуация, например, подобный случай описывал Денис Лысенко в выступление Как заменить всю инфраструктуру и начать спать спокойно, он рассказал как из bash history они получили стройную инфраструктуру на проекте.

При некотором желании, можно сказать, что Infrastructure as bash history это как код:

Infrastructure as Code

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

На проекте по разработке СХД, была подзадача периодически настраивать SDS: выпускаем новый релиз — его необходимо раскатать, для дальнейшего тестирования. Задача предельно простая:

Для описанной логики более чем достаточно bash, особенно на ранних стадиях проекта, когда он только стартует. Это не плохо что вы используете bash, но со временем появляются запросы развернуть нечто похожее, но чуть-чуть отличающиеся. Первое что приходит в голову: copy-paste. И вот у нас уже два очень похожих скрипта, которые делают почти тоже самое. Со временем кол-во скриптов выросло, и мы столкнулись с тем, что есть некая бизнес логика развертывания инсталляции, которую необходимо синхронизировать между разными скриптами, это достаточно сложно.

Оказывается, есть такая практика D.R.Y. (Do not Repeat Yourself). Идея в том, чтобы переиспользовать существующий код. Звучит просто, но пришли к этому не сразу. В нашем случае это была банальная идея: отделить конфиги от скриптов. Т.е. бизнес логика как разворачивается инсталляция отдельно, конфиги отдельно.

S.O.L.I.D. for CFM

Со временем проект рос и естественным продолжением стало появление Ansible. Основная причина появления его это наличие экспертизы в команде и что bash не предназначен для сложной логики. Ansible тоже стал содержать сложную логику. Для того что бы сложная логика не превращалась в хаос, в разработке ПО существуют принципы организации кода S.O.L.I.D. Так же, например, Григория Петров в докладе «Зачем айтишнику личный бренд» затронул вопрос, что человек, так устроен, что ему проще оперировать какими-то социальными сущностями, в разработке ПО это объекты. Если объединить эти две идеи продолжить развивать их, то можно заметить, что в описании инфраструктуры тоже можно использовать S.O.L.I.D. что бы в дальнейшем было проще поддерживать и модифицировать эту логику.

The Single Responsibility Principle

Каждый класс выполняет лишь одну задачу.

Не надо смешивать код и делать монолитные божественные макаронные монстры. Инфраструктура должна состоять из простых кирпичиков. Оказывается, что если раздробить Ansible playbook на небольшие кусочки, читай Ansible роли, то их проще поддерживать.

The Open Closed Principle

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

The Liskov Substitution Principle

Принцип подстановки Барбары Лисков. объекты в программе должны быть заменяемыми на экземпляры их подтипов без изменения правильности выполнения программы

Если посмотреть шире, то не особенность какого-то конкретного проекта, что там можно применить S.O.L.I.D., оно в целом про CFM, например, на другом проекте необходимо разворачивать коробочное Java приложение поверх различных Java, серверов приложений, баз данных, OS, итд. На это примере я буду рассматривать дальнейшие принципы S.O.L.I.D.

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

Проблема здесь кроется в том, что в Ansible нельзя реализовать такое, как следствие в рамках команды появляются какие-то договоренности.

The Interface Segregation Principle

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

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

The Dependency Inversion Principle

Принцип инверсии зависимостей. Модули верхних уровней не должны зависеть от модулей нижних уровней. Оба типа модулей должны зависеть от абстракций. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.

Здесь пример будет основан на антипаттерне.

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

Interaction

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

Bus factor

Предположим, что у вас на проекте есть Вася. Вася всё знает про вашу инфраструктуру, что будет если Вася вдруг пропадет? Это вполне реальная ситуация, ведь его может сбить автобус. Иногда такое случается. Если такое случится и знание о коде, его структуре, как он работает, явках и паролях, не распределены в команде, то можно столкнуться с рядом неприятных ситуаций. Что бы минимизировать эти риски и распределить знание в рамках команды можно использовать различные подходы

Pair Devopsing

Это не как в шутке, что админы пили пиво, пароли меняли, а аналог парного программирования. Т.е. два инженера садятся за один компьютер, одну клавиатуру и начинают вместе настраивать вашу инфраструктуру: сервер настраивать, Ansible роль писать, итд. Звучит красиво, но у нас не сработало. Но вот частные случаи этой практики работали. Пришел новый сотрудник, его наставник вместе с ним берет реальную задачу, работает — передает знание.

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

Code Review

Субьективно, более эффективно распространение знаний об инфраструктуре и том как она устроена проходило при помощи code review:

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

Code Style

Со временем стали появляться склоки во время ревью, т.к. у ревьюверов был свой стиль и ротируемости ревьюверов стакивала их с разными стилями: 2 пробела или 4, camelCase или snake_case. Внедрить это получилось не сразу.

Green Build Master

Время идет, и пришли к тому что нельзя пускать в мастер коммиты, которые не проходят некие тесты. Вуаля! мы изобрели Green Build Master который уже давным-давно практикуется в разработке ПО:

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

IaC Testing

Кроме проверки стиля можно использовать и другие вещи, например, проверять что ваша инфраструктура действительно может развернуться. Или проверять что изменения в инфраструктуре не приведут к потере денег. Зачем это может понадобиться? Вопрос сложный и философский, ответить лучше байкой, что как-то был auto-scaler на Powershell который, не проверял пограничные условия => создалось больше ВМ чем надо => клиент потратил денег больше чем планировал. Приятного мало, но эту ошибку вполне реально было бы отловить на более ранних стадиях.

Можно спросить, а зачем делать сложную инфраструктуру еще сложнее? Тесты для инфраструктуры, так же, как и для кода, это не про упрощение, а про знание как ваша инфраструктура должна работать.

IaC Testing Pyramid

IaC Testing: Static Analysis

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

Bash is tricky

Вот рассмотрим банальный пример. выбрать все файлы в текущей директории и скопировать в другое место. Первое что приходит в голову:

А что если в имени файла пробел есть? Ну ок, мы же умные, умеем пользоваться кавычками:

Молодцы? нет! Что если в директории нет ничего, т.е. глобинг не сработает.

Static analysis tools

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

IaC Testing: Unit Tests

Как мы убедились из предыдущего примера, линтеры не всемогущие и не могут указать на все проблемные места. Дальше по аналогии с тестированием в разработке ПО можно вспомнить про unit tests. Тут сразу на ум приходят shunit, junit, rspec, pytest. Но что делать с ansible, chef, saltstack и иже с ними?

В самом начале мы говорили про S.O.L.I.D. и то что наша инфраструктура должна состоять из маленьких кирпичиков. Пришло их время.

IaC Testing: Unit Testing tools

Вопрос, а что такое тесты для CFM? можно банально запускать скрипт, а можно использовать готовые решения для этого:

Что выбрать? вопрос сложный и не однозначный, вот пример изменения в проектах на github за 2018-2019 года:

IaC Testing frameworks

Возникает как это все собрать вместе и запустить? Можно взять и сделать всё самому при наличии достаточного кол-во инженеров. А можно взять готовые решения, правда их не очень-то и много:

Пример изменения в проектах на github за 2018-2019 года:

Molecule vs. Testkitchen

Для 25-35 ролей это работало 40-70 минут, что было долго.

Следующим шагом стал переход на jenkins / docker / ansible / molecule. Идиологически все тоже самое

Линтовка для 40 ролей и тесты для десятка стали занимать порядка 15 минут.

Что выбрать зависит от множества факторов, как то используемый стэк, экспертиза в команде итд. тут каждый решает сам как закрывать вопрос Unit тестирования

IaC Testing: Integration Tests

На следующей ступени пирамиды тестирования инфраструктуры появлются интеграционные тесты. Они похожи на Unit тесты:

Грубо говоря, мы не проверяем работоспособность отдельного элемента системы как в unit тестах, мы проверяем как сервер сконфигурирован в целом.

IaC Testing: End to End Tests

На вершине пирамиды нас встречают End to End тесты. Т.е. мы не проверяем работоспособность отдельного сервера, отдельного скрипта, отдельного кирпичика нашей инфраструктуры. Мы проверяем что множество серверов, объединенных воедино, наша инфраструктура работает, как мы этого ожидаем. К сожалению готовых коробочных решений, мне не доводилось видеть, наверно т.к. инфраструктура зачастую уникальная и ее сложно шаблонизировать и сделать фрэймворк для ее тестирования. Как итог все создают свои собственные решению. Спрос есть, а вот ответа нет. Поэтому, расскажу что есть, чтобы натолкнуть других на здравые мысли или ткнуть меня носом, что всё давно изобретено до нас.

Проект с богатой историей. Используется в больших организациях и вероятно каждый из вас косвенно пересекался. Приложение поддерживает множество баз данных, интеграций итд итп. Знание о том, как инфраструктура может выглядеть это множество docker-compose файлов, а знание того, какие тесты в каком окружение запускать — это jenkins.

Эта схема достаточно долго работала, пока в рамках исследования мы не попробовали это перенести в Openshift. Контейнеры остались теже, а вот среда запуска сменилась (привет D.R.Y. опять).

Мысль исследования пошла дальше, и в openshift нашлась такая штука APB (Ansible Playbook Bundle), которая позволяет в контейнер запаковать знание как разворачивать инфраструктуру. Т.е. есть воспроизводимая, тестируемая точка знания, как развернуть инфраструктуру.

Всё это звучало хорошо, пока не уткнулись в гетерогенную инфраструктуру: нам для тестов нужна Windows. В итоге знание о том что, где как развернуть, и протестировать сидит в jenkins.

Conclusion

Infrastructure as Code это

Источник

What is infrastructure as code (IaC)?

Infrastructure as code (IaC) uses DevOps methodology and versioning with a descriptive model to define and deploy infrastructure, such as networks, virtual machines, load balancers, and connection topologies. Just as the same source code always generates the same binary, an IaC model generates the same environment every time it deploys.

IaC is a key DevOps practice and a component of continuous delivery. With IaC, DevOps teams can work together with a unified set of practices and tools to deliver applications and their supporting infrastructure rapidly and reliably at scale.

Avoid manual configuration to enforce consistency

IaC evolved to solve the problem of environment drift in release pipelines. Without IaC, teams must maintain deployment environment settings individually. Over time, each environment becomes a «snowflake,» a unique configuration that can’t be reproduced automatically. Inconsistency among environments can cause deployment issues. Infrastructure administration and maintenance involve manual processes that are error prone and hard to track.

IaC avoids manual configuration and enforces consistency by representing desired environment states via well-documented code in formats such as JSON. Infrastructure deployments with IaC are repeatable and prevent runtime issues caused by configuration drift or missing dependencies. Release pipelines execute the environment descriptions and version configuration models to configure target environments. To make changes, the team edits the source, not the target.

Idempotence, the ability of a given operation to always produce the same result, is an important IaC principle. A deployment command always sets the target environment into the same configuration, regardless of the environment’s starting state. Idempotency is achieved by either automatically configuring the existing target, or by discarding the existing target and recreating a fresh environment.

Deliver stable test environments rapidly at scale

IaC helps DevOps teams test applications in production-like environments early in the development cycle.В Teams can provision multiple test environments reliably on demand. The cloud dynamically provisions and tears down environments based on IaC definitions. The infrastructure code itself can be validated and tested to prevent common deployment issues.

Use declarative definition files

IaC should use declarative definition files if possible. A definition file describes the components and configuration that an environment requires, but not necessarily how to achieve that configuration. For example, the file might define a required server version and configuration, but not specify the server installation and configuration process. This abstraction allows for greater flexibility to use optimized techniques the infrastructure provider supplies. Declarative definitions also help reduce the technical debt of maintaining imperative code, such as deployment scripts, that can accrue over time.

There’s no standard syntax for declarative IaC. The syntax for describing IaC usually depends on the requirements of the target platform. Different platforms support file formats such as YAML, JSON, and XML.

Deploy IaC on Azure

Azure provides native support for IaC via the Azure Resource Manager model. Teams can define declarative ARM templates that specify the infrastructure required to deploy solutions.

Third-party platforms like Terraform, Ansible, Chef, and Pulumi also support IaC to manage automated infrastructure.

Источник

Инфраструктура как код. Введение для начинающих

Согласно отчету «State of DevOps 2019», 80% респондентов сказали, что основное приложение или служба, которую они поддерживали, было размещено на какой-то облачной платформе. 50% респондентов заявили, что их основное приложение размещено в публичном облаке.

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

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

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

Льготы

Инфраструктура как код предоставляет значительные преимущества по сравнению с ручной подготовкой:

Самообслуживание

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

Идемпотентность

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

Такие инструменты, как Ansible и Terraform, имеют встроенные функции, которые делают ваш код идемпотентным.

Снижение затрат

Сокращает время и усилия, необходимые для предоставления, намного меньше, чем подготовка вручную.

Более быстрая доставка программного обеспечения

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

Самодокументирование

Состояние инфраструктуры определяется в коде, который легко читается любым человеком.

Контролируемая версия

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

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

Валидация и тестирование

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

Улучшенная безопасность

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

Источник

What is Infrastructure as Code (IaC)?

Overview

Infrastructure as Code (IaC) is the managing and provisioning of infrastructure through code instead of through manual processes.

With IaC, configuration files are created that contain your infrastructure specifications, which makes it easier to edit and distribute configurations. It also ensures that you provision the same environment every time. By codifying and documenting your configuration specifications, IaC aids configuration management and helps you to avoid undocumented, ad-hoc configuration changes.

Version control is an important part of IaC, and your configuration files should be under source control just like any other software source code file. Deploying your infrastructure as code also means that you can divide your infrastructure into modular components that can then be combined in different ways through automation.

Automating infrastructure provisioning with IaC means that developers don’t need to manually provision and manage servers, operating systems, storage, and other infrastructure components each time they develop or deploy an application. Codifying your infrastructure gives you a template to follow for provisioning, and although this can still be accomplished manually, an automation tool, such as Red Hat ® Ansible ® Automation Platform, can do it for you.

Declarative vs. imperative approaches to IaC

There are 2 ways to approach IaC: declarative or imperative.

A declarative approach defines the desired state of the system, including what resources you need and any properties they should have, and an IaC tool will configure it for you.

A declarative approach also keeps a list of the current state of your system objects, which makes taking down the infrastructure simpler to manage.

An imperative approach instead defines the specific commands needed to achieve the desired configuration, and those commands then need to be executed in the correct order.

Many IaC tools use a declarative approach and will automatically provision the desired infrastructure. If you make changes to the desired state, a declarative IaC tool will apply those changes for you. An imperative tool will require you to figure out how those changes should be applied.

IaC tools are often able to operate in both approaches, but tend to prefer 1 approach over the other.

Benefits of IaC

Provisioning infrastructure has historically been a time consuming and costly manual process. Now infrastructure management has moved away from physical hardware in data centers, though this still may be a component for your organization, to virtualization, containers, and cloud computing.

With cloud computing, the number of infrastructure components has grown, more applications are being released to production on a daily basis, and infrastructure needs to be able to be spun up, scaled, and taken down frequently. Without an IaC practice in place, it becomes increasingly difficult to manage the scale of today’s infrastructure.

IaC can help your organization manage IT infrastructure needs while also improving consistency and reducing errors and manual configuration.

Benefits:

What’s the difference between Ansible and Red Hat Ansible Automation Platform?

IaC tools

Server automation and configuration management tools can often be used to achieve IaC. There are also solutions specifically for IaC.

These are a few popular choices:

Ansible Automation Platform can be used to provision operating systems and network devices, deploy applications, and manage configuration.

Why does IaC matter for DevOps?

IaC is an important part of implementing DevOps practices and continuous integration/continuous delivery (CI/CD). IaC takes away the majority of provisioning work from developers, who can execute a script to have their infrastructure ready to go.

That way, application deployments aren’t held up waiting for the infrastructure, and sysadmins aren’t managing time-consuming manual processes.

CI/CD relies on ongoing automation and continuous monitoring throughout the application lifecycle, from integration and testing to delivery and deployment.

In order for an environment to be automated it needs to be consistent. Automating application deployments doesn’t work when the development team deploys applications or configures environments one way and the operations teams deploys and configures another way.

Aligning development and operations teams through a DevOps approach leads to fewer errors, manual deployments, and inconsistencies.

IaC helps you to align development and operations because both teams can use the same description of the application deployment, supporting a DevOps approach.

The same deployment process should be used for every environment, including your production environment. IaC generates the same environment every time it is used.

IaC also removes the need to maintain individual deployment environments with unique configurations that can’t be reproduced automatically and ensures that the production environment will be consistent.

DevOps best practices are also applied to infrastructure in IaC. Infrastructure can go through the same CI/CD pipeline as an application does during software development, applying the same testing and version control to the infrastructure code.

Why choose Red Hat for automation?

Creating an enterprise-wide approach to automation lets you automate not only IT processes, but also entire technologies, teams, and organizations.

Red Hat® Ansible® Automation Platform includes all the tools needed to implement enterprise-wide automation, including playbooks, a visual dashboard, and analytics. Ansible Automation Platform also uses webhooks to to automate IaC workflows and enable GitOps practices.

Ansible Playbooks, written in YAML, describe the desired state of your systems, which are usually kept in source control. Ansible Automation Platform does the work of getting your systems to the desired state, no matter their current state.

Ansible Automation Platform makes your installations, upgrades and day-to-day management repeatable and reliable.

With the right automation solution in place, you can deploy new applications and services faster, manage IT infrastructure more efficiently, and see an increase in app development productivity.

Keep reading

Learning Ansible basics

Ansible automates IT processes like provisioning and configuration management. Learn the basics of Ansible with this introduction to key concepts.

What is business process management?

Business process management (BPM) is the practice of modeling, analyzing, and optimizing end-to-end business processes to meet your strategic business goals.

Why choose Red Hat for automation?

Red Hat Ansible Automation Platform includes all the tools needed to share automation across teams and implement enterprise-wide automation.

More about automation

Products

Engagements with our strategic advisers who take a big-picture view of your organization, analyze your challenges, and help you overcome them with comprehensive, cost-effective solutions.

A platform for implementing enterprise-wide automation, no matter where you are in your automation journey

A platform for developing cloud-native applications that automate business decisions and processes.

Источник

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

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

Такие средства, как Azure Resource Manager (ARM), Terraform и интерфейс командной строки Azure (CLI), позволяют декларативно создавать сценарии необходимой облачной инфраструктуры.

Шаблоны Azure Resource Manager

ARM означает Azure Resource Manager. Это модуль подготовки API, встроенный в Azure и предоставляемый в качестве службы API. ARM позволяет развертывать, обновлять, удалять и администрировать ресурсы, содержащиеся в группе ресурсов Azure, в рамках одной скоординированной операции. Вы предоставляете обработчик шаблону на основе JSON, который указывает необходимые ресурсы и их конфигурацию. ARM автоматически управляет развертыванием в правильном порядке с учетом зависимостей. Подсистема обеспечивает идемпотентность. Если требуемый ресурс уже существует с той же конфигурацией, подготовка будет проигнорирована.

Шаблоны Azure Resource Manager — это язык на основе JSON для определения различных ресурсов в Azure. Базовая схема выглядит примерно так: рис. 10-14.

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

Шаблон ARM можно параметризовать с помощью динамической среды и сведений о конфигурации. Это позволяет повторно использовать его для определения различных сред, таких как разработка, QA или рабочая среда. Как правило, шаблон создает все ресурсы в одной группе ресурсов Azure. При необходимости можно определить несколько групп ресурсов в одном шаблоне Resource Manager. Вы можете удалить все ресурсы в среде, удалив саму группу ресурсов. Анализ затрат также может выполняться на уровне группы ресурсов, что позволяет быстро учитывать стоимость каждой среды.

В проекте шаблонов быстрого запуска Azure на сайте GitHub доступно множество примеров шаблонов ARM. Они могут помочь ускорить создание нового шаблона или изменить существующий.

Шаблоны Resource Manager можно запускать различными способами. Возможно, самый простой способ — просто вставить их на портал Azure. Для экспериментальных развертываний этот метод может быть быстрым. Они также могут выполняться как часть процесса сборки или выпуска в Azure DevOps. Существуют задачи, которые будут использовать подключения к Azure для запуска шаблонов. Изменения шаблонов Resource Manager применяются постепенно, то есть для добавления нового ресурса требуется только добавить его в шаблон. Средства будут согласовывать различия между текущими ресурсами и теми, которые определены в шаблоне. Затем ресурсы будут созданы или изменены, чтобы они соответствовали тому, что определено в шаблоне.

Terraform

Terraform — это коммерческое средство создания шаблонов, которое может подготавливать собственные облачные приложения для всех основных облачных игроков: Azure, Google Cloud Platform, AWS и AliCloud. Вместо того чтобы использовать JSON в качестве языка определения шаблона, он использует немного более подробный HCL (язык конфигурации Hashicorp).

Пример файла Terraform, который выполняет то же самое, что и предыдущий шаблон Resource Manager (рис. 10-15), показан на рисунке 10-16:

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

Как и в случае с шаблонами Resource Manager, средства командной строки доступны для развертывания шаблонов Terraform. В Azure Pipelines также есть задачи, созданные сообществом, которые могут проверять и применять шаблоны Terraform.

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

Скрипты и задачи Azure CLI

Наконец, вы можете использовать Azure CLI для декларативного скрипта облачной инфраструктуры. Скрипты Azure CLI можно создавать, находить и совместно использовать для подготовки и настройки практически любого ресурса Azure. Интерфейс командной строки прост в использовании с нежной кривой обучения. Скрипты выполняются в PowerShell или Bash. Они также просты в отладке, особенно при сравнении с шаблонами ARM.

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

На рисунке 10–17 показан фрагмент YAML, в который перечислены версия Azure CLI и сведения о подписке. Обратите внимание, как команды Azure CLI включены в встроенный скрипт.

В статье » Что такое инфраструктура как код», автор Сэм Гукенхаймер описывает, как «Teams, реализующие IaC, могут быстро и масштабировать стабильные среды. Teams избегает ручной настройки сред и обеспечивает согласованность путем представления требуемого состояния сред с помощью кода. Развертывания инфраструктуры с IaC повторяются и предотвращают проблемы среды выполнения, вызванные смещением конфигурации или отсутствием зависимостей. Команды DevOps могут работать вместе с единым набором методик и инструментов для быстрого, надежного и масштабного предоставления приложений и их вспомогательной инфраструктуры.

Источник

Infrastructure as code

Cloud-native systems embrace microservices, containers, and modern system design to achieve speed and agility. They provide automated build and release stages to ensure consistent and quality code. But, that’s only part of the story. How do you provision the cloud environments upon which these systems run?

Tools like Azure Resource Manager (ARM), Terraform, and the Azure Command Line Interface (CLI) enable you to declaratively script the cloud infrastructure you require.

Azure Resource Manager templates

ARM stands for Azure Resource Manager. It’s an API provisioning engine that is built into Azure and exposed as an API service. ARM enables you to deploy, update, delete, and manage the resources contained in Azure resource group in a single, coordinated operation. You provide the engine with a JSON-based template that specifies the resources you require and their configuration. ARM automatically orchestrates the deployment in the correct order respecting dependencies. The engine ensures idempotency. If a desired resource already exists with the same configuration, provisioning will be ignored.

Azure Resource Manager templates are a JSON-based language for defining various resources in Azure. The basic schema looks something like Figure 10-14.

Within this template, one might define a storage container inside the resources section like so:

An ARM template can be parameterized with dynamic environment and configuration information. Doing so enables it to be reused to define different environments, such as development, QA, or production. Normally, the template creates all resources within a single Azure resource group. It’s possible to define multiple resource groups in a single Resource Manager template, if needed. You can delete all resources in an environment by deleting the resource group itself. Cost analysis can also be run at the resource group level, allowing for quick accounting of how much each environment is costing.

There are many examples of ARM templates available in the Azure Quickstart Templates project on GitHub. They can help accelerate creating a new template or modifying an existing one.

Resource Manager templates can be run in many of ways. Perhaps the simplest way is to simply paste them into the Azure portal. For experimental deployments, this method can be quick. They can also be run as part of a build or release process in Azure DevOps. There are tasks that will leverage connections into Azure to run the templates. Changes to Resource Manager templates are applied incrementally, meaning that to add a new resource requires just adding it to the template. The tooling will reconcile differences between the current resources and those defined in the template. Resources will then be created or altered so they match what is defined in the template.

Terraform

Terraform is a commercial templating tool that can provision cloud-native applications across all the major cloud players: Azure, Google Cloud Platform, AWS, and AliCloud. Instead of using JSON as the template definition language, it uses the slightly more terse HCL (Hashicorp Configuration Language).

An example Terraform file that does the same as the previous Resource Manager template (Figure 10-15) is shown in Figure 10-16:

Terraform also provides intuitive error messages for problem templates. There’s also a handy validate task that can be used in the build phase to catch template errors early.

As with Resource Manager templates, command-line tools are available to deploy Terraform templates. There are also community-created tasks in Azure Pipelines that can validate and apply Terraform templates.

Sometimes Terraform and ARM templates output meaningful values, such as a connection string to a newly created database. This information can be captured in the build pipeline and used in subsequent tasks.

Azure CLI Scripts and Tasks

Finally, you can leverage Azure CLI to declaratively script your cloud infrastructure. Azure CLI scripts can be created, found, and shared to provision and configure almost any Azure resource. The CLI is simple to use with a gentle learning curve. Scripts are executed within either PowerShell or Bash. They’re also straightforward to debug, especially when compared with ARM templates.

Azure CLI scripts work well when you need to tear down and redeploy your infrastructure. Updating an existing environment can be tricky. Many CLI commands aren’t idempotent. That means they’ll recreate the resource each time they’re run, even if the resource already exists. It’s always possible to add code that checks for the existence of each resource before creating it. But, doing so, your script can become bloated and difficult to manage.

Figure 10-17 shows a YAML snippet that lists the version of Azure CLI and the details of the subscription. Note how Azure CLI commands are included in an inline script.

In the article, What is Infrastructure as Code, Author Sam Guckenheimer describes how, «Teams who implement IaC can deliver stable environments rapidly and at scale. Teams avoid manual configuration of environments and enforce consistency by representing the desired state of their environments via code. Infrastructure deployments with IaC are repeatable and prevent runtime issues caused by configuration drift or missing dependencies. DevOps teams can work together with a unified set of practices and tools to deliver applications and their supporting infrastructure rapidly, reliably, and at scale.»

Источник

Опыт построения Infrastructure-as-Code в VMware. Часть 1: Обозначение проблемы

Приветствую, дорогой читатель. Я начинаю цикл статей о том, как мы искали решение для применения подхода Infrastructure-as-Code в нашем виртуальном окружении VMware VSphere.

У нас есть система управления конфигурациями Puppet для Linux, есть (на данный момент) DSC для Windows Server.

Что касается Linux — практически все автоматизированно. Мы заносим конфигурации машин в nodes.yaml, мы заносим роли в Hiera, строим модули (или берем готовые), у нас есть PXE, IP адреса раздаются из DHCP по MAC адресу.

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

Когда я впервые поднял этот вопрос, мне сказали, что искали решение, пробовали варианты, но ничего не получилось. “К черту!” — подумал я и поспорил на ящик пива, что найду решение, которое будет работать по следующему сценарию: разработчик или инженер делает Pull Request, в котором у нас находится конфигурация виртуальной машины (ядра, память, сеть, шаблон и т.д.) — далее некая магия обращается в VSphere и создает машину, согласно настройкам в файле.

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

У нас в качестве On-Premise виртуализации используется VMware VSphere — парочка датацентров, datastore-кластер и несколько Resource Pool’ов (RP) под каждую команду. Члены команды имеют права на создание виртуальных машин в пределах RP, ребята-инфраструктурщики им в этом не мешают и просто занимаются обслуживанием всей платформы, периодически напоминая разработчикам и инженерам убирать за собой неиспользуемые машины (ресурсы-то не резиновые).

У нас есть Windows виртуалки, Linux виртуалки, масштаб задач огромен — веб серверы, реверс прокси, балансировщики, контроллеры домена, серверы приложений и баз данных и нет им конца и края.

Теперь я поведаю тебе, какие инструменты я пытался применять, и почему они мне не подошли.

Эмпирическим путем…

Ansible vsphere_guest

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

Согласно документации, есть хороший модуль vsphere_guest который может создавать и удалять виртуалки. То, что нужно. Вот так выглядит мой плейбук createvm.yaml

Я сознательно комментирую hostname esxi потому, что я создаю виртуалку непосредственно в RP, а не на хосте. DRS сам решит, куда виртуалку положить.

Если я запускаю плейбук, он ругается что необходимый параметр hostname не указан. Если я его раскоментирую, то он поругается на отсутствие прав на создание виртуалки на esx хосте (что очевидно, т.к. права у меня есть только на RP). Я создал соответствующий issue, так что надеюсь, ребята из Ansible это исправят, поскольку инструмент реально хороший.

Terraform

Иная тулза, которая умеет создавать виртуалки в VMware это Terraform, продукт от HashiCorp. Изначально он заточен под взаимодействие с Packer и деплоит в AWS, но наши задачи он тоже решает. Вот собственно файл с конфигурацией:

terraform plan работает прекрасно.

Что так же здорово, можно задать IP адрес, доменное имя — то есть задать полноценную кастомизацию машинки из шаблона. Пробуем запустить…

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

Что ж… снова неудача. Позже выяснилось, что Terraform не умеет работать с datastore-кластерами. Соответственный issue был создан на GitHub моим коллегой, но успехов на этот поприще тоже, увы, нет.

PowerCLI

Претерпев неудачу в поисках рабочих инструментов от третьих лиц, я решил обратиться к вендорскому решению.

Вендор предлагает два решения — PowerCLI (надстройка над Powershell) и vmware-cli (командный интерфейс для *nix).

Заставить работать vmware-cli на CentOS 7 и OS X не удалось (один страдалец даже написал блог об этом), посему я решил сразу начать пользоваться инструментом, который работает.

Внимательный читатель может поинтересоваться, почему я потратил столько времени на Ansible и Terraform, в то время как PowerCLI уже давно используется. Причины просты — я не знаю Powershell на должном уровне, чтобы с наскоку начать пользоваться им, плюс это вынуждает меня использовать windows машину, которая будет заниматься чистым provision’ом. Впрочем, иных вариантов у меня и нет.

Беглое изучение документации дало мне достаточно навыков, чтобы написать простенький скрипт.

Этот скрипт рабочий и делает все необходимое. Запуск скрипта выглядит следующим образом:

Скрипт попросит меня предоставить логин и пароль, переиграет переменные и создаст машинку с помощью cmdlet’а new-vm. Читатель может поинтересоваться, почему присутствует вот эта строка:

Пусть меня поправят опытные powershell ребята, если я ошибаюсь. Get-Credential создает объект состоящий из логина, пароля и домена (если он есть). Пароль находится в состоянии SecureString. К сожалению, PowerCLI не умеет работать ни с объектом Get-Credential, ни с SecureString, потому приходится идти на подобные ухищрения, чтобы передать ему логин и пароль простой строковой переменной.

Выводы

Дорогой читатель, если у тебя однажды встанет задача автоматизировать создание виртуальных машин в VMware, то учти следующее:

Если же у тебя такая же сложная инфраструктура, как и у нас, то лучше не изобретай велосипед, а осваивай PowerCLI.

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

Источник

Terraform: новый подход к Infrastructure as code

Привет, коллеги! Пока блистательный Илон Маск вынашивает амбициозные планы терраформирования Марса, мы интересуемся новыми возможностями, связанными с парадигмой «Infrastructure as Code» и хотим предложить вам перевод статьи об одном из представителей «великолепной семерки» — Terraform. Книга Евгения Брикмана по теме неплохая, но ей скоро год, так что просим высказаться — хотите ли увидеть ее на русском языке

Слово Камалу Мархуби (Kamal Marhubi) из компании Heap.

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

Terraform и инфраструктура на уровне кода

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

Вот как, к примеру, в Terraform определяется инстанс EC2 с томом EBS:

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

Модель данных Terraform

В общей перспективе модель данных Terraform проста: Terraform управляет ресурсами, а у ресурсов есть атрибуты. Несколько примеров из мира AWS:

Не всякий ресурс Terraform – это ресурс AWS

Понять такую модель данных с ресурсами и атрибутами не столь сложно, однако, она может не вполне совпадать с API облачного провайдера. Фактически, единственный ресурс Terraform может соответствовать как одному, так и нескольким базовым объектам облачного провайдера – либо даже не соответствовать ни одному. Вот несколько примеров из AWS:

Все задачи решаются несколькими способами, так что при выборе будьте внимательны!

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

Зачастую не важно, какое именно представление EBS вы выберете. Но иногда, если выбор был ошибочным, изменить после этого вашу инфраструктуру будет довольно сложно!

Мы ошиблись с выбором

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

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

Состояние Terraform: переходим к хирургии

Учитывая, что у нас добавлялось более тысячи ресурсов, мы определенно не собирались делать это вручную. Состояние Terraform хранится в формате JSON. Хотя, этот формат стабилен, в документации указано, что «непосредственно редактировать файлы с состоянием не рекомендуется». Нам бы все равно пришлось это делать, но мы хотели быть уверены, что делаем это верно. Мы решили не заниматься обратной разработкой формата JSON, а написали программу, которая использует внутренние элементы Terraform как библиотеку для считывания, изменения и записи. Это было не так просто, поскольку для всех из нас это была первая программа на Go, с которой довелось работать! Но мы считали, что необходимо убедиться: да мы не перепутаем в одну кучу все Terraform-состояния всех инстансов нашей базы данных.

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

Терраформируем аккуратно

Запуск terraform apply – один из тех немногочисленных актов, которым можно всерьез повредить всю корпоративную инфраструктуру. Есть несколько советов, следуя которым, риски можно снизить – и вообще будет не так страшно.

Всегда готовьте план –out и следуйте этому плану

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

Для перебора изменений сделайте специальную роль IAM «только для чтения»

Работая с AWS, можно управлять в Terraform ролями IAM и соответствующими правами доступа. Роль в Terraform выглядит так:

В assume_role_policy просто выводится список пользователей, которые вправе принять эту роль.

Организовать такую роль оказалось гораздо легче, чем переписывать все состояние Terraform для использования aws_volume_attachment с томами нашей базы данных. Мы знали, что никаких изменений в инфраструктуре AWS не планируется – поменяться должно было лишь ее представление в Terraform. В конце концов, мы совершенно не собирались менять инфраструктуру – зачем же нам такая возможность?

Идеи на будущее

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

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

Источник

Lessons learned from testing Over 200,000 lines of Infrastructure Code

IaC (Infrastructure as Code) is a modern approach and I believe that infrastructure is code. It means that we should use the same philosophy for infrastructure as for software development. If we are talking that infrastructure is code, then we should reuse practices from development for infrastructure, i.e. unit testing, pair programming, code review. Please, keep in mind this idea while reading the article.

It is the translation of my speech (video RU) at DevopsConf 2019-05-28.

Infrastructure as bash history

Let us imagine that you are on-boarding on a project and you hear something like: «We use Infrastructure as Code approach». Unfortunately, what they really mean is Infrastructure as bash history or Documentation as bash history. This is almost a real situation. For example, Denis Lysenko described this situation in his speech How to replace infrastructure and stop worrying(RU). Denis shared the story on how to convert bash history into an upscale infrastructure.

What is to be done?

Infrastructure as Code

On the one hand, this abnormal case, Infrastructure as bash history, can be presented as Infrastructure as Code, but on the other hand, if you want to do something more complex than LAMP server, you have to manage, maintain and modify the code. Let us chat about parallels between Infrastructure as Code development and software development.

We were developing SDS (software-defined storage). The SDS consisted of custom OS distributive, upscale servers, a lot of business logic, as a result, it had to use real hardware. Periodically, there was a sub-task install SDS. Before publishing new release, we had to install it and check out. At first, it looked as if it was a very simple task:

I believe that Make CM, not bash is a good approach. However, bash is only used in extreme, limited cases, like at the very beginning of a project. So, bash was a pretty good and reasonable choice at the very beginning of the project. Time was ticking. We were facing different requests to create new installations in a slightly different configuration. We were SSHing into installations, and running the commands to install all needed software, editing the configuration files by scripts and, finally, configuring SDS via Web HTTP rest API. After all that the installation was configured and working. This was a pretty common practice, but there were a lot of bash scripts and installation logic was becoming more complex every day.

Unfortunately, each script was like a little snowflake depending on who was copy-pasting it. It was also a real pain when we were creating or recreating the installation.

I hope you have got the main idea, that at this stage we had to constantly tweak scripts logic until the service was OK. But, there was a solution for that. It was D.R.Y.

There is D.R.Y. (Do not Repeat Yourself) approach. The main idea is to reuse already existing code. It sounds extremely simple. In our case, D.R.Y. was meaning: split configs and scripts.

S.O.L.I.D. for CFM

The project was growing, as a result, we decided to use Ansible. There were reasons for that:

There was an amount of business logic inside the Ansible code. There is an approach for putting things in source code during the software development process. It is called S.O.L.I.D.. From my point of view, we can re-use S.O.L.I.D. for Infrastructure as Code. Let me explain step by step.

The Single Responsibility Principle

A class should only have a single responsibility, that is, only changes to one part of the software’s specification should be able to affect the specification of the class.

You should not create a Spaghetti Code inside your infrastructure code. Your infrastructure should be made from simple predictable bricks. In other words, it might be a good idea to split immense Ansible playbook into independent Ansible roles. It will be easier to maintain.

The Open-Closed Principle

Software entities… should be open for extension, but closed for modification.

In the beginning, we were deploying the SDS at virtual machines, a bit later we added deploy to bare metal servers. We had done it. It was as easy as pie for us because we just added an implementation for bare metal specific parts without modifying the SDS installation logic.

The Liskov Substitution Principle

Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.

Let us be open-minded. S.O.L.I.D. is possible to use in CFM in general, it was not a lucky project. I would like to describe another project. It is an out of box enterprise solution. It supports different databases, application servers and integration interfaces with third-party systems. I am going to use this example for describing the rest of S.O.L.I.D.

For example in our case, there is an agreement inside infrastructure team: if you deploy ibm java role or oracle java or openjdk, you will have executable java binary. We need it because top*level Ansible roles depend on that. Also, it allows us to swap java implementation without modifying application installing logic.

Unfortunately, there is no syntax sugar for that in Ansible playbooks. It means that you must keep it in mind while developing Ansible roles.

The Interface Segregation Principle

Many client-specific interfaces are better than one general-purpose interface.

In the beginning, we were putting application installation logic into the single playbook, we were trying to cover all cases and cutting edges. We had faced the issue that it is hard to maintain, so we changed our approach. We understood that a client needs an interface from us (i.e. https at 443 port) and we were able to combine our Ansible roles for each specific environment.

The Dependency Inversion Principle

One should «depend upon abstractions, [not] concretions.»

I would like to describe this principle via anti-pattern.

In other words, we were not able to reuse our IaC in another cloud because top-level deploying logic was depending on the lower-level implementation. Please, don’t do it

Interaction

Infrastructure is not only code, it is also about interaction code DevOps, DevOps DevOps, IaC people.

Bus factor

Let us imagine, there is DevOps engineer John. John knows everything about your infrastructure. If John gets hit by a bus, what will happen with your infrastructure? Unfortunately, it is almost a real case. Some time things happen. If it has happened and you do not share knowledge about IaC, Infrastructure among your team members you will face a lot of unpredictable & awkward consequences. There are some approaches for dealing with that. Let us chat about them.

Pair DevOpsing

It is like pair programming. In other words, there are two DevOps engineers and they use single laptop\keyboard for configuring infrastructure: configuring a server, creating Ansible role, etc. It sounds great, however, it did not work for us. There were some custom cases when it partially worked.

Code Review

From my point of view, Code review is one of the most efficient ways to share knowledge inside a team about your infrastructure. How does it work?

The most interesting thing is that we were rotating a reviewer. It means that every couple of days we elected a new reviewer and the reviewer was looking through all merge requests. As a result, theoretically, every person had to touch a new part of the infrastructure and had an average knowledge about our infrastructure in general.

Code Style

Time was ticking, we were sometimes arguing during the review because the reviewer and the committer might use a different code style: 2 spaces or 4, camelCase or snake_case. We implemented it, however, it was not a picnic.

Green Build Master

Next, the most painful step was to restrict pushing to the master branch for everyone. Only via merge requests & green tests have to be ok. This is called Green Build Master. In other words, you are 100% sure that you can deploy your infrastructure from the master branch. It is a pretty common practice in software development:

It was a tough decision. Hopefully, as a result during review process, there was no arguing about the code style and the amount of code smell was decreasing.

IaC Testing

Besides code style checking, you are able to check that you can deploy or recreate your infrastructure in a sandbox. What’s for? It is a sophisticated question and I would like to share a story instead of an answer. Were was a custom auto-scaler for AWS written in Powershell. The auto-scaler did not check cutting edges for input params, as a result, it created tons of virtual machines and the customer was unhappy. It is an awkward situation, hopefully, it is possible to catch it on the earliest stages.

On the one hand, it is possible to test the script & infrastructure, but on the other hand, you are increasing an amount of code and making the infrastructure more complex. However, the real reason under the hood for that is that you are putting your knowledge about infrastructure to the tests. You are describing how things should work together.

IaC Testing Pyramid

IaC Testing: Static Analysis

You can create the whole infrastructure from scratch for each commit, but, usually, there are some obstacles:

Hopefully, there are some tricks. You should have a lot of simple, rapid, primitive tests in your foundation.

Bash is tricky

Let us take a look at an extremely simple example. I would like to create a backup script:

Pretty good. However, what if the filename contains space? We are clever guys, we use quotes:

Are we finished? Nope! What if the directory is empty? Globing fails in this case.

Have we finished? Not yet… We forgot that filename might contain \n character.

Static analysis tools

You can catch some issues from the previous example via Shellcheck. There are a lot of tools like that, they are called linters and you can find out the most suitable for your IDE, stack and environment.

IaC Testing: Unit Tests

As you can see linters can not catch everything, they can only predict. If we continue to think about parallels between software development and Infrastructure as Code we should mention unit tests. There are a lot of unit tests systems like shunit, JUnit, RSpec, pytest. But have you ever heard about unit tests for Ansible, Chef, Saltstack, CFengine?

When we were talking about S.O.L.I.D. for CFM, I mentioned that our infrastructure should be made from simple bricks/modules. Now the time has come:

IaC Testing: Unit Testing tools

What is the test for CFM and your infrastructure? i.e. you can just run a script or you can use production-ready solution like:

What is the best solution? There is no single answer for that question, however, I created the heat map and compared changes in this projects during 2018-2019:

IaC Testing frameworks

After that, you can face a question how to run it all together? On the one hand, you can do everything on your own if you have enough great engineers, but on the other hand, you can use opensource production-ready solutions:

I created the heat map and compared changes in this projects during 2018-2019:

Molecule vs. Testkitchen

It took 40-70 minutes for 25-35 Ansible roles. It was too long for us.

The next step was use Jenkins / docker / Ansible / molecule. It is approximately the same idea:

Linting for 40 roles and testing for ten of them took about 15 minutes.

What is the best solution? On the one hand, I do not want to be the final authority, but on the other hand, I would like to share my point of view. There is no silver bullet exists, however, in case of Ansible molecule is a more suitable solution then testkitchen.

IaC Testing: Integration Tests

On the next level of IaC testing pyramid, there are integration tests. Integration tests for infrastructure look like unit tests:

In other words, during unit tests, we check one simple module(i.e. Ansible role, python script, Ansible module, etc) of an infrastructure, but in the case of integration tests, we check the whole server configuration.

IaC Testing: End to End Tests

On top of the IaC testing pyramid, there are End to End Tests. In this case, we do not check dedicated server, script, module of our infrastructure; We check the whole infrastructure together works properly. Unfortunately, there is no out of the box solution for that or I have not heard about them(please, flag me if you know about them). Usually, people reinvent the wheel, because, there is demand on end to end tests for infrastructure. So, I would like to share my experience, hope it will be useful for somebody.

First of all, I would like to describe the context. It is an out of box enterprise solution, it supports different databases, application servers and integration interfaces with third-party systems. Usually, our clients are an immense enterprise with a completely different environment. We have knowledge about different environments combinations and we store it as different docker-compose files. Also, there matching between docker-compose files and tests, we store it as Jenkins jobs.

This scheme had been working quiet log period of time when during openshift research we tried to migrate it into Openshift. We used approximately the same containers (hell D.R.Y. again) and change the surrounding environment only.

We continue to research and found APB (Ansible Playbook Bundle). The main idea is that you pack all needed things into a container and run the container inside Openshift. It means that you have a reproducible and testable solution.

Everything was fine until we faced one more issue: we had to maintain heterogeneous infrastructure for testing environments. As a result, we store our knowledge of how to create infrastructure and run tests in the Jenkins jobs.

Conclusion

Infrastructure as Code it is a combination of:

Источник

Infrastructure as Code Explained

Introduction

Cloud computing provides on-demand computing resources, which are decoupled from physical hardware and necessary underlying configuration. Autonomous software systems provision these computing resources in the cloud to achieve the automation that cloud computing offers. Because of such automation, it’s possible to control and manipulate the available resources programmatically by interfacing with the cloud providers. This way, infrastructure changes (such as resource scaling) can be implemented more quickly and reliably and operated mostly without manual interaction, but still with the ability to oversee the whole process and revert changes if something does not go according to plan.

Infrastructure as Code (IaC) is the approach of automating infrastructure deployment and changes by defining the desired resource states and their mutual relationships in code. The code is written in specialized, human-readable languages of IaC tools. The actual resources in the cloud are created (or modified) when you execute the code. This then prompts the tool to interface with the cloud provider or deployment system on your behalf to apply the necessary changes, without using a cloud provider’s web interface. The code can be modified whenever needed—upon code execution the IaC tool will take care of finding the differences between the desired infrastructure in code and the actual infrastructure in the cloud, taking steps to make the actual state equal to the desired one.

For IaC to work in practice, created resources must not be manually modified afterward (an immutable infrastructure), as this creates discord between the expected infrastructure in code and the actual state in the cloud. In addition, the manually modified resources could get recreated or deleted during future code executions, and all such customization would be lost. The solution to this is to incorporate the modifications into the infrastructure code.

In this conceptual article, we’ll explore the IaC approach, its benefits, and examples of real-world implementations. We’ll also introduce Terraform, an open source IaC provisioning tool. We’ll review Terraform’s role in this approach and how it compares to other IaC tools.

Benefits of IaC

With IaC, you can quickly create as many instances of your entire infrastructure as you need, in multiple provider regions, from a single source of truth: your declarative code. This has many advantages that ensures you’re creating resources consistently without error while reducing management and manual setup time.

The main benefits of IaC are:

Within an IaC workflow you can repeatedly spin up infrastructure in a standardized fashion, which means software development and testing is a quicker process because development, staging, quality-assurance testing, and production environments are separated. You can repeat the process of writing code and testing it live by deploying the infrastructure as many times as needed. Once your written infrastructure fulfills all requirements, you can deploy it in desired cloud environments. When new requirements arise, you can reiterate the process.

IaC, being based on code, should always be coupled with version control software (VCS), such as Git. Storing your infrastructure declarations in VCS makes it easily retrievable, with changes visible to everyone on your team, and provides snapshots at historical points, so you can always roll back to an earlier version if new modifications create errors. Advanced VCS can be configured to automatically trigger the IaC tool to update the infrastructure in the cloud when an approved change is added.

You now know what the IaC approach is, and what benefits it brings. You’ll now learn about states, the resource tracking mechanism employed in IaC. Then, you’ll follow up with the role of Terraform and other tools using IaC.

What is ‘state’?

In an IaC environment, the term ‘state’ refers to the state of affairs of desired infrastructure resources in a deployment. There are at least three states at a given moment: the actual one in the cloud, the ideal state presented in code, and the cached state that the IaC tool maintains. The cached state describes the state in the cloud as it was when the code was last executed. Terraform allows you to deploy the same code multiple times, forming multiple states for each deployment.

The actual state in the cloud (of the managed resources) should always be the same as the cached state of the tool. When executing the code, the tool will compare the ideal state with the cached one and apply the detected differences to the cloud. If the cached and actual states do not match, it’s highly likely that the execution will fail or that resources will be incorrectly provisioned.

Role of Terraform in IaC

Terraform works by reading the code describing your infrastructure and generating a graph containing all resources with their mutual relationships. It then compares it to the cached state of the resources in the cloud, and prepares an execution plan that details what will be applied to the cloud, and in what order, to reach the desired state.

The two main types of underlying components in Terraform are providers and provisioners. Providers are responsible for interacting with a given cloud provider, creating, managing, and deleting resources, while provisioners are used to execute specific actions on created remote resources or the local machine the code is executing on.

Terraform supports managing basic cloud provider components, such as compute instances, load balancers, storage, and DNS records, though more providers and provisioners can be added, owing to its extensible nature.

In IaC Terraform’s role is to ensure that the state of resources in the cloud is equal to the state expressed in code. It does not monitor the deployed resources, and its main focus is not on further bootstrapping of the provisioned compute instances with software and tasks. In the next section, you’ll learn how it compares to other tools and how they extend each other in a typical workflow.

Tools Using IaC

The IaC approach is widespread in modern deployment, configuration management, virtualization, and orchestration software. Docker and Kubernetes, the leading tools used for container creation and orchestration, both use YAML as their language for declaring the desired end result. On the other hand, Hashicorp Packer, a tool for creating snapshots of deployments, uses JSON to declare the template and variables from which a snapshot of the system will be built.

Ansible, Chef, and Puppet, the three most popular configuration management tools, all use the IaC approach to define the desired state of the servers they manage.

Ansible bootstraps provided servers according to a given playbook. A playbook is a textual file written in appropriate YAML, instructing Ansible what operations to perform on the existing target resources. Examples of such operations include running and starting services, installing packages using the system-provided package manager, or executing custom bash commands. To learn more about writing Ansible playbooks, read Configuration Managment 101: Writing Ansible Playbooks.

Chef and Puppet both require central servers with agents installed on each of the managed ones. Unlike Ansible, Chef uses Ruby, and Puppet uses its own declarative language for describing the resources.

Terraform is not mutually exclusive with other IaC tools and DevOps systems. Its strength is in provisioning hardware resources, rather than further software installation and initial server setup.

Unlike configuration management tools such as Ansible and Chef, Terraform is not suitable for installing software on the target resources and setting up tasks. Instead Terraform offers providers for interacting with their supported resources.

Terraform can work from a single machine and does not require central servers with client agents installed on the provisioned resources, unlike some other tools. It does not check their actual state and reapplies the configuration automatically, because its main focus is on provisioning them. A typical workflow is to provision the infrastructure resources using Terraform and then bootstrap them using a configuration management tool, if needed.

For Chef, Terraform has a built-in provisioner that sets up its client agent on provisioned remote resources. With it you can automatically have all your provisioned servers added to the main server, from where you can additionally configure them using cookbooks, Chef’s infrastructure declarations. You can learn more about writing them in Configuration Management 101: Writing Chef Recipes.

Conclusion

This article covered the paradigms of the IaC approach, its advantages over traditional manual system administration, the basics of Terraform as an IaC resource provisioning tool, and how it compares to other popular infrastructure automation tools.

If you’re looking to incorporate Infrastructure as Code into your workflow, check out our Terraform series to learn the fundamentals of using this tool in your development and deployment process.

One way to start with Terraform is to read How To Structure Your Terraform Project to understand how to ensure your infrastructure stays scalable and extensible.

Want to learn more? Join the DigitalOcean Community!

Join our DigitalOcean community of over a million developers for free! Get help and share knowledge in our Questions & Answers section, find tutorials and tools that will help you grow as a developer and scale your project or business, and subscribe to topics of interest.

Tutorial Series: How To Manage Infrastructure with Terraform

Terraform is a popular open source Infrastructure as Code (IAC) tool that automates provisioning of your infrastructure in the cloud and manages the full lifecycle of all deployed resources, which are defined in source code. Its resource-managing behavior is predictable and reproducible, so you can plan the actions in advance and reuse your code configurations for similar infrastructure.

In this series, you will build out examples of Terraform projects to gain an understanding of the IAC approach and how it’s applied in practice to facilitate creating and deploying reusable and scalable infrastructure architectures.

Источник

Infrastructure as Code: как побороть проблемы с помощью XP

Привет, Хабр! Раньше я жаловался на жизнь в парадигме Infrastructure as code и ничего не предлагал для решения сложившейся ситуации. Сегодня я вернулся, чтобы рассказать, какие подходы и практики помогут вырваться из бездны отчаяния и вырулить ситуацию в правильное русло.

Серия статей про Infrastructure as code и наш опыт в SRE:
1. Infrastructure as Code: первое знакомство.
2. Infrastructure as Code: как побороть проблемы с помощью XP. (You are here).
3. Путь разработчика в SRE: зачем идти в инфраструктуру и что из этого выйдет.

В предыдущей статье «Infrastructure as code: первое знакомство» я делился своим впечатлением от этой сферы, пытался размышлять о текущей ситуации в этой области и даже предположил, что стандартные, известные всем разработчикам практики, могут помочь. Могло показаться, что там было много жалоб на жизнь, но не было предложений по выходу из сложившейся ситуации.

Кто мы, где мы и какие у нас проблемы

Сейчас мы находимся в Sre Onboarding Team, которая состоит из шести программистов и трёх инженеров инфраструктуры. Все мы пытаемся писать Infrastructure as code (IaC). Делаем мы это, потому что в принципе умеем писать код и в анамнезе являемся разработчиками уровня «выше среднего».

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

Сейчас мы боремся с такими проблемами IaC:

Экстремальное программирование (XP) спешит на помощь

Всем разработчикам хорошо знакомо экстремальное программирование (XP) и те практики, которые за ним стоят. Многие из нас работали по такому подходу, и он был удачен. Так почему бы не воспользоваться принципами и практиками, заложенными там, чтобы побороть трудности инфраструктуры? Мы решили применить этот подход и посмотреть, что из этого выйдет.

Привожу описание среды, для которой хорошо подходит XP, и как это соотносится с нами:

1. Dynamically changing software requirements. Нам было понятно, какова конечная цель. Но в деталях можно варьировать. Мы сами решаем, куда нам надо вырулить, поэтому требования периодически меняются (в основном нами же самими). Если брать команду SRE, которая сама делает автоматизацию, и сама же ограничивает требования и scope работ, то этот пункт ложится хорошо.

2. Risks caused by fixed time projects using new technology. У нас могут возникнуть риски при использовании каких-то неизвестных нам вещей. И это 100% наш случай. Весь наш проект – это использование технологий, с которыми мы не были до конца знакомы. Вообще, это постоянная проблема, т.к. в сфере инфраструктуры постоянно появляется множество новых технологий.

3,4. Small, co-located extended development team. The technology you are using allows for automated unit and functional tests. Эти два пункта не совсем нам подходят. Во-первых, мы не колоцированная команда, во-вторых, нас девять человек, что может считаться большой командой. Хотя, по ряду определений «большой» команды, много – это 14+ человек.

Рассмотрим некоторые практики из XP и то, как они влияют на скорость и качество обратной связи.

Принцип цикла обратной связи в XP

В моём понимании обратная связь – это ответ на вопрос, правильно ли я делаю, туда ли мы идём? В ХР на этот счёт есть божественная схемка: цикл обратной связи по времени. Интересность заключается в том, что чем ниже мы находимся, тем мы быстрее имеем возможность получить ОС, чтобы ответить на необходимые вопросы.

Это довольно интересная тема для обсуждения, что у нас в IT индустрии возможно быстро получить ОС. Представьте, как больно сложно делать какой-нибудь проект полгода и только потом узнать, что в самом начале была заложена ошибка. Такое бывает и в проектировании, и в любом построении сложных систем.

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

Важно: обратная связь может стать решением для всех заявленных выше проблем. В совокупности с практиками XP, она может вытащить из бездны отчаяния.

Как вытащить себя из бездны отчаяния: три практики

Тесты

Тесты упоминаются дважды в цикле обратной связи XP. Это не просто так. Они крайне важны для всей техники экстремального программирования.

Предполагается, что у тебя есть Unit и Acceptance tests. Одни дают тебе фидбек за сколько-то минут, другие за сколько-то дней, потому они пишутся дольше, а прогоняются реже.

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

Как это схема применима к нам в проекте IaC? На самом деле… никак.

Вот так выглядят интеграционные тесты.

Это пример при сборке образов в Drone CI. Чтобы до них дойти, надо 30 минут ждать, пока соберётся имидж Packer, потом ещё минут 15 ждать, пока они пройдут. Но они есть!

Обратная связь на пайплайне в районе 40 минут. Всё происходит очень долго. Можно использовать для регресса, но для новой разработки вообще нереально. Если очень-очень к этому подготовиться, подготовить running, скрипты, то можно сократить до 10 минут. Но это всё равно не Unit-тесты, которые за 5 секунд 100 штук.

Отсутствие Unit-тестов при сборке образов или модулей терраформа сподвигает перекладывать работу на отдельные сервисы, которые просто можно дёрнуть по REST, или на Python-скрипты.

Например, нам нужно было сделать так, чтобы при старте виртуальной машины она регистрировала себя в сервисе ScaleFT, а при уничтожении виртуалки удаляла себя.

Так как ScaleFT у нас как сервис, мы вынуждены работать с ним через API. Tам была написана обёртка, которую можно дёрнуть и сказать: «Зайди и удали то-то, то-то». Она хранит все необходимые настройки и доступы.

На это уже можем писать нормальные тесты, так как это никак не отличается от обычного софта: мокается какая-то апиха, ты дёргаешь, и смотрим, что происходит.

Итоги по тестам: Unit-тестирование, которое должно давать ОС за минуту, не даёт его. А более высокие по пирамиде виды тестирования дают эффект, но закрывают лишь часть проблем.

Парное программирование

Тесты – это, конечно, хорошо. Их можно писать много, они могут быть разных видов. Они будут работать на своих уровнях и давать нам обратную связь. Но проблема с плохими Unit-тестами, которые дают самую быструю ОС, остаётся. При этом продолжает хотеться быстрой ОС, с ней легко и приятно работать. Не говоря уже о качестве получаемого решения. К счастью, есть техники, позволяющие дать ещё более быстрый feedback, чем модульные тесты. Это парное программирование.

При написании кода хочется получить обратную связь о его качестве как можно быстрее. Да, можно написать всё в фича-ветке (чтобы не поломать ничего никому), сделать pull request в гитхабе, назначить на кого-то, чьё мнение имеет вес, и ждать ответа.

Но ждать можно долго. Люди все занятые, а ответ, даже если и будет, может быть не самым высоким по качеству. Предположим, что ответ пришёл сразу, ревьювер моментально понял весь замысел, но ответ всё равно приходит с запозданием, постфактум. А хочется-то раньше. Вот парное программирование и нацелено на это – чтобы сразу, в момент написания.

Далее привожу стили парного программирования и их применимость в работе над IaC:

1. Classic, Опытный+опытный, смена по таймеру. Две роли – driver and navigator. Два человека. Они работают над одним кодом и меняются ролями через определенный заранее обозначенный промежуток времени.

Рассмотрим сочетаемость наших проблем со стилем:

Вывод: в чистом виде нам не подходит.

2. Ping-pong. Это подход предполагает, что один участник пишет тест, а другой делает для него реализацию. С учетом того, что с Unit-тестами всё сложно, и приходится писать долгий по времени программирования интеграционный тест, вся легкость ping-pong’а уходит.

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

Вывод: увы, темп работы не позволяет использовать ping-pong, как практику парного программирования в IaC.

3. Strong Style. Сложная практика. Идея в том, что один участник становится директивным навигатором, а второй берёт роль исполняющего драйвера. При этом право решений исключительно за навигатором. Драйвер лишь печатает и словом может повлиять на происходящее. Роли не меняются долгое время.

Хорошо подходит для обучения, но требует сильных soft skills. На этом мы и запнулись. Техника шла сложно. И дело тут даже не в инфраструктуре.

Вывод: потенциально может применяться, мы не оставляем попытки.

4. Mobbing, swarming и все известные, но не перечисленные тут стили не рассматриваем, т.к. не пробовали и сказать про это в контексте нашей работы не получится.

Общие итоги по использованию pair programming:

5. Несмотря на это, были и успехи. Мы придумали собственный метод «Схождение – расхождение». Кратенько опишу, как он работает.

У нас есть постоянные партнеры на несколько дней (меньше недели). Мы делаем одну задачу вместе. Какое-то время мы сидим вместе: один пишет, второй сидит и наблюдает, как саппорт тим. Потом мы расходимся на какое-то время, каждый делает какие-то независимые вещи, потом опять сходимся, синхронизируемся очень быстро, делаем что-то вместе и опять расходимся.

Планирование и общение

Последний блок практик, через которые решаются проблемы ОС – это организация работ с самими задачами. Сюда же входит и обмен опытом, который находится вне парной работы. Рассмотрим три практики:

1. Задачи через дерево целей. Общее ведение проекта мы организовали через дерево, бесконечно уходящее в будущее. Технически ведение делается в Miro. Есть одна задача – она промежуточная цель. От неё идут либо более мелкие цели, либо группы задач. От них уже сами задачи. Все задачи создаются и ведутся на этой доске.

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

Преимущества визуального видения задач:

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

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

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

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

1. Введите в контекст. Откуда взялась задача, зачем это вообще было нужно?

2. Как решалась задача до этого? Например, требовалось массовое мышекликанье, или же вообще было невозможно что-то сделать.

3. Как мы улучшаем это. Например: «Смотрите, теперь есть скриптосик, вот ридми».

4. Покажите, как это работает. Желательно прямо осуществить какой-либо сценарий пользователя. Хочу X, делаю Y, вижу Й (или Z). Например, деплою NGINX, курлю url, получаю 200 OK. Если действие долгое, подготовьте заранее, чтобы потом показать. Желательно за час до демо уже не разламывать особо, если хрупкое.

5. Объясните, насколько удачно решена проблема, какие трудности остались, что не доделано, какие усовершенствования возможны в дальнейшем. Например, сейчас cli, потом будет полная автоматика в CI.

Желательно каждому спикеру уложиться в 5-10 минут. Если ваше выступление заведомо важное и займет больше времени, заранее согласуйте это в канале sre-takeover.

После очной части обязательно идет обсуждение в треде. Вот тут-то и появляется та необходимая нам обратная связь по своим задачам.

По итогу проводится опрос для выявления полезности происходящего. Это уже обратная связь по сути выступления и важности задачи.

Длинные выводы и что дальше

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

Тесты, в текущем их виде, дают лишь частичное покрытие кода. Много функций конфигурации оказываются не протестированными. Влияние их на непосредственную работу при написании кода низкое. Однако эффект от интеграционных тестов есть, и именно они позволяют безбоязненно проводить рефакторинги. Это большое достижение. Также с переносом фокуса на разработку в высокоуровневых языках (у нас python, go) проблема уходит. А на «клей» много проверок и не надо, достаточно общей интеграционной.

Работа в паре больше зависит от конкретных людей. Есть фактор задачи и наши soft skills. С кем-то получается очень хорошо, с кем-то хуже. Польза от этого точно есть. Ясно, что даже при недостаточном соблюдении правил парной работы, сам факт совместного выполнения задач положительно влияет на качество результата. Лично мне в паре работается проще и приятнее.

Более высокоуровневые способы влияние на ОС – планирование и работа с задачами точно дают эффекты: качественный обмен знаний и улучшение качества разработки.

Источник

Infrastructure as code

How infrastructure as code (IaC) manages complex infrastructures

Ian Buchanan

Principal Solutions Engineer

Infrastructure as code (IaC) is an IT infrastructure management process that applies best practices from DevOps software development to the management of cloud infrastructure resources.

The rise of hardware virtualization in the mid-2000s spawned new opportunities of cloud infrastructure hosting. Cloud hosting providers began offering access to dynamic infrastructure as a service (IaaS) platforms. As these platforms grew and began offering more complex infrastructure assets, the complexity of a traditional systems administration role also grew. The need to rapidly configure and manage complex cloud infrastructures quickly became a challenge.

The idea of infrastructure as code (IaC), or modeling infrastructure with code, was spurred on by the success of CI/CD. DevOps proved how productive it was to commit code to a Git repository and then apply feature branches and pull request workflows. The automation these workflows brought to software development helped reduce the new complexity of cloud systems administration.

What is infrastructure as code?

Infrastructure as code is an IT infrastructure management process that applies best practices from DevOps software development to the management of cloud infrastructure resources. Applicable infrastructure resources are virtual machines, networks, load balancers, databases, and other networked applications.

IaC is a form of configuration management that codifies an organization’s infrastructure resources into text files. These infrastructure files are then committed to a version control system like Git. The version control repository enables feature branch and pull request workflows, which are foundational dependencies of CI/CD.

Infrastructure as code is made possible by the rise of cloud infrastructure hosting platforms, specifically IaaS platforms. IaaS allows on-demand provisioning and requisition of cloud resources through remote APIs, which set the template for properties committed to the infrastructure configuration files. IaC’s automation features can take the configuration files and run them against the remote IaaS APIs.

Once a team has committed infrastructure configuration to version control, they can apply CI/CD practices to infrastructure changes. Infrastructure updates can follow a DevOps workflow. If a team member has edited one of the configuration text files, pull requests and code review workflows can be used to audit and verify the correctness of the edits. Furthermore, a DevOps-enabled infrastructure as code system will utilize automatic infrastructure deployments and rollbacks.

related material

Infrastructure as a Service

SEE SOLUTION

Manage your components with Compass

Why is infrastructure as code important?

IaC evolved to help solve the problem of “environment drift”. Cloud applications usually have separate deployment environments for the stages of their release lifecycle. It’s common to have development, staging, and production environments. These environments are composed of networked resources like application servers, load balancers, and databases. Environment drift occurs when the infrastructure between these different environments falls out of sync.

Without IaC, infrastructure management can be a disorganized and fragile process. System administrators manually connect to remote cloud providers and use API or web dashboards to provision new hardware and resources. This manual workflow does not give a holistic view of the application infrastructure. Administrators may manually make changes to one environment and forget to follow through on the other. This is how environment drift happens.

Environment drift becomes an expensive business waste. Bugs and failures happen because teams build against a staging or development environment and then find upon deployment that the production environment is out of sync, which leads to a time-consuming investigation of why and what is missing.

Without IaC, manual infrastructure management is a slow process. If a required infrastructure change is identified due to environment drift, spikes in traffic, or some other issue, it can take an unknown amount of time for a systems administrator to react and adapt. This leads to outages and customer frustration. With IaC in place, infrastructure can automatically adapt to changes in configuration and react to spikes in traffic with auto-scaling features.

Infrastructure as code brings more oversight and visibility to manual systems administration. With the infrastructure configuration files committed to a central version control repository, all team members can view and edit infrastructure data. This enables powerful auditing capabilities. For example, if your team undergoes a PCI compliance audit, you’ll need to know if a specific part of your infrastructure is using SSL encryption. With IaC you can quickly see how SSL is configured and execute the code to make sure the live infrastructure matches the configuration files, which identifies if SSL is enabled. The version control commit history also acts as a log to review when it was added or removed.

How does infrastructure as code work?

There are a few dependencies that need to be in place to fully achieve infrastructure as code.

Remote accessible hosting or IaaS cloud hosting platform

The first and foremost dependency is remote accessible hosting. The configuration management tool needs to connect to and modify the remote host. If the remote infrastructure is self-managed your team needs to ensure the configuration management tool has access. The IaaS-enabled cloud hosting platform offers APIs that allow users to automatically create, delete, and modify infrastructure resources on demand. These APIs can also be accessed by configuration management tools to further automate these tasks. Some examples of popular IaaS platforms are Digital Ocean, Amazon AWS, and Microsoft Azure.

Configuration management platform

The next requirement to complete IaC is a tools suite that connects to the IaaS APIs and automates common tasks. A team can create a set of scripts and tools. However it would be a lot of work, future maintenance, and probably have a low return on investment. There are already many open source configuration management platforms that solve this problem, including Terraform, Ansible, Salt Stack, and Chef.

Version control system

A configuration management platform uses human and machine-readable text files written in a markup language like YAML to declare tasks and sequences for the platform to execute. These text files can be treated like application code files and stored in a version control system repository. The repository acts as a central source of truth and enables pull requests and code review. The most popular version control system is Git.

With these dependencies in place, let’s consider an example scenario in which a developer wants to add a new application service to a system. This scenario helps demonstrate an IaC workflow

In conclusion.

IaC is a highly productive form of configuration management that focuses on automating cloud IT infrastructure management. Once IaC is in place it can be used to achieve levels of CI/CD automation for changes to a project’s infrastructure. IaC enables many beneficial insights into communication and transparency around infrastructure changes. IaC requires a set of dependencies like hosting platforms and automation tools, that are widely available from modern hosting companies.

Источник

Применение инструментов IaC в облаке

Привет, Хабр! Я Алексей Волков, менеджер продукта компании VK Cloud Solutions. Хочу рассказать о подходе IaC (Infrastructure as Code, инфраструктура как код), который позволяет управлять сетями, виртуальными машинами, подсистемами балансировки нагрузки и другими элементами инфраструктуры как кодом с помощью описательной модели. Поговорим о современных принципах управления инфраструктурой, инструментах IaC в облаке и вариантах построения CI/CD-пайплайна.

Традиционный процесс администрирования vs IaC

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

При традиционном подходе:

При IaC-подходе алгоритм отличается:

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

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

На практике для реализации IaC-подхода к администрированию используют разные инструменты. Рассмотрим Packer и Terraform от компании HashiCorp.

Packer

Packer — инструмент для создания одинаковых образов ОС для различных платформ из одного описания. Образ, создаваемый Packer, включает в себя настроенную операционную систему (ОС) и набор программного обеспечения (ПО). Packer умеет создавать образы AMI для EC2, VMDK/VMX-файлы для VMware, OVF для VirtualBox и другие.

Packer не зависит от облачной инфраструктуры — он поддерживает несколько бэкендов и может работать с разными провайдерами «из коробки».

Алгоритм работы с Packer следующий:

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

Пример использования Packer

Покажу на примере. Возьмем директорию Nginx, она вложена в директорию Packer на GitHub:

Далее соберем базовый образ с Nginx. Для этого:

Приступаем к сборке образа:

1. Для примера я создал на GitHub директорию Packer. В ней лежит директория Nginx и файл nginx.pkr.hcl.

2. Файл nginx.pkr.hcl содержит конфигурацию для Packer, эта информация нужна, чтобы Packer понимал, в каком бэкенде и как нужно запустить виртуальную машину.

3. В конфиге через source «openstack» и source_image_filter указываем, какой базовый образ использовать для создания нового. В данном случае — Centos-7.9-202107, который находится в публичном доступе в облаке VK Cloud Solutions.

4. Через flavor указываем размер виртуальной машины, например: 1 ядро, 1 ГБ оперативной памяти, 10 ГБ диска. Эти параметры касаются только базовой виртуальной машины, с которой снимается образ. Из нового образа можно будет запускать ВМ любого размера.

5. Здесь же указываем параметры подключения к ВМ по SSH и другие настройки. Доступ по SSH нужен, чтобы Packer мог запустить в облаке ВМ и получить доступ к Ansible, который подключается к ВМ и выполняет нужные действия. Только после этого создается снапшот виртуальной машины.

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

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

10. В файле конфига default.conf просим Nginx при обращении к корню возвращать «200» и свой hostname. Это поможет понять, как работают инстансы и выполняется балансировка.

Это вся конфигурация, которая нужна для запуска Packer. Перед этим важно соблюсти два условия:

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

Terraform

Terraform — инструмент от компании Hashicorp, который позволяет декларативно управлять инстансами, сетями, группами безопасности и другими компонентами инфраструктуры с помощью файлов конфигураций. Благодаря Terraform можно привести инфраструктуру к нужному состоянию декларативно, сразу указав нужные параметры системы.

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

Конфигурация Terraform

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

Как правило, описание конфигурации содержит:

1. Файл с описанием провайдеров. Terraform может работать с разными облаками, поэтому в файле описываем параметры провайдера — название и версию. Подробнее про настройку Terraform-провайдера для VK Cloud Solutions можно посмотреть здесь.

2. Файл с данными для подключения к облаку. Инструменту надо передать API endpoints, ключи и другие персональные идентификаторы.

3. Файл с описанием конфигурации виртуальных машин. Terraform работает с двумя типами объектов: Data и Resource. Data — то, что можно получить из облака. Например, конфигурация дефолтной сети облака. А Resource — то, что создаем сами.

Также описываем и другие параметры.

5. Файл с ключами доступа. В нем прописываем, что Terraform сам автоматически генерирует SSH-ключ: приватную часть после запуска сохранит локально, а публичную часть положит в облако. Впоследствии публичный ключ будет доставлен во все новые ВМ.

Ресурс tls_private_key.ssh.private_key_pem содержит приватный ключ. В выводе он помечен как sensitive = true и будет маскирован. Используем следующую команду для сохранения приватного ключа:

6. Файл с конфигурацией load balancer. Балансировщик нагрузки нужен, если планируется запускать несколько виртуальных машин. Для подготовки в файле создаем Load Balancer и внешний Listener, добавляем в балансировщик виртуальные машины и определяем правила проверки. При правильной настройке балансировщика Terraform обеспечивает Zero Downtime Deployment с плавной для пользователей сменой версии приложения.

В итоге IaC-инструменты сводят всю подготовку инфраструктуры к простым действиям:

Обновленный CI/CD-пайплайн

C помощью Packer и Terraform можно реализовать все принципы Docker с неизменяемой инфраструктурой и Kubernetes с выкатыванием новых версий через перезапуск.

Связка инструментов отлично работает с инфраструктурой на виртуальных машинах в облаке и сохраняет привычный алгоритм:

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

Источник

Infrastructure as Code (IaC): The Complete Beginner’s Guide

Infrastructure is one of the core tenets of a software development process—it is directly responsible for the stable operation of a software application. This infrastructure can range from servers, load balancers, firewalls, and databases all the way to complex container clusters.

Infrastructure considerations are valid beyond production environments, as they spread across the complete development process. They include tools and platforms such as CI/CD platforms, staging environments, and testing tools. These infrastructure considerations increase as the level of complexity of the software product increases. Very quickly, the traditional approach for manually managing infrastructure becomes an unscalable solution to meet the demands of DevOps-based modern rapid software development cycles.

And that’s how Infrastructure as Code (IaC) has become the de facto solution in development today. IaC allows you to meet the growing needs of infrastructure changes in a scalable and trackable manner.

What is infrastructure as code?

Infrastructure as Code or IaC is the process of provisioning and managing infrastructure defined through code, instead of doing so with a manual process.

As infrastructure is defined as code, it allows users to easily edit and distribute configurations while ensuring the desired state of the infrastructure. This means you can create reproducible infrastructure configurations.

Moreover, defining infrastructure as code also:

Declarative vs imperative Infrastructure as Code

When dealing with IaC tools, there are two major differentiating approaches for writing code. These two approaches are declarative and imperative. Simply put:

The declarative approach is preferred in most infrastructure management use cases as it offers a greater degree of flexibility when managing infrastructure.

Chef is considered an imperative tool, where Terraform, Pulumi, CloudFormation, ART, Puppet are all declarative. Uniquely, Ansible is mostly declarative with support for imperative commands.

IaC vs IaaS

Importantly, IaC is not a derivative of infrastructure as a service (IaaS). They are two different concepts.

When & how to use Infrastructure as Code

IaC may seem unnecessary for simpler, less complex infrastructure requirements, but that isn’t accurate. Any—every—modern software development pipeline should use infrastructure as Code to handle the infrastructure.

Besides, the advantages of IaC far outweigh any implementation and management overheads.

Advantages of IaC

Here are the top benefits of IaC:

When to use IaC

Not sure when to use IaC? The simplest answer is whenever you have to manage any type of infrastructure.

However, it becomes more complex with the exact requirements and tools. Some may require strict infrastructure management, while others may require both infrastructure and configuration management. Then comes platform-specific questions like if the tool has the necessary feature set, security implication, integrations, etc. On top of that, the learning curve comes into play as users prefer a simpler and more straightforward tool than a complex one.

The below table shows a categorization of the tools mentioned above according to their ideal use cases.

One tool may not be sufficient in most scenarios. For instance, Terraform may be excellent for managing infrastructure across multiple cloud environments yet may be limited when in-depth configurations are required. In those kinds of situations, users can utilize a tool such as Ansible to carry out the necessary configurations.

Likewise, users can mix and match any IaC tool and use them in their CI/CD pipelines depending on the exact requirements.

Infrastructure as Code tools & platforms

Under the big IaC umbrella, there are all sorts of tools, from dedicated infrastructure management tools to configuration management, from open-source tools to platform-specific IaC options.

Let’s look at some of the most popular IaC tools and platforms.

Terraform

Terraform by HashiCorp is the leading IaC tool specialized in managing infrastructure across various platforms from AWS, Azure, GCP to Oracle Cloud, Alibaba Cloud, and even platforms like Kubernetes and Heroku.

As a platform-agnostic tool, Terraform can be used to facilitate any infrastructure provisioning and management use cases across different platforms and providers while ensuring the desired state across the configurations.

Ansible

Ansible is not a dedicated Infrastructure management tool but more of an open-source configuration management tool with IaC capabilities. Ansible supports both cloud and on-prem environments and can act through SSH or WinRM as an agentless tool. Ansible excels at configuration management and infrastructure provisioning yet is limited when it comes to managing said infrastructure.

Pulumi

Pulumi is a relatively new tool that aims to provide a developer-first IaC experience. Unlike other tools that force users to use a specific language or format, Pulumi offers freedom to use any supported programming language any way they like.

This tool supports Python, TypeScript, JavaScript, Go, C#, F#, and the state is managed through Pulumi service by default.

Chef/Puppet

Chef and Puppet are two powerful configuration management tools. Both aim to provide configuration management and automation capabilities with some infrastructure management capabilities across the development pipeline.

CFEngine

CFEngine is one of the most mature tools solely focused on configuration management. Even though there is no capability to manage the underlying infrastructure, CDEngine can accommodate even the most complex configuration requirements, covering everything from security hardening to compliance.

AWS CloudFormation

CloudFormation is the AWS proprietary platform specific IaC tool to manage AWS infrastructure. CloudFormation has deep integration with all AWS services and can facilitate any AWS configuration as a first-party solution.

Azure Resource Templates

Microsoft Azure uses JSON-based Azure Resource Templates to facilitate IaC practices within the Azure platform. These resource templates ensure consistency of the infrastructure and can be used for any type of resource configuration.

In addition to the above, there are specialized tools aimed at specific infrastructure and configuration management tasks such as:

Examples of Infrastructure as Code

Let’s consider a simple scenario of provisioning an AWS EC2 Instance. In the following example, we can see how Terraform, Ansible, and AWS CloudFormation codes are used for this requirement.

Terraform

Ansible

AWS CloudFormation

A real world example: IaC for DevOps

Within the context of software development, a fundamental constraint is the need for the environment where recently developed software code is tested to exactly mirror the live environment where such code will be deployed to. This is the only way of assuring that the new code will not collide with existing code definitions: by generating errors or conflicts that may compromise the entire system.

In the past, software delivery would follow this sort of pattern:

Manual recreation of a live environment leaves doors open to a multitude of most likely minor but potentially quite important human errors, regarding:

A live environment clone, created using the exact same IaC as the live environment, has the absolute guarantee that that if it works in the cloned environment it will work in live.

Imagine a software delivery process involving separate environments for DEV, UAT, and Production. There’s seemingly little value in having a DEV and UAT environment that isn’t an exact mirror of the prod environment given that those early environments are critical to measuring the quality and production readiness of a software build version.

The introduction of virtualization enabled this process to be expedited, especially regarding the phase of creating and updating a test server that would mirror the live environment. Yet the process was manual, meaning a human would have to create and update the machine accordingly and in a timely fashion. With the introduction of DevOps, these process became even more “agile”. Adding automation to the server virtualization and testing phases replaces human intervention, improving productivity and efficiency.

To summarize: In the past, several man-hours and human resources were required to complete the software deployment cycle (Developers, Systems Administrators, Database Administrators, Operation testers). Now, it is possible to have the developer alone complete all tasks:

Quick, trackable infrastructure changes

Infrastructure as Code has become a vital part of modern application development and deployment pipelines. It is achieved by facilitating quick and trackable infrastructure changes that directly integrate into CI/CD platforms. Infrastructure as Code is crucial for both:

Getting started with Infrastructure as Code may seem daunting with many different tools and platforms targeted at different use cases. However, cross this hurdle, and you will have a powerful infrastructure management mechanism at your fingertips.

Related reading

Free Download: Enterprise DevOps Skills Report

Human skills like collaboration and creativity are just as vital for DevOps success as technical expertise. This DevOps Institute report explores current upskilling trends, best practices, and business impact as organizations around the world make upskilling a top priority.

These postings are my own and do not necessarily represent BMC’s position, strategies, or opinion.

See an error or have a suggestion? Please let us know by emailing blogs@bmc.com.

BMC Brings the A-Game

BMC works with 86% of the Forbes Global 50 and customers and partners around the world to create their future. With our history of innovation, industry-leading automation, operations, and service management solutions, combined with unmatched flexibility, we help organizations free up time and space to become an Autonomous Digital Enterprise that conquers the opportunities ahead.
Learn more about BMC ›

Источник

Опыт построения Infrastructure-as-Code в VMware. Часть 1.1: Динамическая инвентаризация

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

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

Первым делом, что я сделал, когда обнаружил этот коммент, это побежал к нашим инфраструктурщикам с вопросом «оно мне надо, велосипед пилить?». Ребята пояснили, что Vcloud это:

Ищем нужный скрипт

На данный момент на Github в разделе contrib представлены следующие реализации динамического инвентаря: тот и этот.

На просторах интернета еще нашелся такой вариант. Я его отбросил сразу — он тупо выгребает список всех машинок (без внутренностей), работает долго, логин и пароль для соединения с варей надо хардкодить. Иными словами — здорово чтобы поиграть, но не более.

vmware.py тоже отпал, поскольку работает долго даже с кэшем (на моей машинке 30 минут без кэша, и 8 с кэшем), да и «глубина» погружения во внутренности виртуалки тоже не нравится.

Так что мой выбор пал vmware_inventory.py — он очень гибок, с кэшем работает 2 секунды и дает мне возможность группировать по параметрам машинки.

В первую очередь, большой и длинный INI файлик — конфигурация для работы с варей.

В первую очередь я рекомендую завести отдельного юзера для работы с варей. По сути нам нужен обычный пользователь, который может читать данные машинок, ресурспулов, папок и датасторов. Никаких прав на включение/выключение, создание/удаление виртуалок у него нет и не должно быть. Least privilege principle!

Повторюсь, читатель, будь осторожен обновлением кэша, а то плейбуки будут медленнее черепашки!

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

Здорово, правда? 🙂 Как я уже сказал, количество метаданных также регулируется max_object_level, так что если данных уж слишком много — опустите до 1.

Работаем со скриптом.

Пользоваться можно двумя способами: либо кладем скрипт с настройками в папку наших инвентарей, либо задаем инвентарь вручную:

Чем мне нравится модуль setup — он не требует подключения, а просто прогоняется по машинкам.
Дальше уже можно экспериментировать, причем использовать метаданные виртуалки можно и в обработке условий. Для чистоты эксперимента я буду фильтровать по ресурс пулу.
Если при запуске Ansible поругается, то необходимо удалить комментарии в начале скрипта.

Пример номер 1

В этом примере я беру несколько одноименных хостов и вывожу переменную, взятую не из Ansible facts, а именно из метаданных машины.

Пример номер 2

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

Пример номер 3

Делать подобные выкрутасы можно и в ролях.

Дорогой читатель, возможности использования метаданных ограничиваются лишь твоей фантазией!

Группируем по-своему

Здорово использовать метаданные для фильтрации в when, но это не решает проблему пробега по всем машинам — нам же хочется группировать машины на уровне скрипта. Для этого мы еще раз поиграем с настройкой groupby_patterns. К примеру, если выставить значение << resourcepool.name >> то группироваться будет по имени ресурс пула. Группировать еще можно по имени виртуальной сети (<< network.name >>) или по таге (<< tag >>)

Какой способ лучше решать уже тебе, читатель.

Источник

What is Infrastructure as Code? (Tutorial)

What is Infrastructure as Code?

In this article you will learn all about Infrastructure as Code. I will start with an overview of the general concepts, and then I will show you how to implement Infrastructure as Code with three different labs. The labs use Python and AWS but the concepts will apply to other programming languages and cloud providers.

There is also a video version of this article. You can watch the video on the freeCodeCamp.org YouTube channel (1-hour watch).

Let’s start by talking about what infrastructure as code is. To put it simply, it is setting up your infrastructure as code.

By infrastructure, I mean all the different things needed to deploy your software into a cloud environment. That can mean things like virtual machines, containers, or serverless functions.

Infrastructure also means all the other pieces of infrastructure you need to set up to make that successful. That can be security like IAM and KMS, or networking, or some of the monitoring and logging capabilities.

You can also use code to configure and set up data stores. These are the things that your application needs to store and manage data.

The last piece of the infrastructure landscape is the applications themselves and getting the applications that we’re building into the infrastructure.

All of these different pieces of infrastructure can be set up using code.

It is becoming more and more important to automate infrastructure because applications can be deployed to production up to a hundred times per day. You don’t want to have to do that manually.

Also, it is helpful to automate infrastructure to be provisioned or deprovisioned in response to load.

Infrastructures as code is is all about finding a way to describe using code what pieces of our infrastructure need to do.

Over the years there has been a transition with how people are using cloud infrastructure within their organizations.

In the first wave, it was relatively simple. The infrastructures were fairly static. It was often a single virtual machine that you just accessed through SSH.

It got a little more complex in the second wave. There were more containers and people started using provisioning tools to specify the application behaviors. People used Docker and DataDog.

Modern cloud infrastructure has added way more complexity. It uses containers, serverless, and more managed services as part of the applications. There are now way more different pieces involved in how people build the infrastructure.

Infrastructure as code is becoming a more important part of how people build and deliver applications because infrastructure as code is what what describes the glue between all the different edges on these diagrams.

Modern Infrastructure

The diagram for the modern infrastructure may look more complicated than the previous ones but it can actually be easier to maintain. A key benefit is that the dark grey squares in the diagram is the only part which is the code that you own. And that part is smaller that the previous ways of doing things. So a lot of the operational burden has been decreased compared to how it used to be done.

With infrastructure as code, you hand off some of the operational burden to AWS, Azure, Kubernetes, or some other system. Now the focus is on the glue between the different services that are being managed by a cloud provider.

Infrastructure code takes on an increasingly more important role in how you manage everything in the modern cloud.

So here are the three main ways that can be used to manage all the resources:

Infrastructure as code gives us the ability to write down what we want the desired state of our infrastructure to be. I’ll be showing you exactly how to do these things later.

Writing Infrastructure as Code

One approach to infrastructure as code is to use JSON. Here is an example:

The above is a way to tell AWS what resources you want to have.

Another method is to use a domain specific language (DSL). This is a custom method specific to the tool or cloud provider you are using. Here is an example:

Here is an example using TypeScript (and later we’ll be using Python).

Using code gives the ability to do things that are not possible in some of the other methods. In the example above, there is a for loop that creates in Instance for each Availability Zone. Code gives the ability to use loops, conditionals, classes, packages, and more. Using popular programming languages also allows the use common IDEs, linters, and test frameworks.

There are a few different services that allow you to use popular languages to create infrastructure as code. In this article, we’ll be using Pulumi.

This article (and the video course) was made possible through a grant from Pulumi.

Pulumi is an open source infrastructure as code tool for creating, deploying, and managing cloud infrastructure. Pulumi works with traditional infrastructure like VMs, networks, and databases, in addition to modern architectures, including containers, Kubernetes clusters, and serverless functions. Pulumi supports dozens of public, private, and hybrid cloud service providers.

We’ll be using Python and deploying on AWS, though it can be done with other programming languages and cloud providers.

Lab 1: Provisioning Infrastructure with an S3 Bucket

We’ll start out with a simple example. This will show an end-to-end experience of working with Pulumi using very simple resources.

In this first example we will do the following:

We will use an S3 bucket and then work through the life cycle with a simple set of resources. Then in future examples you will learn how to implement more complex things.

With Pulumi, infrastructure is organized into projects. Each project is a single program that, when run, declares the desired infrastructure for Pulumi to manage.

Before we start the first lab, make sure Pulumi is installed. The way to install is different depending on your operating system.

For this example, we are using AWS. You’ll have to make sure you have an AWS account and have the CLI set up and authenticated. (There is also a method that does not use the CLI.)

You can sign up for a free AWS account here: https://aws.amazon.com/free/

For MacOS, you can use these commands:

For Windows there are a few extra steps and you should just follow the instructions here.

Next, you need to get an Access key ID and secret access key from AWS. Follow the instructions from Amazon to get these.

Now run the following in the command line:

Enter your Access Key ID and Secret Access Key when prompted. You can keep the «Default region name» and «Default output format» as None.

Step 1: Create a Directory

Each Pulumi project lives in its own directory. Create one now and change into it:

mkdir iac-lab1 cd iac-lab1

Step 2: Initialize Your Project

A Pulumi project is just a directory with some files in it. It’s possible for you to create a new one by hand. The pulumi new command, however, automates the process:

If this is the first time you have used Pulumi, you will be directed to enter an access code or login. To get an access code, go to https://app.pulumi.com/account/tokens

Step 3: Setup Virtual Environment

Step 4: Inspect Your New Project

Our project is comprised of multiple files:

If you look in the __main__.py file you will notice a single line of code:

Configuring AWS

Now that you have a basic project, let’s configure AWS support for it.

Step 5: Install the AWS Package

Run the following command to install the AWS package:

pip3 install pulumi-aws

Step 6: Import the AWS Package

Now that the AWS package is installed, add the following line to __main__.py to import it:

import pulumi_aws as aws

Step 7: Configure an AWS Region

Configure the AWS region you would like to deploy to by running the following on the command line.

pulumi config set aws:region us-east-1

You can choose a different AWS region if you like. (See this table for a list of available regions.)

Optional Step: Configure an AWS Profile

If you’re using an alternative AWS profile, you can tell Pulumi which to use in one of two ways:

Provisioning Infrastructure

Now that you have a project configured to use AWS, you’ll create some basic infrastructure in it. We will start with a simple S3 bucket.

Step 8: Declare a New Bucket

Add the following to your __main__.py file:

So the full file should look like this:

Step 9: Preview Your Changes

Now preview your changes:

This command evaluates your program, determines the resource updates to make, and shows you an outline of these changes:

This is a summary view. Select details to view the full set of properties:

The stack resource is a synthetic resource that all resources your program creates are parented to.

Step 10: Deploy Your Changes

Now that we’ve seen the full set of changes, let’s deploy them. Select yes :

Now our S3 bucket has been created in our AWS account. If you view your buckets on the AWS website, you will see the new bucket. If you go to the URL shown in the output you will be taken to the Pulumi Console, which records your deployment history.

Step 11: Export Your New Bucket Name

Programs can export variables which will be shown in the CLI and recorded for each deployment. Export your bucket’s name by adding this line to the end of __main__.py :

Now deploy the changes with:

You will now notice a new Outputs section in the output displaying the bucket’s name:

You can select «Yes» to perform the update.

Step 12: Inspect Your New Bucket

The result should look something like this:

Then you can run the aws CLI to list the objects in this new bucket (getting the bucket name using the command from above):

There currently will not be any result from that command since the bucket is still empty.

Updating Your Infrastructure

We just saw how to create new infrastructure from scratch. Next, let’s make a few updates:

This demonstrates how declarative infrastructure as code tools can be used not just for initial provisioning, but also subsequent changes to existing resources.

Step 13: Add an Object to Your Bucket

Create a directory site/ and add a new index.html file with the following contents:

Now update your __main__.py file so that it looks like this:

Deploy the changes:

This will give you a preview and selecting yes will apply the changes:

A single resource is added and the 2 existing resources are left unchanged. This is a key attribute of infrastructure as code — such tools determine the minimal set of changes necessary to update your infrastructure from one change to the next.

Now, list again the contents of your bucket:

You will notice that the index.html file has been added:

Step 14: Serve Content From Your Bucket as a Website

To serve content from your bucket as a website, you’ll need to update a few properties.

Next, your index.html object will need two changes: an ACL (Access Control List) of public-read so that it can be accessed anonymously over the Internet, and a content type so that it is served as HTML. You will also need to export the resulting bucket’s endpoint URL so we can easily access it.

Combining everything, the file should now look like this:

Now deploy the changes:

The preview will look something like this:

Selecting details during the preview has a lot more information this time:

Now just select yes to deploy all of the updates. The result will show the URL that can be used to access your index.html file.

Step 15: Access Your Website

Besides going to the URL in a web browser (from the results shown above), you can also access the website with this command in the terminal:

This will fetch and print our index.html file:

Making Your Stack Configurable

Right now, the bucket’s contents are hard-coded. Next, you’ll make the location of the contents configurable, and add support for populating the bucket with an entire directory’s worth of contents.

Step 16: Adding a Config Variable

Instead of hard-coding the «site» directory, we will use configuration to make it easy to change the location without editing the program.

Add this to your __main__.py file right below the imports:

Step 17: Populating the Bucket Based on Config

And replace the hard-coded «site» parameter with this imported siteDir variable:

Now let’s see how this can be helpful. Using the terminal rename the site directory to www :

Step 18: Deploying the Changes

Now, deploy your changes. To do so, first configure your stack. If you don’t, you’ll get an error:

This results in an error like the following:

Configure the iac-workshop:siteDir variable similar to how the aws:region variable was configured:

pulumi config set iac-lab1:siteDir www

This detects that the path has changed and will perform a simple update.

Step 19: Add More Files

Instead of hard-coding the set of files, you will now change the program to read the entire contents of the www directory.

Add a new file named about.html to the www directory and add some HTML. Here is one option:

Now replace the object allocation code with the code below. You will notice that there is now a for loop to loop through every file in the site directory:

You will see a single new object created for the about.html file:

You can now go to the URL from before and add «/about.html» to the end.

You can also get the file in the terminal with the command:

Creating a Second Stack

It is easy to create multiple instances of the same project. In Pulumi, each instance is called a stack. This is useful if you have multiple development or test environments, staging versus production, and scaling a given infrastructure across many regions.

Step 20: Create and Configure a New Stack

Create a new stack named ‘prod’:

pulumi stack init prod

Next, configure its two required variables:

You can see the list of stacks for your current project with the command:

It will print all stacks for this project that are available to you:

Step 21: Populate the New Site Directory

So create this new directory:

Add a new index.html file to it. It can contain any HTML but here is a suggestion:

Step 22: Deploy the New Stack

Now deploy all of the changes:

This will create an entirely new set of resources from scratch, unrelated to the existing dev stack’s resources.

You will notice a new URL in the output. You can access that URL in a browser to see the new website.

Also you can get it using this command in the terminal:

Destroying Your Infrastructure

The final thing we’ll cover in this first lab is to destroy all of the resources from the two stacks created.

Step 23: Destroy Resources

First, destroy the resources in your current stack:

This will show you a preview, much like the pulumi up command does:

Step 24: Remove the Stack

The AWS resources for this stack have been destroyed. You may have noticed the message printed at the end that the history and configuration associated with the stack are still maintained. This means all past history is still available and you can perform subsequent updates on this stack.

Now, fully remove the stack and all history:

This is irreversible and so asks to confirm that this is your intent:

Type the name of the stack and hit enter. The stack is now gone.

Step 24: Select Another Stack, Rinse and Repeat

Now, go back and repeat the previous two steps to destroy it.

Step 25: Verify That Stacks are Gone

Verify that all of this project’s stacks are now gone:

Conclusion of Lab 1

Congratulations! You have completed the first lab. The next few labs are a little shorter and demonstrate some more advanced tasks.

Lab 2: Provisioning EC2 Virtual Machines

Amazon Elastic Compute Cloud (Amazon EC2) is a web service that provides secure, resizable compute capacity in the cloud. It is designed to make web-scale cloud computing easier for developers. Amazon EC2’s simple web service interface allows you to obtain and configure capacity with minimal friction.

In this second lab, you’ll first create a single EC2 virtual machine (VM). Afterwards, you’ll scale that out to a VM per availability zone in your region, and then add a load balancer to spread load across the entire fleet.

Step 1: Create a Directory

We could use the same project and directory as before. But we’ll create a new one to get more practice.

Create a new directory that is not inside the directory of used in the last lab.

Step 2: Initialize Your Project

Remember, a Pulumi project is just a directory with some files in it. It’s possible for you to create a new one by hand. The pulumi new command, however, automates the process:

This command has created all the files we need, initialized a new stack named dev (an instance of our project), and installed the needed package dependencies from PyPi. The «aws» part of the command made sure our __main__.py file started with samle code to create an AWS bucket.

Step 3: Configure an AWS Region

Configure the AWS region you would like to deploy to:

Step 4: Declare the EC2 Instance

Remove any existing code here from the bootstrapping of your project. Then, import the AWS package in an empty __main__.py file:

We also need to grab the default Virtual Private Cloud is a service that lets you launch AWS resources in a logically isolated virtual network that you define) that is available in our AWS account:

Next, create an AWS security group. This enables ping over ICMP and HTTP traffic on port 80:

Create the server. Notice it has a startup script that spins up a simple Python webserver:

For most real-world applications, you would want to create a dedicated image for your application, rather than embedding the script in your code like this.

Finally export the EC2 instances’s resulting IP address and hostname:

After this change, your __main__.py should look like this:

Step 5: Provision the EC2 Instance and Access It

To provision the VM, run:

After confirming, you will see output like the following:

If you get an error, try running pulumi up again and confirming. The first time I ran it there was a race condition which required re-running the command.

You can now try accessing the URL from the output in a web browser.

Alternatively, you can use this command:

Either way you should see a response from the Python webserver:

Step 6: Add more EC2 instances

Now you will create multiple EC2 instances, each running the same Python webserver, across all AWS availability zones in your region. Replace the part of your code that creates the webserver and exports the resulting IP address and hostname with the following:

After this change, your __main__.py should look like this:

Now run a command to update your stack with the new resource definitions:

You will see output like the following:

Notice that your original server was deleted and new ones created in its place, because its name changed.

To test the changes, curl any of the resulting IP addresses or hostnames (or access the URLs in a web browser):

The count of servers depends on the number of AZs in your region. You may need to adjust the <0..2>.

Note that the webserver number is included in its response:

Add a loadbalancer

Needing to loop over the webservers isn’t very realistic. You will now create a load balancer over them to distribute load evenly.

Step 7: Update our Security Group

We need to add an egress rule to our security group. Whenever you add a listener to your load balancer or update the health check port for a target group used by the load balancer to route requests, you must verify that the security groups associated with the load balancer allow traffic on the new port in both directions.

This is required to ensure the security group ingress rules don’t conflict with the load balancer’s.

Step 8: Define the ALB

Now right after the security group creation, and before the EC2 creation block, add the load balancer creation steps:

Here, we’ve defined the ALB, its TargetGroup and some Listeners, but we haven’t actually added the EC2 instances to the ALB.

Step 9: Add the Instances to the ALB

Replace the EC2 creation block with the following:

After this change, your __main__.py should look like this:

This is all the infrastructure we need for our load balanced webserver. Let’s apply it.

Step 10: Deploy your Changes

Deploy these updates:

This should result in a fairly large update and, if all goes well, the load balancer’s resulting endpoint URL:

Step 11: Verify

Now we can curl the load balancer:

Observe that the resulting text changes based on where the request is routed:

Step 12: Destroy Everything

Finally, destroy the resources and the stack itself:

Lab 3: Deploying Docker images to ECS & Fargate

In this lab, you will use Pulumi to deploy a Docker Image to ECS with Fargate.

Let’s start from the beginning again to get more practice.

Step 1: Create a Directory

Create a new directory and change into it:

Pulumi will use the directory name as your project name by default. To create an independent project, simply name the directory differently.

Step 2: Initialize Your Project

A Pulumi project is just a directory with some files in it. It’s possible for you to create a new one by hand. The pulumi new command, however, automates the process:

This command has created all the files we need, initialized a new stack named dev (an instance of our project), and installed the needed package dependencies from PyPi.

Step 3: Inspect Your New Project

Our project is comprised of multiple files (these are the same as before so this is a review):

Run cat __main__.py to see the contents of your project’s empty program:

Feel free to explore the other files, although we won’t be editing any of them by hand.

Step 4: Configure an AWS Region

Configure the AWS region you would like to deploy to:

Step 5: Create an ECS Cluster

Remove all the boilerplate from the project bootstrap.

Import the AWS and Pulumi packages in an empty __main__.py file:

And now create a new ECS cluster. You will use the default values, so doing so is very concise:

After this change, your __main__.py should look like this:

Step 6: Create a Load-Balanced Container Service

Next, allocate the application load balancer (ALB) and listen for HTTP traffic port 80. In order to do this, we need to find the default VPC and the subnet groups for it:

After this change, your __main__.py should look like this:

Run your program with pulumi up :

We’ve fleshed out our infrastructure and added a LoadBalancer we can add infrastructure to, in the next steps we’ll run a container.

Step 7: Create ECS FargateService

In order to create a Fargate service, we need to add an IAM Role and a Task Definition and Service. The ECS Cluster will run the «nginx» image from the Docker Hub.

Firstly, we need to add a new import at the top of our file

Now let’s define our IAM Role and attach a policy. You should define this at the end of your __main__.py :

Then we can define a task definition for our ECS service:

After these changes, your __main__.py should look like this

Step 8: Provision the Cluster and Service

Deploy the program to stand up your initial cluster and service:

This will output the status and resulting load balancer URL:

You can access the URL from the output above in a web browser. Also, you can now curl the resulting endpoint:

And you’ll see the Nginx default homepage:

Step 9: Update the Service

Now, also update the desired container count from 1 to 3 :

Next update the stack:

The output should look something like this:

Step 10: Destroy Everything

Finally, destroy the resources and the stack itself:

Источник