2022年6月10日
Continuous Delivery
「GitOps」の「Git」を管理する：GitOpsのリポジトリーでコードを構造化する４つの方法
宣言型、不変型、継続的に調整可能なインフラは、GitOpsのベストプラクティスで管理することで多くのメ リットをもたらします。ここでは、これらのパイプラインで使われるコードを管理するための４つのアプローチを紹介します。
GitOpsのプラクティスを導入することで、ソフトウェアデリバリーパイプラインを次のレベルへと引き上げることができます。宣言的で、不変的で、継続的に調整されるインフラは、GitOpsのベストプラクティスによって管理されると、多くの利益をもたらします。長年にわたり、私は多くの開発チームがGitOpsのワークフローを構築し、改善するのを支援してきました。このブログでは、パイプラインで使われるコードを管理するための４つのアプローチについて紹介します。
「GitOps」の後半「Ops」は、構成コード、またはInfrastructure as Code（IaC）のことを指しています。ソフトウェアは、このコードによって管理されるリソースに依存して機能します。この構成をGitリポジトリーで管理することは、多くの利点をもたらします。多くの場合、このコードの構造 は後回しにされ、将来的に重要なリファクタリングにつながることになります。
アプリケーションとインフラストラクチャーのコードを１つのリポジトリーに
最初の例では、アプリケーションのコードとインフラのコードを同じリポジトリーで管理しています。長寿命ブランチが１つだけ存在します（main）。
例
以下はNode.jsのプロジェクトで、rootにアプリケーションコード、kubernetesディレクトリにYAMLファイルを置いています。development.yamlの変更は開発環境、production.yamlの変更は本番環境に適用されます。
メリット
- インフラストラクチャーのコードとアプリケーションのコードが同じリポジトリーにあることで、全てがバージョン管理されている。ある時点のアプリケーションと構成の状態を再現するために、複数のリポジトリー間で点を結ぶ必要はない。
- リポジトリーが１つであるため、開発者のコンテキスト切り替えが必要ない。開発者は、インフラストラクチャーのコードに変更を加える際にリポジトリーを変更する必要がない。
デメリット
- 権限分離がない。リポジトリーにアクセスできる開発者は、アプリケーションとインフラの両方のコードを変更することができる。
組織によっては、アプリケーションとインフラストラクチャーのコードを分離する必要があります。以下の例では、アプリケーションとインフラのコードをそれぞれ専用のリポジトリーで管理しています。Gitリポジトリーごとにユーザー権限を設定できるため、権限分離がうまくいきます。
独立したインフラストラクチャーリポジトリー、複数のブランチ
GitflowなどのGit分岐ワークフローをご存知でしょうか。Gitflowは、トランクベースの開発に人気が出てきたため、最近ではあまり使われなくなっています。Gitリポジトリーで複数の長寿命ブランチを使わないほうがよいというのは、それなりの理由があるからです。しかし、場合によっては複数の長寿命ブランチを使うことも検討する価値があります。
例
以下は、developmentとproductionという２つの長寿命ブランチを持つHelmチャートリポジトリーです。変更は常にdevelopmentブランチから行われます。本番環境に移行するには、developmentをproductionにマージする必要があります。開発環境では、developmentブランチにあるdevelopment-values.yamlという値ファイルが使用されます。本番環境では、productionブランチにあるproduction-values.yamlという値ファイルを使用します。
メリット
- 環境間で変更を推進する際に、設定のドリフトが発生するリスクが低い。ブランチをマージすることで、変更の取りこぼしがないようにする。
- 開発環境と本番環境での変更の権限分離が改善される。たとえば、GitHubはブランチ保護ルールをサポートしている。リポジトリーのオーナーは、どのユーザーがブランチにコミットできるかを制御できる。
デメリット
- インフラストラクチャーのコードにとって「一車線の道路」である。developmentブランチの変更は、本番環境の変更をブロックすることができる（希望する変更を選択することなく）。
インフラストラクチャーリポジトリの分離、ディレクトリーベース
さて、長寿命ブランチが１つだけ存在するリポジトリー（main）を考えてみましょう。それぞれの環境には、そ れぞれのディレクトリーがあります。
例
以下はTerraformのリポジトリーで、開発用と本番用のディレクトリーが分かれています。開発環境への変更には、developmentディレクトリーにあるdevelopment.tfvarsというtfvarsファイルが使われます。本番環境への変更はproductionディレクトリーにあるproduction.tfvarsというtfvarsファイルを使用します。
メリット
- developmentディレクトリーで行われた変更は、productionディレクトリーには影響しない。
デメリット
- 環境間のコンフィギュレーションドリフトのリスクが高まる。ディレクトリー間の違いを理解するための開発者の負担が大きい。
- 権限分離ができない。開発環境と本番環境の両方でユーザーが変更できる。
複数のインフラストラクチャーリポジトリー、環境ごとに１つ
各環境がそれぞれ専用のリポジトリーを持っている場合のアプローチを考えてみましょう。各リポジトリーには、１つの長寿命ブランチ（main）があります。
例
ここでは、Terraformプロジェクトの例として、developmentとproductionが別々のリポジトリーになっているものを示します。開発環境への変更には、developmentリポジトリーにあるdevelopment.tfvarsというtfvarsファイルを使用します。本番環境への変更には、productionリポジトリーのproduction.tfvarsというtfvarsファイルを使用します。
メリット
- 最高レベルの権限分離。Gitホストが提供する、リポジトリーレベルでのユーザー／グループアクセスに関するあらゆる機能が利用できるようになる。本番環境に変更を加える必要があるユーザーだけが、productionリポジトリーに変更をコミットできるようになる。
- 新しい環境の立ち上げや既存環境の移行が容易になる。新しい環境を立ち上げる場合、新しいリポジトリーを作成する。既存のリポジトリーと統合して新しい環境を立ち上げる必要はない。
デメリット
- 環境間のコンフィギュレーションドリフトのリスクが高い。開発者がリポジトリー間の違いを理解する負担が大きい。
まとめ
私の経験では、GitOpsのコード管理は環境ごとに１つのリポジトリーで行うのが最も将来性のある方法です。権限や環境を分けることで得られる利点は、潜在的な欠点を上回ります。将来的に分離が必要ないと判断した場合は、複数のリポジトリーを１つにまとめることができます。どの方法を選んでも、Harnessの製品群は全てサポートしているのが良い点です。
Harness CIによる構築、テスト、アーティファクトの公開、Harness CDによるデプロイ、Harness GitOps（現在ベータ版）によるパイプラインのレベルアップなど、Harnessはあらゆるニーズに対応します。また、全てのHarnessパイプラインは、ガバナンスやカオスエンジニアリングなどの先進的な機能を利用することができます。
GitOpsの旅を加速させるHarnessの魅力をご覧ください。14日間の無料トライアルに登録し、Kubernetes CDクイックスタートガイドに従って、アプリケーションをクラスターにデプロイしてください。ガイド付きツアーをご希望の場合は、デモをご予約ください。
フォーラム、コミュニティーSlack、またはHarness & Drone User Groupのバーチャルミートアップで、ご質問にお答えします。
この記事はHarness社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。