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

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
② Code:stg のマージをきっかけに、
　　Manifest を自動生成して Manifest:stg へ自動マージ
　　Docker Image のビルドと Registry に Push

GitHub
k8s YAML
manifest
GitHub
Application
Code
stg
prd
stg
prd
③ Manifest:stg ブランチへのマージ
　　＝ stg クラスタ or NS への反映
stg クラスタの状態
prd クラスタの状態

GitHub
k8s YAML
manifest
GitHub
Application
Code
stg
prd
stg
prd
④ Code を stg から prd にマージ
⑤ Manifest が自動生成されて Manifest:prd に PR

GitHub
k8s YAML
manifest
GitHub
Application
Code
stg
prd
stg
prd
⑥ Manifest:prd の PR がマージされたタイミングで
　prd クラスタに反映

GitHub
k8s YAML
manifest
GitHub
Application
Code
dev
stg
prd
dev
stg
prd
厳密には
・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
○ 共通設定や管理の集中化を考える必要がある
結構しんどい。

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 を実現しましょう！
　※ 変更から反映までの間隔を出来るだけ短くすること

１．Image First
● Immutable なコンテナにする
● Entrypoint を設定してそのまま起動できるようにする
● local / dev / prd で同じイメージを利用する
● latest タグは使わない
● GitHub の特定のコミットと Image Tag を紐付けておく
● local でビルドして push はしない（自動化必須）

２．Shift Left
テストは出来るだけ前倒ししましょう
Bottleneck

３．Maintain Application Portability
クラスタが消し飛んだときに復旧できますか？　（会場では x hour ~ x day の声）
ちゃんと移動出来るようにメンテナンスはし続けて下さい
● 設定ファイルはコンテナイメージに内包せず ConfigMap / Secret を使う
○ Docker Build は出来るだけ避ける
○ 環境変化に強い設計にする
● Helm Charts 化も検討しましょう
● ディザスタリカバリのテストもしましょう

４．Outsource Cluster Management
● クラスタの管理は専門チームに任せる
● スケーラビリティや冗長化の計画を持っておく
● Certified Kubernetes Conformance Program に準拠した構成にしましょう

CodeFresh
　Kubernetes に特化した Spinnaker + CircleCI + DockerHub のようなもの
● Github のコード変更
● Docker Image の作成
● Deployment の Config や Helm Charts を生成
● （Performance Test）
● Kubernetes クラスタにデプロイ

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 内でのパフォーマンスチェック

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

あとこのセッションでちょっと納得したのは
● 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 の 3 つの柱
● Pipeline
● Observility
● Controll

Pipeline
● 1 Repository は 1 app / service で構成
● ブランチは prd / stg / dev などで切る
● ブランチは Namespace か Cluster にマップさせる
● stg に展開するときは stg ブランチにマージしたら自動で行われる
● ブランチはプロテクトしてレビューを必須にする

Observility
メトリクス等を駆使して PR をマージしていいかを判断する
レスポンスタイムが 100ms 以下かどうか等
Controll
すべては Git を介して行い Kuberentes を直接操作しない

Developer Tooling for Kubernetes Configuration
Validation（kubeval）
● Manifest YAML のフォーマットが正しいかどうか
Unit Test（kubetest）
● podSpec のチェック
● label 設定のチェック
● 特権コンテナを使っていないかのチェック
● etc…
jsonnet や helm charts などでもテスト可能

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

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

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

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