スキーマのない ConfigMap 一枚がプラットフォームを決める

一言でいうと

argocd-cmはスキーマのないConfigMapなので、綴りのミスがエラーではなく「設定なし」になります。argocd admin settings validateは、それを検査してくれるツールではなく、読み取った値を返してくれるツールです。

なぜこの確認が必要なのか

Argo CDを宣言で管理し始めると、argocd-cm1枚が大きくなります。アカウント、SSO、kustomizeのビルドオプション、監視しない種類、所有マークの方式、ヘルスルール、無視ルール、リソースアクションが、すべてこのファイルのキーとして入ってきます。問題は、このファイルがごく普通のConfigMapだという点です。Kubernetesはキー名を検査しません。kustomize.buildOptionsをkustomize.buildOptionと書いてもapplyは成功し、Argo CDはそのキーを知らないので、そのまま通り過ぎます。画面のどこにも警告がありません。

この種のミスは非常に長く生きます。オプションが効いていないことは、たいてい別の作業をしているときに偶然発見され、そのころには、その行を誰がなぜ入れたのか、誰も覚えていません。

どう動くのか

argocd admin settings validateは、argocd-cm(と、必要ならargocd-secret)を読んで、5つの節に分けて解釈した結果を出力します。

✅ accounts            3 accounts
✅ general             Dex is configured
✅ kustomize           --enable-helm
✅ repositories        1 repositories
✅ resource-overrides  2 resource overrides

ここで読み方が重要です。✅は「その節を読むのに失敗しなかった」という意味であって、「設定が正しい」という意味ではありません。実際の情報は、その下の行にあります。アカウントを2つ足したのに数が変わらなければ、キー名が間違っていますし、ビルドオプションを入れたのにdefault optionsと出るなら、そのオプションはありません。つまり、このコマンドはリンターではなく、読み戻しです。自分が入れた値が返ってくるかを見る用途で使って、初めて価値が出ます。

そして限界があります。すべての設定がこの5つの節に現れるわけではありません。resource.exclusionsとresource.inclusionsは、どの節にも要約されません。こうしたキーは、ファイルを直接パースして確認するしかありません。inclusionsは特に注意が必要です。1つでも書いた瞬間に、そこにない種類はすべて見えなくなります。

所有マークの設定も、知っておく価値があります。application.resourceTrackingMethodがlabelなら、Argo CDはapp.kubernetes.io/instanceのようなラベルにアプリ名を書きます。ところが、ラベルの値は63文字を超えられません。組織が大きくなってアプリ名が長くなると、この上限にぶつかり、切り詰められた名前のせいで、異なるアプリが同じ所有マークを持つことになります。1つのアプリの同期が別のアプリのリソースに触れる事故は、ここから起きます。annotation方式は、argocd.argoproj.io/tracking-idアノテーションに書くので長さ制限がなく、そのため、現在推奨されている方式です。

リポジトリも、2つの世代が混ざっています。argocd-cmのrepositoriesリストは以前の方式で、現在は、リポジトリ1つにSecret1つを置いて、argocd.argoproj.io/secret-type: repositoryラベルを付けます。認証情報を一緒に入れられるのが大きな違いです。ここにも静かな失敗があります。ラベルを抜かすと、Argo CDがそのSecretを見つけられません。エラーは出ません。

現場での姿

最もよくある場面は、「Helmを使うkustomizeのビルドが動かない」という問い合わせです。kustomize.buildOptionsを入れたはずなのに、実際のファイルにはbuildOptionと書かれています。このコマンドを1回実行すれば3秒で終わることなのに、なければ、コントローラーのログとPodの再起動を行き来して、半日を使います。

2つ目は、除外リストを誤って触ることです。負荷を減らそうとresource.inclusionsに数種類だけを書いたら、それ以外のすべてのリソースがアプリのツリーから消えます。人々はリソースが削除されたと思って、パニックになります。この設定はvalidateの出力に現れないので、変更する前にファイルを直接読んで、何を残すかを数えておく必要があります。

3つ目は、移行です。ラベル方式からアノテーション方式に変えると、Argo CDは、以前のラベルが付いたリソースを自分のものとして認識できないことがあります。そのため、この変更は静かに行うものではなく、変更の前後の読み取った値をファイルに残して、レビューに貼る変更です。このラボの最後のステップが、まさにその習慣です。

このラボ環境の限界

ラボのPodには、Argo CDコントローラーとサーバーがありません。そのため、設定を変えて画面が変わるのを見ることはできず、SSOでログインしてみることもできません。その代わり、設定を実際に解釈するコードがCLIの中にあるので、何が読み取られて何が無視されたかは、まったく同じ結果で確認できます。リポジトリのSecretと所有マークのアノテーションは、kwokクラスターに実際に上げてみます。

次のラボですること

空の設定の読み戻しから始めて、アカウント、ビルドオプション、除外リスト、所有マーク、リポジトリを1項目ずつ足していきます。途中でキー名をわざと1文字間違えて、それがどう静かに消えるかを見ます。ラベルの63文字の上限は、kwokクラスターで直接ぶつかってみて、最後に、最初と最後の読み戻しをdiffとして残します。