Инфраструктура как код (IAC) в конвейерах DevOps

Учебники

Этот блог-пост является главой из электронной книги From Admin to DevOps: The No-BS Way to DevOps in Azure. Обязательно ознакомьтесь с ней, если вы хотите погрузиться в то, что нужно для успешной работы с DevOps в Microsoft Azure, изучая Infrastructure as a Code.

Если вы когда-либо создавали облачную или виртуальную инфраструктуру на месте вручную, то вы знаете, что вам приходится много кликать или много печатать. Infrastructure as Code (Iac) заботится об этом.

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

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

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

Infrastructure as Code (IaC): на примере

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

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

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

Шаблон

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

{
	"VM": {
        "Name": "MYVM",
        "Disk": {
            "Size": "100GB"
        },
        "Networking": {
            "IPAddress" : "10.0.0.1"
        }
    }
}

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

Управление исходным кодом

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

Инструмент

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

> [some command line tool] -File myvm.json

Хорошая сделка, верно? Но это еще не все.

Борьба с отклонением конфигурации

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

  1. Это изменение делается вручную, что занимает время и может привести к ошибкам человека.
  2. Не существует аудита того, кто и когда изменил IP-адрес.
  3. Не существует автоматического способа отката изменений, если вы случайно введете неправильный IP-адрес.

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

Откройте файл myvm.json, измените атрибут IPAddress, зафиксируйте изменение в системе контроля версий и запустите инструмент еще раз. Готово.

{
	"VM": {
        "Name": "MYVM",
        "Disk": {
            "Size": "100GB"
        },
        "Networking": {
            "IPAddress" : "10.0.0.2"
        }
    }
}
> [some command line tool] -File myvm.json

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

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

Но это еще не все.

Начало непрерывной доставки.

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

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

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

Заключение

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

Source:
https://adamtheautomator.com/infrastructure-as-code-iac/