2. これらの値をプロジェクトのルートディレクトリにある `run.sh` スクリプトに貼り付けます。BACKEND_BUCKET_ID=""
DYNAMODB_ID=""
3. プロジェクトコードを CodeCommit リポジトリにアップロードします。`demo/pipeline/locals.tf` ファイルの次の変数を `true` に設定することにより、Terraform からこのリポジトリを自動的に作成できます。create_new_repo = true
4. 要件に従って `locals.tf` ファイルを更新し、パイプラインリソースを作成します。 | 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 |
### ネットワークインフラストラクチャを作成する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| パイプラインを開始します。 | 1. `templates` フォルダで、`buildspec` ファイルの次の変数が `network` に設定されていることを確認します。TF_MODULE_TO_BUILD: "network"
2. [CodePipeline コンソール](https://console.aws.amazon.com/codesuite/codepipeline/home)のパイプラインの詳細ページで、**[変更のリリース]** を選択してパイプラインを開始します。初めて実行した後は、CodeCommit リポジトリのメインブランチに変更をコミットするたびに、パイプラインが自動的に開始されます。
パイプラインには次の[ステージ](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts.html#concepts-stages)が含まれます。+ `validate` は Terraform を初期化し、[checkov](https://www.checkov.io/) ツールと [tfsec](https://github.com/aquasecurity/tfsec) ツールを使用して Terraform セキュリティスキャンを実行し、スキャンレポートを S3 バケットにアップロードします。
+ `plan ` は Terraform プランを表示し、そのプランを S3 バケットにアップロードします。
+ `apply` は S3 バケットから Terraform プラン出力を適用し、 AWS リソースを作成します。
+ `destroy` は、`apply`ステージ中に作成された AWS リソースを削除します。このオプションのステージを有効にするには、`demo/pipeline/locals.tf` ファイルで次の変数を `true` に設定します。enable_destroy_stage = true
| AWS DevOps |
| ネットワークモジュールを通じて作成されたリソースを検証します。 | パイプラインが正常にデプロイされた後に、次の AWS リソースが作成されていることを確認します。+ 3 つのパブリックサブネットと 3 つのプライベートサブネット、インターネットゲートウェイ、NAT ゲートウェイを備えた Egress VPC。
+ 3 つのプライベートサブネットを持つ Amazon EKS VPC。
+ それぞれ 3 つのプライベートサブネットを持つテナント 1 とテナント 2 VPC。
+ すべての VPC アタッチメントと各プライベートサブネットへのルートを持つトランジットゲートウェイ。
+ 送信先 CIDR ブロックが `0.0.0.0/0` の Amazon EKS Egress VPC の静的トランジットゲートウェイルート。これは、すべての VPC が Amazon EKS Egress VPC を介してアウトバウンドインターネットアクセスできるようにするために必要です。 | AWS DevOps |
### コンピューティングインフラストラクチャを作成する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| `locals.tf` を更新して、CodeBuild プロジェクトの VPC へのアクセスを有効にします。 | Amazon EKS プライベートクラスターのアドオンをデプロイするには、CodeBuild プロジェクトを Amazon EKS VPC にアタッチする必要があります。1. `demo/pipeline` フォルダで `locals.tf` ファイルを開き、`vpc_enabled` 変数を `true` に設定します。
2. `run.sh` スクリプトを実行して、パイプラインモジュールに変更を適用します。demo/pipeline/locals.tf
./run.sh -m pipeline -env demo -region -tfcmd init
./run.sh -m pipeline -env demo -region -tfcmd plan
./run.sh -m pipeline -env demo -region -tfcmd apply
| AWS DevOps |
| `buildspec` ファイルを更新してコンピューティングモジュールを構築します。 | `templates` フォルダのすべての `buildspec` YAML ファイルで、`TF_MODULE_TO_BUILD` 変数の値を `network` から `compute` に設定します。TF_MODULE_TO_BUILD: "compute"
| AWS DevOps |
| テナント管理 Helm チャートの `values` ファイルを更新します。 | 1. 次の場所で `values.yaml` ファイルを開きます。cd cfg-terraform/demo/compute/cfg-tenant-mgmt
ファイルは次のようになります。---
global:
clusterRoles:
operator: platform-tenant
flux: flux-tenant-applier
flux:
tenantCloneBaseUrl: ${TEANT_BASE_URL}
repoSecret: ${TENANT_REPO_SECRET}
tenants:
tenant-1:
quotas:
limits:
cpu: 1
memory: 1Gi
flux:
path: overlays/tenant-1
tenant-2:
quotas:
limits:
cpu: 1
memory: 2Gi
flux:
path: overlays/tenant-2
2. `global` および `tenants` セクションで、要件に基づいて設定を更新します。`tenantCloneBaseUrl` – すべてのテナントのコードをホストするリポジトリへのパス (すべてのテナントに同じ Git リポジトリを使用します)`repoSecret` – グローバルテナント Git リポジトリに対して認証するための SSH キーと既知のホストを保持する Kubernetes シークレット`quotas` – テナントごとに適用する Kubernetes リソースクォータ`flux path` – グローバルテナントリポジトリ内のテナントアプリケーション YAML ファイルへのパス | AWS DevOps |
| コンピューティングリソースを検証します。 | 前のステップでファイルを更新すると、CodePipeline が自動的に起動します。コンピューティングインフラストラクチャ用に次の AWS リソースが作成されていることを確認します。+ プライベートエンドポイントを持つ Amazon EKS クラスター
+ Amazon EKS ワーカーノード
+ Amazon EKS アドオン: 外部シークレット、`aws-loadbalancer-controller`、`metrics-server`
+ GitOps モジュール、Flux Helm チャート、Cilium Helm チャート、テナント管理 Helm チャート | AWS DevOps |
### テナント管理およびその他のリソースを確認する
| タスク | 説明 | 必要なスキル |
| --- | --- | --- |
| Kubernetes のテナント管理リソースを検証します。 | 次のコマンドを実行し、Helm を使用してテナント管理リソースが正常に作成されたことを確認します。1. `values.yaml` で指定されているとおり、テナント名前空間が作成されました。kubectl get ns -A
2. クォータは、`values.yaml` で指定されているとおり、各テナント名前空間に割り当てられます。kubectl get quota --namespace=
3. 各テナント名前空間のクォータの詳細は正確です。kubectl describe quota cpu-memory-resource-quota-limit -n
4. Cilium ネットワークポリシーが各テナント名前空間に適用されました。kubectl get CiliumNetworkPolicy -A
| AWS DevOps |
| テナントアプリケーションのデプロイを確認します。 | 次のコマンドを実行して、テナントアプリケーションがデプロイされたことを確認します。1. Flux は、GitOps モジュールで指定された CodeCommit リポジトリに接続できます。kubectl get gitrepositories -A
2. Flux kustomization Controller は、CodeCommit リポジトリに YAML ファイルをデプロイしました。kubectl get kustomizations -A
3. すべてのアプリケーションリソースはテナント名前空間にデプロイされます。kubectl get all -n
4. イングレスはテナントごとに作成されています。kubectl get ingress -n
| |
## トラブルシューティング
| 問題 | ソリューション |
| --- | --- |
| 次のようなエラーメッセージが表示されます。
`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.` | 問題のトラブルシューティングを行うには、以下の手順を実行します。1. テナントアプリケーションリポジトリを確認する: リポジトリが空であるか、設定が間違っていると、エラーが発生する可能性があります。テナントアプリケーションリポジトリに必要なコードが含まれていることを確認してください。
2. `tenant_mgmt` モジュールを再デプロイする: `tenant_mgmt` モジュール設定ファイルで、`app` ブロックを見つけ、`deploy` パラメータを `0` に設定します。deploy = 0
Terraform `apply` コマンドを実行したら、`deploy` パラメータ値を `1` に戻します。deploy = 1
3. ステータスを再確認する: 前のステップを実行した後、次のコマンドを使用して問題が解決したかどうかを確認します。 kubectl get gitrepositories -A
問題が解決しない場合は、Flux ログの詳細を確認するか、[Flux の一般的なトラブルシューティングガイド](https://fluxcd.io/flux/cheatsheets/troubleshooting/)を参照してください。 |
## 関連リソース
+ [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
```