App of Apps
簡単に言えば、App of Appsパターンを使用すると、ルートArgoCD Application(ルートアプリ)を定義できます。ルートアプリは、アプリケーションマニフェストを指すのではなく、アプリバンドル(子アプリ)のポイントである各マイクロサービスのApplicationYAML定義を含むフォルダーを指します。次に、各マイクロサービスのApplicationYAMLは、アプリケーションマニフェストを含むディレクトリを指します。
App of Apps Best Practices
App of Appsパターンに関するいくつかのベストプラクティスに注目する価値があります。
1- Create a project for each app bundle
ArgoCDプロジェクトは、アプリケーションの論理的なグループ化を提供します。また、次の目的にも使用できます。
信頼できるGitリポジトリを定義します(古いgitリポジトリのみを指すアプリをデプロイして、大混乱を引き起こす可能性はありません)
クラスタで作成できるリソースの種類を定義します(誰かがRoleBindingsを意地悪に作成してほしくないのではないでしょうか。)
プロジェクトにアクセスできるユーザー、つまりプロジェクト内のアプリケーションにアクセスできるユーザーを定義します。
アプリをデプロイできるクラスターを制限します。ここでの関心の分離は、私たちにとって優れたものです。
ArgoCDプロジェクトは、AppProjectと呼ばれる特別なArgoCDリソースを使用して定義されます。
2- Create environment-specific app bundles and projects
したがって、私たちはアプリケーションバンドルごとにAppProjectを作成する必要があることに同意します。さらに一歩進んで、環境ごとのアプリケーションバンドルごとにAppProjectを作成しましょう。あなたがそれについて考えるとき、それは理にかなっています。とにかく、ターゲット環境ごとに個別のアプリケーションバンドル定義を作成する必要があります。これは、異なる環境にデプロイするたびに異なるクラスターをターゲットにする必要があるためです。
そして、はい、あなたは確かに空想を得て、あなたのアプリケーション定義を作成するためにいくつかのテンプレートを作ることができます。
3- Keep Application definitions in a separate repo
私の個人的な好みは、ArgoCDアプリケーションとAppProjectの定義をソースコードリポジトリとは別のリポジトリに含めることです。
どうして?おそらく、ArgoCDを介してKubernetesへのアプリケーションのデプロイを管理するチームは、実際のアプリケーションコードを作成するチームとは異なるためです。