Развертывание настраиваемого контейнера в Службе приложений с помощью GitHub Actions

Статья
06/01/2023

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

Рабочий процесс определяется файлом YAML (.yml) по пути /.github/workflows/ в вашем репозитории. Это определение содержит разные шаги и параметры рабочего процесса.

Для рабочего процесса контейнера Службы приложений Azure файл содержит три раздела:

Раздел	Задачи
Аутентификация	1. Получение субъекта-службы или профиля публикации. 2. Создание секрета GitHub.
Сборка	1. Создание среды. 2. Создание образа контейнера.
Развертывание	1. Развертывание образа контейнера.

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

Учетная запись Azure с активной подпиской. Создание бесплатной учетной записи
Учетная запись GitHub. Если у вас ее нет, зарегистрируйтесь бесплатно. Для развертывания в Службе приложений Azure необходимо иметь код в репозитории GitHub.
Рабочий реестр контейнеров и приложение “Служба приложений Azure” для контейнеров. В этом примере используется Реестр контейнеров Azure. Обязательно выполните полное развертывание в Службе приложений Azure для контейнеров. В отличие от обычных веб-приложений, веб-приложения для контейнеров не имеют целевой страницы по умолчанию. Опубликуйте контейнер, чтобы получить рабочий пример.
- Узнайте, как создать контейнерное приложение Node.js с помощью Docker, отправить образ контейнера в реестр, а затем развернуть образ в Службе приложений Azure

Создание учетных данных для развертывания.

Для проверки подлинности в Службе приложений Azure при работе с GitHub Actions мы рекомендуем использовать профиль публикации. Можно также пройти проверку подлинности с помощью субъекта-службы или Open ID Connect, но этот процесс требует дополнительных действий.

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

Профиль публикации — это учетные данные уровня приложения. Настройте профиль публикации в качестве секрета GitHub.

Перейдите к службе приложений на портале Azure.
На странице Обзор выберите Получить профиль публикации.

Примечание.

По состоянию на октябрь 2020 г. для веб-приложений Linux нужно присваивать параметру приложения WEBSITE_WEBDEPLOY_USE_SCM значение true перед скачиванием файла. В дальнейшем это требование будет отменено. Подробнее о настройке общих параметров веб-приложения см. в разделе Настройка приложения “Служба приложений” на портале Azure.
Сохраните скачанный файл. Содержимое этого файла будет использоваться для создания секрета GitHub.

Вы можете создать субъект-службу с помощью команды az ad sp create-for-rbac в Azure CLI. Чтобы выполнить эту команду, откройте Azure Cloud Shell на портале Azure или нажмите кнопку Попробовать.

az ad sp create-for-rbac --name "myApp" --role contributor \
                            --scopes /subscriptions/<subscription-id>/resourceGroups/<group-name>/providers/Microsoft.Web/sites/<app-name> \
                            --json-auth

В приведенном примере укажите вместо заполнителей соответствующий идентификатор подписки, имя группы ресурсов и имя приложения. Выходные данные содержат объект JSON с учетными данными назначения роли, которые предоставляют доступ к приложению “Служба приложений”. Скопируйте этот объект JSON для последующего использования.

  {
    "clientId": "<GUID>",
    "clientSecret": "<GUID>",
    "subscriptionId": "<GUID>",
    "tenantId": "<GUID>",
    (...)
  }

Внимание

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

Метод проверки подлинности OpenID Connect использует маркеры с коротким сроком жизни. Настройка OpenID Connect с помощью GitHub Actions выполняется сложнее, но зато обеспечивает более безопасную работу.

Если у вас нет существующего приложения, зарегистрируйте новое приложение Active Directory и субъект-службу, который может обращаться к ресурсам. Создайте приложение Azure Active Directory.
```
az ad app create --display-name myApp
```
Эта команда выводит код JSON с объектом appId, который представляет client-id. Сохраните это значение, чтобы позднее применить в качестве секрета GitHub AZURE_CLIENT_ID.

Значение objectId вы примените при создании федеративных учетных данных с помощью API Graph, создав для них ссылку APPLICATION-OBJECT-ID.
Создание субъекта-службы. Замените $appID значением appId из выходных данных в формате JSON.

Эта команда создает выходные данные в формате JSON с другим значением objectId, которое вы примените на следующем шаге. Новое значение objectId представляет assignee-object-id.

Скопируйте appOwnerTenantId, чтобы позднее применить в качестве секрета GitHub AZURE_TENANT_ID.
```
 az ad sp create --id $appId
```
Создайте назначение ролей для подписки и объекта. По умолчанию назначение ролей будет привязано к вашей подписке по умолчанию. Замените $subscriptionId идентификатором подписки, $resourceGroupName именем группы ресурсов и $assigneeObjectId созданным assignee-object-id. Узнайте, как управлять подписками Azure с помощью Azure CLI.
```
az role assignment create --role contributor --subscription $subscriptionId --assignee-object-id  $assigneeObjectId --assignee-principal-type ServicePrincipal --scopes /subscriptions/$subscriptionId/resourceGroups/$resourceGroupName/providers/Microsoft.Web/sites/
```
Выполните следующую команду, чтобы создать федеративные учетные данные удостоверения для своего приложения Active Directory.
- Замените APPLICATION-OBJECT-ID значением objectId (которое было создано при создании приложения) для приложения Active Directory.
- Задайте значение для CREDENTIAL-NAME, оно понадобится позже.
- Задайте subject. Значение этого определяется GitHub в зависимости от рабочего процесса:
  - Задания в среде GitHub Actions: repo:< Organization/Repository >:environment:< Name >.
  - Если задания не привязаны к среде, включите путь ссылки для ветви или тега с учетом пути, используемого для запуска рабочего процесса: repo:< Organization/Repository >:ref:< ref path>. Например, repo:n-username/ node_express:ref:refs/heads/my-branch или repo:n-username/ node_express:ref:refs/tags/my-tag.
  - Для рабочих процессов, запускаемых событием запроса на вытягивание: repo:< Organization/Repository >:pull_request.
```
az rest --method POST --uri 'https://graph.microsoft.com/beta/applications/<APPLICATION-OBJECT-ID>/federatedIdentityCredentials' --body '{"name":"<CREDENTIAL-NAME>","issuer":"https://token.actions.githubusercontent.com","subject":"repo:organization/repository:ref:refs/heads/main","description":"Testing","audiences":["api://AzureADTokenExchange"]}' 
```
Чтобы узнать, как создать приложение Active Directory, субъект-службу и федеративные учетные данные на портале Azure, воспользуйтесь статьей о подключении GitHub к Azure.

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

В GitHub найдите нужный репозиторий. Выберите "Параметры секретов > безопасности > " и переменных > "Действия > нового репозитория".

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

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

- uses: azure/webapps-deploy@v2
  with:
    publish-profile: ${{ secrets.AZURE_WEBAPP_PUBLISH_PROFILE }}

Чтобы использовать учетные данные уровня пользователя, вставьте все выходные данные JSON, полученные из команды Azure CLI, в поле значения секрета. Присвойте секрету имя, например AZURE_CREDENTIALS.

Когда вы позже настроите файл рабочего процесса, этот секрет будет передан в действие входа в Azure как параметр creds. Например:

- uses: azure/login@v1
  with:
    creds: ${{ secrets.AZURE_CREDENTIALS }}

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

Откройте репозиторий GitHub и перейдите к разделу "Параметры секретов > безопасности > " и переменных > Actions > New репозитория.

Создайте секреты для AZURE_CLIENT_ID, AZURE_TENANT_ID и AZURE_SUBSCRIPTION_ID. Используйте эти значения из приложения Active Directory для секретов GitHub. Эти значения можно найти на портале Azure, выполнив поиск приложения Active Directory.

Секрет Github	Приложение Active Directory
AZURE_CLIENT_ID	Идентификатор приложения (клиент)
AZURE_TENANT_ID	Идентификатор каталога (клиента)
AZURE_SUBSCRIPTION_ID	ИД подписки

Сохраните каждый секрет, выбрав Добавить секрет.

Настройка секретов GitHub для реестра

Определите секреты, которые будут использоваться действием входа в Docker. В приведенном здесь примере в качестве реестра контейнеров используется Реестр контейнеров Azure.

Перейдите к контейнеру на портале Azure или Docker и скопируйте имя пользователя и пароль. Имя пользователя и пароль Реестра контейнеров Azure можно найти на портале Azure в разделе Параметры > Ключи доступа для вашего реестра.
Задайте новый секрет для имени пользователя REGISTRY_USERNAME реестра.
Задайте новый секрет для пароля REGISTRY_PASSWORD реестра.

Создание образа контейнера

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

name: Linux Container Node Workflow

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2
    - uses: azure/docker-login@v1
      with:
        login-server: mycontainer.azurecr.io
        username: ${{ secrets.REGISTRY_USERNAME }}
        password: ${{ secrets.REGISTRY_PASSWORD }}
    - run: |
        docker build . -t mycontainer.azurecr.io/myapp:${{ github.sha }}
        docker push mycontainer.azurecr.io/myapp:${{ github.sha }}

Вы также можете использовать вход Docker для входа в несколько реестров контейнеров одновременно. Этот пример включает два новых секрета GitHub для проверки подлинности с помощью docker.io. В этом примере предполагается, что файл Dockerfile находится на корневом уровне реестра.

name: Linux Container Node Workflow

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2
    - uses: azure/docker-login@v1
      with:
        login-server: mycontainer.azurecr.io
        username: ${{ secrets.REGISTRY_USERNAME }}
        password: ${{ secrets.REGISTRY_PASSWORD }}
    - uses: azure/docker-login@v1
      with:
        login-server: index.docker.io
        username: ${{ secrets.DOCKERIO_USERNAME }}
        password: ${{ secrets.DOCKERIO_PASSWORD }}
    - run: |
        docker build . -t mycontainer.azurecr.io/myapp:${{ github.sha }}
        docker push mycontainer.azurecr.io/myapp:${{ github.sha }}

Развертывание в контейнере Службы приложений

Чтобы развернуть образ в настраиваемом контейнере Службы приложений, используйте действие azure/webapps-deploy@v2. У этого действия семь параметров:

Параметр	Описание
app-name	(Обязательный) Имя приложения Службы приложений.
publish-profile	(Необязательный) Применяется к веб-приложениям (Windows и Linux) и контейнерам веб-приложений (Linux). Сценарий с несколькими контейнерами не поддерживается. Файл профиля публикации (*.publishsettings) содержит секреты для веб-развертывания.
slot-name	(Необязательный) Введите существующий слот вместо рабочего.
package	(Необязательный) Применяется только к веб-приложению: путь к пакету или папке. Файлы ZIP, WAR, JAR или папка для развертывания.
images	(Обязательный) Применяется только к контейнерам веб-приложений: Укажите полное имя образа контейнера. Например, myregistry.azurecr.io/nginx:latest или python:3.7.2-alpine/. Для многоконтейнерного приложения можно указать несколько имен образов контейнеров (в несколько строк).
configuration-file	(Необязательный) Применяется только к контейнерам веб-приложений: путь к файлу Docker-Compose. Это должен быть полный путь или путь относительно рабочего каталога по умолчанию. Требуется для приложений с несколькими контейнерами.
startup-command	(Необязательный) Введите команду запуска. Для ex. dotnet run или dotnet filename.dll

name: Linux Container Node Workflow

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2

    - uses: azure/docker-login@v1
      with:
        login-server: mycontainer.azurecr.io
        username: ${{ secrets.REGISTRY_USERNAME }}
        password: ${{ secrets.REGISTRY_PASSWORD }}

    - run: |
        docker build . -t mycontainer.azurecr.io/myapp:${{ github.sha }}
        docker push mycontainer.azurecr.io/myapp:${{ github.sha }}     

    - uses: azure/webapps-deploy@v2
      with:
        app-name: 'myapp'
        publish-profile: ${{ secrets.AZURE_WEBAPP_PUBLISH_PROFILE }}
        images: 'mycontainer.azurecr.io/myapp:${{ github.sha }}'

on: [push]

name: Linux_Container_Node_Workflow

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
    # checkout the repo
    - name: 'Checkout GitHub Action' 
      uses: actions/checkout@main
    
    - name: 'Sign in via Azure CLI'
      uses: azure/login@v1
      with:
        creds: ${{ secrets.AZURE_CREDENTIALS }}
    
    - uses: azure/docker-login@v1
      with:
        login-server: mycontainer.azurecr.io
        username: ${{ secrets.REGISTRY_USERNAME }}
        password: ${{ secrets.REGISTRY_PASSWORD }}
    - run: |
        docker build . -t mycontainer.azurecr.io/myapp:${{ github.sha }}
        docker push mycontainer.azurecr.io/myapp:${{ github.sha }}     
      
    - uses: azure/webapps-deploy@v2
      with:
        app-name: 'myapp'
        images: 'mycontainer.azurecr.io/myapp:${{ github.sha }}'
    
    - name: Azure logout
      run: |
        az logout

on: [push]
name: Linux_Container_Node_Workflow

permissions:
      id-token: write
      contents: read

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
    # checkout the repo
    - name: 'Checkout GitHub Action' 
      uses: actions/checkout@main
    
    - name: 'Sign in via Azure CLI'
      uses: azure/login@v1
      with:
        client-id: ${{ secrets.AZURE_CLIENT_ID }}
        tenant-id: ${{ secrets.AZURE_TENANT_ID }}
        subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
    
    - uses: azure/docker-login@v1
      with:
        login-server: mycontainer.azurecr.io
        username: ${{ secrets.REGISTRY_USERNAME }}
        password: ${{ secrets.REGISTRY_PASSWORD }}
    - run: |
        docker build . -t mycontainer.azurecr.io/myapp:${{ github.sha }}
        docker push mycontainer.azurecr.io/myapp:${{ github.sha }}     
      
    - uses: azure/webapps-deploy@v2
      with:
        app-name: 'myapp'
        images: 'mycontainer.azurecr.io/myapp:${{ github.sha }}'
    
    - name: Azure logout
      run: |
        az logout

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

Вы можете найти наш набор компонентов Actions, объединенных в разных репозитории, а также соответствующую документацию и примеры использования GitHub для CI/CD и развертыванию приложений в Azure на GitHub.

Поделиться через