Terraform を使用してロードバランサーエンドポイントが変更されたときの CloudFront 更新を自動化 - AWS 規範ガイダンス
概要前提条件と制限アーキテクチャツールエピックトラブルシューティング関連リソース追加情報

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Terraform を使用してロードバランサーエンドポイントが変更されたときの CloudFront 更新を自動化

Amazon Web Services、Tamilselvan P、Mohan Annam、Naveen Suthar

概要

Amazon Elastic Kubernetes Service (Amazon EKS) のユーザーが Helm チャートを使用してイングレス設定を削除したのち再度インストールすると、新しい Application Load Balancer (ALB) が作成されます。この問題は、Amazon CloudFront が古い ALB の DNS レコードを参照し続けることが原因で発生します。そのためこのエンドポイント宛てのサービスに到達できません。(このワークフローの問題に関する詳細は追加情報を参照してください)。

この問題を解決するために、このパターンでは Python で開発されたカスタム AWS Lambda 関数の使用について説明します。この Lambda 関数は、Amazon EventBridge ルールを使用して新しい ALB がいつ作成されるかを自動的に検出します。を使用して AWS SDK for Python (Boto3)、関数は新しい ALB の DNS アドレスで CloudFront 設定を更新し、トラフィックが正しいエンドポイントにルーティングされるようにします。

この自動化されたソリューションは、追加のルーティングなしで、また遅延を発生させることなくサービスの継続性を維持します。このプロセスにより、基盤となるインフラストラクチャが変更されても、CloudFront は常に正しい ALB DNS エンドポイントを参照することができます。

前提条件と制限

前提条件

制限事項

製品バージョン

  • Terraform バージョン 1.0.0 以降

  • Terraform AWS Provider バージョン 4.20 以降

アーキテクチャ

次の図表は、このパターンのアプリケーションのワークフローとアーキテクチャコンポーネントを示しています。

EventBridge ルールで検出された新しい ALB DNS アドレスで CloudFront を更新するワークフロー。

以下の手順で実行します。

  1. Amazon EKS Ingress コントローラーは、Helm の再起動またはデプロイが行われるたびに、新しい Application Load Balancer (ALB) を作成します。

  2. EventBridge は ALB の作成イベントを検索します。

  3. ALB の作成イベントは Lambda 関数をトリガーします。

  4. Lambda 関数は python 3.9 に基づいてデプロイされており、boto3 API を使用して を呼び出します AWS のサービス。Lambda 関数は、ロードバランサーの作成イベントから受信した最新のロードバランサー DNS 名で CloudFront エントリを更新します。

ツール

AWS のサービス

  • Amazon CloudFront は、世界中のデータセンターネットワークを通じて配信することで、ウェブコンテンツの配信を高速化します。これにより、レイテンシーが減少し、パフォーマンスが向上します。

  • Amazon Elastic Kubernetes Service (Amazon EKS) を使用すると、独自の Kubernetes コントロールプレーンやノードをインストールまたは維持 AWS することなく、 で Kubernetes を実行できます。

  • Amazon EventBridge は、アプリケーションをさまざまなソースのリアルタイムデータに接続できるようにするサーバーレスイベントバスサービスです。例えば、 AWS Lambda 関数、API 送信先を使用する HTTP 呼び出しエンドポイント、その他のイベントバスなどです AWS アカウント。

  • AWS Lambda は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。

  • AWS SDK for Python (Boto3) は、Python アプリケーション、ライブラリ、またはスクリプトを と統合するのに役立つソフトウェア開発キットです AWS のサービス。

その他のツール

  • 「Python」は汎用のコンピュータプログラミング言語です。

  • 「Terraform」は、HashiCorp の infrastructure as code (IaC) ツールで、クラウドとオンプレミスのリソースの作成と管理を支援します。

コードリポジトリ

このパターンのコードは、GitHub の aws-cloudfront-automation-terraform-samples リポジトリで利用できます。

エピック

タスク説明必要なスキル

Git CLI をセットアップして設定します。

ローカルワークステーションに Git コマンドラインインターフェイス (CLI) をインストールして設定するには、Git ドキュメントの「Getting Started – Installing Git」の手順に従います。

DevOps エンジニア

プロジェクトフォルダを作成し、ファイルを追加します。

  1. パターンの GitHub リポジトリに移動し、[コード] ボタンを選択します。

  2. [クローン] ダイアログで、[HTTPS] タブを選択します。[ウェブ URL を使用してクローンを作成] で、表示されている URL をコピーします。

  3. ローカルマシンでフォルダを作成します。プロジェクト名をフォルダの名前にします。

  4. ローカルマシンでターミナルを開き、このフォルダに移動します。

  5. 以下のコマンドを実行して、このパターンの GitHub リポジトリのクローンを作成します。git clone https://github.com/aws-samples/aws-cloudfront-automation-terraform-samples

  6. リポジトリのクローンを作成したら、次のコマンドを使用してクローンのディレクトリに移動します。cd <directory name>/cloudfront-update

    選択した統合開発環境 (IDE) でこのプロジェクトを開きます。

DevOps エンジニア
タスク説明必要なスキル

ソリューションのデプロイ

ターゲットにリソースをデプロイするには AWS アカウント、次のステップを使用します。

  1. cloudfront-update フォルダに移動します。

  2. cloudfront_distribution_id で terraform.tfvars ファイルを更新します。

  3. AWS プロファイル AWS リージョン の を設定するには、次のコマンドを実行します。

    export AWS_REGION={{ REGION }}

  4. 以下のコマンドを実行し、Terraform を初期化します。

    terraform init

  5. 以下のコマンドを実行し、Terraform を検証します。

    terraform validate

  6. 以下のコマンドを実行し、Terraform 実行プランを作成します。

    terraform plan

  7. 以下のコマンドを実行し、terraform plan からアクションを適用します。

    terraform apply
DevOps エンジニア
タスク説明必要なスキル

デプロイを検証する。

  1. にサインイン AWS マネジメントコンソール し、https://console.aws.amazon.com/cloudfront/v4/home で Amazon CloudFront コンソールを開きます。

  2. 左側のナビゲーションペインで、[ディストリビューション] を選択し、[CloudFront ディストリビューション] を選択します。

  3. [オリジン] タブで、オリジン名とオリジンマッピングに更新された ALB DNS レコードがあることを確認します。

DevOps エンジニア
タスク説明必要なスキル

インフラストラクチャをクリーンアップします。

作成したインフラストラクチャをクリーンアップするには、次の手順に従います。

  1. 次のコマンドを実行します。terraform destroy

  2. destroy コマンドを確認するには、「yes」と入力します。

DevOps エンジニア

トラブルシューティング

問題ソリューション

プロバイダー認証情報の検証中にエラーが発生しました。

ローカルマシンから Terraform apply または destroy コマンドを実行すると、次のようなエラーが発生する場合があります。

Error: configuring Terraform AWS Provider: error validating provider 
credentials: error calling sts:GetCallerIdentity: operation error STS: 
GetCallerIdentity, https response error StatusCode: 403, RequestID: 
123456a9-fbc1-40ed-b8d8-513d0133ba7f, api error InvalidClientTokenId: 
The security token included in the request is invalid.

このエラーは、ローカルマシンの設定で使用されている認証情報のセキュリティトークンの有効期限が切れていることが原因です。

エラーを解決するには、 AWS Command Line Interface (AWS CLI) ドキュメントの「設定の設定と表示」を参照してください。

関連リソース

AWS リソース

Terraformのドキュメント

追加情報

問題のあるワークフロー

CloudFront で古い ALB DNS エントリを生成するワークフロー。

この図表は、次のワークフローを示しています:

  1. ユーザーがアプリケーションにアクセスすると、呼び出しは CloudFront に送信されます。

  2. CloudFront は、呼び出しをそれぞれの Application Load Balancer (ALB) にルーティングします。

  3. ALB には、アプリケーションポッドの IP アドレスであるターゲット IP アドレスが含まれています。そこから、ALB はユーザーに期待される結果を提供します。

ただし、このワークフローには問題があります。アプリケーションのデプロイは Helm チャートを通じて行われます。デプロイがあるたびに、または誰かが Helm を再起動すると、それぞれのイングレスも再作成されます。その結果、外部のロードバランサーコントローラーが ALB を再作成します。また、再作成のたびに、ALB は別の DNS 名で再作成されます。このため、CloudFront に最初の設定で古いエントリが作成されます。このエントリのためにユーザーはアプリケーションにアクセスできなくなります。この問題はユーザーのダウンタイムにつながります。

代替の解決策

もう 1 つの可能な解決策は、ALB の外部 DNS を作成し、CloudFront の Amazon Route 53 プライベートホストゾーンエンドポイントを指すことです。ただし、このアプローチではアプリケーションフローに別のホップが追加されるため、アプリケーションに遅延が発生する可能性があります。このパターンの Lambda 関数ソリューションは、現在のフローを中断しません。