Развертывание шаблонов ARM с помощью конвейера YML Azure Devops в нескольких средах Azure

Вступление

Сегодня мы можем определить инфраструктуру как код (шаблон ARM) и конвейер CI / CD как код (конвейеры YAML) в экосистеме Azure. Но почему мы хотим выполнять эти задачи в виде кода?

Есть веские причины, помимо классного занятия.

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

Относительно просто развернуть простой шаблон ARM в единой среде Azure через конвейер YAML. Но в коммерческом проекте все гораздо сложнее.

Заявление о миссии

В конце этой статьи вы сможете:

Развертывайте сложные шаблоны ARM с зависимостями между ресурсами в нескольких средах.

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

Применение гипотез

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

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

  • Приложение-функция Azure, выполняющее бизнес-логику.
  • Учетная запись хранения, необходимая для приложений-функций.
  • Application Insights для мониторинга.
  • Хранилище ключей Azure для хранения конфиденциальных данных.

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

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

Какой из них создать в первую очередь? Приложение-функция или хранилище ключей? Это становится проблемой в первую очередь курица или яйцо.

Или нет?

Шаблон ARM

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

Давайте пройдемся по разделам в шаблоне ARM.

Pre-warning: the ARM template is quite long and can look confusing at first. Bear with me, it should all make sense in the end.

Параметры и переменные

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

В этом проекте определены следующие параметры и переменные.

Приложение-функция Azure

Мы рассмотрели бит кода, теперь перейдем к инфраструктуре.

Приложение-функция Azure - это особый вид веб-приложения с некоторыми зависимостями.

Обязательные зависимости:

  • Учетная запись хранения Azure.
  • План обслуживания приложений.

Необязательные зависимости:

  • Информация о приложениях.

Мы можем указать его зависимости с помощью свойства dependsOn, чтобы указать Azure сначала создать зависимые ресурсы.

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



Практическое руководство по долгосрочным функциям Azure - часть 1. Введение
Все, что вам нужно знать, чтобы создать готовое к работе приложение-функцию с помощью функций Azure Durable Functions. medium .com



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

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

Теперь мы настроили инфраструктуру в виде кода. А как насчет конвейера для его развертывания?

Трубопровод YAML

Группы переменных

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

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

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

Среда

Это относится к средам Azure DevOps. В меню слева выберите Среды. Создавайте среды разработки и тестирования.

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

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

Трубопровод

Конвейер YAML разбит на этапы.

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

На втором этапе шаблон ARM развертывается в группе ресурсов разработчика.

Здесь следует отметить несколько моментов:

  • Группа переменных DevGroup указывается на уровне стадии. Переменные в этой группе становятся доступными на этом этапе. Ссылайтесь на переменные в формате $ (variableName).
  • Для среды задано значение DevEnv, созданное ранее на уровне задания. Не знаю, почему я не могу установить его на уровне сцены. Если вы знаете, пожалуйста, оставьте комментарий. Идея состоит в том, что этап тестирования будет защищен шлюзом утверждения, определенным ранее.
  • Установлен режим развертывания Инкрементное. Это означает, что конвейер не будет пытаться удалить ресурсы, не указанные в шаблоне ARM. Это более безопасный вариант, поскольку разработчики могут вручную создавать ресурсы для проведения экспериментов. Но это означает, что им нужно не забывать убирать лишние ресурсы, когда они больше не нужны.

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

Результат

Теперь все готово. Давайте развернем в Azure.

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

Нажмите «Утвердить», и ресурсы также будут развернуты в тестовой среде.

Развернутый ресурс должен иметь правильное имя среды.

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

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

Резюме

Вот и все. Мы успешно развернули ресурсы Azure с зависимостями через конвейер Azure DevOps в виде кода.

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

Версия «в виде кода», безусловно, имеет свои преимущества и является шагом вперед - Azure DevOps поощряет использование конвейера YAML в отличие от классического конвейера с удобным пользовательским интерфейсом.

Но вначале у него крутая кривая обучения. Вот несколько советов, которые помогут вам начать работу:

  • Не пытайтесь создавать шаблоны ARM с нуля. Создайте ресурсы в группе ресурсов среды разработки. Затем экспортируйте шаблон ARM из группы ресурсов. Экспортированный шаблон может быть не совсем таким, каким вы его хотите. Но это хорошее начало.
  • Очень легко испортить все эти квадратные скобки, скобки, одинарные и двойные кавычки в шаблонах ARM. IntelliSense Visual Studio - довольно хороший инструмент, чтобы помочь в этом. Однако иногда он ошибается в параметрах API. Так что не верьте этому слепо.
  • Вам не хватает простых в использовании раскрывающихся вариантов на классических конвейерах Azure DevOps? Отредактируйте конвейер YAML в Azure DevOps и посмотрите на помощника в правом верхнем углу. Не так удобно, как UI, но неплохо.
  • Не знаете, какие параметры есть у задачи? Убедитесь, что ваш курсор находится в правильном месте, и нажмите CTRL + пробел (как и в Visual Studio), будут перечислены доступные параметры.

Наконец, вам нужно подумать: дублирование этапов разработки и тестирования в конвейере YAML может хорошо выглядеть всего в двух средах. Что, если есть еще UAT, промежуточная и производственная среды? Очевидно, что дублировать эти коды для каждой среды - не лучший вариант. Итак, что вы можете сделать, чтобы сделать его более читабельным и простым в обслуживании?

Подсказка: Google "Шаблон YAML Azure Devops".