Azure DevOps и IaC: методы и процессы мозгового штурма

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

Монолитный подход

Монолитный подход — это когда репозиторий имеет один шаблон ARM и файл параметров для развертывания всего приложения через конвейеры Azure. Хорошим примером является ARM, который развертывает виртуальную сеть, аналитику журналов, Azure Key Vault, пару виртуальных машин и шлюз приложений.

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

Модульный подход: больше свободы для команд DevOps

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

Простой подход заключается в том, чтобы иметь шаблон ARM для развертывания определенных компонентов (виртуальная сеть, виртуальная машина, Key Vault и т. д.), и мы создаем набор файлов параметров для каждой среды. Наши конвейеры будут использовать пару файлов (Keyvault.json, шаблон и keyvault.prod.json, который является файлом параметров) и развернуты в указанной подписке.

Предположим, нам нужно выполнить развертывание в совершенно новой подписке/среде. Мы можем либо создать новый конвейер Azure для развертывания новых файлов параметров в новой подписке, либо добавить этап в существующий конвейер, ссылающийся на новую среду (файлы параметров).

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

Azure DevOps допускает множество настроек. Мы могли бы легко использовать репозиторий со всеми модулями, которые мы хотим развернуть в нашей организации, и ссылаться на них из репозитория из приложения. Таким образом, у вас есть центральное расположение для всех ваших поддерживаемых приложений.

Соглашение об именовании IaC и Azure DevOps: не берите пленных!

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

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

Затем в шаблоне ARM мы используем переменные для объединения этих значений и создания ресурсов с использованием четко определенного соглашения об именах. Это упрощает развертывание, когда требуется всего несколько параметров. Однако для уникальных имен, таких как Key Vault, использование третьей переменной (например, имя приложения помогает избежать конфликтов).

В приведенном ниже примере после создания имен для Key Vault мы будем использовать переменную v_keyvaultName при назначении имени для ресурса Key Vault.

Параметры: использование конвейера или файла

При развертывании шаблонов ARM простым подходом является создание файла шаблона и файла параметров. Файл параметров будет содержать всю информацию, необходимую шаблону для предоставления ресурсов.

При использовании конвейера выпуска у нас есть оба варианта: шаблон (элемент 1) и файл параметров (элемент 2), который нужно выбрать из списка файлов в репо для выполнения.

У нас также есть третий вариант — переопределить параметры шаблона (пункт 3). Когда мы нажмем кнопку …, у нас будут все параметры, запрашиваемые файлом шаблона. Значения темного цвета — это значения по умолчанию в шаблоне (мы можем выбрать параметры, если они доступны в файле шаблона), а значения серого цвета — значения, которые были введены в файле параметров. Мы можем заменить их во время выполнения конвейера.

В чем проблема? Что ж, вам может сойти с рук использование файлов шаблонов и использование переменных в вашем конвейере. Мы можем настроить достаточно, чтобы предоставить имя стадии в Azure DevOps, которое будет параметром для вашего файла шаблона.

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

Azure DevOps и IaC: наш путь только начинается

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

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