Tweet
Tweet

Slide 1

Slide 1 text

Kubernetesを 最⼤限に活かすためのGitOps⼊⾨ @さくらの⼣べ Docker/Kubernetesナイト 技術本部 伊藤⻯⼀ (@amaya382) 2019/6/17

Slide 2

Slide 2 text

⾃⼰紹介 伊藤⻯⼀ • しごと • 所属: 技術本部 アプリケーショングループ • 新規プロジェクト×2でKubernetesを導⼊中 • 1つはAPIサーバのデプロイ先、バッチ処理実⾏環境として • 1つはスケーラブルなデータ処理基盤として • こじん • Twitter: @amaya382 • Kubernetesに関する同⼈誌を書いたり • 技術書典7もKubernetes関係で模索中 2

Slide 3

Slide 3 text

対象者とゴール 前提 • k8s・CI/CDの基本的な概念をある程度理解している 対象者 • k8s上にアプリをデプロイするベストプラクティスを知りたい⼈ ゴール • GitOpsの概念を知る • 既存のCI/CDとの違い • GitOps導⼊に必要な諸々を知る • あわよくば、 「kubectlで⼿動デプロイするのは⼩学⽣までだよねーwww」 ぐらいの⼼意気を⼿に⼊れる 3

Slide 4

Slide 4 text

GitOpsの概要とゴール k8s環境を前提としたCI/CDの戦略 • 原典: https://www.weave.works/technologies/gitops/ 全ての設定をコード化、Gitで管理 • 属⼈化したHackを防ぐ • デプロイ状態の確認を容易に • 開発だけでなく、運⽤作業もGitの操作で統⼀ 適切な関⼼の分離 • 権限の分離 • セキュリティリスクの抑制 4 例えば… Git Revertでサービス巻き戻し

Slide 5

Slide 5 text

GitOpsの概要とゴール k8s環境を前提としたCI/CDの戦略 • 原典: https://www.weave.works/technologies/gitops/ 全ての設定をコード化、Gitで管理 • 属⼈化したHackを防ぐ • デプロイ状態の確認を容易に • 開発だけでなく、運⽤作業もGitの操作で統⼀ 適切な関⼼の分離 • 権限の分離 • セキュリティリスクの抑制 5 CIの権限は最低限に

Slide 6

Slide 6 text

GitOpsを従来のCI/CDと⽐較する 6

Slide 7

Slide 7 text

CI/CDを振り返る CI/CDの⽬的は？ • 変更があった際に必要な処理の⾃動化 CIとCDは似ているが、役割が少し異なる • CI(ContinuousIntegration) • ⾃動的なテスト実⾏・ビルド成果物 (DockerImage、npmパッケージ等)アップロード • CD(ContinuousDelivery/Deployment) • ⾃動的なアプリデプロイ ※2つまとめてCIと呼ぶことも多い 7 Push Hook ビルド・テスト実⾏ コード変更 Hook デプロイ実⾏ 開発者 Deploy

Slide 8

Slide 8 text

CI/CDを振り返る CI/CDの⽬的は？ • 変更があった際に必要な処理の⾃動化 CIとCDは似ているが、役割が少し異なる • CI(ContinuousIntegration) • ⾃動的なテスト実⾏・ビルド成果物 (DockerImage、npmパッケージ等)アップロード • CD(ContinuousDelivery/Deployment) • ⾃動的なアプリデプロイ ※2つまとめてCIと呼ぶことも多い 8 Push Hook ビルド・テスト実⾏ コード変更 Hook デプロイ実⾏ 開発者 Deploy CI

Slide 9

Slide 9 text

CI/CDを振り返る CI/CDの⽬的は？ • 変更があった際に必要な処理の⾃動化 CIとCDは似ているが、役割が少し異なる • CI(ContinuousIntegration) • ⾃動的なテスト実⾏・ビルド成果物 (DockerImage、npmパッケージ等)アップロード • CD(ContinuousDelivery/Deployment) • ⾃動的なアプリデプロイ ※2つまとめてCIと呼ぶことも多い 9 Push Hook ビルド・テスト実⾏ コード変更 Hook デプロイ実⾏ 開発者 Deploy CD

Slide 10

Slide 10 text

k8s環境へアプリデプロイ kubectl applyコマンド • いい感じに新規作成または部分更新してくれる • ただし、⼿動では 「apply漏れ」・「デプロイ先間違い」・「権限管理問題」等が発⽣ 10 Apply 開発環境で 試してみよう ？ ？ 環境

Slide 11

Slide 11 text

k8s環境へアプリデプロイ kubectl applyコマンド • いい感じに新規作成または部分更新してくれる • ただし、⼿動では 「apply漏れ」・「デプロイ先間違い」・「権限管理問題」等が発⽣ 11 Apply ？ ？ 環境 本番 本番環境だった！！

Slide 12

Slide 12 text

k8s環境で従来のCI/CD (CIOps) 「CI/CDでkubectlすればいいじゃん」 サービスの世代管理が困難 意図したデプロイ状況になっているか分からない 属⼈化したHackが発⽣ パワフルな権限を持つCI ※GitOpsと対⽐して、従来のCI/CDをCIOpsと呼ぶ • Push型 12 Apply 開発環境 本番環境 Apply

Slide 13

Slide 13 text

k8s環境で従来のCI/CD (CIOps) 「CI/CDでkubectlすればいいじゃん」 サービスの世代管理が困難 意図したデプロイ状況になっているか分からない 属⼈化したHackが発⽣ パワフルな権限を持つCI ※GitOpsと対⽐して、従来のCI/CDをCIOpsと呼ぶ • Push型 13 Apply 開発環境 本番環境 Apply 変更をデプロイするだけ 状態を管理できるわけではない

Slide 14

Slide 14 text

k8s環境で従来のCI/CD (CIOps) 「CI/CDでkubectlすればいいじゃん」 サービスの世代管理が困難 意図したデプロイ状況になっているか分からない 属⼈化したHackが発⽣ パワフルな権限を持つCI ※GitOpsと対⽐して、従来のCI/CDをCIOpsと呼ぶ • Push型 14 Apply 開発環境 本番環境 Apply 誰も触れない秘伝のタレ

Slide 15

Slide 15 text

k8s環境で従来のCI/CD (CIOps) 「CI/CDでkubectlすればいいじゃん」 サービスの世代管理が困難 意図したデプロイ状況になっているか分からない 属⼈化したHackが発⽣ パワフルな権限を持つCI ※GitOpsと対⽐して、従来のCI/CDをCIOpsと呼ぶ • Push型 15 Apply 開発環境 本番環境 Apply ⾼セキュリティリスク

Slide 16

Slide 16 text

GitOpsとは DevOps技術の1つで、Gitを利⽤しk8sに特化したCI/CD戦略 • SingleSourceofTruthとして、サービスの状態を1つのGitリポジトリで持つ • 関⼼ (CI/CD) の分離 • 権限の分離 16 SingleSourceofTruth (Manifestファイル群) SSoTと同期 • アプリAを2つ • アプリBを4つ • GET /users はアプリAへ • POST /comments はアプリBへ • ロードバランサが必要

Slide 17

Slide 17 text

Docker Registry GitOpsとは DevOps技術の1つで、Gitを利⽤しk8sに特化したCI/CD戦略 • SingleSourceofTruthとして、サービスの状態を1つのGitリポジトリで持つ • 関⼼ (CI/CD) の分離 • 権限の分離 17 SingleSourceofTruth (Manifestファイル群) アプリの更新 デ プ ロ イ要 求 (PR作 成 ) Hook アプリイメージ更新 開発者(Dev) アプリソースコード CIツール CDツール

Slide 18

Slide 18 text

Docker Registry GitOpsとは DevOps技術の1つで、Gitを利⽤しk8sに特化したCI/CD戦略 • SingleSourceofTruthとして、サービスの状態を1つのGitリポジトリで持つ • 関⼼ (CI/CD) の分離 • 権限の分離 18 SingleSourceofTruth (Manifestファイル群) アプリの更新 デ プ ロ イ要 求 (PR作 成 ) CI Hook アプリイメージ更新 開発者(Dev) アプリソースコード CIツール CDツール

Slide 19

Slide 19 text

Docker Registry GitOpsとは DevOps技術の1つで、Gitを利⽤しk8sに特化したCI/CD戦略 • SingleSourceofTruthとして、サービスの状態を1つのGitリポジトリで持つ • 関⼼ (CI/CD) の分離 • 権限の分離 19 SingleSourceofTruth (Manifestファイル群) アプリの更新 デ プ ロ イ要 求 (PR作 成 ) Hook アプリイメージ更新 開発者(Dev) CD アプリソースコード CIツール CDツール

Slide 20

Slide 20 text

Docker Registry GitOpsとは DevOps技術の1つで、Gitを利⽤しk8sに特化したCI/CD戦略 • SingleSourceofTruthとして、サービスの状態を1つのGitリポジトリで持つ • 関⼼ (CI/CD) の分離 • 権限の分離 20 SingleSourceofTruth (Manifestファイル群) アプリの更新 デ プ ロ イ要 求 (PR作 成 ) Hook アプリイメージ更新 開発者(Dev) アプリソースコード CIツール CDツール CD CI

Slide 21

Slide 21 text

Docker Registry GitOpsとは DevOps技術の1つで、Gitを利⽤しk8sに特化したCI/CD戦略 • SingleSourceofTruthとして、サービスの状態を1つのGitリポジトリで持つ • 関⼼ (CI/CD) の分離 • 権限の分離 21 SingleSourceofTruth (Manifestファイル群) アプリの更新 デ プ ロ イ要 求 (PR作 成 ) Hook アプリイメージ更新 開発者(Dev) アプリソースコード CIツール CDツール デプロイ実⾏

Slide 22

Slide 22 text

Docker Registry GitOpsの全体像 22 SingleSourceofTruth (Manifestファイル群) アプリの更新 デ プ ロ イ要 求 (PR作 成 ) Hook アプリイメージ更新 開発者(Dev) デプロイ実⾏(PR承認) 運⽤者(Ops) アプリソースコード CIツール CDツール 1. コードをPush

Slide 23

Slide 23 text

Docker Registry GitOpsの全体像 23 SingleSourceofTruth (Manifestファイル群) アプリの更新 デ プ ロ イ要 求 (PR作 成 ) Hook アプリイメージ更新 開発者(Dev) デプロイ実⾏(PR承認) 運⽤者(Ops) アプリソースコード CIツール CDツール 2. CI動作開始

Slide 24

Slide 24 text

Docker Registry GitOpsの全体像 24 SingleSourceofTruth (Manifestファイル群) アプリの更新 デ プ ロ イ要 求 (PR作 成 ) Hook アプリイメージ更新 開発者(Dev) デプロイ実⾏(PR承認) 運⽤者(Ops) アプリソースコード CIツール CDツール 3. ビルド成果物 をアップロード

Slide 25

Slide 25 text

Docker Registry GitOpsの全体像 25 SingleSourceofTruth (Manifestファイル群) アプリの更新 デ プ ロ イ要 求 (PR作 成 ) Hook アプリイメージ更新 開発者(Dev) デプロイ実⾏(PR承認) 運⽤者(Ops) アプリソースコード CIツール CDツール 4. 更新を反映する PRを作成

Slide 26

Slide 26 text

Docker Registry GitOpsの全体像 26 SingleSourceofTruth (Manifestファイル群) アプリの更新 デ プ ロ イ要 求 (PR作 成 ) Hook アプリイメージ更新 開発者(Dev) デプロイ実⾏(PR承認) 運⽤者(Ops) アプリソースコード CIツール CDツール 5. 更新を確認・承認

Slide 27

Slide 27 text

Docker Registry GitOpsの全体像 27 SingleSourceofTruth (Manifestファイル群) アプリの更新 デ プ ロ イ要 求 (PR作 成 ) Hook アプリイメージ更新 開発者(Dev) デプロイ実⾏(PR承認) 運⽤者(Ops) アプリソースコード CIツール CDツール 6. SSoTが更新

Slide 28

Slide 28 text

Docker Registry GitOpsの全体像 28 SingleSourceofTruth (Manifestファイル群) アプリの更新 デ プ ロ イ要 求 (PR作 成 ) Hook アプリイメージ更新 開発者(Dev) デプロイ実⾏(PR承認) 運⽤者(Ops) アプリソースコード CIツール CDツール 7. SSoTが更新を検知・反映

Slide 29

Slide 29 text

GitOpsの全体像 SingleSourceofTruthとして、サービスの状態を1つのGitリポジトリで持つ • コードベースでリソース管理できるk8sと相性 CIとCDの分離 • CI • テストやビルドに注⼒ • Push型 • 実⾏環境への権限は不要 • CD • デプロイに注⼒ • Pull型 • ⾃⾝の実⾏環境への権限のみ持つ 29 apiVersion: apps/v1 kind: Deployment metadata: labels: app: debugkit name: debugkit spec: replicas: 1 selector: matchLabels: app: debugkit template: metadata: labels: app: debugkit spec: containers: - image: amaya382/k8s-debugkit name: k8s-debugkit

Slide 30

Slide 30 text

GitOpsの全体像 SingleSourceofTruthとして、サービスの状態を1つのGitリポジトリで持つ • コードベースでリソース管理できるk8sと相性 CIとCDの分離 • CI • テストやビルドに注⼒ • Push型 • 実⾏環境への権限は不要 • CD • デプロイに注⼒ • Pull型 • ⾃⾝の実⾏環境への権限のみ持つ 30 CI CD

Slide 31

Slide 31 text

実際に使うには 31

Slide 32

Slide 32 text

どうやって導⼊するん？ • 「ツール選択」 • 「アプリとManifest⽤Gitリポジトリの作成」 • 「Manifest作成」 • 「アプリ側の準備 (CI)」 • 「k8s側の準備 (CD)」 32

Slide 33

Slide 33 text

どうやって導⼊するん？ 「ツール選択」 Gitリポジトリ • GitHub/GitHubEnterprise/GitLab/Bitbucket/GitBucket/... • 選ぶポイント:どれを使ってもGitOpsには⼤差なし、よく使ってるやつでok CI • CircleCI/TravisCI/Jenkins/Drone/ConcourceCI/... • 選ぶポイント:どれを使ってもGitOpsには⼤差なし、よく使ってるやつでok • (GitリポジトリやDockerRegistryのCIでも可) 33

Slide 34

Slide 34 text

どうやって導⼊するん？ 「ツール選択」 CD • WeaveFlux/ArgoCD/JenkinsX/... • 選ぶポイント: GitOpsに対応していること、対応しているテンプレートエンジン、権限管理、対応して いるデプロイ⽅法 (e.g.,Blue-Green)、UIやCLIの使いやすさ Manifestテンプレートエンジン • Helm/kustomize/... • 選ぶポイント:対応しているCDツール、扱いやすさ • ※ksonnetは開発中⽌の⾒込みなので注意 • ※Helm3は未知数 34

Slide 35

Slide 35 text

どうやって導⼊するん？ 「アプリとManifest⽤Gitリポジトリの作成」 • アプリごとのリポジトリ • Manifestリポジトリはプロジェクトで1つ (Single Source of Truth) 「Manifest作成」 • k8sのManifestを作成 • 開発⽤・本番⽤といった環境の切り替えにはテンプレートを利⽤ • e.g.,接続先DB、レプリカ数 35 アプリソースコード SingleSourceofTruth (Manifestファイル群)

Slide 36

Slide 36 text

どうやって導⼊するん？ 「アプリとManifest⽤Gitリポジトリの作成」 • アプリごと • Manifestリポジトリはプロジェクトで1つ (Single Source of Truth) 「Manifest作成」 • k8sのManifestを作成 • 開発⽤・本番⽤といった環境の切り替えにはテンプレートを利⽤ • e.g.,接続先DB、レプリカ数 36 アプリソースコード SingleSourceofTruth (Manifestファイル群) apiVersion: apps/v1 kind: Deployment metadata: labels: app: debugkit name: debugkit spec: replicas: 1 selector: matchLabels: app: debugkit template: metadata: labels: app: debugkit spec: containers: - image: amaya382/k8s-debugkit name: k8s-debugkit

Slide 37

Slide 37 text

どうやって導⼊するん？ 「アプリとManifest⽤Gitリポジトリの作成」 • アプリごとのリポジトリ • Manifestリポジトリはプロジェクトで1つ (Single Source of Truth) 「Manifest作成」 • k8sのManifestを作成 • 開発⽤・本番⽤といった環境の切り替えにはテンプレートエンジンを利⽤ • e.g.,接続先DB、レプリカ数 37 アプリソースコード SingleSourceofTruth (Manifestファイル群)

Slide 38

Slide 38 text

どうやって導⼊するん？ 「アプリ側の準備 (CI)」 • 各アプリのDockerImageをDockerRegistryにプッシュ • 同時に、「新しいDockerImageを利⽤するManifest」の プルリクエストをManifestリポジトリに作成 38 Docker Registry SingleSourceofTruth (Manifestファイル群) デ プ ロ イ要 求 (PR作 成 ) アプリイメージ更新 CIツール CI設定

Slide 39

Slide 39 text

どうやって導⼊するん？ 「k8s側の準備 (CD)」 • クラスタ別にCDツールをインストール • Manifestリポジトリを利⽤するCD設定を追加 39 環境ごとにPullすることで 最低限の権限で動作 SingleSourceofTruth (Manifestファイル群) CDツール CDツール 開発環境 本番環境 CD設定 CD設定

Slide 40

Slide 40 text

どんな感じにサイクル回すん？ アプリ単体の更新 1. 開発者が各アプリリポジトリに変更をPush (実際にはプルリクエストを経由) 2. CIが動作 1. ビルドし、DockerImageをDockerRegistryへPush 2. 新しいDockerImageを使うように変更するプルリクエストを作成 3. 運⽤者がプルリクエストを確認・承認 4. SSoTが更新される 5. CDがSSoTの変化を検知・反映 40 従来のデプロイ作業を プルリクエスト承認で⾏う

Slide 41

Slide 41 text

Docker Registry どんな感じにサイクル回すん？ 41 SingleSourceofTruth (Manifestファイル群) アプリの更新 デ プ ロ イ要 求 (PR作 成 ) Hook アプリイメージ更新 開発者(Dev) デプロイ実⾏(PR承認) 運⽤者(Ops) アプリソースコード CIツール CDツール 1. コードをPush ⼈⼿ ⾃動

Slide 42

Slide 42 text

Docker Registry どんな感じにサイクル回すん？ 42 SingleSourceofTruth (Manifestファイル群) アプリの更新 デ プ ロ イ要 求 (PR作 成 ) Hook アプリイメージ更新 開発者(Dev) デプロイ実⾏(PR承認) 運⽤者(Ops) アプリソースコード CIツール CDツール 2. CI動作開始 2-2. 更新を反映する PRを作成 ⼈⼿ ⾃動 2-1. ビルド成果物 をアップロード PR

Slide 43

Slide 43 text

Docker Registry どんな感じにサイクル回すん？ 43 SingleSourceofTruth (Manifestファイル群) アプリの更新 デ プ ロ イ要 求 (PR作 成 ) Hook アプリイメージ更新 開発者(Dev) デプロイ実⾏(PR承認) 運⽤者(Ops) アプリソースコード CIツール CDツール 3. 更新を確認・承認 ⼈⼿ ⾃動 PR

Slide 44

Slide 44 text

Docker Registry どんな感じにサイクル回すん？ 44 SingleSourceofTruth (Manifestファイル群) アプリの更新 デ プ ロ イ要 求 (PR作 成 ) Hook アプリイメージ更新 開発者(Dev) デプロイ実⾏(PR承認) 運⽤者(Ops) アプリソースコード CIツール CDツール 4. SSoTが更新 ⼈⼿ ⾃動

Slide 45

Slide 45 text

Docker Registry どんな感じにサイクル回すん？ 45 SingleSourceofTruth (Manifestファイル群) アプリの更新 デ プ ロ イ要 求 (PR作 成 ) Hook アプリイメージ更新 開発者(Dev) デプロイ実⾏(PR承認) 運⽤者(Ops) アプリソースコード CIツール CDツール 5. SSoTが更新を検知・反映 ⼈⼿ ⾃動

Slide 46

Slide 46 text

どんな感じにサイクル回すん？ サービス構成の更新 1. 開発者がManifestリポジトリを更新するプルリクエストを作成 2. 運⽤者がプルリクエストを確認・承認 3. SSoTが更新される 4. CDがSSoTの変化を検知・反映 46

Slide 47

Slide 47 text

どんな感じにサイクル回すん？ 47 SingleSourceofTruth (Manifestファイル群) 構 成 変 更 要 求 (PR作 成 ) 開発者(Dev) デプロイ実⾏(PR承認) 運⽤者(Ops) CDツール 1. サービス構成を 変更するPRを作成 ⼈⼿ ⾃動 PR

Slide 48

Slide 48 text

どんな感じにサイクル回すん？ 48 SingleSourceofTruth (Manifestファイル群) 構 成 変 更 要 求 (PR作 成 ) 開発者(Dev) デプロイ実⾏(PR承認) 運⽤者(Ops) CDツール 2. 更新を確認・承認 ⼈⼿ ⾃動 PR

Slide 49

Slide 49 text

どんな感じにサイクル回すん？ 49 SingleSourceofTruth (Manifestファイル群) 構 成 変 更 要 求 (PR作 成 ) 開発者(Dev) デプロイ実⾏(PR承認) 運⽤者(Ops) CDツール 3. SSoTが更新 ⼈⼿ ⾃動

Slide 50

Slide 50 text

どんな感じにサイクル回すん？ 50 SingleSourceofTruth (Manifestファイル群) 構 成 変 更 要 求 (PR作 成 ) 開発者(Dev) デプロイ実⾏(PR承認) 運⽤者(Ops) CDツール 4. SSoTが更新を検知・反映 ⼈⼿ ⾃動

Slide 51

Slide 51 text

残る課題 • 全体が揃うと⼀気に動き出すモデルなので、 最初のセットアップがやや⼤変 • 適切なブランチ戦略が必要 • どのような変更をどの環境への変更としたいか • サービスによりその戦略は異なる • e.g., • 似たようなプロダクション環境が⼤量に必要になる場合 • バージョンごとにプロダクション環境を維持し続けていく場合 51

Slide 52

Slide 52 text

まとめ DevOps技術の1つで、Gitを利⽤しk8sに特化したCI/CD戦略 How • SingleSourceofTruthとして、デプロイ状態を1つのGitリポジトリで管理 • 関⼼ (CI/CD) の分離 Result • 全ての設定をコード化、Gitで管理 • 属⼈化したHackを防ぐ • Gitリポジトリの状態 == デプロイの状態 • 開発だけでなく、運⽤作業もGitの操作で統⼀ • 適切な関⼼の分離 • 権限の分離 • セキュリティリスクの抑制 52 運⽤者(Ops) 開発者(Dev)

Slide 53

Slide 53 text

ベストプラクティス・ Pitfall集 CDツールって1箇所に設置すれば集中管理できて楽じゃん！ • 別クラスタの稼働状況に依存させるべきではない 別クラスタへのアクセス権限をもたせるべきではない • 環境ごとに設置し、Pull型を維持すべき k8s外のリソースは？ • 考慮されていないので難しい • k8s上のCDツールではk8s外リソースのデプロイを管理しないほうが良い • e.g.,TerraformでSaaSのRDBを構築 • Manifestにはサービスへのアクセス情報だけ保持 (e.g.,HeadlessService) • ≒k8s内のServiceDiscovery対象には⼊れておく 53

Slide 54

Slide 54 text

ベストプラクティス・ Pitfall集 あれ？反映できてない？ • 即座に更新されるリソース・されないリソース • e.g.,環境変数の更新→Podを再起動しないと反映されない • CDツールが判断して全てを適切に更新してくれるのが理想 • ⚠更新ポリシーに注意する必要がある (模索中) 複数アプリの場合、Manifestの更新がバラバラになりそうだけど…？ • そもそもアプリ側がバラバラにデプロイできるように設計するべき • e.g.,API互換性の管理はURLの /v1/とか 54

Slide 55

Slide 55 text

ベストプラクティス・ Pitfall集 Helmでデプロイまでできるよね？ • 「どのHelmパッケージがデプロイされているのか」を別途管理しなければならな くなってしまう • GitOpsでは、Helmはテンプレートエンジンとしてのみ使う • なのでTiller(2.x系にあるk8s内部に設置するリソース)は不要 CredentialsをGitリポジトリに含めるとかありえん！！！ • せやな！！！ • SealedSecret • https://github.com/bitnami-labs/sealed-secrets • Credentialsを暗号化した状態でManifestリポジトリに含める k8s側で⾃動的に復号される 55

Slide 56

Slide 56 text

ベストプラクティス・ Pitfall集 IstioやPrometheus、Exporterみたいなやつらの管理は？ • 例えばCDツールにはbootstrap問題 • 上記のような場合は別リポジトリに切り出し Manifest書くの⼤変そう… • kubectlのcreatedry-runやgetexportでテンプレート作成 • 公式APIDocが便利 • https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.14/ 56

Slide 57

Slide 57 text

参考⽂献 • GitOps • https://www.weave.works/technologies/gitops/ • GitOpsではじめるKubernetes CI/CD Pipeline • https://www.slideshare.net/linecorp/gitopskubernetes-cicd-pipeline • Kubernetesで作るコンテナベースCI★CDの⼣べ/ochacafe#1 • https://speakerdeck.com/hhiroshell/ochacafe-number-1 57