この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
App of apps patternとは
Argo CDで複数のapplicationをインストール(デプロイ)したい場合に用いられるパターン（構成）です。
他のapplicationを内包するapplicationを作成する構成です。
何が嬉しいの?
Argo CD周りでよくこのApp of apps patternが言及されている印象があるのですが、私はいまいちこの構成のメリットがわかりませんでした。「一個ずつ別々にapplication作ったらええやん」と。というわけでこのApp of apps patternのメリットについて調べてみました。
複数アプリをまとめてインストールできる
Argo CD公式ドキュメントでは、以下のような文脈でApp of apps patternを紹介しています。
This guide is for operators who have already installed Argo CD, and have a new cluster and are looking to install many apps in that cluster.
There's no one particular pattern to solve this problem, e.g. you could write a script to create your apps, or you could even manually create them. However, users of Argo CD tend to use the app of apps pattern.
(意訳)このガイドは、既にArgo CDをインストールしていて、かつ新しいクラスターにたくさんのアプリケーションをインストールしようとしている運用担当者向けに書かれたものです。
この問題解決にドンズバのパターンはありません。例えばアプリを作成するスクリプトを作成することも、手動で作成することもできます。しかしながらArgo CDユーザーはApp of apps patternを使用する傾向にあります。
なるほど。確かにArgo CDのWebUIやコマンドでapplicationを登録するのであれば、App of apps patternは親appliationの登録1回で済むので楽かもしれません。
ですが、applicationの登録もマニフェストファイルで宣言的にやるのが普通というか、履歴も残るので良いのではないでしょうか。そしてマニフェストファイルでやるなら手間はさほど変わらない、むしろ親applicationを作る分コード量は増えると思うのですが…
アプリケーションの追加が楽
サイボウズさんのブログにてApp of apps patternのメリットが以下のように説明されていました。
App of Apps Patternでアプリケーションリソースを管理すると、Argo CDで管理するアプリケーションが増減したとしても、 Web UIやコマンドラインでArgo CDを操作する必要はなく、マニフェストを追加してGitにPushするだけですみます。
これは確かにそうですね。追加のapplicationはArgoCDを介してデプロイできるので、git pushだけでデプロイできます。Web UIやコマンドラインでの作業や、あるいはマニフェストファイルをCDパイプラインを通じてapplyする必要がありません。
アプリケーションをグルーピングできる
Mastering the App of Apps pattern is critical to leveraging the full power of Argo CD. This method allows you to manage groups of applications cleanly. For example, deploying Prometheus, Grafana, Loki, and other vital services could be managed by a DevOps Application, while deploying frontend code could be managed by a Frontend Application. Configuring different sync options and repo locations for each gives you precise control over different application groups.
(意訳) App of Apps patternをマスターすることはArgo CDの能力を最大限活用するために重要です。この方法により、applicationのグループをきれいに管理できます。たとえば、Prometheus、Grafana、Loki、およびその他の重要なサービスのデプロイは、DevOps application(を作ってそのなかに作成すること)によって管理できます。一方、フロントエンドコードのデプロイはFrontend applicationで管理できます。各application毎に異なるsyncオプションとリポジトリのロケーションを設定することでさまざまなアプリケーション グループを正確に制御できます。
なるほど。親applicationはひとつだけかと思っていたのですが、別にそうである必要はありませんね。
デプロイ順を制御できる
上記ブログでは、App of apps patternとSyncWavesを組み合わせることで、依存関係のあるマイクロサービスのデプロイを正しい順番で行なうことが可能になると述べられています。前項の「グルーピングできる」の更に発展型といった感じでしょうか。これは便利そうですね。
また蛇足ですが最後のほうに「ApplicationSetsはApp of apps patternの上位互換だ」みたいな説明があって気になりました。私はまだApplicationSetsについては未勉強なので、今後触ってみたいと思います。
感想
ちょっとApp of apps patternの良さがわかりました。グルーピングが必要になってくるくらいたくさんのアプリをデプロイする予定ならば必ずこの構成を使ったほうが良い気がします。逆に言うとそれほど複雑なことをする予定が無いなら採用しないでも良さそうだということがわかりました。
2
