CI/CD による自動化でビジネスを加速させよう

CNBF Meetup #3 「CI/CD による自動化でビジネスを加速させよう」

Transcript

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

   View Slide

2. 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
   

   View Slide

3. 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
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

7. 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年くらい
   

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

17. CNBF #3 | @makocchi 17
    GitOps とは？
    

    View Slide

18. 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 を作成して、
    それを承認する、
    というサイクルでアプリケーションのデプロイ作業を管理するということです
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

24. CNBF #3
    @makocchi 24
    

    View Slide

25. 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) が開発中
    

    View Slide

26. 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 にできることはこれだけじゃない！
    

    View Slide

27. 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(造語)
    

    View Slide

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

    View Slide

29. 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
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

33. CNBF #3 | @makocchi 33
    できます
    

    View Slide

34. 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 といったデプロイ手法に対応しています
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

38. 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
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide