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