翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# DevOps
**Topics**
+ [Backstage とセルフサービスの Amazon SageMaker AI テンプレートを使用して MLOps を高速化](accelerate-mlops-with-backstage-and-sagemaker-templates.md)
+ [Amazon Bedrock を使用して AWS インフラストラクチャオペレーションを自動化する](automate-aws-infrastructure-operations-by-using-amazon-bedrock.md)
+ [Terraform を使用してロードバランサーエンドポイントが変更されたときの CloudFront 更新を自動化](automate-cloudfront-updates-when-load-balancer-endpoints-change.md)
+ [GitHub Actions を使用して Python AWS CDK アプリケーションの Amazon CodeGuru レビューを自動化する](automate-amazon-codeguru-reviews-for-aws-cdk-python-applications.md)
+ [GitHub Actions、Artifactory、Terraform を使用して、マルチリポジトリ設定で AWS Supply Chain データレイクのデプロイを自動化する](automate-the-deployment-of-aws-supply-chain-data-lakes.md)
+ [AWS リソース評価を自動化する](automate-aws-resource-assessment.md)
+ [オープンソースツールを使用して SAP システムを自動的にインストール](install-sap-systems-automatically-by-using-open-source-tools.md)
+ [AWS CDK を使用して AWS Service Catalog ポートフォリオと製品のデプロイを自動化する](automate-aws-service-catalog-portfolio-and-product-deployment-by-using-aws-cdk.md)
+ [AWS Service Catalog と を使用して、Gitflow 環境にホットフィックスソリューションをデプロイするための動的パイプライン管理を自動化する AWS CodePipeline](automate-dynamic-pipeline-management-for-deploying-hotfix-solutions.md)
+ [AWS CloudFormation スタックと関連リソースの削除を自動化する](automate-deletion-cloudformation-stacks-associated-resources.md)
+ [Terraform を使用して Amazon Managed Grafana での Amazon MWAA カスタムメトリクスの取り込みと視覚化を自動化する](automate-ingestion-and-visualization-of-amazon-mwaa-custom-metrics.md)
+ [AWS CodePipeline および AWS CodeBuild を使用して、スタックセットデプロイを自動化](automate-stack-set-deployment-by-using-aws-codepipeline-and-aws-codebuild.md)
+ [Cloud Custodian と AWS CDK を使用して、Systems Manager の AWS マネージドポリシーを EC2 インスタンスプロファイルに自動的にアタッチする](automatically-attach-an-aws-managed-policy-for-systems-manager-to-ec2-instance-profiles-using-cloud-custodian-and-aws-cdk.md)
+ [AWS CDK を使用してマイクロサービス用の CI/CD パイプラインと Amazon ECS クラスターを自動的に構築する](automatically-build-ci-cd-pipelines-and-amazon-ecs-clusters-for-microservices-using-aws-cdk.md)
+ [GitHub Actions と Terraform を使用して Docker イメージを構築し Amazon ECR にプッシュする](build-and-push-docker-images-to-amazon-ecr-using-github-actions-and-terraform.md)
+ [AWS CodeCommit、AWS CodePipeline、AWS Device Farm を使用して iOS アプリを構築してテストする](build-and-test-ios-apps-with-aws-codecommit-aws-codepipeline-and-aws-device-farm.md)
+ [Amazon EKS で実行されているアプリケーションの相互 TLS 認証を設定する](configure-mutual-tls-authentication-for-applications-running-on-amazon-eks.md)
+ [を使用して Amazon WorkSpaces アプリケーションリソースの作成を自動化する AWS CloudFormation](automate-the-creation-of-appstream-2-0-resources-using-aws-cloudformation.md)
+ [Firelens ログルーターを使用して Amazon ECS 用のカスタムログパーサーを作成する](create-a-custom-log-parser-for-amazon-ecs-using-a-firelens-log-router.md)
+ [GitHub Actions と Terragrunt を使用した API 駆動型リソースオーケストレーションフレームワークの作成](create-an-api-driven-resource-orchestration-framework-using-github-actions-and-terragrunt.md)
+ [GitHub Actions を使用して Terraform マネージド AWS インフラストラクチャの自動プルリクエストを作成する](create-automated-pull-requests-for-terraform-managed-aws-infrastructure.md)
+ [Java および Python プロジェクト用の動的 CI パイプラインを自動的に作成](create-dynamic-ci-pipelines-for-java-and-python-projects-automatically.md)
+ [Terraform を使用して CloudWatch Synthetics Canary をデプロイする](deploy-cloudwatch-synthetics-canaries-by-using-terraform.md)
+ [ChatOps ソリューションをデプロイして、チャットアプリケーションのカスタムアクションと で Amazon Q Developer を使用して SAST スキャン結果を管理する CloudFormation](deploy-chatops-solution-to-manage-sast-scan-results.md)
+ [Terraform を使用して CrewAI フレームワークで Amazon Bedrock にエージェンティックシステムを展開する](deploy-agentic-systems-on-amazon-bedrock-with-the-crewai-framework.md)
+ [AWS CodePipeline CI/CD パイプラインで AWS Glue ジョブをデプロイする](deploy-an-aws-glue-job-with-an-aws-codepipeline-ci-cd-pipeline.md)
+ [AWS CodePipeline、AWS CodeCommit、AWS CodeBuild を使用して、複数の AWS リージョンにコードをデプロイする](deploy-code-in-multiple-aws-regions-using-aws-codepipeline-aws-codecommit-and-aws-codebuild.md)
+ [Azure DevOps パイプラインからプライベート Amazon EKS クラスターにワークロードをデプロイする](deploy-workloads-from-azure-devops-pipelines-to-private-amazon-eks-clusters.md)
+ [Terraform を使用して Amazon Redshift SQL クエリを実行する](execute-redshift-sql-queries-using-terraform.md)
+ [AWS Organizations 内の組織全体の AWS Backup レポートを CSV ファイルとしてエクスポートする](export-aws-backup-reports-from-across-an-organization-in-aws-organizations-as-a-csv-file.md)
+ [Amazon EC2 インスタンスのリストのタグを CSV ファイルにエクスポートする](export-tags-for-a-list-of-amazon-ec2-instances-to-a-csv-file.md)
+ [Troposphere を使用して AWS Config マネージドルールを含む AWS CloudFormation テンプレートを生成します](generate-an-aws-cloudformation-template-containing-aws-config-managed-rules-using-troposphere.md)
+ [SageMaker ノートブックインスタンスに、別の AWS アカウントの CodeCommit リポジトリへの一時的なアクセスを許可する](give-sagemaker-notebook-instances-temporary-access-to-a-codecommit-repository-in-another-aws-account.md)
+ [マルチアカウント DevOps 環境に GitHub フローブランチ戦略を実装する](implement-a-github-flow-branching-strategy-for-multi-account-devops-environments.md)
+ [マルチアカウント DevOps 環境に Gitflow ブランチ戦略を実装する](implement-a-gitflow-branching-strategy-for-multi-account-devops-environments.md)
+ [マルチアカウント DevOps 環境に Trunk 分岐戦略を実装する](implement-a-trunk-branching-strategy-for-multi-account-devops-environments.md)
+ [AWS インフラストラクチャをデプロイする前に、一元化されたカスタム Checkov スキャンを実装してポリシーを適用する](centralized-custom-checkov-scanning.md)
+ [K8sGPT と Amazon Bedrock の統合を利用して AI を活用した Kubernetes の診断とトラブルシューティングを実装する](implement-ai-powered-kubernetes-diagnostics-and-troubleshooting-with-k8sgpt-and-amazon-bedrock-integration.md)
+ [CodeCommit 内のモノリポジトリの変更を自動的に検出し、さまざまな CodePipeline パイプラインを開始する](automatically-detect-changes-and-initiate-different-codepipeline-pipelines-for-a-monorepo-in-codecommit.md)
+ [AWS CloudFormation を使用して Bitbucket リポジトリを AWS Amplify と統合する](integrate-a-bitbucket-repository-with-aws-amplify-using-aws-cloudformation.md)
+ [Step Functions と Lambda プロキシ関数を使用して AWS アカウント間で CodeBuild プロジェクトを起動する](launch-a-codebuild-project-across-aws-accounts-using-step-functions-and-a-lambda-proxy-function.md)
+ [Application Recovery Controller を使用して EMR クラスターのマルチ AZ フェイルオーバーを管理する](multi-az-failover-spark-emr-clusters-arc.md)
+ [AWS コードサービスと AWS KMS マルチリージョンキーを使用して、複数のアカウントとリージョンへのマイクロサービスのブルー/グリーンデプロイを管理](manage-blue-green-deployments-of-microservices-to-multiple-accounts-and-regions-by-using-aws-code-services-and-aws-kms-multi-region-keys.md)
+ [AWS CloudFormation と AWS Config を使用して Amazon ECR リポジトリのワイルドカード権限をモニタリングする](monitor-amazon-ecr-repositories-for-wildcard-permissions-using-aws-cloudformation-and-aws-config.md)
+ [AWS CDK および GitHub Actions ワークフローを使用してマルチアカウントサーバーレスデプロイを最適化する](optimize-multi-account-serverless-deployments.md)
+ [GitHub Actions を使用して AWS CloudFormation テンプレートに基づいて AWS Service Catalog 製品をプロビジョニングする](provision-aws-service-catalog-products-using-github-actions.md)
+ [ロールベンディングマシンソリューションをデプロイして最小特権の IAM ロールをプロビジョニングする](provision-least-privilege-iam-roles-by-deploying-a-role-vending-machine-solution.md)
+ [Amazon CloudWatch メトリクスを CSV ファイルに公開](publish-amazon-cloudwatch-metrics-to-a-csv-file.md)
+ [AWS Lambda オートメーションを使用して 全体の Amazon EC2 エントリを AWS アカウント から削除 AWS Managed Microsoft AD する](remove-amazon-ec2-entries-across-aws-accounts-from-aws-managed-microsoft-ad.md)
+ [AWS Lambda オートメーションを使用して AWS アカウント から同じ の Amazon EC2 AWS Managed Microsoft AD エントリを削除する](remove-amazon-ec2-entries-in-the-same-aws-account-from-aws-managed-microsoft-ad.md)
+ [pytest フレームワーク AWS Glue を使用して で Python ETL ジョブのユニットテストを実行する](run-unit-tests-for-python-etl-jobs-in-aws-glue-using-the-pytest-framework.md)
+ [AWS CodePipeline と AWS CDK を使用して CI/CD パイプラインを設定する](set-up-a-ci-cd-pipeline-by-using-aws-codepipeline-and-aws-cdk.md)
+ [Terraform を使用してエンタープライズ規模で一元化されたログ記録を設定する](set-up-centralized-logging-at-enterprise-scale-by-using-terraform.md)
+ [cert-managerと Let's Encrypt を使用して Amazon EKS のアプリケーションのエンドツーエンド暗号化を設定](set-up-end-to-end-encryption-for-applications-on-amazon-eks-using-cert-manager-and-let-s-encrypt.md)
+ [Flux を使用して Amazon EKS マルチテナントアプリケーションのデプロイを簡素化する](simplify-amazon-eks-multi-tenant-application-deployment-by-using-flux.md)
+ [自動ワークフローを使用して Amazon Lex ボットの開発とデプロイを合理化する](streamline-amazon-lex-bot-development-and-deployment-using-an-automated-workflow.md)
+ [AWS Fargate WaitCondition フック構造を使用してリソースの依存関係とタスク実行を調整する](use-the-aws-fargate-waitcondition-hook-construct.md)
+ [AWS CodePipeline のサードパーティーの Git ソースリポジトリを使用する](use-third-party-git-source-repositories-in-aws-codepipeline.md)
+ [AWS CodePipeline を使用して Terraform の構成を検証するための CI/CD パイプラインを作成する](create-a-ci-cd-pipeline-to-validate-terraform-configurations-by-using-aws-codepipeline.md)
+ [その他のパターン](devops-more-patterns-pattern-list.md)
# Backstage とセルフサービスの Amazon SageMaker AI テンプレートを使用して MLOps を高速化
*Amazon Web Services、Ashish Bhatt、Shashank Hirematt、Shivanshu Suryakar*
## 概要
機械学習オペレーション (MLOps) システムを使用している多くの組織は、ML インフラストラクチャのスケーリング、標準化、保護において大きな課題に直面しています。このパターンでは、オープンソースのデベロッパーポータルである [Backstage](https://backstage.io/) と [Amazon SageMaker AI](https://aws.amazon.com/sagemaker/)、および強化された Infrastructure as Code (IaC) モジュールを組み合わせることで、データサイエンスチームによる ML ワークフローの開発、デプロイ、管理の方法を向上させる革新的なアプローチを取り入れています。
このパターンの IaC モジュールは、GitHub [AWS AIOps モジュール](https://github.com/awslabs/aiops-modules/tree/main/modules/sagemaker)リポジトリで提供されています。これらのモジュールでは、ML インフラストラクチャをセットアップし一貫した ML 環境を作成する構築済みのテンプレートが提供されます。しかし、インフラストラクチャの専門知識が必要になるため、データサイエンティストがこれらのテンプレートをそのまま使用すると、苦労することがよくあります。Backstage などのデベロッパーポータルを追加すると、標準化された ML 環境を簡単にデプロイできるため、データサイエンティストは基盤となるインフラストラクチャの詳細を理解する必要はありません。
Backstage をセルフサービスプラットフォームとして使用し、事前設定された SageMaker AI テンプレートを統合することで、次のことが可能になります。
+ ML イニシアチブの価値実現までの時間を短縮する。
+ 一貫したセキュリティとガバナンスの実施を支援する。
+ データサイエンティストに標準化された準拠環境を提供する。
+ 運用上のオーバーヘッドとインフラストラクチャの複雑さを軽減する。
このパターンでは、MLOps の重要な課題に対処するためのソリューションと、組織の標準を維持しながらイノベーションを可能にするスケーラブルで反復可能なフレームワークも提供されます。
**ターゲットオーディエンス**
このパターンは、組織内の ML、クラウドアーキテクチャ、プラットフォームエンジニアリングに携わる幅広いユーザーを対象としています。これには、以下が含まれます。
+ **ML ワークフローのデプロイを標準化および自動化したいと考えている ML エンジニア**。
+ 標準に準拠した事前設定済みの ML 環境へのセルフサービスアクセスを希望する**データサイエンティスト**。
+ 社内デベロッパーのプラットフォームおよび共有インフラストラクチャの構築と保守を担当する**プラットフォームエンジニア**。
+ MLOps 用の安全でスケーラブルかつ費用対効果の高いクラウドソリューションを設計する**クラウドアーキテクト**。
+ 継続的インテグレーションと継続的デリバリー (CI/CD) のプラクティスを ML インフラストラクチャのプロビジョニングとワークフローに拡張することに関心のある **DevOps エンジニア**。
+ ML イニシアチブを監督し、チームの生産性、ガバナンス、市場投入までの時間を向上させたいと考えている**技術部門のリーダーおよびマネージャー**。
MLOps の課題、SageMaker AI MLOps モジュール、および本パターンによって提供されるソリューションが ML チームのニーズにどう対応するのかの詳細については、「[追加情報](#accelerate-mlops-with-backstage-and-sagemaker-templates-additional)」のセクションを参照してください。
## 前提条件と制限事項
**前提条件**
+ AWS Identity and Access Management にリソースをプロビジョニングするための (IAM) [ロールとアクセス許可](https://github.com/aws-samples/sample-aiops-idp-backstage/blob/main/SETUP.md#prerequisites) AWS アカウント
+ [Amazon SageMaker Studio](https://docs.aws.amazon.com/sagemaker/latest/dg/studio-updated.html)、[SageMaker プロジェクト](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-projects-whatis.html)、[SageMaker Pipelines](https://docs.aws.amazon.com/sagemaker/latest/dg/pipelines-overview.html)、[SageMaker モデルレジストリ](https://docs.aws.amazon.com/sagemaker/latest/dg/model-registry.html)の概念を理解していること
+ IaC の原則を理解しており、[AWS Cloud Development Kit (AWS CDK)](https://aws.amazon.com/cdk/) などのツールを使用したことがあること
**制限事項**
+ **テンプレートの対象範囲には制限があります**。現在、このソリューションは、より広範な [AIOps ソリューション](https://github.com/awslabs/aiops-modules)の SageMaker AI 関連の AIOps モジュールのみをサポートしています。Ray on Amazon Elastic Kubernetes Service (Amazon EKS)、MLflow、Apache Airflow、Amazon Bedrock のファインチューニングなどの他のモジュールは、Backstage テンプレートとしてまだご利用いただけません。
+ **設定不可能なデフォルトの設定**。テンプレートでは、AIOps SageMaker モジュールからの固定のデフォルト設定がカスタマイズなしで使用されます。Backstage のインターフェイスから、インスタンスタイプ、ストレージサイズ、ネットワーク設定、セキュリティポリシーを変更することはできないため、特定のユースケースでは柔軟性が制限されます。
+ **AWSのみをサポートしています**。プラットフォームは AWS デプロイ専用に設計されており、マルチクラウドシナリオをサポートしていません。の外部でクラウドサービスを使用する組織は AWS クラウド 、これらのテンプレートを ML インフラストラクチャのニーズに使用することはできません。
+ **手動での認証情報管理**。デプロイごとに AWS 認証情報を手動で指定する必要があります。このソリューションでは、企業 ID プロバイダーとの統合 AWS IAM アイデンティティセンターや認証情報の自動ローテーションは提供されません。
+ **ライフサイクル管理の制限**。このテンプレートには、自動クリーンアップポリシー、コスト最適化の推奨事項、インフラストラクチャのドリフト検出などの包括的なリソースライフサイクル管理機能はありません。デプロイされたリソースは、作成後に手動で管理およびモニタリングする必要があります。
## アーキテクチャ
次の図は、SageMaker AI を使用して環境間で ML インフラストラクチャのデプロイを標準化および高速化する、統合デベロッパーポータルのソリューションアーキテクチャを示したものです。
![\[Backstage、CNOE、GitHub Actions、Seed-Farmer を使用した統合デベロッパーポータルのアーキテクチャ。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/c16160cf-d637-423e-93a7-485ffbb28646/images/233adab3-83cf-42f3-a1de-72d0b8ade5ae.png)
このアーキテクチャの詳細は以下のとおりです。
1. [AWS アプリケーションのモダナイゼーションブループリントは](https://github.com/aws-samples/appmod-blueprints.git)、[Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html) クラスターを使用してインフラストラクチャのセットアップを [Cloud Native Operational Excellence (CNOE)](https://cnoe.io/) フレームワークのベースとしてプロビジョニングします。この包括的なソリューションは、社内デベロッパー向けのスケーラブルなプラットフォーム (IDP) を提供することで、クラウドネイティブなインフラストラクチャ管理における複雑な課題を解消します。この設計図は、進化する組織のニーズに適応できる堅牢で柔軟なインフラストラクチャをセットアップする構造化されたアプローチを示しています。
1. CNOE オープンソースフレームワークは、DevOps ツールを統合し、統合されたプラットフォームエンジニアリングアプローチを通じてエコシステムの断片化を解決します。さまざまなツールとテクノロジーを組み合わせることで、クラウドネイティブ開発の複雑な環境を簡素化できるため、チームはツールチェーンの管理ではなくイノベーションに専念できます。このフレームワークは、開発ツールを選択、統合、管理するための標準化された方法を提供します。
1. CNOE では、Backstage は Amazon EKS クラスター内にすぐに使えるソリューションとしてデプロイされます。Backstage は、[Keycloak](https://www.keycloak.org/) による堅牢な認証と[、Argo CD](https://argo-cd.readthedocs.io/en/stable/) による包括的なデプロイワークフローにバンドルされています。この統合プラットフォームは、開発プロセスを管理するための一元化された環境を作成し、チームが複数の環境をまたいでインフラストラクチャとアプリケーションにアクセス、デプロイ、モニタリングできる一元的な場所として機能します。
1. GitHub リポジトリには、SageMaker AI ライフサイクル全体をカバーする、事前設定済みの AIOps ソフトウェアテンプレートが含まれています。これらのテンプレートは、SageMaker Studio のプロビジョニング、モデルトレーニング、推論パイプライン、モデルモニタリングなど、重要な ML インフラストラクチャのニーズに対処します。これらのテンプレートを使えば、ML イニシアチブを加速させ、さまざまなプロジェクトやチーム間で一貫性を確保することができます。
1. [GitHub Actions](https://github.com/features/actions) は、[Seed-Farmer](https://github.com/awslabs/seed-farmer) ユーティリティを介してリソースプロビジョニングを動的にトリガーする自動ワークフローを実装しています。このアプローチでは、Backstage カタログを AIOps モジュールリポジトリと統合させ、効率的なインフラストラクチャデプロイプロセスを作成します。自動化によって手動介入が軽減され、人的ミスを最小限に抑えることができ、さまざまな環境で迅速かつ一貫したインフラストラクチャの作成が可能になります。
1. [AWS CDK](https://docs.aws.amazon.com/cdk/v2/guide/home.html) を使うことで、インフラストラクチャをコードとして定義してプロビジョニングすることができます。また、指定された AWS アカウント全体で反復可能な標準に準拠した安全なリソースをデプロイできます。このアプローチは、最小限の手動介入で最大限のガバナンスを実現できるため、標準化されたインフラストラクチャテンプレートを作成して、複製やバージョン管理、監査を簡単に行うことができます。
## ツール
**AWS のサービス**
+ [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/v2/guide/home.html) は、コードで AWS クラウド インフラストラクチャを定義およびプロビジョニングするのに役立つソフトウェア開発フレームワークです。
+ [Amazon Elastic Kubernetes Service (Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html) を使用すると、独自の Kubernetes コントロールプレーンやノードをインストールまたは維持 AWS することなく、 で Kubernetes を実行できます。
+ [Amazon SageMaker AI](https://docs.aws.amazon.com/sagemaker/) は、ML モデルを構築およびトレーニングし、これらの ML モデルを、稼働準備の整ったホストされている環境にデプロイするのに役立つマネージド型 ML サービスです。
**その他のツール**
+ [Backstage](https://backstage.io/) は、社内デベロッパー向けポータルの構築に役立つオープンソースフレームワークです。
+ [GitHub Actions](https://github.com/features/actions) は、コードの構築、テスト、デプロイなどのタスクを含むソフトウェア開発のワークフローを自動化する CI/CD プラットフォームです。
**コードリポジトリ**
本パターンでは、次の GitHub リポジトリのコードとテンプレートを使用します。
+ [AIOps internal developer platform (IDP) with Backstage](https://github.com/aws-samples/sample-aiops-idp-backstage/) リポジトリ
+ [AWS AIOps モジュール](https://github.com/awslabs/aiops-modules)リポジトリの SageMaker AI 関連モジュール
+ [Modern engineering on AWS](https://github.com/aws-samples/appmod-blueprints) リポジトリ
**実装**
この実装では、[Modern engineering on AWS](https://github.com/aws-samples/appmod-blueprints) リポジトリから Backstage の本番稼働グレードのデプロイパターンを使用します。このアプローチは、セキュリティとスケーラビリティの AWS ベストプラクティスを組み込むと同時に、セットアッププロセスを大幅に簡素化します。
このパターンの[エピック](#accelerate-mlops-with-backstage-and-sagemaker-templates-epics)のセクションでは、実装アプローチの概要を説明します。詳細なデプロイ手順については、[Backstage を備えた AIOps 内部開発者プラットフォーム](https://github.com/aws-samples/sample-aiops-idp-backstage/)リポジトリにある包括的な[デプロイガイド](https://github.com/aws-samples/sample-aiops-idp-backstage/blob/main/SETUP.md)を参照してください。この実装には以下が含まれます。
+ 初期 Backstage プラットフォームのデプロイ
+ SageMaker ソフトウェアテンプレートと Backstage の統合
+ Backstage テンプレートの使用と保守
本デプロイガイドには、継続的なメンテナンス、トラブルシューティング、プラットフォームのスケーリングに関するガイダンスも含まれています。
## ベストプラクティス
これらのベストプラクティスに従い、MLOps インフラストラクチャ実装のセキュリティ、ガバナンス、運用上の優秀性を確保してください。
**テンプレート管理**
+ ライブテンプレートに大きな変更を加えない。
+ 本番環境にデプロイするときは事前に更新を十分にテストする。
+ 明確かつ十分に立証されたテンプレートバージョンを維持する。
**セキュリティ**
+ GitHub Actions を特定のコミットセキュアハッシュアルゴリズム (SHAs) に固定し、サプライチェーン攻撃を防止する。
+ きめ細かなアクセス許可を持つ最小特権の IAM ロールを使用する。
+ 機密認証情報は [GitHub Secrets](https://docs.github.com/en/actions/concepts/security/secrets) および [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) に保存する。
+ 認証情報をテンプレートでハードコードしない。
**ガバナンスと追跡**
+ 包括的なリソースタグ付け標準を実装する。
+ 正確なコスト追跡とコンプライアンスモニタリングを有効にする。
+ インフラストラクチャの変更に関する明確な監査証跡を維持する。
本ガイドは、Backstage、SageMaker AI、IaC モジュールを使用して上記のベストプラクティスを実装するための強固な基盤となるものです。
## エピック
### ML 環境のセットアップ
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| Backstage をデプロイする。 | このステップでは、 リポジトリ[の Modern Engineering AWS](https://github.com/aws-samples/appmod-blueprints) のブループリントを使用して、複数の を統合して ML ワークフロー用の一元化された IDP を作成する堅牢 AWS のサービス でスケーラブルなインフラストラクチャを構築します。デプロイガイドの[「Backstage deployment」セクション](https://github.com/aws-samples/sample-aiops-idp-backstage/blob/main/SETUP.md#backstage-deployment)の指示に従って、リポジトリのクローン作成、依存関係のインストール、環境変数 AWS CDK の設定のブートストラップ、Backstage プラットフォームのデプロイを行います。インフラストラクチャは、IDP コンポーネントをデプロイするためのコンテナオーケストレーションプラットフォームとして Amazon EKS を使用します。Amazon EKS アーキテクチャには、厳密なネットワーク分離を規定し、アクセスパターンを制御するための安全なネットワーク設定が含まれています。このプラットフォームには認証のメカニズムが統合され、サービスや環境間のユーザーアクセスを保護しています。 | プラットフォームエンジニア |
| SageMaker AI テンプレートをセットアップする。 | このステップでは、GitHub の [AIOps internal developer platform (IDP) with Backstage](https://github.com/aws-samples/sample-aiops-idp-backstage/) リポジトリのスクリプトを使用します。デプロイガイドの「[SageMaker テンプレートのセットアップ](https://github.com/aws-samples/sample-aiops-idp-backstage/blob/main/SETUP.md#sagemaker-template-setup)」のセクションの指示に従って、リポジトリのクローンを作成し、前提条件を設定し、セットアップスクリプトを実行します。このプロセスでは、Backstage との統合に必要な SageMaker AI テンプレートを含むリポジトリを作成します。 | プラットフォームエンジニア |
| SageMaker AI** **テンプレートを Backstage と統合する。 | デプロイガイドの「[SageMaker テンプレートの統合](https://github.com/aws-samples/sample-aiops-idp-backstage/blob/main/SETUP.md#sagemaker-templates-integration)」セクションの指示に従って、SageMaker AI テンプレートを登録します。このステップでは、AIOps モジュール (前のステップの SageMaker AI テンプレート) を Backstage デプロイに統合し、ML インフラストラクチャのニーズをセルフサービスできるようにします。 | プラットフォームエンジニア |
| Backstage の SageMaker AI テンプレートを使用する。 | デプロイガイドの「[SageMaker テンプレートの使用](https://github.com/aws-samples/sample-aiops-idp-backstage/blob/main/SETUP.md#using-sagemaker-templates)」セクションの指示に従って Backstage ポータルにアクセスし、SageMaker Studio で ML 環境を作成します。Backstage ポータルでは、SageMaker Studio 環境、SageMaker ノートブック、カスタム SageMaker プロジェクトテンプレート、モデルデプロイパイプラインのオプションなど、使用可能な SageMaker AI テンプレートの中から選択できます。設定パラメータを指定すると、プラットフォームは自動的に専用リポジトリを作成し、GitHub Actions と Seed-Farmer を通じて AWS リソースをプロビジョニングします。進行状況は、GitHub Actions ログと Backstage コンポーネントカタログからモニタリングできます。 | データサイエンティスト、データエンジニア、デベロッパー |
### ガバナンスとコンプライアンス用のテンプレートの管理
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| SageMaker AI テンプレートを更新する。 | Backstage で SageMaker AI テンプレートを更新するには、次の手順に従います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/accelerate-mlops-with-backstage-and-sagemaker-templates.html) | プラットフォームエンジニア |
| テンプレートの複数のバージョンを作成および管理する。 | 破壊的変更やアップグレードの場合は、複数のバージョンの SageMaker AI テンプレートを作成することをお勧めします。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/accelerate-mlops-with-backstage-and-sagemaker-templates.html) | プラットフォームエンジニア |
### ML 環境の拡張
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| テンプレートの対象範囲を SageMaker AI を超えて拡張する。 | 現在のソリューションに実装されているのは SageMaker AI 関連の AIOps テンプレートのみです。[AIOps モジュール](https://github.com/awslabs/aiops-modules)を追加し、追加の AWS のサービス およびアプリケーション用のカスタムソフトウェアテンプレートを統合することで、ML 環境を拡張できます。これらは、Backstage のテンプレートデザイナーインターフェイスを使用するか、カスタムスキャフォールダーアクションを実装するか、標準メタデータでテンプレートリポジトリを維持することで作成できます。このプラットフォームは、一貫性を保つために、テンプレートのバージョニング、チーム間の共有、検証ワークフローをサポートしています。詳細については、[Backstage のドキュメント](https://backstage.io/docs/overview/what-is-backstage/)を参照してください。テンプレートの継承パターンを実装して、ベーステンプレートの特殊なバージョンを作成することもできます。この拡張性により、簡素化された開発者エクスペリエンスを維持し、組織の標準を維持しながら、SageMaker AI 以外のさまざまな AWS リソースやアプリケーションを管理できます。 | プラットフォームエンジニア |
| 動的パラメータインジェクションを使用する。 | 現在のテンプレートは、デフォルトの設定をカスタマイズなしで使用し、Seed-Farmer CLI を実行して、デフォルトの変数を持つリソースをデプロイします。デフォルトの設定は、モジュールに固有の設定に動的パラメータインジェクションを使用することで拡張できます。 | プラットフォームエンジニア |
| セキュリティとコンプライアンスを高める。 | AWS リソースの作成時のセキュリティを強化するために、ロールベースのアクセスコントロール (RBAC) に、シングルサインオン (SSO)、SAML、OpenID Connect (OIDC)、ポリシーをコード適用として統合することができます。 | プラットフォームエンジニア |
| 自動リソースクリーンアップを追加する。 | 自動クリーンアップポリシーの機能を有効にしたり、インフラストラクチャドリフトの検出と修復を追加したりできます。 | プラットフォームエンジニア |
### リソースをクリーンアップする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| Backstage インフラストラクチャと SageMaker AI リソースを削除する。 | ML 環境の使用が完了したら、デプロイガイドの「[クリーンアップとリソース管理](https://github.com/aws-samples/sample-aiops-idp-backstage/blob/main/SETUP.md#cleanup-and-resource-management)」セクションの指示に従って Backstage のインフラストラクチャを削除し、ML 環境で SageMaker AI リソースを削除します。 | プラットフォームエンジニア |
## トラブルシューティング
| 問題 | ソリューション |
| --- | --- |
| AWS CDK ブートストラップの失敗 | AWS 認証情報とリージョン設定を確認します。 |
| Amazon EKS クラスターアクセスの問題 | **kubectl** 設定と IAM アクセス許可を確認します。 |
| Application Load Balancer の接続の問題 | セキュリティグループで、ポート 80/443 上の受信トラフィックが許可されていることを確認します。 |
| SSH 統合の問題 | GitHub トークンのアクセス許可と組織アクセスを確認します。 |
| SageMaker AI デプロイの失敗 | [AWS のサービス クォータ](https://docs.aws.amazon.com/general/latest/gr/sagemaker.html#limits_sagemaker)と IAM アクセス許可を確認する。 |
## 関連リソース
+ [プラットフォームエンジニアリング](https://docs.aws.amazon.com/prescriptive-guidance/latest/aws-caf-platform-perspective/platform-eng.html)(「*AWS クラウド導入フレームワーク: プラットフォームの視点*」ガイドを参照)
+ [Amazon SageMaker AI ドキュメント](https://docs.aws.amazon.com/sagemaker/)
+ [Backstage Software Templates](https://backstage.io/docs/features/software-templates/) (Backstage ウェブサイト)
+ [AIOps modules repository](https://github.com/awslabs/aiops-modules) (ML 用の再利用可能な IaC モジュールのコレクション)
+ [AIOps internal developer platform (IDP) with Backstage](https://github.com/aws-samples/sample-aiops-idp-backstage/) リポジトリ
+ [Modern engineering on AWS](https://github.com/aws-samples/appmod-blueprints) リポジトリ
+ [Cloud Native Operational Excellence (CNOE) ウェブサイト](https://cnoe.io/)
## 追加情報
**ビジネス上の課題**
MLOps イニシアチブを開始またはスケールしようとする多くの組織が、ビジネス上および技術上の課題に頻繁に遭遇していす。
+ **一貫性のない環境**。開発環境とデプロイ環境が標準化されていないため、コラボレーションが困難になり、デプロイ上のリスクも高まります。
+ **手動プロビジョニングのオーバーヘッド**。SageMaker Studio、Amazon Simple Storage Service (Amazon S3) バケット、IAM ロール、CI/CD パイプラインを使用して ML インフラストラクチャを手動でセットアップするのには時間がかかり、エラーも発生しやすく、データサイエンティストはモデル開発のコアタスクに専念することができません。
+ **検出可能性と再利用性の欠如**。一元化されたカタログがなければ、既存の ML モデル、データセット、パイプラインを見つけることが困難になります。これにより、作業が重複し、再利用の機会が失われます。
+ **複雑なガバナンスとコンプライアンス**。自動化されたガードレールがなければ、ML プロジェクトが組織のセキュリティポリシー、データプライバシー規制、医療保険の相互運用性と説明責任に関する法律 (HIPAA)、および一般データ保護規則 (GDPR) などのコンプライアンス標準に準拠しているかどうかを確認することが困難になります。
+ **価値実現までの時間が長い**。これらの課題の累積的な影響により、ML プロジェクトのライフサイクルが長くなり、ML 投資によるビジネス価値の実現が遅れます。
+ **セキュリティ上のリスク**。設定や手動プロセスに一貫性がなければ、セキュリティの脆弱性が発生し、最小特権やネットワーク分離の適用が困難になる可能性があります。
これらの問題は、開発サイクルを長引かせ、運用オーバーヘッドを増やし、セキュリティリスクをもたらします。反復的な性質を持つ ML には、反復可能なワークフローと効率的なコラボレーションが不可欠です。
Gartner 社による予測では、ソフトウェアエンジニアリング組織の 80% が 2026 年までにプラットフォームチームを持つと予想されています。(Gartner 社のウェブサイト[「Platform Engineering Empowers Developers to be Better, Faster, Happier](https://www.gartner.com/en/experts/top-tech-trends-unpacked-series/platform-engineering-empowers-developers)」を参照)。この予測では IDP がいかにしてソフトウェア配信を高速化するかに焦点が当てられています。IDP である Backstage は、チームが高品質のコードを迅速かつ安全に提供できるよう、複雑なインフラストラクチャへの命令の復元をサポートします。Backstage と強化された AIOps モジュールとを統合することで、事後対応型のトラブルシューティングから事前対応型の予防への移行が可能になります。
**MLOps SageMaker モジュール**
このパターンに使用される GitHub リポジトリの [AIOps モジュールは](https://github.com/awslabs/aiops-modules)、再利用可能な強化された IaC AWS を通じて で MLOps を標準化するための貴重な基盤を提供します。これらのモジュールには、SageMaker プロジェクト、パイプライン、関連するネットワークおよびストレージリソースをプロビジョニングするためのベストプラクティスがカプセル化されているため、ML 環境の複雑さを軽減し、セットアップを高速化できます。これらのテンプレートをさまざまな MLOps ユースケースに使用することで、一貫性のある安全なデプロイパターンを確立し、ML ワークフローへの管理性および効率性が向上したアプローチを促進できます。
AIOps モジュールをそのまま使用すると、多くの場合、プラットフォームチームがこれらの IaC テンプレートをデプロイおよび管理しなければならなくなり、このことがセルフサービスアクセスを必要とするデータサイエンティストにとって課題となる可能性があります。使用可能なテンプレートの検出と理解、必要なパラメータの設定、デプロイのトリガーには、 AWS のサービス コンソールを操作するか、IaC ツールと直接やり取りする必要がある場合があります。これにより摩擦が生じ、ML タスクに専念したいデータサイエンティストの認知負荷が増加し、テンプレートが一元化された使いやすいインターフェイスで管理されていない場合には、一貫性のないパラメータ化や組織標準からの逸脱が生じる可能性があります。これらの強力な AIOps モジュールを Backstage などの IDP と統合すると、標準化された MLOps の構成要素を使用するための合理化されたセルフサービスエクスペリエンス、強化された検出可能性、強力なガバナンスコントロールが実現できるため、このような課題に対処できます。
**IDP としての Backstage**
社内デベロッパープラットフォーム (IDP) は、デベロッパーがアプリケーションを構築、デプロイ、管理する方法を簡素化および標準化するために、プラットフォームチームによって構築されたセルフサービスレイヤーです。インフラストラクチャの複雑さを抽象化し、デベロッパーは、統合されたインターフェイスを通じてツール、環境、サービスに簡単にアクセスできるようになります。
IDP の主な目標は、デベロッパーのエクスペリエンスと生産性を向上させることです。
+ サービスの作成やデプロイなどのタスクでセルフサービスを有効にする。
+ 標準のテンプレートを使用して一貫性とコンプライアンスを促す。
+ 開発ライフサイクル全体でツールを統合する (CI/CD、モニタリング、ドキュメント)。
Backstage は、Spotify によって作成されたオープンソースのデベロッパーポータルであり、現在は Cloud Native Computing Foundation (CNCF) の一部となっています。ソフトウェアコンポーネント、ツール、ドキュメントを管理するための一元化された拡張可能なプラットフォームを提供し、組織が独自の IDP を構築するのを支援します。Backstage を使用すると、デベロッパーは次のことが行うことができます。
+ ソフトウェアカタログを通じてすべての内部サービスを検出および管理する。
+ スキャフォールダープラグインを使って、事前定義されたテンプレートを使用して新しいプロジェクトを作成する。
+ CI/CD パイプライン、Kubernetes ダッシュボード、モニタリングシステムなどの統合ツールに一元的にアクセスできる。
+ TechDocs を通じて一貫性のあるマークダウンベースのドキュメントを維持できる。
**よくある質問**
**Backstage テンプレートを使用する場合と、SageMaker コンソールから SageMaker Studio を手動でデプロイする場合の違いは何ですか?**
Backstage テンプレートには、組織のベストプラクティスに従った標準化された設定、Seed-Farmer と を使用した IaC の自動デプロイ AWS CDK、組み込みのセキュリティポリシーとコンプライアンス対策、GitHub を介した組織の開発者ワークフローとの統合など、手動 AWS コンソールデプロイよりもいくつかの利点があります。このテンプレートは、バージョン管理による再現可能なデプロイも作成します。これにより、さまざまなステージ (開発、ステージング、本番稼働) にまたがる環境を簡単に複製できるため、チーム間の一貫性が確保されます。さらに、テンプレートには自動クリーンアップ機能が含まれており、Backstage を通じて組織の ID 管理システムと統合されます。コンソールを介した手動デプロイには深い AWS 専門知識が必要であり、バージョン管理やテンプレートが提供するのと同じレベルの標準化とガバナンスは提供されません。このような理由から、コンソールのデプロイは、本番環境の ML 環境よりも 1 回限りの実験に適しています。
**Seed-Farmer とは何ですか? このソリューションがそれを使用しているのはなぜですか?**
Seed-Farmer は、 を使用してインフラストラクチャモジュールを管理する AWS デプロイオーケストレーションツールです AWS CDK。このパターンでは、Seed-Farmer を使用します。これは、AI/ML ワークロード用に特別に設計された標準化された再利用可能なインフラストラクチャコンポーネントを提供し、 間の複雑な依存関係 AWS のサービス を自動的に処理し、異なる環境間で一貫したデプロイを保証するためです。
**これらのテンプレートを使用するには AWS CLI 、 をインストールする必要がありますか?**
いいえ。コンピュータ AWS CLI に をインストールする必要はありません。テンプレートはクラウド内の GitHub Actions を通じて全体的に実行されます。Backstage インターフェイスを介して AWS 認証情報 (アクセスキー、シークレットキー、セッショントークン) を指定すると、デプロイは GitHub Actions 環境で自動的に行われます。
**SageMaker Studio 環境のデプロイにはどのくらいの時間がかかりますか?**
SageMaker Studio のデプロイが完了するまでに通常 15～25 分かかります。これには、 AWS CDK ブートストラップ (2～3 分）、Seed-Farmer ツールチェーンのセットアップ (3～5 分）、リソースの作成 (10～15 分) が含まれます。正確な時間は、 AWS リージョン とネットワーク設定の複雑さによって異なります。
**同じ AWS アカウントに複数の SageMaker 環境をデプロイすることは可能ですか?**
はい、可能です。各デプロイでは、テンプレートで指定したコンポーネント名に基づいて一意の名前のリソースが作成されます。ただし、 AWS のサービス クォータに注意してください。各アカウントでは、リージョンごとに SageMaker ドメインの数に制限があるため、複数の環境を作成する前に[クォータを確認してください](https://docs.aws.amazon.com/general/latest/gr/sagemaker.html#limits_sagemaker)。
# Amazon Bedrock を使用して AWS インフラストラクチャオペレーションを自動化する
*Amazon Web Services、Ishwar Chauthaiwale、Anand Bukkapatnam Tirumala*
## 概要
クラウドネイティブなソリューションでは、一般的なインフラストラクチャオペレーションの自動化は、効率性と費用対効果の高い安全な環境を維持する上で重要な役割を果たします。オペレーションの手動処理は時間を要し、人為的ミスが発生しやすくなります。さらに、さまざまなレベルの AWS 専門知識を持つチームメンバーは、セキュリティプロトコルへの準拠を確保しながら、これらのタスクを実行する必要があります。このパターンは、Amazon Bedrock を使用して自然言語処理 (NLP) を通じて一般的な AWS インフラストラクチャオペレーションを自動化する方法を示しています。
本パターンは、複数の環境に生成 AI ベースのインフラストラクチャをデプロイする、再利用可能なモジュール式の安全なコードを開発するのに役立ちます。Infrastructure as Code (IaC) と自動化に重点を置くことで、バージョン管理、一貫したデプロイ、エラーの削減、プロビジョニングの高速化、コラボレーションの改善など、DevOps の主な利点を活用できるようになります。
このパターンは、以下 AWS のサービス を含むキーに関連するオペレーションをチームが管理できるようにする安全なアーキテクチャを実装しています。
+ Amazon Simple Storage Service (Amazon S3) バケットのバージョニングを設定する
+ Amazon Relational Database Service (Amazon RDS) のスナップショット作成
+ Amazon Elastic Compute Cloud (Amazon EC2) のインスタンス管理
このアーキテクチャは、安全な通信のために Amazon Virtual Private Cloud (Amazon VPC) エンドポイントとプライベートネットワークを採用し、 AWS Lambda プライベートサブネット内のタスクエグゼキュターとして機能します。Amazon S3 はデータ管理を提供し、包括的な AWS Identity and Access Management (IAM) ロールとアクセス許可を実装して、適切なアクセスコントロールを確保します。このソリューションにはチャット履歴機能がないため、チャットは保存されません。
## 前提条件と制限事項
+ アクティブ AWS アカウント。
+ アクセスをセキュリティで保護および制御するには、適切なアクセスコントロール対策を講じる必要があります。アクセスコントロールの例としては AWS Systems Manager、 の使用、基盤モデルアクセス、デプロイ用の IAM ロール、サービスベースのロール、Amazon S3 バケットへのパブリックアクセスの無効化、デッドレターキューの設定などがあります。
+ AWS Key Management Service (AWS KMS) [カスタマーマネージドキー](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk)。
+ AWS Command Line Interface (AWS CLI) バージョン 2 以降、デプロイ環境に[インストール](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html)および[設定されています](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html)。
+ Terraform AWS Provider バージョン 4 以降[がインストールされ](https://registry.terraform.io/providers/-/aws/latest/docs/guides/version-4-upgrade)、設定されています。
+ Terraform バージョン 1.5.7 以降が[インストールされ、設定されている](https://developer.hashicorp.com/terraform/install)こと。
+ 不正アクセスからの保護とデータ整合性の維持のため、[Amazon Bedrock でエージェントのアクショングループの OpenAPI スキーマを確認して定義](https://docs.aws.amazon.com/bedrock/latest/userguide/agents-api-schema.html)します。
+ 必要な Amazon Titan Text Embeddings v2 と Claude 3.5 Sonnet または Claude 3 Haiku 基盤モデルのいずれか AWS アカウント に対して で[有効になっているアクセス](https://docs.aws.amazon.com/bedrock/latest/userguide/model-access-modify.html)。 [https://docs.aws.amazon.com/bedrock/latest/userguide/models-supported.html](https://docs.aws.amazon.com/bedrock/latest/userguide/models-supported.html)デプロイの失敗を回避するには、ターゲットデプロイ AWS リージョン [が必要なモデルをサポート](https://docs.aws.amazon.com/bedrock/latest/userguide/models-regions.html)していることを確認します。
+ [AWS Well Architected Framework](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec-design.html) のベストプラクティスに従って設定された仮想プライベートクラウド (VPC)。
+ [Amazon Responsible AI ポリシー](https://aws.amazon.com/ai/responsible-ai/policy/)のレビューが完了していること。
**製品バージョン**
+ Amazon Titan Text Embeddings V2
+ Anthropic Claude 3.5 Sonnet or Claude 3 Haiku
+ Terraform AWS プロバイダーバージョン 4 以降
+ Terraform バージョン 1.5.7 以降
## アーキテクチャ
次の図表は、このパターンのアプリケーションのワークフローとアーキテクチャコンポーネントを示しています。
![\[Amazon Bedrock を使用して一般的な AWS インフラストラクチャオペレーションを自動化するワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/924e503f-bfc5-4452-abdf-d72a58d4d36f/images/bd56ad29-b435-4543-8ee8-dc4e1d38df18.png)
ソリューションアーキテクチャは、自然言語リクエストを処理し、対応する AWS オペレーションを実行するために連携する複数のレイヤーで構成されています。
1. ユーザーは、Amazon Bedrock のチャットコンソールからオペレーションリクエストを行います。
1. チャットボットはリクエスト処理に Amazon Bedrock ナレッジベースを使用します。こちらは自然言語処理用の Amazon Titan Text Embeddings v2 モデルを実装しています。
1. ユーザープロンプトにアクションリクエストが含まれている場合、Amazon Bedrock アクショングループは、実行ロジックに Anthropic Claude 3 Haiku または Claude 3.5 Sonnet モデル (ユーザーの選択による) のいずれかを使用し、OpenAPI スキーマを介してオペレーションを定義します。
1. アクショングループは、安全なサービス通信 AWS PrivateLink のために を使用して Amazon VPC [エンドポイント](https://docs.aws.amazon.com/whitepapers/latest/aws-privatelink/what-are-vpc-endpoints.html)に到達します。
1. AWS Lambda 関数は、Amazon Bedrock サービスの Amazon VPC エンドポイントを介して到達します。
1. Lambda 関数は主要な実行エンジンです。Lambda 関数は、リクエストに基づいて API を呼び出し、 AWS のサービスに対してアクションを実行します。また、Lambda 関数はオペレーションのルーティングと実行も処理します。
1. Lambda 関数からの API リクエスト AWS のサービス の取得と、対応するオペレーションが実行されます。
1. Lambda 関数は、Amazon Bedrock によって理解される出力ペイロードを計算します。
1. このペイロードは、安全なサービス通信を行うため、PrivateLink を使用して Amazon Bedrock に送信されます。Amazon Bedrock で使用される大規模言語モデル (LLM) は、このペイロードを解釈し、人間が理解できる形式に変換します。
1. その後、出力は Amazon Bedrock チャットコンソール上でユーザーに対して表示されます。
このソリューションでは、次の主要なオペレーションを有効にします。
+ Amazon S3 – バージョン管理のためにバケットのバージョニングを有効にします。
+ Amazon RDS – バックアップ用のデータベーススナップショットを作成します。
+ Amazon EC2 – インスタンスを一覧表示し、インスタンスの開始と停止を制御します。
## ツール
**AWS のサービス**
+ [Amazon Bedrock](https://docs.aws.amazon.com/bedrock/latest/userguide/what-is-bedrock.html) は、主要な AI スタートアップや Amazon が提供する高パフォーマンスな基盤モデル (FM) を、統合 API を通じて利用できるようにするフルマネージド型サービスです。
+ [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) は、コマンドラインシェルのコマンド AWS のサービス を通じて を操作するのに役立つオープンソースツールです。
+ [Amazon Elastic Compute Cloud (Amazon EC2)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts.html) は、 AWS クラウドでスケーラブルなコンピューティング容量を提供します。仮想サーバーを必要な数だけ起動して、迅速にスケールアップまたはスケールダウンができます。
+ [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、誰を認証し、誰に使用を認可するかを制御することで、 AWS リソースへのアクセスを安全に管理するのに役立ちます。
+ [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。
+ [Amazon OpenSearch Serverless](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/serverless-overview.html) は、Amazon OpenSearch Service 用のオンデマンドサーバーレス設定です。
+ [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html) は、仮想プライベートクラウド (VPC) から他の VPC 内のサービスへの単方向のプライベート接続の確立に役立ちます。
+ [Amazon Relational Database Service (Amazon RDS)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html) を使用して、 AWS クラウドでリレーショナルデータベース (DB) をセットアップ、運用、スケーリングできます。
+ [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) は、あらゆる量のデータを保存、保護、取得できるクラウドベースのオブジェクトストレージサービスです。
+ 「[AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html)」は、 AWS クラウドで実行されるアプリケーションとインフラストラクチャの管理に役立ちます。これにより、アプリケーションとリソースの管理が簡素化され、運用上の問題を検出して解決する時間を短縮し、 AWS リソースを大規模に安全に管理できます。
+ [Amazon Virtual Private Cloud (Amazon VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) は、定義した仮想ネットワークに AWS リソースを起動するのに役立ちます。この仮想ネットワークは、ユーザー自身のデータセンターで運用されていた従来のネットワークと似ていますが、 AWSのスケーラブルなインフラストラクチャを使用できるという利点があります。
**その他のツール**
+ [Git](https://git-scm.com/docs) はオープンソースの分散バージョンの管理システムです。
+ 「[Terraform](https://www.terraform.io/)」は、HashiCorp の infrastructure as code (IaC) ツールで、クラウドとオンプレミスのリソースの作成と管理を支援します。
**コードリポジトリ**
このパターンのコードは、GitHub の [aws-samples/infra-ops-orchestrator](https://github.com/aws-samples/infra-ops-orchestrator) リポジトリから入手できます。
## ベストプラクティス
+ Lambda 実行ログを定期的にモニタリングします。詳細については、「[Lambda 関数をモニタリングおよびトラブルシューティングする](https://docs.aws.amazon.com/lambda/latest/dg/lambda-monitoring.html)」を参照してください。ベストプラクティスの詳細については、「 [AWS Lambda 関数を使用するためのベストプラクティス](https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html)」を参照してください。
+ セキュリティ設定を定期的に見直し、組織の要件に準拠していることを確認します。詳細については、「[セキュリティのベストプラクティス](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec-bp.html)」を参照してください。
+ 最小特権の原則に従い、タスクの実行に必要な最小限の権限を付与します。詳細については、IAM ドキュメントの「[最小限の特権を認める。](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#grant-least-priv)」と「[IAM でのセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)」を参照してください。
## エピック
### 解決策をデプロイする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| リポジトリのクローン作成 | ローカルマシンにリポジトリのクローンを作成するときは次のコマンドを実行します。git clone "git@github.com:aws-samples/infra-ops-orchestrator.git"
cd infra-ops-orchestrator
| AWS DevOps、DevOps エンジニア |
| 環境変数を編集します。 | クローンされたリポジトリのルートディレクトリで `terraform.tfvars` file. を編集します。`[XXXXX]` に示されたプレースホルダーを確認し、お使いの環境に応じて更新します。 | AWS DevOps、DevOps エンジニア |
| インフラストラクチャを作成する | インフラストラクチャを作成するには、次のコマンドを実行します。terraform init
terraform plan
実行計画を注意深く確認します。計画された変更が許容できる場合は、次のコマンドを実行します。terraform apply --auto-approve
| AWS DevOps、DevOps エンジニア |
### ソリューションにアクセスする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| ソリューションにアクセスする | デプロイが成功したら、以下のステップに従ってチャットベースのインターフェイスを使用します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-aws-infrastructure-operations-by-using-amazon-bedrock.html) | AWS DevOps、DevOps エンジニア |
### リソースをクリーンアップする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| 作成したリソースを削除します。 | このパターンによって作成されたすべてのインフラストラクチャを削除するには、次のコマンドを実行します。terraform plan -destroy
破棄計画を注意深く確認してください。計画された削除が許容される場合は、次のコマンドを実行します。terraform destroy
注: このコマンドによって、本パターンで作成したリソースは完全に削除されます。リソースを削除する前にコマンドから確認を求められます。 | AWS DevOps、DevOps エンジニア |
## トラブルシューティング
| 問題 | ソリューション |
| --- | --- |
| エージェントの動作 | この問題の詳細については、Amazon Bedrock ドキュメントの「[Test and troubleshoot agent behavior](https://docs.aws.amazon.com/lambda/latest/dg/troubleshooting-networking.html)」を参照してください。 |
| Lambda ネットワークの問題 | これらの問題の詳細については、「Lambda ドキュメント」の「[Lambda でのネットワーク問題のトラブルシューティング](https://docs.aws.amazon.com/lambda/latest/dg/troubleshooting-networking.html)」を参照してください。 |
| IAM アクセス許可 | これらの問題の詳細については、IAM ドキュメントの「[IAM のトラブルシューティング](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot.html)」を参照してください。 |
## 関連リソース
+ [Amazon RDS のシングル AZ DB インスタンスの DB スナップショットの作成](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateSnapshot.html)
+ [Define OpenAPI schemas for your agent's action groups in Amazon Bedrock](https://docs.aws.amazon.com/bedrock/latest/userguide/agents-api-schema.html)
+ [バケットでのバージョニングの有効化](https://docs.aws.amazon.com/AmazonS3/latest/userguide/manage-versioning-examples.html)
+ [Amazon Bedrock エージェントの仕組み](https://docs.aws.amazon.com/bedrock/latest/userguide/agents-how.html)
+ [Retrieve data and generate AI responses with Amazon Bedrock Knowledge Bases](https://docs.aws.amazon.com/whitepapers/latest/aws-privatelink/aws-privatelink.html)
+ [経由でサービスに安全にアクセスする AWS PrivateLink](https://docs.aws.amazon.com/whitepapers/latest/aws-privatelink/aws-privatelink.html)
+ [Amazon EC2 インスタンスの停止と起動](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Stop_Start.html)
+ [アクショングループを使用して、エージェントが実行するアクションを定義する](https://docs.aws.amazon.com/bedrock/latest/userguide/agents-action-create.html)
# 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 以降
## アーキテクチャ
次の図表は、このパターンのアプリケーションのワークフローとアーキテクチャコンポーネントを示しています。
![\[EventBridge ルールで検出された新しい ALB DNS アドレスで CloudFront を更新するワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/03c30b18-4dd7-4dd4-b960-5a5cc58cec63/images/28854767-0902-4398-80af-b19141dd94e4.png)
以下の手順で実行します。
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)
## 追加情報
**問題のあるワークフロー**
![\[CloudFront で古い ALB DNS エントリを生成するワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/03c30b18-4dd7-4dd4-b960-5a5cc58cec63/images/bb3c2c93-c749-435d-9b1d-2bbf6f0cf085.png)
この図表は、次のワークフローを示しています:
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 関数ソリューションは、現在のフローを中断しません。
# GitHub Actions を使用して Python AWS CDK アプリケーションの Amazon CodeGuru レビューを自動化する
*Amazon Web Services、Vanitha Dontireddy、Sarat Chandra Pothula*
## 概要
注: 2025 年 11 月 7 日現在、Amazon CodeGuru Reviewer で新しいリポジトリの関連付けを作成することはできません。CodeGuru Reviewer と同様の機能を持つサービスの詳細については、[CodeGuru Reviewer ドキュメントの「Amazon CodeGuru Reviewer の可用性の変更](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/codeguru-reviewer-availability-change.html)」を参照してください。 CodeGuru
このパターンは、GitHub Actions を通じてオーケストレーションされた Python AWS Cloud Development Kit (AWS CDK) アプリケーションの Amazon CodeGuru 自動コードレビューの統合を示しています。このソリューションは、Python で定義されたサーバーレスアーキテクチャ AWS CDK をデプロイします。開発パイプライン内のエキスパートコード分析を自動化することで、このアプローチは Python AWS CDK プロジェクトに対して次のことを実行できます。
+ コードの品質を向上させる
+ ワークフローを効率化する
+ サーバーレスコンピューティングの利点を最大化する
## 前提条件と制限
**前提条件**
+ アクティブ AWS アカウント。
+ AWS Command Line Interface (AWS CLI) バージョン 2.9.11 以降、[インストール](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html)および[設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html)済み。
+ 有効な GitHub アカウントと、ワークフローの読み取りおよび書き込み権限ならびに PR ワークフローが正常に動作することを確保するための GitHub アクションによるプルリクエスト (PR) の作成機能を備えた GitHub リポジトリ。
+ AWS アカウントにソリューションをデプロイするための GitHub アクションの OpenID Connect (OIDC) ロール。ロールを作成するには [AWS CDK コンストラクト](https://github.com/aws-samples/github-actions-oidc-cdk-construct)を使用します。
**制限事項**
+ Amazon CodeGuru Profiler は、すべての Java 仮想マシン (JVM) 言語 (Scala や Kotlin など) およびランタイム、ならびに Python 3.6 以降で記述された[アプリケーションをサポート](https://docs.aws.amazon.com/codeguru/latest/profiler-ug/what-is-codeguru-profiler.html#what-is-language-support)しています。
+ Amazon CodeGuru Reviewer は、、Bitbucket AWS CodeCommit、GitHub、GitHub Enterprise Cloud、GitHub Enterprise Server のソースプロバイダーからのみ、Java および Python コードリポジトリとの[関連付けをサポートします](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/working-with-repositories.html)。また、Amazon Simple Storage Service (Amazon S3) リポジトリは、GitHub アクションを通じてのみサポートされています。
+ 継続的インテグレーションと継続的デプロイ (CI/CD) のパイプライン中に結果を自動的に出力する方法はありません。このパターンでは、代替の方法として GitHub アクションを使用し検出結果を処理および表示します。
+ 一部の 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)」を参照し、サービスのリンクを選択してください。
## アーキテクチャ
このソリューション用のアーキテクチャを次の図に示します。
![\[GitHub アクションを使用して AWS CDK Python アプリケーションの CodeGuru コードレビューを統合するためのワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/c5395e3e-ff2a-41cf-bd64-c73cc928b60b/images/18f880a2-9bc3-4d71-a598-bb83b68ee383.png)
図に示すように、開発者がレビュー用のプルリクエスト (PR) を作成すると、GitHub アクションが次のステップをトリガーします。
1. IAM ロールの引き受け – パイプラインは、GitHub Secrets で指定された IAM ロールを使用してデプロイタスクを実行します。
1. コード分析
+ CodeGuru Reviewer は、Amazon S3 バケットに保存されているコードを分析します。不具合を特定し、修正と最適化に関する推奨事項を提供します。
+ CodeGuru Security は、ポリシー違反と脆弱性をスキャンします。
1. 検出結果の確認
+ パイプラインが、コンソールの出力に検出結果ダッシュボードへのリンクを出力します。
+ 重要度が重大である場合、パイプラインは直ちに失敗します。
+ 重要度が高、普通、低である場合、パイプラインは次のステップに進みます。
1. PR の承認
+ レビュー担当者は、PR を手動で承認する必要があります。
+ PR が拒否されると、パイプラインは失敗し、それ以降のデプロイステップが停止します。
1. CDK デプロイ – PR の承認後、CDK デプロイプロセスが開始します。以下の AWS のサービス および リソースを設定します。
+ CodeGuru Profiler
+ AWS Lambda 関数
+ Amazon Simple Queue Service (Amazon SQS) キュー
1. データ生成のプロファイリング – CodeGuru Profiler 用に十分なプロファイリングデータを生成するには:
+ パイプラインは、Amazon SQS キューに定期的にメッセージを送信することで、Lambda 関数を複数回呼び出します。
## ツール
**AWS のサービス**
+ [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/latest/guide/home.html) は、コードで AWS クラウド インフラストラクチャを定義およびプロビジョニングするのに役立つソフトウェア開発フレームワークです。
+ [CDK Toolkit](https://docs.aws.amazon.com/cdk/latest/guide/cli.html) は、 AWS CDK アプリの操作に役立つコマンドラインクラウド開発キットです。
+ [Amazon CodeGuru Profiler](https://docs.aws.amazon.com/codeguru/latest/profiler-ug/what-is-codeguru-profiler.html) は、ライブアプリケーションからランタイムパフォーマンスデータを収集し、アプリケーションのパフォーマンスを微調整する上で役立つ推奨事項を提供します。
+ [Amazon CodeGuru Reviewer](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html) は、プログラム解析と機械学習により、開発者が検出するのが難しい潜在的な不具合を検出します。次に、CodeGuru Profiler は Java および Python コードを改善するための提案を提供します。
+ Amazon CodeGuru Security は、機械学習を使用してセキュリティポリシー違反と脆弱性を検出する静的アプリケーションセキュリティツールです。セキュリティリスクに対処するための提案を行い、アプリケーションのセキュリティ態勢を追跡できるようにメトリクスを生成します。
+ [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、誰を認証し、誰に使用する権限を付与するかを制御することで、 AWS リソースへのアクセスを安全に管理するのに役立ちます。
+ [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。
+ 「[Amazon Simple Queue Service (Amazon SQS](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)) 」は、安全で耐久性があり、配信ソフトウェアシステムとコンポーネントを統合および分離できる利用可能なホスト型キューを提供します。
+ 「[Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) 」は、どのようなデータの量であっても、保存、保護、取得することを支援するクラウドベースのオブジェクトストレージサービスです。
**その他のツール**
+ [GitHub アクション](https://docs.github.com/en/actions/writing-workflows/quickstart)は、GitHub リポジトリと緊密に統合された継続的インテグレーションおよび継続的デリバリー (CI/CD) プラットフォームです。GitHub アクションを使用することで、生成、テスト、デプロイのパイプラインを自動化できます。
**コードリポジトリ**
本パターン用のコードは、GitHub の [amazon-codeguru-suite-cdk-python](https://github.com/aws-samples/amazon-codeguru-suite-cdk-python) リポジトリから入手できます。
## ベストプラクティス
+ 「[Best practices for developing and deploying cloud infrastructure with the AWS CDK](https://docs.aws.amazon.com/cdk/v2/guide/best-practices.html)」に従います。
+ GitHub Actions ワークフロー AWS のサービス で を使用する場合は、[IAM のセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)に従います。
+ リポジトリコードに認証情報を保存しない。
+ 一時的な認証情報を受け取るときは [IAM ロールを引き受け](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-workloads-use-roles)、可能な限り一時的な認証情報を使用する。
+ GitHub アクションのワークフローで使用される IAM ロールに[最小特権を付与する](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)。アクセス権限は、GitHub アクションのワークフローでアクションを実行するために必要なもののみを付与する。
+ GitHub アクションのワークフローで使用される IAM ロールの[アクティビティをモニタリングする](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#remove-credentials)。
+ 有効期間の長い認証情報を使用するときは定期的にローテーションする。
## エピック
### 環境をセットアップします。
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| AWS 認証情報を設定します。 | スタックをデプロイする AWS アカウント と AWS リージョン を定義する変数をエクスポートするには、次のコマンドを実行します。export CDK_DEFAULT_ACCOUNT=<12-digit AWS account number>
export CDK_DEFAULT_REGION=
の AWS 認証情報 AWS CDK は、環境変数を通じて提供されます。 | AWS DevOps、DevOps エンジニア |
| リポジトリのクローン作成 | ローカルマシンにリポジトリのクローンを作成するときは次のコマンドを実行します。git clone https://github.com/aws-samples/amazon-codeguru-suite-cdk-python.git
| AWS DevOps、DevOps エンジニア |
| CDK Toolkit をインストールします。 | CDK Toolkit がインストールされていることを確認し、バージョンをチェックするには、次のコマンドを実行します。 cdk --version
CDK Toolkit のバージョンが 2.27.0 より前の場合は、次のコマンドを入力してバージョン 2.27.0 に更新します。npm install -g aws-cdk@2.27.0
CDK Toolkit が*インストールされていない*場合は、次のコマンドを実行してインストールします。npm install -g aws-cdk@2.27.0 --force
| AWS DevOps、DevOps エンジニア |
| 必要な依存ファイルをインストールします。 | 必要なプロジェクトの従属関係をインストールには、次のコマンドを実行します。python -m pip install --upgrade pip
pip install -r requirements.txt
| AWS DevOps、DevOps エンジニア |
| CDK 環境をブートストラップします。 | AWS CDK 環境を[ブートストラップ](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html)するには、以下のコマンドを実行します。npm install
npm run cdk bootstrap "aws://${ACCOUNT_NUMBER}/${AWS_REGION}"
環境を正常に起動すると、次の出力が表示されるはずです。⏳ Bootstrapping environment aws://{account}/{region}...
✅ Environment aws://{account}/{region} bootstrapped | AWS DevOps、DevOps エンジニア |
### CDK アプリをデプロイする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| AWS CDK アプリケーションを合成します。 | AWS CDK アプリケーションを合成するには、次のコマンドを実行します。cdk synth
このコマンドの詳細については、 AWS CDK ドキュメントの[「cdk 合成](https://docs.aws.amazon.com/cdk/v2/guide/ref-cli-cmd-synth.html)」を参照してください。 | AWS DevOps、DevOps エンジニア |
| リソースのデプロイ | コマンドをデプロイするには次のコマンドをデプロイします。cdk deploy --require-approval never
`--require-approval never` フラグは、CDK がすべての変更を自動的に承認して実行することを意味します。これには、CDK が通常手動レビューを必要とするものとしてフラグを付ける変更 (IAM ポリシーの変更やリソースの削除など) が含まれます。本番環境で `--require-approval never` フラグを使用するときは、事前に CDK コードと CI/CD パイプラインが十分にテストされ安全であることを確認してください。 | AWS DevOps、DevOps エンジニア |
### GitHub シークレットと個人用アクセストークンを作成します。
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| GitHub で必要なシークレットを作成します。 | GitHub Actions ワークフローがリポジトリのコードに機密情報を公開することなく AWS リソースに安全にアクセスできるようにするには、シークレットを作成します。GitHub for `ROLE_TO_ASSUME`、`CodeGuruReviewArtifactBucketName`、`AWS_ACCOUNT_ID` でシークレットを作成するには、GitHub アクションのドキュメントにある「[Creating secrets for a repository](https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions#creating-secrets-for-a-repository)」の手順に従います。以下は、これらの変数の詳細です。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-amazon-codeguru-reviews-for-aws-cdk-python-applications.html) | AWS DevOps、DevOps エンジニア |
| パーソナルアクセストークンを作成する | GitHub アクションのワークフローが GitHub を認証して操作するための安全な方法を設定するには、以下を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-amazon-codeguru-reviews-for-aws-cdk-python-applications.html) | AWS DevOps、DevOps エンジニア |
### クリーンアップ
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| リソースをクリーンアップします。 | Python AWS CDK アプリケーションをクリーンアップするには、次のコマンドを実行します。cdk destroy --all
| DevOps エンジニア |
## トラブルシューティング
| 問題 | ソリューション |
| --- | --- |
| ダッシュボードの検出結果へのリンクを表示します。 | CI/CD パイプライン中に結果を出力することはできません。このパターンでは、代替の方法として GitHub アクションを使用し検出結果を処理および表示します。 |
## 関連リソース
**AWS リソース**
+ [AWS クラウド開発キット](https://aws.amazon.com/cdk/)
+ [Amazon CodeGuru ドキュメント](https://docs.aws.amazon.com/codeguru/)
+ [Amazon S3](https://aws.amazon.com/s3/)
+ [AWS Identity and Access Management](https://aws.amazon.com/iam/)
+ [Amazon Simple Queue Service](https://aws.amazon.com/sqs/)
+ [とは AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
**GitHub ドキュメント**
+ [Configuring OpenID Connect in Amazon Web Services](https://docs.github.com/en/actions/security-for-github-actions/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services)
+ [GitHub Actions](https://github.com/features/actions)
+ [ワークフローの再利用](https://docs.github.com/en/actions/using-workflows/reusing-workflows)
+ [ワークフローのトリガー](https://docs.github.com/en/actions/using-workflows/triggering-a-workflow)
# GitHub Actions、Artifactory、Terraform を使用して、マルチリポジトリ設定で AWS Supply Chain データレイクのデプロイを自動化する
*Keshav Ganesh、Amazon Web Services*
## 概要
このパターンは、マルチリポジトリの継続的インテグレーションと継続的デプロイ (CI/CD) パイプラインを使用して AWS Supply Chain データレイクをデプロイおよび管理するための自動化されたアプローチを提供します。これは、GitHub Actions ワークフローを使用した自動デプロイと、Terraform を使用した手動デプロイの 2 つのデプロイ方法を示しています。どちらのアプローチもInfrastructure as Code (IaC) に Terraform を使用し、自動化された方法で GitHub Actions と JFrog Artifactory を追加して CI/CD 機能を強化します。
このソリューションは AWS Supply Chain、 AWS Lambdaと Amazon Simple Storage Service (Amazon S3) を活用してデータレイクインフラストラクチャを確立し、いずれかのデプロイ方法を使用して設定とリソースの作成を自動化します。この自動化により、手動の設定手順がなくなり、環境間で一貫したデプロイが保証されます。さらに、 は抽出、変換、ロード (ETL) に関する深い専門知識の必要性 AWS Supply Chain を排除し、Amazon Quick Sight を活用したインサイトと分析を提供できます。
このパターンを実装することで、組織はバージョン管理された自動化されたプロセスを通じて、デプロイ時間を短縮し、Infrastructure as Code を維持し、サプライチェーンのデータレイクを管理できます。マルチリポジトリアプローチは、きめ細かなアクセスコントロールを提供し、さまざまなコンポーネントの独立したデプロイをサポートします。チームは、既存のツールやプロセスに最適なデプロイ方法を選択できます。
## 前提条件と制限
**前提条件**
ローカルマシンに以下がインストールされていることを確認します。
+ [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) バージョン 2
+ [GitHub CLI](https://docs.github.com/en/get-started/git-basics/set-up-git)
+ [Python](https://www.python.org/downloads/) v3.13
+ [Terraform](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli) v1.12 以降
デプロイする前に、以下が設定されていることを確認します。
+ アクティブ AWS アカウント。
+ AWS アカウント AWS リージョン 選択した の に 2 [つのプライベートサブネット](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-example-private-subnets-nat.html)を持つ [Virtual Private Cloud (VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/create-vpc.html)。
+ 次のサービスへのデプロイに使用される AWS Identity and Access Management (IAM) ロールの十分なアクセス許可。
+ AWS Supply Chain – データセットや統合フローなどのコンポーネントをデプロイし、 からアクセスする場合は、フルアクセスが推奨されます AWS マネジメントコンソール。
+ Amazon CloudWatch Logs – CloudWatch ロググループの作成と管理用。
+ Amazon Elastic Compute Cloud (Amazon EC2) – Amazon EC2 セキュリティグループと Amazon Virtual Private Cloud (Amazon VPC) エンドポイント用。
+ Amazon EventBridge – が使用します AWS Supply Chain。
+ IAM – AWS Lambda サービスロールの作成用。
+ AWS Key Management Service (AWS KMS) – Amazon S3 アーティファクトバケットと Amazon S3 AWS Supply Chain ステージングバケット AWS KMS keys に使用される へのアクセス用。
+ AWS Lambda – AWS Supply Chain コンポーネントをデプロイする Lambda 関数を作成する場合。
+ Amazon S3 – Amazon S3 アーティファクトバケット、サーバーアクセスログバケット、 AWS Supply Chain ステージングバケットへのアクセス用。手動デプロイを使用している場合は、Amazon S3 Terraform アーティファクトバケットのアクセス許可も必要です。
+ Amazon VPC – VPC の作成と管理用。
デプロイに GitHub Actions ワークフローを使用する場合は、以下を実行します。
+ 前述のアクセス許可を使用して、IAM ロールの [OpenID Connect (OIDC)](https://docs.github.com/en/actions/how-tos/secure-your-work/security-harden-deployments/oidc-in-aws#configuring-the-role-and-trust-policy) を設定します。
+ にアクセスするための同様のアクセス許可を持つ IAM ロールを作成します AWS マネジメントコンソール。詳細については、IAM [ドキュメントの「IAM ユーザーにアクセス許可を付与するロールを作成する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html)」を参照してください。
手動デプロイを行う場合は、以下を実行します。
+ 前述のアクセス許可を持つ IAM ロールを引き受ける IAM ユーザーを作成します。詳細については、IAM [ドキュメントの「IAM ユーザーにアクセス許可を付与するロールを作成する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html)」を参照してください。
+ ローカルターミナルで [ロールを引き受け](https://docs.aws.amazon.com/cli/v1/userguide/cli-configure-role.html)ます。
デプロイに GitHub Actions ワークフローを使用する場合は、以下を設定します。
+ ホスト名、ログインユーザー名、ログインアクセストークンを取得する [JFrog Artifactory アカウント](https://jfrog.com/artifactory/?utm_source=google&utm_medium=cpc_search&utm_campaign=SearchDSKBrandAPACIN202506&utm_term=jfrog%20cloud&gads_network=g&utm_content=u-bin&gads_campaign_id=22674833884&gads_adgroup_id=184501797241&gads_extension_id=233003714635&gads_target_id=aud-312135645780:kwd-1598615735032&gads_matchtype=b&gad_source=1&gad_campaignid=22674833884&gbraid=0AAAAADqV85U5B37iapTR9IIFHBvydF5AQ&gclid=CjwKCAjwiY_GBhBEEiwAFaghvqdNV-odNLZXPHjT7NAwf8lA-QuMtg666hgvDW1oCJ4nn7wvf869_xoCW4IQAvD_BwE)。
+ アーティファクトを保存するための [JFrog プロジェクトキーとリポジトリ](https://jfrog.com/help/r/jfrog-platform-administration-documentation/step-1-set-up-a-new-project)。
**制限事項**
+ AWS Supply Chain インスタンスは、複雑なデータ変換手法をサポートしていません。
+ AWS Supply Chain は、組み込みの分析とインサイトを提供するため、サプライチェーンドメインに最適です。他のドメインの場合、 AWS Supply Chain はデータレイクアーキテクチャの一部としてデータストアとして使用できます。
+ このソリューションで使用される Lambda 関数は、本番環境のデプロイで API の再試行とメモリ管理を処理するために拡張する必要がある場合があります。
+ 一部の 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)」を参照して、サービスのリンクを選択してください。
## アーキテクチャ
このソリューションは、自動化された GitHub Actions ワークフローを使用するか、Terraform を使用して手動でデプロイできます。
**GitHub Actions を使用した自動デプロイ**
次の図は、GitHub Actions ワークフローを使用する自動デプロイオプションを示しています。JFrog Artifactory はアーティファクトの管理に使用されます。マルチリポジトリデプロイで使用するリソース情報と出力を保存します。
![\[GitHub Actions ワークフローと JFrog を使用する自動デプロイオプション。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/2f0b78b0-a174-4703-b533-d66b3fb005e0/images/d454a5c5-ed51-421c-a87f-ff74cfcb30be.png)
**Terraform を使用した手動デプロイ**
次の図は、Terraform による手動デプロイオプションを示しています。JFrog Artifactory の代わりに、Amazon S3 がアーティファクト管理に使用されます。
![\[Terraform と Amazon S3 を使用した手動デプロイオプション。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/2f0b78b0-a174-4703-b533-d66b3fb005e0/images/1130e728-44d5-4ae7-9586-1e497f54352a.png)
**デプロイのワークフロー**
図は次のワークフローを示しています。
1. 次のいずれかのデプロイ方法を使用して、 AWS Supply Chain サービスデータセットのインフラストラクチャとデータベースをデプロイします。
+ **自動デプロイ** – GitHub Actions ワークフローを使用してすべてのデプロイステップを調整し、JFrog Artifactory を使用してアーティファクトを管理します。
+ **手動デプロイ** – デプロイステップごとに Terraform コマンドを直接実行し、Amazon S3 を使用してアーティファクトを管理します。
1. AWS Supply Chain サービスオペレーションに必要なサポート AWS リソースを作成します。
+ Amazon VPC エンドポイントとセキュリティグループ
+ AWS KMS keys
+ CloudWatch Logs ロググループ
1. 次のインフラストラクチャリソースを作成してデプロイします。
+ AWS Supply Chain サービスインスタンス、名前空間、データセットを管理 (作成、更新、削除する) する Lambda 関数。
+ AWS Supply Chain データインジェスト用の Amazon S3 バケットのステージング
1. ステージングバケットと AWS Supply Chain データセット間の統合フローを管理する Lambda 関数をデプロイします。デプロイが完了すると、残りのワークフローステップでデータの取り込みと分析を管理します。
1. AWS Supply Chain ステージング Amazon S3 バケットへのソースデータの取り込みを設定します。
1. AWS Supply Chain ステージング Amazon S3 バケットにデータが追加されると、サービスは自動的に AWS Supply Chain データセットへの統合フローをトリガーします。
1. AWS Supply Chain は Quick Sight Analytics と統合して、取り込まれたデータに基づいてダッシュボードを生成します。
## ツール
**AWS のサービス**
+ [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) を使用すると、すべてのシステム、アプリケーション、および からのログを一元化 AWS のサービス できるため、ログをモニタリングして安全にアーカイブできます。
+ [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) は、コマンドラインシェルのコマンド AWS のサービス を通じて を操作するのに役立つオープンソースツールです。
+ [Amazon Elastic Compute Cloud (Amazon EC2)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts.html) は、 AWS クラウドでスケーラブルなコンピューティング容量を提供します。仮想サーバーを必要な数だけ起動して、迅速にスケールアップまたはスケールダウンができます。
+ [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) は、アプリケーションをさまざまなソースのリアルタイムデータに接続できるようにするサーバーレスイベントバスサービスです。例えば、 AWS Lambda 関数、API 送信先を使用する HTTP 呼び出しエンドポイント、その他のイベントバスなどです AWS アカウント。
+ [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、誰を認証し、誰に使用を承認するかを制御することで、 AWS リソースへのアクセスを安全に管理できます。
+ [AWS IAM アイデンティティセンター](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) を使用すると、すべての AWS アカウント およびクラウドアプリケーションへのシングルサインオン (SSO) アクセスを一元管理できます。
+ [AWS Key Management Service (AWS KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) は、データの保護に役立つ暗号化キーの作成と制御に役立ちます。
+ [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。
+ [Amazon Q](https://docs.aws.amazon.com/aws-supply-chain/latest/userguide/qinasc.html) in AWS Supply Chain は、 AWS Supply Chain データレイク内のデータを分析することでサプライチェーンをより効率的に運用するのに役立つインタラクティブな生成 AI アシスタントです。
+ [Amazon QuickSight](https://docs.aws.amazon.com/quicksight/latest/user/welcome.html) は、視覚化、分析、レポート生成に使用できるクラウドスケールのビジネスインテリジェンス (BI) サービスです。
+ [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) は、あらゆる量のデータを保存、保護、取得できるクラウドベースのオブジェクトストレージサービスです。
+ [AWS Supply Chain](https://docs.aws.amazon.com/aws-supply-chain/latest/adminguide/getting-started.html) は、サプライチェーンドメインのデータストアとして組織で使用できるクラウドベースのマネージドアプリケーションです。これは、インサイトを生成し、取り込まれたデータに対して分析を実行するために使用できます。
+ [Amazon Virtual Private Cloud (Amazon VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) は、定義した仮想ネットワークに AWS リソースを起動するのに役立ちます。この仮想ネットワークは、ユーザー自身のデータセンターで運用されていた従来のネットワークと似ていますが、 AWSのスケーラブルなインフラストラクチャを使用できるという利点があります。[Amazon VPC エンドポイント](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html)は、インターネットゲートウェイ、NAT デバイス、VPN 接続、または AWS Direct Connect 接続を必要と AWS のサービス せずに、サポートされている に VPC をプライベートに接続するのに役立つ仮想デバイスです。
**その他のツール**
+ [GitHub アクション](https://docs.github.com/en/actions)は、GitHub リポジトリと緊密に統合された継続的インテグレーションおよび継続的デリバリー (CI/CD) プラットフォームです。GitHub Actions を使用して、生成、テスト、デプロイのパイプラインを自動化できます。
+ [HashiCorp Terraform](https://www.terraform.io/) は、Infrastructure as Code (IaC) ツールで、クラウドとオンプレミスのリソースの作成と管理を支援します。
+ [JFrog Artifactory](https://jfrog.com/help/r/jfrog-artifactory-documentation/jfrog-artifactory) は、アプリケーション配信プロセスを通じてバイナリとアーティファクトのend-to-endの自動化と管理を提供します。
+ 「[Python](https://www.python.org/)」は汎用のコンピュータプログラミング言語です。このパターンでは、 AWS 関数のコードが とやり取りするために Python を使用します。 AWS Supply Chain
.
## ベストプラクティス
+ このパターンを実装する場合、可能な限り高レベルのセキュリティを維持します。[「前提条件](#automate-the-deployment-of-aws-supply-chain-data-lakes-prereqs)」で説明されているように、2 つのプライベートサブネットを持つ [Virtual Private Cloud (VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/create-vpc.html) が、 AWS リージョン 選択した AWS アカウント の にあることを確認します。 [https://docs.aws.amazon.com/vpc/latest/userguide/vpc-example-private-subnets-nat.html](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-example-private-subnets-nat.html)
+ 可能な限り AWS KMS [カスタマーマネージドキー](https://docs.aws.amazon.com/kms/latest/cryptographic-details/basic-concepts.html)を使用し、制限付きアクセス許可を付与します。
+ このパターンのデータを取り込むために必要な最小限のアクセスを持つ IAM ロールを設定するには、このパターンのリポジトリの[「ソースシステムから Amazon S3 への安全なデータ取り込み](https://github.com/aws-samples/sample-automate-aws-supply-chain-deployment/tree/main?tab=readme-ov-file#secure-data-ingestion-from-source-systems-to-amazon-s3)」を参照してください。
## エピック
### (両方のオプション) ローカルワークステーションをセットアップする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| リポジトリのクローン作成 | このパターンのリポジトリのクローンを作成するには、ローカルワークステーションで次のコマンドを実行します。git clone https://github.com/aws-samples/sample-automate-aws-supply-chain-deployment.git
cd ASC-Deployment
| AWS DevOps |
| (自動オプション) デプロイの前提条件を確認します。 | 自動デプロイの[前提条件](#automate-the-deployment-of-aws-supply-chain-data-lakes-prereqs)が完了していることを確認します。 | アプリ所有者 |
| (手動オプション) AWS Supply Chain データセットのデプロイを準備します。 | の `terraform-deployment` ディレクトリに移動するには`ASC-Datasets`、次のコマンドを実行します。cd ASC-Datasets/terraform-deployment
[前提条件](#automate-the-deployment-of-aws-supply-chain-data-lakes-prereqs)で作成されたロール ARN を引き受けるには、次のコマンドを実行します。aws sts assume-role --role-arn --role-session-name
環境変数を設定してエクスポートするには、次のコマンドを実行します。# Export Environment variables
export REGION=
export REPO_NAME=
export PROJECT_NAME="asc-deployment-poc"
export ACCOUNT_ID=
export ENVIRONMENT="dev"
export LAMBDA_LAYER_TEMP_DIR_TERRAFORM="layerOutput"
export LAMBDA_FUNCTION_TEMP_DIR_TERRAFORM="lambdaOutput"
export AWS_USER_ROLE=
export S3_TERRAFORM_ARTIFACTS_BUCKET_NAME="$PROJECT_NAME-$ACCOUNT_ID-$REGION-terraform-artifacts-$ENVIRONMENT"
| AWS DevOps |
| (手動オプション) デプロイで AWS Supply Chain 統合フローを管理する準備をします。 | の `terraform-deployment` ディレクトリに移動するには`ASC-Integration-Flows`、次のコマンドを実行します。cd ASC-Integration-Flows/terraform-deployment
以前に作成したロール ARN を引き受けるには、次のコマンドを実行します。aws sts assume-role --role-arn --role-session-name
環境変数を設定してエクスポートするには、次のコマンドを実行します。# Export Environment variables
export REGION=
export REPO_NAME=
export ASC_DATASET_VARS_REPO= #Must be the same directory name used for ASC Datasets deployment
export PROJECT_NAME="asc-deployment-poc"
export ACCOUNT_ID=
export ENVIRONMENT="dev"
export LAMBDA_LAYER_TEMP_DIR_TERRAFORM="layerOutput"
export LAMBDA_FUNCTION_TEMP_DIR_TERRAFORM="lambdaOutput"
export S3_TERRAFORM_ARTIFACTS_BUCKET_NAME="$PROJECT_NAME-$ACCOUNT_ID-$REGION-terraform-artifacts-$ENVIRONMENT"
| アプリ所有者 |
### (自動オプション) GitHub Actions ワークフローを使用して AWS Supply Chain データセットをデプロイする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| `ASC-Datasets` ディレクトリをコピーします。 | `ASC-Datasets` ディレクトリを新しい場所にコピーするには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-the-deployment-of-aws-supply-chain-data-lakes.html) | AWS DevOps |
| `ASC-Datasets` ディレクトリを設定します。 | を組織内のスタンドアロンリポジトリ`ASC-Datasets`として設定するには、次のコマンドを実行します。git init
git add .
git commit -m "Initial commit: ASC-Datasets standalone repository"
git remote add origin
git branch -M dev
| AWS DevOps |
| .github ワークフローファイルでブランチ名を設定します。 | 次の例に示すように、[デプロイ](https://github.com/aws-samples/sample-automate-aws-supply-chain-deployment/blob/main/ASC-Datasets/.github/workflows/asc-datasets.yml)ワークフローファイルにブランチ名を設定します。 on:
workflow_dispatch:
push:
branches:
- dev #Change to any other branch preferred for deployment
| アプリ所有者 |
| GitHub 環境をセットアップし、環境値を設定します。 | GitHub 組織で GitHub 環境を設定するには、このパターンのリポジトリにある [ GitHub 環境のセットアップ](https://github.com/aws-samples/sample-automate-aws-supply-chain-deployment/tree/main/ASC-Datasets#setup-github-environments)の手順を使用します。ワークフローファイルで[環境値](https://github.com/aws-samples/sample-automate-aws-supply-chain-deployment/tree/main/ASC-Datasets#setup-environment-values-in-the-workflow-files)を設定するには、このパターンのリポジトリ[のワークフローファイルの環境値のセットアップ](https://github.com/aws-samples/sample-automate-aws-supply-chain-deployment/tree/main/ASC-Datasets#setup-environment-values-in-the-workflow-files)の手順を使用します。 | アプリ所有者 |
| ワークフローをトリガーします。 | 変更を GitHub 組織にプッシュし、デプロイワークフローをトリガーするには、次のコマンドを実行します。git push -u origin dev
| AWS DevOps |
### (自動オプション) GitHub Actions ワークフローを使用して AWS Supply Chain 統合フローをデプロイする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| `ASC-Integration-Flows` ディレクトリをコピーします。 | `ASC-Integration-Flows` ディレクトリを新しい場所にコピーするには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-the-deployment-of-aws-supply-chain-data-lakes.html) | AWS DevOps |
| `ASC-Integration-Flows` ディレクトリを設定します。 | `ASC-Integration-Flows` ディレクトリを組織内のスタンドアロンリポジトリとして設定するには、次のコマンドを実行します。git init
git add .
git commit -m "Initial commit: ASC-Integration-Flows standalone repository"
git remote add origin
git branch -M dev
| AWS DevOps |
| .github ワークフローファイルでブランチ名を設定します。 | 次の例に示すように、[デプロイ](https://github.com/aws-samples/sample-automate-aws-supply-chain-deployment/blob/main/ASC-Integration-Flows/.github/workflows/asc-integration-flows.yml)ワークフローファイルにブランチ名を設定します。 on:
workflow_dispatch:
push:
branches:
- dev #Change to any other branch preferred for deployment
| アプリ所有者 |
| GitHub 環境をセットアップし、環境値を設定します。 | GitHub 組織で GitHub 環境を設定するには、このパターンのリポジトリにある [ GitHub 環境のセットアップ](https://github.com/aws-samples/sample-automate-aws-supply-chain-deployment/tree/main/ASC-Integration-Flows#setup-github-environments)の手順を使用します。ワークフローファイルで[環境値](https://github.com/aws-samples/sample-automate-aws-supply-chain-deployment/tree/main/ASC-Integration-Flows#setup-github-environments)を設定するには、このパターンのリポジトリ[のワークフローファイルの環境値のセットアップ](https://github.com/aws-samples/sample-automate-aws-supply-chain-deployment/tree/main/ASC-Integration-Flows#setup-environment-values-in-the-workflow-files)の手順を使用します。 | アプリ所有者 |
| ワークフローをトリガーします。 | 変更を GitHub 組織にプッシュし、デプロイワークフローをトリガーするには、次のコマンドを実行します。git push -u origin dev
| AWS DevOps |
### (手動オプション) Terraform を使用して AWS Supply Chain データセットをデプロイする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| `terraform-deployment ` ディレクトリに移動します。 | の `terraform-deployment` ディレクトリに移動するには`ASC-Datasets`、次のコマンドを実行します。cd ASC-Datasets/terraform-deployment
| AWS DevOps |
| Terraform 状態 Amazon S3 バケットを設定します。 | Terraform 状態 Amazon S3 バケットを設定するには、次のスクリプトを使用します。# Setup terraform bucket
chmod +x ../scripts/setup-terraform.sh
../scripts/setup-terraform.sh
| AWS DevOps |
| Terraform アーティファクト Amazon S3 バケットを設定します。 | Terraform アーティファクト Amazon S3 バケットを設定するには、次のスクリプトを使用します。# Setup terraform artifacts bucket
chmod +x ../scripts/setup-terraform-artifacts-bucket.sh
../scripts/setup-terraform-artifacts-bucket.sh
| AWS DevOps |
| Terraform バックエンドとプロバイダーの設定をセットアップします。 | Terraform バックエンドとプロバイダーの設定を設定するには、次のスクリプトを使用します。# Setup terraform backend and providers config if they don't exist
chmod +x ../scripts/generate-terraform-config.sh
../scripts/generate-terraform-config.sh
| AWS DevOps |
| デプロイプランを生成します。 | デプロイプランを生成するには、次のコマンドを実行します。# Run terraform init and validate
terraform init
terraform validate
# Run terraform plan
terraform plan \
-var-file="tfInputs/$ENVIRONMENT.tfvars" \
-var="project_name=$PROJECT_NAME" \
-var="environment=$ENVIRONMENT" \
-var="user_role=$AWS_USER_ROLE" \
-var="lambda_temp_dir=$LAMBDA_FUNCTION_TEMP_DIR_TERRAFORM" \
-var="layer_temp_dir=$LAMBDA_LAYER_TEMP_DIR_TERRAFORM" \
-parallelism=40 \
-out='tfplan.out'
| AWS DevOps |
| 設定をデプロイします。 | 設定をデプロイするには、次のコマンドを実行します。# Run terraform apply
terraform apply tfplan.out
| AWS DevOps |
| 他の設定を更新し、出力を保存します。 | AWS KMS キーポリシーを更新し、適用された設定出力を Terraform アーティファクト Amazon S3 バケットに保存するには、次のコマンドを実行します。# Update AWS Supply Chain KMS Key policy with the service's requirements
chmod +x ../scripts/update-asc-kms-policy.sh
../scripts/update-asc-kms-policy.sh
# Update AWS KMS Keys' policy with IAM roles
chmod +x ../scripts/update-kms-policy.sh
../scripts/update-kms-policy.sh
# Create terraform outputs file to be used as input variables
terraform output -json > raw_output.json
jq -r 'to_entries | map(
if .value.type == "string" then
"\(.key) = \"\(.value.value)\""
else
"\(.key) = \(.value.value | tojson)"
end
) | .[]' raw_output.json > $REPO_NAME-outputs.tfvars
# Upload reformed outputs file to Amazon S3 terraform artifacts bucket (For retrieval from other repositories)
aws s3 cp $REPO_NAME-outputs.tfvars s3://$S3_TERRAFORM_ARTIFACTS_BUCKET_NAME/$REPO_NAME-outputs.tfvars
rm -f raw_output.json
rm -f $REPO_NAME-outputs.tfvars
| AWS DevOps |
### (手動オプション) Terraform を使用して AWS Supply Chain サービス統合フローをデプロイする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| `terraform-deployment` ディレクトリに移動します。 | の `terraform-deployment` ディレクトリに移動するには`ASC-Integration-Flows`、次のコマンドを実行します。cd ASC-Integration-Flows/terraform-deployment
| AWS DevOps |
| Terraform バックエンドとプロバイダーの設定をセットアップします。 | Terraform バックエンドとプロバイダーの設定を設定するには、次のスクリプトを使用します。# Setup terraform backend and providers config if they don't exist
chmod +x ../scripts/generate-terraform-config.sh
../scripts/generate-terraform-config.sh
| AWS DevOps |
| デプロイプランを生成します。 | デプロイプランを生成するには、次のコマンドを実行します。これらのコマンドは、Terraform 環境を初期化し、 の設定変数を既存の Terraform 設定`ASC-Datasets`とマージして、デプロイプランを生成します。# Run terraform init and validate
terraform init
terraform validate
# Download and merge ASC DATASET tfvars
chmod +x ../scripts/download-vars-through-s3.sh
../scripts/download-vars-through-s3.sh $ASC_DATASET_VARS_REPO
# Run terraform plan
terraform plan \
-var-file="tfInputs/$ENVIRONMENT.tfvars" \
-var="project_name=$PROJECT_NAME" \
-var="environment=$ENVIRONMENT" \
-var="lambda_temp_dir=$LAMBDA_FUNCTION_TEMP_DIR_TERRAFORM" \
-var="layer_temp_dir=$LAMBDA_LAYER_TEMP_DIR_TERRAFORM" \
-parallelism=40 \
-out='tfplan.out'
| AWS DevOps |
| 設定をデプロイします。 | 設定をデプロイするには、次のコマンドを実行します。# Run terraform apply
terraform apply tfplan.out
| AWS DevOps |
| 他の設定を更新します。 | AWS KMS キーポリシーを更新し、適用された設定出力を Terraform アーティファクト Amazon S3 バケットに保存するには、次のコマンドを実行します。# Update AWS KMS Keys' policy with IAM roles
chmod +x ../scripts/update-kms-policy-through-s3.sh
../scripts/update-kms-policy-through-s3.sh $ASC_DATASET_VARS_REPO
# Create terraform outputs file to be used as input variables
terraform output -json > raw_output.json
jq -r 'to_entries | map(
if .value.type == "string" then
"\(.key) = \"\(.value.value)\""
else
"\(.key) = \(.value.value | tojson)"
end
) | .[]' raw_output.json > $REPO_NAME-outputs.tfvars
# Upload reformed outputs file to Amazon S3 terraform artifacts bucket (For retrieval from other repositories)
aws s3 cp $REPO_NAME-outputs.tfvars s3://$S3_TERRAFORM_ARTIFACTS_BUCKET_NAME/$REPO_NAME-outputs.tfvars
rm -f raw_output.json
rm -f $REPO_NAME-outputs.tfvars
| AWS DevOps |
### (両方のオプション) データを取り込む
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| サンプル CSV ファイルをアップロードします。 | データセットのサンプル CSV ファイルをアップロードするには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-the-deployment-of-aws-supply-chain-data-lakes.html) | データエンジニア |
### (両方のオプション) AWS Supply Chain アクセスを設定する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| AWS Supply Chain アクセスを設定します。 | からの AWS Supply Chain アクセスを設定するには AWS マネジメントコンソール、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-the-deployment-of-aws-supply-chain-data-lakes.html) | アプリ所有者 |
### (自動オプション) GitHub Actions ワークフローを使用してすべてのリソースをクリーンアップする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| 統合フローリソースの破棄ワークフローをトリガーします。 | GitHub 組織のデプロイブランチ`ASC-Integration-Flows`から の[破棄ワークフロー](https://github.com/aws-samples/sample-automate-aws-supply-chain-deployment/blob/main/ASC-Integration-Flows/.github/workflows/destroy-workflow.yml)をトリガーします。 | AWS DevOps |
| データセットリソースの破棄ワークフローをトリガーします。 | GitHub 組織のデプロイブランチ`ASC-Datasets`から の[破棄ワークフロー](https://github.com/aws-samples/sample-automate-aws-supply-chain-deployment/blob/main/ASC-Datasets/.github/workflows/destroy-workflow.yml)をトリガーします。 | AWS DevOps |
### (手動オプション) Terraform を使用して AWS Supply Chain 統合フローのリソースをクリーンアップする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| `terraform-deployment` ディレクトリに移動します。 | の `terraform-deployment` ディレクトリに移動するには`ASC-Integration-Flows`、次のコマンドを実行します。cd ASC-Integration-Flows/terraform-deployment
| AWS DevOps |
| Terraform バックエンドとプロバイダーの設定をセットアップします。 | Terraform バックエンドとプロバイダーの設定を設定するには、次のスクリプトを使用します。# Setup terraform backend and providers config if they don't exist
chmod +x ../scripts/generate-terraform-config.sh
../scripts/generate-terraform-config.sh
| AWS DevOps |
| インフラストラクチャ破壊計画を作成します。 | 詳細なティアダウンプランを生成して AWS インフラストラクチャの制御された破壊に備えるには、次のコマンドを実行します。このプロセスでは、Terraform を初期化し、 AWS Supply Chain データセット設定を組み込み、実行前に確認できる破棄計画を作成します。# Run terraform init and validate
terraform init
terraform validate
# Download and merge ASC DATASET tfvars
chmod +x ../scripts/download-vars-through-s3.sh
../scripts/download-vars-through-s3.sh $ASC_DATASET_VARS_REPO
# Run terraform plan
terraform plan -destroy\
-var-file="tfInputs/$ENVIRONMENT.tfvars" \
-var="project_name=$PROJECT_NAME" \
-var="environment=$ENVIRONMENT" \
-var="lambda_temp_dir=$LAMBDA_FUNCTION_TEMP_DIR_TERRAFORM" \
-var="layer_temp_dir=$LAMBDA_LAYER_TEMP_DIR_TERRAFORM" \
-parallelism=40 \
-out='tfplan.out'
| AWS DevOps |
| インフラストラクチャ破壊計画を実行します。 | インフラストラクチャの計画された破棄を実行するには、次のコマンドを実行します。# Run terraform apply
terraform apply tfplan.out
| AWS DevOps |
| Amazon S3 バケットから Terraform 出力を削除します。 | のデプロイ中にアップロードされた出力ファイルを削除するには`ASC-Integration-Flows`、次のコマンドを実行します。# Delete the outputs file
aws s3 rm s3://$S3_TERRAFORM_ARTIFACTS_BUCKET_NAME/$REPO_NAME-outputs.tfvars
| AWS DevOps |
### (手動オプション) Terraform を使用して AWS Supply Chain サービスデータセットのリソースをクリーンアップする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| `terraform-deployment` ディレクトリに移動します。 | の `terraform-deployment` ディレクトリに移動するには`ASC-Datasets`、次のコマンドを実行します。cd ASC-Datasets/terraform-deployment
| AWS DevOps |
| Terraform バックエンドとプロバイダーの設定をセットアップします。 | Terraform バックエンドとプロバイダーの設定を設定するには、次のスクリプトを使用します。# Setup terraform backend and providers config if they don't exist
chmod +x ../scripts/generate-terraform-config.sh
../scripts/generate-terraform-config.sh
| AWS DevOps |
| インフラストラクチャ破壊計画を作成します。 | AWS Supply Chain データセットリソースを破棄する計画を作成するには、次のコマンドを実行します。# Run terraform init and validate
terraform init
terraform validate
# Run terraform plan
terraform plan -destroy\
-var-file="tfInputs/$ENVIRONMENT.tfvars" \
-var="project_name=$PROJECT_NAME" \
-var="environment=$ENVIRONMENT" \
-var="user_role=$AWS_USER_ROLE" \
-var="lambda_temp_dir=$LAMBDA_FUNCTION_TEMP_DIR_TERRAFORM" \
-var="layer_temp_dir=$LAMBDA_LAYER_TEMP_DIR_TERRAFORM" \
-parallelism=40 \
-out='tfplan.out'
| AWS DevOps |
| Amazon S3 バケットを空にします。 | すべての Amazon S3 バケット ( 用に設定されたサーバーアクセスログ記録バケットを除く`force-destroy`) を空にするには、次のスクリプトを使用します。# Delete S3 buckets excluding server access logging bucket
chmod +x ../scripts/empty-s3-buckets.sh
../scripts/empty-s3-buckets.sh tfplan.out
| AWS DevOps |
| インフラストラクチャ破壊計画を実行します。 | 生成されたプランを使用して AWS Supply Chain データセットインフラストラクチャの計画された破壊を実行するには、次のコマンドを実行します。# Run terraform apply
terraform apply tfplan.out
| AWS DevOps |
| Amazon S3 Terraform アーティファクトバケットから Terraform 出力を削除します。 | クリーンアッププロセスを完了するには、次のコマンド`ASC-Datasets`を実行して、 のデプロイ中にアップロードされた出力ファイルを削除します。# Delete the outputs file
aws s3 rm s3://$S3_TERRAFORM_ARTIFACTS_BUCKET_NAME/$REPO_NAME-outputs.tfvars
| AWS DevOps |
## トラブルシューティング
| 問題 | ソリューション |
| --- | --- |
| AWS Supply Chain 内部エラーまたはサービスロールの IAM アクセス許可が不十分であるため、 AWS Supply Chain データセットまたは統合フローが正しくデプロイされませんでした。 | まず、すべてのリソースをクリーンアップします。次に、 AWS Supply Chain [データセットリソース](https://github.com/aws-samples/sample-automate-aws-supply-chain-deployment/blob/main/ASC-Datasets/README.md)を再デプロイし、 AWS Supply Chain [統合フローリソース](https://github.com/aws-samples/sample-automate-aws-supply-chain-deployment/blob/main/ASC-Integration-Flows/README.md)を再デプロイします。 |
| AWS Supply Chain 統合フローは、 AWS Supply Chain データセットにアップロードされた新しいデータファイルを取得しません。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-the-deployment-of-aws-supply-chain-data-lakes.html) |
## 関連リソース
**AWS ドキュメント**
+ [AWS Supply Chain](https://docs.aws.amazon.com/aws-supply-chain/latest/adminguide/getting-started.html)
**その他のリソース**
+ [GitHub Actions ワークフローについて](https://docs.github.com/en/actions/get-started/understand-github-actions) (GitHub ドキュメント)
## 追加情報
このソリューションは、 で提供される構築済みのダッシュボード AWS Supply Chain または Amazon Quick Sight とのカスタム統合を通じて、より多くのデータセットにレプリケートでき、さらなる分析のためにクエリを実行できます。さらに、Amazon Q を使用して、 AWS Supply Chain インスタンスに関連する質問をすることができます。
**Analytics でデータを分析する AWS Supply Chain **
AWS Supply Chain 分析を設定する手順については、 AWS Supply Chain ドキュメントの[AWS Supply Chain 「分析の設定](https://docs.aws.amazon.com/aws-supply-chain/latest/userguide/setting_analytics.html)」を参照してください。
このパターンは、**カレンダー**データセットと **Outbound\$1Order\$1Line** データセットの作成を示しています。これらのデータセットを使用する分析を作成するには、次の手順を実行します。
1. データセットを分析するには、**季節性分析**ダッシュボードを使用します。ダッシュボードを追加するには、 AWS Supply Chain ドキュメントの[「構築済みダッシュボード](https://docs.aws.amazon.com/aws-supply-chain/latest/userguide/prebuilt_dashboards.html)」のステップに従います。
1. ダッシュボードを選択すると、カレンダーデータとアウトバウンド注文明細データのサンプル CSV ファイルに基づく分析が表示されます。
ダッシュボードは、データセットの取り込まれたデータに基づいて、長年にわたってオンデマンドでインサイトを提供します。ProductID、CustomerID、年、およびその他のパラメータをさらに指定して分析できます。
**Amazon Q を使用して AWS Supply Chain インスタンスに関連する質問をする**
[Amazon Q in AWS Supply Chain](https://docs.aws.amazon.com/aws-supply-chain/latest/userguide/qinasc.html) は、サプライチェーンをより効率的に運用するのに役立つインタラクティブな生成 AI アシスタントです。Amazon Q は以下を実行できます。
+ AWS Supply Chain データレイク内のデータを分析します。
+ 運用上および財務上のインサイトを提供します。
+ サプライチェーンに関する即時の質問に回答します。
Amazon Q の使用の詳細については、 AWS Supply Chain ドキュメントの[「 での Amazon Q の有効化 AWS Supply Chain](https://docs.aws.amazon.com/aws-supply-chain/latest/userguide/enabling_QinASC.html)」と[「 での Amazon Q の使用 AWS Supply Chain](https://docs.aws.amazon.com/aws-supply-chain/latest/userguide/using_QinASC.html)」を参照してください。
# AWS リソース評価を自動化する
*Amazon Web Services、Naveen Suthar、Arun bagal、Manish Garg、Sandeep Gawande*
## 概要
このパターンでは、[AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/v2/guide/home.html) を使用してリソース評価機能を設定する自動化アプローチを説明します。このパターンを使用すると、運用チームはリソース監査の詳細を自動的に収集し、AWS アカウントにデプロイされたすべてのリソースの詳細を単一のダッシュボードに表示できます。このパターンは、以下に示すユースケースで役立ちます。
+ infrastructure as code (IaC) ツールを特定し、[HashiCorp Terraform](https://www.terraform.io/)、[AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)、AWS CDK、[AWS コマンドラインインターフェイス (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) など、さまざまな IaC ソリューションによって作成されたリソースを孤立化します。
+ リソース監査情報を取得する
このソリューションは、リーダーシップチームが単一ダッシュボードから AWS アカウントのリソースとアクティビティに関する洞察を得る上でも役立ちます。
|
|
| 注: [Amazon Quick Sight](https://docs.aws.amazon.com/quicksight/latest/user/welcome.html) は有料サービスです。データを分析し、ダッシュボードを作成する前に、[Amazon Quick Sight の料金](https://aws.amazon.com/quicksight/pricing/)を確認してください。 |
| --- |
## 前提条件と制限
**前提条件**
+ アクティブな AWS アカウント。
+ AWS Identity and Access Management (IAM) ロールとプロビジョンリソースへのアクセス権限
+ Amazon [Simple Storage Service (Amazon Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html)[S3) と Amazon Athena にアクセスできるように作成された Amazon Quick アカウント](https://docs.aws.amazon.com/quicksight/latest/user/signing-up.html) [Amazon Athena](https://docs.aws.amazon.com/athena/latest/ug/what-is.html)
+ AWS CDK バージョン 2.55.1 以降がインストールされている
+ [Python](https://www.python.org/downloads/release/python-390/) 3.9 以降がインストールされている
**制限**
+ このソリューションは単一 AWS アカウントにデプロイされます。
+ このソリューションは、AWS CloudTrail がすでにセットアップされ、S3 バケットにデータを保存していない限り、デプロイ前に発生したイベントを追跡しません。
**製品バージョン**
+ AWS CDK バージョン 2.55.1 またはそれ以降
+ Python バージョン 3.9 以降
## アーキテクチャ
**ターゲットテクノロジースタック**
+ Amazon Athena
+ AWS CloudTrail
+ AWS Glue
+ AWS Lambda
+ Amazon Quick Sight
+ Amazon S3
**ターゲットアーキテクチャ**
AWS CDK コードは、AWS アカウントへのリソース評価機能の設定に必要なすべてのリソースをデプロイします。次の図は、CloudTrail ログを AWS Glue、Amazon Athena、および Quick Sight に送信するプロセスを示しています。
![\[AWS Glue、Amazon Athena、Amazon QuickSight を使用した AWS リソース評価は 6 つのステップから成るプロセスです。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/a504774e-db7a-4c36-a22c-ce56d252fb58/images/8f2b549d-33a8-4cbf-86fd-33244716b668.png)
1. CloudTrail は、ストレージ用にログを S3 バケットに送信します。
1. イベント通知は、ログを処理してフィルタリングされたデータを生成する Lambda 関数を呼び出します。
1. フィルタリングされたデータは、別の S3 バケットに保存されます。
1. S3 バケット内のフィルタリングされたデータに AWS Glue クローラーを設定して、AWS Glue データカタログテーブルにスキーマを作成します。
1. フィルタリングされたデータを Amazon Athena によってクエリする準備ができました。
1. クエリされたデータは、Quick Sight によって視覚化のためにアクセスされます。
**自動化とスケール**
+ AWS Organizations に組織全体の CloudTrail トレイルがある場合は、このソリューションを 1 つの AWS アカウントから複数の AWS アカウントに拡張できます。CloudTrail を組織レベルでデプロイすることで、このソリューションを使用して、必要なすべてのリソースのリソース監査詳細を取得することもできます。
+ このパターンでは、AWS サーバーレスリソースを使用してソリューションをデプロイします。
## ツール
**AWS サービス**
+ [Amazon Athena](https://docs.aws.amazon.com/athena/latest/ug/what-is.html) はインタラクティブなクエリサービスで、Amazon S3 内のデータをスタンダード SQL を使用して直接分析できます。
+ [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/latest/guide/home.html) は、AWS クラウドインフラストラクチャをコードで定義してプロビジョニングするのに役立つソフトウェア開発フレームワークです。
+ [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) を使用すると、AWS リソースをセットアップし、迅速かつ一貫したプロビジョニングをし、AWS アカウントと AWS リージョンにわたってライフサイクル全体のリソースを管理できます。
+ [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) は、AWS アカウントのガバナンス、コンプライアンス、運用面のリスクの監査をサポートします。
+ [AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/what-is-glue.html) は、フルマネージド型の抽出、変換、ロード (ETL) サービスです。これにより、データストアとデータストリーム間でのデータの確実な分類、整理、強化、移動をサポートできます。このパターンでは、AWS Glue クローラーと AWS Glue データカタログテーブルを使用します。
+ [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。
+ [Amazon Quick](https://docs.aws.amazon.com/quicksight/latest/user/welcome.html) は、単一のダッシュボードでデータを視覚化、分析、レポートするのに役立つクラウドスケールのビジネスインテリジェンス (BI) サービスです。
+ [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) は、あらゆる量のデータを保存、保護、取得できるクラウドベースのオブジェクトストレージサービスです。
**コードリポジトリ**
このパターンのコードは、GitHub 内の「[infrastructure-assessment-iac-automation](https://github.com/aws-samples/infrastructure-assessment-iac-automation)」リポジトリで利用できます。
コードリポジトリには、以下のファイルとフォルダが含まれます。
+ `lib` フォルダ — AWS CDK は、AWS リソースの作成に使用される Python ファイルをコンストラクトします。
+ `src/lambda_code` — Lambda 関数で実行される Python コード
+ `requirements.txt` — インストールする必要があるすべての Python 依存関係のリスト
+ `cdk.json` — リソースの起動に必要な値を提供する入力ファイル
## ベストプラクティス
Lambda 関数のモニタリングとアラートを設定します。詳細については、[Lambda 関数をモニタリングおよびトラブルシューティングする](https://docs.aws.amazon.com/lambda/latest/dg/lambda-monitoring.html)を参照してください。Lambda 関数を使用する際の一般的なベストプラクティスについては、[AWS ドキュメント](https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html)を参照してください。
## エピック
### 環境をセットアップします。
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| ローカルマシンにリポジトリを複製します。 | リポジトリを複製するには、`git clone https://github.com/aws-samples/infrastructure-assessment-iac-automation.git` コマンドを実行します。 | AWS DevOps、DevOps エンジニア |
| Python 仮想環境を設定し、必要な依存関係をインストールします。 | Python 仮想環境をセットアップするには、次のコマンドを実行します。cd infrastructure-assessment-iac-automation
python3 -m venv .venv
source .venv/bin/activate
必要な依存関係を設定するには、`pip install -r requirements.txt` コマンドを実行します。 | AWS DevOps、DevOps エンジニア |
| AWS CDK 環境をセットアップし、AWS CDK コードを合成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-aws-resource-assessment.html) | AWS DevOps、DevOps エンジニア |
### ローカルマシンで AWS 認証情報をセットアップする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| スタックをデプロイするアカウントとリージョンの変数をエクスポートします。 | 環境変数を使用して AWS CDK の AWS 認証情報を提供には、次のコマンドを実行します。export CDK_DEFAULT_ACCOUNT=<12 Digit AWS Account Number>
export CDK_DEFAULT_REGION=
| AWS DevOps、DevOps エンジニア |
| AWS CLI プロファイルをセットアップします。 | アカウントの AWS CLI プロファイルを設定するには、[AWS ドキュメント](https://docs.aws.amazon.com/toolkit-for-visual-studio/latest/user-guide/keys-profiles-credentials.html)の指示に従います。 | AWS DevOps、DevOps エンジニア |
### リソース評価ツールを設定してデプロイする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| アカウントにリソースをデプロイします。 | AWS CDK を使用して AWS アカウントにリソースをデプロイするには、以下を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-aws-resource-assessment.html) | AWS DevOps |
| AWS Glue クローラーを実行し、データカタログテーブルを作成します。 | [AWS Glue クローラー](https://docs.aws.amazon.com/glue/latest/dg/add-crawler.html)は、データスキーマを動的に保つために使用されます。このソリューションは、AWS Glue クローラースケジューラーの定義に従ってクローラーを定期的に実行することで、[AWS Glue データカタログテーブル](https://docs.aws.amazon.com/athena/latest/ug/querying-glue-catalog.html)のパーティションを作成および更新します。出力 S3 バケットでデータが使用できるようになると、次のステップを使用して AWS Glue クローラーを実行し、テスト用の Data Catalog テーブルスキーマを作成します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-aws-resource-assessment.html)AWS CDK コードは AWS Glue クローラーを特定の時間に実行するように設定しますが、オンデマンドで実行することもできます。 | AWS DevOps、DevOps エンジニア |
| Quick Sight コンストラクトをデプロイします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-aws-resource-assessment.html) | AWS DevOps、DevOps エンジニア |
| Quick Sight ダッシュボードを作成します。 | Quick Sight ダッシュボードと分析の例を作成するには、以下を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-aws-resource-assessment.html)詳細については、[「Amazon Quick Sight での分析の開始](https://docs.aws.amazon.com/quicksight/latest/user/creating-an-analysis.html)」および[「Amazon Quick Sight でのビジュアルタイプ](https://docs.aws.amazon.com/quicksight/latest/user/working-with-visual-types.html)」を参照してください。 | AWS DevOps、DevOps エンジニア |
### ソリューション内のすべての AWS リソースをクリーンアップする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| AWS リソースを削除します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-aws-resource-assessment.html) | AWS DevOps、DevOps エンジニア |
### AWS リソース評価ツールの自動化のトップに追加機能を設定する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| 手動で作成したリソースを監視してクリーンアップします。 | (オプション) アプリケーションに IaC ツールを使用してリソースを作成するというコンプライアンス要件がある場合は、AWS リソース評価ツールの自動化を使用して手動でプロビジョニングされたリソースを取得することで、コンプライアンスを達成できます。また、このツールを使用して、リソースを IaC ツールにインポートまたはリソースを再作成できます。手動でプロビジョニングされたリソースを監視するには、以下の高レベルのタスクを実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-aws-resource-assessment.html) | AWS DevOps、DevOps エンジニア |
## トラブルシューティング
| 問題 | ソリューション |
| --- | --- |
| AWS CDK はエラーを返します。 | AWS CDK の問題に関するヘルプは、[一般的な AWS CDK 問題をトラブルシューティングする](https://docs.aws.amazon.com/cdk/v2/guide/troubleshooting.html)を参照してください。 |
## 関連リソース
+ [Python で Lambda 関数を構築する](https://docs.aws.amazon.com/lambda/latest/dg/lambda-python.html)
+ [AWS CDK の使用を開始する](https://docs.aws.amazon.com/cdk/v2/guide/getting_started.html)
+ [Python の AWS CDK を使用する](https://docs.aws.amazon.com/cdk/v2/guide/work-with-cdk-python.html)
+ [CloudTrail ログ証跡を作成する](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html)
+ [Amazon Quick Sight の使用を開始する](https://aws.amazon.com/quicksight/getting-started/)
## 追加情報
**複数アカウント**
複数アカウントの AWS CLI 認証情報を設定するには、AWS プロファイルを使用します。詳細については、[AWS CLI をセットアップする](https://aws.amazon.com/getting-started/guides/setup-environment/module-three/)」の*複数のプロファイルの設定する*セクションを参照してください。
**AWS CDK コマンド**
AWS CDK を使用する際は、以下の便利なコマンドに注意してください。
+ アプリ内のすべてのスタックを一覧表示
```
cdk ls
```
+ 合成された AWS CloudFormation テンプレートを発行
```
cdk synth
```
+ スタックをデフォルトの AWS アカウントとリージョンにデプロイ
```
cdk deploy
```
+ デプロイされたスタックを現在の状態と比較
```
cdk diff
```
+ AWS CDK ドキュメントを開く
```
cdk docs
```
# オープンソースツールを使用して SAP システムを自動的にインストール
*Amazon Web Services、Guilherme Sesterheim*
## 概要
このパターンでは、オープンソースツールを使用して以下のリソースを作成することで SAP システムのインストールを自動化する方法を示しています。
+ SAP S/4HANA 1909 データベース
+ SAP ABAP セントラルサービス (ASCS) インスタンス
+ SAP プライマリアプリケーションサーバー (PAS) インスタンス
HashiCorp Terraform が SAP システムのインフラストラクチャを作成し、Ansible がオペレーティングシステム (OS) を設定し、SAP アプリケーションをインストールします。Jenkins がインストールを実行します。
この設定により、SAP システムのインストールが反復可能なプロセスになり、デプロイの効率と品質が向上します。
**注記**
このパターンで提供されるサンプルコードは、高可用性 (HA) システムと非 HA システムの両方で機能します。
## 前提条件と制限
**前提条件**
+ アクティブなAWS アカウント
+ すべての SAP メディアファイルを含めるAmazon Simple Storage Service (Amazon S3) バケット
+ [アクセスキーとシークレットキー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html) を持ち、以下の権限を持つ AWS アイデンティテとアクセス管理 (IAM) プリンシパルです。
+ **読み取り専用権限：**Amazon Route 53、AWS Key Management Service (AWS KMS)
+ **読み取り権限と書き込み権限：**Amazon S3、Amazon Elastic Compute Cloud (Amazon EC2)、Amazon Elastic File System (Amazon EFS)、IAM、Amazon CloudWatch、Amazon DynamoDB
+ ルート 53 [プライベートホストゾーン](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-private.html)
+ Amazon マーケットプレイスの [HA およびアップデートサービス 8.2 付けの Red Hat Enterprise Linux for SAP](https://aws.amazon.com/marketplace/pp/prodview-5grz5a5thx7c2) のAmazon マシンイメージ (AMI) についての説明
+ [AWS KMS カスタマー管理キー](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html#aws-managed-customer-managed-keys)
+ [Secure Shell (SSH) キーペア](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)
+ Jenkins をインストールしたホスト名からのポート 22 で SSH 接続を許可する [Amazon EC2 セキュリティグループ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html) (多分、ホスト名が**localhost**)
+ インストール、設定されたHashiCorpによる [バグラント](https://www.vagrantup.com/)
+ インストール、設定された Oracle による [VirtualBox](https://www.virtualbox.org/)
+ Git、テラフォーム、アンシブル、ジェンキンスに精通
**制限事項**
+ この特定のシナリオで完全にテストされているのは SAP S/4HANA 1909 だけです。別のバージョンの SAP HANA を使用する場合、このパターンの Ansible コード例を変更する必要があります。
+ このパターンのサンプル手順は Mac OS と Linux オペレーティングシステムで機能します。一部のコマンドは UNIX ベースの端末でしか実行できません。ただし、別のコマンドと Windows OS を使用しても同様の結果が取得されます。
**製品バージョン**
+ SAP S/4HANA 1909
+ Red Hat Enterprise Linux (RHEL) バージョン 6 以上
## アーキテクチャ
次の図表では、オープンソースツールを使用して AWS アカウントで SAP システムのインストールを自動化するワークフローの例を示しています。
![\[オープンソースツールを使用して AWS アカウントで SAP システムのインストールを自動化するワークフローの例。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/aaf11dac-38cc-4e89-be86-51d4409cf238/images/d7902f9d-f1be-461f-b69b-cf3c663c8f2f.png)
この図表は、次のワークフローを示しています:
1. Jenkins は Terraform と Ansible のコードを実行することで SAP システムのインストールをオーケストレーションします。
1. Terraform コードは SAP システムのインフラストラクチャを構築します。
1. Ansible コードが OS を設定し、SAP アプリケーションをインストールします。
1. 定義されたすべての前提条件を含む SAP S/4HANA 1909 データベース、ASCS インスタンス、および PAS インスタンスが Amazon EC2 インスタンスにインストールされます。
**注記**
このパターンの設定例では、Terraform 状態ファイルを保存するための Amazon S3 バケットが AWS アカウントに自動的に作成されます。
**テクノロジースタック**
+ Terraform
+ Ansible
+ Jenkins
+ SAP S/4HANA 1909 データベース
+ SAP ASCS インスタンス
+ SAP PAS インスタンス
+ Amazon EC2
## ツール
** サービス**
+ 「[Amazon Elastic Compute Cloud (Amazon EC2)](https://docs.aws.amazon.com/ec2/?id=docs_gateway)」は、AWS クラウドでスケーラブルなコンピューティング容量を提供します。仮想サーバーを必要な数だけ起動して、迅速にスケールアップまたはスケールダウンができます。
+ 「[AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)」は、AWS リソースへのアクセスを安全に管理し、誰が認証され、使用する権限があるかを制御するのに役立ちます。
+ [AWS Key Management Service (AWS KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) は、ユーザーのデータを保護するために使用される、暗号化キーの作成と制御を容易にするマネージドサービスです。
+ [Amazon Virtual Private Cloud (Amazon VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) を使用すると、定義した仮想ネットワーク内で AWS リソースを起動できます。この仮想ネットワークは、お客様自身のデータセンターで運用されていた従来のネットワークに似ていますが、AWS のスケーラブルなインフラストラクチャを使用できるというメリットがあります。
**その他のツール**
+ [HashiCorp Terraform](https://www.terraform.io/docs) は、コードを使用してクラウドインフラストラクチャとリソースをプロビジョニングおよび管理するのに役立つコマンドラインインターフェイスアプリケーションです。
+ [Ansible](https://www.ansible.com/) は、アプリケーション、構成、IT インフラストラクチャの自動化に役立つオープンソースのコード設定 (CaC) ツールです。
+ [Jenkins](https://www.jenkins.io/) は、デベロッパーがソフトウェアを確実に構築、テスト、デプロイできるようにするオープンソースのオートメーションサーバーです。
**コード**
このパターンのコードでは、GitHub 内の「[aws-install-sap-with-jenkins-ansible](https://github.com/aws-samples/aws-install-sap-with-jenkins-ansible)」リポジトリで利用できます。
## エピック
### AWS の前提条件の設定
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| Amazon S3 バケットにファイルを追加します。 | SAP メディアファイルをすべて含め、[Amazon S3 バケットを作成](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html)します。[Launch Wizard ドキュメント](https://docs.aws.amazon.com/launchwizard/latest/userguide/launch-wizard-sap-software-install-details.html) の **S/4HANA** の AWS Launch Wizard のフォルダ階層に必ず従ってください。 | クラウド管理者 |
| VirtualBox をインストールします。 | Oracle で [VirtualBox](https://www.virtualbox.org/) をインストールして設定します。 | DevOps エンジニア |
| Vagrant をインストールします。 | HashiCorp による [Vagrant](https://www.vagrantup.com/)のインストールと設定を行います。 | DevOps エンジニア |
| AWS アカウントの設定 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/install-sap-systems-automatically-by-using-open-source-tools.html) | AWS 全般 |
### SAP インストールを構築して実行
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| GitHub から リポジトリのクローンを作成します。 | GitHub の [aws-install-sap-with-jenkins-ansible](https://github.com/aws-samples/aws-install-sap-with-jenkins-ansible) リポジトリをクローンします。 | DevOps エンジニア |
| Jenkins サービスを開始します。 | Linux ターミナルを開く 次に、クローンされたコードリポジトリフォルダを含むローカルフォルダにナビゲーションし、以下のコマンドを実行します。sudo vagrant up
Jenkins の起動には約 20 分かかります。コマンドが成功する場合、**サービスがアップし、実行されています**というメッセージが返されます。 | DevOps エンジニア |
| ウェブブラウザで Jenkins を開き、ログインします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/install-sap-systems-automatically-by-using-open-source-tools.html) | DevOps エンジニア |
| SAP システムのインストールパラメータを設定します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/install-sap-systems-automatically-by-using-open-source-tools.html)[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/install-sap-systems-automatically-by-using-open-source-tools.html)その他の必須ではないパラメータは、ユースケースに基づいて必要に応じて設定できます。例えば、SAP システムのインスタンスの SAP システム ID (SID)、デフォルトパスワード、名前、タグを変更できます。 すべての必須変数には、名前の先頭に **(必須)** が付いています。 | AWS システム管理者、DevOps エンジニア |
| SAP システムインストールを実行します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/install-sap-systems-automatically-by-using-open-source-tools.html)パイプラインステップの詳細については、AWS ブログの[オープンソースツールによる SAP インストールの自動化](https://aws.amazon.com/blogs/awsforsap/automating-sap-installation-with-open-source-tools/) の**パイプラインステップの理解** セクションを参照してください。エラーが発生した場合、表示される赤いエラーボックスの上にカーソルを移動し、**[ログ]** を選択します。エラーが発生したパイプラインステップのログが表示されます。ほとんどのエラーは、誤ったパラメータ設定が原因で発生します。 | DevOps エンジニア、AWS システム管理者 |
## 関連リソース
+ [SAP 向け DevOps — SAP インストール：2 か月から 2 時間へ](https://videos.itrevolution.com/watch/707351918/) (DevOps エンタープライズ提出ビデオライブラリ)
# AWS CDK を使用して AWS Service Catalog ポートフォリオと製品のデプロイを自動化する
*Amazon Web Services、Sandeep Gawande、Vyoma Sachdeva、RAJNEESH TYAGI*
## 概要
AWS Service Catalog は、組織の AWS 環境での使用が承認された IT サービスまたは*製品*のカタログを一元管理するのに役立ちます。*ポートフォリオ*とは製品の一群のことです。これには設定情報も含まれます。AWS Service Catalogでは、組織のユーザータイプごとにカスタマイズしたポートフォリオを作成し、適切なポートフォリオへのアクセス権を選択的に付与できます。そうすれば、ユーザーはポートフォリオ内から必要な製品をすばやくデプロイできます。
マルチリージョンアーキテクチャやマルチアカウントアーキテクチャなどの複雑なネットワークインフラストラクチャを使用している場合は、Service Catalog ポートフォリオを単一の中央アカウントで作成および管理することをお勧めします。このパターンでは、AWS Cloud Development Kit (AWS CDK) を使用して、中央アカウントでの Service Catalog ポートフォリオの作成を自動化し、エンドユーザーにそのポートフォリオへのアクセスを許可し、オプションで 1 つ以上のターゲット AWS アカウントに製品をプロビジョニングする方法を説明します。このすぐに使用できるソリューションにより、ソースアカウントに Service Catalog ポートフォリオが作成されます。また、オプションで AWS CloudFormation スタックを使用してターゲットアカウントに製品をプロビジョニングし、製品の TagOptions を設定するのに役立ちます。
+ **AWS CloudFormation StackSets** — StackSets を使用して、複数の AWS リージョンとアカウントにわたってService Catalog 製品を起動できます。このソリューションでは、このソリューションをデプロイするときに製品を自動的にプロビジョニングできます。詳細については、[AWS CloudFormation StackSets](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/using-stacksets.html) (Service Catalog ドキュメント) と [StackSets の概念](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-concepts.html) (CloudFormation ドキュメント) を参照してください。
+ **TagOption ライブラリ** — TagOption ライブラリを使用して、プロビジョニングされた製品のタグを管理できます。*TagOption* は AWS Service Catalog で管理されるキーと値のペアです。これは AWS のタグではありませんが、TagOption に基づいて AWS のタグを作成するためのテンプレートとして機能します。詳細については、[TagOption ライブラリー](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/tagoptions.html) との共有(Service Catalog ドキュメント) を参照してください。
## 前提条件と制限
**前提条件**
+ Service Catalog ポートフォリオを管理するためのソースアカウントとして使用するアクティブな AWS アカウント。
+ このソリューションを使用して 1 つ以上のターゲットアカウントに製品をプロビジョニングする場合、ターゲットアカウントはすでに存在し、アクティブである必要があります。
+ AWS Service Catalog、AWS CloudFormationおよび AWS IAM にアクセスするための AWS Identity and Access Management (IAM) 権限。
**製品バージョン**
+ AWS CDK バージョン 2.27.0
## アーキテクチャ
**ターゲットテクノロジースタック**
+ 一元管理された AWS アカウントのService Catalog ポートフォリオ
+ ターゲットアカウントにデプロイされたService Catalog 製品
**ターゲット アーキテクチャ**
![\[AWS CDK がService Catalog ポートフォリオを作成し、ターゲットアカウントに製品をプロビジョニングします。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/e8f217a7-aec4-4c85-8f6b-f91995506be0/images/1f027b82-14c3-485a-909b-1544e974b90a.png)
1. ポートフォリオ (または *ソース*) アカウントで、**config.json** ファイルを AWS アカウント、AWS リージョン、IAM ロール、ポートフォリオ、ユースケースの製品情報で更新します。
1. AWS CDK アプリケーションをデプロイします。
1. AWS CDK アプリケーションはデプロイメント IAM ロールを引き受け、**config.json** ファイルに定義されているService Catalog ポートフォリオと製品を作成します。
ターゲットアカウントに製品をデプロイするように StackSets を設定した場合、プロセスは続行されます。製品をプロビジョニングするように StackSets を設定していない場合、プロセスは完了です。
1. AWS CDK アプリケーションは**StackSet 管理者**ロールを引き受け、**config.json** ファイルで定義した AWS CloudFormationスタックセットをデプロイします。
1. ターゲットアカウントでは、StackSets が **StackSet の実行**ロールを引き受け、製品をプロビジョニングします。
## ツール
**AWS サービス**
+ [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/latest/guide/home.html) は、AWS クラウドインフラストラクチャをコードで定義してプロビジョニングするのに役立つソフトウェア開発フレームワークです。
+ [AWS CDK Toolkit](https://docs.aws.amazon.com/cdk/latest/guide/cli.html) は、 AWS CDKアプリケーションの操作に役立つコマンドラインクラウド開発キットです。
+ [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) を使用すると、AWS リソースをセットアップし、迅速かつ一貫したプロビジョニングを行い、AWS アカウントとリージョン全体でライフサイクル全体にわたってリソースを管理できます。
+ 「[AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)」は、AWS リソースへのアクセスを安全に管理し、誰が認証され、使用する権限があるかを制御するのに役立ちます。
+ [AWS Service Catalog](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/introduction.html) では、AWS で承認された IT サービスのカタログを一元管理できます。エンドユーザーは、組織によって設定された制約に従って、必要な承認済みの IT サービスのみをすばやくデプロイできます。
**コードリポジトリ**
このパターンのコードは、GitHub 内の「[aws-cdk-servicecatalog-automation](https://github.com/aws-samples/aws-cdk-servicecatalog-automation.git)」リポジトリで利用できます。コードリポジトリには以下のファイルとフォルダが含まれています。
+ **cdk-sevicecatalog-app** — このフォルダには、このソリューションの AWS CDK アプリケーションが含まれています。
+ **config** — このフォルダには、Service Catalog ポートフォリオに製品をデプロイするための **config.json** ファイルと CloudFormation テンプレートが含まれています。
+ **config/config.json** — このファイルにはすべての設定情報が含まれています。このファイルを更新して、ユースケースに合わせてこのソリューションをカスタマイズします。
+ **config/templates** — このフォルダには、サービスセンター製品のCloudFormation テンプレートが含まれています。
+ **setup.sh** — このスクリプトはソリューションをデプロイします。
+ **uninstall.sh** — このスクリプトは、スタックと、このソリューションのデプロイ時に作成されたすべての AWS リソースを削除します。
これらのファイルを使用するには、[エピック](#automate-aws-service-catalog-portfolio-and-product-deployment-by-using-aws-cdk-epics)セクションの指示に従ってください。
## ベストプラクティス
+ このソリューションのデプロイに使用する IAM ロールは、[最小権限の原則](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) (IAM ドキュメント) に従う必要があります。
+ [AWS CDK でクラウドアプリケーションを開発するためのベストプラクティス](https://aws.amazon.com/blogs/devops/best-practices-for-developing-cloud-applications-with-aws-cdk/) (AWS ブログ記事) に従ってください。
+ [AWS CloudFormation のベストプラクティス](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/best-practices.html) (クラウドフォーメーションドキュメント) に従ってください。
## エピック
### 環境をセットアップします。
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| AWS CDK Toolkitをインストールします。 | AWS CDK Toolkit がインストールされていることを確認します。次のコマンドを入力して、インストールされているかどうかを確認し、バージョンを確認します。 cdk --version
がインストールされていない場合は、次のコマンドを実行してインストールします。npm install -g aws-cdk@2.27.0
AWS CDK Toolkit のバージョンが 2.27.0 より前の場合は、次のコマンドを入力してバージョン 2.27.0 に更新します。npm install -g aws-cdk@2.27.0 --force
| AWS DevOps、DevOps エンジニア |
| リポジトリのクローン作成 | 次のコマンドを入力します。[追加情報](#automate-aws-service-catalog-portfolio-and-product-deployment-by-using-aws-cdk-additional) セクションの*リポジトリのクローン* では、リポジトリの URL を含むコマンド全体をコピーできます。これにより、GitHub から [aws-cdk-サービスカタログ-自動化](https://github.com/aws-samples/aws-cdk-servicecatalog-automation) リポジトリがクローンされます。git clone .git
これにより、ターゲットディレクトリに `cd aws-cdk-servicecatalog-automation` フォルダーが作成されます。次のコマンドを入力して、このフォルダーに移動します。cd aws-cdk-servicecatalog-automation
| AWS DevOps、DevOps エンジニア |
| AWS 認証情報の設定 | 以下のコマンドを入力します。これらは、スタックをデプロイする AWS アカウントとリージョンを定義する以下の変数をエクスポートします。export CDK_DEFAULT_ACCOUNT=<12-digit AWS account number>
export CDK_DEFAULT_REGION=
AWS CDK の AWS 認証情報は、環境変数を通じて提供されます。 | AWS DevOps、DevOps エンジニア |
| エンドユーザーIAM ロールのアクセス許可を設定する | IAM ロールを使用してポートフォリオとその中の製品へのアクセスを許可する場合、ロールには **servicecatalog.amazonaws.com**サービスプリンシパルが引き受ける権限が必要です。これらのアクセス権限を付与する方法については、[Service Catalog による信頼できるアクセスの有効化](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-servicecatalog.html#integrate-enable-ta-servicecatalog) (AWS Organizations ドキュメント) を参照してください。 | AWS DevOps、DevOps エンジニア |
| StackSets に必要な IAM ロールを設定します。 | StackSets を使用してターゲットアカウントに製品を自動的にプロビジョニングする場合は、スタックセットを管理および実行する IAM ロールを設定する必要があります。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-aws-service-catalog-portfolio-and-product-deployment-by-using-aws-cdk.html) | AWS DevOps、DevOps エンジニア |
### ソリューションのカスタマイズとデプロイ
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| CloudFormation テンプレートの準備 | この `config/templates` フォルダーで、ポートフォリオに含めたい製品の CloudFormation テンプレートを作成します。詳細については、[Working with AWS CloudFormation テンプレート](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-guide.html) (CloudFormation ドキュメント) を参照してください。 | アプリ開発者、AWS DevOps、DevOps エンジニア |
| 設定ファイルをカスタマイズします。 | `config` フォルダーで **config.json** ファイルを開き、ユースケースに適したパラメーターを定義します。特に明記されていない限り、以下のパラメータは必須です。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-aws-service-catalog-portfolio-and-product-deployment-by-using-aws-cdk.html)完成した設定ファイルの例については、[追加情報](#automate-aws-service-catalog-portfolio-and-product-deployment-by-using-aws-cdk-additional) セクションの*サンプル設定ファイル*を参照してください。 | アプリ開発者、AWS DevOps、DevOps エンジニア |
| ソリューションのデプロイ | 次のコマンドを入力します。これにより、AWS CDK アプリケーションがデプロイされ、**config.json** ファイルに指定されているService Catalog ポートフォリオと製品がプロビジョニングされます。sh +x setup.sh
| アプリ開発者、AWS DevOps、DevOps エンジニア |
| デプロイメントを確認する | 以下を実行して、デプロイが正常に完了したことを確認します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-aws-service-catalog-portfolio-and-product-deployment-by-using-aws-cdk.html) | AWS 全般 |
| (オプション) ポートフォリオと製品を更新します。 | このソリューションを使用してポートフォリオや製品を更新したり、新しい製品をプロビジョニングしたりする場合：[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-aws-service-catalog-portfolio-and-product-deployment-by-using-aws-cdk.html)たとえば、ポートフォリオを追加したり、リソースをさらにプロビジョニングできます。AWS CDK アプリケーションは変更のみを実装します。以前にデプロイしたポートフォリオや製品に変更がなければ、再デプロイしても影響はありません。 | アプリ開発者、AWS DevOps、DevOps エンジニア |
### ソリューションをクリーンアップする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| (オプション) このソリューションによってデプロイされた AWS リソースを削除します。 | プロビジョニング済み製品を削除する場合は、[プロビジョニング済み製品の削除](https://docs.aws.amazon.com/servicecatalog/latest/userguide/enduser-delete.html) (Service Catalog ドキュメント)の手順に従ってください。このソリューションで作成されたリソースをすべて削除する場合は、次のコマンドを入力します。sh uninstall.sh
| AWS DevOps、DevOps エンジニア |
## 関連リソース
+ [AWS Service Catalog コンストラクトライブラリ](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_servicecatalog-readme.html) (AWS API リファレンス)
+ [StackSets の概念](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-concepts.html) (CloudFormation ドキュメント)
+ [AWS Service Catalog](https://aws.amazon.com/servicecatalog) (AWS マーケティング)
+ [AWS CDK でのService Catalog の使用](https://catalog.us-east-1.prod.workshops.aws/workshops/d40750d7-a330-49be-9945-cde864610de9/en-US/4-builders-devs/sc-cdk) (AWS ワークショップ)
## 追加情報
**リポジトリをクローンします**
リポジトリのクローンを作成するには、次の コマンドを入力します。
```
git clone https://github.com/aws-samples/aws-cdk-servicecatalog-automation.git
```
**サンプル設定ファイル**
以下は、サンプル値を含む **config.json** ファイルのサンプルです。
```
{
"portfolios": [
{
"displayName": "EC2 Product Portfolio",
"providerName": "User1",
"description": "Test1",
"roles": [
""
],
"users": [
""
],
"groups": [
""
]
},
{
"displayName": "Autoscaling Product Portfolio",
"providerName": "User2",
"description": "Test2",
"roles": [
""
]
}
],
"tagOption": [
{
"key": "Group",
"value": [
"finance",
"engineering",
"marketing",
"research"
]
},
{
"key": "CostCenter",
"value": [
"01",
"02",
"03",
"04"
]
},
{
"key": "Environment",
"value": [
"dev",
"prod",
"stage"
]
}
],
"products": [
{
"portfolioName": "EC2 Product Profile",
"productName": "Ec2",
"owner": "owner1",
"productVersionName": "v1",
"templatePath": "../../config/templates/template1.json"
},
{
"portfolioName": "Autoscaling Product Profile",
"productName": "autoscaling",
"owner": "owner1",
"productVersionName": "v1",
"templatePath": "../../config/templates/template2.json",
"deployWithStackSets": {
"accounts": [
"012345678901",
],
"regions": [
"us-west-2"
],
"stackSetAdministrationRoleName": "AWSCloudFormationStackSetAdministrationRole",
"stackSetExecutionRoleName": "AWSCloudFormationStackSetExecutionRole"
}
}
]
}
```
# AWS Service Catalog と を使用して、Gitflow 環境にホットフィックスソリューションをデプロイするための動的パイプライン管理を自動化する AWS CodePipeline
*Amazon Web Services、Balaji Vedagiri、Faisal Shahdad、Shanmugam Shanker、Vivek Thangamuthu*
## 概要
**注記**
AWS CodeCommit は新規顧客には利用できなくなりました。の既存のお客様は、通常どおりサービスを AWS CodeCommit 引き続き使用できます。[詳細はこちら](https://aws.amazon.com/blogs/devops/how-to-migrate-your-aws-codecommit-repository-to-another-git-provider)
このパターンは、ホットフィックスソリューションの本番環境への安全なデプロイ専用の動的ホットフィックスパイプラインを管理するシナリオに対応します。このソリューションは、 AWS Service Catalog ポートフォリオと製品を使用して実装および管理されます。Amazon EventBridge ルールがイベントの自動化に使用されます。制限は、Service Catalog ポートフォリオの制約と開発者向けの AWS Identity and Access Management (IAM) ロールを使用して適用されます。EventBridge ルールによってトリガーされる Service Catalog 製品を起動できるのは、 AWS Lambda 関数のみです。このパターンは、「[追加情報](#automate-dynamic-pipeline-management-for-deploying-hotfix-solutions-additional)」で説明されている特定の Gitflow セットアップを使用する環境向けに設計されています。
通常、修正プログラムは、本番稼働環境などのライブ環境で報告された重大な問題やセキュリティ問題に対応するためにデプロイされます。ホットフィックスはステージング環境と本番環境にのみ直接デプロイする必要があります。ステージングパイプラインと本番パイプラインは、定期的な開発リクエストに広く使用されています。これらのパイプラインは、品質検証中の機能があり、本番環境に移行できないため、ホットフィックスのデプロイには使用できません。このパターンでは、ホットフィックスのリリース用として、次のセキュリティ機能を備えた、存続期間の短い動的パイプラインについて説明します。
+ **自動作成** — ホットフィックスブランチが AWS CodeCommit リポジトリに作成されるたびに、ホットフィックスパイプラインが自動的に作成されます。
+ **アクセス制限** – 開発者は、ホットフィックスプロセスの外でこのパイプラインを作成するためのアクセス権限がありません。
+ **制御されたステージ** – パイプラインには特別なアクセストークンを持つ制御されたステージがあり、プルリクエスト (PR) は 1 回しか作成できません。
+ **承認ステージ** – 関連するステークホルダーから必要な承認を得るため、承認ステージがパイプラインに含まれます。
+ **自動削除** – ホットフィックスパイプラインは、`hotfix` ブランチが PR とマージされた後、CodeCommit リポジトリから削除されるたびに自動的に削除されます。
## 前提条件と制限
**前提条件**
+ 次のように 3 つのアクティブな AWS アカウント が必要です。
+ ツールアカウント – 継続的インテグレーションと継続的デリバリー (CI/CD)
+ ステージアカウント – ユーザー承認テスト用。
+ 本番環境用アカウント – ビジネスエンドユーザー向け。
+ (オプション) QA アカウント AWS アカウント として機能する を追加します。このアカウントは、QA を含むメインパイプライン設定とテスト用のホットフィックスパイプラインソリューションの両方を希望する場合に必要です。
+ 必要に応じて、メインパイプラインを使用して QA アカウントにデプロイするオプションの条件を持つ AWS CloudFormation スタック。パターンは、`hotfix` ブランチを作成および削除することで、メインパイプラインのセットアップなしでテストできます。
+ Service Catalog 製品の作成に使用される CloudFormation テンプレートを保存する Amazon Simple Storage Service (Amazon S3) バケット。
+ コンプライアンス要件に従って CodeCommit リポジトリの PR 承認ルールを作成します (リポジトリの作成の後)。
+ 開発者とチームの IAM アクセス許可を制限して、[prcreation-lambda](https://github.com/aws-samples/dynamic_hotfix_codepipeline/blob/main/pre-requisites/lambdasetup.yaml#L55) Lambda 関数の実行を拒否します (この関数の呼び出しはパイプラインからのみとする必要があるため)。
**制限事項**
+ CloudFormation プロバイダーはデプロイステージで使用され、アプリケーションは CloudFormation 変更セットを使用してデプロイされます。別のデプロイオプションを使用する場合、必要に応じて CodePipeline スタックを変更します。
+ このパターンでは AWS CodeBuild 、 およびその他の設定ファイルを使用してサンプルマイクロサービスをデプロイします。別のワークロードタイプ (サーバーレスワークロードなど) を使用している場合は、関連する設定をすべて更新する必要があります。
+ このパターンでは、アプリケーションを単一の AWS リージョン (たとえば、米国東部 (バージニア北部) us-east-1) にデプロイします AWS アカウント。複数のリージョンにデプロイするには、コマンドとスタックでリージョンリファレンスを変更します。
+ 一部の 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)」を参照し、サービスのリンクを選択してください。
## アーキテクチャ
このセクションの図は、ライフサイクルイベント作成とライフサイクルイベント削除のワークフローを示しています。
![\[ライフサイクルイベント作成のワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/64311acc-8c0f-4734-aa1b-74345d86c752/images/3939f77c-4221-4c23-a3a1-3e8a294b2b32.png)
ライフサイクルイベント作成の前述の図は、以下を示しています。
1. 開発者は CodeCommit リポジトリに `hotfix-*` ブランチを作成して、ホットフィックス関連のソリューションを開発します。
1. `hotfix-*` ブランチ作成イベントは、EventBridge ルールを通じてキャプチャされます。イベントの詳細には、リポジトリ名およびブランチ名が含まれます。
1. EventBridge ルールは AWS Lambda 関数 を呼び出します`hotfix-lambda-function`。EventBridge ルールは、入力としてイベント情報を Lambda 関数に渡します。
1. Lambda 関数は入力を処理してリポジトリ名とブランチ名を取得します。処理された入力から取得した値を使用して Service Catalog 製品を起動します。
1. Service Catalog 製品には、ソリューションをステージ環境と本番環境にデプロイするパイプライン設定が含まれています。パイプラインブロックには、ソース、ビルド、デプロイの各ステージが含まれます。また、本番環境のデプロイを昇格させる手動承認ステージもあります。
1. ソースステージは、最初のステップで作成されたリポジトリと `hotfix-*` ブランチからコードを取得します。コードは、アーティファクト用の Amazon S3 バケットを介してビルドステージに渡されます。ビルドステージでは、`hotfix-*` ブランチで開発され、Amazon Elastic Container Registry (Amazon ECR) にプッシュされるホットフィックスを含むコンテナイメージが作成されます。
1. ステージ環境へのデプロイステージでは、ホットフィックスを含む最新のコンテナイメージで Amazon Elastic Container Service (Amazon ECS) が更新されます。ホットフィックスは、CloudFormation 変更セットを作成して実行することでデプロイされます。
1. `prcreation-lambda` Lambda 関数は、ステージ環境で正常にデプロイされた後に呼び出されます。この Lambda 関数は、`hotfix-*` ブランチからリポジトリの `develop` および `main` ブランチに PR を作成します。Lambda 関数は、`hotfix-*` ブランチで開発された修正がバックマージされ、後続のデプロイに含まれるようにします。
1. 手動承認ステージは、必要なステークホルダーが修正を確認し、本番環境にデプロイするための承認を与えるのに役立ちます。
1. 本番環境へのデプロイステージでは、ホットフィックスを含む最新のコンテナイメージで Amazon ECS が更新されます。ホットフィックスは、CloudFormation 変更セットを作成して実行することでデプロイされます。
![\[ライフサイクルイベントを削除するワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/64311acc-8c0f-4734-aa1b-74345d86c752/images/192aa897-bd9b-4a9f-804e-340371612b3b.png)
ライフサイクルイベント削除の前述の図は、以下を示しています。
1. 開発者は、ホットフィックスを本番環境に正常にデプロイした後、`hotfix-*` ブランチを削除します。
1. `hotfix-*` ブランチ削除イベントは、EventBridge ルールを通じてキャプチャされます。イベントの詳細には、リポジトリ名およびブランチ名が含まれます。
1. EventBridge ルールは、Lambda 関数を呼び出します。EventBridge ルールは、入力としてイベント情報を Lambda 関数に渡します。
1. Lambda 関数は入力を処理してリポジトリ名とブランチ名を取得します。Lambda 関数は、渡された入力からそれぞれの Service Catalog 製品を決定し、製品を終了します。
1. Service Catalog でプロビジョニングされた製品が終了すると、その製品で以前に作成されたパイプラインおよび関連リソースが削除されます。
**自動化とスケール**
+ このパターンには、EventBridge ルールと Lambda 関数が含まれており、複数の修正ブランチの作成リクエストに並行して対応できます。Lambda 関数は、一致するイベントルール向けの Service Catalog 製品をプロビジョニングします。
+ パイプラインのセットアップは、バージョン管理機能を提供する Service Catalog 製品を使用して対応されます。また、このソリューションは、同じアプリケーションの複数の修正プログラム開発に並行して対応するように自動的にスケーリングされます。
+ [prcreation-lambda](https://github.com/aws-samples/dynamic_hotfix_codepipeline/blob/main/pre-requisites/lambdasetup.yaml#L55) 関数を使用すると、これらのホットフィックスの変更も自動プルリクエストの作成を通じて `main` と `develop` ブランチにマージされます。このアプローチは、`main` と `develop` ブランチをすべての修正で最新の状態に保ち、潜在的なコードリグレッションを回避するために不可欠です。このプロセスは、存続期間の長いすべてのブランチに最新の修正を適用することで、ブランチ間の一貫性を維持し、コードのリグレッションを防ぐのに役立ちます。
## ツール
**AWS のサービス**
+ [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) は、 AWS リソースの設定、迅速かつ一貫したプロビジョニング、および AWS アカウント 全体にわたるライフサイクル全体の管理に役立ちます AWS リージョン。
+ [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) は完全マネージド型の構築サービスです。ソースコードのコンパイル、ユニットテストの実行、すぐにデプロイできるアーティファクトの生成を行います。
+ [AWS CodeCommit](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html) は、独自のソースコントロールシステムを管理しなくても、Git リポジトリを非公開で保存および管理できるバージョン管理サービスです。新規のお客様への AWS CodeCommit の提供は終了しました。の既存のお客様は、通常どおりサービスを AWS CodeCommit 引き続き使用できます。詳細については、[AWS CodeCommit 「リポジトリを別の Git プロバイダーに移行する方法](https://aws.amazon.com/blogs/devops/how-to-migrate-your-aws-codecommit-repository-to-another-git-provider/)」を参照してください。
+ [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) は、ソフトウェアリリースのさまざまな段階を迅速にモデル化および設定し、ソフトウェアの変更を継続的にリリースするために必要なステップを自動化するのに役立ちます。
+ 「[Amazon Elastic Container Registry (Amazon ECR)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html)」 は、セキュリティ、スケーラビリティ、信頼性を備えたマネージドコンテナイメージレジストリサービスです。
+ 「[Amazon Elastic Container Service (Amazon ECS)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html)」 は、クラスターでのコンテナの実行、停止、管理を支援する、高速でスケーラブルなコンテナ管理サービスです。
+ [AWS Key Management Service (AWS KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) は、データの保護に役立つ暗号化キーの作成と制御に役立ちます。
+ [AWS Service Catalog](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/introduction.html) では、承認された IT サービスのカタログを一元管理できます AWS。エンドユーザーは、組織によって設定された制約に従って、必要な承認済みの IT サービスのみをすばやくデプロイできます。
+ [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) は、あらゆる量のデータを保存、保護、取得できるクラウドベースのオブジェクトストレージサービスです。
**その他のツール**
+ [CloudFormation Linter (cfn-lint)](https://github.com/aws-cloudformation/cfn-lint) は、CloudFormation YAML または JSON テンプレートを [CloudFormation リソース仕様](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-resource-specification.html)と照合する linter です。また、リソースプロパティの有効な値の確認やベストプラクティスの遵守などの他のチェックも実行します。
+ [cfn\$1nag](https://github.com/stelligent/cfn_nag) は、CloudFormation テンプレートのパターンを探して潜在的なセキュリティ問題を特定するオープンソースツールです。
+ 「[Docker](https://www.docker.com/)」は、オペレーティングシステムレベルの仮想化を使用してソフトウェアをコンテナで配信するPlatform as a Service (PaaS) 製品のセットです。このパターンでは、Docker でコンテナイメージをローカルでビルドしてテストします。
+ [Git](https://git-scm.com/docs) はオープンソースの分散バージョンの管理システムです。
**コードリポジトリ**
このパターンのコードは、GitHub [dynamic\$1hotfix\$1codepipeline](https://github.com/aws-samples/dynamic_hotfix_codepipeline) リポジトリにあります。
## ベストプラクティス
環境内の IAM ロールとサービスコントロールポリシー (SCP) を確認および調整し、アクセスが適切に制限されていることを確認します。これは、このパターンに含まれるセキュリティ対策を上書きする可能性のあるアクションを防ぐために重要です。最小特権の原則に従い、タスクの実行に必要な最小限の権限を付与します。詳細については、IAM ドキュメントの「[最小限の特権を認める。](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#grant-least-priv)」と「[IAM でのセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)」を参照してください。
## エピック
### 作業環境の設定
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| リポジトリのクローン作成 | サンプル[リポジトリ](https://github.com/aws-samples/dynamic_hotfix_codepipeline)を作業場所の新しいディレクトリにクローンするには、次のコマンドを実行します。git clone git@github.com:aws-samples/dynamic_hotfix_codepipeline.git
| AWS DevOps |
| CloudFormation スタックデプロイ用の環境変数を出力します。 | このパターンの後半で CloudFormation スタックへの入力として使用する次の環境変数を定義します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-dynamic-pipeline-management-for-deploying-hotfix-solutions.html)export BucketStartName=
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-dynamic-pipeline-management-for-deploying-hotfix-solutions.html)export ProdAccount=
export StageAccount=
export QAAccount=
export ToolsAccount=
export DepRegion=
| AWS DevOps |
### で必要な前提条件を設定する AWS アカウント
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| ツールアカウントで CI/CD に必要なリソースを作成します。 | ツールアカウントに CloudFormation スタックをデプロイするには、次のコマンドを使用します。(セットアップに QA アカウントを使用していない場合は、`QAAccount` パラメータを削除します)。#InToolsAccount
aws cloudformation deploy \
--template-file pre-requisites/pre-reqs.yaml \
--stack-name prereqs \
--parameter-overrides BucketStartName=${BucketStartName} \
ApplicationName=${ApplicationName} ProdAccount=${ProdAccount} \
StageAccount=${StageAccount} ToolsAccount=${ToolsAccount} \
QAAccount=${QAAccount} \
--capabilities CAPABILITY_IAM CAPABILITY_NAMED_IAM --region ${DepRegion}
CodeCommit リポジトリと Amazon ECR が前のスタックから作成したリソースを書き留めておきます。これらのパラメータは、次のステップでパイプラインの `main` ブランチをセットアップするために必要です。 | AWS DevOps |
| ワークロードアカウントで CI/CD に必要なリソースを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-dynamic-pipeline-management-for-deploying-hotfix-solutions.html) | AWS DevOps |
| S3 アーティファクトバケットポリシーを更新して、ワークロードアカウントへのアクセスを許可します。 | ツールアカウント内の CloudFormation スタックの前提条件を更新するには、次のコマンドを使用して、ステージおよび本番ワークロードアカウントに必要なすべてのアクセス許可を追加します。(セットアップに使用していない場合は、`QAAccount` パラメータを削除します)。#InToolsAccount
aws cloudformation deploy \
--template-file pre-requisites/pre-reqs.yaml \
--stack-name prereqs \
--parameter-overrides BucketStartName=${BucketStartName} \
ApplicationName=${ApplicationName} ProdAccount=${ProdAccount} \
StageAccount=${StageAccount} ToolsAccount=${ToolsAccount} \
QAAccount=${QAAccount} PutPolicy=true \
--capabilities CAPABILITY_IAM CAPABILITY_NAMED_IAM --region ${DepRegion}
| AWS DevOps |
### ツールアカウントで Lambda 関数と Service Catalog リソースを設定する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| Service Catalog ポートフォリオと製品をセットアップします。 | Service Catalog ポートフォリオと製品をセットアップするには、以下を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-dynamic-pipeline-management-for-deploying-hotfix-solutions.html) | AWS DevOps |
| Lambda 関数をセットアップします。 | このソリューションでは、次の Lambda 関数を使用してホットフィックスワークフローを管理します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-dynamic-pipeline-management-for-deploying-hotfix-solutions.html)`hotfix ` ブランチが関連する EventBridge ルールによって作成または削除されたときに、Lambda 関数が Service Catalog 製品をプロビジョニングおよび終了できるようにするには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-dynamic-pipeline-management-for-deploying-hotfix-solutions.html) | AWS DevOps |
### main ブランチのパイプラインを作成し、ワークロードアカウントにアプリケーションをデプロイする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| `main` ブランチのパイプラインを設定します。 | メインブランチのパイプラインを設定するには、ツールアカウントで次のコマンドを実行します。`MainProductId` および `servicecatalogsetup` のパラメータを `MainProductArtifactId` スタック出力の値に置き換えます。#InToolsAccount
aws servicecatalog provision-product \
--product-id \
--provisioning-artifact-id \
--provisioned-product-name "${ApplicationName}-main-pipeline" \
--provisioning-parameters Key=CodeCommitRepoName,Value="${ApplicationName}-repository" Key=ECRRepository,Value="${ApplicationName}-app" \
--region=${DepRegion}
| AWS DevOps |
| `main` ブランチを使用してアプリケーションをデプロイします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-dynamic-pipeline-management-for-deploying-hotfix-solutions.html) | AWS DevOps |
### hotfix-\$1 ブランチのパイプラインを作成し、ホットフィックスをデプロイする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| `hotfix-*` ブランチを作成し、変更をコミットします。 | `hotfix-*` ブランチのパイプラインを作成し、ワークロードアカウントにホットフィックスをデプロイするには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-dynamic-pipeline-management-for-deploying-hotfix-solutions.html) | AWS DevOps |
| `hotfix-check1` ブランチを削除する | 前に作成した `hotfix-check1` ブランチを削除するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-dynamic-pipeline-management-for-deploying-hotfix-solutions.html) | AWS DevOps |
### リソースをクリーンアップする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| デプロイされたリソースをクリーンアップします。 | 以前にデプロイされたリソースをクリーンアップするには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-dynamic-pipeline-management-for-deploying-hotfix-solutions.html)##In Tools Account##
aws cloudformation delete-stack --stack-name servicecatalogsetup --region ${DepRegion}
aws cloudformation delete-stack --stack-name prlambdasetup --region ${DepRegion}
aws cloudformation delete-stack --stack-name prereqs --region ${DepRegion}
##In Workload Accounts##
aws cloudformation delete-stack --stack-name inframainstack --region ${DepRegion}
詳細については、Service Catalog ドキュメントの「[Deleting provisioned products](https://docs.aws.amazon.com/servicecatalog/latest/userguide/enduser-delete.html)」を参照してください。 | AWS DevOps |
## トラブルシューティング
| 問題 | ソリューション |
| --- | --- |
| CodeCommit リポジトリにコミットした変更はデプロイされません。 | CodeBuild ログに Docker ビルド操作のエラーがないか確認します。詳細については、「[CodeBuild のドキュメント](https://docs.aws.amazon.com/codebuild/latest/userguide/troubleshooting.html)」を参照してください。 |
| Service Catalog 製品はプロビジョニングされていません。 | 関連する CloudFormation スタックで失敗したイベントを確認します。詳細については、「[CloudFormation のドキュメント](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/troubleshooting.html)」を参照してください。 |
## 関連リソース
+ [基本的な Git コマンド](https://docs.aws.amazon.com/codecommit/latest/userguide/how-to-basic-git.html)
+ [ブランチへのプッシュとマージを制限するように IAM ポリシーを設定する](https://docs.aws.amazon.com/codecommit/latest/userguide/how-to-conditional-branch.html#how-to-conditional-branch-create-policy)
+ [AWS CodeCommit リポジトリに接続する](https://docs.aws.amazon.com/codecommit/latest/userguide/how-to-connect.html)
+ [ユーザーへのアクセス権限の付与](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/catalogs_portfolios_users.html)
+ [Docker イメージを Amazon ECR プライベートリポジトリにプッシュする](https://docs.aws.amazon.com/AmazonECR/latest/userguide/docker-push-ecr-image.html)
+ [トラブルシューティング AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/troubleshooting.html)
+ [とは AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)
## 追加情報
このパターンは、CI/CD プロセスの開発ワークフローに採用された Gitflow セットアップ環境向けに設計されています。パイプラインは、開発から始まり、品質保証 (QA)、ステージ、本番環境を通過するデプロイサイクルに従います。CI/CD セットアップには、次のように環境への昇格デプロイを含む 2 つの git ブランチが含まれています。
+ `develop` ブランチは開発環境にデプロイされます。
+ `main` ブランチは、QA、ステージ、本番環境にデプロイされます。
この設定では、新機能のアクティブな開発の進行中に、通常のデプロイサイクルよりも早くホットフィックスまたはセキュリティパッチを適用することが課題になります。修正プログラムやセキュリティリクエストに対処し、本番環境の適切な機能と安全性を確実に維持するには、専用のプロセスが必要です。
ただし、以下の場合は専用のデプロイプロセスを必要とせずに、使用可能な他のオプションを使用できます。
+ CI/CD プロセスは、機能テストやエンドツーエンドテストなどの自動テストを備えているため、手動テストが不要になり、本番環境へのデプロイの遅延を防ぐことができます。ただし、自動テストが CI/CD プロセスに適切に統合されていない場合、本番環境に小規模の修正をプッシュすると、開発者側の作業が複雑化し、手間が増えてしまう可能性があります。これは、QA 環境で承認とサインオフを待機する新機能が存在する可能性があるためです。修正プログラムまたはセキュリティ修正プログラムを同時に本番環境にプッシュすることはできません。
+ 開発チームは、新しい機能を本番環境に継続的にデプロイし、各新機能のスケジュールされたデプロイにホットフィックスまたはセキュリティパッチを統合します。つまり、本番環境への次の機能更新は、新機能の追加と、修正プログラムまたはセキュリティパッチの追加の 2 つの要素で構成されます。ただし、デプロイサイクルが連続していない場合は、QA 環境で承認を待機する複数の新機能が既に存在する可能性があります。異なるバージョンを管理し、正しい変更が再適用されるようにした場合、作業が複雑になり、エラーが発生しやすくなります。
**注記**
`hotfix` バージョン [2 ](https://docs.aws.amazon.com/codepipeline/latest/userguide/pipeline-types.html#:~:text=V2%20type%20pipelines%20have%20the%20same%20structure)を使用してブランチに AWS CodePipeline 適切なトリガーを設定している場合は、予定外のリクエストに対応するための専用プロセスが必要です。バージョン 2 では、プッシュリクエストまたはプルリクエストのトリガーを設定できます。実行は、パイプラインの以前の状態に応じて、キューに入れられるかすぐに実行されます。ただし、専用パイプラインでは、修正がすぐに本番環境に適用され、緊急の問題が遅滞なく解決されます。
# AWS CloudFormation スタックと関連リソースの削除を自動化する
*SANDEEP SINGH および James Jacob、Amazon Web Services*
## 概要
[AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) は、クラウド Infrastructure as Code (IaC) を管理するために広く使用されているサービスです。CloudFormation を使用する際、関連リソースは*スタック*と呼ばれる単一のユニットとして管理します。スタックを作成、更新、削除することで、リソースのコレクションを作成、更新、削除します。
CloudFormation スタック内のリソースが不要になる場合があります。リソースとその設定によっては、スタックとその関連リソースの削除が複雑になる場合があります。実際の実稼働システムでは、CloudFormation が上書きできない競合する条件や制限により、削除が失敗する場合や、削除に長時間を要する場合があります。すべてのリソースが効率的かつ一貫した方法で適切に削除されるように、慎重な計画と実行が必要になることがあります。このパターンでは、以下のような複雑さを伴う CloudFormation スタックの削除を管理するのに役立つフレームワークを設定する方法について説明します。
+ **削除保護を持つリソース** – 一部のリソースでは、削除保護が有効になっている場合があります。一般的な例としては、[Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html) テーブルと [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) バケットがあります。削除保護は、CloudFormation による削除などの自動削除を防止します。これらのリソースを削除する場合、手動で、またはプログラムで削除保護を上書きまたは一時的に無効にする必要があります。先に進む前に、これらのリソースを削除する意味を慎重に検討する必要があります。
+ **保持ポリシーを持つリソース** – AWS Key Management Service (AWS KMS) キーや Amazon S3 バケットなどの特定のリソースには、削除がリクエストされた後に保持する期間を指定する保持ポリシーがある場合があります。組織のポリシーと規制要件への準拠を維持するため、クリーンアップ戦略でこれらのポリシーを考慮する必要があります。
+ **VPC にアタッチされている Lambda 関数の遅延削除** – 仮想プライベートクラウド (VPC) にアタッチされている [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) 関数の削除には、プロセスに関連する相互接続された複数の依存関係に応じて、5～40 分が必要になります。スタックを削除する前に VPC から関数をデタッチすると、この遅延を 1 分未満まで短縮できます。
+ **CloudFormation によって直接作成されていないリソース** – 特定のアプリケーション設計では、アプリケーション自体によって、またはスタックを介してプロビジョニングされたリソースによって、リソースが元の CloudFormation スタックの外部に作成される場合があります。以下に 2 つの例を示します。
+ CloudFormation では、ユーザーデータスクリプトを実行する [Amazon Elastic Compute Cloud (Amazon EC2)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts.html) インスタンスをプロビジョニングする場合があります。その後、このスクリプトはアプリケーション関連のデータを保存するための [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html) パラメータを作成する場合があります。このパラメータは CloudFormation では管理されません。
+ CloudFormation では、ログを保存するための [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) グループを自動的に生成する Lambda 関数をプロビジョニングする場合があります。このロググループは CloudFormation では管理されません。
これらのリソースは CloudFormation によって直接管理されることはありませんが、多くの場合スタックが削除されたときにクリーンアップする必要があります。管理対象外のままにしておくと孤立状態となり、不要なリソース消費につながる可能性があります。
これらのガードレールにより作業が煩雑化する可能性はありますが、これは重要度が高く意図的な仕様です。CloudFormation がすべての制約を上書きし、リソースを無差別に削除できるようにすると、多くのシナリオで有害で予期しない結果が生じる可能性があります。ただし、環境の管理を担当する DevOps またはクラウドエンジニアは、特に開発、テスト、またはステージング環境では、これらの制約を上書きする必要がある場合があります。
**ターゲットを絞ったビジネス成果**
このフレームワークを実装すると、次の利点を実現できます。
+ **コスト管理** – エンドツーエンドのテスト環境やユーザー受け入れテスト環境など、一時的な環境を定期的に効率的にクリーンアップすることで、リソースが必要以上に長く実行されないようにします。これにより、コストを大幅に削減できます。
+ **セキュリティ** – 古いリソースや未使用のリソースの自動クリーンアップは、攻撃対象領域を減らし、安全な AWS 環境を維持するのに役立ちます。
+ **運用効率** – 定期クリーンアップと自動クリーンアップには、次の運用上の利点があります。
+ 古いロググループまたは空の Amazon S3 バケットを削除する自動スクリプトは、環境をクリーンで管理しやすいようにすることで、運用効率を向上させることができます。
+ スタックを迅速に削除して再作成すると、設計と実装のための迅速なイテレーションが可能になるため、アーキテクチャの堅牢性と回復性が向上する可能性があります。
+ 環境を定期的に削除および再構築すると、潜在的な問題を特定して修正するのに役立ちます。これにより、インフラストラクチャが現実のシナリオに耐えることができます。
## 前提条件と制限
**前提条件**
+ アクティブな AWS アカウント
+ Python バージョン 3.6 以降が[インストールされている](https://www.python.org/downloads/)
+ AWS Command Line Interface (AWS CLI)、[インストール](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)および[設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html)済み
**制限事項**
+ 命名規則は、削除するリソースを識別するために使用されます。このパターンのサンプルコードでは、リソース名のプレフィックスが使用されますが、独自の命名規則を定義できます。この命名規則を使用しないリソースは識別されず、その後も削除されません。
## アーキテクチャ
次の図は、このフレームワークがターゲット CloudFormation スタックとそれに関連付けられた追加のリソースをどのように識別するかを示しています。
![\[CloudFormation スタックおよび関連するリソースを検出、処理、削除するフェーズ。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/ab7c3b56-3476-41a3-8ece-68915605a546/images/a7fceb1c-d624-47b3-957d-f910ef2f44d7.png)
この図表は、次のワークフローを示しています:
1. **リソースの収集** – 自動化フレームワークでは命名規則を使用して、関連するすべての CloudFormation スタック、Amazon Elastic Container Registry (Amazon ECR) リポジトリ、DynamoDB テーブル、Amazon S3 バケットを返します。
**注記**
このステージの関数では、切り捨てられた API 結果セットを反復するプロセスを抽象化する Boto3 の機能である[ページネーター](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/paginators.html)が使用されます。これにより、すべてのリソースが確実に処理されます。パフォーマンスをさらに最適化するには、[サーバー側の](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/paginators.html#filtering-results)フィルタリングを適用するか、JMESPath を使用して[クライアント側の](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/paginators.html#filtering-results-with-jmespath)フィルタリングの実行を検討してください。
1. **前処理** – 自動化フレームワークは、CloudFormation がリソースを削除できるようにするために上書きする必要があるサービス制約を特定して対応します。例えば、DynamoDB テーブルの `DeletionProtectionEnabled` 設定を `False` に変更します。コマンドラインインターフェイスでは、リソースごとに制約を上書きするかどうか確認するプロンプトが表示されます。
1. **スタックの削除** – 自動化フレームワークは CloudFormation スタックを削除します。コマンドラインインターフェイスで、スタックを削除するかどうかを確認するプロンプトが表示されます。
1. **後処理** – 自動化フレームワークが、スタックの一部として CloudFormation から直接プロビジョニングされなかった関連リソースをすべて削除します。これらのリソースタイプの例には、Systems Manager パラメータおよび CloudWatch ロググループが含まれます。個別の関数は、これらのリソースを収集し、前処理してから削除します。コマンドラインインターフェイスでは、リソースごとにリソースを削除するかどうかを確認するプロンプトが表示されます。
**注記**
このステージの関数では、切り捨てられた API 結果セットを反復するプロセスを抽象化する Boto3 の機能である[ページネーター](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/paginators.html)が使用されます。これにより、すべてのリソースが確実に処理されます。パフォーマンスをさらに最適化するには、[サーバー側の](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/paginators.html#filtering-results)フィルタリングを適用するか、JMESPath を使用して[クライアント側の](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/paginators.html#filtering-results-with-jmespath)フィルタリングの実行を検討してください。
**自動化とスケール**
CloudFormation スタックにサンプルコードに含まれていない他のリソースが含まれている場合、またはスタックにこのパターンで対処されていない制約がある場合、ユースケースに合わせて自動化フレームワークを適応させることができます。リソースの収集、前処理、スタックの削除、後処理と同じ手法に従います。
## ツール
**AWS のサービス**
+ [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) は、 AWS リソースをセットアップし、迅速かつ一貫してプロビジョニングし、 AWS アカウント および 全体のライフサイクルを通じてリソースを管理するのに役立ちます AWS リージョン。
+ [CloudFormation コマンドラインインターフェイス (CFN-CLI) ](https://docs.aws.amazon.com/cloudformation-cli/latest/userguide/what-is-cloudformation-cli.html)は、 AWS およびサードパーティーの拡張機能を開発およびテストし、CloudFormation で使用するために登録するのに役立つオープンソースツールです。
+ [AWS SDK for Python (Boto3)](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/quickstart.html) は、Python アプリケーション、ライブラリ、またはスクリプトを と統合するのに役立つソフトウェア開発キットです AWS のサービス。
**その他のツール**
+ [Click](https://click.palletsprojects.com/en/stable/) は、コマンドラインインターフェイスの作成に役立つ Python ツールです。
+ [Poetry](https://python-poetry.org/docs/) は、Python での依存関係管理とパッケージングのためのツールです。
+ [Pyenv](https://github.com/pyenv/pyenv) は、Python のバージョンを管理および切り替えるのに役立つツールです。
+ 「[Python](https://www.python.org/)」は汎用のコンピュータプログラミング言語です。
**コードリポジトリ**
このパターンのコードは、GitHub 内の「[cloudformation-stack-cleanup](https://github.com/aws-samples/cloudformation-stack-cleanup/)」リポジトリで利用できます。
## ベストプラクティス
+ **識別しやすいようにリソースにタグを付ける** – [タグ付け戦略](https://aws.amazon.com/solutions/guidance/tagging-on-aws/)を実行して、さまざまな環境や目的で作成されたリソースを特定します。タグに基づいてリソースをフィルタリングするのに役立つため、クリーンアッププロセスを簡素化できます。
+ **リソースライフサイクルの設定** – 一定期間後にリソースを自動的に削除するために、リソースライフサイクルを定義します。この手法は、一時的な環境が永続的なコスト負担にならないようにするのに役立ちます。
## エピック
### ツールをインストールする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| リポジトリのクローン作成 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-deletion-cloudformation-stacks-associated-resources.html) | DevOps エンジニア |
| Poetry をインストールします。 | [手順](https://python-poetry.org/docs/) (Poetry ドキュメント) に従い、ターゲット仮想環境に Poetry をインストールします。 | DevOps エンジニア |
| 依存関係をインストールします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-deletion-cloudformation-stacks-associated-resources.html) | DevOps エンジニア |
| (オプション) Pyenv をインストールします。 | [手順](https://github.com/pyenv/pyenv#installation) (GitHub) に従って Pyenv をインストールします。 | DevOps エンジニア |
### (オプション) フレームワークをカスタマイズする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| ターゲットリソースを収集、前処理、削除する関数を作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-deletion-cloudformation-stacks-associated-resources.html) | DevOps エンジニア、Python |
### サンプルリソースを作成する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| CloudFormation スタックを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-deletion-cloudformation-stacks-associated-resources.html) | AWS DevOps |
| Systems Manager パラメータを作成します。 | 次のコマンドを入力し、CloudFormation を介してプロビジョニングされない Systems Manager パラメータを作成します。aws ssm put-parameter \
--name "/sampleforcleanup/database/password" \
--value "your_db_password" \
--type "SecureString" \
--description "Database password for my app" \
--tier "Standard" \
--region "us-east-1"
| AWS DevOps |
| Amazon S3 バケットを作成する。 | 次のコマンドを入力し、CloudFormation を介してプロビジョニングされない Amazon S3 バケットを作成します。aws s3api create-bucket \
--bucket samplesorcleanup-unmanagedbucket- \
--region us-east-1 \
--create-bucket-configuration LocationConstraint=us-east-1
| AWS DevOps |
### サンプルリソースを削除する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| CloudFormation スタックを削除します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-deletion-cloudformation-stacks-associated-resources.html) | AWS DevOps |
| リソースの削除を検証します。 | 出力で、すべてのサンプルリソースが削除されていることを確認します。出力例については、このパターンの[追加リソース](#automate-deletion-cloudformation-stacks-associated-resources-additional)のセクションを参照してください。 | AWS DevOps |
## 関連リソース
+ [スタックを削除する](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-delete-stack.html) (CloudFormation ドキュメント)
+ [CloudFormation のトラブルシューティング](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/troubleshooting.html) (CloudFormation ドキュメント)
+ [Lambda 関数に Amazon VPC 内のリソースへのアクセスを許可する](https://docs.aws.amazon.com/lambda/latest/dg/configuration-vpc.html) (Lambda ドキュメント)
+ [DELETE\$1FAILED ステータスのままになっている AWS CloudFormation スタックを削除するにはどうすればよいですか?](https://repost.aws/knowledge-center/cloudformation-stack-delete-failed) (AWS ナレッジセンター)
## 追加情報
以下は、`cfncli` コマンドからの出力例です。
```
cfncli --region aus-east-1 dev cleanup-env --prefix-list sampleforcleanup
https://sts.us-east-1.amazonaws.com
Cleaning up: ['sampleforcleanup'] in xxxxxxxxxx:us-east-1
Do you want to proceed? [Y/n]: Y
No S3 buckets
No ECR repositories
No Lambda functions in VPC
The following DynamoDB tables will have their deletion protection removed:
sampleforcleanup-MyDynamoDBTable
Do you want to proceed with removing deletion protection from these tables? [Y/n]: Y
Deletion protection disabled for DynamoDB table 'sampleforcleanup-MyDynamoDBTable'.
The following CloudFormation stacks will be deleted:
sampleforcleanup-Stack
Do you want to proceed with deleting these CloudFormation stacks? [Y/n]: Y
Initiated deletion of CloudFormation stack: `sampleforcleanup-Stack`
Waiting for stack `sampleforcleanup-Stack` to be deleted...
CloudFormation stack `sampleforcleanup-Stack` deleted successfully.
The following ssm_params will be deleted:
/sampleforcleanup/database/password
Do you want to proceed with deleting these ssm_params? [Y/n]: Y
Deleted SSM Parameter: /sampleforcleanup/database/password
Cleaned up: ['sampleforcleanup']
```
# Terraform を使用して Amazon Managed Grafana での Amazon MWAA カスタムメトリクスの取り込みと視覚化を自動化する
*Faisal Abdullah、Satya Vajrapu (Amazon Web Services)*
## 概要
このパターンでは、Amazon Managed Grafana を使用して、Amazon Managed Workflows for Apache Airflow (Amazon MWAA) によって取り込まれるカスタムメトリクスを作成およびモニタリングする方法を説明します。Amazon MWAA はワークフローのオーケストレーターとして機能し、Python でスクリプト化された有向非巡回グラフ (DAG) を使用します。このパターンは、過去 1 時間以内に実行 DAG の合計数、1 時間あたりの合格および不合格の DAG の数、これらのプロセスの平均期間など、カスタムメトリクスのモニタリングに焦点を当てています。この分析は、Amazon Managed Grafana を Amazon MWAA と統合して、この環境内のワークフローのオーケストレーションに関する包括的なモニタリングとインサイトを実現する方法を示しています。
## 前提条件と制限
**前提条件**
+ 以下を作成および管理するために必要なユーザーアクセス許可 AWS アカウント を持つアクティブな AWS のサービス。
+ AWS Identity and Access Management (IAM) ロールとポリシー
+ AWS Lambda
+ Amazon Managed Grafana
+ Amazon Managed Workflows for Apache Airflow (Amazon MWAA)
+ Amazon Simple Storage Service (Amazon S3)
+ Amazon Timestream
+ ローカルマシンまたは [AWS CloudShell](https://docs.aws.amazon.com/cloudshell/latest/userguide/welcome.html) のターミナルであるシェル環境へのアクセス。
+ Git がインストールされ、最新バージョンの AWS Command Line Interface (AWS CLI) がインストールされ、設定されているシェル環境。詳細については、 AWS CLI ドキュメントの[「 の最新バージョンのインストールまたは更新 AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)」を参照してください。
+ Terraform `required_version = ">= 1.6.1, < 2.0.0"` バージョンがインストール済み。[tfswitch](https://tfswitch.warrensbox.com/) を使用して、Terraform の異なるバージョンを切り替えることができます。
+ AWS IAM アイデンティティセンター 用に で設定された ID ソース AWS アカウント。詳細については、IAM Identity Center ドキュメントの「[Confirm your identity sources in IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/prereq-identity-sources.html)」を参照してください。デフォルト IAM アイデンティティセンターディレクトリ、Active Directory、または Okta などの外部 ID プロバイダー (IdP) から選択できます。詳細については、「[関連リソース](#automate-ingestion-and-visualization-of-amazon-mwaa-custom-metrics-resources)」を参照してください。
**制限事項**
+ 一部の AWS のサービス は では使用できません AWS リージョン。利用可能なリージョンについては、「[AWS のサービス (リージョン別)](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)」を参照してください。特定のエンドポイントについては、「[Service endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)」で、サービスのリンクを選択してご確認ください。
**製品バージョン**
+ Terraform `required_version = ">= 1.6.1, < 2.0.0"`
+ Amazon Managed Grafana バージョン 9.4 以降。このパターンはバージョン 9.4 でテストされました。
## アーキテクチャ
次のアーキテクチャ図は、ソリューション AWS のサービス で使用される を示しています。
![\[Amazon MWAA カスタムメトリクスの取り込みを自動化するワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/3458d0a9-aee1-428a-bf2f-c357bb531c64/images/b43ed8d2-94ac-4438-913b-81c7eba8f3e0.png)
前の図は、次のワークフローを段階的に示しています。
1. Amazon MWAA 内のカスタムメトリクスは、環境内で実行されている DAG から生成されます。メトリクスは、CSV ファイル形式で Amazon S3 バケットにアップロードされます。次の DAG は、Amazon MWAA のデータベースクエリ機能を使用します。
+ `run-example-dag` – この DAG には、1 つ以上のタスクを定義するサンプル Python コードが含まれています。7 分ごとに実行され、日付が出力されます。日付の表示後、DAG には、特定の期間の実行をスリープまたは一時停止するタスクが含まれます。
+ `other-sample-dag` – この DAG は 10 分ごとに実行され、日付を出力します。日付の表示後、DAG には、特定の期間の実行をスリープまたは一時停止するタスクが含まれます。
+ `data-extract` – この DAG は 1 時間ごとに実行され、Amazon MWAA データベースをクエリしてメトリクスを収集します。メトリクスが収集されると、この DAG はそれらを Amazon S3 バケットに書き込み、さらに処理と分析を行います。
1. データ処理を効率化するため、Lambda 関数は Amazon S3 イベントによってトリガーされたときに実行されるため、Timestream へのメトリクスのロードが容易になります。
1. Timestream は Amazon Managed Grafana 内のデータソースとして統合されており、Amazon MWAA のすべてのカスタムメトリクスが保存されます。
1. ユーザーはデータをクエリし、カスタムダッシュボードを構築することで、主要なパフォーマンス指標を視覚化し、Amazon MWAA 内のワークフローのオーケストレーションに関するインサイトを得ることができます。
## ツール
**AWS のサービス**
+ [AWS IAM アイデンティティセンター](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) を使用すると、すべての AWS アカウント およびクラウドアプリケーションへのシングルサインオン (SSO) アクセスを一元管理できます。
+ [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。このパターンでは、 は Amazon S3 イベントに応答して Python コード AWS Lambda を実行し、コンピューティングリソースを自動的に管理します。
+ [Amazon Managed Grafana](https://docs.aws.amazon.com/grafana/latest/userguide/what-is-Amazon-Managed-Service-Grafana.html) は、フルマネージド型データ可視化サービスであり、メトリクス、ログ、トレースを照会、関連付け、視覚化できます。このパターンでは、Amazon Managed Grafana を使用し、メトリクスの視覚化とアラートのためのダッシュボードを作成します。
+ [Amazon Managed Workflows for Apache Airflow (Amazon MWAA)](https://docs.aws.amazon.com/mwaa/latest/userguide/what-is-mwaa.html) は、Apache Airflow 用のマネージドオーケストレーションサービスで、クラウド上でデータパイプラインを大規模に設定、運用するために使用できます。[Apache Airflow](https://airflow.apache.org/) は、ワークフローと呼ばれる一連のプロセスとタスクをプログラムで作成、スケジュール、監視するために使用されるオープンソースのツールです。このパターンでは、サンプル DAG とメトリクスエクストラクタ DAG が Amazon MWAA にデプロイされます。
+ [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) は、あらゆる量のデータを保存、保護、取得できるクラウドベースのオブジェクトストレージサービスです。このパターンでは、Amazon S3 を使用して DAG、スクリプト、カスタムメトリクスを CSV 形式で保存します。
+ [Amazon Timestream for LiveAnalytics](https://docs.aws.amazon.com/timestream/latest/developerguide/what-is-timestream.html) は、高速でスケーラブルなフルマネージド型の専用時系列データベースで、1 日あたり何兆もの時系列データポイントの保存と分析を容易にします。また、LiveAnalytics の Timestream は、データ収集、視覚化、機械学習に一般的に使用されるサービスと統合されます。このパターンでは、生成された Amazon MWAA カスタムメトリクスを取り込むために使用されます。
**その他のツール**
+ [HashiCorp Terraform](https://www.terraform.io/docs) は、コードを使用してクラウドインフラストラクチャとリソースを割り当てて管理するのに役立つ Infrastructure as Code (IaC) ツールです。このパターンでは、Terraform モジュールを使用して AWSでのインフラストラクチャのプロビジョニングを自動化します。
**コードリポジトリ**
このパターンのコードは、GitHub の [visualize-amazon-mwaa-custom-metrics-grafana](https://github.com/aws-samples/visualize-amazon-mwaa-custom-metrics-grafana) リポジトリで入手できます。`stacks/Infra` フォルダには以下が含まれています。
+ すべての AWS リソースの Terraform 設定ファイル
+ `grafana` フォルダ内の Grafana ダッシュボード .json ファイル
+ `mwaa/dags` フォルダ内の Amazon Managed Workflows for Apache Airflow DAG
+ .csv ファイルを解析し、メトリクスを `src` フォルダの Timestream データベースに保存するための Lambda コード
+ `templates` フォルダ内の IAM ポリシー .json ファイル
## ベストプラクティス
Terraform は、実際のリソースを設定にマッピングできるよう、マネージドインフラストラクチャと設定に関する状態を保存する必要があります。デフォルトでは、Terraform は `terraform.tfstate` という名前のファイルに状態をローカルに保存します。インフラストラクチャの現在の状態が維持されるため、Terraform 状態ファイルの安全性と整合性を確保することが重要です。詳細については、Terraform ドキュメントの「[Remote State](https://developer.hashicorp.com/terraform/language/state/remote)」を参照してください。
## エピック
### Terraform を使用してインフラストラクチャをデプロイする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| インフラストラクチャを準備します。 | ソリューションインフラストラクチャをデプロイするには、次を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-ingestion-and-visualization-of-amazon-mwaa-custom-metrics.html) | AWS DevOps |
### デプロイされたインフラストラクチャリソースを検証する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| Amazon MWAA 環境を検証する | Amazon MWAA 環境を検証するには、次を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-ingestion-and-visualization-of-amazon-mwaa-custom-metrics.html) | AWS DevOps、データエンジニア |
| DAG スケジュールを確認します。 | 各 DAG スケジュールを表示するには、**Airflow UI** の **[Schedule]**タブに移動します。以下の各 DAG には、Amazon MWAA 環境で実行され、カスタムメトリクスを生成する事前設定されたスケジュールがあります。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-ingestion-and-visualization-of-amazon-mwaa-custom-metrics.html)各 DAG が正常に実行されたことを **Runs** 列で確認することもできます。 | データエンジニア、AWS DevOps |
### Amazon Managed Grafana 環境を設定する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| Amazon Managed Grafana ワークスペースへのアクセスを設定します。 | Terraform スクリプトが、必要な Amazon Managed Grafana ワークスペース、ダッシュボード、メトリクスページを作成しました。アクセスを表示できるように設定するには、以下を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-ingestion-and-visualization-of-amazon-mwaa-custom-metrics.html) | AWS DevOps |
| Amazon Timestream プラグインをインストールします。 | Amazon MWAA カスタムメトリクスは、Timestream データベースにロードされます。Timestream プラグインを使用し、Amazon Managed Grafana ダッシュボードでメトリクスを視覚化します。Timestream プラグインをインストールするには、次を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-ingestion-and-visualization-of-amazon-mwaa-custom-metrics.html)詳細については、Amazon Managed Grafana ドキュメントの「[Extend your workspace with plugins](https://docs.aws.amazon.com/grafana/latest/userguide/grafana-plugins.html#manage-plugins)」を参照してください。 | AWS DevOps、DevOps エンジニア |
### Amazon Managed Grafana ダッシュボードでカスタムメトリクスを視覚化する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| Amazon Managed Grafana ダッシュボードを表示します。 | Amazon Managed Grafana ワークスペースに取り込まれたメトリクスを表示するには次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-ingestion-and-visualization-of-amazon-mwaa-custom-metrics.html)ダッシュボードのメトリクスページには、次の情報が表示されます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-ingestion-and-visualization-of-amazon-mwaa-custom-metrics.html) | AWS DevOps |
| Amazon Managed Grafana ダッシュボードをカスタマイズします。 | 今後の機能強化のためにダッシュボードをカスタマイズするには、次を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-ingestion-and-visualization-of-amazon-mwaa-custom-metrics.html)または、このダッシュボードのソースコードは、[GitHub リポジトリ](https://github.com/aws-samples/visualize-amazon-mwaa-custom-metrics-grafana/blob/main/stacks/infra/grafana/dashboard.json)の `stacks/infra/grafana` フォルダの `dashboard.json` ファイルで使用できます。 | AWS DevOps |
### AWS リソースをクリーンアップする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| Amazon MWAA DAG の実行を一時停止します。 | DAG 実行を一時停止するには、次を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-ingestion-and-visualization-of-amazon-mwaa-custom-metrics.html) | AWS DevOps、データエンジニア |
| Amazon S3 バケットのオブジェクトを削除します。 | Amazon S3 バケットの **mwaa-events-bucket-\$1** および **mwaa-metrics-bucket-\$1** を削除するには、Amazon S3 ドキュメントの「[汎用バケットの削除](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html)」で Amazon S3 コンソールを使用する手順に従ってください。 | AWS DevOps |
| Terraform によって作成されたリソースを破棄します。 | Terraform によって作成されたリソースと関連するローカル Terraform 状態ファイルを破棄するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-ingestion-and-visualization-of-amazon-mwaa-custom-metrics.html) | AWS DevOps |
## トラブルシューティング
| 問題 | ソリューション |
| --- | --- |
| `null_resource.plugin_mgmt (local-exec): aws: error: argument operation: Invalid choice, valid choices are:` | AWS CLI を[最新バージョン](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)にアップグレードします。 |
| データソースのロードエラー: `Fetch error: 404 Not Found Instantiating…` | エラーは断続的です。数分待ってからデータソースを更新して、リストされた Timestream データソースを表示します。 |
## 関連リソース
**AWS ドキュメント**
+ [ダッシュボードと可視化のための Amazon Managed Grafana](https://docs.aws.amazon.com/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/amg-dashboarding-visualization.html)
+ [Okta を使用するように Amazon Managed Grafana を設定する](https://docs.aws.amazon.com/grafana/latest/userguide/AMG-SAML-providers-okta.html)
+ [Amazon Managed Grafana ワークスペース AWS IAM アイデンティティセンター で を使用する](https://docs.aws.amazon.com/grafana/latest/userguide/authentication-in-AMG-SSO.html)
+ [Amazon MWAA での DAGs の使用](https://docs.aws.amazon.com/mwaa/latest/userguide/working-dags.html)
**AWS ビデオ**
+ 次の[ビデオ](https://www.youtube.com/watch?v=XX2Xcz-Ps9U)に示されているように、認証用に Amazon Managed Grafana で IAM Identity Center を設定します。
[https://www.youtube-nocookie.com/embed/XX2Xcz-Ps9U?controls=0](https://www.youtube-nocookie.com/embed/XX2Xcz-Ps9U?controls=0)
+ IAM Identity Center が利用できない場合は、次の[動画](https://www.youtube.com/watch?v=Z4JHxl2xpOg)に示されているように、Okta などの外部 ID プロバイダー (IdP) を使用して Amazon Managed Grafana 認証を統合することもできます。
[https://www.youtube-nocookie.com/embed/Z4JHxl2xpOg?controls=0](https://www.youtube-nocookie.com/embed/Z4JHxl2xpOg?controls=0)
## 追加情報
Amazon MWAA 環境の包括的なモニタリングおよびアラートソリューションを作成し、事前対応型の管理と潜在的な問題や異常への迅速な対応を可能にします。Amazon Managed Grafana には次の機能が含まれています。
**アラート** – 事前定義されたしきい値または条件に基づいて、Amazon Managed Grafana にアラートを設定できます。特定のメトリクスが指定されたしきい値を上回ったり下回ったりした場合に、関連するステークホルダーに警告する E メール通知を設定します。詳細については、Amazon Managed Grafana ドキュメントの「[Grafana alerting](https://docs.aws.amazon.com/grafana/latest/userguide/alerts-overview.html)」を参照してください。
**統合** – Amazon Managed Grafana を OpsGenie、PagerDuty、Slack などのさまざまなサードパーティーツールと統合し、通知機能を強化できます。例えば、Amazon Managed Grafana で生成されたアラートに基づいて、ウェブフックを設定したり API と統合したりして、これらのプラットフォームでインシデントや通知をトリガーしたりできます。さらに、このパターンは AWS リソースを作成するための [GitHub リポジトリ](https://github.com/aws-samples/visualize-amazon-mwaa-custom-metrics-grafana)を提供します。このコードをインフラストラクチャのデプロイワークフローとさらに統合できます。
# AWS CodePipeline および AWS CodeBuild を使用して、スタックセットデプロイを自動化
*Thiyagarajan Mani、Mihir Borkar、Raghu Gowda (Amazon Web Services)*
## 概要
継続的統合と継続的デリバリ (CI/CD) のプロセスでは、既存のすべてのAWSアカウントと、AWS Organizationsで組織に追加する新しいアカウントにアプリケーションを自動的にデプロイする場合があります。この要件に対応する CI/CD ソリューションを設計する場合、AWS CloudFormation の[委任スタックセット管理者](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-orgs-delegated-admin.html) キャパシティが役立ちます。管理アカウントへのアクセスを制限することでセキュリティレイヤーを実現できるためです。ただし、AWS CodePipeline はサービス管理型のアクセス権限モデルを使用して、アプリケーションを複数のアカウントとリージョンにデプロイします。AWS CodePipeline に委任スタックセット管理者機能が適用されないため、 AWS Organizations 管理アカウントを使用して、スタックセットでデプロイします。
このパターンでは、この制限を回避する方法を示しています。このパターンでは、AWS CodeBuild とカスタムスクリプトを使用して、AWS CodePipeline 付けのスタックセットのデプロイを自動化します。以下のアプリケーションデプロイアクティビティを自動化します。
+ アプリケーションをスタックセットとして既存の組織単位 (OU) にデプロイ
+ アプリケーションのデプロイをその他の OU やリージョンにまで拡張
+ デプロイされたアプリケーションをすべてまたは特定の OU またはリージョンから削除
## 前提条件と制限事項
**前提条件**
このパターンのステップに従う前に、
+ AWS Organizations の管理アカウントで組織を作成します。手順については、[AWS Organizations ドキュメント](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org_create.html)を参照してください。
+ AWS Organizations と CloudFormation 間の信頼できるアクセスを有効にして、サービス管理の権限を使用します。手順について、CloudFormation ドキュメントの[AWS Organizations との信頼できるアクセスを有効にする](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-orgs-enable-trusted-access.html) を参照してください。
**機能制限**
このパターンで提供されるコードには以下の制限があります。
+ 1 つのアプリケーションにデプロイする CloudFormation テンプレートは 1 つだけです。複数のテンプレートのデプロイが現在サポートされていません。
+ 現在の実装をカスタマイズするには、DevOpsの専門知識が必要です。
+ このパターンでは AWS キー管理システム (AWS KMS) キーは使用されません。ただし、このパターンに含まれている CloudFormation テンプレートを再設定することで、この機能を有効にできます。
## アーキテクチャ
![\[CI/CD パイプライン自動化アーキテクチャ\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/a5c47de7-9039-415d-a9e5-9de0d4c3a260/images/2dbca422-7f32-4f9c-a4aa-1f95b484b772.png)
この CI/CD デプロイパイプラインのアーキテクチャは、以下を処理します。
+ スタックセットデプロイの責任を、アプリケーションデプロイのスタックセット管理者として専用 CI/CD アカウントに委任することで、管理アカウントへの直接アクセスを制限します。
+ サービス管理型の権限モデルを使用して、OU に新しいアカウントが作成されマッピングされるたびに、アプリケーションを自動的にデプロイします。
+ 環境レベルですべてのアカウントでアプリケーションバージョンの一貫性を確保します。
+ リポジトリレベルとパイプラインレベルで複数の承認ステージを使用して、デプロイされたアプリケーションのセキュリティとガバナンスをさらに強化します。
+ CodeBuild のカスタムビルドのデプロイスクリプトを使用して、スタックセットとスタックインスタンスを自動的にデプロイまたは削除することで、CodePipeline の現在の制限を克服します。カスタムスクリプトによって実装される API 呼び出しのフロー制御と階層の図について、[追加情報](#automate-stack-set-deployment-by-using-aws-codepipeline-and-aws-codebuild-additional) セクションを参照してください。
+ 開発環境、テスト環境、本番環境用に個別のスタックセットを作成します。さらに、各段階で複数の OU とリージョンを組み合わせたスタックセットを作成できます。たとえば、開発デプロイメント段階でサンドボックスと開発 OU を組み合わせることができます。
+ アカウントのサブセットや OU リストへのアプリケーションのデプロイや除外が適用されます。
**自動化とスケール**
このパターンで提供されるコードを使用して、AWS CodeCommit リポジトリとアプリケーション用のコードパイプラインを作成できます。その後、これらをスタックセットとして OU レベルで複数のアカウントにデプロイできます。このコードでは、承認者に通知する Amazon Simple Notification Service (Amazon SNS) トピック、必要な AWS Identity and Access Management (IAM) ロール、管理アカウントに適用するサービスコントロールポリシー (SCP) などのコンポーネントも自動化されます。
## ツール
**AWS サービス**
+ [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) を使用すると、AWS リソースをセットアップし、迅速かつ一貫したプロビジョニングを行い、AWS アカウントとリージョン全体でライフサイクル全体にわたってリソースを管理できます。
+ [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) は完全マネージド型の構築サービスです。ソースコードのコンパイル、ユニットテストの実行、すぐにデプロイできるアーティファクトの生成を行います。
+ [AWS CodeCommit](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html) は、独自のソースコントロールシステムを管理しなくても、Git リポジトリを非公開で保存および管理できるバージョン管理サービスです。
+ [AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) は、Amazon Elastic Compute Cloud (Amazon EC2) またはオンプレミスインスタンス、AWS Lambda 関数、または Amazon Elastic Container Service (Amazon ECS) サービスへのデプロイを自動化します。
+ [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) は、ソフトウェアリリースのさまざまな段階を迅速にモデル化および設定し、ソフトウェアの変更を継続的にリリースするために必要なステップを自動化するのに役立ちます。
+ [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html) は、作成して一元管理している複数の AWS アカウントを組織に統合するためのアカウント管理サービスです。
+ 「[Amazon Simple Notification Service (Amazon SNS)](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)」は、ウェブサーバーやメールアドレスなど、パブリッシャーとクライアント間のメッセージの交換を調整および管理するのに役立ちます。
**コードリポジトリ**
このパターンのコードは、GitHub 内の「[自動コードパイプラインスタックセットデプロイ](https://github.com/aws-samples/automated-code-pipeline-stackset-deployment)」リポジトリで利用できます。フォルダ構造やその他の詳細については、リポジトリの [readme ファイル](https://github.com/aws-samples/automated-code-pipeline-stackset-deployment/blob/main/README.md)を参照してください。
## ベストプラクティス
このパターンでは、OU レベルでアプリケーションをデプロイしている間、管理アカウントへの直接アクセスが制限されます。パイプラインとリポジトリのプロセスに複数の承認ステージを追加することで、このアプローチを使用してデプロイするアプリケーションとコンポーネントのセキュリティとガバナンスを強化できます。
## エピック
### AWS Organizations アカウントを設定
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| 管理アカウントですべての特徴量を有効にします。 | [AWS Organizations ドキュメント](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org_support-all-features.html) の指示に従って、組織の管理アカウントのすべての機能を有効にします。 | AWS 管理者、プラットフォーム管理者 |
| CI/CD アカウントを作成します。 | AWS Organizations では、組織内で専用の CI/CD アカウントを作成し、そのアカウントへのアクセスを所有および管理するチームを割り当てます。 | AWS 管理者 |
| 委任管理者を追加する | 管理アカウントに、前のステップで作成した CI/CD アカウントを委任スタックセット管理者として登録します。手順については、[AWS CloudFormation のドキュメント](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-orgs-delegated-admin.html) を参照してください。 | AWS 管理者、プラットフォーム管理者 |
### アプリケーションリポジトリと CI/CD パイプラインを作成
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| コードリポジトリを複製します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-stack-set-deployment-by-using-aws-codepipeline-and-aws-codebuild.html) | AWS DevOps |
| SNS トピックを作成します。 | GitHub リポジトリに用意されている `sns-template.yaml` テンプレートを使用して SNS トピックを作成し、承認リクエストのサブスクリプションを設定できます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-stack-set-deployment-by-using-aws-codepipeline-and-aws-codebuild.html) | AWS DevOps |
| CI/CD コンポーネントの IAM ロールを作成します。 | GitHub リポジトリに用意されている `cicd-role-template.yaml` テンプレートを使用して、CI/CD コンポーネントに必要な IAM ロールとポリシーを作成できます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-stack-set-deployment-by-using-aws-codepipeline-and-aws-codebuild.html) | AWS DevOps |
| アプリケーションの CodeCommit リポジトリとコードパイプラインを作成します。 | GitHub リポジトリに提供されている `cicd-pipeline-template.yaml` テンプレートを使用して、アプリケーションの CodeCommit リポジトリとコードパイプラインを作成できます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-stack-set-deployment-by-using-aws-codepipeline-and-aws-codebuild.html) | AWS DevOps |
### スタックセットをデプロイします。
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| アプリケーションリポジトリをクローニングします。 | 以前に使用した CI/CD パイプラインテンプレートは、サンプルアプリケーションリポジトリとコードパイプラインを作成します。リポジトリを複製して検証するには：[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-stack-set-deployment-by-using-aws-codepipeline-and-aws-codebuild.html) | アプリ開発者、データエンジニア |
| アプリケーションアーティファクトの追加。 | CloudFormation テンプレートを使用してアプリケーションリポジトリを更新します。このソリューションでは、単一の CloudFormation テンプレートのデプロイのみが適用されます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-stack-set-deployment-by-using-aws-codepipeline-and-aws-codebuild.html) | アプリ開発者、データエンジニア |
| デプロイ設定ファイルを更新します。 | ファイルを更新します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-stack-set-deployment-by-using-aws-codepipeline-and-aws-codebuild.html)このパターンでは、デプロイ設定ファイルに指定したスタックセット名に環境名を追加して、環境ごとに個別のスタックセットを作成します。 | アプリ開発者、データエンジニア |
| 変更内容をコミットし、スタックセットをデプロイします。 | アプリケーションテンプレートで指定した変更をコミットし、スタックセットを複数の環境に段階的にマージしてデプロイします。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-stack-set-deployment-by-using-aws-codepipeline-and-aws-codebuild.html) | アプリ開発者、データエンジニア |
## トラブルシューティング
| 問題 | ソリューション |
| --- | --- |
| 例外のせいでデプロイが失敗しました。*テンプレートパラメータファイルの名前を<アプリケーション名>-パラメータ-.json に変更します。デフォルトの名前は使用できません* | CloudFormation テンプレートのパラメータファイルは、指定された命名規則に従う必要があります。パラメータファイル名を更新し、再試行します。 |
| 例外のせいでデプロイが失敗しました。*CloudFormation テンプレートの名前を <アプリケーション名>.yml 、デフォルトのテンプレート.yml 、または template.yaml は使用できませんに変更します* | CloudFormation テンプレートのパラメータファイルは、指定された命名規則に従う必要があります。ファイル名を更新して、再試行します。 |
| 例外のせいでデプロイが失敗しました。*\$1環境名\$1 環境の有効な CloudFormation テンプレートとそのパラメータファイルが見つかりません* | CloudFormation テンプレートのファイル命名規則と、指定された環境のパラメータファイルを確認します。 |
| 例外のせいでデプロイが失敗しました。*デプロ設定ファイルに無効なデプロイアクションが提供されています。有効なオプションは「デプロイ」と「削除」です。* | デプロイ設定ファイルの `deployment_action` パラメータに無効な値を指定しました。このパラメータには、`deploy` と `delete` の 2 つの有効な値があります。`deploy` を使用して、スタックセットとそれに関連するスタックインスタンスを作成、更新します。スタックセット全体と関連するスタックインスタンスを削除する場合のみ、`delete` を使用します。 |
## 関連リソース
+ GitHub [自動コードパイプラインスタックセットデプロイ](https://github.com/aws-samples/automated-code-pipeline-stackset-deployment) リポジトリ
+ [組織内のすべての特徴量の有効化](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org_support-all-features.html) (AWS Organizations ドキュメント)
+ [委任管理者を登録](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-orgs-delegated-admin.html) (AWS CloudFormation ドキュメント)
+ [サービスマネージド型スタックセットのアカウントレベルのターゲット](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/account-level-targets.html) (AWS CloudFormation ドキュメント)
## 追加情報
**フローチャート**
次のフローチャートは、スタックセットのデプロイを自動化するためにカスタムスクリプトによって実装される API 呼び出しのフロー制御と階層を示しています。
![\[Python スクリプトによって実装されたフロー制御と API 呼び出し\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/a5c47de7-9039-415d-a9e5-9de0d4c3a260/images/1898883a-62b7-40c2-8f08-9f2a9dda8404.png)
** サンプルのデプロイ設定ファイル**
**新しいスタックセットの作成t**
次のデプロイ設定ファイルは、3 つの OU の AWS リージョン `us-east-1` の `sample-stack-set` と呼ばれる新しいスタックセットを作成します。
```
{
"deployment_action": "deploy",
"stack_set_name": "sample-stack-set",
"stack_set_desciption": "this is a sample stack set",
"deployment_targets": {
"dev": {
"org_units": ["dev-org-unit-1"],
"regions": ["us-east-1"],
"filter_accounts": [],
"filter_type": ""
},
"test": {
"org_units": ["test-org-unit-1"],
"regions": ["us-east-1"],
"filter_accounts": [],
"filter_type": ""
},
"prod": {
"org_units": ["prod-org-unit-1"],
"regions": ["us-east-1"],
"filter_accounts": [],
"filter_type": ""
}
},
"cft_capabilities": ["CAPABILITY_IAM", "CAPABILITY_NAMED_IAM"],
"auto_deployement": "True",
"retain_stacks_on_account_removal": "True",
"region_deployment_concurrency": "PARALLEL"
}
```
**既存のスタックセットを別の OU にデプロイ**
前の例で示した設定をデプロイし、`dev-org-unit-2` 開発環境で呼び出される別の OU にスタックセットをデプロイする場合、デプロイ設定ファイルは次のようになります。
```
{
"deployment_action": "deploy",
"stack_set_name": "sample-stack-set",
"stack_set_desciption": "this is a sample stack set",
"deployment_targets": {
"dev": {
"org_units": ["dev-org-unit-1", "dev-org-unit-2"],
"regions": ["us-east-1"],
"filter_accounts": [],
"filter_type": ""
},
"test": {
"org_units": ["test-org-unit-1"],
"regions": ["us-east-1"],
"filter_accounts": [],
"filter_type": ""
},
"prod": {
"org_units": ["prod-org-unit-1"],
"regions": ["us-east-1"],
"filter_accounts": [],
"filter_type": ""
}
},
"cft_capabilities": ["CAPABILITY_IAM", "CAPABILITY_NAMED_IAM"],
"auto_deployement": "True",
"retain_stacks_on_account_removal": "True",
"region_deployment_concurrency": "PARALLEL"
}
```
**既存のスタックセットを別の AWS リージョンにデプロイ**
前の例で示した設定をデプロイし、2 つの OU( `dev-org-unit-1` と `dev-org-unit-2` ) の開発環境内の別の AWS リージョン (`us-east-2`) にスタックセットをデプロイする場合、デプロイ設定ファイルは次のようになります。
**注記**
CloudFormation テンプレート内のリソースは有効で、リージョン固有である必要があります。
```
{
"deployment_action": "deploy",
"stack_set_name": "sample-stack-set",
"stack_set_desciption": "this is a sample stack set",
"deployment_targets": {
"dev": {
"org_units": ["dev-org-unit-1", "dev-org-unit-2"],
"regions": ["us-east-1", "us-east-2"],
"filter_accounts": [],
"filter_type": ""
},
"test": {
"org_units": ["test-org-unit-1"],
"regions": ["us-east-1"],
"filter_accounts": [],
"filter_type": ""
},
"prod": {
"org_units": ["prod-org-unit-1"],
"regions": ["us-east-1"],
"filter_accounts": [],
"filter_type": ""
}
},
"cft_capabilities": ["CAPABILITY_IAM", "CAPABILITY_NAMED_IAM"],
"auto_deployement": "True",
"retain_stacks_on_account_removal": "True",
"region_deployment_concurrency": "PARALLEL"
}
```
**OU または AWS リージョンからのスタックインスタンスを削除**
前の例で示したデプロイ設定がデプロイされたとみなされます。次の設定ファイルは OU `dev-org-unit-2` の両方のリージョンからスタックインスタンスを削除します。
```
{
"deployment_action": "deploy",
"stack_set_name": "sample-stack-set",
"stack_set_desciption": "this is a sample stack set",
"deployment_targets": {
"dev": {
"org_units": ["dev-org-unit-1"],
"regions": ["us-east-1", "us-east-2"],
"filter_accounts": [],
"filter_type": ""
},
"test": {
"org_units": ["test-org-unit-1"],
"regions": ["us-east-1"],
"filter_accounts": [],
"filter_type": ""
},
"prod": {
"org_units": ["prod-org-unit-1"],
"regions": ["us-east-1"],
"filter_accounts": [],
"filter_type": ""
}
},
"cft_capabilities": ["CAPABILITY_IAM", "CAPABILITY_NAMED_IAM"],
"auto_deployement": "True",
"retain_stacks_on_account_removal": "True",
"region_deployment_concurrency": "PARALLEL"
}
```
次の設定ファイルは、開発環境内の両方の OU の AWS リージョン `us-east-1` からスタックインスタンスを削除します。
```
{
"deployment_action": "deploy",
"stack_set_name": "sample-stack-set",
"stack_set_desciption": "this is a sample stack set",
"deployment_targets": {
"dev": {
"org_units": ["dev-org-unit-1", "dev-org-unit-2"],
"regions": ["us-east-2"],
"filter_accounts": [],
"filter_type": ""
},
"test": {
"org_units": ["test-org-unit-1"],
"regions": ["us-east-1"],
"filter_accounts": [],
"filter_type": ""
},
"prod": {
"org_units": ["prod-org-unit-1"],
"regions": ["us-east-1"],
"filter_accounts": [],
"filter_type": ""
}
},
"cft_capabilities": ["CAPABILITY_IAM", "CAPABILITY_NAMED_IAM"],
"auto_deployement": "True",
"retain_stacks_on_account_removal": "True",
"region_deployment_concurrency": "PARALLEL"
}
```
**スタックセット全体を削除します。**
次のデプロイ設定ファイルは、スタックセット全体と関連するスタックインスタンスを削除します。
```
{
"deployment_action": "delete",
"stack_set_name": "sample-stack-set",
"stack_set_desciption": "this is a sample stack set",
"deployment_targets": {
"dev": {
"org_units": ["dev-org-unit-1", "dev-org-unit-2"],
"regions": ["us-east-2"],
"filter_accounts": [],
"filter_type": ""
},
"test": {
"org_units": ["test-org-unit-1"],
"regions": ["us-east-1"],
"filter_accounts": [],
"filter_type": ""
},
"prod": {
"org_units": ["prod-org-unit-1"],
"regions": ["us-east-1"],
"filter_accounts": [],
"filter_type": ""
}
},
"cft_capabilities": ["CAPABILITY_IAM", "CAPABILITY_NAMED_IAM"],
"auto_deployement": "True",
"retain_stacks_on_account_removal": "True",
"region_deployment_concurrency": "PARALLEL"
}
```
* ***デプロイメントからアカウントを除外します。**
次のデプロイ設定ファイルでは、OU `dev-org-unit-1` の一部であるアカウント `111122223333` がデプロイから除外されます。
```
{
"deployment_action": "deploy",
"stack_set_name": "sample-stack-set",
"stack_set_desciption": "this is a sample stack set",
"deployment_targets": {
"dev": {
"org_units": ["dev-org-unit-1"],
"regions": ["us-east-1"],
"filter_accounts": ["111122223333"],
"filter_type": "DIFFERENCE"
},
"test": {
"org_units": ["test-org-unit-1"],
"regions": ["us-east-1"],
"filter_accounts": [],
"filter_type": ""
},
"prod": {
"org_units": ["prod-org-unit-1"],
"regions": ["us-east-1"],
"filter_accounts": [],
"filter_type": ""
}
},
"cft_capabilities": ["CAPABILITY_IAM", "CAPABILITY_NAMED_IAM"],
"auto_deployement": "True",
"retain_stacks_on_account_removal": "True",
"region_deployment_concurrency": "PARALLEL"
}
```
**OU のアカウントのサブセットにアプリケーションをデプロイ**
次のデプロイ設定ファイルでは、OU `dev-org-unit-1` の 3 つのアカウント(`111122223333`、`444455556666`、および `777788889999`)にのみアプリケーションをデプロイします。
```
{
"deployment_action": "deploy",
"stack_set_name": "sample-stack-set",
"stack_set_desciption": "this is a sample stack set",
"deployment_targets": {
"dev": {
"org_units": ["dev-org-unit-1"],
"regions": ["us-east-1"],
"filter_accounts": ["111122223333", "444455556666", "777788889999"],
"filter_type": "INTERSECTION"
},
"test": {
"org_units": ["test-org-unit-1"],
"regions": ["us-east-1"],
"filter_accounts": [],
"filter_type": ""
},
"prod": {
"org_units": ["prod-org-unit-1"],
"regions": ["us-east-1"],
"filter_accounts": [],
"filter_type": ""
}
},
"cft_capabilities": ["CAPABILITY_IAM", "CAPABILITY_NAMED_IAM"],
"auto_deployement": "True",
"retain_stacks_on_account_removal": "True",
"region_deployment_concurrency": "PARALLEL"
}
```
# Cloud Custodian と AWS CDK を使用して、Systems Manager の AWS マネージドポリシーを EC2 インスタンスプロファイルに自動的にアタッチする
*Ali Asfour、Aaron Lennon (Amazon Web Services)*
## 概要
運用タスクを自動化し、より多くの可視性と制御を提供する AWS Systems Manager に、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを統合することができます。Systems Manager と統合するには、EC2 インスタンスに [AWS Systems Manager Agent(SSM Agent)](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent.html) をインストールし、`AmazonSSMManagedInstanceCore` AWS Identity and Access Management (IAM) ポリシーをプロファイルに追加する必要があります。
ただし、すべての EC2 インスタンスプロファイルに `AmazonSSMManagedInstanceCore` ポリシーを確実にアタッチする場合、インスタンスプロファイルを持たない新規 EC2 インスタンスや、インスタンスプロファイルを持つが `AmazonSSMManagedInstanceCore` ポリシーを持たない EC2 インスタンスを更新する際に問題が発生する可能性があります。また、このポリシーを複数の Amazon Web Services (AWS) アカウントや AWS リージョンに追加することが難しい場合もあります。
このパターンは、AWS アカウントに次の 3 つの [Cloud Custodian](https://cloudcustodian.io/) ポリシーをデプロイすることで、これらの課題を解決するのに役立ちます。
+ 最初の Cloud Custodian ポリシーは、インスタンスプロファイルを持つが、`AmazonSSMManagedInstanceCore` ポリシーを持たない既存の EC2 インスタンスをチェックします。その後、`AmazonSSMManagedInstanceCore` ポリシーがアタッチされます。
+ 2 つ目の Cloud Custodian ポリシーは、インスタンスプロファイルのない既存の EC2 インスタンスをチェックし、`AmazonSSMManagedInstanceCore` ポリシーがアタッチされたデフォルトのインスタンスプロファイルを追加します。
+ 3 つ目の Cloud Custodian ポリシーでは、EC2 インスタンスとインスタンスプロファイルの作成を監視するための [AWS Lambda 関数](https://cloudcustodian.io/docs/aws/lambda.html)をアカウント内に作成します。これにより、EC2 インスタンスの作成時に自動的に `AmazonSSMManagedInstanceCore` ポリシーがアタッチされます。
このパターンは、[AWS DevOps](https://aws.amazon.com/devops/) ツールを使用することで、個別のコンピューティング環境をプロビジョニングすることなく、マルチアカウント環境で Cloud Custodian ポリシーの継続的かつ大規模なデプロイを実現します。
## 前提条件と制限
**前提条件**
+ 2 つ以上の AWS アカウントがアクティブである。一方のアカウントは*セキュリティアカウント*で、他方は*メンバーアカウント*である。
+ セキュリティアカウントで AWS リソースをプロビジョニングする権限がある。このパターンでは、[管理者権限](https://docs.aws.amazon.com/singlesignon/latest/userguide/getting-started.html)を使用しますが、組織の要件とポリシーに従って権限を付与する必要があります。
+ セキュリティアカウントから IAM ロールをメンバーアカウントに引き継ぎ、必要な IAM ロールを作成できます。詳細については、IAM ドキュメントの「[IAM ロールを使用して AWS アカウント間でアクセスを委任する](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html)」を参照してください。
+
**重要**
AWS コマンドラインインターフェイス (AWS CLI) をインストールして設定済み。テスト目的で、`aws configure` コマンドを使用するか、環境変数を設定することで、AWS CLI を設定できます。: これは本番環境では推奨されません。このアカウントには、最小特権のみ付与することをお勧めします。詳細については、IAM ドキュメントの「[最小特権を付与する](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)」を参照してください。
+ `devops-cdk-cloudcustodian.zip` ファイル (添付) は、ローカルコンピュータにダウンロードされます。
+ Python に精通していること。
+ 必要なツール (Node.js、AWS Cloud Development Kit (AWS CDK)、および Git) をインストールして設定済み。`devops-cdk-cloudcustodian.zip` ファイル内の `install-prerequisites.sh` ファイルを使用して、これらのツールをインストールできます。****このファイルを root 権限で実行していることを確認します。****
**機能制限**
+ このパターンは実稼働環境でも使用できますが、すべての IAM ロールとポリシーが組織の要件とポリシーを満たしていることを確認してください。
**パッケージバージョン**
+ Cloud Custodian バージョン 0.9 以降
+ TypeScript バージョン 3.9.7 以降
+ Node.js バージョン 14.15.4 以降
+ `npm` バージョン 7.6.1 以降
+ AWS CDK バージョン 1.96.0 またはそれ以降
## アーキテクチャ
![\[AWS CodePipeline workflow with CodeCommit, CodeBuild, and deployment to member accounts.\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/169a7bde-789e-4ebd-b4ca-80eb28ac9927/images/8ec0b6b4-d4b0-42e5-833d-24d1e6098fd9.png)
この図表は、次のワークフローを示しています:
1. Cloud Custodian ポリシーが、セキュリティ アカウントに AWS CodeCommit リポジトリにプッシュされます。Amazon CloudWatch Events ルールは、AWS CodePipeline パイプラインを自動的に起動します。
1. パイプラインは CodeCommit から最新のコードを取得し、AWS CodeBuild で処理される CI/CD (継続統合および継続配信) パイプラインの継続的な統合部分に送信します。
1. CodeBuild は、Cloud Custodian ポリシーのポリシー構文検証を含む完全な DevSecOps アクションを実行し、`--dryrun` モードでこれらのポリシーを実行して、どのリソースが認識されているかをチェックします。
1. エラーがなければ、次のタスクで変更を確認し、メンバーアカウントへのデプロイを承認するよう管理者にアラートが送信されます。
**テクノロジースタック**
+ AWS CDK
+ CodeBuild
+ CodeCommit
+ CodePipeline
+ IAM
+ Cloud Custodian
**自動化とスケール**
AWS CDK Pipelines モジュールは、AWS CloudFormation スタックを使用した AWS リソースのデプロイに加え、CodePipeline を使用する CI/CD コンジットをプロビジョニングして、CodeBuild を介したソースコードのビルドとテストをオーケストレーションします。このパターンは、組織内のすべてのメンバーアカウントとリージョンで使用できます。`Roles creation` スタックを拡張して、メンバーアカウントに他の IAM ロールをデプロイすることもできます。
## ツール
+ [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/latest/guide/home.html) は、コードでクラウドインフラストラクチャを定義し、AWS CloudFormation を通じてプロビジョニングするための、ソフトウェア開発フレームワーク
+ [AWS コマンドラインインターフェイス (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) はオープンソースのツールであり、コマンドラインシェルのコマンドを使用して AWS サービスとやり取りすることができます。
+ [AWS CodeBuild ](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)はクラウドで動作する、完全マネージド型のビルドサービスです。
+ [AWS CodeCommit](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html) は、プライベートな保存と管理を有効にするバージョン管理サービスです。
+ [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)は、ソフトウェアをリリースするために必要な手順のモデル化、視覚化、および自動化に使用できる継続的な配信サービスです。
+ [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、AWS リソースへのアクセスをセキュアに制御するためのウェブサービスです。
+ [Cloud Custodian](https://cloudcustodian.io/) は、多くの組織がパブリック クラウドアカウントの管理に使用しているツールとスクリプトを 1 つのオープンソースツールに統合します。
+ [Node.js](https://nodejs.org/en/) は Google Chrome の V8 JavaScript エンジンをベースに構築された JavaScript ランタイムです。
**コード **
このパターンで使用されるモジュール、アカウント関数、ファイル、およびデプロイコマンドの詳細なリストについては、`devops-cdk-cloudcustodian.zip` ファイル（添付） `README` 内のファイルを参照してください。
## エピック
### AWS CDK でパイプラインをセットアップする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| CodeCommit リポジトリを設定します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-attach-an-aws-managed-policy-for-systems-manager-to-ec2-instance-profiles-using-cloud-custodian-and-aws-cdk.html)[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-attach-an-aws-managed-policy-for-systems-manager-to-ec2-instance-profiles-using-cloud-custodian-and-aws-cdk.html)詳細については、AWS CodeCommit ドキュメントの「[CodeCommit リポジトリの作成](https://docs.aws.amazon.com/codecommit/latest/userguide/how-to-create-repository.html)」を参照してください。 | 開発者 |
| 必要なツールをインストールします。 | `install-prerequisites.sh` ファイルを使用して Amazon Linux に必要なすべてのツールをインストールします。AWS CLI は事前にインストールされているため、含まれていません。詳細については、AWS CDK ドキュメントの「[AWS CDK の使用開始](https://docs.aws.amazon.com/cdk/latest/guide/getting_started.html)」にある「[前提条件](https://docs.aws.amazon.com/cdk/latest/guide/getting_started.html#getting_started_prerequisites)」セクションを参照してください。 | 開発者 |
| 必要な AWS CDK パッケージをインストールします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-attach-an-aws-managed-policy-for-systems-manager-to-ec2-instance-profiles-using-cloud-custodian-and-aws-cdk.html)以下のパッケージは AWS CDK に必要であり、`requirements.txt` ファイルに含まれています。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-attach-an-aws-managed-policy-for-systems-manager-to-ec2-instance-profiles-using-cloud-custodian-and-aws-cdk.html) | 開発者 |
### 環境の設定
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| 必要な変数を更新してください。 | CodeCommit `vars.py` リポジトリのルートフォルダにあるファイルを開き、次の変数を更新します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-attach-an-aws-managed-policy-for-systems-manager-to-ec2-instance-profiles-using-cloud-custodian-and-aws-cdk.html) | 開発者 |
| account.yml ファイルをメンバーアカウント情報で更新します。 | [c7n-org Cloud Custodian](https://cloudcustodian.io/docs/tools/c7n-org.html) ツールを複数のアカウントに対して実行するには、`accounts.yml` 設定ファイルをリポジトリのルートに配置する必要があります。以下は、AWS の Cloud Custodian 設定のサンプルファイルです。accounts:
- account_id: '123123123123'
name: account-1
regions:
- us-east-1
- us-west-2
role: arn:aws:iam::123123123123:role/CloudCustodian
vars:
charge_code: xyz
tags:
- type:prod
- division:some division
- partition:us
- scope:pci
| 開発者 |
### AWS アカウントをブートストラップする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| セキュリティアカウントをブートストラップします。 | 以下のコマンドを実行して、`cloudcustodian_stack` アプリケーションで `deploy_account` をブートストラップします。cdk bootstrap -a 'python3
cloudcustodian/cloudcustodian_stack.py
| 開発者 |
| オプション 1 - メンバーアカウントを自動的にブートストラップします。 | `vars.py` ファイルで `cdk_bootstrap_member_accounts` 変数が `True` に設定されている場合、`member_accounts` 変数で指定されたアカウントは パイプラインによって自動的にブートストラップされます。必要に応じて、IAM ロールを使用して `*cdk_bootstrap_role*` を更新できます。このロールは、セキュリティアカウントから引き受けることができ、AWS CDK をブートストラップするために必要な権限を持っています。`member_accounts ` 変数に追加された新規アカウントは、パイプラインによって自動的にブートストラップされ、必要なロールをデプロイできるようになります。 | 開発者 |
| オプション 2 - メンバーアカウントを手動でブートストラップします。 | この方法はお勧めしませんが、`cdk_bootstrap_member_accounts` の値を `False` に設定し、次のコマンドを使用して手動で実行できます：$ cdk bootstrap -a 'python3 cloudcustodian/member_account_roles_stack.py' \
--trust {security_account_id} \
--context assume-role-credentials:writeIamRoleName={role_name} \
--context assume-role-credentials:readIamRoleName={role_name} \
--mode=ForWriting \
--context bootstrap=true \
--cloudformation-execution-policies arn:aws:iam::aws:policy/AdministratorAccess
`{security_account_id}` と `{role_name}` の値は、セキュリティアカウントから引き受けることができ、AWS CDK のブートストラップに必要な権限を持つ IAM ロールの名前で更新されることを確認してください。AWS CloudFormation など、他の方法を使用してメンバーアカウントをブートストラップすることもできます。詳細については、AWS CDK ドキュメントの「[ブートストラップ](https://docs.aws.amazon.com/cdk/latest/guide/bootstrapping.html)」を参照してください。 | 開発者 |
### AWS CDK スタックをデプロイする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| メンバーアカウントで IAM ロールを作成します。 | 次のコマンドを実行して、`member_account_roles_stack` スタックをデプロイし、メンバーアカウントに IAMロールを作成します：cdk deploy --all -a 'python3 cloudcustodian/member_account_roles_stack.py' --require-approval never
| 開発者 |
| Cloud Custodian パイプラインスタックをデプロイします。 | 次のコマンドを実行して、セキュリティアカウントにデプロイされる Cloud Custodian `cloudcustodian_stack.py` パイプラインを作成します。cdk deploy -a 'python3 cloudcustodian/cloudcustodian_stack.py'
| 開発者 |
## 関連リソース
+ [AWS CDK の使用開始](https://docs.aws.amazon.com/cdk/latest/guide/getting_started.html)
## アタッチメント
このドキュメントに関連する追加コンテンツにアクセスするには、次のファイルを解凍してください。「[attachment.zip](samples/p-attach/169a7bde-789e-4ebd-b4ca-80eb28ac9927/attachments/attachment.zip)」
# AWS CDK を使用してマイクロサービス用の CI/CD パイプラインと Amazon ECS クラスターを自動的に構築する
*Varsha Raju (Amazon Web Services)*
## 概要
このパターンは、Amazon Elastic Container Service (Amazon ECS) でマイクロサービスを構築およびデプロイするための、継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインと基盤となるインフラストラクチャを自動的に作成する方法を示しています。概念実証の CI/CD パイプラインを設定して、組織に CI/CD、マイクロサービス、DevOps の利点を説明する場合は、このアプローチを使用できます。また、このアプローチを使用して最初の CI/CD パイプラインを作成し、組織の要件に応じてカスタマイズまたは変更もできます。
このパターンのアプローチでは、本番環境と非本番環境を作成し、それぞれに仮想プライベートクラウド (VPC) と 2 つのアベイラビリティーゾーンで実行するように設定された Amazon ECS クラスターがあります。これらの環境はすべてのマイクロサービスとユーザーで共有され、各マイクロサービスに CI/CD パイプラインを作成します。これらの CI/CD パイプラインは、AWS CodeCommit のソースリポジトリから変更を取得し、変更を自動的にビルドして、本番環境と非本番環境にデプロイします。パイプラインがすべてのステージを正常に完了すると、URL を使用して本番環境と非本番環境のマイクロサービスにアクセスできます。
## 前提条件と制限事項
**前提条件**
+ アクティブな Amazon Web Services (AWS)アカウント。
+ `starter-code.zip` ファイル (添付) を含む既存の Amazon Simple Storage Service (Amazon S3) バケット。
+ AWS Cloud Development Kit (AWS CDK) はお使いのアカウントにインストールおよび設定済みです。詳細については、AWS CDK ドキュメントの「[Getting started with the AWS CDK](https://docs.aws.amazon.com/cdk/latest/guide/getting_started.html)」を参照してください。
+ Python 3 と `pip` をインストールおよび設定済みです。詳細については、[Python のドキュメント](https://www.python.org/)を参照してください。
+ AWS CDK、AWS CodePipeline、AWS CodeBuild、CodeCommit、Amazon Elastic Container Registry (Amazon ECR)、Amazon ECS、AWS Fargate に精通していること。
+ Docker に精通していること。
+ CI/CD と DevOps について理解していること。
**制限**
+ AWS アカウントの全般的な制限が適用されます。この詳細については、AWS 全般のリファレンスドキュメントの「[AWS Service Quotas](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)」を参照してください。
**製品バージョン**
+ このコードは、 Node.js バージョン 16.13.0 および AWS CDK バージョン 1.132.0 を使用してテストされました。
## アーキテクチャ
![\[AWS クラウド architecture diagram showing CI/CD pipeline and deployment to production and non-production VPCs.\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/05ac2cad-408e-433f-8150-0a2b71f63cfd/images/6fa3dbef-88de-4b3f-ae41-dfa90256a058.png)
この図表は、次のワークフローを示しています:
1. アプリ開発者は CodeCommit リポジトリにコードをコミットします。
1. パイプラインが開始されます。
1. CodeBuild は、Docker イメージをビルドして Amazon ECR リポジトリにプッシュします。
1. CodePipeline は、非本番環境の Amazon ECS クラスター内の既存の Fargate サービスに新しいイメージをデプロイします。
1. Amazon ECS は Amazon ECR リポジトリから非本番環境の Fargate サービスにイメージを引き出します。
1. テストは非本番環境の URL を使用して実行されます。
1. リリースマネージャーは本番環境へのデプロイを承認します。
1. CodePipeline は、新しいイメージを本番環境の Amazon ECS クラスター内の既存の Fargate サービスにデプロイします。
1. Amazon ECS は Amazon ECR リポジトリから本番環境の Fargate サービスにイメージを引き出します。
1. 本番環境ユーザーは本番環境の URL を使用して機能にアクセスします。
**テクノロジースタック**
+ AWS CDK
+ CodeBuild
+ CodeCommit
+ CodePipeline
+ Amazon ECR
+ Amazon ECS
+ Amazon VPC
**自動化とスケール**
このパターンのアプローチを使用して、共有の AWS CloudFormation スタックにデプロイされたマイクロサービスのパイプラインを作成できます。自動化により、各 VPC に複数の Amazon ECS クラスターを作成できるほか、共有 Amazon ECS クラスターにデプロイされたマイクロサービスのパイプラインも作成できます。ただし、そのためには、新しいリソース情報をパイプラインスタックへの入力として提供する必要があります。
## ツール
+ [AWS CDK](https://docs.aws.amazon.com/cdk/latest/guide/home.html)— AWS Cloud Development Kit (AWS CDK) は、コードでクラウドインフラストラクチャを定義し、AWS CloudFormation でプロビジョニングするソフトウェア開発フレームワークです。
+ [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) - AWS CodeBuild はクラウドの完全マネージド型のビルドサービスです。CodeBuild はソースコードをコンパイルし、ユニットテストを実行して、すぐにデプロイできるアーティファクトを作成します。
+ [AWS CodeCommit](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html) – AWS CodeCommit は、 AWS クラウドでの Git リポジトリのプライベートな保存と管理を可能にするバージョン制御サービスです。CodeCommit により、お客様が独自のソース制御システムを管理、またはインフラストラクチャのスケーリングに関して心配する必要はなくなります。
+ [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) – AWS CodePipeline は、ソフトウェアのリリースに必要な手順のモデル化、可視化、および自動化に使用できる継続的な配信サービスです。ソフトウェアリリースプロセスのさまざまなステージを素早くモデル化して設定できます。CodePipeline はソフトウェア変更の継続的リリースに必要なステップを自動化します。
+ [Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html) – Amazon Elastic Container Service (Amazon ECS) は、クラスターでコンテナの実行、停止、管理に使用される、高度にスケーラブルで高速のコンテナ管理サービスです。タスクとサービスは、 AWS Fargate で管理されているサーバーレスインフラストラクチャで実行できます。または、インフラストラクチャをより詳細に制御するために、管理する Amazon Elastic Compute Cloud (Amazon EC2) インスタンスのクラスターでタスクとサービスを実行できます。
+ [Docker](https://www.docker.com/) — Dockerを使用すると、開発者は任意のアプリケーションを軽量、ポータブル、自給自足のコンテナとして梱包、出荷、実行する上で役立ちます。
**コード**
このパターンのコードは、`cicdstarter.zip` および `starter-code.zip` ファイル (添付) にあります。
## エピック
### 環境をセットアップします。
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| AWS CDK の作業ディレクトリを設定します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-build-ci-cd-pipelines-and-amazon-ecs-clusters-for-microservices-using-aws-cdk.html) | AWS DevOps、クラウドインフラストラクチャ |
### 共有インフラストラクチャの作成
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| 共有インフラストラクチャを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-build-ci-cd-pipelines-and-amazon-ecs-clusters-for-microservices-using-aws-cdk.html) | AWS DevOps、クラウドインフラストラクチャ |
| AWS CloudFormation スタックを監視します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-build-ci-cd-pipelines-and-amazon-ecs-clusters-for-microservices-using-aws-cdk.html) | AWS DevOps、クラウドインフラストラクチャ |
| AWS CloudFormation スタックをテストします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-build-ci-cd-pipelines-and-amazon-ecs-clusters-for-microservices-using-aws-cdk.html)2 つの VPC の ID と、両方の VPC のデフォルトセキュリティグループのセキュリティグループ ID が記録されていることを確認します。 | AWS DevOps、クラウドインフラストラクチャ |
### マイクロサービスの CI/CD パイプラインの作成
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| マイクロサービスのインフラストラクチャーを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-build-ci-cd-pipelines-and-amazon-ecs-clusters-for-microservices-using-aws-cdk.html)ディレクトリの `cdk.json` ファイルを使用して、両方のコマンドの値を指定することもできます。 | AWS DevOps、クラウドインフラストラクチャ |
| AWS CloudFormation スタックを監視します。 | AWS CloudFormation コンソールを開き、`myservice1-cicd-stack` スタックの進捗状況をモニタリングします。最終的に、ステータスは `CREATE_COMPLETE`* に変わります。* | AWS DevOps、クラウドインフラストラクチャ |
| AWS CloudFormation スタックをテストします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-build-ci-cd-pipelines-and-amazon-ecs-clusters-for-microservices-using-aws-cdk.html) | |
| パイプラインを使用します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-build-ci-cd-pipelines-and-amazon-ecs-clusters-for-microservices-using-aws-cdk.html) | AWS DevOps、クラウドインフラストラクチャ |
| 各マイクロサービスにこのエピックを繰り返します。 | このエピックのタスクを繰り返して、各マイクロサービスの CI/CD パイプラインを作成します。 | AWS DevOps、クラウドインフラストラクチャ |
## 関連リソース
+ [Python と AWS CDK の併用](https://docs.aws.amazon.com/cdk/latest/guide/work-with-cdk-python.html)
+ [AWS CDK Python リファレンス](https://docs.aws.amazon.com/cdk/api/latest/python/index.html)
+ [AWS CDK を使用して AWS Fargate サービスを作成する](https://docs.aws.amazon.com/cdk/latest/guide/ecs_example.html)
## 追加情報
**`cdk synth`コマンド**
```
cdk synth --context aws_account= --context aws_region= --context vpc_nonprod_id= --context vpc_prod_id= --context ecssg_nonprod_id=< default_security_group_id_of_non-production_VPC> --context ecssg_prod_id= --context code_commit_s3_bucket_for_code= --context code_commit_s3_object_key_for_code= --context microservice_name=
```
**`cdk deploy `コマンド**
```
cdk deploy --context aws_account= --context aws_region= --context vpc_nonprod_id= --context vpc_prod_id= --context ecssg_nonprod_id=< default_security_group_id_of_non-production_VPC> --context ecssg_prod_id= --context code_commit_s3_bucket_for_code= --context code_commit_s3_object_key_for_code= --context microservice_name=
```
## アタッチメント
このドキュメントに関連する追加コンテンツにアクセスするには、次のファイルを解凍してください。「[attachment.zip](samples/p-attach/05ac2cad-408e-433f-8150-0a2b71f63cfd/attachments/attachment.zip)」
# GitHub Actions と Terraform を使用して Docker イメージを構築し Amazon ECR にプッシュする
*Ruchika Modi (Amazon Web Services)*
## 概要
このパターンでは、再利用可能な GitHub ワークフローを作成して Dockerfile を構築し、結果のイメージを Amazon Elastic Container Registry (Amazon ECR) にプッシュする方法について説明します。このパターンは、Terraform と GitHub Actions を使用して Dockerfile のビルドプロセスを自動化します。これにより、人為的ミスの可能性が最小限に抑えられ、デプロイ時間を大幅に短縮できます。
GitHub リポジトリのメインブランチへの GitHub プッシュアクションにより、リソースのデプロイが開始されます。このワークフローでは、GitHub 組織とリポジトリ名の組み合わせに基づいて一意の Amazon ECR リポジトリが作成されます。その後、Dockerfile イメージが Amazon ECR リポジトリにプッシュされます。
## 前提条件と制限事項
**前提条件**
+ アクティブな AWS アカウント。
+ アクティブな GitHub アカウント。
+ [GitHub リポジトリ](https://docs.github.com/en/get-started/quickstart/create-a-repo)。
+ Terraform バージョン 1 以降が[インストールされ、設定されている](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli)こと。
+ [Terraform バックエンド](https://developer.hashicorp.com/terraform/language/settings/backends/s3)の Amazon Simple Storage Service (Amazon S3) バケット。
+ Terraform の状態ロックと整合性のための [Amazon DynamoDB](https://www.googleadservices.com/pagead/aclk?sa=L&ai=DChcSEwjO95K9xqCCAxW-KIMDHfOvD7IYABADGgJzZg&gclid=EAIaIQobChMIzveSvcagggMVviiDAx3zrw-yEAAYASADEgJYWfD_BwE&ohost=www.google.com&cid=CAASJuRoKjv_llGjIU3liZ4T2IRecPqw0dVHSvjZ7bee1lvcc36K_lO_&sig=AOD64_1b294pq65HiFN-T1YxQAuXmRu_hw&adurl&ved=2ahUKEwjhiY29xqCCAxUgzjgGHRu6CAIQqyQoAnoECAkQDQ) テーブル。テーブルには、データ型が `String` の `LockID` という名前のパーティションキーが必要です。これが設定されていない場合、状態ロックは無効になります。
+ Terraform の Amazon S3 バックエンドを設定するアクセス許可を持つ AWS Identity and Access Management (IAM) ロール。設定の手順については、[Terraform のドキュメント](https://developer.hashicorp.com/terraform/language/settings/backends/s3#assume-role-configuration)を参照してください。
**制限事項**
この再利用可能なコードは、GitHub Actions でのみテストされています。
## アーキテクチャ
**ターゲットテクノロジースタック**
+ Amazon ECR リポジトリ
+ GitHub Actions
+ Terraform
**ターゲットアーキテクチャ**
![\[再利用可能な GitHub ワークフローを作成して Dockerfile を構築し、Amazon ECR にイメージをプッシュするワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/c39c110e-cbe5-459e-a0aa-de27e884fb10/images/298e0e16-3054-49b7-8695-db510e0df2df.png)
この図表は、以下を示すものです:
1. ユーザーが Dockerfile と Terraform テンプレートを GitHub リポジトリに追加します。
2. これらの追加により、GitHub Actions ワークフローが開始されます。
3. ワークフローは、Amazon ECR リポジトリが存在するかどうかをチェックします。既存のものがなければ、GitHub の組織とリポジトリ名に基づいてリポジトリが作成されます。
4. Dockerfile が構築され、Amazon ECR リポジトリにイメージがプッシュされます。
## ツール
**Amazon サービス**
+ [Amazon Elastic Container Registry (Amazon ECR)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html) は、セキュリティ、スケーラビリティ、信頼性を備えたマネージドコンテナレジストリサービスです。
**その他のツール**
+ [GitHub Actions](https://docs.github.com/en/actions) は GitHub プラットフォームに統合されており、GitHub リポジトリ内のワークフローの作成、共有、実行に役立ちます。GitHub Actions を使用して、コードの構築、テスト、デプロイなどのタスクを自動化できます。
+ [Terraform](https://developer.hashicorp.com/terraform/intro) は HashiCorp の提供する infrastructure as code (IaC) ツールであり、クラウドおよびオンプレミスインフラストラクチャの作成と管理を支援します。
**コードリポジトリ**
このパターンのコードは、GitHub の [Docker ECR Actions ワークフロー](https://github.com/aws-samples/docker-ecr-actions-workflow)リポジトリで利用できます。
+ GitHub Actions を作成すると、Docker ワークフローファイルはこのリポジトリの `/.github/workflows/` フォルダに保存されます。このソリューションのワークフローは [workflow.yaml](https://github.com/aws-samples/docker-ecr-actions-workflow/blob/main/.github/workflows/workflow.yaml) ファイル内にあります。
+ `e2e-test` フォルダには、参照およびテスト用のサンプル Dockerfile が用意されています。
## ベストプラクティス
+ Dockerfiles を記述するためのベストプラクティスについては、[Docker ドキュメント](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/)を参照してください。
+ [Amazon ECR の VPC エンドポイント](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html)を使用します。VPC エンドポイントには AWS PrivateLink が使用されています。これは、プライベート IP アドレスを介して Amazon ECR API にプライベートにアクセスするためのテクノロジーです。Fargate 起動タイプを使用する Amazon ECS タスクの場合、VPC エンドポイントを利用することで、タスクにパブリック IP アドレスを割り当てることなく、Amazon ECR からプライベートイメージをプルできます。
## エピック
### OIDC プロバイダーと GitHub リポジトリを設定する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| OpenID Connect を設定します。 | OpenID Connect (OIDC) プロバイダーを作成します。このプロバイダーは、このアクションで使用される IAM ロールの信頼ポリシーで使用します。手順については、GitHub ドキュメントの「[Configuring OpenID Connect in Amazon Web Services](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services)」を参照してください。 | AWS 管理者、AWS DevOps、AWS 全般 |
| GitHub リポジトリのクローンを作成します。 | GitHub [Docker ECR Actions ワークフロー](https://github.com/aws-samples/docker-ecr-actions-workflow)リポジトリのクローンをローカルフォルダに作成します。$git clone https://github.com/aws-samples/docker-ecr-actions-workflow
| DevOps エンジニア |
### GitHub の再利用可能なワークフローをカスタマイズし、Docker イメージをデプロイする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| Docker ワークフローを開始するイベントをカスタマイズします。 | このソリューションのワークフローは [workflow.yaml](https://github.com/aws-samples/docker-ecr-actions-workflow/blob/main/.github/workflows/workflow.yaml) 内にあります。このスクリプトは現在、`workflow_dispatch` イベントを受信したときにリソースをデプロイするように設定されています。この設定をカスタマイズするには、イベントを `workflow_call` に変更し、このワークフローを別の親ワークフローから呼び出します。 | DevOps エンジニア |
| ワークフローをカスタマイズします。 | [Workflow.yaml](https://github.com/aws-samples/docker-ecr-actions-workflow/blob/main/.github/workflows/workflow.yaml) ファイルは、動的で再利用可能な GitHub ワークフローを作成するように設定されています。このファイルを編集してデフォルト設定をカスタマイズすることもできますが、`workflow_dispatch` イベントを使用してデプロイを手動で開始している場合は、GitHub Actions コンソールからの入力値を渡すこともできます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/build-and-push-docker-images-to-amazon-ecr-using-github-actions-and-terraform.html) | DevOps エンジニア |
| Terraform テンプレートをデプロイします。 | このワークフローにより、設定済みの GitHub イベントに基づいて、Amazon ECR リポジトリを作成する Terraform テンプレートが自動的にデプロイされます。これらのテンプレートは、[Github リポジトリのルート](https://github.com/aws-samples/docker-ecr-actions-workflow/tree/main)にある `.tf` ファイルとして使用できます。 | AWS DevOps、DevOps エンジニア |
## トラブルシューティング
| 問題 | ソリューション |
| --- | --- |
| Amazon S3 と DynamoDB を Terraform リモートバックエンドとして設定する際の問題またはエラー。 | [Terraform ドキュメント](https://developer.hashicorp.com/terraform/language/settings/backends/s3)の指示に従って、リモートバックエンド設定のための Amazon S3 および DynamoDB リソースに必要となるアクセス許可を設定します。 |
| `workflow_dispatch` イベントでワークフローを実行または開始できない。 | `workflow_dispatch` イベントからデプロイするように設定されたワークフローは、このワークフローがメインブランチでも設定されている場合にのみ機能します。 |
## 関連リソース
+ [Reusing workflows](https://docs.github.com/en/actions/using-workflows/reusing-workflows) (GitHub ドキュメント)
+ [Triggering a workflow](https://docs.github.com/en/actions/using-workflows/triggering-a-workflow) (GitHub ドキュメント)
# AWS CodeCommit、AWS CodePipeline、AWS Device Farm を使用して iOS アプリを構築してテストする
*Abdullahi Olaoye、Amazon Web Services*
## 概要
このパターンでは、AWS CodePipeline を使用して AWS 上の実際のデバイスで iOS アプリケーションを構築してテストする、継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインを作成する手順の概要を示しています。このパターンでは、AWS CodeCommit を使用してアプリケーションコードを保存し、Jenkins のオープンソースツールを使用して iOS アプリケーションを構築し、AWS Device Farm を使用して構築したアプリケーションを実際のデバイス上でテストします。これらの 3 つのフェーズは、AWS CodePipeline を使用してパイプラインにまとめてオーケストレーションされます。
このパターンは、AWS DevOps ブログの「[AWS DevOps とモバイルサービスを使用した iOS および iPadOS アプリの構築とテスト](https://aws.amazon.com/blogs/devops/building-and-testing-ios-and-ipados-apps-with-aws-devops-and-mobile-services/)」の投稿に基づいています。詳細な手順については、このブログ記事を参照してください。
## 前提条件と制限事項
**前提条件**
+ アクティブな AWS アカウント
+ Apple 開発者アカウント
+ ビルドサーバー (macOS)
+ [Xcode](https://developer.apple.com/xcode/) バージョン 11.3 (ビルドサーバーにインストールしてセットアップ済み)
+ AWS コマンドラインインターフェイス (AWS CLI) を[インストール](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv1.html)して[設定済み](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html)
+ [Git](https://git-scm.com/docs) の基本的な知識
**制限事項**
+ アプリケーションビルドサーバーは macOS を実行していることが必要です。
+ CodePipeline が構築を開始するためにリモートで接続できるように、ビルドサーバーにはパブリック IP アドレスが必要です。
## アーキテクチャ
**ソーステクノロジースタック**
+ シミュレータを使用するか、物理デバイス上で手動テストを行うオンプレミスの iOS アプリケーション構築プロセス
**ターゲットテクノロジースタック**
+ アプリケーションのソースコードを保存するための AWS CodeCommit リポジトリ
+ Xcode を使用してアプリケーションを構築するための Jenkins サーバー
+ 実際のデバイスでアプリケーションをテストするための AWS Device Farm デバイスプール
**ターゲットアーキテクチャ**
ユーザーがソースリポジトリに変更をコミットすると、パイプライン (AWS CodePipeline) はソースリポジトリからコードを取得し、Jenkins ビルドを開始して、アプリケーションコードを Jenkins に渡します。ビルドの完了後、パイプラインはビルドアーティファクトを取得し、AWS Device Farm ジョブを開始してデバイスプールに対してアプリケーションをテストします。
![\[CI/CD パイプラインは AWS CodePipeline を使用して、実際のデバイスで iOS アプリケーションを構築してテストします。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/06fbd82f-4aed-441c-818c-5f89f56af78e/images/0ae3d7b6-b40c-44ef-9580-8c8266c3d841.png)
## ツール
+ [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) はフルマネージド型の継続的デリバリーサービスで、アプリケーションとインフラストラクチャの更新を迅速に、かつ高い信頼性で行うために、パイプラインのリリースを自動化します。CodePipeline はお客様が定義したリリースモデルに基づき、コードチェンジがあった場合のフェーズの構築、テスト、およびデプロイを自動化します。
+ [AWS CodeCommit](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html) は、安全な Git ベースのリポジトリをホストする完全マネージド型のソース管理サービスです。これにより、セキュアで拡張性の高いエコシステムで、チームによるコードの共同作業が簡単になります。CodeCommit を使用することにより、独自のソース管理システムを運用したり、そのインフラストラクチャをスケールしたりする必要がなくなります。
+ [AWS Device Farm](https://docs.aws.amazon.com/devicefarm/latest/developerguide/welcome.html) は、テストインフラストラクチャをプロビジョニングして管理しなくても、さまざまなデスクトップブラウザと実際のモバイルデバイスでテストすることで、ウェブアプリやモバイルアプリの品質を向上させることができるアプリケーションテストサービスです。
+ [Jenkins](https://www.jenkins.io/) は、デベロッパーがソフトウェアを確実に構築、テスト、デプロイできるようにするオープンソースのオートメーションサーバーです。
## エピック
### ビルド環境をセットアップします。
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| macOS を実行しているビルドサーバーに Jenkins をインストールします。 | Jenkins を使用してアプリケーションを構築するので、最初に Jenkins をビルドサーバーにインストールする必要があります。このタスクとそれ以降のタスクの詳細な手順については、このパターンの最後にある「[関連リソース](#build-and-test-ios-apps-with-aws-codecommit-aws-codepipeline-and-aws-device-farm-resources)」セクションで、AWS ブログ投稿「[AWS DevOps とモバイルサービスを使用して、iOS および iPadOS のアプリを構築してテストする](https://aws.amazon.com/blogs/devops/building-and-testing-ios-and-ipados-apps-with-aws-devops-and-mobile-services/)」とその他のリソースを参照してください。 | DevOps |
| Jenkins を設定します。 | 画面上の指示に従って Jenkins を設定します。 | DevOps |
| Jenkins 用の AWS CodePipeline プラグインをインストールします。 | Jenkins が AWS CodePipeline サービスとやり取りできるようにするには、このプラグインを Jenkins サーバーにインストールする必要があります。 | DevOps |
| 自由形式の Jenkins プロジェクトを作成します。 | Jenkins で、自由形式のプロジェクトを作成します。トリガーやその他のビルド設定オプションを指定するようにプロジェクトを設定します。 | DevOps |
### AWS Device Farm を設定する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| Device Farm プロジェクトを作成します。 | AWS Device Farm コンソールを開きます。テスト用のプロジェクトとデバイスプールを作成します。手順については、ブログ記事を参照してください。 | 開発者 |
### ソースリポジトリを設定する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| CodeCommit リポジトリを作成します。 | ソースコードを保存するリポジトリを作成します。 | DevOps |
| アプリケーションコードをリポジトリにコミットします。 | 作成した CodeCommit リポジトにリコネクトします。 コードをローカルマシンからリポジトリにプッシュします。 | DevOps |
### パイプラインを設定する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| AWS CodePipeline でパイプラインを作成します。 | AWS CodePipeline コンソールを使用してパイプラインを作成します。パイプラインは CI/CD プロセスのすべてのフェーズをオーケストレーションします。手順については、AWS ブログ投稿「[AWS DevOps とモバイルサービスを使用して、iOS および iPadOS のアプリを構築してテストする](https://aws.amazon.com/blogs/devops/building-and-testing-ios-and-ipados-apps-with-aws-devops-and-mobile-services/)」を参照してください。 | DevOps |
| パイプラインにテストステージを追加します。 | テストステージを追加して AWS Device Farm と統合するには、パイプラインを編集します。 | DevOps |
| パイプラインを開始します。 | パイプラインと CI/CD プロセスを開始するには、**[変更をリリース]** を選択します。 | DevOps |
### アプリケーションテストの結果を表示します。
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| テスト結果を確認します。 | AWS Device Farm コンソールで、作成したプロジェクトを選択し、テストの結果を確認します。コンソールには、各テストの詳細が表示されます。 | 開発者 |
## 関連リソース
**このパターンのステップバイステップの説明**
+ 「[AWS DevOps とモバイルサービスを使用した iOS および iPadOS アプリの構築とテスト](https://aws.amazon.com/blogs/devops/building-and-testing-ios-and-ipados-apps-with-aws-devops-and-mobile-services/)」(AWS DevOps ブログ記事)
**AWS Device Farm を設定する**
+ [AWS Device Farm コンソール](https://console.aws.amazon.com/devicefarm)
**ソースリポジトリを設定する**
+ 「[新しい AWS CodeCommit リポジトリの作成](https://docs.aws.amazon.com/codecommit/latest/userguide/how-to-create-repository.html)」
+ 「[AWS CodeCommit リポジトリに接続する](https://docs.aws.amazon.com/codecommit/latest/userguide/how-to-connect.html)」
「**パイプラインを設定する**」
+ 「[AWS CodePipeline コンソール](https://console.aws.amazon.com/codesuite/codepipeline/home)」
**追加リソース**
+ 「[AWS CodePipeline ドキュメント](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)」
+ 「[AWS CodeCommit ドキュメント](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html)」
+ 「[AWS Device Farm ドキュメント](https://docs.aws.amazon.com/devicefarm/latest/developerguide/welcome.html)」
+ 「[Jenkins ドキュメント](https://www.jenkins.io/doc/)」
+ 「[macOS での Jenkins のインストール](https://www.jenkins.io/download/weekly/macos/)」
+ 「[Jenkins 用の AWS CodePipeline プラグイン](https://plugins.jenkins.io/aws-codepipeline/)」
+ 「[Xcode のインストール](https://developer.apple.com/xcode/)」
+ AWS CLI の [インストール](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv1.html)と[設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html)
+ 「[Git ドキュメント](https://git-scm.com/docs)」
# Amazon EKS で実行されているアプリケーションの相互 TLS 認証を設定する
*Mahendra Revanasiddappa (Amazon Web Services)*
## 概要
証明書ベースの相互 Transport Layer Security (TLS) は、サーバーとクライアント間の双方向ピア認証を提供するオプションの TLS コンポーネントです。相互 TLS では、クライアントはセッションネゴシエーションプロセス中に X.509 証明書を提供する必要があります。サーバーは、この証明書を使用してクライアントを識別し、認証します。
相互 TLS は、モノのインターネット (IoT) アプリケーションの一般的な要件であり、企業間 (B2B) アプリケーションや[オープンバンキング](https://docs.aws.amazon.com/wellarchitected/latest/financial-services-industry-lens/open-banking.html)などの標準に使用できます。
このパターンでは、NGINX Ingress Controller を使用して Amazon Elastic Kubernetes Service (Amazon EKS) クラスターで実行されているアプリケーションの相互 TLS を設定する方法を説明します。イングレスリソースに注釈を付けることで、NGINX イングレスコントローラーのビルトイン相互 TLS 機能を有効にできます。NGINX コントローラーの相互 TLS アノテーションについて詳しくは、Kubernetes ドキュメントの「[クライアント証明書認証](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#client-certificate-authentication)」を参照してください。
**重要**
このパターンでは、自己署名証明書を使用します。このパターンはテストクラスターでのみ使用し、本番環境では使用しないことをお勧めします。このパターンを本番環境で使用する場合は、「[AWS Private Certificate Authority (AWS Private CA) (AWS Private CA)](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html)」または既存のパブリックキーインフラストラクチャ (PKI) 標準を使用してプライベート証明書を発行できます。
## 前提条件と制限事項
**前提条件**
+ アクティブな Amazon Web Services (AWS)アカウント。
+ 既存の Amazon EKS クラスター。
+ AWS コマンドラインインターフェイス(AWS CLI) バージョン 1.7 以降。macOS、Linux、または Windows にインストールされ、設定されている。
+ Amazon EKS クラスターにアクセスするためにインストールして設定した kubectl コマンドラインユーティリティ。詳細については、Amazon EKS ドキュメントの「[kubectl のインストール](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)」を参照してください。
+ アプリケーションをテストするための既存のドメインネームシステム (DNS) 名。
**制限事項**
+ このパターンでは、自己署名証明書を使用します。このパターンはテストクラスターでのみ使用し、本番環境では使用しないことをお勧めします。
## アーキテクチャ
![\[Amazon EKS で実行されているアプリケーションの相互 TLS 認証の設定\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/ae2761e3-7ed2-4c2a-ba54-a4ddce8a1e7e/images/cefc60f9-2f29-4052-b7ae-df4eb6395e1c.png)
テクノロジースタック
+ Amazon EKS
+ Amazon Route 53
+ kubectl
## ツール
+ 「[Amazon Elastic Kubernetes Service (Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html)」は、AWS で Kubernetes を実行する際に役立ち、独自の Kubernetes コントロールプレーンまたはノードをインストールまたは維持する必要はありません。
+ [Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) は、高可用性でスケーラブルな DNS Web サービスです。
+ 「[Kubectl](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)」は、Amazon EKS クラスターを操作するために使用するコマンドラインユーティリティです。
## エピック
### 自己署名証明書を生成します
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| CA キーと証明書を生成します。 | 次のコマンドを実行して、証明機関 (CA) キーと証明書を生成します。openssl req -x509 -sha256 -newkey rsa:4096 -keyout ca.key -out ca.crt -days 356 -nodes -subj '/CN=Test Cert Authority'
| DevOps エンジニア |
| サーバーキーと証明書を生成し、CA 証明書で署名します。 | サーバーキーと証明書を生成し、次のコマンドを実行して CA 証明書で署名します。openssl req -new -newkey rsa:4096 -keyout server.key -out server.csr -nodes -subj '/CN= ' && openssl x509 -req -sha256 -days 365 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crt
`` は、必ず既存のドメイン名に置き換えてください。 | DevOps エンジニア |
| クライアントキーと証明書を生成し、CA 証明書で署名します。 | クライアントキーと証明書を生成し、次のコマンドを実行して CA 証明書で署名します。openssl req -new -newkey rsa:4096 -keyout client.key -out client.csr -nodes -subj '/CN=Test' && openssl x509 -req -sha256 -days 365 -in client.csr -CA ca.crt -CAkey ca.key -set_serial 02 -out client.crt
| DevOps エンジニア |
### NGINX イングレスコントローラーをデプロイします。
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| Amazon EKS クラスターに NGINX イングレスコントローラーをデプロイします。 | 次のコマンドを使用して、NGINX イングレスコントローラをデプロイします。kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.7.0/deploy/static/provider/aws/deploy.yaml
| DevOps エンジニア |
| NGINX Ingress Controller サービスが実行中であることを確認します。 | 以下のコマンドを使用して、NGINX イングレスコントローラサービスが実行されていることをを確認します。kubectl get svc -n ingress-nginx
サービスアドレスのフィールドに Network Load Balancer のドメイン名が含まれていることを確認してください。 | DevOps エンジニア |
### Amazon EKS クラスターにネームスペースを作成して、相互 TLS をテストします。
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| Amazon EKS クラスターにネームスペースを作成します。 | 次のコマンドを実行して、Amazon EKS クラスターに `mtls` という名前の名前空間を作成します。kubectl create ns mtls
これにより、相互 TLS をテストするためのサンプルアプリケーションがデプロイされます。 | DevOps エンジニア |
### サンプルアプリケーションのデプロイとサービスを作成します。
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| Kubernetes デプロイメントとサービスを mtls 名前空間に作成します。 | `mtls.yaml` という名前のファイルを作成します。ファイルに次のコードを貼り付けます。kind: Deployment
apiVersion: apps/v1
metadata:
name: mtls-app
labels:
app: mtls
spec:
replicas: 1
selector:
matchLabels:
app: mtls
template:
metadata:
labels:
app: mtls
spec:
containers:
- name: mtls-app
image: hashicorp/http-echo
args:
- "-text=mTLS is working"
---
kind: Service
apiVersion: v1
metadata:
name: mtls-service
spec:
selector:
app: mtls
ports:
- port: 5678 # Default port for image
次のコマンドを実行して、`mtls` 名前空間に Kubernetes デプロイとサービスを作成します。kubectl create -f mtls.yaml -n mtls
| DevOps エンジニア |
| Kubernetes デプロイが作成されていることを確認します。 | デプロイが作成され、1 つのポッドが使用可能になっていることを確認するには、次のコマンドを実行します。kubectl get deploy -n mtls
| DevOps エンジニア |
| Kubernetes サービスが作成されていることを確認します。 | 次のコマンドを実行して、Kubernetes サービスが作成されたことを確認します。kubectl get service -n mtls
| DevOps エンジニア |
### mtls 名前空間にシークレットを作成します。
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| イングレスリソースにシークレットを作成します。 | 以下のコマンドを実行して、前に作成した証明書を使用して NGINX Ingress コントローラーのシークレットを作成します。kubectl create secret generic mtls-certs --from-file=tls.crt=server.crt --from-file=tls.key=server.key --from-file=ca.crt=ca.crt -n mtls
シークレットには、サーバーを識別するためのクライアント用のサーバー証明書と、クライアント証明書を検証するためのサーバー用の CA 証明書があります。 | DevOps エンジニア |
### mtls 名前空間に Ingress リソースを作成します。
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| mtls 名前空間にイングレスリソースを作成します。 | `ingress.yaml` という名前のファイルを作成します。ファイルに次のコードを貼り付けます (`` を既存のドメイン名に置き換えます)。apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/auth-tls-verify-client: "on"
nginx.ingress.kubernetes.io/auth-tls-secret: mtls/mtls-certs
name: mtls-ingress
spec:
ingressClassName: nginx
rules:
- host: "*."
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: mtls-service
port:
number: 5678
tls:
- hosts:
- "*."
secretName: mtls-certs
次のコマンドを実行して、`mtls` ネームスペースに Ingress リソースを作成します。kubectl create -f ingress.yaml -n mtls
つまり、NGINX Ingress コントローラーはトラフィックをサンプルアプリケーションにルーティングできます。 | DevOps エンジニア |
| Ingress リソースが作成されていることを確認します。 | 次のコマンドを実行して、Ingress リソースが作成されたことを確認します。kubectl get ing -n mtls
Ingress リソースのアドレスに、NGINX Ingress コントローラー用に作成されたロードバランサーが表示されていることを確認してください。 | DevOps エンジニア |
### ホスト名がロードバランサーを指すように DNS を設定します。
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| NGINX Ingress コントローラーのロードバランサーを指す CNAME レコードを作成します。 | AWS マネジメントコンソールにサインインし、Amazon Route 53 コンソールを開いて、NGINX イングレスコントローラーのロードバランサーに `mtls.` を指す正規名 (CNAME) レコードを作成します。詳細については、Route 53 ドキュメントの「[Route 53 コンソールを使用したレコードの作成](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-creating.html)」を参照してください。 | DevOps エンジニア |
### アプリケーションをテストする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| 証明書なしで相互 TLS セットアップをテストする。 | 以下のコマンドを実行してください。curl -k https://mtls.
「400 必要な SSL 証明書は送信されませんでした」というエラー応答が表示されるはずです。 | DevOps エンジニア |
| 証明書を使用して相互 TLS セットアップをテストします。 | 以下のコマンドを実行してください。curl -k https://mtls. --cert client.crt --key client.key
「mTLS は動作しています」という応答が返されるはずです。 | DevOps エンジニア |
## 関連リソース
+ 「[Amazon Route 53 コンソールを使用したレコードの作成](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-creating.html)」
+ 「[Amazon EKS の NGINX 入力コントローラーでのNetwork Load Balancer の使用](https://aws.amazon.com/blogs/opensource/network-load-balancer-nginx-ingress-controller-eks/)」
+ 「[クライアント証明書認証](https://kubernetes.github.io/ingress-nginx/examples/auth/client-certs/)」
# を使用して Amazon WorkSpaces アプリケーションリソースの作成を自動化する AWS CloudFormation
*Ram Kandaswamy (Amazon Web Services)*
## 概要
このパターンでは、 [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) テンプレート AWS クラウド を使用して での [Amazon WorkSpaces アプリケーション](https://aws.amazon.com/workspaces/applications/)リソースの作成を自動化するコードサンプルと手順を示します。このパターンは、 CloudFormation スタックを使用して、Image Builder、イメージ、フリートインスタンス、スタックなどの WorkSpaces アプリケーションアプリケーションリソースの作成を自動化する方法を示しています。デスクトップまたはアプリケーション配信モードを使用して、HTML5-compliantのブラウザで WorkSpaces アプリケーションアプリケーションをエンドユーザーにストリーミングできます。
## 前提条件と制限
**前提条件**
+ アクティブな AWS アカウント
+ WorkSpaces アプリケーションの利用規約の承諾
+ [フリート、スタック](https://docs.aws.amazon.com/appstream2/latest/developerguide/managing-stacks-fleets.html)、[Image Builder](https://docs.aws.amazon.com/appstream2/latest/developerguide/managing-image-builders.html) などの WorkSpaces アプリケーションリソースに関する基本的な知識
**制限事項**
+ WorkSpaces アプリケーションインスタンスに関連付けられた [AWS Identity and Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) (IAM) ロールは、そのインスタンスの作成後に変更することはできません。
+ Image Builder の作成後に WorkSpaces Applications Image Builder インスタンスのプロパティ ([サブネット](https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html#subnet-basics)や[セキュリティグループ](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html)など) を変更することはできません。
## アーキテクチャ
次の図は、 CloudFormation テンプレートを使用して WorkSpaces アプリケーションリソースの作成を自動化する方法を示しています。
![\[WorkSpaces アプリケーションリソースを自動的に作成するためのワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/4f0205f5-5b91-4832-9f0f-2135ae866226/images/cb578939-d9af-4f60-93c9-286881df4c3a.png)
この図表は、次のワークフローを示しています:
1. このパターンの[追加情報](#automate-the-creation-of-appstream-2-0-resources-using-aws-cloudformation-additional)セクションの YAML コードに基づいて CloudFormation テンプレートを作成します。
1. CloudFormation テンプレートは CloudFormation テストスタックを作成します。
1. (オプション) WorkSpaces アプリケーションを使用して Image Builder インスタンスを作成します。
1. (オプション) カスタムソフトウェアを使用して Windows イメージを作成します。
1. CloudFormation スタックは WorkSpaces Applications フリートインスタンスとスタックを作成します。
1. WorkSpaces アプリケーションリソースを HTML5-compliantのブラウザでエンドユーザーにデプロイします。
## ツール
+ [Amazon WorkSpaces Applications](https://docs.aws.amazon.com/appstream2/latest/developerguide/what-is-appstream.html) は、どこからでもデスクトップアプリケーションに瞬時にアクセスできるフルマネージド型のアプリケーションストリーミングサービスです。WorkSpaces Applications は、アプリケーションのホストと実行に必要な AWS リソースを管理し、自動的にスケールし、オンデマンドでユーザーへのアクセスを提供します。
+ [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) は、 AWS リソースのモデル化とセットアップ、迅速かつ一貫したプロビジョニング、ライフサイクル全体の管理に役立ちます。リソースを個別に管理する代わりに、テンプレートを使用してリソースとその依存関係を記述し、それらをスタックとしてまとめて起動して設定できます。複数の および にまたがるスタックを管理 AWS アカウント およびプロビジョニングできます AWS リージョン。
## ベストプラクティス
+ **Image Builder のネットワークアクセスを正しく設定**する – アウトバウンドのみのインターネットアクセスに NAT ゲートウェイを使用して、適切なインターネットアクセスで Virtual Private Cloud (VPC) サブネットで Image Builder を起動します。
イメージを作成する前に、必要なリソース (アプリケーションサーバー、データベース、ライセンスサーバーなど) へのネットワーク接続をテストします。VPC ルートテーブルで、必要なすべてのネットワークリソースへの接続が許可されていることを確認します。詳細については、WorkSpaces アプリケーションドキュメントの[「インターネットアクセス](https://docs.aws.amazon.com/appstream2/latest/developerguide/internet-access.html)」を参照してください。
+ フリー**ト容量をサービスクォータに対してプロアクティブにモニタリング**する – WorkSpaces Applications インスタンスタイプとサイズクォータは ごと AWS アカウント、 ごとです AWS リージョン。同じリージョン内に同じインスタンスタイプとサイズを使用するフリートが複数存在する場合、そのリージョン内のすべてのフリートインスタンスの総数は、該当するクォータ以下でなければなりません。詳細については、WorkSpaces [アプリケーションドキュメントの「フリートのトラブルシューティング](https://docs.aws.amazon.com/appstream2/latest/developerguide/troubleshooting-fleets.html)」を参照してください。
+ **フリートデプロイ前に Image Builder テストモードでアプリケーションをテスト**する – イメージを作成してフリートにデプロイする前に、必ず Image Builder テストモードでアプリケーションを検証します。テストモードは、エンドユーザーがフリートインスタンスに対して持つ制限されたアクセス許可をシミュレートします。詳細については、WorkSpaces アプリケーションドキュメントの[「Image Builders のトラブルシューティング](https://docs.aws.amazon.com/appstream2/latest/developerguide/troubleshooting-image-builder.html#troubleshooting-07)」を参照してください。
## エピック
### (オプション) WorkSpaces アプリケーションイメージを作成する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| カスタムソフトウェアをインストールしてイメージを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-the-creation-of-appstream-2-0-resources-using-aws-cloudformation.html)Windows AppLocker 機能を使用してイメージをさらにロックダウンすることを検討してください。 | AWS DevOps、クラウドアーキテクト |
### CloudFormation テンプレートをデプロイする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| CloudFormation テンプレートを更新します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-the-creation-of-appstream-2-0-resources-using-aws-cloudformation.html) | AWS システム管理者、クラウド管理者、クラウドアーキテクト、AWS 全般、AWS 管理者 |
| テンプレートを使用して CloudFormation スタックを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automate-the-creation-of-appstream-2-0-resources-using-aws-cloudformation.html) | アプリ所有者、AWS システム管理者、Windows エンジニア |
## トラブルシューティング
| 問題 | ソリューション |
| --- | --- |
| さまざまな問題 | 詳細については、WorkSpaces アプリケーションドキュメントの[「トラブルシューティング](https://docs.aws.amazon.com/appstream2/latest/developerguide/troubleshooting.html)」を参照してください。 |
## 関連リソース
**リファレンス**
+ [Amazon WorkSpaces アプリケーションの使用を開始する: サンプルアプリケーションのセットアップ](https://docs.aws.amazon.com/appstream2/latest/developerguide/getting-started.html)
+ [Amazon WorkSpaces アプリケーションフリートとスタックを作成する](https://docs.aws.amazon.com/appstream2/latest/developerguide/set-up-stacks-fleets.html)
**チュートリアルと動画**
+ [Amazon WorkSpaces アプリケーションユーザーワークフロー](https://www.youtube.com/watch?v=hVGQ87-Uhrc)
+ [レガシー Windows Forms アプリを Amazon WorkSpaces アプリケーションに移行する方法](https://www.youtube.com/watch?v=CIImtS2iVbg)
+ [AWS re:Invent 2018: Amazon WorkSpaces アプリケーションでデスクトップアプリケーションを安全に配信する (BAP201)](https://www.youtube.com/watch?v=xNIyc_inOhM)
## 追加情報
次のコードは、WorkSpaces アプリケーションリソースを自動的に作成するために使用できる CloudFormation テンプレートの例です。
```
AWSTemplateFormatVersion: 2010-09-09
Parameters:
SubnetIds:
Type: 'List'
testSecurityGroup:
Type: 'AWS::EC2::SecurityGroup::Id'
ImageName:
Type: String
Resources:
AppStreamFleet:
Type: 'AWS::AppStream::Fleet'
Properties:
ComputeCapacity:
DesiredInstances: 5
InstanceType: stream.standard.medium
Name: appstream-test-fleet
DisconnectTimeoutInSeconds: 1200
FleetType: ON_DEMAND
IdleDisconnectTimeoutInSeconds: 1200
ImageName: !Ref ImageName
MaxUserDurationInSeconds: 345600
VpcConfig:
SecurityGroupIds:
- !Ref testSecurityGroup
SubnetIds: !Ref SubnetIds
AppStreamStack:
Type: 'AWS::AppStream::Stack'
Properties:
Description: AppStream stack for test
DisplayName: AppStream test Stack
Name: appstream-test-stack
StorageConnectors:
- ConnectorType: HOMEFOLDERS
UserSettings:
- Action: CLIPBOARD_COPY_FROM_LOCAL_DEVICE
Permission: ENABLED
- Action: CLIPBOARD_COPY_TO_LOCAL_DEVICE
Permission: ENABLED
- Action: FILE_DOWNLOAD
Permission: ENABLED
- Action: PRINTING_TO_LOCAL_DEVICE
Permission: ENABLED
AppStreamFleetAssociation:
Type: 'AWS::AppStream::StackFleetAssociation'
Properties:
FleetName: appstream-test-fleet
StackName: appstream-test-stack
DependsOn:
- AppStreamFleet
- AppStreamStack
```
# Firelens ログルーターを使用して Amazon ECS 用のカスタムログパーサーを作成する
*Amazon Web Services、Varun Sharma*
## 概要
Firelensは、Amazon Elastic Container Service (Amazon ECS) と AWS Fargate 用のログルーターです。Firelens を使用して、Amazon ECS から Amazon CloudWatch やその他の転送先 ([Splunk](https://www.splunk.com/) や [Sumo Logic](https://www.sumologic.com/) など) にコンテナログをルーティングできます。Firelens は [Fluentd](https://www.fluentd.org/) または [Fluent Bit](https://fluentbit.io/) をロギングエージェントとして使用し、これにより [Amazon ECS タスク定義パラメータ](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html)を使用してログをルーティングできます。
ログをソースレベルで解析することを選択することで、ロギングデータを分析し、クエリを実行して、運用上の問題に効率的かつ効果的に対応できます。アプリケーションが異なればロギングパターンも異なるため、ログを構造化して最終転送先での検索を容易にするカスタムパーサーを使用する必要があります。
このパターンでは、カスタムパーサーを備えた Firelens ログルーターを使用して、Amazon ECS で実行されているサンプル Spring Boot アプリケーションから CloudWatch にログをプッシュします。その後、Amazon CloudWatch Logs Insights を使用して、カスタムパーサーによって生成されたカスタムフィールドに基づいてログをフィルタリングできます。
## 前提条件と制限事項
**前提条件**
+ アクティブな Amazon Web Services (AWS)アカウント。
+ ユーザーのローカルマシンにインストールされ、構成された AWS コマンドラインインターフェイス (AWS CLI)。
+ コンピュータにインストールされて構成されている Docker。
+ Amazon Elastic Container Registry (Amazon ECR) にある既存の Spring Boot ベースのコンテナ化アプリケーション。
## アーキテクチャ
![\[Firelens ログルーターを使用して、Amazon ECS で実行されているアプリケーションから CloudWatch にログをプッシュします。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/e82b4992-c4e0-4af5-b87e-cb0b1c1ed8c9/images/ef60e087-965a-40e9-9f80-35edbda2befe.png)
テクノロジースタック
+ CloudWatch
+ Amazon ECR
+ Amazon ECS
+ Fargate
+ Docker
+ Fluent Bit
## ツール
+ [Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html) – Amazon Elastic Container Registry (Amazon ECR) は、セキュリティ、スケーラビリティ、信頼性を備えた AWS マネージドコンテナイメージレジストリサービスです。
+ [Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html) – Amazon Elastic Container Service (Amazon ECS) は、クラスターでコンテナの実行、停止、管理を簡単に行うことのできる、高度にスケーラブルで高速なコンテナ管理サービスです。
+ [ Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) - IAM は、AWS サービスへのアクセスをセキュアに制御するためのウェブサービスです。
+ [ CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) – AWS コマンドラインインターフェイス (AWS CLI) は、オープンソースのツールであり、コマンドラインシェルのコマンドを使用して AWS サービスとやり取りすることができます。
+ [Docker](https://www.docker.com/) — Docker は、アプリケーションの開発、出荷、実行のためのオープンプラットフォームです。
**Code**
このパターンには以下のファイルが添付されています。
+ `customFluentBit.zip` – カスタムの解析と構成を追加するためのファイルが含まれています。
+ `firelens_policy.json` – IAM ポリシーを作成するためのポリシードキュメントが含まれます。
+ `Task.json` – Amazon ECS のサンプルタスク定義が含まれています。
## エピック
### カスタム Fluent Bit イメージの作成
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| Amazon ECR リポジトリを作成します。 | AWS マネジメントコンソールにサインインし、Amazon ECR コンソールを開いて、`fluentbit_custom` というリポジトリを作成します。これに関する詳細については、Amazon ECR のドキュメントの「[リポジトリを作成する](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-create.html)」を参照してください。 | システム管理者、開発者 |
| customFluentBit.zip パッケージを解凍する。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-a-custom-log-parser-for-amazon-ecs-using-a-firelens-log-router.html) | |
| カスタム Docker イメージを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-a-custom-log-parser-for-amazon-ecs-using-a-firelens-log-router.html)詳細については、Amazon ECR のドキュメントの「[Docker イメージの作成](https://docs.aws.amazon.com/AmazonECR/latest/userguide/docker-push-ecr-image.html)」を参照してください。 | システム管理者、開発者 |
### Amazon ECS クラスターの設定
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| Amazon ECS クラスターを作成します。 | Amazon ECS クラスターを作成するには、Amazon ECS ドキュメントの「[クラスターの作成](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create_cluster.html)」の「*ネットワーク専用テンプレート*」セクションの指示に従います。Amazon ECS クラスター用の新しい仮想プライベートクラウド (VPC) を作成する場合は、必ず、**[VPC の作成]** を選択してください。 | システム管理者、開発者 |
### Amazon ECS タスクを設定する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| Amazon ECS タスク実行 IAM ロールを設定します。 | `AmazonECSTaskExecutionRolePolicy` マネージドポリシーを使用して Amazon ECS タスク実行 IAM ロールを作成します。これに関する詳細については、Amazon ECS デベロッパーガイド の 「[Amazon ECS タスク実行 IAM ロール](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_execution_IAM_role.html)」 を参照してください。IAM ロールの Amazon リソースネーム (ARN) は必ず記録してください。 | システム管理者、開発者 |
| IAM ポリシーを Amazon ECS タスク実行 IAM ロールに添付する。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-a-custom-log-parser-for-amazon-ecs-using-a-firelens-log-router.html) | システム管理者、開発者 |
| Amazon ECS タスク定義のセットアップ | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-a-custom-log-parser-for-amazon-ecs-using-a-firelens-log-router.html)これに関する詳細については、Amazon ECS ドキュメントの「[タスク定義の作成」](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-task-definition.html)」を参照してください。 | システム管理者、開発者 |
### Amazon ECS タスクを実行する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| Amazon ECS タスクを実行します。 | Amazon ECS コンソールで [**クラスター**] を選択し、先に作成したクラスターを選択して、スタンドアロンタスクを実行します。これに関する詳細については、Amazon ECS ドキュメントの「[スタンドアロンタスクの実行](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_run_task.html)」を参照してください。 | システム管理者、開発者 |
### CloudWatch のログを検証する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| ログを検証します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-a-custom-log-parser-for-amazon-ecs-using-a-firelens-log-router.html) | システム管理者、開発者 |
## 関連リソース
+ [Amazon ECS のドッカーの基本](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/docker-basics.html)
+ [AWS Fargate 上の Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/AWS_Fargate.html)
+ [基本的なサービスパラメーターの構成](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/basic-service-params.html)
## アタッチメント
このドキュメントに関連する追加コンテンツにアクセスするには、次のファイルを解凍してください。「[attachment.zip](samples/p-attach/e82b4992-c4e0-4af5-b87e-cb0b1c1ed8c9/attachments/attachment.zip)」
# GitHub Actions と Terragrunt を使用した API 駆動型リソースオーケストレーションフレームワークの作成
*Amazon Web Services、Tamilselvan P、Abhigyan Dandriyal、Sandeep Gawande、および Akash Kumar*
## 概要
このパターンでは、GitHub Actions ワークフローを活用して、標準化された JSON ペイロードによるリソースのプロビジョニングを自動化するため、手動設定が不要になります。この自動化されたパイプラインは、デプロイライフサイクル全体を管理し、カスタム UI コンポーネントから ServiceNow まで、さまざまなフロントエンドシステムとスムーズに統合できます。このソリューションの柔軟性により、ユーザーは標準化されたプロセスを維持しながら、推奨されるインターフェイスを介してシステムとやり取りできます。
パイプラインアーキテクチャは設定可能で、さまざまな組織要件を満たすように調整できます。実装例では、Amazon Virtual Private Cloud (Amazon VPC) と Amazon Simple Storage Service (Amazon S3) のプロビジョニングに焦点を当てています。このパターンは、組織にまたがる要望を標準化し、一貫した統合ポイントを提供することで、一般的なクラウドリソース管理の課題に効果的に対処します。このアプローチにより、チームは標準化を確保しながらリソースを簡単に要求および管理することができます。
## 前提条件と制限
**前提条件**
+ アクティブな AWS アカウント
+ 設定されたリポジトリにアクセスできるアクティブな GitHub アカウント
**制限事項**
+ 新しいリソースでは、リポジトリ設定に `terragrunt.hcl` ファイルを手動で追加する必要があります。
+ 一部の 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)」を参照して、サービスのリンクを選択してください。
## アーキテクチャ
次の図は、このパターンのコンポーネントとワークフローを示しています。
![\[GitHub Actions と Terraform を使用してリソースのプロビジョニングを自動化するワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/bff5d70e-e8f1-454a-94bc-60e8cc16e69f/images/d4a768c8-4e11-493c-85ed-f4bf7e76ce60.png)
アーキテクチャ図は次のアクションを示しています。
1. ユーザーは JSON ペイロードを GitHub Actions に送信することで、自動化のパイプラインを実行できます。
1. GitHub Actions パイプラインは、ペイロードの仕様に基づいて、Terragrunt リポジトリと Terraform リポジトリから必要なリソースコードを取得します。
1. パイプラインは、指定された AWS アカウント ID を使用して適切な AWS Identity and Access Management (IAM) ロールを引き受けます。次に、パイプラインはリソースをターゲットにデプロイ AWS アカウント し、アカウント固有の Amazon S3 バケットと Amazon DynamoDB テーブルを使用して Terraform 状態を管理します。
各 AWS アカウント には、セキュアアクセス用の IAM ロール、Terraform ステートストレージ用の Amazon S3 バケット、およびステートロック用の DynamoDB テーブルが含まれています。この設計により、 AWS アカウント全体で制御された自動リソースデプロイが可能になります。デプロイプロセスは、各アカウントの専用の Amazon S3 バケットと IAM ロールを通じて、適切な状態管理とアクセスコントロールを維持します。
## ツール
**AWS のサービス**
+ [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html) は、フルマネージド NoSQL データベースサービスです。高速かつ予測可能でスケーラブルなパフォーマンスを提供します。
+ [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、誰を認証し、誰に使用する権限を付与するかを制御することで、 AWS リソースへのアクセスを安全に管理するのに役立ちます。
+ [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) は、あらゆる量のデータを保存、保護、取得できるクラウドベースのオブジェクトストレージサービスです。
+ [Amazon Virtual Private Cloud (Amazon VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) は、定義した仮想ネットワークに AWS リソースを起動するのに役立ちます。この仮想ネットワークは、ユーザー自身のデータセンターで運用されていた従来のネットワークと似ていますが、 AWSのスケーラブルなインフラストラクチャを使用できるという利点があります。
**その他のツール**
+ [GitHub アクション](https://docs.github.com/en/actions)は、GitHub リポジトリと緊密に統合された継続的インテグレーションおよび継続的デリバリー (CI/CD) プラットフォームです。GitHub Actions を使用して、ビルド、テスト、デプロイパイプラインを自動化できます。
+ 「[Terraform](https://www.terraform.io/)」は、HashiCorp の infrastructure as code (IaC) ツールで、クラウドとオンプレミスのリソースの作成と管理を支援します。
+ [Terragrunt](https://terragrunt.gruntwork.io/docs/getting-started/overview/) は、OpenTofu と Terraform の両方の機能を拡張するオーケストレーションツールです。一般的なインフラストラクチャパターンをどのように適用するかを管理し、大規模なインフラストラクチャ資産のスケーリングと維持を容易にします。
**コードリポジトリ**
このパターンのコードは、GitHub 内の [sample-aws-orchestration-pipeline-terraform](https://github.com/aws-samples/sample-aws-orchestration-pipeline-terraform) リポジトリで入手可能です。
## ベストプラクティス
+ GitHub リポジトリシークレットを使用して AWS 認証情報と機密データを保存し、安全なアクセスを実現します。
+ GitHub Actions の OpenID Connect (OIDC) プロバイダーを設定して IAM ロールを引き受け、静的認証情報を回避します。
+ 最小特権の原則に従い、タスク実行に必要最小限の権限を付与します。詳細については、IAM ドキュメントの「[最小限の特権を認める。](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#grant-least-priv)」と「[IAM でのセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)」を参照してください。
## エピック
### リポジトリの作成と設定
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| GitHub リポジトリを初期化します。 | GitHub リポジトリを初期化するには、次の手順を使用します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-an-api-driven-resource-orchestration-framework-using-github-actions-and-terragrunt.html) | DevOps エンジニア |
| IAM ロールとアクセス許可を設定します。 | IAM ロールとアクセス許可を設定するには、次の手順を使用します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-an-api-driven-resource-orchestration-framework-using-github-actions-and-terragrunt.html) | DevOps エンジニア |
| GitHub シークレットおよび変数を設定します。 | GitHub リポジトリでリポジトリシークレットと変数を設定する方法については、GitHub ドキュメントの「[Creating configuration variables for a repository](https://docs.github.com/en/actions/how-tos/write-workflows/choose-what-workflows-do/use-variables#creating-configuration-variables-for-a-repository)」を参照してください。次の変数を設定します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-an-api-driven-resource-orchestration-framework-using-github-actions-and-terragrunt.html) | DevOps エンジニア |
| リポジトリ構造を作成します。 | リポジトリ構造を作成するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-an-api-driven-resource-orchestration-framework-using-github-actions-and-terragrunt.html) | DevOps エンジニア |
### パイプラインをトリガーし、結果を検証する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| curl を使用してパイプラインを実行します。 | [curl](https://curl.se/) を使用してパイプラインを実行するには、次の手順を使用します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-an-api-driven-resource-orchestration-framework-using-github-actions-and-terragrunt.html)パイプライン実行プロセスの詳細については、「[追加情報](#create-an-api-driven-resource-orchestration-framework-using-github-actions-and-terragrunt-additional)」を参照してください。 | DevOps エンジニア |
| パイプライン実行結果の検証 | 結果を検証するには、次の手順を使用します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-an-api-driven-resource-orchestration-framework-using-github-actions-and-terragrunt.html)また、`terragrunt.hcl` ファイルと同じリソース内にあるリポジトリで作成された `output.json` ファイルを使用して、作成されたリソースを相互確認することもできます。 | DevOps エンジニア |
### リソースをクリーンアップする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| クリーンアップリクエストを送信します。 | 不要になったリソースを削除するには、次の手順を使用します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-an-api-driven-resource-orchestration-framework-using-github-actions-and-terragrunt.html) | DevOps エンジニア |
## 関連リソース
**AWS ブログ**
+ [IAM ロールを使用して GitHub Actions を のアクションに接続する AWS](https://aws.amazon.com/blogs/security/use-iam-roles-to-connect-github-actions-to-actions-in-aws/)
**AWS のサービス ドキュメント**
+ [IAM ロールの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html)
+ [Amazon CloudWatch Logs を使用した CloudTrail ログファイルのモニタリング](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/monitor-cloudtrail-log-files-with-cloudwatch-logs.html)
+ [Amazon S3 のセキュリティのベストプラクティス](https://docs.aws.amazon.com/AmazonS3/latest/userguide/security-best-practices.html)
**GitHub リソース**
+ [Create a repository dispatch event](https://docs.github.com/en/rest/repos/repos?apiVersion=2022-11-28#create-a-repository-dispatch-event)
+ [ウェブフックの作成](https://docs.github.com/en/webhooks/using-webhooks/creating-webhooks#payload)
+ [GitHub 上のアクセス権限](https://docs.github.com/en/get-started/learning-about-github/access-permissions-on-github)
+ [Organization のセキュリティ設定の管理](https://docs.github.com/en/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization)
+ [Security checks in the CI/CD pipeline](https://github.com/marketplace/actions/checkov-github-action)
+ [2 要素認証を設定する](https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa/configuring-two-factor-authentication)
## 追加情報
**パイプライン実行プロセス**
パイプライン実行の手順を次に示します。
1. **JSON ペイロード形式を検証する** – 受信 JSON 設定が適切に構造化され、すべての必須パラメータが含まれていることを確認します
1. **指定された IAM ロールを引き受ける** - AWS オペレーションに必要な IAM ロールを認証して引き受けます
1. **必要な Terraform および Terragrunt コードをダウンロードする** – 指定されたバージョンのリソースコードと依存関係を取得します
1. **リソースデプロイを実行する** - 設定を適用して、ターゲット環境に AWS リソースをデプロイまたは更新します
**VPC 作成に使用されるペイロードのサンプル**
次に示すのは、Terraform バックエンドのステートバケット作成のコード例です。
```
state_bucket_name = "${local.payload.ApplicationName}-${local.payload.EnvironmentId}-tfstate"
```
```
lock_table_name = "${local.payload.ApplicationName}-${local.payload.EnvironmentId}-tfstate-lock"
```
次に示すのは、Amazon VPC で VPC を作成するためのペイロードの例です。`vpc_cidr` は VPC の [CIDR ブロック](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-cidr-blocks.html)仕様を定義します。Terraform ステートバケットは、`terraform` ファイルで定義された変数にマッピングされます。`ref` パラメータには、実行するコードのブランチ名が含まれます。
```
{
"ref": "main",
"inputs": {
"RequestParameters": {
"RequestId": "1111111",
"RequestType": "create",
"ResourceType": "vpc",
"AccountId": "1234567890",
"AccountAlias": "account-alias",
"RegionId": "us-west-2",
"ApplicationName": "myapp",
"DivisionName": "division-name",
"EnvironmentId": "dev",
"Suffix": "poc"
},
"ResourceParameters": [
{
"VPC": {
"vpc_cidr": "10.0.0.0/16"
}
}
]
}
}
```
`RequestParameters` は、パイプラインセクションのリクエストステータスを追跡するために使用され、`tfstate` はこの情報に基づいて作成されます。次のパラメータにはメタデータとコントロールに関する情報が含まれます。
+ `RequestId` – リクエストの一意の識別子
+ `RequestType` – オペレーションのタイプ (作成、更新、または削除)
+ `ResourceType` – プロビジョニングするリソースのタイプ
+ `AccountId` – デプロイ AWS アカウント のターゲット
+ `AccountAlias` – のわかりやすい名前 AWS アカウント
+ `RegionId` – リソースデプロイ AWS リージョン 用
+ `ApplicationName` – アプリケーション名
+ `DivisionName` – 組織部門
+ `EnvironmentId` – 環境 (dev や prod など)
+ `Suffix` – リソースの追加識別子
`ResourceParameters` には、Terraform ファイルで定義された変数にマッピングするリソース固有の設定が含まれます。Terraform モジュールに渡す必要があるカスタム変数はすべて、`ResourceParameters` に含める必要があります。Amazon VPC には、`vpc_cidr` パラメータが必須です。
# GitHub Actions を使用して Terraform マネージド AWS インフラストラクチャの自動プルリクエストを作成する
*Amazon Web Services、Matt Padgett、Ashish Bhatt、Ashwin Divakaran、Sandip Gangapadhyay、および Prafful Gupta*
## 概要
このパターンでは、複数の Terraform リポジトリ間での変更管理に伴う手動の繰り返し作業を排除するように設計された自動化ユーティリティについて説明します。多くの組織は、Terraform リポジトリを使用して Infrastructure as Code (IaC) を管理しています。多くの場合、数百の個別のリポジトリがさまざまな環境、サービス、チームを表しています。これらのリポジトリを大規模に管理することは、運用上の重要な課題となります。パラメータの更新、モジュールバージョンのアップグレード、設定変更の適用などの日常的なタスクでは、多くの場合、多くのリポジトリに 1 日に何度もプルリクエスト (PR) を作成および管理する必要があります。
単純な変更であっても、この繰り返しで手動のプロセスには時間がかかり、エラーが発生しやすくなります。エンジニアは、すべてのターゲットリポジトリに同じ変更を一貫して適用し、意味のある PR タイトルと説明を作成する必要があります。さらに、問題追跡リファレンスを取得または含めるために、Jira などの外部ツールとやり取りする必要がたびたび生じます。これらのタスクは、必要ではあるものの、貴重なエンジニアリング時間を消費し、全体的な効率を低下させるような、差別化にならない重労働です。このワークフローを自動化しないと、衝突が発生し、引き渡しが遅くなり、大規模な Terraform インフラストラクチャの維持を担当するチームの認知負担が増大します。
**ソリューションの概要**
この課題に対処するために、このパターンでは完全に設定駆動型のユーティリティを提供します。これにより、ユーザーは構造化された設定ファイルで必要な変更を定義できます。このファイルでは、明確に定義されたスキーマを使用して、ターゲットリポジトリ、モジュール、パラメータ、および値を指定できます。
設定が済むと、ユーティリティは次の自動ステップを実行します。
1. **ユーザー定義の設定を読み取り**、変更の範囲と性質を決定する
1. 各ターゲットリポジトリに、必要な更新が適用された**新しいブランチを作成**する
1. 変更ごとに **PR を生成**し、すべてのリポジトリ間で整合性を確保する
1. **Slack 通知を送信**して (オプション)、作成された PR へのリンクと共に関係者に警告する
これらの繰り返しのタスクを自動化することにより、このユーティリティは大規模なインフラストラクチャ更新の管理に伴う時間、労力、リスクを大幅に削減します。その結果、チームは、変更が一貫して適用されて、すべてのリポジトリで追跡できることを容易に確認できると同時に、より価値の高いエンジニアリング作業に集中できます。
## 前提条件と制限
**前提条件**
+ アクティブ AWS アカウント。
+ Python バージョン 3.8 以降。
+ GitHub の個人用アクセストークン (PAT)。詳細は、GitHub ドキュメントの「[Creating a personal access token (classic)](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens#creating-a-personal-access-token-classic)」を参照してください。
+ GitHub PAT はターゲットリポジトリにアクセスできるため、ユーティリティはブランチの作成やプルリクエストなどのオペレーションを実行できます。詳細については、このパターンの GitHub [コードリポジトリ](https://github.com/aws-samples/sample-terraform-pr-automation-utility?tab=readme-ov-file#repository-access-verification)を参照してください。
**制限事項**
+ **設定の複雑さ**が主な課題です。オートメーションの有効性は、設定ファイルの機能によって制約されます。システムは標準の変更を効率的に処理しますが、複雑なインフラストラクチャの変更には手動による介入が必要になる場合があり、特定のまれな状況は自動処理の範囲外のままです。
+ **セキュリティとアクセス**は、特に GitHub アクセストークンと API レート制限を管理する上で重要な検討事項です。組織は、自動化の必要性と安全な認証情報の保管と管理を慎重に釣り合いをとり、運用効率を維持すると同時に、適切なアクセスコントロールを確保する必要があります。
+ 自動システムにはビジネス論理と環境固有の要件を検証する機能が限られているため、**検証制約**には別の重要な制限があります。自動検証ではすべての文脈の微妙な差異とビジネスルールを完全に把握できないため、複雑な依存関係とサービス間のやり取りには多くの場合、人による監視が必要です。
+ 大規模なインフラストラクチャの変更に対処していると、**スケールとパフォーマンス**の問題が発生します。システムは、多数のリポジトリを同時に管理しながら GitHub API の制限内で動作する必要があります。広範なインフラストラクチャにわたるリソース集約型のオペレーションは、慎重な管理を必要とするパフォーマンスのボトルネックを引き起こす可能性があります。
+ **統合境界**は、主に GitHub や Slack などの特定のツールで動作するように設計されているため、システムの柔軟性を制限します。さまざまなツールを使用する組織にはカスタムソリューションが必要になる場合があり、このパターンのワークフローカスタマイズオプションはサポート対象の統合ポイントに制限されます。
## アーキテクチャ
次の図は、このソルーションのワークフローとコンポーネントを示しています。
![\[GitHub Actions を使用して自動プルリクエストを作成するワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/e211359a-03b1-4e69-b152-eb7c09bdb01a/images/6cee0660-5b44-4abe-970c-c0a3c830a9aa.png)
ワークフローの主なステップは、以下のとおりです。
1. デベロッパーは Terraform リポジトリを指定して GitHub Actions の実行を開始します。
1. 自動化ユーティリティは、定義された設定を読み取ります。
1. 自動化ユーティリティは、提供された Terraform リポジトリも取得します。
1. 自動化ユーティリティは新しいブランチを作成し、Terraform テンプレートをローカルで更新します。
1. 自動化ユーティリティは、新しいブランチをリポジトリに反映し、新しい PR を作成します。
1. 自動化ユーティリティは、PR リンクを含む Slack 通知を使用してデベロッパーに通知し、Terraform テンプレートを AWS クラウド デプロイできるようにします。
## ツール
+ [GitHub](https://docs.github.com/) は、デベロッパーがコードの作成、保存、管理、共有に使用できるデベロッパー用プラットフォームです。
+ [GitHub Actions](https://docs.github.com/en/actions) は、GitHub リポジトリと緊密に統合された継続的インテグレーションおよび継続的デリバリー (CI/CD) プラットフォームです。GitHub Actions を使用して、生成、テスト、デプロイのパイプラインを自動化できます。
+ [HashiCorp Terraform](https://www.terraform.io/) は、Infrastructure as Code (IaC) ツールで、クラウドとオンプレミスのリソースの作成と管理を支援します。
+ Salesforce の製品である [Slack](https://slack.com/help/articles/115004071768-What-is-Slack-) は、チャットとビデオでの共同作業、ノーコードでのプロセスの自動化、情報共有が可能な、AI を活用した対話型プラットフォームです。
**コードリポジトリ**
このパターンのコードは、GitHub の [Automated Terraform Infrastructure Update Workflow using GitHub Actions](https://github.com/aws-samples/sample-terraform-pr-automation-utility?tab=readme-ov-file) リポジトリで入手可能です。
## ベストプラクティス
+ 実装を成功させるためには、効果的な**変更管理**が不可欠です。組織は、大規模な変更に対して段階的な導入戦略を採用する必要があります。一貫したブランチ命名規則と PR の記述を維持し、すべての変更を包括的に文書化することを確実にします。
+ **セキュリティコントロール**は、最小特権のアクセス原則と安全な認証情報管理に焦点を当てて、厳格に実装する必要があります。ブランチ保護ルールを有効にして、不正な変更を防止します。システムの整合性を維持するために、定期的にセキュリティ監査を実施します。
+ 堅牢な**テストプロトコル**には、継続的インテグレーションおよび継続的デプロイ (CI/CD) パイプラインでの自動化した `terraform plan` の実行を含める必要があります。プロトコルには、コミット前検証チェックと重要な変更に特化したレビュー環境も含める必要があります。この多層テストアプローチは、問題を早期に発見し、インフラストラクチャの安定性を確保するのに役立ちます。
+ **モニタリング戦略**には、包括的な警告メカニズム、詳細な成功/失敗メトリックの追跡、および失敗したオペレーションの自動再試行メカニズムを含める必要があります。この戦略は、運用の可視性を確保し、発生した問題への迅速な対応を可能にします。
+ **設定標準**では、すべての設定のバージョン管理を重視し、再利用性とスケーラビリティのためにモジュール性を維持する必要があります。スキーマと事例の明確なドキュメントは、チームが自動化システムを効果的に理解し、使用するのに役立ちます。
## エピック
### インストールとセットアップ
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| リポジトリを設定します。 | リポジトリのクローンを作成するには、次のコマンドを実行します。# Clone the automation tool repository
git clone https://github.com/aws-samples/sample-terraform-pr-automation-utility
cd sample-terraform-pr-automation-utility
# Copy example configuration
cp config.example.yaml config.yaml
| AWS DevOps |
| 依存関係をインストールします。 | 次のコマンドを実行して、Python の依存関係をインストールし、検証します。# Install Python dependencies
pip3 install -r requirements.txt
# Verify installation
python3 -c "import github; import hcl2; import yaml; import requests; print('All packages installed successfully')"
| AWS DevOps |
| GitHub トークンを設定します。 | GitHub トークンを設定し、それが機能することを確認するには、次のコマンドを実行します。# Set GitHub token environment variable
export GITHUB_TOKEN="your_github_token_here"
# Verify token works
curl -H "Authorization: token $GITHUB_TOKEN" https://api.github.com/user
| AWS DevOps |
### Terraform を変更する設定ファイルのセットアップ
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| `config.yaml` ファイルを設定します。 | ターゲットリポジトリと必要な変更を定義するには、次のように `config.yam`l ファイルを編集します。repositories:
- owner: "your-org"
repo: "your-terraform-repo"
files:
- path: "variables.tf"
changes:
variables:
- app_version:
default:
update:
- from: ["1.0.0"]
to: "1.1.0"
settings:
pr_title_template: "Infrastructure Update - {{timestamp}}"
slack:
username: "Terraform Bot"
icon_emoji: ":terraform:"
notify_on_success: true
notify_on_error: true
notify_batch_summary: true
| AWS DevOps |
### テストと検証
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| 事前テストを実行します。 | 本番用リポジトリで実行する前に、必ず設定をテストしてください。次のコマンドを使用します。# 1. Test configuration syntax
python3 -c "from main import get_config_content; get_config_content()"
# 2. Run in dry-run mode first
DRY_RUN=true python3 main.py
# 3. Test with minimal configuration
# Use a simple config.yaml with just one repository and one change
| AWS DevOps |
| リポジトリへのアクセスを確認します。 | GitHub トークンがリポジトリにアクセスできることを確認するには、次のコマンドを実行します。# Test GitHub token access
curl -H "Authorization: token $GITHUB_TOKEN" \
https://api.github.com/repos/owner/repo-name
# Should return repository information, not 404
| AWS DevOps |
### 自動化ユーティリティの実行
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| GitHub Actions UI を使用して自動化ユーティリティを実行します。 | GitHub Actions UI を使用して自動化ユーティリティを実行するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-automated-pull-requests-for-terraform-managed-aws-infrastructure.html) | AWS DevOps |
| (代替) コマンドラインから自動化ユーティリティを実行します。 | 必要に応じて、GitHub Actions UI ではなく、コマンドラインから自動化ユーティリティを実行できます。以下のコマンドを使用します。# Run actual automation
python3 main.py
| AWS DevOps |
### PR と変更を検証する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| 作成された PR と変更を確認します。 | GitHub ワークフロー実行の結果をモニタリングするには、次を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-automated-pull-requests-for-terraform-managed-aws-infrastructure.html) | AWS DevOps |
### クリーンアップ
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| (オプション) PR をクリーンアップします。 | 中止された、もしくは不要な PR を閉じます。 | AWS DevOps |
## 関連リソース
**AWS 規範ガイダンス**
+ [の IaC ツールとしての Terraform の使用 AWS クラウド](https://docs.aws.amazon.com/prescriptive-guidance/latest/choose-iac-tool/terraform.html)
**GitHub ドキュメント**
+ [pull requests について](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests)
+ [個人用アクセストークンを管理する](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens)
+ [GitHub Actions を理解する](https://docs.github.com/en/actions/get-started/understand-github-actions)
+ [GitHub Actions のクイックスタート](https://docs.github.com/en/actions/get-started/quickstart)
# Java および Python プロジェクト用の動的 CI パイプラインを自動的に作成
*Amazon Web Services、Aromal Raj Jayarajan、Vijesh Vijayakumaran Nair、MAHESH RAGHUNANDANAN、Amarnath Reddy*
## 概要
このパターンは、AWS 開発者ツールを使用して Java および Python プロジェクトの動的継続的インテグレーション (CI) パイプラインを自動的に作成する方法を示しています。
テクノロジースタックが多様化し、開発活動が増えるにつれて、組織全体で一貫性のある CI パイプラインを作成して維持することが難しくなる可能性があります。AWS Step Functions のプロセスを自動化することで、CI パイプラインの使用法とアプローチに一貫性を持たせることができます。
動的 CI パイプラインの作成を自動化するために、このパターンでは以下の変数入力を使用します。
+ プログラミング言語 (Java または Python のみ)
+ パイプライン名
+ 必要なパイプラインステージ
**注記**
Step Functions は、複数の AWS サービスを使用してパイプラインの作成をオーケストレーションします。このソリューションで使用されている AWS サービスの詳細については、このパターンの「**ツール**」セクションを参照してください。
## 前提条件と制限
**前提条件**
+ アクティブな AWS アカウント。
+ このソリューションがデプロイされている同じ AWS リージョンにある Amazon S3 バケット
+ このソリューションに必要なリソースを作成するために必要な AWS CloudFormation アクセス許可を持つ AWS Identity and Access Management (IAM) 「[プリンシパル](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html)」
**制限事項**
+ このパターンは Java プロジェクトと Python プロジェクトのみをサポートします。
+ このパターンでプロビジョニングされる IAM ロールは、最小特権の原則に従います。IAM ロールの権限は、CI パイプラインが作成する必要のある特定のリソースに基づいて更新する必要があります。
## アーキテクチャ
**ターゲットテクノロジースタック**
+ AWS CloudFormation
+ AWS CodeBuild
+ AWS CodeCommit
+ AWS CodePipeline
+ IAM
+ Amazon Simple Storage Service (Amazon S3)
+ AWS Systems Manager
+ AWS Step Functions
+ AWS Lambda
+ Amazon DynamoDB
**ターゲットアーキテクチャ**
次の図は、AWS 開発者ツールを使用して Java および Python プロジェクトの動的 CI パイプラインを自動的に作成するワークフローの例を示しています。
![\[AWS ツールを使用して Java および Python プロジェクトの動的 CI パイプラインを自動的に作成するワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/bef2ccb8-68b3-4c0f-9ee7-4b93e9422d9c/images/b5ed003f-cf16-4130-8bfb-2bc2cb9a0d33.png)
この図表は、次のワークフローを示しています:
1. AWS ユーザーは CI パイプラインを作成するための入力パラメータを JSON 形式で提供します。この入力により、AWS 開発者ツールを使用して CI パイプラインを作成する Step Functions ワークフロー (*ステートマシン*) が開始されます。
1. Lambda 関数は Amazon S3 バケットに保存されている「**インプット-レファレンス**」という名前のフォルダを読み取り、「**buildspec.yml**」ファイルを生成します。この生成されたファイルは CI パイプラインのステージを定義し、パラメータ参照を格納しているのと同じ Amazon S3 バケットに保存されます。
1. Step Functions は CI パイプライン作成ワークフローの依存関係に変更がないか確認し、必要に応じて依存関係スタックを更新します。
1. Step Functions は、CodeCommit リポジトリ、CodeBuild プロジェクト、CodePipeline パイプラインを含む CI パイプラインリソースを CloudFormation スタックに作成します。
1. CloudFormation スタックは、選択したテクノロジースタック (Java または Python) のサンプルソースコードと 「**buildspec.yml**」ファイルを CodeCommit リポジトリにコピーします。
1. CI パイプラインランタイムの詳細は DynamoDB テーブルに保存されます。
**自動化とスケール**
+ このパターンは 1 つの開発環境でのみ使用できます。複数の開発環境で使用するには、設定の変更が必要です。
+ 複数の CloudFormation スタックのサポートを追加するには、追加の CloudFormation テンプレートを作成できます。詳細については、CloudFormation ドキュメントの「[AWS CloudFormation 入門](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/GettingStarted.html)」を参照してください。
## ツール
**ツール**
+ [AWS Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)は、AWS Lambda関数と他のAWS サービスを組み合わせてビジネスクリティカルなアプリケーションを構築できるサーバーレスオーケストレーションサービスです。
+ [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。
+ [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) はフルマネージドの構築サービスです。ソースコードのコンパイル、ユニットテストの実行、すぐにデプロイできるアーティファクトの生成を行います。
+ [AWS CodeCommit](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html) は、独自のソースコントロールシステムを管理しなくても、Git リポジトリを非公開で保存および管理できるバージョン管理サービスです。
+ [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) は、ソフトウェアリリースのさまざまな段階を迅速にモデル化および設定し、ソフトウェアの変更を継続的にリリースするために必要なステップを自動化するのに役立ちます。
+ 「[AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)」は、AWS リソースへのアクセスを安全に管理し、誰が認証され、使用する権限があるかを制御するのに役立ちます。
+ [AWS Key Management Service (AWS KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) は、データの保護に役立つ暗号キーを作成および管理する上で役立ちます。
+ [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) は、あらゆる量のデータを保存、保護、取得できるクラウドベースのオブジェクトストレージサービスです。
+ [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) を使用すると、AWS リソースをセットアップし、迅速かつ一貫したプロビジョニングを行い、AWS アカウントとリージョン全体でライフサイクル全体にわたってリソースを管理できます。
+ [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html) は、フルマネージド NoSQL データベースサービスです。高速かつ予測可能でスケーラブルなパフォーマンスを提供します。
+ [AWS Systems Manager Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html) は、設定データ管理とシークレット管理用の安全な階層型ストレージを提供します。
**Code**
このパターンのコードは、GitHub 内の「[automated-ci-pipeline-creation](https://github.com/aws-samples/automated-ci-pipeline-creation)」リポジトリで利用できます。リポジトリには、このパターンで概説されているターゲットアーキテクチャの作成に必要な CloudFormation テンプレートが含まれています。
## ベストプラクティス
+ トークンやパスワードなどの認証情報 (*シークレット*) を CloudFormation テンプレートや Step Functions アクション設定に直接入力しないでください。その場合、情報は DynamoDB ログに表示されます。代わりに、AWS Secrets Manager を使用してシークレットを設定し、保存してください。次に、必要に応じて CloudFormation テンプレートとStep Functions アクション設定内のSecrets Manager に保存されているシークレットを参照します。詳細については、AWS Secrets Manager ユーザーガイドの「[AWS Secrets Manager とは](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html)」を参照してください。
+ Amazon S3 に保存した CodePipeline アーティファクトのサーバー側の暗号化を設定する 詳細については、CodePipeline ドキュメントの「[CodePipeline 用に Amazon S3 に保存したアーティファクトのサーバー側の暗号化を設定する](https://docs.aws.amazon.com/codepipeline/latest/userguide/S3-artifact-encryption.html)」を参照してください。
+ IAM ロールを設定する際には、最小特権アクセス許可を適用します。詳細については、IAM ドキュメントの「[最小特権アクセス許可を適用する](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)」を参照してください。
+ Amazon S3 バケットがパブリックにアクセスできないことを確認します。詳細については、Amazon S3 ドキュメントの「[S3 バケットのブロックパブリックアクセス設定を行う](https://docs.aws.amazon.com/AmazonS3/latest/userguide/configuring-block-public-access-bucket.html)」を参照してください。
+ Amazon S3 バケットのバージョニングを必ず有効にしてください。詳細については、「[Amazon S3 バケットでのバージョニングの使用](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Versioning.html)」を参照してください。
+ IAM ポリシーを設定するときは IAM アクセスアナライザーを使用してください。このツールは安全で機能的なIAMポリシーを作成するのに役立つ実用的な推奨事項を提供します。詳細については、IAM ドキュメントの「[AWS アイデンティティとアクセスマネジメントアクセスアナライザの使用](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)」を参照してください。
+ 可能な場合は、IAM ポリシーを設定する際に特定のアクセス条件を定義してください。
+ モニタリングと監査の目的で Amazon CloudWatch のロギングを有効化します。詳細については、Cloudwatch ドキュメントの「[Amazon CloudWatch Logsとは](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)」を参照してください。
## エピック
### AWS の前提条件の設定
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| Amazon S3 バケットを作成する。 | Amazon S3 バケットを作成して (または既存のバケットを使用して)、ソリューションに必要な CloudFormation テンプレート、ソースコード、および入力ファイルを保存します。詳細については、Amazon S3 ドキュメントの「[ステップ１：最初の S3 バケットの作成](https://docs.aws.amazon.com/AmazonS3/latest/userguide/creating-bucket.html)」を参照してください。Amazon S3 バケットが、ソリューションをデプロイしているリージョンと同じ AWS リージョンに存在する必要があります。 | AWS DevOps |
| GitHub リポジトリのクローンを作成します。 | ターミナルウィンドウで次のコマンドを実行して、GitHub 「[自動 CI パイプライン作成](https://github.com/aws-samples/automated-ci-pipeline-creation)」リポジトリをクローンします。git clone https://github.com/aws-samples/automated-ci-pipeline-creation.git
詳細については、Github ドキュメントの「[リポジトリのクローン](https://docs.github.com/en/repositories/creating-and-managing-repositories/cloning-a-repository)」を参照してください。 | AWS DevOps |
| クローンした GitHub リポジトリから Amazon S3 バケットにソリューションテンプレートフォルダをアップロードします。 | クローンした「**ソリューション-テンプレート**」フォルダから内容をコピーし、作成した Amazon S3 バケットにアップロードします。詳細については、Amazon S3 ドキュメントの「[オブジェクトのアップロード](https://docs.aws.amazon.com/AmazonS3/latest/userguide/upload-objects.html)」を参照してください。必ず **Solution-Templates** フォルダのコンテンツのみをアップロードしてください。Amazon S3 バケットのルートレベルでのみファイルをアップロードできます。 | AWS DevOps |
### 解決策をデプロイする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| クローンされた GitHub リポジトリ内の template.yml ファイルを使用して、ソリューションをデプロイするための CloudFormation スタックを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-dynamic-ci-pipelines-for-java-and-python-projects-automatically.html)スタックの作成中、スタックは **[スタック]**ページにリストされ、そのステータスが **CREATE\$1IN\$1PROGRESS** と表示されます。このパターンの残りのステップを完了する前に、スタックのステータスが「**作成\$1完了**」に変わるのを必ず待ってください。 | AWS 管理者、AWS DevOps |
### セットアップをテストする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| 作成した関数を実行します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-dynamic-ci-pipelines-for-java-and-python-projects-automatically.html)(JSON 形式) を使用してエクスポートおよびダウンロードするには：{
"details": {
"tech_stack": "Name of the Tech Stack (python/java)",
"project_name": "Name of the Project that you want to create with",
"pre_build": "Choose the step if it required in the buildspec.yml file i.e., yes/no",
"build": "Choose the step if it required in the buildspec.yml file i.e., yes/no",
"post_build": "Choose the step if it required in the buildspec.yml file i.e., yes/no",
"reports": "Choose the step if it required in the buildspec.yml file i.e., yes/no",
}
}**Java JSON 入力の例**{
"details": {
"tech_stack": "java",
"project_name": "pipeline-java-pjt",
"pre_build": "yes",
"build": "yes",
"post_build": "yes",
"reports": "yes"
}
}**Python JSON 入力の例**{
"details": {
"tech_stack": "python",
"project_name": "pipeline-python-pjt",
"pre_build": "yes",
"build": "yes",
"post_build": "yes",
"reports": "yes"
}
} | AWS 管理者、AWS DevOps |
| CI パイプラインの CodeCommit リポジトリが作成されたことを確認します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-dynamic-ci-pipelines-for-java-and-python-projects-automatically.html) | AWS DevOps |
| CodeBuild プロジェクトリソースを確認してください。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-dynamic-ci-pipelines-for-java-and-python-projects-automatically.html) | AWS DevOps |
| CodePipeline のステージを検証します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-dynamic-ci-pipelines-for-java-and-python-projects-automatically.html) | AWS DevOps |
| CI パイプラインが正常に実行されたことを確認します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-dynamic-ci-pipelines-for-java-and-python-projects-automatically.html) | AWS DevOps |
### リソースのクリーンアップ
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| CloudFormation のリソーススタックを削除します。 | CloudFormation 内の CI パイプラインのリソーススタックを削除します。詳細については、CloudFormationドキュメントの「[AWS CloudFormation でのスタックの削除](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-delete-stack.html)」を参照してください。**-stack** という名前のスタックは必ず削除してください。 | AWS DevOps |
| Amazon S3 とCloudFormation の CI パイプラインの依存関係を削除します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-dynamic-ci-pipelines-for-java-and-python-projects-automatically.html)**pipeline-creation-dependencies-stack** という名前のスタックは必ず削除してください。 | AWS DevOps |
| Amazon S3 バケットを削除します。 | このパターンの「**前提条件の設定**」セクションで作成した Amazon S3 バケットを削除します。このバケットには、このソリューションのテンプレートが保存されています。詳細については、Amazon S3 ドキュメントの「[バケットの削除](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html)」を参照してください。 | AWS DevOps |
## 関連リソース
+ 「[Lambda を使用する Step Functions ステートマシンの作成](https://docs.aws.amazon.com/step-functions/latest/dg/tutorial-creating-lambda-state-machine.html)」 (「AWS Step Functions 開発者ガイド」)
+ 「[AWS Step Functions Workflow Studio](https://docs.aws.amazon.com/step-functions/latest/dg/workflow-studio.html)」 (「AWS Step Functions 開発者ガイド」)
+ [DevOps と AWS](https://aws.amazon.com/devops/)
+ [AWS CloudFormation の仕組み](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-whatis-howdoesitwork.html) (「AWS CloudFormation ドキュメント」)
+ 「[Complete CI/CD with AWS CodeCommit, AWS CodeBuild, AWS CodeDeploy, and AWS CodePipeline](https://aws.amazon.com/blogs/devops/complete-ci-cd-with-aws-codecommit-aws-codebuild-aws-codedeploy-and-aws-codepipeline/)」 (AWS ブログ)
+ 「[IAM および AWS STS クォータ、名前の要件、および文字の制限](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html)」 (「IAM ドキュメント」)
# Terraform を使用して CloudWatch Synthetics Canary をデプロイする
*Amazon Web Services、Dhrubajyoti Mukherjee および Jean-Francois Landreau*
## 概要
顧客の観点からシステムの状態を検証し、顧客が接続できることを確認することは重要です。顧客がエンドポイントを頻繁に呼び出さない場合、これはさらに困難になります。[Amazon CloudWatch Synthetics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) は、パブリックエンドポイントとプライベートエンドポイントの両方をテストできる Canary の作成をサポートしています。Canary を使用すれば、使用中でなくてもシステムの状態を知ることができます。これらの Canary は Node.js Puppeteer スクリプトまたは Python Selenium スクリプトのどちらかです。
このパターンでは、HashiCorp Terraform を使用してプライベートエンドポイントをテストする Canary をデプロイする方法を説明します。URL が `200-OK` に返されるかどうかをテストする Puppeteer スクリプトが組み込まれています。その後、Terraform スクリプトを、プライベートエンドポイントをデプロイするスクリプトと統合できます。パブリックエンドポイントを監視するようにソリューションを変更することもできます。
## 前提条件と制限事項
**前提条件**
+ 仮想プライベートクラウド (VPC) とプライベートサブネットを持つアクティブなAmazon Web Services (AWS) アカウント
+ プライベートサブネットからアクセスできるエンドポイントの URL
+ Terraform をインストールしたデプロイメント環境
**制限**
現在のソリューションは、次の CloudWatch Synthetics ランタイムバージョンで動作します。
+ syn-nodejs-puppeteer-3.4
+ syn-nodejs-puppeteer-3.5
+ syn-nodejs-puppeteer-3.6
+ syn-nodejs-puppeteer-3.7
新しいランタイムバージョンがリリースされると、現在のソリューションの更新が必要な場合があります。また、セキュリティアップデートに対応できるようにソリューションを変更する必要もあります。
**製品バージョン**
+ Terraform 1.3.0
## アーキテクチャ
Amazon CloudWatch Synthetics は、CloudWatch、Lambda、および Amazon Simple Storage Service (Amazon S3) をベースにしています。Amazon CloudWatch には、Canary を作成するウィザードと、Canary の実行状況を表示するダッシュボードが用意されています。Lambda 関数はスクリプトを実行します。Amazon S3 は、Canary 実行のログとスクリーンショットを保存します。
このパターンは、ターゲットサブネットにデプロイされた Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを介してプライベートエンドポイントをシミュレートします。Lambda 関数には、プライベートエンドポイントがデプロイされている VPC 内の伸縮自在なネットワークインターフェイスが必要です。
![\[説明は図に続いて記載します。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/73ed0103-ec45-4653-bb29-f402a88f0c64/images/39aaed0f-f259-4f2a-98fb-8e3a340d0b02.png)
図に示す内容は以下のとおりです。
1. Synthetics canary が Canary Lambda 関数を開始します。
1. Canary Lambda 関数が Elastic Network Interface に接続します。
1. Canary Lambda 関数はエンドポイントのステータスを監視します。
1. Synthetics Canary は、実行データを S3 バケットと CloudWatch メトリックスにプッシュします。
1. メトリックスに基づいて CloudWatch アラームが開始されます。
1. CloudWatch アラームが Amazon Simple Notification Service (Amazon SNS) トピックを開始します。
## ツール
**AWS サービス**
+ [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) は、AWS のリソースや、AWS で実行されるアプリケーションをリアルタイムにモニタリングします。
+ [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。
+ 「[Amazon Simple Notification Service (Amazon SNS)](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)」は、ウェブサーバーやメールアドレスなど、パブリッシャーとクライアント間のメッセージの交換を調整および管理するのに役立ちます。
+ [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) は、あらゆる量のデータを保存、保護、取得できるクラウドベースのオブジェクトストレージサービスです。
+ [Amazon Virtual Private Cloud (Amazon VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) を使用すると、定義した仮想ネットワーク内で AWS リソースを起動できます。この仮想ネットワークは、お客様自身のデータセンターで運用されていた従来のネットワークに似ていますが、AWS のスケーラブルなインフラストラクチャを使用できるというメリットがあります。このパターンは VPC エンドポイントとエラスティックネットワークインターフェイスを使用します。
**その他のサービス**
+ [HashiCorp Terraform](https://www.terraform.io/docs) は、コードを使用してクラウドインフラストラクチャとリソースをプロビジョニングおよび管理するのに役立つオープンソースの Infrastructure as Code (IaC) ツールです。このパターンでは、Terraform を使用してインフラストラクチャをデプロイします。
+ [Puppeteer](https://pptr.dev/) は Node.js ライブラリです。CloudWatch Synthetics ランタイムは Puppeteer フレームワークを使用しています。
**コード**
このソリューションは、GitHub の [cloud watch-synthetics-canary-terraform](https://github.com/aws-samples/cloudwatch-synthetics-canary-terraform) リポジトリで利用できます。詳細については、「追加情報」セクションを参照してください。
## エピック
### プライベート URL を監視するソリューションを実装してください。
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| プライベート URL を監視するための要件を収集する。 | ドメイン、パラメータ、ヘッダーなどの URL 定義をすべて収集します。Amazon S3 や Amazon CloudWatch とプライベートに通信するには、VPC エンドポイントを使用してください。VPC とサブネットがエンドポイントにどのようにアクセスできるかに注意してください。Canary 実行の頻度を考えてみましょう。 | クラウドアーキテクト、ネットワーク管理者 |
| プライベート URL を監視するように既存のソリューションを変更する。 | `terraform.tfvars` ファイルの変更:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-cloudwatch-synthetics-canaries-by-using-terraform.html) | クラウドアーキテクト |
| ソリューションをデプロイして運用する。 | ソリューションを展開するには、次を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-cloudwatch-synthetics-canaries-by-using-terraform.html) | クラウドアーキテクト、DevOps エンジニア |
## トラブルシューティング
| 問題 | ソリューション |
| --- | --- |
| プロビジョニングされたリソースの削除が停止する。 | Canary Lambda 関数、対応する elastic network interface、セキュリティグループをこの順序で手動で削除します。 |
## 関連リソース
+ [模擬モニタリングの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [Monitor API Gateway endpoints with Amazon CloudWatch Synthetics](https://aws.amazon.com/blogs/mt/monitor-api-gateway-endpoints-with-amazon-cloudwatch-synthetics/) (ブログ記事)
## 追加情報
**リポジトリのアーティファクト**
リポジトリのアーティファクトは、次の構造を持っています。
```
.
├── README.md
├── main.tf
├── modules
│ ├── canary
│ └── canary-infra
├── terraform.tfvars
├── tf.plan
└── variable.tf
```
`main.tf` ファイルにはコアモジュールが含まれ、2 つのサブモジュールがデプロイされます。
+ `canary-infra` は、Canary に必要なインフラストラクチャをデプロイします。
+ `canary` は、Canary をデプロイします。
ソリューションの入力パラメータは `terraform.tfvars` ファイルにあります。次のコード例を使用して 1 つの Canary を作成できます。
```
module "canary" {
source = "./modules/canary"
name = var.name
runtime_version = var.runtime_version
take_screenshot = var.take_screenshot
api_hostname = var.api_hostname
api_path = var.api_path
reports-bucket = module.canary_infra.reports-bucket
role = module.canary_infra.role
security_group_id = module.canary_infra.security_group_id
subnet_ids = var.subnet_ids
frequency = var.frequency
alert_sns_topic = var.alert_sns_topic
}
```
対応する.var ファイルは次のとおりです。
```
name = "my-canary"
runtime_version = "syn-nodejs-puppeteer-3.7"
take_screenshot = false
api_hostname = "mydomain.internal"
api_path = "/path?param=value"
vpc_id = "vpc_id"
subnet_ids = ["subnet_id1"]
frequency = 5
alert_sns_topic = "arn:aws:sns:eu-central-1:111111111111:yyyyy"
```
**ソリューションのクリーンアップ**
開発環境でこれをテストする場合は、コストの発生を避けるためにソリューションをクリーンアップできます。
1. AWS マネジメントコンソールで、Amazon S3 コンソールに移動します。ソリューションが作成した Amazon S3 バケットを空にします。必要な場合は、必ずデータのバックアップを取ってください。
1. 開発環境の `cloudwatch-synthetics-canary-terraform` ディレクトリから `destroy` コマンドを実行します。
```
terraform destroy
```
# ChatOps ソリューションをデプロイして、チャットアプリケーションのカスタムアクションと で Amazon Q Developer を使用して SAST スキャン結果を管理する CloudFormation
*Amazon Web Services、Anand Bukkapatnam Tirumala*
## 概要
このパターンは、チャットアプリケーションで Amazon Q Developer を使用して、SonarQube を通じて報告された静的アプリケーションセキュリティテスト (SAST) のスキャン障害の管理を合理化する包括的なソリューションを示しています。この革新的なアプローチは、カスタムアクションと通知を会話型インターフェイスに統合し、開発チーム内での効率的な共同作業と意思決定プロセスを可能にします。
今日のペースの速いソフトウェア開発環境では、SAST スキャン結果を効率的に管理することは、コードの品質とセキュリティを維持する上で不可欠です。しかし、多くの組織は次のような大きな課題に直面しています。
+ 非効率的な通知システムによる重大な脆弱性の認識の遅延
+ 分断された承認ワークフローによる時間のかかる意思決定プロセス
+ SAST スキャン障害に対する即時の実用的な対応の欠如
+ セキュリティ検出結果に関する断片化されたコミュニケーションとコラボレーション
+ セキュリティツールに関する、時間がかかり、エラーが発生しやすい手動インフラストラクチャ設定
これらの問題は、多くの場合、セキュリティリスクの増加、リリースの遅延、チームの生産性の低下につながります。これらの課題に効果的に対処するには、SAST の結果管理を合理化し、チームのコラボレーションを強化し、インフラストラクチャの割り当てを自動化できるソリューションが必要です。
このソリューションの主な機能は次のとおりです。
+ **カスタマイズされた通知** – リアルタイムの警告と通知はチームチャットチャネルに直接配信されるため、SAST スキャンの脆弱性や障害に対する迅速な認識とアクションが保証されます。
+ **会話による承認** – 利害関係者は、チャットインターフェイス内で途切れなく SAST スキャン結果の承認ワークフローを開始および完了できるため、意思決定プロセスが加速されます。
+ **カスタムアクション** – チームは、品質ゲートの障害に対する E メールメッセージの自動トリガー、セキュリティ問題への応答性の向上など、SAST スキャンの結果に基づいてカスタムアクションを定義して実行できます。
+ **一元化されたコラボレーション** – SAST スキャン関連の議論、決定、アクションはすべて統一されたチャット環境内に保持されるため、チームメンバー間のコラボレーションと知識共有が向上します。
+ **Infrastructure as Code (IaC)** – ソリューション全体が AWS CloudFormation テンプレートでラップされ、手動セットアップエラーを減らしながら、より高速で信頼性の高いインフラストラクチャプロビジョニングを可能にします。
## 前提条件と制限
**前提条件**
+ アクティブ AWS アカウント。
+ ツールに AWS のサービス リストされている に関連付けられたリソースを作成および管理するためのアクセス許可を持つ AWS Identity and Access Management (IAM) ロール[ツール](#deploy-chatops-solution-to-manage-sast-scan-results-tools)。
+ Slack ワークスペース。
+ 必要な Slack ワークスペースにプラグインとして追加されたチャットアプリケーションの Amazon Q Developer。詳細については、Slack ドキュメントの「[Slack ワークスペースにアプリを追加する](https://slack.com/intl/en-in/help/articles/202035138-Add-apps-to-your-Slack-workspace)」を参照してください。登録が成功 AWS マネジメントコンソール したら、「」に示すように Slack ワークスペース ID を書き留めます。
+ チャットアプリケーションクライアントで設定された Amazon Q Developer。ワークスペース ID は CloudFormation コンソールですぐに入力できます。手順については、「*Amazon Q Developer in chat applications Administrator Guide*」の「[Configure a Slack client](https://docs.aws.amazon.com/chatbot/latest/adminguide/slack-setup.html#slack-client-setup)」を参照してください。
+ 承認 E メールメッセージを送信するために Amazon Simple Email Service (Amazon SES) で作成および検証される送信元 E メールアカウント。セットアップ手順については、「*Amazon Simple Email Service Developer Guide*」の「[Creating and verifying email identities](https://docs.aws.amazon.com/ses/latest/dg/creating-identities.html#verify-email-addresses-procedure)」を参照してください。
+ 承認通知を受信するための送信先 E メールアドレス。このアドレスは、共有受信トレイまたは特定のチームの配布グループにすることができます。
+ からアクセスできる運用上の SonarQube インスタンス AWS アカウント。詳細については「[SonarQube installation instructions](https://docs.sonarsource.com/sonarqube/latest/setup-and-upgrade/install-the-server/introduction/)」を参照してください。
+ パイプラインを介してプロジェクトをトリガーおよび作成するためのアクセス許可を持つ SonarQube [ユーザートークン](https://docs.sonarsource.com/sonarqube-server/latest/user-guide/managing-tokens/)。
**制限事項**
+ カスタムアクションボタンの作成は、このソリューションでは手動プロセスです。
+ 一部の 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)」を参照して、サービスのリンクを選択してください。
## アーキテクチャ
次の図表は、このパターンのアプリケーションのワークフローとアーキテクチャコンポーネントを示しています。
![\[Amazon Q Developer を使用したリリース管理用の自動コード品質保証をデプロイするワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/198312ed-e379-49a7-b706-8e79e2142f21/images/a977924c-957e-4f91-99d6-ed790e343ea6.png)
この図は、自動コード品質保証ワークフローを示しています。
1. コードの準備とアップロード:
+ 開発者はコードベースを .zip ファイルに圧縮します。
+ 開発者は、指定された Amazon Simple Storage Service (Amazon S3) バケットに手動で .zip ファイルをアップロードします。
1. Amazon S3 イベントトリガーと AWS Step Functions オーケストレーション:
+ Amazon S3 アップロードイベントは Step Functions ワークフローの実行を開始します。
+ Step Functions は、SonarQube を使用して SAST スキャンをオーケストレーションします。
+ ワークフローは AWS CodeBuild ジョブのステータスをモニタリングして、次のアクションを決定します。CodeBuild が成功すると (品質ゲート通過)、ワークフローは終了します。CodeBuild が失敗すると、診断のために AWS Lambda 関数が呼び出されます。詳細については、このセクションの後半にある「**AWS Step Functions のロジック**」を参照してください。
1. AWS CodeBuild 実行:
+ CodeBuild ジョブは、アップロードされたコードベースで SonarQube スキャンを実行します。
+ スキャンアーティファクトは、監査と分析のために別の Amazon S3 バケットに保存されます。
1. 障害分析 (Lambda 関数):
+ CodeBuild が失敗すると、`CheckBuildStatus` Lambda 関数の実行が開始されます。
+ CodeBuild が成功すると、プロセスは終了し、それ以上のアクションは必要ありません。
1. Lambda 関数が障害の原因を分析 (品質ゲートの障害またはその他の問題)
+ `CheckBuildStatus` 関数は、詳細な障害情報を含むカスタムペイロードを作成します。
+ `CheckBuildStatus` 関数は、カスタムペイロードを Amazon Simple Notification Service (Amazon SNS) トピックに発行します。
1. 通知システム:
+ Amazon SNS は、Slack 統合用のチャットアプリケーションでペイロードを Amazon Q Developer に転送します。
1. Slack 統合:
+ チャットアプリケーションの Amazon Q Developer は、指定された Slack チャンネルに通知を投稿します。
1. 承認プロセス:
+ 承認者は、Slack 通知で障害の詳細を確認します。
+ 承認者は、Slack の **[承認]** ボタンを使用して承認を開始できます。
1. 承認ハンドラー:
+ 承認 Lambda 関数は、Slack からの承認アクションを処理します。
+ 承認関数は、カスタムメッセージを Amazon SES に発行します。
1. 生成されたメッセージ:
+ 承認関数は、開発者への通知用のカスタムメッセージを生成します。
1. 開発者への通知:
+ Amazon SES は、次のステップまたは必要なアクションを含む E メールメッセージを開発者に送信します。
このワークフローは、手動コードアップロードと自動品質チェックを組み合わせて、Slack を通じて即座にフィードバックを提供し、必要に応じて人間の介入を可能にし、堅牢で柔軟なコードレビュープロセスを確実にします。
**AWS Step Functions ** ロジック
前のアーキテクチャ図に示すように、SonarQube の品質ゲート通過が失敗すると、ワークフローは `CheckBuildStatus` Lambda 関数に移ります。`CheckBuildStatus` 関数は、Slack チャンネルで通知をトリガーします。各通知には、次に実行すべきステップに関する情報が含まれています。次に示すのが通知のタイプです。
+ **アプリケーションがコードセキュリティスキャンで不合格だった** – アップロードされたコードが SonarQube セキュリティスキャンに合格しなかった場合、ユーザーはこの通知を受け取ります。ユーザーは **[APPROVE]** を選択してビルドを受け入れることができます。しかし、この通知は、潜在的なコードの品質問題とセキュリティリスクに注意するようユーザーに忠告します。通知には、次の詳細が含まれます。
+ Next steps: Error: Quality gate status: FAILED – 指定された URL に詳細が表示されます。
+ 指定された URL でドキュメントに記載されている脆弱性の優先順位付けをします。
+ CodeBuild の詳細は、指定された URL で示される場所にあります。
+ **アプリケーションスキャンパイプラインが他の理由で失敗した** – ユーザーは、コードセキュリティスキャンの失敗以外の理由でパイプラインが失敗したときにこの通知を受け取ります。通知には、次の詳細が含まれます。
+ 次のステップについては、さらなるトラブルシューティング用のリンク先を参照してください。
Slack チャンネルに表示される通知のスクリーンショットを表示するには、chatops-slack GitHub リポジトリの[アセットフォルダ](https://github.com/aws-samples/chatops-slack/tree/main/assets)に移動します。
次の図は、品質ゲート通過に失敗した後の Step Functions ステップステータスの例を示しています。
![\[品質ゲート通過に失敗した後の AWS Step Functions ステップステータスのワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/198312ed-e379-49a7-b706-8e79e2142f21/images/40b7ebf0-2518-4413-9717-0bfb7559adde.png)
## ツール
**AWS のサービス**
+ [チャットアプリケーションの Amazon Q Developer](https://docs.aws.amazon.com/chatbot/latest/adminguide/what-is.html) を使用すると、Amazon Chime、Microsoft Teams、Slack チャットチャネルを使用して、 AWS アプリケーションの運用イベントをモニタリングして対応できます。*サポート終了通知:* 2026 年 2 月 20 日に、 AWS は Amazon Chime サービスのサポートを終了します。2026 年 2 月 20 日以降、Amazon Chime コンソールまたは Amazon Chime アプリケーションリソースにアクセスできなくなります。詳細については、こちらの[ブログ記事](https://aws.amazon.com/blogs/messaging-and-targeting/update-on-support-for-amazon-chime/)をご覧ください。これは [Amazon Chime SDK サービス](https://aws.amazon.com/chime/chime-sdk/)の可用性には影響しません。
+ [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) は、 AWS リソースをセットアップし、迅速かつ一貫してプロビジョニングし、 AWS アカウント および 全体のライフサイクルを通じてリソースを管理するのに役立ちます AWS リージョン。
+ [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) は完全マネージド型の構築サービスです。ソースコードのコンパイル、ユニットテストの実行、すぐにデプロイできるアーティファクトの生成を行います。
+ [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、誰を認証し、誰に使用する権限を付与するかを制御することで、 AWS リソースへのアクセスを安全に管理するのに役立ちます。
+ [AWS Key Management Service (AWS KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) は、データの保護に役立つ暗号化キーの作成と制御に役立ちます。
+ [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。
+ [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) を使用すると、コード内のハードコードされた認証情報 (パスワードを含む) を Secrets Manager への API コールで置き換えて、プログラムでシークレットを取得することができます。
+ [Amazon Simple Email Service (Amazon SES)](https://docs.aws.amazon.com/ses/latest/dg/Welcome.html) は、独自の E メールアドレスとドメインを使用して E メールを送受信するのに役立ちます。
+ 「[Amazon Simple Notification Service (Amazon SNS)](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)」は、ウェブサーバーやメールアドレスなど、パブリッシャーとクライアント間のメッセージの交換を調整および管理するのに役立ちます。
+ [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) は、あらゆる量のデータを保存、保護、取得できるクラウドベースのオブジェクトストレージサービスです。
+ [AWS Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) は、 AWS Lambda 関数と他の を組み合わせてビジネスクリティカルなアプリケーション AWS のサービス を構築するのに役立つサーバーレスオーケストレーションサービスです。
**その他のツール**
+ Salesforce の製品である [Slack](https://slack.com/help/articles/115004071768-What-is-Slack-) は、チャットと動画による共同作業を可能にし、ノーコードでプロセスを自動化し、情報共有に対応する AI を活用した会話型プラットフォームです。
+ [SonarQube](https://docs.sonarsource.com/sonarqube/latest/user-guide/user-account/generating-and-using-tokens/) は、30 を超える言語、フレームワーク、IaC プラットフォームでコーディングの問題を検出するように設計されたオンプレミスの分析ツールです。
**コードリポジトリ**
このパターンのコードは [chatops-slack](https://github.com/aws-samples/chatops-slack) GitHub リポジトリから入手可能です。
## ベストプラクティス
+ **CloudFormation スタック管理** – CloudFormation スタックの実行中に障害が発生した場合は、障害が発生したスタックを削除することを推奨します。次に、正しいパラメータ値を使用して再作成します。このアプローチは、クリーンなデプロイを支援し、潜在的な競合や一部だけ実装されることを回避するのに役立ちます。
+ **共有受信トレイ E メール設定** – `SharedInboxEmail` パラメータを設定するときは、関連するすべての開発者がアクセスできる共通の配布グループを使用します。このアプローチは透明性を促進し、関連するチームメンバーへの重要な通知に役立ちます。
+ **本番承認ワークフロー** – 本番環境では、ビルド承認に使用される Slack チャンネルへのアクセスを制限します。指定された承認者のみがこのチャンネルのメンバーである必要があります。この習慣は、明確な責任の連鎖を維持し、重要な変更を承認できるユーザーを制限することでセキュリティを強化します。
+ **IAM アクセス権限** – 最小特権の原則に従い、タスクの実行に必要最小限の権限を付与します。詳細については、IAM ドキュメントの「[最小限の特権を認める。](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#grant-least-priv)」と「[IAM でのセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/IAMBestPracticesAndUseCases.html)」を参照してください。
## エピック
### 初期セットアップを実行する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| リポジトリのクローン作成 | このパターンの [chatops-slack](https://github.com/aws-samples/chatops-slack) リポジトリを複製するには、次のコマンドを使用します。`git clone "git@github.com:aws-samples/chatops-slack.git"` | AWS DevOps、ビルドリード、DevOps エンジニア、クラウド管理者 |
| Lambda コードを含む .zip ファイルを作成する。 | `CheckBuildStatus` および `ApprovalEmail`機能の AWS Lambda 関数コードの .zip ファイルを作成します。`notification.zip` と `approval.zip` を作成するには、次のコマンドを使用します。cd chatops-slack/src
chmod -R 775 *
zip -r approval.zip approval
zip -r notification.zip notification
| AWS DevOps、ビルドリード、DevOps エンジニア、クラウド管理者 |
### pre-requisite.yml スタックファイルをデプロイする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| `pre-requisite.yml` スタックファイルを実行する。 | `pre-requisite.yml` CloudFormation スタックファイルは、`app-security.yml` スタックファイルを実行する前に必要な初期リソースをデプロイします。`pre-requisite.yml` ファイルを実行するには、次の手順を実施します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-chatops-solution-to-manage-sast-scan-results.html) | AWS 管理者、AWS DevOps、ビルドリード、DevOps エンジニア |
| .zip ファイルを Amazon S3 バケットにアップロードする。 | 前に作成した `notification.zip` および `approval.zip` ファイルを、`S3LambdaBucket` という名前の Amazon S3 バケットにアップロードします。`app-security.yml` CloudFormation スタックファイルは、`S3LambdaBucket` を使用して Lambda 関数を割り当てます。 | AWS DevOps、ビルドリード、DevOps エンジニア、AWS システム管理者 |
### app-security.yml スタックファイルを実行する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| `app-security.yml` スタックファイルを実行する。 | `app-security.yml` スタックファイルは、通知と承認システムの残りのインフラストラクチャをデプロイします。`app-security.yml` ファイルを実行するには、次の手順を実施します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-chatops-solution-to-manage-sast-scan-results.html) | AWS DevOps、AWS システム管理者、DevOps エンジニア、ビルドリード |
| 通知設定をテストする。 | 通知設定をテストするには、次の手順を実施します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-chatops-solution-to-manage-sast-scan-results.html)テストメッセージが正常に配信されると、Slack チャンネルに通知が表示されます。詳細については、「Amazon Q Developer in chat applications Administrator Guide」の[「Test notifications from AWS のサービス to Slack](https://docs.aws.amazon.com/chatbot/latest/adminguide/slack-setup.html#test-notifications-slack)」を参照してください。 ** | AWS DevOps、AWS システム管理者、DevOps エンジニア、ビルドリード |
### 承認フローを設定する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| カスタム Lambda アクションを設定する。 | カスタム AWS Lambda アクションを設定するには、以下を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-chatops-solution-to-manage-sast-scan-results.html) | AWS 管理者、AWS DevOps、ビルドリード、DevOps エンジニア、Slack 管理者 |
| 承認フローを検証する。 | 承認フローが期待どおりに機能することを検証するには、Slack の **[Approve]** ボタンを選択します。**承認 E メールが正常に送信された**ことを示す確認文字列の通知が、Slackbot からメッセージスレッドに送信されるはずです。 | AWS 管理者、AWS DevOps、DevOps エンジニア、Slack 管理者 |
## トラブルシューティング
| 問題 | ソリューション |
| --- | --- |
| Slack の設定ミス | Slack の設定ミスに関連する問題のトラブルシューティングについては、「*Amazon Q Developer in chat applications Administrator Guide*」の「Troubleshooting Amazon Q Developer」を参照してください。 |
| 他の理由でのスキャン失敗 | このエラーは、コードビルドタスクが失敗したことを意味します。この問題をトラブルシューティングするには、メッセージ内のリンクで示される場所に移動します。コードビルドタスクの失敗には、次の原因が考えられます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-chatops-solution-to-manage-sast-scan-results.html) |
## 関連リソース
**AWS ドキュメント**
+ [Configure a Slack client](https://docs.aws.amazon.com/chatbot/latest/adminguide/slack-setup.html#slack-client-setup)
+ [カスタムアクションの作成](https://docs.aws.amazon.com/chatbot/latest/adminguide/custom-actions.html#creating-custom-actions)
+ [Creating an email address identity](https://docs.aws.amazon.com/ses/latest/dg/creating-identities.html#verify-email-addresses-procedure) [procedure](https://docs.aws.amazon.com/ses/latest/dg/creating-identities.html#verify-email-addresses-procedure)
+ [チュートリアル: Slack の使用を開始する](https://docs.aws.amazon.com/chatbot/latest/adminguide/slack-setup.html)
**その他のリソース**
+ [Slack ワークスペースにアプリを追加する](https://slack.com/intl/en-in/help/articles/202035138-Add-apps-to-your-Slack-workspace) (Slack ドキュメント)
+ [Generating and using tokens](https://docs.sonarsource.com/sonarqube/latest/user-guide/user-account/generating-and-using-tokens/) (SonarQube ドキュメント)
+ [Introduction to the server installation](https://docs.sonarsource.com/sonarqube/latest/setup-and-upgrade/install-the-server/introduction/) (SonarQube ドキュメント)
## 追加情報
このソリューションは、リリース管理の目的における、チャットアプリケーションの Amazon Q Developer のカスタムアクションに重点を置いています。しかし、特定のユースケースに合わせて Lambda コードを変更し、それを活用することで、ソリューションを再利用できます。
**CloudFormation スタックファイルのパラメータ**
次の表は、CloudFormation スタックファイル `pre-requisite.yml` のパラメータとその説明を示しています。
|
|
| **キー** | **説明** |
| --- |--- |
| `StackName` | CloudFormation スタックの名前。 |
| `S3LambdaBucket` | Lambda コードをアップロードした Amazon S3 バケットの名前。名前はグローバルに一意である必要があります。 |
| `SonarToken` | 「[前提条件](#deploy-chatops-solution-to-manage-sast-scan-results-prereqs)」で説明されている SonarQube ユーザートークン。 |
次の表は、CloudFormation スタックファイル `app-security.yml` のパラメータとその説明を示しています。
|
|
| **キー** | **説明** |
| --- |--- |
| `CKMSKeyArn` | このスタックで作成された IAM ロールと Lambda 関数で使用される AWS KMS key Amazon リソースネーム (ARN)。 |
| `CKMSKeyId` | このスタックで作成された Amazon SNS トピックで使用される AWS KMS key ID。 |
| `EnvironmentType` | アプリケーションスキャンパイプラインをデプロイするクライアント環境の名前。許可された値のドロップダウンリストから環境名を選択します。 |
| `S3LambdaBucket` | `approval.zip` と `notification.zip` ファイルを含む、Amazon S3 バケットの名前。 |
| `SESEmail` | 「[前提条件](#deploy-chatops-solution-to-manage-sast-scan-results-prereqs)」で説明されている Amazon SES に登録された E メール ID の名前。この ID は送信元の E メールアドレスです。 |
| `SharedInboxMail` | スキャン通知の送信先 E メールアドレス。 |
| `SlackChannelId` | 通知を送信する Slack チャンネルのチャンネル ID。チャンネル ID を見つけるには、Slack アプリの **[Channel Details]** でチャンネル名を右クリックします。チャンネル ID は下部にあります。 |
| `SlackWorkspaceId` | 「[前提条件](#deploy-chatops-solution-to-manage-sast-scan-results-prereqs)」で説明されている Slack ワークスペース ID。Slack ワークスペース ID を検索するには、 にサインインし AWS マネジメントコンソール、チャットアプリケーションコンソールで Amazon Q Developer を開き、**設定済みクライアント**、**Slack**、**WorkspaceID** を選択します。 |
| `StackName` | CloudFormation スタックの名前。 |
| `SonarFileDirectory` | `sonar.project..properties` ファイルを含むディレクトリ。 |
| `SonarFileName` | `sonar.project.properties` ファイルの名前。 |
| `SourceCodeZip` | `sonar.project.properties` ファイルとソースコードが含まれている .zip ファイルの名前。 |
# Terraform を使用して CrewAI フレームワークで Amazon Bedrock にエージェンティックシステムを展開する
*Amazon Web Services、Vanitha Dontireddy*
## 概要
このパターンは、[Amazon Bedrock](https://aws.amazon.com/bedrock/?nc1=h_ls) および [Terraform](https://registry.terraform.io/) と統合された [CrewAI](https://www.crewai.com/) フレームワークを使用して、拡張性のあるマルチエージェント AI システムを実装する方法を示しています。このソリューションにより、組織は Infrastructure as Code (IaC) を通じて高度な AI エージェントワークフローを作成、展開、管理できます。このパターンでは、CrewAI マルチエージェントオーケストレーション機能を Amazon Bedrock 基盤モデルと Terraform インフラストラクチャ自動化と組み合わせています。その結果、チームは人間による監視を最小限に抑えながら、複雑なタスクに取り組むためのリリース可能な AI システムを構築できます。このパターンは、エンタープライズ等級のセキュリティ、スケーラビリティ、運用に対する最良の手法を実装しています。
## 前提条件と制限
**前提条件**
+ [Amazon Bedrock 基盤モデルにアクセス](https://docs.aws.amazon.com/bedrock/latest/userguide/model-access.html)するための適切なアクセス許可 AWS アカウント を持つアクティブな
+ Terraform バージョン 1.5 以降が[インストール済み](https://developer.hashicorp.com/terraform/install)
+ Python バージョン 3.9 以降[がインストールされている](https://www.python.org/downloads/)
+ CrewAI フレームワークが[インストール済み](https://docs.crewai.com/installation)
**制限事項**
+ エージェントとのやり取りは、モデルコンテキストウィンドウによって制限されます。
+ 大規模なデプロイでは、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)」を参照して、サービスのリンクを選択してください。
## アーキテクチャ
このパターンでは、次の相互作用が発生します。
+ Amazon Bedrock は、一連の基盤モデル (FM) を通じてエージェントインテリジェンスの基盤を提供します。これにより、高可用性とスケーラビリティを維持しながら、AI エージェントの自然言語処理 (NLP)、論理的思考、意思決定能力を実現します。
+ CrewAI フレームワークは、AI エージェントを作成および管理するためのコアオーケストレーションレイヤーとして機能します。Amazon Bedrock と統合しながら、エージェントの通信プロトコル、タスクの委譲、ワークフロー管理を処理します。
+ Terraform は、コンピューティングリソース、ネットワーク、セキュリティグループ、 AWS Identity and Access Management (IAM) ロールなどのコードを通じてインフラストラクチャスタック全体を管理します。これにより、環境間で一貫性のある、バージョン管理されたデプロイが保証されます。Terraform デプロイでは、次の機能が作成されます。
+ AWS Lambda CrewAI アプリケーションを実行する 関数
+ コードとレポート用の Amazon Simple Storage Service (Amazon S3) バケット
+ 適切なアクセス許可を持つ IAM ロール
+ Amazon CloudWatch ログ
+ Amazon EventBridge によってスケジュールされた実行
次の図は、Amazon Bedrock と Terraform を使用して CrewAI マルチエージェントシステムを展開するためのアーキテクチャを示しています。
![\[Terraform と Amazon Bedrock を使用して CrewAI マルチエージェントシステムを展開するワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/b46069e9-4c38-405f-b0f0-310eabb06b06/images/b3296b17-e388-46ba-8d71-2ec7ce3ed3e0.png)
この図表は、次のワークフローを示しています:
1. ユーザーはリポジトリを複製します。
1. ユーザーは コマンドを実行して AWS リソース`terraform apply`をデプロイします。
1. Amazon Bedrock モデル設定には、CrewAI エージェントの設定に使用する基盤モデル (FM) の指定が含まれます。
1. EventBridge ルールが確立され、定義されたスケジュールに従って Lambda 関数の実行が開始されます。
1. (スケジュールまたは手動で) トリガーされると、Lambda 関数は と Amazon Bedrock へのアクセス許可を持つ IAM ロールを初期化 AWS のサービス して引き受けます。
1. CrewAI フレームワークは、YAML ファイルからエージェント設定をロードし、特殊な AI エージェント (*AWS インフラストラクチャセキュリティ監査*クルー) を作成します。Lambda 関数は、これらのエージェントを順次実行して、 AWS リソースをスキャンし、セキュリティの脆弱性を分析し、包括的な監査レポートを生成します。
1. CloudWatch Logs は、365 日間の保持期間とコンプライアンス要件のための AWS Key Management Service (AWS KMS) 暗号化を使用して、Lambda 関数から詳細な実行情報をキャプチャします。ログは、エージェントのアクティビティ、エラー追跡、パフォーマンスメトリックを可視化し、セキュリティ監査プロセスの効果的なモニタリングとトラブルシューティングを可能にします。
1. セキュリティ監査レポートが自動的に生成され、指定された Amazon S3 バケットに保存されます。自動セットアップは、運用上のオーバーヘッドを最小限に抑えながら、セキュリティモニタリングの一貫性を維持するのに役立ちます。
最初のデプロイ後、ワークフローは、手動で介入することなく AWS 、インフラストラクチャの継続的なセキュリティ監査とレポートを提供します。
**AI エージェントの概要**
このパターンでは、それぞれに一意のロール、目標、ツールを持つ、複数の AI エージェントを作成します。
+ **セキュリティアナリストエージェント**は、 AWS リソース情報を収集して分析します。
+ **ペネトレーションテスターエージェント**は、 AWS リソースの脆弱性を特定します。
+ **コンプライアンスエキスパートエージェント**は、コンプライアンス標準に照らして設定をチェックします。
+ **レポートライターエージェント**は、検出結果を包括的なレポートに編集します。
これらのエージェントは、一連のタスクで共同作業を行い、集合的なスキルを活用してセキュリティ監査を実行し、包括的なレポートを生成します。(この `config/agents.yaml` ファイルは、このクルーでの各エージェントの機能と設定の概要を示しています。)
セキュリティ分析処理は、次のアクションで構成されます。
1. セキュリティアナリストエージェントは、次のような AWS リソースについて収集されたデータを調べます。
+ Amazon Elastic Compute Cloud (Amazon EC2) インスタンスとセキュリティグループ
+ Amazon S3 バケットと設定
+ IAM ロール、ポリシー、およびアクセス権限
+ 仮想プライベートクラウド (VPC) の設定とネットワーク設定
+ Amazon RDS データベースとセキュリティ設定
+ Lambda 関数と設定
+ 監査範囲内 AWS のサービス のその他
1. 侵入テスターエージェントは潜在的な脆弱性を特定します。
1. エージェントは CrewAI フレームワークを通じて共同作業を行い、検出結果を共有します。
レポート生成は、次のアクションで構成されます。
1. レポートライターエージェントは、他のすべてのエージェントの検出結果を編集します。
1. セキュリティの問題は、サービス、重要度、コンプライアンスへの影響の分類で整理されています。
1. 特定された問題ごとに修復のための推奨事項が生成されます。
1. 包括的なセキュリティ監査レポートはマークダウン記法で作成され、指定された Amazon S3 バケットにアップロードされます。履歴レポートは、コンプライアンス追跡とセキュリティ体制の改善のために保持されます。
ログ記録とモニタリングアクティビティには以下が含まれます。
+ CloudWatch ログは、実行の詳細とエラーをキャプチャします。
+ Lambda 実行メトリックはモニタリングのために記録されます。
**注記**
のコード`aws-security-auditor-crew`は、 AWS サンプルコレクションで利用可能な GitHub [3P-Agentic\$1frameworks](https://github.com/aws-samples/3P-Agentic-Frameworks/blob/main/crewai/aws-security-auditor-crew/README.md) リポジトリから取得されます。
**可用性とスケール**
使用可能なエージェントは、4 つ以上のコアエージェントに拡張できます。追加の専門エージェントに合わせてスケールするには、次の新しいエージェントタイプを検討します。
+ *脅威インテリジェンススペシャリスト*エージェントは、以下を実行できます。
+ 外部の脅威フィードをモニタリングし、内部検出結果と関連付けます
+ インフラストラクチャに関連する新たな脅威に関する背景を提供します。
+ 実環境での悪用に基づいて脆弱性の優先順位付けをする
+ *コンプライアンスフレームワーク*エージェントは、次のような特定の規制分野に集中できます。
+ Payment Card Industry Data Security Standard (PCI DSS) コンプライアンスエージェント
+ 1996 年の医療保険の携行性と責任に関する法律 (HIPAA) コンプライアンスエージェント
+ System and Organization Controls 2 (SOC 2) コンプライアンスエージェント
+ EU 一般データ保護規則 (GDPR) コンプライアンスエージェント
利用可能なエージェントを慎重に拡張することで、このソリューションは大規模な AWS 環境全体でスケーラビリティを維持しながら、より深く、より専門的なセキュリティインサイトを提供できます。実装方法、ツール開発、スケールに関する考慮事項の詳細については、「[追加情報](#deploy-agentic-systems-on-amazon-bedrock-with-the-crewai-framework-additional)」を参照してください。
## ツール
**AWS のサービス**
+ [Amazon Bedrock](https://docs.aws.amazon.com/bedrock/latest/userguide/what-is-bedrock.html) は、高パフォーマンスな基盤モデル (FM) を、統合 API を通じて利用できるようにする完全管理型 AI サービスです。
+ [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) を使用すると、すべてのシステム、アプリケーション、および からのログを一元化 AWS のサービス できるため、ログをモニタリングして安全にアーカイブできます。
+ [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) は、アプリケーションをさまざまなソースのリアルタイムデータに接続できるようにするサーバーレスイベントバスサービスです。例えば、 AWS Lambda 関数、API 送信先を使用する HTTP 呼び出しエンドポイント、その他のイベントバスなどです AWS アカウント。このパターンでは、エージェントワークフローのスケジューリングとオーケストレーションに使用されます。
+ [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、誰が認証され、誰に使用を許可するかを制御することで、 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 のサービス。
+ [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) は、あらゆる量のデータを保存、保護、取得できるクラウドベースのオブジェクトストレージサービスです。このパターンでは、エージェントアーティファクトとステート管理用のオブジェクトストレージを提供します。
**その他のツール**
+ [CrewAI](https://www.crewai.com/open-source) は、マルチエージェント AI システムを構築するためのオープンソースで Python ベースのフレームワークです。
+ 「[Terraform](https://www.terraform.io/)」は、HashiCorp の infrastructure as code (IaC) ツールで、クラウドとオンプレミスのリソースの作成と管理を支援します。
**コードリポジトリ**
このパターンのコードは、GitHub 「[deploy-crewai-agents-terraform](https://github.com/aws-samples/deploy-crewai-agents-terraform.git)」リポジトリから入手可能です。
## ベストプラクティス
+ Amazon S3 バックエンドを Amazon DynamoDB ロックと共に使用して、Terraform の適切な状態管理を実装します。詳細については、*「Terraform AWS プロバイダーを使用するためのベストプラクティス*」の[「バックエンド](https://docs.aws.amazon.com/prescriptive-guidance/latest/terraform-aws-provider-best-practices/backend.html)のベストプラクティス」を参照してください。
+ ワークスペースを使用して、開発環境、ステージング環境、本番環境を分離します。
+ 最小特権の原則に従い、タスクの実行に必要最小限のアクセス許可を付与します。詳細については、IAM ドキュメントの「[最小限の特権を認める。](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#grant-least-priv)」と「[IAM でのセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)」を参照してください。
+ CloudWatch ログを使用して詳細なログ記録とモニタリングを有効にします。
+ エージェントオペレーションの再試行メカニズムとエラー処理を実装します。
## エピック
### CrewAI フレームワークを展開する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| リポジトリのクローン作成 | ローカルマシンでこのパターンのリポジトリの複製を作成するには、次のコマンドを実行します。git clone "git@github.com:aws-samples/deploy-crewai-agents-terraform.git"
cd deploy-crewai-agents-terraform
| DevOps エンジニア |
| 環境変数を編集します。 | 環境変数を編集するには、以下の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-agentic-systems-on-amazon-bedrock-with-the-crewai-framework.html) | DevOps エンジニア |
| インフラストラクチャを作成する。 | インフラストラクチャを作成するには、次のコマンドを実行します。cd terraform
terraform init
terraform plan
実行計画を注意深く確認します。計画された変更が許容できる場合は、次のコマンドを実行します。terraform apply --auto-approve
| DevOps エンジニア |
### CrewAI エージェントにアクセスする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| エージェントにアクセスする。 | AWS インフラストラクチャセキュリティ監査およびレポートクルーのエージェントは、Lambda 関数としてデプロイされます。エージェントにアクセスするには、次の手順を使用します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-agentic-systems-on-amazon-bedrock-with-the-crewai-framework.html) | DevOps エンジニア |
| (オプション) エージェントの手動実行を設定する。 | エージェントは、毎日のスケジュール (UTC 午前 0 時) で自動的に実行されるように設定されています。ただし、次の手順を使用して手動で実行を開始できます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-agentic-systems-on-amazon-bedrock-with-the-crewai-framework.html)詳細については、「Lambda ドキュメント」の「[コンソールでの Lambda 関数のテスト](https://docs.aws.amazon.com/lambda/latest/dg/testing-functions.html)」を参照してください。 | DevOps エンジニア |
| デバッグ用のエージェントログにアクセスする。 | CrewAI エージェントは、セキュリティ監査を実行し、Amazon S3 にレポートを保存するために必要なアクセス許可を持つ Lambda 環境で実行されています。出力は、 AWS インフラストラクチャの包括的なセキュリティ分析を提供するマークダウンレポートです。エージェントの動作の詳細なデバッグを支援するには、以下の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-agentic-systems-on-amazon-bedrock-with-the-crewai-framework.html) | DevOps エンジニア |
| エージェント実行の結果を表示する。 | エージェント実行の結果を表示するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-agentic-systems-on-amazon-bedrock-with-the-crewai-framework.html)レポートは、次のようなタイムスタンプベースのファイル名で保存されます。`security-audit-report-YYYY-MM-DD-HH-MM-SS.md)` | DevOps エンジニア |
| エージェントの実行をモニタリングする。 | CloudWatch Logs を使用してエージェントの実行をモニタリングするには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-agentic-systems-on-amazon-bedrock-with-the-crewai-framework.html) | DevOps エンジニア |
| エージェントの動作をカスタマイズする。 | エージェントもしくはそのタスクを変更するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-agentic-systems-on-amazon-bedrock-with-the-crewai-framework.html)cd terraform
terraform apply
| DevOps エンジニア |
### リソースをクリーンアップする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| 作成したリソースを削除します。 | このパターンによって作成されたすべてのインフラストラクチャを削除するには、次のコマンドを実行します。terraform plan -destroy
次のコマンドは、このパターンによって作成されたすべてのリソースを完全に削除します。リソースを削除する前にコマンドから確認を求められます。破棄計画は注意して確認してください。計画された削除が許容される場合は、次のコマンドを実行します。terraform destroy
| DevOps エンジニア |
## トラブルシューティング
| 問題 | ソリューション |
| --- | --- |
| エージェントの動作 | この問題の詳細については、Amazon Bedrock ドキュメントの「[Test and troubleshoot agent behavior](https://docs.aws.amazon.com/lambda/latest/dg/troubleshooting-networking.html)」を参照してください。 |
| Lambda ネットワークの問題 | これらの問題の詳細については、「Lambda ドキュメント」の「[Lambda でのネットワーク問題のトラブルシューティング](https://docs.aws.amazon.com/lambda/latest/dg/troubleshooting-networking.html)」を参照してください。 |
| IAM アクセス許可 | これらの問題の詳細については、IAM ドキュメントの「[IAM のトラブルシューティング](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot.html)」を参照してください。 |
## 関連リソース
**AWS ブログ**
+ 「[Build agentic systems with CrewAI and Amazon Bedrock](https://aws.amazon.com/blogs/machine-learning/build-agentic-systems-with-crewai-and-amazon-bedrock/)」
**AWS ドキュメント**
+ [Amazon Bedrock ドキュメント](https://docs.aws.amazon.com/bedrock/)
+ [Amazon Bedrock エージェントの仕組み](https://docs.aws.amazon.com/bedrock/latest/userguide/agents-how.html)
+ [AWS Well-Architected フレームワーク](https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html)
**その他のリソース**
+ [CrewAI ドキュメント](https://docs.crewai.com/introduction)
+ [Terraform AWS プロバイダーのドキュメント](https://registry.terraform.io/providers/hashicorp/aws/latest/docs)
## 追加情報
このセクションでは、先の[自動化とスケール](#deploy-agentic-systems-on-amazon-bedrock-with-the-crewai-framework-architecture)の議論に関連して、実装アプローチ、ツール開発、スケールに関する考慮事項について説明します。
**実装アプローチ**
エージェントを追加する際、次のアプローチを検討してください。
1. エージェントの設定
+ `config/agents.yaml` ファイルに新しいエージェント定義を追加します。
+ エージェントごとに特殊なバックストーリー、目標、ツールを定義します。
+ エージェントの専門分野に基づいてメモリと分析機能を設定します。
1. タスクのオーケストレーション
+ `config/tasks.yaml` ファイルを更新して、新しいエージェント固有のタスクを含めます。
+ タスク間に依存関係を作成して、適切な情報フローを確保します。
+ 必要に応じて並列タスク実行を実装します。
**技術的な実装**
次に示すのは、提案された脅威インテリジェンススペシャリストエージェントの `agents.yaml` ファイルへの追加です。
```
Example new agent configuration in agents.yaml
threat_intelligence_agent:
name: "Threat Intelligence Specialist"
role: "Cybersecurity Threat Intelligence Analyst"
goal: "Correlate AWS security findings with external threat intelligence"
backstory: "Expert in threat intelligence with experience in identifying emerging threats and attack patterns relevant to cloud infrastructure."
verbose: true
allow_delegation: true
tools:
- "ThreatIntelligenceTool"
- "AWSResourceAnalyzer"
```
**ツール開発**
CrewAI フレームワークを使用すると、セキュリティ監査のクルーの有効性を高めるために、次のアクションを取ることができます。
+ 新しいエージェントのカスタムツールを作成します。
+ 脅威インテリジェンスのために外部 API と統合します。
+ さまざまな 専用のアナライザーを開発します AWS のサービス。
**スケーリングに関する考慮事項**
AWS インフラストラクチャセキュリティ監査およびレポートシステムを拡張して大規模な環境やより包括的な監査を処理する場合は、次のスケーリング要因に対処します。
+ **計算リソース**
+ Lambda メモリ割り当てを増やして、追加のエージェントを処理します。
+ エージェントワークロードを複数の Lambda 関数に分割することを検討します。
+ **コスト管理**
+ エージェント数の増加に応じて Amazon Bedrock API の使用状況をモニタリングします。
+ 監査範囲に基づいて選択的なエージェントの有効化を実装します。
+ **コラボレーション効率**
+ エージェント間の情報共有を最適化します。
+ 複雑な環境のために階層型エージェント構成を実装します。
+ **知識ベースの機能強化**
+ エージェントにドメインの専門知識ベースを提供します。
+ 新しいセキュリティのベストプラクティスを使用して、エージェントの知識を定期的に更新します。
# AWS CodePipeline CI/CD パイプラインで AWS Glue ジョブをデプロイする
*Amazon Web Services、Bruno Klein、Luis Henrique、Massao Yamada*
## 概要
このパターンは、AWS CodeCommit と AWS CodePipeline を AWS Glue に統合し、開発者が変更をリモートの AWS CodeCommit リポジトリに反映すると直ちに AWS Lambda を使用してジョブを起動する方法を示しています。
開発者が抽出、変換、ロード (ETL) リポジトリに変更を送信し、その変更を AWS CodeCommit にプッシュすると、新しいパイプラインが呼び出されます。パイプラインは、これらの変更を含む AWS Glue ジョブを起動する Lambda 関数を開始します。AWS Glue ジョブは ETL タスクを実行します。
このソリューションは、企業、開発者、データエンジニアが変更をコミットしてターゲットリポジトリにプッシュしたらすぐにジョブを開始する場合に役立ちます。より高いレベルの自動化と再現性を実現できるため、ジョブの起動時とライフサイクル中のエラーを回避できます。
## 前提条件と制限
**前提条件**
+ アクティブな AWS アカウント
+ [Git](https://git-scm.com/) がローカルマシンにインストールされている
+ [Amazon Cloud 開発キット (Amazon CDK)](https://docs.aws.amazon.com/cdk/latest/guide/home.html) がローカルマシンにインストールされている
+ [Python](https://www.python.org/) がローカルマシンにインストールされている
+ *添付ファイル*セクションのコード
**制限**
+ パイプラインは、AWS Glue ジョブが正常に起動されるとすぐに終了します。ジョブの完了を待たずに行われます。
+ 添付のコードはデモ専用です。
## アーキテクチャ
**ターゲットテクノロジースタック**
+ AWS Glue
+ AWS Lambda
+ AWS CodePipeline
+ AWS CodeCommit
**ターゲットアーキテクチャ**
![\[開発者が CodeCommit リポジトリに変更を反映すると、直ちに Lambda を使用して Glue ジョブを起動します。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/99a67388-5939-4267-8324-b6ca8bfa7962/images/917c9041-b94d-4e95-a3c4-9a1115ead228.png)
このプロセスは次の 4 つの手順で構成されます。
1. 開発者またはデータエンジニアは ETL コードを変更してコミットし、その変更を AWS CodeCommit にプッシュします。
1. プッシュによってパイプラインが開始されます。
1. パイプラインは Lambda 関数を開始します。Lambda 関数はリポジトリで `codecommit:GetFile` を呼び出し、ファイルを Amazon Simple Storage Service (Amazon S3) にアップロードします。
1. Lambda 関数は ETL コードで新しい AWS Glue ジョブを起動します。
1. Lambda 関数はパイプラインを終了します。
**自動化とスケール**
添付ファイルのサンプルは、AWS Glue を AWS CodePipeline と統合する方法を示しています。ユーザー自身で使用するためにカスタマイズまたは拡張できるベースラインサンプルを提供します。詳細については、「*エピック*」セクションを参照ください。
## ツール
+ [AWS CodePipeline](https://aws.amazon.com/codepipeline/) – AWS CodePipeline はフルマネージド型の[継続的デリバリー](https://aws.amazon.com/devops/continuous-delivery/)サービスで、アプリケーションとインフラストラクチャの更新を迅速かつ信頼できるものにするパイプラインのリリース自動化に役立ちます。
+ [AWS CodeCommit](https://aws.amazon.com/codecommit/) — AWS CodeCommit は、安全な Git ベースのリポジトリをホストするフルマネージド型の[ソース管理](https://aws.amazon.com/devops/source-control/)サービスです。
+ [AWS Lambda](https://aws.amazon.com/lambda/) – AWS Lambda はサーバーをプロビジョニングまたは管理しなくてもコードを実行できるサーバーレスコンピュートサービスです。
+ [AWS Glue](https://aws.amazon.com/glue) – AWS Glue は、分析、機械学習、アプリケーション開発用のデータの検出、準備、結合を容易にするサーバーレスデータ統合サービスです。
+ [Git クライアント](https://git-scm.com/downloads) — Git は GUI ツールを提供し、コマンドラインまたはデスクトップツールを使用して GitHub から必要なアーティファクトをチェックアウトできます。
+ [AWS CDK](https://aws.amazon.com/cdk/) — AWS CDK は、使い慣れたプログラミング言語を使用してクラウドアプリケーションリソースの定義に役立つオープンソースのソフトウェア開発フレームワークです。
## エピック
### サンプルコードをデプロイする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| AWS CLI を設定します。 | AWS コマンドラインインターフェイス (AWS CLI) を設定し、現在の AWS アカウントをターゲットにして認証します。手順については、[AWS CLI ドキュメント](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html)を参照してください。 | 開発者、DevOpsエンジニア |
| サンプルプロジェクトファイルを抽出します。 | 添付ファイルからファイルを抽出し、サンプルプロジェクトファイルを含めるフォルダを作成します。 | 開発者、DevOpsエンジニア |
| サンプルコードをデプロイします。 | ファイルを抽出したら、抽出場所から以下のコマンドを実行してベースラインサンプルを作成します。cdk bootstrap
cdk deploy
git init
git remote add origin
git stage .
git commit -m "adds sample code"
git push --set-upstream origin main
最後のコマンドの後、パイプラインと AWS Glue ジョブのステータスを監視できます。 | 開発者、DevOpsエンジニア |
| コードをカスタマイズします。 | etl.py ファイルのコードをビジネス要件に合わせてカスタマイズします。ETL コードを改訂、パイプラインステージを変更、またはソリューションを拡張できます。 | データエンジニア |
## 関連リソース
+ [AWS CDK の使用開始](https://docs.aws.amazon.com/cdk/latest/guide/getting_started.html)
+ [AWS Glue にジョブを追加する](https://docs.aws.amazon.com/glue/latest/dg/add-job.html)
+ [CodePipeline のソースアクション統合](https://docs.aws.amazon.com/codepipeline/latest/userguide/integrations-action-type.html#integrations-source)
+ [CodePipeline の パイプラインで AWS Lambda 関数を呼び出す](https://docs.aws.amazon.com/codepipeline/latest/userguide/actions-invoke-lambda-function.html)
+ [AWS Glue プログラミング](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-programming.html)
+ [AWS CodeCommit GetFile API](https://docs.aws.amazon.com/codecommit/latest/APIReference/API_GetFile.html)
## アタッチメント
このドキュメントに関連する追加コンテンツにアクセスするには、次のファイルを解凍してください。「[attachment.zip](samples/p-attach/99a67388-5939-4267-8324-b6ca8bfa7962/attachments/attachment.zip)」
# AWS CodePipeline、AWS CodeCommit、AWS CodeBuild を使用して、複数の AWS リージョンにコードをデプロイする
*Amazon Web Services、Anand Krishna Varanasi*
## 概要
このパターンは、AWS AWS CloudFormation を使用して複数のAmazon Web Services (AWS) リージョンにまたがるインフラストラクチャまたはアーキテクチャを構築する方法を示しています。 これには、複数の AWS リージョンにわたる継続的インテグレーション (CI) / 継続的デプロイ (CD) が含まれており、デプロイを迅速に行うことができます。** **このパターンのステップは、例として 3 つの AWS リージョンにデプロイする AWS CodePipeline ジョブの作成でテストされています。ユースケースに基づいてリージョン数を変更できます。
## 前提条件と制限
**前提条件**
+ アクティブな AWS アカウント。
+
+ *AmazonS3FullAccess* ポリシーと *CloudWatchFullAccess* ポリシーを含む CodeBuild ロール。これらのポリシーは、CodeBuild に Amazon CloudWatch を通じて AWS CodeCommit のイベントをモニタリングしたり、Amazon Simple Storage Service (Amazon S3) をアーティファクトストアとして使用したりするためのアクセス権を付与します。
+ 以下のポリシーを持つ AWS CloudFormation ロール。これにより、AWS CloudFormation は、ビルドの最終段階で AWS Lambda 関数を作成または更新したり、Amazon CloudWatch Logs をプッシュまたはモニタリングしたり、変更セットを作成および更新したりできるようになります。
+ *AWSLambdaFullAccess*
+ *AWSCodeDeployFullAccess*
+ *CloudWatchFullAccess*
+ *AWSCloudFormationFullAccess*
+ *AWSCodePipelineFullAccess*
**注記**
AWS CodeBuild と AWS CloudFormation の 2 つの AWS Identity and Access Management (IAM) ロールには、アーティファクトのテスト、バンドル、パッケージ化、複数の AWS リージョンへのデプロイという CI タスクを並列して実行するための CodeBuild 用の適切なポリシーがあります。 CodePipeline によって作成されたポリシーをクロスチェックして、CodeBuild と AWS CloudFormation が CI フェーズと CD フェーズで適切なアクセス権限を持っていることを確認します。
## アーキテクチャ
![\[3 つの AWS リージョンにデプロイする AWS CodePipeline ジョブ。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/d44c393c-7243-4d4e-8b84-88a8503af98f/images/5c27fc35-5e62-4292-8b18-a7bc7faf2631.png)
このパターンの複数リージョンのアーキテクチャとワークフローは以下のステップで構成されています。
1. CodeCommit リポジトリにコールを送信します。
1. コードの更新またはコミットを受信すると、CodeCommit は CloudWatch イベントを呼び出し、そのイベントによって CodePipeline ジョブが開始されます。
1. CodePipeline は CodeBuild によって処理される CI を利用します。以下のタスクが実行されます。
+ AWS CloudFormation テンプレートのテスト (オプション)
+ デプロイに含まれる各リージョンの AWS CloudFormation テンプレートをパッケージ化します。例えば、このパターンは 3 つの AWS リージョンに並列にデプロイされるため、CodeBuild は AWS CloudFormation テンプレートを、指定された各リージョンに 1 つずつ、合計 3 つの S3 バケットにパッケージ化します。S3 バケットは CodeBuild によってアーティファクトリポジトリとしてのみ使用されます。
1. CodeBuild は、3 つの AWS リージョンで並列に実行される次のデプロイフェーズの入力としてアーティファクトをパッケージ化します。 異なる数のリージョンを指定すると、CodePipeline はそれらのリージョンにデプロイされます。
## ツール
**ツール**
+ [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) – AWS CodePipelineは、ソフトウェアを継続的に変更するために必要な手順のモデル化、視覚化、および自動化に使用できる継続的な配信サービスです。
+ [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) – CodeBuild は、ソースコードをコンパイルし、ユニットテストを実行し、すぐにデプロイできるアーティファクトを生成するフルマネージドビルドサービスです。
+ [AWS CodeCommit](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html) — CodeCommit は、Amazon Web Services がホスティングするバージョン管理サービスで、アセット（ソースコード、バイナリファイルなど）をクラウド内で非公開で保存して管理するために使用できます。
+ [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) – AWS CloudFormation は、Amazon Web Services リソースのモデル化とセットアップを支援するサービスであるため、これらのリソースの管理に費やす時間を減らし、AWS で実行されるアプリケーションに集中する時間を増やすことができます。
+ [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) – AWS Identity and Access Management (IAM) は、AWS リソースへのアクセスをセキュアに制御するのに役立つウェブサービスです。
+ 「[Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/dev/Welcome.html)」— Amazon Simple Storage Service (Amazon S3)は、インターネット用のストレージです。Web スケールのコンピューティングを開発者が容易にできるように設計されています。
**コード**
次のサンプルコードは `BuildSpec.yaml` ファイル (ビルドフェーズ) 用です。
```
---
artifacts:
discard-paths: true
files:
- packaged-first-region.yaml
- packaged-second-region.yaml
- packaged-third-region.yaml
phases:
build:
commands:
- echo "********BUILD PHASE - CF PACKAGING**********"
- "aws cloudformation package --template-file sam-template.yaml --s3-bucket $S3_FIRST_REGION --output-template-file packaged-first-region.yaml --region $FIRST_REGION"
- "aws cloudformation package --template-file sam-template.yaml --s3-bucket $S3_SECOND_REGION --output-template-file packaged-second-region.yaml --region $SECOND_REGION"
- "aws cloudformation package --template-file sam-template-anand.yaml --s3-bucket $S3_THIRD_REGION --output-template-file packaged-third-region.yaml --region $THIRD_REGION"
install:
commands:
- echo "********BUILD PHASE - PYTHON SETUP**********"
runtime-versions:
python: 3.8
post_build:
commands:
- echo "********BUILD PHASE - PACKAGING COMPLETION**********"
pre_build:
commands:
- echo "********BUILD PHASE - DEPENDENCY SETUP**********"
- "npm install --silent --no-progress"
- echo "********BUILD PHASE - DEPENDENCY SETUP DONE**********"
version: 0.2
```
## エピック
### コードと CodeCommit リポジトリを準備します。
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| デプロイするプライマリ AWS リージョンを選択します。 | AWS アカウントにサインインして、デプロイするプライマリリージョンを選択します。CodeCommit リポジトリはプライマリ リージョンにあります。 | DevOps |
| CodeCommit リポジトリを作成します。 | CodeCommit リポジトリを作成し、必要なコードをプッシュします。コードには通常、AWS CloudFormation または AWS SAM テンプレート、Lambda コード (ある場合)、および AWS CodePipeline への入力としての CodeBuild `buildspec.yaml` ファイルが含まれます。 | DevOps |
| コードを CodeCommit リポジトリにプッシュします。 | 「*添付ファイル*」セクションで、この例のコードをダウンロードし、必要なコードをそのコードにプッシュします。通常、コードには、パイプラインへの入力として AWS CloudFormation または AWS SAM テンプレート、Lambda コード、および CodeBuild `buildspec.yaml` ファイルを含めることができます。 | DevOps |
### ソースフェーズ: パイプラインを作成する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| CodePipeline ジョブを作成します。 | CodePipeline コンソールで、[**パイプラインの作成**] を選択します。 | DevOps |
| CodePipeline ジョブに名前を付け、サービスロール設定を選択します。 | ジョブの名前を入力し、デフォルトのサービスロール設定のままにして、CodePipeline が必要なポリシーをアタッチしたロールを作成します。 | DevOps |
| アーティファクトストアの場所を指定します。 | [**詳細設定**] では、デフォルトのオプションをそのまま使用して、CodePipeline がコードアーティファクトストレージに使用する S3 バケットを作成します。代わりに既存の S3 バケットを使用する場合、そのバケットは最初のエピックで指定したプライマリリージョンにある必要があります。 | DevOps |
| 暗号化キーを指定します。 | デフォルトのオプションである**デフォルトの AWS マネージドキー**をそのまま使用するか、AWS Key Management Service (AWS KMS) のカスタマーマネージドキーを使用します。 | DevOps |
| ソースプロバイダを指定します。 | [**ソースプロバイダ**] には、**AWS CodeCommit** を選択します。 | DevOps |
| リポジトリを指定します。 | 最初のエピックで作成した CodeCommit リポジトリを選択します。ブランチにコードを配置した場合は、ブランチを選択します。 | DevOps |
| コード変更の検出方法を指定します。 | CodeCommit が CodePipeline ジョブを開始するための変更トリガーとして、デフォルトの **Amazon CloudWatch Events** ままにします。 | DevOps |
### ビルドフェーズ:パイプラインを設定する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| ビルドプロバイダを指定します。 | [ビルドプロバイダ] には、[**AWS CodeBuild**] を選択します。 | DevOps |
| AWS リージョンを指定します。 | 最初のエピックで指定したプライマリ リージョンを選択します。 | DevOps |
### ビルドフェーズ:プロジェクトを作成して設定する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| プロジェクトの作成 | プロジェクトの名前を入力し、[**プロジェクトの作成**] を選択します。 | DevOps |
| 環境イメージを指定します。 | このパターンのデモンストレーションでは、デフォルトの CodeBuild マネージドイメージを使用します。 また、カスタムの Docker イメージがある場合は、使用することもできます。 | DevOps |
| オペレーティングシステムを指定します。 | Amazon Linux 2 または Ubuntu のいずれかを選択します。Amazon Linux 2 のサポートは間もなく終了します。詳細については、「[Amazon Linux 2 に関するよくある質問](https://aws.amazon.com/amazon-linux-2/faqs/)」を参照してください。 | DevOps |
| サービスロールを指定します。 | CodePipeline ジョブの作成を開始する前に CodeBuild 用に作成したロールを選択します。 (「*前提条件*」セクションを参照してください) | DevOps |
| 追加のオプションを設定します。 | [**タイムアウト**] と [**キュータイムアウト**] は、デフォルト値のままにします。証明書については、使用したいカスタム証明書がない限り、デフォルト設定のままにします。 | DevOps |
| 環境変数 | デプロイする AWS リージョンごとに、S3 バケット名とリージョン名 (us-east-1 など) を指定して環境変数を作成します。 | DevOps |
| buildspec.yml でない場合は、buildspec ファイル名を指定します。 | ファイル名がデフォルトの `buildspec.yaml` の場合は、このフィールドを空白のままにします。buildspec ファイルの名前を変更した場合は、ここに名前を入力します。CodeCommit リポジトリ内のファイルの名前と一致することを確認します。 | DevOps |
| ログ記録を指定します。 | Amazon CloudWatch Events のログを表示するには、デフォルト設定のままにします。または、特定のグループ名やロガー名を定義することもできます。 | DevOps |
### デプロイフェーズをスキップします。
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| デプロイフェーズをスキップして、パイプラインの作成を完了します。 | パイプラインを設定すると、CodePipeline ではデプロイフェーズに 1 つのステージのみ作成できます。複数の AWS リージョンにデプロイするには、このフェーズをスキップしてください。パイプラインを作成した後、複数のデプロイ フェーズ段階を追加できます。 | DevOps |
### デプロイフェーズ: パイプラインを最初のリージョンにデプロイするように設定します。
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| デプロイ フェーズにステージを追加します。 | パイプラインを編集し、デプロイ フェーズで**ステージを追加**を選択します。この第 1 ステージはプライマリ リージョン用です。 | DevOps |
| ステージのアクション名を指定します。 | 最初の（プライマリ）ステージおよびリージョンを反映する一意の名前を入力します。たとえば、 **primary\$1<リージョン>\$1deploy** と入力します。 | DevOps |
| アクションプロバイダを指定します。 | [**アクションプロバイダ**] で、AWS CloudFormation を選択します。 | DevOps |
| 第 1 ステージのリージョンを設定します。 | 第 1 (プライマリ) リージョンは、CodePipeline と CodeBuild が設定されているのと同じリージョンを選択します。これは、スタックをデプロイするプライマリ リージョンです。 | DevOps |
| 入力アーティファクトを指定します。 | **BuildArtifact** を選択します。これはビルドフェーズの出力です。 | DevOps |
| 必要なアクションを指定します。 | [**アクションモード**] で、[**スタックを作成または更新する**] をクリックします。 | DevOps |
| CloudFormation スタックの名前を入力します。 | | DevOps |
| 第 1 リージョンのテンプレートを指定します。 | CodeBuild によってパッケージ化され、第 1 (プライマリ) リージョンの S3 バケットにダンプされたリージョン固有のパッケージ名を選択します。 | DevOps |
| 機能を指定します。 | スタックテンプレートに IAM リソースがある場合やマクロを含むテンプレートから直接スタックを作成する場合に、機能が必要です。このパターンでは、CAPABILITY\$1IAM、CAPABILITY\$1NAMED\$1IAM、CAPABILITY\$1AUTO\$1EXPAND を使用します。 | DevOps |
### デプロイフェーズ:パイプラインを第 2 リージョンにデプロイするように設定します。
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| デプロイ フェーズに第 2 ステージを追加します。 | 第 2 リージョンにステージを追加するには、パイプラインを編集し、デプロイ フェーズで [**ステージを追加**] を選択します。重要: 第 2 リージョンの作成プロセスは、次の値を除いて第 1 リージョンの作成プロセスと同じです。 | DevOps |
| 第 2 ステージのアクション名を指定します。 | 第 2 ステージと第 2 リージョンを表す一意の名前を入力します。 | DevOps |
| 第 2 ステージのリージョンを設定します。 | スタックをデプロイする第 2 リージョンを選択します。 | DevOps |
| 第 2 リージョンのテンプレートを指定します。 | CodeBuild によってパッケージ化され、第 2 リージョンの S3 バケットにダンプされたリージョン固有のパッケージ名を選択します。 | DevOps |
### デプロイフェーズ:パイプラインを第 3 リージョンにデプロイするように設定します。
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| デプロイ フェーズにステージを追加します。 | 第 3 リージョンにステージを追加するには、パイプラインを編集し、デプロイフェーズで [**ステージを追加**] を選択します。重要: 第 2 リージョンの作成プロセスは、次の値を除いて、これまでの 2 つのリージョンの作成プロセスと同じです。 | DevOps |
| 第 3 ステージのアクション名を指定します。 | 第 3 ステージと第 3 リージョンを表す一意の名前を入力します。 | DevOps |
| 第 3 ステージのリージョンを設定します。 | スタックをデプロイする第 3 リージョンを選択します。 | DevOps |
| 第 3 リージョンのテンプレートを指定します。 | CodeBuild によってパッケージ化され、第 3 リージョンの S3 バケットにダンプされたリージョン固有のパッケージ名を選択します。 | DevOps |
### デプロイをクリーンアップする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| AWS リソースを削除します。 | デプロイをクリーンアップするには、各リージョンの CloudFormation スタックを削除します。次に、CodeCommit、CodeBuild、および CodePipeline リソースをプライマリリージョンから削除します。 | DevOps |
## 関連リソース
+ 「[AWS CodePipeline とは何ですか?](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)」
+ 「[AWS サーバーレスアプリケーションモデル](https://aws.amazon.com/serverless/sam/)」
+ 「[AWS CloudFormation](https://aws.amazon.com/cloudformation/)」
+ 「[AWS CodePipeline 用の AWS CloudFormation アーキテクチャ構造リファレンス](https://docs.aws.amazon.com/codepipeline/latest/userguide/action-reference-CloudFormation.html)」
## アタッチメント
このドキュメントに関連する追加コンテンツにアクセスするには、次のファイルを解凍してください。「[attachment.zip](samples/p-attach/d44c393c-7243-4d4e-8b84-88a8503af98f/attachments/attachment.zip)」
# Azure DevOps パイプラインからプライベート Amazon EKS クラスターにワークロードをデプロイする
*Amazon Web Services、Mahendra Revanasiddappa*
## 概要
このパターンは、Azure DevOps パイプラインからプライベート Amazon Elastic Kubernetes Service (Amazon EKS) クラスターに継続的インテグレーションおよび継続的デリバリー (CI/CD) を実装する方法を示しています。Amazon EKS クラスターのプライベート API サーバーエンドポイントに移行することにより、セキュリティ体制を強化している組織が直面する重大な課題に対処します。
パブリックエンドポイントは Kubernetes API サーバーをインターネットに直接公開するため、悪意のある攻撃者のターゲットとなりうる大きなアタックサーフェスが発生します。プライベートエンドポイントに切り替えると、クラスターのコントロールプレーンへのアクセスが顧客の仮想プライベートクラウド (VPC) 内に限定されます。
Amazon EKS クラスターをプライベート API エンドポイントに移行するとセキュリティが大幅に強化されますが、Azure DevOps などの外部 CI/CD プラットフォームに接続の課題が生じます。プライベートエンドポイントにアクセスできるのは、クラスターの VPC またはピアネットワーク内からのみです。したがって、 AWS プライベートネットワーク外で動作する標準の Microsoft がホストする Azure DevOps エージェントは、Kubernetes API サーバーに直接到達できません。これらのエージェントで実行されている kubectl や Helm などのツールに依存する一般的なデプロイワークフローは、クラスターへの接続を確立できないため、中断されます。
この問題を解決するために、このパターンでは、プライベート Amazon EKS クラスター内でセルフホスト型の Azure DevOps エージェントを使用して効率的なアプローチを説明します。このソリューションは、セキュリティ要件を維持しながら、優れたコスト最適化、運用効率、スケーラビリティを提供します。このアプローチは、特に、パフォーマンスやセキュリティを犠牲にすることなく、マルチクラウド DevOps プロセスを合理化しようとする企業にメリットをもたらします。
## 前提条件と制限
**前提条件**
+ アクティブ AWS アカウント。
+ AWS Command Line Interface (AWS CLI) バージョン 2.13.17 以降がインストールされ[ています。](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)
+ kubectl バージョン 1.25.1 以降が[インストールされていること。](https://kubernetes.io/docs/tasks/tools/)
+ 名前空間、シークレット、デプロイを作成するアクセス権限を持つプライベート Amazon EKS クラスターバージョン 1.24 以降[が作成されていること](https://docs.aws.amazon.com/eks/latest/userguide/create-cluster.html)[。](https://docs.aws.amazon.com/eks/latest/userguide/create-cluster.html)
+ インターネットへのアウトバウンド接続を持つ Amazon EKS クラスター内のワーカーノード。これは、ワーカーノードで動作している Azure DevOps エージェントを Azure DevOps エージェントプールに接続できるようにするものです。
+ GitHub アカウントが[作成されていること](https://github.com/signup)。
+ サービス接続を設定できるアクセス権を持つ Azure DevOps プロジェクト (Azure Pipelines と外部サービスまたはリモートサービス間の認証された接続) が[作成されていること](https://learn.microsoft.com/en-us/azure/devops/user-guide/sign-up-invite-teammates?view=azure-devops&tabs=microsoft-account)。
+ 前のポイントで説明した Azure DevOps プロジェクト用にインストールされた AWS Toolkit for Azure DevOps バージョン 1.15 以降。インストール手順は、Visual Studio Marketplace の「[AWS Toolkit for Azure DevOps](https://marketplace.visualstudio.com/items?itemName=AmazonWebServices.aws-vsts-tools)」を参照してください。
**制限事項**
+ 一部の 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)」を参照して、サービスのリンクを選択してください。
## アーキテクチャ
このパターンでは、以下が作成されます。
+ **Amazon ECR リポジトリ** – Amazon Elastic Container Registry (Amazon ECR) リポジトリは、Azure DevOps エージェントとデプロイされたサンプルアプリケーションを使用して Docker イメージを保存します。
+ **Azure DevOps エージェントプール** – Azure DevOps セルフホスト型エージェントプールは、プライベート Amazon EKS クラスターで動作するエージェントを登録します。
+ **IAM ロール** - プライベート Amazon EKS クラスターで実行されているエージェントに必要なアクセスを提供する Azure サービス接続の AWS Identity and Access Management (IAM) ロール。
+ **Azure DevOps サービス接続** – パイプラインジョブが AWS のサービスにアクセスするために必要なアクセスを提供する IAM ロールを使用する Azure DevOps アカウントのサービス接続。
次の図は、プライベート Amazon EKS クラスターにセルフホスト型の Azure DevOps エージェントをデプロイし、同じクラスターにサンプルアプリケーションをデプロイするアーキテクチャを示しています。
![\[プライベート Amazon EKS クラスターへのセルフホスト型の Azure DevOps エージェントとサンプルアプリケーションのデプロイ。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/a965834f-a1e2-4679-bd8c-15eed4f57b55/images/ee22bd3e-311c-46e0-8024-9b7e7752080a.png)
この図表は、次のワークフローを示しています:
1. セルフホスト型の Azure DevOps エージェントを Amazon EKS クラスター内のデプロイとしてデプロイします。
1. Azure DevOps エージェントは、認証のための個人アクセストークン (PAT) を使用して Azure DevOps アカウントのエージェントプールに接続します。
1. Azure Pipelines は、GitHub リポジトリのコードを使用して、デプロイするパイプラインを設定します。
1. パイプラインは、パイプライン設定で設定されたエージェントプールからのエージェントで動作します。Azure DevOps エージェントは、Azure DevOps アカウントに常にポーリングすることにより、パイプラインのジョブ情報を取得します。
1. Azure DevOps エージェントは、Docker イメージをパイプラインジョブの一部として構築し、そのイメージを Amazon ECR リポジトリにプッシュします。
1. Azure DevOps エージェントは、`webapp` という名前空間のプライベート Amazon EKS クラスターにサンプルアプリケーションをデプロイします。
## ツール
**ツール**
+ [Amazon Elastic Container Registry (Amazon ECR)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html) は、セキュリティ、スケーラビリティ、信頼性を備えたマネージドコンテナイメージレジストリサービスです。
+ [Amazon Elastic Kubernetes Service (Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html) を使用すると、独自の Kubernetes コントロールプレーンやノードをインストールまたは維持 AWS することなく、 で Kubernetes を実行できます。
+ [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、誰を認証し、誰に使用する権限を付与するかを制御することで、 AWS リソースへのアクセスを安全に管理するのに役立ちます。
**その他のツール**
+ [Docker](https://www.docker.com/) は、オペレーティングシステムレベルの仮想化を使用してソフトウェアをコンテナで配信するサービスとしてのPlatform as a Service (PaaS) 製品のセットです。
+ [kubectl](https://kubernetes.io/docs/tasks/tools/)は、Kubernetes クラスターに対してコマンドを実行するためのコマンドラインインターフェイスです。
**コードリポジトリ**
+ このパターンのコードは、GitHub の [deploy-kubernetes-resources-to-amazon-eks-using-azure-devops](https://github.com/aws-samples/deploy-kubernetes-resources-to-amazon-eks-using-azure-devops) リポジトリで入手できます。
## ベストプラクティス
+ Amazon EKS については、「[Amazon EKS Best Practices Guide](https://docs.aws.amazon.com/eks/latest/best-practices/introduction.html)」を参照してください。
+ 最小特権の原則に従い、タスクの実行に必要な最小限の権限を付与します。詳細については、IAM ドキュメントの「[最小限の特権を認める。](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#grant-least-priv)」と「[IAM でのセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)」を参照してください。
## エピック
### サービス接続を作成する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| Azure DevOps の組織 GUID を検索する。 | Azure DevOps アカウントにサインインし、次の URL (`https://dev.azure.com/{DevOps_Org_ID}/_apis/projectCollections?api-version=6.0`) を使用して組織の GUID を検索します。この URL で、`{DevOps_org_ID}` は Azure DevOps の組織 ID に置き換えてください。 | AWS DevOps |
| AWS アカウントで IdP を設定する。 | Azure サービス接続 AWS アカウント 用に で ID プロバイダー (IdP) を設定するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-workloads-from-azure-devops-pipelines-to-private-amazon-eks-clusters.html)詳細については、[OpenID Connect を使用して Azure DevOps AWS から にフェデレーションする方法](https://aws.amazon.com/blogs/modernizing-with-aws/how-to-federate-into-aws-from-azure-devops-using-openid-connect/)」を参照してください。 | AWS DevOps |
| AWS アカウントで IAM ポリシーを作成する。 | Azure DevOps パイプラインで使用される IAM ロールに必要なアクセス権限を付与する IAM ポリシーを作成するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-workloads-from-azure-devops-pipelines-to-private-amazon-eks-clusters.html) | AWS DevOps |
| AWS アカウントで IAM ロールを作成する。 | Azure サービス接続 AWS アカウント 用に で IAM ロールを設定するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-workloads-from-azure-devops-pipelines-to-private-amazon-eks-clusters.html){
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::{account_id}:oidc-provider/vstoken.dev.azure.com/{OrganizationGUID}"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"vstoken.dev.azure.com/{OrganizationGUID}:aud": "api://AzureADTokenExchange",
"vstoken.dev.azure.com/{OrganizationGUID}:sub": "sc://{OrganizationName}/{ProjectName}/{ServiceConnectionName}"
}
}
}
]
}ポリシーで、次のプレースホルダーの情報を指定します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-workloads-from-azure-devops-pipelines-to-private-amazon-eks-clusters.html) | AWS DevOps |
| Azure DevOps アカウントでサービス接続を作成する。 | Azure サービス接続を設定するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-workloads-from-azure-devops-pipelines-to-private-amazon-eks-clusters.html)詳細は、Microsoft ドキュメントの「[Create a service connection](https://learn.microsoft.com/en-us/azure/devops/pipelines/library/service-endpoints?view=azure-devops#create-a-service-connection)」を参照してください。 | AWS DevOps |
| Amazon EKS 設定ファイルに IAM ロールを追加する。 | IAM ロールには、Amazon EKS クラスターで必要なオペレーションを実行するためのアクセス権限が必要です。パイプラインロールであるため、IAM ロールでクラスター上のほぼすべてのタイプのリソースを管理できる必要があります。そのため、このロールには `system:masters` グループアクセス権限が適しています。必要な設定を Kubernetes 内の `aws-auth ConfigMap` に追加するには、次のコードを使用します。- groups:
- system:masters
rolearn: arn:aws:iam::{account_id}:role/ADO-role
username: ADO-role
を AWS アカウント ID `{account_id}`に置き換えます。詳細は、Amazon EKS ドキュメントの「[Amazon EKS で IAM を使用する方法](https://docs.aws.amazon.com/eks/latest/userguide/security-iam-service-with-iam.html#security-iam-service-with-iam-roles)」を参照してください。 | AWS DevOps |
### エージェントプールを作成する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| セルフホスト型エージェントプールを作成する。 | Azure DevOps アカウントでセルフホスト型エージェントプールを設定するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-workloads-from-azure-devops-pipelines-to-private-amazon-eks-clusters.html)詳細については、Microsoft ドキュメントの「[Create and manage agent pools](https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/pools-queues?view=azure-devops&tabs=yaml%2Cbrowser)」を参照してください。 | |
### Azure DevOps エージェントイメージを構築し、Amazon ECR にプッシュする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| Amazon ECR リポジトリを作成します。 | Azure DevOps エージェントとサンプルアプリケーション (`webapp`) をプライベート Amazon EKS クラスターにデプロイするために使用される Docker イメージは、Amazon ECR リポジトリに保存する必要があります。Amazon ECR リポジトリを作成するには、次の手順に従います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-workloads-from-azure-devops-pipelines-to-private-amazon-eks-clusters.html)詳細は、Amazon ECR ドキュメントの「[Creating an Amazon ECR private repository to store images](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-create.html)」を参照してください。 | AWS DevOps |
| Dockerfile を作成して Azure DevOps エージェントを構築する。 | Dockerfile を作成して、Azure DevOps エージェントがインストールされている Docker イメージを構築します。次の内容を `Dockerfile` という名前のファイルに保存します。
FROM ubuntu:22.04
ENV TARGETARCH="linux-x64"
RUN apt update && apt upgrade -y && apt install -y curl git jq libicu70 unzip wget
RUN curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
RUN unzip awscliv2.zip
RUN ./aws/install
RUN rm -rf aws awscliv2.zip
RUN curl -sSL https://get.docker.com/ | sh
RUN curl -sL https://aka.ms/InstallAzureCLIDeb | bash
RUN mkdir -p azp
WORKDIR /azp/
COPY ./start.sh ./
RUN chmod +x ./start.sh
RUN useradd -m -d /home/agent agent
RUN chown -R agent:agent /azp /home/agent
RUN groupadd -f docker
RUN usermod -aG docker agent
USER agent
ENTRYPOINT [ "./start.sh" ]
| AWS DevOps |
| Azure DevOps エージェント用のスクリプトを作成する。 | `start.sh` スクリプトを作成するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-workloads-from-azure-devops-pipelines-to-private-amazon-eks-clusters.html) | AWS DevOps |
| Azure DevOps エージェントを使用して Docker イメージを構築する。 | Azure DevOps エージェントをインストールするための Docker イメージを作成するには、前に作成した Dockerfile を使用してイメージを構築します。Dockerfile を保存したのと同じディレクトリで、以下のコマンドを実行します。aws ecr get-login-password --region region | docker login --username AWS --password-stdin aws_account_id.dkr.ecr.region.amazonaws.com
docker build --platform linux/amd64 -t ado-agent:latest .
docker tag ado-agent:latest aws_account_id.dkr.ecr.region.amazonaws.com/webapp:latest
docker push aws_account_id.dkr.ecr.region.amazonaws.com/webapp:latest
`aws_account_id` と を AWS アカウント ID と `region` に置き換えます AWS リージョン。 | AWS DevOps |
### Azure DevOps エージェントをプライベート Amazon EKS クラスターにデプロイする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| Azure 個人アクセストークンを生成する。 | プライベート Amazon EKS クラスターで動作するエージェントには、Azure DevOps アカウントで認証できるように個人アクセストークン (PAT) が必要です。PAT を生成するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-workloads-from-azure-devops-pipelines-to-private-amazon-eks-clusters.html)[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-workloads-from-azure-devops-pipelines-to-private-amazon-eks-clusters.html)apiVersion: v1
kind: Secret
metadata:
name: azdevops-pat
namespace: default
type: Opaque
stringData:
AZP_TOKEN:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-workloads-from-azure-devops-pipelines-to-private-amazon-eks-clusters.html)kubectl create -f ado-secret.yaml
詳細は、Microsoft ドキュメントの「[Register an agent using a personal access token (PAT)](https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/personal-access-token-agent-registration?view=azure-devops)」を参照してください。 | AWS DevOps |
| エージェントのデプロイに Kubernetes マニフェストファイルを使用する。 | Azure DevOps エージェントをプライベート Amazon EKS クラスターにデプロイするには、次のマニフェストファイルをコピーし、`agent-deployment.yaml` として保存します。apiVersion: apps/v1
kind: Deployment
metadata:
name: azure-pipelines-agent-eks
labels:
app: azure-pipelines-agent
spec:
replicas: 1
selector:
matchLabels:
app: azure-pipelines-agent
template:
metadata:
labels:
app: azure-pipelines-agent
spec:
containers:
- name: docker
image: docker:dind
securityContext:
privileged: true
volumeMounts:
- name: shared-workspace
mountPath: /workspace
- name: dind-storage
mountPath: /var/lib/docker
env:
- name: DOCKER_TLS_CERTDIR
value: ""
- name: azure-pipelines-agent
image: aws_account_id.dkr.ecr.region.amazonaws.com/webapp:latest
env:
- name: AZP_URL
value: ""
- name: AZP_POOL
value: "eks-agent"
- name: AZP_TOKEN
valueFrom:
secretKeyRef:
name: azdevops-pat
key: AZP_TOKEN
- name: AZP_AGENT_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: DOCKER_HOST
value: tcp://localhost:2375
volumeMounts:
- mountPath: /workspace
name: shared-workspace
volumes:
- name: dind-storage
emptyDir: {}
- name: shared-workspace
emptyDir: {}
`aws_account_id` と を AWS アカウント ID と Azure DevOps アカウント URL ``に置き換えます。 | AWS DevOps |
| エージェントをプライベート Amazon EKS クラスターにデプロイする。 | Azure DevOps エージェントをプライベート Amazon EKS クラスターにデプロイするには、次のコマンドを実行します。kubectl create -f agent-deployment.tf
| AWS DevOps |
| エージェントが実行されていることを確認する | Azure DevOps エージェントが実行されていることを確認するには、次のコマンドを使用します。kubectl get deploy azure-pipelines-agent-eks
次のような内容が出力されます。
NAME READY UP-TO-DATE AVAILABLE AGE
azure-pipelines-agent-eks 1/1 1 1 58s
`READY ` 列に `1/1` が表示されていることを確認します。 | AWS DevOps |
| エージェントが Azure DevOps エージェントプールに登録されていることを確認する。 | エージェントがプライベート Amazon EKS クラスターにデプロイされ、エージェントプール `eks-agent` に登録されていることを確認するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-workloads-from-azure-devops-pipelines-to-private-amazon-eks-clusters.html)**[Status]** が **[Online]** のエージェントが 1 つ表示されます。エージェントの名前は、**azure-pipelines-agent-eks-\$1** で始まっているはずです。 | AWS DevOps |
### サンプルアプリケーションをデプロイする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| サンプルアプリケーションリポジトリを GitHub アカウントにフォークする。 | 次の AWS サンプルリポジトリを GitHub アカウントにフォークします。[https://github.com/aws-samples/deploy-kubernetes-resources-to-amazon-eks-using-azure-devops](https://github.com/aws-samples/deploy-kubernetes-resources-to-amazon-eks-using-azure-devops) | AWS DevOps |
| パイプラインを作成する | Azure DevOps アカウントでパイプラインを作成するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-workloads-from-azure-devops-pipelines-to-private-amazon-eks-clusters.html)pool:
name: eks-agent
#pool: self-hosted # If you are running self-hosted Azure DevOps Agents
stages:
# Refering the pipeline template, input parameter that are not specified will be added with defaults
- template: ./pipeline_templates/main_template.yaml
parameters:
serviceConnectionName: aws-sc
awsRegion:
awsEKSClusterName:
projectName: webapp
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-workloads-from-azure-devops-pipelines-to-private-amazon-eks-clusters.html) | AWS DevOps |
| サンプルアプリケーションがデプロイされていることを確認する。 | パイプラインが完了したら、Amazon ECR リポジトリと Amazon EKS クラスターの両方をチェックして、サンプルアプリケーションのデプロイが成功したことを確認します。Amazon ECR リポジトリのアーティファクトを検証するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-workloads-from-azure-devops-pipelines-to-private-amazon-eks-clusters.html)[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-workloads-from-azure-devops-pipelines-to-private-amazon-eks-clusters.html)例えば、`20250501.1-image` と `20250501.1-helm` です。名前空間 `webapp` のプライベート Amazon EKS クラスターでのデプロイを確認するには、次のコマンドを実行します。kubectl get deploy -n webapp
予想される出力は次のようになります。
NAME READY UP-TO-DATE AVAILABLE
webapp 1/1 1 1
注: これが最初のパイプライン実行である場合は、サービス接続とエージェントプールの承認が必要となる場合があります。Azure DevOps パイプラインインターフェイスでアクセス許可リクエストを探し、承認して続行します。 | AWS DevOps |
## トラブルシューティング
| 問題 | ソリューション |
| --- | --- |
| Amazon ECR リポジトリ名が `webapp` と一致しないとパイプラインが失敗する | サンプルアプリケーションでは、Amazon ECR リポジトリ名が `azure_pipeline.yml` の `projectName: webapp` パラメータと一致することが想定されています。この問題を解決するには、Amazon ECR リポジトリの名前を `webapp` に変更するか、以下を更新します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-workloads-from-azure-devops-pipelines-to-private-amazon-eks-clusters.html) |
| エラー: Kubernetes クラスターに到達できません: サーバーがクライアントに認証情報の提供を要求しました | Azure パイプラインの「Helm チャートのプルとデプロイ」ステップでこのエラーが発生した場合、通常、Amazon EKS クラスターの `aws-auth ConfigMap` での誤った IAM ロール設定が根本原因です。この問題を解決するには、以下を確認してください。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/deploy-workloads-from-azure-devops-pipelines-to-private-amazon-eks-clusters.html) |
## 関連リソース
**AWS ブログ**
+ [OpenID Connect を使用して Azure DevOps AWS から にフェデレーションする方法](https://aws.amazon.com/blogs/modernizing-with-aws/how-to-federate-into-aws-from-azure-devops-using-openid-connect/)
**AWS のサービス ドキュメント**
+ [Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html)
+ [Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html)
**Microsoft ドキュメント**
+ [What is Azure DevOps?](https://learn.microsoft.com/en-us/azure/devops/user-guide/what-is-azure-devops?view=azure-devops)
+ [What is Azure Pipelines?](https://learn.microsoft.com/en-us/azure/devops/pipelines/get-started/what-is-azure-pipelines?view=azure-devops)
# Terraform を使用して Amazon Redshift SQL クエリを実行する
*Amazon Web Services、Sylvia Qi、Aditya Ambati*
## 概要
Amazon Redshift のデプロイと管理に Infrastructure as Code (IaC) を使用することは、DevOps 内での一般的なプラクティスです。IaC を使用すると、クラスター、スナップショット、パラメータグループなど、さまざまな Amazon Redshift リソースのデプロイと設定が簡単に行えます。ただし、IaC はテーブル、スキーマ、ビュー、ストアドプロシージャなどのデータベースリソースの管理までは対応していません。これらのデータベース要素は SQL クエリによって管理されるもので、IaC ツールでは直接サポートされていません。これらのリソースを管理するためのソリューションとツールがありますが、テクノロジースタックへの追加ツールの導入を回避したい場合があります。
このパターンでは、Terraform を使用してテーブル、スキーマ、ビュー、ストアドプロシージャなどの Amazon Redshift データベースリソースをデプロイする方法の概要を示します。パターンでは、2 種類の SQL クエリを区別します。
+ **再現不可能なクエリ** – これらのクエリは、最初の Amazon Redshift デプロイ中に 1 回実行され、重要なデータベースコンポーネントを確立します。
+ **反復可能なクエリ** – これらのクエリはイミュータブルであり、データベースに影響を与えることなく再実行できます。このソリューションは、Terraform を使用して反復可能なクエリの変更をモニタリングし、それに応じて適用します。
詳細については、「[追加情報](#execute-redshift-sql-queries-using-terraform-additional)」の*「ソリューションの詳細*」を参照してください。
## 前提条件と制限
**前提条件**
をアクティブに AWS アカウント し、デプロイマシンに以下をインストールする必要があります。
+ [AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) (AWS CLI)
+ Amazon Redshift の読み取り/書き込みアクセス権限が設定された [AWS CLI プロファイル](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html)
+ [Terraform](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli) バージョン 1.6.2 以降
+ [Python3](https://www.python.org/downloads/)
+ [Boto3](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/quickstart.html)
**制限事項**
+ Terraform でのクラスター作成中はデータベースを 1 つしか作成できないため、このソリューションでは単一の Amazon Redshift データベースをサポートします。
+ このパターンには、反復可能なクエリへの変更を適用する前に検証するテストは含まれません。信頼性を高めるために、このようなテストを組み込むことをお勧めします。
+ このソリューションを説明するために、このパターンではローカル Terraform ステートファイルを使用するサンプル `redshift.tf` ファイルを用意しています。ただし、本番環境では、安定性とコラボレーションを強化するために、ロック機構を備えたリモートステートファイルを使用することを強くお勧めします。
+ 一部の AWS のサービス は では使用できません AWS リージョン。利用可能なリージョンについては、「[AWS のサービス (リージョン別)](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)」を参照してください。特定のエンドポイントについては、「[Service endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)」で、サービスのリンクを選択してご確認ください。
**製品バージョン**
このソリューションは、[Amazon Redshift パッチ 179](https://docs.aws.amazon.com/redshift/latest/mgmt/cluster-versions.html#cluster-version-179) で開発およびテストされています。
**コードリポジトリ**
このパターンのコードは、GitHub の「[amazon-redshift-sql-deploy-terraform](https://github.com/aws-samples/amazon-redshift-sql-deploy-terraform)」リポジトリで入手できます。
## アーキテクチャ
次の図に、Terraform が反復不可能な SQL クエリと反復不可能な SQL クエリの両方を処理することで Amazon Redshift データベースリソースを管理する方法を示します。
![\[Terraform が SQL クエリを使用して Amazon Redshift データベースリソースを管理するプロセス。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/0f4467ac-761b-4b6b-a32f-e18a2ca2245d/images/3b6ff9e8-e3d1-48ed-9fa1-4b14f7d3d65b.png)
図表に示す内容は以下のステップです。
1. Amazon Redshift クラスターの初回デプロイ時に、Terraform が反復不可能な SQL クエリを適用します。
1. 開発者が、反復可能な SQL クエリの変更をコミットします。
1. Terraform が、反復可能な SQL クエリの変更をモニタリングします。
1. Terraform が、反復可能な SQL クエリを Amazon Redshift データベースに適用します。
このパターンで提供するソリューションは、[Amazon Redshift 用の Terraform モジュール](https://registry.terraform.io/modules/terraform-aws-modules/redshift/aws/latest)に基づいて構築されています。Terraform モジュールは Amazon Redshift クラスターとデータベースをプロビジョニングします。モジュールを強化するために、ここでは `terraform_data` リソースを使用しています。ここで、カスタム Python スクリプトを呼び出し、Amazon Redshift [ExecuteStatement](https://docs.aws.amazon.com/redshift-data/latest/APIReference/API_ExecuteStatement.html) API オペレーションを使用して SQL クエリを実行します。結果として、モジュールは以下を実行できます。
+ データベースのプロビジョニング後に SQL クエリを使用して、任意の数のデータベースリソースをデプロイする。
+ 反復可能な SQL クエリの変更を継続的にモニタリングし、Terraform を使用してそれらの変更を適用する。
詳細については、「[追加情報](#execute-redshift-sql-queries-using-terraform-additional)」の*「ソリューションの詳細*」を参照してください。
## ツール
**AWS のサービス**
+ [Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/welcome.html) は、フルマネージド型で、ペタバイトスケールのデータウェアハウスを提供する、 AWS クラウドのサービスです。
**その他のツール**
+ [Terraform](https://www.terraform.io/) は HashiCorp の infrastructure as code (IaC) ツールで、クラウドとオンプレミスのリソースの作成と管理を支援します。
+ [Python](https://www.python.org/) は、SQL クエリを実行するためにこのパターンで使用する汎用プログラミング言語です。
## ベストプラクティス
+ [Amazon Redshift のベストプラクティス](https://docs.aws.amazon.com/redshift/latest/dg/best-practices.html)
+ [Using the Amazon Redshift Data API to interact with Amazon Redshift clusters](https://aws.amazon.com/blogs/big-data/using-the-amazon-redshift-data-api-to-interact-with-amazon-redshift-clusters/)
## エピック
### Terraform を使用してソリューションをデプロイする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| **リポジトリのクローンを作成します。** | Amazon Redshift クラスターをプロビジョニングするための Terraform コードを含む Git リポジトリのクローンを作成するには、次のコマンドを実行します。git clone https://github.com/aws-samples/amazon-redshift-sql-deploy-terraform.git
| DevOps エンジニア |
| **Terraform 変数を更新します。** | 特定の要件に従って Amazon Redshift クラスターのデプロイをカスタマイズするには、`terraform.tfvars` ファイル内の次のパラメータを更新します。region = ""
cluster_identifier = ""
node_type = ""
number_of_nodes = ""
database_name = ""
subnet_ids = ""
vpc_security_group_ids = ""
run_nonrepeatable_queries = true
run_repeatable_queries = true
sql_path_bootstrap = ""
sql_path_nonrepeatable = ""
sql_path_repeatable = ""
sql_path_finalize = ""
create_random_password = false
master_username = ""
| DevOps エンジニア |
| Terraform を使用してリソースをデプロイします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/execute-redshift-sql-queries-using-terraform.html) | DevOps エンジニア |
| (オプション) 追加の SQL クエリを実行します。 | サンプルリポジトリには、デモ用の SQL クエリがいくつか用意されています。独自の SQL クエリを実行するには、それらを次のフォルダに追加します。`/bootstrap` `/nonrepeatable` `/repeatable` `/finalize` | |
### SQL ステートメントの実行をモニタリングする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| SQL ステートメントのデプロイをモニタリングします。 | Amazon Redshift クラスターに対する SQL 実行の結果をモニタリングできます。失敗した SQL 実行と成功した SQL 実行を示す出力の例については、「[追加情報](#execute-redshift-sql-queries-using-terraform-additional)」の「*SQL ステートメントの例*」を参照してください。 | DBA、DevOps エンジニア |
| リソースをクリーンアップします。 | Terraform によってデプロイされたリソースをすべて削除するには、次のコマンドを実行します。terraform destroy
| DevOps エンジニア |
### 結果を検証する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| Amazon Redshift クラスターのデータを検証します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/execute-redshift-sql-queries-using-terraform.html) | DBA、AWS DevOps |
## 関連リソース
**AWS ドキュメント**
+ [Amazon Redshift でプロビジョニングされたクラスター](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html)
+ [Amazon Redshift Data API の問題のトラブルシューティング](https://docs.aws.amazon.com/redshift/latest/mgmt/data-api-troubleshooting.html)
**その他のリソース**
+ [コマンド: apply](https://developer.hashicorp.com/terraform/cli/commands/apply) (Terraform ドキュメント)
## 追加情報
**ソリューションの詳細**
このソリューションを使用するには、Amazon Redshift SQL クエリを特定の方法で配置する必要があります。すべての SQL クエリは、`.sql` 拡張子が付いたファイルに保存する必要があります。
このパターンで提供するコード例では、SQL クエリは次のフォルダ構造内に配置されます。独自のユースケースに適した任意の構造に対応するように、コード (`sql-queries.tf` と `sql-queries.py`) を変更することができます。
```
/bootstrap
|- Any # of files
|- Any # of sub-folders
/nonrepeatable
|- Any # of files
|- Any # of sub-folders
/repeatable
/udf
|- Any # of files
|- Any # of sub-folders
/table
|- Any # of files
|- Any # of sub-folders
/view
|- Any # of files
|- Any # of sub-folders
/stored-procedure
|- Any # of files
|- Any # of sub-folders
/finalize
|- Any # of files
|- Any # of sub-folders
```
このようなフォルダ構造のため、Amazon Redshift クラスターのデプロイ中、Terraform でのクエリ実行は次の順序で行われます。
1. `/bootstrap`
1. `/nonrepeatable`
1. `/repeatable`
1. `/finalize`
`/repeatable` フォルダには、`/udf`、`/table`、`/view`、`/stored-procedure` の 4 つのサブフォルダがあります。これらのサブフォルダは、Terraform が SQL クエリを実行する順序を示しています。
SQL クエリを実行する Python スクリプトは `sql-queries.py` です。スクリプトは、まず `sql_path_bootstrap` パラメータなど、特定のソースディレクトリのすべてのファイルとサブフォルダを読み取ります。その次に、Amazon Redshift [ExecuteStatement](https://docs.aws.amazon.com/redshift-data/latest/APIReference/API_ExecuteStatement.html) API オペレーションを呼び出してクエリを実行します。ファイル内に 1 つ以上の SQL クエリがある場合があります。次のコードスニペットは、ファイルに保存されている SQL ステートメントを Amazon Redshift クラスターに対して実行する Python 関数を示しています。
```
def execute_sql_statement(filename, cluster_id, db_name, secret_arn, aws_region):
"""Execute SQL statements in a file"""
redshift_client = boto3.client(
'redshift-data', region_name=aws_region)
contents = get_contents_from_file(filename),
response = redshift_client.execute_statement(
Sql=contents[0],
ClusterIdentifier=cluster_id,
Database=db_name,
WithEvent=True,
StatementName=filename,
SecretArn=secret_arn
)
...
```
Terraform スクリプト `sql-queries.tf` は、`sql-queries.py` スクリプトを呼び出す [terraform\$1data](https://developer.hashicorp.com/terraform/language/resources/terraform-data) リソースを作成します。`/bootstrap`、`/nonrepeatable`,`/repeatable`,`/finalize` の 4 つのフォルダのそれぞれに 1 つの `terraform_data` リソースがあります。次のコードスニペットは、`/bootstrap` フォルダ内の SQL クエリを実行する `terraform_data` リソースを示しています。
```
locals {
program = "${path.module}/sql-queries.py"
redshift_cluster_name = try(aws_redshift_cluster.this[0].id, null)
}
resource "terraform_data" "run_bootstrap_queries" {
count = var.create && var.run_nonrepeatable_queries && (var.sql_path_bootstrap != "") && (var.snapshot_identifier == null) ? 1 : 0
depends_on = [aws_redshift_cluster.this[0]]
provisioner "local-exec" {
command = "python3 ${local.program} ${var.sql_path_bootstrap} ${local.redshift_cluster_name} ${var.database_name} ${var.redshift_secret_arn} ${local.aws_region}"
}
}
```
これらのクエリを実行するかどうかを制御するには、次の変数を使用できます。`sql_path_bootstrap`、`sql_path_nonrepeatable`、`sql_path_repeatable`、`sql_path_finalize` でクエリを実行しない場合は、それらの値を `""` に設定します。
```
run_nonrepeatable_queries = true
run_repeatable_queries = true
sql_path_bootstrap = "src/redshift/bootstrap"
sql_path_nonrepeatable = "src/redshift/nonrepeatable"
sql_path_repeatable = "src/redshift/repeatable"
sql_path_finalize = "src/redshift/finalize"
```
`terraform apply` を実行すると、Terraform はスクリプトの結果に関係なく、スクリプトが完了した後に追加された `terraform_data` リソースを考慮します。一部の SQL クエリが失敗し、再実行する場合は、Terraform 状態からリソースを手動で削除して、`terraform apply` を再度実行できます。例えば、次のコマンドを実行すると、Terraform 状態から `run_bootstrap_queries` リソースが削除されます。
`terraform state rm module.redshift.terraform_data.run_bootstrap_queries[0]`
次のコード例は、`run_repeatable_queries` リソースが [sha256 ハッシュ](https://developer.hashicorp.com/terraform/language/functions/sha256)を使用して `repeatable` フォルダでの変更をモニタリングする方法を示しています。フォルダ内のファイルが更新されると、Terraform はディレクトリ全体に更新のマークを付けます。そして、次の `terraform apply` 中にディレクトリ内でクエリを再度実行します。
```
resource "terraform_data" "run_repeatable_queries" {
count = var.create_redshift && var.run_repeatable_queries && (var.sql_path_repeatable != "") ? 1 : 0
depends_on = [terraform_data.run_nonrepeatable_queries]
# Continuously monitor and apply changes in the repeatable folder
triggers_replace = {
dir_sha256 = sha256(join("", [for f in fileset("${var.sql_path_repeatable}", "**") : filesha256("${var.sql_path_repeatable}/${f}")]))
}
provisioner "local-exec" {
command = "python3 ${local.sql_queries} ${var.sql_path_repeatable} ${local.redshift_cluster_name} ${var.database_name} ${var.redshift_secret_arn}"
}
}
```
コードを効率化するために、すべてのファイルに無差別に変更を適用するのではなく、`repeatable` フォルダ内で更新されたファイルのみの変更を検出して適用するメカニズムを実装できます。
**SQL ステートメントの例**
次の出力は、失敗した SQL 実行とエラーメッセージを示しています。
```
module.redshift.terraform_data.run_nonrepeatable_queries[0] (local-exec): Executing: ["/bin/sh" "-c" "python3 modules/redshift/sql-queries.py src/redshift/nonrepeatable testcluster-1 db1 arn:aws:secretsmanager:us-east-1:XXXXXXXXXXXX:secret:/redshift/master_user/password-8RapGH us-east-1"]
module.redshift.terraform_data.run_nonrepeatable_queries[0] (local-exec): -------------------------------------------------------------------
module.redshift.terraform_data.run_nonrepeatable_queries[0] (local-exec): src/redshift/nonrepeatable/table/admin/admin.application_family.sql
module.redshift.terraform_data.run_nonrepeatable_queries[0] (local-exec): -------------------------------------------------------------------
module.redshift.terraform_data.run_nonrepeatable_queries[0] (local-exec): Status: FAILED
module.redshift.terraform_data.run_nonrepeatable_queries[0] (local-exec): SQL execution failed.
module.redshift.terraform_data.run_nonrepeatable_queries[0] (local-exec): Error message: ERROR: syntax error at or near ")"
module.redshift.terraform_data.run_nonrepeatable_queries[0] (local-exec): Position: 244
module.redshift.terraform_data.run_nonrepeatable_queries[0]: Creation complete after 3s [id=ee50ba6c-11ae-5b64-7e2f-86fd8caa8b76]
```
次の出力は、成功した SQL 実行を示しています。
```
module.redshift.terraform_data.run_bootstrap_queries[0]: Provisioning with 'local-exec'...
module.redshift.terraform_data.run_bootstrap_queries[0] (local-exec): Executing: ["/bin/sh" "-c" "python3 modules/redshift/sql-queries.py src/redshift/bootstrap testcluster-1 db1 arn:aws:secretsmanager:us-east-1:XXXXXXXXXXXX:secret:/redshift/master_user/password-8RapGH us-east-1"]
module.redshift.terraform_data.run_bootstrap_queries[0] (local-exec): -------------------------------------------------------------------
module.redshift.terraform_data.run_bootstrap_queries[0] (local-exec): src/redshift/bootstrap/db.sql
module.redshift.terraform_data.run_bootstrap_queries[0] (local-exec): -------------------------------------------------------------------
module.redshift.terraform_data.run_bootstrap_queries[0] (local-exec): Status: FINISHED
module.redshift.terraform_data.run_bootstrap_queries[0] (local-exec): SQL execution successful.
module.redshift.terraform_data.run_bootstrap_queries[0]: Creation complete after 2s [id=d565ef6d-be86-8afd-8e90-111e5ea4a1be]
```
# AWS Organizations 内の組織全体の AWS Backup レポートを CSV ファイルとしてエクスポートする
*Amazon Web Services、Aromal Raj Jayarajan、Purushotham G K*
## 概要
このパターンは、AWS Organizations 内のある組織全体の AWS Backup ジョブレポートを CSV ファイルとしてエクスポートする方法を示しています。このソリューションでは、AWS Lambda と Amazon EventBridge を使用して AWS Backup ジョブレポートをステータスに基づいて分類します。これは、ステータスベースの自動化を構成するときに役立ちます。
AWS Backup は、AWS のサービス、クラウド内、およびオンプレミス間の一元化およびデータ保護の自動化を支援します。ただし、AWS Organizations 内で構成された AWS Backup ジョブの場合、統合レポートは各組織の管理アカウントの AWS マネジメントコンソールでのみ使用できます。このレポートを管理アカウントの外部に置くことで、監査に必要な労力を減らし、自動化、通知、アラートの範囲を広げることができます。
## 前提条件と制限事項
**前提条件**
+ アクティブな AWS アカウント
+ 少なくとも管理アカウントとメンバーアカウントを含む、AWS Organizations 内のアクティブな[組織](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_tutorials_basic.html)
+ AWS Organizations の組織レベルで構成された AWS Backup (詳細については、AWS ブログの「[ Backup を使用して AWS のサービス全体にわたる大規模集中バックアップを自動化する](https://aws.amazon.com/blogs/storage/automate-centralized-backup-at-scale-across-aws-services-using-aws-backup/)」を参照してください)
+ ローカルマシンにインストールされて構成されている [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)
**機能制限**
このパターンで提供されるソリューションは、AWS Backup ジョブ専用に構成された AWS リソースを識別します。このレポートでは、AWS Backup によるバックアップ用に構成されていない AWS Backup リソースは特定できません。
## アーキテクチャ
**ターゲットテクノロジースタック**
+ AWS Backup
+ AWS CloudFormation
+ Amazon EventBridge
+ AWS Lambda
+ AWS Security Token Service (AWS STS)
+ Amazon Simple Storage Service (Amazon S3)
+ AWS Identity and Access Management (IAM)
**ターゲットアーキテクチャ**
次の図は、AWS Organizations 内のある組織全体から AWS Backup ジョブレポートを CSV ファイルとしてエクスポートするワークフローの例を示しています。
![\[EventBridge、Lambda、AWS STS、IAM を使用して、組織全体の AWS Backup ジョブレポートを CSV 形式でエクスポートします。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/74955aad-cc6d-488b-aa34-ae43f50fec60/images/5c39c79f-e731-4ad0-b404-51ebe0976420.png)
この図表は、次のワークフローを示しています:
1. スケジュールされた EventBridge イベントルールは、メンバー (レポーティング) AWS アカウントの Lambda 関数を呼び出します。
1. 次に、Lambda 関数は AWS STS を使用して、管理アカウントへの接続に必要な権限を持つ IAM ロールを引き受けます。
1. Lambda 関数は以下を実行します。
+ AWS Backup サービスに統合された AWS Backup ジョブレポートをリクエストする
+ AWS Backup ジョブのステータスに基づいて結果を分類する
+ レスポンスを CSV ファイルに変換する
+ 作成日に基づいてラベル付けされたフォルダ内のレポーティングアカウントの Amazon S3 バケットに、結果をアップロードする
## ツール
**ツール**
+ [AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html) は、フルマネージド型のサービスで、 AWS サービス、クラウド、オンプレミスにおけるデータ保護の一元化と自動化に役立ちます。
+ [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) を使用すると、AWS リソースをセットアップし、迅速かつ一貫したプロビジョニングを行い、AWS アカウントとリージョン全体でライフサイクル全体にわたってリソースを管理できます。
+ [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) は、アプリケーションをさまざまなソースのリアルタイムデータに接続できるようにするサーバーレスイベントバスサービスです。たとえば、AWS Lambda 関数、API 宛先を使用する HTTP 呼び出しエンドポイント、または他の AWS アカウントのイベントバスなどです。
+ 「[AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)」は、AWS リソースへのアクセスを安全に管理し、誰が認証され、使用する権限があるかを制御するのに役立ちます。
+ [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。
+ 「[Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) 」は、どのようなデータの量であっても、保存、保護、取得することを支援するクラウドベースのオブジェクトストレージサービスです。
**Code**
このパターンのコードは、GitHub の[aws-backup-report-generator](https://github.com/aws-samples/aws-backup-report-generator) リポジトリにあります。
## ベストプラクティス
+ [Amazon S3 のセキュリティベストプラクティス](https://docs.aws.amazon.com/AmazonS3/latest/userguide/security-best-practices.html) (*Amazon S3 ユーザーガイド*)
+ [AWS Lambda 関数を操作するためのベストプラクティス](https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html) (*AWS Lambda デベロッパーガイド*)
+ [管理アカウントのベストプラクティス](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_best-practices_mgmt-acct.html) (*AWS Organizations ユーザーガイド*)
## エピック
### ソリューションコンポーネントをデプロイする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| GitHub リポジトリのクローン作成 | ターミナルウィンドウで次のコマンドを実行して、GitHub の [aws-backup-report-generator](https://github.com/aws-samples/aws-backup-report-generator) リポジトリをクローン作成します。git clone https://github.com/aws-samples/aws-backup-report-generator.git
詳細については、GitHub Docsの「[リポジトリのクローン作成](https://docs.github.com/en/repositories/creating-and-managing-repositories/cloning-a-repository)」を参照してください。 | AWS DevOps、DevOps エンジニア |
| メンバー (レポーティング) AWS アカウントにソリューションコンポーネントをデプロイします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/export-aws-backup-reports-from-across-an-organization-in-aws-organizations-as-a-csv-file.html) | DevOps エンジニア、AWS DevOps |
### ソリューションをテストする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| テスト前に EventBridge ルールが実行されていることを確認する。 | 少なくとも 24 時間待つか、CloudFormation テンプレートの **template-reporting.yml** ファイル内のレポート頻度を増やして、EventBridge ルールが実行されることを確認してください。**レポート頻度を増やすには**[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/export-aws-backup-reports-from-across-an-organization-in-aws-organizations-as-a-csv-file.html) | AWS DevOps、DevOps エンジニア |
| 生成されたレポートを Amazon S3 バケットで確認します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/export-aws-backup-reports-from-across-an-organization-in-aws-organizations-as-a-csv-file.html) | AWS DevOps、DevOps エンジニア |
### リソースのクリーンアップ
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| メンバー (レポーティング) アカウントからソリューションコンポーネントを削除します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/export-aws-backup-reports-from-across-an-organization-in-aws-organizations-as-a-csv-file.html) | AWS DevOps、DevOps エンジニア |
| 管理アカウントからソリューションコンポーネントを削除します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/export-aws-backup-reports-from-across-an-organization-in-aws-organizations-as-a-csv-file.html) | AWS DevOps、DevOps エンジニア |
## 関連リソース
+ [チュートリアル: スケジュールされたイベントで Lambda を使用する](https://docs.aws.amazon.com/lambda/latest/dg/services-cloudwatchevents-tutorial.html) (AWS Lambda ドキュメント)
+ [Creating scheduled events to execute AWS Lambda functions](https://docs.aws.amazon.com/sdk-for-javascript/v3/developer-guide/scheduled-events-invoking-lambda-example.html) (AWS SDK for JavaScript ドキュメント)
+ [IAM チュートリアル: AWS アカウント間の IAM ロールを使用したアクセスの委任](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html) (IAM ドキュメント)
+ [AWS Organizations 用語と概念](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html) (AWS Organizations ドキュメント)
+ [Creating report plans using the AWS Backup console](https://docs.aws.amazon.com/aws-backup/latest/devguide/create-report-plan-console.html) (AWS Backup ドキュメント)
+ [Create an audit report](https://docs.aws.amazon.com/aws-backup/latest/devguide/create-audit-report.html) (AWS Backup ドキュメント)
+ [Creating on-demand reports](https://docs.aws.amazon.com/aws-backup/latest/devguide/create-on-demand-reports.html) (AWS Backup ドキュメント)
+ [AWS Backup とは?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html) (AWS Backup ドキュメント)
+ [Automate centralized backup at scale across AWS services using AWS Backup](https://aws.amazon.com/blogs/storage/automate-centralized-backup-at-scale-across-aws-services-using-aws-backup/) (AWS ブログ記事)
# Amazon EC2 インスタンスのリストのタグを CSV ファイルにエクスポートする
*Amazon Web Services、Sida Ju、PAC Joonhyun*
## 概要
このパターンは、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスのリストのタグをプログラムで CSV ファイルにエクスポートする方法を示しています。
以下の Python スクリプトの例を使用すると、Amazon EC2 インスタンスを確認して特定のタグで分類するのにかかる時間を短縮できます。たとえば、このスクリプトを使用して、セキュリティチームがソフトウェアアップデートのフラグを付けたインスタンスのリストをすばやく特定して分類できます。
## 前提条件と制限
**前提条件**
+ Python 3 がインストールされ、構成されている
+ AWS コマンドラインインターフェイス (AWS CLI) がインストールされ、構成されている
**制限事項**
このパターンで指定される Python スクリプトの例では、以下の属性のみに基づいて Amazon EC2 インスタンスを検索できます。
+ インスタンス ID
+ プライベート IPv4 アドレス
+ パブリック IPv4 アドレス
## ツール
+ 「[Python](https://www.python.org/)」は汎用のコンピュータープログラミング言語です。
+ [virtualenv](https://virtualenv.pypa.io/en/latest/) は、隔離された Python 環境を作成するのに役立ちます。
+ 「[AWS コマンドラインインターフェイス (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html)」は、オープンソースのツールであり、コマンドラインシェルのコマンドを使用して AWS サービスとやり取りすることができます。
**コードリポジトリ**
このパターンの Python スクリプトの例は、GitHub の [search-ec2-instances-export-tags](https://github.com/aws-samples/search-ec2-instances-export-tags) リポジトリにあります。
## エピック
### 前提条件をインストールして設定する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| GitHub リポジトリのクローン作成 | AWS CLI コマンドの実行中にエラーが発生した場合は、[最新の CLI バージョンを使用していることを確認してください](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-troubleshooting.html)。ターミナルウィンドウで次の Git コマンドを実行して、GitHub の [search-ec2-instances-export-tags](https://github.com/aws-samples/search-ec2-instances-export-tags) リポジトリのクローンを作成します。git clone https://github.com/aws-samples/search-ec2-instances-export-tags.git
| DevOps エンジニア |
| virtualenv をインストールして有効にします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/export-tags-for-a-list-of-amazon-ec2-instances-to-a-csv-file.html)詳細については、「[virtualenv ユーザーガイド](https://virtualenv.pypa.io/en/latest/user_guide.html)」を参照してください。 | DevOps エンジニア |
| 依存関係をインストールします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/export-tags-for-a-list-of-amazon-ec2-instances-to-a-csv-file.html) | DevOps エンジニア |
| AWS の名が付いたプロファイルを構成します。 | まだ構成していない場合は、スクリプトを実行するために必要な認証情報を含む AWS の名前付きプロファイルを構成します。名前付きプロファイルを作成するには、[ configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html#cli-configure-files-methods) コマンドを実行します。詳細については、AWS CLI ドキュメントの「[名前付きプロファイルを使用する](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html#cli-configure-files-using-profiles)」を参照してください。 | DevOps エンジニア |
### Python スクリプトを構成して実行する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| 入力ファイルを作成します。 | スクリプトでタグを検索してエクスポートしたい Amazon EC2 インスタンスのリストを含む入力ファイルを作成します。インスタンス ID、プライベート IPv4 アドレス、またはパブリック IPv4 アドレスを一覧表示できます。各 Amazon EC2 インスタンスが入力ファイルの個別の行にリストされていることを確認してください。**入力データの例**1 i-0547c351bdfe85b9f
2 54.157.194.156
3 172.31.85.33
4 54.165.198.144
5 i-0b6223b5914111a4b
6 172.31.85.44
7 54.165.198.145
8 172.31.80.219
9 172.31.94.199
| DevOps エンジニア |
| Python スクリプトを実行する。 | ターミナルで次のコマンドを実行して、スクリプトを実行します。python search_instances.py -i INPUTFILE -o OUTPUTFILE -r REGION [-p PROFILE]
`INPUTFILE` を入力ファイルの名前に置き換えます。`OUTPUTFILE` を、CSV 出力ファイルの名前に置き換えます。`REGION` を Amazon EC2 リソースが存在する AWS リージョンに置き換えます。AWS の名前付きプロファイルを使用している場合は、`PROFILE` を使用している名前付きプロファイルに置き換えます。サポートされているパラメータとその説明のリストを取得するには、次のコマンドを実行します。python search_instances.py -h
詳細および出力ファイルの例については、GitHub の [search-ec2-instances-export-tags](https://github.com/aws-samples/search-ec2-instances-export-tags) リポジトリにある `README.md` ファイルを参照してください。 | DevOps エンジニア |
## 関連リソース
+ [AWS CLI の構成](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html) (*AWS CLI ユーザーガイド*)
# Troposphere を使用して AWS Config マネージドルールを含む AWS CloudFormation テンプレートを生成します
*Lucas Nation と Freddie Wilson、Amazon Web Services*
## 概要
多くの組織は、「[AWS Config マネージド](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config_use-managed-rules.html)」ルールを使用して、Amazon Web Services (AWS) リソースのコンプライアンスを一般的なベストプラクティスに照らして評価しています。ただし、これらのルールは保守に時間がかかる場合があり、このパターンは Python ライブラリである「[Troposphere](https://troposphere.readthedocs.io/en/latest/quick_start.html)」を活用して AWS Config マネージドルールを生成および管理するのに役立ちます。
このパターンは、Python スクリプトを使用して AWS マネージドルールを含む Microsoft Excel スプレッドシートを AWS CloudFormation テンプレートに変換することで、AWS Config マネージドルールを管理するのに役立ちます。Troposphere は infrastructure as code (IaC) として機能します。つまり、JSON や YAML 形式のファイルを使用する代わりに、マネージドルールで Excel スプレッドシートを更新できるということです。次に、このテンプレートを使用して AWS CloudFormation スタックを起動し、AWS アカウントのマネージドルールを作成および更新します。
AWS CloudFormation テンプレートは Excel スプレッドシートを使用して各 AWS Config マネージドルールを定義し、AWS マネジメントコンソールで個々のルールを手動で作成する手間を省くのに役立ちます。このスクリプトでは、各マネージドルールのパラメータは空の辞書にデフォルト設定され、`ComplianceResourceTypes` スコープのデフォルトは `THE_RULE_IDENTIFIER.template file` からになります*。*ルール識別子の詳細については、AWS Config ドキュメントの「[AWS CloudFormation テンプレートを使用した AWS Config マネージドルールの作成](https://docs.aws.amazon.com/config/latest/developerguide/aws-config-managed-rules-cloudformation-templates.html)」を参照してください。
## 前提条件と制限事項
**前提条件**
+ アクティブな AWS アカウント。
+ AWS CloudFormation テンプレートを使用して AWS Config マネージドルールを作成することに精通していること。これに関する詳細については、AWS Config ドキュメントの「[AWS CloudFormation テンプレートを使用した AWS Config マネージドルールの作成](https://docs.aws.amazon.com/config/latest/developerguide/aws-config-managed-rules-cloudformation-templates.html)」を参照してください。
+ Python 3 がインストールされ、設定されています。詳細については、「[Python ドキュメント](https://www.python.org/)」を参照してください。
+ 既存の統合開発環境 (IDE)。
+ サンプル `excel_config_rules.xlsx` Excel スプレッドシート (添付) の列で組織単位 (OU) を特定します。
## エピック
### AWS Config マネージドルールのカスタマイズと設定
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| サンプル Excel スプレッドシートを更新してください。 | サンプル `excel_config_rules.xlsx` Excel スプレッドシート (添付) をダウンロードし、使用したい AWS Config マネージドルールを `Implemented` としてラベルを付けます。 `Implemented` とマークされたルールは AWS CloudFormation テンプレートに追加されます。 | 開発者 |
| (オプション) config\$1rules\$1params.json ファイルを AWS Config ルールパラメータで更新します。 | 一部の AWS Config マネージドルールはパラメータを必要とするため、`--param-file` オプションを使用して JSON ファイルとして Python スクリプトに渡す必要があります。たとえば、`access-keys-rotated` マネージドルールは次の `maxAccessKeyAge` パラメータを使用します。{
"access-keys-rotated": {
"InputParameters": {
"maxAccessKeyAge": 90
}
}
}このサンプルパラメータでは、`maxAccessKeyAge` は 90 日に設定されています。スクリプトはパラメータファイルを読み取り、見つかった `InputParameters` をすべて追加します。 | 開発者 |
| (オプション) config\$1rules\$1params.json ファイルを AWS Config コンプライアンスリソースタイプで更新します。 | デフォルトでは、Python スクリプトは AWS 定義のテンプレートから `ComplianceResourceTypes` を取得します。特定の AWS Config マネージドルールの範囲をオーバーライドする場合は、`--param-file` オプションを使用して JSON ファイルとして Python スクリプトに渡す必要があります。たとえば、次のサンプルコードは、`ec2-volume-inuse-check` の `ComplianceResourceTypes` を `["AWS::EC2::Volume"]` リストに設定する方法を示しています。{
"ec2-volume-inuse-check": {
"Scope": {
"ComplianceResourceTypes": [
"AWS::EC2::Volume"
]
}
}
} | 開発者 |
### Python スクリプトを実行する。
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| requirements.txt ファイルから pip パッケージをインストールします。 | `requirements.txt` ファイル (添付) をダウンロードし、IDE で次のコマンドを実行して Python パッケージをインストールします。`pip3 install -r requirements.txt` | 開発者 |
| Python スクリプトを実行します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/generate-an-aws-cloudformation-template-containing-aws-config-managed-rules-using-troposphere.html)また、次のオプションパラメータを含めることができます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/generate-an-aws-cloudformation-template-containing-aws-config-managed-rules-using-troposphere.html) | 開発者 |
### AWS Config マネージドルールをデプロイする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| AWS CloudFormation スタックを起動します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/generate-an-aws-cloudformation-template-containing-aws-config-managed-rules-using-troposphere.html) | 開発者 |
## アタッチメント
このドキュメントに関連する追加コンテンツにアクセスするには、次のファイルを解凍してください。「[attachment.zip](samples/p-attach/07c1cfff-fc9e-4a1f-bd36-48f025808bd8/attachments/attachment.zip)」
# SageMaker ノートブックインスタンスに、別の AWS アカウントの CodeCommit リポジトリへの一時的なアクセスを許可する
*Helge Aufderheide、Amazon Web Services*
## 概要
このパターンは、Amazon SageMaker ノートブックインスタンスとユーザーに、別の AWS アカウントにある AWS CodeCommit リポジトリへの一時的なアクセスを許可する方法を示しています。このパターンはまた、各エンティティが各リポジトリで実行できる特定のアクションに対してきめ細かいアクセス権限を付与する方法も示しています。
組織は多くの場合、開発環境をホストするアカウントとは別の AWS アカウントに CodeCommit リポジトリを保存します。このマルチアカウント設定は、リポジトリへのアクセスを制御し、リポジトリを誤って削除するリスクを軽減するのに役立ちます。クロスアカウントアクセス権の付与には、AWS Identity and Access Management (IAM) ロールを使用するのがベストプラクティスです。これにより、各 AWS アカウントの事前定義済みの IAM アイデンティティが一時的にロールを引き受け、アカウント間で制御された信頼の連鎖を構築できます。
**注記**
同様の手順を適用して、他の IAM アイデンティティに CodeCommit リポジトリへのクロスアカウントアクセスを許可できます。詳細については、「*AWS CodeCommit ユーザーガイド*」の「[ロールを使用して AWS CodeCommit リポジトリへのクロスアカウントアクセスを構成する](https://docs.aws.amazon.com/codecommit/latest/userguide/cross-account.html)」を参照してください。
## 前提条件と制限
**前提条件**
+ CodeCommit リポジトリを持つアクティブな AWS アカウント (*アカウント A*)
+ SageMaker ノートブックインスタンスを持つ 2 つ目のアクティブな AWS アカウント (*アカウント B*)
+ アカウント A の IAM ロールを作成および変更するための十分な権限を持つ AWS ユーザー
+ アカウント B の IAM ロールを作成および変更するための十分な権限を持つ 2 人目の AWS ユーザー
## アーキテクチャ
以下の図は、SageMaker ノートブックインスタンスと 1 つの AWS アカウントのユーザーに CodeCommit リポジトリへのクロスアカウントアクセスを許可するワークフローの例を示しています。
![\[CodeCommit へのクロスアカウントアクセスを許可するワークフロー\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/54d0fdb3-6d25-4433-9f67-c87846633d61/images/97a799af-ce88-4495-a61c-d0cd22493ce2.png)
この図表は、次のワークフローを示しています:
1. アカウント B の AWS ユーザーロールと SageMaker ノートブックインスタンスロールは、[名前付きプロファイル](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html#cli-configure-files-using-profiles)を前提としています。
1. 名前付きプロファイルのアクセス権限ポリシーは、プロファイルが引き受けるアカウント A の CodeCommit アクセスロールを指定します。
1. アカウント A の CodeCommit アクセスロールの信頼ポリシーにより、アカウント B の名前付きプロファイルが CodeCommit アクセスロールを引き受けます。
1. アカウント A の CodeCommit リポジトリの IAM アクセス権限ポリシーにより、CodeCommit アクセスロールは CodeCommit リポジトリにアクセスできます。
**テクノロジースタック**
+ CodeCommit
+ Git
+ IAM
+ pip
+ SageMaker
## ツール
+ [AWS CodeCommit](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html) は、独自のソースコントロールシステムを管理しなくても、Git リポジトリを非公開で保存および管理できるバージョン管理サービスです。
+ 「[AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)」は、AWS リソースへのアクセスを安全に管理し、誰が認証され、使用する権限があるかを制御するのに役立ちます。
+ [Git](https://git-scm.com/) は、ソフトウェア開発中のソースコードの変更を追跡するための分散型バージョン管理システムです。
+ [git-remote-codecommit](https://docs.aws.amazon.com/codecommit/latest/userguide/setting-up-git-remote-codecommit.html) は、Git を拡張することにより、CodeCommit リポジトリからコードをプッシュおよびプルするための簡単な方法を提供するユーティリティです。
+ [pip](https://pypi.org/project/pip/) は Python のパッケージインストーラです。pip を使用して Python Package インデックスやその他のインデックスからパッケージをインストールできます。
## ベストプラクティス
IAM ポリシーでアクセス許可を設定するときは、タスクの実行に必要なアクセス許可のみを付与するようにします。詳細については、IAM ドキュメントの「[最小特権アクセス許可を適用する](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)」を参照してください。
このパターンを実装する場合は、必ず以下を実行してください。
+ IAM プリンシパルには、各リポジトリ内で必要な特定のアクションを実行するための権限のみが含まれていることを確認してください。たとえば、承認された IAM プリンシパルは変更を特定のリポジトリブランチにプッシュしてマージすることを許可しますが、保護されたブランチへのマージのみを要求することが推奨されます。
+ IAM プリンシパルには、各プロジェクトのそれぞれのロールと責任に基づいて異なる IAM ロールが割り当てられていることを確認してください。たとえば、開発者はリリースマネージャーや AWS 管理者とは異なるアクセス権限を持ちます。
## エピック
### IAM ロールを構成する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| CodeCommit のアクセスロールと権限ポリシーを構成します。 | このエピックで説明されている手動設定プロセスを自動化するには、****[AWS CloudFormation テンプレート](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-guide.html)を使用します。CodeCommit リポジトリを含むアカウント (*アカウント A*) で、次の操作を行います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/give-sagemaker-notebook-instances-temporary-access-to-a-codecommit-repository-in-another-aws-account.html)ベストプラクティスは、この設定を本稼働環境に移行する前に、[最小特権アクセス許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)を適用する独自の IAM ポリシーを作成することです。詳細については、このパターンの「**追加情報**」セクションを参照してください。 | AWS 全般、AWS DevOps |
| アカウント B の SageMaker ノートブックインスタンスのロールに、アカウント A の CodeCommit アクセスロールを引き受ける権限を付与します。 | SageMaker ノートブックインスタンスの IAM ロールを含むアカウント (*アカウント B*) で、次の操作を行います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/give-sagemaker-notebook-instances-temporary-access-to-a-codecommit-repository-in-another-aws-account.html)注: リポジトリの Amazon リソースネーム (ARN) を表示するには、「*AWS CodeCommit ユーザーガイド*」の「[CodeCommit リポジトリの詳細を表示する](https://docs.aws.amazon.com/codecommit/latest/userguide/how-to-view-repository-details.html)」を参照してください。 | AWS 全般、AWS DevOps |
### アカウント B に SageMaker ノートブックインスタンスを設定する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| AWS SageMaker ノートブックインスタンスにユーザープロファイルを設定して、アカウント A のロールを引き受けます。 | [最新バージョンの AWS コマンドラインインターフェイス (AWS CLI) がインストールされていることを確認してください](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)。SageMaker ノートブックインスタンスを含むアカウント (*アカウント B*) で、次の操作を行います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/give-sagemaker-notebook-instances-temporary-access-to-a-codecommit-repository-in-another-aws-account.html)------.aws/config--------------
[profile remoterepouser]
role_arn = arn:aws:iam:::role/
role_session_name = remoteaccesssession
region = eu-west-1
credential_source = Ec2InstanceMetadata
----------------------------------
| AWS 全般、AWS DevOps |
| git-remote-codecommit ユーティリティをインストールします。 | 「*AWS CodeCommit ユーザーガイド*」の「[ステップ 2: git-remote-codecommit をインストールする](https://docs.aws.amazon.com/codecommit/latest/userguide/setting-up-git-remote-codecommit.html#setting-up-git-remote-codecommit-install)」の指示に従ってください。 | データサイエンティスト |
### リポジトリにアクセスする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| Git コマンドまたは SageMaker を使用して CodeCommit リポジトリにアクセスする。 | **Git を使用するには**これで、アカウント B で SageMaker ノートブックインスタンスのロールを引き受ける IAM プリンシパルは、Git コマンドを実行してアカウント A の CodeCommit リポジトリにアクセスできるようになりました。たとえば、ユーザーは、`git clone`、`git pull`、`git push` などのコマンドを実行できます。手順については、「*AWS CodeCommit ユーザーガイド*」の「[AWS CodeCommit リポジトリに接続する](https://docs.aws.amazon.com/codecommit/latest/userguide/how-to-connect.html)」 を参照してください。CodeCommit で Git を使用する方法については、「*AWS CodeCommit ユーザーガイド*」の「[AWS CodeCommit 入門](https://docs.aws.amazon.com/codecommit/latest/userguide/getting-started-cc.html)」を参照してください。**SageMaker を使用するには**SageMaker コンソールから Git を使用するには、Git が CodeCommit リポジトリから認証情報を取得できるよう許可する必要があります。手順については、「SageMaker ドキュメント」の「[別の アカウントの CodeCommit リポジトリをノートブックインスタンスに関連付ける](https://docs.aws.amazon.com/sagemaker/latest/dg/nbi-git-cross.html)」を参照してください。 | Git、バッシュコンソール |
## 関連リソース
+ [ロールを使用して AWS CodeCommit リポジトリへのクロスアカウントアクセスを設定する](https://docs.aws.amazon.com/codecommit/latest/userguide/cross-account.html) (AWS CodeCommit ドキュメント)
+ [IAM チュートリアル: AWS アカウント間の IAM ロールを使用したアクセスの委任](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html) (IAM ドキュメント)
## 追加情報
**CodeCommit 権限を特定のアクションに制限する**
IAM プリンシパルが CodeCommit リポジトリで実行できるアクションを制限するには、CodeCommit アクセスポリシーで許可されているアクションを変更します。
CodeCommit API の操作の詳細については、「*AWS CodeCommit ユーザーガイド*」の「[CodeCommit アクセス権限リファレンス](https://docs.aws.amazon.com/codecommit/latest/userguide/auth-and-access-control-permissions-reference.html)」を参照してください。
**注記**
[AWSCodeCommitPowerUser](https://docs.aws.amazon.com/codecommit/latest/userguide/security-iam-awsmanpol.html#managed-policies-poweruser) AWS マネージドポリシーをユースケースに合わせて編集することもできます。
**CodeCommit 権限を特定のリポジトリに制限する**
特定のユーザーだけが複数のコードリポジトリにアクセスできるマルチテナント環境を作成するには、次の操作を行います。
1. アカウント A に複数の CodeCommit アクセスロールを作成します。次に、アカウント B の特定のユーザーがロールを引き受けることができるように、各アクセスロールの信頼ポリシーを構成します。
1. 各 CodeCommit アクセスロールのポリシーに「**リソース**」条件を追加して、各ロールが引き受けることができるコードリポジトリを制限します。
**特定の CodeCommit リポジトリに対する IAM プリンシパルのアクセスを制限する「リソース」条件の例**
```
"Resource" : [, ]
```
**注記**
同じ AWS アカウント内の複数のコードリポジトリを識別して区別しやすくするために、リポジトリ名に異なるプレフィックスを割り当てることができます。たとえば、**myproject-subproject1-repo1** や **myproject-subproject2-repo1** など、異なる開発者グループに対応するプレフィックスを付けた名前をコードリポジトリに付けます。その後、割り当てられたプレフィックスに基づいて、開発者グループごとに IAM ロールを作成できます。たとえば、**myproject-subproject1-repoaccess** という名前のロールを作成し、**myproject-subproject1** というプレフィックスを含むすべてのコードリポジトリへのアクセスをそのロールに付与することができます。
**特定のプレフィックスを含むコードリポジトリ ARN を参照する「リソース」条件の例**
```
"Resource" : arn:aws:codecommit:::myproject-subproject1-*
```
# マルチアカウント DevOps 環境に GitHub フローブランチ戦略を実装する
*Amazon Web Services、Mike Stephens と Abhilash Vinod*
## 概要
ソースコードリポジトリを管理する場合、さまざまな分岐戦略が、開発チームが使用するソフトウェア開発およびリリースプロセスに影響します。一般的な分岐戦略の例としては、Trunk、GitHub Flow、Gitflow などがあります。これらの戦略では異なるブランチが使用され、各環境で実行されるアクティビティは異なります。DevOps プロセスを実装している組織は、ビジュアルガイドを活用して、これらの分岐戦略の違いを理解できます。組織でこのビジュアルを使用すると、開発チームが作業を調整し、組織の標準に従うのに役立ちます。このパターンでは、このビジュアルを提供し、組織に GitHub フローブランチ戦略を実装するプロセスについて説明します。
このパターンは、複数の を持つ組織の DevOps ブランチ戦略の選択と実装に関するドキュメントシリーズの一部です AWS アカウント。このシリーズは、クラウドでのエクスペリエンスを効率化するために、最初から正しい戦略とベストプラクティスを適用するのに役立つように設計されています。GitHub フローは、組織で使用できるブランチ戦略の 1 つです。このドキュメントシリーズでは、[トランク](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/implement-a-trunk-branching-strategy-for-multi-account-devops-environments.html)および [Gitflow](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/implement-a-gitflow-branching-strategy-for-multi-account-devops-environments.html) ブランチモデルについても説明します。まだ確認していない場合は、このパターンのガイダンスを実装する前に、「[Choosing a Git branching strategy for multi-account DevOps environments](https://docs.aws.amazon.com/prescriptive-guidance/latest/choosing-git-branch-approach/)」を確認することをお勧めします。デューデリジェンスを使用して、組織に適したブランチ戦略を選択してください。
このガイドでは、組織が GitHub フロー戦略を実装する方法を記した図を示します。「[AWS Well-Architected DevOps Guidance](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/devops-guidance.html)」でベストプラクティスを確認することをお勧めします。このパターンには、DevOps プロセスの各段階に推奨されるタスク、ステップ、制限が含まれます。
## 前提条件と制限事項
**前提条件**
+ 「[インストール済み](https://git-scm.com/downloads)」Git これはソースコードリポジトリツールとして使用されます。
+ Draw.io が[インストールされていること](https://github.com/jgraph/drawio-desktop/releases)。このアプリケーションは、図の表示や編集のために使用されます。
## アーキテクチャ
**ターゲットアーキテクチャ**
次の図は、[パネットスクエア](https://en.wikipedia.org/wiki/Punnett_square) (Wikipedia) のように使用できます。垂直軸のブランチを水平軸の AWS 環境と並べて、各シナリオで実行するアクションを決定します。数字は、ワークフロー内のアクションのシーケンスを示します。この例では、`feature` ブランチから本番環境へのデプロイまでを示します。
![\[各ブランチと環境での GitHub フローアクティビティのパネットスクエア。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/780a5bce-3cd2-4092-8537-b7a77c3d6b8d/images/8a2a774a-cd85-466e-838e-a9a1f3b58a63.png)
GitHub Flow アプローチの AWS アカウント、環境、ブランチの詳細については、[「マルチアカウント DevOps 環境の Git ブランチ戦略の選択](https://docs.aws.amazon.com/prescriptive-guidance/latest/choosing-git-branch-approach)」を参照してください。
**自動化とスケール**
継続的インテグレーションと継続的デリバリー (CI/CD) は、ソフトウェアリリースライフサイクルを自動化するプロセスです。CI/CD は、初期コミットから本番環境に新しいコードを移行するために従来必要とされていた手動プロセスの多く、またはすべてを自動化します。CI/CD パイプラインには、サンドボックス、開発、テスト、ステージング、および本番環境が含まれます。各環境で、CI/CD パイプラインはコードをデプロイまたはテストするために必要なインフラストラクチャをプロビジョニングします。CI/CD を使用することで、開発チームはコードを変更し、自動的にテストとデプロイを行うことができます。CI/CD パイプラインは、機能の受け入れとデプロイに一貫性、標準、ベストプラクティス、最小限の承認レベルを適用することで、開発チームのガバナンスとガードレールも提供します。詳細については、「[AWSでの継続的インテグレーションと継続的デリバリーの実践](https://docs.aws.amazon.com/whitepapers/latest/practicing-continuous-integration-continuous-delivery/welcome.html)」を参照してください。
AWS は、CI/CD パイプラインの構築を支援するように設計された一連の開発者サービスを提供します。例えば、[AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) は完全マネージド型の継続的デリバリーサービスであり、リリースパイプラインを自動化して、迅速かつ信頼性の高いアプリケーションとインフラストラクチャの更新を実現します。[AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) はソースコードをコンパイルし、テストを実行し、すぐにデプロイできるソフトウェアパッケージを生成します。詳細については、[「Developer Tools on AWS](https://aws.amazon.com/products/developer-tools/)」を参照してください。
## ツール
**AWS サービスとツール**
AWS には、このパターンの実装に使用できる一連の開発者サービスが用意されています。
+ スケーラビリティが高く、フルマネージド型のアーティファクトリポジトリサービスである [AWS CodeArtifact](https://docs.aws.amazon.com/codeartifact/latest/ug/welcome.html) を使用すると、アプリケーション開発に使用するソフトウェアパッケージを保存および共有できます。
+ [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) は完全マネージド型の構築サービスです。ソースコードのコンパイル、ユニットテストの実行、すぐにデプロイできるアーティファクトの生成を行います。
+ [AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) は、Amazon Elastic Compute Cloud (Amazon EC2) またはオンプレミスインスタンス、 AWS Lambda 関数、または Amazon Elastic Container Service (Amazon ECS) サービスへのデプロイを自動化します。
+ [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) は、ソフトウェアリリースのさまざまな段階を迅速にモデル化および設定し、ソフトウェアの変更を継続的にリリースするために必要なステップを自動化するのに役立ちます。
**その他のツール**
+ [Draw.io Desktop](https://github.com/jgraph/drawio-desktop/releases) は、フローチャートと図を作成するためのアプリケーションです。コードリポジトリには、Draw.io 用の .drawio 形式のテンプレートが格納されています。
+ [Figma](https://www.figma.com/design-overview/) は、コラボレーション用に設計されたオンライン設計ツールです。コードリポジトリには、Figma 用の .fig 形式のテンプレートが格納されています。
**コードリポジトリ**
このパターンにおける図のソースファイルは、[Git Branching Strategy for GitHub Flow](https://github.com/awslabs/git-branching-strategies-for-multiaccount-devops/tree/main/github-flow) GitHub リポジトリで入手できます。ここには、PNG、draw.io、および Figma 形式のファイルが含まれます。これらの図は、組織のプロセスに対応するように変更できます。
## ベストプラクティス
「[AWS Well-Architected DevOps Guidance](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/devops-guidance.html)」と「[Choosing a Git branching strategy for multi-account DevOps environments](https://docs.aws.amazon.com/prescriptive-guidance/latest/choosing-git-branch-approach/)」のベストプラクティスと推奨事項に従ってください。これらは、GitHub フローベースの開発を効果的に実装し、コラボレーションを促進し、コード品質を高め、開発プロセスを合理化するのに役立ちます。
## エピック
### GitHub フローワークフローの確認
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| 標準の GitHub フロープロセスを確認する。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/implement-a-github-flow-branching-strategy-for-multi-account-devops-environments.html) | DevOps エンジニア |
| バグ修正 GitHub フロープロセスを確認する。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/implement-a-github-flow-branching-strategy-for-multi-account-devops-environments.html) | DevOps エンジニア |
| ホットフィックス GitHub フロープロセスを確認する。 | GitHub フローは、継続的な配信が可能になり、コードの変更が上位環境に頻繁かつ確実にデプロイされるように設計されています。重要なのは、すべての `feature` ブランチがいつでもデプロイ可能であることです。`Hotfix` ブランチは、`feature` ブランチや `bugfix` ブランチに似ていますが、これらの他のブランチと同じプロセスに従うことができます。ただし、緊急性を考慮すると、通常はホットフィックスの優先度が高くなります。チームのポリシーと状況の緊急性によっては、プロセスの特定のステップが迅速化される可能性があります。例えば、ホットフィックスのコードレビューは高速で追跡される場合があります。そのため、ホットフィックスプロセスでは機能プロセスとバグ修正プロセスが並列で扱われますが、ホットフィックスの緊急性により、手続きの遵守に変更が必要となる場合があります。ホットフィックスが効率的かつ安全に処理されるように、ホットフィックスの管理に関するガイドラインを確立することが重要です。 | DevOps エンジニア |
## トラブルシューティング
| 問題 | ソリューション |
| --- | --- |
| ブランチの競合 | GitHub フローモデルで発生する可能性がある一般的な問題は、ホットフィックスを本番環境に適用する必要がある場合に、同じリソースが変更されている `feature`、`bugfix`、または `hotfix` ブランチでもそれに対応する変更を適用する必要があるという状況です。`main` へのマージ時に大きな競合が発生するのを避けるため、`main` の変更を下位ブランチに頻繁にマージすることをお勧めします。 |
| チームの成熟度 | GitHub フローは、真の継続的インテグレーションと継続的デリバリー (CI/CD) により、上位環境への日々のデプロイを促進します。機能を構築し、機能の自動化テストを作成するには、チームのエンジニアリングスキルが成熟している必要があります。チームは、変更が承認される前に、マージリクエストの詳細なレビューを実行する必要があります。これにより、開発プロセスの品質、説明責任、効率性を促進する堅牢なエンジニアリング文化が育まれます。 |
## 関連リソース
このガイドには Git のトレーニングは含まれていませんが、このトレーニングが必要な場合は、インターネット上で多くの高品質のリソースを入手できます。[Git ドキュメント](https://git-scm.com/doc)のサイトから始めることをお勧めします。
以下のリソースは、 AWS クラウドで GitHub フローブランチを利用する際に役立ちます。
**AWS DevOps ガイダンス**
+ [AWS DevOps ガイダンス](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/devops-guidance.html)
+ [AWS デプロイパイプラインリファレンスアーキテクチャ](https://pipelines.devops.aws.dev/)
+ [DevOps とは?](https://aws.amazon.com/devops/what-is-devops/)
+ [DevOps リソース](https://aws.amazon.com/devops/resources/)
**GitHub フローガイダンス**
+ [GitHub フローのクイックスタートチュートリアル](https://docs.github.com/en/get-started/using-github/github-flow) (GitHub)
+ [Why GitHub Flow?](https://githubflow.github.io/)
**その他のリソース**
+ [Twelve-factor app methodology](https://12factor.net/) (12factor.net)
# マルチアカウント DevOps 環境に Gitflow ブランチ戦略を実装する
*Amazon Web Services、Mike Stephens、Stephen DiCato、Abhilash Vinod、Tim Wondergem*
## 概要
ソースコードリポジトリを管理する場合、さまざまなブランチ戦略が、開発チームが使用するソフトウェア開発およびリリースプロセスに影響します。一般的なブランチ戦略の例としては、トランク、Gitflow、GitHub フローなどがあります。これらの戦略では異なるブランチが使用され、各環境で実行されるアクティビティは異なります。DevOps プロセスを実装している組織は、ビジュアルガイドを活用して、これらの分岐戦略の違いを理解できます。組織でこのビジュアルを使用すると、開発チームが作業を調整し、組織の標準に従うのに役立ちます。このパターンでは、このビジュアルを提供し、組織に Gitflow ブランチ戦略を実装するプロセスについて説明します。
このパターンは、複数の を持つ組織の DevOps ブランチ戦略の選択と実装に関するドキュメントシリーズの一部です AWS アカウント。このシリーズは、クラウドでのエクスペリエンスを効率化するために、最初から正しい戦略とベストプラクティスを適用するのに役立つように設計されています。Gitflow は、組織で使用できるブランチ戦略の 1 つです。このドキュメントシリーズでは、[トランク](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/implement-a-trunk-branching-strategy-for-multi-account-devops-environments.html)および [GitHub フロー](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/implement-a-github-flow-branching-strategy-for-multi-account-devops-environments.html)ブランチモデルについても説明します。まだ確認していない場合は、このパターンのガイダンスを実装する前に、「[Choosing a Git branching strategy for multi-account DevOps environments](https://docs.aws.amazon.com/prescriptive-guidance/latest/choosing-git-branch-approach/)」を確認することをお勧めします。デューデリジェンスを使用して、組織に適したブランチ戦略を選択してください。
このガイドでは、組織が Gitflow 戦略を実装する方法を記した図を示します。「[AWS Well-Architected DevOps Guidance](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/devops-guidance.html)」でベストプラクティスを確認することをお勧めします。このパターンには、DevOps プロセスの各段階に推奨されるタスク、ステップ、制限が含まれます。
## 前提条件と制限事項
**前提条件**
+ 「[インストール済み](https://git-scm.com/downloads)」Git これはソースコードリポジトリツールとして使用されます。
+ Draw.io が[インストールされていること](https://github.com/jgraph/drawio-desktop/releases)。このアプリケーションは、図の表示や編集のために使用されます。
+ (オプション) Gitflow プラグインが[インストールされていること](https://github.com/nvie/gitflow)。
## アーキテクチャ
**ターゲットアーキテクチャ**
次の図は、[パネットスクエア](https://en.wikipedia.org/wiki/Punnett_square) (Wikipedia) のように使用できます。垂直軸のブランチを水平軸の AWS 環境と並べて、各シナリオで実行するアクションを決定します。数字は、ワークフロー内のアクションのシーケンスを示します。この例では、feature ブランチから本番環境へのデプロイまでを示します。
![\[各ブランチと環境での Gitflow アクティビティのパネットスクエア。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/1dee2a06-cc54-4797-b9a9-78b6685edd33/images/d8be49bf-dca1-4892-ac4c-11996a7258c2.png)
Gitflow アプローチの AWS アカウント、環境、ブランチの詳細については、[「マルチアカウント DevOps 環境の Git ブランチ戦略の選択](https://docs.aws.amazon.com/prescriptive-guidance/latest/choosing-git-branch-approach/)」を参照してください。
**自動化とスケール**
継続的インテグレーションと継続的デリバリー (CI/CD) は、ソフトウェアリリースライフサイクルを自動化するプロセスです。CI/CD は、初期コミットから本番環境に新しいコードを移行するために従来必要とされていた手動プロセスの多く、またはすべてを自動化します。CI/CD パイプラインには、サンドボックス、開発、テスト、ステージング、および本番環境が含まれます。各環境で、CI/CD パイプラインはコードをデプロイまたはテストするために必要なインフラストラクチャをプロビジョニングします。CI/CD を使用することで、開発チームはコードを変更し、自動的にテストとデプロイを行うことができます。CI/CD パイプラインは、機能の受け入れとデプロイに一貫性、標準、ベストプラクティス、最小限の承認レベルを適用することで、開発チームのガバナンスとガードレールも提供します。詳細については、「[AWSでの継続的インテグレーションと継続的デリバリーの実践](https://docs.aws.amazon.com/whitepapers/latest/practicing-continuous-integration-continuous-delivery/welcome.html)」を参照してください。
AWS は、CI/CD パイプラインの構築を支援するように設計されたデベロッパーサービスのスイートを提供します。例えば、[AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) は完全マネージド型の継続的デリバリーサービスであり、リリースパイプラインを自動化して、迅速かつ信頼性の高いアプリケーションとインフラストラクチャの更新を実現します。[AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) はソースコードをコンパイルし、テストを実行し、すぐにデプロイできるソフトウェアパッケージを生成します。詳細については、[「Developer Tools on AWS](https://aws.amazon.com/products/developer-tools/)」を参照してください。
## ツール
**AWS サービスとツール**
AWS は、このパターンの実装に使用できる一連の開発者サービスを提供します。
+ スケーラビリティが高く、フルマネージド型のアーティファクトリポジトリサービスである [AWS CodeArtifact](https://docs.aws.amazon.com/codeartifact/latest/ug/welcome.html) を使用すると、アプリケーション開発に使用するソフトウェアパッケージを保存および共有できます。
+ [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) は完全マネージド型の構築サービスです。ソースコードのコンパイル、ユニットテストの実行、すぐにデプロイできるアーティファクトの生成を行います。
+ [AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) は、Amazon Elastic Compute Cloud (Amazon EC2)、オンプレミスインスタンス、 AWS Lambda 関数、または Amazon Elastic Container Service (Amazon ECS) サービスへのデプロイを自動化します。
+ [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) は、ソフトウェアリリースのさまざまな段階を迅速にモデル化および設定し、ソフトウェアの変更を継続的にリリースするために必要なステップを自動化するのに役立ちます。
**その他のツール**
+ [Draw.io Desktop](https://github.com/jgraph/drawio-desktop/releases) は、フローチャートと図を作成するためのアプリケーションです。コードリポジトリには、Draw.io 用の .drawio 形式のテンプレートが格納されています。
+ [Figma](https://www.figma.com/design-overview/) は、コラボレーション用に設計されたオンライン設計ツールです。コードリポジトリには、Figma 用の .fig 形式のテンプレートが格納されています。
+ (オプション) [Gitflow プラグイン](https://github.com/nvie/gitflow)は、Gitflow ブランチモデルの高レベルのリポジトリオペレーションを提供する Git 拡張機能のコレクションです。
**コードリポジトリ**
このパターンにおける図のソースファイルは、[Git Branching Strategy for GitFlow](https://github.com/awslabs/git-branching-strategies-for-multiaccount-devops/tree/main/gitflow) GitHub リポジトリで入手できます。ここには、PNG、draw.io、および Figma 形式のファイルが含まれます。これらの図は、組織のプロセスに対応するように変更できます。
## ベストプラクティス
「[AWS Well-Architected DevOps Guidance](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/devops-guidance.html)」と「[Choosing a Git branching strategy for multi-account DevOps environments](https://docs.aws.amazon.com/prescriptive-guidance/latest/choosing-git-branch-approach/)」のベストプラクティスと推奨事項に従ってください。これらは、Gitflow ベースの開発を効果的に実装し、コラボレーションを促進し、コード品質を高め、開発プロセスを合理化するのに役立ちます。
## エピック
### Gitflow ワークフローの確認
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| 標準の Gitflow プロセスを確認します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/implement-a-gitflow-branching-strategy-for-multi-account-devops-environments.html) | DevOps エンジニア |
| ホットフィックス Gitflow プロセスを確認します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/implement-a-gitflow-branching-strategy-for-multi-account-devops-environments.html) | DevOps エンジニア |
| バグ修正 Gitflow プロセスを確認します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/implement-a-gitflow-branching-strategy-for-multi-account-devops-environments.html) | DevOps エンジニア |
## トラブルシューティング
| 問題 | ソリューション |
| --- | --- |
| ブランチの競合 | Gitflow モデルで発生する可能性がある一般的な問題は、ホットフィックスを本番環境に適用する必要がある場合に、別のブランチによって同じリソースが変更されている下位環境でもそれに対応する変更を適用する必要があるという状況です。有効にする release ブランチは一度に 1 つだけにすることをお勧めします。複数のブランチが同時に有効になっている場合、環境内での変更が衝突し、ブランチを本番環境に移行できない可能性があります。 |
| マージ | リリースをメインにマージし、できるだけ早く開発して、作業をプライマリブランチに統合する必要があります。 |
| スカッシュマージ | スカッシュマージは、`feature` ブランチから `develop` ブランチにマージする場合にのみ使用します。上位のブランチでスカッシュマージを使用すると、変更を下位のブランチに戻してマージする際に問題が発生します。 |
## 関連リソース
このガイドには Git のトレーニングは含まれていませんが、このトレーニングが必要な場合は、インターネット上で多くの高品質のリソースを入手できます。[Git ドキュメント](https://git-scm.com/doc)のサイトから始めることをお勧めします。
以下のリソースは、 AWS クラウドで Gitflow ブランチを利用する際に役立ちます。
**AWS DevOps ガイダンス**
+ [AWS DevOps ガイダンス](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/devops-guidance.html)
+ [AWS デプロイパイプラインリファレンスアーキテクチャ](https://pipelines.devops.aws.dev/)
+ [DevOps とは?](https://aws.amazon.com/devops/what-is-devops/)
+ [DevOps リソース](https://aws.amazon.com/devops/resources/)
**Gitflow ガイダンス**
+ [元の Gitflow ブログ](https://nvie.com/posts/a-successful-git-branching-model/) (Vincent Driessen 氏のブログ記事)
+ [Gitflow ワークフロー](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow) (Atlassian)
+ [Gitflow on GitHub: How to use Git Flow workflows with GitHub Based Repos](https://youtu.be/WQuxeEvaCxs) (YouTube 動画)
+ [Git Flow Init Example](https://www.youtube.com/watch?v=d4cDLBFbekw) (YouTube 動画)
+ [The Gitflow Release Branch from Start to Finish](https://www.youtube.com/watch?v=rX80eKPdA28) (YouTube 動画)
**その他のリソース**
[Twelve-factor app methodology](https://12factor.net/) (12factor.net)
# マルチアカウント DevOps 環境に Trunk 分岐戦略を実装する
*Mike Stephens と Rayjan Wilson、Amazon Web Services*
## 概要
ソースコードリポジトリを管理する場合、さまざまな分岐戦略が、開発チームが使用するソフトウェア開発およびリリースプロセスに影響します。一般的な分岐戦略の例としては、Trunk、GitHub Flow、Gitflow などがあります。これらの戦略では異なるブランチが使用され、各環境で実行されるアクティビティは異なります。DevOps プロセスを実装している組織は、ビジュアルガイドを活用して、これらの分岐戦略の違いを理解できます。組織でこのビジュアルを使用すると、開発チームが作業を調整し、組織の標準に従うのに役立ちます。このパターンでは、このビジュアルを提供し、組織に Trunk 分岐戦略を実装するプロセスについて説明します。
このパターンは、複数の を持つ組織の DevOps ブランチ戦略の選択と実装に関するドキュメントシリーズの一部です AWS アカウント。このシリーズは、クラウドでのエクスペリエンスを効率化するために、最初から正しい戦略とベストプラクティスを適用するのに役立つように設計されています。Trunk は、組織で使用できる分岐戦略の 1 つです。このドキュメントシリーズでは、[GitHub Flow](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/implement-a-github-flow-branching-strategy-for-multi-account-devops-environments.html) および [Gitflow](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/implement-a-gitflow-branching-strategy-for-multi-account-devops-environments.html) 分岐モデルについても説明します。確認がまだの場合は、このパターンのガイダンスを実装する前に、「[Choosing a Git branching strategy for multi-account DevOps environments](https://docs.aws.amazon.com/prescriptive-guidance/latest/choosing-git-branch-approach/)」を確認することをお勧めします。デューデリジェンスを使用して、組織に適した分岐戦略を選択してください。
このガイドでは、組織が Trunk 戦略を実装する方法を記した図を示します。公式の「[AWS Well-Architected DevOps Guidance](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/devops-guidance.html)」でベストプラクティスを確認することをお勧めします。このパターンには、DevOps プロセスの各ステップのための推奨のタスク、ステップ、制限が含まれます。
## 前提条件と制限事項
**前提条件**
+ 「[インストール済み](https://git-scm.com/downloads)」Git これはソースコードリポジトリツールとして使用されます。
+ Draw.io が[インストールされていること](https://github.com/jgraph/drawio-desktop/releases)。このアプリケーションは、図の表示や編集のために使用されます。
## アーキテクチャ
**ターゲットアーキテクチャ**
次の図は、[パネットスクエア](https://en.wikipedia.org/wiki/Punnett_square) (Wikipedia) のように使用できます。垂直軸のブランチを水平軸の AWS 環境と並べて、各シナリオで実行するアクションを決定します。数字は、ワークフロー内のアクションのシーケンスを示します。この例では、`feature` ブランチから本番環境へのデプロイまでを案内します。
![\[各ブランチと環境での Trunk アクティビティのパネットスクエア。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/5df23e4d-84fe-4ab3-a54f-96b6406abc57/images/ad549ef4-90ad-47c1-bd01-f21d6ce5511a.png)
トランクアプローチの AWS アカウント、環境、ブランチの詳細については、[「マルチアカウント DevOps 環境の Git ブランチ戦略の選択](https://docs.aws.amazon.com/prescriptive-guidance/latest/choosing-git-branch-approach)」を参照してください。
**自動化とスケール**
継続的インテグレーションと継続的デリバリー (CI/CD) は、ソフトウェアリリースライフサイクルを自動化するプロセスです。CI/CD は、初期コミットから本番環境に新しいコードを移行するために従来必要とされていた手動プロセスの多く、またはすべてを自動化します。CI/CD パイプラインには、サンドボックス、開発、テスト、ステージング、および本番環境が含まれます。各環境で、CI/CD パイプラインはコードをデプロイまたはテストするために必要なインフラストラクチャをプロビジョニングします。CI/CD を使用することで、開発チームはコードを変更し、自動的にテストとデプロイを行うことができます。CI/CD パイプラインは、機能の受け入れとデプロイに一貫性、標準、ベストプラクティス、最小限の承認レベルを適用することで、開発チームのガバナンスとガードレールも提供します。詳細については、「[AWSでの継続的インテグレーションと継続的デリバリーの実践](https://docs.aws.amazon.com/whitepapers/latest/practicing-continuous-integration-continuous-delivery/welcome.html)」を参照してください。
AWS は、CI/CD パイプラインの構築を支援するように設計された一連の開発者サービスを提供します。例えば、[AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) は完全マネージド型の継続的デリバリーサービスであり、リリースパイプラインを自動化して、迅速かつ信頼性の高いアプリケーションとインフラストラクチャの更新を実現します。[AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) はソースコードをコンパイルし、テストを実行し、すぐにデプロイできるソフトウェアパッケージを生成します。詳細については、[「Developer Tools on AWS](https://aws.amazon.com/products/developer-tools/)」を参照してください。
## ツール
**AWS サービスとツール**
AWS には、このパターンの実装に使用できる一連の開発者サービスが用意されています。
+ スケーラビリティが高く、フルマネージド型のアーティファクトリポジトリサービスである [AWS CodeArtifact](https://docs.aws.amazon.com/codeartifact/latest/ug/welcome.html) を使用すると、アプリケーション開発に使用するソフトウェアパッケージを保存および共有できます。
+ [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) は完全マネージド型の構築サービスです。ソースコードのコンパイル、ユニットテストの実行、すぐにデプロイできるアーティファクトの生成を行います。
+ [AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) は、Amazon Elastic Compute Cloud (Amazon EC2) またはオンプレミスインスタンス、 AWS Lambda 関数、または Amazon Elastic Container Service (Amazon ECS) サービスへのデプロイを自動化します。
+ [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) は、ソフトウェアリリースのさまざまな段階を迅速にモデル化および設定し、ソフトウェアの変更を継続的にリリースするために必要なステップを自動化するのに役立ちます。
**その他のツール**
+ [Draw.io デスクトップ](https://github.com/jgraph/drawio-desktop/releases) – フローチャートと図を作成するためのアプリケーション。
+ [Figma](https://www.figma.com/design-overview/) は、コラボレーション用に設計されたオンライン設計ツールです。コードリポジトリには、Figma 用の .fig 形式のテンプレートが格納されています。
**コードリポジトリ**
このパターンの図のソースファイルは、GitHub の「[Git Branching Strategy for Trunk](https://github.com/awslabs/git-branching-strategies-for-multiaccount-devops/tree/main/trunk)」リポジトリで入手できます。ここには、PNG、draw.io、および Figma 形式のファイルが含まれます。これらの図は、組織のプロセスに対応するように変更できます。
## ベストプラクティス
「[AWS Well-Architected DevOps Guidance](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/devops-guidance.html)」と「[Choosing a Git branching strategy for multi-account DevOps environments](https://docs.aws.amazon.com/prescriptive-guidance/latest/choosing-git-branch-approach/)」のベストプラクティスと推奨事項に従ってください。これらは、Trunk ベースの開発を効果的に実装し、コラボレーションを促進し、コード品質を向上させ、開発プロセスを合理化するのに役立ちます。
## エピック
### Trunk のワークフローの確認
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| 標準の Trunk プロセスを確認する。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/implement-a-trunk-branching-strategy-for-multi-account-devops-environments.html) | DevOps エンジニア |
## トラブルシューティング
| 問題 | ソリューション |
| --- | --- |
| ブランチの競合 | Trunk モデルで発生する可能性がある一般的な問題は、ホットフィックスを本番環境に適用する必要がある場合に、同じリソースが変更されている `feature` ブランチでもそれに対応する変更を適用する必要があるという状況です。`main` へのマージ時に大きな競合が発生するのを避けるため、`main` の変更を下位ブランチに頻繁にマージすることをお勧めします。 |
## 関連リソース
このガイドには Git のトレーニングは含まれていませんが、このトレーニングが必要な場合は、インターネット上で多くの高品質のリソースを入手できます。[Git ドキュメント](https://git-scm.com/doc)のサイトから始めることをお勧めします。
以下のリソースは、 AWS クラウドで Trunk 分岐を利用する際に役立ちます。
**AWS DevOps ガイダンス**
+ [AWS DevOps ガイダンス](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/devops-guidance.html)
+ [AWS Deployment Pipeline Reference Architecture](https://pipelines.devops.aws.dev/)
+ [DevOps とは?](https://aws.amazon.com/devops/what-is-devops/)
+ [DevOps リソース](https://aws.amazon.com/devops/resources/)
**Trunk ガイダンス**
+ [Trunk Based Development](https://trunkbaseddevelopment.com/)
**その他のリソース**
+ [Twelve-factor app methodology](https://12factor.net/) (12factor.net)
# AWS インフラストラクチャをデプロイする前に、一元化されたカスタム Checkov スキャンを実装してポリシーを適用する
*Benjamin Morris (Amazon Web Services)*
## 概要
このパターンは、1 つのリポジトリ内にカスタム Checkov ポリシーを作成し、このポリシーを GitHub 組織全体で再利用するための GitHub Actions フレームワークを提供します。このパターンに従うことにより、情報セキュリティチームは会社の要件に基づいてカスタムポリシーを記述、追加、維持できます。カスタムポリシーは、GitHub 組織内のすべてのパイプラインに自動的にプルされます。このアプローチを使用して、リソースをデプロイする前に、リソースに関する会社の標準を適用できます。
## 前提条件と制限事項
**前提条件**
+ アクティブな AWS アカウント
+ GitHub Actions を使用する GitHub 組織
+ AWS HashiCorp Terraform または AWS CloudFormation
**制限事項**
+ このパターンは GitHub Actions 用に記述されています。ただし、GitLab など、同様の継続的インテグレーションおよび継続的デリバリー (CI/CD) フレームワークにも適応できます。GitHub の特定の有料バージョンは必要ありません。
+ 一部の AWS のサービス は では使用できません AWS リージョン。リージョンの可用性については、 AWS ドキュメントの[「サービスエンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)」を参照して、サービスのリンクを選択します。
## アーキテクチャ
このパターンは、再利用可能な GitHub ワークフローとカスタム Checkov ポリシーを含む GitHub リポジトリとしてデプロイされるように設計されています。再利用可能なワークフローは、Terraform と CloudFormation のどちらの Infrastructure as Code (IaC) リポジトリでもスキャンできます。
次の図では、**再利用可能な GitHub ワークフローリポジトリ**と**カスタム Checkov ポリシーリポジトリ**を、それぞれ別のアイコンとして示しています。ただし、これらのリポジトリは個別のリポジトリとしても、単一のリポジトリとしても実装できます。サンプルコードでは 1 つのリポジトリを使用し、ワークフロー用のファイル (`.github/workflows`) とカスタムポリシー用のファイル (`custom_policies` フォルダと `.checkov.yml` 設定ファイル) を同一リポジトリ内に含めています。
![\[GitHub Actions は、再利用可能な GitHub ワークフローとカスタム Checkov ポリシーを使用して IaC を評価します。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/6c0c941f-14f9-4569-92da-9f81ab3e525c/images/a1539ce5-0ee6-4af1-bd01-cafad0f71708.png)
この図表は、次のワークフローを示しています。
1. ユーザーが GitHub リポジトリにプルリクエストを作成します。
1. 再利用可能な Checkov ワークフローへの参照を含むパイプラインワークフローが GitHub Actions で開始されます。
1. パイプラインワークフローは、参照された再利用可能な Checkov ワークフローを外部リポジトリからダウンロードし、GitHub Actions を使用してこの Checkov ワークフローを実行します。
1. 再利用可能な Checkov ワークフローは、外部リポジトリからカスタムポリシーをダウンロードします。
1. 再利用可能な Checkov ワークフローは、組み込みの Checkov ポリシーとカスタム Checkov ポリシーの両方に照合して GitHub リポジトリの IaC を評価します。再利用可能な Checkov ワークフローは、セキュリティの問題が見つかったかどうかに基づいて合格または不合格になります。
**自動化とスケール**
このパターンにより Checkov 設定を一元管理できるため、ポリシーの更新を 1 か所に適用するだけで済みます。ただし、このパターンでは、中央の再利用可能なワークフローへの参照を含むワークフローを、全リポジトリが使用する必要があります。この参照を手動で追加することも、スクリプトを使用して各リポジトリの `.github/workflows` フォルダにファイルをプッシュすることもできます。
## ツール
**AWS のサービス**
+ [CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) は、 AWS リソースをセットアップし、迅速かつ一貫してプロビジョニングし、 AWS アカウント および リージョン全体のライフサイクルを通じてリソースを管理するのに役立ちます。Checkov は CloudFormation をスキャンできます。
**その他のツール**
+ [Checkov](https://www.checkov.io/) は、IaC のセキュリティとコンプライアンスの設定ミスをチェックする静的コード分析ツールです。
+ [GitHub Actions](https://github.com/features/actions) は GitHub プラットフォームに統合されており、GitHub リポジトリ内のワークフローの作成、共有、実行に役立ちます。GitHub Actions を使用して、コードの構築、テスト、デプロイなどのタスクを自動化できます。
+ [Terraform](https://www.terraform.io/) は HashiCorp の IaC ツールであり、クラウドおよびオンプレミスのリソースの作成と管理を支援します。Checkov は Terraform をスキャンできます。
**コードリポジトリ**
このパターンのコードは、GitHub の [centralized-custom-checkov-sast](https://github.com/aws-samples/centralized-custom-checkov-sast) リポジトリから入手できます。
## ベストプラクティス
+ 一貫したセキュリティ体制を維持するには、会社のセキュリティポリシーと Checkov ポリシーの整合性を確保します。
+ Checkov カスタムポリシーの実装の初期段階では、セキュリティ問題のある IaC もマージされるように、Checkov スキャンにソフトフェイルオプションを使用することもできます。プロセスが成熟したら、ソフトフェイルオプションからハードフェイルオプションに切り替えます。
## エピック
### カスタムポリシー用の中央 Checkov リポジトリを作成する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| 中央の Checkov リポジトリを作成 | 組織内で使用されるカスタム Checkov ポリシーを保存するためのリポジトリを作成します。クイックスタートとして、このパターンの GitHub [centralized-custom-checkov-sast ](https://github.com/aws-samples/centralized-custom-checkov-sast)リポジトリの内容を、中央の Checkov リポジトリにコピーできます。 | DevOps エンジニア |
| 再利用可能なワークフロー用のリポジトリを作成 | 再利用可能なワークフロー用のリポジトリが既に存在する場合、またはカスタム Checkov ポリシーと同じリポジトリに再利用可能なワークフローファイルを保存する場合は、このステップをスキップできます。再利用可能なワークフローを保持する GitHub リポジトリを作成します。このリポジトリは、他のリポジトリのパイプラインから参照されます。 | DevOps エンジニア |
### 再利用可能なサンプル Checkov ワークフローを作成する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| 再利用可能な Checkov ワークフローを追加する | 再利用可能なワークフローリポジトリ内に、再利用可能な Checkov GitHub Actions ワークフロー (YAML ファイル) を作成します。この再利用可能なワークフローは、このパターンで提供されているワークフローファイルを基に作成できます。変更の例として、ソフトフェイルオプションを使用するように再利用可能なワークフローを変更することが挙げられます。`soft-fail` を `true` に設定すると、Checkov スキャンが失敗した場合でもジョブを正常に完了できます。手順については、Checkov ドキュメントの「[Hard and soft fail](https://www.checkov.io/2.Basics/Hard%20and%20soft%20fail.html)」を参照してください。 | DevOps エンジニア |
| ワークフローの例を追加する | `reusable` ワークフローを参照するサンプル Checkov ワークフローを追加します。これにより、`reusable` ワークフローを再利用するためのテンプレートが提供されます。サンプルリポジトリでは、`checkov-source.yaml` は再利用可能なワークフローであり、`checkov-scan.yaml` は `checkov-source` を利用するサンプルです。サンプル Checkov ワークフローの記述方法の詳細については、「[追加情報](#centralized-custom-checkov-scanning-additional)」を参照してください。 | DevOps エンジニア |
### 企業ポリシーを Checkov カスタムポリシーに関連付ける
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| Checkov によって適用可能なポリシーを決定する | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/centralized-custom-checkov-scanning.html)Checkov カスタムポリシーの作成方法の詳細については、Checkov ドキュメントの「[Custom Policies Overview](https://www.checkov.io/3.Custom%20Policies/Custom%20Policies%20Overview.html)」を参照してください。 | セキュリティおよびコンプライアンス |
| Checkov カスタムポリシーを追加する | 特定した企業ポリシーを、中央リポジトリのカスタム Checkov ポリシーに変換します。Python または YAML を使用して、シンプルな Checkov ポリシーを記述できます。 | セキュリティ |
### 一元化された Checkov カスタムポリシーを実装する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| Checkov の再利用可能なワークフローをすべてのリポジトリに追加する | この時点で、再利用可能なワークフローを参照するサンプル Checkov ワークフローが必要となります。再利用可能なワークフローを参照するサンプル Checkov ワークフローを、これを必要とする各リポジトリにコピーします。 | DevOps エンジニア |
| マージ前に Checkov が実行されるようにメカニズムを作成する | プルリクエストごとに Checkov ワークフローが実行されるようにするには、Checkov ワークフローが成功した場合にのみプルリクエストをマージするための[ステータスチェック](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/about-status-checks)を作成します。GitHub では、プルリクエストをマージする前に特定のワークフローが実行されるように指定できます。 | DevOps エンジニア |
| 組織全体の PAT を作成し、シークレットとして共有する | GitHub 組織が公開されている場合は、このステップをスキップできます。このパターンでは、Checkov ワークフローが、GitHub 組織のカスタムポリシーリポジトリからカスタムポリシーをダウンロードできる必要があります。Checkov ワークフローがこれらのリポジトリにアクセスできるように、必要なアクセス許可を付与する必要があります。これには、組織リポジトリを読み取るアクセス許可を持つ[個人用アクセストークン (PAT) を作成](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens#creating-a-fine-grained-personal-access-token)します。この PAT を、組織全体のシークレット (有料プランの場合) または各リポジトリのシークレット (無料版の場合) として、各リポジトリと共有します。サンプルコードでは、シークレットのデフォルト名は `ORG_PAT` です。 | DevOps エンジニア |
| (オプション) Checkov ワークフローファイルを変更から保護する | Checkov ワークフローファイルを不要な変更から保護するには、`CODEOWNERS` ファイルを使用します。`CODEOWNERS` ファイルは通常、ディレクトリのルートにデプロイされます。例えば、`checkov-scan.yaml` ファイルの変更時に GitHub 組織の `secEng` グループからの承認が必要となるように設定するには、リポジトリの `CODEOWNERS` ファイルに以下を追加します。[Checkov]
.github/workflows/checkov-scan.yaml @myOrg/secEng
`CODEOWNERS` ファイルは、ファイルが存在するリポジトリに固有です。リポジトリで使用される Checkov ワークフローを保護するには、各リポジトリに `CODEOWNERS` ファイルを追加 (または更新) する必要があります。Checkov ワークフローファイルの保護の詳細については、「[追加情報](#centralized-custom-checkov-scanning-additional)」を参照してください。`CODEOWNERS` ファイルの詳細については、CI/CD プロバイダー ([GitHub](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) など) の公式ドキュメントを参照してください。 | DevOps エンジニア |
## 関連リソース
+ [Checkov Custom Policies Overview](https://www.checkov.io/3.Custom%20Policies/Custom%20Policies%20Overview.html)
+ [CloudFormation Configuration Scanning](https://www.checkov.io/7.Scan%20Examples/Cloudformation.html)
+ [GitHub Actions Reusable Workflows](https://docs.github.com/en/actions/using-workflows/reusing-workflows)
## 追加情報
**Checkov ワークフローファイルの記述**
`checkov-scan.yaml` を記述する場合は、このファイルをいつ実行するかを検討してください。最上位の `on` キーは、ワークフローの実行時を決定します。サンプルリポジトリでは、`main` ブランチをターゲットとするプルリクエストがあった場合 (およびプルリクエストのソースブランチが変更された場合) に、ワークフローが実行されます。ワークフローは、`workflow_dispatch` キーによって必要とされる時点で実行することもできます。
ワークフローのトリガー条件は、ワークフローを実行する頻度に応じて変更できます。例えば、`pull_request` を `push` に置き換えて `branches` キーを削除することにより、いずれかのブランチにコードがプッシュされるたびにワークフローが実行されるように変更できます。
個々のリポジトリ内で作成したサンプルワークフローファイルを変更できます。例えば、リポジトリが `production` ブランチを中心に構造化されている場合は、ターゲットブランチの名前を `main` から `production` に変更して調整できます。
**Checkov ワークフローファイルの保護**
Checkov スキャンを実行することにより、潜在的なセキュリティ設定ミスに関する有用な情報が得られます。しかし、デベロッパーによってはこのスキャンが生産性の障壁のように感じられ、スキャンワークフローを削除または無効にしようとする場合があります。
この問題にはいくつかの対処方法が考えられます。例えば、セキュリティスキャンの長期的な価値を伝える的確なメッセージを発信したり、安全なインフラストラクチャのデプロイ方法を明確に規定するドキュメントを整備したりします。こうした方法は、DevSecOps コラボレーションに対する重要な「ソフト」アプローチであり、この問題の根本原因の解決策とみなすことができます。ただし、デベロッパーを適切な方向に誘導するためのガードレールとして、`CODEOWNERS` ファイルなどの技術的な制御を使用することもできます。
**サンドボックスでのパターンのテスト**
サンドボックス環境でこのパターンをテストするには、次の手順に従います。
1. 新しい GitHub 組織を作成します。組織内のすべてのリポジトリに対する読み取り専用アクセス権を持つトークンを作成します。このトークンは有料環境ではなくサンドボックス環境用であるため、このトークンを組織全体のシークレットに保存することはできません。
1. Checkov 設定を保持する `checkov` リポジトリと、再利用可能なワークフロー設定を保持する `github-workflows` リポジトリを作成します。各リポジトリに、サンプルリポジトリの内容を入力します。
1. アプリケーションリポジトリを作成し、`checkov-scan.yaml` ワークフローをコピーして、その `.github/workflows` フォルダに貼り付けます。組織の読み取り専用アクセス用に作成した PAT を含むシークレットをリポジトリに追加します。デフォルトのシークレットは `ORG_PAT` です。
1. Terraform または CloudFormation コードをアプリケーションリポジトリに追加するプルリクエストを作成します。Checkov スキャンを実行し、その結果が返される必要があります。
# K8sGPT と Amazon Bedrock の統合を利用して AI を活用した Kubernetes の診断とトラブルシューティングを実装する
*Amazon Web Services、Ishwar Chauthaiwale、Muskan、Prafful Gupta*
## 概要
このパターンでは、K8sGPT を Amazon Bedrock で利用可能な Anthropic Claude v2 モデルと統合することで、AI を活用した Kubernetes の診断とトラブルシューティングを実装する方法を示します。このソリューションは、安全な踏み台ホストアーキテクチャを通じて、Kubernetes クラスターの問題に対する自然言語分析と修復手順を提供します。K8sGPT Kubernetes の専門知識と Amazon Bedrock の高度な言語機能を組み合わせることで、DevOps チームはクラスターの問題をすばやく特定して解決することができます。これらの機能により、平均解決時間 (MTTR) を最大 50% 短縮できます。
このクラウドネイティブのパターンでは、Kubernetes の管理のために Amazon Elastic Kubernetes Service (Amazon EKS) を使用します。このパターンは、適切な AWS Identity and Access Management (IAM) ロールとネットワーク分離を通じてセキュリティのベストプラクティスを実装します。このソリューションは、Kubernetes のオペレーションを合理化し、AI の支援によりトラブルシューティング機能を強化することを求めている組織にとって特に価値があります。
## 前提条件と制限
**前提条件**
+ 適切なアクセス許可 AWS アカウント を持つアクティブな
+ AWS Command Line Interface (AWS CLI) [のインストール](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)と[設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html)
+ Amazon EKS クラスター
+ [Amazon Bedrock](https://docs.aws.amazon.com/bedrock/latest/userguide/model-access.html) での Anthropic Claude 2 モデルへのアクセス
+ 必要なセキュリティグループが設定された踏み台ホスト
+ K8sGPT が[インストールされていること](https://docs.k8sgpt.ai/getting-started/installation/)
**制限事項**
+ K8sGPT 分析は、Claude v2 モデルのコンテキストウィンドウサイズによって制限されます。
+ Amazon Bedrock API レート制限は、アカウントのクォータに基づいて適用されます。
+ 一部の 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)」を参照して、サービスのリンクを選択してください。
**製品バージョン**
+ Amazon EKS [バージョン 1.31 以降](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)
+ Amazon Bedrock 上の [Claude 2 モデル](https://docs.aws.amazon.com/bedrock/latest/userguide/models-supported.html)
+ K8sGPT [v0.4.2 以降](https://github.com/k8sgpt-ai/k8sgpt/releases)
## アーキテクチャ
次の図に、 AWS クラウドの Amazon Bedrock と統合された K8sGPT を使用した AI 活用 Kubernetes 診断のためのアーキテクチャを示します。
![\[Amazon Bedrock と統合された K8sGPT を使用した Kubernetes 診断のワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/09bc08f6-e191-4cef-b26b-dcb6225b15cc/images/8789891d-4a90-44b0-a108-387f6d96496b.png)
アーキテクチャは以下のワークフローを示しています。
1. 開発者が、踏み台ホストへの安全な接続を介して環境にアクセスします。この Amazon EC2 インスタンスは安全なエントリポイントとして機能し、K8sGPT コマンドラインインターフェイス (CLI) のインストールと必要な設定が格納されています。
1. 特定の IAM ロールで設定された踏み台ホストが、Amazon EKS クラスターと Amazon Bedrock エンドポイントの両方への安全な接続を確立します。K8sGPT は Kubernetes クラスター分析を実行するための踏み台ホストにインストールされ、設定されます。
1. Amazon EKS が Kubernetes コントロールプレーンとワーカーノードを管理し、K8sGPT 分析のターゲット環境を提供します。このサービスは、仮想プライベートクラウド (VPC) 内の複数のアベイラビリティーゾーンで実行され、高可用性と耐障害性を提供するのに役立ちます。Amazon EKS が Kubernetes API を通じて運用データを提供し、包括的なクラスター分析を可能にします。
1. K8sGPT が分析データを Amazon Bedrock に送信します。Amazon Bedrock は、自然言語処理用の Claude v2 基盤モデル (FM) を備えています。このサービスは K8sGPT 分析を処理して人間が読める説明を生成し、特定された問題に基づいて詳細な修復の提案を示します。Amazon Bedrock は、高可用性とスケーラビリティを備えたサーバーレス AI サービスとして動作します。
**注記**
このワークフロー全体で、IAM はロールとポリシーを通じてコンポーネント間のアクセスを制御し、踏み台ホスト、Amazon EKS、Amazon Bedrock インタラクションの認証を管理します。IAM は最小特権の原則を実装し、アーキテクチャ全体で安全なクロスサービス通信を可能にします。
**自動化とスケール**
K8sGPT オペレーションは、さまざまな およびツールを使用して、複数の Amazon EKS クラスターにまたがって自動化 AWS のサービス およびスケーリングできます。このソリューションは、スケジュールされた分析のために、[Jenkins](https://www.jenkins.io/)、[GitHub Actions](https://docs.github.com/en/actions/get-started/understand-github-actions)、または [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) を使用した継続的インテグレーションと継続的デプロイ (CI/CD) 統合をサポートします。K8sGPT Operator は、自動問題検出およびレポート機能を使用して、クラスター内の継続的なモニタリングを可能にします。エンタープライズ規模のデプロイでは、[Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) を使用してスキャンをスケジュールし、カスタムスクリプトで自動レスポンスをトリガーできます。 AWS SDK 統合により、大規模なクラスターフリートをプログラムで制御できます。
## ツール
**AWS サービス**
+ [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) は、コマンドラインシェルのコマンド AWS のサービス を使用して を操作するのに役立つオープンソースツールです。
+ [Amazon Elastic Kubernetes Service (Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html) を使用すると、独自の Kubernetes コントロールプレーンやノードをインストールまたは維持 AWS することなく、 で Kubernetes を実行できます。
+ [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、誰を認証し、誰に使用する権限を付与するかを制御することで、 AWS リソースへのアクセスを安全に管理するのに役立ちます。
**その他のツール**
+ [K8sGPT](https://k8sgpt.ai/) は、Kubernetes 管理を変革するオープンソースの AI 搭載ツールです。仮想サイト信頼性エンジニアリング (SRE) のエキスパートとして機能し、Kubernetes クラスターの問題を自動的にスキャン、診断、トラブルシューティングします。管理者は自然言語を使用して K8sGPT を操作し、クラスターの状態、ポッドのクラッシュ、サービス障害に関する明確で実用的なインサイトを得ることができます。ツールの組み込みアナライザーは、コンポーネントの設定ミスからリソースの制約まで、幅広い問題を検出し、わかりやすい説明とソリューションを提供します。
## ベストプラクティス
+ 踏み台ホストアクセス AWS Systems Manager Session Manager に を使用して、安全なアクセスコントロールを実装します。 [https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/access-a-bastion-host-by-using-session-manager-and-amazon-ec2-instance-connect.html](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/access-a-bastion-host-by-using-session-manager-and-amazon-ec2-instance-connect.html)
+ K8sGPT 認証で、Amazon Bedrock および Amazon EKS インタラクション用の最小特権のアクセス許可を持つ専用の IAM ロールを使用していることを確認します。詳細については、IAM ドキュメントの「[最小限の特権を認める。](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#grant-least-priv)」と「[IAM でのセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)」を参照してください。
+ [リソースへのタグ付け](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/what-are-tags.html)を設定し、Amazon CloudWatch の[監査証跡のログ記録](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/monitor-cloudtrail-log-files-with-cloudwatch-logs.html)を有効にして、機密情報の[データ匿名化](https://aws.amazon.com/solutions/guidance/data-anonymization-on-aws/)を実装します。
+ K8sGPT 設定の定期的なバックアップを維持しながら、オフピーク時に自動スキャンスケジュールを設定して、運用への影響を最小限に抑えます。
## エピック
### Amazon Bedrock を AI バックエンドプロバイダーリストに追加する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| Amazon Bedrock を K8sGPT の AI バックエンドプロバイダーとして設定する。 | Amazon Bedrock を K8sGPT 用の AI [バックエンド provide](https://docs.k8sgpt.ai/reference/providers/backend/) r として設定するには、次の AWS CLI コマンドを使用します。k8sgpt auth add -b amazonbedrock \
-r us-west-2 \
-m anthropic.claude-v2 \
-n endpoint-name
コマンド例では、 AWS リージョンに `us-west-2` を使用します。ただし、Amazon EKS クラスターとそれに対応する Amazon Bedrock モデルの両方がその選択したリージョンで使用可能であり有効になっている場合は、別のリージョンを選択できます。`amazonbedrock` が AI バックエンドプロバイダーリストに追加されていて、`Active` 状態であることを確認するには、次のコマンドを実行します。k8sgpt auth list
以下に、このコマンドを実行したときの出力の例を示します。Default:
> openai
Active:
> amazonbedrock
Unused:
> openai
> localai
> ollama
> azureopenai
> cohere
> amazonsagemaker
> google
> noopai
> huggingface
> googlevertexai
> oci
> customrest
> ibmwatsonxai
| AWS DevOps |
### フィルターを使用してリソースをスキャンする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| 使用可能なフィルターのリストを表示する。 | 使用可能なすべてのフィルターのリストを表示するには、次の AWS CLI コマンドを使用します。k8sgpt filters list
以下に、このコマンドを実行したときの出力の例を示します。Active:
> Deployment
> ReplicaSet
> PersistentVolumeClaim
> Service
> CronJob
> Node
> MutatingWebhookConfiguration
> Pod
> Ingress
> StatefulSet
> ValidatingWebhookConfiguration
| AWS DevOps |
| フィルターを使用して、特定の名前空間のポッドをスキャンする。 | このコマンドは、Kubernetes クラスター内の特定ポッドの問題に対するターゲットを絞ったデバッグに役立ち、Amazon Bedrock AI 機能を使用して、検出された問題を分析および説明します。フィルターを使用して特定の名前空間のポッドをスキャンするには、次の AWS CLI コマンドを使用します。k8sgpt analyze --backend amazonbedrock --explain --filter Pod -n default
以下に、このコマンドを実行したときの出力の例を示します。100% |████████████████████████████████████████████████████████| (1/1, 645 it/s)
AI Provider: amazonbedrock
0: Pod default/crashme()
- Error: the last termination reason is Error container=crashme pod=crashme
Error: The pod named crashme terminated because the container named crashme crashed.
Solution: Check logs for crashme pod to identify reason for crash. Restart pod or redeploy application to resolve crash.
| AWS DevOps |
| フィルターを使用して、特定の名前空間のデプロイをスキャンする。 | このコマンドは、特に実際の状態が目的の状態と一致しない場合に、デプロイ固有の問題を特定してトラブルシューティングするのに役立ちます。フィルターを使用して特定の名前空間のデプロイをスキャンするには、次の AWS CLI コマンドを使用します。k8sgpt analyze --backend amazonbedrock --explain --filter Deployment -n default
以下に、このコマンドを実行したときの出力の例を示します。100% |██████████████████████████████████████████████████████████| (1/1, 10 it/min)
AI Provider: amazonbedrock
0: Deployment default/nginx()
- Error: Deployment default/nginx has 1 replicas but 2 are available
Error: The Deployment named nginx in the default namespace has 1 replica specified but 2 pod replicas are running.
Solution: Check if any other controllers like ReplicaSet or StatefulSet have created extra pods. Delete extra pods or adjust replica count to match available pods.
| AWS DevOps |
| フィルターを使用して、特定の名前空間のノードをスキャンする。 | フィルターを使用して特定の名前空間のノードをスキャンするには、次の AWS CLI コマンドを使用します。k8sgpt analyze --backend amazonbedrock --explain --filter Node -n default
以下に、このコマンドを実行したときの出力の例を示します。AI Provider: amazonbedrock
No problems detected
| AWS DevOps |
### 詳細な出力を分析する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| 詳細な出力を取得する。 | 詳細な出力を取得するには、次の AWS CLI コマンドを使用します。k8sgpt analyze --backend amazonbedrock --explain --ouput json
以下に、このコマンドを実行したときの出力の例を示します。{
"provider": "amazonbedrock",
"errors": null,
"status": "ProblemDetected",
"problems": 1,
"results": [
{
"kind": "Pod",
"name": "default/crashme",
"error": [
{
"Text": "the last termination reason is Error container=crashme pod=crashme",
"KubernetesDoc": "",
"Sensitive": []
}
],
"details": " Error: The pod named crashme terminated because the container named crashme crashed.\nSolution: Check logs for crashme pod to identify reason for crash. Restart pod or redeploy application to resolve crash.",
"parentObject": ""
}
]
} | AWS DevOps |
| 問題のあるポッドを確認する。 | 特定の問題のあるポッドを確認するには、次の AWS CLI コマンドを使用します。kubectl get pods --all-namespaces | grep -v Running
以下に、このコマンドを実行したときの出力の例を示します。NAMESPACE NAME READY STATUS RESTARTS AGE
default crashme 0/1 CrashLoopBackOff 260(91s ago) 21h
| AWS DevOps |
| アプリケーション固有のインサイトを取得する。 | このコマンドは、特に次の場合に便利です。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/implement-ai-powered-kubernetes-diagnostics-and-troubleshooting-with-k8sgpt-and-amazon-bedrock-integration.html)アプリケーション固有のインサイトを取得するには、次のコマンドを実行します。k8sgpt analyze --backend amazonbedrock --explain -L app=nginx -n default
以下に、このコマンドを実行したときの出力の例を示します。AI Provider: amazonbedrock
No problems detected
| |
## 関連リソース
**AWS ブログ**
+ [Automate Amazon EKS troubleshooting using an Amazon Bedrock agentic workflow](https://aws.amazon.com/blogs/machine-learning/automate-amazon-eks-troubleshooting-using-an-amazon-bedrock-agentic-workflow/)
+ [Use K8sGPT and Amazon Bedrock for simplified Kubernetes cluster maintenance](https://aws.amazon.com/blogs/machine-learning/use-k8sgpt-and-amazon-bedrock-for-simplified-kubernetes-cluster-maintenance/)
**AWS ドキュメント**
+ AWS CLI コマンド: [create-cluster](https://docs.aws.amazon.com/cli/latest/reference/eks/create-cluster.html) および [describe-cluster](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/eks/describe-cluster.html)
+ [Amazon EKS の使用を開始する](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html) (Amazon EKS ドキュメント)
+ [IAM でのセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) (IAM ドキュメント)
**その他のリソース**
+ [K8sGPT](https://k8sgpt.ai/)
# CodeCommit 内のモノリポジトリの変更を自動的に検出し、さまざまな CodePipeline パイプラインを開始する
*Helton ribeiro、Petrus Batalha、Ricardo Morais (Amazon Web Services)*
## 概要
**注意**: AWS Cloud9 は新規顧客には利用できなくなりました。の既存のお客様は、通常どおりサービスを AWS Cloud9 引き続き使用できます。[詳細はこちら](https://aws.amazon.com/blogs/devops/how-to-migrate-from-aws-cloud9-to-aws-ide-toolkits-or-aws-cloudshell/)
このパターンは、 でモノレポベースのアプリケーションのソースコードの変更を自動的に検出し AWS CodeCommit 、マイクロサービスごとに継続的インテグレーションと継続的デリバリー (CI/CD) オートメーション AWS CodePipeline を実行するパイプラインを で開始するのに役立ちます。このアプローチは、モノレポベースのアプリケーション内の各マイクロサービスに専用の CI/CD パイプラインを持たせることができることを意味します。これにより、可視性が向上し、コードの共有が容易になり、コラボレーション、標準化、発見が容易になります。
このパターンで説明されているソリューションは、モノレポ内のマイクロサービス間での依存関係分析を実行しません。ソースコードの変更のみを検出し、一致する CI/CD パイプラインを開始します。
このパターンでは、 を統合開発環境 (IDE) AWS Cloud9 として使用し AWS Cloud Development Kit (AWS CDK) 、 `MonoRepoStack`と の 2 つの CloudFormation スタックを使用してインフラストラクチャを定義します`PipelinesStack`。`MonoRepoStack` スタックは、 にモノレポ AWS CodeCommit を作成し、CI/CD パイプラインを開始する AWS Lambda 関数を作成します。`PipelinesStack` スタックはパイプラインインフラストラクチャを定義します。
**重要**
このパターンのワークフローは概念実証 (PoC) です。テスト環境でのみ使用することをお勧めします。このパターンのアプローチを本番環境で使用する場合は、 AWS Identity and Access Management ([IAM) ドキュメントの「IAM のセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)」を参照して、IAM ロールと に必要な変更を加えます AWS のサービス。
## 前提条件と制限事項
**前提条件**
+ アクティブな AWS アカウント。
+ AWS Command Line Interface (AWS CLI)、インストールおよび設定済み。詳細については、 AWS CLI ドキュメント[AWS CLIの「 のインストール、更新、アンインストール](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)」を参照してください。
+ ローカルマシンにインストール済みの Python 3 と `pip`。詳細については、[Python のドキュメント](https://www.python.org/)を参照してください。
+ AWS CDKがインストールされ設定済みであること。詳細については、 AWS CDK ドキュメントの[「Getting started with the AWS CDK](https://docs.aws.amazon.com/cdk/latest/guide/getting_started.html)」を参照してください。
+ IDE AWS Cloud9 がインストールされ、設定されています。詳細については、 AWS Cloud9 ドキュメントの[「セットアップ AWS Cloud9](https://docs.aws.amazon.com/cloud9/latest/user-guide/setting-up.html)」を参照してください。
+ GitHub の [AWS CodeCommit monorepo multi-pipeline triggers](https://github.com/aws-samples/monorepo-multi-pipeline-trigger)リポジトリが、ローカルマシンでクローン済み。
+ CodePipeline でビルドしてデプロイするアプリケーションコードを含む既存のディレクトリ。
+ AWS クラウドでの DevOps のベストプラクティスに関する知識と経験。DevOps の知識を高めるには、 パターンを使用します。[DevOps プラクティスと 規範ガイダンスウェブサイトを使用して、マイクロサービスと疎結合アーキテクチャを構築 AWS Cloud9](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/build-a-loosely-coupled-architecture-with-microservices-using-devops-practices-and-aws-cloud9.html)します。 AWS
## アーキテクチャ
次の図は、 を使用して、 `MonoRepoStack`と の 2 つの AWS CloudFormation スタックを持つインフラストラクチャ AWS CDK を定義する方法を示しています`PipelinesStack`。
![\[AWS CDK を使用して 2 つの CloudFormation スタックを持つインフラストラクチャを定義するワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/a3397158-a208-4033-844e-969af13ae8b6/images/b0bb1094-b598-4b3d-ab8b-ad9b0eb45f38.png)
この図表は、次のワークフローを示しています:
1. ブートストラッププロセスでは、 AWS CDK を使用して AWS CloudFormation スタック`MonoRepoStack`と を作成します`PipelinesStack`。
1. `MonoRepoStack` スタックは、アプリケーション用の CodeCommit リポジトリと、各コミットの後に開始される `monorepo-event-handler` Lambda 関数を作成します。
1. `PipelinesStack` スタックは、Lambda 関数によって開始されるパイプラインを CodePipeline に作成します。各マイクロサービスにはインフラストラクチャパイプラインが定義されている必要があります。
1. `microservice-n` のパイプラインは Lambda 関数によって開始され、CodeCommit のソースコードに基づいて分離された CI/CD ステージを開始します。
1. `microservice-1` のパイプラインは Lambda 関数によって開始され、CodeCommit のソースコードに基づいて分離された CI/CD ステージを開始します。
次の図は、 アカウント`PipelinesStack`での AWS CloudFormation スタック`MonoRepoStack`と のデプロイを示しています。
![\[CloudFormation スタック MonoRepoStack と PipelinesStack の AWS アカウントへのデプロイ。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/a3397158-a208-4033-844e-969af13ae8b6/images/39e60e49-dea2-486d-8a2c-6cae438f69b4.png)
1. ユーザーがアプリケーションのマイクロサービスの 1 つでコードを変更します。
1. ユーザーは、ローカルリポジトリから CodeCommit リポジトリに変更をプッシュします。
1. プッシュアクティビティは、CodeCommit リポジトリへのすべてのプッシュを受け取る Lambda 関数を開始します。
1. Lambda 関数は、 AWS Systems Managerの機能として Parameter Store のパラメータを読み取り、最新のコミット ID を取得します。パラメータには `/MonoRepoTrigger/{repository}/{branch_name}/LastCommit` 命名形式があります。パラメータが見つからない場合、Lambda 関数は CodeCommit リポジトリから最後のコミット ID を読み取り、戻り値をパラメータストアに保存します。
1. コミット ID と変更されたファイルを特定すると、Lambda 関数は各マイクロサービスディレクトリのパイプラインを識別し、必要な CodePipeline パイプラインを開始します。
## ツール
+ [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/latest/guide/home.html) は、コードでクラウドインフラストラクチャを定義し、それをプロビジョニングするためのソフトウェア開発フレームワークです CloudFormation。
+ [Python](https://www.python.org/) は、すばやく作業し、システムをより効果的に統合できるプログラミング言語です。
**コード**
このパターンのソースコードとテンプレートは、GitHub の [AWS CodeCommit monorepo multi-pipeline triggers](https://github.com/aws-samples/monorepo-multi-pipeline-trigger) リポジトリにあります。
## ベストプラクティス
+ このサンプルアーキテクチャには、デプロイされたインフラストラクチャのモニタリングソリューションは含まれていません。このソリューションを本番環境にデプロイしたい場合は、モニタリングを有効にすることをお勧めします。詳細については、 AWS Serverless Application Model (AWS SAM) ドキュメントの[CloudWatch Application Insights を使用してサーバーレスアプリケーションをモニタリングする](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/monitor-app-insights.html)」を参照してください。
+ このパターンで提供されるサンプルコードを編集するときは、 AWS CDK ドキュメントの[クラウドインフラストラクチャを開発およびデプロイするためのベストプラクティス](https://docs.aws.amazon.com/cdk/v2/guide/best-practices.html)に従ってください。
+ マイクロサービスパイプラインを定義するときは、 AWS CodePipeline ドキュメント[のセキュリティのベストプラクティス](https://docs.aws.amazon.com/codepipeline/latest/userguide/security-best-practices.html)を確認してください。
+ [cdk-nag](https://github.com/cdklabs/cdk-nag) ユーティリティを使用して AWS CDK 、コードのベストプラクティスを確認することもできます。このツールは、パックごとにグループ化された一連のルールを使用してコードを評価します。使用可能なパックは次のとおりです。
+ [AWS ソリューションライブラリ](https://github.com/cdklabs/cdk-nag/blob/main/RULES.md#awssolutions)
+ [医療保険の相互運用性と責任に関する法律 (HIPAA) セキュリティ](https://github.com/cdklabs/cdk-nag/blob/main/RULES.md#hipaa-security)
+ [米国国立標準技術研究所 (NIST) 800-53 リビジョン 4](https://github.com/cdklabs/cdk-nag/blob/main/RULES.md#nist-800-53-rev-4)
+ [NIST 800-53 rev 5](https://github.com/cdklabs/cdk-nag/blob/main/RULES.md#nist-800-53-rev-5)
+ [Payment Card Industry Data Security Standard (PCI DSS) 3.2.1](https://github.com/cdklabs/cdk-nag/blob/main/RULES.md#pci-dss-321)
## エピック
### 環境をセットアップする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| 仮想 Python 環境を作成します。 | AWS Cloud9 IDE で、仮想 Python 環境を作成し、次のコマンドを実行して必要な依存関係をインストールします。`make install` | 開発者 |
| の AWS アカウント と AWS リージョン をブートストラップします AWS CDK。 | 次のコマンドを実行して、必要な AWS アカウント とリージョンをブートストラップします。`make bootstrap account-id= region=` | 開発者 |
### マイクロサービス用の新しいパイプラインの追加
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| サンプルコードをアプリケーションディレクトリに追加します。 | サンプルアプリケーションコードを含むディレクトリを、複製された GitHub [AWS CodeCommit monorepo multi-pipeline triggers](https://github.com/aws-samples/monorepo-multi-pipeline-trigger) リポジトリ内の `monorepo-sample` ディレクトリに追加します。 | 開発者 |
| `monorepo-main.json` ファイルを編集します。 | アプリケーションのコードのディレクトリ名とパイプラインの名前を、複製されたリポジトリ内の `monorepo-main.json` ファイルに追加します。 | 開発者 |
| パイプラインを作成します。 | リポジトリの `Pipelines` ディレクトリに、アプリケーションのパイプライン `class` を追加します。ディレクトリには、`pipeline_hotsite.py` と `pipeline_demo.py` の 2 つのサンプルファイルが含まれています。各ファイルには、ソース、ビルド、デプロイの 3 つのステージがあります。ファイルの 1 つをコピーして、アプリケーションの要件に応じて変更を加えることができます。 | 開発者 |
| `monorepo_config.py` ファイルを編集します。 | `service_map` に、アプリケーションのディレクトリ名と、パイプライン用に作成したクラスを追加します。例えば、次のコードは、`MySamplePipeline`クラスで `pipeline_mysample.py` と名前が付けられたファイルを使用する `Pipelines` ディレクトリ内のパイプライン定義を示しています。...
# Pipeline definition imports
from pipelines.pipeline_demo import DemoPipeline
from pipelines.pipeline_hotsite import HotsitePipeline
from pipelines.pipeline_mysample import MySamplePipeline
### Add your pipeline configuration here
service_map: Dict[str, ServicePipeline] = {
# folder-name -> pipeline-class
'demo': DemoPipeline(),
'hotsite': HotsitePipeline(),
'mysample': MySamplePipeline()
}
| 開発者 |
### MonorePostack スタックをデプロイします。
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| AWS CloudFormation スタックをデプロイします。 | `make deploy-core` コマンドを実行して、 AWS CloudFormation `MonoRepoStack`デフォルトのパラメータ値を持つスタックをクローンされたリポジトリのルートディレクトリにデプロイします。リポジトリの名前は、`make deploy-core monorepo-name=` コマンドを実行して変更できます。`make deploy monorepo-name=` コマンドを使用すると、両方のパイプラインを同時にデプロイできます。 | 開発者 |
| CodeCommit リポジトリを検証します。 | `aws codecommit get-repository --repository-name ` コマンドを実行して、リソースが作成されたことを確認します。 CloudFormation スタックはモノレポが保存されている CodeCommit リポジトリを作成するため、変更のプッシュを開始した場合は`cdk destroy MonoRepoStack `コマンドを実行しないでください。 | 開発者 |
| CloudFormation スタックの結果を検証します。 | 次のコマンドを実行して、 CloudFormation `MonoRepoStack`スタックが正しく作成および設定されていることを確認します。aws cloudformation list-stacks --stack-status-filter CREATE_COMPLETE --query 'StackSummaries[?StackName == 'MonoRepoStack']'
| 開発者 |
### PipelinesStack スタックをデプロイします。
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| CloudFormation スタックをデプロイします。 | AWS CloudFormation `PipelinesStack` スタックは、スタックをデプロイした後にデプロイする必要があります`MonoRepoStack`。monorepo のコードベースに新しいマイクロサービスが追加されるとスタックのサイズが大きくなり、新しいマイクロサービスが導入されるとスタックが再デプロイされます。`make deploy-pipelines` コマンドを実行して PipelinesStack スタックをデプロイします。`make deploy monorepo-name=` コマンドを実行して、両方のパイプラインを同時にデプロイすることもできます。以下の出力例は、実装の最後に `PipelinesStacks` デプロイメントによってマイクロサービスの URL がどのように出力されるかを示しています。Outputs:
PipelinesStack.demourl = .cloudfront.net
PipelinesStack.hotsiteurl = .cloudfront.net
| 開発者 |
| AWS CloudFormation スタックの結果を検証します。 | 次のコマンドを実行して、 AWS CloudFormation `PipelinesStacks`スタックが正しく作成および設定されていることを確認します。aws cloudformation list-stacks --stack-status-filter CREATE_COMPLETE UPDATE_COMPLETE --query 'StackSummaries[?StackName == 'PipelinesStack']'
| 開発者 |
### リソースをクリーンアップする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| AWS CloudFormation スタックを削除します。 | `make destroy` コマンドを実行します。 | 開発者 |
| パイプラインの S3 バケットを削除します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-detect-changes-and-initiate-different-codepipeline-pipelines-for-a-monorepo-in-codecommit.html) | 開発者 |
## トラブルシューティング
| 問題 | ソリューション |
| --- | --- |
| AWS CDK 問題が発生しました。 | AWS CDK ドキュメントの「一般的な[AWS CDK 問題のトラブルシューティング](https://docs.aws.amazon.com/cdk/v2/guide/troubleshooting.html)」を参照してください。 |
| マイクロサービスコードをプッシュしましたが、マイクロサービスパイプラインは実行されませんでした。 | **セットアップの検証***ブランチ設定を確認します。*[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-detect-changes-and-initiate-different-codepipeline-pipelines-for-a-monorepo-in-codecommit.html)*設定ファイルを検証します。*[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-detect-changes-and-initiate-different-codepipeline-pipelines-for-a-monorepo-in-codecommit.html)**コンソールでのトラブルシューティング***AWS CodePipeline は以下をチェックします。*[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-detect-changes-and-initiate-different-codepipeline-pipelines-for-a-monorepo-in-codecommit.html)*AWS Lambda トラブルシューティング:*[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-detect-changes-and-initiate-different-codepipeline-pipelines-for-a-monorepo-in-codecommit.html) |
| すべてのマイクロサービスを再デプロイする必要があります。 | すべてのマイクロサービスの再デプロイを強制するためには、2 つのアプローチがあります。要件に合ったオプションを選択してください。**アプローチ 1: Parameter Store でパラメータを削除する**このメソッドでは、デプロイに使用された最後のコミット ID を追跡する Systems Manager Parameter Store 内の特定のパラメータを削除します。このパラメータを削除すると、システムは新しい状態として認識するため、次のトリガーですべてのマイクロサービスを強制的に再デプロイします。手順:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-detect-changes-and-initiate-different-codepipeline-pipelines-for-a-monorepo-in-codecommit.html)メリット:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-detect-changes-and-initiate-different-codepipeline-pipelines-for-a-monorepo-in-codecommit.html)デメリット:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-detect-changes-and-initiate-different-codepipeline-pipelines-for-a-monorepo-in-codecommit.html)**アプローチ 2: 各モノレポサブフォルダにコミットをプッシュする**この方法では、マイナーな変更を行い、モノレポ内の各マイクロサービスサブフォルダにプッシュし、個々のパイプラインを開始します。手順:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-detect-changes-and-initiate-different-codepipeline-pipelines-for-a-monorepo-in-codecommit.html)メリット:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-detect-changes-and-initiate-different-codepipeline-pipelines-for-a-monorepo-in-codecommit.html)デメリット:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-detect-changes-and-initiate-different-codepipeline-pipelines-for-a-monorepo-in-codecommit.html) |
## 関連リソース
+ [CDK Pipelines を使用した継続的な統合と配信 (CI/CD)](https://docs.aws.amazon.com/cdk/latest/guide/cdk_pipeline.html) (AWS CDK ドキュメント)
+ [aws-cdk/pipelines モジュール](https://docs.aws.amazon.com/cdk/api/latest/docs/pipelines-readme.html) (AWS CDK API リファレンス)
# AWS CloudFormation を使用して Bitbucket リポジトリを AWS Amplify と統合する
*Amazon Web Services、Alwin Abraham*
## 概要
AWS Amplify を使用すると、通常必要なインフラストラクチャをセットアップしなくても、静的ウェブサイトを迅速にデプロイしてテストできます。既存のアプリケーションコードを移行する場合でも、新しいアプリケーションを構築する場合でも、組織が Bitbucket をソース管理に使用したい場合は、このパターンのアプローチを導入できます。AWS CloudFormation を使用して Amplify を自動的にセットアップすることで、使用している設定を可視化できます。
AWS CloudFormation を使用して Bitbucket リポジトリを AWS Amplify と統合することで、フロントエンド CI/CD パイプラインとデプロイ環境を作成します。このパターンのアプローチは、反復可能なデプロイメントのためのAmplify フロントエンドパイプラインを構築できることを意味します。
## 前提条件と制限事項
前提条件
+ Amazon Web Services (AWS) (AWS) アカウント。
+ 管理者アクセス権を持つアクティブな Bitbucket アカウント
+ 「[cURL](https://curl.se/)」または「[Postman](https://www.postman.com/)」アプリケーションを使用する端末へのアクセス
+ Amplify Gurify の使用方法
+ AWS CloudFormation に精通している
+ YAML 形式のファイルに精通していること
## アーキテクチャ
![\[Diagram showing user interaction with Bitbucket repository connected to AWS Amplify in AWS クラウド region.\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/24ae87ed-aa5d-4114-9c5d-bdcb4d40a78b/images/25d73a9d-d2ae-40bc-9ebc-57f9bd13884a.png)
**テクノロジースタック**
+ Amplify
+ AWS CloudFormation
+ Bitbucket
## ツール
+ [AWS Amplify](https://docs.aws.amazon.com/amplify/) — Amplify は、開発者がクラウドを利用したモバイルアプリやウェブアプリを開発およびデプロイするのに役立ちます。
+ [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) – AWS CloudFormation は AWS リソースのモデル化とセットアップに役立つサービスです。リソース管理に割く時間を減らし、AWS で実行するアプリケーションにより注力できるようになります。
+ [Bitbucket](https://bitbucket.org/) — Bitbucket は、プロフェッショナルチーム向けに設計された Git リポジトリ管理ソリューションです。Git リポジトリの管理、ソースコードの共同編集、開発フローのガイドなどを一元的に行えます。
**コード**
`bitbucket-amplify.yml`ファイル (添付) には、このパターンの AWS CloudFormation テンプレートが含まれています。
## エピック
### Bitbucket リポジトリを設定します。
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| (オプション) Bitbucket リポジトリを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/integrate-a-bitbucket-repository-with-aws-amplify-using-aws-cloudformation.html)既存の Bitbucket リポジトリを使用することもできます。 | DevOps エンジニア |
| ワークスペース設定を開きます。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/integrate-a-bitbucket-repository-with-aws-amplify-using-aws-cloudformation.html) | DevOps エンジニア |
| OAuth コンシューマーを作成します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/integrate-a-bitbucket-repository-with-aws-amplify-using-aws-cloudformation.html) | DevOps エンジニア |
| OAuth アクセストークンを取得します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/integrate-a-bitbucket-repository-with-aws-amplify-using-aws-cloudformation.html)`curl -X POST -u "KEY:SECRET" https://bitbucket.org/site/oauth2/access_token -d grant_type=client_credentials ``KEY` と `SECRET` を先ほど記録したキーとシークレットに置き換えます。 2. 引用符を使わずにアクセストークンを記録します。トークンの有効期間は限られており、デフォルトは 2 時間です。この期間内に AWS CloudFormation テンプレートを実行する必要があります。 | DevOps エンジニア |
### AWS CloudFormation スタックの設定とデプロイ
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| AWS CloudFormation のテンプレートをダウンロードします。 | `bitbucket-amplify.yml`AWS CloudFormation のテンプレートをダウンロードします。このテンプレートは、Amplify プロジェクトとブランチに加えて、AAmplify でCI/CDパイプラインを作成します。 | |
| AWS CloudFormation スタックの設定とデプロイ | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/integrate-a-bitbucket-repository-with-aws-amplify-using-aws-cloudformation.html)5. [**次へ**] を選択してから、[**スタックの作成**] を選択します。 | DevOps エンジニア |
### CI/CD パイプラインをテストする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| コードをリポジトリのブランチにデプロイします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/integrate-a-bitbucket-repository-with-aws-amplify-using-aws-cloudformation.html)このコマンドの詳細については、Ｂｉｔｂｕｋｅｃｔドキュメントの「[基本の Git コマンド](https://confluence.atlassian.com/bitbucketserver/basic-git-commands-776639767.html)」を参照してください。 | アプリ開発者 |
## 関連リソース
[認証方法](https://developer.atlassian.com/bitbucket/api/2/reference/meta/authentication) (アトラシアン製品ドキュメント)
## アタッチメント
このドキュメントに関連する追加コンテンツにアクセスするには、次のファイルを解凍してください。「[attachment.zip](samples/p-attach/24ae87ed-aa5d-4114-9c5d-bdcb4d40a78b/attachments/attachment.zip)」
# Step Functions と Lambda プロキシ関数を使用して AWS アカウント間で CodeBuild プロジェクトを起動する
*Amazon Web Services、Richard Milner-Watts および Amit Anjarlekar*
## 概要
このパターンは、AWS Step Functions と AWS Lambda プロキシ関数を使用して複数の AWS アカウント間で AWS CodeBuild プロジェクトを非同期で起動する方法を示しています。パターンのサンプル Step Functions ステートマシンを使用して、CodeBuild プロジェクトの成功をテストできます。
CodeBuild は、フルマネージドのランタイム環境から AWS コマンドラインインターフェイス (AWS CLI) を使用して運用タスクを起動するのに役立ちます。環境変数をオーバーライドすることで、ランタイムにおける CodeBuild プロジェクトの動作を変更できます。また、CodeBuild を使用してワークフローを管理できます。詳細については、AWS ワークショップウェブサイトの「[サービスカタログツール](https://service-catalog-tools-workshop.com/tools.html)」と、AWS データベースブログの「[AWS CodeBuild と Amazon EventBridge を使用して Amazon RDS for PostgreSQL のジョブをスケジュールする](https://aws.amazon.com/blogs/database/schedule-jobs-in-amazon-rds-for-postgresql-using-aws-codebuild-and-amazon-eventbridge/)」を参照してください。
## 前提条件と制限
**前提条件**
+ 2 つのアクティブな AWS アカウント。1 つはStep Functions で Lambda プロキシ関数を呼び出すためのソースアカウントで、もう 1 つはリモート CodeBuild サンプルプロジェクトを構築するためのターゲットアカウント
**制限事項**
+ このパターンを使用して、[アーティファクト](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-codebuild-project-artifacts.html)をアカウント間でコピーすることはできません。
## アーキテクチャ
このパターンが構築するアーキテクチャを次の図に示します。
![\[複数の AWS アカウントで CodeBuild プロジェクトを起動するアーキテクチャ図\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/809a5716-56e5-477c-aac6-02243675a2f2/images/857ba3ae-eb9a-4d6b-b73e-e596f41c8cb8.png)
この図表は、次のワークフローを示しています:
1. Step Functions ステートマシンは、指定された入力マップを解析し、定義したアカウント、リージョン、プロジェクトごとに Lambda プロキシ関数 (`codebuild-proxy-lambda`) を呼び出します。
1. Lambda プロキシ関数は、AWS Security Token Service (AWS STS) を使用して、ターゲットアカウントで IAM ポリシー (`codebuild-proxy-policy`) に関連付けられている IAM プロキシロール (`codebuild-proxy-role`) を引き受けます。
1. 引き受けたロールを使用して、Lambda 関数は CodeBuild プロジェクトを起動し、CodeBuild ジョブ ID を返します。Step Functions ステートマシンは、成功または失敗のステータスを受け取るまでループし、CodeBuild ジョブをポーリングします。
ステートマシンロジックを次の図に示します。
![\[Step Functions ステートマシンのワークフロー\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/809a5716-56e5-477c-aac6-02243675a2f2/images/4729bbfc-79ad-455d-a85a-b96cce00f432.png)
テクノロジースタック
+ AWS CloudFormation
+ CodeBuild
+ IAM
+ Lambda
+ ステップ関数
+ X-Ray
## ツール
+ [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) を使用すると、AWS リソースをセットアップし、迅速かつ一貫したプロビジョニングを行い、AWS アカウントとリージョン全体でライフサイクル全体にわたってリソースを管理できます。
+ [AWS CloudFormation Designer](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/working-with-templates-cfn-designer-json-editor.html) には、CloudFormation テンプレートの表示と編集に役立つ JSON と YAML の統合エディタが用意されています。
+ [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) はフルマネージドの構築サービスです。ソースコードのコンパイル、ユニットテストの実行、すぐにデプロイできるアーティファクトの生成を行います。
+ 「[AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)」は、AWS リソースへのアクセスを安全に管理し、誰が認証され、使用する権限があるかを制御するのに役立ちます。
+ [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。
+ [AWS Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)は、AWS Lambda関数と他のAWS サービスを組み合わせてビジネスクリティカルなアプリケーションを構築できるサーバーレスオーケストレーションサービスです。
+ [AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) は、アプリケーションで処理するリクエストに関するデータを収集するのに役立ち、さらにデータの表示、フィルタリング、インサイトによって問題や機会を特定して最適化するために使用できるツールを提供します。
**Code**
このパターンのサンプルコードは、GitHub [クロスアカウント CodeBuild プロキシ](https://github.com/aws-samples/cross-account-codebuild-proxy)リポジトリにあります。このパターンでは、AWS Lambda Powertools for Python ライブラリを使用してロギング機能とトレース機能を提供しています。このライブラリとそのユーティリティの詳細については、「[Powertools for AWS Lambda (Python)](https://docs.powertools.aws.dev/lambda/python/latest/)」を参照してください。
## ベストプラクティス
1. ジョブステータスのポーリングリクエストを最小限に抑えるために、Step Function ステートマシンの待機時間の値を調整します。CodeBuild プロジェクトの予想される実行時間を使用します。
1. Step Functions のマップの `MaxConcurrency` プロパティを調整して、並行して実行できる CodeBuild プロジェクトの数を制御します。
1. 必要に応じて、サンプルコードを確認して本番稼働への準備状況を確認します。ソリューションによってログに記録される可能性のあるデータと、デフォルトの Amazon CloudWatch 暗号化で十分かどうかを検討します。
## エピック
### ソースアカウントで Lambda プロキシ関数と関連する IAM ロールを作成する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| AWS アカウント ID を記録する。 | アカウント間のアクセスを設定するには、AWS アカウント ID が必要です。ソースアカウントとターゲットアカウントの AWS アカウント ID を記録します。詳細については、IAM ドキュメントの「[ アカウント ID の検索](https://docs.aws.amazon.com/IAM/latest/UserGuide/console_account-alias.html#FindingYourAWSId)」を参照してください。 | AWS DevOps |
| AWS CloudFormation のテンプレートをダウンロードする。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/launch-a-codebuild-project-across-aws-accounts-using-step-functions-and-a-lambda-proxy-function.html)AWS CloudFormation テンプレートでは、`` はソースアカウントの AWS アカウント ID で、`` はターゲットアカウントの AWS アカウント ID です。 | AWS DevOps |
| AWS CloudFormation スタックを設定しデプロイします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/launch-a-codebuild-project-across-aws-accounts-using-step-functions-and-a-lambda-proxy-function.html)ターゲットアカウントにリソースを作成する前に、プロキシ Lambda 関数用の AWS CloudFormation スタックを作成する必要があります。ターゲットアカウントで信頼ポリシーを作成すると、IAM ロールはロール名から内部識別子に変換されます。これが、IAM ロールが既に存在している必要がある理由です。 | AWS DevOps |
| プロキシ関数とステートマシンが作成されていることを確認します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/launch-a-codebuild-project-across-aws-accounts-using-step-functions-and-a-lambda-proxy-function.html) | AWS DevOps |
### ターゲットアカウントに IAM ロールを作成し、サンプル CodeBuild プロジェクトを起動する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| AWS CloudFormation スタックを設定しデプロイします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/launch-a-codebuild-project-across-aws-accounts-using-step-functions-and-a-lambda-proxy-function.html) | AWS DevOps |
| サンプル CodeBuild プロジェクトが作成されていることを確認します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/launch-a-codebuild-project-across-aws-accounts-using-step-functions-and-a-lambda-proxy-function.html) | AWS DevOps |
### クロスアカウントの Lambda プロキシ関数のテスト
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| ステートマシンを起動します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/launch-a-codebuild-project-across-aws-accounts-using-step-functions-and-a-lambda-proxy-function.html) | AWS DevOps |
| 環境変数を検証します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/launch-a-codebuild-project-across-aws-accounts-using-step-functions-and-a-lambda-proxy-function.html) | AWS DevOps |
## トラブルシューティング
| 問題 | ソリューション |
| --- | --- |
| Step Functions の実行には予想よりも時間がかかります。 | Step Function ステートマシンのマップの `MaxConcurrency` プロパティを調整して、並行して実行できる CodeBuild プロジェクトの数を制御します。 |
| CodeBuild ジョブの実行には予想よりも時間がかかります。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/launch-a-codebuild-project-across-aws-accounts-using-step-functions-and-a-lambda-proxy-function.html) |
# Application Recovery Controller を使用して EMR クラスターのマルチ AZ フェイルオーバーを管理する
*Amazon Web Services、Aarti Rajput、Ashish Bhatt、Neeti Mishra、Nidhi Sharma*
## 概要
このパターンは、Amazon EMR ワークロードの効率的なディザスタリカバリ戦略を提供し、ひとつの AWS リージョン内における複数のアベイラビリティーゾーン間で高可用性とデータ整合性を確保するのに役立ちます。この設計では、[Amazon Application Recovery Controller](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html) と [Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) を使用して、Apache Spark ベースの EMR クラスターのフェイルオーバーオペレーションとトラフィック分散を管理します。
標準条件下では、プライマリアベイラビリティーゾーンは、完全な読み取り / 書き込み機能を備えたアクティブな EMR クラスターとアプリケーションをホストします。アベイラビリティーゾーンが予期せず失敗した場合、トラフィックは自動的にセカンダリアベイラビリティーゾーンにリダイレクトされ、そこで新しい EMR クラスターが起動されます。両方のアベイラビリティーゾーンは、専用の[ゲートウェイエンドポイント](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-s3.html)を介して共有 Amazon Simple Storage Service (Amazon S3) バケットにアクセスし、一貫したデータ管理を実現します。このアプローチにより、ダウンタイムが最小限に抑えられ、アベイラビリティーゾーンの障害発生時に重要なビッグデータワークロードを迅速に復旧できます。このソリューションは、リアルタイム分析が重要な金融や小売などの業界で役立ちます。
## 前提条件と制限
**前提条件**
+ アクティブな [AWS アカウント](https://aws.amazon.com/resources/create-account/)
+ Amazon Elastic Compute Cloud (Amazon EC2) 上の [Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-what-is-emr.html)
+ EMR クラスターのプライマリノードから Amazon S3 へのアクセス。
+ AWS マルチ AZ インフラストラクチャ
**制限事項**
+ 一部の AWS のサービス は では使用できません AWS リージョン。利用可能なリージョンについて、詳しくは「[AWS のサービス by Region](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)」をご確認ください。特定のエンドポイントについては、「[Service endpoints and quotas page](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)」から、サービスのリンクを選択してご確認ください。
**製品バージョン**
+ [Amazon EMR リリース 6.x 以降](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-release-components.html)
## アーキテクチャ
**ターゲットテクノロジースタック**
+ Amazon EMR クラスター
+ Amazon Application Recovery Controller
+ Application Load Balancer
+ Amazon S3 バケット
+ Amazon S3 のゲートウェイエンドポイント
**ターゲットアーキテクチャ**
![\[Application Recovery Controller を使用した自動復旧メカニズムのアーキテクチャ。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/e5ecdb66-0eef-4a6a-8367-982a55104748/images/e982d580-13db-4bdd-9f6b-6400d7c31c01.png)
このアーキテクチャは、複数のアベイラビリティーゾーンを使用し、Application Recovery Controller を通じて自動復旧メカニズムを実装することで、アプリケーションの耐障害性を提供します。
1. Application Load Balancer は、トラフィックをアクティブな Amazon EMR 環境にルーティングします。通常この環境は、プライマリアベイラビリティーゾーンのプライマリ EMR クラスターになります。
1. アクティブな EMR クラスターはアプリケーションリクエストを処理し、専用の Amazon S3 ゲートウェイエンドポイント経由で Amazon S3 に接続して、読み取りおよび書き込みオペレーションを行います。
1. Amazon S3 は中央データリポジトリとして機能し、チェックポイントまたは EMR クラスター間の共有ストレージとして使用される可能性があります。EMR クラスターは、`s3://` プロトコルと [EMR ファイルシステム (EMRFS)](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-fs.html) を介して Amazon S3 に直接書き込む際にデータ整合性を維持します。
1. Application Recovery Controller は、プライマリアベイラビリティーゾーンの状態を継続的にモニタリングし、必要に応じてフェイルオーバーオペレーションを自動的に管理します。
1. Application Recovery Controller がプライマリ EMR クラスターで障害を検出すると、次のアクションを実行します。
+ アベイラビリティーゾーン 2 のセカンダリ EMR クラスターへのフェイルオーバープロセスを開始します。
+ ルーティング設定を更新して、トラフィックをセカンダリクラスターに転送します。
## ツール
**AWS サービス**
+ [Amazon Application Recovery Controller](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)** **は、 とアベイラビリティーゾーン間のアプリケーションの復旧を管理 AWS リージョン および調整するのに役立ちます。このサービスは、従来のツールやプロセスに必要な手動ステップを削減することで、プロセスを簡素化し、アプリケーション復旧の信頼性を向上させます。
+ [Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) は、開放型システム間相互接続 (OSI) モデルの第 7 層であるアプリケーションレイヤーで機能します。受信アプリケーショントラフィックを複数のアベイラビリティーゾーンの複数のターゲット (EC2 インスタンスなど) に分散します。これにより、アプリケーションの可用性が向上します。
+ [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) は、コマンドラインシェルのコマンド AWS のサービス を使用して を操作するのに役立つオープンソースツールです。
+ [Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-what-is-emr.html) は、Apache Spark、Apache Hive、Presto などのオープンソースフレームワークのデータ処理、インタラクティブ分析、機械学習を提供するビッグデータプラットフォームです。
+ [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、誰を認証し、誰に使用する権限を付与するかを制御することで、 AWS リソースへのアクセスを安全に管理するのに役立ちます。
+ [Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) のウェブサービスインターフェイスはシンプルで、いつでも、ウェブのどこからでも容量に関係なくデータを格納および取得できます。このサービスを使用すると、クラウドネイティブストレージを利用するアプリケーションを簡単に構築できます。
+ [Amazon S3 のゲートウェイエンドポイント](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-s3.html)は、 AWS ネットワーク経由で Virtual Private Cloud (VPC) から Amazon S3 にアクセスするためにルートテーブルで指定するゲートウェイです。
## ベストプラクティス
+ 「[AWS best practices for security, identity, and compliance](https://aws.amazon.com/architecture/security-identity-compliance/?cards-all.sort-by=%5b…%5d.sort-order=desc&awsf.content-type=*all&awsf.methodology=*all)」の記載に従って、信頼性のある安全なアーキテクチャを構築します。
+ アーキテクチャ調整の際には「[AWS Well-Architected フレームワーク](https://aws.amazon.com/architecture/well-architected/)」を参照してください。
+ Amazon S3 Access Grants を使用して、Spark ベースの EMR クラスターから Amazon S3 へのアクセスを管理します。詳しくはブログ記事「[Use Amazon EMR with S3 Access Grants to Scale Spark access to Amazon S3](https://aws.amazon.com/blogs/big-data/use-amazon-emr-with-s3-access-grants-to-scale-spark-access-to-amazon-s3/)」をご確認ください。
+ [Amazon S3 で Spark のパフォーマンスを向上させます](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-spark-s3-performance.html)。
## エピック
### 環境をセットアップします。
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| AWS マネジメントコンソールにサインインします。 | [AWS マネジメントコンソール](https://console.aws.amazon.com/) に IAM ユーザーとしてサインインします。手順については、[AWS ドキュメント](https://docs.aws.amazon.com/signin/latest/userguide/introduction-to-iam-user-sign-in-tutorial.html)を参照してください。 | AWS DevOps |
| AWS CLIを設定します。**** | をインストールする AWS CLI か、最新バージョンに更新して、 AWS のサービス で を操作できるようにします AWS マネジメントコンソール。手順については、[AWS CLI ドキュメント](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)を参照してください。 | AWS DevOps |
### EMR クラスターに Spark アプリケーションをデプロイする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| S3 バケットを作成する。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/multi-az-failover-spark-emr-clusters-arc.html) | AWS DevOps |
| EMR クラスターの作成 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/multi-az-failover-spark-emr-clusters-arc.html) | AWS DevOps |
| EMR クラスターのセキュリティ設定を行います。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/multi-az-failover-spark-emr-clusters-arc.html) | AWS DevOps |
| EMR クラスターに接続します。 | 提供されたキーペアを使用して、SSH を介して EMR クラスターのプライマリノードに接続します。キーペアファイルがアプリケーションと同じディレクトリに存在することを確認します。次のコマンドを実行して、キーペアに正しいアクセス許可を設定し、SSH 接続を確立します。chmod 400
ssh -i ./ hadoop@
| AWS DevOps |
| Spark アプリケーションをデプロイします。 | SSH 接続を確立すると、Hadoop コンソールに表示されます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/multi-az-failover-spark-emr-clusters-arc.html) | AWS DevOps |
| Spark アプリケーションをモニタリングします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/multi-az-failover-spark-emr-clusters-arc.html) | AWS DevOps |
### トラフィックを別のアベイラビリティーゾーンに移動する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| Application Load Balancer を作成します。 | AWS リージョン内の 2 つのアベイラビリティーゾーンにデプロイされている Amazon EMR プライマリノード間でトラフィックをルーティングするターゲットグループを設定します。手順について、詳しくは「[Create a target group for your Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-target-group.html)」(Elastic ロードバランサードキュメント) をご確認ください。 | AWS DevOps |
| Application Recovery Controller でゾーンシフトを設定します。 | このステップでは、Application Recovery Controller の[ゾーンシフト機能](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.html)を使用して、トラフィックを別のアベイラビリティーゾーンにシフトします。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/multi-az-failover-spark-emr-clusters-arc.html)を使用するには AWS CLI、Application Recovery Controller [ドキュメントの「ゾーンシフト AWS CLI で を使用する例](https://docs.aws.amazon.com/r53recovery/latest/dg/getting-started-cli-zonalshift.html)」を参照してください。 | AWS DevOps |
| ゾーンシフトの設定と進行状況を確認します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/multi-az-failover-spark-emr-clusters-arc.html) | AWS DevOps |
## 関連リソース
+ AWS CLI コマンド:
+ [クラスター作成](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/emr/create-cluster.html)
+ [describe-cluster](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/emr/describe-cluster.html)
+ [arc-zonal-shift](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/arc-zonal-shift/index.html)
+ [Configuring Amazon EMR cluster instance types and best practices for Spot instances](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-instances-guidelines.html) (Amazon EMR ドキュメント)
+ [IAM でのセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) (IAM ドキュメント)
+ [インスタンスプロファイルを使用する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2_instance-profiles.html) (IAM ドキュメント)
+ [Use zonal shift and zonal autoshift to recovery applications in ARC](https://docs.aws.amazon.com/r53recovery/latest/dg/multi-az.html) (Application Recovery Controller ドキュメント)
# AWS コードサービスと AWS KMS マルチリージョンキーを使用して、複数のアカウントとリージョンへのマイクロサービスのブルー/グリーンデプロイを管理
*Amazon Web Services、Balaji Vedagiri、Vanitha Dontireddy、Ashish Kumar、Faisal Shahdad、Vivek Thangamuthu、および Anand Krishna Varanasi*
## 概要
このパターンは、ブルー/グリーンデプロイ戦略に従い、中央のAWS アカウントから複数のワークロードアカウントとリージョンにグローバルマイクロサービスアプリケーションをデプロイする方法を説明しています。このパターンは以下をサポートします。
+ ソフトウェアは中央アカウントで開発されますが、ワークロードとアプリケーションは複数のアカウントと AWS リージョンに分散されます。
+ ディザスタリカバリとして、単一の AWS キー管理システム (AWS KMS) マルチリージョンキーが暗号化と復号に使用されます。
+ KMS キーはリージョン固有であり、パイプラインアーティファクト用に 3 つの異なるリージョンで管理しまたは作成する必要があります。KMS マルチリージョンキーは、リージョン間で同じキー ID を保持することに役立ちます。
+ Git ワークフローの分岐モデルは 2 つのブランチ (開発とメイン) で実装され、コードはプルリクエスト (PR) でマージされます。このスタックからデプロイされる AWS Lambda 関数は、開発ブランチからメインブランチへの PR を作成します。メインブランチにマージするPR は、AWS CodePipeline パイプラインを開始します。これにより、継続的インテグレーションと継続的デリバリー (CI/CD) フローをオーケストレーションし、アカウントにスタックをデプロイします。
このパターンは、AWS CloudFormation スタックによるコードとしての Infrastructure as Code (IaC) 設定のサンプルを提供され、このユースケースを説明します。マイクロサービスのブルー/グリーンデプロイは、AWS CodeDeploy を使用して実装されます。
## 前提条件と制限
**前提条件**
+ 4 つのアクティブな AWS アカウント:
+ コードパイプラインを管理し、AWS CodeCommit リポジトリを維持するためのツールアカウント。
+ マイクロサービスワークロードをデプロイするための 3 つのワークロード (テスト) アカウント。
+ このパターンでは次のリージョンを使用します。他のリージョンを使用する場合は、AWS CodeDeploy と AWS KMS マルチリージョンスタックに適切な変更を加える必要があります。
+ ツール (AWS CodeCommit) アカウント： `ap-south-1`
+ ワークロード (テスト) アカウント 1： `ap-south-1`
+ ワークロード (テスト) アカウント 2： `eu-central-1`
+ ワークロード (テスト) アカウント 3： `us-east-1`
+ 各ワークロードアカウントのデプロイ用の 3 つの Amazon Simple Storage Service (Amazon S3) バケット。(これらはこのパターンで、`S3BUCKETNAMETESTACCOUNT1` 、`S3BUCKETNAMETESTACCOUNT2 ` 、`S3BUCKETNAMETESTACCOUNT3 ` と呼ばれています。)
例えば、これらのバケットは、特定のアカウントとリージョンに次のように固有のバケット名で作成できます (*xxxx* をランダムなナンバーに置き換える)。
```
##In Test Account 1
aws s3 mb s3://ecs-codepipeline-xxxx-ap-south-1 --region ap-south-1
##In Test Account 2
aws s3 mb s3://ecs-codepipeline-xxxx-eu-central-1 --region eu-central-1
##In Test Account 3
aws s3 mb s3://ecs-codepipeline-xxxx-us-east-1 --region us-east-1
#Example
##In Test Account 1
aws s3 mb s3://ecs-codepipeline-18903-ap-south-1 --region ap-south-1
##In Test Account 2
aws s3 mb s3://ecs-codepipeline-18903-eu-central-1 --region eu-central-1
##In Test Account 3
aws s3 mb s3://ecs-codepipeline-18903-us-east-1 --region us-east-1
```
**制限事項**
このパターンは、AWS CodeBuild とその他の設定ファイルでサンプルマイクロサービスをデプロイします。別のワークロードタイプ (サーバーレスなど) を使用している場合は、関連する設定をすべて更新する必要があります。
## アーキテクチャ
**ターゲットテクノロジースタック**
+ AWS CloudFormation
+ AWS CodeCommit
+ AWS CodeBuild
+ AWS CodeDeploy
+ AWS CodePipeline
**ターゲットアーキテクチャ**
![\[マイクロサービスを複数のアカウントとリージョンにデプロイするためのターゲットアーキテクチャ\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/a144c977-6823-4b08-a215-fae779b3ce7c/images/eedfabdb-f266-4190-b271-5caf7ac9b47b.png)
**自動化とスケール**
設定は、AWS CloudFormation スタックテンプレート (IaC) を使用して自動化されます。複数の環境やアカウントに合わせて簡単にスケールすることができます。
## ツール
**AWS サービス**
+ [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) を使用すると、AWS リソースをセットアップし、迅速かつ一貫したプロビジョニングを行い、AWS アカウントとリージョン全体でライフサイクル全体にわたってリソースを管理できます。
+ [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) は完全マネージド型の構築サービスです。ソースコードのコンパイル、ユニットテストの実行、すぐにデプロイできるアーティファクトの生成を行います。
+ [AWS CodeCommit](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html) は、独自のソースコントロールシステムを管理しなくても、Git リポジトリを非公開で保存および管理できるバージョン管理サービスです。
+ [AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) は、Amazon Elastic Compute Cloud (Amazon EC2) またはオンプレミスインスタンス、AWS Lambda 関数、または Amazon Elastic Container Service (Amazon ECS) サービスへのデプロイを自動化します。
+ [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) は、ソフトウェアリリースのさまざまな段階を迅速にモデル化および設定し、ソフトウェアの変更を継続的にリリースするために必要なステップを自動化するのに役立ちます。
+ 「[Amazon Elastic Container Registry (Amazon ECR)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html)」は、セキュリティ、スケーラビリティ、信頼性を備えたマネージドコンテナイメージレジストリサービスです。
+ 「[Amazon Elastic Container Service (Amazon ECS)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html)」 は、クラスターでのコンテナの実行、停止、管理を支援する、高速でスケーラブルなコンテナ管理サービスです。
+ [AWS Key Management Service (AWS KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) は、データの保護に効果的な暗号キーを作成および管理する上で役立ちます。
+ [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) は、あらゆる量のデータを保存、保護、取得できるクラウドベースのオブジェクトストレージサービスです。
その他のツール
+ 「[Git](https://git-scm.com/docs)」は、AWS CodeCommit リポジトリと連携するオープンソースの分散型バージョン管理システムです。
+ 「[Docker](https://www.docker.com/)」は、オペレーティングシステムレベルの仮想化を使用してソフトウェアをコンテナで配信するPlatform as a Service (PaaS) 製品のセットです。このパターンでは、Docker でコンテナイメージをローカルでビルドしてテストします。
+ 「[cfn-lint](https://github.com/aws-cloudformation/cfn-lint)」と「[cfn-nag](https://github.com/stelligent/cfn_nag)」は、CloudFormation スタックにエラーやセキュリティ上の問題がないかを確認することに役立つオープンソースツールです。
**コードリポジトリ**
このパターンのコードは、GitHub 内の「[複数のリージョンとアカウントのグローバルブルー/グリーンデプロイ](https://github.com/aws-samples/ecs-blue-green-global-deployment-with-multiregion-cmk-codepipeline)」リポジトリで利用できます。
## エピック
### 環境変数のセットアップ
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| CloudFormation スタックデプロイ用の環境変数を出力します。 | このパターンの後半で CloudFormation スタックへの入力として使用する環境変数を定義します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/manage-blue-green-deployments-of-microservices-to-multiple-accounts-and-regions-by-using-aws-code-services-and-aws-kms-multi-region-keys.html) | AWS DevOps |
### インフラストラクチャ用にCloudFormation スタックをパッケージしてデプロイ
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| リポジトリのクローン作成 | [「サンプルリポジトリ」](https://github.com/aws-samples/ecs-blue-green-global-deployment-with-multiregion-cmk-codepipeline)を作業場所の新しいリポジトリにクローンを作成します。##In work location
git clone https://github.com/aws-samples/ecs-blue-green-global-deployment-with-multiregion-cmk-codepipeline.git
| AWS DevOps |
| Cloudformation リソースをパッケージします。 | このステップでは、CloudFormation テンプレートが参照するローカルアーティファクトをパッケージして、Amazon Virtual Private Cloud (Amazon VPC) やApplication Load Balancer などのサービスに必要なインフラストラクチャリソースを作成します。このテンプレートはコードリポジトリの `Infra` フォルダで利用できます。##In TestAccount1##
aws cloudformation package \
--template-file mainInfraStack.yaml \
--s3-bucket $S3BUCKETNAMETESTACCOUNT1 \
--s3-prefix infraStack \
--region $TESTACCOUNT1REGION \
--output-template-file infrastructure_${TESTACCOUNT1}.template
##In TestAccount2##
aws cloudformation package \
--template-file mainInfraStack.yaml \
--s3-bucket $S3BUCKETNAMETESTACCOUNT2 \
--s3-prefix infraStack \
--region $TESTACCOUNT2REGION \
--output-template-file infrastructure_${TESTACCOUNT2}.template
##In TestAccount3##
aws cloudformation package \
--template-file mainInfraStack.yaml \
--s3-bucket $S3BUCKETNAMETESTACCOUNT3 \
--s3-prefix infraStack \
--region $TESTACCOUNT3REGION \
--output-template-file infrastructure_${TESTACCOUNT3}.template
| AWS DevOps |
| パッケージテンプレートを検証します。 | パッケージテンプレートを検証します。aws cloudformation validate-template \
--template-body file://infrastructure_${TESTACCOUNT1}.template
aws cloudformation validate-template \
--template-body file://infrastructure_${TESTACCOUNT2}.template
aws cloudformation validate-template \
--template-body file://infrastructure_${TESTACCOUNT3}.template
| AWS DevOps |
| パッケージファイルをワークロードアカウントにデプロイ | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/manage-blue-green-deployments-of-microservices-to-multiple-accounts-and-regions-by-using-aws-code-services-and-aws-kms-multi-region-keys.html) | AWS DevOps |
### サンプルイメージをプッシュして Amazon ECS をスケールします。
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| Amazon ECR リポジトリにサンプルイメージをプッシュします | (パラメータで設定されているように) `web` という Amazon Elastic Container Registry (Amazon ECR) リポジトリに、サンプル (NGINX) イメージをプッシュします。このイメージは必要に応じてカスタマイズできます。ログインして、Amazon ECR にイメージをプッシュするための認証情報を設定するには、「[Amazon ECR のドキュメント](https://docs.aws.amazon.com/AmazonECR/latest/userguide/docker-push-ecr-image.html)」の指示に従ってください。コマンドは以下のとおりです。 docker pull nginx
docker images
docker tag aws_account_id.dkr.ecr.region.amazonaws.com/:latest
docker push .dkr.ecr..amazonaws.com/:tag
| AWS DevOps |
| Amazon ECS をスケールしてアクセスを検証します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/manage-blue-green-deployments-of-microservices-to-multiple-accounts-and-regions-by-using-aws-code-services-and-aws-kms-multi-region-keys.html) | AWS DevOps |
### コードサービスとリソースを設定
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| ツール アカウントに CodeCommit リポジトリを作成します。 | GitHub リポジトリの `code` フォルダにある `codecommit.yaml` テンプレートを使用して、ツールアカウントに CodeCommit リポジトリを作成します。このリポジトリは、コードを開発する予定の 1 つのリージョンにのみ作成する必要があります。aws cloudformation deploy --stack-name codecommitrepoStack --parameter-overrides CodeCommitReponame=$CODECOMMITREPONAME \
ToolsAccount=$TOOLSACCOUNT --template-file codecommit.yaml --region $TOOLSACCOUNTREGION \
--capabilities CAPABILITY_NAMED_IAM
| AWS DevOps |
| CodePipeline によって生成されたアーティファクトを管理するための S3 バケットを作成します。 | GitHub リポジトリの `code` フォルダにある `pre-reqs-bucket.yaml` テンプレートを使用して、CodePipeline によって生成されたアーティファクトを管理するための S3 バケットを作成します。スタックは 3 つのワークロード (テスト) とツールのアカウントとリージョンにすべてデプロイする必要があります。aws cloudformation deploy --stack-name pre-reqs-artifacts-bucket --parameter-overrides BucketStartName=$BUCKETSTARTNAME \
TestAccount1=$TESTACCOUNT1 TestAccount2=$TESTACCOUNT2 \
TestAccount3=$TESTACCOUNT3 CodeCommitAccount=$CODECOMMITACCOUNT ToolsAccount=$TOOLSACCOUNT \
--template-file pre-reqs_bucket.yaml --region $TESTACCOUNT1REGION --capabilities CAPABILITY_NAMED_IAM
aws cloudformation deploy --stack-name pre-reqs-artifacts-bucket --parameter-overrides BucketStartName=$BUCKETSTARTNAME \
TestAccount1=$TESTACCOUNT1 TestAccount2=$TESTACCOUNT2 \
TestAccount3=$TESTACCOUNT3 CodeCommitAccount=$CODECOMMITACCOUNT ToolsAccount=$TOOLSACCOUNT \
--template-file pre-reqs_bucket.yaml --region $TESTACCOUNT2REGION --capabilities CAPABILITY_NAMED_IAM
aws cloudformation deploy --stack-name pre-reqs-artifacts-bucket --parameter-overrides BucketStartName=$BUCKETSTARTNAME \
TestAccount1=$TESTACCOUNT1 TestAccount2=$TESTACCOUNT2 \
TestAccount3=$TESTACCOUNT3 CodeCommitAccount=$CODECOMMITACCOUNT ToolsAccount=$TOOLSACCOUNT \
--template-file pre-reqs_bucket.yaml --region $TESTACCOUNT3REGION --capabilities CAPABILITY_NAMED_IAM
aws cloudformation deploy --stack-name pre-reqs-artifacts-bucket --parameter-overrides BucketStartName=$BUCKETSTARTNAME \
TestAccount1=$TESTACCOUNT1 TestAccount2=$TESTACCOUNT2 \
TestAccount3=$TESTACCOUNT3 CodeCommitAccount=$CODECOMMITACCOUNT ToolsAccount=$TOOLSACCOUNT \
--template-file pre-reqs_bucket.yaml --region $TOOLSACCOUNTREGION --capabilities CAPABILITY_NAMED_IAM
| AWS DevOps |
| マルチリージョン KMS キーを設定します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/manage-blue-green-deployments-of-microservices-to-multiple-accounts-and-regions-by-using-aws-code-services-and-aws-kms-multi-region-keys.html) | AWS DevOps |
| ツールアカウントで CodeBuild プロジェクトを設定します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/manage-blue-green-deployments-of-microservices-to-multiple-accounts-and-regions-by-using-aws-code-services-and-aws-kms-multi-region-keys.html) | AWS DevOps |
| ワークロードアカウントに CodeDeploy を設定します。 | GitHub リポジトリの `code` フォルダにある `codedeploy.yaml` テンプレートを使用して、3 つのワークロードアカウントにすべて CodeDeploy を設定します。`mainInfraStack` の出力には、Amazon ECS クラスターの Amazon リソースネーム (ARN) とApplication Load Balancer リスナーが含まれます。インフラストラクチャスタックの値は既に出力されているため、CodeDeploy スタックテンプレートにより入力されます。##WorkloadAccount1##
aws cloudformation deploy --stack-name ecscodedeploystack \
--parameter-overrides ToolsAccount=$TOOLSACCOUNT mainInfrastackname=mainInfrastack \
--template-file codedeploy.yaml --region $TESTACCOUNT1REGION --capabilities CAPABILITY_NAMED_IAM
##WorkloadAccount2##
aws cloudformation deploy --stack-name ecscodedeploystack \
--parameter-overrides ToolsAccount=$TOOLSACCOUNT mainInfrastackname=mainInfrastack \
--template-file codedeploy.yaml --region $TESTACCOUNT2REGION --capabilities CAPABILITY_NAMED_IAM
##WorkloadAccount3##
aws cloudformation deploy --stack-name ecscodedeploystack \
--parameter-overrides ToolsAccount=$TOOLSACCOUNT mainInfrastackname=mainInfrastack \
--template-file codedeploy.yaml --region $TESTACCOUNT3REGION --capabilities CAPABILITY_NAMED_IAM
| AWS DevOps |
### ツールアカウントで CodeBuild プロジェクトを設定
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| ツールアカウントにコードパイプラインを作成します。 | ツールアカウントで、以下のコマンドを実行します。aws cloudformation deploy --stack-name ecscodepipelinestack --parameter-overrides \
TestAccount1=$TESTACCOUNT1 TestAccount1Region=$TESTACCOUNT1REGION \
TestAccount2=$TESTACCOUNT2 TestAccount2Region=$TESTACCOUNT2REGION \
TestAccount3=$TESTACCOUNT3 TestAccount3Region=$TESTACCOUNT3REGION \
CMKARNTools=$CMKTROOLSARN CMKARN1=$CMKARN1 CMKARN2=$CMKARN2 CMKARN3=$CMKARN3 \
CodeCommitRepoName=$CODECOMMITREPONAME BucketStartName=$BUCKETSTARTNAME \
--template-file codepipeline.yaml --capabilities CAPABILITY_NAMED_IAM
| AWS DevOps |
| AWS KMS キーポリシーと S3 バケットポリシーの CodePipeline と CodeBuild ロールへのアクセスを提供します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/manage-blue-green-deployments-of-microservices-to-multiple-accounts-and-regions-by-using-aws-code-services-and-aws-kms-multi-region-keys.html) | AWS DevOps |
### パイプラインを呼び出してテスト
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| 変更を CodeCommit リポジトリにプッシュします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/manage-blue-green-deployments-of-microservices-to-multiple-accounts-and-regions-by-using-aws-code-services-and-aws-kms-multi-region-keys.html) | |
### クリーンアップ
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| デプロイされたすべてのリソースをクリーンアップします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/manage-blue-green-deployments-of-microservices-to-multiple-accounts-and-regions-by-using-aws-code-services-and-aws-kms-multi-region-keys.html) | |
## トラブルシューティング
| 問題 | ソリューション |
| --- | --- |
| リポジトリにコミットした変更はデプロイされません。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/manage-blue-green-deployments-of-microservices-to-multiple-accounts-and-regions-by-using-aws-code-services-and-aws-kms-multi-region-keys.html) |
## 関連リソース
+ 「[Docker イメージをプッシュする](https://docs.aws.amazon.com/AmazonECR/latest/userguide/docker-push-ecr-image.html)」(Amazon ECR のドキュメント)
+ 「[AWS CodeCommit リポジトリに接続する](https://docs.aws.amazon.com/codecommit/latest/userguide/how-to-connect.html)」(AWS CodeCommit のドキュメント)
+ 「[AWS CodeBuild のトラブルシューティング](https://docs.aws.amazon.com/codebuild/latest/userguide/troubleshooting.html)」(AWS CodeBuild のドキュメント)
# AWS CloudFormation と AWS Config を使用して Amazon ECR リポジトリのワイルドカード権限をモニタリングする
*Amazon Web Services、Vikrant Telkar、Wassim Benhallam、Sajid Momin*
## 概要
Amazon Web Services (AWS) クラウド上のAmazon Elastic Container Registry (Amazon ECR) は AWS Identity and Access Management (IAM) を使用したリソースベースのアクセス権限によるプライベートリポジトリをサポートするマネージドコンテナイメージレジストリサービスです。
IAM はリソース属性とアクション属性の両方で「`*`」ワイルドカードをサポートしているため、一致する複数の項目を簡単に自動的に選択できます。テスト環境では、「[リポジトリポリシーステートメント](https://docs.aws.amazon.com/AmazonECR/latest/userguide/set-repository-policy.html)」のプリンシパル要素にある `ecr:*` 「[ワイルドカードアクセス権限](https://docs.aws.amazon.com/lambda/latest/operatorguide/wildcard-permissions-iam.html)」を使用して、認証されたすべての AWS ユーザーに Amazon ECR リポジトリへのアクセスを許可できます。`ecr:*` ワイルドカードアクセス権限は、本稼働データにアクセスできない開発アカウントで開発やテストを行う場合に役立ちます。
ただし、`ecr:*` ワイルドカード権限は重大なセキュリティ上の脆弱性を引き起こす可能性があるため、本番環境では使用しないようにする必要があります。このパターンのアプローチは、`ecr:*` リポジトリポリシーステートメントにワイルドカード権限が含まれている Amazon ECR リポジトリを特定することに役立ちます。 このパターンには、AWS Config でカスタムルールを作成するためのステップと AWS CloudFormation テンプレートが含まれています。次に、AWS Lambda 関数が Amazon ECR リポジトリのポリシーステートメントを監視して、`ecr:*` ワイルドカードアクセス権限を確認します。準拠していないリポジトリポリシーステートメントが見つかると、Lambda は Amazon EventBridge にイベントを送信するよう AWS Config に通知し、EventBridge は Amazon Simple Notification Service (Amazon SNS) トピックを開始します。SNS トピックは、非準拠のリポジトリポリシーステートメントについてメールで通知します。
## 前提条件と制限事項
**前提条件**
+ アクティブなAWS アカウント
+ AWS コマンドラインインターフェイス (AWS CLI) がインストール済みおよび設定済み。詳細については、AWS CLI ドキュメントの「[AWS CLI バージョン 2 のインストール、更新、およびアンインストール](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)」を参照してください。
+ ポリシーステートメントが添付された既存の Amazon ECR リポジトリがテスト環境にインストールし、設定されています。詳細については、「Amazon ECR のドキュメント」の「[プライベートリポジトリを作成する](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-create.html)」と「[リポジトリポリシーステートメントを設定する](https://docs.aws.amazon.com/AmazonECR/latest/userguide/set-repository-policy.html)」を参照してください。
+ お好みの AWS リージョンで設定された AWS Config。詳細については、「AWS Config のドキュメント」の「[AWS Config の開始方法](https://docs.aws.amazon.com/config/latest/developerguide/getting-started.html)」を参照してください。
+ `aws-config-cloudformation.template` ファイル (添付) は、ローカルマシンにダウンロードされます。
**制限事項**
+ このパターンのソリューションはリージョナルで、リソースは、同じリージョンに作成されます。
## アーキテクチャ
次の図は、AWS Config が Amazon ECR リポジトリポリシーステートメントを評価する方法を示しています。
![\[AWS Config workflow with Lambda, Amazon ECR, EventBridge, SNS, and email notification components.\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/01bbf5f8-27aa-4c64-9a03-7fcccc0955b8/images/49bbf14b-0a18-4d4a-86ab-162d37708e01.png)
この図表は、次のワークフローを示しています:
1. AWS Config はカスタムルールを開始します。
1. カスタムルールは Lambda 関数を呼び出して Amazon ECR リポジトリポリシーステートメントのコンプライアンスを評価します。次に、Lambda 関数は非準拠のリポジトリポリシーステートメントを識別します。
1. Lambda 関数はコンプライアンス違反ステータスを AWS Config に送信します。
1. AWS Config は EventBridge にイベントを送信します。
1. EventBridge はコンプライアンス違反通知を SNS トピックに公開します。
1. Amazon SNS は、ユーザーや承認されたユーザーにメールアラートを送信します。
**自動化とスケール**
このパターンのソリューションでは、Amazon ECR リポジトリのポリシーステートメントをいくつでもモニタリングできますが、評価するリソースはすべて同じリージョンで作成されている必要があります。
## ツール
+ 「[AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)」 を使用することで、AWS リソースをセットアップし、迅速かつ一貫したプロビジョニングを行い、AWS アカウントとリージョン全体でライフサイクルの最初から最後までリソースを管理できます。リソースを個別に管理する代わりに、テンプレートを使用してリソースとその依存関係を記述し、それらをスタックとしてまとめて起動して設定できます。複数の AWS アカウントと AWS リージョンにまたがるスタックを管理およびプロビジョニングすることが可能です。
+ 「[AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html)」— AWS Config は、AWS アカウント内の AWS リソースの設定の詳細なビューを提供します。これには、リソース間の関係と設定の履歴が含まれるため、時間の経過と共に設定と関係がどのように変わるかを確認できます。
+ [Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html)** **–** **Amazon Elastic Container Registry (Amazon ECR) は、セキュリティ、スケーラビリティ、信頼性を備えたマネージドコンテナイメージレジストリサービスです。Amazon ECR は、 IAM を使用するリソースベースの許可を持つプライベートリポジトリをサポートします。
+ 「[Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html)」— Amazon EventBridgeは、アプリケーションをさまざまなソースからのデータに接続するために使用できるサーバーレスのイベントバスサービスです。EventBridge は、アプリケーション、software as a service (SaaS) アプリケーション、および AWS サービスからのリアルタイムデータのストリームを、AWS Lambda 関数、API デスティネーションを使用した HTTP 呼び出しエンドポイント、または他のアカウントのイベントバスなどのターゲットに配信します。
+ 「[AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)」 – AWS Lambda はサーバーのプロビジョニングや管理を行わずにコードの実行を支援できるコンピューティングサービスです。Lambda は必要に応じてコードを実行し、1 日あたり数個のリクエストから 1 秒あたり数千のリクエストまで自動的にスケールします。課金は実際に消費したコンピューティング時間に対してのみ発生します。コードが実行されていない場合、料金は発生しません。
+ [Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) — Amazon Simple Notification Service (Amazon SNS) は、ウェブサーバーや E メールアドレスなど、パブリッシャーとクライアント間のメッセージ配信や送信を調整および管理します。サブスクライバーは、サブスクライブしているトピックに対して発行されたすべてのメッセージを受信します。また、同じトピックのサブスクライバーはすべて同じメッセージを受信します。
**Code**
このパターンのコードは `aws-config-cloudformation.template` ファイル (添付) にあります。
## エピック
### AWS CloudFormation スタックを作成する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| AWS CloudFormation スタックを作成する | AWS CLI で次のコマンドを実行して AWS CloudFormation スタックを作成します。$ aws cloudformation create-stack --stack-name=AWSConfigECR \
--template-body file://aws-config-cloudformation.template \
--parameters ParameterKey=,ParameterValue= \
--capabilities CAPABILITY_NAMED_IAM
| AWS DevOps |
### AWS Config カスタムルールをテスト
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| AWS Config カスタムルールをテストします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/monitor-amazon-ecr-repositories-for-wildcard-permissions-using-aws-cloudformation-and-aws-config.html) | AWS DevOps |
## アタッチメント
このドキュメントに関連する追加コンテンツにアクセスするには、次のファイルを解凍してください。「[attachment.zip](samples/p-attach/01bbf5f8-27aa-4c64-9a03-7fcccc0955b8/attachments/attachment.zip)」
# AWS CDK および GitHub Actions ワークフローを使用してマルチアカウントサーバーレスデプロイを最適化する
*Amazon Web Services、Sarat Chandra Pothula、VAMSI KRISHNA SUNKAVALLI*
## 概要
サーバーレスインフラストラクチャを複数の AWS アカウント および環境にデプロイしている組織では、コードの重複、手動プロセス、一貫性のないプラクティスなどの課題に直面することがよくあります。このパターンのソリューションは、Go および GitHub Actions の再利用可能なワークフロー AWS Cloud Development Kit (AWS CDK) で を使用して、マルチアカウントのサーバーレスインフラストラクチャ管理を合理化する方法を示しています。クラウドリソースをコードとして定義する手法、標準化された継続的インテグレーション/継続的デプロイ (CI/CD) プロセスの実装法、モジュール式の再利用可能コンポーネントの作成方法を説明します。
これらの操作を行うことで、組織は複数のアカウントにまたがるリソースを効率的に管理し、一貫したデプロイパイプラインの実装と、複雑なサーバーレスアーキテクチャの簡素化を実現できます。このアプローチは、 で使用するために標準化されたプラクティスを適用することでセキュリティとコンプライアンスを強化し AWS アカウント、最終的には生産性を向上させ、サーバーレスアプリケーションの開発とデプロイのエラーを減らします。
## 前提条件と制限
**前提条件**
+ アクティブ AWS アカウント。
+ AWS Identity and Access Management デプロイプロセスには (IAM) [ロールとアクセス許可](https://docs.aws.amazon.com/AmazonECR/latest/userguide/security-iam.html)が設定されています。これには、Amazon Elastic Container Registry (Amazon ECR) リポジトリへのアクセス、 AWS Lambda 関数の作成、およびターゲット全体で必要なその他のリソースへのアクセス許可が含まれます AWS アカウント。
+ AWS Command Line Interface (AWS CLI) バージョン 2.9.11 以降、[インストール](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html)および[設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html)済み。
+ AWS Cloud Development Kit (AWS CDK) バージョン 2.114.1 以降、[インストール](https://docs.aws.amazon.com/cdk/v2/guide/getting_started.html#getting_started_install)および[ブートストラップ](https://docs.aws.amazon.com/cdk/v2/guide/getting_started.html#getting_started_bootstrap)。
+ [インストール済み](https://go.dev/doc/install)の Go 1.22 以降。
+ [インストール済み](https://docs.docker.com/engine/install/)の Docker 24.0.6 以降。
**制限事項**
+ **言語の互換性 **– Go はサーバーレスアプリケーションの一般的言語です。ただし、Go に加えて、 は C\$1、Java、Python、TypeScript などの他のプログラミング言語 AWS CDK をサポートしています。他の言語に対する既存コードベースや専門知識を組織が有している場合でも、本パターンで説明するソリューションを最大限に活用するためには Go を導入し、学習していくことが推奨されます。
+ **学習曲線 **– Go (組織を初めて使用する場合) AWS CDK、GitHub の再利用可能なワークフローを採用すると、デベロッパーと DevOps チーム向けの学習曲線が必要になる場合があります。テクノロジーの円滑な導入と効果的な使用を実現するためには、研修の実施や資料作成が必要になる場合があります。
## アーキテクチャ
次の図表は、このパターンのアプリケーションのワークフローとアーキテクチャコンポーネントを示しています。
![\[マルチアカウントサーバーレスインフラストラクチャ管理のための AWS CDK および GitHub Actions ワークフローのアーキテクチャ。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/8d61917b-bd27-44fa-ae95-55358aaf8812/images/a4b36793-95c7-42f7-a92f-99b4722c9c64.png)
このソリューションでは、以下のステップを実行します。
1. 開発者がリポジトリのクローンを元に新しいブランチを作成し、ローカル環境でアプリケーションコードを変更します。
1. 開発者がこれらの変更を確定し、新たなブランチを GitHub リポジトリにプッシュします。
1. 開発者が GitHub リポジトリにプルリクエストを作成し、機能および新機能ブランチのメインブランチへのマージを提案します。
1. このプルリクエストは、継続的インテグレーション (CI) の GitHub Actions ワークフローをトリガーします。このパターンの CI と継続的デプロイ (CD) ワークフローは、再利用可能なワークフローを使用します。再利用可能なワークフローは、さまざまなプロジェクトまたはリポジトリ間で共有および実行できる、事前定義されたモジュール式のテンプレートです。再利用可能なワークフローを使用すると、CI/CD プロセスを標準化し、効率を向上させることができます。
1. CI ワークフローが必要な環境を設定し、イメージの Docker タグを生成して、アプリケーションコードで Docker イメージを構築します。
1. CI ワークフローは central AWS アカウント GitHub OIDC ロールを使用して AWS で認証します。CI ワークフローの場合、 central AWS アカウント GitHub OIDC ロールは AWS Security Token Service (AWS STS) を使用して一時的な認証情報を取得します。これらの認証情報により、ロールは Docker イメージを構築して中央の Amazon ECR リポジトリにプッシュできます AWS アカウント。
1. CI ワークフローは、ビルドされた Docker イメージを Amazon ECR にプッシュします。
1. CI ワークフローは、イメージタグを Systems Manager Parameter Store に保存します。
1. CI ワークフローが正常に完了すると、Docker イメージタグが出力されます。
1. CD ワークフローをトリガーする際、開発者はデプロイする Docker イメージのイメージタグを手動で入力します。このイメージタグは、CI ワークフロー中に生成され Amazon ECR にプッシュされたタグに対応します。
1. 開発者は、CD 再利用可能なワークフローを使用する CD ワークフローを手動でトリガーします。
1. CD ワークフローは central AWS アカウント GitHub OIDC ロール AWS を使用して で認証します。CD ワークフローの場合、 AWS STS 最初に central AWS アカウント GitHub OIDC ロールを引き受けるために使用されます。次に、このロールはターゲットアカウントのデプロイの CDK ブートストラップロールを引き受けます。
1. CD ワークフローは、 を使用して AWS CloudFormation テンプレート AWS CDK を合成します。
1. CD ワークフローは、Lambda 関数に手動で指定されたイメージタグ AWS アカウント を使用して、CDK デプロイを使用してアプリケーションをターゲットにデプロイします。
## ツール
**AWS のサービス**
+ [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/latest/guide/home.html) は、コードで AWS クラウド インフラストラクチャを定義およびプロビジョニングするのに役立つソフトウェア開発フレームワークです。
+ [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) は、 AWS リソースをセットアップし、迅速かつ一貫してプロビジョニングし、 AWS アカウント および 全体のライフサイクルを通じてリソースを管理するのに役立ちます AWS リージョン。CloudFormation は AWS CDK デプロイプロセスの不可欠な部分です。CDK は CloudFormation テンプレートを合成し、CloudFormation を使用して AWS 環境内のリソースを作成または更新します。
+ [Amazon Elastic Container Registry (Amazon ECR)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html) は、セキュリティ、スケーラビリティ、信頼性を備えたマネージドコンテナイメージレジストリサービスです。
+ [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、誰を認証し、誰に使用する権限を付与するかを制御することで、 AWS リソースへのアクセスを安全に管理するのに役立ちます。
+ [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。
+ [AWS Systems Manager Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html) は、設定データ管理とシークレット管理のための安全な階層型ストレージを提供します。
**その他のツール**
+ [Docker](https://www.docker.com/) は、オペレーティングシステムレベルの仮想化を使用してソフトウェアをコンテナで配信するサービスとしての Platform as a Service (PaaS) 製品のセットです。
+ [GitHub Actions](https://docs.github.com/en/actions/writing-workflows/quickstart) は、GitHub リポジトリと緊密に統合された継続的インテグレーションおよび継続的デリバリー (CI/CD) プラットフォームです。GitHub Actions を使用して、生成、テスト、デプロイのパイプラインを自動化できます。
+ [Go](https://go.dev/doc/install) は、Google がサポートするオープンソースのプログラミング言語です。
**コードリポジトリ**
このパターンのコードは、GitHub の [aws-cdk-golang-serverless-cicd-github-actions](https://github.com/aws-samples/aws-cdk-golang-serverless-cicd-github-actions) リポジトリから入手できます。
## ベストプラクティス
+ **モジュラー設計** – AWS CDK コードをモジュール式で再利用可能なコンストラクトまたはスタックに整理し、複数のアカウントやプロジェクトでコードの再利用と保守性を促進します。
+ **懸念事項の分離** – インフラストラクチャコードをアプリケーションコードから分離すれば、各コンポーネントの独立したデプロイと管理が可能になります。
+ **バージョニングとイミュータビリティ** – Infrastructure as Code (IaC) を処理し、バージョン管理に Git を使用します。既存のリソースを変更するのではなく、新しいリソースを作成すれば、堅牢なインフラストラクチャを築くことができます。
+ **テストと検証** – ユニットテスト、統合テスト、end-to-endテストなどの包括的なテスト戦略を実装して、 AWS CDK コードとデプロイの正確性と信頼性をサポートします。
+ **セキュリティとコンプライアンス** – 最小特権アクセス、安全な通信、データ暗号化などの AWS セキュリティのベストプラクティスに従います。コンプライアンスチェックと監査メカニズムを実装して、組織のポリシーと規制要件に準拠していることを確認します。脆弱性のスキャン、イメージ署名の強制、組織のコンプライアンス要件の遵守など、コンテナイメージのセキュリティのベストプラクティスを実装します。
+ **モニタリングとログ記録** – サーバーレスアプリケーションとインフラストラクチャの健全性やパフォーマンスを追跡するためのモニタリングとログ記録メカニズムを設定します。Amazon CloudWatch AWS のサービス と同様に を使用し AWS CloudTrail、モニタリングと監査 AWS X-Ray の目的で使用します。
+ **自動化と CI/CD** – GitHub の再利用可能なワークフローやその他の CI/CD ツールを使用して、ビルド、テスト、デプロイのプロセスを自動化します。この作業は、複数のアカウント間で、一貫性のある反復可能なデプロイを実行するのに役立ちます。
+ **環境管理** – 個別の環境 (開発、ステージング、本番環境など) の保守を行います。環境間の変更を促進する戦略を実装し、本番環境のデプロイ前に適切なテストと検証を行います。
+ **ドキュメントとコラボレーション** – インフラストラクチャコード、デプロイプロセス、ベストプラクティスを文書化して、チーム内での知識の共有とコラボレーションを促進します。
+ **コスト最適化** – リソースの適正化、自動スケーリングの使用、 や などのコスト最適化サービスの利用など、 AWS コストのモニタリングと最適化戦略を実装 AWS Budgets します AWS Cost Explorer。
+ **ディザスタリカバリとバックアップ** – サーバーレスアプリケーションとインフラストラクチャリソースのバックアップと復元メカニズムを実装することで、ディザスタリカバリシナリオを計画します。
+ **継続的な改善** — サーバーレスエコシステムにおける最新のベストプラクティス、セキュリティ上の推奨事項、技術面での進歩に合わせて、定期的に見直しを行い、プラクティス、ツール、プロセスを更新します。
+ **セキュリティ体制の改善** – を使用して[AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html)、Amazon ECR のインターフェイス VPC エンドポイント、および AWS Systems Manager Parameter Store を設定することで AWS Lambda、仮想プライベートクラウド (VPC) のセキュリティ体制を改善します。
## エピック
### 環境設定
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| 中央で Amazon ECR リポジトリを作成します AWS アカウント。 | 複数の 間でコンテナイメージを共有するには AWS アカウント、Amazon ECR のクロスアカウントアクセスを設定する必要があります。まず、中央で Amazon ECR リポジトリを作成します AWS アカウント。Amazon ECR レポジトリを作成するには、次のコマンドを実行します。aws ecr create-repository --repository-name sample-repo
後のタスクでは、コンテナイメージを使用する AWS アカウント 必要がある他の にプルアクセスを許可します。 | AWS DevOps |
| Amazon ECR リポジトリにクロスアカウントアクセス許可を追加します。 | 中央の Amazon ECR リポジトリにクロスアカウントアクセス許可を追加するには AWS アカウント、次のコードを実行します。{
"Version": "2008-10-17",
"Statement": [
{
"Sid": "LambdaECRImageRetrievalPolicy",
"Effect": "Allow",
"Principal": {
"Service": "lambda.amazonaws.com"
},
"Action": [
"ecr:BatchGetImage",
"ecr:GetDownloadUrlForLayer",
],
"Condition": {
"StringLike": {
"aws:sourceArn": "arn:aws:lambda:::function:*"
}
}
},
{
"Sid": "new statement",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam:::root"
},
"Action": [
"ecr:BatchGetImage",
"ecr:GetDownloadUrlForLayer",
],
}
]
} | AWS DevOps |
| 中央で GitHub OIDC ロールのロールを設定します AWS アカウント。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/optimize-multi-account-serverless-deployments.html) | AWS DevOps |
| ターゲットで AWS 環境をブートストラップします AWS アカウント。 | 中央アカウントからのクロスアカウントデプロイを有効に AWS アカウント AWS リージョン し、最小特権の原則を CloudFormation 実行ロールに適用する特定の および で CDK 環境を設定します。 AWS 環境を[ブートストラップ](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html)するには、次のコマンドを実行します。cdk bootstrap aws:/// --trust --cloudformation-execution-policies arn:aws:iam::aws:policy/
| AWS DevOps |
| ターゲット AWS アカウント ブートストラップロールへのアクセス権を中央 AWS アカウント OIDC ロールに付与します。 | CDK ブートストラップは、CDK デプロイプロセスの AWS アカウント さまざまな段階で中央 が引き受けるように設計された次の IAM ロールを作成します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/optimize-multi-account-serverless-deployments.html)各ロールは、最小特権の原則に従って、目的に合わせた特定のアクセス権限が付与されています。`Target_Region` 各ロール名の `Target_Account_ID`と は、これらのロールが異なる AWS アカウント およびリージョン間で一意であることを示すのに役立ちます。このアプローチは、マルチアカウント、マルチリージョンのセットアップで明確な識別と管理に役立ちます。Target Account CDK Bootstrap Roles
arn:aws:iam:::role/cdk-deploy-role--
arn:aws:iam:::role/cdk-file-publishing-role--
arn:aws:iam:::role/cdk-image-publishing-role--
arn:aws:iam:::role/cdk-lookup-role--
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/optimize-multi-account-serverless-deployments.html)中央の OIDC ロールのアクセス許可ポリシーを更新するには AWS アカウント、次のコードを使用します。{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": [
"arn:aws:iam:::role/cdk-deploy-role--",
"arn:aws:iam:::role/cdk-file-publishing-role--",
"arn:aws:iam:::role/cdk-image-publishing-role--",
"arn:aws:iam:::role/cdk-lookup-role--"
]
}
]
}
| AWS DevOps |
### Docker イメージを作成します。
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| プロジェクトリポジトリのクローンを作成します。 | 以下のコマンドを実行して、このパターンの [GitHub リポジトリ](https://github.com/aws-samples/aws-cdk-golang-serverless-cicd-github-actions)のクローンを作成します。git clone https://github.com/aws-samples/aws-cdk-golang-serverless-cicd-github-actions.git
| AWS DevOps |
| Dockerfile パスに移動します。 | Dockerfile パスに移動するには、次のコマンドを実行します。cd lambda
| AWS DevOps |
| Amazon ECR で Docker を認証します。 | Amazon ECR には、プライベートコンテナリポジトリへの安全なアクセスが必要になります。この方法でサインインすると、ローカルマシンまたは CI/CD 環境で Docker が Amazon ECR と安全にやり取りできるようになります。Amazon ECR で Docker を認証するには、次のコマンドを実行します。aws ecr get-login-password --region | docker login --username AWS --password-stdin .dkr.ecr..amazonaws.com
プレースホルダー `AWS_REGION` および `AWS_Account_ID` を自分の情報に置き換えます。 | AWS DevOps |
| Docker イメージを作成します。 | Docker イメージを作成するには、次のコマンドを実行します。docker build --platform linux/arm64 -t sample-app .
| AWS DevOps |
| Docker イメージをタグ付けし、プッシュします。 | 次のコマンドを実行して、Docker イメージを Amazon ECR リポジトリにタグ付けしてプッシュします。docker tag sample-app:latest .dkr.ecr..amazonaws.com/:
docker push .dkr.ecr..amazonaws.com/:
プレースホルダー `AWS_Account_ID`、`AWS_REGION`、`ECR_REPOSITORY`、`DOCKER_TAG` を自分の情報に置き換えます。 | AWS DevOps |
### AWS CDK アプリをデプロイする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| CDK スタックを環境固有の変数で合成します。 | CDK コードで定義されているインフラストラクチャの CloudFormation テンプレートを生成するには、次のコマンドを実行します。ENV= IMAGETAG= ECR_ARN= cdk synth
以下のプレースホルダーを自分の情報に置き換えます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/optimize-multi-account-serverless-deployments.html) | AWS DevOps |
| CDK スタックをデプロイします。 | CDK スタックを にデプロイするには AWS アカウント、次のコマンドを実行します。`--require-approval never` フラグは、CDK が*すべての*変更を自動的に承認して実行することを意味します。これには、CDK が通常手動レビューを必要とするものとしてフラグを付ける変更 (IAM ポリシーの変更やリソースの削除など) が含まれます。本番環境で `--require-approval never` フラグを使用する前に、CDK コードと CI/CD パイプラインが十分にテストされ、安全であることを確認してください。ENV= IMAGETAG= ECR_ARN= cdk deploy --require-approval never
| AWS DevOps |
### GitHub Actions ワークフローを使用して CI/CD を自動化する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| 機能ブランチを作成し、変更を追加します。 | 事前に作成したリポジトリのクローンを使用して機能ブランチを作成し、アプリケーションコードに変更を追加します。次のコマンドを使用します。git checkout -b
git add .
git commit -m "add your changes"
git push origin
変更の例を次に示します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/optimize-multi-account-serverless-deployments.html)GitHub Actions は再利用可能なワークフローを使用し、CI/CD パイプラインをトリガーします。 | AWS DevOps |
| 変更をマージします。 | プルリクエストを作成し、変更点を本文とマージします。 | AWS DevOps |
## トラブルシューティング
| 問題 | ソリューション |
| --- | --- |
| `AccessDenied` リソースを にデプロイする際のエラー。 AWS アカウントたとえば、 です`AccessDenied: User not authorized to perform: "sts:AssumeRole"`。 | この問題を解決するには、以下を実行してクロスアカウントのアクセス権を確認してください。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/optimize-multi-account-serverless-deployments.html) |
| 旧バージョン CDK の `undefined: awscdkStack` エラーなど、バージョンの不一致による互換性の問題。 | この問題を解決するには、以下を実行して、 AWS CDK と Go の必要なバージョンを使用していることを確認します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/optimize-multi-account-serverless-deployments.html) |
| CI/CD パイプラインの失敗や、YAML の設定不備による `Error: No such file or directory`、あるいはブランチが防がれたことによる `Permission denied` などが例として挙げられます。 | GitHub Actions 設定の問題を解決するには、再利用可能なワークフローが正しく参照・設定されていることを確認してください。 |
## 関連リソース
「**AWS リソース**」
+ [AWS セキュリティ、アイデンティティ、コンプライアンスのベストプラクティス](https://aws.amazon.com/architecture/security-identity-compliance/)
+ [AWS CDK ワークショップ](https://cdkworkshop.com/60-go.html)
+ [AWS クラウド開発キットライブラリ](https://pkg.go.dev/github.com/aws/aws-cdk-go/awscdk/v2)
+ [コンテナイメージを使用した Lambda 関数の作成](https://docs.aws.amazon.com/lambda/latest/dg/images-create.html)
+ [Amazon Elastic Container Registry の Identity and Access Management](https://docs.aws.amazon.com/AmazonECR/latest/userguide/security-iam.html)
+ [Working with the AWS CDK in Go](https://docs.aws.amazon.com/cdk/v2/guide/work-with-cdk-go.html)
**その他のリソース**
+ [Configuring OpenID Connect in Amazon Web Services](https://docs.github.com/en/actions/security-for-github-actions/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services) (GitHub ドキュメント)
+ [Go 言語ドキュメント](https://golang.org/doc/)
+ [Quickstart for GitHub Actions](https://docs.github.com/en/actions/writing-workflows/quickstart) (GitHub ドキュメント)
+ [Reusing workflows](https://docs.github.com/en/actions/sharing-automations/reusing-workflows) (GitHub ドキュメント)
# GitHub Actions を使用して AWS CloudFormation テンプレートに基づいて AWS Service Catalog 製品をプロビジョニングする
*Amazon Web Services、Ashish Bhatt、Ruchika Modi*
## 概要
このパターンは、[AWS Service Catalog](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/introduction.html)製品とポートフォリオを使用して標準化され、チーム AWS のサービス 間で準拠したプロビジョニングを行う効率的なアプローチを組織に提供します。 は、Service Catalog 製品とポートフォリオの重要なコンポーネントを組み合わせて、ベースネットワークインフラストラクチャをプロビジョニングする[AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)のに役立ちます AWS クラウド。このパターンは、[GitHub Actions](https://github.com/features/actions) を使用して Infrastructure as Code (IaC) を自動開発ワークフローに統合することで、DevOps プラクティスも促進します。
AWS Service Catalog を使用すると、組織は で承認された IT サービスを作成および管理でき AWS、標準化、一元管理、セルフサービスプロビジョニング、コスト管理などのメリットが得られます。GitHub Actions を通じて Service Catalog ポートフォリオと製品のデプロイを自動化することで、組織は以下を実行できます。
+ 一貫性のある反復可能なデプロイ。
+ IaC のバージョン管理。
+ クラウドリソース管理の既存の開発ワークフローとの統合。
この組み合わせにより、手動エラーを減らし、全体的な効率を向上させながら、クラウド運用を合理化し、コンプライアンスを強制し、承認されたサービスの配信を高速化できます。
## 前提条件と制限事項
**前提条件**
+ アクティブな AWS アカウント
+ [GitHub リポジトリ](https://docs.github.com/en/get-started/quickstart/create-a-repo)へのアクセス権
+ AWS CloudFormation と の基本的な理解 AWS Service Catalog
+ CloudFormation テンプレートをホストするための Amazon Simple Storage Service (Amazon S3) バケット
+ GitHub と 間の接続に使用される という名前`github-actions`の AWS Identity and Access Management (IAM) ロール AWS
**制限事項**
+ このパターンの再利用可能なコードは、GitHub Actions でのみテストされています。
+ 一部の 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)」を参照して、サービスのリンクを選択してください。
**製品バージョン**
このパターンのソリューションは、次の [GitHub Marketplace](https://github.com/marketplace) アクションとそれぞれのバージョンを使用して作成されました。
+ `actions/checkout@v4`
+ `aws-actions/configure-aws-credentials@v2`
+ `aws-actions/aws-cloudformation-github-deploy@v1.2.0`
## アーキテクチャ
このソリューション用のアーキテクチャを次の図に示します。
![\[GitHub Actions を使用して、CloudFormation テンプレートに基づいて Service Catalog 製品をプロビジョニングします。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/49f82fa7-0c74-4581-bf92-95505dca264c/images/a13c7b41-534e-4a9e-bdca-2974fa40a49a.png)
1. 管理者またはプラットフォームエンジニアは、標準化された CloudFormation テンプレートを GitHub リポジトリにプッシュし、そこでテンプレートが維持されます。GitHub リポジトリには、GitHub Actions AWS Service Catalog を使用した のプロビジョニングを自動化するワークフローも含まれています。
1. GitHub Actions は、OpenID Connect (OIDC) プロバイダー AWS クラウド を使用して に接続し、Service Catalog をプロビジョニングするワークフローをトリガーします。
1. Service Catalog には、開発者が標準化された AWS リソースのプロビジョニングに直接使用できるポートフォリオと製品が含まれています。このパターンは、仮想プライベートクラウド (VPCs)、サブネット、NAT およびインターネットゲートウェイ、ルートテーブルなどの AWS リソースをバンドルします。
1. 開発者が Service Catalog 製品を作成すると、Service Catalog はそれを事前設定および標準化された AWS リソースに変換します。その結果、開発者は個々のリソースをプロビジョニングして手動で設定する必要がなくなるため、時間を節約できます。
## ツール
**AWS のサービス**
+ [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) は、 AWS リソースをセットアップし、迅速かつ一貫してプロビジョニングし、 AWS アカウント および 全体のライフサイクルを通じてリソースを管理するのに役立ちます AWS リージョン。これは、 製品タイプの 1 つとして簡単に使用できるコードとしてのインフラストラクチャ (IaC) サービスです AWS Service Catalog。
+ [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、誰を認証し、誰に使用を許可するかを制御することで、 AWS リソースへのアクセスを安全に管理するのに役立ちます。
+ [AWS Service Catalog](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/getstarted.html) では、承認された IT サービスのカタログを一元管理できます AWS。エンドユーザーは、組織によって設定された制約に従って、必要な承認済みの IT サービスのみをすばやくデプロイできます。
+ [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) は、あらゆる量のデータを保存、保護、取得できるクラウドベースのオブジェクトストレージサービスです。
**その他**
+ [GitHub Actions](https://docs.github.com/en/actions) は、GitHub リポジトリと緊密に統合された継続的インテグレーションおよび継続的デリバリー (CI/CD) プラットフォームです。GitHub アクションを使用することで、生成、テスト、デプロイのパイプラインを自動化できます。
**コードリポジトリ**
このパターンのコードは、GitHub 内の [service-catalog-with-github-actions](https://github.com/aws-samples/service-catalog-with-github-actions) リポジトリから取得できます。リポジトリには、以下のファイルが含まれます。
+ `github/workflows`:
+ `e2e-test.yaml` – このファイルは[再利用可能なワークフロー](https://docs.github.com/en/actions/sharing-automations/reusing-workflows)である `workflow.yaml` を呼び出します。このワークフローは、ブランチにコミットとプッシュがあるとすぐにトリガーされます。
+ `workflow.yaml` – このファイルには、このソリューションの再利用可能なワークフローが含まれており、トリガーとして `workflow_call` が設定されています。再利用可能なワークフローとして、`workflow.yaml` は他のワークフローから呼び出すことができます。
+ `templates`:
+ `servicecatalog-portfolio.yaml` – この CloudFormation テンプレートには、Service Catalog ポートフォリオと Service Catalog 製品をプロビジョニングするリソースが含まれています。テンプレートには、Service Catalog ポートフォリオと製品のプロビジョニング中に使用される一連のパラメータが含まれています。1 つのパラメータは、テンプレートの `vpc.yaml` がアップロードされる Amazon S3 ファイル URL を受け入れます。このパターンには AWS リソースをプロビジョニングする `vpc.yaml` ファイルが含まれていますが、設定に パラメータ S3 ファイル URL を使用することもできます。
+ `vpc.yaml` – この CloudFormation テンプレートには、Service Catalog product に追加される AWS リソースが含まれています。 AWS リソースには、VPCs、サブネット、インターネットゲートウェイ、NAT ゲートウェイ、ルートテーブルが含まれます。`vpc.yaml` テンプレートは、Service Catalog 製品およびポートフォリオテンプレートで CloudFormation テンプレートを使用する方法の例です。
## ベストプラクティス
+ AWS Service Catalog ドキュメントの[「 のセキュリティのベストプラクティス AWS Service Catalog](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/security-best-practices.html)」を参照してください。
+ GitHub ドキュメントの「[Security hardening for GitHub Actions](https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions)」をご確認ください。
## エピック
### ローカルワークステーションのセットアップ
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| ローカルワークステーションに Git をセットアップします。 | Git ドキュメントの「[Getting Started – Installing Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)」に記載の手順に従って、ローカルワークステーションへ Git をインストールし、設定します。 | アプリ開発者 |
| GitHub プロジェクトリポジトリのクローンを作成します。 | GitHub プロジェクトリポジトリのクローンを作成するには、以下を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/provision-aws-service-catalog-products-using-github-actions.html) | DevOps エンジニア |
### OIDC プロバイダーをセットアップする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| OIDC プロバイダーを設定します。 | AWS 認証情報を存続期間の長い GitHub シークレットとして保存することなく AWS、GitHub Actions ワークフローがリソースにアクセスできるようにする OpenID Connect (OIDC) GitHub プロバイダーを作成します。手順について、詳しくは GitHub ドキュメントの「[Amazon Web Services での OpenID Connect の構成](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services)」をご確認ください。OIDC プロバイダーが設定されると、[前提条件](#provision-aws-service-catalog-products-using-github-actions-prereqs)で前述した IAM ロール `github-actions` の信頼ポリシーが更新されます。 | AWS 管理者、AWS DevOps、AWS 全般 |
### GitHub Actions パイプラインをトリガーして Service Catalog ポートフォリオと製品をデプロイする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| `e2e-test.yaml` を更新する。 | この `e2e-test.yaml` ファイルは、`workflow.yaml` で再利用可能なワークフローをトリガーします。`e2e-test.yaml` で次の入力パラメータの値を更新して検証します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/provision-aws-service-catalog-products-using-github-actions.html) | DevOps エンジニア |
### デプロイを検証する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| Service Catalog リソースを検証します。 | Service Catalog リソースを検証するには、以下を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/provision-aws-service-catalog-products-using-github-actions.html) | AWS DevOps |
### リソースをクリーンアップする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| CloudFormation スタックを削除します。 | 以下の操作を行い CloudFormation スタックを削除します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/provision-aws-service-catalog-products-using-github-actions.html)詳細については、CloudFormation ドキュメントの「[CloudFormation コンソールからスタックを削除する](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-delete-stack.html)」をご確認ください。 | DevOps エンジニア、AWS 管理者 |
## トラブルシューティング
| 問題 | ソリューション |
| --- | --- |
| `e2e-test``Can't find 'action.yml', 'action.yaml' or 'Dockerfile' under '*/home/runner/work/service-catalog-with-github-actions/service-catalog-with-github-actions``Did you forget to run actions/checkout before running your local action?` | 正しいリポジトリ設定が有効になっていることを確認するには、以下を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/provision-aws-service-catalog-products-using-github-actions.html) |
## 関連リソース
**AWS ドキュメント**
+ [Service Catalog の概要](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/what-is_concepts.html)
**その他のリソース**
+ [About events that trigger workflows](https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#about-events-that-trigger-workflows) (GitHub ドキュメント)
+ [Reuse workflows](https://docs.github.com/en/actions/sharing-automations/reusing-workflows) (GitHub ドキュメント)
## 追加情報
[エピック](#provision-aws-service-catalog-products-using-github-actions-epics)に関連するスクリーンショットを表示するには、このパターンの GitHub リポジトリの **[Images]** フォルダに移動してください。次のスクリーンショットを使用できます。
+ [AWS Service Catalog ポートフォリオ、管理セクション](https://github.com/aws-samples/service-catalog-with-github-actions/blob/main/images/SC_portfolio.png)
+ [AWS Service Catalog product、Administration セクション](https://github.com/aws-samples/service-catalog-with-github-actions/blob/main/images/SC_Product.png)
+ [AWS Service Catalog product、ユーザー/プロビジョニングセクション](https://github.com/aws-samples/service-catalog-with-github-actions/blob/main/images/SC_Product_User.png)
# ロールベンディングマシンソリューションをデプロイして最小特権の IAM ロールをプロビジョニングする
*Benjamin Morris、Nima Fotouhi、Aman Kaur Gandhi、および Chad Moon、Amazon Web Services*
## 概要
パイプラインのスコープを超える AWS Identity and Access Management (IAM) ロールのアクセス許可は、組織に不要なリスクをもたらす可能性があります。開発者は、開発中に広範なアクセス許可を付与することがありますが、コードのトラブルシューティング後にアクセス許可の範囲を絞り込むことを忘れることがあります。これにより、ビジネスニーズのない強力なロールが存在し、セキュリティエンジニアによってレビューされていない可能性がある問題が発生します。
このパターンの場合、問題の解決策としてロールベンディングマシン (RVM) があります。RVM は、一元化された安全なデプロイモデルを使用して、開発者の労力を最小限に抑えながら、個々の GitHub リポジトリのパイプラインに対して最小特権の IAM ロールをプロビジョニングする方法を示します。RVM は中央ソリューションであるため、セキュリティチームを変更の承認に必要なレビューアーとして設定できます。このアプローチにより、セキュリティチームは過剰な権限のパイプラインロールリクエストを拒否できます。
RVM は Terraform コードを入力として受け取り、パイプライン対応の IAM ロールを出力として生成します。必要な入力は、 AWS アカウント ID、GitHub リポジトリ名、およびアクセス許可ポリシーです。RVM はこれらの入力を使用して、ロールの信頼ポリシーとアクセス許可ポリシーを作成します。結果として得られる信頼ポリシーにより、指定された GitHub リポジトリがロールを引き受け、パイプラインオペレーションに使用できます。
RVM は IAM ロール (ブートストラップ中に設定) を使用します。このロールには、組織内の各アカウントで role-provisioning-role を引き受けるアクセス許可があります。ロールは、 AWS Control Tower Account Factory for Terraform (AFT) または AWS CloudFormation StackSets を介して設定されます。role-provisioning-roles は、開発者向けのパイプラインロールを実際に作成するロールです。
## 前提条件と制限事項
**前提条件**
+ アクティブ AWS アカウント。
+ GitHub Actions を通じて Infrastructure as Code (IaC) をデプロイするために使用される GitHub 組織。(GitHub Enterprise/Premium/Ultimate は必要*ありません*** **。)
+ マルチアカウント AWS 環境。この環境の一部である必要はありません AWS Organizations。
+ all AWS アカウント (AFT や CloudFormation StackSets など) に IAM ロールをデプロイするメカニズム。
+ Terraform バージョン 1.3 以降が[インストールされ、設定されている](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli)。
+ Terraform AWS Provider バージョン 4 以降[がインストールされ](https://github.com/hashicorp/terraform-provider-aws/releases)、[設定されています](https://developer.hashicorp.com/terraform/language/providers/configuration)。
**制限事項**
+ このパターンのコードは GitHub Actions と Terraform に固有のものです。ただし、パターンの一般的な概念は、他の継続的インテグレーションおよびデリバリー (CI/CD) フレームワークで再利用できます。
+ 一部の 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)」を参照して、サービスのリンクを選択してください。
## アーキテクチャ
次の図は、このパターンのワークフローを図解したものです。
![\[GitHub Actions を使用して IAM ロールの作成とデプロイを自動化するワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/215c590e-0c84-411d-be6e-b1739f1e19d2/images/82fcdc9f-9576-4e7c-b7fe-b45046ba79d2.png)
ロールベンディングマシンは、一般的に以下のステップで使用されます。
1. 開発者は、新しくリクエストされた IAM ロールの Terraform コードを含むコードを RVM GitHub リポジトリにプッシュします。このアクションは、RVM GitHub Actions パイプラインをトリガーします。
1. パイプラインは、OpenID Connect (OIDC) 信頼ポリシーを使用して RVM ロール引き受けロールを引き受けます。
1. RVM パイプラインは実行されると、開発者の新しい IAM ロールをプロビジョニングするアカウントの RVM ワークフローロールを引き受けます。(RVM ワークフローロールは、AFT または CloudFormation StackSets を使用してプロビジョンされました。)
1. RVM は、適切なアクセス許可と信頼を持つ開発者の IAM ロールを作成し、そのロールを他のアプリケーションパイプラインが引き受けられるようにします。
1. アプリ開発者は、この RVM がプロビジョニングしたロールを引き受けるようにアプリパイプラインを設定できます。
作成されたロールには、開発者がリクエストしたアクセス許可と`ReadOnlyAccess` ポリシーが含まれます。ロールを引き受けられるのは、開発者が指定したリポジトリの `main` ブランチに対して実行されるパイプラインだけです。このアプローチで、ロールを使用するためにブランチの保護とレビューを要求できます。
**自動化とスケール**
最小特権のアクセス許可では、プロビジョニングされる各ロールの詳細に注意する必要があります。このモデルにより、これらのロールの作成に必要となる複雑さが軽減され、開発者は追加の学習や多大な労力をかけることなく、必要なロールを作成できます。
## ツール
**AWS のサービス**
+ [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、誰を認証し、誰に使用する権限を付与するかを制御することで、 AWS リソースへのアクセスを安全に管理するのに役立ちます。
+ [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html) は、作成して一元管理する AWS アカウント 組織に複数の を統合するのに役立つアカウント管理サービスです。
**その他のツール**
+ [Git](https://git-scm.com/docs) はオープンソースの分散バージョンの管理システムです。これには、[組織アカウント](https://docs.github.com/en/get-started/learning-about-github/types-of-github-accounts#organization-accounts)を作成する機能が含まれます。
+ [GitHub Actions](https://docs.github.com/en/actions/writing-workflows/quickstart) は、GitHub リポジトリと密接に統合された継続的インテグレーションおよび継続的デリバリー (CI/CD) プラットフォームです。GitHub Actions を使用して、ビルド、テスト、デプロイパイプラインを自動化できます。
+ 「[Terraform](https://www.terraform.io/)」は、HashiCorp の infrastructure as code (IaC) ツールで、クラウドとオンプレミスのリソースの作成と管理を支援します。
**コードリポジトリ**
このパターンのコードは、GitHub 内の [role-vending-machine](https://github.com/aws-samples/role-vending-machine) リポジトリで利用できます。
## ベストプラクティス
+ **正しい方法は簡単に、間違った方法は難しく** – 正しい方法を簡単に行えるようにします。開発者が RVM プロビジョニングプロセスに苦戦しているときに、他の方法でロールを作成しようとする可能性があります。その場合、RVM の中心的な性質が損なわれます。セキュリティチームが RVM を安全かつ効果的に使用する方法について明確なガイダンスを提供していることを確認します。
また、開発者が間違った方法で作業するのが難しくなるようにする必要があります。サービスコントロールポリシー (SCPs) またはアクセス許可の境界を使用して、他のロールを作成できるロールを制限します。このアプローチによって、ロールの作成を RVM やその他の信頼できるソースのみに制限できます。
+ **良い例を提供する** – 一部の開発者は、必然的に非公式テンプレートとして RVM リポジトリ内の既存のロールを適応させ、新しいロールにアクセス許可を付与するようになります。コピー可能な最小限のアクセス許可の例がある場合は、それを提供して、開発者が広範でワイルドカードの多いアクセス許可をリクエストするリスクを軽減できるようにします。多数のワイルドカードを持つアクセス許可の多いロールから開始すると、時間の経過とともにその問題が増大する可能性があります。
+ **命名規則と条件を使用する** – 開発者がアプリケーションで作成されるすべてのリソース名を知らなくても、命名規則を使用してロールのアクセス許可を制限する必要があります。例えば、Amazon S3 バケットを作成する場合、リソースキーの値は `arn:aws:s3:::myorg-myapp-dev-*` のようになります。これにより、ロールはその名前に一致するバケット以外のアクセス許可を持たなくなります。IAM ポリシーを使用して命名規則を適用すると、命名規則への準拠が向上するという別の利点があります。これは、一致しないリソースは作成できなくなるためです。
+ **プルリクエスト (PR) レビューを要求する** – RVM ソリューションの価値は、新しいパイプラインロールをレビューできる一元的な場所を作成することにあります。ただし、この設計は、安全で質の高いコードが RVM にコミットされるよう保証するガードレールがある場合にのみ役立ちます。コード (`main` など) をデプロイするために使用されるブランチを直接のプッシュから保護し、それらをターゲットとするマージリクエストの承認を要求します。
+ **読み取り専用ロールを設定する** – デフォルトでは、RVM はリクエストされた各ロール `readonly` バージョンをプロビジョニングします。このロールは、`terraform plan` パイプラインワークフローなど、データを書き込まない CI/CD パイプラインで使用できます。このアプローチは、読み取り専用ワークフローの動作が異常である場合に、不要な変更を防ぐのに役立ちます。
デフォルトでは、 AWS 管理`ReadOnlyAccess`ポリシーは読み取り専用ロールと読み取り/書き込みロールの両方にアタッチされます。このポリシーによって、必要なアクセス許可を決定する際のイテレーションの必要性を軽減できますが、一部の組織では過度な許可となる場合があります。必要に応じて、Terraform コードからポリシーを削除できます。
+ **最小限の権限を付与する** – 最小特権の原則に従い、タスクの実行に必要最小限の権限を付与します。詳細については、IAM ドキュメントの「[最小限の特権を認める。](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#grant-least-priv)」と「[IAM でのセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)」を参照してください。
## エピック
### 環境の準備
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| サンプルリポジトリを GitHub 組織にコピーします。 | このパターンのリポジトリを[クローン](https://docs.github.com/en/repositories/creating-and-managing-repositories/cloning-a-repository)するか、このリポジトリを GitHub 組織に[フォーク](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/fork-a-repo)して、ニーズに合わせて調整できるようにします。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/provision-least-privilege-iam-roles-by-deploying-a-role-vending-machine-solution.html) | DevOps エンジニア |
| RVM AWS アカウント の を決定します。 | RVM AWS アカウント に使用するインフラストラクチャのデプロイを決定します。管理アカウントまたはルートアカウントを使用しないでください。 | クラウドアーキテクト |
| (オプション) 組織のパイプラインに PR の作成を許可します。 | このステップは、`generate_providers_and_account_vars` ワークフローに PR の作成を許可する場合にのみ必要です。組織のパイプラインに PR の作成を許可するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/provision-least-privilege-iam-roles-by-deploying-a-role-vending-machine-solution.html)詳細については、GitHub ドキュメントの「[リポジトリの GitHub Actions の設定を管理する](https://docs.github.com/en/enterprise-server@3.10/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#preventing-github-actions-from-creating-or-approving-pull-requests)」を参照してください。 | DevOps エンジニア |
| RVM アカウントに読み取り専用アクセス許可を付与します。 | RVM アカウントに読み取り専用アクセス許可を付与する委任ポリシーを管理アカウントに作成します。これにより、RVM GitHub ワークフローは、`generate_providers_and_account_vars.py`スクリプトの実行時に AWS 組織のアカウントのリストを動的にプルできます。次のコードを使用して、 をステップ 2 で選択した AWS アカウント ID ``に置き換えます。{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Statement",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam:::root"
},
"Action": [
"organizations:ListAccounts",
"organizations:DescribeOrganization",
"organizations:DescribeOrganizationalUnit",
"organizations:ListRoots",
"organizations:ListAWSServiceAccessForOrganization",
"organizations:ListDelegatedAdministrators"
],
"Resource": "*"
}
]
} | クラウド管理者 |
| サンプルリポジトリのデフォルト値を更新します。 | 特定の環境で動作するように RVM を設定するには AWS リージョン、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/provision-least-privilege-iam-roles-by-deploying-a-role-vending-machine-solution.html) | DevOps エンジニア |
### インフラストラクチャの初期化
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| RVM リポジトリをブートストラップします。 | このステップは、RVM パイプライン自体で使用される OIDC 信頼ロールと IAM ロールを作成するために必要です。これにより、他のロールの運用と販売を開始できるようになります。RVM アカウントのコンテキストで、`scripts/bootstrap` ディレクトリから `terraform apply` コマンドを手動で実行します。変数ドキュメントに基づいて必要な値を指定します。 | DevOps エンジニア |
### オペレーションの設定
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| `github-workflow-rvm` および `github-workflow-rvm-readonly` ロールをすべてのアカウントにデプロイします。 | AFT や StackSets など、組織のプラクティスに沿ったデプロイ方法を選択します。このメソッドを使用して、`scripts/assumed_role/main.tf` ファイル内の 2 つの IAM ロール (デフォルト名 `github-workflow-rvm` と `github-workflow-rvm-readonly`) を、RVM がパイプラインロールを作成できる各アカウントにデプロイします。これらの IAM ロールには、RVM アカウントのロール引き受けロール (または `readonly` と同等のロール) が引き受けることを許可する信頼ポリシーがあります。このロールには、`github-workflow-role-*` に一致するロールの読み取りと書き込み (`readonly` ロールを使用している場合を除く) を許可する IAM アクセス許可ポリシーもあります。 | AWS 管理者 |
| `generate_providers_and_account_vars` ワークフローを実行します。 | RVM を設定してパイプラインロールを作成する準備を整えるには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/provision-least-privilege-iam-roles-by-deploying-a-role-vending-machine-solution.html)ワークフローが完了すると、RVM は次を行う準備が整います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/provision-least-privilege-iam-roles-by-deploying-a-role-vending-machine-solution.html) | DevOps エンジニア |
## トラブルシューティング
| 問題 | ソリューション |
| --- | --- |
| RVM を使用してロールを作成しましたが、GitHub がロールを引き受けることができません。 | GitHub リポジトリの名前が `github_workflow_roles` モジュールに指定された名前と一致していることを確認します。引き受けられるリポジトリが 1 つだけになるように、ロールの範囲が設定されています。同様に、GitHub パイプラインで使用されるブランチが、`github_workflow_roles` モジュールに指定されたブランチの名前と一致することを確認します。通常、書き込み権限を持つ RVM 作成ロールは、`main` ブランチ (つまり、`main` から取得されたデプロイ) を対象とするワークフローでのみ使用できます。 |
| 特定のリソースを読み取るアクセス許可がないため、読み取り専用ロールはパイプラインの実行に失敗しています。 | `ReadOnlyAccess` ポリシーには広範な読み取り専用アクセス許可がありますが、一部の読み取りアクション (特定の AWS Security Hub CSPM アクションなど) はありません。`github-workflow-roles` モジュールの `inline_policy_readonly` パラメータを使用して、特定のアクションのアクセス許可を追加できます。 |
## 関連リソース
+ [Stack AWS CloudFormation StackSets を使用するためのベストプラクティス](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-bestpractices.html)
+ [複数のアカウントを使用した AWS 環境の整理](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html)
+ [AWS Control Tower Account Factory for Terraform (AFT) の概要](https://docs.aws.amazon.com/controltower/latest/userguide/aft-overview.html)
+ [ポリシーのベストプラクティス](https://docs.aws.amazon.com/codepipeline/latest/userguide/security_iam_service-with-iam-policy-best-practices.html)
## 追加情報
**GitHub 環境の使用**
GitHub 環境は、ロールアクセスのブランチベースの制限に代わるアプローチです。GitHub 環境を使用する場合、IAM 信頼ポリシーの追加条件の構文の例は以下のようになります。この構文は、GitHub アクションが `Production` 環境で実行されている場合にのみロールを使用できることを指定します。
```
"StringLike": {
"token.actions.githubusercontent.com:sub": "repo:octo-org/octo-repo:environment:Production"
}
```
構文の例では、次のプレースホルダー値を使用します。
+ `octo-org` は GitHub 組織名です。
+ `octo-repo` はリポジトリの名前です。
+ `Production` は特定の GitHub 環境名です。
# Amazon CloudWatch メトリクスを CSV ファイルに公開
*Abdullahi Olaoye、Amazon Web Services*
## 概要
このパターンでは、Python スクリプトを使用して Amazon CloudWatch メトリクスを取得し、メトリクス情報をカンマ区切り値 (CSV) ファイルに変換して読みやすくします。このスクリプトは、メトリックスを取得する必要がある AWS サービスを必須の引数として取ります。AWS リージョンと AWS 認証情報プロファイルをオプションの引数として指定できます。これらの引数を指定しない場合、スクリプトはスクリプトが実行されるワークステーションに設定されているデフォルトのリージョンとプロファイルを使用します。スクリプトが実行されると、CSV ファイルが生成され、同じディレクトリに保存されます。
このパターンで提供されるスクリプトと関連ファイルについては、*添付ファイル*セクションを参照してください。
## 前提条件と制限事項
**前提条件**
+ Python 3.x
+ AWS コマンドラインインターフェイス (AWS CLI)
**制限事項**
このスクリプトでは、現在以下の AWS サービスをサポートします。
+ AWS Lambda
+ Amazon Elastic Compute Cloud (Amazon EC2)
+ デフォルトでは、スクリプトは Amazon Elastic Block Store (Amazon EBS) ボリュームメトリクスを収集しません。Amazon EBS メトリクスを収集するには、添付 `metrics.yaml` ファイルを変更する必要があります。
+ Amazon Relational Database Service (Amazon RDS)
+ ただし、このスクリプトは Amazon Aurora をサポートしていません。
+ Application Load Balancer
+ Network Load Balancer
+ Amazon API Gateway
## ツール
+ [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) は、DevOps エンジニア、開発者、サイト信頼性エンジニア (SRE)、IT マネージャー向けに構築された、モニタリングサービスです。CloudWatch では、データと実用的なインサイトを提供して、アプリケーションのモニタリング、システム全体のパフォーマンスの変化に関する対応、リソース使用率の最適化、および運用状態の統合的な確認を行うことができます。CloudWatch は、ログ、メトリックス、イベントの形式でモニタリングデータと運用データを収集し、AWS とオンプレミスサーバーで実行される AWS のリソース、アプリケーション、サービスを一元的に表示します。
## エピック
### 前提条件をインストールして設定する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| 前提条件をインストールします。 | 次のコマンドを実行します。$ pip3 install -r requirements.txt
| 開発者 |
| AWS CLI を設定します。 | 次のコマンドを実行します。 $ aws configure
| 開発者 |
### Python スクリプトを設定します
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| スクリプトを開きます。 | スクリプトのデフォルト設定を変更するには、`metrics.yaml` を開きます。 | 開発者 |
| スクリプトの期間を設定します。 | これは取得する期間です。デフォルト期間は 5 分 (300 秒) です。期間は変更できますが、以下の制限事項に注意します。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/publish-amazon-cloudwatch-metrics-to-a-csv-file.html)そうしないと、API オペレーションはデータポイントを返しません。 | 開発者 |
| スクリプトの時間を設定します。 | この値には、取得するメトリックスの時間数を指定します。デフォルトは 1 時間です。複数日分のメトリクスを取得するには、値を時間単位で指定します。例えば、2 日間の場合は 48 と指定します。 | 開発者 |
| スクリプトの統計値を変更します。 | (オプション) グローバル統計値は `Average` で、特定の統計値が割り当てられていないメトリクスを取得するときに使用されます。このスクリプトは統計値 `Maximum`、`SampleCount`、`Sum` をサポートします。 | 開発者 |
### Python スクリプトを実行する。
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| スクリプトを実行します。 | 以下のコマンドを使用します。 $ python3 cwreport.py
サービス値、オプション `region `、`profile ` パラメータのリストを表示するには、以下のコマンドを実行します。 $ python3 cwreport.py -h
オプションパラメータの詳細については、*追加情報*セクションを参照してください。 | 開発者 |
## 関連リソース
+ 「[AWS CLI の設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html)」
+ [Amazon CloudWatch メトリクスを使用する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
+ 「[Amazon CloudWatch ドキュメント](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)」
+ 「[EC2: CloudWatch - メトリクス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html#ec2-cloudwatch-metrics)」
+ [AWS Lambda メトリクス](https://docs.aws.amazon.com/lambda/latest/operatorguide/logging-metrics.html)
+ 「[Amazon RDS メトリクス](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-metrics.html#rds-cw-metrics-instance)」
+ 「[Application Load Balancer のメトリクス](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html)」
+ 「[Network Load Balancer のメトリクス](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-cloudwatch-metrics.html)」
+ 「[Amazon API Gateway のメトリクス](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-metrics-and-dimensions.html)」
## 追加情報
スクリプトの使用法
```
$ python3 cwreport.py -h
```
シンタックス例
```
python3 cwreport.py <--region=Optional Region> <--profile=Optional credential profile>
```
**パラメータ**
+ **service (必須)** ‒ スクリプトを実行したいサービス。スクリプトは現在、AWS Lambda、Amazon EC2、Amazon RDS、Application Load Balancer、Network Load Balancer、API ゲートウェイといったサービスをサポートします。
+ **region (オプション)** ‒ メトリックスを取得する AWS リージョン。デフォルトのリージョンは `ap-southeast-1` です。
+ **プロファイル (オプション)** ‒ 使用する AWS CLI の名前付きプロファイル。このパラメータを指定しない場合、デフォルトで設定されている認証情報プロファイルが使用されます。
**例**
+ デフォルトのリージョンと `ap-southeast-1` デフォルトで設定された認証情報を使用して Amazon EC2 メトリックスを取得するには:`$ python3 cwreport.py ec2`
+ リージョンを指定して API ゲートウェイメトリクスを取得するには:`$ python3 cwreport.py apigateway --region us-east-1`
+ AWS プロファイルを指定して Amazon EC2 メトリックスを取得するには: `$ python3 cwreport.py ec2 --profile testprofile`
+ リージョンとプロファイルの両方を指定して、Amazon EC2 メトリックスを取得するには: `$ python3 cwreport.py ec2 --region us-east-1 --profile testprofile`
## アタッチメント
このドキュメントに関連する追加コンテンツにアクセスするには、次のファイルを解凍してください。「[attachment.zip](samples/p-attach/0a915a9d-2eef-4da1-8283-3cf4a115b3b2/attachments/attachment.zip)」
# AWS Lambda オートメーションを使用して 全体の Amazon EC2 エントリを AWS アカウント から削除 AWS Managed Microsoft AD する
*Amazon Web Services、Dr. Rahul Sharad Gaikwad、Tamilselvan P*
## 概要
Active Directory (AD) は、ドメイン情報とネットワークサービスとのユーザーインタラクションを管理する Microsoft スクリプトツールです。これは、従業員の認証情報とアクセス許可を管理するために、マネージドサービスプロバイダー (MSP) の間で広く使用されています。AD 攻撃者は非アクティブなアカウントを使用して組織をハッキングしようとするため、非アクティブなアカウントを見つけて定期的なメンテナンススケジュールで無効にすることが重要です。を使用すると AWS Directory Service for Microsoft Active Directory、Microsoft Active Directory をマネージドサービスとして実行できます。このパターンは、非アクティブなアカウントをすばやく見つけて削除するように AWS Lambda 自動化を設定するのに役立ちます。
次のシナリオが組織に当てはまる場合、このパターンが役立ちます。
+ **一元化された AD 管理** – 組織に複数の があり AWS アカウント、それぞれに独自の AD デプロイがある場合、すべてのアカウントでユーザーアカウントとアクセス許可を一貫して管理するのは難しい場合があります。アカウント間の AD クリーンアップソリューションを使用すると、すべての AD インスタンスから非アクティブなアカウントを一元的に無効化または削除できます。
+ **AD の再構築または移行** – 組織が AD デプロイを再構築または移行する場合、アカウント間の AD クリーンアップソリューションが環境の準備に役立ちます。このソリューションを使用すると、不要なアカウントや非アクティブなアカウントを削除し、移行プロセスを簡素化し、潜在的な競合や問題を減らしやすくなります。
このパターンを使用すると、次のような利点があります。
+ データベースとサーバーのパフォーマンスを向上させ、非アクティブなアカウントのセキュリティの脆弱性を修正します。
+ AD サーバーがクラウドでホストされている場合、非アクティブなアカウントを削除すると、パフォーマンスを向上させながらストレージコストを削減することもできます。帯域幅料金とコンピューティングリソースの両方が下がることがあるため、月額請求額が減る可能性があります。
+ クリーンな Active Directory を使用して、潜在的な攻撃者を阻止しましょう。
## 前提条件と制限
**前提条件**
+ アクティブな親アカウント AWS アカウント と 1 つ以上の子アカウント。このパターンでは、*親アカウント*は Active Directory が作成される場所です。*子アカウント*は Windows サーバーをホストし、親アカウントの Active Directory を介して結合されます。
+ ローカルワークステーションに[インストール](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)および設定されている Git。
+ ローカルワークステーションに[インストール](https://learn.hashicorp.com/tutorials/terraform/install-cli)および設定されている Terraform。
+ AWS Managed Microsoft AD 親アカウントで設定され、すべての子アカウントと共有される ディレクトリ。詳細については、 *AWS Directory Service 管理ガイド*の[「チュートリアル: シームレスな EC2 ドメイン参加のための AWS Managed Microsoft AD ディレクトリの共有](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_tutorial_directory_sharing.html)」を参照してください。
+ 仮想プライベートクラウド (VPC) ピアリング接続、または AWS Directory Service (親アカウント) の VPC と Amazon Elastic Compute Cloud (Amazon EC2) インスタンス (子アカウント) の VPC の間で利用可能な AWS Transit Gateway 接続。詳細は、*AWS Directory Service 管理ガイド*で「[Configure a VPC peering connection between the directory owner and the directory consumer account](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/step1_setup_networking.html#step1_configure_owner_account_vpc)」を参照してください。
+ すべての親アカウントと子アカウントで `EC2WindowsUserdata` スクリプトで設定された Windows マシン。スクリプトファイルは、このパターンの[コードリポジトリ](https://github.com/aws-samples/aws-lambda-ad-cleanup-terraform-samples/tree/main/multiple-account-cleanup)のルートにあります。
+ 親アカウントからの AWS Lambda 関数の使用を許可する信頼ポリシーで設定された各子アカウントで使用可能なクロスアカウント AWS Identity and Access Management (IAM) ロール。詳細については、[「Amazon EventBridge ユーザーガイド」の「Amazon EventBridge AWS アカウント での 間のイベントの送受信](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/CloudWatchEvents-CrossAccountEventDelivery.html)」を参照してください。 * EventBridge *
+ 親アカウントの Parameter Store AWS Systems Manager で使用できる次のシークレット値。
+ `domainJoinUser` – ディレクトリサービスのユーザー名
+ `domainJoinPassword` – ディレクトリサービスのパスワード
シークレットの詳細については、「 *AWS Secrets Manager ユーザーガイド*」の「 [AWS Secrets Manager シークレットの作成](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html)」を参照してください。
**制限事項**
+ 子アカウントでのリソースの作成は、Terraform では自動化されません。 AWS マネジメントコンソールを使用して、次のリソースを手動で作成する必要があります。
+ Amazon EC2 終了イベントを親アカウントに送信する Amazon EventBridge ルール
+ 信頼ポリシーを持つ子アカウントでの Amazon EC2 クロスアカウントロールの作成
+ VPC ピアリングまたは Transit Gateway 接続
+ 一部の AWS のサービス は では使用できません AWS リージョン。利用可能なリージョンについては、「[AWS のサービス (リージョン別)](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)」を参照してください。特定のエンドポイントについては、「[Service endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)」で、サービスのリンクを選択してご確認ください。
**製品バージョン**
+ [Terraform バージョン 1.1.9 以降](https://developer.hashicorp.com/terraform/install)
+ [Terraform AWS プロバイダーバージョン 3.0 以降](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/guides/version-3-upgrade)
## アーキテクチャ
次の図は、ソリューションの高レベルアーキテクチャを示しています。
![\[Lambda オートメーションを使用して、AWS アカウント間から EC2 エントリを削除するプロセス。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/c397d873-e10d-44b6-8352-5f1380ab94ca/images/bd6c80a7-e490-47db-bd47-165314e1ea8a.png)
アーキテクチャ図は次のプロセスを示しています。
1. 子アカウントで、EventBridge ルールはすべての Amazon EC2 終了イベントを収集します。ルールは、親アカウントに存在する EventBridge にこれらのイベントを送信します。
1. 親アカウントから、EventBridge はすべてのイベントを収集します。EventBridge には、Lambda 関数 `ADcleanup-Lambda` をトリガーするルールが含まれます。
1. 親アカウントは、親アカウントまたは子アカウントから終了イベントを受け取り、Lambda 関数をトリガーします。
1. Lambda 関数は、Python boto モジュールを使用して Amazon EC2 Auto Scaling グループを呼び出し、ランダムなインスタンス ID を取得します。インスタンス ID は、Systems Manager コマンドを実行するために使用されます。
1. Lambda 関数は、boto モジュールを使用して Amazon EC2 に別の呼び出しを行います。Lambda 関数は、実行中の Windows サーバーのプライベート IP アドレスを取得し、そのアドレスを一時変数に保存します。ステップ 5.1 および 5.2 では、実行中の Windows EC2 インスタンスが子アカウントから収集されます。
1. Lambda 関数は、Systems Manager をもう一度呼び出して、 AWS Directory Serviceに接続されているコンピュータ情報を取得します。
1. AWS Systems Manager ドキュメントは、Amazon EC2 Windows サーバーで PowerShell コマンドを実行して、AD に接続されているコンピュータのプライベート IP アドレスを取得するのに役立ちます。(Systems Manager ドキュメントは、ステップ 4 で取得したインスタンス ID を使用します。)
1. AD ドメインのユーザー名とパスワードは Parameter Store AWS Systems Manager に保存されます。 AWS Lambda Systems Manager は Parameter Store を呼び出し、AD への接続に使用するユーザー名とパスワードの値を取得します。
1. Systems Manager ドキュメントを使用し、ステップ 4 で先ほど取得したインスタンス ID を使用して PowerShell スクリプトが Amazon EC2 Windows サーバーで実行されます。
1. Amazon EC2 は PowerShell コマンド AWS Directory Service を使用して に接続し、使用されていないコンピュータや非アクティブのコンピュータを削除します。
## ツール
**AWS サービス**
+ [AWS Directory Service](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/what_is.html) には、Amazon Elastic Compute Cloud (Amazon EC2)、Amazon Relational Database Service (Amazon RDS) for SQL Server、Amazon FSx for Windows File Server AWS のサービス など、他の で Microsoft Active Directory (AD) を使用する複数の方法が用意されています。
+ [AWS Directory Service for Microsoft Active Directory](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html) では、ディレクトリ対応のワークロードと AWS リソースが で Microsoft Active Directory を使用できます AWS クラウド。
+ [Amazon Elastic Compute Cloud (Amazon EC2)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts.html) は、 AWS クラウドでスケーラブルなコンピューティング容量を提供します。仮想サーバーを必要な数だけ起動して、迅速にスケールアップまたはスケールダウンができます。
+ [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) は、アプリケーションをさまざまなソースのリアルタイムデータに接続できるようにするサーバーレスイベントバスサービスです。例えば、 AWS Lambda 関数、API 送信先を使用する HTTP 呼び出しエンドポイント、その他のイベントバスなどです AWS アカウント。
+ [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、誰を認証し、誰に使用する権限を付与するかを制御することで、 AWS リソースへのアクセスを安全に管理するのに役立ちます。IAM を使用すると、 のサービスとリソースにアクセスできるユーザーまたはユーザーを指定し AWS、きめ細かなアクセス許可を一元管理し、アクセスを分析してアクセス許可を絞り込むことができます AWS。
+ [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。
+ [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html) は、 AWS クラウドで実行されるアプリケーションとインフラストラクチャの管理に役立ちます。これにより、アプリケーションとリソースの管理が簡素化され、運用上の問題を検出して解決する時間を短縮し、 AWS リソースを大規模に安全に管理できます。
+ [AWS Systems Manager ドキュメント](https://docs.aws.amazon.com/systems-manager/latest/userguide/documents.html)は、Systems Manager がマネージドインスタンスで実行するアクションを定義します。Systems Manager には、ランタイムでパラメータを指定して使用できる事前設定済みのドキュメントが 100 件以上含まれています。
+ [AWS Systems Manager Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html) は の機能であり、設定データ管理 AWS Systems Manager とシークレット管理のための安全な階層型ストレージを提供します。
**その他のツール**
+ [HashiCorp Terraform](https://www.terraform.io/docs) は、コードを使用してクラウドインフラストラクチャとリソースをプロビジョニングして管理するのに役立つ infrastructure as code (IaC) ツールです。
+ [PowerShell](https://learn.microsoft.com/en-us/powershell/) は Windows、Linux、および macOS で動作するMicrosoft の自動化および構成管理プログラムです。
+ 「[Python](https://www.python.org/)」は汎用のコンピュータプログラミング言語です。
**コードリポジトリ**
このパターンのコードは、GitHub 内の「[aws-lambda-ad-cleanup-terraform-samples](https://github.com/aws-samples/aws-lambda-ad-cleanup-terraform-samples/tree/main/multiple-account-cleanup)」リポジトリで利用できます。
## ベストプラクティス
+ **自動的にドメインを結合します。** Directory Service ドメインの一部となる Windows インスタンスを起動する場合は、後でインスタンスを手動で追加するのではなく、インスタンスの作成プロセス中にドメインに参加します。自動的にドメインを結合するには、新しいインスタンスを起動するときに、**ドメイン結合ディレクトリ**の適切なディレクトリを選択します。詳細については、 *Directory Service 管理ガイド*[のAmazon EC2 Windows インスタンスを AWS Managed Microsoft AD Active Directory にシームレスに結合する](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/launching_instance.html)」を参照してください。
+ **未使用のアカウントを削除します。**AD では、使用されたことがないアカウントがよく見られます。システム内に残っている無効または非アクティブなアカウントと同様に、未使用のアカウントを無視すると、AD システムが遅くなったり、組織がデータ侵害に対して脆弱になる可能性があります。
+ **Active Directory のクリーンアップを自動化します。**セキュリティリスクを軽減し、古いアカウントが AD のパフォーマンスに影響を与えないようにするには、AD クリーンアップを定期的に実行する必要があります。スクリプトを記述することで、ほとんどの AD 管理タスクとクリーンアップタスクを実行できます。タスクの例としては、無効なアカウントと非アクティブなアカウントの削除、空のグループと非アクティブなグループの削除、期限切れのユーザーアカウントとパスワードの特定などがあります。
## エピック
### 子アカウントをセットアップする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| 子アカウントにクロスアカウントロールを作成します。 | 子アカウントにクロスアカウントロールを作成するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/remove-amazon-ec2-entries-across-aws-accounts-from-aws-managed-microsoft-ad.html) | DevOps エンジニア |
| 子アカウントでイベントルールを作成します。 | 子アカウントごとに EventBridge ルールを作成するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/remove-amazon-ec2-entries-across-aws-accounts-from-aws-managed-microsoft-ad.html)詳細については、*Amazon EventBridge ユーザーガイド*の「[Creating rules that react to events in Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-create-rule.html)」を参照してください。 | DevOps エンジニア |
| EC2 インスタンスを作成し、AD に結合します。 | Windows 用の EC2 インスタンスを作成するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/remove-amazon-ec2-entries-across-aws-accounts-from-aws-managed-microsoft-ad.html) | DevOps エンジニア |
### ローカルワークステーションをセットアップする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| プロジェクトフォルダを作成し、ファイルを追加します。 | リポジトリを複製し、プロジェクトフォルダを作成するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/remove-amazon-ec2-entries-across-aws-accounts-from-aws-managed-microsoft-ad.html) | DevOps エンジニア |
| `adcleanup.zip` ファイルを構築します。 | `lambda_function.py` ファイルを圧縮するには、次のコマンドを実行します。`zip -r adcleanup.zip lambda_function.py` | DevOps エンジニア |
### Terraform の設定を使用してターゲットアーキテクチャをプロビジョニングする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| Terraform 変数の値を指定します。 | 子アカウントの場合、`terraform.tfvars` ファイルに文字列型として次の `arn` 変数の値を指定します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/remove-amazon-ec2-entries-across-aws-accounts-from-aws-managed-microsoft-ad.html) | DevOps エンジニア |
| Terraform の設定を初期化します。 | Terraform ファイルを含む作業ディレクトリを初期化するには、次のコマンドを実行します。`terraform init` | DevOps エンジニア |
| 変更のプレビュー | インフラストラクチャがデプロイされる前に、Terraform がインフラストラクチャに加える変更をプレビューできます。Terraform が必要に応じて変更を行うことを確認するには、次のコマンドを実行します。`terraform plan —-var-file=examples/terraform.tfvars` | DevOps エンジニア |
| 提案されたアクションを実行します。 | `terraform plan` コマンドの結果が期待どおりであることを確認するには、以下を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/remove-amazon-ec2-entries-across-aws-accounts-from-aws-managed-microsoft-ad.html) | DevOps エンジニア |
### デプロイメントを確認する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| Lambda 関数を実行およびテストします。 | デプロイが正常に行われたことを確認するには、以下を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/remove-amazon-ec2-entries-across-aws-accounts-from-aws-managed-microsoft-ad.html)実行結果には、関数の出力が表示されます。 | DevOps エンジニア |
| 親アカウントの EventBridge ルール実行の結果を表示します。 | 親アカウントの Amazon EC2 終了イベントに基づく EventBridge ルールの結果を表示するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/remove-amazon-ec2-entries-across-aws-accounts-from-aws-managed-microsoft-ad.html)CloudWatch コンソールの**ロググループ**ページには、Lambda 関数の結果が表示されます。 | DevOps エンジニア |
| 子アカウントの EventBridge ルール実行の結果を表示します。 | 子アカウントの Amazon EC2 終了イベントに基づく EventBridge ルールの結果を表示するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/remove-amazon-ec2-entries-across-aws-accounts-from-aws-managed-microsoft-ad.html)CloudWatch コンソールの**ロググループ**ページには、Lambda 関数の結果が表示されます。 | DevOps エンジニア |
### 使用後にインフラストラクチャをクリーンアップする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| インフラストラクチャをクリーンアップします。 | 作成したインフラストラクチャをクリーンアップするには、次のコマンドを使用します。`terraform destroy``destroy` コマンドを確認するには、「`yes`」と入力します。 | DevOps エンジニア |
| クリーンアップ後に確認します。 | リソースが正常に削除されたことを確認します。 | DevOps エンジニア |
## トラブルシューティング
| 問題 | ソリューション |
| --- | --- |
| AWS Directory Service (親アカウント) と Amazon EC2 インスタンス (子アカウント) 間の接続の問題 – VPC ピア接続が使用可能であっても、子アカウントのコンピュータを AD に参加させることはできません。 | VPC にルーティングを追加します。手順については、 AWS Directory Service ドキュメントの[「ディレクトリ所有者とディレクトリコンシューマーアカウント間の VPC ピアリング接続を設定する](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/step1_setup_networking.html#step1_configure_owner_account_vpc)」を参照してください。 |
## 関連リソース
**AWS ドキュメント**
+ [Amazon EventBridge と AWS Identity and Access Management](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-iam.html)
+ [Systems Manager に必要なインスタンスのアクセス許可を設定する](https://docs.aws.amazon.com/systems-manager/latest/userguide/setup-instance-profile.html)
+ [の ID とアクセスの管理 Directory Service](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/iam_auth_access.html)
+ [Lambda のアイデンティティベースの IAM ポリシー](https://docs.aws.amazon.com/lambda/latest/dg/access-control-identity-based.html)
+ [Amazon EC2 Windows インスタンスを AWS Managed Microsoft AD Active Directory に手動で結合する](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/join_windows_instance.html)
+ [AWS Lambda オートメーションを使用して同じ の Amazon EC2 エントリを AWS アカウント から削除 AWS Managed Microsoft AD する](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/remove-amazon-ec2-entries-in-the-same-aws-account-from-aws-managed-microsoft-ad.html)
**その他のリソース**
+ [AWS プロバイダー](https://registry.terraform.io/providers/hashicorp/aws/latest/docs) (Terraform ドキュメント)
+ [バックエンド設定](https://developer.hashicorp.com/terraform/language/backend) (Terraform ドキュメント)
+ [Terraform のインストール](https://learn.hashicorp.com/tutorials/terraform/install-cli) (Terraform ドキュメント)
+ [Python boto モジュール](https://pypi.org/project/boto/) (Python Package Index リポジトリ)
+ [Terraform バイナリダウンロード](https://www.terraform.io/downloads) (Terraform ドキュメント)
# AWS Lambda オートメーションを使用して AWS アカウント から同じ の Amazon EC2 AWS Managed Microsoft AD エントリを削除する
*Amazon Web Services、Dr. Rahul Sharad Gaikwad、Tamilselvan P*
## 概要
Active Directory (AD) は、ドメイン情報とネットワークサービスとのユーザーインタラクションを管理する Microsoft スクリプトツールです。これは、従業員の認証情報とアクセス許可を管理するために、マネージドサービスプロバイダー (MSP) の間で広く使用されています。AD 攻撃者は非アクティブなアカウントを使用して組織をハッキングしようとするため、非アクティブなアカウントを見つけて定期的なメンテナンススケジュールで無効にすることが重要です。を使用すると AWS Directory Service for Microsoft Active Directory、Microsoft Active Directory をマネージドサービスとして実行できます。
このパターンは、非アクティブなアカウントをすばやく見つけて削除するように AWS Lambda 自動化を設定するのに役立ちます。このパターンを使用すると、次のような利点があります。
+ データベースとサーバーのパフォーマンスを向上させ、非アクティブなアカウントのセキュリティの脆弱性を修正します。
+ AD サーバーがクラウドでホストされている場合、非アクティブなアカウントを削除すると、パフォーマンスを向上させながらストレージコストを削減することもできます。帯域幅料金とコンピューティングリソースの両方が下がることがあるため、月額請求額が減る可能性があります。
+ クリーンな Active Directory を使用して、潜在的な攻撃者を阻止しましょう。
## 前提条件と制限事項
**前提条件**
+ アクティブ AWS アカウント。
+ ローカルワークステーションに[インストール](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)および設定されている Git。
+ ローカルワークステーションに[インストール](https://learn.hashicorp.com/tutorials/terraform/install-cli)および設定されている Terraform。
+ Active Directory モジュール (`ActiveDirectory`) を搭載した Windows コンピュータ。
+ パラメータストアの パラメータに保存されている AWS Managed Microsoft AD および 認証情報のディレクトリ。 [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/parameter-create-console.html)
+ AWS Identity and Access Management [「 ツール](#remove-amazon-ec2-entries-in-the-same-aws-account-from-aws-managed-microsoft-ad-tools)」に AWS のサービス リストされている へのアクセス許可を持つ (IAM) ロール*。*IAM の詳細については、「[関連リソース](#remove-amazon-ec2-entries-in-the-same-aws-account-from-aws-managed-microsoft-ad-resources)」を参照してください。
**制限事項**
+ このパターンは、クロスアカウント設定をサポートしていません。
+ 一部の AWS のサービス は では使用できません AWS リージョン。利用可能なリージョンについては、「[AWS のサービス (リージョン別)](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)」を参照してください。特定のエンドポイントについては、「[Service endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)」で、サービスのリンクを選択してご確認ください。
**製品バージョン**
+ [Terraform バージョン 1.1.9 以降](https://developer.hashicorp.com/terraform/install)
+ [Terraform AWS プロバイダーバージョン 3.0 以降](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/guides/version-3-upgrade)
## アーキテクチャ
次の図表は、このパターンのアプリケーションのワークフローとアーキテクチャコンポーネントを示しています。
![\[Lambda オートメーションを使用して Managed Microsoft AD から EC2 エントリを削除するプロセス。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/6b50dcc5-4f4b-4eea-85a7-04cebc9f7454/images/b7fc5962-bfb8-4f5a-968e-7487b1d48c4f.png)
この図表は、次のワークフローを示しています:
1. Amazon EventBridge は、cron 式に基づいて AWS Lambda 関数をトリガーします。(このパターンでは、cron 式スケジュールは 1 日に 1 回です)。
1. 必要な IAM ロールとポリシーが作成され、Terraform AWS Lambda を介して にアタッチされます。
1. AWS Lambda 関数が実行され、Python boto モジュールを使用して Amazon Elastic Compute Cloud (Amazon EC2) Auto Scaling Groups を呼び出します。Lambda 関数はランダムなインスタンス ID を取得します。インスタンス ID は AWS Systems Manager コマンドの実行に使用されます。
1. AWS Lambda は、boto モジュールを使用して Amazon EC2 に別の呼び出しを行い、実行中の Windows サーバーのプライベート IP アドレスを取得し、そのアドレスを一時変数に保存します。
1. AWS Lambda は、Systems Manager をもう一度呼び出して、接続されているコンピュータ情報を取得します Directory Service。
1. AWS Systems Manager ドキュメントは、Amazon EC2 Windows サーバーで PowerShell スクリプトを実行して、AD に接続されているコンピュータのプライベート IP アドレスを取得するのに役立ちます。
1. AD ドメインのユーザー名とパスワードは Parameter Store AWS Systems Manager に保存されます。 AWS Lambda Systems Manager は Parameter Store を呼び出し、AD の接続に使用するユーザー名とパスワードの値を取得します。
1. Systems Manager ドキュメントを使用し、ステップ 3 で先ほど取得したインスタンス ID を使用して PowerShell スクリプトが Amazon EC2 Windows サーバーで実行されます。
1. Amazon EC2 Directory Service は PowerShell コマンドを使用して接続し、使用されていないコンピュータや非アクティブのコンピュータを削除します。
## ツール
**AWS サービス**
+ [AWS Directory Service](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/what_is.html) は、Amazon Elastic Compute Cloud (Amazon EC2)、Amazon Relational Database Service (Amazon RDS) for SQL Server、Amazon FSx for Windows File Server AWS のサービス など、他の で Microsoft Active Directory (AD) を使用する複数の方法を提供します。
+ [AWS Directory Service for Microsoft Active Directory](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html) は、ディレクトリ対応のワークロードと AWS リソースが で Microsoft Active Directory を使用できるようにします AWS クラウド。
+ [Amazon Elastic Compute Cloud (Amazon EC2)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts.html) は、 AWS クラウドでスケーラブルなコンピューティング容量を提供します。仮想サーバーを必要な数だけ起動して、迅速にスケールアップまたはスケールダウンができます。
+ [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) は、アプリケーションをさまざまなソースのリアルタイムデータに接続できるようにするサーバーレスイベントバスサービスです。例えば、 AWS Lambda 関数、API 送信先を使用する HTTP 呼び出しエンドポイント、その他のイベントバスなどです AWS アカウント。
+ [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、誰を認証し、誰に使用する権限を付与するかを制御することで、 AWSリソースへのアクセスを安全に管理するのに役立ちます。IAM を使用すると、 のサービスとリソースにアクセスできるユーザーまたはユーザーを指定し AWS、きめ細かなアクセス許可を一元管理し、アクセスを分析してアクセス許可を絞り込むことができます AWS。
+ [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。
+ [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html) は、 AWS クラウドで実行されるアプリケーションとインフラストラクチャの管理に役立ちます。これにより、アプリケーションとリソースの管理が簡素化され、運用上の問題を検出して解決する時間を短縮し、 AWS リソースを大規模に安全に管理できます。
+ [AWS Systems Manager ドキュメント](https://docs.aws.amazon.com/systems-manager/latest/userguide/documents.html)は、Systems Manager がマネージドインスタンスで実行するアクションを定義します。Systems Manager には、ランタイムでパラメータを指定して使用できる事前設定済みのドキュメントが 100 件以上含まれています。
+ [AWS Systems Manager Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html) は の機能であり、設定データ管理 AWS Systems Manager とシークレット管理のための安全な階層型ストレージを提供します。
**その他のツール**
+ [HashiCorp Terraform](https://www.terraform.io/docs) は、コードを使用してクラウドインフラストラクチャとリソースをプロビジョニングして管理するのに役立つオープンソースの infrastructure as code (IaC) ツールです。
+ [PowerShell](https://learn.microsoft.com/en-us/powershell/) は Windows、Linux、および macOS で動作するMicrosoft の自動化および構成管理プログラムです。
+ 「[Python](https://www.python.org/)」は汎用のコンピュータプログラミング言語です。
**コ****ードリポジトリ**
このパターンのコードは、GitHub 内の「[カスタム AD クリーンアップオートメーションソリューション](https://github.com/aws-samples/aws-lambda-ad-cleanup-terraform-samples/)」リポジトリで利用できます。
## ベストプラクティス
+ **自動的にドメインを結合します。** Directory Service ドメインの一部となる Windows インスタンスを起動する場合は、後でインスタンスを手動で追加するのではなく、インスタンスの作成プロセス中にドメインに参加します。自動的にドメインを結合するには、新しいインスタンスを起動するときに、**ドメイン結合ディレクトリ**の適切なディレクトリを選択します。詳細については、 *Directory Service 管理ガイド*[のAmazon EC2 Windows インスタンスを AWS Managed Microsoft AD Active Directory にシームレスに結合する](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/launching_instance.html)」を参照してください。
+ **未使用のアカウントを削除します。**AD では、使用されたことがないアカウントがよく見られます。システム内に残っている無効または非アクティブなアカウントと同様に、未使用のアカウントを無視すると、AD システムが遅くなったり、組織がデータ侵害に対して脆弱になる可能性があります。
+ **Active Directory のクリーンアップを自動化します。**セキュリティリスクを軽減し、古いアカウントが AD のパフォーマンスに影響を与えないようにするには、AD クリーンアップを定期的に実行する必要があります。スクリプトを記述することで、ほとんどの AD 管理タスクとクリーンアップタスクを実行できます。タスクの例としては、無効なアカウントと非アクティブなアカウントの削除、空のグループと非アクティブなグループの削除、期限切れのユーザーアカウントとパスワードの特定などがあります。
## エピック
### 環境をセットアップします。
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| プロジェクトフォルダを作成し、ファイルを追加します。 | リポジトリを複製し、プロジェクトフォルダを作成するには、次の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/remove-amazon-ec2-entries-in-the-same-aws-account-from-aws-managed-microsoft-ad.html) | DevOps エンジニア |
### Terraform の設定を使用してターゲットアーキテクチャをプロビジョニングする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| Terraform の設定を初期化する | Terraform ファイルを含む作業ディレクトリを初期化するには、次のコマンドを実行します。`terraform init` | DevOps エンジニア |
| 変更のプレビュー | インフラストラクチャがデプロイされる前に、Terraform がインフラストラクチャに加える変更をプレビューできます。Terraform が必要に応じて変更を行うことを確認するには、次のコマンドを実行します。`terraform plan` | DevOps エンジニア |
| 提案されたアクションを実行します。 | `terraform plan` コマンドの結果が期待どおりであることを確認するには、以下を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/remove-amazon-ec2-entries-in-the-same-aws-account-from-aws-managed-microsoft-ad.html) | DevOps エンジニア |
| インフラストラクチャをクリーンアップします。 | 作成したインフラストラクチャをクリーンアップするには、次のコマンドを使用します。`terraform destroy`destroy コマンドを確認するには、「`yes`」と入力します。 | DevOps エンジニア |
### デプロイメントを確認する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| Lambda 関数を実行およびテストします。 | デプロイが正常に行われたことを確認するには、以下を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/remove-amazon-ec2-entries-in-the-same-aws-account-from-aws-managed-microsoft-ad.html)実行結果には、関数の出力が表示されます。 | DevOps エンジニア |
| Lambda 関数の結果を表示します。 | このパターンでは、EventBridge ルールは Lambda 関数を 1 日に 1 回実行します。Lambda 関数の結果を表示するには、以下の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/remove-amazon-ec2-entries-in-the-same-aws-account-from-aws-managed-microsoft-ad.html)CloudWatch コンソールの**ロググループ**ページには、Lambda 関数の結果が表示されます。 | DevOps エンジニア |
### 使用後にインフラストラクチャをクリーンアップする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| インフラストラクチャをクリーンアップします。 | 作成したインフラストラクチャをクリーンアップするには、次のコマンドを使用します。`terraform destroy`destroy コマンドを確認するには、「`yes`」と入力します。 | DevOps エンジニア |
| クリーンアップ後に確認します。 | リソースが正常に削除されたことを確認します。 | DevOps エンジニア |
## トラブルシューティング
| 問題 | ソリューション |
| --- | --- |
| AD コンピュータを削除しようとすると、「アクセスが拒否されました」というメッセージが表示されます。デフォルトでは、アクションは AD サービスの一部として接続されている 2 つのプライベート IP アドレスを削除しようとするため、AD コンピュータを削除することはできません。 | このエラーを回避するには、AD コンピュータ出力と Windows を実行しているマシンの出力の違いを一覧表示するときに、次の Python オペレーションを使用して最初の 2 つのコンピュータを無視します。Difference = Difference[2:]
|
| Lambda は Windows サーバーで PowerShell スクリプトを実行する場合、Active Directory モジュールがデフォルトで使用可能であることを想定します。モジュールが使用できない場合、Lambda 関数は「Get-AdComputer is not installed on instance」というエラーを作成します。 | このエラーを回避するには、EC2 インスタンスのユーザーデータを使用して必要なモジュールをインストールします。このパターンの GitHub リポジトリにある [EC2WindowsUserdata](https://github.com/aws-samples/aws-lambda-ad-cleanup-terraform-samples/blob/main/EC2WindowsUserdata) スクリプトを使用します。 |
## 関連リソース
**AWS ドキュメント**
+ [Amazon EventBridge と AWS Identity and Access Management](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-iam.html)
+ [Systems Manager に必要なインスタンスのアクセス許可を設定する](https://docs.aws.amazon.com/systems-manager/latest/userguide/setup-instance-profile.html)
+ [の ID とアクセスの管理 Directory Service](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/iam_auth_access.html)
+ [Amazon EC2 Windows インスタンスを AWS Managed Microsoft AD Active Directory に手動で結合する](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/join_windows_instance.html)
+ [でのアイデンティティベースの IAM ポリシーの使用 AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/access-control-identity-based.html)
**その他のリソース**
+ [AWS プロバイダー](https://registry.terraform.io/providers/hashicorp/aws/latest/docs) (Terraform ドキュメント)
+ [バックエンド設定](https://developer.hashicorp.com/terraform/language/backend) (Terraform ドキュメント)
+ [Terraform のインストール](https://learn.hashicorp.com/tutorials/terraform/install-cli) (Terraform ドキュメント)
+ [Python boto モジュール](https://pypi.org/project/boto/) (Python Package Index リポジトリ)
+ [Terraform バイナリダウンロード](https://www.terraform.io/downloads) (Terraform ドキュメント)
# pytest フレームワーク AWS Glue を使用して で Python ETL ジョブのユニットテストを実行する
*Praveen Kumar Jeyarajan と Vaidy Sankaran、Amazon Web Services*
## 概要
[ローカル開発環境で](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-programming-etl-libraries.html) の Python 抽出、変換、ロード (ETL) ジョブ AWS Glue のユニットテストを実行できますが、DevOps パイプラインでこれらのテストをレプリケートするのは困難で時間がかかる場合があります。 AWS テクノロジースタックでメインフレーム ETL プロセスをモダナイズする場合、ユニットテストは特に難しい場合があります。このパターンは、既存の機能をそのまま維持し、新機能をリリースしたときに主要なアプリケーション機能の中断を回避し、高品質のソフトウェアを維持しながら、ユニットテストを簡素化する方法を示しています。このパターンのステップとコードサンプルを使用して、pytest フレームワーク AWS Glue を使用して で Python ETL ジョブのユニットテストを実行できます AWS CodePipeline。このパターンを使用して、複数の AWS Glue ジョブをテストおよびデプロイすることもできます。
## 前提条件と制限
**前提条件**
+ アクティブな AWS アカウント
+ Amazon ECR Public Gallery からダウンロードした AWS Glue ライブラリの Amazon Elastic Container Registry (Amazon ECR) イメージ URI [https://gallery.ecr.aws/glue/aws-glue-libs](https://gallery.ecr.aws/glue/aws-glue-libs)
+ ターゲット AWS アカウント と のプロファイルを持つ Bash ターミナル (任意のオペレーティングシステム上) AWS リージョン
+ [Python 3.10](https://www.python.org/downloads/) 以降
+ [Pytest](https://github.com/pytest-dev/pytest)
+ テスト用の [Moto](https://github.com/getmoto/moto) Python ライブラリ AWS のサービス
## アーキテクチャ
次の図は、Python に基づく AWS Glue ETL プロセスのユニットテストを一般的なエンタープライズスケールの AWS DevOps パイプラインに組み込む方法を示しています。
![\[AWS Glue ETL プロセスのユニットテスト。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/82781ca8-4da0-4df0-bf23-32992fece231/images/6286dafc-f1e0-4967-beed-4dedc6047c10.png)
この図表は、次のワークフローを示しています:
1. ソースステージでは、 AWS CodePipeline はバージョニングされた Amazon Simple Storage Service (Amazon S3) バケットを使用して、ソースコードアセットを保存および管理します。これらのアセットには、サンプル Python ETL ジョブ (`sample.py`)、ユニットテストファイル (`test_sample.py`)、 AWS CloudFormation テンプレートが含まれます。次に、CodePipeline は最新のコードをメインブランチから AWS CodeBuild プロジェクトに転送し、さらに処理します。
1. ビルドおよび公開ステージでは、前のソースステージの最新のコードは、 AWS Glue パブリック Amazon ECR イメージを使用してユニットテストされます。次に、テストレポートが CodeBuild レポートグループに公開されます。 AWS Glue ライブラリのパブリック Amazon ECR リポジトリのコンテナイメージには、 で [PySpark ベースの](https://spark.apache.org/docs/latest/api/python/) ETL タスクを AWS Glue ローカルで実行およびユニットテストするために必要なすべてのバイナリが含まれています。パブリックコンテナリポジトリには、 AWS Glueがサポートするバージョンごとに 1 つずつ、合計 3 つのイメージタグがあります。デモンストレーションの目的から、このパターンでは `glue_libs_4.0.0_image_01` image タグを使用しています。このコンテナイメージを CodeBuild のランタイムイメージとして使用するには、使用する予定のイメージタグに対応するイメージ URI をコピーし、`TestBuild` リソースの GitHub リポジトリ内の `pipeline.yml` ファイルを更新します。
1. デプロイ段階では、CodeBuild プロジェクトが起動され、すべてのテストに合格すると Amazon S3 バケットにコードが公開されます。
1. ユーザーは、 `deploy`フォルダの CloudFormation テンプレートを使用して AWS Glue タスクをデプロイします。
## ツール
**AWS のサービス**
+ [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) は完全マネージド型の構築サービスです。ソースコードのコンパイル、ユニットテストの実行、すぐにデプロイできるアーティファクトの生成を行います。
+ [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) は、ソフトウェアリリースのさまざまな段階を迅速にモデル化および設定し、ソフトウェアの変更を継続的にリリースするために必要なステップを自動化するのに役立ちます。
+ [Amazon Elastic Container Registry (Amazon ECR)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html) は、セキュリティ、スケーラビリティ、信頼性を備えたマネージドコンテナイメージレジストリサービスです。
+ [AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/what-is-glue.html) はフルマネージド型の ETL サービスです。これにより、データストアとデータストリーム間でのデータの分類、整理、強化、移動を確実に行うことができます。
+ [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) は、業界をリードするスケーラビリティ、データ可用性、セキュリティ、およびパフォーマンスを提供するオブジェクトストレージサービスです。
**その他のツール**
+ [Python](https://www.python.org/) は、高水準のインタープリター型汎用プログラミング言語です。
+ [Moto](https://github.com/getmoto/moto) はテスト用の Python ライブラリです AWS のサービス。
+ [Pytest](https://github.com/pytest-dev/pytest) は、アプリケーションやライブラリの複雑な機能テストをサポートするように拡張できる小規模なユニットテストを作成するためのフレームワークです。
+ の [Python ETL ライブラリ](https://github.com/awslabs/aws-glue-libs) AWS Glue は、PySpark バッチジョブのローカル開発で使用される Python ライブラリのリポジトリです AWS Glue。
**コードリポジトリ**
このパターンのコードは、GitHub 内の「[aws-glue-jobs-unit-testing](https://github.com/aws-samples/aws-glue-jobs-unit-testing)」リポジトリで利用できます。リポジトリには次のリソースが含まれています。
+ `src` フォルダ内のサンプル Python ベースの AWS Glue ジョブ
+ `tests` フォルダ内の関連ユニットテストケース (pytest フレームワークを使用して構築)
+ `deploy` フォルダ内の CloudFormation テンプレート (YAML で記述)
## ベストプラクティス
**CodePipeline リソースのセキュリティ**
CodePipeline のパイプラインに接続するソースリポジトリに暗号化と認証を使用することがベストプラクティスです。詳細については、CodePipeline ドキュメントの「[Security best practices](https://docs.aws.amazon.com/codepipeline/latest/userguide/security-best-practices.html)」を参照してください。
**CodePipeline リソースで使用するモニタリングとログ記録**
AWS ログ記録機能を使用して、ユーザーがアカウントで実行するアクションと使用するリソースを決定するのがベストプラクティスです。ログファイルには次の内容が表示されます。
+ アクションが実行された日時
+ アクション送信元 IP アドレス
+ 不適切なアクセス権限が理由で失敗したアクション
ログ記録機能は、 AWS CloudTrail および Amazon CloudWatch Events で使用できます。CloudTrail を使用して、 によって、または に代わって行われた AWS API コールおよび関連イベントを記録できます AWS アカウント。詳細については、CodePipeline ドキュメントの「[Logging CodePipeline API calls with AWS CloudTrail](https://docs.aws.amazon.com/codepipeline/latest/userguide/monitoring-cloudtrail-logs.html)」を参照してください。
CloudWatch Events を使用して、 で実行されている AWS クラウド リソースとアプリケーションをモニタリングできます AWS。CloudWatch イベントでアラートを作成することもできます。詳細については、CodePipeline ドキュメントの「[CodePipeline イベントのモニタリング](https://docs.aws.amazon.com/codepipeline/latest/userguide/detect-state-changes-cloudwatch-events.html)」を参照してください。
## エピック
### ソースコードをデプロイするには
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| コードアーカイブをデプロイ用に準備する。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/run-unit-tests-for-python-etl-jobs-in-aws-glue-using-the-pytest-framework.html) | DevOps エンジニア |
| CloudFormation スタックを更新する。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/run-unit-tests-for-python-etl-jobs-in-aws-glue-using-the-pytest-framework.html)スタックは、Amazon S3 をソースとして使用して CodePipeline ビューを作成します。上記のステップでは、パイプラインは **aws-glue-unit-test-pipeline** です。 | AWS DevOps、DevOps エンジニア |
### ユニットテストを実行する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| パイプラインでユニットテストを実行する。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/run-unit-tests-for-python-etl-jobs-in-aws-glue-using-the-pytest-framework.html) | AWS DevOps、DevOps エンジニア |
### すべての AWS リソースをクリーンアップする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| 環境内のリソースをクリーンアップする。 | 追加のインフラストラクチャコストを避けるため、このパターンで提供されている例を試した後は、必ずスタックを削除してください。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/run-unit-tests-for-python-etl-jobs-in-aws-glue-using-the-pytest-framework.html) | AWS DevOps、DevOps エンジニア |
## トラブルシューティング
| 問題 | ソリューション |
| --- | --- |
| CodePipeline サービスロールは Amazon S3 バケットにアクセスできません。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/run-unit-tests-for-python-etl-jobs-in-aws-glue-using-the-pytest-framework.html) |
| CodePipeline は、Amazon S3 バケットがバージョニングされていないというエラーを返します。 | CodePipeline では、ソース Amazon S3 バケットがバージョニングされている必要があります。Amazon S3 バケットのバージョニングを有効にします。手順については、「[バケットでのバージョニングの有効化](https://docs.aws.amazon.com/AmazonS3/latest/userguide/manage-versioning-examples.html)」を参照してください。 |
## 関連リソース
+ [AWS Glue](https://aws.amazon.com/glue/)
+ [ローカルでの AWS Glue ジョブの開発とテスト](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-programming-etl-libraries.html)
+ [の AWS CloudFormation AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/populate-with-cloudformation-templates.html)
## 追加情報
さらに、 AWS Command Line Interface () を使用して AWS CloudFormation テンプレートをデプロイできますAWS CLI。詳細については、CloudFormation ドキュメントの「[変換が含まれるテンプレートの迅速なデプロイ](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-cli-deploy.html)」を参照してください。
# AWS CodePipeline と AWS CDK を使用して CI/CD パイプラインを設定する
*Amazon Web Services、Konstantin Zarudaev、Yasha Dabas、Lars Kinder、Cizer Pereira*
## ホーム
継続的インテグレーションおよび継続的デリバリー (CI/CD) によるソフトウェアのビルドとリリースのプロセスを自動化することで、繰り返しビルドが可能になり、ユーザーへの新機能の迅速な提供が可能になります。各コード変更をすばやく簡単にテストでき、ソフトウェアをリリースする前にバグを見つけて修正できます。各変更をステージングとリリースのプロセスで実行することで、アプリケーションやインフラストラクチャコードの品質を検証できます。CI/CD は、アプリケーション開発チームがコード変更をより頻繁かつ確実に行うのに役立つ文化、一連の運用原則、[一連のプラクティス](https://aws.amazon.com/devops/#cicd)を体現しています。この実装は *CI/CD パイプライン*とも呼ばれます。
このパターンは、AWS CodeCommit リポジトリを使用して、Amazon Web Services (AWS) での再利用可能な継続的インテグレーションおよび継続的デリバリー (CI/CD) パイプラインを定義します。AWS CodePipeline パイプラインは、[AWS Cloud Development Kit (AWS CDK)](https://aws.amazon.com/cdk/) v2 を使用して作成されています。
CodePipeline を使用すると、AWS マネジメントコンソールインターフェイス、AWS コマンドラインインターフェイス (AWS CLI)、AWS CloudFormation、または AWS SDK を使用して、ソフトウェアリリースプロセスのさまざまな段階をモデル化することができます。このパターンは、AWS CDK を使用して CodePipeline とそのコンポーネントを実装する方法を示しています。ライブラリを構築することに加えて、AWS CDK には AWS CDK アプリケーションを操作するための主要なツールであるツールキット (CLI コマンド `cdk`) が含まれています。他の機能の中でも、このツールキットには、1 つ以上のスタックを CloudFormation テンプレートに変換して AWS アカウントにデプロイする機能があります。
パイプラインにはサードパーティライブラリのセキュリティを検証するテストが含まれており、指定された環境で迅速かつ自動的なリリースを保証するのに役立ちます。アプリケーションを検証プロセスにかけることで、アプリケーション全体のセキュリティを強化できます。
このパターンの目的は、デプロイするリソースが DevOps のベストプラクティスに従っていることを確認しながら、CI/CD パイプラインを使用してコードをデプロイする時間を短縮することです。[サンプルコード](https://github.com/aws-samples/aws-codepipeline-cicd)を実装すると、リンティング、テスト、セキュリティチェック、デプロイ、およびデプロイ後のプロセスを含む [AWS CodePipeline](https://aws.amazon.com/codepipeline/) が完成します。このパターンには Makefile のステップも含まれています。Makefile を使用すると、デベロッパーは CI/CD のステップをローカルで再現し、開発プロセスのスピードを上げることができます。
## 前提条件と制限
**前提条件**
+ アクティブな AWS アカウント
+ 基本的な理解は以下のとおりです。
+ AWS CDK
+ AWS CloudFormation
+ AWS CodePipeline
+ TypeScript
**制限**
このパターンでは、TypeScript のみに [AWS CDK](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-construct-library.html) を使用します。AWS CDK でサポートされている他の言語は対象外です。
**製品バージョン**
次のツールの最新バージョンを使用します。
+ AWS コマンドラインインターフェイス (AWS CLI)
+ cfn\$1nag
+ git-remote-codecommit
+ Node.js
## アーキテクチャ
**ターゲットテクノロジースタック**
+ AWS CDK
+ AWS CloudFormation
+ AWS CodeCommit
+ AWS CodePipeline
**ターゲットアーキテクチャ**
パイプラインは、AWS CodeCommit リポジトリ (`SampleRepository`) の変更によってトリガーされます。最初に、CodePipeline はアーティファクトをビルドし、それ自体を更新し、デプロイプロセスを開始します。作成されたパイプラインは、次の 3 つの独立した環境に解決策をデプロイします。
+ 開発 – アクティブな開発環境での 3 段階のコードチェック
+ テスト – 統合/リグレッションテスト環境
+ 本番 – 本番環境
開発段階には、リンティング、セキュリティ、ユニットテストの 3 つのステップが含まれます。これらの手順はプロセスを高速化するために並行して実行されます。パイプラインが動作するアーティファクトのみを提供するようにするため、プロセス内のステップが失敗するたびにパイプラインの実行が停止されます。開発段階のデプロイ後、パイプラインは検証テストを実行して結果を検証します。成功すると、パイプラインはデプロイ後の検証を含むテスト環境にアーティファクトをデプロイします。最後のステップは、アーティファクトを Prod 環境にデプロイすることです。
次の図は、CodeCommit リポジトリから CodePipeline によって実行されるビルドおよび更新プロセスまでのワークフロー、3 つの開発環境ステップ、および 3 つの環境のそれぞれにおけるその後のデプロイと検証を示しています。
![\[各工程にデプロイと検証を含む、リンティング、セキュリティ検査、ユニットテストを含む開発環境。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/d617e735-8624-4722-8a3d-073bcc356328/images/92504aac-03e3-4c95-b225-74505f8dd136.png)
## ツール
**AWS サービス**
+ [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/latest/guide/home.html) は、AWS クラウドインフラストラクチャをコードで定義してプロビジョニングするのに役立つソフトウェア開発フレームワークです。
+ [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) を使用すると、AWS リソースをセットアップし、迅速かつ一貫したプロビジョニングを行い、AWS アカウントとリージョン全体でライフサイクル全体にわたってリソースを管理できます。このパターンでは、CloudFormation テンプレートを使用して CodeCommit リポジトリと CodePipeline CI/CD パイプラインを作成できます。
+ [AWS CodeCommit](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html) は、独自のソースコントロールシステムを管理しなくても、Git リポジトリを非公開で保存および管理できるバージョン管理サービスです。
+ [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) は、ソフトウェアリリースのさまざまな段階を迅速にモデル化および設定し、ソフトウェアの変更を継続的にリリースするために必要なステップを自動化するのに役立ちます。
+ 「[AWS コマンドラインインターフェイス (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html)」は、オープンソースのツールであり、コマンドラインシェルのコマンドを使用して AWS サービスとやり取りすることができます。
**その他のツール**
+ [cfn\$1nag](https://github.com/stelligent/cfn_nag) は、CloudFormation テンプレートのパターンを探して潜在的なセキュリティ問題を特定するオープンソースのツールです。
+ [git-remote-codecommit](https://docs.aws.amazon.com/codecommit/latest/userguide/setting-up-git-remote-codecommit.html) は、Git を拡張して CodeCommit リポジトリからコードをプッシュおよびプルするためのユーティリティです。
+ [Node.js](https://nodejs.org/en/docs/) は、スケーラブルなネットワークアプリケーションを構築するために設計された、イベント駆動型の JavaScript ランタイム環境です。
**コード**
このパターンのコードは、GitHub 内の「[AWS CodePipeline with CI/CD practices](https://github.com/aws-samples/aws-codepipeline-cicd)」リポジトリで利用できます。
## ベストプラクティス
AWS Identity and Access Management (IAM) ポリシーなどのリソースを確認して、組織のベストプラクティスに沿っていることを確認します。
## エピック
### ツールをインストールする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| macOS または Linux にツールをインストールします。 | macOS または Linux を使用している場合は、任意のターミナルで次のコマンドを実行するか、[Homebrew for Linux](https://docs.brew.sh/Homebrew-on-Linux) を使用してツールをインストールできます。brew install
brew install git-remote-codecommit
brew install ruby brew-gem
brew-gem install cfn-nag
| DevOps エンジニア |
| AWS CLI をセットアップします。 | AWS CLI を設定するには、お使いのオペレーティングシステムの手順に従ってください。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-a-ci-cd-pipeline-by-using-aws-codepipeline-and-aws-cdk.html) | DevOps エンジニア |
### 初期のデプロイをセットアップする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| コードをダウンロードまたはクローンします。 | このパターンで使用されるコードを取得するには、以下のいずれかを実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-a-ci-cd-pipeline-by-using-aws-codepipeline-and-aws-cdk.html)git clone --depth 1 https://github.com/aws-samples/aws-codepipeline-cicd.git
クローニングしたリポジトリから `.git` ディレクトリを削除します。cd ./aws-codepipeline-cicd
rm -rf ./.git
後で、新しく作成した AWS CodeCommit リポジトリをリモートオリジンとして使用します。 | DevOps エンジニア |
| AWS アカウントに接続します。 | 一時的なセキュリティトークンまたはランディングゾーン認証を使用して接続できます。正しいアカウントと AWS リージョンを使用していることを確認するには、以下のコマンドを実行します。AWS_REGION="eu-west-1"
ACCOUNT_NUMBER=$(aws sts get-caller-identity --query Account --output text)
echo "${ACCOUNT_NUMBER}"
| DevOps エンジニア |
| 環境を起動します。 | AWS CDK 環境を起動するには、以下のコマンドを実行します。npm install
npm run cdk bootstrap "aws://${ACCOUNT_NUMBER}/${AWS_REGION}"
環境を正常に起動すると、次の出力が表示されるはずです。⏳ Bootstrapping environment aws://{account}/{region}...
✅ Environment aws://{account}/{region} bootstrappedAWS CDK 起動の詳細については、[AWS CDK のドキュメント](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html)を参照してください。 | DevOps エンジニア |
| テンプレートを合成します。 | AWS CDK アプリケーションを合成するには、`cdk synth` コマンドを使用します。npm run cdk synth
次のような出力が表示されます。Successfully synthesized to /aws-codepipeline-cicd/cdk.out
Supply a stack id (CodePipeline, Dev-MainStack) to display its template.
| DevOps エンジニア |
| CodePipeline スタックをデプロイします。 | CloudFormation テンプレートを起動して合成したので、デプロイできます。デプロイすると、CodePipeline パイプラインと CodeCommit リポジトリが作成されます。これらは、パイプラインのソースとトリガーになります。npm run cdk -- deploy CodePipeline --require-approval never
コマンドを実行すると、CodePipeline スタックが正常にデプロイされ、情報が出力されるはずです。`CodePipeline.RepositoryName` により、AWS アカウントの CodeCommit リポジトリの名前が表示されます。CodePipeline: deploying...
CodePipeline: creating CloudFormation changeset...
✅ CodePipeline
Outputs:
CodePipeline.RepositoryName = SampleRepository
Stack ARN:
arn:aws:cloudformation:REGION:ACCOUNT-ID:stack/CodePipeline/STACK-ID
| DevOps エンジニア |
| リモート CodeCommit リポジトリとブランチを設定します。 | デプロイが成功すると、CodePipeline はパイプラインの最初の実行を開始します。この実行は [AWS CodePipeline コンソール](https://eu-west-1.console.aws.amazon.com/codesuite/codepipeline/pipelines)で確認できます。AWS CDK と CodeCommit はデフォルトブランチを開始しないため、この最初のパイプライン実行は失敗し、次のエラーメッセージが返されます。The action failed because no branch named main was found in the selected AWS CodeCommit repository SampleRepository. Make sure you are using the correct branch name, and then try again. Error: null
このエラーを修正するには、リモートオリジンを `SampleRepository` として設定し、必要な `main` ブランチを作成します。RepoName=$(aws cloudformation describe-stacks --stack-name CodePipeline --query "Stacks[0].Outputs[?OutputKey=='RepositoryName'].OutputValue" --output text)
echo "${RepoName}"
#
git init
git branch -m master main
git remote add origin codecommit://${RepoName}
git add .
git commit -m "Initial commit"
git push -u origin main
| DevOps エンジニア |
### デプロイされた CodePipeline パイプラインをテストする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| 変更をコミットしてパイプラインを有効にします。 | 初期デプロイメントが成功すると、`SampleRepository` の `main` ブランチをソースブランチとして持つ完全な CI/CD パイプラインが完成するはずです。`main` ブランチに変更をコミットするとすぐに、パイプラインは次の一連のアクションを開始して実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-a-ci-cd-pipeline-by-using-aws-codepipeline-and-aws-cdk.html) | DevOps エンジニア |
### Makefile を使用してローカルでテストする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| Makefile を使用して開発プロセスを実行します。 | `make` コマンドを使用してパイプライン全体をローカルで実行することも、個別のステップ (`make linting` など) を実行することもできます。`make` を使用してテストするには、次のアクションを実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-a-ci-cd-pipeline-by-using-aws-codepipeline-and-aws-cdk.html) | アプリ開発者、DevOps エンジニア |
### リソースをクリーンアップする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| AWS CDK アプリケーションリソースを削除します。 | AWS CDK アプリをクリーンアップするには、次のコマンドを実行します。cdk destroy --all
起動中に作成された Amazon Simple Storage Service (Amazon S3) バケットは、自動的に削除されないことに注意してください。削除を許可する保持ポリシーが必要か、AWS アカウントで手動で削除する必要があります。 | DevOps エンジニア |
## トラブルシューティング
| 問題 | ソリューション |
| --- | --- |
| テンプレートが期待どおりに動作しません。 | 何か問題が発生し、テンプレートが機能しない場合は、次があることを確認してください。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-a-ci-cd-pipeline-by-using-aws-codepipeline-and-aws-cdk.html) |
## 関連リソース
+ [IAM アイデンティティセンターで一般的なタスクを開始する](https://docs.aws.amazon.com/singlesignon/latest/userguide/getting-started.html)
+ [AWS CodePipeline ドキュメント](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)
+ [AWS CDK](https://docs.aws.amazon.com/cdk/v2/guide/home.html)
# Terraform を使用してエンタープライズ規模で一元化されたログ記録を設定する
*Amazon Web Services、Aarti Rajput、Yashwant Patel、Nishtha Yadav*
## 概要
一元化されたログ記録は、組織のクラウドインフラストラクチャにとって不可欠です。これにより、組織の運用、セキュリティ、コンプライアンスを可視化できるためです。組織が複数のアカウントにまたがって AWS 環境をスケールするにつれて、構造化ログ管理戦略は、セキュリティ運用の実行、監査要件を満たすこと、運用上の優秀性を達成するための基本となります。
このパターンは、複数の AWS アカウント および サービスからのログを一元化するためのスケーラブルで安全なフレームワークを提供し、複雑な AWS デプロイ全体でエンタープライズ規模のログ記録管理を可能にします。このソリューションは、Terraform を使用して自動化されます。Terraform は HashiCorp の Infrastructure as Code (IaC) ツールであり、一貫性のある反復可能なデプロイを保証し、手動設定を最小限に抑えます。Amazon CloudWatch Logs、Amazon Data Firehose、Amazon Simple Storage Service (Amazon S3) を組み合わせることで、以下を実現する堅牢なログ集約と分析パイプラインを実装できます。
+ での組織全体の一元化されたログ管理 AWS Organizations
+ 組み込みのセキュリティコントロールを使用した自動ログ収集
+ スケーラブルなログ処理と耐久性のあるストレージ
+ シンプルなコンプライアンスレポートと監査証跡
+ リアルタイムの運用に関するインサイトとモニタリング
このソリューションは、CloudWatch Logs を介して Amazon Elastic Kubernetes Service (Amazon EKS) コンテナ、 AWS Lambda 関数、Amazon Relational Database Service (Amazon RDS) データベースインスタンスからログを収集します。CloudWatch サブスクリプションフィルターを使用して、これらのログを専用のログ記録アカウントに自動的に転送します。Firehose は、Amazon S3 への高スループットのログストリーミングパイプラインを管理し、長期保存を可能にします。Amazon Simple Queue Service (Amazon SQS) は、オブジェクトの作成時に Amazon S3 イベント通知を受信するように設定されています。これにより、以下を含む分析サービスとの統合が可能になります。
+ ログ検索、視覚化、リアルタイム分析のための Amazon OpenSearch Service
+ SQL ベースクエリ用の Amazon Athena
+ 大規模な処理のための Amazon EMR
+ カスタム変換のための Lambda
+ ダッシュボード用の Amazon Quick Sight
すべてのデータは AWS Key Management Service (AWS KMS) を使用して暗号化され、インフラストラクチャ全体が Terraform を使用して環境間で一貫した設定でデプロイされます。
この一元的なログ記録アプローチにより、組織はセキュリティ体制を改善し、コンプライアンス要件を維持し、 AWS インフラストラクチャ全体の運用効率を最適化できます。
## 前提条件と制限
**前提条件**
+ [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/getting-started-with-control-tower.html) を使用して構築された組織のランディングゾーン
+ 必要なアカウントでデプロイおよび設定された [Account Factory for Terraform (AFT)](https://docs.aws.amazon.com/controltower/latest/userguide/aft-getting-started.html)
+ インフラストラクチャをプロビジョニングするための [Terraform](https://developer.hashicorp.com/terraform/downloads)
+ クロスアカウントアクセス用の [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-started.html) ロールとポリシー
アカウント AWS Control Tower、AFT、およびアプリケーションアカウントを設定する手順については、[「エピック」セクション](#set-up-centralized-logging-at-enterprise-scale-by-using-terraform-epics)を参照してください。
**必要なアカウント**
の組織には、次のアカウントを含める AWS Organizations 必要があります。
+ **アプリケーションアカウント** – AWS のサービス (Amazon EKS、Lambda、Amazon RDS) が実行され、ログを生成する 1 つ以上のソースアカウント
+ **ログアーカイブアカウント** – 一元化されたログの保管と管理を行うための専用アカウント
**製品バージョン**
+ [AWS Control Tower バージョン 3.1](https://docs.aws.amazon.com/controltower/latest/userguide/2023-all.html#lz-3-1) 以降
+ [Terraform バージョン 0.15.0](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli) 以降
## アーキテクチャ
次の図は、複数のアプリケーションアカウントから専用のログアーカイブアカウントにログを収集、処理、保存するためのスケーラブルなソリューションを提供する一 AWS 元的なログ記録アーキテクチャを示しています。このアーキテクチャは AWS のサービス、Amazon RDS、Amazon EKS、Lambda などの からのログを効率的に処理し、合理化されたプロセスを通じて Log Archive アカウントのリージョン S3 バケットにルーティングします。
![\[複数のアプリケーションアカウントからログを収集する AWS の一元化されたログ記録アーキテクチャ。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/9fc71a10-65d6-437b-9128-cc27bda11af4/images/2e916040-0f11-4712-a8dd-31c95194ce5d.png)
ワークフローには 5 つのプロセスが含まれます。
1. **ログフロープロセス**
+ ログフロープロセスはアプリケーションアカウントで開始されます。アプリケーションアカウントでは、一般ログ、エラーログ、監査ログ、Amazon RDS からのスロークエリログ、Amazon EKS からのコントロールプレーンログ、Lambda からの関数の実行ログとエラーログなど、さまざまなタイプのログ AWS のサービス が生成されます。
+ CloudWatch は最初の収集ポイントとして機能します。これらのログは、各アプリケーションアカウント内のロググループレベルで収集されます。
+ CloudWatch では、[サブスクリプションフィルター](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Subscriptions.html)によって、中央アカウントに転送するログを判断します。これらのフィルターを使用すると、ログ転送をきめ細かく制御できるため、正確なログパターンや完全なログストリームを指定して一元化できます。
1. **クロスアカウントログ転送**
+ ログはログアーカイブアカウントに移動します。CloudWatch サブスクリプションフィルターによって、クロスアカウント転送が容易になり、リージョンコンテキストが保持されます。
+ このアーキテクチャは、さまざまなログソースを効率的に処理するために複数の並列ストリームを確立して、最適なパフォーマンスとスケーラビリティを確保します。
1. **ログアーカイブアカウントでのログ処理**
+ ログアーカイブアカウントでは、Firehose が受信ログストリームを処理します。
+ 各リージョンは、必要に応じてログを変換、または強化できる専用の Firehose 配信ストリームを維持します。
+ これらの Firehose ストリームは、データ主権要件を維持するために、ソースアプリケーションアカウント (図のリージョン A) と同じリージョンにあるログアーカイブアカウントの S3 バケットに処理されたログを配信します。
1. **通知と追加のワークフロー**
+ ログが宛先の S3 バケットに到達すると、アーキテクチャは Amazon SQS を使用して通知システムを実装します。
+ リージョン SQS キューは、非同期処理を有効にし、保存されたログに基づいて追加のワークフロー、分析、またはアラートシステムをトリガーできます。
1. **AWS KMS セキュリティ用**
このアーキテクチャには、セキュリティ AWS KMS のために が組み込まれています。 は S3 バケットの暗号化キー AWS KMS を提供します。これにより、保存されているすべてのログが保存中の暗号化を維持するとともに、リージョンでの暗号化を保つことで、データレジデンシー要件を満たすことが保証されます。
## ツール
**AWS のサービス**
+ [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) は、ログ、メトリクス、イベントの形式でモニタリングおよび運用データを収集するモニタリングおよびオブザーバビリティサービスです。AWS サーバーとオンプレミスサーバーで実行される AWS リソース、アプリケーション、サービスの統合ビューを提供します。
+ [CloudWatch Logs サブスクリプションフィルター](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/SubscriptionFilters.html)は、受信ログイベントのパターンに一致し、一致するログイベントを指定された AWS リソースに配信して、さらなる処理または分析を行う式です。
+ [AWS Control Tower Account Factory For Terraform (AFT)](https://docs.aws.amazon.com/controltower/latest/userguide/aft-overview.html) は、アカウントのプロビジョニングとカスタマイズに役立つ Terraform パイプラインを設定します AWS Control Tower。AFT は Terraform ベースのアカウントプロビジョニングを提供し、アカウントを管理できるようにします AWS Control Tower。
+ [Amazon Data Firehose](https://docs.aws.amazon.com/firehose/latest/dev/what-is-this-service.html) は、Amazon S3、Amazon Redshift、Amazon OpenSearch Service などの送信先にリアルタイムのストリーミングデータを配信します。これはデータのスループットに合わせて自動的に拡張し、継続的な管理作業は不要です。
+ [Amazon Elastic Kubernetes Service (Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html) は、Kubernetes を使用してコンテナ化されたアプリケーションのデプロイ、管理、スケーリングを容易にするマネージドコンテナオーケストレーションサービスです。Kubernetes コントロールプレーンノードの可用性とスケーラビリティを自動で管理します。
+ [AWS Key Management Service (AWS KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) は、データを暗号化するための暗号化キーを作成および制御します。 は、他の と AWS KMS 統合 AWS のサービス して、これらのサービスで保存するデータを保護します。
+ [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理をする必要なくコードを実行できるサーバーレスコンピューティングサービスです。各トリガーに応じてコードを実行することでアプリケーションを自動でスケーリングします。使用したコンピューティング時間に対してのみ料金が発生します。
+ [Amazon Relational Database Service (Amazon RDS)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html) は、クラウドでリレーショナルデータベースを簡単にセットアップし、運用し、スケーリングすることのできるマネージドリレーショナルデータベースです。時間のかかる管理タスクを自動化しながら、コスト効率が高くサイズ変更可能な容量を提供します。
+ [Amazon Simple Queue Service (Amazon SQS)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html) は、マイクロサービス、分散システム、およびサーバーレスアプリケーションの疎結合化とスケールを可能にするメッセージキューイングサービスです。メッセージ指向ミドルウェアの管理と運用の複雑さを解消します。
+ [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) は、スケーラビリティ、データ可用性、セキュリティ、パフォーマンスを提供するクラウドベースのオブジェクトストレージサービスです。ウェブ上の任意の場所から、任意の量のデータを保存および取得できます。
**その他のツール**
+ [Terraform](https://www.terraform.io/) は HashiCorp の infrastructure as code (IaC) ツールで、クラウドとオンプレミスのリソースの作成と管理を支援します。
**Code**
このパターンのコードは GitHub 内の [Centralized logging](https://github.com/aws-samples/sample-centralised-logging-at-enterprise-scale-using-terraform) リポジトリで入手できます。
## ベストプラクティス
+ [の 1 つの組織 AWS アカウント で複数の を使用します AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts.html)。この方法により、アカウント間で一元的な管理と標準化されたログ記録が可能になります。
+ [S3 バケットのバージョニング、ライフサイクルポリシー、クロスリージョンレプリケーション](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html)を設定します。セキュリティとコンプライアンスのため、暗号化とアクセスのログ記録を実装します。
+ 標準のタイムスタンプとフィールドを含む、[JSON 形式を使用した一般的なログ記録標準](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_AnalyzeLogData-discoverable-fields.html)を実装します。追跡と分析を容易にするために、一貫したプレフィックス構造と相関 ID を使用します。
+ [AWS KMS 暗号化と最小特権アクセスを使用してセキュリティコントロール](https://docs.aws.amazon.com/AmazonS3/latest/userguide/security-best-practices.html)を有効にします。セキュリティを強化するために、 AWS CloudTrail モニタリングと定期的なキーローテーションを維持します。
+ 配信追跡用の [CloudWatch メトリクスとアラート](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)を設定します。自動通知を使用してコストとパフォーマンスをモニタリングします。
+ コンプライアンス要件を満たすように [Amazon S3 保持ポリシー](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html)を設定し、Amazon S3 サーバーアクセスログ記録を有効にして、S3 バケットに対して行われたすべてのリクエストを追跡します。S3 バケットポリシーとライフサイクルルールのドキュメントを維持管理します。アクセスログ、バケットのアクセス許可、ストレージ設定を定期的に見直して、コンプライアンスと[セキュリティのベストプラクティス](https://docs.aws.amazon.com/AmazonS3/latest/userguide/security-best-practices.html)を確保します。
## エピック
### セットアップ AWS Control Tower、AFT、およびアプリケーションアカウント
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| AFT を使用して AWS Control Tower 環境をセットアップします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-centralized-logging-at-enterprise-scale-by-using-terraform.html) | AWS 管理者 |
| 組織のリソース共有を有効にします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-centralized-logging-at-enterprise-scale-by-using-terraform.html) | AWS 管理者 |
| アプリケーションアカウントを検証またはプロビジョニングします。 | ユースケース用に新しいアプリケーションアカウントをプロビジョニングするには、AFT を介してアカウントを作成します。詳細については、 AWS Control Tower ドキュメント[の「AFT を使用して新しいアカウントをプロビジョニング](https://docs.aws.amazon.com/controltower/latest/userguide/aft-provision-account.html)する」を参照してください。 | AWS 管理者 |
### アプリケーションアカウントの設定ファイルを設定する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| `Application_account` フォルダの内容を `aft-account-customizations` リポジトリにコピーします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-centralized-logging-at-enterprise-scale-by-using-terraform.html) | DevOps エンジニア |
| アプリケーションアカウントを設定するための入力パラメータを確認して編集します。 | このステップでは、CloudWatch ロググループ、CloudWatch サブスクリプションフィルター、IAM ロールとポリシー、Amazon RDS、Amazon EKS、Lambda 関数の設定詳細など、アプリケーションアカウントにリソースを作成するための設定ファイルを設定します。`aft-account-customizations` リポジトリの `Application_account` フォルダで、組織の要件に基づいて `terraform.tfvars` ファイルの入力パラメータを設定します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-centralized-logging-at-enterprise-scale-by-using-terraform.html) | DevOps エンジニア |
### ログアーカイブアカウントの設定ファイルを設定する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| `Log_archive_account` フォルダの内容を `aft-account-customizations` リポジトリにコピーします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-centralized-logging-at-enterprise-scale-by-using-terraform.html) | DevOps エンジニア |
| ログアーカイブアカウントを設定するための入力パラメータを確認して編集します。 | このステップでは、Firehose 配信ストリーム、S3 バケット、SQS キュー、IAM ロールとポリシーなど、ログアーカイブアカウントにリソースを作成するための設定ファイルを設定します。`aft-account-customizations` リポジトリの `Log_archive_account` フォルダで、組織の要件に基づいて `terraform.tfvars` ファイルの入力パラメータを設定します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-centralized-logging-at-enterprise-scale-by-using-terraform.html) | DevOps エンジニア |
### Terraform コマンドを実行してリソースをプロビジョニングする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| オプション 1 – AFT から Terraform 設定ファイルをデプロイします。 | AFT では、設定変更を含むコードを GitHub `aft-account-customizations` リポジトリにプッシュすると、AFT パイプラインがトリガーされます。AFT は変更を自動的に検出し、アカウントのカスタマイズプロセスを開始します。Terraform (`terraform.tfvars`) ファイルに変更を加えたら、変更をコミットして `aft-account-customizations` リポジトリにプッシュします。$ git add *
$ git commit -m "update message"
$ git push origin main
別のブランチ (`dev` など) を使用している場合は、`main` をブランチ名に置き換えます。 | DevOps エンジニア |
| オプション 2 – Terraform 設定ファイルを手動でデプロイします。 | AFT を使用していない場合、またはソリューションを手動でデプロイする場合は、`Application_account` および `Log_archive_account` フォルダから次の Terraform コマンドを使用できます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-centralized-logging-at-enterprise-scale-by-using-terraform.html) | DevOps エンジニア |
### リソースを検証する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| サブスクリプションフィルターを検証します。 | サブスクリプションフィルターがアプリケーションアカウントのロググループからログアーカイブアカウントにログを正しく転送することを検証するには、以下の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-centralized-logging-at-enterprise-scale-by-using-terraform.html) | DevOps エンジニア |
| Firehose ストリームを確認します。 | ログアーカイブアカウントの Firehose ストリームがアプリケーションログを正常に処理することを確認するには、以下の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-centralized-logging-at-enterprise-scale-by-using-terraform.html) | DevOps エンジニア |
| 一元化された S3 バケットを検証します。 | 一元化された S3 バケットがログを適切に受信して整理することを確認するには、以下の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-centralized-logging-at-enterprise-scale-by-using-terraform.html) | DevOps エンジニア |
| SQS キューを検証します。 | SQS キューが新しいログファイルの通知を受信することを確認するには、以下の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-centralized-logging-at-enterprise-scale-by-using-terraform.html) | DevOps エンジニア |
### リソースをクリーンアップする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| オプション 1 – AFT から Terraform 設定ファイルを削除します。 | Terraform 設定ファイルを削除して変更をプッシュすると、AFT は自動的にリソース削除プロセスを開始します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-centralized-logging-at-enterprise-scale-by-using-terraform.html) | DevOps エンジニア |
| オプション 2 – Terraform リソースを手動でクリーンアップします。 | AFT を使用していない場合、またはリソースを手動でクリーンアップする場合は、`Application_account` および `Log_archive_account` フォルダから次の Terraform コマンドを使用します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-centralized-logging-at-enterprise-scale-by-using-terraform.html) | DevOps エンジニア |
## トラブルシューティング
| 問題 | ソリューション |
| --- | --- |
| CloudWatch Logs の送信先が作成されていないか、非アクティブです。 | 以下を確認してください。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-centralized-logging-at-enterprise-scale-by-using-terraform.html) |
| サブスクリプションフィルターが失敗した、または保留中のステータスのままです。 | 以下をチェックしてください:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-centralized-logging-at-enterprise-scale-by-using-terraform.html) |
| Firehose 配信ストリームに受信レコードが表示されません。 | 以下について確認します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-centralized-logging-at-enterprise-scale-by-using-terraform.html) |
## 関連リソース
+ [Terraform infrastructure setup](https://developer.hashicorp.com/terraform/tutorials/aws-get-started) (Terraform ドキュメント)
+ [Account AWS Control Tower Factory for Terraform (AFT) をデプロイ](https://docs.aws.amazon.com/controltower/latest/userguide/aft-getting-started.html)する (AWS Control Tower ドキュメント)
+ [IAM チュートリアル: IAM ロール AWS アカウント を使用して 全体でアクセスを委任](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html)する (IAMdocumentation)
# cert-managerと Let's Encrypt を使用して Amazon EKS のアプリケーションのエンドツーエンド暗号化を設定
*Mahendra Revanasiddappa と Vasanth Jeyaraj、Amazon Web Services*
## 概要
エンドツーエンド暗号化の実装は複雑で、マイクロサービスアーキテクチャ内の各アセットの証明書を管理する必要があります。Amazon Web Services (AWS) ネットワークの端にあるTransport Layer Security (TLS) 接続は、Network Load Balancer または Amazon API Gateway を使用して終了できますが、一部の組織ではエンドツーエンドの暗号化が必要です。
このパターンでは、入力に NGINX Ingress コントローラーを使用します。これは、Kubernetes Ingress を作成する場合、イングレスリソースがNetwork Load Balancer を使用するためです。Network Load Balancer は、クライアント証明書のアップロードを許可しません。したがって、Kubernetes Ingress では相互TLSを実現できません。
このパターンは、アプリケーション内のすべてのマイクロサービス間の相互認証を必要とする組織を対象としています。相互 TLS は、ユーザー名やパスワードを管理する負担を軽減し、すぐに使えるセキュリティフレームワークを使用することもできます。このパターンのアプローチは、接続されているデバイスが多数ある組織や、厳格なセキュリティガイドラインに準拠する必要がある場合にも適合します。
このパターンは、Amazon Elastic Kubernetes Service (Amazon EKS) 上で実行されるアプリケーションにエンドツーエンドの暗号化を実装することで、組織のセキュリティ体制強化に役立ちます。このパターンでは、「[Amazon EKS リポジトリの GitHub エンドツーエンド暗号化](https://github.com/aws-samples/end-to-end-encryption-on-amazon-eks#readme)」 のサンプルアプリケーションとコードを提供し、マイクロサービスが Amazon EKS でエンドツーエンド暗号化を使用してどのように実行されるかを示します。このパターンのアプローチでは、Kubernetes のアドオンである「[cert-manager](https://cert-manager.io/docs/)」 を使用し、認証局 (CA) として 「[Let's Encrypt](https://letsencrypt.org/)」 を使用します。Let's Encrypt は費用対効果の高い証明書管理ソリューションで、90 日間有効な証明書を無料で提供しています。Cert-manager は、新しいマイクロサービスが Amazon EKS にデプロイされたときに、証明書のオンデマンドプロビジョニングとローテーションを自動化します。
**対象者**
このパターンは、Kubernetes、TLS、Amazon Route 53、およびドメインネームシステム (DNS) の使用経験があるユーザーに推奨されます。
## 前提条件と制限事項
**前提条件**
+ アクティブな AWS アカウント。
+ 既存の Amazon EKS クラスター。
+ macOS、Linux、または Windows にインストールされ、設定された AWS コマンドラインインターフェイス (AWS CLI) バージョン 1.7 以降。
+ Amazon EKS クラスターにアクセスするために、インストールおよび設定された `kubectl` コマンドラインユーティリティ。これについての詳細は、Amazon EKS ドキュメントの「[kubectl のインストール](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)」 を参照してください。
+ アプリケーションをテストするための既存のアプリケーション名です。これについての詳細は、Amazon Route 53 デベロッパーガイドの「 [Amazon Route 53 を使用したドメイン名の登録](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/registrar.html)」を参照してください。
+ ローカルマシンにインストールされている最新の 「[Helm](https://docs.aws.amazon.com/eks/latest/userguide/helm.html)」 バージョン。これについての詳細は、Amazon EKS ドキュメントの「[Amazon EKS での Helm の使用](https://docs.aws.amazon.com/eks/latest/userguide/helm.html)」 と GitHub 「[Helm](https://github.com/helm/helm)」 リポジトリを参照してください。
+ ローカルマシンに複製された GitHub 「[Amazon EKS リポジトリの エンドツーエンド暗号化](https://github.com/aws-samples/end-to-end-encryption-on-amazon-eks#readme)」。
+ 複製された GitHub 「[Amazon EKS リポジトリのエンドツーエンド暗号化](https://github.com/aws-samples/end-to-end-encryption-on-amazon-eks#readme)」から `policy.json` と `trustpolicy.json` のファイルの以下の値を置き換えます:
+ `` — ソリューションをデプロイするアカウントの AWS アカウント ID と置き換えます。
+ `` — ドメイン名の Route 53 ゾーン ID に置き換えます。
+ `` — Amazon EKS ノードに関連付けられている AWS 識別とアクセス管理(IAM) ロールの名前に置き換えます。
+ `` — NGINX Ingress コントローラーとサンプルアプリケーションをデプロイする Kubernetes 名前空間に置き換えます。
+ `` — Route 53 の DNS ドメイン名に置き換えます。
**制限事項**
+ このパターンでは、証明のローテーション方法を説明するものではなく、Amazon EKS のマイクロサービスで証明書を使用する方法のみを示しています。
## アーキテクチャ
次の図表は、このパターンのアプリケーションのワークフローとアーキテクチャコンポーネントを示しています。
![\[cert-manager と Let's Encrypt を使用して Amazon EKS のアプリケーションの暗号化を設定するワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/9aa3ee9e-73db-41f5-a467-b5c47fef496e/images/40692ede-6fb3-474e-8c9e-85c51529e8ad.png)
この図表は、次のワークフローを示しています:
1. クライアントは DNS 名へのアプリケーションへのアクセスリクエストを送信します。
1. Route 53 レコードは Network Load Balancer の CNAMEです。
1. Network Load Balancer は、TLS リスナーで設定された NGINX Ingress コントローラーにリクエストを転送します。NGINX Ingress コントローラーと Network Load Balancer 間の通信は HTTPS プロトコルに従います。
1. NGINX Ingress Controller は、アプリケーションサービスへのクライアントのリクエストに基づいてパスベースのルーティングを実行します。
1. アプリケーションサービスはリクエストをアプリケーションポッドに転送します。このアプリケーションは、シークレットを呼び出すことで。同じ証明書を使用するように設計されています。
1. ポッドは cert-managerの証明書を使用してサンプルアプリケーションを実行します。NGINX Ingress コントローラーとポッド間の通信には HTTPS が使用されます。
|
|
| 注: cert-managerはその独自の名前空間で実行されます。Kubernetes クラスターロールを使用して、証明書を特定の名前空間のシークレットとしてプロビジョニングします。これらの名前空間はアプリケーションポッドと NGINX Ingress コントローラーにアタッチできます。 |
| --- |
## ツール
**AWS サービス**
+ [Amazon Elastic Kubernetes Service (Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html) は、AWS で Kubernetes を簡単に実行できるようにするマネージド型サービスです。ユーザー独自の Kubernetes コントロールプレーンまたはノードをインストール、操作、維持する必要はありません。
+ [Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html) は、受信したトラフィックを複数のターゲット、コンテナ、IPアドレスに自動的に分散します。
+ 「[AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)」は、AWS リソースへのアクセスを安全に管理し、誰が認証され、使用する権限があるかを制御するのに役立ちます。
+ [Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) は、高可用性でスケーラブルな DNS Web サービスです。
**その他のツール**
+ 「[cert-manager](https://cert-manager.io/docs/installation/supported-releases/)」 は Kubernetes のアドオンで、証明書をリクエストして Kubernetes コンテナに配布し、証明書の更新を自動化します。
+ 「[NGINX Ingress Controller](https://kubernetes.github.io/ingress-nginx/) 」は、Kubernetes およびコンテナ化された環境におけるクラウドネイティブアプリケーション向けのトラフィック管理ソリューションです。
## エピック
### Route 53 でパブリックホストゾーンを作成して設定
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| Route 53 にドメインのパブリックホストゾーンを作成します。 | AWS マネジメントコンソールにサインインし、Amazon Route 53 コンソールを開き、［**ホストゾーン**］を選択し、［**ホストゾーンの作成**］を選択します。パブリックホストゾーンを作成し、ゾーン ID を記録します。これについての詳細は、Amazon Route 53 ドキュメントの「[公開ホストゾーンの作成](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingHostedZone.html)」を参照してください。ACME DNS01 は DNS プロバイダーを使用して、証明書発行用の cert-manager にチャレンジを投稿します。このチャレンジでは、ドメイン名の TXT レコードに特定の値を入力して、そのドメイン名の DNS を管理していることを証明するよう求められます。Let's Encrypt が ACME クライアントにトークンを渡した後、クライアントはそのトークンとアカウントキーから得た TXT レコードを作成し、そのレコードを `_acme-challenge.` に保存します。次に、Let's Encrypt は DNS にそのレコードを問い合わせます。一致するものが見つかったら、証明書の発行に進むことができます。 | AWS DevOps |
### 証明書マネージャーがパブリックホストゾーンにアクセスできるように IAM ロールを設定する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| cert-manager 用の IAM ポリシーを作成します。 | ユーザーが Route 53 ドメインを所有していることを検証する権限を cert-manager に提供するには、IAM ポリシーが必要です。`policy.json` のサンプル IAM ポリシーが、複製されたGitHub「[ Amazon EKS リポジトリのエンドツーエンドの暗号化](https://github.com/aws-samples/end-to-end-encryption-on-amazon-eks#readme)」リポジトリの `1-IAMRole` ディレクトリにあります。次の AWS CLI コマンドを使用して、IAM ポリシーを作成します。aws iam create-policy \
--policy-name PolicyForCertManager \
--policy-document file://policy.json
| AWS DevOps |
| cert-managerの IAM ロールを作成します。 | IAM ポリシーを作成したら、IAM ロールを作成する必要があります。`trustpolicy.json` サンプル IAM ロールが `1-IAMRole` ディレクトリに提供されます。IAM ロールを作成するには、次のコマンドをAWS CLIに入力します。aws iam create-role \
--role-name RoleForCertManager \
--assume-role-policy-document file://trustpolicy.json
| AWS DevOps |
| ロールへのポリシーの付与 | AWS CLI に以下のコマンドを入力して、 IAM ロールにIAMポリシーをアタッチします。`AWS_ACCOUNT_ID` を自分の AWS アカウントのID に置き換えます。aws iam attach-role-policy \
--policy-arn arn:aws:iam::AWS_ACCOUNT_ID:policy/PolicyForCertManager \
--role-name RoleForCertManager
| AWS DevOps |
### Amazon EKS で NGINX Ingress コントローラーをセットアップする
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| NGINX Ingress コントローラーをデプロイします。 | Helm を使用する `nginx-ingress` の最新バージョンをインストールします。デプロイする前に、要件に応じて `nginx-ingress` の設定を変更できます。このパターンでは、`5-Nginx-Ingress-Controller` ディレクトリの使用可能の注釈付き、内部向けのNetwork Load Balancer を使用します。 `5-Nginx-Ingress-Controller` ディレクトリから次の Helm コマンドを実行して、 NGINX Ingress コントローラーをインストールします。`helm install test-nginx nginx-stable/nginx-ingress -f 5-Nginx-Ingress-Controller/values_internal_nlb.yaml` | AWS DevOps |
| コントローラーがインストールされていることを確認します。 | `helm list` コマンドを入力します。出力では NGINX Ingress コントローラーがインストールされていることが表示されるはずです。 | AWS DevOps |
| Route 53 A レコードを作成します。 | A レコードは NGINX Ingress コントローラーによって作成された Network Load Balancer を指します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-end-to-end-encryption-for-applications-on-amazon-eks-using-cert-manager-and-let-s-encrypt.html) | AWS DevOps |
### Amazon EKS に NGINX 仮想サーバーをセットアップ
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| NGINX 仮想サーバーをデプロイします。 | NGINX VirtualServer リソースは、イングレスリソースの代替となるロードバランシング設定です。NGINX VirtualServer リソースを作成するための設定は、`6-Nginx-Virtual-Server` ディレクトリの `nginx_virtualserver.yaml` のファイルで利用可能です。NGINX VirtualServer リソースを作成するには、`kubectl` に以下のコマンドを入力します。`kubectl apply -f nginx_virtualserver.yaml``nginx_virtualserver.yaml` ファイルのアプリケーションドメイン名、証明書シークレット、アプリケーションサービス名の更新を必ず行ってください。 | AWS DevOps |
| NGINX 仮想サーバーが作成されていることを確認します。 | `kubectl` にある以下のコマンドを入力して、NGINX VirtualServer リソースが正常に作成されたことを確認します。`kubectl get virtualserver``Host` 列がアプリケーションのドメイン名と一致することを確認します。 | AWS DevOps |
| TLS を有効にして NGINX ウェブサーバーをデプロイします。 | このパターンでは、TLS が有効になっている NGINX Web サーバーを、エンドツーエンドの暗号化をテストするためのアプリケーションとして使用します。テストアプリケーションのデプロイに必要な設定ファイルは、`demo-webserver` のディレクトリに使用可能です。 アプリケーションのテストを行うには、次のコマンドを`kubectl` に入力します。`kubectl apply -f nginx-tls-ap.yaml` | AWS DevOps |
| テストアプリケーションリソースが作成されたことを確認します。 | 次のコマンドを `kubectl` に入力して、テストアプリケーションに必要なリソースが作成されていることを確認します[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-end-to-end-encryption-for-applications-on-amazon-eks-using-cert-manager-and-let-s-encrypt.html) | AWS DevOps |
| アプリケーションを検証します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-end-to-end-encryption-for-applications-on-amazon-eks-using-cert-manager-and-let-s-encrypt.html) | AWS DevOps |
## 関連リソース
「**AWS リソース**」
+ 「[Amazon Route 53 コンソールを使用したレコードの作成](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-creating.html)」 (Amazon Route 53 ドキュメント)
+ 「[Amazon EKS の NGINX イングレスコントローラーでのNetwork Load Balancer の使用](https://aws.amazon.com/blogs/opensource/network-load-balancer-nginx-ingress-controller-eks/)」 (AWS ブログ投稿)
**その他のリソース**
+ 「[Route 53](https://cert-manager.io/docs/configuration/acme/dns01/route53/)」 (cert-managerドキュメント)
+ 「[DNS01 チャレンジプロバイダーの設定](https://cert-manager.io/docs/configuration/acme/dns01/)」 (cert-managerドキュメント)
+ 「[Let’s Encrypt DNS チャレンジ](https://letsencrypt.org/docs/challenge-types/#dns-01-challenge)」(Let’s Encrypt ドキュメント)
# Flux を使用して Amazon EKS マルチテナントアプリケーションのデプロイを簡素化する
*Nadeem Rahaman、Aditya Ambati、Aniket Dekate、Shrikant Patil、Amazon Web Services*
## 概要
製品やサービスを提供する多くの企業は、社内のビジネス機能間のデータバリアを維持するためにデータ規制が必要とされる業界です。このパターンでは、Amazon Elastic Kubernetes Service (Amazon EKS) のマルチテナンシー機能を使用して、単一の Amazon EKS クラスターを共有するテナントまたはユーザー間で論理的および物理的な分離を実現するデータプラットフォームを構築する方法について説明します。このパターンは、以下のアプローチを通じて分離を実現します。
+ Kubernetes 名前空間の分離
+ ロールベースのアクセスコントロール (RBAC)
+ ネットワークポリシー
+ リソースクォータ
+ AWS Identity and Access Management サービスアカウント (IRSA) の (IAM) ロール
また、このソリューションは Flux を使用して、アプリケーションをデプロイするときにテナント設定をイミュータブルに保ちます。設定に Flux `kustomization.yaml` ファイルを含むテナントリポジトリを指定することにより、テナントアプリケーションをデプロイできます。
このパターンでは、以下を実装します。
+ AWS CodeCommit Terraform スクリプトを手動でデプロイすることで作成されるリポジトリ、 AWS CodeBuild プロジェクト、 AWS CodePipeline パイプライン。
+ テナントをホストするために必要なネットワークコンポーネントとコンピューティングコンポーネント。これらは、Terraform を使用して CodePipeline と CodeBuild を介して作成されます。
+ Helm チャートで設定されるテナント名前空間、ネットワークポリシー、リソースクォータ。
+ Flux を使用してデプロイされた、異なるテナントに属するアプリケーション。
固有の要件とセキュリティ上の考慮事項に基づいて、マルチテナンシー用に独自のアーキテクチャを慎重に計画および構築することをお勧めします。このパターンは、実装の開始点となります。
## 前提条件と制限事項
**前提条件**
+ アクティブな AWS アカウント
+ AWS Command Line Interface (AWS CLI) バージョン 2.11.4 以降、[インストール](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)および[設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html)済み
+ ローカルマシンにインストールされた [Terraform](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli) バージョン 0.12 以降
+ [Terraform AWS Provider](https://registry.terraform.io/providers/hashicorp/aws/latest) バージョン 3.0.0 以降
+ [Kubernetes Provider](https://registry.terraform.io/providers/hashicorp/kubernetes/latest/docs) バージョン 2.10 以降
+ [Helm Provider](https://registry.terraform.io/providers/hashicorp/helm/latest/docs) バージョン 2.8.0 以降
+ [Kubectl Provider](https://registry.terraform.io/providers/gavinbunney/kubectl/latest/docs) バージョン 1.14 以降
**制限事項**
+ **Terraform 手動デプロイの依存関係: **CodeCommit リポジトリ、CodeBuild プロジェクト、CodePipeline パイプラインの作成を含むワークフローの初期セットアップは、Terraform の手動デプロイに依存します。インフラストラクチャの変更に手動で介入する必要があるため、自動化とスケーラビリティの面で潜在的な制限が生じます。
+ **CodeCommit リポジトリの依存関係: **ワークフローは、ソースコード管理ソリューションとして CodeCommit リポジトリに依存し、密接に結合されています AWS のサービス。
## アーキテクチャ
**ターゲットアーキテクチャ**
このパターンでは、次の図に示すように、3 つのモジュールをデプロイして、データプラットフォームのパイプライン、ネットワーク、コンピューティングインフラストラクチャを構築します。
*パイプラインアーキテクチャ:*
![\[Amazon EKS マルチテナントアーキテクチャのパイプラインインフラストラクチャ\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/97b700a7-74b6-4f9d-b53a-76de42409a8e/images/76a4a23d-4275-427a-ae36-51c9a3803128.png)
*ネットワークアーキテクチャ:*
![\[Amazon EKS マルチテナントアーキテクチャのネットワークインフラストラクチャ\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/97b700a7-74b6-4f9d-b53a-76de42409a8e/images/e542249a-19a3-4c99-b6f5-fdf80fee4edf.png)
*コンピューティングアーキテクチャ:*
![\[Amazon EKS マルチテナントアーキテクチャのコンピューティングインフラストラクチャ\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/97b700a7-74b6-4f9d-b53a-76de42409a8e/images/91bd1ca8-17f0-433c-8600-4c8e6c474e31.png)
## ツール
**AWS のサービス**
+ [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) は完全マネージド型の構築サービスです。ソースコードのコンパイル、ユニットテストの実行、すぐにデプロイできるアーティファクトの生成を行います。
+ [AWS CodeCommit](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html) は、独自のソースコントロールシステムを管理することなく、Git リポジトリを非公開で保存および管理できるバージョン管理サービスです。
+ [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) は、ソフトウェアリリースのさまざまな段階を迅速にモデル化および設定し、ソフトウェアの変更を継続的にリリースするために必要なステップを自動化するのに役立ちます。
+ [Amazon Elastic Kubernetes Service (Amazon EKS) ](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html)を使用すると、独自の Kubernetes コントロールプレーンやノードをインストールまたは維持 AWS することなく、 で Kubernetes を実行できます。
+ [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) は、仮想プライベートクラウド (VPC) とオンプレミスネットワークを接続する中央ハブです。
+ [Amazon Virtual Private Cloud (Amazon VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) は、定義した仮想ネットワークに AWS リソースを起動するのに役立ちます。この仮想ネットワークは、ユーザー自身のデータセンターで運用されていた従来のネットワークと似ていますが、 AWSのスケーラブルなインフラストラクチャを使用できるという利点があります。
**その他のツール**
+ [Cilium ネットワークポリシー](https://cilium.io/use-cases/network-policy/#:~:text=Cilium%20implements%20Kubernetes%20Network%20Policies,%2C%20Kafka%2C%20gRPC%2C%20etc.)は、Kubernetes L3 および L4 ネットワークポリシーをサポートします。L7 ポリシーで拡張して、HTTP、Kafka、gRPC、その他の同様のプロトコルに API レベルのセキュリティを提供できます。
+ [Flux](https://fluxcd.io/) は、Git ベースの継続的デリバリー (CD) ツールです。Kubernetes へのアプリケーションのデプロイを自動化します。
+ [Helm](https://helm.sh/docs/) は、Kubernetes 用のオープンソースのパッケージマネージャです。Kubernetes クラスター上でアプリケーションをインストールおよび管理できます。
+ 「[Terraform](https://www.terraform.io/)」は、HashiCorp の infrastructure as code (IaC) ツールで、クラウドとオンプレミスのリソースの作成と管理を支援します。
**コードリポジトリ**
このパターンのコードは、GitHub「[EKS Multi-Tenancy Terraform Solution](https://github.com/aws-samples/aws-eks-multitenancy-deployment)」のリポジトリで入手できます。
## ベストプラクティス
この実装を使用するためのガイドラインとベストプラクティスについては、以下を参照してください。
+ [Amazon EKS マルチテナンシーのベストプラクティス](https://aws.github.io/aws-eks-best-practices/security/docs/multitenancy/)
+ [Flux ドキュメント](https://fluxcd.io/flux/get-started/)
## エピック
### Terraform のビルド、テスト、デプロイの各ステージのパイプラインを作成する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| プロジェクトリポジトリのクローンを作成する | ターミナルウィンドウで次のコマンドを実行して、GitHub [EKS Multi-Tenancy Terraform Solution](https://github.com/aws-samples/aws-eks-multitenancy-deployment) のリポジトリをクローンします。git clone https://github.com/aws-samples/aws-eks-multitenancy-deployment.git
| AWS DevOps |
| Terraform S3 バケットと Amazon DynamoDB をブートストラップします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/simplify-amazon-eks-multi-tenant-application-deployment-by-using-flux.html) | AWS DevOps |
| `run.sh` および `locals.tf` ファイルを更新します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/simplify-amazon-eks-multi-tenant-application-deployment-by-using-flux.html) | AWS DevOps |
| パイプラインモジュールをデプロイします。 | パイプラインリソースを作成するには、次の Terraform コマンドを手動で実行します。これらのコマンドを自動的に実行するためのオーケストレーションはありません。./run.sh -m pipeline -e demo -r -t init
./run.sh -m pipeline -e demo -r -t plan
./run.sh -m pipeline -e demo -r -t apply
| AWS DevOps |
### ネットワークインフラストラクチャを作成する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| パイプラインを開始します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/simplify-amazon-eks-multi-tenant-application-deployment-by-using-flux.html)初めて実行した後は、CodeCommit リポジトリのメインブランチに変更をコミットするたびに、パイプラインが自動的に開始されます。パイプラインには次の[ステージ](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts.html#concepts-stages)が含まれます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/simplify-amazon-eks-multi-tenant-application-deployment-by-using-flux.html) | AWS DevOps |
| ネットワークモジュールを通じて作成されたリソースを検証します。 | パイプラインが正常にデプロイされた後に、次の AWS リソースが作成されていることを確認します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/simplify-amazon-eks-multi-tenant-application-deployment-by-using-flux.html) | AWS DevOps |
### コンピューティングインフラストラクチャを作成する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| `locals.tf` を更新して、CodeBuild プロジェクトの VPC へのアクセスを有効にします。 | Amazon EKS プライベートクラスターのアドオンをデプロイするには、CodeBuild プロジェクトを Amazon EKS VPC にアタッチする必要があります。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/simplify-amazon-eks-multi-tenant-application-deployment-by-using-flux.html) | AWS DevOps |
| `buildspec` ファイルを更新してコンピューティングモジュールを構築します。 | `templates` フォルダのすべての `buildspec` YAML ファイルで、`TF_MODULE_TO_BUILD` 変数の値を `network` から `compute` に設定します。TF_MODULE_TO_BUILD: "compute"
| AWS DevOps |
| テナント管理 Helm チャートの `values` ファイルを更新します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/simplify-amazon-eks-multi-tenant-application-deployment-by-using-flux.html) | AWS DevOps |
| コンピューティングリソースを検証します。 | 前のステップでファイルを更新すると、CodePipeline が自動的に起動します。コンピューティングインフラストラクチャ用に次の AWS リソースが作成されていることを確認します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/simplify-amazon-eks-multi-tenant-application-deployment-by-using-flux.html) | AWS DevOps |
### テナント管理およびその他のリソースを確認する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| Kubernetes のテナント管理リソースを検証します。 | 次のコマンドを実行し、Helm を使用してテナント管理リソースが正常に作成されたことを確認します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/simplify-amazon-eks-multi-tenant-application-deployment-by-using-flux.html) | AWS DevOps |
| テナントアプリケーションのデプロイを確認します。 | 次のコマンドを実行して、テナントアプリケーションがデプロイされたことを確認します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/simplify-amazon-eks-multi-tenant-application-deployment-by-using-flux.html) | |
## トラブルシューティング
| 問題 | ソリューション |
| --- | --- |
| 次のようなエラーメッセージが表示されます。`Failed to checkout and determine revision: unable to clone unknown error: You have successfully authenticated over SSH. You can use Git to interact with AWS CodeCommit.` | 問題のトラブルシューティングを行うには、以下の手順を実行します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/simplify-amazon-eks-multi-tenant-application-deployment-by-using-flux.html) |
## 関連リソース
+ [Amazon EKS Blueprints for Terraform](https://github.com/aws-ia/terraform-aws-eks-blueprints)
+ [Amazon EKS ベストプラクティスガイド、マルチテナンシーセクション](https://aws.github.io/aws-eks-best-practices/security/docs/multitenancy/)
+ [Flux ウェブサイト](https://fluxcd.io/)
+ [Helm ウェブサイト](https://helm.sh/)
## 追加情報
テナントアプリケーションをデプロイするためのリポジトリ構造の例を次に示します。
```
applications
sample_tenant_app
├── README.md
├── base
│ ├── configmap.yaml
│ ├── deployment.yaml
│ ├── ingress.yaml
│ ├── kustomization.yaml
│ └── service.yaml
└── overlays
├── tenant-1
│ ├── configmap.yaml
│ ├── deployment.yaml
│ └── kustomization.yaml
└── tenant-2
├── configmap.yaml
└── kustomization.yaml
```
# 自動ワークフローを使用して Amazon Lex ボットの開発とデプロイを合理化する
*Balaji Panneerselvam、Attila Dancso、Pavan Dusanapudi、Anand Jumnani、James O'Hara (Amazon Web Services)*
## 概要
Amazon Lex 会話ボットの開発とデプロイは、複数の機能、開発者、および環境を管理しようとする場合には困難になることがあります。Infrastructure as Code (IaC) 原則を使用する自動ワークフローは、このプロセスを合理化するのに役立ちます。このパターンは、以下のようにして Amazon Lex 開発者の生産性の向上と、効率的なボットライフサイクル管理の実現に寄与します。
+ **複数の機能の同時開発を可能にする** - 自動ワークフローを使用すると、開発者はさまざまな機能を別々のブランチで並行して開発できます。その後、他の作業をブロックすることなく、変更をマージしてデプロイできます。
+ **Amazon Lex コンソール UI を使用する** - 開発者は、使いやすい Amazon Lex コンソールを使用してボットをビルドおよびテストできます。その後、ボットはインフラストラクチャコードで記述され、デプロイされます。
+ **複数の環境にまたがってボットを昇格させる** - ワークフローは、ボットバージョンの下位環境 (開発やテストなど) から本番環境までの昇格を自動化します。このアプローチにより、手動昇格のリスクとオーバーヘッドが軽減されます。
+ **バージョン管理を維持する** - ボット定義は、Amazon Lex サービスだけでなく Git でも管理されます。これにより、バージョン管理と監査証跡が提供されます。または AWS マネジメントコンソール APIs のみを使用して保存されているボットを変更する場合とは異なり、変更は個々の開発者に追跡されます AWS。
チームは、Amazon Lex ボットのリリースプロセスを自動化することで、リスクと労力を軽減し、機能をより迅速に提供できます。ボットは、Amazon Lex コンソールで分離されるのではなく、バージョン管理下にとどまります。
## 前提条件と制限事項
**前提条件**
+ ワークフローには、異なる環境 (開発、本番稼働、DevOps) AWS アカウント に対して複数の が含まれます。そのためには、アカウント管理とクロスアカウントアクセス設定が必要です。
+ デプロイ環境またはパイプラインで利用可能な Python 3.9。
+ ソース管理のためにローカルワークステーションに[インストール](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)および設定されている Git。
+ AWS Command Line Interface (AWS CLI) コマンドラインまたは Python を使用して認証するように[インストール](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html)および設定されています。
**制限事項**
+ **リポジトリアクセス** – ワークフローでは、継続的インテグレーションおよび継続的デリバリー (CI/CD) パイプラインに、ソースコードリポジトリに変更をコミットするために必要なアクセス許可があることを前提としています。
+ **初期ボットバージョン** – ツールでは、 AWS CloudFormation テンプレートを使用してボットの初期バージョンをデプロイする必要があります。ボットを自動ワークフローに引き継がせる前に、ボットの最初のイテレーションを作成し、リポジトリにコミットする必要があります。
+ **マージの競合** – ワークフローの目的は同時開発を可能にすることですが、さまざまなブランチからの変更を統合するときにマージの競合が発生する可能性がまだあります。ボット設定の競合を解決するには、手動介入が必要になる場合があります。
**製品バージョン**
+ [Python 3.9](https://www.python.org/downloads/) 以降
+ [AWS CDK v2 2.124.0](https://docs.aws.amazon.com/cdk/api/versions.html) 以降
+ [AWS SDK for Python (Boto3)](https://docs.aws.amazon.com/pythonsdk/) 1.28 以降
## アーキテクチャ
次の図は、ソリューションの高レベルアーキテクチャと主要コンポーネントを示しています。
![\[Amazon Lex ボットの開発とデプロイを自動化するワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/3c7f9d16-9708-43c4-afa6-9d804d6b9dad/images/cdc73e82-a777-4e88-8bf8-a73c9bacb47f.png)
主なコンポーネントは以下のとおりです。
+ **Lex ボットリポジトリ** – Amazon Lex ボットの IaC 定義を保存する Git リポジトリ。
+ **DevOps** – 開発およびデプロイプロセス用の CI/CD パイプラインおよび関連リソースを格納する AWS アカウント 専用の です。
+ **パイプライン** – 新しいボットの作成、ボットの定義のエクスポート、ボット定義のインポート、ボットの削除など、ボットの開発とデプロイのライフサイクルのさまざまな段階を自動化する AWS CodePipeline インスタンス。
+ **チケットボットとメインボット** – Amazon Lex ボットリソース。ここで、チケットボットは個々のチームまたは開発者によって開発される機能固有のボットで、メインボットはすべての機能を統合するベースラインボットです。
このアーキテクチャ図は、次のワークフローを示しています。
1. **メインボットをベースラインに設定する** – ワークフローの出発点は、開発 (Dev) 環境でメインボットをベースラインに設定することです。メインボットは、将来の開発と機能追加の基盤として機能します。
1. **チケットボットを作成する** – 新機能または変更が必要な場合、チケットボットが作成されます。チケットボットは基本的に、開発者がメインバージョンに影響を与えることなく操作できるメインボットのコピーまたはブランチです。
1. **チケットボットをエクスポートする** - チケットボットに対する作業が完了したら、Amazon Lex サービスからチケットボットがエクスポートされます。その後、チケットボットを含むブランチがメインブランチからリベースされます。このステップにより、チケットボットの開発中にメインボットに加えられた変更が確実に組み込まれ、潜在的な競合が軽減されます。
1. **リベースされたチケットボットをインポートして検証する** – リベースされたチケットボットは開発環境にインポートされ、メインブランチからの最新の変更で正しく機能することが検証されます。検証が成功すると、チケットボットの変更をメインブランチにマージするためのプルリクエスト (PR) が作成されます。
1. **チケットボットを削除する** – 変更がメインブランチに正常にマージされると、チケットボットは不要になります。チケットボットを削除して、環境をクリーンで管理しやすい状態に保つことができます。
1. **メインボットを開発環境にデプロイしてテストする** – 新機能や変更を含む最新のメインボットが開発環境にデプロイされます。ここでは、徹底的なテストを実施して、すべての機能が予期したとおりに動作することを確認します。
1. **メインボットを本番環境にデプロイする** – 開発環境でのテストが正常に完了すると、メインボットが本番環境にデプロイされます。このステップはワークフローの最終段階で、ここでエンドユーザーが新機能を利用できるようになります。
**自動化とスケール**
自動ワークフローにより、開発者はさまざまな機能を別々のブランチで並行して開発できます。これにより、同時開発が容易になり、チームが効果的にコラボレーションして、機能をより迅速に提供することが可能になります。相互に分離されたブランチにより、他の進行中の作業をブロックまたは妨害することなく、変更をマージしてデプロイできます。
ワークフローは、開発、テスト、本番などのさまざまな環境にまたがるボットバージョンのデプロイと昇格を自動化します。
Git などのバージョン管理システムにボット定義を保存することで、包括的な監査証跡が提供され、効率的なコラボレーションが可能になります。変更は個々の開発者まで追跡されます。これにより、開発ライフサイクル全体を通じて透明性と説明責任が確保されます。このアプローチでは、コードレビューも容易になるため、チームは本番環境にデプロイする前に問題を特定して対処できます。
AWS CodePipeline およびその他の を使用することで AWS のサービス、自動化ワークフローは増加するワークロードとチームサイズに合わせてスケーリングできます。
## ツール
**AWS のサービス**
+ [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/v2/guide/home.html) は、使い慣れたプログラミング言語を使用してコード内の AWS クラウド インフラストラクチャを定義し、それをプロビジョニングするためのオープンソースのソフトウェア開発フレームワークです CloudFormation。このパターンのサンプル実装では Python を使用します。
+ [AWS CDK コマンドラインインターフェイス (AWS CDK CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) - Toolkit AWS CDK は、 AWS CDK アプリを操作するための主要なツールです。アプリケーションを実行し、定義したアプリケーションモデルを調査し、CDK によって生成された CloudFormation テンプレートを生成してデプロイします。
+ [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) は、 AWS リソースをセットアップし、迅速かつ一貫してプロビジョニングし、 AWS アカウント および 全体のライフサイクルを通じてリソースを管理するのに役立ちます AWS リージョン。このパターンでは、CloudFormation を使用し、Infrastructure as Code によって Amazon Lex ボット設定と関連リソースをデプロイします。
+ [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) は完全マネージド型の構築サービスです。ソースコードのコンパイル、ユニットテストの実行、すぐにデプロイできるアーティファクトの生成を行います。このパターンでは、CodeBuild を使用してデプロイアーティファクトをビルドおよびパッケージ化します。
+ [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) は、ソフトウェアリリースのさまざまな段階を迅速にモデル化および設定し、ソフトウェアの変更を継続的にリリースするために必要なステップを自動化するのに役立ちます。このパターンでは、CodePipeline を使用して継続的デリバリーパイプラインをオーケストレーションします。
+ [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) は、コマンドラインシェルのコマンドAWS のサービス を使用して を操作するのに役立つオープンソースツールです。
+ [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、誰を認証し、誰に使用する権限を付与するかを制御することで、 AWS リソースへのアクセスを安全に管理するのに役立ちます。
+ [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。
+ [Amazon Lex V2](https://docs.aws.amazon.com/lexv2/latest/dg/what-is.html) は、音声とテキストを使用してアプリケーションの会話インターフェイス (ボット) を構築 AWS のサービス するための です。
+ [AWS SDK for Python (Boto3)](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/quickstart.html) は、Python アプリケーション、ライブラリ、またはスクリプトを と統合するのに役立つソフトウェア開発キットです AWS のサービス。
**その他のツール**
+ [Git](https://git-scm.com/docs) はオープンソースの分散型バージョン管理システムです。
**コードリポジトリ**
このパターンのコードは、GitHub [management-framework-sample-for-amazon-lex](https://github.com/aws-samples/management-framework-sample-for-amazon-lex) リポジトリで入手できます。コードリポジトリには、以下のフォルダとファイルが含まれています。
+ `prerequisite` フォルダ – 必要なリソースと環境を設定するための CloudFormation スタック定義 ( を使用 AWS CDK) が含まれています。
+ `prerequisite/lexmgmtworkflow` フォルダ – スタック定義や Python コードを含む、Lex Management Workflow プロジェクトのメインディレクトリ。
+ `prerequisite/tests` – ユニットテストが含まれています。
+ `src` フォルダ – Amazon Lex ボット管理ラッパーとユーティリティを含むソースコードディレクトリ。
+ `src/dialogue_lambda` – Amazon Lex ボットとの会話中にユーザー入力を傍受して処理するダイアログフック Lambda 関数のソースコードディレクトリ。
## ベストプラクティス
+ **懸念事項の分離**
+ DevOps、開発、および本番環境間の責任の明確な分離を維持します。
+ 環境 AWS アカウント ごとに個別の を使用して、適切な分離とセキュリティの境界を適用します。
+ クロスアカウントロールと最小特権アクセス原則を使用して、環境間の制御されたアクセスを確保します。
+ **コードとしてのインフラストラクチャ**
+ インフラストラクチャコードを定期的に見直し、ベストプラクティスと要件の変化に合わせて更新します。
+ ソースコードリポジトリに対する明確なブランチおよびマージ戦略を確立する
+ **テストと検証**
+ パイプラインのさまざまな段階で自動テストを実装して、開発サイクルの早い段階で問題を特定します。
+ Amazon Lex コンソールまたは自動テストフレームワークを使用し、ボットを上位環境に昇格させる前にボットの設定と機能を検証します。
+ 本番環境または重要な環境へのデプロイのための手動承認ゲートを実装することを検討します。
+ **モニタリングとログ記録 **
+ パイプライン、デプロイ、ボットインタラクションのモニタリングおよびログ記録メカニズムを設定します。
+ パイプラインイベント、デプロイステータス、ボットパフォーマンスメトリクスをモニタリングし、問題を迅速に特定して対処します。
+ Amazon CloudWatch などの AWS のサービス、および を使用して AWS CloudTrail、一元的なログ記録とモニタリング AWS X-Ray を行います。
+ 自動ワークフローのパフォーマンス、効率、および有効性を定期的に見直して分析します。
+ セキュリティとコンプライアンス
+ 安全なコーディングプラクティスを実装し、Amazon Lex ボットの開発とデプロイのセキュリティ AWS のベストプラクティスに従います。
+ 最小特権の原則に合わせて IAM ロール、ポリシー、およびアクセス許可を定期的に見直して更新します。
+ セキュリティスキャンとコンプライアンスチェックをパイプラインに統合することを検討します。
## エピック
### Amazon Lex ボット管理用の IaC を設定する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| ローカル環境を設定します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/streamline-amazon-lex-bot-development-and-deployment-using-an-automated-workflow.html) | AWS DevOps |
| `devops` 環境でクロスアカウントロールを作成します。 | `devops` アカウントは、CI/CD パイプラインのホスティングおよび管理を担当します。CI/CD パイプラインが `dev` および `prod` 環境とやり取りできるようにするには、以下のコマンドを実行して `devops` アカウントにクロスアカウントロールを作成します。cdk bootstrap --profile=devops
cdk deploy LexMgmtDevopsRoleStack -c dev-account-id=2222222222222 -c prod-account-id=333333333333 --profile=devops
| AWS DevOps |
| `dev` 環境でクロスアカウントロールを作成します。 | `dev` アカウントがこのロールを引き受けられるようにするために必要なアクセス許可を持つ IAM ロールを `devops` アカウントに作成します。CI/CD パイプラインは、このロールを使用して、Amazon Lex ボットリソースのデプロイや管理などのアクションを `dev` アカウントで実行します。IAM ロールを作成するには、以下のコマンドを実行します。cdk bootstrap --profile=dev
cdk deploy LexMgmtCrossaccountRoleStack -c devops-account-id=1111111111111 --profile=dev
| AWS DevOps |
| `prod` 環境でクロスアカウントロールを作成します。 | `prod` アカウントがこのロールを引き受けられるようにするために必要なアクセス許可を持つ IAM ロールを `devops` アカウントに作成します。CI/CD パイプラインは、このロールを使用して、Amazon Lex ボットリソースのデプロイや管理などのアクションを `prod` アカウントで実行します。cdk bootstrap --profile=prod
cdk deploy LexMgmtCrossaccountRoleStack -c devops-account-id=1111111111111 --profile=prod
| AWS DevOps |
| `devops` 環境にパイプラインを作成します。 | Amazon Lex ボットの開発ワークフローを管理するには、以下のコマンドを実行して `devops` 環境にパイプラインを設定します。cdk deploy LexMgmtWorkflowStack -c devops-account-id=1111111111111 -c dev-account-id=2222222222222 -c prod-account-id=333333333333 --profile=devops
| AWS DevOps |
### メインボットのベースラインを確立する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| メインボットの初期バージョンを定義します。 | メインボットの初期バージョンを定義するには、`BaselineBotPipeline` パイプラインを[トリガー](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts.html#concepts-triggers)します。このパイプラインは、CloudFormation テンプレートで定義されている基本的なボット定義をデプロイし、メインボット定義を .json ファイルとしてエクスポートし、メインボットコードをバージョン管理システムに保存します。 | AWS DevOps |
### 機能開発ワークフローを実装する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| チケットボットを作成し、機能を開発してテストします。 | `TicketBot` は、機能ブランチにある既存のメインボット定義からインポートされる新しいボットインスタンスです。このアプローチにより、メインボットの最新の機能と設定が新しいボットに含まれることが保証されます。チケットボットの初期バージョンを定義するには、`CreateTicketBotPipeline` パイプラインをトリガーします。このパイプラインは、バージョン管理システムに新しい機能ブランチを作成し、メインボットに基づいて新しいチケットボットインスタンスを作成します。 | Lex ボット開発者 |
| チケットボット機能を開発してテストします。 | 機能を開発してテストするには、 にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/lex/](https://console.aws.amazon.com/lex/) で Amazon Lex コンソールを開きます。詳細については、Amazon Lex ドキュメントの「[コンソールを使用したボットのテスト](https://docs.aws.amazon.com/lexv2/latest/dg/test-bot.html)」を参照してください。`TicketBot` インスタンスにより、ボットの機能を追加、変更、または拡張して新機能を実装できるようになりました。例えば、インテント、発話、スロット、ダイアログフローを作成または変更できます。詳細については、Amazon Lex ドキュメントの「[インテントの追加](https://docs.aws.amazon.com/lexv2/latest/dg/add-intents.html)」を参照してください。 | Lex ボット開発者 |
| チケットボット定義をエクスポートします。 | エクスポートされたボット定義は、基本的にボットの設定と機能を JSON 形式で表現したものです。チケットボット定義をエクスポートするには、`ExportTicketBotPipeline` パイプラインをトリガーします。このパイプラインは、チケットボット定義を .json ファイルとしてエクスポートし、チケットボットコードをバージョン管理システムの機能ブランチに保存します。 | Lex ボット開発者 |
| 最新のメインブランチから機能ブランチをリベースします。 | 新機能の開発中に、別の開発者またはチームがメインブランチに他の変更を加えた可能性があります。これらの変更を機能ブランチに組み込むには、Git `rebase` オペレーションを実行します。このオペレーションは基本的に、メインブランチからの最新のコミットに加えて機能ブランチからのコミットをリプレイすることで、機能ブランチに最新の変更がすべて含まれるようにします。 | Lex ボット開発者 |
| リベースされたチケットボットをインポートして検証します。 | 機能ブランチをリベースしたら、それをチケットボットインスタンスにインポートする必要があります。このインポートにより、既存のチケットボットがリベースされたブランチからの最新の変更で更新されます。リベースされたチケットボットをインポートするには、`ImportTicketBotPipeline` パイプラインをトリガーします。このパイプラインは、バージョン管理システムの機能ブランチにあるチケットボット定義 .json ファイルを `TicketBot` インスタンスにインポートします。 | Lex ボット開発者 |
| リベースされたボット定義を検証します。 | リベースされたボット定義をインポートしたら、その機能を検証することが重要です。新機能が予期したとおりに動作し、既存の機能と競合しないことを確認する必要があります。この検証では、通常、ボットをさまざまな入力シナリオでテストし、レスポンスを調べて、ボットが意図したとおりに動作することを検証します。検証は、次のいずれかの方法で実行できます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/streamline-amazon-lex-bot-development-and-deployment-using-an-automated-workflow.html) | Lex ボット開発者 |
| 機能ブランチをメインブランチにマージします。 | 分離された `TicketBot` インスタンスで新機能を開発してテストしたら、次の操作を行います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/streamline-amazon-lex-bot-development-and-deployment-using-an-automated-workflow.html) | Lex ボット開発者、リポジトリ管理者 |
| 機能ブランチとチケットボットを削除します。 | 機能ブランチがメインブランチに正常にマージされたら、ソースコードリポジトリから機能ブランチとチケットボットを削除します。機能ブランチとチケットボットを削除するには、`DeleteTicketBotPipeline` パイプラインをトリガーします。このパイプラインは、開発プロセス中に作成された一時的なボットリソース (チケットボットなど) を削除します。このアクションは、リポジトリをクリーンな状態に保ち、将来の機能ブランチとの混同や競合を防ぐのに役立ちます。 | Lex ボット開発者 |
### メインボットを保守する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| 最新のメインボット定義を `dev` 環境にインポートします。 | メインブランチの最新のメインボット定義を `dev` 環境にインポートするには、`DeployBotDevPipeline` パイプラインをトリガーします。このパイプラインは、承認時に git タグも作成します。 | AWS DevOps |
| 最新のメインボット定義を `prod` 環境にインポートします。 | メインブランチの最新のボット定義を `prod` 環境にインポートするには、前のタスクのタグリファレンスをパラメータとして指定して `DeployBotProdPipeline` パイプラインをトリガーします。このパイプラインは、特定のタグの最新のボット定義を `prod` 環境にインポートします。 | AWS DevOps |
## トラブルシューティング
| 問題 | ソリューション |
| --- | --- |
| Amazon Lex ボットを別の にデプロイする場合 AWS アカウント、ツールサービスには、それらのアカウントのリソースにアクセスするために必要なアクセス許可が必要です。 | クロスアカウントアクセスを付与するには、IAM ロールとポリシーを使用します。ターゲットアカウントに IAM ロールを作成し、必要なアクセス許可を付与するロールにポリシーをアタッチします。次に、Amazon Lex ボットがデプロイされているアカウントからそれらのロールを引き受けます。詳細については、Amazon Lex ドキュメントの「[インポートに必要な IAM アクセス許可](https://docs.aws.amazon.com/lexv2/latest/dg/import.html#import-permissions)」と「[Lex V2 でボットをエクスポートするために必要な IAM アクセス許可](https://docs.aws.amazon.com/lexv2/latest/dg/export.html#export-permissions)」を参照してください。 |
## 関連リソース
+ [Amazon Lex V2 でのボットのインポート](https://docs.aws.amazon.com/lexv2/latest/dg/import.html)
+ [CodePipeline でパイプラインを開始する](https://docs.aws.amazon.com/codepipeline/latest/userguide/pipelines-about-starting.html)
+ [Amazon Lex V2 ボットの使用 V2 ](https://docs.aws.amazon.com/lexv2/latest/dg/building-bots.html)
# AWS Fargate WaitCondition フック構造を使用してリソースの依存関係とタスク実行を調整する
*Amazon Web Services、Stan Fan*
## 概要
このパターンでは、Amazon Elastic Container Service (Amazon ECS) クラスターの [AWS Fargate](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/AWS_Fargate.html) タスクをオーケストレーションするために設計されたクラウドネイティブソリューションである WaitCondition フック (`waitcondition-hook-for-aws-fargate-task`) npm パッケージを説明します。
WaitCondition フックは、 との統合用に特別にカスタマイズされた AWS Cloud Development Kit (AWS CDK) コンストラクトです AWS CloudFormation。WaitCondition フックの主な機能は、次のとおりです。
+ 待機条件メカニズムとして機能し、指定された Fargate タスクが完了するまで CloudFormation スタックの実行を一時停止します。これにより、正しい順序でのデプロイとリソースプロビジョニングがしやすくなります。
+ TypeScript と Python をサポートしているため、 AWS CDK プロジェクトに最適です。
+ AWSでコンテナ化されたアプリケーションのタスク完了とリソース管理を調整することで、開発者やアーキテクトがデプロイをオーケストレーションできるようにします。
+ CloudFormation ライフサイクルに埋め込まれた 1 つ以上のコンテナを使用する Fargate タスクの実行を可能にします。また、タスクの失敗を処理し、タスクの失敗後に CloudFormation スタックをロールバックできます。
+ カスタムタスクを有効にしたり、他のエンドポイントを呼び出したりして、リソースと Fargate タスク実行結果の間の依存関係を柔軟に追加できるようにします。例えば、CloudFormation スタックを一時停止し、データベース移行 (Fargate タスクによって実行) の完了を待ち、データベース移行の成功に依存する可能性のある他のリソースをプロビジョニングできます。
## 前提条件と制限
**前提条件**
+ アクティブ AWS アカウント。
+ AWS Cloud Development Kit (AWS CDK) ローカルワークステーションにインストールされたコマンドラインインターフェイス (CLI)。詳細については、 AWS CDK ドキュメントの [AWS CDK CLI リファレンス](https://docs.aws.amazon.com/cdk/v2/guide/cli.html)を参照してください。
+ ローカルワークステーションにインストールされ、[TypeScript のAWS CDK](https://docs.aws.amazon.com/cdk/v2/guide/work-with-cdk-typescript.html) 用に設定されたノードパッケージマネージャー (npm)。詳細については、npm ドキュメントの [[Node.js と npm のダウンロードとインストール]](https://docs.npmjs.com/downloading-and-installing-node-js-and-npm) を参照してください。
+ ローカルワークステーションにインストールされた Yarn。詳細については、Yarn ドキュメントの「[インストール](https://yarnpkg.com/getting-started/install)」を参照してください。
**制限事項**
+ このソリューションは 1 つの にデプロイされます AWS アカウント。
+ 成功の場合、コンテナの期待されるリターンコードは `0` です。その他のリターンコードは失敗を示し、CloudFormation スタックはロールバックされます。
+ 一部の AWS のサービス は では使用できません AWS リージョン。利用可能なリージョンについては、「[AWS のサービス (リージョン別)](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)」を参照してください。特定のエンドポイントについては「[Service endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)」から、サービスのリンクを選択してご確認ください。
## アーキテクチャ
コンストラクトアーキテクチャを次の図に示します。
![\[waitcondition-hook-for-aws-fargate-task コンストラクトの AWS Step Functions ワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/e58680e3-f89f-422f-b0e1-e85605ae8bf9/images/598020df-908c-4486-9844-c05af759c18a.png)
この図表は、`waitcondition-hook-for-aws-fargate-task` のワークフローを示しています。
1. `WaitCondition` および `WaitConditionHandler` は、 AWS Lambda 関数からのレスポンスをリッスンするようにプロビジョニングされます。
1. タスクの結果に応じて、Fargate タスクの終了によって `CallbackFunction` または `ErrorHandlerFunction` がトリガーされます。
1. Lambda 関数は、SUCCEED シグナルか FAILURE シグナルを `WaitConditionHandler` に送信します。
1. Fargate タスクの実行結果が成功だった場合、`WaitConditionHandler` はリソースのプロビジョニングを継続します。タスクが失敗した場合はスタックをロールバックします。
次の図は、データベース移行を実行するためのワークフローの例を示しています。
![\[WaitCondition フックコンストラクトを使用した Amazon RDS データベース移行のワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/e58680e3-f89f-422f-b0e1-e85605ae8bf9/images/3b83fc2a-80bb-4ba9-9637-782060493cf0.png)
このワークフロー例では、`waitcondition-hook-for-aws-fargate-task` コンストラクトを使用して、次のようにデータベース移行を実行します。
1. Amazon Relational Database Service (Amazon RDS) インスタンスがプロビジョニングされます。
1. `waitcondition-hook-for-aws-fargate-task` コンストラクトは、データベース移行タスクを実行し、スタックを Amazon Elastic Compute Cloud (Amazon EC2) インスタンスとして一時停止します。
1. 移行タスクが正常に終了すると、Succeed シグナルを CloudFormation に送信します。正常に終了しなかった場合は、Fail シグナルを CloudFormation に送信し、スタックをロールバックします。
## ツール
**AWS サービス**
+ [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/v2/guide/home.html) は、コードでクラウドインフラストラクチャを定義し、それをプロビジョニングするのに役立つソフトウェア開発フレームワークです CloudFormation。
+ [CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) は、 AWS リソースをセットアップし、迅速かつ一貫してプロビジョニングし、 AWS アカウント および 全体のライフサイクルを通じてリソースを管理するのに役立ちます AWS リージョン。
+ [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) は、 AWS リソースと で実行しているアプリケーションのメトリクスを AWS リアルタイムでモニタリングするのに役立ちます。
+ 「[Amazon Elastic Container Service (Amazon ECS)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html)」 は、クラスターでのコンテナの実行、停止、管理を支援する、高速でスケーラブルなコンテナ管理サービスです。
+ [AWS Fargate](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/AWS_Fargate.html) を使用すると、サーバーや Amazon EC2 インスタンスを管理する必要なくコンテナを実行できます。これは Amazon ECS と組み合わせて使用されます。
+ [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) は、誰を認証し、誰に使用を認可するかを制御することで、 AWS リソースへのアクセスを安全に管理するのに役立ちます。
+ [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。
+ [AWS Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) は、 AWS Lambda 関数やその他の を組み合わせてビジネスクリティカルなアプリケーション AWS のサービス を構築するのに役立つサーバーレスオーケストレーションサービスです。
+ [Amazon Virtual Private Cloud (Amazon VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) は、定義した仮想ネットワークに AWS リソースを起動するのに役立ちます。この仮想ネットワークは、お客様自身のデータセンターで運用されていた従来のネットワークに似ていますが、 AWSのスケーラブルなインフラストラクチャを使用できるというメリットがあります。
**その他のツール**
+ [npm](https://docs.npmjs.com/about-npm) は Node.js 環境で動作するソフトウェアレジストリで、パッケージの共有や借用、プライベートパッケージのデプロイ管理に使用されます。
+ [Yarn](https://yarnpkg.com/) は、JavaScript プロジェクトの依存関係を管理するために使用できるオープンソースのパッケージマネージャーです。Yarn は、パッケージの依存関係のインストール、更新、設定、削除をサポートします。
**コードリポジトリ**
このパターンのコードは、GitHub の [waitcondition-hook-for-aws-fargate-task](https://github.com/aws-samples/waitcondition-hook-for-aws-fargate-task) リポジトリで入手できます。
## ベストプラクティス
+ AWS CDK アプリを構築するときは、v2 AWS CDK ドキュメントの「 [を使用したクラウドインフラストラクチャの開発とデプロイのベストプラクティス AWS CDK](https://docs.aws.amazon.com/cdk/v2/guide/best-practices.html)」に従ってください。
+ AWS Fargate タスクについては、[Amazon ECS ドキュメントの「Amazon ECS コンテナイメージのベストプラクティス](https://docs.aws.amazon.com/AmazonECS/latest/bestpracticesguide/application.html)」に従ってください。
## エピック
### のセットアップ AWS CDK
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| をインストールします AWS CDK。 | AWS CDK ローカルマシンまたは他の環境に をインストールするには、次のコマンドを実行します。npm install -g aws-cdk@latest
| クラウドアーキテクト、アプリ開発者 |
| をブートストラップします AWS CDK。 | [ブートストラップ](https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html)は、デプロイ用の[環境](https://docs.aws.amazon.com/cdk/v2/guide/environments.html)を準備するプロセスです。ターゲット AWS アカウント と の AWS CDK ツールキットをブートストラップするには AWS リージョン、次のコマンドを実行します。cdk bootstrap aws://ACCOUNT-NUMBER-1/REGION-1
このコマンドは、`CDKToolkit` という名前の CloudFormation スタックを作成します。 | クラウドアーキテクト |
### AWS Fargate タスクコンストラクトの WaitCondition フックを実行する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| CDK プロジェクトを作成します。 | 任意の言語を使用して、CDK プロジェクトを作成します。このパターンでは、TypeScript を使用します。TypeScript を使用して CDK プロジェクトを作成するには、次のコマンドを実行します。`cdk init app —language typescript` | クラウドアーキテクト |
| パッケージをインストールします。 | CDK プロジェクトのルートパスで `npm install` を実行します。CDK ライブラリをインストールしたら、次のコマンドを実行して `waitcondition-hook-for-aws-fargate-task` をインストールします。`yarn add waitcondition-hook-for-aws-fargate-task` | クラウドアーキテクト |
| CDK アプリケーションと Amazon ECS コンポーネントをビルドします。 | CDK プロジェクトをビルドします。Amazon ECS タスク定義リソースが必要です。タスク定義の作成に関する詳細については、Amazon ECS ドキュメントの「[Amazon ECS タスク定義](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definitions.html)」を参照してください。次の例ではこのコンストラクトを使用します。import * as cdk from 'aws-cdk-lib';
import { Vpc } from 'aws-cdk-lib/aws-ec2';
import * as ecr from 'aws-cdk-lib/aws-ecr';
import * as ecs from 'aws-cdk-lib/aws-ecs';
import { Construct } from 'constructs';
import { FargateRunner } from 'waitcondition-hook-for-aws-fargate-task';
import { Queue } from 'aws-cdk-lib/aws-sqs';
export class FargateRunnerStack extends cdk.Stack {
constructor(scope: Construct, id: string, props?: cdk.StackProps) {
super(scope, id, props);
// Define the VPC
const vpc = new Vpc(this, 'MyVpc')
// Define the Fargate Task
const taskDefinition = new ecs.FargateTaskDefinition(this, 'MyTask', {});
// Import exiting ecr repo
const repo = ecr.Repository.fromRepositoryName(this, 'MyRepo', 'RepoName');
// Add a container to the task
taskDefinition.addContainer('MyContainer', {
image: ecs.ContainerImage.fromEcrRepository(repo),
});
// Create the Fargate runner
const myFargateRunner = new FargateRunner(this, 'MyRunner', {
fargateTaskDef: taskDefinition,
timeout: `${60 * 5}`,
vpc: vpc,
});
// Create the SQS queue
const myQueue = new Queue(this, 'MyQueue', {});
// Add dependency
myQueue.node.addDependency(myFargateRunner);
}
}
| クラウドアーキテクト |
| CDK アプリケーションを合成し、起動します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/use-the-aws-fargate-waitcondition-hook-construct.html)`waitcondition-hook-for-aws-fargate-task` コンストラクトは Fargate タスクを実行します。 | クラウドアーキテクト |
### クリーンアップ
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| リソースをクリーンアップします。 | 前のステップでプロビジョニングされたリソースをクリーンアップするには、次のコマンドを実行します。cdk destroy
| クラウドアーキテクト |
## トラブルシューティング
| 問題 | ソリューション |
| --- | --- |
| 一般的な CloudFormation スタックの障害 | 一般的な CloudFormation スタックの障害のトラブルシューティングに役立つように、次の例に示すように `--no-rollback` フラグを追加します。cdk deploy --no-rollback
このコマンドは CloudFormation スタックのロールバックを一時停止し、トラブルシューティングのためのリソースを提供します。詳細については、 CloudFormation ドキュメントの[「リソースをプロビジョニングするときに障害を処理する方法を選択する](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stack-failure-options.html)」を参照してください。 |
| AWS Step Functions 失敗 | AWS Step Functions ステートマシンは、さまざまな理由で実行に失敗することがあります。`—disable-rollback` が設定されている場合は、次のステップを使用してトラブルシューティングを行います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/use-the-aws-fargate-waitcondition-hook-construct.html)詳細については、 AWS Step Functions ドキュメントの[「Step Functions の問題のトラブルシューティング](https://docs.aws.amazon.com/step-functions/latest/dg/troubleshooting.html)」および[「Step Functions コンソールの実行の詳細の表示](https://docs.aws.amazon.com/step-functions/latest/dg/concepts-view-execution-details.html#exec-details-intf-step-details)」を参照してください。 |
| AWS Lambda 関数の失敗 | このコンストラクトは、`CallbackFunction` と `ErrorhandlerFunction` の 2 つの Lambda 関数をプロビジョニングします。処理されない例外など、さまざまな理由で失敗する可能性があります。次の手順を使用して、トラブルシューティングを行います。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/use-the-aws-fargate-waitcondition-hook-construct.html)詳細については、 AWS Lambda ドキュメントの[「Lambda の問題のトラブルシューティング](https://docs.aws.amazon.com/lambda/latest/dg/lambda-troubleshooting.html)」を参照してください。 |
## 関連リソース
**AWS ドキュメント**
+ [AWS CDK コンストラクト API リファレンス](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-construct-library.html)
+ [の開始方法 AWS CDK](https://docs.aws.amazon.com/cdk/v2/guide/getting_started.html)
+ [Amazon ECS リソースを作成して使用する方法について説明します。](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/getting-started.html)
+ [Step Functions の使用を開始する方法について説明します。](https://docs.aws.amazon.com/step-functions/latest/dg/getting-started-with-sfn.html)
+ [とは AWS CDK](https://docs.aws.amazon.com/cdk/v2/guide/home.html)
**その他のリソース**
+ [AWS Fargate タスクの待機条件フック](https://pypi.org/project/waitcondition-hook-for-aws-fargate-task/) (npm)
+ [waitcondition-hook-for-aws-fargate-task 1.0.6](https://pypi.org/project/waitcondition-hook-for-aws-fargate-task/) (pypi.org)
# AWS CodePipeline のサードパーティーの Git ソースリポジトリを使用する
*Amazon Web Services、Kirankumar Chandrashekar*
## 概要
このパターンでは、AWS CodePipeline をサードパーティーの Git ソースリポジトリで使用する方法を説明します。
[AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts-continuous-delivery-integration.html) は、ソフトウェアの構築、テスト、製品へのデプロイを自動化する 継続的デリバリーサービス です。このサービスは現在、GitGitHub、「[AWS CodeCommit](https://aws.amazon.com/codecommit)」、およびアトラシアン Bitbucket によって管理されている Git リポジトリをサポートしています。ただし、一部の企業では、シングルサインオン (SSO) サービスとMicrosoft Active Directoryと統合されたサードパーティー製の Git リポジトリを認証に使用しています。カスタムアクションと Webhook を作成することで、これらのサードパーティーの Git リポジトリを CodePipeline のソースとして使用できます。
ウェブフックとは、GitHub リポジトリなど、別のツールにおけるイベントを検出し、この外部イベントをパイプラインに接続する HTTP 通知です。CodePipeline でウェブフックを作成すると、サービスは Git リポジトリのウェブフックで使用できる URL を返します。Git リポジトリの特定のブランチにコードをプッシュすると、Git ウェブフックはこの URL から CodePipeline ウェブフックを開始し、パイプラインのソースステージを「**進行中**」に設定します。パイプラインがこの状態になると、ジョブワーカーは CodePipeline をポーリングしてカスタムジョブを探し、ジョブを実行し、成功または失敗のステータスを CodePipeline に送信します。この場合、パイプラインはソースステージにあるため、ジョブワーカーは Git リポジトリのコンテンツを取得して圧縮し、ポーリングされたジョブによって提供されたオブジェクトキーを使用して、パイプラインのアーティファクトが保存されている Amazon Simple Storage Service (Amazon S3) バケットにアップロードします。カスタムアクションのトランジションを Amazon CloudWatch のイベントに関連付けて、そのイベントに基づいてジョブワーカーを起動することもできます。この設定により、サービスがネイティブにサポートしていないサードパーティーの Git リポジトリを CodePipeline のソースとして使用できます。
## 前提条件と制限事項
**前提条件**
+ アクティブな AWS アカウント。
+ ウェブフックをサポートし、インターネット経由で CodePipeline ウェブフック URL に接続できる Git リポジトリ
+ AWS コマンドラインインターフェイス (AWS CLI) が「[インストールされ](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)」、AWS アカウントと連携するように「[設定されている](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html)」
## アーキテクチャ
このパターンには以下のステップが含まれます。
1. ユーザーは Git リポジトリにコードをコミットします。
1. Git ウェブフックが呼び出されます。
1. CodePipeline ウェブフックが呼び出されます。
1. パイプラインは「**進行中**」に設定され、ソースステージは「**進行中**」状態に設定されます。
1. ソースステージアクションは、開始されたことを示す CloudWatch Events ルールを開始します。
1. CloudWatch イベントは Lambda 関数を開始します。
1. Lambda 関数はカスタムアクションジョブの詳細を取得します。
1. Lambda 関数は AWS CodeBuild を起動し、ジョブに関連するすべての情報を渡します。
1. CodeBuild は、HTTPS Git アクセス用の公開 SSH キーまたはユーザー認証情報をSecrets Manager から取得します。
1. CodeBuild は特定のブランチの Git リポジトリをクローンします。
1. CodeBuild はアーカイブを圧縮し、CodePipeline アーティファクトストアとして機能する S3 バケットにアップロードします。
![\[AWS CodePipeline のソースとしてサードパーティーの Git ソースリポジトリを使用するワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/84284bec-b39d-466a-9fd9-994be2c953df/images/85555dab-7317-40f5-86a7-ccb8987c5bf3.png)
## ツール
+ [AWS CodePipeline](https://aws.amazon.com/codepipeline/) – AWS CodePipeline はフルマネージド型の[継続的デリバリー](https://aws.amazon.com/devops/continuous-delivery/)サービスで、アプリケーションとインフラストラクチャの更新を迅速かつ信頼できるものにするパイプラインのリリース自動化に役立ちます。CodePipeline はお客様が定義したリリースモデルに基づき、コードチェンジがあった場合のフェーズの構築、テスト、およびデプロイを自動化します。機能とアップデートをすばやく、信頼性の高い方法で配信できます。AWS CodePipeline は、GitHub などのサードパーティーサービスや独自のカスタムプラグインと統合できます。
+ [AWS Lambda](https://aws.amazon.com/lambda/) – AWS Lambda を使用すると、サーバーをプロビジョニングまたは管理しなくてもコードを実行できます。Lambda を使用すれば、実質どのようなタイプのアプリケーションやバックエンドサービスでも、管理をまったく必要とせずに実行できます。コードをアップロードするだけで、コードの実行とスケールに必要な処理はすべて Lambda により自動的に実行され、高い可用性が維持されます。コードは、他の AWS サービスから自動的に開始するよう設定することも、ウェブやモバイルアプリケーションから直接呼び出すよう設定することもできます。
+ [AWS CodeBuild](https://aws.amazon.com/codebuild/) – AWS CodeBuild はフルマネージド型の[継続的統合](https://aws.amazon.com/devops/continuous-integration/)サービスであり、このサービスにより、ソースコードをコンパイルし、テストを実行し、デプロイ可能なソフトウェアパッケージを作成できます。CodeBuild により、ビルドサーバーのプロビジョニング、管理、スケーリングが不要になります。CodeBuild では、継続的にスケーリングされ、複数のビルドが同時にプロセスされるため、ビルドの実行までキューで待機することはありません。パッケージ済みのビルド環境を使用、またはご自分のビルドツールを使用するカスタムビルド環境を作成できることですぐに開始できます。
+ [AWS Secrets Manager](https://aws.amazon.com/secrets-manager/) – AWS Secrets Manager は、アプリケーション、サービス、IT リソースへのアクセスに必要なシークレットの保護に役立ちます。このサービスを使用すると、データベースクレデンシャル、APIキー、およびその他のシークレットをライフサイクル全体で簡単にローテーション、管理、および取得できます。ユーザーとアプリケーションは、機密情報をプレーンテキストにハードコーディングしなくても、Secrets Manager API を呼び出すことでシークレットを取得します。Secrets Manager では、Amazon Relational Database Service (Amazon RDS)、Amazon Redshift、Amazon DocumentDB の統合が組み込まれています。このサービスは、API キーや OAuth トークンなど、他のタイプのシークレットをサポートするように拡張できます。さらに、Secrets Manager では、きめ細かい権限を使用してシークレットへのアクセスを制御したり、AWS クラウド、サードパーティーサービス、オンプレミス環境内のリソースに対するシークレットのローテーションを一元的に監査したりできます。
+ [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) – Amazon CloudWatch は、DevOps エンジニア、開発者、サイト信頼性エンジニア (SRE)、ITマネージャー、アプリケーション所有者向けに構築された、モニタリングおよびオブザーバビリティサービスです。CloudWatch では、データと実用的なインサイトを提供して、アプリケーションのモニタリング、システム全体のパフォーマンスの変化に関する対応、リソース使用率の最適化、および運用状態の統合的な確認を行うことができます。CloudWatch は、ログ、メトリックス、イベントの形式でモニタリングデータと運用データを収集し、AWS とオンプレミスサーバーで実行される AWS のリソース、アプリケーション、サービスを一元的に把握できるようにします。CloudWatch を使用すると、環境内の異常な動作の検出、アラームの設定、ログとメトリクスの並列表示、自動アクションの実行、問題のトラブルシューティング、およびアプリケーションの円滑な稼働を維持するための洞察の発見を行うことができます。
+ [Amazon S3](https://aws.amazon.com/s3/) — Amazon Simple Storage Service (Amazon S3) は、ウェブサイト、モバイルアプリケーション、バックアップおよび復元、アーカイブ、エンタープライズアプリケーション、IoT デバイス、ビッグデータ分析など、広範なユースケースのデータを容量にかかわらず、保存して保護することができます。Amazon S3 には、特定のビジネス、組織、コンプライアンスの要件を満たすために、データへのアクセスを最適化、整理、設定できる管理機能があります。
## エピック
### CodePipeline でカスタムアクションを作成および追加する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| AWS CLI または AWS CloudFormation を使用してカスタムアクションを作成します。 | このステップでは、特定のリージョンの AWS アカウントのパイプラインのソースステージで使用できるカスタムソースアクションを作成します。カスタムソースアクションを作成するには、AWS CLI または AWS CloudFormation (コンソールではない) を使用する必要があります。このエピックやその他のエピックで説明されているコマンドとステップの詳細については、このパターンの最後にある「関連リソース」セクションを参照してください。AWS CLI では、カスタムアクションタイプの作成コマンドを使用します。--configuration-properties を使用して、ジョブワーカーがジョブの CodePipeline をポーリングするときに処理する必要があるすべてのパラメータを指定します。このカスタムソースステージでパイプラインを作成するときに同じ値を使用できるように、--provider オプションと--action-version オプションに指定されている値を必ず書き留めてください。リソースタイプ AWS：： CodePipeline：： CustomActionType を使用して AWS CloudFormation でカスタムソースアクションを作成することもできます。 | AWS 全般 |
### 認証を設定する。
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| SSH キーペア を作成します。 | Secure Shell (SSH) key pair を作成します。手順については、Github のドキュメントを参照してください。 | システム/DevOps エンジニア |
| AWS Secrets Manager でシークレットを作成します。 | SSH キーkey pair からプライベートキーの内容をコピーし、AWS Secrets Manager でシークレットを作成します。このシークレットは、Git リポジトリにアクセスするときの認証に使用されます。 | AWS 全般 |
| パブリックキーを Git リポジトリに追加します。 | SSH キーペアのパブリックキーを Git リポジトリアカウント設定に追加して、プライベートキーに対する認証を行います。 | システム/DevOps エンジニア |
### パイプラインと Webhook を作成します。
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| カスタムソースアクションを含むパイプラインを作成します。 | CodePipeline でパイプラインを作成します。ソースステージを設定するときは、以前に作成したカスタムソースアクションを選択します。AWS CodePipeline コンソールまたは AWS CLI でこれを行うことができます。CodePipeline は、カスタムアクションに設定した設定プロパティの入力を求めます。この情報は、ジョブワーカーがカスタムアクションのジョブを処理するために必要です。ウィザードに従い、パイプラインの次のステージを作成します。 | AWS 全般 |
| CodePipeline Web フックを作成します。 | カスタムソースアクションで作成したパイプライン用の Webhook を作成します。ウェブフックを作成するには、AWS CLI または AWS CloudFormation (コンソールではない) を使用する必要があります。AWS CLI で put-webhook コマンドを実行し、ウェブフックオプションに適切な値を指定します。コマンドから返される Webhook URL を書き留めておきます。AWS CloudFormation を使用してウェブフックを作成する場合は、リソースタイプ AWS：： CodePipeline：： Webhook を使用してください。作成したリソースからウェブフック URL を出力し、書き留めておいてください。 | AWS 全般 |
| Lambda 関数と CodeBuild プロジェクトを作成します。 | カスタムアクションを作成する際、このカスタムアクションのジョブリクエストの CodePipeline をポーリングするジョブワーカーを作成し、ジョブを実行してステータス結果を CodePipeline に返す必要があります。 パイプラインのカスタムソースアクションステージが「進行中」に移行したときに Amazon CloudWatch Events ルールによって開始される Lambda 関数を作成します。Lambda 関数が開始されると、ジョブをポーリングしてカスタムアクションジョブの詳細を取得する必要があります。PollForJobs API を使用してこの情報を返すことができます。ポーリングされたジョブ情報を取得したら、Lambda 関数は確認を返し、カスタムアクションの設定プロパティから取得したデータを使用して情報を処理する必要があります。ワーカーが Git リポジトリと通信する準備ができたら、CodeBuild プロジェクトを開始します。SSH クライアントを使用して Git タスクを処理する方が便利なためです。 | AWS 全般、コード開発者 |
### CloudWatch でイベントを作成する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| CloudWatch Events ルールを作成します。 | パイプラインのカスタムアクションステージが「進行中」に移行するたびに、ターゲットとして Lambda 関数を開始する CloudWatch Events ルールを作成します。 | AWS 全般 |
## 関連リソース
**CodePipeline でカスタムアクションにタグ付けする**
+ [CodePipeline でカスタムアクションを作成および追加する](https://docs.aws.amazon.com/codepipeline/latest/userguide/actions-create-custom-action.html)
+ [AWS：：CodePipeline：：CustomActionType](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-codepipeline-customactiontype.html)
**認証の設定**
+ [AWS Secrets Manager でのシークレットの作成と管理](https://docs.aws.amazon.com/secretsmanager/latest/userguide/managing-secrets.html)
**パイプラインと Web フックの作成**
+ [CodePipeline でパイプラインの作成](https://docs.aws.amazon.com/codepipeline/latest/userguide/pipelines-create.html)
+ [put-webhook コマンドリファレンス](https://docs.aws.amazon.com/cli/latest/reference/codepipeline/put-webhook.html)
+ [AWS：：CodePipeline：：Webhook](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-codepipeline-webhook.html)
+ [PollForJobs API リファレンス](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_PollForJobs.html)
+ [CodePipeline でカスタムアクションを作成および追加する](https://docs.aws.amazon.com/codepipeline/latest/userguide/actions-create-custom-action.html)
+ [AWS CodeBuild でビルドプロジェクトを削除する](https://docs.aws.amazon.com/codebuild/latest/userguide/create-project.html)
**イベントの作成**
+ [Amazon CloudWatch Eventsでパイプラインステートの変更を検知し反応する](https://docs.aws.amazon.com/codepipeline/latest/userguide/detect-state-changes-cloudwatch-events.html)
**その他の参考資料**
+ [CodePipeline でのパイプラインの使用](https://docs.aws.amazon.com/codepipeline/latest/userguide/pipelines.html)
+ [AWS Lambda 開発者ガイド](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
# AWS CodePipeline を使用して Terraform の構成を検証するための CI/CD パイプラインを作成する
*Aromal Raj Jayarajan、Vijesh Vijayakumaran Nair (Amazon Web Services)*
## 概要
このパターンは、AWS CodePipeline がデプロイした継続的インテグレーションおよび継続的デリバリー (CI/CD) パイプラインを使用して HashiCorp Terraform の構成をテストする方法を説明しています。
Terraform は、コードを使用してクラウドインフラストラクチャとリソースをプロビジョニングおよび管理する上で役立つコマンドラインインターフェイスアプリケーションです。このパターンで提供されるソリューションは、[CodePipeline の 5 つのステージ](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts.html#concepts-stages)を実行して Terraform 構成の整合性を検証する際に役立つ CI/CD パイプラインを作成します。
1. `"checkout"` は、テスト中の Terraform 構成を AWS CodeCommit リポジトリから取得します。
1. `"validate"` は、[tfsec](https://github.com/aquasecurity/tfsec)、[TFLint](https://github.com/terraform-linters/tflint)、[checkov](https://www.checkov.io/) などの Infrastructure as Code (IaC) 検証ツールを実行します。このステージでは、Terraform の IaC 検証コマンド `terraform validate` および `terraform fmt` も実行されます。
1. `"plan"` は、Terraform 構成が適用された場合にインフラストラクチャにどのような変更が適用されるかを示します。
1. `"apply"` は、生成された計画を使用して、必要なインフラストラクチャをテスト環境にプロビジョニングします。
1. `"destroy"` は、`"apply"` ステージ中に作成されたテストインフラストラクチャを削除します。
## 前提条件と制限事項
**前提条件**
+ アクティブなAWS アカウント
+ [インストールされ](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)、[構成済み](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html)の AWS コマンドラインインターフェイス (AWS CLI)
+ ローカルマシンにインストールされて構成されている [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)
+ ローカルマシンにインストールされ、構成済みの [Terraform](https://learn.hashicorp.com/collections/terraform/aws-get-started?utm_source=WEBSITE&utm_medium=WEB_IO&utm_offer=ARTICLE_PAGE&utm_content=DOCS)
**制限事項**
+ このパターンのアプローチでは、AWS CodePipeline を 1 つの AWS アカウントと AWS リージョンのみにデプロイします。マルチアカウントおよびマルチリージョンデプロイには、構成の変更が必要です。
+ このパターンでプロビジョニングされる AWS Identity and Access Management (IAM) ロール (**codepipeline\$1iam\$1role**) は、最小特権の原則に従います。IAM ロールの権限は、パイプラインが作成する必要のある特定のリソースに基づいて更新する必要があります。****
**製品バージョン**
+ AWS CLI バージョン 2.9.15 以降
+ Terraform バージョン 1.3.7 以降:
## アーキテクチャ
**ターゲットテクノロジースタック**
+ AWS CodePipeline
+ AWS CodeBuild
+ AWS CodeCommit
+ AWS IAM
+ Amazon Simple Storage Service (Amazon S3)
+ AWS Key Management Service (AWS KMS)
+ Terraform
**ターゲットアーキテクチャ**
次の図は、CodePipeline で Terraform 構成をテストするための CI/CD パイプラインワークフローの例を示しています。
![\[AWS CI/CD パイプラインを使用して Terraform 設定をテストするアーキテクチャ。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/4df7b1f8-8eef-4d85-a971-a7f158be9691/images/90b931c8-e745-4b52-92de-a367fb0f1f51.png)
この図表は、次のワークフローを示しています:
1. CodePipeline では、AWS ユーザーは AWS CLI で `terraform apply` コマンドを実行して Terraform プランで提案されているアクションを開始します。
1. AWS CodePipeline は、CodeCommit、CodeBuild、AWS KMS、Amazon S3 へのアクセスに必要なポリシーを含む IAM サービスロールを引き受けます。
1. CodePipelineは、`"checkout"` パイプラインステージを実行して、テスト用に AWS CodeCommit リポジトリから Terraform 構成を取得します。
1. CodePipeline は、CodeBuild プロジェクトで IaC 検証ツールを実行し、Terraform IaC 検証コマンドを実行して Terraform 構成をテストする `"validate"` ステージを実行します。
1. CodePipeline は `"plan"` ステージを実行し、Terraform 構成に基づいて CodeBuild プロジェクトでプランを作成します。AWS ユーザーは、変更をテスト環境に適用する前にこのプランを確認できます。
1. Code Pipeline は、CodeBuild プロジェクトを使用してテスト環境に必要なインフラストラクチャをプロビジョニングすることで、プランを実装する `"apply"` ステージを実行します。
1. CodePipeline は、`"destroy"` ステージを実行することで、`"apply"` ステージ中に作成されたテストインフラストラクチャを CodeBuild で削除します。
1. Amazon S3 バケットには、AWS KMS [カスタマーマネージドキー](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk)を使用して暗号化および復号化されたパイプラインアーティファクトが格納されます。
## ツール
**ツール**
*AWS サービス*
+ [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) は、ソフトウェアリリースのさまざまな段階を迅速にモデル化および設定し、ソフトウェアの変更を継続的にリリースするために必要なステップを自動化するのに役立ちます。
+ [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) はフルマネージドの構築サービスです。ソースコードのコンパイル、ユニットテストの実行、すぐにデプロイできるアーティファクトの生成を行います。
+ [AWS CodeCommit](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html) は、独自のソースコントロールシステムを管理しなくても、Git リポジトリを非公開で保存および管理できるバージョン管理サービスです。
+ 「[AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)」は、AWS リソースへのアクセスを安全に管理し、誰が認証され、使用する権限があるかを制御するのに役立ちます。
+ [AWS Key Management Service (AWS KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) は、データの保護に役立つ暗号キーを作成および管理する上で役立ちます。
+ [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) は、任意のデータ量を保存、保護、取得する際に役立つクラウドベースのオブジェクトストレージサービスです。
*その他のサービス*
+ [HashiCorp Terraform](https://www.terraform.io/docs) は、コードを使用してクラウドインフラストラクチャとリソースをプロビジョニングおよび管理するのに役立つコマンドラインインターフェイスアプリケーションです。
**コード**
このパターンのコードは、GitHub 内の「[aws-codepipeline-terraform-cicdsamples](https://github.com/aws-samples/aws-codepipeline-terraform-cicd-samples)」リポジトリで利用できます。リポジトリには、このパターンで概説されているターゲットアーキテクチャの作成に必要な Terraform 構成が含まれています。
## エピック
### ソリューションコンポーネントのプロビジョニング
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| GitHub リポジトリのクローン作成 | ターミナルウィンドウで以下のコマンドを実行して GitHub の [aws-codepipeline-terraform-cicdsamples](https://github.com/aws-samples/aws-codepipeline-terraform-cicd-samples) リポジトリをクローン作成します。git clone https://github.com/aws-samples/aws-codepipeline-terraform-cicd-samples.git
詳細については、GitHub ドキュメントの「[リポジトリのクローン作成](https://docs.github.com/en/repositories/creating-and-managing-repositories/cloning-a-repository)」を参照してください。 | DevOps エンジニア |
| Terraform 変数定義ファイルを作成する。 | ユースケース要件に基づいて `terraform.tfvars` ファイルを作成します。クローン作成したリポジトリにある `examples/terraform.tfvars` ファイル内の変数を更新できます。詳細については、Terraform ドキュメントの「[ルートモジュール変数への値の割り当て](https://developer.hashicorp.com/terraform/language/values/variables#assigning-values-to-root-module-variables)」を参照してください。リポジトリの `Readme.md` ファイルには、必要な変数に関する詳細情報が含まれています。 | DevOps エンジニア |
| AWS を Terraform プロバイダーとして構成する。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-a-ci-cd-pipeline-to-validate-terraform-configurations-by-using-aws-codepipeline.html)詳細については、[ のプロバイダー](https://registry.terraform.io/providers/hashicorp/aws/latest/docs)を参照してください。 | DevOps エンジニア |
| Amazon S3 レプリケーションバケットを作成するための Terraform プロバイダー構成を更新する。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-a-ci-cd-pipeline-to-validate-terraform-configurations-by-using-aws-codepipeline.html)レプリケーションを使用すると、Amazon S3 バケット間でオブジェクトを自動で非同期的にコピーできます。 | DevOps エンジニア |
| Terraform 構成を初期化します。 | Terraform 構成ファイルを含む作業ディレクトリを初期化するには、クローン作成したリポジトリのルートフォルダで以下のコマンドを実行します。terraform init
| DevOps エンジニア |
| Terraform プランを作成します。 | Terraform プランを作成するには、クローン作成したリポジトリのルートフォルダで以下のコマンドを実行します。terraform plan --var-file=terraform.tfvars -out=tfplan
Terraform は設定ファイルを評価して、宣言されたリソースのターゲット状態を判断します。次に、ターゲットの状態を現在の状態と比較し、プランを作成します。 | DevOps エンジニア |
| Terraform プランを検証します。 | Terraform プランを確認し、ターゲット AWS アカウントで必要なアーキテクチャが構成されていることを確認します。 | DevOps エンジニア |
| ソリューションのデプロイ | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-a-ci-cd-pipeline-to-validate-terraform-configurations-by-using-aws-codepipeline.html)Terraform は、構成ファイルに宣言されている目標状態を達成するために、インフラストラクチャを作成、更新、または破棄します。 | DevOps エンジニア |
### パイプラインを実行して Terraform の構成を検証します。
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| ソースコードリポジトリをセットアップします。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-a-ci-cd-pipeline-to-validate-terraform-configurations-by-using-aws-codepipeline.html) | DevOps エンジニア |
| パイプラインのステージを検証します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-a-ci-cd-pipeline-to-validate-terraform-configurations-by-using-aws-codepipeline.html)詳細については、*AWS CodePipeline ユーザーガイド*の「[パイプラインの詳細と履歴を表示する (コンソール)](https://docs.aws.amazon.com/codepipeline/latest/userguide/pipelines-view-console.html)」を参照してください。ソースリポジトリのメインブランチに変更がコミットされると、テストパイプラインは自動的に有効になります。 | DevOps エンジニア |
| レポート出力を確認します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-a-ci-cd-pipeline-to-validate-terraform-configurations-by-using-aws-codepipeline.html)`-validate` CodeBuild プロジェクトは、`"validate"` ステージ中にコードの脆弱性レポートを生成します。 | DevOps エンジニア |
### リソースのクリーンアップ
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| パイプラインと関連リソースをクリーンアップします。 | AWS アカウントからテストリソースを削除するには、クローン作成したリポジトリのルートフォルダで次のコマンドを実行します。terraform destroy --var-file=terraform.tfvars
| DevOps エンジニア |
## トラブルシューティング
| 問題 | ソリューション |
| --- | --- |
| `"apply"` ステージ中に **AccessDenied** エラーが表示される。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/create-a-ci-cd-pipeline-to-validate-terraform-configurations-by-using-aws-codepipeline.html) |
## 関連リソース
+ [Module blocks](https://developer.hashicorp.com/terraform/language/modules/syntax) (Terraform ドキュメント)
+ [How to use CI/CD to deploy and configure AWS security services with Terraform](https://aws.amazon.com/blogs/security/how-use-ci-cd-deploy-configure-aws-security-services-terraform/) (AWS ブログ投稿)
+ [サービスにリンクされたロールの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html) (IAM ドキュメント)
+ [create-pipeline](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/codepipeline/create-pipeline.html) (AWS CLI ドキュメント)
+ [Configure server-side encryption for artifacts stored in Amazon S3 for CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/S3-artifact-encryption.html) (AWS CodePipeline ドキュメント)
+ [Quotas for AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/limits.html) (AWS CodeBuild ドキュメント)
+ [Data protection in AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/data-protection.html) (AWS CodePipeline ドキュメント)
## 追加情報
**カスタム Terraform モジュール**
以下は、このパターンで使用されるカスタム Terraform モジュールのリストです。
+ `codebuild_terraform` は、パイプラインの各ステージを形成する CodeBuild プロジェクトを作成します。
+ `codecommit_infrastructure_source_repo` は、ソース CodeCommit リポジトリをキャプチャして作成します。
+ `codepipeline_iam_role` は、パイプラインに必要な IAM ロールを作成します。
+ `codepipeline_kms` は、Amazon S3 オブジェクトの暗号化と復号化に必要な AWS KMS キーを作成します。
+ `codepipeline_terraform` は、ソース CodeCommit リポジトリのテストパイプラインを作成します。
+ `s3_artifacts_bucket` は、Amazon S3 バケットを作成して、パイプラインアーティファクトを管理します。
**ビルド仕様ファイル**
以下は、このパターンが各パイプラインステージを実行するために使用するビルド仕様 (buildspec) ファイルのリストです。
+ `buildspec_validate.yml` は、`"validate"` ステージを実行します。
+ `buildspec_plan.yml` は、`"plan"` ステージを実行します。
+ `buildspec_apply.yml` は、`"apply"` ステージを実行します。
+ `buildspec_destroy.yml` は、`"destroy"` ステージを実行します。
*ビルド仕様ファイル変数*
各 buildspec ファイルは次の変数を使用して異なるビルド固有の設定を有効にします。
|
|
| 変数 | デフォルトの 値 | 説明 |
| --- |--- |--- |
| `CODE_SRC_DIR` | "." | ソース CodeCommit ディレクトリを定義します。 |
| `TF_VERSION` | 「1.3.7」 | ビルド環境の Terraform バージョンを定義します。 |
`buildspec_validate.yml` ファイルでは、さまざまなビルド固有の設定を有効にする以下の変数もサポートしています。
|
|
| 変数 | デフォルトの 値 | 説明 |
| --- |--- |--- |
| `SCRIPT_DIR` | 「./templates/scripts」 | スクリプトディレクトリを定義します。 |
| `ENVIRONMENT` | 「dev」 | 環境名を定義します |
| `SKIPVALIDATIONFAILURE` | 「Y」 | 障害発生時の検証をスキップします |
| `ENABLE_TFVALIDATE` | 「Y」 | Terraform 検証を有効にします |
| `ENABLE_TFFORMAT` | 「Y」 | Terraform フォーマットを有効にします |
| `ENABLE_TFCHECKOV` | 「Y」 | checkovスキャンを有効にします |
| `ENABLE_TFSEC` | 「Y」 | tfsec スキャンを有効にします |
| `TFSEC_VERSION` | 「v1.28.1」 | tfsec バージョンを定義します。 |
# その他のパターン
**Topics**
+ [AWS PrivateLink と Network Load Balancer を使用して、Amazon EKS 上のコンテナアプリケーションにプライベートアクセスします。](access-container-applications-privately-on-amazon-eks-using-aws-privatelink-and-a-network-load-balancer.md)
+ [ある の AWS CodeCommit リポジトリ AWS アカウント を別のアカウントの Amazon SageMaker AI Studio Classic に関連付ける](associate-an-aws-codecommit-repository-in-one-aws-account-with-sagemaker-studio-in-another-account.md)
+ [で Landing Zone Accelerator を使用してアカウントの作成を自動化する AWS](automate-account-creation-lza.md)
+ [AWS Systems Manager を使用して Windows レジストリエントリの追加または更新を自動化する](automate-adding-or-updating-windows-registry-entries-using-aws-systems-manager.md)
+ [AWS Batch を使用して Amazon RDS for PostgreSQL DBインスタンスのバックアップを自動化します](automate-backups-for-amazon-rds-for-postgresql-db-instances-by-using-aws-batch.md)
+ [AWS SAM を使用してネストされたアプリケーションのデプロイを自動化](automate-deployment-of-nested-applications-using-aws-sam.md)
+ [CI/CD パイプラインを使用して Amazon EKS へのノード終了ハンドラーのデプロイを自動化する](automate-deployment-of-node-termination-handler-in-amazon-eks-by-using-a-ci-cd-pipeline.md)
+ [Amazon MQ で RabbitMQ 設定を自動化する](automate-rabbitmq-configuration-in-amazon-mq.md)
+ [間の Amazon RDS インスタンスのレプリケーションを自動化する AWS アカウント](automate-the-replication-of-amazon-rds-instances-across-aws-accounts.md)
+ [CI/CD パイプラインを使用して Amazon EKS へ Java アプリケーションを自動的にビルドし、デプロイする](automatically-build-and-deploy-a-java-application-to-amazon-eks-using-a-ci-cd-pipeline.md)
+ [Python アプリケーションを使用して Amazon DynamoDB の PynamoDB モデルと CRUD 関数を自動的に生成する](automatically-generate-a-pynamodb-model-and-crud-functions-for-amazon-dynamodb-by-using-a-python-application.md)
+ [CodePipeline、IAM アクセスアナライザー、AWS CloudFormation マクロを使用して、IAM ポリシーとロールを自動的に検証してデプロイする](automatically-validate-and-deploy-iam-policies-and-roles-in-an-aws-account-by-using-codepipeline-iam-access-analyzer-and-aws-cloudformation-macros.md)
+ [の Stromasys Charon-SSP エミュレータで Sun SPARC サーバーをバックアップする AWS クラウド](back-up-sun-sparc-servers-in-the-stromasys-charon-ssp-emulator-on-the-aws-cloud.md)
+ [AWS DataOps Development Kit を使用して Google Analytics データを取り込み、変換、分析するためのデータパイプラインを構築する](build-a-data-pipeline-to-ingest-transform-and-analyze-google-analytics-data-using-the-aws-dataops-development-kit.md)
+ [Amazon EC2 Auto Scaling と Systems Manager を搭載した Micro Focus Enterprise Server PAC を構築する](build-a-micro-focus-enterprise-server-pac-with-amazon-ec2-auto-scaling-and-systems-manager.md)
+ [EC2 Image Builder と Terraform を使用して、強化されたコンテナイメージ用のパイプラインを構築する](build-a-pipeline-for-hardened-container-images-using-ec2-image-builder-and-terraform.md)
+ [Amazon SageMaker AI と Azure DevOps を使用して MLOps ワークフローを構築する](build-an-mlops-workflow-by-using-amazon-sagemaker-and-azure-devops.md)
+ [AWS Managed Microsoft AD とオンプレミスの Microsoft Active Directory を使用して DNS 解決を一元化する](centralize-dns-resolution-by-using-aws-managed-microsoft-ad-and-on-premises-microsoft-active-directory.md)
+ [ステートファイルが失われた後、 AWS Account Factory for Terraform (AFT) リソースを安全にクリーンアップする](clean-up-aft-resources-safely-after-state-file-loss.md)
+ [NLog を使用して Amazon CloudWatch Logs 内の.NET アプリケーションのロギングを設定します](configure-logging-for-net-applications-in-amazon-cloudwatch-logs-by-using-nlog.md)
+ [AWS アカウント と 間で Amazon ECR コンテナイメージをコピーする AWS リージョン](copy-ecr-container-images-across-accounts-regions.md)
+ [SageMaker 用のカスタム Docker コンテナイメージを作成し、AWS Step Functions のモデルトレーニングに使用する](create-a-custom-docker-container-image-for-sagemaker-and-use-it-for-model-training-in-aws-step-functions.md)
+ [AWS CodePipeline に適用されない AWS リージョンにパイプラインを作成](create-a-pipeline-in-aws-regions-that-don-t-support-aws-codepipeline.md)
+ [Amazon CloudWatch 異常検知により、カスタムメトリクスのアラームを作成](create-alarms-for-custom-metrics-using-amazon-cloudwatch-anomaly-detection.md)
+ [AWS CDK アスペクトとエスケープハッチを使用してデフォルトのロール名をカスタマイズする](customize-default-role-names-by-using-aws-cdk-aspects-and-escape-hatches.md)
+ [複数のコード成果物のセキュリティ問題を一斉に検出するパイプラインをデプロイする](deploy-a-pipeline-that-simultaneously-detects-security-issues-in-multiple-code-deliverables.md)
+ [インフラストラクチャをコードとして使用して、AWS クラウドにサーバーレスデータレイクをデプロイして管理する](deploy-and-manage-a-serverless-data-lake-on-the-aws-cloud-by-using-infrastructure-as-code.md)
+ [Docker コンテナとして AWS IoT Greengrass V2 実行されている にコンテナ化されたアプリケーションをデプロイする](deploy-containerized-applications-on-aws-iot-greengrass-version-2-running-as-a-docker-container.md)
+ [Amazon EKS と Amazon S3 の Helm チャートリポジトリを使用して Kubernetes のリソースとパッケージをデプロイする](deploy-kubernetes-resources-and-packages-using-amazon-eks-and-a-helm-chart-repository-in-amazon-s3.md)
+ [AWS CDK と TypeScript を使用してマルチスタックのアプリケーションをデプロイする](deploy-multiple-stack-applications-using-aws-cdk-with-typescript.md)
+ [Kiro やその他のコーディングアシスタントで MCP サーバーを使用してリアルタイムのコーディングセキュリティ検証をデプロイする](deploy-real-time-coding-security-validation-by-using-an-mcp-server-with-kiro-and-other-coding-assistants.md)
+ [Terraform を使用して SQL Server フェイルオーバークラスターインスタンスを Amazon EC2 および Amazon FSx にデプロイする](deploy-sql-server-failover-cluster-instances-on-amazon-ec2-and-amazon-fsx.md)
+ [Terraform を使用して AWS WAF ソリューションのセキュリティオートメーションをデプロイする](deploy-the-security-automations-for-aws-waf-solution-by-using-terraform.md)
+ [RAG と ReAct プロンプトを使用して高度な生成 AI チャットベースのアシスタントを開発する](develop-advanced-generative-ai-chat-based-assistants-by-using-rag-and-react-prompting.md)
+ [AWS CloudFormation テンプレートを使用して Amazon GuardDuty を条件付きで有効にする](enable-amazon-guardduty-conditionally-by-using-aws-cloudformation-templates.md)
+ [Amazon EKS Pod Identity と KEDA を使用して Amazon EKS でイベント駆動型自動スケーリングをセットアップする](event-driven-auto-scaling-with-eks-pod-identity-and-keda.md)
+ [Amazon Personalize を使用して、パーソナライズされ再ランク付けされたレコメンデーションを生成します](generate-personalized-and-re-ranked-recommendations-using-amazon-personalize.md)
+ [AWS KMS キーのキーの状態が変更されたときに Amazon SNS 通知を受け取る](get-amazon-sns-notifications-when-the-key-state-of-an-aws-kms-key-changes.md)
+ [Account Factory for Terraform を使用して複数のアカウントのアクセス許可セットを管理する](govern-permission-sets-aft.md)
+ [Amazon ECR リポジトリに移行するときに、重複するコンテナイメージを自動的に識別する](identify-duplicate-container-images-automatically-when-migrating-to-ecr-repository.md)
+ [Amazon API Gateway でカスタムドメインを使用してパスベースの API バージョニングを実装する](implement-path-based-api-versioning-by-using-custom-domains.md)
+ [AWS CDK を使用して複数の AWS リージョン、アカウント、OU にわたって Amazon DevOps Guru を有効にすることで、運用パフォーマンスを向上させます。](improve-operational-performance-by-enabling-amazon-devops-guru-across-multiple-aws-regions-accounts-and-ous-with-the-aws-cdk.md)
+ [Kubernetes DaemonSet を使用して Amazon EKS ワーカーノードに SSM エージェントをインストールします](install-ssm-agent-on-amazon-eks-worker-nodes-by-using-kubernetes-daemonset.md)
+ [Stonebranch ユニバーサルコントローラーと AWS Mainframe Modernizationを統合](integrate-stonebranch-universal-controller-with-aws-mainframe-modernization.md)
+ [メインフレームのモダナイゼーション: Rocket Software Enterprise Suite AWS を使用した での DevOps](mainframe-modernization-devops-on-aws-with-micro-focus.md)
+ [を使用してアクセス AWS IAM アイデンティティセンター 許可セットをコードとして管理する AWS CodePipeline](manage-aws-iam-identity-center-permission-sets-as-code-by-using-aws-codepipeline.md)
+ [Terraform を使用して AWS アクセス許可セットを動的に管理する](manage-aws-permission-sets-dynamically-by-using-terraform.md)
+ [AWS CDK で Amazon ECS Anywhere を設定して、オンプレミスコンテナアプリケーションを管理します。](manage-on-premises-container-applications-by-setting-up-amazon-ecs-anywhere-with-the-aws-cdk.md)
+ [AWS CodePipeline と Amazon Bedrock を使用して AWS Organizations ポリシーをコードとして管理する](manage-organizations-policies-as-code.md)
+ [DNS レコードを Amazon Route 53 プライベートホストゾーンに一括で移行する](migrate-dns-records-in-bulk-to-an-amazon-route-53-private-hosted-zone.md)
+ [appcmd.exe を使用して IIS がホストするアプリケーションを Amazon EC2 に移行する](migrate-iis-hosted-applications-to-amazon-ec2-by-using-appcmd.md)
+ [複数の で共有 Amazon マシンイメージの使用をモニタリングする AWS アカウント](monitor-use-of-a-shared-amazon-machine-image-across-multiple-aws-accounts.md)
+ [を使用して、検証、変換、パーティショニングで ETL パイプラインをオーケストレーションする AWS Step Functions](orchestrate-an-etl-pipeline-with-validation-transformation-and-partitioning-using-aws-step-functions.md)
+ [IaC 原則を使用して Amazon Aurora Global Database のブルー/グリーンデプロイを自動化する](p-automate-blue-green-deployments-aurora-global-databases-iac.md)
+ [非ワークロードサブネット用のマルチアカウント VPC 設計でルーティング可能な IP スペースを節約](preserve-routable-ip-space-in-multi-account-vpc-designs-for-non-workload-subnets.md)
+ [コードリポジトリ AWS Service Catalog を使用して で Terraform 製品をプロビジョニングする](provision-a-terraform-product-in-aws-service-catalog-by-using-a-code-repository.md)
+ [AWS Step Functions から AWS Systems Manager Automation タスクを同期的に実行する](run-aws-systems-manager-automation-tasks-synchronously-from-aws-step-functions.md)
+ [AWS CDK と GitLab を使用して、Amazon ECS Anywhere 上のハイブリッドワークロード用に CI/CD パイプラインを設定する](set-up-a-ci-cd-pipeline-for-hybrid-workloads-on-amazon-ecs-anywhere-by-using-aws-cdk-and-gitlab.md)
+ [Terraform を使用してデータベース移行用の CI/CD パイプラインを設定する](set-up-ci-cd-pipeline-for-db-migration-with-terraform.md)
+ [Amazon FSx を使用して SQL Server Always On FCI 向けのマルチ AZ インフラストラクチャをセットアップする](set-up-multi-az-infrastructure-for-a-sql-server-always-on-fci-by-using-amazon-fsx.md)
+ [AWS CloudFormation を使用して Amazon EC2 に UiPath RPA ボットを自動的にセットアップする](set-up-uipath-rpa-bots-automatically-on-amazon-ec2-by-using-aws-cloudformation.md)
+ [Application Load Balancer を使用して Amazon ECS の相互 TLS でアプリケーション認証を簡素化する](simplify-application-authentication-with-mutual-tls-in-amazon-ecs.md)
+ [C\$1 と AWS CDK を使用するサイロモデル用の SaaS アーキテクチャでのテナントオンボーディング](tenant-onboarding-in-saas-architecture-for-the-silo-model-using-c-and-aws-cdk.md)
+ [Terraform を使用すると、組織の Amazon GuardDuty が自動的に有効になります。](use-terraform-to-automatically-enable-amazon-guardduty-for-an-organization.md)
+ [Amazon Bedrock エージェントを使用してテキストベースのプロンプトで Amazon EKS でのアクセスエントリコントロールの作成を自動化する](using-amazon-bedrock-agents-to-automate-creation-of-access-entry-controls-in-amazon-eks.md)
+ [Account Factory for Terraform (AFT) のコードをローカルで検証する](validate-account-factory-for-terraform-aft-code-locally.md)
+ [フラスコと AWS Elastic Beanstalk を使用して AI/ML モデルの結果を視覚化](visualize-ai-ml-model-results-using-flask-and-aws-elastic-beanstalk.md)