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

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

В этом руководстве вы:

• Настройте непрерывное развертывание для приложения-контейнера с помощью рабочего процесса GitHub Actions.
• Внесите изменения в копию примера репозитория, чтобы активировать рабочий процесс GitHub Actions.
• Устранение неполадок, которые могут возникнуть при настройке непрерывного развертывания.
• Удалите ресурсы, которые вам не нужны при завершении серии учебников.

Непрерывное развертывание связано с практикой DevOps непрерывной интеграции и непрерывной доставки (CI/CD), которая является автоматизацией рабочего процесса разработки приложений.

На следующей схеме показаны задачи, описанные в этом руководстве.

Необходимые условия

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

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

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

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

Настройка непрерывного развертывания для контейнера

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

В этом разделе описано, как настроить непрерывное развертывание с помощью рабочего процесса GitHub Actions. При непрерывном развертывании создается новый образ Docker и редакция контейнера на основе триггера. Триггер в этом руководстве — это любое изменение в основной ветви репозитория, например с pull-запросом. Когда рабочий процесс активируется, он создает новый образ 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.

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

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

   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-apps, либо https://github.com/userid/msdocs-python-flask-azure-container-apps. В этих URL-адресах userid — это идентификатор пользователя GitHub.
   • <имя реестра> — это существующий экземпляр контейнерного реестра Azure, созданный в предыдущем руководстве, или тот, который можно использовать.
   • <идентификатор клиента> — это значение свойства appId из предыдущей команды az ad sp create-for-rbac. Идентификатор — это GUID формата 00000000-0000-0000-0000-00000000.
   • <идентификатор клиента> — это значение свойства tenant из предыдущей команды az ad sp create-for-rbac. Идентификатор также представляет собой GUID, аналогичный идентификатору клиента.
   • <client-secret> — это значение свойства password из предыдущей команды az ad sp create-for-rbac.

портал Azure

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

   

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

   1. Выберите Войти с помощью GitHub.
   2. В диалоговом окне авторизации выберите Авторизовать AzureAppService.

   

   Совет

   Вы можете отозвать доступ контейнерных приложений к вашей учетной записи GitHub через раздел безопасности вашей учетной записи.

3. Настройте сведения о непрерывном развертывании:

   • Organization: Используйте имя пользователя GitHub.
   • репозиторий: выберите форк образца приложения. (Если вы первоначально скачали пример кода в среду разработчика, отправьте репозиторий в GitHub.)
   • Ветка: выберите main.
   • Источник репозитория: выберите реестр контейнеров Azure.
   • Registry: Выберите инстанцию реестра контейнеров Azure, созданную в предыдущем руководстве.
   • изображение: выберите имя образа Docker. В этом руководстве упоминается python-container-app.
   • субъект-служба: оставьте создать новый и позвольте процессу создания создать новый субъект-службу.

   Выберите Запустить непрерывное развертывание, чтобы завершить настройку.

   

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

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

   

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

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

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

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

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

GitHub

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

   

2. Внесите изменения:

   1. Перейдите к файлу /templates/base.html. (Для Django путь — restaurant_review/templates/restaurant_review/base.html.)
   2. Выберите Изменить и измените фразу Azure Restaurant Review на Azure Restaurant Review - Redeployed.

   

3. В нижней части страницы, которую вы редактируете, убедитесь, что выбрана опция 'Фиксация непосредственно в главной ветви'. Затем нажмите кнопку Фиксация изменений.

   

Коммит запускает рабочий процесс GitHub Actions.

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

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

1. Начните с main:

   git checkout main
   git pull
   

2. Внесите изменения.

   Перейдите в файл ./templates/base.html (./restaurant_review/templates/restaurant_review/base.html для Django) и измените фразу Azure Restaurant Review на Azure Restaurant Review - Redeployed.

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

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

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

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

Заметка

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

Общие сведения о действиях GitHub

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

Если вам нужно просмотреть журнал рабочих процессов, используйте одну из следующих процедур.

GitHub

На GitHubперейдите в форк образца репозитория и откройте вкладку «Actions».

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

В этих шагах используется GitHub CLI.

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/<имя рабочего процесса>.yml, добавленный в репозиторий, включает заполнители для учетных данных, необходимых для заданий сборки и обновления приложения контейнера рабочего процесса. Учетные данные хранятся зашифрованными в области параметров репозитория, в разделе Секреты и переменные>безопасности>действий.

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

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

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

Устранение неполадок

При настройке субъекта-службы с помощью Azure CLI возникают ошибки.

Этот раздел может помочь устранить ошибки, которые вы получаете при настройке учетной записи службы с помощью команды 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

Чтобы проверить состояние рабочего процесса, перейдите на вкладку "Действия " репозитория:

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

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

В GitHub:

• Убедитесь, что рабочий процесс GitHub Actions запущен и что вы проверили изменение в ветви, которая активирует рабочий процесс.

На портале Azure:

• Проверьте экземпляр реестра контейнеров Azure, чтобы проверить, был ли создан новый образ Docker с меткой времени с момента изменения в ветви.

• Проверьте журналы приложения-контейнера, чтобы узнать, возникла ли ошибка программирования:

  1. Перейдите в приложение контейнера, а затем перейдите к разделу Управление версиями><активный контейнер>>сведения о ревизии>журналы консоли.
  2. Выберите порядок столбцов для отображения времени создания, Stream_sи Log_s.
  3. Сортируйте журналы по дате и найдите сообщения Python stderr и stdout в столбце Stream_s. Выходные данные Python print — это сообщения stdout.

В Azure CLI:

• Используйте команду az containerapp logs show.

Вы хотите остановить непрерывное развертывание

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

На портале Azure:

• Перейдите к приложению-контейнеру. В меню службы выберите непрерывное развертывание, а затем выберите Отключить.

В Azure CLI:

• Используйте команду az container app github-action remove.

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

• Файл .github/workflows/<с именем рабочего процесса>.yml удалён из вашего репозитория.
• Секретные ключи не удаляются из репозитория.
• Приложения контейнеров Azure остаются авторизованным приложением OAuth для учетной записи GitHub.
• В Azure контейнер остается с последним развернутым контейнером. Вы можете повторно подключить приложение-контейнер к экземпляру реестра контейнеров Azure, чтобы новые редакции контейнеров могли получить последний образ.
• В Azure служебные принципы, которые вы создали и использовали для непрерывного развертывания, не удаляются.

Удаление ресурсов

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

Удаление группы ресурсов удаляет все ресурсы в группе и является самым быстрым способом удаления ресурсов. Пример того, как удалить группы ресурсов, см. в разделе Завершение работы с руководством по контейнеризации.

Связанное содержимое

Если вы планируете продолжить изучение этого учебника, вот несколько следующих шагов, которые вы можете предпринять:

• Настройка правил масштабирования в приложениях контейнеров Azure
• Привязка пользовательских доменов и сертификатов в Azure Container Apps
• Мониторинг приложения в приложениях контейнеров Azure