Kubernetesで作るコンテナベースCI★CDの夕べ / ochacafe#1

36bb9dcd778d2a9621d44e92425d0907?s=47 hhiroshell
December 20, 2018
3.5k

Kubernetesで作るコンテナベースCI★CDの夕べ / ochacafe#1

Oracle Cloud Hangout Cafe#1で喋りました。
GitOpsの考え方解説と、Kubernetes + Wercker + Helm + SpinnakerでGitOpsを動かすデモ。

36bb9dcd778d2a9621d44e92425d0907?s=128

hhiroshell

December 20, 2018
Tweet

Transcript

  1. 1.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | Kubernetesで作る コンテナベースCI★CDの夕べ 早川 博 | @hhiroshell 日本オラクル株式会社 ソリューション・エンジニアリング統括 セールスコンサルタント Oracle Cloud Hangout Cafe #1
  2. 2.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | Safe Harbor Statement The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle.
  3. 3.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | 自己紹介 • 早川 博(はやかわ ひろし) • 日本オラクル所属 – Java SE/EE, Microservices, DevOps • Ergodoxユーザー @hhiroshell
  4. 4.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | Special Thanks • 今回の発表の元になった知見は、Cloud Native Developers JPでのコミュニティ活動で得られたものを多く 含みます。 • この場を借りてお礼をさせていただきます。
  5. 5.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | 目次 • イントロダクション • CI/CD(継続的インテグレーション/継続的デリバリー)とは • GitOps – GitOpsとは – GitOpsの実践 • GitOpsを実現するツールの紹介
  6. 6.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | 目次 • イントロダクション • CI/CD(継続的インテグレーション/継続的デリバリー)とは • GitOps – GitOpsとは – GitOpsの実践 • GitOpsを実現するツールの紹介
  7. 7.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | 新しいビジネスの発見 既存ビジネスの遂行 バックオフィス業務の効率化 New IT Old IT ITシステムへの新しいニーズ ※Kelly Goetsch 「Oracle: Building Cloud Native Software」 より一部改変
  8. 8.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | 新しいビジネスの 発見 • 新たなビジネス要件や機会に対処するために 構築される新規アプリケーション。 • ライフサイクルは12カ月未満と短い。 既存ビジネスの 遂行 • 企業固有のプロセスや業界固有の機能を 実現 • ライフサイクルは1~3年程度だが、頻繁に変 更・強化して変化に対応する必要がある。 バックオフィス 業務 • 中核的なトランザクション処理を担い、企業の 重要なマスターデータを管理。 • 変更のペースは遅い。 Systems of Record Systems of Differentiate Systems of Inovation 参考:「ペースレイヤリング」が変えるIT戦略 http://itpro.nikkeibp.co.jp/article/COLUMN/20120306/384850 新しいビジネスに対応するにはアプリケーションを高頻度で更新する必要がある ペースレイヤー モデル 更新頻度 高 更新頻度 低
  9. 9.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | •① 開発プロジェクトの進め方 – 進捗管理、タスク管理手法が短期開発に最適 化されていない – 計画変更を柔軟に取り込むことができない •② 開発者と運用担当者の壁 – 運用担当者はアプリ更新を嫌うため、高頻度 のリリースに協力的でない – 情報共有の手段が効率的でなく連携が不足 – テストからリリースに至るオペレーションが多く なり、運用者が対応できない Confidential – Oracle Internal/Restricted/Highly Restricted 10 •③ 開発・運用環境構築のリードタイム – 一から環境構築するのはリードタイムが大きく 短期開発に対応できない – 要件が頻繁に変わる状況で、柔軟に環境の構 成を変更するのは困難 •④ アーキテクチャ – 大規模なアプリケーションの場合、変更の影 響範囲の把握が難しく、実装に時間がかかる – (同じく)再起試験の工数が膨大になるため、 テストに時間が係る 高頻度リリースを実現する上での課題
  10. 10.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | •① 開発プロジェクトの進め方 →アジャイル開発 – 進捗管理、タスク管理手法が短期開発に最適 化されていない – 計画変更を柔軟に取り込むことができない •② 開発者と運用担当者の壁 →DevOps – 開発/運用のチーム文化の改善 – 開発プロセスのためのITの活用 • 情報共有ツールの活用 • 自動テスト/自動デプロイ Confidential – Oracle Internal/Restricted/Highly Restricted 11 •③ 開発・運用環境構築のリードタイム → インフラの自動構築とCI/CD – 構成管理ツールやCI/CDパイプラインを利用 – 開発、テスト、運用環境の構築を自動化、高速 化 •④ アーキテクチャ →Microservices – システムを複数の疎結合なアプリケーションの 集合体として構成 – 変更の影響範囲を極小化することで、高頻度 でのアプリケーション更新を可能にする 高頻度リリースにおける課題を克服する手段
  11. 11.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | •① 開発プロジェクトの進め方 →アジャイル開発 – 進捗管理、タスク管理手法が短期開発に最適 化されていない – 計画変更を柔軟に取り込むことができない •② 開発者と運用担当者の壁 →DevOps – 開発/運用のチーム文化の改善 – 開発プロセスのためのITの活用 • 情報共有ツールの活用 • 自動テスト/自動デプロイ Confidential – Oracle Internal/Restricted/Highly Restricted 12 •③ 開発・運用環境構築のリードタイム → インフラの自動構築とCI/CD – 構成管理ツールやCI/CDパイプラインを利用 – 開発、テスト、運用環境の構築を自動化、高速 化 •④ アーキテクチャ →Microservices – システムを複数の疎結合なアプリケーションの 集合体として構成 – 変更の影響範囲を極小化することで、高頻度 でのアプリケーション更新を可能にする 今日のテーマ
  12. 12.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | 目次 • イントロダクション • CI/CD(継続的インテグレーション/継続的デリバリー)とは • GitOps – GitOpsとは – GitOpsの実践 • GitOpsを実現するツールの紹介
  13. 13.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | CI/CD(継続的インテグレーション/継続的デリバリー)とは • ソースコードの変更から本番環境へのリリースまでの流れを極力自動化 • 人手を極力配したテスト・リリースにより、システムの品質の安定と高頻度 リリースを実現する 開発、運用プロセスにおける高頻度リリースのための取り組み 手作業での テスト 成果物リポジトリ 自動受け入れ テスト 自動 キャパシティ テスト リリース コミットステージ ソースコード リポジトリ 1つのビルド成果物を使い回す コミット
  14. 14.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | コンテナとKubernetes登場後のCI/CD • コンテナの可搬性 – アプリケーションに与える設定、依存ライブラリなどの状態を小容量のコンテナイ メージとしてパッケージング – 多数の環境に、容易にアプリケーションを展開可能 • Kubernetesの宣言的オペレーションと環境のコード化 – 実行環境の構成をコードに記述することで、複数クラスターに同等の環境を容易に 構築 テスト・運用環境の構築が省力化されCI/CDを実現しやすくなった
  15. 15.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | Kubernetesの宣言的オペレーションと環境のコード化 • クラスター上にデプロイする成果物の構成をコードによって定義 – 運用オペレーションはコードの変更によって実施し、作業を簡素化する – 複数Kubernetesクラスターでの相互運用を実現する Confidential – Oracle Internal/Restricted/Highly Restricted 16 あるべき状態を指示するだけで、Kubernetesクラスターに所望の環境を構築 Kuberenetesクラスター manifestファイル ✓ アプリ x 3 ✓ データストア x 2 ✓ ネットワークはアプリ→ データストアを許可 ✓ …etc Kubernetesに適用
  16. 16.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | CIツールとKubernetesによるCI/CDパイプラインの例 • ビルド・単体テスト後の後処理として、コンテナのPushとクラスターへのデ プロイを行う – docker push / kubectl apply • フェーズ毎にデプロイ先のクラスターを切り替える CIツールからクラスターに指示を出すことで複数の環境を自動構築 CIツール アプリケーション コード Dev コンテナレジストリ Prod Dev Staging コードをプッシュ > docker push > kubectl apply Kubernetesクラスター
  17. 17.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | CI/CDに残された課題 (全体感) • CIツール側で全てのデプロイ先との連携設定を管理する必要がある • セキュリティのリスク。CIツールがAttack Surfaceになる • 環境の再現性が保証されない • オペレーションにCIツール固有の操作が入り込む まだまだたくさんの課題が…。
  18. 18.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | CI/CDに残された課題 1/4 • CIツール側で全てのデプロイ先との連携設定を管理する必要がある – 一度設定すれば終わりではない(クレデンシャル情報の更新など) – 多数の環境があると管理が困難に CIツール Prod Dev Staging Kubernetesクラスター • たくさんの接続情報 • 消していいのかわからない謎 の設定 …
  19. 19.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | CI/CDに残された課題 2/4 • セキュリティのリスク。CIツールがAttack Surfaceになる – CIツールがハックされると、実行環境に影響を与える操作が可能になりうる – クラウドで提供されるCIサービスを利用する場合はより注意が要る CIツール Prod Dev Staging Kubernetesクラスター ハック わるいこと
  20. 20.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | CI/CDに残された課題 3/4 • manifestが現在の環境を表現しているとは限らない – パイプラインの実行順序が必ず保証されるとは限らない。パイプライン実行の manifestが最後に適用されたのか…? – 最悪の場合、環境の異変に気付いて初めて問題が起きたことがわかる CIツール Prod Dev Staging Kubernetesクラスター ?
  21. 21.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | CI/CDに残された課題 4/4 • オペレーションにCIツール固有の操作が入り込む – デファクトのCIツールの不在。学習コスト↑ – 最悪の場合手動でのkubectl実行が常態化 秘伝のJenkins
  22. 22.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | 目次 • イントロダクション • CI/CD(継続的インテグレーション/継続的デリバリー)とは • GitOps – GitOpsとは – GitOpsの実践 • GitOpsを実現するツールの紹介
  23. 24.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | 【再掲】CI/CDに残された課題 (全体感) • CIツール側で全てのデプロイ先との連携設定を管理する必要がある • セキュリティのリスク。CIツールがAttack Surfaceになる • 環境の再現性が保証されない • オペレーションにCIツール固有の操作が入り込む まだまだたくさんの課題が…。
  24. 25.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | GitOpsとは • CD(継続的デリバリー)を行うための手法のひとつ • 2017年にロンドン発のスタートアップ「Weaveworks」社によって提唱された • Gitリポジトリのコードを起点にして、システムの実行環境やアプリケーショ ンの変更をおこなう手法 GitOps → Gitリポジトリのコードを起点にオペレーションを行うCDの手法
  25. 26.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | GitOpsの核となるアイデア – 1/2 • Single Source of Truth – Gitリポジトリ上のコードによって、インフラとアプリケーションの状態が決定する • 状態の差分検出とconversion – 実行環境がSingle Source of Truthとの差分を検出して自律的に状態を変える – 環境の差分が解消されない場合は、アラートを上げる 実行環境 差分検出 装置 ✓ アプリ x 3 ✓ データストア x 2 ✓ ネットワークはアプリ→ データストアを許可 ✓ …etc 自環境に 差分を反映 (conversion) Single Source of Truth (manifest)
  26. 27.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | GitOpsの核となるアイデア – 2/2 • CIとCDの分離 – CIツールがGitリポジトリを境界にCDと分離される。CDはCIツールに依存しない • OpsのインターフェースをGitに統合 – オペレーションは、Sigle Source of TruthへのPull Requestによっておこなう 実行環境 差分検出 装置 自環境に 差分を反映 (conversion) CIツール Ops CD CI PR 運用操作 PR アプリの更新 Single Source of Truth (manifest)
  27. 28.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | GitOpsの考え方に基づくCI/CDパイプライン • 環境への変更適用はSingle Source of Truthを介して行われる Single Source of Truthを中心としたパイプラインを構成 差分検出装置 conversion Ops PR: 運用操作 CIツール コンテナレジストリ PR:環境別のmanifestの作成・適用 アプリケーションコード Single Source of Truth (manifest) Dev コードをプッシュ > docker push 差分検出装置 Production Staging 差分検出装置 development
  28. 29.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | GitOpsのメリット • 管理性とセキュリティ 従来型のCI/CDの課題を解決 差分検出装置 conversion Ops PR: 運用操作 CIツール コンテナレジストリ PR:アプリの更新 アプリケーションコード Single Source of Truth (manifest) Dev コードをプッシュ > docker push CIはクラスターへの接続を行わないので ✓ CIで連携設定を管理しなくて良い ✓ セキュア(Attack Surfaceにならない) 差分検出装置 Production Staging 差分検出装置 development
  29. 30.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | GitOpsのメリット • 環境の状態の保証 従来型のCI/CDの課題を解決 差分検出装置 conversion Ops PR: 運用操作 CIツール コンテナレジストリ PR:アプリの更新 アプリケーションコード Single Source of Truth (manifest) Dev コードをプッシュ > docker push クラスターの状態はSingle Source of Truth によって決定される 差分検出装置 Production Staging 差分検出装置 development
  30. 31.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | GitOpsのメリット • 運用のインターフェースをGitに統一 従来型のCI/CDの課題を解決 差分検出装置 conversion Ops PR: 運用操作 CIツール コンテナレジストリ PR:アプリの更新 アプリケーションコード Single Source of Truth (manifest) Dev コードをプッシュ > docker push 運用のインターフェースはGitに統一 CI固有の操作を排除 差分検出装置 Production Staging 差分検出装置 development
  31. 32.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | GitOpsを実現するツール • CIツール – Jenkins、CircleCI、ConcourceCI、Wercker… • 環境毎のmanifestを生成するテンプレートエンジン – Helm、Ksonnet、Kustomize • 差分検出と反映 – Weave Flux、Spinnakerと差分アラート(e.g. kubediff) 従来からあるツールの組み合わせで実現可能 ※Kustomizeは まだロゴがない
  32. 34.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | GitOpsでの開発 – リリースのフロー • もう少し詳しくGitOpsの環境を表現した図 Single Source of Truth テンプレート 環境毎のmanifest master release 差分検出装置 Staging 差分検出装置 Production build test docker push create manifest Dev
  33. 35.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | GitOpsでの開発 – リリースのフロー • featureブランチをPushするとテストを実行 Single Source of Truth テンプレート 環境毎のmanifest master release 差分検出装置 Staging 差分検出装置 Production build test docker push create manifest Dev feature-xxx コードをプッシュ
  34. 36.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | GitOpsでの開発 – リリースのフロー • releaseにマージするとimageのPushとmanifestの更新PRを発行 Single Source of Truth テンプレート 環境毎のmanifest master release 差分検出装置 Staging 差分検出装置 Production build test docker push create manifest Dev feature-xxx コードをプッシュ v1.0-release-xxxxx PR
  35. 37.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | GitOpsでの開発 – リリースのフロー • manifestを更新するとその内容が環境(staging)に反映される Single Source of Truth テンプレート 環境毎のmanifest master release 差分検出装置 Staging 差分検出装置 Production build test docker push create manifest Dev v1.0-release-xxxxx feature-xxx merge PR
  36. 38.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | GitOpsでの開発 – リリースのフロー • stagingでの確認が完了したらmasterにマージ。あとは一緒 Single Source of Truth テンプレート 環境毎のmanifest master release 差分検出装置 Staging 差分検出装置 Production build test docker push create manifest Dev feature-xxx コードをプッシュ v1.0-release-xxxxx PR v1.0-master-xxxxx
  37. 39.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | GitOpsでの開発 – リリースのフロー • 今度はproductionにmanifestの更新が反映される Single Source of Truth テンプレート 環境毎のmanifest master release 差分検出装置 Staging 差分検出装置 Production build test docker push create manifest Dev feature-xxx merge PR v1.0-release-xxxxx v1.0-master-xxxxx
  38. 40.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | ここでデモの準備 • OKEでKubernetesのクラスターを作ります
  39. 41.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | パイプラインを作るときの注意点 • アプリケーションのブランチ戦略とGitOpsパイプラインの関係を独立して考 えるのは難しい – パイプラインとセットで設計する必要がある → DevとOps俯瞰して考えることが必要 • Single Source of Truthにmanifestのテンプレートエンジンがほとんど必須 – 環境毎のmanifestを別々に作成するのはつらい。共通化できるところはしたい 話はそんなに簡単ではなく・・・。
  40. 42.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | ブランチ戦略とGitOpsパイプライン • うまくいきやすい例 → ブランチと環境とを1対1で考えられる(これを発展させたものが Git Flow) ブランチ戦略の特性によってパイプラインの維持管理の難易度がちがう – masterのコードの成果物だけが本番環境に乗るようなケース – ECサイト、SNS(インターネット向け)など、複数のバージョンを併存して提供されるこ とが基本的にないもの master release feature Staging development Production meargeされたら 環境を更新
  41. 43.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | ブランチ戦略とGitOpsパイプライン • 難易度が高い例 → バージョン毎のブランチを維持していくケース ブランチ戦略の特性によってパイプラインの維持管理の難易度がちがう – たとえば、新バージョンの確定ごとにリリース用のブランチが作られ、複数の過去 バージョンでメンテナンスが走るような方法 – 異なるバージョンを配布して、ユーザーがインストールして使うソフトウェア • パッケージ製品、MW、DB…。 master v1.1 v1.0 release … … Prod Dev Staging ?
  42. 44.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | Single Source of Truthにテンプレートエンジンを利用する • Single Source of Truthでテンプレートエンジンを使うモチベーション – 環境毎のmanifestを別々に作成するのはつらい。共通化できるところはしたい – テンプレートでは現状の構成を把握しにくいので、テンプレートから作ったrawなmanifestも 管理しておく – 運用オペレーションのI/Fにもなるので、オペレーションのやり易さも考慮したい manifestのバリエーションを生成する機能がGitOpsと高相性 差分検出装置 conversion 差分検出装置 Production Staging 差分検出装置 Development Single Source of Truth テンプレート 環境毎のmanifest
  43. 45.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | 目次 • イントロダクション • CI/CD(継続的インテグレーション/継続的デリバリー)とは • GitOps – GitOpsとは – GitOpsの実践 • GitOpsを実現するツールの紹介
  44. 46.
  45. 47.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | GitOpsを実現するツール • CIツール – Jenkins、CircleCI、ConcourceCI、Wercker… • 環境毎のmanifestを生成するテンプレートエンジン – Helm、Ksonnet、Kustomize • 差分検出と反映 – Weave Flux、Spinnakerと差分アラート(e.g. kubediff) 従来からあるツールの組み合わせで実現可能 ※Kustomizeは まだロゴがない ※ 赤字はこのあと紹介&デモするもの
  46. 48.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | Wercker | Oracle Container Pipelines Service • オランダ発のスタートアップが発祥。2017年に Oracleが買収してサービスを継続 • 成果物はコンテナとしてビルド • パイプライン実行環境として任意のコンテナを導入 可能。簡単に幅広いカスタマイズができる • 直感的で効率的なWorkflow作成 – 初学者でも直感的に操作しやすいGUI コンテナベースの開発に対応するCI/CDサービス
  47. 49.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | • Step – 処理の最小単位。1回の コマンドの呼び出しや スクリプトの実行に相当 – 複数のPipelineで流用可能 • Pipeline – 複数Stepを連結して束ねる 単位 – 「結合テスト」、「実行環境へ のデプロイ」など • Workflow – CI/CDの一連の処理の全体 – CI/CDがKickされたときに通 して実行される単位 Werckerのコンセプト Pipeline: build Pipeline: integration test Pipeline: deploy to cluster Workflow Step Step Step Step Step Step Pipelineの流れは GUIで作成 具体的な処理内 容はyamlで記述 >gradle build >prep data >run test >kubectl xx >kubectl xx >kubectl xx
  48. 50.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | Werckerの特徴 • Box: – Stepの実行環境として任意のDockerコンテナを利用 • Services: – Stepの処理中に利用する外部サービスを、任意のコンテナとして起動 e.g.) redis, mongo等のデータストアを自動テスト中に利用 • Step Store: – 自作したStepを公開/共有し合うエコシステム – ストアからStepを取り入れることで効率よくパイプラインを作成 ワークフローの作成をサポートする様々な機能を提供
  49. 51.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | Helm • Kubernetesのパッケージマネージャ – Linuxにおけるapt, yumのような位置づけ – 所定のリポジトリに公開されたChartを利用して、コマンド 1つでKubernetes上にソフトウェアスタックを展開する – 依存関係の管理、アップデート/ロールバック • CNCFがホストするプロジェクトのひとつ。現在は Incubating • Chartを自作してmanifestのテンプレートエンジンと しても利用可能 Kubernetes上で可動するソフトウェアを簡単に展開/共有するツール
  50. 52.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | Helmのアーキテクチャ • リポジトリから取得したChart(雛形)をValue(雛形を埋める設定値)とともにクラ スターに送付 • Tillerがクラスター内にソフトウェアを展開する • ChartとValueのセットの管理をクラスター側で行う リポジトリ、Client、Tillerで構成 Kubernetesクラスター Helm Tiller Helm Client Chartリポジトリ (GitHub) ChartとValue(default) デプロイ メタデータ Chartと Value(変更後)
  51. 53.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | GitOpsにおけるHelmの使い方(例) • クライアント側でmanifest生成を完結する方法を利用 – Chartから環境毎のValueを当てはめたmanifestを生成 – クラスターが自分に対応するmanifestをみて、デリバリーをおこなう Chart / Valueとそこから生成したmanifestをSingle Source of Truthとして扱う 差分検出装置 conversion 差分検出装置 Production Staging 差分検出装置 Development Single Source of Truth ChartとValue 環境毎のmanifest > helm template
  52. 54.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | Spinnaker • CD(継続的デリバリー)ツール • Netflixにより開発されているOSS。2015年に公開 • Cloud Providerを利用することにより、様々なインフラ 環境を抽象化してデプロイ先として利用することがで きる – Public Cloud (AWS, Azure, GCP, Oracle…) – Kubernetes V1 / V2 – Openstack …他 • (名前がかっこいい) 継続的デリバリーツール https://www.spinnaker.io/setup/install/providers/
  53. 55.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | Spinnakerによるリソースの抽象化 様々なインフラ環境を抽象化して取り扱う https://www.spinnaker.io/concepts/ • 様々な環境のリソースを、Spinnaker のコンセプトに置き換えてマッピング して取り扱う Spinaker Kubernetes Instance Pod Server Group ReplicaSet Cluster Deployment Load Balancer Service Kubernetesオブジェクトとの対応
  54. 56.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | Spinnakerを利用したデプロイメント • インテリジェントなデプロイ方式を複数サポート – ローリング、Red/Black、カナリアリリース – 特にカナリアリリースの実現手段としての活用がよく知られている • Spinnakerによるカナリアリリース – モニタリングツールとKayentaを組み合わせて実現 – モニタリングツール: Stackdriver, Datadog, Prometheus, Signalfxにビルドインで対応。 カナリア分析のためのメトリックを提供する – Kayenta: カナリア分析のエンジン。モニタリングツールから収集したメト リックによって、カナリアの安全性を判定する(名前がかっこいい) Blue/Greenデプロイメント、カナリアリリースなどの高度なデプロイ方式をサポート
  55. 57.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | GitOpsにおけるSpinnakerの使い方 • SpinnakerをKubernetesクラスター内に構成 – 自身が乗っているクラスターに対してリソースのデプロイを行う – Single Source of Truthの変更をクラスターに反映するエージェントとして機能する • KubernetesクラスターへのSpinnakerのインストールは、標準ツールである Halyardによって、コマンドベースで実施可能 – 名前がかっこいい Kubernetes内にSpinnakerを構成してエージェントして利用 実行環境 Spinnaker 自環境に 差分を反映 (conversion) Single Source of Truth (manifest)
  56. 58.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | Demo Wercker + Helm + SpinnakerでGitOpsのCI/CDパイプラインを組んで見る
  57. 59.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | デモの構成 Single Source of Truth テンプレート 環境毎のmanifest master release 差分検出装置 Namaspace:Production build test docker push create manifest Dev Namaspace:Staging cowweb-gitops hhayakaw/cowweb
  58. 60.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | 参考文献 1/2 • Weaveworks社のブログ(GitOpsの原典) – 「GitOps」 • https://www.weave.works/technologies/gitops/ – 「GitOps - Operations by Pull Request」 • https://www.weave.works/blog/gitops-operations-by-pull-request – 「What Is GitOps Really?」 • https://www.weave.works/blog/what-is-gitops-really – 「Kubernetes anti-patterns: Let's do GitOps, not CIOps!」 • https://www.weave.works/blog/kubernetes-anti-patterns-let-s-do-gitops-not-ciops – 「GitOps - Frequently Asked Questions」 • https://www.weave.works/technologies/gitops-frequently-asked-questions/
  59. 61.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | 参考文献 2/2 • コミュニティや有志の発表資料 – 「CI/CD Pipeline を考える 〜KubeCon 2017 + CyberAgent の最大公倍数〜」 / @amsy810 • https://www.slideshare.net/masayaaoyama14/cicd-pipeline-kubecon-2017-cyberagent – 「最強のリアルタイムQA投稿アプリをCloud_Nativeに作ってみた」 / @sugimount, @hhiroshell と Cloud Native Developers JPメンバー • https://speakerdeck.com/cndjp/jkd-v18-dot-12-2w3
  60. 63.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | 最新のデータベース、コンピュート、コンテナ、IoT、ビッグ・データ、API管理、統合、チャットボット、 その他の各種クラウド・サービスを、無料で体験してみませんか? 無料トライアルのお申込方法の詳細は、QRコード、またはURLにアクセスしてください。 Oracle Cloud 最大 3,500時間の 無料トライアル oracle.co.jp/tryit_dev
  61. 64.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | アンケートにご協力をお願いいたします! http://bit.ly/ocha1survey
  62. 65.

    Copyright © 2018, Oracle and/or its affiliates. All rights reserved.

    | Safe Harbor Statement The preceding is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle.
  63. 67.