∫∫∫∫∫∫∫ Presented by @makocchi 1 CNBF Meetup #3 CI/CDによる自動化でビジネスを加速させよう

CNBF #3 | @makocchi 2 Makoto Hasegawa Working at // AI Division, CyberAgent, Inc Currently // Develop and maintain private OpenStack cloud. Develop and maintain Kubernetes as a Service platform. CKA (Certified Kubernetes Administrator) CKA-1700-0150-0100 CKAD (Certified Kubernetes Application Developper) CKAD-1800-0005-0100 Job Title // Technical Lead Infrastructure Engineer WHO am I Twitter // @makocchi Facebook // makocchi0923 Hobby // Playing bass

CNBF #3 | @makocchi 3 CNBF Meetup #1 「Google Kubernetes Engine と オンプレミス Kubernetes 基盤 に関す る取り組み」 https://speakerdeck.com/makocchi/about-container-runtimes-japan-container-days- v18-dot-04 Makoto Hasegawa

CNBF #3 | @makocchi 4 本日のゴール CI/CD について知ろう！ GitOps について知ろう！

TODAY'S AGENDA 5 CI/CD とは？ GitOps とは？ GitOps ツールについて紹介 まとめ なぜ CI/CD が必要なのか

CNBF #3 | @makocchi 6 CI/CD とは C I D C /

CNBF #3 @makocchi 7 CI/CD とは？ CI = Continuous Integration CD = Continuous Delivery (or Deployment) 日本語ではそれぞれ 「継続的インテグレーション」 「継続的デリバリー(デプロイ)」 と呼ばれています CI と CD は全然違うものなんですが、 CI/CD として 2 つ一緒に出てくることが多いです CI/CD の Google Trend 5 年くらい前からよく聞くようになりました 2015年くらい

CNBF #3 @makocchi 8 CI(継続的インテグレーション) とは？ ソフトウェア開発に必要な「ビルド」や「テスト」等の工程を自動化し、継続的に行われている状態にすることを言います 例えば・・ ソースコードが変更(更新)されたら(もしくは取り込む前に)自動的にテストが走り、コードの品質を担保する ソースコードが変更(更新)されたらコンテナのイメージをビルドし、自動的に Registry に登録される などなど CI 環境を整えることでソフトウェア開発者は開発に集中することができるようになります CI

CNBF #3 @makocchi 9 CD(継続的デリバリー) とは？ リリースプロセスを自動化し、CI で作成された成果物を実際の環境へ自動的に反映させます。 例えば・・・ CI で生成されたコンテナイメージを Kubernetes クラスターへ反映させる CI で生成されたアプリケーションのソースをサーバーに配布する などなど CD 環境を整えることでリリースプロセスが短縮され、より高頻度なアプリケーションの更新が可能になります 似たような言葉に「継続的デプロイ」というものがあります 継続的デプロイは運用環境へのアプリケーションの適用までノンストップで行われることに対し、 継続的デリバリーは運用環境への適用時に承認のステップが入ります CD

CNBF #3 @makocchi 10 結局 CI/CD とは？ まとめると、、、CI/CDを構築するということは コードの修正をトリガーにビルド、テストなどの工程が進み、 アプリケーションがデプロイされるまで自動化されたパイプライン処理を構築すること と言ってもいいでしょう CI/CD を実現してくれるソフトウェアも最近は増えてきていますので、 構築に関してのハードルは下がってきていると思います CD CI

CNBF #3 @makocchi 11 どこまでが CI でどこからが CD ? コード修正 ビルド テスト デプロイ CI CD 諸説あってどれが正しいという事ではないのですが、 CD は CI を拡張してデプロイまで含んだものとする場合もあります(上段) 個人的には CI はテストまで、CD はデプロイする部分に分かれていたほうが分かりやすいと思ってます(下段) CI CD OR

CNBF #3 | @makocchi 12 なぜ CI/CD が必要なのか？ C I D C

CNBF #3 @makocchi 13 なぜ CI/CD が必要なのか？ CI/CD を構築することで様々なメリットを享受することができます - リリースサイクルを短縮することができ、市場のニーズにすばやく対応することができる - テストが組み込まれていることにより、ソフトウェアの品質を担保したまま開発することができる - テスト以外にも脆弱性スキャン等を CI に組み込む事によりセキュリティの向上も見込める - 開発以外の部分は自動化されており、全体的な工数の削減に繋がる - 開発者は開発に集中することができるので開発効率の向上も見込める 良いことばかりですが、逆に大変な部分もあります 結果として 企業競争力の向上 につながる

CNBF #3 @makocchi 14 CI/CD の構築は容易なのか？ どんな CI/CD を構築するのか、によって答えは変わってくるのですが 一般的には CI/CD を構築して実際の運用に乗せるまではかなり苦労すると思います いわゆる CI/CD の ”ベストプラクティス” 的なものがなかなか存在しないという点と、 そもそも実際にきちんとしたテストコードを書かないといけない点があります CI/CD を実現してくれるツールも豊富にあるので技術選定もきちんとしないといけません 確かに初期コストはかかるのですが、長い目で見れば初期コストをかけるだけのメリットはあると言えます

CNBF #3 @makocchi 15 まずは簡単なところから始めてみよう 最初からそのシステムに最適な CI/CD が作れるはずがありません まだ CI/CD を構築していない場合は、まずは簡単な CI/CD を組んで見ることをオススメします そして重要なことですが、CI/CD 自体も定期的に見直しや改修が必要だということです (CI/CD も CI/CD！) 陳腐化した CI/CD に価値はありません なんかよくわからないけどテスト通らなくなった・・・状態では CI/CD が開発の効率を妨げることに為りかねません CD CI

CNBF #3 @makocchi 16 CD の部分はどうしたらいいのか？ CD(継続的デリバリー) は運用環境へのリリース作業に承認が必要になります どうやってこれを実現したらいいのか？疑問に思う方もいらっしゃると思います この承認の部分を Git を使って実現させる手法である GitOps というのが最近流行しています 「承認 = Git での Pull Request の merge」とし、Git の merge をきっかけにしてデプロイが行われる手法です 詳しく見ていきましょう CD CI

CNBF #3 | @makocchi 17 GitOps とは？

CNBF #3 @makocchi 18 GitOps とは？ https://www.weave.works/blog/gitops-operations-by-pull-request 言葉として広まったのは Weaveworks 社が blog で 発表してからと言われています blog「Operations by Pull Request」(2017/08) Weaveworks 社では 2016 年から使われているようです 簡単に言うと、、、 Gitへの変更をコミットし、 Pull Request を作成して、 それを承認する、 というサイクルでアプリケーションのデプロイ作業を管理するということです

CNBF #3 @makocchi 19 GitOps とは？ GitOps を実現する上で欠かせないルールがいくつかあります 例えばこんな感じです。 すべてのインフラのリソース構成を Git リポジトリに保存する Git リポジトリのリソースは Pull Request 経由でのみ変更する Git リポジトリのリソースが変更されたら、その変更を自動でクラスターに適用する クラスターの実際の状態が Git リポジトリのリソースと違っている場合は、それを修正する ここらへんの定義は運用しているチームによって若干違ってくる場合があると思いますが、 概ねこんな感じになるのではないでしょうか

CNBF #3 @makocchi 20 GitOps とは？ GitOps によってもたらされるメリットとしては下記のようなものがあります 環境に対する変更が Git の履歴によって分かりやすくなる 誰がいつ何を変更したのかが分かる いつでも前の環境に戻すことができる 環境に対する変更の差分が分かりやすくなる Pull Request によるレビュープロセスを通すことで組織のガバナンスを適用することができる 自動化による運用コスト軽減 デプロイ作業に関してコマンドラインは一切使う必要が無い すごいでしょ

CNBF #3 @makocchi 21 GitOps とは？ CI/CD のパイプラインを考えた時に、GitOps が担当する部分は CD の部分になります (諸説あります) CI パイプライン Image Registry コードの更新 Pull Request 作成 Pull Request の merge いい感じに自動で Deploy CI CD ※ こちらは Kubernets にデプロイする GitOps の例

CNBF #3 @makocchi 22 GitOps とは？ CI/CD のパイプラインを考えた時に、GitOps が担当する部分は CD の部分になります (諸説あります) CI パイプライン コードの更新 Pull Request 作成 Pull Request の merge いい感じに自動で Deploy Image Registry ※ こちらは Kubernets にデプロイする GitOps の例

Presented by @makocchi 23 GitOps ツールについて紹介

CNBF #3 @makocchi 24

CNBF #3 | @makocchi 25 https://github.com/fluxcd/flux Flux は一言で言ってしまうと非常にシンプルな作りになっています Flux の設定・操作は fluxctl を使います Flux の Agent をクラスターに展開する際に Git のリポジトリや ディレクトリ、Namespace 等を指定して起動させます つまり 1 Agent = 1 リポジトリ定義 になります 複数のリポジトリ定義、例えば Production や Staging 等を branch を分けている場合、同一のクラスターに展開したい場合は定義毎に Flux の Agent を起動させないといけません (※注意事項あり) ということでマルチテナント環境の場合においても、それぞれのテ ナントの環境毎に Agent が必要になります 現在の V1 と平行して V2(GitOps Toolkit) が開発中

CNBF #3 | @makocchi 26 https://github.com/fluxcd/flux Flux の Agent は port 3031 経由で metrics を取得することができ ます(Prometheus 形式) 例えば "flux_daemon_sync_manifests{success='false'} > 0" のよ うに監視しておけば、manifest の apply に失敗した場合検知するこ とができます シンプルな作りなゆえ、実行に必要なリソースは非常に軽量 version 1.20.2 において binary は 60MB 程 / メモリ使用は 40MB 以下 が、Flux にできることはこれだけじゃない！

CNBF #3 | @makocchi 27 https://github.com/fluxcd/flux Flux が監視するのは実は Git リポジトリだけではなくて、Image を 監視することもできます (flux 的には「policy」という定義) Image が更新されたら deployment も更新される仕組み Policy は annotation で自由に設定が可能です 例えばコンテナ名が "myapp" で image に "nginx:1.18.0" を使用し ていたとすると・・・ "fluxcd.io/tag.myapp: glob:1.18.*" としておくと 1.18.x の image が更新される度に deployment を更新してくれます Git 内のマニフェストの更新(image tag の更新)は flux が自動で やってくれます これはもはや GitOps というか ImageOps(造語)

CNBF #3 | @makocchi 28 Argo CD の特徴としては、なんといっても GUI があることではないで しょうか 設定や状態の確認、マニュアルの Sync 操作等すべて GUI から可能です 誰でも見れるデモサイトがあります https://cd.apps.argoproj.io/ https://github.com/argoproj/argo-cd

CNBF #3 | @makocchi 29 Argo CD も各種 metrics を Prometheus 形式で取得可能です Install 手順に従っていれば "argocd-metrics" 及び "argocd-server- metrics" の Service のエンドポイントが作成されています Prometheus 側は scrape 先に上記のエンドポイントを port 8082 で設 定するだけ Grafana の dashboard もあります https://github.com/argoproj/argo-cd

CNBF #3 | @makocchi 30 ちょっと待った GitOps って Kubernetes にしかデプロイできないの？

CNBF #3 | @makocchi 31 そんなことはありません！

CNBF #3 | @makocchi 32 Kubernetes じゃないシステムに対して GitOps でデプロイしたい

CNBF #3 | @makocchi 33 できます

CNBF #3 | @makocchi 34 https://pipecd.dev Flux や Argo CD は Kubernetes に対してしかデプロイできません が、PipeCD は Kubernetes 以外のデプロイに対応しています Terraform/GCP Cloud Run/AWS Lambda PipeCD 自体が Kubernetes 上で動かすものなので Kubernetes は 必要になってきます Argo CD や Flux の良いところ取りをした OSS です もちろん GUI も提供 canary や blue green といったデプロイ手法に対応しています

CNBF #3 @makocchi 35 GitOps ツール比較 インストール Multi Tenancy GUI ImageOps デプロイ対象 Kubernetes だけ Kubernetes だけ Kubernetes だけじゃない インストールに関してはどのプロダクトも簡単に行うことができます PipeCD はまだまだ生まれたばかりの OSS です 完成度といった点では Flux や Argo CD の方に軍配が上がるかもしれませんが、今後に非常に期待できる OSS です ※2020/11/11時点

CNBF #3 @makocchi 36 GitOps ツール比較 (付録) もう少し詳細な比較については CNDT 2020 で発表した資料を御覧ください 「GitOps ツール徹底比較！あなたにぴったりな GitOps ツールがきっと見つかる」 https://speakerdeck.com/makocchi/why-not-find-your-favorite-gitops-tools

CNBF #3 | @makocchi 37 ちょっと待った(再び) OSS のツールでしか GitOps できないの？

CNBF #3 | @makocchi 38 商用製品で GitOps が実現できるものとして Google 社の 「Anthos Config Management」があります 対象は GKE になりますが、ポリシー管理やリソースの管理を GitOps で 実現することができる製品になっています 詳しくはこちらのドキュメントを御覧ください https://cloud.google.com/solutions/best-practices-for-policy-management-with-anthos-config-management

CNBF #3 | @makocchi 39 本日のまとめ

CNBF #3 | @makocchi 40 CI/CD は「継続的インテグレーション」と「継続的デリバリー」の意味 CI/CD を構築することで開発の効率化やリリースサイクルの短縮等が実現 でき、結果として企業の競争力を高めることができる CI/CD 構築には初期コストがかかるが、長い目で見れば初期のコストは回 収できる CI/CD が陳腐化しないように定期的にメンテナンスしていくべき CD の部分は GitOps という手法が最近の流行り傾向 GitOps とは Git の merge をトリガーにしてデプロイが行われる仕組み アプリケーションの状態をすべて Git で管理することで差分の確認や巻き 戻しが容易になる まとめだよ

CNBF #3 | @makocchi 41 本日のゴール CI/CD について知ろう！ GitOps について知ろう！ 達成できましたでしょうか？ おぼえてね

∫∫∫∫∫∫∫ Presented by @makocchi 42 CNBF Meetup #3 CI/CDによる自動化でビジネスを加速させよう FINISH ご清聴ありがとうございました！！ CI/CD による自動化でビジネスを加速させよう All images in this presentation are picked from pixabay.com