GitLabで動的かつスケーラブルなマルチクラウドデプロイパイプラインを構築

Alex Cohen

Volterraのソリューションチームは、Volterraプラットフォームがもたらし得る価値を示すために、さまざまなユースケースを設計し、維持しています。これらのユースケースは、多くの場合、Volterraを初めて実際に操作するお客さま向けのガイドとして提供されます。

ソリューションチームは、人手をできる限り介さずに、社内でユースケースをオンデマンドかつ迅速に自動デプロイできる方法を求めていました。デプロイの対象は、IaaSプラットフォーム（AWS、Azure、GCP）とプライベートデータセンター環境（VMware vSphere、Vagrant KVM）の両方を使用するハイブリッドマルチクラウド環境でした。そこで、個々のユーザーが仮想化プラットフォームやIaaSプロバイダーごとに追加のアクセスアカウントを作成したり、追加のユーザー認証情報を管理したりすることなく、あらゆる環境にデプロイできる単一のツールを提供することで、これらの環境の管理を簡素化したいと考えました。また、このツールには、複数のユーザーとデプロイを同時にサポートできる拡張性も必要でした。

要約すると、私たちが解決しようとした中心的な課題は、ユーザー入力を可能な限り抑えながら、ハイブリッドマルチクラウド環境への同時デプロイに対応し、拡張可能なソリューションユースケースの自動デプロイツールを構築することでした。

Altered-Carbonプロジェクト（AC）

この目的のために、Altered-Carbon（通称AC）というプロジェクトを作成しました。ACプロジェクトは、20を超えるVolterraソリューションのユースケースを作成できる動的なGitLabパイプラインです。パイプラインの自動化により、1つのコマンドで実行できる「プッシュボタンデプロイ」を構築しました。これにより、複数のユースケースクラスターをオンデマンドで、または毎日実行されるスケジュール済みcronジョブを通じて簡単にデプロイできます。

参考までに、ACでは各デプロイを「STACK」、一意の各ユースケースを「SLEEVE」と呼びます。

プロジェクト開発

ACプロジェクトの開発では、まずユースケースhello-cloudを自動化し、最初のSLEEVEに組み込みました。hello-cloudユースケースは、AWSとAzureにVolterraサイトを作成し、それらを1つのVolterra VK8s（仮想Kubernetes）クラスターに統合したうえで、VK8sを使用して両方のサイトにまたがる10ポッド構成のアプリケーションをデプロイします。まず、Volterra APIを利用するTerraformテンプレートとシェルスクリプトを追加で作成し、GitLabのCI/CDパイプラインで管理できる完全自動化ワークフローを構築しました。その後、このデプロイ手法の再利用性と拡張性の向上に取り組みました。

次に設計上の課題となったのは、一意の命名規則を追加することでした。単一のVolterraテナント環境に同じユースケースを複数デプロイできるようにするには、各STACKで作成されるリソースに一意の名前を付け、同じVolterraテナント環境内の別のSTACKと重複する名前のリソースが作成されないようにする必要がありました。命名規則で発生し得る競合を解消するため、パイプライントリガーにユーザー指定の一意の環境変数を組み込むという、プロジェクトの中核となる考え方を採用し始めました。環境変数STACK_NAMEを導入し、特定のSTACKに関連するすべてのリソース名にユーザー定義の文字列を含めるため、terraformで使用しました。ACパイプラインジョブのトリガー条件は、コミット時に実行するのではなく、GitLab Project CI Trigger Tokenを使用したGitLabユーザーのAPI呼び出しによってトリガーされた場合にのみ実行するよう設定しました。これにより、人による操作または外部API呼び出しでパイプラインを制御できます。次の例のようなAPI呼び出しを使用することで、リソースの競合を発生させずに複数のデプロイを作成するという目標を、1つのコマンドで実現できるようになりました。

次に、このモデルを基に、追加のデプロイオプションの作成に取り組みました。hello-cloudのAWSサイトとAzureサイトへのデプロイも、それぞれACで個別にデプロイしたいユースケースでした。そこで、GitLabに関する最初の大きな問題に直面しました。GitLab CI/CDパイプラインでは、プロジェクトのパイプライン内にあるすべてのジョブが相互に接続されています。hello-cloudのデプロイに必要なジョブの多くは、AWSサイトやAzureサイトへのデプロイには不要だったため、これは直感に反する仕組みでした。つまり、1つのGitLabプロジェクトのCIパイプライン内に複数の独立したパイプラインを含め、必要なときに、それぞれ異なるCIジョブのセットを使用してオンデマンドでトリガーできるようにしたいと考えていました。

この問題を解決するため、GitLab CI/CDのonly/exceptオプションを組み込んだパイプライン構造に、環境変数SLEEVEを導入しました。これにより、パイプライントリガーで指定されたSLEEVEの値に基づいて、任意のパイプラインでトリガーされるCIジョブを制限できるようになりました。最終的に、最初の3つのSLEEVEオプションとして、simple-aws、simple-azure、hello-cloudを用意しました。各SLEEVEでは、ユーザーがデプロイするユースケース（これにより、トリガーされたパイプライン内のCIジョブを制御）と、トリガーされたパイプラインによって作成されるリソースの名前を指定するSTACK_NAMEを定義します。以下は、両方の環境変数を組み込んだコマンド構造です。これは、現在も使用されている最も基本的なACコマンドです。

次の画像は、環境変数SLEEVEを変更すると、ACパイプラインの各実行でトリガーされるジョブがどのように変わるかを視覚化したものです。

SLEEVE「simple-aws」パイプライン：

SLEEVE「hello-cloud」パイプライン：

また、いずれかのパイプライントリガーで環境変数 DESTROY が指定された場合に実行される追加ジョブも導入しました。これにより、ACで作成したリソースを削除する逆方向のオプションが提供されます。以下は、既存のSTACKのリソースを削除する例です。

その他の環境変数は、トリガーコマンドに値を追加することで上書きできるデフォルト値とともにGitLabに保存されていました。たとえば、Volterraテナント環境のAPI URLは、VOLTERRATENANT環境変数に保存されていました。ユーザーがAPIコマンドにVOLTERRATENANT環境変数を追加すると、デフォルト値が上書きされ、デプロイ先が目的の場所に変更されます。ソリューションチームは数十のVolterraテナント環境を管理しており、作業内容に応じて環境を切り替える必要があるため、この機能は社内テストを行ううえで非常に重要でした。

これらのオプションの環境変数を使用すると、必要に応じてデプロイをより細かく制御できる一方、追加の管理負担を避けたいユーザーは、よりシンプルなデフォルトのデプロイ方法を選択できました。また、ステージング環境と本番環境のデプロイを容易に切り替えられるようになり、これは最大規模のAC利用者にとって不可欠な機能となりました。

ソリューションのユースケース：夜間回帰テスト

前述のとおり、ACの各SLEEVEはVolterraのユースケースを表しており、多くの場合、お客さまが製品に初めて触れる機会となっていました。製品に対する良い第一印象を与えるには、これらのユースケースが正常に機能し、バグがないことが重要でした。ACが作成される前は、ユースケースが正常に機能し、最新のVolterraソフトウェアおよびAPIバージョンに対応していることを確認するテストに多くの時間を要していました。各ユースケースで手作業が必要だったため、回帰テストには制約があり、十分な頻度で実施できず、人為的ミスも発生しやすい状況でした。

しかし、ACによる自動化では、日次のスケジュールジョブを使用して、SLEEVEで任意のユースケースのデプロイを開始し、デプロイの完了後または失敗後に作成済みのリソースを削除できました。これはステージング環境と本番環境の両方で使用され、各環境の直近の変更がユースケースのデプロイに影響したか、またはVolterraソフトウェアにバグを引き起こしたかをテストしました。これにより、ユースケースガイドで見つかったバグを更新したり、Volterraソフトウェアのバグを迅速に検出して解決チケットを提出したりできました。

別のリポジトリとパイプラインを作成し、スケジュール済みジョブからGitLab APIのトリガーコマンドを使用して、異なるSLEEVEで複数のスタックを同時に生成できるようにしました。各スモークテストジョブは、独立したACパイプラインでスタックの作成をトリガーすることから開始します。次に、パイプライントリガー呼び出しのstdoutからパイプラインIDを取得し、GitLab APIを使用して、トリガーしたパイプラインのステータスを監視します。パイプラインが完了すると（成功または失敗のいずれの場合も）、作成した同じSTACKに対してdestroyパイプラインを実行し、テスト後にリソースを削除します。

次の図は、このプロセスの詳細と、作成および破棄コマンドによってACでトリガーされるジョブを示しています。

スモークテストのパイプラインが失敗した場合、ACトリガーで問題を再現するために使用できる環境変数を提示できるようになりました。この情報を技術的な問題のチケットに記載することで、開発者は失敗したデプロイを容易に再現できます。その後、完成したSLEEVESが増えるにつれてCIパイプラインに追加するジョブも増やし、テスト範囲を拡大しました。さらに、これらのテストの可視性を高めるためにSlack連携を追加し、スモークテストジョブから各パイプライン実行の成功または失敗を通知するメッセージを送信するようにしました。メッセージには、Altered-CarbonプロジェクトとSmoke-Testプロジェクトの両方について、対応するCI Webページへのリンクと詳細情報が含まれます。

スタックの記録管理とパイプラインWeb URLへの移動

ACの進化に伴い、ソリューションチームから新たなユーザーが加わり、作成するスタックも増え続けたことで、プロジェクトは複雑さを増していきました。その結果、GitLab PipelineのWeb UIでの操作に根本的な問題が生じ始めました。GitLabパイプラインを従来とは大きく異なる方法で使用していたため、作成したSTACKに関連する個々のパイプライン実行をGitLabパイプラインのWeb UIで追跡することが困難になっていました。

GitOpsワークフローを通じてデプロイを管理するGitLabパイプラインは、静的に定義された一連のクラスターに対して使用する場合に最も適していると考えられます。この場合、GitLabパイプラインを実行するたびに、同じクラスターとリソースが対象になります。これらのクラスターのデプロイ履歴は、GitLab Web UIに表示されるパイプライン履歴に相当します。一方、ACは動的であり、絶えず変化する一連のリソースを処理します。パイプラインを実行するたびに、まったく異なる一連のジョブを使用し、異なる仮想化プロバイダー上にあるさまざまなリソースのSTACKを管理できます。SLEEVEとSTACKの規則によってこのような違いが生じるため、どのパイプラインがどのSTACKに対応するのかを特定することは非常に困難です。たとえば、ACのGitLab CI/CDパイプラインWeb UIを見てみましょう。

このビューだけでは、各パイプラインを個別に確認しない限り、どのパイプラインがどのSTACKまたはSLEEVEを変更しているのか判断できません。1日に数百件のパイプラインが実行される場合、特定のSTACKを作成または破棄したパイプライン実行を見つけたり、そのSTACKに関する詳細情報を確認したりするのは手間がかかります。この問題を解決するため、ACの開発初期にシンプルな記録管理システムを追加しました。各パイプラインの実行前に、stack-recordsというジョブが実行されます。このジョブは、スタックの作成時にその詳細情報を収集してJSONファイルを生成し、tfstateのバックアップ保存に使用しているS3ストレージバケットにアップロードします。以下は、スタックレコードの例です。

stack-record.jsonファイルには、各スタックについて次のような詳細情報が含まれています。

• 使用されたVolterraテナント環境。
• 使用されたSLEEVE。
• STACKが現在「apply」状態で実行中だったか、または「destroy」状態でそのリソースが削除されたか。
• スタックを作成したGitLabユーザー。
• STACKを変更する権限を持つ他のユーザーを一覧表示するワークグループ。
• そして最も重要なのが、スタックに対して実行された各パイプライン実行のWeb URL、パイプラインをトリガーしたユーザー、パイプラインがスタックを適用したのか破棄したのか、およびパイプラインがトリガーされた日時を含むpipelines配列です。

これにより、各スタックに関連付けられたすべてのパイプラインURLの履歴が記録されました。さらにプロセスを簡素化するため、S3 API呼び出しを介してこれらのファイルにアクセスできるシンプルなCLIスクリプトも作成しました。ACを利用するユーザーは、これらのドキュメントでスタックの履歴を追跡し、スタックの記録を参照して変更日時を確認できました。

スタックレコードにより、デプロイするパイプラインに対して、一定レベルのユーザー制御とエラー検出も実装できるようになりました。たとえば、ACの作成後にVolterra Softwareに加えられた変更に伴い、Volterraサイトの作成に使用するサイトクラスター名（STACKNAMEの値から生成される値）を17文字以内に制限する必要が生じました。そこで、STACKNAMEが文字数制限に違反している場合、デプロイ手順を実行する前にパイプラインを失敗させるチェックをスタックレコードジョブに追加しました。また、ACで管理される特定のスタックを変更できるユーザーを制限するため、ACにユーザー権限レベルを追加するなど、その他のカスタム制御も導入しました。

• Adminレベルの権限では、ACの上位2名の開発者が、デバッグ目的で任意のスタックを作成または破棄できます。-ownerまたはcreatorレベルは、STACKを最初に作成したGitLabユーザーに付与されます。そのユーザーのGitLabメールアドレスがcreatorとしてスタックレコードに記録され、スタックを作成または破棄できるようになります。
• 次に、workgroupレベルの権限があります。GitLabユーザーのメールアドレスをスタックレコードのworkgroup配列に追加すると、作成者以外のユーザーにもSTACKを適用または破棄する権限を付与できます。
• これらのいずれの権限レベルも持たないユーザーは、スタックを変更できません。そのようなユーザーが権限のないスタックを変更しようとすると、リソースがデプロイされる前にstack-recordsジョブが失敗します。

内部利用と現在のテストカバレッジ

現在、ACはソリューションチームの中核を担い、回帰テストと自動化の大部分を支えています。主な用途は、回帰スモークテスト、スケールテスト、製品の課金テスト、および製品デモ用の簡易デプロイです。

自動デプロイは、主に夜間の回帰テストで利用されています。毎晩、デプロイを実行して作成されたリソースを削除することで、各SLEEVESを本番環境とステージング環境に対してテストしています。変更が発生した場合は迅速に検出し、ガイドを更新するためのバグレポートを提出できます。現在のテスト対象は次のとおりです。

• Secure Kubernetes Gateway。
• Webアプリケーションセキュリティ。
• 標準の10ポッド構成の「hipster-co」アプリケーションと、より軽量なシングルポッド構成のアプリケーションをデプロイするNetwork Edge Applications。
• Hello-Cloud.
• AWS、GCP、Azure、VSphere、KVM/Vagrantにわたる、単一ノード、単一ネットワークインターフェース構成のCE volterraサイト。
• AWS、GCP、Azure、VSphere、KVM/Vagrant上の、単一ノードおよびデュアルネットワークインターフェース構成のCE volterraサイト。
• CEシングルノード／シングルネットワークインターフェース構成のVolterraサイトを複数作成し、デプロイをスケールさせました（GCP、VSphere、KVMを使用）。これにより、Volterraのスケーリング機能をテストしました。
• AWS、GCP、Azure、VSphere、KVM/Vagrantにわたる、単一ノード・複数ネットワークインターフェース構成のCE volterraサイト。
• AWS、GCP、Azure、VSphere、KVM/Vagrantにまたがる、マルチノードかつ単一ネットワークインターフェース構成のCE volterraサイト。
• AWS、GCP、Azure、VSphere、KVM/Vagrantにまたがる、マルチノード、マルチネットワークインターフェース構成のCE volterraサイト。

また、Volterraソフトウェアのスケーリング機能を検証するために、最大400サイトを一度にデプロイするプロセスを自動化する専用のスケールテストスリーブも用意しています。これはGCP、vSphere、KVMを使用してテスト済みです。

ユースケースを迅速に自動デプロイすることで、ソリューションチームのメンバーは他のタスクに集中でき、社内業務の効率が向上します。ソリューションチームでは、動画デモの収録用に数十のKVM、GCP、vSphereサイトをデプロイする際にACを頻繁に使用しています。既存の自動化を基盤として、より複雑なインフラストラクチャの構築に使用するVolterraサイトを作成できるため、時間を節約できます。また、請求情報を記録する専用のVolterraテナント上で、AWS、Webアプリセキュリティ、セキュアKubernetesゲートウェイ、ネットワークエッジアプリケーションの各ユースケースを自動デプロイし、Volterraプラットフォームの請求機能をテストする日次cronジョブにも使用されています。

今後の計画とロードマップ

ACの活用はすでに大きな成果を上げており、近い将来、このプロジェクトにはさらに多くの機能追加や改善を予定しています。

このプロジェクトにおける最大の拡充点は、より多様なユースケースのデプロイに対応するため、新しいSLEEVEオプションを継続的に追加していることです。新しいSLEEVEを追加するたびに、夜間の回帰スモークテストに新しいジョブを追加し、ソリューションのデプロイプロジェクトに対するテスト範囲を広げています。従来のSLEEVEの多くは、単一ノードおよび単一ネットワークインターフェースのユースケースを対象としていましたが、最近では、AWS、Azure、GCP、VMWare、KVM/Vagrantの各プラットフォームにおけるマルチノードのVolterraサイトクラスターと、複数のネットワークインターフェースを使用するユースケースにも対象範囲を拡大しています。

また、スタック記録システムの改善にも取り組んでいます。ACの記録をさらに詳細化するとともに、記録の保存先としてRDSデータベースストアを導入し、検索機能を強化する予定です。これにより、AC環境をより迅速に検索できるようにし、スタックの状態や作成者などに基づくスタック検索にも対応することを目指しています。さらに、これらの記録を活用してカスタムUIを構築し、ACで作成したデプロイメントをより効率的に可視化することもロードマップに含まれています。

著者について

Alex Cohen

Alex Cohenのその他のブログ記事