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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

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.

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

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 新しいビジネスに対応するにはアプリケーションを高頻度で更新する必要があるペースレイヤーモデル更新頻度高更新頻度低

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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に適用

Slide 16

Slide 16 text

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クラスター

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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)

Slide 27

Slide 27 text

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)

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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はまだロゴがない

Slide 33

Slide 33 text

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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 コードをプッシュ

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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されたら環境を更新

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

Slide 46

Slide 46 text

Slide 47

Slide 47 text

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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（変更後）

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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/

Slide 55

Slide 55 text

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オブジェクトとの対応

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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)

Slide 58

Slide 58 text

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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/

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

Slide 65

Slide 65 text

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.