Gridwich は、相互に安全に通信するために、Azure 内外に複数のリソースを必要とします。 この要件により、Microsoft Entra のアクセス許可、ゲート、リソースの作成、操作の順序、および実行時間の長い関数のデプロイに関する継続的インテグレーションと継続的デリバリー (CI/CD) の課題が生じます。 次の基本原則で、これらの課題に対処します。
- 1 つのビルド成果物が、同じパイプライン内のすべての環境に影響します。
- 非ゲート環境は破棄可能です。
- Terraform は、宣言によってべき等環境を作成します。
- Terraform はソフトウェアをリリースしません。
- インフラストラクチャの作成とソフトウェアのリリースは、パイプライン内の個別のステージです。
- CI/CD パイプラインで、Microsoft Entra アクセス許可は割り当てられません。
- パイプラインはすべてをコードとみなします。
- パイプラインは、構成可能性に重点を置いた再利用可能なコンポーネントを使用します。
次の考慮事項は、前述の原則に関連しています。
単一の成果物、複数の環境
Gridwich パイプラインは複数の環境にスケーリングされますが、パイプラインによって 1 つの環境から次の環境にレベルが上がる成果物は 1 つだけです。
ソフトウェアのリリースとインフラストラクチャの作成との比較
Gridwich では、ソフトウェアのリリースとインフラストラクチャの展開は 2 つの異なる役割です。 1 つのパイプラインは、次の一般的なパターンを使用して、さまざまな段階で両方の役割に対応します。
ソフトウェアのビルド > インフラストラクチャの展開 > ソフトウェアのリリース > ソフトウェアの構成 > カスタム スクリプトの展開
インフラストラクチャとソフトウェアのリリースは 2 つの異なる役割であるという基本原則により、Event Grid サブスクリプションの展開がより困難になります。 Azure が Event Grid Webhook サブスクリプションを作成すると、登録エンドポイントが Event Grid イベントを受け入れるかどうかを確認する検証イベントが送信されます。 この検証チェックに合格するには、Terraform が Event Grid サブスクリプション リソースを構築する前に、Azure 関数を解放して実行する必要があります。
この問題に対処するために、CI/CD パイプラインには次の 2 つの Terraform ジョブがあります。
- Terraform 1 では、Azure Event Grid サブスクリプションを除くすべてのリソースが作成されます。
- Terraform 2 では、ソフトウェアが起動して実行された後、Event Grid サブスクリプションが作成されます。
Terraform は、現在特定のモジュールを除外する機能を持っていないため、Terraform 1 ジョブは、Event Grid サブスクリプションを除くすべてのモジュールを明示的にターゲットにする必要があります。 この要件により、エラーが発生しやすい可能性があり、 現在 GitHub の Terraform の問題に関するページでこの問題を追跡してます。
展開後スクリプト
CI/CD パイプラインは、昇格された特権を必要とする操作を実行しませんが、管理者スクリプト テンプレートを使用して、一連の管理スクリプトをパイプライン成果物として生成します。 昇格された特権を持つ管理者は、新しい Gridwich 環境が作成されるたびに、これらの管理スクリプトを実行する必要があります。 詳細については、Azure 管理スクリプトの実行に関するページを参照してください。
Terraform とソフトウェアのリリースでは、次のような特定の Gridwich 操作を完了できません。
- Azure Key Vault に証明書をコピーする
- Azure Storage で Storage Analytics を有効化する
これらの最後の手順は、Azure CLI スクリプト azcli-last-steps-template により提供されます。
すべてをコードとみなすことと、コードの再利用
「すべてをコードとみなす」プラクティスの利点の 1 つは、コンポーネントの再利用です。
- Terraform の場合、構成可能性と再利用性を強化するために Gridwich は Terraform モジュールに大きく依存します。
- Azure Pipelines YAML の場合、Gridwich ではパイプライン テンプレートが使用されます。