Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
GitOps共有会
Search
johnmanjiro
August 17, 2022
Technology
2
6.4k
GitOps共有会
johnmanjiro
August 17, 2022
Tweet
Share
More Decks by johnmanjiro
See All by johnmanjiro
Istio Helm化
johnmanjiro13
0
2.2k
Other Decks in Technology
See All in Technology
API提供者のためのMCPサーバー設計ガイド / MCP Server Design Guide for API Providers
yokawasa
0
240
BtoBプロダクト開発の深層
16bitidol
0
130
Azure SynapseからAzure Databricksへ 移行してわかった新時代のコスト問題!?
databricksjapan
0
110
あなたのWebサービスはAIに自動テストしてもらえる?アクセシビリティツリーで読み解く、AIの『視点』
yusukeiwaki
1
3.3k
AWSのProductのLifecycleについて
stknohg
PRO
0
290
研究開発部メンバーの働き⽅ / Sansan R&D Profile
sansan33
PRO
3
20k
SoccerNet GSRの紹介と技術応用:選手視点映像を提供するサッカー作戦盤ツール
mixi_engineers
PRO
1
110
VCC 2025 Write-up
bata_24
0
140
GA technologiesでのAI-Readyの取り組み@DataOps Night
yuto16
0
230
組織観点からIAM Identity CenterとIAMの設計を考える
nrinetcom
PRO
1
130
Modern_Data_Stack最新動向クイズ_買収_AI_激動の2025年_.pdf
sagara
0
130
インサイト情報からどこまで自動化できるか試してみた
takas0522
0
120
Featured
See All Featured
Side Projects
sachag
455
43k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
127
53k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
18
1.2k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
229
22k
KATA
mclloyd
32
14k
A better future with KSS
kneath
239
17k
Imperfection Machines: The Place of Print at Facebook
scottboms
269
13k
What's in a price? How to price your products and services
michaelherold
246
12k
Building Better People: How to give real-time feedback that sticks.
wjessup
368
20k
Transcript
johnmanjiro GitOps共有会
None
1. 今日の目標 2. GitOpsとは 3. ArgoCDとは アジェンダ
今日の目標 • GitOpsについてなんとなくわかる • ArgoCDについてなんとなくわかる 今日やりたいのは全体感の共有(導入指南ではない) 実際導入するかの判断材料になれば嬉しい 概要を知りチームで議論した上で、 最終的に導入しないという判断をすることもありだと思う
GitOps
GitOpsとは GitリポジトリをSingle Source of Truthとしてアプリケーションとインフラの両方を 管理するCD手法 リソースを常にGitの状態に合わせる 2017年にWeaveworksが提唱した 管理手法なので利用はKubernetesに限らない(実際はk8sが多い)
GitOpsとは GitOpsには2種類ある Push型 Pull型
GitOpsとは Push型 既存で実施している方法 k8sクラスタの外からapplyするのでPush git push (PRマージ) 発火 apply
GitOpsとは Pull型 k8sクラスタの中にデプロイする君がいてGitリポジトリをpolling リポジトリのmanifestと実際のリソースに差分があったらapply 差分をとってきてapplyするのでPull 世間一般でのGitOpsはこっち git push (PRマージ) polling
差分があったら apply
なぜPull型なのか Push型のデメリット • CIの権限が強すぎる ◦ CI乗っ取られたら終わる • CIとCDを分離できない ◦ アプリケーションの開発とk8sの管理が別チームの場合やりづらい
• k8sのリソースが直接変化したときにGitリポジトリと同期できない ◦ Single Source of Truthとは Pull型のメリット • クラスタ内でデプロイするのでCIに権限がいらない • CIとCDを明確に分離できる(上と同じ理由) • Gitリポジトリをpollingしているのでリソースが変わってもリポジトリに同期できる ◦ 逆にいうとkubectl editしても戻される(設定で変更可能) • Revert時にアプリケーションのCI(RSpecなど)がいらない(構成のところで解説) ◦ 後からアプリケーション側でもRevertする必要はある
Pull型GitOpsの構成
Pull型の構成 Application Repo Amazon ECR 2. docker imageを push Manifest
Repo 1. 機能開発の PRマージ 3. manifestのimageタグを 書き換えるPRを作成 polling 5. 差分を検知 6. apply 4. PRマージ • リポジトリが2つに分かれる ◦ ApplicationとManifestは完全にライフサイクルやCIの内容が違う ◦ RevertでApplicationのCIを待たなくてよくなる
GitOpsのまとめ • GitリポジトリをSingle Source of TruthとしたCD手法 • Push型とPull型がある • 世間一般でのGitOpsにはPull型が使われる
• Gitリポジトリに合わせるので手で直接いじっても戻される • Pull型の構成ではリポジトリが2つにわかれる(ApplicationとManifest) • Revert時にアプリケーションのCIを待たなくていい ◦ しかし、アプリケーション側でもRevertをかける必要がある
ArgoCD
ArgoCDとは =
ArgoCDとは Application Repo Amazon ECR 2. docker imageを push Manifest
Repo 1. 機能開発の PRマージ 3. manifestのimageタグを 書き換えるPRを作成 polling 5. 差分を検知 6. apply 4. PRマージ
• Kubernetes上でGitOpsを実現するCDツール • Argo Projectで開発されている ◦ 既存で使っているArgo Rolloutsの兄弟 • GitOpsツールとしては有名
◦ 情報もいっぱい ArgoCDとは
• 導入が簡単 ◦ 運用はしっかり考える必要がありそう • Argo Projectのツールをすでに使っている ◦ Argo Rollouts
• 高機能なGUI ◦ デモサイト:https://cd.apps.argoproj.io/applications ◦ マニフェストのeditもGUIからできる • Sync(Gitリポジトリとk8sを一致させること)を細かく設定できる なぜArgoCDか?
• Application ◦ ArgoCDが管理する対象 ◦ GitHubのリポジトリなどを指定する • Project ◦ 自由にProjectを切ることができる
• Resource Hooks ◦ SyncのPhaseをフックに色々実行できる • Self Heal ◦ 手動でリソースが変更された場合に Gitの状態に戻す ◦ 使わないことも可能 • リソースの一部を管理から外すこともできる ◦ 例:Deploymentのreplicasを外せばHPAがreplicasを書き換えても怒られない ArgoCDの概要
• Hook(Sync Phase) ◦ PreSync ◦ Sync ← 通常ここで実行される ◦
Skip ◦ PostSync ◦ SyncFail • Sync Wave ◦ 各Phaseの中でのapplyする順番 ◦ Sync ▪ Sync Wave: 1 ▪ Sync Wave : 2 ← 1, 2の順番でapplyされる どれも各リソース(e.g. Deployment)にannotationで設定できる Resource Hooks 差分を取得 apply Sync
マイグレーションの自動化ができる PreSync:マイグレーションJobをapply、実行 Sync:通常のアプリケーションをapply Resource Hooksで何ができるのか? 注意点 • この構成の場合マイグレーションは常に実行される
• 2つのRevert PR ◦ ManifestとApplication両方にRevertが必要 ◦ argocd-image-updaterもあるけどCIのメリットがなくなる • マイグレーションするかしないかを設定 ◦
個別にJobをSyncするとかでできなくはない ◦ ほぼ常にJobがOutOfSyncになる ArgoCDで大変そう(?)なこと
• Kubernetes上でGitOpsを実現するCDツール • リッチなGUIがある • Sync PhaseとSync Waveを組み合わせることで、マイグレーションの自動 化も可能 •
Self Healで常にGitの状態に合わせることができる • リソースの一部を管理から外すことでHPAも使える • 一方でRevert PRが複数必要になるなどの懸念点もある ArgoCDまとめ
まとめ • GitOpsはGitをSingle Source of TruthとしたCD手法 • ArgoCDはGitOpsをKubernetes上で実現するためのCDツール • 導入する場合は運用が大きく変わるのでみんな理解しているとよさそう
• Guide To GitOps • ArgoCDドキュメント • ArgoCDデモサイト • argocd-notifications
• 5 GitOps Best Practices • ArgoCDに入門する 参考リンク