Open2021/04/21にコメント追加59

Cloud Native 読書会第6回 ArgoCD

Cloud Native 読書会

前回
毎月第3水曜日に少人数で集まり一緒に Cloud Native 技術のコードを読む会です。
Connpass と Wantedly で募集しています。

Role

@potsbo 司会 -> 全体進行
@tomoasleep

Timetable

Introduction 5 min
自己紹介 15 min
読書 60 min
反省会/次回予告 10 min

概要

コードを読むことがなんだかんだ一番コスパの良い技術の学習方法だと @potsbo 考えています。もともとは Kubernetes 読書会として Kubernetes のコードを読む会をしていた事がありましたが、今回はそれの復活版で更に Kubernetes 以外のコードも読んでいいじゃないか、という会です。
かなりカジュアルに行っていた会で進め方も固まっているわけではありません。
皆さんのいろんな意見を聞きながら良い会にしていければなと思ってます。
(ちゃんとやるのが面倒になって中止してしまっていましたが結構評判が良かったので「続けること」を目標に再開しています。)
うまくいったら下の発表のような知見が得られることを期待しています。

前提

ハードルは低く行きます。「少人数だからこそ何でも聞いて良い」を前提にします。どんなに馬鹿に思える質問でもコードを追うことで理解するという解決策を取れば必ず良い学びになると思っています。
多分人の顔と名前も覚えてられないと思うので、「名前は覚えられていない」という前提を共有して進みましょう。

進め方

誰か一人の PC の画面共有をしながら議論をしながら何らかのテーマを解決していきます。全員が非公開 Podcast の出演者のような気持ちで積極的に発言してくれることを期待しています。
テーマはまだ決めていないので「そういえばここの挙動が気になる」というようなものがあると嬉しいです。

@potsbo
Wantedly で技術基盤をやっている大坪です。
Wantedly では deploy 基盤を完全に構築してしまっているのでまだ ArgoCD は使ったことがありませんが、いつか使いたいなと思っていてよく知らない状態です。
https://www.wantedly.com/id/potsbo

@onsd_
Wantedly のDX Squad でインターンをしている大森です
https://www.wantedly.com/id/onsd_

ArgoCDは前にいた会社で使っていましたが、中身はよく知らないので楽しみにしています！

さ

@gosarami
Web系企業でインフラエンジニアをしています。
最近はPipeCDとかも興味あります。
よろしくお願いします！

@hidexir
Yappliという会社で現在エンジニアをしてます。
ArgoCDの内部により詳しくなりたいとおもいます。よろしくお願いします！

@kyohmizu
水元と申します。最近転職して SRE 的なことをやってます。
ArgoCD は仕事でも使いので、コードを理解してより使いこなせるようになれればと思います。

@bells17
普段Kubernetesのコンポーネントなどを書いてます。
ArgoCDは軽くしか触ったことが無いのですがよろしくおねがいします。

@pnd
ドワンゴでエンジニアをしている荻野です。
最近個人的に k8s を調べていて、Argo CD など gitops に興味があります。
よろしくお願いします。

@tomoasleep

Wantedly の Infrastructure squad (インフラチーム) で Engineer をやっています。
GitOps を入れたいと考えているので、徐々に CI 周りを整備して CIOps を慣らしつつ、 Argo CD を入れることを目論んでいます。お家の k3s cluster で動かして遊んだりしてます。

Profile: https://www.wantedly.com/id/tomoasleep

そもそも argo って色々あるよね?
https://github.com/argoproj/argo-workflows は job の依存関係を解決しながら順番に実行してくれる
https://github.com/argoproj/argo-cd が deploy とか周りだという認識

@south37

（遅れたのでこっそり書いておきます）
Wantedly の Infrastructure squad (インフラチーム) で Engineer をやっています。よろしくお願いします！

https://wantedly.com/id/south37

では https://github.com/argoproj/gitops-engine は何なのか?
https://www.weave.works/blog/argo-flux-join-forces で切り出そうとしているやつでまだ全然進行中だという認識

さ

ここに用語集がある

アーキテクチャ

https://argo-cd.readthedocs.io/en/stable/ の getting started の manifest file を見ると、quay.io/argoproj/argocd:v2.0.0 が image として利用されている。

$ curl https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml > manifest.yaml

$ cat manifest.yaml | grep 'image:'
        image: ghcr.io/dexidp/dex:v2.27.0
        image: quay.io/argoproj/argocd:v2.0.0
        image: redis:6.2.1-alpine
        image: quay.io/argoproj/argocd:v2.0.0
        image: quay.io/argoproj/argocd:v2.0.0
        image: quay.io/argoproj/argocd:v2.0.0

github から webhook をもらうのはどこか？ポーリングで pull しているという噂

Argo CD polls Git repositories every three minutes to detect changes to the manifests. To eliminate this delay from polling, the API server can be configured to receive webhook events.

3分毎にポーリングしているが、その遅延をなくすために webhook event をうけるように設定もできる

quay.io/argoproj/argocd:v2.0.0 が動く

argocd-application-controller というコマンドを実行しているのが application controller の StatefulSet
前まで Deployment だったけど最近 leader election のために StatefulSet になったっぽい

さ

実際に argoproj 側が動かしているものがあるので、雰囲気掴むのに参考になるかも

argo-cd を管理している apllication

自分自身を管理しているのがちょっとおもしろい
（Watchしているリソースが更新されると、勝手にクラスタのargo-cd も更新される）

OpenID Connect
https://github.com/dexidp/dex

run を掘るとここに来る

status processor と operation processor に大きく分かれている様子がある

	for i := 0; i < statusProcessors; i++ {
		go wait.Until(func() {
			for ctrl.processAppRefreshQueueItem() {
			}
		}, time.Second, ctx.Done())
	}

	for i := 0; i < operationProcessors; i++ {
		go wait.Until(func() {
			for ctrl.processAppOperationQueueItem() {
			}
		}, time.Second, ctx.Done())
	}

status processor の中はここ

make mod-vendor-local

するとgo moduleがDLされてジャンプできるようになる

下の2つのステートがある

SYNC STATUS
APP HEALTH

// Possible comparison results
const (
	// SyncStatusCodeUnknown indicates that the status of a sync could not be reliably determined
	SyncStatusCodeUnknown SyncStatusCode = "Unknown"
	// SyncStatusCodeOutOfSync indicates that desired and live states match
	SyncStatusCodeSynced SyncStatusCode = "Synced"
	// SyncStatusCodeOutOfSync indicates that there is a drift beween desired and live states
	SyncStatusCodeOutOfSync SyncStatusCode = "OutOfSync"
)

HealthStatusCode の定義

// Represents resource health statusAlexander Matyushentsev, 11 months ago: • docs: document 'top level' packages (#44)
type HealthStatusCode string


const (
	// Indicates that health assessment failed and actual health status is unknown
	HealthStatusUnknown HealthStatusCode = "Unknown"
	// Progressing health status means that resource is not healthy but still have a chance to reach healthy state
	HealthStatusProgressing HealthStatusCode = "Progressing"
	// Resource is 100% healthy
	HealthStatusHealthy HealthStatusCode = "Healthy"
	// Assigned to resources that are suspended or paused. The typical example is a
	// [suspended](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/#suspend) CronJob.
	HealthStatusSuspended HealthStatusCode = "Suspended"
	// Degrade status is used if resource status indicates failure or resource could not reach healthy state
	// within some timeout.
	HealthStatusDegraded HealthStatusCode = "Degraded"
	// Indicates that resource is missing in the cluster.
	HealthStatusMissing HealthStatusCode = "Missing"
)

needRefreshAppStatus は何をやっているのか?
Application という CRD だけを見ている

これがなんか diff を見る上で怪しそう

CompareAppState は 300行近くある...

getRepoObjs

GenerateManifest という grpc call をしていて repo server 側が kustomize や helm の適応も対応していて controller 側は文字列としての yaml だけを受け取っている
これを unstructured に変換したものが desired state として扱われる様子

controller/cache/cache.go

	reconciliation := sync.Reconcile(targetObjs, liveObjByKey, app.Spec.Destination.Namespace, infoProvider)

さ

Design Docs あるけど Resource reconciliation については WIP だった :sob:

argo cd の「git から情報を持ってきて k8s の状態を正しい状態にする」という部分は下のリンクの関数がコアな部分であるように見えた。

更に詳しく読みたい人は是非ここからどうぞ！

感想

本当に全く argo cd の内容を知らない状態からだったが結構何やっているかのイメージが掴めたので嬉しい
結構使ったことがあって詳しく知っている人に助けられてラッキーな回だった
前知識として gitopts-engine の存在などをちょっと知っていたのが役に立った

反省

ちょっと人数を増やしすぎたかな?という気もしているので皆さんの感想が知りたい
- なかなか発言できない人もいたのではないかという不安
「ファシリテーターは何も知らなくていいはずだ！」と信じて進めたけど流石にもう少し前知識入れても良かったか?

感想

Argo CD 独力で読むには複雑で昔諦めたけど、人の手を借りることで割と理解が進んだ感じがある。
GitHub は検索とかそこまで早くないのと依存ライブラリ掘ったりしにくい (SourceGraph 一応やってくれたりするけど) から、コード読むのだったら git clone して Editor + Language Server で読むみたいにして最初からローカルでやるのが良さそう？
- VSCode の go language server 今日はじめてちゃんと使ったけど、割とセットアップいらずで色々やれていてかなり便利ということがわかった

感想

argo cdのコード、色々カオス感があってRancherと十分に勝負できる実装だった
とりあえずtargetObjectsのgRPCリクエストの先でどんなことやってるかがわかったのは良かった

反省

argoの構成が広かったので把握に時間がかかった

よかった

「振る舞いの理解を深める」、「どういうコンポーネントがどういう役割で存在するか全体像をつかむ」などの時間を取ったのはとてもよかったと思う

感想

（ちゃんと環境が構築されてる場合は）ブラウザで GitHub を利用するより local のコードで読む方がスピードは出そう
（これは完全に個人的問題ですが）引っ越したばかりでまだ光回線が通っておらず、ネットワークが貧弱だったのは反省点

余談

reconcilation ではなく reconciliation だということを今日はじめて知りました
今日たまたま AWS 開発者の方が「コードリーディング」について書いたブログポストを見かけたので、コードリーディング力を上げるために参考にしようと思いました
https://blog.riywo.com/2021/04/software-engineer-who-reads-code/

感想

挙動を軽く知っているアプリケーションだったので、読みやすかった気がする
画面は見つつ、詳しくは手元で読んでもいいなと思った
- Live Shareとかでやっても面白そう

Live Share 普段あんまり試せてないから、機能試したさで使ってみたい気持ちある…

感想

普段 UI で操作していた部分の実装がおぼろげに分かりました。
gitops engine は flux との統合はなくなったんですよね確か。
もう少しゆっくりコード見る時間が欲しいと思いましたが、それは前もって読んでおけという話ですね…

感想

Argo CD の知識がある方が多くてスムーズに読み進められた
gitops-engine の存在を初めて知った
IDE, zenn, zoom, github を開いていて、ディスプレイがもう一枚欲しかった

感想/反省

興味のあるOSSのソースコードリーディングは特に楽しい。
追いかけるに必死だったので事前に予習した方が良さそうだなと思ったのが反省でした。
出先だったので途中までスマホだったのでスマホ画面だと超辛い。

ソースコードリーディングの進め方

他のソースコードリーディングでもzennが使われていたが一般的？

感想・反省

全体がなんとなく理解できてよかった。
実装を読むのはシンプルに楽しい細かいオプションや小さいことにきづけたのはよかった。
やはりプロジェクト自体が大きな理解だったので時間あるときに細かい部分おってみたい。
自分もvim tmuxなので、久しぶりに人のあまり他の人の開発環境見る機会がないのでよかった

さ

感想

楽しかったです！
ふんわりとしか知らなかった各コンポーネントに対する解像度が少し上がった気がする
- 管理画面のボタンとの対応とか
新しいバージョンのArgoCDではすでにちょこちょこGitOps Engineが使われており、挙動を理解するためにはそちらもちゃんと読む必要があるということがわかった

じゃあ今は xx を読む時間です！！みたいなのを作ると結構自分のペースで進めていいかも?

Argo Flux 断念したという話が CNDT の発表で出てた

しかし実際にはFluxとArgo CDの統合は上手くいかなかったとして、FluxはGitOps Toolkitの開発に移行し、IntuitのArgo CDはArgo CDと並行にGitOps Engineを開発するということになったと説明した。

https://thinkit.co.jp/article/18040

次回は runc です！！！