Использование CI/CD с GitHub Actions для развертывания веб-приложения Python в службе приложение Azure в Linux

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

Создание репозитория для кода приложения

Если у вас уже есть веб-приложение Python, убедитесь, что он зафиксирован в репозитории GitHub.

Если вам нужно, чтобы приложение работало, вы можете клонировать репозиторий и клонировать его https://github.com/Microsoft/python-sample-vscode-flask-tutorial. Код представлен в руководстве Flask в Visual Studio Code.

Примечание.

Если приложение использует Django и базу данных SQLite, она не будет работать в этом руководстве. Если приложение Django использует отдельную базу данных, например PostgreSQL, ее можно использовать с этим руководством. Дополнительные сведения о Django см . в рекомендациях по Django далее в этой статье.

Создание целевой службы приложение Azure

Самый быстрый способ создания экземпляра Служба приложений — использовать интерфейс командной строки Azure с помощью интерактивной azure Cloud Shell. Cloud Shell включает Git и Azure CLI. В следующих шагах вы будете использовать az webapp для создания Служба приложений и выполнения первого развертывания приложения.

Шаг 1. Войдите на портал Azure по адресу https://portal.azure.com.

Шаг 2. Откройте Azure CLI, выбрав значок Cloud Shell на панели инструментов портала.

Screenshot showing how to open Azure Cloud Shell in Azure portal.

Шаг 3. В Cloud Shell выберите Bash из раскрывающегося списка.

Screenshot showing an Azure Cloud Shell Bash shell in Azure portal.

Шаг 4. В Cloud Shell клонируйте репозиторий с помощью клона git. Например, если вы используете пример приложения Flask, выполните следующую команду:

git clone https://github.com/<github-user>/python-sample-vscode-flask-tutorial.git

Замените <github-user> именем учетной записи GitHub, в которой вы вкнули репозиторий. Если вы используете другой репозиторий приложений, это репозиторий, где вы настроите GitHub Actions.

Примечание.

Cloud Shell поддерживается учетной записью служба хранилища Azure в группе ресурсов, называемой cloud-shell-storage-your-region<>. Эта учетная запись хранения содержит образ файловой системы Cloud Shell, в которой хранятся клонированные репозитории. Для этого хранилища существует небольшая стоимость. Вы можете удалить учетную запись хранения в конце этой статьи, а также другие ресурсы, которые вы создаете.

Совет

Чтобы вставить в Cloud Shell, нажмите клавиши CTRL+SHIFT+V или щелкните правой кнопкой мыши и выберите команду "Вставить" в контекстном меню.

Шаг 5. В Cloud Shell измените каталог в папку репозитория с приложением Python, чтобы команда az webapp up распознала приложение как Python. Например, для примера приложения Flask:

cd python-sample-vscode-flask-tutorial

Шаг 6. В Cloud Shell используйте az webapp up для создания Служба приложений и первоначального развертывания приложения.

az webapp up --name <app-service-name> --runtime "PYTHON:3.9"

Укажите Служба приложений имя, уникальное в Azure. Имя должно быть длиной 3–60 символов и может содержать только буквы, цифры и дефисы. Имя должно начинаться с буквы или цифры и заканчиваться буквой или цифрой.

Используется az webapp list-runtimes для получения списка доступных сред выполнения. PYTHON|X.Y Используйте формат, где X.Y находится версия Python.

Вы также можете указать расположение Служба приложений с параметром--location. az account list-locations --output table Используйте команду, чтобы получить список доступных расположений.

Шаг 7. Если приложение использует пользовательскую команду запуска, используйте команду az webapp config , используя следующую команду. Если у приложения нет пользовательской команды запуска, пропустите этот шаг.

Например, приложение python-sample-vscode-flask-tutorial содержит файл с именем startup.txt , содержащий команду запуска, которую можно использовать следующим образом:

az webapp config set \
  --resource-group <resource-group-name> \
  --name <app-service-name> \
  --startup-file startup.txt

Имя группы ресурсов можно найти из выходных данных предыдущей az webapp up команды. Имя группы ресурсов начнется с <azure-account-name>_rg_.

Шаг 8. Чтобы просмотреть работающее приложение, откройте браузер и перейдите к http:// app-service-name.azurewebsites.net>.<

Если отображается универсальная страница, подождите несколько секунд до начала Служба приложений и обновите страницу. Если вы продолжаете видеть универсальную страницу, проверка, развернутую из правильной папки. Например, если вы используете пример приложения Flask, папка — python-sample-vscode-flask-tutorial. Кроме того, для примера приложения Flask проверка правильно задать команду запуска.

Настройка непрерывного развертывания в Служба приложений

В приведенных ниже шагах вы настроите непрерывное развертывание (CD), что означает, что при активации рабочего процесса происходит новое развертывание кода. Триггер в этом руководстве — это любое изменение основной ветви репозитория, например с запросом на вытягивание (PR).

Шаг 1. Добавьте действие GitHub с помощью команды az webapp deployment github-actions.

az webapp deployment github-actions add \
  --repo "<github-user>/<github-repo>" \
  --resource-group <resource-group-name> \
  --branch <branch-name> \
  --name <app-service-name> \
  --login-with-github

Параметр --login-with-github использует интерактивный метод для получения личного маркера доступа. Следуйте инструкциям, чтобы завершить проверку подлинности.

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

Что делает команда добавления:

  • Создает новый файл рабочего процесса: .github/workflows/<workflow-name.yml> в репозитории; имя файла будет содержать имя Служба приложений.
  • Извлекает профиль публикации с секретами для Служба приложений и добавляет его в качестве секрета действия GitHub. Имя секрета начинается с AZUREAPPSERVICE_PUBLISHPROFILE_. Этот секрет ссылается на файл рабочего процесса.

Шаг 2. Получите сведения о конфигурации развертывания системы управления версиями с помощью команды az webapp deployment source show .

az webapp deployment source show \
  --name <app-service-name> \
  --resource-group <resource-group-name>

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

Описание рабочего процесса и действий GitHub

Рабочий процесс определяется файлом YAML (yml) в файле /.github/workflows/ path в репозитории. Этот ФАЙЛ YAML содержит различные шаги и параметры, составляющие рабочий процесс, автоматизированный процесс, связанный с репозиторием GitHub. Вы можете создавать, тестировать, упаковывать, выпускать и развертывать любой проект на GitHub с помощью рабочего процесса.

Каждый рабочий процесс состоит из одного или нескольких заданий. Каждое задание, в свою очередь, представляет собой набор шагов. И, наконец, каждый шаг — это скрипт оболочки или действие.

С точки зрения рабочего процесса, настроенного с помощью кода Python для развертывания в Служба приложений, рабочий процесс имеет следующие действия:

Действие Description
проверка out Ознакомьтесь с репозиторием в средстве выполнения, агенте GitHub Actions.
setup-python Установите Python в средстве выполнения.
appservice-build Создайте веб-приложение.
webapps-deploy Разверните веб-приложение с помощью учетных данных профиля публикации для проверки подлинности в Azure. Учетные данные хранятся в секрете GitHub.

Шаблон рабочего процесса, используемый для создания рабочего процесса, — azure /actions-workflow-samples.

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

on:
  push:
    branches:
    - main

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

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

Screenshot showing how to view authorized OAuth Apps for a GitHub account.

Секрет профиля публикации рабочего процесса

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

Screenshot showing how to view action secrets in GitHub.

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

Запуск рабочего процесса

Теперь вы протестируете рабочий процесс, внося изменения в репозиторий.

Шаг 1. Перейдите в вилку примера репозитория (или используемый репозиторий) и выберите ветвь, которую вы задали в качестве части триггера.

Screenshot showing how to go to the repo and branch where the GitHub Actions workflow is defined.

Шаг 2. Сделайте небольшое изменение.

Например, если вы использовали учебник VS Code Flask, вы можете

  • Перейдите в файл /hello-app/templates/home.html ветви триггера.
  • Выберите "Изменить " и добавьте текст "Повторно развернуто!".

Шаг 3. Зафиксируйте изменение непосредственно в ветвь, в которую вы работаете.

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

Вы также можете запустить рабочий процесс вручную.

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

Шаг 2. Выберите рабочий процесс в списке рабочих процессов и выберите команду "Выполнить рабочий процесс".

Устранение неполадок с неудачным рабочим процессом

Чтобы проверка состояние рабочего процесса, перейдите на вкладку "Действия" репозитория. При детализации файла рабочего процесса, созданного в этом руководстве, вы увидите два задания "сборка" и "развертывание". Для неудачного задания просмотрите выходные данные задач задания для указания сбоя. К наиболее распространенным проблемам относятся:

  • Если приложение завершается ошибкой из-за отсутствующих зависимостей, файл requirements.txt не был обработан во время развертывания. Это происходит, если вы создали веб-приложение непосредственно на портале, а не с помощью az webapp up команды, как показано в этой статье.

  • Если вы подготовили службу приложений на портале, возможно, не задано действие сборки SCM_DO_BUILD_DURING_DEPLOYMENT. Этот параметр должен иметь значение true. Команда az webapp up автоматически задает действие сборки.

  • Если отображается сообщение об ошибке с временем ожидания подтверждения TLS, запустите рабочий процесс вручную, выбрав автоматическое развертывание триггера на вкладке "Действия" репозитория, чтобы узнать, является ли время ожидания временным.

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

Запуск скрипта после развертывания

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

Чтобы избежать жесткого кодирования значений переменных в файле YML рабочего процесса, их можно использовать в веб-интерфейсе GitHub, а затем ссылаться на имя переменной в скрипте. Вы можете создать зашифрованные секреты для репозитория или среды (репозиторий учетных записей). Дополнительные сведения см. в разделе "Зашифрованные секреты" в документации GitHub.

Рекомендации по Django

Как отмечалось ранее в этой статье, вы можете использовать GitHub Actions для развертывания приложений Django для приложение Azure службы в Linux, если вы используете отдельную базу данных. Невозможно использовать базу данных SQLite, так как Служба приложений блокирует файл db.sqlite3, предотвращая операции чтения и записи. Это поведение не влияет на внешнюю базу данных.

Как описано в статье Настройка приложения Python на Служба приложений — процесс запуска контейнера, Служба приложений автоматически ищет файл wsgi.py в коде приложения, который обычно содержит объект приложения. При использовании команды для задания команды запуска параметр использовался webapp config set--startup-file для указания файла, содержащего объект приложения. Команда webapp config set недоступна в действии webapps-deploy. Вместо этого можно использовать startup-command параметр для указания команды запуска. Например, в следующем фрагменте кода показано, как указать команду запуска в файле рабочего процесса:

startup-command: startup.txt

При использовании Django обычно требуется перенести модели данных с помощью python manage.py migrate команды после развертывания кода приложения. Вы можете выполнить команду миграции в скрипте после развертывания.

Отключение действий GitHub

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

Отключите GitHub Actions с помощью Azure CLI az webapp deployment github-actions remove command.

az webapp deployment github-actions remove \
  --repo "<github-user>/<github-repo>" \
  --resource-group <resource-group-name> \
  --branch <branch-name> \
  --name <app-service-name> \
  --login-with-github

Очистка ресурсов

Чтобы избежать возникновения расходов на ресурсы Azure, созданные в этом руководстве, удалите группу ресурсов, содержащую Служба приложений и план Служба приложений.

В любом месте, где установлен Azure CLI, включая Azure Cloud Shell, можно использовать команду az group delete для удаления группы ресурсов.

az group delete --name <resource-group-name>

Чтобы удалить учетную запись хранения, которая поддерживает файловую систему для Cloud Shell, которая несет небольшую ежемесячную плату, удалите группу ресурсов, которая начинается с cloud-shell-storage-. Если вы являетесь единственным пользователем группы, это безопасно удалить группу ресурсов. Если есть другие пользователи, вы можете удалить учетную запись хранения в группе ресурсов.

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

  • В репозитории удалите файл .github/workflows/<workflow-name.yml>.
  • В параметрах репозитория удалите ключ секрета AZUREAPPSERVICE_PUBLISHPROFILE_, созданный для рабочего процесса.
  • В параметрах учетной записи GitHub удалите службу приложение Azure в качестве авторизованного приложения Oauth для учетной записи GitHub.