レビュー用のエフェメラル環境をデプロイする
Bicep コードをリントすると、Azure デプロイが成功する可能性が高いかどうかがわかります。 また、Bicep コードを実際にどこかに展開して、pull request がマージされ、展開が完了した後の環境がどのようになるかを確認することも役立ちます。
このユニットでは、コードを pull request 内から一時的な環境にデプロイする方法を学習します。
コードを pull request 内からデプロイする理由
Bicep コードを含む pull request をレビューする場合、Bicep コードを実際の Azure 環境にデプロイすることをお勧めします。 そうすることにより、変更を運用環境で実現しても機能するという確信を深めることができます。 問題が発生した場合は、すばやく検出する必要があります。 Pull request を使用すると、レビュー担当者からすぐにフィードバックを受け取るため、問題を発見して掘り下げる絶好の機械が提供されます。
そろそろ、運用環境にデプロイする前に、変更を 1 つ以上の非運用環境 ("テスト"、QA、"ステージング" など) にデプロイするという考えに慣れてきたはずです。 多くの組織では、このような環境は "長寿命" です。これは、変更がロールアウトされると環境が更新され、通常は削除されないことを意味します。
これに対して、"エフェメラル" 環境は動的に作成され、役に立たなくなったら削除しても問題のない環境です。 エフェメラル環境は、短時間のみ存在することを意図しています (たとえば、変更を確認するのに十分な長さのみ)。
エフェメラル環境は、pull request 用の環境をデプロイする場合に適しています。多数の個別の pull request を一度に開いて、さまざまな種類の変更を表すことができるためです。 複数の pull request を開いている場合、寿命の長い非運用環境を共有するということは、一度にプレビューできる変更が 1 つのみであることを意味します。
エフェメラル環境を作成する
Azure インフラストラクチャをコードとして構築することに慣れており、リソースを展開するために Bicep ファイルの構築に投資してきたため、それらの同じアセットを再利用してエフェメラル環境を展開することができます。 必要に応じて、一度の複数のエフェメラル環境をデプロイすることもできます。 独立した環境を簡単に作成できるように、展開が十分に "パラメーター化" および "一般化" されていることを確認する必要があります。 たとえば、一部の Azure リソースにはグローバルに一意の名前を付ける必要があります。これは、他のエフェメラル環境または寿命の長い環境のリソース名と同じにすることはできません。
エフェメラル環境には、次のような多くの利点があります。
- 他の運用環境または非運用環境のワークロードに影響を与えない分離された環境で、新しい機能を安全にテストできます。
- 自分のブランチに変更を表示して、簡単に自分の作業を同僚に紹介したり、レビュー担当者にアクセス権を付与したりすることができます。
- 変更に互換性がない場合でも、複数のチーム メンバーが、個別の変更を同時にテストできます。
- Bicep ファイルを定期的に実行する必要があるため、エフェメラル環境は Bicep コードやその他のスクリプトの正確性と完全性を継続的にテストするのに役立ちます。 その結果、運用環境でコードが完全に実行されることを確信できます。
このモジュールでは、pull request 内の変更について信頼を構築するのに役立つエフェメラル環境を作成します。 pull request をレビューする人は誰でも、pull request を承認してマージする前に、新しい追加や更新を含むエフェメラル環境にアクセスできます。
展開
エフェメラル環境で作業する場合は、チームが作成する pull request ごとに個別の Azure リソース グループを作成することをお勧めします。 1 人の作成者が 2 つの個別のプル要求を開いている場合、それぞれに独自のエフェメラル環境があります。 これにより、各変更を他の変更と分離し続けるのに役立ち、混乱や誤ってリソースが上書きされるのを防ぐことができます。
このアプローチを機能させるには、検証を行う pull request ワークフローでリソースグループを動的に作成する必要があります。 リソース グループには一意の名前が必要です。また、リソースをテストし、pull request が閉じられたときにそれらを削除できるようにするため、リソース グループを簡単に見つけられるようにする必要もあります。 リソース グループ名を効果的に処理するには、リソース グループ名内に pull request 番号を使用することができます。 この方法については、次の演習で説明します。
エフェメラル環境を削除するときに、ワークフローで簡単にリソース グループを見つけて、リソース グループ全体を削除できます。 エフェメラル環境で使用されているすべてのリソースは、同時に削除されます。
アクセス許可
リソース グループを作成するには、サブスクリプション レベルのアクセス許可が必要なため、通常、ワークフローのワークロード ID に共同作成者ロールを割り当てる必要があります。
エフェメラル環境には、専用の Azure サブスクリプションを使用することをお勧めします。 このアプローチに従うと、誤って他の環境へのアクセス権を与えることなく、ワークフローのワークロード ID とチーム メンバーにアクセス権を付与することができます。
重要
サブスクリプションをスコープに指定した共同作成者は強力であるため、ワークフローのワークロード ID とそれでデプロイできる変更に関する適切なガバナンスを確保する必要があります。 エフェメラル環境に専用のサブスクリプションを使用すると、他の環境へのリスクを軽減できます。
ワークフローの ID
デプロイ ワークフローでは、ワークロード ID とフェデレーション資格情報を使用して Azure に対する認証を行います。 pull request 検証ワークフローを使用する場合は、pull request を処理するようにフェデレーション資格情報を構成する必要があります。
このモジュールの前の演習では、フェデレーション資格情報を作成するコマンドを実行しました。 ポリシー文字列は次のようになっていました。
repo:my-github-user/my-repo:pull_request
文字列の末尾付近の pull_request で、フェデレーション資格情報が pull request 検証ワークフローで動作することを指定しています。
コスト管理
エフェメラル環境を動的に作成すると、Azure のコストが増加する危険性があります。 チームで多数の pull request が開かれると、コストの高い多数のリソースが Azure にデプロイされる危険性があります。
ヒント
チームで pull request が迅速に閉じられると、対応する pull request が閉じられたときにエフェメラル環境が削除されるため、コストの増加はそれほど問題にはなりません。
専用の Azure サブスクリプションを使用すると、エフェメラル環境のコストを簡単に監視することもできます。 さらに、エフェメラル リソースの SKU を制限するポリシーをサブスクリプション全体で適用することができます。これは、コスト超過を回避するのに役立ちます。
さらに、Azure には、エフェメラル環境のコストを制御するために役立つ多くの方法が用意されています。たとえば、次のようなものがあります。
- Microsoft Cost Management を使用すると、サブスクリプションの "予算" を設定できます。 予算によって通知がトリガーされるため、チームは、コストが指定されたしきい値に近づいていることを認識します。
- 多くの Azure リソースの種類には、非運用ワークロード用の安価なレベルや無料レベルも用意されています。 これらの価格レベルと SKU を使用できるかどうかを検討してください。
- 一部のお客様は、非運用サブスクリプションに Azure Dev/Test 価格を使用できます。
- リソース タグは、各エフェメラル環境に関連付けられるリソースを識別し、各エフェメラル環境のコストを計算するのに役立ちます。
- 定義された期間が経過したとき、または毎日営業時間終了後の夜間などに、エフェメラル環境を削除する自動スクリプトを作成できます。
また、エフェメラル環境間で特定のリソースを共有することも検討できます。 たとえば、Bicep コードで多くのリソースが定義され、その一部はコストがかかるか、プロビジョニングに時間がかかる場合があります。 コストのかかるリソースを共有するために、すべての pull request に対して寿命の長い 1 つの共有リソース グループを作成し、他のリソースに対しては個別のエフェメラル リソース グループを作成することができます。 ただし、このアプローチを使用すると、エフェメラル環境を管理して、レビュー プロセス時に役立つように十分に分離しておくことが難しくなり、エラーが発生しやすくなります。 エフェメラル環境のコストが高くなりすぎる場合を除いて、このアプローチを使用しないようにすることをお勧めします。