GitOps — Operations by Pull Request
TL;DR
GitOpsシリーズの続き、gitopsの プルリクエストを紹介します。
Weaveworksでは、デベロッパーたちがWeave Cloud SaaSを操作する責任を担っています。 “GitOps”というのは作業するためにどのようにデベロッパーツールを使おうかという考え方の名前です。このブログではGitOpsについて詳しく説明したいと思います。GitOpsは90％がベストプラクティス、そして10％が私が構築する必要があった、かっこよくて新しいものでできています。このブログの内容は私たちの取り組みに関するもので、読者の方の中にも私たちの意見に反対される方がもちろんいらっしゃると思います。ただそういう反対の意見も当然あってしかるべきだと思っております。
Gitは全てのデベロッパーのツールキットの1つです。この投稿で概要を説明したプラクティスを使うことで、デベロッパーたちはGitを通してKubernetesを操作します。実際、私たちはGitOpsを使って‘cloud native stack’全体とアプリケーションの全てを管理し、モニターしています。すごくナチュラルで、学んでいてもプレッシャーを感じないとてもシンプルなツールです
Git as the Source of Truth
信頼できる情報源としてのGit
２年前から、私たちはアマゾンのウェブサービス上で、マルチプルKubernetesクラスターとPrometheusテレメトリー・データベースを走らせています。それに関しては“プロビジョンとプロダクションのライフサイクル 準備が整ったKubernetesクラスター”を読んでください。
それでは一体GitOpsとは何なのでしょうか。Gitを信頼できる情報源として使うことで、ほとんど全てをオペレートすることができます。例えば、バージョンコントロール、履歴、部門内レビュー、ロールバックなど、kubectkeのようなツール周辺のポークを必要としないGitを通して起こった事象などを操作することができます。
・私たちのAWSリソースの提供とdeclarative（宣言的）なk8sのデプロイ
・私たちの全体のシステム状態がバージョンコントロールされ、シングルGitレポジトリーの中で表示される
・オペレーションチェンジがプル・リクエストによって作られる（プラス・ビルドとリリース・パイプライン）
・Diffツールは違いを発見し、スラック・アラートを通して知らせてくれる。そしてsyncツールは収束を可能にしてくれる。
・ロールバックとオーディト・ログがGitを通して提供される。
GitOps Alerts — an example
新しいチームメンバーが待機しているチームに何も告げずにプロッドするためのサービスの新しいバージョンをデプロイするということ。私たちのdiffツールは「走っているもの」と「その動作にコンフィグされるもの」とは一致しないということを発見しました。（例えば、Gitレポジトリの中での特定のイメージはプロダクションの中のデプロイしたものとは違うものだということです）そのdiffツールはアラートを発動します。その待機中のエンジニアはこのことについて質問してから、変更するかどうか決定します。
Declarative tools love using Git as source of truth
Kubernetesは“declarative”な多くの新しいツールの中の一例に過ぎません。“declarative”というのはコンフィグが指示ではなく、事実に基づいて保証されているということです。例えば、「10個のレディースサーバーを開始して、それが機能しているかどうか知らせてくれる」というのではなく、「レディースサーバーが10個ある」ということです。
declarativeツールを使うことで、コンフィグファイルのセット全体がGitの中でコントロールされたバージョンになることがあります。これはGitが信頼できる情報源であるということを意味しています。またそれはコードレビュー、コンフィグファイルの中のコメント、コメントメッセージやPRの中に出てきたリンクなどを取得できるということです。この状態のおかげでシステム（とシステムの背後にある原因も！）発見できるようになり、オペレートしやすくなり、リカバリーや観察も簡単にできるようになります。実装するのと同じように、開発の意向を理解する手助けをするためにバージョン・コントロールされたユーザーストーリーを含めて考えることもできます。
Kubernetesの場合、私たちはバージョンコントロールを使います。コードのためだけではなく、Kubernetesデプロイを設定するYAMLファイルのためや、サービス、DaemonSetsなどのために使います。また私たちはアマゾンでKubernetesを機能させるためにTerraformやAnsibleを使います。TerraformやAnsibleもまたGitの中でバージョンコントロールされています。
What if my system diverges from the source of truth?
Declarativeなプロビジョニング・ツールはかっこいいんです。Gitの中の自分たちが欲しい本当の状態を表示してくれるんです。でも、Declarativeなプロビジョニング・ツールは稼働中のシステムのなかで「本当に今正しいのは何か」ということを見極めることに苦労しています。それはソース・コントロールの中で表示されたものとは違う可能性があるのです。どのように私たちは、いつその稼働中のシステムが自分たちが欲しい状態に収れんされたかを知ることができるのでしょうか？「炭鉱の中のカナリア」は私たちに何か問題が起きた時に教えてくれるのでしょうか？そのシステムと状態との融合をどのように引き起こせばいいのでしょうか？
ここには先行技術があります。Chef, Puppet や Ansibleなどのようなツールは“diff alerts”.のような特徴をサポートします。それらはオペレーターが、可動中のシステムと予定された状態（コンフィグ・スクリプトによって設定されるような）とが「融合」するようにいつアクションを起こす必要があるのか知らせてくれます。そして最近、ベストプラクティスは不変のイメージ（例えばコンテナなど）をデプロイし、分離しないようにすることです。
“GitOps”モデルの中で、私たちは分離と融合を解決するためにGitを使います。実際の状態と意図的に比較する“diff” と “sync”ツールに補助されています。より詳しい内容はこちらをお読みください。.
Essential GitOps tools
ここでは、Weaveworksツールについて話をしたいと思います。ここでは軽い導入部分だけお話します。より詳しい内容は二回目の投稿でお話します。
私たちの製品であるWeave CloudはGitOpsパターンを使ったクラウド・ネイティブ・アプリケーションのためのツールを提供してくれます。そのGitOps機能のコアはCICDツーリングです。私たちにとって、重要なポイントは持続的なデプロイ（CD）とマネージメントのリリースです。これは私たちのオープンソースプロジェクトWeave Fluxのベースになっています。Weave Fluxは、Git-clusterの同期をサポートします。そして、バーョンコントロールされたシステムとdeclarativeアプリケーション・スタックのためにデザインされています。
付け加えると、私たちは３つのメイン’diff’ツールを持っています。それはkubediff, ansiblediff, terradiffです。それそれがデプロイされた環境の中で走っているものと最新のGitを比較します。このように、私たちはそれらのツールをdevクラスター上で走らせます。それはGitとdevの間のdiffを見るためです。そしてGitとプロッドの間のdiffを見るためにプロッドクラスター上のツールを走らせます。”is there a diff゛のために Prometheusメトリックが存在します。このメトリック・ファイルは、もし1時間以上diffが存在したら（もしくはそれに似たような状況であれば）、急に警告を発動します。
例えば：
kubediffはコマンド・ライン・ツールです。それは、自分の実装中のコンフィグと自分のバージョンコントロールされたコンフィグを表示します。もしその二つに違いがあれば、non-zero exit コードを取り戻します。（これはKubernetes InfrastructureをPrometheusでモニタリングすること ”からの引用です）
ではなぜこれが問題になるのでしょうか？このようなことが起こらなければ、小さいアドホック変化は徐々に構成されていきます。そしてもう「そのシステムがどうなるべきか」と「今どういう状況か」ということの違いを見分けることができなくなります。―あなたは何が計画的なもので何がそうではないのか分からないということです。またそれは、Gitレポジトリの中にあるものは何であれ古くなってしまうということを意味します。
使用例：あるエンジニアがパフォーマンスを上げるように新しく変更をしたのをテストしようとdev上のフラッグを変えます。エンジニアは実験をして、結果を収集します。でもそれから、フラッグをリセットするのを忘れます。幸運にも、スラックの中のアラートのポップアップが30分後、クリーンアップをするようにと知らせてくれます。
GitOps is a way to manage systems like Kubernetes
それでは今までの内容をまとめましょう。その使用例は私たちがKubernetesを含んだフル・クラウド・ネイティブ・スタックを提供しているところです。 こういう状況でフルライトアップの中にセットアウトする時:
そのここで紹介したシステムは、システムの全ての状態がバージョンコントロールの中に保存されることを可能にします。そしてその状態がチェックされ3つのジョブ（erradiff, ansiblediff ,kubediff）によって実施されることを可能にします。クラスターのための全てのコンフィグ・ファイルはバージョンコントロールされたもの、ゼロ 休止時間でロールアウトされるコンポーネントへの修正です。もしそれらが何かを壊したら簡単にロールバックします。私たちは、Google SREの言葉“100マイル走ったらレーシングカーのタイヤを変える”. に応えようとしています。
Recovery from total wipeout of your system
それでは、どのようにGitOpsアプローチが私たちの役に立ってきたか詳しく話をさせてくれませんか。
場面：2016年春、ロンドン。和やかな朝です。太陽がまぶしく輝いて、鳥のさえずりが聞こえます。
「私は、私たちの全てのシステムをワイプアウトするであろう変更をしようとしている」
「トム、本当にやるつもりかい？」
＜クリック＞
「おっと、AWS上のKubernetesクラスターを全部消してしまったよ」
トータルシステムワイプアウトからのリカバリーはその日その日の失敗を修正するのとは違います。それでは次に何が起きたのでしょうか？チームがシステム全体の完全な再構築をするには45分かかりました。これはマルチプル AWSサービス（つまりEC2 AMIs, ELBs, SQS, DynamoDBなど全ての私たちのKubernetesクラスターとアプリケーション、そして全体の監視可能なスタックのことです）のセットアップを含む時間です。45分というのは、とてもいい結果です。“GitOps”によって可能になりました。（Kubernetes をAWS上で走らせる方法 と知っておくべきこと を読んでみてください）
私たちのワイプアウトの話から、リカバリーする間の時間のための最適化（MTTR）をすることが、どれだけ重要かということが分かると思います。これは、顧客の満足度にもつながります。もし私が、TwitterでBrian Hatfield の引用をするとすれば、素晴らしい運用のプラクティスは“頻繁な反復と顧客への高い評価”につながる、ということです。
GitOps makes life easier
それでは、まとめに入ります。
Weaveworksでは私たちのミッションはデベロッパーたちに運営権限を与えることです。
Gitは開発においてアートの状態をもっと前に進めました。ここ１０年でのベストプラクティスでは「コンフィグはコードであり、コードはバージョンコントロールに保存されるべきである」と言われています。今Opsへ利益に対するの対価を払っているところです。Weaveworksでは、私たちは実装中のシステムを変更するよりも、プル・リクエストを通してプロダクションの問題を修正する方がいいということを発見しました。
それが自分のアプリケーション・クラスターを理解しやすく、そして使いやすくするしない限り、この問題は全く問題にならないということです。GitOpsプラクティスはKubernetesとクラウド・ネイティブアプリケーションをもっと簡単にしてくれました。私たちは、絶対にあなたたちにもそう思ってもらえると信じています。そのツール自身はとてもシンプルです。私たちは、そのツールを私たちのプロダクトWeave Cloudとして作りました。
今後のこのブログでは、私は、GitOpsの原理、そして「GitOpsの使い方」などをご紹介していこうと思っています。コンテナやCDパイプライン(The GitOpsパイプライン — Part 2)、バージョンコントロールされたなどの使い方も含めた内容をアップしていく予定です。またGitOpsは、既存のアプローチの繰り返しであるかについて詳しく説明します。DevOps, 「コードとしてのインフラストラクチャー」などについてお話しましょう。ぜひこのブログを楽しみにしていてください。
Orangesys.ioでは、kuberneteの運用、DevOps、監視の手伝いをさせていただいています。ぜひ私たちにおまかせください。
