Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
CI details in Kubernetes
matsuo
September 02, 2020
Technology
5
980
CI details in Kubernetes
matsuo
September 02, 2020
Tweet
Share
More Decks by matsuo
See All by matsuo
how-to-make-the-helm-operator
matsu1235
0
150
K8sNativeSecurityToolkit
matsu1235
4
540
CI in kubernetes
matsu1235
1
3.6k
DockerCompose to k8s
matsu1235
0
880
Other Decks in Technology
See All in Technology
Power AutomateでのAdaptive Cards
miyakemito
1
570
The application of formal methods in Kafka reliability engineering
line_developers
PRO
1
200
サイボウズの アジャイル・クオリティ / Agile Quality at Cybozu
cybozuinsideout
PRO
4
2.3k
Custom GitHub Actions by Java
kazamori
0
290
スタートアップと技術選定と AWS
track3jyo
PRO
2
350
JDK Flight Recorder入門
chiroito
1
510
紙にまつわる苦しみを機能化してきた カミナシの歴史
kaminashi
0
1.3k
LINEのB2Bプラットフォームにおけるトラブルシューティング2選
line_developers
PRO
4
300
Retca Cloud
bau
0
520
Autonomous Database Cloud 技術詳細 / adb-s_technical_detail_jp
oracle4engineer
PRO
10
18k
Data in Google I/O - IO Extended GDG Seoul
kennethanceyer
0
150
SwiftUI Layout
auramagi
1
110
Featured
See All Featured
Streamline your AJAX requests with AmplifyJS and jQuery
dougneiner
127
8.5k
Fashionably flexible responsive web design (full day workshop)
malarkey
396
62k
WebSockets: Embracing the real-time Web
robhawkes
57
5.2k
Design by the Numbers
sachag
271
17k
Code Review Best Practice
trishagee
43
9.2k
BBQ
matthewcrist
74
7.9k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
269
11k
For a Future-Friendly Web
brad_frost
166
7.4k
It's Worth the Effort
3n
172
25k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
236
1M
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
151
13k
Six Lessons from altMBA
skipperchong
14
1.4k
Transcript
マスター タイトルの書式設定 KubernetesにおけるCIの考え方、 および具体的な実装について CNDT2020 rejekts
マスター タイトルの書式設定 自己紹介 名前 : 松尾 所属 :
株式会社オージス総研 職種 : インフラエンジニア 1
マスター タイトルの書式設定 そもそもCIとは? 2
マスター タイトルの書式設定 そもそもCIとは? 小さなサイクルでインテグレーションを繰り返し行い、エラー修正や開発を迅速に行うことが出来 る 3 Plan Code Build
Test Release Deploy Operate テスト手法 行程 単体、結合、システム、受け入れテスト 実行方法 静的、動的テスト 品質 機能、性能、負荷、ユーザビリティ、セキュリティテスト テスト技法 ブラックボックス、ホワイトボックステスト ※知識ゼロから学ぶソフトウェアテスト 【改訂版】 より
マスター タイトルの書式設定 Kubernetesの構成要素 4
マスター タイトルの書式設定 Gitリポジトリ コンテナレジストリ Dockerfile アプリケーション コンテナイメージ Manifest 物理/VMホスト Kuberntesクラスタ
コンテナ OS アプリケーション ミドルウェア 5 Kubernetesの構成要素 ※簡略化して書いています 静的なもの 動的なもの Dev、 K8s admin push deploy
マスター タイトルの書式設定 レイヤー 静的な 構成要素 動的な 構成要素 物理/VM等の インフラ構成 Terraform、CFn等
実環境 Kubernetes Manifest Kubernetesクラスタ コンテナ Dockerfile ベースイメージ コンテナイメージ ミドルウェア パッケージ アプリケーションコード リポジトリ Gitリポジトリ - コンテナ レジストリ - 6 Kubernetesの構成要素
マスター タイトルの書式設定 構成要素に対するテストを 考える 7
マスター タイトルの書式設定 構成要素に対するテストを考える 8 レイヤー 分類 構成要素 行程 実行方法 品質
テスト技法 単体、結合、シス テム、受け入れテ スト 静的、動的テスト 機能、性能、負荷、 ユーザビリティ、セ キュリティテスト ブラックボックス、 ホワイトボックステ スト 物理/VM等の インフラ構成 静的 Terraform、CFn等 動的 実環境 Kubernetes 静的 Manifest 動的 Kubernetesクラスタ コンテナ 静的 Dock erfile ベースイメー ジ ミドルウェア パッケージ アプリケー ションコード 動的 コンテナイメージ リポジトリ 静的 Gitリポジトリ コンテナレジストリ 動的 -
マスター タイトルの書式設定 構成要素に対するテストを考える 9 レイヤー 分類 構成要素 行程 実行方法 品質
テスト技法 単体、結合、シス テム、受け入れテ スト 静的、動的テスト 機能、性能、負荷、 ユーザビリティ、セ キュリティテスト ブラックボックス、 ホワイトボックステ スト 物理/VM等の インフラ構成 静的 Terraform、CFn等 動的 実環境 Kubernetes 静的 Manifest 動的 Kubernetesクラスタ コンテナ 静的 Dock erfile ベースイメー ジ ミドルウェア パッケージ アプリケー ションコード 動的 コンテナイメージ リポジトリ 静的 Gitリポジトリ コンテナレジストリ 動的 - 現実的に、何に対して どんなテストを行えばよい?
マスター タイトルの書式設定 テストの考え方 10
マスター タイトルの書式設定 テストの考え方 11 どのテストを行うか 行程 小さく始めていくためにはテスト実装の難易度から、受け入れテストより、単体テスト
実行方法 自動化の難易度から、動的なテストより、静的なテスト 品質 重要視する要件により決めていく 機能、性能、負荷、ユーザビリティ、セキュリティテスト テスト技法 静的に表現されているものに対してのユニットテストが行いやすいため、ホワイトボックステスト 何に対してテストを行うか ガバナンスきかせたいもの(セキュリティ、コード規約、・・・) 頻繁に更新がかかるもの(アプリケーション、・・・) 静的に宣言されているもの(そのまま) テスト可能なもの(テスト手段があり、実装が容易なもの) 履歴から、バグが起こりやすいもの(過去に何か障害が発生した箇所) このようにテスト手法と、対象を考慮して、小さく始めていく
マスター タイトルの書式設定 具体的なテスト方法と対象 12
マスター タイトルの書式設定 具体的なテスト方法と対象 13 レイヤー 分類 構成要素 コード規約 、Lint 単体
セキュリティ 、脆弱性 ガイドライン、 コンプライアンス 結合 その他 物理/VM等の インフラ構成 静的 Terraform、CFn等 cfn-lint … cfn-ng、 git-secrets … … … 動的 実環境 … … … … … … Kubernetes 静的 Manifest kubeval conftest kubesec、 git-secrets … Kubetest、 kubetest2 … 動的 Kubernetesクラスタ … gate Keeper gatekeeper、 kube-hunter、 falco gatekeeper、 kube-bench、 kubeaudit、 Falco kind litmus コンテナ 静的 Docker file ベース イメージ hadolint … Trivy dockle … … ミドル ウェア パッケージ アプリ ケーション コード 動的 コンテナイメージ … … Trivy … … … リポジトリ 静的 Gitリポジトリ … … git-secrets … … … コンテナレジストリ … … Trivy … … …
マスター タイトルの書式設定 具体的なテスト方法と対象 14 conftest/gatekeeperでのテストについて K8s manifestのベストプラクティス集
K8s.io naked podの禁止(replicaset, deploymentのみ使用) workloadの前に、必ずserviceを作成すること hostNetwork、hostPortの不使用 label設定 imagePullPolicyのlatestタグ不使用 Learn k8s readiness probe、passive liveness probeが設定されていること readiness probeとliveness probeの値が同じでないこと ・・・ Stakkrox Google ・・・ これらの設定項目を確認し、リスクと優先度付けして、REGO言語で表現することが必要
マスター タイトルの書式設定 どのようなCIツールを使うか? 15
マスター タイトルの書式設定 どのようなCIツールを使うか? 16 CIツールの要件例 テストのサマリ、エラー時のデバッグのしやすさ、停止/再試行、アラーティング機能があること 設定すべてが静的に表現できること(CIツール自身もIaC管理)
アプリ開発者が使っているリポジトリとの親和性 単純にリポジトリとしでではなく、issueやPR等の機能連携も考慮 クラウドとの連携 低スペックなリソースによる長時間ビルド×、高スペックで短時間〇、オンプレにある高スペックなリソースがあればそれを活用も 良し 並列テストの容易さ(アプリにもよる) などを満たすCIツールを選定 要件はDevOps的に検討する 上記がインフラ観点、アプリ開発者観点での要件に分類できるということだが、それらはどれが欠け ても良いCIは出来ない DevOps的に一緒に検討して決めていく必要がある
マスター タイトルの書式設定 いつテストを行うべきか? 17
マスター タイトルの書式設定 いつテストを行うべきか? 18 一般的にはShift Left Testingという考え方があり、ライフサイクルのより手前、つ まり静的なものに対して、早期かつ頻繁にテストを行うべきと言われている Gitリポジトリ
コンテナレジストリ Dockerfile コンテナイメージ Manifest 物理/VMホスト Kuberntesクラスタ コンテナ OS アプリケーション ミドルウェア 静的なもの 動的なもの テスト Dev、 K8s admin deploy push
マスター タイトルの書式設定 いつテストを行うべきか? 19 ライフサイクルの手前で行うテストと同じようなテストを、後半でも行うかどう か?については、手段があれば可能な限り行う Gitリポジトリ コンテナレジストリ Dockerfile
コンテナイメージ Manifest 物理/VMホスト Kuberntesクラスタ コンテナ OS アプリケーション ミドルウェア Dev、 K8s admin push 静的なもの 動的なもの conftest gatekeeper deploy
マスター タイトルの書式設定 どのようにCIツールを 構成するか? 20
マスター タイトルの書式設定 どのようにCIツールを構成するか? 21 パイプラインの粒度 gitのイベントにhookしてCIツール(パイプライン)を実行するよう設定するのが一般的 インフラやアプリが同じレポジトリの場合
全テスト入りのCIツールが都度実行される → ビルドの長時間化 別ブランチにコミット溜めておいて、まとめてマージしてビルド → 開発効率が悪い DevとOpsで担当コードは分かれているので、リポジトリは基本的には分ける おのずとパイプラインも分かれる
マスター タイトルの書式設定 具体的な実装例 22
マスター タイトルの書式設定 具体的な実装例 23 Push CIツール • アプリケーションコード • Lint、ユニットテスト
• Dockerfile • 脆弱性チェック • ベストプラクティスチェック • 全ファイル • シークレットチェック --- ビルド実施 --- • コンテナイメージ • ベストプラクティスチェック Push git Hook Dev アプリケーション コード Dockerfile コンテナレ ジストリ Git-secrets コンテナ イメージ
マスター タイトルの書式設定 具体的な実装例 24 Manifest Kubernetes クラスタ Push CIツール •
Manifest • Yamlフォーマットチェック • ユニットテスト • ベストプラクティスチェック • ガバナンスチェック • シークレットチェック 適用 git Hook conftest Git-secrets kubetest kubeval K8s admin
マスター タイトルの書式設定 具体的な実装例 25 Manifestのイメージタグは手動で書き換え?
マスター タイトルの書式設定 具体的な実装例 26 Manifest内のコンテナタグの書き換えは、手動では効率が悪い アプリCIにて、生成したイメージタグを元にインフラリポジトリのmanifestを書き換える アプリCI処理内容
GitのコミットIDをタグにしてコンテナビルド TAG=AP-$(git rev-parse HEAD) docker build . –t ${TAG} インフラリポジトリからClone git clone https://hogehoge.git コミットIDを含めたタグでテンプレートからmanifset生成 find . -type f -name “AP.yaml.tpl” | xargs sed -e “s|CONTAINER_IMAGE|${TAG}|g” > k8s- manifest/31.AP.yaml インフラリポジトリへPush git add . git commit -m "Update ImageTag based on ${TAG}" git push --set-upstream origin CI Helm等の活用も検討
マスター タイトルの書式設定 (番外編)DockerfileやManifestは 一方だけで作るものか? 27
マスター タイトルの書式設定 Dev Ops コンテナイメージ情報 • OS • ミドルウェア •
依存関係 ベースDockerfile作成、ビルド • セキュアなベースイメージ選定 • セキュリティ観点の設定 • ロギング、モニタリング設定 • ビルドの軽量、高速化の考慮 • OS、ミドルウェアのセキュリ ティ脆弱性チェック ベース Dockerfile アプリコンテナイメージ作成 • アプリ含めてビルド • 単体テスト ベースのコンテナイメージ提供依頼 Dev Git アプリ Dockerfile コンテナ レジストリ アプリ コンテナ イメージ Push ベース コンテナ イメージ Push Pull (番外編)DockerfileやManifestは一方だけで作るものか? Dockerfileの作り方例
マスター タイトルの書式設定 (番外編)DockerfileやManifestは一方だけで作るものか? Dev Ops オーケストレーション設定作成 • K8sマニフェスト作成 • コンテナ連携テスト
K8sマニフェスト ファイル Ops Git オーケストレーション情報 • コンテナ同士の連携内容 • コンテナの起動順序 • コンテナ連携テスト方法 • ・・・ 提供 コンテナ レジストリ Pull アプリ コンテナ イメージ Push Manifestの作り方例
マスター タイトルの書式設定 全体の実装例 30
マスター タイトルの書式設定 Github Github Dev Feature ブランチ Master ブランチ CodeBuild
AppCI Push アプリケーショ ンコード、 Dockerfile K8s マニフェスト ファイル 全体の実装例 K8s admin CodeBuild ブランチ Push PR作成 Pull Request マージ レビューア 1 2 3 4 CI実行 結果 返却 1 Master ブランチ CodeBuild InfraCI PR作成 Pull Request マージ レビューア 2 3 4 CI実行 結果 返却 コンテナ レジストリ Push コンテナイメージ (コミットID) CodeBuild コンテナタグ更新 Hook コミットID 3’ 5
マスター タイトルの書式設定 見えてきた課題 32
マスター タイトルの書式設定 見えてきた課題 33 ビルドの長時間化 テストの種類が多すぎたり、アーティファクトの肥大化等が原因 まずは何に時間がかかっているかを、きちんと測定する
キャッシュやマルチステージビルド等のベストプラクティスは押さえておく 各フェーズでのテストを熟慮する(開発環境でテストしていれば本番でテスト減らす等) 並列テストが可能かどうか検討する ビルドエラーのデバッグ CIを再試行してのデバッグは、繰り返しづらいし、クラウドだと費用もかかる クライアントPC上にイメージとCI内容を持ってきて再現させてデバッグする CIログの可視化 数千行にもわたるCIログが出力される場合、CI停止直後のログは確認できるが、中盤あたりまで 処理を追おうとすると追いづらい
マスター タイトルの書式設定 Kubernetesでも 速さと安定を兼ね備えた、 より良いCIをやっていきましょう! 34