$30 off During Our Annual Pro Sale. View Details »

Kubernetesを最大限に活かすためのGitOps入門

 Kubernetesを最大限に活かすためのGitOps入門

Kubernetes環境でCI/CDを実現する「GitOps」について。
@さくらの夕べ Docker/Kubernetesナイト

お受けした質問の一部はこちらのツイートに紐づく形で回答しています→https://twitter.com/amaya382/status/1140575485878886400

Ryuichi Ito

June 17, 2019
Tweet

More Decks by Ryuichi Ito

Other Decks in Technology

Transcript

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  16. 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へ
    • ロードバランサが必要

    View Slide

  17. Docker Registry
    GitOpsとは
    DevOps技術の1つで、Gitを利⽤しk8sに特化したCI/CD戦略
    • SingleSourceofTruthとして、サービスの状態を1つのGitリポジトリで持つ
    • 関⼼ (CI/CD) の分離
    • 権限の分離
    17
    SingleSourceofTruth
    (Manifestファイル群)
    アプリの更新



    イ要

    (PR作

    )
    Hook
    アプリイメージ更新
    開発者(Dev)
    アプリソースコード CIツール
    CDツール

    View Slide

  18. Docker Registry
    GitOpsとは
    DevOps技術の1つで、Gitを利⽤しk8sに特化したCI/CD戦略
    • SingleSourceofTruthとして、サービスの状態を1つのGitリポジトリで持つ
    • 関⼼ (CI/CD) の分離
    • 権限の分離
    18
    SingleSourceofTruth
    (Manifestファイル群)
    アプリの更新



    イ要

    (PR作

    )
    CI
    Hook
    アプリイメージ更新
    開発者(Dev)
    アプリソースコード CIツール
    CDツール

    View Slide

  19. Docker Registry
    GitOpsとは
    DevOps技術の1つで、Gitを利⽤しk8sに特化したCI/CD戦略
    • SingleSourceofTruthとして、サービスの状態を1つのGitリポジトリで持つ
    • 関⼼ (CI/CD) の分離
    • 権限の分離
    19
    SingleSourceofTruth
    (Manifestファイル群)
    アプリの更新



    イ要

    (PR作

    )
    Hook
    アプリイメージ更新
    開発者(Dev)
    CD
    アプリソースコード CIツール
    CDツール

    View Slide

  20. Docker Registry
    GitOpsとは
    DevOps技術の1つで、Gitを利⽤しk8sに特化したCI/CD戦略
    • SingleSourceofTruthとして、サービスの状態を1つのGitリポジトリで持つ
    • 関⼼ (CI/CD) の分離
    • 権限の分離
    20
    SingleSourceofTruth
    (Manifestファイル群)
    アプリの更新



    イ要

    (PR作

    )
    Hook
    アプリイメージ更新
    開発者(Dev)
    アプリソースコード CIツール
    CDツール
    CD
    CI

    View Slide

  21. Docker Registry
    GitOpsとは
    DevOps技術の1つで、Gitを利⽤しk8sに特化したCI/CD戦略
    • SingleSourceofTruthとして、サービスの状態を1つのGitリポジトリで持つ
    • 関⼼ (CI/CD) の分離
    • 権限の分離
    21
    SingleSourceofTruth
    (Manifestファイル群)
    アプリの更新



    イ要

    (PR作

    )
    Hook
    アプリイメージ更新
    開発者(Dev)
    アプリソースコード CIツール
    CDツール
    デプロイ実⾏

    View Slide

  22. Docker Registry
    GitOpsの全体像
    22
    SingleSourceofTruth
    (Manifestファイル群)
    アプリの更新



    イ要

    (PR作

    )
    Hook
    アプリイメージ更新
    開発者(Dev)
    デプロイ実⾏(PR承認)
    運⽤者(Ops)
    アプリソースコード CIツール
    CDツール
    1. コードをPush

    View Slide

  23. Docker Registry
    GitOpsの全体像
    23
    SingleSourceofTruth
    (Manifestファイル群)
    アプリの更新



    イ要

    (PR作

    )
    Hook
    アプリイメージ更新
    開発者(Dev)
    デプロイ実⾏(PR承認)
    運⽤者(Ops)
    アプリソースコード CIツール
    CDツール
    2. CI動作開始

    View Slide

  24. Docker Registry
    GitOpsの全体像
    24
    SingleSourceofTruth
    (Manifestファイル群)
    アプリの更新



    イ要

    (PR作

    )
    Hook
    アプリイメージ更新
    開発者(Dev)
    デプロイ実⾏(PR承認)
    運⽤者(Ops)
    アプリソースコード CIツール
    CDツール
    3. ビルド成果物
    をアップロード

    View Slide

  25. Docker Registry
    GitOpsの全体像
    25
    SingleSourceofTruth
    (Manifestファイル群)
    アプリの更新



    イ要

    (PR作

    )
    Hook
    アプリイメージ更新
    開発者(Dev)
    デプロイ実⾏(PR承認)
    運⽤者(Ops)
    アプリソースコード CIツール
    CDツール
    4. 更新を反映する
    PRを作成

    View Slide

  26. Docker Registry
    GitOpsの全体像
    26
    SingleSourceofTruth
    (Manifestファイル群)
    アプリの更新



    イ要

    (PR作

    )
    Hook
    アプリイメージ更新
    開発者(Dev)
    デプロイ実⾏(PR承認)
    運⽤者(Ops)
    アプリソースコード CIツール
    CDツール
    5. 更新を確認・承認

    View Slide

  27. Docker Registry
    GitOpsの全体像
    27
    SingleSourceofTruth
    (Manifestファイル群)
    アプリの更新



    イ要

    (PR作

    )
    Hook
    アプリイメージ更新
    開発者(Dev)
    デプロイ実⾏(PR承認)
    運⽤者(Ops)
    アプリソースコード CIツール
    CDツール
    6. SSoTが更新

    View Slide

  28. Docker Registry
    GitOpsの全体像
    28
    SingleSourceofTruth
    (Manifestファイル群)
    アプリの更新



    イ要

    (PR作

    )
    Hook
    アプリイメージ更新
    開発者(Dev)
    デプロイ実⾏(PR承認)
    運⽤者(Ops)
    アプリソースコード CIツール
    CDツール
    7. SSoTが更新を検知・反映

    View Slide

  29. 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

    View Slide

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

    View Slide

  31. 実際に使うには
    31

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  36. どうやって導⼊するん?
    「アプリと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

    View Slide

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

    View Slide

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



    イ要

    (PR作

    )
    アプリイメージ更新
    CIツール
    CI設定

    View Slide

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

    View Slide

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

    View Slide

  41. Docker Registry
    どんな感じにサイクル回すん?
    41
    SingleSourceofTruth
    (Manifestファイル群)
    アプリの更新



    イ要

    (PR作

    )
    Hook
    アプリイメージ更新
    開発者(Dev)
    デプロイ実⾏(PR承認)
    運⽤者(Ops)
    アプリソースコード CIツール
    CDツール
    1. コードをPush
    ⼈⼿
    ⾃動

    View Slide

  42. Docker Registry
    どんな感じにサイクル回すん?
    42
    SingleSourceofTruth
    (Manifestファイル群)
    アプリの更新



    イ要

    (PR作

    )
    Hook
    アプリイメージ更新
    開発者(Dev)
    デプロイ実⾏(PR承認)
    運⽤者(Ops)
    アプリソースコード CIツール
    CDツール
    2. CI動作開始
    2-2. 更新を反映する
    PRを作成
    ⼈⼿
    ⾃動
    2-1. ビルド成果物
    をアップロード
    PR

    View Slide

  43. Docker Registry
    どんな感じにサイクル回すん?
    43
    SingleSourceofTruth
    (Manifestファイル群)
    アプリの更新



    イ要

    (PR作

    )
    Hook
    アプリイメージ更新
    開発者(Dev)
    デプロイ実⾏(PR承認)
    運⽤者(Ops)
    アプリソースコード CIツール
    CDツール
    3. 更新を確認・承認
    ⼈⼿
    ⾃動
    PR

    View Slide

  44. Docker Registry
    どんな感じにサイクル回すん?
    44
    SingleSourceofTruth
    (Manifestファイル群)
    アプリの更新



    イ要

    (PR作

    )
    Hook
    アプリイメージ更新
    開発者(Dev)
    デプロイ実⾏(PR承認)
    運⽤者(Ops)
    アプリソースコード CIツール
    CDツール
    4. SSoTが更新
    ⼈⼿
    ⾃動

    View Slide

  45. Docker Registry
    どんな感じにサイクル回すん?
    45
    SingleSourceofTruth
    (Manifestファイル群)
    アプリの更新



    イ要

    (PR作

    )
    Hook
    アプリイメージ更新
    開発者(Dev)
    デプロイ実⾏(PR承認)
    運⽤者(Ops)
    アプリソースコード CIツール
    CDツール
    5. SSoTが更新を検知・反映
    ⼈⼿
    ⾃動

    View Slide

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

    View Slide

  47. どんな感じにサイクル回すん?
    47
    SingleSourceofTruth
    (Manifestファイル群)






    (PR作

    )
    開発者(Dev)
    デプロイ実⾏(PR承認)
    運⽤者(Ops)
    CDツール
    1. サービス構成を
    変更するPRを作成
    ⼈⼿
    ⾃動
    PR

    View Slide

  48. どんな感じにサイクル回すん?
    48
    SingleSourceofTruth
    (Manifestファイル群)






    (PR作

    )
    開発者(Dev)
    デプロイ実⾏(PR承認)
    運⽤者(Ops)
    CDツール
    2. 更新を確認・承認
    ⼈⼿
    ⾃動
    PR

    View Slide

  49. どんな感じにサイクル回すん?
    49
    SingleSourceofTruth
    (Manifestファイル群)






    (PR作

    )
    開発者(Dev)
    デプロイ実⾏(PR承認)
    運⽤者(Ops)
    CDツール
    3. SSoTが更新
    ⼈⼿
    ⾃動

    View Slide

  50. どんな感じにサイクル回すん?
    50
    SingleSourceofTruth
    (Manifestファイル群)






    (PR作

    )
    開発者(Dev)
    デプロイ実⾏(PR承認)
    運⽤者(Ops)
    CDツール
    4. SSoTが更新を検知・反映
    ⼈⼿
    ⾃動

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  57. 参考⽂献
    • 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

    View Slide