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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

| GitOpsとは

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

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

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

| 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)

| 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

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

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

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

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

| GitOpsの実践

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

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

| 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

| 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

| 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

| 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

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

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

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

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

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

| GitOpsを実現するツールの紹介

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

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

| • 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

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

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

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

| 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

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

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

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

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

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

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

| 参考文献 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/

| 参考文献 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

| お知らせとお願い

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

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

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

|

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

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

More Decks by hhiroshell

Featured

Transcript