Настройка непрерывного развертывания для веб-приложения Python в приложениях контейнеров Azure

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

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

На этой схеме службы выделены компоненты, описанные в этой статье: конфигурация CI/CD.

Необходимые компоненты

Чтобы настроить непрерывное развертывание, вам потребуется:

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

• Учетная запись GitHub, в которой вы вилировали пример кода (Django или Flask) и можете подключиться к приложениям контейнеров Azure. (Если вы скачали пример кода вместо вилки, убедитесь, что вы отправляете локальный репозиторий в учетную запись GitHub.)

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

Настройка CD для контейнера

В предыдущей статье этого руководства вы создали и настроили приложение-контейнер в приложениях контейнеров Azure. Часть конфигурации извлекла образ Docker из Реестр контейнеров Azure. Образ контейнера извлекается из реестра при создании редакции контейнера, например при первой настройке приложения контейнера.

В этом разделе описано, как настроить непрерывное развертывание с помощью рабочего процесса GitHub Actions. При непрерывном развертывании создается новый образ Docker и редакция контейнера на основе триггера. Триггер в этом руководстве — это любое изменение основной ветви репозитория, например с запросом на вытягивание (PR). При активации рабочий процесс создает новый образ Docker, отправляет его в Реестр контейнеров Azure и обновляет приложение-контейнер до новой редакции с помощью нового образа.

Azure CLI

Команды Azure CLI могут выполняться в Azure Cloud Shell или на рабочей станции с установленным интерфейсом Azure CLI.

Если вы выполняете команды в оболочке Git Bash на компьютере с Windows, введите следующую команду, прежде чем продолжить:

export MSYS_NO_PATHCONV=1

Шаг 1. Создайте субъект-службу с помощью команды az ad sp create-for-rbac.

az ad sp create-for-rbac \
--name <app-name> \
--role Contributor \
--scopes "/subscriptions/<subscription-ID>/resourceGroups/<resource-group-name>"

Где:

• <имя приложения — это необязательное отображаемое имя> субъекта-службы. Если вы оставьте --name этот параметр, в качестве отображаемого имени создается GUID.
• <Идентификатор> подписки — это GUID, который однозначно идентифицирует подписку в Azure. Если вы не знаете идентификатор подписки, можно запустить команду az account show и скопировать его из id свойства в выходных данных.
• <Имя> группы ресурсов — это имя группы ресурсов, содержащей контейнер приложений контейнеров Azure. Управление доступом на основе ролей (RBAC) находится на уровне группы ресурсов. Если вы выполнили действия, описанные в предыдущей статье в этом руководстве, имя группы ресурсов — pythoncontainer-rgэто .

Сохраните выходные данные этой команды для следующего шага, в частности, идентификатор клиента (свойство), секрет клиента (appIdpasswordсвойство) и идентификатор клиента (tenantсвойство).

Шаг 2. Настройте GitHub Actions с помощью команды add az containerapp github-action.

az containerapp github-action add \
--resource-group <resource-group-name> \
--name python-container-app \
--repo-url <https://github.com/userid/repo> \
--branch main \
--registry-url <registry-name>.azurecr.io \
--service-principal-client-id <client-id> \
--service-principal-tenant-id <tenant-id> \
--service-principal-client-secret <client-secret> \
--login-with-github

Где:

• <имя> группы ресурсов — это имя группы ресурсов. Если вы используете этот учебник, это pythoncontainer-rg.
• <https://github.com/userid/repo> — это URL-адрес репозитория GitHub. Если вы выполняете действия, описанные в этом руководстве, оно будет https://github.com/userid/msdocs-python-django-azure-container-appshttps://github.com/userid/msdocs-python-flask-azure-container-appsлибо; где userid находится идентификатор пользователя GitHub.
• <имя> реестра — это существующий реестр контейнеров, созданный для этого руководства, или тот, который можно использовать.
• <идентификатор> клиента — это значение appId свойства из предыдущей az ad sp create-for-rbac команды. Идентификатор — это GUID формы 000000000000-0000-0000-0000-000000000.
• <идентификатор> клиента — это значение tenant свойства из предыдущей az ad sp create-for-rbac команды. Идентификатор также является ИДЕНТИФИКАТОРом GUID, аналогичным идентификатору клиента.
• <секрет> клиента — это значение password свойства из предыдущей az ad sp create-for-rbac команды.

Портал Azure

Шаг 1. В портал Azure перейдите в приложение-контейнер, для которого нужно настроить непрерывное развертывание и выберите ресурс непрерывного развертывания.

Шаг 2. Авторизация приложений контейнеров Azure для доступа к учетной записи GitHub.

• Выберите Войти по учетным данным GitHub.
• Во всплывающем авторизации выберите AuthorizationAppService.

Доступ к приложению-контейнеру к accont GitHub можно отменить, перейдя в раздел безопасности вашей учетной записи и отменив доступ.

Шаг 3. После входа в GitHub настройте сведения о непрерывном развертывании.

• Организация → Использовать имя пользователя GitHub.
• Репозиторий → Выбрать вилку примера приложения. (Если вы первоначально скачали пример кода в среду разработчика, отправьте репозиторий в GitHub.)
• Ветвь → Выбрать main.
• Источник репозитория → Выбрать Реестр контейнеров Azure.
• → Реестра выберите Реестр контейнеров Azure, созданные ранее в руководстве.
• Изображение → Выберите имя образа Docker. Если вы используете учебник, это "python-container-app".
• Субъект-служба → оставить создать новый и позволить процессу создания создать новый субъект-службу.

Нажмите кнопку "Начать непрерывное развертывание" , чтобы завершить настройку.

Шаг 4. Просмотрите сведения о непрерывном развертывании.

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

В конфигурации непрерывного развертывания субъект-служба используется для предоставления GitHub Actions доступа к ресурсам Azure и их изменения. Доступ к ресурсам ограничен ролями, назначенными субъекту-службе. Субъект-служба был назначен встроенной роли участника в группе ресурсов, содержащей приложение-контейнер.

Если вы выполнили действия на портале, субъект-служба был автоматически создан для вас. Если вы выполнили действия для Azure CLI, вы явно создали субъект-службу перед настройкой непрерывного развертывания.

Повторное развертывание веб-приложения с помощью GitHub Actions

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

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

GitHub

Шаг 1. Перейдите в вилку примера репозитория и запустите в главной ветви.

Шаг 2. вносить изменения.

• Перейдите в файл /templates/base.html . (Для Django путь : restaurant_review/templates/restaurant_review/base.html.)
• Выберите "Изменить " и измените фразу "Обзор ресторана Azure" на "Обзор ресторана Azure — повторно развернуто".

Шаг 3. Зафиксируйте изменение непосредственно в главной ветви.

• В нижней части страницы, где вы редактируйте, нажмите кнопку "Зафиксировать ".
• Фиксация запускает рабочий процесс GitHub Actions.

Командная строка

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

Шаг 1. Начните с главного.

git checkout main
git pull

Шаг 2. вносить изменения.

Перейдите в файл ./templates/base.html (./restaurant_review/templates/restaruant_review/base.html для Django) и измените фразу "Обзор ресторана Azure" на "Обзор ресторана Azure — повторно развернутый".

Шаг 3. Зафиксируйте изменение и отправьте его в GitHub.

git commit -a -m "Redeploy with title change."
git push

При первом использовании git может потребоваться задать глобальные переменные "user.name" и "user.email". Дополнительные сведения см. в справке по git-config.

Отправка изменений в основную ветвь запускает рабочий процесс GitHub Actions.

Примечание.

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

О GitHub Actions

Просмотр журнала рабочих процессов

GitHub

Шаг 1. На сайте GitHub перейдите в вилку примера репозитория и откройте вкладку "Действия ".

Командная строка

В этих шагах используется интерфейс командной строки GitHub.

Шаг 1. Получите сводку по рабочему процессу. Выполните следующую команду в папке, содержащей клон:

gh workflow view

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

Примечание.

При первом использовании gh может появиться запрос на проверку подлинности. Следуйте указаниям интерфейса командной строки GitHub для проверки подлинности.

Если у вас несколько удаленных настроек, может потребоваться выбрать gh repo set-default удаленный репозиторий по умолчанию. Выберите вилку из представленных параметров.

Вы можете выполнить gh workflow view команду из любой папки без необходимости задать репозиторий по умолчанию, добавив --repo [HOST/]OWNER/REPO этот параметр.

Шаг 2. Перейдите в GitHub для получения сведений о выполнении рабочего процесса.

gh workflow view --web

Секреты рабочего процесса

В файле рабочего процесса .github/workflows/<workflow-name>.yml файл рабочего процесса, добавленный в репозиторий, вы увидите заполнители для учетных данных, необходимых для заданий обновления приложения сборки и контейнера рабочего процесса. Данные учетных данных хранятся в репозитории Параметры в разделе "Секреты безопасности/и переменные/Действия".

Если данные учетных данных изменяются, его можно обновить здесь. Например, если Реестр контейнеров Azure пароли повторно создаются, необходимо обновить значение REGISTRY_PASSWORD. Дополнительные сведения см. в разделе "Зашифрованные секреты " в документации по GitHub.

Авторизованные приложения OAuth

При настройке непрерывного развертывания вы авторизуете Приложения контейнеров Azure в качестве авторизованного Приложение OAuth для учетной записи GitHub. Контейнерные приложения используют авторизованный доступ для создания файла YML GitHub Actions в .github/workflows/<workflow-name>.yml. Вы можете просмотреть авторизованные приложения и отозвать разрешения в разделе "Приложения интеграции/" вашей учетной записи.

Советы по устранению неполадок

Ошибки, связанные с настройкой субъекта-службы с помощью команды Azure CLI az ad sp create-for-rba .

• Появится сообщение об ошибке "InvalidSchema: не найдены адаптеры подключения".

  • Проверьте оболочку, в которую вы работаете. При использовании оболочки Bash задайте переменные MSYS_NO_PATHCONV следующим образом export MSYS_NO_PATHCONV=1. Дополнительные сведения см. в статье о проблеме с GitHub, не удалось создать субъект-службу с помощью Azure CLI из оболочки Git Bash, не найдены адаптеры подключения.

• Появится сообщение об ошибке с сообщением "Несколько приложений имеют одинаковое отображаемое имя".

  • Эта ошибка указывает, что имя уже принято для субъекта-службы. Выберите другое имя или оставьте --name аргумент, и GUID будет автоматически создан в качестве отображаемого имени.

Сбой рабочего процесса GitHub Actions.

• Чтобы проверка состояние рабочего процесса, перейдите на вкладку "Действия" репозитория.
• Если рабочий процесс завершился сбоем, выполните детализацию по его файлу рабочего процесса. Должно быть два задания "build" и "deploy". Для неудачного задания просмотрите выходные данные задач задания, чтобы искать проблемы.
• Если отображается сообщение об ошибке с временем ожидания подтверждения TLS, запустите рабочий процесс вручную, выбрав автоматическое развертывание триггера на вкладке "Действия " репозитория, чтобы узнать, является ли время ожидания временным.
• Если вы настроили непрерывное развертывание для приложения-контейнера, как показано в этом руководстве, файл рабочего процесса (.github/workflows/<workflow-name>.yml) создается автоматически. Для этого руководства не нужно изменять этот файл. Если вы сделали это, отменить изменения изменения и попробуйте рабочий процесс.

Веб-сайт не отображает изменения, объединенные в основную ветвь.

• В GitHub: проверка, что рабочий процесс GitHub Actions запущен и проверка изменения в ветвь, которая активирует рабочий процесс.
• В портал Azure: проверка Реестр контейнеров Azure, чтобы узнать, был ли создан новый образ Docker с меткой времени после изменения в ветви.
• В портал Azure: проверка журналы приложения-контейнера. Если возникла ошибка программирования, вы увидите ее здесь.
  • Перейти к приложению-контейнеру | Управление редакциями | <активный контейнер> | Сведения о редакции | Журналы консоли
  • Выберите порядок столбцов для отображения "Время создания", "Stream_s" и "Log_s". Сортируйте журналы по последнему первому и найдите сообщения stderr и stdout в столбце "Stream_s". Выходные данные Python "print" будут сообщения stdout .
• С помощью Azure CLI используйте команду az containerapp logs show .

Что происходит при отключении непрерывного развертывания?

• Остановка непрерывного развертывания означает отключение приложения-контейнера от репозитория. Чтобы отключиться:

  • В портал Azure перейдите к приложению-контейнеру, выберите ресурс непрерывного развертывания, выберите "Отключить".
  • С помощью Azure CLI используйте команду az container app github-action remove .

• После отключения в репозитории GitHub:

  • Файл github/workflows/<workflow-name>.yml удаляется из репозитория.
  • Секретные ключи не удаляются.
  • Приложения контейнеров Azure остаются авторизованными Приложение OAuth для учетной записи GitHub.

• После отключения в Azure:

  • Контейнер остается с последним развернутым контейнером. Вы можете повторно подключить приложение-контейнер к Реестр контейнеров Azure, чтобы новые редакции контейнеров могли получить последний образ.
  • Субъекты-службы, созданные и используемые для непрерывного развертывания, не удаляются.

Следующие шаги

Если вы закончите работу с руководством и не хотите нести дополнительные расходы, удалите используемые ресурсы. Удаление группы ресурсов удаляет все ресурсы в группе и является самым быстрым способом удаления ресурсов. Пример удаления групп ресурсов см. в разделе "Очистка учебника по контейнеризации".

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

• Настройка правил масштабирования в приложениях контейнеров Azure

• Привязка имен и сертификатов личного домена в приложениях контейнеров Azure

• Мониторинг приложения в Контейнерах приложений Azure