GitOps: High velocity CICD for Kubernetes

Published in

Orangesys

17 min readOct 22, 2018

GitOpsを読みましたが、和訳しました。原文を直接読みたい方、文書の最後に

TL;DR

“The world is envisioned as a repo and not as a kubernetes installation” — Kelsey Hightower
「kubernete installationとしての世界には先はないが、レポジトリとしての世界には将来性がある」 — Kelsey Hightower

Kelsey氏の言葉、この和訳が良いかなぁ

このブログはkuberneteとDockerを使って高速継続デリバリ(high velocity continuous delivery)をしたい人のための役に立つ情報をまとめたものです。“高速”(high velocity)というと、すべてのプロダクトチームが一日に何回も何回も安全にアップデートできることを意味します。つまりは、すぐにデプロイし、リアルタイムで監察でき、ロールフォワードかロールバックにこのフィードバックを使うことです。その目的はプロダクトチームにとってカスタマーエクスペリエンスの向上をできる限り急速に改善するためにcontinuous experimentation（持続的な試み）を使用することです。

もしまだあなたがGitOpsを詳しく知らないというのであれば、少し説明しておきます。これは動作の早い現代のアプリケーションのためのソフトウェア・ライフサイクルです。Gitops — Operations by Pull Requestという私たちのブログを読んでいただければ分かりやすく解説しています。

Use Case: high velocity CICD is game-changing

どのように一週間ごとのシングルマニュアルデプロイが１から３０にまで増加するのでしょうか？つまり、一日に何の努力もしないでデプロイできるということです。

Qordobaとの出会い－Qordobaはサンフランシスコを拠点にしたチームで、有名ブランドどのために最適化されたローカライゼーションを国際的な市場に売り出すマシンラーニングを使っているチームです。そのうちの1つのチームではKuberneteをベースにしたマイクロサービスをQordobaバックエンドの1つとして使っています。私たちが推奨したGitOpsやツールを実際に取り入れることで、徹底的にカスタマーUXを形作る能力を向上することができました。

プロッドソフトウェアバグを直すために必要な推定時間：Weave クラウド使用後、60％短縮
カスタマ―リクエストに反応するための推定時間：Weave クラウド使用後43％
稼働率が99％から100％に（今のところ…）

Qordobaは週に一回の１もしくは２個のデプロイを一日にプラス３０以上に増加させました。ここで重要なのは、全てのデプロイがもともと“zero cost”（コストがかからない）ということです。それはつまり、ほとんど時間がかからないということです。開発チームがシステムを良い状態に戻すことができないまま、まだデプロイが半分もできていない状態ですね。そして全ての変化はローバックされます。ゼロ・コスト・デプロイのおかげで、開発チームはもうビジネスロジックやUXに集中できるようになり、失敗コストを恐れずにいくらでも高速に値を反復処理できるようになりました。

Learn more: GitOps intro presentation

William Denniss, PM for Google Cloud.（ウィリアム・デニス、Google CludのためのPM）とのKubecon 2017 での使用事例をご紹介しました。

背景説明：Weave ワークスが2年以上にもわたり、production Kubernetes cloud services on AWS（AWS上でのKuberneteクラウドサービスプロダクション）を運営しています。最近私たちは、これのために一番効率のよい方法を実証しました。それは、私たちが“GitOps”と呼んでいるものです。Kuberneteアプリケーションにジョインドアップや自動化されたライフサイクルを納入する GitOpsはCICD やdeclarative infrastructure as codeのような実績のあるdevopsテクニック上に構築されています。私たちは、‘free tier’ GitOps capability with Google Cloud Platform at Kubeconを世に送り出しました。

もし、どのように私たちがこれを成し遂げたか（例えば高速CICDパイプラインの構築などについて）興味を持たれたかたは、ぜひこのプレゼンテーションをご覧ください（video, slides）。

Kubeconはコミュニティイベントです。そして、このプレゼンテーションの中で私とウィリアムは解決方法のパターンについて話をしています。例えば、Kuberneteデプロイ・オペレーターの役割、それを機能させるオープンソース・プロジェクトについてなどです。

Instant Kubernetes CICD with Weave Cloud

もしこのプレゼンテーションとそのGitOpsのアイデアを気に入って頂けたなら、これもぜひ見てください。きっと気に入って頂けるはずです。GitOpsをWeave Cloudを通してGoogle上で一番早くセットアップする方法via our Weave Cloud offering on Google.です。

こちらも参考にどうぞ

Kubernete パイプラインセットアップを１分以内で
ワンクリックでアプリのデプロイ（もちろんマニュアルステージングも必要であれば）
完全可観測性、ダッシュボードとアラート

Weave CloudはごのGitレポジトリやどのCIとでも簡単に接続が可能です。このセットアップはCICDのためのKuberneteクラスターのためのものなので、上にあげたQordobaのような持続的で高速な納入から受けるメリットがあります。GoogleクラウドではあなたのGIKEクラスターは簡単にGoogleのコンテナビルダーやレポに接続することができます。しかし、ここで少し覚えておいてほしいのは、Weave Cloudはどのクラスター、どのネットワーク、どのCI、どのGitレポとでも機能するということです。私たちはあなたに強制しているわけではないので、あなたの好きなようにして頂いて構いません。

このベースから、Git PRs , CLI 、 GUIなどを通してアプリをロールバックしたりアップデートしたりすることができます。最後に、オペレーションサークルを完成させるために“フルスタック”モニタリングとマネージメントを統合します。Weaveの統合されたアプローチは、デベロッパーやそのデプロイが起こっているときにモニタリングでき、それゆえにその変化の影響への反応や測定をします。下にUIの例を示しておきます。

Open Source GitOps

私たちのクラウドサービスはKuberneteにとってGitOpsを使うにあたり便利で優れたおのだと思います。しかし、もしあなたが自分自身のオープンソースパイプラインをセットアップしたいし、理解したいと思っているデベロッパーだとしたら？以下に、もっとGitOpsアプローチについて詳しく説明しています。

Approach 1 — Use the Weave Flux Deployment Operator

自分のKuberneteクラスターにサービスデプロイをリッスンして、指示するためのオペレーター・パターンをぜひ使ってください。このアプローチはウィリアム・デニス氏によって私たちのKubeconのプレゼンテーション(video, slides)のスライド15–21で説明されています。オペレーターを使うことでエージェントがクラスターに変わってカスタム・リソースの変化に関するイベントをリッスンし、継続的にその変化を提供してくれます。言い換えれば、オペレーターがGitとクラスターのバランスをうまく取り持ってくれるということです。

オペレーターはWeave Flux -オープンソースプロジェクトによって実装されます。Weave FluxーオープンソースプロジェクトはSaaS、つまりWeave CloudのためのKuberneteへの自身のマイクロサービスデプロイを簡単にするために苦難の末、誕生しました。より詳しくは、ブログ“The GitOps Pipeline”（GitOps パイプライン）をお読みください。こちらにはCI プラススクリプト（CI ops）を通してのハンド・コーディングについてというよりはむしろ、デプロイを実行するための利点について書かれています。

Fluxは私たちのWeave Cloud サービスで使われています。ぜひ、ご自身でもこれを使ってみてください。Fluxにご興味をお持ち緒外部のOSS コントリビューターと企業の方はぜひ。多くのCIとデプロイツールがデプロイ・オペレーターから受ける利益は十分にあるでしょう。

Approach 2 — GitOps fundamentals the Kelsey Way

ケルシ―・ハイタワー氏はシンプルなデベロッパーを第一に考えた解決策などについての素晴らしいプレゼンテーションをしています。彼のKubeconでの講演も例にもれず素晴らしいものでした。(動画はこちら）.

ケルシ―氏のプレゼンテーションでは、Github や Google Cloudを使った持続的なデリバリ、また「kubectleは新しいSSHです。（中略）もしあなたがkubectleを個人のパソコンから本番環境へデプロイするためにkubectleを使っているのであれば、おそらく何個かの手順を飛ばしていると思います」と話しています。ケルシ―氏は、そこでGitからCIとステージングを通して本番環境と可観測性ダッシュボードへのステップのレイアウトを実践で見せてくれました。彼はステップを分かりやすく可視化しながら説明をしてくれました。もっと具体的にはこちらで彼のプレゼンテーションをご覧ください。

ケルシ―氏の分析は以下の二つの前提に基づく

Kubernete デプロイは完全に解決されたわけではありません。ケルシ―氏は「どのくらい大勢の人たちが端から端までの持続的なデリバリーパイプラインを持っているのでしょうか？いったんあなたがkuberneteにたどり着いているのであれば、次の新たな目標はこれでしょう。これこそが、次にフォーカスしないといけない、莫大な時間を費やすべき問題です」と彼は述べています。
デベロッパーたちはGitやその結果の観察を通して変化を促進させたいと思っています。ケルシ―氏は「もし私がコードチェンジするとしたら、私がどうしても手に入れたいものは、それがどこを走っているか教えてくれるURLです。それがどういう状態で走っているか教えてくれるメトリックを私に教えてくれた人には何かプレゼントを差し上げます。今の段階ではクラスターの中で何が実際に起きているかを観察できるので、もしあなたが可視化することが可能であれば、デベロッパーたちはkubectleのような役に立つツールをもう求めないでしょう」と述べています。

これはおそらく同じGitOpsのためのピッチの中で論点とすべき内容です。その主要なアイデアは、Gitがスタックの中にある全ての望ましい状態のための真実のソースであるということです。スタックというのはつまり、クラスター、コンフィグレーション、アプリケーション、ツーリングなどコードとしての宣言的インフラストラクチャを使ったもののことです。より詳しい説明は“プル・リクエストによるオペレーション”という私たちの最初のブログを読んでください。

Choose your GitOps adventure

この投稿では、高速CICDを試してみて頂けるように３つのアプローチをしています。

GitからGKEクラスターへのデフォルトのCICDパイプラインを提供する独創的なサービスは、Weabe Cloudを使っていて、モニタリング、可観測性、検査、障害許容力やスケールをサポートする特徴を含みます。また他のKuberneteプロバイダーやご自身のCIにも対応しています
Weave Fluxのイントロダクションは、スタンドアローンであり、（１）で使用されているオープンソースオペレーターです。Kuberneteクラスターさえ持っていればどこでも動作します。
ケルシ―氏が見せてくれたシンプルなGitHubとGoogleとのパイプラインをセットアップする方法

この３つのアプローチは100％と相互に調和が取れています。それでは、それらを比較してみましょう。

Weave CloudサービスはGitOpsパイプラインのセットアップの中で一番完璧なもので、それ自身が重要な事項であるGitOps の可観測性のためのしっかりしたサポートもします。またケルシ―氏は「私たちは、可視化されるようになってほしいと願っています。その1つの方法が、実際に何が起きているか見ることができる精選されたダッシュボードを提供することです。」と述べています。

Weave FluxのオープンソースオペレーターはCICDのCDの部分にのみフォーカスしています。Fluxを使うことは、リリース・ワークフローが何度も作られ、スケールにおいて管理が可能だということ、またkubectleやCIツール上のボルトスクリプトを使うよりも断然簡単だということです。Fluxは、コード、config ファイル、コンテナ、タグなどのアーチファクトの変更をKubernetes オブジェクトのクラスタの変更と同期することができるように、”Kubernetes native” という調整したり、および通知したりするエージェントです。また“ロールバック”や“オートマチック”、“マニュアル”デプロイ（さらに言えば、例えばblue/green、カナリア・デプロイ）のようなポリシーも取得可能です。

ケルシ―氏のアプローチは、本質的により更に小さな部品に分解されます。彼は、GitからCIへの完全な例を紹介してくれていますが、Fluxオペレーターのようなプログラミングのエージェントではありません。ケルシ―氏のアプローチとFluxを合わせることで完璧で合理的なものになります。実際に私たちのKubecon のプレゼンテーションではスライド21でこのような統合を見ることができます。

ケルシ―氏が精選されたダッシュボード（彼のデモではGrafanaとなっています）の使用を奨励しているということも覚えておいてください。私たちもそれには賛成していて、よいアイデアだと思っています。また私たちのクラウドサービスの中でSlackインテグレーションと一緒にそのようなツーリングを提供することにも賛成です。

What about Secrets?

これはGitOpsについての質問で一番よく聞かれる質問です。

よいお知らせがあるのです。私たちのビットナミの友人がシールドシークレット（極秘）オープンソースプロジェクトを作りました。それは、明確にGitOpsワークフローを処理します。このシールドシークレットはKubernetes Custom Resource Definition Controllerです。これがあるのでGitの中の機密情報（いわゆる秘密）を保存することができます。これはずっとオプションではありませんでした。ビットナミのセバスチャン・ゴアスゲンによるKubeconでのプレゼンテーションはBuilding Serverless Application Pipelines（サーバーレス・アプリケーション・パイプランの構築）をご覧ください。

付け加えると、全てのオペレーションがgitベースの持続的なデプロイ・パイプランと、自身の秘密を含んだgitレポの中のアプリケーションの理想的な状態を表示させるパイプランを作るために Weave Cloud’s Deploy feature in conjunction with Sealed Secretsを使ってみてください。

What about Helm?

Helm チャートとは複雑なKuberneteアプリケーションをアトミックデプロイのために潜在的にパッケージする素晴らしい方法です。Helmについてはcool Kubecon talk by Vic Iglesias（ヴィック・イグレシアス氏によるかっこいいKubeconトーク）をご覧ください。

GitOpsのワークフローのファーストクラス・オブジェクトとしてのHelmチャートを取り扱う方法について私たちは取り組んでいます。これはとてもワクワクするような発想です。どういう内容かというと、Helmの利点、すなわちチャートのカプセル化とテンプレートと、GitOpsの利点の両方を合体させるというものです。GitOpsの利点というのは、クラスターが下に下がったときにクラスターを再構築するのを助けてくれるバージョン・コントロール・デプロイの履歴を含みます。つまり、コンテナ・イメージ・ロールアウトを反映するためのクラスター状態のアップデートのオートメーションと同じように、チャートとそのカスタマイゼーションの反映をするためのクラスター状態のオートメーションということです。アップデートなどについてより詳しくは、こちらの私たちのブログ”Helmの管理がGitOpsをリリースすること”をお読みください。

How can I get involved?

もし上の内容にご興味をお持ちならぜひ、【連絡はこちら】からご連絡ください。Blue-Green、カナリア色などのアドバンスド・ポリシーを含む事項や、ランタイムでのルーティング・コンフィグのコントロールを促すIsitoのようツール（これは例えるとアップデートに何％のトラフィックをかけるかということです）というに対しては、GitOpsはどのように処理しているのでしょうか？従来のInfra-as-code（IaC、インフラ構成をコードにしておくこと）ではデプロイ・アーティファクトは変化しないとしていますし、カナリアは変化可能なコンフィグを意味しています。同じように、将来的に私たちは多くのソフトウェア・パッケージがIstio, OpenFaaS や KubeflowのようなKuberneteアドオンのように提供されることを願っています。どのようにすれば私たちはGitOpsをインストールして、設定などの作業がほとんどせずにすぐに使える状態にできるようになるのでしょうか？