The GitOps Pipeline — Part 2

Published in

Orangesys

17 min readNov 12, 2018

GitOps — Operations by Pull Requestの続き、GitOpsのPipelineを説明します。

TL;DR

これは私のGitOpsについての２回目の投稿記事です。GitOpsは「Git Ops」を短くしたものです。GitOpsは」Gitを使ったOpsプラクティスのセットの名前です。この名前はDevOpsのような精神を受け継いでいます。と言うのも「商品」とうよりはむしろ「誰もが使える」というコンセプトを基本にしています。プルリクエストによる GitOps — Operations という記事を読んでいただくとより理解が深まると思います。この記事はGitOpsシリーズの一番最初の記事です。

What is GitOps

GitOpsはContinuous Delivery（継続的なデリバリー）を可能にします。GitOpsはdeclarativeインフラストラクチャーやアプリケーションのための信頼できる情報源としてGitを使いながら機能します。ロールアウトの変化がGitに起こるとき、Automated delivery pipeline(自動化されたデリバリーパイプライン)の自動的なロールアウト変化が自分のインフラストラクチャーに起こります。しかし、そのアイデアはもっと広がります。実際のプロダクション状態を見るツールを使って、ソースコードが現実世界とマッチしないときには教えてくれるのです。そして適宜、その違いを指摘し、問題を修正できるようになります。言い換えれば、GitOpsはシステムの監視とコントロールのためのfeedback ループと共にパイプラインを広げるということです。

Weaveworksでは、私たちは自分たちの商品であるWeave Cloudの中でこの原理を実行しました。これは、お客様がアプリをより素早く購入するのに役立つためだけではなく、自分たちのクラウドネイティブ・スタックを走らせるためにも役立ちます。私はどうやってこれを成し遂げたかを見てもらいたいのです。これは本当にベストプラクティスでありベストツールです。そして、Weaveworksの使用例もお見せしたいと思います。この投稿ではGitOpsのパイプラインについてお話したいと思います。また公判ではGitOpsの可観測性、フィードバックやコントロールについても言及しようと思います。

Wait, but why GitOps?

GitOpsはデベロッパーたちにオペレーションをする権限を与えます。

そのためには、GitOpsは難しいこと（例えばオペレーションマネジメントやモニタリングなど）をするための見慣れたツールをアプライすることでデベロッパーたちの生産性を上げることを目的としています。それぞれのデベロッパーはGitを使うことができますし、プルリクエストを作ることができます。つまりデベロッパーたちはGitを使ってKubernetesのためのオペレーション・タスクを促進したり、シンプルにしたりすることができるということです。

この利点は広範囲にわたります。

cloud ネイティブ CICD パイプラインのためのモデル
デプロイするための平均時間と、リカバリーのための平均時間を早める
すぐに利用できるアラート
安定したロールバック（リバート/ロールバック/Gitごとのフォークなど）
理解しやすい首尾一貫した、観察、管理アプリ

GitOps is Continuous Delivery meets Cloud Native

新規性は主張できません。というのもGitOpsのアイデアはDevOpsとSite Reliability Engineeringから発想を得ています。そしておそらくマーティン・フォウラーのContinuous Integration overview in 2006（継続的インテグレーションの概要2016）から始まりました。ある意味GitOpsは最新のコンセプトだということでしょう。また私たちはimmutable infrastructure（イミュータブルインフラストラクチャ）とdeclarative container orchestration（declarative コンテナorchestration）などの動きの方へ向かっても構築しています。このことについては後ほどお話します。また時間があれば、「事前に読んでいただければ分かりやすい内容」を読んでみてください。

デプロイ後、私たちはその変化に対するリスクを極力減らしたいと思います。そのデプロイが意図的なもの、もしくは「コンフィグドリフト」を通してのものであれ・・・。そして私たちの全てのシステムの望ましい状態がきちんとGitの中で表示されてほしいと思っています。コンテナとクラウドネイティブツール(list of CNCF projects)は私たちがそのために必要なもののほとんどを提供してくれます。どのレートにおいても、それは機能します。Weaveworksはほぼ２年間、その機能を証明するために、私たち自身のプロダクションであるKubernetesスタックを伴ったGitOpsを使っています。それでは話をWeaveworksツールと、どのようにパイプラインを使うかという内容に映りましょう。補足：バックグランドとして、それは上のリンク先の記事を読んでいただくと分かるようにジェズ・ハンブルのFoundations of Continuous Deliveryから始まりました。私たちはその原理を基に構築しています。

GitOps: Pipelines intro

私は Weaveworksで私たちが取り組んでいることについてお話したいと思います。そしてどうやってAWS上のWeave Cloud デプロイに変化をロールアウトするのかをご紹介します。私たちの端から端までつながったパイプラインは直接クラスターとつながっていて、ビルド、デプロイ、管理、ライフサイクルのモニターというそれぞれの工程を網羅しています。私たちはコンテナだけをデプロイします。そして私たちの全てのワークロードはコンテナ化されます。（詳しくは後ほど説明します）

Weaveworksのパイプラインは普通にみんながやっているのとは少し違います。その理由を探るため、一般的なデリバリ―パイプラインを見てみましょう。

ＣＩはテストを行う：アウトプットはコンテナ・イメージデポジトリーに送られる
ＣＤシステムは自動的にコンテナをデプロイする（もしくはマニュアルの通りにリクエスト上で）

ダイヤグラムで表示するとこのようになります。

Choose your own CI — and other pipeline tools

Weaveworksでは、私たちは上のようなコンポーネントも使います。次の章でもまた大切なことを説明します。

私たちの今のツールチェーンはバージョンコントロールためのGitHub、Weave CloudのＣＩビルドのためのCircleCI、内部イメージ・レポジトリのためのQuay.io、デプロイのためのWeave Flux、orchestrationのためのKubernetesです。これに接続しているのはデータストレージと可観測性スタックです。それを簡単に示したのが以下の図です。

いい知らせがあります！GitOpsにはどのCIシステムも使えます。例えば顧客のチュートリアルたのためには私たちはGitLabを使っています。これはコードとビルドをひとまとめにしてくれます。他のCIツールを使えないということはありません。Jenkins, TravisCI, Shippable また Google Container Builderもいいと思います。

GitOps: Automated git → cluster synchronisation

ここはとても重要なところです。デプロイとrelease automationはどのように私たちがGitOpsを使っているか、そしてどのようにデリバリーパイプラインを動かしているかの基本になります。このため、私たちは新しいツールWeave Fluxを作りました。Weave FluxはGitOpsにデプロイを可能にし、ネイティブのようにKubernets上のデプロイを管理する方法を理解しています。Weave FluxはステージングとKubernetesへのコンテナのリリースを自動化するツールです。サービス、デプロイ、ネットワークポリシー、Istioルーティングルールなども同じく自動化します。それゆえFluxはコード、サービス、実装中のクラスターの間の全ての関係を地図化する「接着剤」の役割を果たしています。Fluxはよりスリムです。つまり、SpinnakerへのKubernetes-nativeの代案となるということです。

GitOpsの中のFluxを思い出してみると、プロダクション環境のなかのどの変化（バーチャル・インフラストラクチャーからアプリケーション・デプロイ）もプルリクエストを通して変化しています。もしあなたがGitクラスターの同期をサポートするツールを使っているのなら、それは役に立つし、だからこそ、それはバージョンコントロールされたシステムとdeclarativeアプリケーションスタックのためにデザインされているのです。Fluxの主な特徴はautomated synchronization（自動化された同期）です。それは自分のレポジトリーに何らかの変化があるかどうかを確認してくれます。その変化は自動的に自分のクラスターにデプロイされます。最初の方で述べたようにこれはシンプルだけど, 現段階で最新の素晴らしい改善です。

The GitOps Pipeline

こちらに新しいダイアグラムがあります。全てのデプロイのアップストリームがGitによって固定されているということが分かります。そのデプロイコンポーネントは今２つのパートに分かれています。それは新しいビルドを監視し、新しいリリースを作るためにコンフィグをアップデートする Flux automator ともう一つはorchestrator が正常な状態にあるかを確認するFlux synchronizerです。前述の「簡素化された」ダイアグラムとの違いに注意してください。下のこのダイアグラムは私たちの実際のパイプラインを示しています。

Delivery Orchestration: why GitOps is not CI-Ops

Sidebar！

GitOpsはデリバリーorchestrationのためにCIの相対的インポータンス（相対的重要性）を変えます。例えばコード・トゥー・プロダクション・パイプライン所有し、駆動することです。主な継続的デリバリーはパイプラインのdesign centreでCIを入れ込み、GitとCDをサーバント・コントロールとして扱います。この図では、Gitはサービスであり、ビルドのためにインプットを取り込むCIに使用されています。同様にCDはプロダクションへのビルド・アーティファクトをプロモートするCIによってパワーをもらった実装拡張です。例えば、CIツールはCIジョブの中にはめ込まれたスクリプトを使うと思われます。そのため、主な見方をすれば「CIはデリバリー・orchestrationを持っている」ということが言えます。

GitOpsパイプラインのモデルの中で、Gitはdesign centreです。Gitは「システムの中の全てのものに対する信頼できる情報源」という役割を果たします。それはコード、コンフィグ、フルスタックです。CI（ビルドとテストサービス）はデプロイ可能なアーティファクトの構築のためには必要です。しかし、GitOpsのパイプラインの中では、デリバリーの全体のorchestrationはデプロイによってコーディネートされていて、自動化されたシステムをリリースします。レポジトリーへのアップデートが引き金になります。要約すると、CDはCIではなくデリバリーorchestrationを持っているということです。どのようにパイプラインが機能するかにおいてのわずかなシフトですし、どんなCIプロバイダーも受け入れ可能です。

GitOps: Only deploy containers & config

あなたのビルドシステムがコンテナイメージを統合し、そしてコンテナイメージレポジトリーから自分のクラスターにそれらをデプロイすることをお勧めします。なぜコンテナはそんなに重要なのでしょうか。Weaveworksではimmutable server pattern（不変のサーバーパターン）を使っています。一旦コードがGitの中でコミットされたら、他は何も変更したくはありません。システムの予定された状態からの分散のリスクを最小限に抑えたいと思っています。もしデプロイアーティファクトがdebとprodの中で同じならこのように役に立ちます。そしてコンテナはこれを保障する1つの方法です。VMsを使うのもよいでしょう。でもコンテナを使うことで、この全てをより簡単に、そしてより正確に実行できます。Weaveworksの内部ではDocker containers, やQuay.io for our image repositoryを使っています。私たちのWeave Cloudプロダクトはどんなコンテナレポジトリー（例えばDocker Hub, GCRなど）とでも機能します。

GitOps recommendations for container orchestration

GitOpsの中ではすべてのシステムがdeclarativeに表示されてほしいと思うでしょう。それにはクラウドネイティブツールがすごく便利です。

Orchestration：自分のアプリケーションが成長するにつれKubernetes や Docker Swarmのようなdeclarativeなプラットフォームを使うのがもっと簡単だということが分かるでしょう。declarativeなプラットフォームは全てを「config snowflakes」を使ってするのではなく、orchestrationの自動化、そしてシステム化をするために使います。
Idempotent installation「冪等性（べきとうせい/idempotence）インストール：kubeadm (もしくはkops や kubicorn)のようなツールはGitOpsのための必須なidempotent Kubernetes インストールを提供してくれます。もしくはGKE, ECS, ACSのようなクラウドサービスを使います。WeaveworksではidempotentインストールのためにAnsibleを使っています。
Resources：前回の投稿でも説明したように、私たちはリソースを提供するためにTerraformを使っています。

Selecting a Git provider

Gitは管理、トラックシステムの変更、その変更のロールアウトやロールバックのために必要です。Gitはそれらの特徴をコメントを含む監査証跡を伴ったバージョン管理された信頼できる情報源を通して提供します。しかしGitはそれ自体十分ではありません。以下のような時の場合はGitプロバイダーが必要です。

自分の信頼できる情報源が確かである。自分の今の状況（コード、コンフィグ、コメント）が有効で、自分のチェンジログが失われないでしょう。
ユーザー名、認証、承認、チーム、個人・公共のレポジトリー、プルリクエストコラボレーションなどのユーザーのフレンドリーな社会的な特徴。これはGitをもっと人間にとって分かりやすく、チームワークで動けるようになります。
GitをビルドやCI,デプロイ管理、イメージレポジトリー、またおそらく許可や署名などに関わるもっと大きなワークフローに統合するスタンダードなウェブAPI

私たちはGitHubを使います。GitHubはデベロッパーがチームで作業すること、また顧客への共感やチーム内での共感をサポートしてくれます。GitHubはただのソースコードレポジトリーではありません。それは変更を管理するためのソーシャルツールです。それはBitbucketやGitLabも同じです。何か自分が使いやすいものを選んでください。

Summary

今で以下のような場合の対処法について説明してきました。

Gitはコードと全てのコンフィグやそれに関連したスタックのための信頼できる情報源です。私たちがdeclarativeなインフラストラクチャーを保持しているときにのみ機能します。
CDツール（私たちの場合で言えばWeave Flux)によって引き起こされるプルリクエストやorchestrationであるGitOpsパイプラインが存在します。CIやコンテナレポジトリーはそれをサポートする役目をしています。
コンテナは不変性のためのデプロイのユニットです。GitOpsはPaasに似ているということに注意してください。しかし私たちはコードや端から端までのパイプラインを利用するかもしれないコンテナをサポートする全てのアーキテクチャーやコードではなく、コンテナやdeclarativeコンフィグをお勧めします。

結果として開発者はGitHubの中でコードをアップデートしたり、プルリクエストとしてプロダクションの中にリリースしたりすることができます。デプロイは実装中の（orchestrated）クラスターへのGitからのsyncです。その反対はあるかどうか？これに関しては次の投稿（可観測性とコントロール）で見ていきます。「たぶん」ですが、以下のダイアグラムが現実になるところまで来ています。

Weave Cloud

Weave Cloudは開発者たちにGitOpsの統合をする権利を与えます。デプロイ、自動化、モニタリング、opsマネージメントができるようになります。Weave Cloudを通してもしくはGitのみを使って開発者たちがKubernetesアプリを変更するところの動画を参考にして頂いてもいいと思います。

GitOps and App Dev Culture

GitOpsは10年～15年前のベストプラクティスから受け継がれてきました。今日ではクラウドネイティブがそれらをもっと適切にしています。以下、Adrian Cockroft’s piece on CNCF and AWSからの引用です。

「クラウドネイティブアーキテクチャーはオンデマンドデリバリー、グローバルデプロイ、弾力性、そしてハイレベルのサービスを完全に利用しています。それらは開発者の生産性をものすごく向上させました。そしてビジネス・アジリティ、スケーラビリティー、可用性、ユーティライゼーション、コスト削減の面でも大きく進歩しました」

これは開発者たちがこれらのプラクティスを採用することで直接的にビジネスに影響したということを意味しています。そして、Gitの周りのチーム/ソーシャルプラクティスとともに、その現代のアプリケーションの開発者は変更する管理者です。ビジネスやテクノロジーは絶え間なく変化しています。そして恐らく「流動性がある」と表現されるでしょう。

このビジネスは開発者たちが端から端までのデリバリーを保持する必要があるビジネスです。それと共に作業責任も伴ってきます。誰もがするまで、ますます増えています。Lyftのマット・クレイン氏の言葉を引用をすると「誰もopsをやりたくない。でもopsをしいないといけないんだ。」ということです。そのためにGitOpsがあるのです。

原文

Orangesys.ioでは、kuberneteの運用、DevOps、監視の手伝いをさせていただいています。ぜひ私たちにおまかせください。