CIOpsとGitOpsの話 - inductor's blog

はじめに GitOpsという言葉が生まれたのが自分の知る限り2017年頃なのですが、世の中にあるCI/CDの仕組みはまだほとんどがCIOpsもしくは手動のオペレーションによって成り立っていると思っていて、かつては自分もそうだったのですが「Gitで管理されていればGitOpsなんでしょ？」という勘違いを払拭したくてこのエントリーを書いています。 GitOpsとCIOpsは全然違う まず前提としてGitOpsの明確な定義を知らないという場合、あなたの思う「Gitを契機とした自動デプロイの仕組み」は基本的にはCIOpsです。GitOpsとCIOpsは思ったよりも大きな違いがあって、そもそもGitOpsの必要性が分かっていない場合、自動化によって成立しているデプロイはCIOpsが基本です。 CIOpsとGitOpsの一番の違いは、Push型かPull型かである CIOpsの場合、例えばGitHub

[inductor]

便利な記事を書いたのでブクマお願いします（直球）

[rrreeeyyy]

GitOps は WeaveWorks が最初に提唱していて Principle は https://www.weave.works/technologies/gitops/ にある。CIOps との違いは "4. Software agents to ensure correctness and alert on divergence" 。本番が変更されても Git 側に追従するかが大きな違いだと思う

[sonots]

最近自分も GitHub Actions に権限与えて CD してるのは (初出でweaveworksが言ってた) GitOps じゃないよ、と指摘する業を数回やってた所だったので便利

[onk]

手で変更されたときに勝手に戻るか、つまり Reconciliation Loop が回っているかというのが違いだと思いながら読んでいたので最後に補足されて良かった。Loop を回すためにフェーズ分けられるよねというのはその通り。

[ikeike443]

そのとおりだけどDevOpsムーブメントとは何だったのかという気持ちにはなりますね

[teramako]

GithubActionsから本番に行けちゃう権限を持つことになる点、自分も気になってた。なるほど、GitOpsって名前/考えがあるのか。勉強になった。

[takamii228]

CIの中でDocker pushまでするのは違和感があった。tag pushでレジストリに登録するのは(アプリの)CDではと思った。モノレポだと違うのかな。CIとCDを明確に分けた方が扱いやすいのはわかる。

[kzm1760]

Gitを使ってOperationをすることだと勝手に思ってました。

[hiroponz]

push型もpull型もアプローチの違いであって、Gitを利用してデプロイしていれば両方ともGitOpsと呼ぶのが自然だと思うんだけど、pull型じゃないとGitOpsじゃないみたいな風潮に違和感を感じる。 https://www.gitops.tech/

[juve534]

なるほど！今までGitOpsだと思っていたものはCIOpsだった。

[iekusup]

ほー。

[guitarman18]

Cloud Deployのリリースタイミングと関連してそう

[noritada]

GitOpsという言葉になぜなったのかはよくわかってないけど、CIとCDは明確に違うから責任分界点が必要だよね、は同感なのでわかる。むしろ、何故「CI/CD」ってCIとCDを一緒くたにしたがるのかがよくわかっていなかった。

[manji0]

完全にコード更新とデプロイが同期されてると困るケースに心当たりしかないので、参考になる話だった

[Nyoho]

テストやlintとデプロイを分けようという

[takayuki007]

ci cd

[iwamot]

"GitOpsを適用したいパターンは実はとてもはっきりしていて、「SREと開発の責任分界点が必要」という場合です。"

[gfx]

GitOpsって言葉を初めて知った…とりあえずGitOpsはCIOpsではないってことは分かった。

[retore]

“main(意識が高いのでmasterではない)”

[takahashim]

CI用のdevelopブランチとCD用のmainブランチ（SREのみ権限を持つ）が分かれてればGitOps、みたいな話？

[hiroomi]

“CIとCDの責任分界ができることです。 つまり、開発者チームまではCIを担保し、そこから先にいるSREやらインフラやらがCDの面倒を見るという点にあります。”

[msh5_h]

ほほー、たしかにこの構成ならうまく権限分離できてる。すでに自動化できてるチームなら、Argo導入して既存のデプロイを移行することで自然とGitOpsできそう。

[Eiichiro]

サーバー直で書きかえるの怖いのと、設定めんどい！ってなったてたので、ちょうどgitopsで止めてたところ。もちろんデプロイは、1コマンドで終わるけど。

[slash_01]

なるほど。ちゃんと理解出来てなかったわ。ありがたい。

[surume000]

その違いってどこかで定義されているものなの？

[bouzuya]

GitOpsとCIOpsは違うという話。ぼくはリリースの判断を開発側ではなく運用側に持っていくためにトリガーを docker regiatry までを git に、そこから AP サーバーなどへのデプロイを slack にしたことがあった。

[dekasasaki]

参考になる考え方だ。

[j-u]

最小権限の原則を遵守するために責任分界点が明確になるように実装するというのはすごく大事だな。丁寧な仕事しなきゃ（自戒）。

[ledsun]

なるほど、機能追加だけする人とデプロイできる人の権限を分けたいのはわかる。組織が違ったら、そりゃそうなるか。