配置 GitHub 操作以创建容器实例

项目
02/05/2024

Github 操作是 GitHub 中的一个功能套件，可以在存储代码的同一位置自动执行软件开发工作流，并针对拉取请求和问题进行协作。

使用 GitHub 操作部署到 Azure 容器实例可以自动将单个容器部署到 Azure 容器实例。该操作可为容器实例设置属性（类似于在 az container create 命令中设置的属性）。

本文介绍了如何在 GitHub 存储库中设置用于执行以下操作的工作流：

基于 Dockerfile 生成映像
将映像推送到 Azure 容器注册表
将容器映像部署到 Azure 容器实例

本文将介绍设置工作流的两种方式：

配置 GitHub 工作流 - 使用“部署到 Azure 容器实例”操作和其他操作在 GitHub 存储库中创建工作流。
使用 CLI 扩展 - 使用 Azure CLI 的部署到 Azure 扩展中的 az container app up 命令。此命令简化了 GitHub 工作流的创建和部署步骤。

重要

适用于 Azure 容器实例的 GitHub Actions 目前为预览版。需同意补充使用条款才可使用预览版。在正式版 (GA) 推出之前，此功能的某些方面可能会有所更改。

先决条件

GitHub 帐户 - 如果没有帐户，请在 https://github.com 上创建一个帐户。
Azure CLI - 可以使用 Azure CLI 的本地安装来完成 Azure CLI 步骤。如果需要进行安装或升级，请参阅安装 Azure CLI。
Azure 容器注册表 - 如果没有 Azure 容器注册表，请使用 Azure CLI、Azure 门户或其他方法在基本层中创建一个容器注册表。记下用于部署的资源组，因为在 GitHub 工作流中需要使用它。

设置存储库

对于本文中的示例，请使用 GitHub 创建以下存储库的分支： https://github.com/Azure-Samples/acr-build-helloworld-node

此存储库包含用来为小型 Web 应用创建容器映像的 Dockerfile 和源文件。
确保为你的存储库启用“操作”。导航到你的分支存储库，并选择“设置”>“操作”。在“操作权限”中，确保选中“允许所有操作”。

配置 GitHub 工作流

在 GitHub 工作流中，需要提供 Azure 凭据，以便在 Azure CLI 中进行身份验证。以下示例创建一个服务主体，其“参与者”角色作用域限定为你的容器注册表的资源组。

首先获取你的资源组的资源 ID。请将以下 az group show 命令中的占位符替换为你的组名称：

groupId=$(az group show \
  --name <resource-group-name> \
  --query id --output tsv)

使用 az ad sp create-for-rbac 创建服务主体：

az ad sp create-for-rbac \
  --scope $groupId \
  --role Contributor \
  --json-auth

输出类似于：

{
  "clientId": "xxxx6ddc-xxxx-xxxx-xxx-ef78a99dxxxx",
  "clientSecret": "xxxx79dc-xxxx-xxxx-xxxx-aaaaaec5xxxx",
  "subscriptionId": "xxxx251c-xxxx-xxxx-xxxx-bf99a306xxxx",
  "tenantId": "xxxx88bf-xxxx-xxxx-xxxx-2d7cd011xxxx",
  "activeDirectoryEndpointUrl": "https://login.chinacloudapi.cn",
  "resourceManagerEndpointUrl": "https://management.chinacloudapi.cn/",
  "activeDirectoryGraphResourceId": "https://graph.chinacloudapi.cn/",
  "sqlManagementEndpointUrl": "https://management.core.chinacloudapi.cn:8443/",
  "galleryEndpointUrl": "https://gallery.chinacloudapi.cn/",
  "managementEndpointUrl": "https://management.core.chinacloudapi.cn/"
}

保存 JSON 输出，因为在稍后的步骤中需要使用它。另请记下 clientId，在下一部分更新服务主体时需要使用它。

OpenID Connect 是一种使用短期令牌的身份验证方法。使用 GitHub Actions 设置 OpenID Connect 的过程会更复杂，能提供更强的安全性。

如果没有现有的应用程序，请注册一个可访问资源的新 Active Directory 应用程序和服务主体。创建 Active Directory 应用程序。
```
az ad app create --display-name myApp
```
此命令将输出 JSON，其中 appId 为你的 client-id。保存该值，稍后将其用作 AZURE_CLIENT_ID GitHub 机密。

使用图形 API 创建联合凭据时，将使用 objectId 值，并将其引用为 APPLICATION-OBJECT-ID。
创建服务主体。将 $appID 替换为 JSON 输出中的 appId。

此命令使用不同的 objectId 生成 JSON 输出，将在下一步中使用。新的 objectId 是 assignee-object-id。

复制 appOwnerTenantId 以在稍后用作 AZURE_TENANT_ID 的 GitHub 机密。
```
 az ad sp create --id $appId
```
按订阅和对象创建新的角色分配。默认情况下，角色分配将绑定到默认订阅。将 $subscriptionId 替换为你的订阅 ID，将 $resourceGroupName 替换为你的资源组名称，将 $assigneeObjectId 替换为生成的 assignee-object-id。了解如何使用 Azure CLI 管理 Azure 订阅。
```
az role assignment create --role contributor --subscription $subscriptionId --assignee-object-id  $assigneeObjectId --scope /subscriptions/$subscriptionId/resourceGroups/$resourceGroupName/providers/Microsoft.Web/sites/ --assignee-principal-type ServicePrincipal
```
运行以下命令，为 Active Directory 应用程序创建新的联合标识凭据。
- 将 APPLICATION-OBJECT-ID 替换为 Active Directory 应用程序的 objectId（在创建应用时生成）。
- 为 CREDENTIAL-NAME 设置一个值供以后引用。
- 设置 subject。此项的值由 GitHub 根据工作流定义：
  - GitHub Actions 环境中的作业：repo:< Organization/Repository >:environment:< Name >
  - 对于未绑定到环境的作业，请根据用于触发工作流的 ref 路径包括分支/标记的 ref 路径：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 ad app federated-credential create --id <APPLICATION-OBJECT-ID> --parameters credential.json
("credential.json" contains the following content)
{
    "name": "<CREDENTIAL-NAME>",
    "issuer": "https://token.actions.githubusercontent.com/",
    "subject": "repo:organization/repository:ref:refs/heads/main",
    "description": "Testing",
    "audiences": [
        "api://AzureADTokenExchange"
    ]
}
```

若要了解如何在 Azure 门户中创建 Active Directory 应用程序、服务主体和联合凭据，请参阅连接 GitHub 和 Azure。

注册表身份验证更新

服务主体
OpenID Connect

更新 Azure 服务主体凭据，以允许对容器注册表进行推送和拉取访问。此步骤允许 GitHub 工作流使用服务主体向容器注册表进行身份验证并推送和拉取 Docker 映像。

获取你的容器注册表的资源 ID。请将以下 az acr show 命令中的占位符替换为你的注册表名称：

registryId=$(az acr show \
  --name <registry-name> \
  --resource-group <resource-group-name> \
  --query id --output tsv)

使用 az role assignment create 分配 AcrPush 角色，此角色授予对注册表的推送和拉取访问权限。替换为你的服务主体的客户端 ID：

az role assignment create \
  --assignee <ClientId> \
  --scope $registryId \
  --role AcrPush

需要授予你的应用程序访问 Azure 容器注册表和创建 Azure 容器实例的权限。

在 Azure 门户中，转到应用注册。
搜索 OpenID Connect 应用注册并复制应用程序（客户端）ID。

向资源组授予应用的权限。需要在资源组级别设置权限，以便可以创建 Azure 容器实例。

az role assignment create \
--assignee <appID> \
--role Contributor \
 --scope /subscriptions/<subscription-id>/resourceGroups/<resource-group>

将凭据保存到 GitHub 存储库

服务主体
OpenID Connect

在 GitHub UI 中，导航到分支存储库并选择“安全性”>“机密和变量”>“操作”。

选择“新建存储库机密”，以添加以下机密：

Secret	Value
`AZURE_CREDENTIALS`	创建服务主体步骤后显示的整个 JSON 输出
`REGISTRY_LOGIN_SERVER`	注册表的登录服务器名称（全小写）。示例：myregistry.azurecr.cn
`REGISTRY_USERNAME`	创建服务主体后显示的 JSON 输出中的 `clientId`
`REGISTRY_PASSWORD`	创建服务主体后显示的 JSON 输出中的 `clientSecret`
`RESOURCE_GROUP`	用来限定服务主体作用域的资源组名称

需要向登录操作提供应用程序的“客户端 ID”、“租户 ID”和“订阅 ID” 。这些值可直接在工作流中提供，或可存储在 GitHub 机密中并在工作流中引用。将这些值保存为 GitHub 机密是更安全的选择。

打开 GitHub 存储库，然后转到“设置”>“安全性”>“机密和变量”>“操作”>“新建存储库机密”。
为 AZURE_CLIENT_ID、AZURE_TENANT_ID 和 AZURE_SUBSCRIPTION_ID 创建机密。将 Active Directory 应用程序中的这些值用于 GitHub 机密：

GitHub 机密 Active Directory 应用程序

AZURE_CLIENT_ID 应用程序（客户端）ID

AZURE_TENANT_ID 目录（租户）ID

AZURE_SUBSCRIPTION_ID 订阅 ID
通过选择“添加机密”来保存每个机密。

GitHub 机密	Active Directory 应用程序
AZURE_CLIENT_ID	应用程序（客户端）ID
AZURE_TENANT_ID	目录（租户）ID
AZURE_SUBSCRIPTION_ID	订阅 ID

创建工作流文件

在 GitHub UI 中，选择“操作”。
选择“自己设置工作流”。
在“编辑新文件”中，粘贴以下 YAML 内容并覆盖示例代码。接受默认文件名 main.yml，或提供你选择的文件名。
选择“开始提交”，并提供你的提交内容的简短或详细说明（可选），然后选择“提交新文件”。

服务主体
OpenID Connect

on: [push]
name: Linux_Container_Workflow

jobs:
    build-and-deploy:
        runs-on: ubuntu-latest
        steps:
        # checkout the repo
        - name: 'Checkout GitHub Action'
          uses: actions/checkout@main

        - name: 'Login via Azure CLI'
          uses: azure/login@v1
          with:
            creds: ${{ secrets.AZURE_CREDENTIALS }}

        - name: 'Build and push image'
          uses: azure/docker-login@v1
          with:
            login-server: ${{ secrets.REGISTRY_LOGIN_SERVER }}
            username: ${{ secrets.REGISTRY_USERNAME }}
            password: ${{ secrets.REGISTRY_PASSWORD }}
        - run: |
            docker build . -t ${{ secrets.REGISTRY_LOGIN_SERVER }}/sampleapp:${{ github.sha }}
            docker push ${{ secrets.REGISTRY_LOGIN_SERVER }}/sampleapp:${{ github.sha }}

        - name: 'Deploy to Azure Container Instances'
          uses: 'azure/aci-deploy@v1'
          with:
            resource-group: ${{ secrets.RESOURCE_GROUP }}
            dns-name-label: ${{ secrets.RESOURCE_GROUP }}${{ github.run_number }}
            image: ${{ secrets.REGISTRY_LOGIN_SERVER }}/sampleapp:${{ github.sha }}
            registry-login-server: ${{ secrets.REGISTRY_LOGIN_SERVER }}
            registry-username: ${{ secrets.REGISTRY_USERNAME }}
            registry-password: ${{ secrets.REGISTRY_PASSWORD }}
            name: aci-sampleapp
            location: 'China East 2 '

on: [push]
name: Linux_Container_Workflow_OIDC

permissions:
  id-token: write
  contents: read

on:
  push:
    branches:
    - main
    - release/*

jobs:
    build-and-deploy:
        runs-on: ubuntu-latest
        steps:
        - name: 'Checkout GitHub Action'
          uses: actions/checkout@main

        - name: 'Login 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 }}

        - name: Build and push image
          id: build-image
          run: |
           az acr build --image ${{ secrets.REGISTRY_LOGIN_SERVER }}/sampleapp:${{ github.sha }} --registry ${{ secrets.REGISTRY_LOGIN_SERVER }} --file "Dockerfile" .

        - name: 'Deploy to Azure Container Instances'
          uses: 'azure/aci-deploy@v1'
          with:
           resource-group: ${{ secrets.RESOURCE_GROUP }}
           dns-name-label: ${{ secrets.RESOURCE_GROUP }}${{ github.run_number }}
           image: ${{ secrets.REGISTRY_LOGIN_SERVER }}/sampleapp:${{ github.sha }}
           registry-login-server: ${{ secrets.REGISTRY_LOGIN_SERVER }}
           registry-username: ${{ secrets.REGISTRY_USERNAME }}
           registry-password: ${{ secrets.REGISTRY_PASSWORD }}
           name: aci-sampleapp
           location: 'China East 2 '

验证工作流

提交工作流文件后，会触发该工作流。若要查看工作流进度，请导航到“操作”>“工作流”。

View workflow progress

若要了解如何查看工作流中每个步骤的状态和结果，请参阅查看工作流运行历史记录。如果工作流未完成，请参阅查看日志以诊断故障。

工作流成功完成后，运行 az container show 命令获取有关名为 aci-sampleapp 的容器实例的信息。替换为你的资源组名称：

az container show \
  --resource-group <resource-group-name> \
  --name aci-sampleapp \
  --query "{FQDN:ipAddress.fqdn,ProvisioningState:provisioningState}" \
  --output table

输出类似于：

FQDN                                                     ProvisioningState
-------------------------------------------------------  -------------------
aci-action01.chinaeast2.azurecontainer.console.azure.cn  Succeeded

预配实例后，在浏览器中导航到容器的 FQDN，以查看正在运行的 Web 应用。

Running web app in browser

使用“部署到 Azure”扩展

另外，也可以使用 Azure CLI 中的“部署到 Azure”扩展来配置工作流。该扩展中的 az container app up 命令采用你的输入参数来设置一个工作流，以部署到 Azure 容器实例。

Azure CLI 创建的工作流类似于可以使用 GitHub 手动创建的工作流。

其他先决条件

对于此方案，除了满足先决条件并完成存储库设置以外，还需要安装 Azure CLI 的“部署到 Azure”扩展。

请运行 az extension add 命令来安装该扩展：

az extension add \
  --name deploy-to-azure

有关查找、安装和管理扩展的信息，请参阅在 Azure CLI 中使用扩展。

运行 `az container app up`

若要运行 az container app up 命令，请至少提供：

Azure 容器注册表的名称，例如 myregistry
GitHub 存储库的 URL，例如 https://github.com/<your-GitHub-Id>/acr-build-helloworld-node

示例命令：

az container app up \
  --acr myregistry \
  --repository https://github.com/myID/acr-build-helloworld-node

命令进度

出现提示时，请提供你的 GitHub 凭据，或提供具有“存储库”和“用户”作用域的 GitHub 个人访问令牌 (PAT)，以便向 GitHub 帐户进行身份验证。如果提供了 GitHub 凭据，该命令将为你创建一个 PAT。按照附加提示配置工作流。
该命令将为工作流创建存储库机密：
- 用于 Azure CLI 的服务主体凭据
- 用于访问 Azure 容器注册表的凭据
在该命令将工作流文件提交到存储库后，会触发工作流。

输出类似于：

[...]
Checking in file github/workflows/main.yml in the GitHub repository myid/acr-build-helloworld-node
Creating workflow...
GitHub Action Workflow has been created - https://github.com/myid/acr-build-helloworld-node/runs/515192398
GitHub workflow completed.
Workflow succeeded
Your app is deployed at:  http://acr-build-helloworld-node.chinaeast2.azurecontainer.console.azure.cn:8080/

若要在 GitHub UI 中查看每个步骤的工作流状态和结果，请参阅查看工作流运行历史记录。

验证工作流

工作流使用 GitHub 存储库的基名称（在本例中为 acr-build-helloworld-node）部署 Azure 容器实例。工作流成功完成后，运行 az container show 命令获取有关名为 acr-build-helloworld-node 的容器实例的信息。替换为你的资源组名称：

az container show \
  --resource-group <resource-group-name> \
  --name acr-build-helloworld-node \
  --query "{FQDN:ipAddress.fqdn,ProvisioningState:provisioningState}" \
  --output table

输出类似于：

FQDN                                                                     ProvisioningState
------------------------------------------------------------------       -------------------
acr-build-helloworld-node.chinaeast2.azurecontainer.console.azure.cn     Succeeded

预配实例后，在浏览器中导航到容器的 FQDN，以查看正在运行的 Web 应用。

清理资源

使用 az container delete 命令停止容器实例：

az container delete \
  --name <instance-name>
  --resource-group <resource-group-name>

若要删除资源组及其包含的所有资源，请运行 az group delete 命令：

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

后续步骤

浏览 GitHub 市场，了解用于自动执行开发工作流的其他操作

配置 GitHub 操作以创建容器实例

先决条件

设置存储库

配置 GitHub 工作流

为 Azure 身份验证创建凭据

注册表身份验证更新

将凭据保存到 GitHub 存储库

创建工作流文件

验证工作流

使用“部署到 Azure”扩展

其他先决条件

运行 az container app up

命令进度

验证工作流

清理资源

后续步骤

其他资源

运行 `az container app up`