GitOps とは何か、そしてそれが (ほとんど) 役に立たない理由: パート 1

新しい航空会社で。スチュワーデスが客室に入ります。「あなたは私たちの新しい航空会社に乗りました。飛行機の機首には映画館があります。尾部にはスロットマシンのホールがあります。下のデッキにはプールがあります。アッパーデッキ - サウナ さて、皆さん、シートベルトを締めてください、そしてこれらすべての不要なものを付けて、離陸してみます。

こんにちは、私の名前はアンドリーです。私は人生のほとんどをIT業界で働いてきました。私はインフラストラクチャ構成管理エンジニアリングの進化に非常に興味があります。過去 8 年間、私はDevOpsに携わってきました。

新たな人気トレンドの 1 つは、Weaveworks の CEO である Alexis Richardson によって 2017 年に導入されたGitOpsの概念です。 Weaveworks は、2020 年に GitOps の開発のために 3,600 万ドルを超える投資を調達した大規模なアダルト企業です。

前回の記事では、Elastic Stack から Grafana に切り替えた方法に関するコスト削減の成功事例について説明しました。ここで、この概念を採用する際に待ち構える可能性がある、明白ではない課題について話していきたいと思います。つまり、GitOps は「特効薬」ではありません。おそらく、多くの複雑な回避策を講じて再編成することになるでしょう。私自身もこの道を歩んできたので、GitOps に関する他の記事を読んでもわからない、最もイライラする問題を紹介したいと思います。

コンテンツの概要

• GitOps とは何か、そしてなぜそれが必要なのか (必要ないのか)
• Snowflake サーバーの問題
• GitOps - すべての問題に対する万能薬 (またはそうでない)
• Helm で Flux を使用するロジック
• カスタムフラックスリソース
• GitOps のチェックリスト
• 単一の真実の情報源の概念の違反
• 小さな結論

GitOps とは何か、そしてなぜそれが必要ないのか

さっそく飛び込んでみましょう！

ステートレスとステートフル

今日のインフラストラクチャ構築の最も有望な概念は、不変のインフラストラクチャです。その重要なアイデアは、インフラストラクチャをステートレスとステートフルという 2 つの根本的に異なる部分に分割することです。

インフラストラクチャのステートレス部分は不変で冪等です。状態を蓄積しません（データを保存しません）。また、蓄積された状態に応じて動作を変更します。ステートレス パーツのインスタンスには、いくつかの基本的なアーティファクト、スクリプト、アセンブリが含まれる場合があります。原則として、クラウド/仮想化環境のベースイメージから作成します。これらは脆弱で一時的なものです。新しいベース イメージからインスタンスを再作成することで、新しいバージョンのアプリケーションを提供します。

永続データはステートフル部分に保存されます。これは、専用サーバーを使用した古典的なスキーム、または一部のクラウドメカニズム (DBaaS、オブジェクト、またはブロックストレージ) によって実現できます。

この「動物園」を管理しやすく、正しく機能させるには、エンジニアリング チームと DevOps チーム間のコラボレーション、および完全に自動化された配信パイプラインが必要です。

CI部分

エクストリーム プログラミングは、アジャイル開発手法の 1 つです。多くのフィードバック ループが特徴で、クライアントのニーズとの同期を維持できます。

CI/CDシステムを利用したデリバリーパイプラインの自動化を実現します。 CI (継続的インテグレーション) という用語は、1994 年に Grady Booch によって提案され、1997 年に Kent Beck と Ron Jeffries によってエクストリーム プログラミングの分野に導入されました。 CI では、変更をプロジェクトのメイン作業ブランチにできるだけ頻繁に統合する必要があります。

これには、まずタスクをより細かく分解する必要があります。小さな変更はより原子的であり、追跡、理解、統合が容易です。次に、新しく書かれたコードを単にマージすることはできません。ブランチをマージする前に、以前に動作していたものが壊れていないことを確認する必要があります。これを行うには、少なくともアプリケーションを構築する必要があります。コードをテストでカバーすることもお勧めします。

そしてこれは、開発において長い道のりを経て、その途中で CI/CD システムになった CI システムによって実行されるタスクです。

CDパート

CDとは何ですか? Martin Fowler は 2 つの CD 定義を区別します。

• 継続的デリバリー。このとき、継続的インテグレーションの実践と DevOps 文化の助けを借りて、プロジェクトのメイン ブランチを常に実稼働環境にデプロイできる状態に保ちます。

  
  

• 継続的な展開。これは継続的デリバリーであり、メイン ブランチに送られるすべてのものがクラスターや本番環境にダンプされます。

さらに進んでみましょう。

Snowflakeサーバーの問題

残念ながら、不変のインフラストラクチャにはいくつかの問題があります。その大部分は、Infrastructure as Code (IaC) の概念から継承されています。

まず第一に、それは構成のドリフトです。この用語は Puppet Labs (有名な Puppet SCM の作成者) で生まれ、ターゲット システム上のすべての変更がシステム構成管理 (SCM) の助けを借りて行われるわけではないことを述べています。一部はそれらをバイパスして手動で行われます。

このような複数の変更の過程で、構成のドリフト、つまり SCM で説明されている構成と実際の状況との差異が現れます。

これは自動化恐怖スパイラルにつながります。

手動による変更が増えるほど、SCM スクリプトを実行すると、記録されていない変更が壊れる可能性が高くなります。実行するのが怖ければ怖いほど、新たな手動編集が行われる可能性が高くなります。

最終的には、この悪質なポジティブ フィードバックがスノーフレーク サーバーの形成につながり、そのサーバーは非常に不整合になり、もはや内部の内容を誰も理解できなくなりました。手動で編集すると、ノードは降雪の中の個々の雪の結晶と同じくらい固有になります。

このドリフトにより、サーバーは不変のインフラストラクチャ内の上位レベルに残ります。これで、GCP プロジェクト/AWS VPC/Kubernetes-cluster-snowflakes について話すことができます。これは、不変のインフラストラクチャでは変更の実装が規制されていないために発生します。さらに、それを適切に行う方法を誰も知りません。

GitOps - すべての問題を解決する万能薬 (またはそうでない)

そこに Weaveworks がやって来て、「みなさん、私たちはあなたが必要とするものを持っています - GitOps です」と言います。 GitOps を推進するために、彼らは「Kubernetes the Hard Way」ガイドを作成した Kelsey Hightower のような重鎮を迎え入れました。 PR 中に、彼は「男になれ! 脚本をやめて出荷を始めよう!」というメッセージを大々的に宣伝します。そして、彼はある程度のマーケティングでたらめなビンゴを言います。

私の意見では、最も魅力的な利点は次のとおりです。

• デプロイの一貫性と標準化の向上
• セキュリティ保証の向上
• エラーからのより簡単かつ迅速な回復
• アクセスとシークレットの管理が容易になる
• 自己文書化されたデプロイ
• チーム内での知識の配布

そして、GitOps が何なのかを理解しようとしている人は、この教科書のスライドに遭遇します。

次に、GitOps の原則を見つけます。これは、IaC の原則をわずかに拡張したものに似ています。

• GitOps は宣言型です
• GitOps アプリはバージョン管理されており、不変です
• GitOps アプリは自動的にプルされます
• GitOps アプリは継続的に調整されます

それでも、これは真空中での球状の記述であるため、研究は続けられます。 GitOps.tech Web サイトには、いくつかの重要な説明が記載されています。

まず、GitOps は、これをインフラストラクチャに自動的に適用する CD ツールを備えた Git のインフラストラクチャのようなコードであることを学びます。

GitOps 内には少なくとも 2 つのリポジトリが必要です。

• アプリケーションリポジトリ。アプリケーションのソース コードと、そのアプリケーションのデプロイメントを記述するマニフェストについて説明します。
• インフラストラクチャ リポジトリ。インフラストラクチャ マニフェストと展開環境について説明します。

また、GitOps イデオロギーでは、プッシュ指向のアプローチよりもプル指向のアプローチが好まれます。これは、重量級のプル モンスターである Puppet や Chef から、軽量なプッシュ ベースの Ansible や Terraform への SCM システムの進化とは若干対照的です。

そして、GitOps が主にツールキットの話であるならば、Weaveworks 自体から Flux ベースの概念を取り出してそれを分解することは理にかなっています。アイデアの作成者はリファレンス実装を作成したに違いありません。

Flux は現在バージョン 2 であり、アーキテクチャ的にはクラスター内で動作するコントローラーで構成されています。

• ソースコントローラー
• コントローラーをカスタマイズする
• HELMコントローラー
• 通知コントローラー
• 画像自動化コントローラー

次に、Flux と Helm の作業について説明しましょう。

Helm で Flux を使用するロジック

Flux 2 の Helm パッケージ マネージャーを使用してアプリケーションをデプロイする例をさらに説明します。

なぜ？ CNCF 調査 2021によると、HELM パッケージ マネージャーは最も人気のあるパッケージング アプリケーションであり、50% 以上のシェアを占めています。

残念ながら、これ以上の最新のデータは見つかりませんでしたが、それ以来、大きな変化はないと思います。

それでは、Flux 2 が Helm とどのように連携するかという基本ロジックを見ていきましょう。アプリケーションとインフラストラクチャの 2 つのリポジトリがあります。

アプリケーション リポジトリから HELM チャートと Docker イメージを作成し、それぞれ Helm チャート リポジトリと Docker レジストリに追加します。

次に、フラックス コントローラーを実行する Kubernetes クラスターがあります。

アプリケーションをロールアウトするには、カスタム リソース (CR) HelmRelease を記述する YAML を準備し、それをインフラストラクチャ リポジトリに追加します。

Flux がそれを取得できるように、Kubernetes クラスターに CR GitRepository を作成します。ソース コントローラーはそれを認識し、git にアクセスしてダウンロードします。

この YAML をクラスターにデプロイするには、カスタマイズ リソースを記述します。

KusTOMize コントローラーはそれを認識し、ソース コントローラーに移動して YAML を取得し、クラスターにデプロイします。

Helm コントローラーは、CR HelmRelease がクラスターに出現したことを確認し、ソース コントローラーにアクセスして、記述されている HELM チャートを取得します。

ソース コントローラーが要求されたチャートを HELM コントローラーに提供するには、CR クラスターに HelmRepository を作成する必要があります。

Helm-controller は Source-controller からチャートを取得し、リリースを作成してクラスターにデプロイします。次に、Kubernetes は必要なポッドを作成し、Docker レジストリに移動して、対応するイメージをダウンロードします。

したがって、アプリケーションの新しいバージョンをロールアウトするには、新しいイメージ、新しい HelmRelease ファイル、そして場合によっては新しい HELM チャートを作成する必要があります。次に、それらを適切なリポジトリに配置し、Flux コントローラーが上記のチェーンで作業を繰り返すのを待つ必要があります。

そして、作業を終了するために、問題が発生した可能性があることを通知する通知コントローラーをどこかに配置します。

カスタム Flux リソース

次に、Flux が動作するカスタム リソースについて説明します。

1 つ目は Git リポジトリです。ここでは、Git リポジトリのアドレス (14 行目) と、Git リポジトリが参照するブランチ (10 行目) を指定できます。

したがって、リポジトリ全体ではなく、単一のブランチのみをダウンロードします。しかし！私たちは責任あるエンジニアであり、ゼロ トラストの概念を遵守しようとしているため、リポジトリへのアクセスをロックし、Kubernetes クラスター内にキーを使用してシークレットを作成し、それを Flux に渡してそこに移動できるようにします (12 行目)。

次にカスタマイズです。ここで注意していただきたいのは、Flux の KusTOMize コントローラーと Kubernetes の作者の KusTOMize は 2 つの異なるものであるということです。なぜこのような混乱を招くような名前が選ばれたのかはわかりませんが、混同しないことが重要です。

Kustomization は、YAML (任意) を Git リポジトリからクラスターにデプロイする方法です。ここでは、配置元のソース (行 12 - 前述の CR GitRepository の名前)、YAML の取得元ディレクトリ (行 8) を指定する必要があり、YAML を格納するターゲットの名前空間を指定できます。 (13行目)。

次は Helm のリリースです。

ここで、名前とチャートのバージョンを指定できます (10、11 行目)。ここでは変数値を指定して、Helm が環境ごとにリリースをカスタマイズできるようにします (15 ～ 19 行目)。環境が大きく異なる可能性があるため、これは非常に重要かつ必要な機能です。 Helm チャートを取得するソースも指定します (12、13、14 行目)。この場合、それは Helm リポジトリです。

しかし！私たちは依然として責任あるエンジニアであるため、Helm リポジトリに緊密にアクセスし、そこに到達するための秘密を Flux に提供します (7、8 行目)。

GitOps のチェックリスト

それでは、今確認した内容を把握するために、小さなチェックリストを作成してみましょう。 GitOps を開始するには、突然大量のスクリプトを作成する必要があります (Immutable インフラストラクチャとは、完全に自動化された配信パイプラインがすべてであることを覚えています)。したがって、まず最初に以下を作成する必要があります。

• イメージをビルドして Docker レジストリにプッシュするスクリプト
• インフラストラクチャ Git リポジトリ
• インフラストラクチャ GIT リポジトリへの CI システム アクセスのアカウント
• HelmRelease ファイルを生成してプッシュするスクリプト
• Helm リポジトリ
• Helm リポジトリへの CI システム アクセスのアカウント
• Helm チャートを構築して公開するスクリプト`
• インフラストラクチャ リポジトリの Flux アカウント
• Helm チャート リポジトリの Flux アカウント

これで、GitOps のチェックリストが完成しました。進む。

単一の真実の情報源の概念の違反

Helm リリースで一般的に何が得られるのかを見てみましょう。この特定のケースでは、Git が唯一の真実の情報源ではないことは明らかです。この Helm リリースが依存する、少なくとも 2 つのリソースと git の外部の 2 つのアーティファクトがあります。

• ヘルム チャート (8 ～ 14 行目)
• Docker イメージ (19 行目)

さらに物事を複雑にして、Helm チャートのバージョンの範囲を指定することもできます。

この場合、Flux はこの範囲内に表示される新しい Helm チャートを監視および設定します。さらに、当社のソース コントローラーは、S3 バンドルを含む YAML をソースとして使用できます。

そこから、YAML チャートと Helm チャートの両方を保持できます。

さらに、Docker レジストリ内の新しいイメージを監視し、インフラストラクチャ リポジトリを編集できるイメージ オートメーション コントローラーもあります。

ただし、HELM Chart リポジトリ運用や Docker レジストリ運用は必要ありません。私たちは可能な限り GitOps になりたいと考えています。そこで、ドキュメントを参照して、GIT リポジトリから Helm チャートをデプロイするプロセスを修正します (保存するアプリケーション リポジトリを選択します)。

これにより、アプリケーション リポジトリ用に別の CR GitRepository、Flux がそれにアクセスするためのアカウントを作成し、キーを使用してシークレットを作成する必要があります。

同時に、Docker イメージへの複雑な依存関係の問題はまったく解決されていません。

小さな結論

今日はこれで十分だと思います。後編では、この善良さがどのような問題を抱えているのかをお伝えします。あとで議論します：

• 複数の環境の問題
• からの値
• 秘密の問題
• CI Ops と GitOps
• 安全
• ロールバック手順
• 複数のクラスターの問題
• GitOps を本当に必要としているのは誰でしょうか?

この記事がお役に立てば幸いです!