GitHub操作Azure容器应用生成部署

　　本教程介绍如何使用 GitHub 操作部署 Azure 容器应用。我将提供有关如何生成自定义 Github 操作工作流以将容器应用部署到 Azure 的示例和分步说明。这将介绍如何根据需要为容器部署创建自己的操作。
　　一些假设： 你有一个 Azure 帐户。 您有一个 GitHub 帐户。 你有 Azure CLI。 你有权在要部署到的 Azure 订阅中创建资源和服务主体。 您有一个映像存储库，您可以在其中存储容器映像。 您有要部署的代码。
　　下面是用于部署容器应用的操作工作流示例： # The name of the deployment name: Trigger auto deployment for containerapps  # When this action will be executed on:   # Automatically trigger it when detected changes in repo   push:     # Branched to look out for changes on     branches:        [ main ]    # Allow manually trigger of the jobs   workflow_dispatch:        jobs:   # Job run image.     build:       runs-on: ubuntu-latest     # Steps that need to happen in this job run.       steps:         # Check out the code         - name: Check out code           uses: actions/checkout@v2          # Log in to Azure CLI         - name: Log in to Azure           uses: azure/login@v1           with:       # Azure CLI credentials             creds: ${{ secrets.AZURE_CREDENTIALS }}          # Build and deploy the container app         - name: Build and deploy Container App           uses: azure/container-apps-deploy-action@v0           with:             appSourcePath: ${{ github.workspace }}             acrName:              acrUsername: ${{ secrets.REGISTRY_USERNAME }}             acrPassword: ${{ secrets.REGISTRY_PASSWORD }}             containerAppName:              containerAppEnvironment:              resourceGroup:              imageToBuild: /:             dockerfilePath: /Path/to/Dockerfile
　　这是相当多的，所以让我们解开它。 GitHub 操作文件结构工作流名称
　　name: Trigger auto deployment for containerapps
　　这是要为部署运行指定的名称。 工作流触发器# When this action will be executed on:   # Automatically trigger it when detected changes in repo   push:     # Branched to look out for changes on     branches:        [ main ]    # Allow manually trigger of the jobs   workflow_dispatch:
　　worflow 触发器是你选择触发部署的方式。此示例基于我将代码推送到主分支创建一个触发器;可以根据触发部署的分支进行设置。也可以使用通配符，例如： branches:       - main       - ＂releases/**＂
　　这允许您在 GitHub 操作中手动触发工作流。当我对基础结构进行更改并且需要再次触发部署时，我发现这特别有用。workflow_dispatch
　　您可以在此处阅读有关工作流触发器的更多信息：
　　触发工作流的事件 - GitHub 文档 工作
　　这是一组需要运行的步骤。您可以有一个或多个作业。
　　上面的例子只有一个名为＂build＂的作业，它构建和部署项目并在 ubuntu 映像上运行。
　　默认情况下，这些作业并行运行，但您可以使用 needs： 关键字创建对其他作业的依赖关系。您还可以有条件地运行作业。 jobs:   review:     name: Deploy/Review    staging:     name: Deploy/Staging    production:     name: Deploy/Production     if: ${{ always() }}     needs: [staging, review]
　　在上图中，＂部署/暂存＂、＂部署/查看＂和＂部署/生产＂块是作业。
　　您可以在此处阅读有关工作的更多信息：
　　在工作流中使用作业 - GitHub 文档 步骤
　　这些是需要作为作业的一部分运行的任务。在这种情况下，我们有 3 个步骤需要作为作业的一部分运行。 签出代码 登录到 Azure 生成和部署容器应用
　　这些操作可以包含来自市场的操作或自定义操作，但在本例中，我们使用标准市场操作。
　　＂签出代码＂步骤将运行此操作的存储库中的代码签出到运行生成/部署的容器中。
　　＂登录到 Azure＂步骤将你登录到 azure CLI，并为部署提供用于部署容器应用的访问令牌。
　　＂生成和部署容器应用＂将在下一节中生成和部署容器应用，我们将更详细地介绍其用途。 凭据和机密设置
　　首先，我们需要在 Azure 中创建服务主体。最好的方法是使用此 Azure CLI。
　　请确保已登录到要部署容器应用的订阅。
　　然后运行以下命令来创建服务主体： az ad sp create-for-rbac --name ＂myApp＂ --role contributor                              --scopes /subscriptions/{subscription-id}/resourceGroups/{resource-group}                              --sdk-auth
　　将 and 替换为要分别部署到的订阅 ID 和资源组。还应替换为服务原则名称。{subscription-id}{resource-group}myApp
　　此命令将创建一个 RBAC（基于角色的访问控制）服务主体，然后该主体对订阅和资源组具有参与者访问权限。
　　然后，您将获得如下所示的输出。您应该小心 不要共享 此信息，因为它是敏感信息。您需要 保留它 ，因为您很快就会使用它。 {    ＂clientId＂: ＂＂,    ＂clientSecret＂: ＂＂,    ＂subscriptionId＂: ＂＂,    ＂tenantId＂: ＂＂,    ＂resourceManagerEndpointUrl＂: ＂＂    (...)  }
　　现在，在存储库的 GitHub 中创建机密，以便将其用于操作。 单击要部署的存储库。 导航到＂设置＂ 然后在＂安全性＂下展开＂机密和变量＂ 点击＂操作＂ 在＂机密＂选项卡上，单击＂新建存储库机密＂ 创建名为＂ AZURE_CREDENTIALS ＂的密钥 使机密值成为您通过创建服务原则获得的值。
　　仅当要使用容器注册表时，才需要此部分。
　　创建机密时，还需要 2 个。＂ REGISTRY_USERNAME ＂和＂ REGISTRY_PASSWORD ＂。这可以从 Azure 容器注册表获取。
　　REGISTRY_USERNAME 是注册表用户的用户名。
　　REGISTRY_PASSWORD是注册表用户的密码。 最低限度
　　工作流页面的前半部分应如下所示： # The name of the deployment name: Trigger auto deployment for containerapps  # When this action will be executed on:   # Automatically trigger it when detected changes in repo   push:     # Branched to look out for changes on     branches:        [ main ]    # Allow mannually trigger of the jobs   workflow_dispatch:        jobs:         # Job run image.     build:       runs-on: ubuntu-latest
　　添加的以下步骤将基于不同的方案。
　　因此，让我们从前三个开始。
　　1.） 您正在部署具有公共注册表访问权限的现有容器映像。 steps:    - name: Log in to Azure     uses: azure/login@v1     with:       creds: ${{ secrets.AZURE_CREDENTIALS }}    - name: Build and deploy Container App     uses: azure/container-apps-deploy-action@v0     with:       imageToDeploy: mcr.microsoft.com/azuredocs/containerapps-helloworld:latest
　　2.） 您正在构建和部署映像。 steps:    - name: Log in to Azure     uses: azure/login@v1     with:       creds: ${{ secrets.AZURE_CREDENTIALS }}    - name: Build and deploy Container App     uses: azure/container-apps-deploy-action@v0     with:       appSourcePath: ${{ github.workspace }}       acrName: mytestacr
　　3.） 您没有 dockerfile 或构建的映像，但您有运行时堆栈。 steps:    - name: Log in to Azure     uses: azure/login@v1     with:       creds: ${{ secrets.AZURE_CREDENTIALS }}    - name: Build and deploy Container App     uses: azure/container-apps-deploy-action@v0     with:       appSourcePath: ${{ github.workspace }}       acrName: mytestacr       runtimeStack: ＂dotnetcore:7.0＂
　　在这些情况下，如果没有手动或通过以前的运行创建容器应用、容器环境或资源组，它将为你创建这些资源。
　　资源将按如下方式命名： Container App ： github-action-container-app-- 资源组： <容器应用名称>-rg 容器应用环境： <容器应用名称>-环境
　　我发现这在大多数情况下并不理想，所以让我们看看我们需要给它什么才能不创建这些。 其他参数
　　因此，若要防止操作创建这些资源，需要为其指定现有资源的名称，或者为其指定要初始创建并随后重用的资源的名称。
　　然后，可以将这些参数添加到＂生成和部署容器应用＂步骤。 containerAppName:  containerAppEnvironment:  resourceGroup: 
　　如果您有要构建和部署的自定义 Docker 映像，则需要使用这些参数来生成映像并进行部署。这是如果你有一个现有的Dockerfile imageToBuild: /: dockerfilePath: /Path/to/Dockerfile
　　还需要登录到容器注册表才能推送映像，因此还需要以下参数。如果要从私有映像存储库中提取映像，则还需要这些映像。 acrName:  acrUsername: ${{ secrets.REGISTRY_USERNAME }} acrPassword: ${{ secrets.REGISTRY_PASSWORD }}
　　我没有使用但可能有用的其他一些是： environmentVariables容器的环境变量列表。＂键=值＂格式的空格分隔值。用于清除现有值的空字符串。前缀值为＂secretref：＂以引用密钥。 targetPort容器应用将侦听的目标端口。如果未提供，则对于 Python 应用程序，此值将为＂80＂，对于所有其他受支持的平台，此值将为＂8080＂。
　　干的好！你已经一路走到了最后。