CircleCI ユーザーコミュニティミートアップ #2
KubernetesのマニフェストをそれなりにCIしたいCircleCI User Community Meetup #2 Osaka@stormcat24
View Slide
whois‣ CyberAgent, Inc.‣ Backend Engineer‣ OpenSaaS Studio Tech Lead‣ Docker/Kubernetes 実践コンテナ開発入門Akinori Yamadastormcat24
book1万部突破ベストセラーDocker/Kubernetes実践コンテナ開発入門(技術評論社)※CircleCIについても触れています
この後、紀伊國屋書店へGo
場所提供をしたので喋ることにしました
Kubernetesでのアプリケーション開発
予備知識:PodPodDockerコンテナの集合体nginx api
Podを複製Deployment ReplicaSetPodPodPod予備知識:DeploymentReplicaSetの世代管理基本的に、開発者はアプリケーションのデプロイ定義として、Deploymentリソースを定義・管理します
apiVersion: apps/v1kind: Deploymentmetadata:name: echolabels:app: echospec:replicas: 3selector:matchLabels:app: echotemplate:metadata:labels:app: echospec:containers:- name: echoimage: gcr.io/your-organization/your-service:v0.0.1-01-g39f376aenv:- name: HOGEvalue: fugaports:- containerPort: 8080マニフェストファイルdeployment.yaml※マニフェストファイルをKubernetesクラスタに適用=デプロイ
KubernetesにおけるCI/CD
CIとCDは明確に分離し、GitOpsなスタイルが潮流アプリケーションリポジトリデリバリ用リポジトリ※Kubernetesのマニフェストファイル群を置く
CDの手法は色々ある‣ CircleCIからkubectl‣ Spinnaker‣ ArgoCD‣ Flux CD‣ ローカルから直接kubectl
GitOpsスタイルのCDデリバリ用リポジトリ≒リポジトリへの変更がクラスタへのデプロイ事実上、クラスタ操作をPRで行うことになる
CI CDユニットテストアプリケーションビルドDockerイメージビルドDockerレジストリへPushクラスタの状態をsyncマニフェストをクラスタに反映
課題感
CI CDユニットテストアプリケーションビルドDockerイメージビルドDockerレジストリへPushクラスタの状態をsyncマニフェストをクラスタに反映マニフェストの検証がなされずに反映
apiVersion: apps/v1kind: Deploymentmetadata:name: echolabels:app: echospec:replicas: 3selector:matchLabels:app: echotemplate:metadata:labels:app: echospec:containers:- name: echoimage: gcr.io/your-organization/your-service:v0.0.1-01-g39f376aenv:- name: HOGEvalue: fugaports:- containerPort: 8080PRでの人力レビューには限界がある
アプリケーションはユニットテストを含め検証の手法が豊富
マニフェストファイルもそうあるべきでは?
+
kind = Kubernetes in DockerCircleCI上にKubernetesクラスタを構築できる
version: 2jobs:kind:machine:image: circleci/classic:201808-01steps:- checkout- run:name: Install kubernetes cluster with kindcommand: |curl -Lo ./kind https://github.com/kubernetes-sigs/kind/releases/download/v0.6.1/kind-linux-amd64chmod +x kindsudo mv kind /usr/local/bin- run:name: Start clustercommand: |kind create cluster --name test-cluster --image kindest/node:v1.14.9- run:name: Waiting for readycommand: |READY=""while [ "$READY" != "True" ]dosleep 2READY=`kubectl get node -o=jsonpath='{range .items[*]}{range @.status.conditions[?(@.type == "Ready")]}{@.status}{end}{end}'`doneecho "Node is ready"echo "Current running pods are the follows:"kubectl get --all-namespaces podmachineモードでkindインストールクラスタ起動 クラスタ起動待ち
クラスタ起動
これでCircleCIの中でKubernetesクラスタにいろいろできる
考えられるワークロード‣ マニフェストの反映でエラーでないかチェック‣ 実行時エラー確認‣ マニフェスト反映 → クラスタに対してE2Eテストの実行‣ マニフェストの妥当性のチェック‣ Open Policy Agent(OPA) / gatekeeper‣ 必須なlabelやannotationのチェック‣ イメージや環境変数のチェック etc
CI (CDのCIと)CDユニットテストアプリケーションビルドDockerイメージビルドDockerレジストリへPushクラスタの状態をsyncマニフェストをクラスタに反映マニフェスト妥当性チェック※これからはCDのCIが大事
まとめ‣ CircleCI + kindで気軽に揮発的なKubernetesクラスタが作れる‣ OPAやgatekeeperで、制約を設けることでPRレビューで漏れがちなミスをチェックしやすくなる‣ GitOpsの推進と、デプロイの心理的安全性の確保‣ アプリケーションが巨大(マイクロサービスとか)になると、CircleCIで全てのリソースを展開することが難しい
おわり