SlideShare a Scribd company logo
CI/CD Pipeline を考える
〜KubeCon 2017 + CyberAgent の最大公倍数〜
@市ヶ谷Geek★Night #16 Kubernetes Christmas!
青山 真也 (Masaya Aoyama)
@amsy810
普段の主な仕事↓
世界で 138 番目
https://adtech.cyberagent.io/techblog/
archives/3086
KubeCon で聞いてきた CI/CD セッション(抜粋)
Keynote
● Cloud Native CD: Spinnaker and the Culture Behind the Tech
● KubeCon Opening Keynote - Project Update
Sessions
● Using Containers for Continuous Integration and Continuous Delivery
● Deploying to Kubernetes Thousands of Times Per/Day
● Continuous Delivery with Kubernetes at Box
● Microservices, Service Mesh, and CI/CD Pipelines: Making It All Work Together
● Building Better Containers: A Survey of Container Build Tools
● GitOps - Operations by Pull Request
GitHub
k8s YAML
manifest
GitHub
Application
Code
dev
stg
prd
dev
stg
prd
リポジトリの構成
リポジトリはマイクロサービス毎に分ける
リポジトリは Code と Manifest で分割
● 厳密には同リポジトリでディレクトリを分割も可
● ただし、同居は CI/CD の際にハンドリングが不便
Manifest には実際に適用されている YAML を保存
● テンプレートだと現状のクラスタがわかりにくい
GitHub
k8s YAML
manifest
GitHub
Application
Code
dev
stg
prd
dev
stg
prd
ブランチの構成
dev, stg, prd ブランチは
・Namespace にマッピングさせる
or
・Kubernetes Cluster にマッピングさせる
ブランチの Manifest の状態 = クラスタの状態
 (マージされたタイミングで自動反映)
GitHub
k8s YAML
manifest
GitHub
Application
Code
stg
prd
stg
prd
CI/CD Pipeline の例
① Code の stg ブランチに対して PR を出してマージされる
GitHub
k8s YAML
manifest
GitHub
Application
Code
stg
prd
stg
prd
CI/CD Pipeline の例
② Code:stg のマージをきっかけに、
  Manifest を自動生成して Manifest:stg へ自動マージ
  Docker Image のビルドと Registry に Push
GitHub
k8s YAML
manifest
GitHub
Application
Code
stg
prd
stg
prd
CI/CD Pipeline の例
③ Manifest:stg ブランチへのマージ
  = stg クラスタ or NS への反映
stg クラスタの状態
prd クラスタの状態
GitHub
k8s YAML
manifest
GitHub
Application
Code
stg
prd
stg
prd
CI/CD Pipeline の例
④ Code を stg から prd にマージ
⑤ Manifest が自動生成されて Manifest:prd に PR
GitHub
k8s YAML
manifest
GitHub
Application
Code
stg
prd
stg
prd
CI/CD Pipeline の例
⑥ Manifest:prd の PR がマージされたタイミングで
 prd クラスタに反映
GitHub
k8s YAML
manifest
GitHub
Application
Code
dev
stg
prd
dev
stg
prd
CI/CD Pipeline の例
厳密には
・dev が自動マージする程度
・stg が prd 前の E2E / Performance Test の場
・prd が本番
GitHub
k8s YAML
manifest
GitHub
Application
Code
dev
stg
prd
dev
stg
prd
その他ベストプラクティス
● Entrypoint を設定してそのまま起動可能にする
● 設定は ConfigMap や Secret に寄せる
○ 設定は Env や ConfigMap で渡すだけ
● 脱 Dockerfile
○ 別のツールで生成しましょう
● local / dev / prd で同じイメージを利用する
● Commit と Image Tag を紐付ける
○ ロールバックを容易に
● Manifest の Validation を行なう
○ K8s のリソース文法的、意図的内容
GitHub
k8s YAML
manifest
GitHub
Application
Code
dev
stg
prd
dev
stg
prd
その他ベストプラクティス
● latest タグは使わない
● local でビルドして push はしない(自動化必須)
● kubectl は基本的に使わない
● Replica 数は Manifest YAML に書かない
○ Scale は Manifest で行わない
● テスト等も行いマージしやすい仕組みづくり
○ Performance Test, E2E
その他印象に残っている話
Spinnaker のロードマップ
● CI にも力を入れていく
● CD 定義をコード化可能に
● デプロイ定義の抽象化
Canary Release の一方法
● PR が出たら Canary リリース
● マージされたら Deploy
is coming soon...
来年はココらへんの話で発表したい!
「GKE 互換のオンプレコンテナ基盤 AKE (Adtech Container Engine)」
https://developers.cyberagent.co.jp/blog/archives/12058/
「Kubernetes をいじって Hardware LoadBalancer で “type LoadBalancer” を実装」
https://adtech.cyberagent.io/techblog/archives/3127
「オンプレでも GKE Like な Ingress を使うために 自作 Ingress Controller を実装」
https://adtech.cyberagent.io/techblog/archives/3758
参考付録
4: Cloud Native CD: Spinnaker and the Culture Behind the Tech
Netflix の Spinnaker が出来るまでのテクノロジーの歴史
● 時間区切りで Deploy タイミングを指定する Time Window
● トラフィックガード機能
● Canary / Blue-Green デプロイ
● Manual Judgement によるデプロイ判断のフロー
● 今後の展望
○ CI
○ Declartive CD (恐らく 宣言的コードによる CD の設定化)
○ デプロイ方法の詳細を抽象化して提供
9: KubeCon Opening Keynote - Project Update
1. アプリケーションコードの変更
a. git clone HOGE;
b. git checkout -b funcA;
c. vi test.java;
d. git push origin funcA
e. PR を出す
f. Merge する(Dev 環境へ反映)
g. Docker Image の build
h. Registry への upload
i. リリース Tag を打つ
2. Kubernetes クラスタへの反映
a. 上記で Tag を打ったことで、Kubernetes Manifest YAML が生成されてPR が自動で出される
b. マージするとapply される(本番適用)
GitHub
k8s YAML
manifest
GitHub
Application
Code
9: KubeCon Opening Keynote - Project Update
アプリケーション開発者は CI/CD Pipeline を確立し、kubectl を使う必要はない
 = kubectl は ssh と同等(kubectl exec -it SOMETHING /bin/sh)
Replica 数は Kubernetes Manifest YAML には書かない
Using Containers for Continuous Integration and Continuous Delivery
Jenkins のスケーリング手法
● 1 Master に Agent を沢山ぶら下げる
○ Master が SPOF
○ Agent の管理が必要
○ エージェント数に限界がある
● 複数 Master を用意する
○ SSO
○ 共通設定や管理の集中化を考える必要がある
結構しんどい。
Using Containers for Continuous Integration and Continuous Delivery
Using Containers for Continuous Integration and Continuous Delivery
podTemplate(label: 'mypod') {
node('mypod') {
sh 'Hello world!'
}
}
build task をコンテナとして起動
Groovy で記述可能
PodTemplate と同等の表現力
https://github.com/jenkinsci/kubernetes-plugin
Deploying to Kubernetes Thousands of Times Per/Day
Kubernetes を使って High Velocity を実現しましょう!
 ※ 変更から反映までの間隔を出来るだけ短くすること
Deploying to Kubernetes Thousands of Times Per/Day
1.Image First
● Immutable なコンテナにする
● Entrypoint を設定してそのまま起動できるようにする
● local / dev / prd で同じイメージを利用する
● latest タグは使わない
● GitHub の特定のコミットと Image Tag を紐付けておく
● local でビルドして push はしない(自動化必須)
Deploying to Kubernetes Thousands of Times Per/Day
2.Shift Left
テストは出来るだけ前倒ししましょう
Bottleneck
Deploying to Kubernetes Thousands of Times Per/Day
3.Maintain Application Portability
クラスタが消し飛んだときに復旧できますか? (会場では x hour ~ x day の声)
ちゃんと移動出来るようにメンテナンスはし続けて下さい
● 設定ファイルはコンテナイメージに内包せず ConfigMap / Secret を使う
○ Docker Build は出来るだけ避ける
○ 環境変化に強い設計にする
● Helm Charts 化も検討しましょう
● ディザスタリカバリのテストもしましょう
Deploying to Kubernetes Thousands of Times Per/Day
4.Outsource Cluster Management
● クラスタの管理は専門チームに任せる
● スケーラビリティや冗長化の計画を持っておく
● Certified Kubernetes Conformance Program に準拠した構成にしましょう
Deploying to Kubernetes Thousands of Times Per/Day
CodeFresh
 Kubernetes に特化した Spinnaker + CircleCI + DockerHub のようなもの
● Github のコード変更
● Docker Image の作成
● Deployment の Config や Helm Charts を生成
● (Performance Test)
● Kubernetes クラスタにデプロイ
Deploying to Kubernetes Thousands of Times Per/Day
Continuous Delivery with Kubernetes at Box
Kubernetes Cluster の状態 = Github になるように構築
Docker Build 時に YAML を自動生成して manifest Github に PR をする方式
(このセッション?)
Kubernetes
Cluster
GitHub
k8s YAML
manifest=
Continuous Delivery with Kubernetes at Box
Kubernetes クラスタに Agent を仕込んでおく
 クラスタの状態となる Github を設定
エージェントが Github を監視して反映
障害時にも Agent を入れるだけで復旧可能
Kubernetes
Cluster
GitHub
k8s YAML
manifest=
Microservices, Service Mesh, and CI/CD Pipelines: Making It All Work Together
Istio + BRIGADE + kashti (WebUI) を使った ServiceMesh + CI/CD 環境
Istio を使うことで
● トラフィックコントロール
○ Canary リリース
● Chaos テストのために Fault injection(遅延やドロップ)
○ 障害試験
● メトリクスのスコアリング
○ パフォーマンス低下の検知
○ 複雑な ServiceMesh 内でのパフォーマンスチェック
Microservices, Service Mesh, and CI/CD Pipelines: Making It All Work Together
Istio + BRIGADE + kashti (WebUI) を使った ServiceMesh + CI/CD 環境
BRIGADE を使うことで
● Event driven な CI/CD Pipeline
○ DockerHub の変更を検知
○ Github の変更を検知
● JavaScript による Pipeline 定義
○ コード化が可能
● 全てを網羅
○ Go binary の作成、Docker Image の作成、Helm Charts の作成、Slack 通知
events.on("exec", () => {
var job = new Job("test", "alpine:3.4")
job.tasks = [
"echo Hello",
"echo World"
]
job.run()
})
Microservices, Service Mesh, and CI/CD Pipelines: Making It All Work Together
あとこのセッションでちょっと納得したのは
● PR で Canary リリース
● Merge で正式リリース
というのは良さそうだなと思いました
Building Better Containers: A Survey of Container Build Tools
現状の Dockerfile の問題
● イメージの再現性が乏しい
● Bash での Programmability
● イメージフォーマット間での連携が弱い
Dockerfile 使ってコンテナイメージ作る時代はきっと終わるよ!
[ソースからイメージビルド]
source-to-image (s2i)
buildkit
habitat
詳しくは凄い量になるので、
付録の SpreadSheet で。
[従来方式]
buildah
nixos-container
ansible-container
smith
(distroless)
GitOps - Operations by Pull Request
GitOps の 3 つの法則
● システム全体が正常に稼働する状態を Git で管理する
● 実際の状態と Git の状態(想定する状態)の差分を比較してアラート発行
● 全ての変更操作は PR 経由で実行する
GitOps - Operations by Pull Request
GitOps の 3 つの柱
● Pipeline
● Observility
● Controll
GitOps - Operations by Pull Request
Pipeline
● 1 Repository は 1 app / service で構成
● ブランチは prd / stg / dev などで切る
● ブランチは Namespace か Cluster にマップさせる
● stg に展開するときは stg ブランチにマージしたら自動で行われる
● ブランチはプロテクトしてレビューを必須にする
GitOps - Operations by Pull Request
GitOps - Operations by Pull Request
Observility
メトリクス等を駆使して PR をマージしていいかを判断する
レスポンスタイムが 100ms 以下かどうか等
Controll
すべては Git を介して行い Kuberentes を直接操作しない
Developer Tooling for Kubernetes Configuration
Validation(kubeval)
● Manifest YAML のフォーマットが正しいかどうか
Unit Test(kubetest)
● podSpec のチェック
● label 設定のチェック
● 特権コンテナを使っていないかのチェック
● etc…
jsonnet や helm charts などでもテスト可能

More Related Content

What's hot

Recap: [Code fresh] Deploying to kubernetes thousands of times per day @kuber...
Recap: [Code fresh] Deploying to kubernetes thousands of times per day @kuber...Recap: [Code fresh] Deploying to kubernetes thousands of times per day @kuber...
Recap: [Code fresh] Deploying to kubernetes thousands of times per day @kuber...
Masaya Aoyama
 
Kubernetesと暮らすRancherな生活
Kubernetesと暮らすRancherな生活Kubernetesと暮らすRancherな生活
Kubernetesと暮らすRancherな生活
Go Chiba
 
Jenkins x Kubernetesが簡単だと思ったら大変だった話
Jenkins x Kubernetesが簡単だと思ったら大変だった話Jenkins x Kubernetesが簡単だと思ったら大変だった話
Jenkins x Kubernetesが簡単だと思ったら大変だった話
Masaki Yamamoto
 
kubernetes初心者がKnative Lambda Runtime触ってみた(Kubernetes Novice Tokyo #13 発表資料)
kubernetes初心者がKnative Lambda Runtime触ってみた(Kubernetes Novice Tokyo #13 発表資料)kubernetes初心者がKnative Lambda Runtime触ってみた(Kubernetes Novice Tokyo #13 発表資料)
kubernetes初心者がKnative Lambda Runtime触ってみた(Kubernetes Novice Tokyo #13 発表資料)
NTT DATA Technology & Innovation
 
Wordpress案件にgkeを採用してみた(短縮版)
Wordpress案件にgkeを採用してみた(短縮版)Wordpress案件にgkeを採用してみた(短縮版)
Wordpress案件にgkeを採用してみた(短縮版)
Yu Amano
 
Introduction to Magnum (JP)
Introduction to Magnum (JP)Introduction to Magnum (JP)
Introduction to Magnum (JP)
Motohiro OTSUKA
 
20分でわかるgVisor入門
20分でわかるgVisor入門20分でわかるgVisor入門
20分でわかるgVisor入門
Shuji Yamada
 
小規模でもGKE - DevFest Tokyo 2016
小規模でもGKE - DevFest Tokyo 2016小規模でもGKE - DevFest Tokyo 2016
小規模でもGKE - DevFest Tokyo 2016
lestrrat
 
Githubを使って簡単に helm repoを公開してみよう
Githubを使って簡単に helm repoを公開してみようGithubを使って簡単に helm repoを公開してみよう
Githubを使って簡単に helm repoを公開してみよう
Shingo Omura
 
DockerMeetup#26 LT: Alibaba Cloudのコンテナ関連についてちょっとだけ
DockerMeetup#26 LT: Alibaba Cloudのコンテナ関連についてちょっとだけDockerMeetup#26 LT: Alibaba Cloudのコンテナ関連についてちょっとだけ
DockerMeetup#26 LT: Alibaba Cloudのコンテナ関連についてちょっとだけ
Shinya Mori (@mosuke5)
 
Google Container Engine (GKE) & Kubernetes のアーキテクチャ解説
Google Container Engine (GKE) & Kubernetes のアーキテクチャ解説Google Container Engine (GKE) & Kubernetes のアーキテクチャ解説
Google Container Engine (GKE) & Kubernetes のアーキテクチャ解説
Samir Hammoudi
 
Magnum - A new OpenStack API for Containers -
Magnum - A new OpenStack API for Containers -Magnum - A new OpenStack API for Containers -
Magnum - A new OpenStack API for Containers -
Takehiro Kaneko
 
Clovaにおける機械学習モジュールの配信&運用基盤の紹介
Clovaにおける機械学習モジュールの配信&運用基盤の紹介Clovaにおける機械学習モジュールの配信&運用基盤の紹介
Clovaにおける機械学習モジュールの配信&運用基盤の紹介
LINE Corporation
 
kubernetes(GKE)環境におけるdatadog利用
kubernetes(GKE)環境におけるdatadog利用kubernetes(GKE)環境におけるdatadog利用
kubernetes(GKE)環境におけるdatadog利用
Koichi HARUNA
 
[External] 2021.12.15 コンテナ移行の前に知っておきたいこと @ gcpug 湘南
[External] 2021.12.15 コンテナ移行の前に知っておきたいこと  @ gcpug 湘南[External] 2021.12.15 コンテナ移行の前に知っておきたいこと  @ gcpug 湘南
[External] 2021.12.15 コンテナ移行の前に知っておきたいこと @ gcpug 湘南
Google Cloud Platform - Japan
 
Rancher2.0で実現する Managed Kubernetes Service
Rancher2.0で実現する Managed Kubernetes ServiceRancher2.0で実現する Managed Kubernetes Service
Rancher2.0で実現する Managed Kubernetes Service
LINE Corporation
 
20220302_TechDojo_OpenShift_BootCamp_1章概要
20220302_TechDojo_OpenShift_BootCamp_1章概要20220302_TechDojo_OpenShift_BootCamp_1章概要
20220302_TechDojo_OpenShift_BootCamp_1章概要
Airi Furukawa
 
新しいOpenShiftのしくみを調べてみた
新しいOpenShiftのしくみを調べてみた新しいOpenShiftのしくみを調べてみた
新しいOpenShiftのしくみを調べてみた
Kazuto Kusama
 
DockerCon '17 Feedback at PaaS JP
DockerCon '17 Feedback at PaaS JPDockerCon '17 Feedback at PaaS JP
DockerCon '17 Feedback at PaaS JP
Go Chiba
 
Kubernete Meetup Tokyo #18 - Kubebuilder/controller-runtime 入門
Kubernete Meetup Tokyo #18 - Kubebuilder/controller-runtime 入門Kubernete Meetup Tokyo #18 - Kubebuilder/controller-runtime 入門
Kubernete Meetup Tokyo #18 - Kubebuilder/controller-runtime 入門
Preferred Networks
 

What's hot (20)

Recap: [Code fresh] Deploying to kubernetes thousands of times per day @kuber...
Recap: [Code fresh] Deploying to kubernetes thousands of times per day @kuber...Recap: [Code fresh] Deploying to kubernetes thousands of times per day @kuber...
Recap: [Code fresh] Deploying to kubernetes thousands of times per day @kuber...
 
Kubernetesと暮らすRancherな生活
Kubernetesと暮らすRancherな生活Kubernetesと暮らすRancherな生活
Kubernetesと暮らすRancherな生活
 
Jenkins x Kubernetesが簡単だと思ったら大変だった話
Jenkins x Kubernetesが簡単だと思ったら大変だった話Jenkins x Kubernetesが簡単だと思ったら大変だった話
Jenkins x Kubernetesが簡単だと思ったら大変だった話
 
kubernetes初心者がKnative Lambda Runtime触ってみた(Kubernetes Novice Tokyo #13 発表資料)
kubernetes初心者がKnative Lambda Runtime触ってみた(Kubernetes Novice Tokyo #13 発表資料)kubernetes初心者がKnative Lambda Runtime触ってみた(Kubernetes Novice Tokyo #13 発表資料)
kubernetes初心者がKnative Lambda Runtime触ってみた(Kubernetes Novice Tokyo #13 発表資料)
 
Wordpress案件にgkeを採用してみた(短縮版)
Wordpress案件にgkeを採用してみた(短縮版)Wordpress案件にgkeを採用してみた(短縮版)
Wordpress案件にgkeを採用してみた(短縮版)
 
Introduction to Magnum (JP)
Introduction to Magnum (JP)Introduction to Magnum (JP)
Introduction to Magnum (JP)
 
20分でわかるgVisor入門
20分でわかるgVisor入門20分でわかるgVisor入門
20分でわかるgVisor入門
 
小規模でもGKE - DevFest Tokyo 2016
小規模でもGKE - DevFest Tokyo 2016小規模でもGKE - DevFest Tokyo 2016
小規模でもGKE - DevFest Tokyo 2016
 
Githubを使って簡単に helm repoを公開してみよう
Githubを使って簡単に helm repoを公開してみようGithubを使って簡単に helm repoを公開してみよう
Githubを使って簡単に helm repoを公開してみよう
 
DockerMeetup#26 LT: Alibaba Cloudのコンテナ関連についてちょっとだけ
DockerMeetup#26 LT: Alibaba Cloudのコンテナ関連についてちょっとだけDockerMeetup#26 LT: Alibaba Cloudのコンテナ関連についてちょっとだけ
DockerMeetup#26 LT: Alibaba Cloudのコンテナ関連についてちょっとだけ
 
Google Container Engine (GKE) & Kubernetes のアーキテクチャ解説
Google Container Engine (GKE) & Kubernetes のアーキテクチャ解説Google Container Engine (GKE) & Kubernetes のアーキテクチャ解説
Google Container Engine (GKE) & Kubernetes のアーキテクチャ解説
 
Magnum - A new OpenStack API for Containers -
Magnum - A new OpenStack API for Containers -Magnum - A new OpenStack API for Containers -
Magnum - A new OpenStack API for Containers -
 
Clovaにおける機械学習モジュールの配信&運用基盤の紹介
Clovaにおける機械学習モジュールの配信&運用基盤の紹介Clovaにおける機械学習モジュールの配信&運用基盤の紹介
Clovaにおける機械学習モジュールの配信&運用基盤の紹介
 
kubernetes(GKE)環境におけるdatadog利用
kubernetes(GKE)環境におけるdatadog利用kubernetes(GKE)環境におけるdatadog利用
kubernetes(GKE)環境におけるdatadog利用
 
[External] 2021.12.15 コンテナ移行の前に知っておきたいこと @ gcpug 湘南
[External] 2021.12.15 コンテナ移行の前に知っておきたいこと  @ gcpug 湘南[External] 2021.12.15 コンテナ移行の前に知っておきたいこと  @ gcpug 湘南
[External] 2021.12.15 コンテナ移行の前に知っておきたいこと @ gcpug 湘南
 
Rancher2.0で実現する Managed Kubernetes Service
Rancher2.0で実現する Managed Kubernetes ServiceRancher2.0で実現する Managed Kubernetes Service
Rancher2.0で実現する Managed Kubernetes Service
 
20220302_TechDojo_OpenShift_BootCamp_1章概要
20220302_TechDojo_OpenShift_BootCamp_1章概要20220302_TechDojo_OpenShift_BootCamp_1章概要
20220302_TechDojo_OpenShift_BootCamp_1章概要
 
新しいOpenShiftのしくみを調べてみた
新しいOpenShiftのしくみを調べてみた新しいOpenShiftのしくみを調べてみた
新しいOpenShiftのしくみを調べてみた
 
DockerCon '17 Feedback at PaaS JP
DockerCon '17 Feedback at PaaS JPDockerCon '17 Feedback at PaaS JP
DockerCon '17 Feedback at PaaS JP
 
Kubernete Meetup Tokyo #18 - Kubebuilder/controller-runtime 入門
Kubernete Meetup Tokyo #18 - Kubebuilder/controller-runtime 入門Kubernete Meetup Tokyo #18 - Kubebuilder/controller-runtime 入門
Kubernete Meetup Tokyo #18 - Kubebuilder/controller-runtime 入門
 

Similar to CI/CD Pipeline を考える 〜KubeCon 2017 + CyberAgent の最大公倍数〜

Recap: Modern CI/CD with Tekton and Prow Automated via Jenkins X - Kubernetes...
Recap: Modern CI/CD with Tekton and Prow Automated via Jenkins X - Kubernetes...Recap: Modern CI/CD with Tekton and Prow Automated via Jenkins X - Kubernetes...
Recap: Modern CI/CD with Tekton and Prow Automated via Jenkins X - Kubernetes...
JUNICHI YOSHISE
 
BuildKitの概要と最近の機能
BuildKitの概要と最近の機能BuildKitの概要と最近の機能
BuildKitの概要と最近の機能
Kohei Tokunaga
 
はてなにおける継続的デプロイメントの現状と Docker の導入
はてなにおける継続的デプロイメントの現状と Docker の導入はてなにおける継続的デプロイメントの現状と Docker の導入
はてなにおける継続的デプロイメントの現状と Docker の導入
Yu Nobuoka
 
SpringOne Platform Replay -Pivotal Cloud Foundry-
SpringOne Platform Replay -Pivotal Cloud Foundry-SpringOne Platform Replay -Pivotal Cloud Foundry-
SpringOne Platform Replay -Pivotal Cloud Foundry-
CASAREAL, Inc.
 
Kubernetes Meetup Tokyo #23 kubebuilder-v2
Kubernetes Meetup Tokyo #23 kubebuilder-v2Kubernetes Meetup Tokyo #23 kubebuilder-v2
Kubernetes Meetup Tokyo #23 kubebuilder-v2
Kazuhito Matsuda
 
Infra: Kubernetes and GKE, Network
Infra: Kubernetes and GKE, NetworkInfra: Kubernetes and GKE, Network
Infra: Kubernetes and GKE, Network
Kuma Arakawa
 
Kubernetes 基盤における非機能試験の deepdive(Kubernetes Novice Tokyo #17 発表資料)
Kubernetes 基盤における非機能試験の deepdive(Kubernetes Novice Tokyo #17 発表資料)Kubernetes 基盤における非機能試験の deepdive(Kubernetes Novice Tokyo #17 発表資料)
Kubernetes 基盤における非機能試験の deepdive(Kubernetes Novice Tokyo #17 発表資料)
NTT DATA Technology & Innovation
 
[GKE & Spanner 勉強会] GKE 入門
[GKE & Spanner 勉強会] GKE 入門[GKE & Spanner 勉強会] GKE 入門
[GKE & Spanner 勉強会] GKE 入門
Google Cloud Platform - Japan
 
Docker入門-基礎編 いまから始めるDocker管理【2nd Edition】
Docker入門-基礎編 いまから始めるDocker管理【2nd Edition】Docker入門-基礎編 いまから始めるDocker管理【2nd Edition】
Docker入門-基礎編 いまから始めるDocker管理【2nd Edition】
Masahito Zembutsu
 
20130329 rtm4
20130329 rtm420130329 rtm4
20130329 rtm4
openrtm
 
130329 04
130329 04130329 04
130329 04
openrtm
 
Container Storage Interface のすべて
Container Storage Interface のすべてContainer Storage Interface のすべて
Container Storage Interface のすべて
祐司 伊藤
 
Kubernetes Operator for vSphere VM
Kubernetes Operator for vSphere VMKubernetes Operator for vSphere VM
Kubernetes Operator for vSphere VM
Masanori Nara
 
今だからこそ知りたい Docker Compose/Swarm 入門
今だからこそ知りたい Docker Compose/Swarm 入門今だからこそ知りたい Docker Compose/Swarm 入門
今だからこそ知りたい Docker Compose/Swarm 入門
Masahito Zembutsu
 
OpenShiftでJBoss EAP構築
OpenShiftでJBoss EAP構築OpenShiftでJBoss EAP構築
OpenShiftでJBoss EAP構築
Daein Park
 
20170311 Developing & Deploying .NET Core on Linux
20170311 Developing & Deploying .NET Core on Linux20170311 Developing & Deploying .NET Core on Linux
20170311 Developing & Deploying .NET Core on Linux
Takayoshi Tanaka
 
Japan Container Day 2018
Japan Container Day 2018Japan Container Day 2018
Japan Container Day 2018
Yoshio Terada
 
VSCodeで始めるAzure Static Web Apps開発
VSCodeで始めるAzure Static Web Apps開発VSCodeで始めるAzure Static Web Apps開発
VSCodeで始めるAzure Static Web Apps開発
Yuta Matsumura
 
GKEで半年運用してみた
GKEで半年運用してみたGKEで半年運用してみた
GKEで半年運用してみた
Katsutoshi Nagaoka
 
Kubernetes Meetup Tokyo #8 Self-hosted Kubernetes を調べてみた
Kubernetes Meetup Tokyo #8 Self-hosted Kubernetes を調べてみたKubernetes Meetup Tokyo #8 Self-hosted Kubernetes を調べてみた
Kubernetes Meetup Tokyo #8 Self-hosted Kubernetes を調べてみた
Akihito Inoh
 

Similar to CI/CD Pipeline を考える 〜KubeCon 2017 + CyberAgent の最大公倍数〜 (20)

Recap: Modern CI/CD with Tekton and Prow Automated via Jenkins X - Kubernetes...
Recap: Modern CI/CD with Tekton and Prow Automated via Jenkins X - Kubernetes...Recap: Modern CI/CD with Tekton and Prow Automated via Jenkins X - Kubernetes...
Recap: Modern CI/CD with Tekton and Prow Automated via Jenkins X - Kubernetes...
 
BuildKitの概要と最近の機能
BuildKitの概要と最近の機能BuildKitの概要と最近の機能
BuildKitの概要と最近の機能
 
はてなにおける継続的デプロイメントの現状と Docker の導入
はてなにおける継続的デプロイメントの現状と Docker の導入はてなにおける継続的デプロイメントの現状と Docker の導入
はてなにおける継続的デプロイメントの現状と Docker の導入
 
SpringOne Platform Replay -Pivotal Cloud Foundry-
SpringOne Platform Replay -Pivotal Cloud Foundry-SpringOne Platform Replay -Pivotal Cloud Foundry-
SpringOne Platform Replay -Pivotal Cloud Foundry-
 
Kubernetes Meetup Tokyo #23 kubebuilder-v2
Kubernetes Meetup Tokyo #23 kubebuilder-v2Kubernetes Meetup Tokyo #23 kubebuilder-v2
Kubernetes Meetup Tokyo #23 kubebuilder-v2
 
Infra: Kubernetes and GKE, Network
Infra: Kubernetes and GKE, NetworkInfra: Kubernetes and GKE, Network
Infra: Kubernetes and GKE, Network
 
Kubernetes 基盤における非機能試験の deepdive(Kubernetes Novice Tokyo #17 発表資料)
Kubernetes 基盤における非機能試験の deepdive(Kubernetes Novice Tokyo #17 発表資料)Kubernetes 基盤における非機能試験の deepdive(Kubernetes Novice Tokyo #17 発表資料)
Kubernetes 基盤における非機能試験の deepdive(Kubernetes Novice Tokyo #17 発表資料)
 
[GKE & Spanner 勉強会] GKE 入門
[GKE & Spanner 勉強会] GKE 入門[GKE & Spanner 勉強会] GKE 入門
[GKE & Spanner 勉強会] GKE 入門
 
Docker入門-基礎編 いまから始めるDocker管理【2nd Edition】
Docker入門-基礎編 いまから始めるDocker管理【2nd Edition】Docker入門-基礎編 いまから始めるDocker管理【2nd Edition】
Docker入門-基礎編 いまから始めるDocker管理【2nd Edition】
 
20130329 rtm4
20130329 rtm420130329 rtm4
20130329 rtm4
 
130329 04
130329 04130329 04
130329 04
 
Container Storage Interface のすべて
Container Storage Interface のすべてContainer Storage Interface のすべて
Container Storage Interface のすべて
 
Kubernetes Operator for vSphere VM
Kubernetes Operator for vSphere VMKubernetes Operator for vSphere VM
Kubernetes Operator for vSphere VM
 
今だからこそ知りたい Docker Compose/Swarm 入門
今だからこそ知りたい Docker Compose/Swarm 入門今だからこそ知りたい Docker Compose/Swarm 入門
今だからこそ知りたい Docker Compose/Swarm 入門
 
OpenShiftでJBoss EAP構築
OpenShiftでJBoss EAP構築OpenShiftでJBoss EAP構築
OpenShiftでJBoss EAP構築
 
20170311 Developing & Deploying .NET Core on Linux
20170311 Developing & Deploying .NET Core on Linux20170311 Developing & Deploying .NET Core on Linux
20170311 Developing & Deploying .NET Core on Linux
 
Japan Container Day 2018
Japan Container Day 2018Japan Container Day 2018
Japan Container Day 2018
 
VSCodeで始めるAzure Static Web Apps開発
VSCodeで始めるAzure Static Web Apps開発VSCodeで始めるAzure Static Web Apps開発
VSCodeで始めるAzure Static Web Apps開発
 
GKEで半年運用してみた
GKEで半年運用してみたGKEで半年運用してみた
GKEで半年運用してみた
 
Kubernetes Meetup Tokyo #8 Self-hosted Kubernetes を調べてみた
Kubernetes Meetup Tokyo #8 Self-hosted Kubernetes を調べてみたKubernetes Meetup Tokyo #8 Self-hosted Kubernetes を調べてみた
Kubernetes Meetup Tokyo #8 Self-hosted Kubernetes を調べてみた
 

CI/CD Pipeline を考える 〜KubeCon 2017 + CyberAgent の最大公倍数〜

  • 1. CI/CD Pipeline を考える 〜KubeCon 2017 + CyberAgent の最大公倍数〜 @市ヶ谷Geek★Night #16 Kubernetes Christmas!
  • 2. 青山 真也 (Masaya Aoyama) @amsy810 普段の主な仕事↓ 世界で 138 番目 https://adtech.cyberagent.io/techblog/ archives/3086
  • 3. KubeCon で聞いてきた CI/CD セッション(抜粋) Keynote ● Cloud Native CD: Spinnaker and the Culture Behind the Tech ● KubeCon Opening Keynote - Project Update Sessions ● Using Containers for Continuous Integration and Continuous Delivery ● Deploying to Kubernetes Thousands of Times Per/Day ● Continuous Delivery with Kubernetes at Box ● Microservices, Service Mesh, and CI/CD Pipelines: Making It All Work Together ● Building Better Containers: A Survey of Container Build Tools ● GitOps - Operations by Pull Request
  • 4. GitHub k8s YAML manifest GitHub Application Code dev stg prd dev stg prd リポジトリの構成 リポジトリはマイクロサービス毎に分ける リポジトリは Code と Manifest で分割 ● 厳密には同リポジトリでディレクトリを分割も可 ● ただし、同居は CI/CD の際にハンドリングが不便 Manifest には実際に適用されている YAML を保存 ● テンプレートだと現状のクラスタがわかりにくい
  • 5. GitHub k8s YAML manifest GitHub Application Code dev stg prd dev stg prd ブランチの構成 dev, stg, prd ブランチは ・Namespace にマッピングさせる or ・Kubernetes Cluster にマッピングさせる ブランチの Manifest の状態 = クラスタの状態  (マージされたタイミングで自動反映)
  • 6. GitHub k8s YAML manifest GitHub Application Code stg prd stg prd CI/CD Pipeline の例 ① Code の stg ブランチに対して PR を出してマージされる
  • 7. GitHub k8s YAML manifest GitHub Application Code stg prd stg prd CI/CD Pipeline の例 ② Code:stg のマージをきっかけに、   Manifest を自動生成して Manifest:stg へ自動マージ   Docker Image のビルドと Registry に Push
  • 8. GitHub k8s YAML manifest GitHub Application Code stg prd stg prd CI/CD Pipeline の例 ③ Manifest:stg ブランチへのマージ   = stg クラスタ or NS への反映 stg クラスタの状態 prd クラスタの状態
  • 9. GitHub k8s YAML manifest GitHub Application Code stg prd stg prd CI/CD Pipeline の例 ④ Code を stg から prd にマージ ⑤ Manifest が自動生成されて Manifest:prd に PR
  • 10. GitHub k8s YAML manifest GitHub Application Code stg prd stg prd CI/CD Pipeline の例 ⑥ Manifest:prd の PR がマージされたタイミングで  prd クラスタに反映
  • 11. GitHub k8s YAML manifest GitHub Application Code dev stg prd dev stg prd CI/CD Pipeline の例 厳密には ・dev が自動マージする程度 ・stg が prd 前の E2E / Performance Test の場 ・prd が本番
  • 12. GitHub k8s YAML manifest GitHub Application Code dev stg prd dev stg prd その他ベストプラクティス ● Entrypoint を設定してそのまま起動可能にする ● 設定は ConfigMap や Secret に寄せる ○ 設定は Env や ConfigMap で渡すだけ ● 脱 Dockerfile ○ 別のツールで生成しましょう ● local / dev / prd で同じイメージを利用する ● Commit と Image Tag を紐付ける ○ ロールバックを容易に ● Manifest の Validation を行なう ○ K8s のリソース文法的、意図的内容
  • 13. GitHub k8s YAML manifest GitHub Application Code dev stg prd dev stg prd その他ベストプラクティス ● latest タグは使わない ● local でビルドして push はしない(自動化必須) ● kubectl は基本的に使わない ● Replica 数は Manifest YAML に書かない ○ Scale は Manifest で行わない ● テスト等も行いマージしやすい仕組みづくり ○ Performance Test, E2E
  • 14. その他印象に残っている話 Spinnaker のロードマップ ● CI にも力を入れていく ● CD 定義をコード化可能に ● デプロイ定義の抽象化 Canary Release の一方法 ● PR が出たら Canary リリース ● マージされたら Deploy
  • 15. is coming soon... 来年はココらへんの話で発表したい! 「GKE 互換のオンプレコンテナ基盤 AKE (Adtech Container Engine)」 https://developers.cyberagent.co.jp/blog/archives/12058/ 「Kubernetes をいじって Hardware LoadBalancer で “type LoadBalancer” を実装」 https://adtech.cyberagent.io/techblog/archives/3127 「オンプレでも GKE Like な Ingress を使うために 自作 Ingress Controller を実装」 https://adtech.cyberagent.io/techblog/archives/3758
  • 17. 4: Cloud Native CD: Spinnaker and the Culture Behind the Tech Netflix の Spinnaker が出来るまでのテクノロジーの歴史 ● 時間区切りで Deploy タイミングを指定する Time Window ● トラフィックガード機能 ● Canary / Blue-Green デプロイ ● Manual Judgement によるデプロイ判断のフロー ● 今後の展望 ○ CI ○ Declartive CD (恐らく 宣言的コードによる CD の設定化) ○ デプロイ方法の詳細を抽象化して提供
  • 18. 9: KubeCon Opening Keynote - Project Update 1. アプリケーションコードの変更 a. git clone HOGE; b. git checkout -b funcA; c. vi test.java; d. git push origin funcA e. PR を出す f. Merge する(Dev 環境へ反映) g. Docker Image の build h. Registry への upload i. リリース Tag を打つ 2. Kubernetes クラスタへの反映 a. 上記で Tag を打ったことで、Kubernetes Manifest YAML が生成されてPR が自動で出される b. マージするとapply される(本番適用) GitHub k8s YAML manifest GitHub Application Code
  • 19. 9: KubeCon Opening Keynote - Project Update アプリケーション開発者は CI/CD Pipeline を確立し、kubectl を使う必要はない  = kubectl は ssh と同等(kubectl exec -it SOMETHING /bin/sh) Replica 数は Kubernetes Manifest YAML には書かない
  • 20. Using Containers for Continuous Integration and Continuous Delivery Jenkins のスケーリング手法 ● 1 Master に Agent を沢山ぶら下げる ○ Master が SPOF ○ Agent の管理が必要 ○ エージェント数に限界がある ● 複数 Master を用意する ○ SSO ○ 共通設定や管理の集中化を考える必要がある 結構しんどい。
  • 21. Using Containers for Continuous Integration and Continuous Delivery
  • 22. Using Containers for Continuous Integration and Continuous Delivery podTemplate(label: 'mypod') { node('mypod') { sh 'Hello world!' } } build task をコンテナとして起動 Groovy で記述可能 PodTemplate と同等の表現力 https://github.com/jenkinsci/kubernetes-plugin
  • 23. Deploying to Kubernetes Thousands of Times Per/Day Kubernetes を使って High Velocity を実現しましょう!  ※ 変更から反映までの間隔を出来るだけ短くすること
  • 24. Deploying to Kubernetes Thousands of Times Per/Day 1.Image First ● Immutable なコンテナにする ● Entrypoint を設定してそのまま起動できるようにする ● local / dev / prd で同じイメージを利用する ● latest タグは使わない ● GitHub の特定のコミットと Image Tag を紐付けておく ● local でビルドして push はしない(自動化必須)
  • 25. Deploying to Kubernetes Thousands of Times Per/Day 2.Shift Left テストは出来るだけ前倒ししましょう Bottleneck
  • 26. Deploying to Kubernetes Thousands of Times Per/Day 3.Maintain Application Portability クラスタが消し飛んだときに復旧できますか? (会場では x hour ~ x day の声) ちゃんと移動出来るようにメンテナンスはし続けて下さい ● 設定ファイルはコンテナイメージに内包せず ConfigMap / Secret を使う ○ Docker Build は出来るだけ避ける ○ 環境変化に強い設計にする ● Helm Charts 化も検討しましょう ● ディザスタリカバリのテストもしましょう
  • 27. Deploying to Kubernetes Thousands of Times Per/Day 4.Outsource Cluster Management ● クラスタの管理は専門チームに任せる ● スケーラビリティや冗長化の計画を持っておく ● Certified Kubernetes Conformance Program に準拠した構成にしましょう
  • 28. Deploying to Kubernetes Thousands of Times Per/Day CodeFresh  Kubernetes に特化した Spinnaker + CircleCI + DockerHub のようなもの ● Github のコード変更 ● Docker Image の作成 ● Deployment の Config や Helm Charts を生成 ● (Performance Test) ● Kubernetes クラスタにデプロイ
  • 29. Deploying to Kubernetes Thousands of Times Per/Day
  • 30. Continuous Delivery with Kubernetes at Box Kubernetes Cluster の状態 = Github になるように構築 Docker Build 時に YAML を自動生成して manifest Github に PR をする方式 (このセッション?) Kubernetes Cluster GitHub k8s YAML manifest=
  • 31. Continuous Delivery with Kubernetes at Box Kubernetes クラスタに Agent を仕込んでおく  クラスタの状態となる Github を設定 エージェントが Github を監視して反映 障害時にも Agent を入れるだけで復旧可能 Kubernetes Cluster GitHub k8s YAML manifest=
  • 32. Microservices, Service Mesh, and CI/CD Pipelines: Making It All Work Together Istio + BRIGADE + kashti (WebUI) を使った ServiceMesh + CI/CD 環境 Istio を使うことで ● トラフィックコントロール ○ Canary リリース ● Chaos テストのために Fault injection(遅延やドロップ) ○ 障害試験 ● メトリクスのスコアリング ○ パフォーマンス低下の検知 ○ 複雑な ServiceMesh 内でのパフォーマンスチェック
  • 33. Microservices, Service Mesh, and CI/CD Pipelines: Making It All Work Together Istio + BRIGADE + kashti (WebUI) を使った ServiceMesh + CI/CD 環境 BRIGADE を使うことで ● Event driven な CI/CD Pipeline ○ DockerHub の変更を検知 ○ Github の変更を検知 ● JavaScript による Pipeline 定義 ○ コード化が可能 ● 全てを網羅 ○ Go binary の作成、Docker Image の作成、Helm Charts の作成、Slack 通知 events.on("exec", () => { var job = new Job("test", "alpine:3.4") job.tasks = [ "echo Hello", "echo World" ] job.run() })
  • 34. Microservices, Service Mesh, and CI/CD Pipelines: Making It All Work Together あとこのセッションでちょっと納得したのは ● PR で Canary リリース ● Merge で正式リリース というのは良さそうだなと思いました
  • 35. Building Better Containers: A Survey of Container Build Tools 現状の Dockerfile の問題 ● イメージの再現性が乏しい ● Bash での Programmability ● イメージフォーマット間での連携が弱い Dockerfile 使ってコンテナイメージ作る時代はきっと終わるよ! [ソースからイメージビルド] source-to-image (s2i) buildkit habitat 詳しくは凄い量になるので、 付録の SpreadSheet で。 [従来方式] buildah nixos-container ansible-container smith (distroless)
  • 36. GitOps - Operations by Pull Request GitOps の 3 つの法則 ● システム全体が正常に稼働する状態を Git で管理する ● 実際の状態と Git の状態(想定する状態)の差分を比較してアラート発行 ● 全ての変更操作は PR 経由で実行する
  • 37. GitOps - Operations by Pull Request GitOps の 3 つの柱 ● Pipeline ● Observility ● Controll
  • 38. GitOps - Operations by Pull Request Pipeline ● 1 Repository は 1 app / service で構成 ● ブランチは prd / stg / dev などで切る ● ブランチは Namespace か Cluster にマップさせる ● stg に展開するときは stg ブランチにマージしたら自動で行われる ● ブランチはプロテクトしてレビューを必須にする
  • 39. GitOps - Operations by Pull Request
  • 40. GitOps - Operations by Pull Request Observility メトリクス等を駆使して PR をマージしていいかを判断する レスポンスタイムが 100ms 以下かどうか等 Controll すべては Git を介して行い Kuberentes を直接操作しない
  • 41. Developer Tooling for Kubernetes Configuration Validation(kubeval) ● Manifest YAML のフォーマットが正しいかどうか Unit Test(kubetest) ● podSpec のチェック ● label 設定のチェック ● 特権コンテナを使っていないかのチェック ● etc… jsonnet や helm charts などでもテスト可能