Slide 1

Slide 1 text

@superbrothers OpenShift Meetup Tokyo #9 - DevOps/GitOps 編 (2020/05/29) Kubernetes で実践する クラウドネイティブ DevOps

Slide 2

Slide 2 text

@superbrothers Kazuki Suda / @superbrothers ▶ ソフトウェアエンジニア ▶ Kubernetes Meetup Tokyo, Prometheus Meetup Tokyo ほか、共同主催者 ▶ CNCF Ambassador ▶ 「Kubernetes実践⼊⾨」、「みんなのDocker/Kubernetes」共著書 ▶ 「⼊⾨ Prometheus」、「Kubernetes で実践するクラウドネイティブ DevOps」監訳書 2

Slide 3

Slide 3 text

@superbrothers Kubernetesが標準プラットフォームである クラウドネイティブの世界でアプリケーションを開発 し運⽤する⽅法を解説する書籍です。Kubernetesの 基本から、継続的デプロイ、機密情報管理、 オブザーバビリティなどの⾼度なトピックを扱う本書 は、サーバ、アプリケーション、サービスを管理する IT運⽤者、クラウドネイティブサービスの構築や 移⾏を⾏う開発者必携の⼀冊です。 3 https://www.oreilly.co.jp/books/9784873119014/ “

Slide 4

Slide 4 text

@superbrothers アジェンダ 1. DevOps とクラウドネイティブ 2. GitOps: クラウドネイティブな継続的デリバリの実践 3. 実践 GitOps 4

Slide 5

Slide 5 text

@superbrothers DevOps とクラウドネイティブ

Slide 6

Slide 6 text

@superbrothers 旧来の開発と運⽤ ▶ ソフトウェアの開発と運⽤は本質的に2種類の異なる仕事 + 開発者(Dev)の職責: ソフトウェアを実装する + 運⽤者(Ops)の職責: 現実のユーザがソフトウェアを利⽤できるようにする ▶ 2つの部⾨は⽬標や動機が⼤きく異なっており、対⽴することが少なくない + 開発者(Dev)の⽬標: 新しい機能をできるだけ早くリリースしたい + 運⽤者(Ops)の⽬標: サービスの⻑期的な安定性や信頼性を実現したい 6

Slide 7

Slide 7 text

@superbrothers DevOps の夜明け ▶ クラウドの登場 + システムの運⽤に必要となる専⾨事項をシステムの設計、アーキテクチャ、実装から切り離し て考えることが容易ではなくなってきた ▶ システムは⾃分のソフトウェアだけでは成り⽴たない + クラウドサービス、ネットワークリソース、ロードバランサ、ファイアウォール、DNS など幅 広い要素で構成される上、これらすべてが緊密に相互作⽤され、相互に依存し合っている いかに早く成果をユーザに届けフィードバックを得られるかがビジネスの成功を左右する。 ⼀⽅で、ユーザは信頼性の⾼い安定したサービス提供で望んでいる。 7

Slide 8

Slide 8 text

@superbrothers 開発(Dev)と運⽤(Ops)がコラボレーションして理解を共有し、システムの信頼性と ソフトウェアの正確性に関する責任を共有するとともに、ソフトウェアシステムとそれを構築する ⼈々のチームとのどちらについても拡張性を改善する⽂化であり、協⼒的な取り組み DevOps: 開発と運⽤がともに学ぶ 8 開発(Dev) 運⽤(Ops)

Slide 9

Slide 9 text

@superbrothers DevOps がもたらすもの ⾼い品質を確保しつつ、システムへの変更をコミットしてから通常の運⽤に移るまでの時間を 短縮することを⽬的とした⼀連のプラクティス ▶ ⾃動化・セルフサービス化された信頼性の⾼いインフラやツール ▶ 開発から運⽤までエンドツーエンドで⽀える CI/CD パイプライン ▶ 継続的な学びや素早いリカバリにつながるフィードバックループ ▶ モダンな開発⼿法をインフラに取り⼊れた Infrastructure as Code ▶ 開発者のコードがインフラにおよぼす影響の把握 ▶ 本番環境におけるモニタリングやトラブルシューティング 9

Slide 10

Slide 10 text

@superbrothers クラウドネイティブ / Cloud Native クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウド などの近代的でダイナミックな環境において、スケーラブルなアプリケーションを構築および実⾏ するための能⼒を組織にもたらします。 このアプローチの代表例に、コンテナ、サービスメッ シュ、マイクロサービス、イミュータブルインフラストラクチャ、および宣⾔型APIがあります。 これらの⼿法により、回復性、管理⼒、および可観測性のある疎結合システムが実現します。 これ らを堅牢な⾃動化と組み合わせることで、エンジニアはインパクトのある変更を最⼩限の労⼒で頻 繁かつ予測どおりに⾏うことができます。 Cloud Native Computing Foundationは、オープンソースでベンダー中⽴プロジェクトのエコシステ ムを育成・維持して、このパラダイムの採⽤を促進したいと考えてます。 私たちは最先端のパター ンを⺠主化し、これらのイノベーションを誰もが利⽤できるようにします。 10 “ CNCF Cloud Native Definition v1.0 / https://github.com/cncf/toc/blob/master/DEFINITION.md

Slide 11

Slide 11 text

@superbrothers こういった専⾨⽤語の例に漏れず⼈により定義は異なるが、ほとんどの⼈に同意してもらえるだろう クラウドネイティブなシステムの特性は次のとおりです。 11 ⾃動化可能 アプリケーションを⼈間の代わりにマシン、ソフトウェアによってデプロイおよび管理する ポータブル ディスクなどの物理リソースやマシンに関する詳細な知識から切り離すことで、 マシンやクラスタ間、さらにはクラウド間で容易に移動できる 分散化 コードを単⼀のエンティティ(モノリスと呼ばれます)としてデプロイする代わりに、協調して動作す る複数の分散化されたマイクロサービスから構成される傾向がある スケーラブル 分散化されたアプリケーションは、冗⻑性や優雅な劣化(グレースフル・デグラデーション)を通じて ⾼度な可⽤性を実現する ダイナミック コピーを数多く実⾏して⾼可⽤性を実現することや、ローリングアップデートを実施して、 トラフィックを取りこぼすことなくサービスを円滑にアップグレードできる 観測可能 分散システムの性質上、プロファイリングやデバッグが難しくなるため、オブザーバビリティ (可観測性)が重要な要件になる クラウドネイティブとは! インパクトのある変更を最小限の労力で頻繁かつ予測どおりに行い、 開発した成果をできる限り早く本番に届け、かつ安定した運用を実現するため!

Slide 12

Slide 12 text

@superbrothers クラウドネイティブを実践する 12 https://github.com/cncf/trailmap その1つの方法の入り口が「Kubernetes」です!

Slide 13

Slide 13 text

@superbrothers ”Kubernetes で実践する”クラウドネイティブ DevOps ▶ GitOps: クラウドネイティブな継続的デリバリ ▶ 頻繁なデプロイに耐えうるワークロードの実⾏ ▶ オブザーバビリティ: アプリケーション、インフラを観測可能にする 13 このセッションでは3つのトピックをお話したかったんですが、 GitOps だけになっちゃいました;; クラウドネイティブという新たな世界における
 DevOps の実践

Slide 14

Slide 14 text

@superbrothers GitOps クラウドネイティブな継続的デリバリの実践

Slide 15

Slide 15 text

@superbrothers GitOps とは 継続デリバリの⼿法の1つで宣⾔型なインフラとアプリケーションの信頼できる情報源 (source of truth)として Git を使⽤し、Git に加えられた変更からインフラ、アプリケーションの 更新を検出して展開する 15 短いサイクルでソフトウェアを開発し、最新バージョンがすぐにでも
 リリース可能な状態を維持する手法です Git オーケストレータ オーケストレータ側からGit の変更を監視して
 自身に適用する「プルモデル」を採用することが特徴のひとつ! プル

Slide 16

Slide 16 text

@superbrothers GitOps ツールが Kubernetes クラスタの現在の状態を Git にバージョン管理された マニフェストファイル(望ましい状態)に⼀致させる。 GitOps を Kubernetes で実践する 16 プル GitOps ツール マニフェストファイル 自身に適用

Slide 17

Slide 17 text

@superbrothers GitOps を Kubernetes で実践する 1. Git リポジトリに Kubernetes リソース設定(マニフェストファイル)の全てを格納する 2. Git リポジトリの更新は(必要なら)プルリクエストを通じて⾏う 3. ⼀度 Git リポジトリが更新されたら直ちに⾃動的にクラスタに変更を適⽤する 4. リポジトリに格納された現在の状態が望ましい状態と⼀致していない場合、 望ましい状態に⼀致するように正すか、GitOps ツールがアラートで通知する 17 コンフィグ repo もう少しはっきりいうと!

Slide 18

Slide 18 text

@superbrothers GitOps の CI/CD パイプライン 18 CI コード repo コンフィグ repo イメージ レジストリ 継続的インテグレーション(CI) 継続的デリバリ(CD) 開発者

Slide 19

Slide 19 text

@superbrothers GitOps の開発者(Dev)への恩恵 Git を⽤いたソフトウェア開発プロセスによるインフラの管理 ▶ Infrastructure-as-Code ▶ セルフサービス ▶ コードレビュー ▶ プルリクエスト / マージリクエスト 19 コンフィグ repo 開発者 ソフトウェア開発のノウハウを取り込める! レビュア

Slide 20

Slide 20 text

@superbrothers 予測可能な信頼性の⾼いシステムの構築 ▶ 宣⾔的でイミュータブル ▶ 信頼できる情報源(source of truth) ▶ ロールバック ▶ 問題があった場合にいつ誰がどんな⽬的で加えた変更なのかを追跡できる GitOps の運⽤者(Ops)への恩恵 20 20 コンフィグ repo 運⽤者 ! 信頼できる情報源と 差分があることを アラートとして通知もできる ロールバックは以前のリビジョンに戻すだけ (ツール自体がロールバックに対応している場合もあります) git revert

Slide 21

Slide 21 text

@superbrothers GitOps と CIOps 旧来の CI システムからデプロイする CI/CD パイプラインは、「CIOps」と呼称され、 GitOps と⽐較して問題点が指摘されている。  CIOps は、CI システムはデプロイに必要なクレデンシャルを与える必要がある   GitOps は、プル型なのでクレデンシャルを外部に出すことがない  CIOps は、デプロイ先を管理する必要があるため、パイプラインが複雑になる   GitOps、デプロイ先となるシステム側からプルするのでスケールしやすい   21 CI RW CIOps RO GitOps

Slide 22

Slide 22 text

@superbrothers 代表的な GitOps ツール for Kubernetes 22 ツール 概要 主な開発 ライセンス Flux GitOps を提供した Weaveworks 社が開発するシンプルな ツール。新しいコンテナイメージが利⽤可能になると マニフェストを更新する機能なども持つ。 CNCF Sandboxプロジェクト。 Weaveworks 社 Apache 2.0 Argo CD マルチテナントに対応し、複数のアプリケーションを管理で きる。Argo プロジェクトの1コンポーネントだが単体でも 使⽤できる。CNCF Incubating プロジェクト。 Intuit 社 Apache 2.0 Jenkins X イメージのビルドとプッシュといった CI ツールとしての 機能も持ち、開発サイクルのより広い範囲をカバーし、 プレビュー環境を⾃動で作成するなどの機能を持つ。 Continuous Delivery Foundation (CDF) プロジェクト。 Cloudbees 社 Apache 2.0

Slide 23

Slide 23 text

@superbrothers デモ / Flux・Get started 23 Get Started - Flux https://docs.fluxcd.io/en/latest/get-started/

Slide 24

Slide 24 text

@superbrothers 実践 GitOps

Slide 25

Slide 25 text

@superbrothers 実践 GitOps 1. 環境管理 ・Namespace /クラスタ編 2. 環境管理・マニフェスト編 3. シークレット管理 4. Git 戦略 5. デプロイ戦略 6. セキュリティ 25

Slide 26

Slide 26 text

@superbrothers 環境管理 ・Namespace /クラスタ編 開発、QA、e2e、ステージング、本番をどう管理するか ▶ Namespace レベルの分離: RBAC、NetworkPolicy、ResourceQuota、LimitRange ▶ クラスタレベルの分離 26 development qa e2e stage production 本番以前と本番でクラスタを分離する場合の例です

Slide 27

Slide 27 text

@superbrothers マニフェストの環境差異をどのように管理するか 環境管理・マニフェスト編 27 ConfigMap Kubernetes の標準リソースで設定をアプリケーションから分離する。 Helm Kubernetes パッケージマネージャで、チャートというパッケージとしてアプリケーションを管理 する。テンプレートからマニフェストを⽣成する。 Kustomize パッチなどを使⽤してマニフェストをカスタマイズするテンプレートフリーなツール。kubectl に ビルトインされてもいる。 Jsonnet JSONテンプレート⾔語。JSON を拡張し演算や関数、ライブラリ等が使えるようになっている。 Google が開発している。 Kpt Kubernetes パッケージツールで、設定をコード(テンプレートや DSL)ではなくデータとして扱 うことで⼈間とマシンの双⽅から扱いやすくしている。Google が開発している。 cbk8s AWS CDK の概念を適⽤し、TypeScript や Python といった使い慣れたプログラミング⾔語を使⽤ してマニフェストを⽣成する。頻出パターンをライブラリとして共有もできる。 最初からツールを手を出さずに
 ConfigMap でやっていくのがオススメ! いくつかの GitOps ツールは、
 これらのツールをネイティブでサポートしてます

Slide 28

Slide 28 text

@superbrothers シークレット管理の戦略 どこにどのように管理するか(場所、⽅法、ローテーション) ▶ ⼿動で Secret オブジェクトを作成し、クラスタに保存 ▶ データを暗号化してマニフェストとして Git リポジトリに保存 + github.com/mozilla/sops ▶ リモートの専⽤の機密情報管理ツールに保存 + Hashicorp Vault、Keywhiz、AWS Secrets Manager、Azure KeyVault、GCP Secret Manager + github.com/godaddy/kubernetes-external-secrets + github.com/GoogleCloudPlatform/berglas + github.com/kubernetes-sigs/secrets-store-csi-driver 28 ちなみに「Encrypting Secret Data at Rest」を使えば
 Kubernetes オブジェクトを保存時に暗号化できます!

Slide 29

Slide 29 text

@superbrothers Git 戦略 環境ごとにどのようにブランチを管理するか ▶ シングルブランチ(複数ディレクトリ) + master ブランチに全環境のマニフェストが格納されている + 各環境の差分をパッチで管理できる kustomize が有効 ▶ マルチブランチ + 個々のブランチが各環境(開発や QA、本番など)に相当する + 複雑になりやすいが各環境への変更が容易にトラックできる 29 シングルブランチ戦略は GitHub flow, 
 マルチブランチ戦略は GitLab flow になるのかな? ソフトウェア開発のプラクティスですね! master stage production デプロイ デプロイ

Slide 30

Slide 30 text

@superbrothers Git 戦略 / コードとマニフェストでリポジトリを分ける ▶ GitOps ツールにコードを取得させる必要はない。セキュリティリスクになる。 ▶ デプロイに関連しないコミット履歴が監査上のノイズになる。 ▶ ⼈間の権限の分離。コードの編集権限と本番へのデプロイ権限はしっかり分ける。 30 コード repo コンフィグ repo コード repo に含まれるマニフェストを
 コンフィグ repo に PR する運用はアリだと思います! 開発者 運⽤者

Slide 31

Slide 31 text

@superbrothers Git 戦略 / マイクロサービスとモノレポ マイクロサービスなアプリケーションの全体をどう管理するか ▶ それぞれのリポジトリで管理する + 個々のポリシーを柔軟に設定できる ▶ モノレポ: 1つのリポジトリの各ディレクトリで管理する + サービス全体の現在の状態が完全に把握できる + 統⼀されたポリシーを全体に確実に適⽤できる + 中央チームが必要になる 31 app-c app-b app-a app-c app-b app-a これもソフトウェア開発のソレですね。

Slide 32

Slide 32 text

@superbrothers デプロイ戦略 新しいバージョンをどのように展開するか 32 戦略 概要 Pros Cons ⼿段 ローリング アップデート 徐々に新しいバージョンに変えていく。 シンプルで簡単に利⽤可能 展開やロールバック に時間がかかる トラフィックの制御 はできない Deployment ブルーグリーン 現バージョン(ブルー) を落とさず、新バー ジョン(グリーン)をデプロイし、問題なけれ ばトラフィックを⼀気に切り替える。 短時間に展開、ロールバック できる 複数バージョンが混在しない ⼀時的に2倍の リソースが必要 Deployment + Service Flagger, Argo Rollouts カナリア 現バージョンを落とさずに新バージョンをデプ ロイするが、トラフィックを徐々に切り替え る。エラー率やパフォーマンスに問題があれば ロールバックする。 問題の影響が最⼩限のうちに ⾼速にロールバックできる 展開やロールバック に時間がかかる Flagger, Argo Rollouts プログレッシブ デリバリ 現バージョンを落とさずに新バージョンをデプ ロイしするが、⼀部のユーザにのみ届けられて 主要なメトリクスの値に問題があるときは⾃動 的にロールバックする。 問題の影響が最⼩限のうちに ⾼速に⾃動的にロールバック できる 展開やロールバック に時間がかかる Flagger, Argo Rollouts

Slide 33

Slide 33 text

@superbrothers DevSecOps? セキュリティを⾃動化して、環境全体とデータ、CI/CD プロセスを守る ▶ 権限管理 + Git リポジトリ + コンテナイメージレジストリ + Kubernetes RBAC ▶ シークレット管理 ▶ コンテナイメージスキャン + github.com/quay/clair、github.com/aquasecurity/trivy + GCR Vulnerability scanning、Amazon ECR イメージスキャン、Azure Security Center ▶ マニフェストのバリデーション + conftest、kubeval、Pod Security Policy、OpenPolicyAgent、Gatekeeper、Grafeas + Kritis CI 33 セキュリティ セキュリティをアプリケーション開発の隅々まで組み込む!

Slide 34

Slide 34 text

@superbrothers 頻繁なデプロイに耐えうる ワークロードの実⾏ 34 オブザーバビリティ アプリケーション、インフラを観測可能にする https://youtu.be/FSwctW3AdaM https://speakerdeck.com/superbrothers/introduction-to-prometheus https://speakerdeck.com/superbrothers/production-ready-pods-plus

Slide 35

Slide 35 text

@superbrothers まとめ

Slide 36

Slide 36 text

@superbrothers まとめ ▶ DevOps: 開発と運⽤がともに学び、システムの信頼性とソフトウェアの正確性に関する責任を 共有する⽂化であり、協⼒的な取り組み ▶ クラウドネイティブ: クラウドネイティブなシステムの特性は、「⾃動化可能で」「ポータブル で」、「分散化でき」「スケーラブルで」「ダイナミックで」「観測可能」 + インパクトのある変更を最⼩限の労⼒で頻繁かつ予測どおりに⾏い、開発した成果をできる限 り早く本番に届け、かつ安定した運⽤を実現するため! ▶ GitOps: Gitを信頼できる情報源(source of truth)として、Git に加えられた変更からインフラ、 アプリケーションの更新を検出して展開する継続的デリバリの⼿法の1つ + メリットに、ソフトウェア開発プロセスによるインフラの管理や予測可能な信頼性の⾼いシス テムの構築が実現できることがある 36

Slide 37

Slide 37 text

@superbrothers DevOpsの第⼀歩は、最先端のソフトウェア開発はコードをリリースしたら終わりで はないと認識することです。それは、コードを書く者とそれを使⽤する者との間の フィードバックループを短くします。 運⽤とインフラのスキルは、クラウドネイティブ⾰命によっても決して陳腐化する わけではなく、現にかつてないほど重要であり、今後もさらに重要性が⾼まります。 ソフトウェアエンジニアと運⽤エンジニアの明確な区別は今後なくなるでしょう。 今ではソフトウェアがすべてであり、誰もがエンジニアです。 「Kubernetesで実践するクラウドネイティブDevOps」第⼀章 1.8節より 37 ”

Slide 38

Slide 38 text

@superbrothers 「Kubernetes で実践するクラウドネイティブ DevOps」の そのほかのトピック

Slide 39

Slide 39 text

@superbrothers そのほかのトピック ▶ コンテナと Kubernetes の基本的な使い⽅ ▶ Kubernetes 環境の選択 ▶ サーバレスプラットフォームへの理解 ▶ Kubernetes リソースへの理解 ▶ Kubernetes クラスタのコスト最適化 ▶ Kubernetes クラスタの運⽤ ▶ Kubernetes のツール郡 ▶ Pod の⾼度なスケジューリング ▶ Kubernetes コントローラとオペレータ ▶ Kubernetes クラスタのバックアップ ▶ オブサーバビリティとメトリクス監視 39

Slide 40

Slide 40 text

@superbrothers Thanks / Question? ▶ Kazuki Suda, @superbrothers ▶ Slide: https://speakerdeck.com/superbrothers/ 40

Slide 41

Slide 41 text

@superbrothers 参考資料 ▶ GitOps - Operations by Pull Request https://www.weave.works/blog/gitops-operations-by-pull-request ▶ "GitOps": WeaveworksがCI/CD実践に使⽤する開発者モデルを公開 https://www.infoq.com/jp/news/2018/11/gitops-weaveworks/ ▶ GitOpsで絶対に避けて通れないブランチ戦略 - ⽔底 https://amaya382.hatenablog.jp/entry/2019/12/02/192159 ▶ Kubernetes anti-patterns: Let's do GitOps, not CIOps! https://www.weave.works/blog/kubernetes-anti-patterns-let-s-do-gitops-not-ciops ▶ DevOps チェックリスト - Azure Design Review Framework | Microsoft Docs https://docs.microsoft.com/ja-jp/azure/architecture/checklist/dev-ops ▶ Guide To GitOps https://www.weave.works/technologies/gitops/ ▶ Introducing Argo Flux - A Weaveworks-Intuit-AWS Collaboration https://www.weave.works/blog/argo-flux-join-forces ▶ Best Practices - Argo CD - Declarative GitOps CD for Kubernetes https://argoproj.github.io/argo-cd/user-guide/best_practices/#separating-config-vs- source-code-repositories ▶ 11 Reasons for Adopting GitOps https://blog.container-solutions.com/11-reasons-for-adopting-gitops ▶ Automate Progressive Deployments to Kubernetes with Flagger and Linkerd https://www.weave.works/blog/automate-progressive-deployments-to- kubernetes-with-flagger-and-linkerd ▶ Six Strategies for Application Deployment ‒ The New Stack https://thenewstack.io/deployment-strategies/ 41