**このページの改善にご協力ください**
このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。
# Argo CD による継続的デプロイ
Argo CD は、Kubernetes 向けの宣言型 GitOps 継続的デリバリーツールです。Argo CD を使用すると、複数のクラスターと環境にわたるアプリケーションのデプロイとライフサイクルを自動的に管理できます。Argo CD は、Git リポジトリ、Helm レジストリ (HTTP および OCI)、OCI イメージなど複数のソースタイプをサポートしており、セキュリティとコンプライアンスの要件がさまざまに異なる組織に柔軟に対応できます。
AWS では EKS の機能を使用して Argo CD を完全に管理できるため、クラスターに Argo CD コントローラーとその依存関係をインストールしてメンテナンスおよびスケールする必要がありません。
## Argo CD の仕組み
Argo CD は GitOps パターンに従い、アプリケーションソース (Git リポジトリ、Helm レジストリ、または OCI イメージ) を、目的のアプリケーション状態を定義するための信頼できるソースとします。Argo CD `Application` リソースを作成するときは、アプリケーションマニフェストが含まれているソースと、ターゲットとなる Kubernetes クラスターおよび名前空間を指定します。Argo CD は、クラスター内のソース状態とライブ状態の両方を継続的にモニタリングし、変更が加えられたら自動的に同期して、クラスターの状態が目的の状態と一致するようにします。
**注記**
EKS Capability for Argo CD では、Argo CD ソフトウェアはワーカーノードではなく AWS コントロールプレーンで動作します。つまり、ワーカーノードが Git リポジトリや Helm レジストリに直接アクセスする必要はありません。この機能は、AWS アカウントからのソースアクセスを処理します。
Argo CD には、主に 3 つのリソースタイプがあります。
+ **Application**: Git リポジトリからターゲットクラスターへのデプロイを定義します。
+ **ApplicationSet**: 複数のクラスターにデプロイできるように、テンプレートから複数の Application を生成します
+ **AppProject**: Application を論理的にグループ化し、アクセスコントロールを付与できます。
**例: Argo CD Application を作成する**
次の例は、Argo CD `Application` リソースを作成する方法を示しています。
```
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: guestbook
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/argoproj/argocd-example-apps.git
targetRevision: HEAD
path: guestbook
destination:
name: in-cluster
namespace: guestbook
syncPolicy:
automated:
prune: true
selfHeal: true
```
**注記**
クラスターの登録時に使用したクラスター名で `destination.name` を使用します (ローカルクラスターの `in-cluster` の場合など)。`destination.server` フィールドは EKS クラスター ARN でも機能しますが、読みやすくするためにクラスター名を使用することをお勧めします。
## Argo CD のメリット
GitOps ワークフローを実装しているため、Git リポジトリにアプリケーション設定を定義できます。また、目的の状態に合わせてアプリケーションを自動的に同期する機能も備えています。この Git 中心のアプローチにより、すべての変更が漏れなく監査証跡に残され、ロールバックが容易になり、既存のコードレビューおよび承認プロセスと必然的に統合されます。Argo CD は、Git の目的の状態とクラスターの実際の状態との間のドリフトを自動的に検出して調整し、デプロイと宣言された設定との整合性が確保されるようにします。
Argo CD を使用すると、単一の Argo CD インスタンスから複数のクラスターにアプリケーションをデプロイして管理できるため、マルチクラスター環境とマルチリージョン環境でのオペレーションがシンプルになります。Argo CD UI に可視化とモニタリングの機能が用意されているため、アプリケーションのデプロイステータス、ヘルス、履歴を確認できます。この UI は AWS アイデンティティセンター (以前の AWS SSO) と統合されており、認証と認可をシームレスに進めて、既存の ID 管理インフラストラクチャを使用してアクセスを制御できます。
AWS では、Argo CD が EKS マネージド機能の一部として完全に管理されるため、Argo CD インフラストラクチャを導入、設定、メンテナンスする必要がありません。AWS がスケール、パッチ適用、運用管理を行うので、チームはツールのメンテナンスではなくアプリケーションの配信に集中できます。
## AWS アイデンティティセンターとの統合
EKS マネージド機能により、Argo CD と AWS アイデンティティセンターを直接統合して、ユーザーの認証と認可をシームレスに進めることができます。Argo CD 機能を有効にすると、アイデンティティセンターのグループとユーザーを Argo CD RBAC ロールにマッピングするように AWS アイデンティティセンターの統合を設定して、Argo CD で誰がアプリケーションにアクセスおよび管理できるかを制御できます。
## 他の EKS マネージド機能との統合
Argo CD は、他の EKS マネージド機能と統合されています。
+ **Kubernetes 用 AWS コントローラー (ACK)**: Argo CD を使用すると、複数のクラスターにまたがる ACK リソースのデプロイを管理して、AWS インフラストラクチャの GitOps ワークフローを有効にできます。
+ **kro (Kube Resource Orchestrator)**: Argo CD を使用すると、複数のクラスターに kro コンポジションをデプロイして、Kubernetes エステート全体で一貫性のあるリソース構成を実現できます。
## Argo CD の使用を開始する
EKS Capability for Argo CD の使用を開始するには:
1. IAM 機能ロールを作成し、Argo CD がソースにアクセスしてアプリケーションを管理できるように必要なアクセス許可を設定します。
1. AWS コンソール、AWS CLI、または任意の Infrastructure as Code ツールを使用して、EKS クラスターに [Argo CD 機能リソースを作成](create-argocd-capability.md)します。
1. アプリケーションをデプロイするために、リポジトリアクセスを設定し、クラスターを登録します。
1. Application リソースを作成して、宣言型ソースからアプリケーションをデプロイします。
# Argo CD 機能を作成する
このトピックでは、Amazon EKS クラスターに Argo CD 機能を作成する方法について説明します。
## 前提条件
Argo CD 機能を作成する前に、以下の点を確認してください。
+ サポート対象の Kubernetes バージョン (標準サポートと延長サポートのすべてのバージョンがサポート対象) を実行している Amazon EKS クラスターが存在する
+ **AWS アイデンティティセンターが設定されている** - Argo CD の認証に必要 (ローカルユーザーはサポート対象外)
+ Argo CD に対するアクセス許可が付与された IAM 機能ロールがある
+ EKS クラスターに機能リソースを作成するための十分な IAM アクセス許可がある
+ クラスターと通信できるように `kubectl` が設定されていること
+ (オプション) Argo CD CLI をインストールしてクラスターとリポジトリの管理を容易にしている
+ (CLI/eksctl の場合) 適切な CLI ツールがインストールおよび設定されている
IAM 機能ロールを作成する手順については、「[Amazon EKS 機能 IAM ロール](capability-role.md)」を参照してください。アイデンティティセンターのセットアップについては、「[AWS アイデンティティセンターの使用を開始する](https://docs.aws.amazon.com/singlesignon/latest/userguide/getting-started.html)」を参照してください。
**重要**
Argo CD でどの AWS リソースにアクセスできるかは、どの IAM 機能ロールを使用するかによって決まります。例えば、Git リポジトリへのアクセスには CodeConnections を利用し、シークレットへのアクセスには Secrets Manager を使用します。最小特権のアクセス許可を付与した適切なロールを作成する際のガイダンスについては、「[Amazon EKS 機能 IAM ロール](capability-role.md)」および「[EKS 機能のセキュリティに関する考慮事項](capabilities-security.md)」を参照してください。
## ツールを選択する
AWS マネジメントコンソール、AWS CLI、または eksctl を使用して、Argo CD 機能を作成できます。
+ [コンソールを使用して Argo CD 機能を作成する](argocd-create-console.md) - 指示に従って操作する場合はコンソールを使用します。
+ [AWS CLI を使用して Argo CD 機能を作成する](argocd-create-cli.md) - スクリプトを作成して自動化を図る場合は AWS CLI を使用します。
+ [eksctl を使用して Argo CD 機能を作成する](argocd-create-eksctl.md) - Kubernetes ネイティブの操作をする場合は eksctl を使用します。
## Argo CD 機能を作成するとどうなるか
Argo CD 機能を作成すると、次のようになります。
1. EKS が AWS コントロールプレーンに Argo CD 機能サービスを作成します。
1. カスタムリソース定義 (CRD) がクラスターにインストールされます。
1. Kubernetes のベースラインアクセス許可を付与する機能固有のアクセスエントリポリシーを使用して、IAM 機能ロールのアクセスエントリを自動的に作成します (「[EKS 機能のセキュリティに関する考慮事項](capabilities-security.md)」を参照)。
1. Argo CD がカスタムリソース (Application、ApplicationSet、AppProject) の監視を開始します。
1. 機能のステータスが `CREATING` から `ACTIVE` に変わります。
1. Argo CD UI が URL 経由でアクセス可能になります。
機能がアクティブになったら、宣言型ソースからデプロイするようにクラスターに Argo CD Application を作成できます。
**注記**
自動的に作成されるアクセスエントリは、アプリケーションをクラスターにデプロイするアクセス許可を付与しません。アプリケーションをデプロイするには、ターゲットクラスターごとに追加の Kubernetes RBAC アクセス許可を設定する必要があります。クラスターの登録とアクセスの設定の詳細については、「[ターゲットクラスターを登録する](argocd-register-clusters.md)」を参照してください。
## 次のステップ
Argo CD 機能の作成後:
+ [Argo CD の概念](argocd-concepts.md) - GitOps の原則、同期ポリシー、マルチクラスターパターンについて学ぶ
+ [Argo CD の使用](working-with-argocd.md) - リポジトリアクセスを設定し、ターゲットクラスターを登録して、Application を作成する
+ [Argo CD に関する考慮事項](argocd-considerations.md) - マルチクラスターアーキテクチャパターンと高度な設定を探る
# コンソールを使用して Argo CD 機能を作成する
このトピックでは、AWS マネジメントコンソール を使用して Argo CD 機能を作成する方法について説明します。
## 前提条件
+ **AWS アイデンティティセンターが設定されていること** – Argo CD での認証には AWS アイデンティティセンターが必要です。ローカルユーザーはサポートされていません。AWS アイデンティティセンターをセットアップしていない場合は、「[AWS アイデンティティセンターの使用を開始する](https://docs.aws.amazon.com/singlesignon/latest/userguide/getting-started.html)」を参照してアイデンティティセンターインスタンスを作成し、「[ユーザーを追加する](https://docs.aws.amazon.com/singlesignon/latest/userguide/addusers.html)」と「[グループを追加する](https://docs.aws.amazon.com/singlesignon/latest/userguide/addgroups.html)」を参照して Argo CD へのアクセスに必要なユーザーとグループを作成します。
## Argo CD 機能を作成する
1. https://console.aws.amazon.com/eks/home\$1/clusters で Amazon EKS コンソールを開きます。
1. クラスター名を選択して、クラスターの詳細ページを開きます。
1. **[機能]** タブを選択します。
1. 左のナビゲーションで、**[Argo CD]** を選択します。
1. **[Argo CD 機能を作成]** を選択します。
1. **IAM 機能ロール**に対して以下の操作を行います。
+ IAM 機能ロールが既に存在する場合は、ドロップダウンから選択します。
+ ロールを作成する必要がある場合は、**[Argo CD ロールを作成]** を選択します。
IAM コンソールが新しいタブに開かれます。信頼ポリシーには値があらかじめ入力され、Secrets Manager にはフル読み取りアクセスが付与されています。デフォルトでは他にアクセス許可は追加されませんが、必要に応じて追加することもできます。CodeCommit リポジトリや他の AWS サービスを使用する場合は、ロールを作成する前に適切なアクセス許可を追加します。
ロールを作成して EKS コンソールに戻ると、そのロールが自動的に選択されます。
**注記**
AWS Secrets Manager または AWS CodeConnections とをオプションで統合する場合は、ロールにアクセス許可を追加する必要があります。IAM ポリシーの例と設定ガイダンスについては、「[AWS Secrets Manager を使用してアプリケーションシークレットを管理する](integration-secrets-manager.md)」および「[AWS CodeConnections を使用して Git リポジトリに接続する](integration-codeconnections.md)」を参照してください。
1. AWS アイデンティティセンターの統合を設定します。
1. **[AWS アイデンティティセンターの統合を有効にする]** を選択します。
1. ドロップダウンからアイデンティティセンターインスタンスを選択します。
1. ユーザーまたはグループを Argo CD ロール (ADMIN、EDITOR、または VIEWER) に割り当てて、RBAC 用にロールマッピングを設定します。
1. **[作成]** を選択します。
機能作成プロセスが始まります。
## 機能がアクティブであることを確認する
1. **[機能]** タブで、Argo CD 機能のステータスを表示します。
1. ステータスが `CREATING` から `ACTIVE` に変わるまで待ちます。
1. アクティブになったら、この機能を使用する準備は完了です。
機能のステータスとトラブルシューティングの詳細については、「[機能リソースの使用](working-with-capabilities.md)」を参照してください。
## Argo CD UI にアクセスする
機能がアクティブになったら、以下の手順で Argo CD UI にアクセスできます。
1. Argo CD 機能のページで、**[Argo CD UI を開く]** を選択します。
1. Argo CD UI がブラウザの新しいタブに開かれます。
1. アプリケーションの作成とデプロイの管理を UI から行えるようになりました。
## 次のステップ
+ [Argo CD の使用](working-with-argocd.md) - リポジトリを設定し、クラスターを登録し、Application を作成する
+ [Argo CD に関する考慮事項](argocd-considerations.md) - マルチクラスターアーキテクチャと高度な設定
+ [機能リソースの使用](working-with-capabilities.md) - Argo CD 機能リソースを管理する
# AWS CLI を使用して Argo CD 機能を作成する
このトピックでは、AWS CLI を使用して Argo CD 機能を作成する方法について説明します。
## 前提条件
+ **AWS CLI** バージョン `2.12.3` 以降。バージョンを確認するには、`aws --version` を実行します。詳細についてはAWS コマンドラインインターフェイスユーザーガイドの「[インストール](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)」を参照してください。
+ **`kubectl`** - Kubernetes クラスターを操作するためのコマンドラインツール。詳細については、「[`kubectl` および `eksctl` のセットアップ](install-kubectl.md)」を参照してください。
+ **AWS アイデンティティセンターが設定されていること** – Argo CD での認証には AWS アイデンティティセンターが必要です。ローカルユーザーはサポートされていません。AWS アイデンティティセンターをセットアップしていない場合は、「[AWS アイデンティティセンターの使用を開始する](https://docs.aws.amazon.com/singlesignon/latest/userguide/getting-started.html)」を参照してアイデンティティセンターインスタンスを作成し、「[ユーザーを追加する](https://docs.aws.amazon.com/singlesignon/latest/userguide/addusers.html)」と「[グループを追加する](https://docs.aws.amazon.com/singlesignon/latest/userguide/addgroups.html)」を参照して Argo CD へのアクセスに必要なユーザーとグループを作成します。
## ステップ 1: IAM 機能ロールを作成する
信頼ポリシーファイルを作成します。
```
cat > argocd-trust-policy.json << 'EOF'
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "capabilities.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
EOF
```
IAM ロールを作成します。
```
aws iam create-role \
--role-name ArgoCDCapabilityRole \
--assume-role-policy-document file://argocd-trust-policy.json
```
**注記**
AWS Secrets Manager または AWS CodeConnections とをオプションで統合する場合は、ロールにアクセス許可を追加する必要があります。IAM ポリシーの例と設定ガイダンスについては、「[AWS Secrets Manager を使用してアプリケーションシークレットを管理する](integration-secrets-manager.md)」および「[AWS CodeConnections を使用して Git リポジトリに接続する](integration-codeconnections.md)」を参照してください。
## ステップ 2: Argo CD 機能を作成する
クラスターに Argo CD 機能リソースを作成します。
まず、アイデンティティセンターを設定するための環境変数を設定します。
```
# Get your Identity Center instance ARN (replace region if your IDC instance is in a different region)
export IDC_INSTANCE_ARN=$(aws sso-admin list-instances --region [.replaceable]`region` --query 'Instances[0].InstanceArn' --output text)
# Get a user ID for RBAC mapping (replace with your username and region if needed)
export IDC_USER_ID=$(aws identitystore list-users \
--region [.replaceable]`region` \
--identity-store-id $(aws sso-admin list-instances --region [.replaceable]`region` --query 'Instances[0].IdentityStoreId' --output text) \
--query 'Users[?UserName==`your-username`].UserId' --output text)
echo "IDC_INSTANCE_ARN=$IDC_INSTANCE_ARN"
echo "IDC_USER_ID=$IDC_USER_ID"
```
アイデンティティセンター統合で機能を作成します。*region-code* をクラスターがある AWS リージョンに、*my-cluster* をクラスター名に、*idc-region-code* をお使いの IAM アイデンティティセンターが設定されているリージョンコードに置き換えます。
```
aws eks create-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-argocd \
--type ARGOCD \
--role-arn arn:aws:iam::$(aws sts get-caller-identity --query Account --output text):role/ArgoCDCapabilityRole \
--delete-propagation-policy RETAIN \
--configuration '{
"argoCd": {
"awsIdc": {
"idcInstanceArn": "'$IDC_INSTANCE_ARN'",
"idcRegion": "'[.replaceable]`idc-region-code`'"
},
"rbacRoleMappings": [{
"role": "ADMIN",
"identities": [{
"id": "'$IDC_USER_ID'",
"type": "SSO_USER"
}]
}]
}
}'
```
このコマンドはすぐに戻りますが、EKS が必要な機能インフラストラクチャとコンポーネントを作成するため、機能がアクティブになるまでにはしばらく時間がかかります。EKS は、この機能に関連する Kubernetes カスタムリソース定義をその作成時にクラスターにインストールします。
**注記**
クラスターが存在しないというエラーやアクセス許可がないというエラーが表示された場合は、以下の点を確認します。
クラスター名が正しいこと
AWS CLI が正しいリージョンに設定されていること
必要な IAM アクセス許可を追加したこと
## ステップ 3: 機能がアクティブであることを確認する
機能がアクティブになるまで待機します。*region-code* はクラスターが配置された AWS リージョンに置き換え、*my-cluster* はクラスターの名前に置き換えます。
```
aws eks describe-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-argocd \
--query 'capability.status' \
--output text
```
ステータスが `ACTIVE` と表示されたら、機能の準備は完了です。ステータスが `ACTIVE` になるまで、次のステップに進まないでください。
機能の詳細全体を表示することもできます。
```
aws eks describe-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-argocd
```
## ステップ 4: カスタムリソースが使用可能であることを確認する
機能がアクティブになったら、Argo CD カスタムリソースがクラスターで使用可能になっていることを確認します。
```
kubectl api-resources | grep argoproj.io
```
`Application` と `ApplicationSet` のリソースタイプがリストされます。
## 次のステップ
+ [Argo CD の使用](working-with-argocd.md) - リポジトリを設定し、クラスターを登録し、Application を作成する
+ [Argo CD に関する考慮事項](argocd-considerations.md) - マルチクラスターアーキテクチャと高度な設定
+ [機能リソースの使用](working-with-capabilities.md) - Argo CD 機能リソースを管理する
# eksctl を使用して Argo CD 機能を作成する
このトピックでは、eksctl で Argo CD 機能を作成する方法について説明します。
**注記**
以下のステップを実行するには、eksctl バージョン `0.220.0` 以降が必要です。バージョンを確認するには、`eksctl version` を実行します。
## ステップ 1: IAM 機能ロールを作成する
信頼ポリシーファイルを作成します。
```
cat > argocd-trust-policy.json << 'EOF'
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "capabilities.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
EOF
```
IAM ロールを作成します。
```
aws iam create-role \
--role-name ArgoCDCapabilityRole \
--assume-role-policy-document file://argocd-trust-policy.json
```
**注記**
こうした基本的なセットアップの場合、追加の IAM ポリシーは必要ありません。リポジトリ認証情報や CodeConnections に Secrets Manager を使用する場合は、ロールにアクセス許可を追加する必要があります。IAM ポリシーの例と設定ガイダンスについては、「[AWS Secrets Manager を使用してアプリケーションシークレットを管理する](integration-secrets-manager.md)」および「[AWS CodeConnections を使用して Git リポジトリに接続する](integration-codeconnections.md)」を参照してください。
## ステップ 2: AWS アイデンティティセンター設定を取得する
RBAC 設定用にアイデンティティセンターインスタンス ARN とユーザー ID を取得します。
```
# Get your Identity Center instance ARN
aws sso-admin list-instances --query 'Instances[0].InstanceArn' --output text
# Get a user ID for admin access (replace 'your-username' with your Identity Center username)
aws identitystore list-users \
--identity-store-id $(aws sso-admin list-instances --query 'Instances[0].IdentityStoreId' --output text) \
--query 'Users[?UserName==`your-username`].UserId' --output text
```
これらの値をメモしてください。次のステップで必要になります。
## ステップ 3: eksctl 設定ファイルを作成する
`argocd-capability.yaml` という名前のファイルを作成し、次の内容を記述します。各プレースホルダーの値をそれぞれクラスター名、クラスターのリージョン、IAM ロール ARN、アイデンティティセンターインスタンス ARN、アイデンティティセンターリージョン、およびユーザー ID に置き換えます。
```
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: my-cluster
region: cluster-region-code
capabilities:
- name: my-argocd
type: ARGOCD
roleArn: arn:aws:iam::[.replaceable]111122223333:role/ArgoCDCapabilityRole
deletePropagationPolicy: RETAIN
configuration:
argocd:
awsIdc:
idcInstanceArn: arn:aws:sso:::instance/ssoins-123abc
idcRegion: idc-region-code
rbacRoleMappings:
- role: ADMIN
identities:
- id: 38414300-1041-708a-01af-5422d6091e34
type: SSO_USER
```
**注記**
RBAC マッピングに複数のユーザーまたはグループを追加できます。グループの場合、`type: SSO_GROUP` を使用してグループ ID を指定します。使用可能なロールは、`ADMIN`、`EDITOR`、および `VIEWER` です。
## ステップ 4: Argo CD 機能を作成する
設定ファイルを適用します。
```
eksctl create capability -f argocd-capability.yaml
```
このコマンドはすぐに戻りますが、機能がアクティブになるまでにはしばらく時間がかかります。
## ステップ 5: 機能がアクティブであることを確認する
機能のステータスを確認します。*region-code* はクラスターがある AWS リージョンに、*my-cluster* はクラスターの名前に置き換えます。
```
eksctl get capability \
--region region-code \
--cluster my-cluster \
--name my-argocd
```
ステータスが `ACTIVE` と表示されたら、機能の準備は完了です。
## ステップ 6: カスタムリソースが使用可能であることを確認する
機能がアクティブになったら、Argo CD カスタムリソースがクラスターで使用可能になっていることを確認します。
```
kubectl api-resources | grep argoproj.io
```
`Application` と `ApplicationSet` のリソースタイプがリストされます。
## 次のステップ
+ [Argo CD の使用](working-with-argocd.md) - Argo CD Application を作成および管理する方法を学ぶ
+ [Argo CD に関する考慮事項](argocd-considerations.md) - SSO とマルチクラスターアクセスを設定する
+ [機能リソースの使用](working-with-capabilities.md) - Argo CD 機能リソースを管理する
# Argo CD の概念
Argo CD は、Git をアプリケーションデプロイの信頼できる単一のソースとして扱うことで GitOps を実装します。このトピックでは、実践的な例を取り上げ、EKS Capability for Argo CD を使用する際に知っておくべきコアとなる概念について説明します。
## Argo CD の使用を開始する
Argo CD 機能を作成したら (「[Argo CD 機能を作成する](create-argocd-capability.md)」を参照)、アプリケーションのデプロイを開始できます。この例では、クラスターの登録と Application の作成を取り上げます。
### ステップ 1: 設定
**クラスターを登録する** (必須)
アプリケーションのデプロイ先となるクラスターを登録します。この例では、Argo CD が実行されているのと同じクラスターを登録します (`in-cluster` という名前を使用すると、Argo CD のほとんどの例との互換性を維持できます)。
```
# Get your cluster ARN
CLUSTER_ARN=$(aws eks describe-cluster \
--name my-cluster \
--query 'cluster.arn' \
--output text)
# Register the cluster using Argo CD CLI
argocd cluster add $CLUSTER_ARN \
--aws-cluster-name $CLUSTER_ARN \
--name in-cluster \
--project default
```
**注記**
EKS で Argo CD 機能を使用するように Argo CD CLI を設定する方法については、「[マネージド機能で Argo CD CLI を使用する](argocd-comparison.md#argocd-cli-configuration)」を参照してください。
あるいは、Kubernetes シークレットを使用してクラスターを登録します (詳細については、「[ターゲットクラスターを登録する](argocd-register-clusters.md)」を参照)。
**リポジトリアクセスを設定する** (任意)
この例では、パブリック GitHub リポジトリを使用しているため、リポジトリの設定は不要です。プライベートリポジトリの場合は、AWS Secrets Manager、CodeConnections、または Kubernetes シークレットを使用してアクセスを設定します (詳細については、「[リポジトリアクセスを設定する](argocd-configure-repositories.md)」を参照)。
AWS サービス (ECR Helm チャート、CodeConnections、および CodeCommit) の場合、リポジトリを作成しなくても、Application リソースで直接参照できます。機能ロールには、IAM アクセス許可が必要です。詳細については、「[リポジトリアクセスを設定する](argocd-configure-repositories.md)」を参照してください。
### ステップ 2: アプリケーションの作成
`my-app.yaml` でこの Application マニフェストを作成します。
```
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: guestbook
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/argoproj/argocd-example-apps.git
targetRevision: HEAD
path: guestbook
destination:
name: in-cluster
namespace: guestbook
syncPolicy:
automated:
prune: true
selfHeal: true
syncOptions:
- CreateNamespace=true
```
Application を適用します。
```
kubectl apply -f my-app.yaml
```
この Application を適用したら、Argo CD で次の手順を実行します。1. Git からクラスターにアプリケーションを同期します (初期デプロイ)。2. Git リポジトリに対する変更をモニタリングします。3. 今後変更があればクラスターに自動的に同期します。4. 目的の状態からのドリフトを検出して修正します。5. UI でヘルスステータスと同期履歴を提供します。
アプリケーションのステータスを表示します。
```
kubectl get application guestbook -n argocd
```
Argo CD CLI または Argo CD UI (クラスターの [機能] タブの EKS コンソールからアクセス可能) を使用して、アプリケーションを表示することもできます。
**注記**
マネージド機能で Argo CD CLI を使用する場合は、名前空間プレフィックス `argocd app get argocd/guestbook` を使用してアプリケーションを指定します。
**注記**
`destination.name` でクラスター名 (クラスターの登録時に使用した名前) を使用します。マネージド機能は、ローカルのクラスター内デフォルト (`kubernetes.default.svc`) をサポートしていません。
## 重要な概念
### GitOps の原則とソースタイプ
Argo CD は、GitOps を実装しており、アプリケーションソースがデプロイの信頼できる単一のソースとなります。
+ **宣言型** - 目的の状態は、YAML マニフェスト、Helm チャート、または Kustomize オーバーレイを使用して宣言されます。
+ **バージョン管理** - すべての変更が完全な監査証跡で追跡されます。
+ **自動** - Argo CD は、ソースを継続的にモニタリングし、変更を自動的に同期します。
+ **自己修復** - 目的のクラスター状態と実際のクラスター状態とのドリフトを検出して修正します。
**サポートされているソースタイプ**:
+ **Git リポジトリ** - GitHub、GitLab、Bitbucket、CodeCommit (HTTPS、SSH、または CodeConnections)
+ **Helm レジストリ** - HTTP レジストリ (`https://aws.github.io/eks-charts` など) および OCI レジストリ (`public.ecr.aws` など)
+ **OCI イメージ** - マニフェストまたは Helm チャートが含まれているコンテナイメージ (`oci://registry-1.docker.io/user/my-app` など)
この柔軟性により、組織のセキュリティ要件とコンプライアンス要件を満たすソースを選択できます。例えば、クラスターからの Git アクセスを制限する場合は、Helm チャートや OCI イメージに ECR を使用できます。
詳細は、Argo CD ドキュメントの「[Application ソース](https://argo-cd.readthedocs.io/en/stable/user-guide/application-sources/)」を参照してください。
### 同期と調整
Argo CD は、ソースとクラスターを継続的にモニタリングして、差分を検出して修正します。
1. 変更がないかソースをポーリングします (デフォルト: 6 分ごと)。
1. 目的の状態とクラスターの状態を比較します。
1. アプリケーションを `Synced` または `OutOfSync` としてマークします。
1. 変更を自動的に同期するか (設定されている場合)、手動による承認を待ちます。
1. 同期後にリソースのヘルスをモニタリングします。
**同期ウェーブ**は、注釈を使用してリソースの作成順序を制御します。
```
metadata:
annotations:
argocd.argoproj.io/sync-wave: "0" # Default if not specified
```
リソースはウェーブ順に適用されます (先頭は `-1` のような負の数値など、小さい数値です)。指定しない場合は、ウェーブ `0` がデフォルトになります。これにより、サービス (ウェーブ `1`) の前にデプロイ (ウェーブ `0`)、その前に名前空間 (ウェーブ `-1`) などの依存関係を作成できます。
**自己修復**は、手動による変更を自動的に元に戻します。
```
spec:
syncPolicy:
automated:
selfHeal: true
```
**注記**
マネージド機能は、注釈ベース (ラベルベースではない) のリソース追跡を使用して、Kubernetes の規則やその他のツールとの互換性を高めます。
同期フェーズ、フック、高度なパターンの詳細については、[Argo CD 同期のドキュメント](https://argo-cd.readthedocs.io/en/stable/user-guide/sync-waves/)を参照してください。
### アプリケーションのヘルス
Argo CD は、アプリケーション内のすべてのリソースのヘルスをモニタリングします。
**ヘルスステータス**: \$1 **正常** - すべてのリソースが想定どおりに動作している \$1 **進行中** - リソースが作成中または更新中 \$1 **低下** - 一部のリソースが正常でない (ポッドのクラッシュやジョブの失敗) \$1 **中断** - アプリケーションが意図的に一時停止している \$1 **欠落** - Git に定義されたリソースがクラスターに存在しない
よく使用される Kubernetes リソース (デプロイ、StatefulSet、ジョブなど) に対しては組み込みのヘルスチェックで対処し、CRD に対してはカスタムヘルスチェックをサポートしています。
アプリケーションのヘルスは、アプリケーションのすべてのリソースによって決まります。いずれかのリソースが `Degraded` であれば、アプリケーションも `Degraded` です。
詳細については、Argo CD ドキュメントの「[リソースのヘルス](https://argo-cd.readthedocs.io/en/stable/operator-manual/health/)」を参照してください。
### マルチクラスターパターン
Argo CD は、主に 2 つのデプロイパターンをサポートしています。
**ハブアンドスポーク** - 複数のワークロードクラスターにデプロイする専用の管理クラスターで Argo CD を実行します。\$1 一元管理と可視性 \$1 すべてのクラスターで一貫したポリシー \$1 Argo CD インスタンスを 1 つ管理 \$1 コントロールプレーンとワークロードとの明確な分離
**クラスターあたり** - 各クラスターで Argo CD を実行して、そのクラスターのアプリケーションのみを管理します。\$1 クラスターの分離 (あるクラスターの障害が他のクラスターに影響を与えない) \$1 シンプルなネットワーク (クラスター間の通信なし) \$1 シンプルな初期セットアップ (クラスターの登録なし)
プラットフォームチームが多数のクラスターを管理する場合はハブアンドスポークを選択し、チームが独立している場合やクラスターを完全に分離する必要がある場合はクラスターあたりを選択します。
マルチクラスター設定の詳細については、「[Argo CD に関する考慮事項](argocd-considerations.md)」を参照してください。
### プロジェクト
Project を使用すると、Application を論理的にグループ化して、アクセスコントロールを付与できます。
+ **ソースの制限** - 使用できる Git リポジトリを制限します。
+ **送信先の制限** - ターゲットにできるクラスターと名前空間を制限します。
+ **リソースの制限** - デプロイできる Kubernetes リソースタイプを制限します。
+ **RBAC の統合** - Project を AWS アイデンティティセンターのユーザー ID とグループ ID にマッピングします。
Application は単一の Project に属します。指定しない場合は、`default` プロジェクトが使用されます。これにはデフォルトの制限はありません。本番稼働用の場合は、`default` プロジェクトを編集してアクセスを制限し、適切な制限で新しいプロジェクトを作成します。
Project の設定と RBAC パターンについては、「[Argo CD アクセス許可を設定する](argocd-permissions.md)」を参照してください。
### 同期オプション
よく使用されるオプションで同期動作をファインチューニングします。
+ `CreateNamespace=true` - 送信先名前空間を自動的に作成します。
+ `ServerSideApply=true` - サーバー側の適用機能を使用して的確に競合を解決します。
+ `SkipDryRunOnMissingResource=true` - CRD がまだ存在しない場合には、ドライランをスキップします (kro インスタンスに有用です)。
```
spec:
syncPolicy:
syncOptions:
- CreateNamespace=true
- ServerSideApply=true
- SkipDryRunOnMissingResource=true
```
同期オプションの完全なリストについては、[Argo CD 同期オプションのドキュメント](https://argo-cd.readthedocs.io/en/stable/user-guide/sync-options/)を参照してください。
## 次のステップ
+ [リポジトリアクセスを設定する](argocd-configure-repositories.md) - Git リポジトリアクセスを設定する
+ [ターゲットクラスターを登録する](argocd-register-clusters.md) - デプロイ用にターゲットクラスターを登録する
+ [Application を作成する](argocd-create-application.md) - 最初の Application を作成する
+ [Argo CD に関する考慮事項](argocd-considerations.md) - EKS 固有のパターン、アイデンティティセンター統合、マルチクラスター設定
+ [Argo CD ドキュメント](https://argo-cd.readthedocs.io/en/stable/) - 同期フック、ヘルスチェック、高度なパターンなどについて説明した包括的な Argo CD ドキュメント
# Argo CD アクセス許可を設定する
Argo CD マネージド機能は、AWS アイデンティティセンターとの統合により認証を実施し、組み込みの RBAC ロールを使用して認可を行います。このトピックでは、ユーザーとチームに対するアクセス許可を設定する方法について説明します。
## Argo CD によるアクセス許可の仕組み
Argo CD 機能は、AWS アイデンティティセンターを使用して認証を実施し、組み込みの 3 つの RBAC ロールを使用して認可を行います。
ユーザーが Argo CD にアクセスすると、次のようになります。
1. AWS アイデンティティセンターを使用してユーザーが認証されます (社内の ID プロバイダーにフェデレーションできます)。
1. AWS アイデンティティセンターは、ユーザーとグループの情報を Argo CD に提供します。
1. Argo CD は、現在の設定に基づいてユーザーとグループを RBAC ロールにマッピングします。
1. ユーザーには、自分がアクセス許可を持つアプリケーションとリソースのみが表示されます。
## 組み込みの RBAC ロール
Argo CD 機能には、AWS アイデンティティセンターのユーザーとグループにマッピングする組み込みのロールが 3 つあります。これらは、プロジェクト、クラスター、リポジトリなどの Argo CD リソースへのアクセスを制御する**グローバルスコープのロール**です。
**重要**
グローバルロールは、Application などのプロジェクトスコープのリソースではなく、Argo CD 自体へのアクセスを制御します。EDITOR ユーザーおよび VIEWER ユーザーは、デフォルトでは Application を表示または管理できません。プロジェクトスコープのリソースにアクセスするには、プロジェクトロールが必要です。Application およびその他のプロジェクトスコープのリソースへのアクセス許可の詳細については、「[プロジェクトロールとプロジェクトスコープのアクセス](#project-roles)」を参照してください。
**ADMIN**
すべての Argo CD リソースと設定へのフルアクセス:
+ 任意のプロジェクト内の Application と ApplicationSet を作成、更新、削除する
+ Argo CD 設定を管理する
+ デプロイターゲットクラスターを登録して管理する
+ リポジトリアクセスを設定する
+ プロジェクトを作成および管理する
+ すべてのアプリケーションのステータスと履歴を表示する
+ すべてのクラスターとリポジトリを一覧表示してアクセスする
**EDITOR**
プロジェクトを更新してプロジェクトロールを設定できますが、グローバル Argo CD 設定を変更することはできません。
+ 既存のプロジェクトを更新する (プロジェクトの新規作成および削除はできません)
+ プロジェクトロールとアクセス許可を設定する
+ GPG キーと証明書を表示する
+ グローバル Argo CD 設定を変更できない
+ クラスターとリポジトリを直接管理できない
+ プロジェクトロールがないと Application を表示または管理できない
**VIEWER**
Argo CD リソースへの読み取り専用アクセス:
+ プロジェクト設定を表示する
+ すべてのプロジェクト (ユーザーが割り当てられていないプロジェクトを含む) を一覧表示する
+ GPG キーと証明書を表示する
+ クラスターまたはリポジトリを一覧表示できない
+ 変更を加えることはできない
+ プロジェクトロールがないと Application を表示または管理できない
**注記**
EDITOR ユーザーまたは VIEWER ユーザーに Application へのアクセス権を付与するには、ADMIN または EDITOR が、アイデンティティセンターグループをプロジェクト内の特定のアクセス許可にマッピングするプロジェクトロールを作成する必要があります。
## プロジェクトロールとプロジェクトスコープのアクセス
グローバルロール (ADMIN、EDITOR、VIEWER) は、Argo CD 自体へのアクセスを制御します。プロジェクトロールは、以下を含む特定のプロジェクト内のリソースと機能へのアクセスを制御します。
+ **リソース**: Application、ApplicationSet、リポジトリ認証情報、クラスター認証情報
+ **機能**: アプリケーションポッドへのログアクセスと実行アクセス
**2 レベルのアクセス許可モデルについて**:
+ **グローバルスコープ**: 組み込みロールは、ユーザーがプロジェクト、クラスター、リポジトリ、および Argo CD 設定で何ができるかを決定します
+ **プロジェクトスコープ**: プロジェクトロールは、ユーザーが特定のプロジェクト内のリソースと機能で何ができるかを決定します
つまり、次のようになります。
+ ADMIN ユーザーは、追加の設定なしですべてのプロジェクトリソースと機能にアクセスできます
+ EDITOR ユーザーおよび VIEWER ユーザーには、プロジェクトのリソースと機能にアクセスするためのプロジェクトロールを付与する必要があります
+ EDITOR ユーザーは、更新できるプロジェクト内で、自分やそれ以外のユーザーにアクセス権を付与するプロジェクトロールを作成できます。
**ワークフローの例**:
1. ADMIN は、アイデンティティセンターグループを EDITOR ロールにグローバルにマッピングします。
1. ADMIN がチームのプロジェクトを作成する
1. EDITOR は、そのプロジェクト内のプロジェクトロールを設定して、チームメンバーにプロジェクトスコープのリソースへのアクセス権を付与します。
1. チームメンバー (VIEWER グローバルロールを持つ可能性がある) は、プロジェクトロールのアクセス許可に基づいて、そのプロジェクトの Application を表示および管理できるようになりました。
プロジェクトロールの設定の詳細については、「[Project ベースのアクセスコントロール](#_project_based_access_control)」を参照してください。
## ロールマッピングを設定する
機能の作成時や更新時に、AWS アイデンティティセンターのユーザーとグループを Argo CD ロールにマッピングします。
**ロールマッピングの例**:
```
{
"rbacRoleMapping": {
"ADMIN": ["AdminGroup", "alice@example.com"],
"EDITOR": ["DeveloperGroup", "DevOpsTeam"],
"VIEWER": ["ReadOnlyGroup", "bob@example.com"]
}
}
```
**注記**
ロール名は、大文字と小文字が区別され、大文字 (ADMIN、EDITOR、VIEWER) にする必要があります。
**重要**
EKS 機能と AWS アイデンティティセンターが統合されている場合、Argo CD 機能あたり最大 1,000 個の ID がサポートされます。ユーザーやグループを ID にすることができます。
**ロールマッピングを更新する**:
```
aws eks update-capability \
--region us-east-1 \
--cluster-name cluster \
--capability-name capname \
--endpoint "https://eks.ap-northeast-2.amazonaws.com" \
--role-arn "arn:aws:iam::[.replaceable]111122223333:role/[.replaceable]`EKSCapabilityRole`" \
--configuration '{
"argoCd": {
"rbacRoleMappings": {
"addOrUpdateRoleMappings": [
{
"role": "ADMIN",
"identities": [
{ "id": "686103e0-f051-7068-b225-e6392b959d9e", "type": "SSO_USER" }
]
}
]
}
}
}'
```
## 管理者アカウントの使用法
管理者アカウントは、クラスターの登録やリポジトリの設定など、初期セットアップと管理タスク向けに設計されています。
**どのような場合に管理者アカウントが適切か**:
+ 機能の初期セットアップと設定
+ 単独開発や迅速なデモンストレーション
+ 管理タスク (クラスターの登録、リポジトリの設定、Project の作成)
**管理者アカウントのベストプラクティス**:
+ アカウントトークンをバージョン管理にコミットしない
+ トークンが漏洩したらすぐにローテーションさせる
+ アカウントトークンの用途をセットアップと管理タスクに制限する
+ 有効期限を短くする (最大 12 時間)
+ 一度に作成できるアカウントトークンを 5 つまでとする
**どのような場合に Project ベースのアクセスを使用するか**:
+ 複数のユーザーと開発環境を共有する場合
+ いずれの環境も本番稼働と同様にする場合
+ 誰がアクションを実行したかを監査証跡に残す場合
+ リソース制限やアクセス境界を設ける場合
本番稼働環境とマルチユーザーシナリオでは、専用の RBAC ロールを AWS アイデンティティセンターグループにマッピングして、Project ベースのアクセスコントロールを使用します。
## Project ベースのアクセスコントロール
Argo CD Project (AppProject) を使用すると、チームを対象にアクセスコントロールとリソース分離をきめ細かく設定できます。
**重要**
ユーザーまたはグループをプロジェクト固有のロールに割り当てる前に、まず機能設定でグローバル Argo CD ロール (ADMIN、EDITOR、または VIEWER) にマッピングする必要があります。ユーザーは、プロジェクトロールに割り当てられていても、グローバルロールマッピングなしで Argo CD にアクセスすることはできません。
ユーザーを VIEWER ロールにグローバルにマッピングし、プロジェクト固有のロールを通じて追加のアクセス許可を付与することを検討してください。これにより、ベースラインアクセスが可能になり、プロジェクトレベルでのきめ細かな制御が可能になります。
Project でできることは以下のとおりです。
+ **ソースの制限**: 使用できる Git リポジトリを制限します。
+ **送信先の制限**: ターゲットにできるクラスターと名前空間を制限します。
+ **リソースの制限**: デプロイできる Kubernetes リソースタイプを制限します。
+ **RBAC の統合**: Project を AWS アイデンティティセンターグループまたは Argo CD ロールにマッピングします。
**チームを分離する Project の例**:
```
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
name: team-a
namespace: argocd
spec:
description: Team A applications
# Required: Specify which namespaces this project watches for Applications
sourceNamespaces:
- argocd
# Source restrictions
sourceRepos:
- https://github.com/myorg/team-a-apps
# Destination restrictions
destinations:
- namespace: team-a-*
server: arn:aws:eks:us-west-2:111122223333:cluster/production
# Resource restrictions
clusterResourceWhitelist:
- group: ''
kind: Namespace
namespaceResourceWhitelist:
- group: 'apps'
kind: Deployment
- group: ''
kind: Service
- group: ''
kind: ConfigMap
```
### ソース名前空間
EKS Argo CD 機能を使用する場合は、AppProject 定義で `spec.sourceNamespaces` フィールドが必要です。このフィールドは、このプロジェクトを参照する Application または ApplicationSet を含めることができる名前空間を指定します。
**重要**
EKS Argo CD 機能は、Application と ApplicationSet 向けに一つの名前空間のみをサポートします。具体的には、機能の作成時に指定した名前空間になります (通常は `argocd`)。これは、複数の名前空間をサポートするオープンソースの Argo CD とは異なります。
**AppProject の設定**
すべての AppProject は、その機能の設定済み名前空間を `sourceNamespaces` に含める必要があります。
```
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
name: team-a-project
namespace: argocd
spec:
description: Applications for Team A
# Required: Specify the capability's configured namespace (configuration.argoCd.namespace)
sourceNamespaces:
- argocd # Must match your capability's namespace configuration
# Source repositories this project can deploy from
sourceRepos:
- 'https://github.com/my-org/team-a-*'
# Destination restrictions
destinations:
- namespace: 'team-a-*'
server: arn:aws:eks:us-west-2:111122223333:cluster/my-cluster
```
**注記**
機能の名前空間を `sourceNamespaces` に含めないと、その名前空間の Application または ApplicationSet はこのプロジェクトを参照できず、デプロイが失敗します。
**ユーザーを Project に割り当てる**:
プロジェクトロールは、EDITOR ユーザーおよび VIEWER ユーザーにプロジェクトリソース (Application、ApplicationSet、リポジトリ、クラスター認証情報) と機能 (ログ、実行) へのアクセスを許可します。プロジェクトロールがないと、これらのユーザーは、グローバルロールアクセスを持っていてもこれらのリソースにアクセスできません。
ADMIN ユーザーは、プロジェクトロールを必要とせずに、すべての Application にアクセスできます。
**例: チームメンバーに Application へのアクセスを許可する**
```
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
name: team-a
namespace: argocd
spec:
# ... project configuration ...
sourceNamespaces:
- argocd
# Project roles grant Application-level access
roles:
- name: developer
description: Team A developers - can manage Applications
policies:
- p, proj:team-a:developer, applications, *, team-a/*, allow
- p, proj:team-a:developer, clusters, get, *, allow # See cluster names in UI
groups:
- 686103e0-f051-7068-b225-e6392b959d9e # Identity Center group ID
- name: viewer
description: Team A viewers - read-only Application access
policies:
- p, proj:team-a:viewer, applications, get, team-a/*, allow
- p, proj:team-a:viewer, clusters, get, *, allow # See cluster names in UI
groups:
- 786203e0-f051-7068-b225-e6392b959d9f # Identity Center group ID
```
**注記**
プロジェクトロールに `clusters, get, *, allow` を含めることで、ユーザーが UI でクラスター名を表示できるようにします。このアクセス許可がない場合、送信先クラスターは「Unknown」として表示されます。
**プロジェクトロールポリシーについて**:
ポリシーの形式は次のとおりです: `p, proj::, , ,