GitHub Actions を使用して Azure インフラストラクチャにデプロイする
このガイドでは、CI/CD とコードとしてのインフラストラクチャ (IaC) を利用して、GitHub アクション を使用して自動化された反復可能な方法で Azure にデプロイする方法について説明します。
この記事はアーキテクチャの概要であり、スケーラブルで、安全で、回復力があり、可用性の高い Azure 上のアプリケーションを設計するための構造化されたソリューションを紹介します。 クラウド アーキテクチャやソリューションのアイデアの実例をさらに確認するには、Azure アーキテクチャを参照してください。
IaC と展開の自動化を使用する利点
Azure にデプロイするには、Azure portal、CLI、API など、さまざまな方法があります。 このガイドでは、IaC と CI/CD 自動化を使用します。 この手法には次のような利点があります。
宣言型: インフラストラクチャと展開プロセスをコードで定義すると、標準のソフトウェア開発ライフサイクルを使用してバージョン管理やレビューを行うことができます。 IaC は、構成内のドリフトを防ぐのにも役立ちます。
一貫性: IaC プロセスに従うことで、組織全体が、ベスト プラクティスを組み込んでセキュリティのニーズを満たすために強化されたインフラストラクチャを導入するための、確立された標準的な方法に従っていることが保証されます。 中央テンプレートに加えられた改善は、組織全体に簡単に適用できます。
セキュリティ: 内部標準を満たすために、一元管理されたテンプレートを強化し、クラウド運用チームまたはセキュリティ チームによって承認できます。
セルフサービス: チームは、一元管理されたテンプレートを利用して独自のインフラストラクチャを展開できます。
生産性の向上: 標準テンプレートを利用することで、チームは実装の詳細を気にすることなく、新しい環境を迅速にプロビジョニングできます。
追加情報については、Azure アーキテクチャ センターの反復可能なインフラストラクチャ、または DevOps リソース センターのコードとしてのインフラストラクチャとはを参照してください。
Architecture
データフロー
- 新しいブランチを作成し、必要な IaC コードの変更をチェックインします。
- 変更を環境にマージする準備ができたら、GitHub でプル リクエスト (PR) を作成します。
- GitHub Actions ワークフローがトリガーされ、コードが適切にフォーマットされ、内部的に一貫性があり、安全なインフラストラクチャが生成されることを確認します。 さらに、Terraform Plan または Bicep の what-if 分析が実行され、Azure 環境で発生する変更のプレビューが生成されます。
- 適切にレビューされた後、PR をメイン ブランチにマージできます。
- 別の GitHub Actions ワークフローがメイン ブランチからトリガーされ、IaC プロバイダーを使用して変更が実行されます。
- (Terraform のみ) 定期的にスケジュールされた GitHub Action ワークフローも実行して、環境内の設定のずれを探し、変更が検出された場合は新しい問題を作成する必要があります。
前提条件
Bicep の使用
GitHub環境を作成する
ワークフローでは、GitHub 環境とシークレットを利用して、Azure ID 情報を保存し、デプロイの承認プロセスを設定します。 これらの手順に従って、
productionという名前の環境を作成します。production環境で、保護ルールを設定し、運用展開でサインオフする必要がある承認者を追加します。 環境をメイン ブランチに制限することもできます。 詳細な手順については、こちらをご覧ください。Azure Identity をセットアップします。
Azure サブスクリプション内にデプロイするためのアクセス許可を持つ Azure Active Directory アプリケーションが必要です。 単一のアプリケーションを作成し、Azure サブスクリプションで適切な読み取り/書き込みアクセス許可を与えます。 次に、GitHub が OpenID Connect (OIDC) を使用して ID を利用できるように、フェデレーション資格情報を設定します。 詳細な手順については、Azure ドキュメントを参照してください。 3 つのフェデレーション資格情報を追加する必要があります。
- エンティティ タイプを
Environmentに設定し、production環境名を使用します。 - エンティティ タイプを
Pull Requestに設定します。 - エンティティ タイプを
Branchに設定し、mainブランチ名を使用します。
- エンティティ タイプを
GitHub シークレットを追加
Note
Azure ID に関するデータにはシークレットや資格情報が含まれていませんが、環境ごとに ID 情報をパラメータ化する便利な手段として GitHub シークレットを利用しています。
Azure ID を使用して、リポジトリに次のシークレットを作成します。
AZURE_CLIENT_ID: Azure でのアプリ登録のアプリケーション (クライアント) IDAZURE_TENANT_ID: アプリ登録が定義されている Azure Active Directory のテナント ID。AZURE_SUBSCRIPTION_ID: アプリ登録が定義されているサブスクリプション ID。
シークレットをリポジトリに追加する手順については、こちらをご覧ください。
Terraform を使用する
Terraform 状態の場所を構成する
Terraform は、状態ファイル を利用して、管理対象インフラストラクチャと関連する構成の現在の状態に関する情報を保存します。 このファイルは、ワークフローの異なる実行間で保持する必要があります。 推奨されるアプローチは、このファイルを Azure ストレージ アカウントまたは他の同様のリモート バックエンド内に保存することです。 通常、このストレージは手動または別のワークフローを通じてプロビジョニングされます。 Terraform バックエンド ブロック は、選択した保存場所で更新する必要があります (ドキュメントについては、こちら を参照してください)。
GitHub環境を作成する
ワークフローでは、GitHub 環境とシークレットを利用して、Azure ID 情報を保存し、デプロイの承認プロセスを設定します。 これらの手順に従って、
productionという名前の環境を作成します。production環境で、保護ルールを設定し、運用展開でサインオフする必要がある承認者を追加します。 環境をメイン ブランチに制限することもできます。 詳細な手順については、こちらをご覧ください。Azure Identity をセットアップします。
Azure サブスクリプション内にデプロイするためのアクセス許可を持つ Azure Active Directory アプリケーションが必要です。
read-onlyアカウントとread/writeアカウントに別のアプリケーションを作成し、Azure サブスクリプションで適切なアクセス許可を与えます。 さらに、両方のロールには、手順 1 の Terraform 状態が存在するストレージ アカウントに対する少なくともReader and Data Access個のアクセス許可も必要です。 次に、GitHub が OpenID Connect (OIDC) を使用して ID を利用できるようにフェデレーション資格情報を設定します。 詳細な手順については、Azure ドキュメントを参照してください。read/writeID については、次のように 1 つのフェデレーション資格情報を作成します。Entity TypeをEnvironmentに設定し、productionの環境名を使用します。
read-onlyID については、次のように 2 つのフェデレーション資格情報を作成します。Entity TypeをPull Requestに設定します。Entity TypeをBranchに設定し、mainブランチ名を使用します。
GitHub シークレットを追加
Note
Azure ID に関するデータにはシークレットや資格情報が含まれていませんが、環境ごとに ID 情報をパラメータ化する便利な手段として GitHub シークレットを利用しています。
read-onlyID を使用して、リポジトリに次のシークレットを作成します。AZURE_CLIENT_ID: Azure でのアプリ登録のアプリケーション (クライアント) IDAZURE_TENANT_ID: アプリ登録が定義されている Azure Active Directory のテナント ID。AZURE_SUBSCRIPTION_ID: アプリ登録が定義されているサブスクリプション ID。
シークレットをリポジトリに追加する手順については、こちらをご覧ください。
read-writeID を使用して、production環境に別のシークレットを作成します。AZURE_CLIENT_ID: Azure でのアプリ登録のアプリケーション (クライアント) ID
シークレットを環境に追加する手順については、こちらをご覧ください。 環境シークレットは、
production環境へのデプロイ手順を実行するときに、昇格された読み取り/書き込み権限が必要なときにリポジトリ シークレットをオーバーライドします。
GitHub Actions を使用したデプロイ
Bicep の使用
リファレンス アーキテクチャには、次の 2 つの主要なワークフローが含まれています。
-
このワークフローはコミットごとに実行され、インフラストラクチャ コードに対する一連の単体テストで構成されます。 bicep build を実行して、Bicepを ARM テンプレートにコンパイルします。 これにより、フォーマット エラーが発生しないことが保証されます。 次に、検証を実行して、テンプレートが展開可能であることを確認します。 最後に、IaC 用のオープンソース静的コード分析ツールである checkov が実行され、セキュリティとコンプライアンスの問題を検出します。 リポジトリが GitHub Advanced Security (GHAS) を利用している場合、結果は GitHub にアップロードされます。
-
このワークフローは、すべてのプル リクエストとメイン ブランチへのコミットごとに実行されます。 ワークフローの what-if ステージは、what-if を実行することで、Azure 環境に対する IaC の変更の影響を理解するために使用されます。 このレポートは PR に添付され、簡単に確認できるようになります。 デプロイ ステージは、ワークフローがメイン ブランチへのプッシュによってトリガーされると、what-if 分析の後に実行されます。 この段階では、手動レビューが承認された後、テンプレートを Azure にデプロイします。
Terraform を使用する
リファレンス アーキテクチャには、次の 3つの主要なワークフローが含まれています。
-
このワークフローはコミットごとに実行され、インフラストラクチャ コードに対する一連の単体テストで構成されます。 terraform fmtを実行して、コードが適切に lint され、terraform のベスト プラクティスに従っていることを確認します。 次に、terraform validate を実行して、コードが構文的に正しく、内部的に一貫性があることを確認します。 最後に、IaC 用のオープンソース静的コード分析ツールである checkov が実行され、セキュリティとコンプライアンスの問題を検出します。 リポジトリが GitHub Advanced Security (GHAS) を利用している場合、結果は GitHub にアップロードされます。
-
このワークフローは、すべてのプル リクエストとメイン ブランチへのコミットごとに実行されます。 ワークフローの計画ステージは、terraform planを実行することによって、Azure 環境に対する IaC の変更の影響を理解するために使用されます。 このレポートは PR に添付され、簡単に確認できるようになります。 適用ステージは、メイン ブランチへのプッシュによってワークフローがトリガーされると、プランの後に実行されます。 この段階では、環境に保留中の変更がある場合、計画文書を取得し、手動レビューが承認された後に変更を適用します。
-
このワークフローは定期的に実行され、Terraform の外部で行われた構成のドリフトや変更がないか環境をスキャンします。 ドリフトが検出された場合は、GitHub の問題が生成され、プロジェクトの管理者に警告されます。