1. GitOpsマスタークラスの紹介とArgo CD App Projectの概要 [0]

  1. GitOpsマスタークラスシリーズの開始:

    1. Argo CDとGitOpsに関する深い知識を提供するために、不定期なシリーズとして開始されたものである [1]。
    2. 既にArgo CDに慣れている、または本番環境で実行しているユーザーを対象に、特定のトピックについて深く掘り下げることが目的である [2]。

  2. 本日のテーマ:

    1. 今回のマスタークラスでは、Argo CDプロジェクト、すなわちArgo CD App Projectについて議論する [6]。

  3. Acuityプラットフォームの背景:

    1. Acuityは、ArgoおよびCargoプロジェクトの作成者によって設立されたプラットフォームである [43]。
    2. 創設者（Hong, Jesse, Alex）はIntuitに在籍しており、IntuitがクラウドとKubernetesに全面的に移行するという戦略的決定を下したことが背景にある [44]。
    3. 当時、Kubernetesはまだ新興製品であり、Intuitはアプリケーションのオンボーディングとエンドユーザーへの良好なユーザーエクスペリエンス提供のためのツールセットを必要としていた [48]。
    4. 開発者はKubernetesのプリミティブについて知る必要がなく、アプリケーション開発に集中すべきであるという考えに基づき、Argoプロジェクトの作成を主導した [51]。
    5. 彼らはIntuitでの本番環境での経験を活かし、Acuityプラットフォームを構築し、後にCargoプロジェクトを作成した [55]。
    6. CargoはIntuit内で生まれたアイデアであり、Argoプロジェクトが軌道に乗ったため当時は時間がなかったが、Acuityプラットフォームの礎石として見なされている [57]。

  4. 無料書籍の紹介:

    1. 講演者とRed HatのAndrew Block氏が共同で執筆したArgo CDに関する書籍が、Acuityのスポンサーにより早期アクセス版として無料で提供されている [67]。
    2. この書籍は、Argo CDの導入とベストプラクティスを学ぶために、長年の経験がまとめられたものである [78]。
    3. 完全版は今年の後半、CubeCon North Americaの頃にリリースされる予定である [82]。

  5. 本日のアジェンダ:

    1. アプリケーションプロジェクトの概要: Argo CD App Projectとは何か、その哲学的理由と動作原理について説明する [89]。
    2. ハンズオンワークショップ:
    3. デフォルトプロジェクトの最適な管理方法
    4. プロジェクトの作成と管理
    5. RBACを使用したプロジェクトによるマルチテナンシー
    6. グローバルプロジェクトの設定方法
    7. 特定のクラスターとリポジトリを特定のプロジェクトにスコープする方法 [90]。

  6. Argo CD App Projectの哲学的背景:

    1. Argo CDはKubernetesの抽象化であり、内部開発者プラットフォーム (IDP) の最初の試みとして見なされる [102]。
    2. 開発チームをKubernetesにオンボーディングし、サービス、デプロイメント、インプレスなどの概念を抽象化することが目的である [105]。
    3. Argo CDは最高のKubernetes UIとして機能し、フレンドリーなUIを通じてKubernetesとアプリケーションを管理するニーズから生まれた [107]。
    4. Kubernetesへのインターフェースとして機能し、すべての操作はAPIを介して行われる [109]。
    5. GitOpsの哲学に基づき、ユーザーはkubectlアクセスを持たないことが前提である [111]。
    6. Argo CDはデフォルトでクラスター管理者権限を持っており、これはインフラストラクチャ管理のために維持されるべきである [117]。

  7. Argo CDのハイレベルなワークフロー:

    1. ユーザー（UIまたはCLI）はArgo CD APIを介して操作を行う [120]。
    2. Argo CDはユーザーに代わって動作し、例えばリポジトリサーバーにGitクローンを指示する [123]。
    3. アプリケーションサーバーはリポジトリサーバーからのペイロードを受け取り、それを直接Kubernetes APIに適用する [126]。
    4. このアプリケーションサーバーからKubernetes APIへの適用は、デフォルトでクラスター管理者として実行される [130]。

  8. Argo CD App Projectの役割:

    1. App Projectはテナンシーの単位であり、マルチテナントシステムを意図している [132]。
    2. スコープダウンの役割を果たし、特定のユーザーやグループにApp Projectへのアクセスを許可する [133]。
    3. きめ細かなRBACポリシーを設定できる:
    4. 特定のユーザーがアプリケーションを同期できるが削除はできない、または特定のデプロイメントの同期を拒否するなど、非常にきめ細かな設定が可能である [135]。
    5. 制御ポイント:
    6. リポジトリアクセス: 特定のGitリポジトリからの同期を許可または拒否できる [138]。
    7. デスティネーション（宛先）制御: 特定のクラスターの特定のネームスペースへの同期を許可したり、特定のクラスターへの読み取り専用アクセスを設定したりできる [139]。
    8. Kubernetesマニフェストの許可/拒否: 特定のGVK（Group, Version, Kind）の同期を許可または拒否できる [140]。
    9. 同期ウィンドウ: 特定の時間帯にのみ同期操作を許可する設定が可能である [143]。
    10. 管理プロセス: App Projectの作成と管理は管理者のタスクである [144]。
    11. App Projectは、クラスター管理者として行われる同期操作に対する制御ポイントとして機能する [152]。

2. ワークショップの前提条件と環境設定 [182]

  1. 前提条件:

    1. GitHubアカウントが必要である [182]。
    2. Codespacesのクレジットが必要であるが、無料枠で十分である [186]。
    3. Argo CD、GitHub、Kubernetes、CLIに慣れている必要がある [192]。
    4. ワークショップで使用するGitリポジトリURLが提供されている [207]。

  2. RBACとCRUD操作に関する補足:

    1. RBACはArgo CD APIを介したCRUD操作（作成、読み取り、更新、削除）であり、KubernetesのAPIヒットを直接受け入れるわけではない [198]。
    2. Argo CDはCRUD操作を実行しているユーザーをチェックするため、アカウントまたはユーザー管理と関連している [204]。

  3. Codespaces環境のセットアップ (テンプレートの使用):

    1. 提供されたリポジトリの「Use this template」ボタンをクリックし、「Create new repository」を選択する [237]。
    2. オーナーとして自身のユーザー名を選択し、リポジトリ名を設定してリポジトリを作成する [246]。
    3. 作成されたリポジトリで「Code」をクリックし、「Codespaces」タブを選択する [264]。
    4. 「Create code spaces on main」をクリックしてCodespaces環境を起動する [271]。
    5. 環境のセットアップには数分かかる場合がある [282]。

  4. 環境の検証とArgo CD UIへのアクセス:

    1. Codespacesが起動したら、ターミナルでkubectl get nodesを実行し、単一ノードが実行されていることを確認する [327]。
    2. kubectl get pods -n argocdを実行し、Argo CDが稼働していることを確認する [330]。
    3. argocd account get user infoを実行し、adminとしてログインされていることを確認する [332]。
    4. kubectl config get-contextsを実行し、K3D-devを含む2つのコンテキストがあることを確認する [334]。
    5. Codespacesの「Ports」タブをクリックし、Argo CDダッシュボードに対応するポートのグローブアイコンをクリックしてUIを新しいタブで開く [339]。
    6. Argo CD UIへのログイン情報: ユーザー名: admin、パスワード: passwordである [413]。

3. デフォルトプロジェクトの制限と管理者用プロジェクトの作成 [450]

  1. デフォルトプロジェクトの確認:

    1. kubectl get appprojects -n argocdを実行すると、defaultというApp Projectが存在することが確認できる [463]。
    2. kubectl get appprojects -n argocd default -o yamlでデフォルトプロジェクトのYAMLを確認すると、clusterResourceWhitelist、destination、sourceRepoのすべてがすべてを許可するように設定されていることがわかる [473]。
    3. これは、使いやすさのためにデフォルトでオープンになっているが、本番環境では無効化または厳しく制限することが推奨される [481]。

  2. デフォルトプロジェクトの制限 (ロックダウン):

    1. projects/project-restricted-default.yamlファイルには、sourceRepo、sourceNamespaces、destinations、namespaceを空のセット（暗黙的な拒否）に設定することで、デフォルトプロジェクトをロックダウンする設定が含まれている [485]。
    2. kubectl replace -f projects/project-restricted-default.yamlを実行して、デフォルトプロジェクトの設定を置き換える [502]。
    3. これにより、デフォルトプロジェクトは基本的に無効化され、このArgo CDインストールは一時的に使用できなくなる [508]。

  3. 管理者用プロジェクトの作成 (Cluster Add-ons):

    1. 管理タスクのために、デフォルトプロジェクトを無効化し、より具体的なプロジェクトを作成することが推奨される [511]。
    2. projects/project-cluster-addons.yamlファイルには、Cluster Add-onsというプロジェクトが定義されている [513]。
    3. リソースホワイトリスト: in-clusterサーバー（Argo CDが実行されているクラスター）内のすべてを許可する [513]。
    4. ソースリポジトリ: 特定のソースリポジトリのみを明示的に許可する [520]。
    5. Cluster Add-onsは、cert-managerやKyiveroなど、クラスターを機能させるための企業標準ビルドに必要なコンポーネント（クラスターアドオン）をデプロイするための管理者用ブートストラッププロジェクトとして機能する [523]。
    6. kubectl create -f projects/project-cluster-addons.yamlを実行して、Cluster Add-onsプロジェクトを作成する [532]。
    7. UIの「Settings」→「Projects」で、新しく作成されたcluster-addonsプロジェクトが確認できる [530]。

  4. アプリケーションのデプロイテスト (デフォルトプロジェクトの拒否):

    1. applications/app-cert-manager.yamlファイルには、cert-managerアプリケーションが定義されており、当初はproject: defaultに設定されている [545]。
    2. kubectl create -f applications/app-cert-manager.yamlを実行してデプロイを試みると、UIで2つのエラーが表示され、デプロイが拒否される [556]。
    3. これは、デフォルトプロジェクトをロックダウンしたことによる即座の制御効果を示すものである [562]。

  5. アプリケーションのデプロイ成功 (Cluster Add-onsプロジェクトの使用):

    1. app-cert-manager.yaml内のプロジェクト名をdefaultからcluster-addonsに変更する [573]。
    2. kubectl replace -f applications/app-cert-manager.yamlを実行すると、アプリケーションの同期が開始される [580]。
    3. App Projectの設計原則: App Projectは、特定のユーザー、特定のグループ、または特定のワークロードタイプ（例：Cluster Add-ons）に基づいて作成されるべきである [567]。

4. RBACのためのユーザー作成とワークロードプロジェクトの設定 [590]

  1. RBACテストのためのローカルユーザー作成:

    1. このワークショップはユーザー管理に関するものではないが、App ProjectのRBAC機能を示すためにローカルユーザーを作成する [590]。
    2. kubectl edit configmap argocd-configmap -n argocdを実行し、dataセクションに新しいユーザーアカウントを追加する [609]。
    3. 例: accounts.christian: api_key_login
    4. argocd account update password --account [ユーザー名] --new-password passwordコマンドを使用して、作成したユーザーのパスワードを設定する [649]。
    5. UIからログアウトし、作成したユーザー（例: Christian、パスワード: password）としてログインする [684]。
    6. 新しいユーザーとしてログインすると、以前にデプロイされたcert-managerアプリケーションは表示されない [687]。
    7. このユーザーは現在、プロジェクトの作成やリポジトリの管理など、何も実行できない状態である [705]。

  2. ワークロードプロジェクトの作成とRBACの設定:

    1. projects/project-workloads.yamlファイルを使用して、新しいworkloadsプロジェクトを作成する [711]。
    2. プロジェクトの設定:
    3. Allow List: GroupとKindはすべて許可するが、デスティネーションはin-clusterサーバーの任意のネームスペースに制限する [711]。
    4. Source Repos: ユーザー自身の特定のリポジトリにのみ制限する [715]。
    5. Role (カスタムプロジェクトロール):
      • p, proj:workloads:custom-project-role, projects, get, workloads, allow (Workloadsプロジェクトの取得を許可) [718]。
      • p, proj:workloads:custom-project-role, applications, *, workloads/*, allow (Workloads内のすべてのアプリケーションに対してすべての操作（作成、更新、削除など）を許可) [721]。
    6. グループとユーザーの関連付け:
    7. App ProjectのRBACはグループでのみ機能するが、ローカルユーザーを作成すると、そのユーザー名と同じ名前の対応するグループが概念的に作成されると見なすことができる [744]。
    8. groupsフィールドにユーザー名（例: Christian）を指定することで、そのユーザーにロールを割り当てる [744]。
    9. kubectl create -f projects/project-workloads.yamlを実行して、workloadsプロジェクトを作成する [762]。
    10. ユーザー（Christian）としてログインした状態で、UIの「Settings」→「Projects」に移動すると、workloadsプロジェクトが表示される [763]。

  3. ユーザーによるアプリケーションのデプロイテスト:

    1. applications/app-simple-go.yamlファイルには、project: workloadsに設定されたsimple-goアプリケーションが定義されている [766]。
    2. ユーザー（Christian）としてログインした状態で、UIの「Create Application」からYAMLを貼り付けてアプリケーションを作成する [773]。
    3. RBAC設定により、このユーザーはworkloadsプロジェクト内でアプリケーションを作成できる [782]。
    4. 拒否テスト: このユーザーがアクセス権のないcluster-addonsプロジェクトにアプリケーションを作成しようとすると、失敗する [788]。

5. グローバルプロジェクトとスコープされたリソースの設定 [796]

  1. グローバルプロジェクトの概念:

    1. グローバルプロジェクトは、特定のラベルを持つすべてのApp Projectに自動的に継承される設定（テンプレート）を提供する [796]。
    2. configs/argo-cd-cm.yamlファイルには、env=prodラベルを持つプロジェクトがglobal-prodプロジェクトの設定を継承するように定義されている [802]。
    3. projects/project-global.yamlファイルで定義されたglobal-prodプロジェクトは、destinationでnamespace: kube-systemを拒否する設定を持つ [808]。
    4. これは、誰がプロジェクトを作成しても、kube-systemネームスペースへのデプロイを明示的に禁止するためのものである [810]。

  2. グローバルプロジェクトの設定と適用:

    1. kubectl patch -n argocd cm argocd-configmap --patch-file configs/argo-cd-cm.yamlを実行して、Argo CD ConfigMapにグローバルプロジェクトの設定をパッチする [825]。
    2. kubectl create -f projects/project-global.yamlを実行して、global-prodプロジェクトを作成する [845]。
    3. kubectl create -f projects/project-prod.yamlを実行して、env: prodラベルを持つprodプロジェクトを作成する [848]。
    4. 継承の確認: prodプロジェクトのYAMLにはkube-systemの拒否設定が直接表示されないが、バックエンドのAPI（/api/v1/projects/prod）を確認すると、global-prodからの設定が継承されていることが確認できる [863]。

  3. スコープされたリポジトリとクラスターの設定:

    1. スコープされたリソースは、特定のApp Projectにのみ特定のGitリポジトリやKubernetesクラスターを関連付ける機能である [879]。
    2. projects/project-scoped.yamlファイルには、permitOnlyProjectScopedClusters: trueという設定を持つscopedプロジェクトが定義されている [880]。
    3. スコープされたリポジトリの追加:
    4. kubectl create -f projects/project-scoped.yamlを実行して、scopedプロジェクトを作成する [894]。
    5. kubectl create -f configs/scoped-repo.yamlを実行して、特定のGitリポジトリをscopedプロジェクトに紐づけるシークレットを作成する [895]。
    6. 管理者としてログインし、UIの「Settings」→「Repositories」でscoped-repoが確認できる [898]。
    7. 他のユーザー（Christian）としてログインすると、このリポジトリは表示されない [901]。
    8. スコープされたクラスターの追加:
    9. kubectl config get-contextsで、K3D-managedという別のクラスターコンテキストが存在することを確認する [909]。
    10. argocd cluster add K3D-managed --yes --name managed --project scopedコマンドを使用して、K3D-managedクラスターをArgo CDに追加し、scopedプロジェクトに割り当てる [913]。
    11. UIの「Settings」→「Clusters」で、in-clusterと新しく追加されたmanagedクラスターが確認できる [926]。
    12. このクラスターは、scopedプロジェクトに紐づけられているため、他のプロジェクトからはアクセスできない [933]。
    13. スコープされたアプリケーションのデプロイ:
    14. applications/app-blue-green.yamlファイルには、project: scopedに設定され、destinationがmanagedクラスターのBGDネームスペースに向けられたアプリケーションが定義されている [904]。
    15. kubectl create -f applications/app-blue-green.yamlを実行してアプリケーションを作成すると、managedクラスターのBGDネームスペースにデプロイされる [927]。
    16. クラスター追加時に作成されたKubernetesシークレットには、projectフィールドが含まれており、そのクラスターが特定のプロジェクトにスコープされていることが確認できる [937]。

  4. まとめと結論:

    1. App Projectを使用することで、デフォルトプロジェクトのロックダウン、管理者用プロジェクトの作成、RBACによるユーザー管理、グローバルポリシーの適用、および特定のリポジトリとクラスターへのきめ細かなスコープ設定が可能になる [943]。
    2. Argo CDの組み込みメカニズムを使用することで、開発者からkubectlアクセスを奪い、安全でロックダウンされたArgo CDのインストールを実現できる [959]。

  5. 質疑応答と今後の予定:

    1. リソース競合: App Project間のリソース競合は、通常、Argo CDで共有リソースエラーとして発生する [980]。
    2. App Projectの作成プロセス: App Projectは管理者タスクであるため、作成プロセス（例：HelmチャートをGitに保存し、Gitアクセスを持つ人のみが作成できるようにする）を確立すべきである [984]。
    3. LDAP/SSO: LDAPはArgo CDに組み込まれているDEXを使用して設定可能であり、今後のマスタークラスで取り上げられる可能性がある [990]。
    4. 書籍のリリース: 早期アクセス版が提供されており、完全版は今年のQ4頃にO'Reillyから出版される予定である [1001]。
    5. 今後のマスタークラス: 今後も半定期的に開催され、YouTubeチャンネルにアップロードされる予定である [964]。