デプロイをプレビューして承認する
パイプライン ステージについて、およびパイプライン ステージを追加して Bicep コードを検証する方法について学習しました。 デプロイの信頼性を構築するための次のステップでは、別のステージを追加して、デプロイによって何が変更されるのかを厳密に確認します。
このユニットでは、パイプラインでの what-if コマンドを使用する方法について学習します。 また、デプロイを実行する前にコマンドの出力を手動で確認できるように、承認を追加する方法についても学習します。
what-if 操作
Bicep ファイルには、デプロイの最後に Azure 環境がどのような状態になるかが記述されています。 デプロイを送信すると、Azure Resource Manager により、Bicep ファイルに記述されている状態に合わせて Azure 環境が変更されます。
デプロイによって、新しいリソースが環境にデプロイされたり、既存のリソースが更新されたりする可能性があります。 デプロイを完全モードで実行すると、既存のリソースが削除されることもあります。
リソースが作成、更新、または削除されるとき、予期しない方法で変更されるリスクがあります。 作成、更新、削除されるリソースを確認するためにさらにステップを追加することをお勧めします。 この検証によって、自動化プロセスの価値が高まります。 運用環境にデプロイする場合は、環境に生じる変更を確認することが重要です。
Resource Manager では、what-if 操作が提供されます。これは、パイプライン ステージ内の Bicep ファイルで実行できます。
パイプライン定義内から az deployment group what-if Azure CLI コマンドを使用して、what-if ステップを実行することができます。
stages:
- stage: Preview
jobs:
- job: Preview
steps:
- task: AzureCLI@2
inputs:
azureSubscription: 'MyServiceConnection'
scriptType: 'bash'
scriptLocation: 'inlineScript'
inlineScript: |
az deployment group what-if \
--resource-group $(ResourceGroupName) \
--template-file deploy/main.bicep
ヒント
このモジュールでは、Azure CLI を使用して what-if 操作を実行します。 PowerShell ベースの独自のパイプラインを構築するには、New-AzResourceGroupDeployment コマンドレットと -Whatif スイッチを使用するか、Get-AzResourceGroupDeploymentWhatIfResult コマンドレットを使用します。
what-if 操作では、環境に対して変更が加えられることはありません。 代わりに、作成または削除されるリソース、更新されるリソース プロパティ、削除されるリソースが記述されます。
What-if では、変更が実際には発生しないのにリソースが変更されることが示される場合があります。 このフィードバックは "ノイズ" と呼ばれます。 Microsoft では、これらの問題を削減することに取り組んでいますが、これらの問題を報告するにはお客様のご協力が必要です。
what-if 操作の出力を確認したら、デプロイに進むかどうかを判断できます。 このステップには通常、ユーザーが what-if コマンドからの出力を確認し、特定された変更が妥当かどうかを判断する手順が含まれます。 レビュー担当者が、変更が妥当であると判断した場合は、パイプラインの実行を手動で承認できます。
what-if コマンドの詳細については、Microsoft Learn モジュールの「what-if を使用して Azure デプロイの変更をプレビューする」を参照してください。
環境
Azure Pipelines では、"環境" はソリューションがデプロイされる場所を表します。 環境には、複雑なデプロイを行うときに役立つ機能が用意されています。 今後のモジュールでは、環境とその機能について詳しく学習します。 ここでは、パイプラインに手動承認を追加する機能に重点を置いて説明します。
既にご存知のとおり、パイプライン ステージ内の一連のステップを定義するには、"ジョブ" を使用します。 パイプラインに環境を含める場合は、"デプロイ ジョブ" と呼ばれる特別な種類のジョブを使用する必要があります。 デプロイ ジョブは通常ジョブに似ていますが、いくつかの追加機能が用意されています。 この機能には、デプロイ ジョブで使用する環境の定義が含まれます。
variables:
- name: deploymentDefaultLocation
value: westus3
stages:
- stage: Preview
jobs:
- job: Preview
steps:
- task: AzureCLI@2
inputs:
azureSubscription: 'MyServiceConnection'
scriptType: 'bash'
scriptLocation: 'inlineScript'
inlineScript: |
az deployment group what-if \
--resource-group $(ResourceGroupName) \
--template-file deploy/main.bicep
- stage: Deploy
jobs:
- deployment: Deploy
environment: MyAzureEnvironment
strategy:
runOnce:
deploy:
steps:
- checkout: self
- task: AzureResourceManagerTemplateDeployment@3
name: Deploy
displayName: Deploy to Azure
inputs:
connectedServiceName: 'MyServiceConnection'
location: $(deploymentDefaultLocation)
resourceGroupName: $(ResourceGroupName)
csmFile: deploy/main.bicep
デプロイ ジョブの YAML 定義には、通常のジョブとはいくつかの重要な違いがあることに注目してください。
- デプロイ ジョブは、
jobという語で始まるのではなく、deploymentとして定義されます。 environmentキーワードにより、対象となる環境の名前が指定されます。 前の例では、デプロイはMyAzureEnvironmentという名前の環境に対して追跡されます。strategyキーワードにより、Azure Pipelines でデプロイ ステップがどのように実行されるかが指定されます。 デプロイ戦略では、特に複数の運用環境がある場合に、複雑なデプロイ プロセスがサポートされます。 このモジュールでは、runOnceデプロイ方法を使用します。 この方法は、既に慣れている他のジョブと同様に動作します。
ステージのチェックと承認
環境を作成した後、"チェック" を定義できます。 チェックを使用して、パイプラインで環境を使用する前に満たす必要がある条件を検証します。 承認は、ユーザーが手動で承認することが必要な種類のチェックです。
チェックは、パイプラインではなく、環境で定義されます。 パイプライン YAML ファイルの作成者は、これらのチェックや承認を削除したり追加したりすることはできません。 チェックと承認を管理できるのは、その環境の管理者だけです。
多くの組織では、Azure Pipelines の環境の所有者は、デプロイ先の環境の責任者です。 チェックと承認は、デプロイ プロセスに適切な人材が携わっていることを確認するのに役立ちます。
チェックと承認のしくみ
チェックと承認は、パイプライン ステージが開始される直前に評価されます。 Azure Pipelines でパイプライン ステージを実行しようとすると、環境を含め、そのステージで使用されるすべてのパイプライン リソースが表示されます。 環境では、満たす必要のあるチェックを行うことができます。
承認は、チェックの一種です。 承認チェックを構成するときは、パイプラインの継続を承認する必要がある 1 人以上のユーザーを割り当てます。
Azure Pipelines では他の種類のチェックも提供されます。 たとえば、API を呼び出して、何らかのカスタム ロジックを実行したり、ステージを実行できる営業時間を制御したり、Azure Monitor に対してクエリを実行してデプロイが成功したことを確認したりできます。 このモジュールでは承認チェックについてのみ説明しますが、「まとめ」に、チェックに関する詳細情報へのリンクを示します。
Note
エージェント プールとサービス接続に、それらのチェックを構成することもできます。 また、手動承認タスクと呼ばれる特別なステップを使用することもできます。 ただし、このモジュールでは、環境とそれらに関連付けられているチェックに焦点を当てます。
パイプラインが開始され、承認チェックを必要とするステージに到達すると、パイプラインの実行は一時停止します。 承認者として指定されたすべてのユーザーには、Azure DevOps およびメールでメッセージが送信されます。
承認者は、パイプライン ログで、what-if 操作によって検出された変更などを検査できます。 次に、この情報に基づいて、変更を承認または拒否します。 変更を承認すると、パイプラインが再開されます。 これらのユーザーが拒否した場合、または構成可能なタイムアウト期間内に応答しなかった場合、ステージは失敗します。
ベスト プラクティスの重要性
Azure Pipelines の環境機能を使用すると、デプロイを環境にリンクできます。その後、環境の所有者によって定義されたチェックと承認がデプロイに継承されます。 ただし、新しいパイプラインで環境を使用する必要はありません。
自分と組織がパイプライン定義を確認するためのグッド プラクティスを確立することが重要です。 たとえば、ブランチ保護ポリシーを使用して、メイン ブランチへの変更に関するプル要求の確認を要求するようにリポジトリを構成します。 この概念については、今後のモジュールで学習します。
また、サービス接続にチェックと承認を追加して、デプロイでサービス プリンシパルの資格情報を使用する前に承認を確実に得ることもできます。 ただし、プレフライト検証と what-if 操作を実行するパイプラインの機能もサービス接続を必要とするため、承認はそれらにも影響を及ぼします。
独自のサービス プリンシパルに基づいて、what-if ステージに他の個別のサービス接続を使用することもできます。 プレフライト ステージと検証ステージに使用されるサービス プリンシパルでは、作業に必要な最小限のアクセス許可が確保されるように、カスタム Azure ロールを定義する必要があります。