マスター タイトルの書式設定 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