Путь к просветлению: переход от Azure Portal/PowerShell к Azure DevOps

Опубликовано: 1 Марта, 2023
Путь к просветлению: переход от Azure Portal/PowerShell к Azure DevOps

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

Добавление среды PROD

Первый шаг — отредактировать существующий конвейер и под существующим DEV нажать Clone. Мы собираемся пометить новый этап как PROD.

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

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

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

Меняем инфраструктуру и отвечаем на наболевшие вопросы

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

Мы можем начать вводить простое изменение — создание новой подсети. Мы назовем его Web и назначим ему диапазон IP-адресов 10.10.20.0/24. Сохраните его и зафиксируйте в ветке, и это автоматически вызовет новое развертывание.

Результаты, достижения? Сладкая консистенция! По крайней мере, в отношении инфраструктуры как кодекса мы можем быть честными и справедливыми по отношению ко всем подданным нашего королевства. На изображении ниже среда PROD имеет две в своей .

Вторым изменением будет переименование подсети Servers в подсеть App, только метка, а не конфигурация IP. Сохраните его и зафиксируйте в ветке . Результатом будут изменения, примененные к обеим средам и серверам, которые будут переименованы в App.

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

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

Аудит изменений

Теперь, когда у нас есть процесс перехода от простого изменения шаблона ARM к полномасштабным DEV и PROD. Наш следующий логический шаг — понять, какие инструменты доступны, которые помогут нам понять задачи, выполняемые конвейерами.

Первая остановка в нашем путешествии — функция «Журнал активности». Используя эту функцию, мы можем видеть точные изменения, выполненные на уровне ресурсов, и это дает нам представление о действиях, реализованных Azure DevOps.

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

В журнале действий (элемент 1) виртуальной сети будет отображаться список всех действий, которые произошли в плоскости управления Microsoft Azure (элемент 2), нажмите на нужное событие. У нас есть три вкладки (элемент 3), где мы можем увидеть сводку, фактический файл JSON и которая находится в предварительном просмотре, но очень помогает объяснить, какое действие произошло, и сравнение между предыдущими и новыми значениями.

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

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

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

Следующим шагом будет переход на вкладку Pipeline. Мы можем щелкнуть любой этап (в нашем случае PROD ), и сводку задач можно будет легко увидеть в удобном для человека формате. Проверьте коммиты и рабочие элементы. Мы можем копнуть глубже и проверить журналы каждого шага, и они доступны по ссылке «Просмотреть журналы».

Контроль изменений в производстве

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

Чтобы настроить утверждения в нашей производственной среде, отредактируйте существующий , щелкните вкладку Конвейер (пункт 1), а затем значок молнии. В новой колонке, которая появится справа, включите Утверждения перед развертыванием и выберите пользователя или группу (этот список взят из Azure Active Directory). Нажмите «Сохранить» и запустите новый выпуск (нажав «Создать выпуск» или обновив ветку в репозитории).

Среда prod не запустится автоматически, но останется в состоянии «Ожидание утверждения». Утверждающий получит электронное письмо и войдет на портал Azure DevOps, перейдите к выпуску и нажмите «Утвердить».

Оставьте комментарии и нажмите «Подтвердить». Это вызовет развертывание в производственной среде.

Azure DevOps: эта серия статей завершена, но предстоит сделать еще больше

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

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

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

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