- アプリケーションは Mono Repo 上にサブディレクトリとして数十ほど存在
- 各アプリケーションは独立してリリース可能とする
- そのためにリリースブランチ等には
*/release
といった形でそのアプリケーションの名前を持つ
- そのためにリリースブランチ等には
- 開発チームは self-contained な DevOps チームへの変化を目指している
- 開発チームはアプリケーションのコードはもちろん、Kubernetes の manifest にも ownership を持つ (持って欲しい)
- そのため、アプリケーションコードも manifest も同一のリポジトリに保持する
- アプリケーション用のディレクトリの中にサブディレクトリとして manifest をおく場所があり、環境ごとのバリエーションは kustomize の overlay として表現
- GitHub の Pull Request を元に Mono Repo 内の全てのアプリケーションを単一の Kubernetes namespace にデプロイしている
- Pull Request の ID を元に URL も発番される
- そういった dynamic な環境は kustomize のみでの表現が難しいため、一部 envsubst による文字列置換も行なっている
- その他、いくつかのブランチから特定の環境へのデプロイを行なっている
develop
: デフォルトのブランチ。最新のコードがdevelop
環境にデプロイされる*/release
: リリーステストの際、Jenkins からジョブをトリガーすることでdevelop
からブランチが作成され、リリーステスト用の環境としてデプロイされる*/master
: リリーステストで問題がなければrelease
ブランチからマージされ、本番環境へデプロイされる
- manifest の変更とコードの変更は atomic に行いたい
- コンテナの入れ替わり自体は Kubernetes の Deployment 等による rolling update となる
- manifest が持つ各種パラメータと image tag が書き換わるタイミングは同時とする
- Docker イメージのタグはデプロイごとにユニークにするっため、Git SHA1 を含んだもの
- なので、manifest 中の image tag の書き換えを行うのは人間ではなく、ビルドパイプライン内で自動的にやらせたい
フィーチャーブランチにおいては開発者が GitHub リポジトリに git push
する。
develop
, */release
, */master
に直接 git push
することはなく、変更は全てPull Request へのマージにより行われるが、基本的に以降の流れは変わらない
Image Builder が具体的にどこで動くかは未定。
CircleCI かもしれないし、Google Cloud Build のようなマネージド環境かもしれない。
単に docker build
するだけなのであまりこだわらないが、ビルドが遅い時に金で殴ればとりあえず速くなる感じにはあって欲しい。
- 元のブランチや Git SHA1 を元にタグが決まる
develop.<Git SHA1>
:develop
ブランチのものrelease.<Git SHA1>
:*/release
ブランチのものproduction.<Git SHA1>
:*/master
ブランチのものpr-123.<Git SHA1>
: フィーチャーブランチのもの。数字の部分は Pull Request の ID
Manifest Reorganization は Mono Repo から持ってきた manifest に一手間加えて、GitOps Repo に push できる状態にする。
- manifest 中の image tag を書き換える
- ステージング環境であれば、
envsubst
で必要な置換を行う。- 主に、URL 中に含む Pull Request ID とか
これは CircleCI でいいかもしれないし、何か Serverless な実行環境でも良いかもしれない
こちらは manifest だけで、アプリケーションコードは含まない。YAML だけを持つことになる。
ステージング環境においては、Pull Request の数だけサブディレクトリが作られて、その中に manifest が配置されるイメージ。
別で、Pull Request が close されたらそのディレクトリを削除して push するジョブも必要。
Argo CD が GitOps repo を watch して勝手にデプロイしてくれるので特別なことは無し。
- 説明的には Monorepo 関係ない感じになってしまった
- 実際は変更が行われたサービスを検知し、変更のあったものだけ並列で
docker build
する - ステージング環境においては、変更がなかったサービスは
develop
のイメージを再利用する
- 実際は変更が行われたサービスを検知し、変更のあったものだけ並列で
- CD だけで CI 関係なかった
- 現行の全部 CircleCI でやってるやつだと、一つの workflow のなかでテストの実行と
docker build
が全部通ったら、それを待って最後にkubectl apply
とかを行うシェルスクリプトでデプロイする仕組み - が、よく考えたら CI と CD とりあず関係を持たせる必要はなさそうな気がしてきた
*/master
へのマージ時は、 事前に*/release
ブランチでテストが通っていることを Pull Request 上の CI status で確認すれば、あとはマージ後に直接デプロイすれば良い
- 現行の全部 CircleCI でやってるやつだと、一つの workflow のなかでテストの実行と
- タコのキャラクターが多い