デプロイ要求: GitOpsの文脈において、アプリリポジトリの更新にCIがフックしSingle Source of Truthであるmanifestsリポジトリに対してその更新を反映させるPRを発行すること。具体的には、manifestsリポジトリに含まれる対象アプリのマニフェストファイルのDockerイメージタグを最新のものに変更するPRを発行する
ドメインを実現するアプリ 以外のミドルウェアのSingle Source of Truthとなるリポジトリです。今回のサンプルではsealed-secretsをデプロイするためのManifestを含んでいます。IstioやPrometheusといったミドルウェアを利用する場合もここに含まれることになります。パラメータファイルだけを保持し、HelmのChart自体は外部を参照する構成となっています。
manifestsリポジトリとsystem-manifestsリポジトリを分けている理由ですが、これはそれぞれのリポジトリで扱っているもののライフサイクルが異なるためです。デプロイの粒度やタイミング、デプロイ先Namespaceも全く異なりますし、ブートストラップ時にはミドルウェア→アプリという順序が必要になることもしばしばあります。「Single Source of Truthといいつつ複数あるじゃねーか！」とツッコミたくなるかもしれませんが、筆者的には常に分けたほうが何かと便利という結論に達しました。
cd-manifests
CDツールであるargo-cdの設定のSingle Source of Truthとなるリポジトリです。各環境にインストールしたargo-cdからはこのリポジトリを参照させます。(argo-cdをデプロイするためのManifestではなく、) ApplicationをデプロイするためのManifestを含んでいます。ここの Application とはデプロイ設定を表す Custom Resource Definitionです。"Application of Applications" と呼ばれる、幾つかのApplicationをデプロイするためのApplicationを取る構成となっています。これは例えば、「dev 環境のアプリ」・「prd 環境のミドルウェア」といった単位でのデプロイを可能にするための手法です。リポジトリルートにApplication of Applicationsがあり、個々のApplicationは環境別・アプリ/ミドルウェア別に配置されています。
git clone "https://github.com/gitops-demo/manifests.git" manifests
cd manifests
git checkout dev # 常にデプロイ要求はdevブランチ (=開発環境) に向ける
git checkout -b"ci-build/app-a/${TRAVIS_COMMIT}"# 更新用のブランチを作成cd app-a/values
for f in *-app-a.yaml # 開発環境向け設定ファイル (dev-app-a.yaml) と本番環境向け設定ファイル (prd-app-a.yaml) どちらにも同じ処理を行うdoPREV_COMMIT=$(grep -oP "(?<=repository: gitopsdemo/app-a:).+$""${f}")sed-i-e"s!repository: gitopsdemo/app-a:.\+\$!repository: gitopsdemo/app-a:${TRAVIS_COMMIT}!""${f}"# Dockerイメージタグを最新のGitコミットハッシュ値に更新done
manifestsリポジトリの dev ブランチをデプロイ要求の対象としつつ、開発環境向け設定ファイルと本番環境向け設定ファイルを同時に同じように更新していることがわかると思います。なお、今回のサンプルでは開発環境と本番環境の2つだけですが、例えばステージング環境がある場合はステージング環境向け設定ファイルも同様に処理することになります。
ちなみに、開発環境の設定は dev ブランチのみ、本番環境の設定は prd ブランチのみ持たせた場合も考えてみましょう。簡単なことですが、dev ブランチと prd ブランチはそれぞれ独立したコミットログを重ねてしまうためGitの恩恵を受けられません。新しいパラメータを増やそうと思ったら、全く独立した2つのブランチの全く独立した2つのファイルを書き換えることになってしまいます。また、テンプレートも活用できません。
ブランチ戦略の失敗例
そしてマージ先ですが、これを必ず dev ブランチにします。これにより、自動化されたデプロイ要求と整合性の取れたブランチ運用を実現します。
開発環境から本番環境への反映
度々になりますが、アプリの変更は必ず最初に dev 環境に対して行うため、CIによるデプロイ要求はmanifestsリポジトリの dev ブランチに行います。これだけでは本番環境 (prd ブランチ) が一生更新されませんので、こちらの更新方法についても紹介していきます。方法としては、prd ブランチに対するCIからの自動的な処理は一切なく、任意のタイミングで手動でmanifestsリポジトリの dev ブランチを prd ブランチにマージ します。
ここまでmanifestsリポジトリ（=アプリのSingle Source of Truth）についてでしたが、system-manifestsリポジトリについてもフローは全く同じです。(アプリとは異なり、ミドルウェア自体の開発を行うリポジトリは外部にありあくまで利用するだけという仮定のもと、) manifestsリポジトリとは異なり基本的にCIによるデプロイ要求はありません。system-manifestsに対する直接の変更はアプリ構成変更を伴うデプロイ要求と同じように feat ブランチを作成し、それをまずは dev ブランチにPR･マージします。そして必要に応じて dev ブランチを prd ブランチにマージすることで最終的に変更を本番環境へ反映できます。
サンプルプロジェクト > Gitリポジトリ でも軽く触れましたがmanifestsとsystem-manifestsはライフサイクルが大きく異なります。もし分けていないと、例えば本番環境のアラート設定のマニフェストを少しだけ変える必要が出た場合、「既に dev ブランチに溜まっていたアプリの変更差分をprd ブランチへのマージに巻き込まないようにアラート設定コミットだけをCherry-Pickする」といった煩雑なCherry-Pickが多発して面倒なことになってしまうでしょう。
