Kubernetesにアプリケーションをデプロイする場合を考える。Requestを通して適用する。アプリケーションはソースコードを変更することなく、どの実行環境でも動作可能とする。アプリケーションの設定は実行時に環境変数などで注入される。開発チームはアプリケーションと設定に責任を持ち、自分自身でデプロイを行う。Platformチームは実行環境の健全性に責任を持つ。以下はスコープ外とする。別に考える必要がある。以下の選択肢が考えられる。ここでは具体的なツールは考えない。Flow)イメージタグの管理イメージタグをリポジトリで管理するイメージタグはクラスタ内部でのみ管理する(リポジトリのマニフェストには書かない)アプリケーションとマニフェストアプリケーションとマニフェストを別のリポジトリで管理するアプリケーションとマニフェストを同一リポジトリで管理するデプロイサイクルの速いチームは、(a-2)のようにブランチの更新を契機にアプリケーションをデプロイした方が無駄な作業が少なくなる。experienceが大幅に悪化するだろう。一方で、本番環境で問題が発生してすぐに旧バージョンに切り戻したい場合は、(a-1)のようにデプロイを切り離しておく方が早く確実に対応できる。dには以下の制約がある。アプリケーションのビルドとデプロイを連続して行う場合(a-2)アプリケーションとマニフェストは同じリポジトリに入れる必要がある(d-2)。別のリポジトリにあるとアトミックな更新ができない。実行環境ごとにブランチを用意する必要がある(b-3)。単一のブランチではデプロイ先の実行環境を判断できない。以降は具体的なツールを挙げて比較してみよう。(a-1)(b-1)(c-1)(d-1)GitOpsを採用する場合に最も簡単なフローから考えてみよう。デプロイの頻度が低いチームはこのフローで十分と思う。開発者がアプリケーションリポジトリに新しいタグをpushする。CIが新しいイメージをビルドする。リポジトリのタグとイメージのタグは名前を合わせておく。開発者がマニフェストリポジトリを更新するPRを作成する。開発者がマニフェストリポジトリのPRをマージする。GitOpsツールがマニフェストリポジトリとクラスタを同期させる。CI/CD外でリソースが変更されても不整合が起こらない。旧イメージタグへの切り戻しが確実で早い。デプロイに必要な作業が多すぎる。experienceを改善するためにイメージタグの更新を自動化する。hashから生成する。開発者がアプリケーションリポジトリのmasterブランチを更新する。CIが新しいイメージをビルドする。CIがマニフェストリポジトリのイメージタグを更新するPRを作成する。開発者がマニフェストリポジトリのPRをマージする。マニフェストを変更したい場合はPRと合わせて更新する。GitOpsツールがマニフェストリポジトリとクラスタを同期させる。開発者はPRをマージするだけで新イメージタグをデプロイできる。CI/CD外でリソースが変更されても不整合が起こらない。旧イメージタグへの切り戻しが確実で早い。マニフェストリポジトリの更新やPRの作成を作り込むのが大変そう。(a-2)(b-3)(c-1)(d-2)前項ではPRを挟んでイメージタグを更新していた。ビルドとデプロイを連続して行いたい場合(a-2)、アプリケーションとマニフェストをアトミックに更新できないことが課題となる。そこで、アプリケーションとマニフェストを同じリポジトリで管理する(d-2)。アプリケーションとマニフェストのライフサイクルが合わなくなるので、実行環境ごとにブランチを用意する(b-3)。ブランチに対するPRをマージする。CIが新しいイメージをビルドする。アプリケーションリポジトリに含まれるマニフェストをレンダリングする。CIがマニフェストリポジトリを更新する。GitOpsツールがマニフェストリポジトリとクラスタを同期させる。開発者は実行環境に対応するブランチを更新するだけで新イメージタグをデプロイできる。CI/CD外でリソースが変更されても不整合が起こらない。commitが必要になる。マニフェストの変更だけでもイメージが新しくなってしまう。マニフェストリポジトリの更新やPRの作成を作り込むのが大変そう。(a-2)(b-3)(c-2)(d-2)GitOpsを使わない方法も考えてみよう。アプリケーションとマニフェストを同じリポジトリで管理する。ブランチに対するPRをマージする。CIが新しいイメージをビルドする。upgradeを実行する。ビルドとデプロイを切り離したい場合(a-1)は、CIの手動ジョブを使えばよい。開発者は実行環境に対応するブランチを更新するだけで新イメージタグをデプロイできる。複数ツールのピタゴラスイッチがない。緊急の切り戻しが必要な場合はリソースを直接変更できる。新しいマニフェストにないリソースを確実に削除するため、Helmが必須になる。他のツールは使えない。CI/CD外でリソースが変更されると不整合が発生する。マニフェストの変更だけでもイメージが新しくなってしまう。CDのような分かりやすさはない。(a-1)(b-2)(c-2)(d-1)アプリケーションとマニフェストを別のリポジトリで管理する方法もあるが、GitOpsを利用する場合とほぼ同じフローで、わざわざHelmを利用するメリットは小さい。まとめ思いつくままに挙げていったところこんな感じです。Infrastructureなサービスの開発チームにいた時は以下のフローでやっていました。開発者がアプリケーションリポジトリに新しいタグをpushする。ballをビルドしてS3に配置する。開発者がタグ名を指定してデプロイツールを実行する。Configurationを更新する。Instanceをterminateする。一方で、少人数で速いサイクルの開発を行っているチームでは以下のようなフローでした。開発者がアプリケーションリポジトリのmasterブランチにpushする。CIが開発環境にデプロイする。開発者が後続の手動ジョブを実行する。CIが本番環境にデプロイする。いうわけでオチは特にないです。Requestを作成する2020-01-20アプリケーションの開発フローとGitOpsArchivesSearchはてなブログをはじめよう!int128さんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。