デプロイをプレビューして承認する

5 分

ワークフロージョブについて、およびワークフロージョブを追加して Bicep コードを検証する方法について学習しました。デプロイの信頼性を構築するための次のステップでは、別のジョブを追加して、デプロイによって何が変更されるのかを厳密に確認します。

このユニットでは、ワークフローでの what-if コマンドを使用する方法について学習します。また、デプロイを実行する前にコマンドの出力を手動で確認できるように、環境保護ルールを追加する方法についても学習します。

what-if 操作

Bicep ファイルには、デプロイの最後に Azure 環境がどのような状態になるかが記述されています。デプロイを送信すると、Azure Resource Manager により、Bicep ファイルに記述されている状態に合わせて Azure 環境が変更されます。

デプロイによって、新しいリソースが環境にデプロイされたり、既存のリソースが更新されたりする可能性があります。デプロイを完全モードで実行すると、既存のリソースが削除されることもあります。

リソースが作成、更新、または削除される場合は常に、予期しない方法で変更されるリスクがあります。作成、更新、および削除される内容を確認するには、さらなるステップを追加することをお勧めします。この検証によって、自動化プロセスの価値が高まります。運用環境にデプロイする場合は、お使いの環境に生じる変更を確認することが重要です。

Resource Manager では、what-if 操作が提供されます。これは、ワークフロージョブ内の Bicep ファイルで実行できます。

リント、検証、プレビュージョブを含むワークフローを示す図。プレビュージョブでは、Azure に対して what-if 操作が実行されます。

この arm-deploy アクションでは、additionalArguments プロパティを使用した What-If 操作のトリガーがサポートされています。

jobs:
  preview:
     runs-on: ubuntu-latest
     needs: [lint, validate]
     steps: 
     - uses: azure/login@v1
       name: Sign in to Azure
       with:
        client-id: ${{ secrets.AZURE_CLIENT_ID }}
        tenant-id: ${{ secrets.AZURE_TENANT_ID }}
        subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
     - uses: azure/arm-deploy@v1
       name: Run what-if
       with:
         failOnStdErr: false
         resourceGroupName: ${{ env.AZURE_RESOURCEGROUP_NAME }}
         template: deploy/main.bicep
         parameters: >
           environmentType=${{ env.ENVIRONMENT_TYPE }}
         additionalArguments: --what-if

強調されているコードは、--what-if 引数が含まれる Azure CLI を使ってデプロイを実行するのと同じです。

what-if 操作では、環境に対して変更が加えられることはありません。代わりに、作成されるリソース、更新されるリソースプロパティ、削除されるリソースが記述されます。

What-if では、変更が実際には発生しないのにリソースが変更されることが示される場合があります。この種類の出力は "ノイズ"と呼ばれます。 Microsoft では、これらの問題を削減することに取り組んでいますが、お客様のご協力が必要です。 What-If の問題を報告します。

what-if 操作の出力を確認したら、デプロイに進むかどうかを判断できます。このステップには通常、ユーザーが what-if コマンドからの出力を確認し、特定された変更が妥当かどうかを判断する手順が含まれます。レビュー担当者が、変更が妥当であると判断した場合は、ワークフロー実行を手動で承認できます。

what-if コマンドの詳細については、Microsoft Learn モジュールの「what-if を使用して Azure デプロイの変更をプレビューする」を参照してください。

環境

GitHub Actions では、"環境" はソリューションがデプロイされる場所を表します。環境には、複雑なデプロイを行うときに役立つ機能が用意されています。今後のモジュールでは、環境とその機能について詳しく学習します。ここでは、必要なレビュー担当者をワークフローに追加する機能に重点を置きます。

GitHub Web インターフェイスを使用して環境を作成します。パブリック GitHub リポジトリを使用する場合、または GitHub Enterprise アカウントを使用する場合には、環境を作成できます。

環境を作成した後は、ワークフロー内の任意のジョブでそれを参照できます。

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - name: 'Lint Bicep template'
      run: az bicep build --file deploy/main.bicep

  validate:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - 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/arm-deploy@v1
      with:
        deploymentName: ${{ github.run_number }}
        resourceGroupName: ${{ env.AZURE_RESOURCEGROUP_NAME }}
        template: ./deploy/main.bicep
        parameters: environmentType=${{ env.ENVIRONMENT_TYPE }}
        deploymentMode: Validate

  deploy:
    runs-on: ubuntu-latest
    environment: MyAzureEnvironment
    needs: [lint, validate]
    steps:
    - uses: actions/checkout@v3
    - 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/arm-deploy@v1
      with:
        deploymentName: ${{ github.run_number }}
        resourceGroupName: ${{ env.AZURE_RESOURCEGROUP_NAME }}
        template: ./deploy/main.bicep
        parameters: environmentType=${{ env.ENVIRONMENT_TYPE }}

Note

デプロイワークフローのワークロード ID が環境内の Resource Manager とやりとりする場合は、その環境の名前で構成されたフェデレーション資格情報が必要です。環境の詳細については、後のモジュールで学習します。このモジュールの演習を実行するときに、必要なフェデレーション資格情報を作成します。

環境保護ルール

環境を作成した後、環境保護ルールを定義できます。保護ルールを使用して、ステップで環境を使用する前に満たす必要がある条件を検証します。 必要なレビュー担当者保護ルールは、ユーザーが手動で承認することが必要な種類の検査です。

保護ルールは、ワークフローではなく、環境に対して定義されます。ワークフロー YAML ファイルの作成者は、これらの保護ルールを削除したり追加したりすることはできません。環境とその保護ルールを管理できるのは、リポジトリの管理者またはアカウント所有者だけです。

環境保護ルールは、デプロイプロセスに適切な人材が携わっていることを確認するのに役立ちます。

環境保護ルールはどのように機能しますか。

環境をステップに関連付けると、その環境の保護ルールが、ステップが開始される直前に評価されます。

必要なレビュー担当者は、保護ルールの一種です。必要なレビュー担当者保護ルールを構成する場合、後続のワークフローを承認する必要がある GitHub ユーザーを 1 人以上割り当てます。

環境には、他の種類の保護ルールも備わっています。たとえば、特定の環境にデプロイできる Git ブランチを制限できます。このモジュールでは、必要なレビュー担当者ルールについてのみ説明しますが、概要部分に他の保護ルールに関する詳細情報へのリンクを示します。

ワークフローが開始され、レビュー担当者を必要とするステップに達すると、ワークフロー実行は一時停止します。レビュー担当者として指定されたすべてのユーザーに、GitHub およびメールでメッセージが送信されます。

レビュー担当者は、ワークフローログで、what-if 操作によって検出された変更などを検査できます。次に、この情報に基づいて、変更を承認または却下します。変更を承認すると、ワークフローが再開されます。却下した場合、またはタイムアウト期間内に応答しなかった場合、ジョブは失敗します。

リント、検証、プレビュー、デプロイジョブを含むワークフローを示す図。デプロイジョブの前に承認チェックが行われます。

グッドプラクティスの重要性

GitHub の環境機能を使用すると、デプロイを環境にリンクできます。その後、環境の管理者によって定義された保護ルールがデプロイに継承されます。ただし、新しいワークフローで環境を使用する必要はありません。

組織にとっては、ワークフローの定義を確認するための適切な方法を確立することが重要です。たとえば、ブランチ保護ルールを使用して、"メイン" ブランチへの変更に関する pull request レビューを要求するようにリポジトリを構成します。この概念については、今後のモジュールで学習します。

また、シークレットを環境に追加できます。そうすれば、このシークレットは環境も使用するジョブでのみ使用できます。環境の保護ルールとシークレットを組み合わせることにより、ワークフローのセキュリティを確実に維持できます。

続行

what-if 操作

環境

環境保護ルール

環境保護ルールはどのように機能しますか。

グッド プラクティスの重要性

フィードバック

グッドプラクティスの重要性