翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 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 レコードを参照し続けることが原因で発生します。そのためこのエンドポイント宛てのサービスに到達できません。(このワークフローの問題に関する詳細は[追加情報](#automate-cloudfront-updates-when-load-balancer-endpoints-change-additional)を参照してください)。
この問題を解決するために、このパターンでは Python で開発されたカスタム AWS Lambda 関数の使用について説明します。この Lambda 関数は、Amazon EventBridge ルールを使用して新しい ALB がいつ作成されるかを自動的に検出します。を使用して AWS SDK for Python (Boto3)、関数は新しい ALB の DNS アドレスで CloudFront 設定を更新し、トラフィックが正しいエンドポイントにルーティングされるようにします。
この自動化されたソリューションは、追加のルーティングなしで、また遅延を発生させることなくサービスの継続性を維持します。このプロセスにより、基盤となるインフラストラクチャが変更されても、CloudFront は常に正しい ALB DNS エンドポイントを参照することができます。
## 前提条件と制限
**前提条件**
+ アクティブ AWS アカウント。
+ Helm を使用して Amazon EKS にデプロイされる、テスト用および検証用のサンプルウェブアプリケーション。詳細については、Amazon EKS ドキュメントの「[Helm を使用して Amazon EKS にアプリケーションをデプロイする](https://docs.aws.amazon.com/eks/latest/userguide/helm.html)」を参照してください。
+ Helm の[Ingress コントローラー](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/)が作成した ALB に、呼び出しをルーティングするように CloudFront を設定します。詳細については、Amazon EKS ドキュメントの「[Install AWS Load Balancer Controller with Helm](https://docs.aws.amazon.com/eks/latest/userguide/lbc-helm.html)」および CloudFront ドキュメントの[「Application Load Balancer へのアクセスを制限する](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/restrict-access-to-load-balancer.html)」を参照してください。
+ ローカルワークスペースに[インストール](https://developer.hashicorp.com/terraform/install?product_intent=terraform)され設定された Terraform。
**制限事項**
+ 一部の AWS のサービス は では使用できません AWS リージョン。利用可能なリージョンについては、「[AWS サービス (リージョン別)](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)」を参照してください。特定のエンドポイントについては、[「サービスエンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)」を参照して、サービスのリンクを選択してください。
**製品バージョン**
+ Terraform バージョン 1.0.0 以降
+ Terraform [AWS Provider](https://registry.terraform.io/providers/hashicorp/aws/latest/docs) バージョン 4.20 以降
## アーキテクチャ
次の図表は、このパターンのアプリケーションのワークフローとアーキテクチャコンポーネントを示しています。
以下の手順で実行します。
1. Amazon EKS Ingress コントローラーは、Helm の再起動またはデプロイが行われるたびに、新しい Application Load Balancer (ALB) を作成します。
1. EventBridge は ALB の作成イベントを検索します。
1. ALB の作成イベントは Lambda 関数をトリガーします。
1. Lambda 関数は python 3.9 に基づいてデプロイされており、boto3 API を使用して を呼び出します AWS のサービス。Lambda 関数は、ロードバランサーの作成イベントから受信した最新のロードバランサー DNS 名で CloudFront エントリを更新します。
## ツール
**AWS のサービス**
+ [Amazon CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html) は、世界中のデータセンターネットワークを通じて配信することで、ウェブコンテンツの配信を高速化します。これにより、レイテンシーが減少し、パフォーマンスが向上します。
+ [Amazon Elastic Kubernetes Service (Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html) を使用すると、独自の Kubernetes コントロールプレーンやノードをインストールまたは維持 AWS することなく、 で Kubernetes を実行できます。
+ [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) は、アプリケーションをさまざまなソースのリアルタイムデータに接続できるようにするサーバーレスイベントバスサービスです。例えば、 AWS Lambda 関数、API 送信先を使用する HTTP 呼び出しエンドポイント、その他のイベントバスなどです AWS アカウント。
+ [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。
+ [AWS SDK for Python (Boto3)](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/quickstart.html) は、Python アプリケーション、ライブラリ、またはスクリプトを と統合するのに役立つソフトウェア開発キットです AWS のサービス。
**その他のツール**
+ 「[Python](https://www.python.org/)」は汎用のコンピュータプログラミング言語です。
+ 「[Terraform](https://www.terraform.io/)」は、HashiCorp の infrastructure as code (IaC) ツールで、クラウドとオンプレミスのリソースの作成と管理を支援します。
**コードリポジトリ**
このパターンのコードは、GitHub の [aws-cloudfront-automation-terraform-samples](https://github.com/aws-samples/aws-cloudfront-automation-terraform-samples) リポジトリで利用できます。
## エピック
### ローカルワークステーションのセットアップ
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| Git CLI をセットアップして設定します。 | ローカルワークステーションに Git コマンドラインインターフェイス (CLI) をインストールして設定するには、Git ドキュメントの「[Getting Started – Installing Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)」の手順に従います。 | DevOps エンジニア |
| プロジェクトフォルダを作成し、ファイルを追加します。 | [See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-cloudfront-updates-when-load-balancer-endpoints-change.html) | DevOps エンジニア |
### Terraform の設定を使用してターゲットアーキテクチャをプロビジョニングする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| ソリューションのデプロイ | ターゲットにリソースをデプロイするには AWS アカウント、次のステップを使用します。[See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-cloudfront-updates-when-load-balancer-endpoints-change.html) | DevOps エンジニア |
### デプロイメントを確認する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| デプロイを検証する。 | [See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-cloudfront-updates-when-load-balancer-endpoints-change.html) | DevOps エンジニア |
### インフラストラクチャをクリーンアップ
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| インフラストラクチャをクリーンアップします。 | 作成したインフラストラクチャをクリーンアップするには、次の手順に従います。[See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-cloudfront-updates-when-load-balancer-endpoints-change.html) | 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) ドキュメントの[「設定の設定と表示](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html#cli-configure-files-methods)」を参照してください。 |
## 関連リソース
**AWS リソース**
+ [Application Load Balancer へのアクセスを制限する](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/restrict-access-to-load-balancer.html)
+ [AWS Load Balancerコントローラーを使用してインターネットトラフィックをルーティングする](https://docs.aws.amazon.com/eks/latest/userguide/aws-load-balancer-controller.html)
Terraformのドキュメント
+ [AWS プロバイダー](https://registry.terraform.io/providers/hashicorp/aws/latest/docs)
+ 「[Terraform のインストール](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli)」
+ [Remote State](https://developer.hashicorp.com/terraform/language/state/remote)
## 追加情報
**問題のあるワークフロー**
この図表は、次のワークフローを示しています:
1. ユーザーがアプリケーションにアクセスすると、呼び出しは CloudFront に送信されます。
1. CloudFront は、呼び出しをそれぞれの Application Load Balancer (ALB) にルーティングします。
1. ALB には、アプリケーションポッドの IP アドレスであるターゲット IP アドレスが含まれています。そこから、ALB はユーザーに期待される結果を提供します。
ただし、このワークフローには問題があります。アプリケーションのデプロイは Helm チャートを通じて行われます。デプロイがあるたびに、または誰かが Helm を再起動すると、それぞれのイングレスも再作成されます。その結果、外部のロードバランサーコントローラーが ALB を再作成します。また、再作成のたびに、ALB は別の DNS 名で再作成されます。このため、CloudFront に最初の設定で古いエントリが作成されます。このエントリのためにユーザーはアプリケーションにアクセスできなくなります。この問題はユーザーのダウンタイムにつながります。
**代替の解決策**
もう 1 つの可能な解決策は、ALB の[外部 DNS](https://github.com/kubernetes-sigs/external-dns) を作成し、CloudFront の Amazon Route 53 プライベートホストゾーンエンドポイントを指すことです。ただし、このアプローチではアプリケーションフローに別のホップが追加されるため、アプリケーションに遅延が発生する可能性があります。このパターンの Lambda 関数ソリューションは、現在のフローを中断しません。