VonageのGitHubアクションによるGitOpsワークフロー

私たちは最近、Vonage Contact Center プラットフォームをサポートする重要なビルドとデプロイのパイプラインを再設計しました。この機会に、このパイプラインをセキュリティに準拠した GitOps 設計に移行しました。このブログ記事では、GitOps の意味と、このコンセプトの恩恵を受けるために私たちのパイプラインがどのように再設計されたかを説明します。

ギトプスのコンセプトそもそもGitOpsとは？

大まかに言えば、GitOpsはDevOpsとセキュリティのベストプラクティスのコラボレーションである。DevOpsとGitOpsの主な違いは、SCM（ソースコード管理）、通常はGitにプロジェクトのコードと一緒に保存されるIaC（Infrastructure as Code）が加わることだ。

GitOpsは、個別のソフトウェア・パッケージやツールではなく、フレームワークだ。これはGitOpsの強みの一つだと私は考えている。GitOpsを使えば、あなたの組織に最適なように実装を調整し、プロセスを強化する自由と柔軟性がある。

GitOpsは3つの異なるコンセプトで構成されている：

1.コードとしてのインフラストラクチャー（IaC）

IaCツールは、インフラストラクチャを一度設計・構成すれば、繰り返しデプロイできるようにし、ライブリソースが元の構成からずれるのを防ぐ状態管理機能を備えている。一度定義すれば、この構成データはソース管理下に置くことができ、インフラ（および関連する権限とセキュリティ・ポリシー）の真実の単一ソースを維持することができる。

さらに、うまく設計されたリポジトリ構造によって、最小特権と職務分掌のセキュリティ概念は、このデータに対して容易に達成される。

2.プルリクエスト (PR)

すべてのコード変更はPRによって管理されるべきである。この保護は、アプリケーション・コードだけでなく、サポートするインフラを記述するIaCコードにも適用される。

開発者は、PRを通じてアプリケーション・リポジトリにコードをマージする権限を持っているべきだが、GitOpsパイプラインやインフラストラクチャ・リポジトリを更新する直接的な権限を持ってはならない。

3.継続的インテグレーション/継続的デリバリー(CI/CD)

GitOpsは、継続的インテグレーションとデリバリーによってCI/CDプロセスを自動化する。CIはメインブランチへのプッシュによってトリガーされる。デプロイは、手動または品質チェックが正常に完了した後に自動的にトリガーされる。

GitOps を使えば、セキュリティ・テストを SDLC（ソフトウェア開発ライフサイクル）にもっと簡単に統合することができる。さらに、反復サイクルがずっと速くなるため、セキュリティの採用がより簡単になり、摩擦が減ることになる。これは、一般に「左遷」と呼ばれる、検知よりも予防に焦点を当てることを奨励する。

GitOpsの導入方法

コンテクスト

私たちの目標は、Micro-FrontEndコンポーネントをVonage Contact Centreのクラウドホスト環境にデリバリーするためのGitOps CI/CDパイプラインを構築することでした。このパイプラインは以前のバージョンからの置き換えで、開発の摩擦とデプロイ時間を大幅に削減し、セキュリティを向上させ、結果としてDevEx（開発者エクスペリエンス）を向上させる設計が必要でした。

リサーチと要件

GitOpsに実際に触れるのはこれが初めてだったので、私たちはGitOpsフレームワークについて初期調査を行い、いくつかの異なるアプローチを試すためにスパイクを実行しました。私たちの要求の性質と仕事上の避けられない制約を考慮して、私たちはGitHub Actionsのイベント・ドリブン・モデルとクラウド・ネイティブCLIツールの組み合わせを採用し、クラウドでホストされたインフラ（この場合はCDN、サーバーレス・コード機能、NoSQL DB）への更新を制御できるようにすることにしました。私たちのGitOpsアーキテクチャでは、必要なイベントは1つだけだ。アプリケーションのデプロイは、アプリケーション・リポジトリから発信されるGitHub repository_dispatchイベントによってトリガーされ、GitOps リポジトリに送られます。

GitOpsが実行可能なソリューションであると確信した後、私たちは要件を絞り込んでいきました：

• 最小限の特権（Least Privilege）と職務の分離（Separation of Duties）の原則を遵守することにより、セキュリティ態勢を改善する。

• 開発者へのタイムリーな配備フィードバックの提供

• デプロイの摩擦を減らし、デプロイ時間とDevExを改善する

• 配備メトリクスのサポート

• メンテナンス可能なGitOps CI/CDパイプラインの使用

• 水平スケーラビリティ（GitOpsパイプラインへの新しいアプリケーションのシームレスな統合）

• 社内ツールを活用し、強化する。

GitOpsアーキテクチャ

インフラストラクチャー・レポジトリ

Terraformは、MFEコンポーネントがホストされるクラウドインフラストラクチャの展開と管理のために選択したツールだ。このIaCアプローチは、頻繁に変更されないインフラストラクチャをコントロールするのに便利だ。

MFEコンポーネントをホストするために必要な各リソースは、必要なセキュリティとパーミッションのオブジェクトとともにTerraformモジュールに取り込まれた。これらのコンポーネントを維持するために、既存のTerraform CI/CDパイプラインが使われている。

アプリケーション・レポジトリ

開発者（およびMFEアプリケーションリポジトリ自体）は、開発ツールやシステムに対して狭い権限しか持っていません。そのため、Github Actionsを使用して定義されたCIワークフローがこれらの責任を引き受け、テンプレート化された自動化されたプロセスで古典的なビルドと品質機能を提供します。このプロセスによって生成されたビルド成果物は、パッケージリポジトリ（jFrog Artifactory）にプッシュされます。

Application CI Workflow

同じリポジトリにあるCDワークフローは、開発者にアプリケーションをデプロイする機能を提供する。具体的には、GitHub repository_dispatchイベントがターゲットの GitOps リポジトリに送信され、その後に完了待ちのステップが続きます。

アプリケーションのデプロイをトリガーする GitHub アクションの例：

- name: Deploy MFE ${{ env.MFE_NAME }} version ${{ env.MFE_VERSION }} to ${{ env.MFE_ENVIRONMENT }}
  uses: peter-evans/repository-dispatch@11ba7d3f32dc7cc919d1c43f1fec1c05260c26b5 # v2.0.0
  with:
    token: ${{ secrets.GITOPS_GITHUB_TOKEN }}
    repository: ${{ env.GITOPS_REPOSITORY }}
    event-type: deploy-mfe-trigger
    client-payload: '{
                        "type": "deploy-mfe-trigger",
                        "timestamp": "${{ env.DATEANDTIME }}",
                        "user": "${{ github.actor }}",
                        "mfe": "${{ env.MFE_NAME }}",
                        "version": "${{ env.MFE_VERSION }}",
                        "environment": "${{ env.ENVIRONMENT }}",
                        "cache_invalidation_keys": "${{ env.CACHE_INVALIDATION_KEYS }}",
                        "repository": "${{ github.repository }}",
                        "ref": "${{ github.ref }}",
                        "sha": "${{ github.sha }}"
                    }'

Application CD GitOps Workflow

GitOps IaCリポジトリ

このリポジトリはGitOpsフレームワークの基盤を形成する。特定のクラウドプロバイダーにデプロイするために必要なパーミッションを持っています。このリポジトリはMFEアプリケーションのリポジトリから分離されており、最小特権（Least Privilege）と職務の分離（Separation of Duties）というセキュリティの原則を遵守していることに注意してください（セキュリティを左遷することも同様です）。

デプロイメント・イベントはアプリケーションCDワークフローから受け取られ、自動的に処理される。要するに、GitOpsプロセスには3つの異なるステップがある：

1. プロセス GitHub repository_dispatchイベント

   1. 受諾/拒否

   2. イベントのメタデータに基づいてIaCの設定を更新する。

   3. PR

2. PRを自動的にマージする

   1. 品質チェックを行う

   2. 品質チェックに合格したらPRをマージする

3. アプリケーションのデプロイ

   1. ビルド成果物をクラウドストレージにコピーする

   2. DBテーブルの更新

   3. CDNキャッシュの無効化

GitOps Operations Deployment Workflow

クラウドインフラ展開ツール

私たちは、クラウド・プロバイダーとのインターフェースを持ち、アプリケーションのシームレスなデプロイを可能にするCLIツールを作りました。

デプロイ・ロジックをこの新しいCLIプロジェクトに抽象化することで、デプロイ・ロジックのきめ細かな詳細を管理できるようになり、同時に新機能を本番パイプラインにリリースする前に確実にテストできるようになりました。

Micro-FrontEndプロジェクト・フレームワークCLI

これは、複数の言語で開発するためのCI/CDフレームワークを提供する社内ツールです。スケルトン・コンポーネント・コード、共通設定オプション、CI/CDパイプライン・テンプレートなどを提供します。様々な言語のランタイムとコンポーネントタイプをサポートしています。

新しい MFE を作成する際の開発者のエクスペリエンスを向上させ、また既存の MFE コンポーネントを新しい CI/CD パイプラインに移行する際の助けにもなります。このツールに対する私たちの変更は、Micro-FrontEndプロジェクトに必要なCI/CD GitOpsワークフローを自動的に作成することを意味します。

新規または既存のプロジェクトにGitOpsパイプラインを採用するには、CLIツールでプロジェクトをレンダリングします。

次はどこに行こうか？

このプロジェクトは、GitOpsのコンセプトを理解する絶好の機会を与えてくれましたし、私たちがさらに改善できる分野を洞察することもできました。以下は、私たちが次に取り組む可能性のあることの一部です：

• Vonage のセキュリティチームと密接に協力して、セキュリティコンプライアンスの要件を設定（YAML、Terraform、...）として定義する。これが SDLC の一部であれば（そしてレビュー/改良の継続的なサイクルの一部であれば）、あなたは確実にコンプライアンスを満たし、コンプライアンスの証明を提供することができます。

• GitHub Actionsのセルフホスト・ランナーの利用を検討し、スケーリング、設定、コストをよりコントロールできるようにする。このステップは、ランナーのセキュリティ、コスト、保守性のトレードオフをもたらすので、慎重に検討する必要があります。

• K8sで利用可能な操作と同様のGitOps GitHub Appを作成/採用する。

最終的な感想

このブログが参考になり、開発パイプラインにGitOpsを採用する利点のいくつかを示すことができたなら幸いです。

フォローしてください。 ツイッターそして Slackチャンネルに参加してください。

読んでくれてありがとう！