ブログ

GitLab を使用した動的かつスケーラブルなマルチクラウド デプロイメント パイプラインの作成

アレックス・コーエン サムネイル
アレックス・コーエン
2020年9月1日公開

Volterra のソリューション チームは、Volterra プラットフォームの潜在的な価値を実証するために、多くの潜在的なユース ケースを設計および維持しています。 これらのユースケースは、多くの場合、顧客が Volterra を初めて実際に体験するために使用する指導ガイドとして作成されます。

ソリューション チームは、できるだけ人的入力を少なくして、ユース ケースをオンデマンドで社内に展開できる、より迅速で自動化された方法を求めていました。 私たちの展開は、IaaS プラットフォーム (AWS、Azure、GCP) とプライベート データ センタ環境 (VMware vSphere および Vagrant KVM) の両方を使用したハイブリッド マルチクラウド環境をカバーしていました。 私たちは、個々のユーザーが追加のアクセス アカウントを作成したり、仮想化プラットフォームや IaaS プロバイダーごとに追加のユーザー資格情報を管理したりする必要なく、あらゆる環境でデプロイメントを作成できる単一のツールを提供することで、これらの環境の管理を簡素化したいと考えました。 このツールは、複数の同時ユーザーと展開をサポートするために拡張する必要もありました。

要約すると、私たちが解決したかった中心的な問題は、ユーザー入力をできるだけ少なくして、ハイブリッド マルチクラウド環境への同時展開をスケーリングおよび処理できる、自動化されたソリューション ユース ケース展開ツールを作成することでした。

オルタードカーボンプロジェクト (AC)

ダイナミック-gitlab0

この目的のために、私たちは Altered-Carbon (AC と略されることが多い) というプロジェクトを作成しました。AC プロジェクトは、20 を超えるさまざまな Volterra ソリューションのユースケースを作成できる動的な GitLab パイプラインです。 パイプラインの自動化により、単一コマンドの「プッシュボタン デプロイメント」が作成され、ユーザーはオンデマンドまたはスケジュールされた毎日の cron ジョブを通じて複数のユースケース クラスターを簡単にデプロイできるようになりました。

参考までに、AC では、各デプロイメントをSTACKと呼び、各固有のユースケースをSLEEVEと呼びます。

プロジェクト開発

私たちは、ユースケース hello-cloud を最初の SLEEVE に自動化することから AC プロジェクトの開発を開始しました。 hello-cloud ユースケースでは、AWS と Azure に Volterra サイトを作成し、これらのサイトを Volterra VK8s (仮想 Kubernetes) クラスターに結合し、VK8s を使用して両方のサイトに 10 個のポッドapplicationをデプロイします。 私たちは、CI/CD パイプラインが管理できる完全に自動化されたワークフロー GitLab を作成するために、Volterra API を利用して追加の terraform テンプレートとシェル スクリプトを作成することからプロセスを開始しました。 次に、この展開方法を再利用可能かつスケーラブルにするための作業に着手しました。

独自の命名規則を追加することが、私たちが設計で次に取り組んだ課題でした。 単一の Volterra テナント環境でユースケースを複数展開できるようにするには、各 STACK で作成されたリソースに一意の名前が付けられ、同じ Volterra テナント環境内の他の STACK と重複する名前のリソースが作成されないようにする必要がありました。 起こり得る命名規則の競合を解決するために、プロジェクトの中心となるパイプライン トリガーに、ユーザーが提供する固有の環境変数というアイデアを取り入れ始めました。 環境変数STACK_NAMEが導入され、特定の STACK に関連付けられたすべてのリソースの名前にユーザー定義の文字列を含めるために terraform によって使用されるようになりました。 AC パイプライン ジョブのトリガー条件は、コミット時にトリガーするのではなく、GitLab プロジェクト CI トリガー トークンを使用して GitLab ユーザー API 呼び出しによってトリガーされた場合にのみ実行されるように設定され、パイプラインを人間の入力または外部 API 呼び出しによって制御できるようになりました。 次の例のような API 呼び出しを使用することで、ユーザーは単一のコマンドでリソースの競合なしに複数のデプロイメントを作成するという目標を達成できるようになりました。

ダイナミック-gitlab1

次に、このモデルから追加の展開オプションを作成することに努めました。 hello-cloud の AWS および Azure サイトのデプロイメントも、AC で個別にデプロイしたい個別のユースケースでした。これにより、GitLab での最初の大きな問題が発生しました。 GitLab CI/CD パイプラインでは、プロジェクト パイプライン内のすべてのジョブが接続されます。 これは直感に反するものでした。hello-cloud デプロイメントで必要なジョブの多くは、AWS または Azure サイトのデプロイメントでは必要ないからです。 基本的に、1 つの GitLab プロジェクト CI パイプラインに、必要に応じて個別の CI ジョブ セットでオンデマンドでトリガーできる複数の独立したパイプラインを含めることを望んでいました。

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

ダイナミック-gitlab2

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

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

ダイナミック-gitlab3

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

ダイナミック-gitlab4

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

ダイナミック-gitlab5

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

ダイナミック-gitlab6

これらのオプションの環境変数を使用すると、必要に応じてデプロイメントに高度な制御を追加できますが、この追加のオーバーヘッドを管理したくないユーザーには、より単純なデフォルトのデプロイメント オプションが許可されます。 また、ステージング環境と本番環境のデプロイメントを簡単に切り替えることができるようになりました。これは、当社の最大の AC 消費者にとって不可欠であることが証明されました。

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

前述のように、AC の各 SLEEVE は Volterra のユースケースを表しており、多くの場合、顧客が製品と初めてやり取りするケースとなります。 これらのユースケースが機能的でバグがないことを確認することは、製品の第一印象を強くするための鍵でした。 AC が作成される前に、ユースケースをテストして、それらが機能し、最新の Volterra ソフトウェアおよび API バージョンに準拠していることを確認するのは、時間のかかる作業でした。 各ユースケースに必要な手動部分により回帰テストに制限が生じ、十分な頻度で実行されず、人為的エラーが発生しやすくなりました。

ただし、AC 自動化を使用すると、毎日スケジュールされたジョブを使用して、SLEEVE を使用した特定のユースケースのデプロイメントをトリガーし、デプロイメントが完了するか、デプロイに失敗した後に作成されたリソースを削除できます。 これはステージング環境と本番環境の両方で使用され、どちらかの最近の変更がユースケースの展開に影響を与えたか、Volterra ソフトウェアにバグが発生したかをテストしました。 そうすれば、ユースケース ガイドで見つかったバグを更新したり、Volterra ソフトウェアのバグを迅速に検出して解決チケットを送信したりできるようになります。

GitLab API トリガー コマンドを使用して異なる SLEEVE を使用して複数のスタックを同時に生成するスケジュールされたジョブを含む別のリポジトリとパイプラインを作成しました。 各スモーク テスト ジョブは、独立した AC パイプラインを持つスタックの作成をトリガーすることから始まります。 スモーク テスト ジョブは、パイプライン トリガー呼び出しの stdout と GitLab API からパイプライン ID を取得し、トリガーされたパイプラインのステータスを監視します。 パイプラインが完了すると (成功または失敗のいずれの場合も)、テスト後にリソースを削除するために作成された同じ STACK 上で破棄パイプラインが実行されます。

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

ダイナミック-gitlab7

スモーク テスト パイプラインが失敗した場合、問題を再現するために AC トリガーで使用できる環境変数を提供できました。 これは技術的な問題チケットで提供され、開発者が失敗したデプロイメントを簡単に再現できるようになります。 その後、さらに多くの SLEEVES が完成するにつれて、CI パイプラインにさらに多くのジョブが追加され、テストの範囲が広がりました。 これらのテストの可視性をさらに向上させるために、Slack 統合を追加し、スモーク テスト ジョブで各パイプライン実行の成功または失敗のメッセージを、Altered-Carbon プロジェクトと Smoke-Test プロジェクトの両方の対応する CI Web ページへのリンクと詳細とともに送信するようにしました。

ダイナミック-gitlab8

スタック記録の保持とパイプライン Web URL ナビゲーション

AC が進化し、ソリューション チームからユーザーが追加され、さらに多くのスタックが作成されるにつれて、プロジェクトの複雑さが増しました。 これにより、GitLab Pipeline の Web UI を操作するときに根本的な問題が発生し始めました。私たちは GitLab パイプラインを非常に非伝統的な方法で使用していたため、作成中の STACK に関連する個々のパイプライン実行をトレースする際に GitLab パイプラインの Web UI が使いにくくなっていました。

GitOps ワークフローを通じてデプロイメントを管理する GitLab パイプラインは、静的に定義されたクラスターのセットに対して使用する場合に最も適しているようです。 この場合、GitLab パイプラインを実行するたびに、同じクラスターとリソースが毎回影響を受けます。 この場合のこれらのクラスターのデプロイメント履歴は、GitLab Web UI で視覚化されたパイプライン履歴です。ただし、AC は動的であり、常に変化するリソース セットを処理します。各パイプライン実行ではまったく異なるジョブ セットを利用し、異なる仮想化プロバイダーで異なるリソースのスタックを管理できます。 SLEEVE 規則と STACK 規則によって作成されたこの区別により、どのパイプラインがどのスタックに対応するかを判断することが非常に困難になりました。 たとえば、AC の GitLab CI/CD パイプライン Web UI を見てみましょう。

ダイナミック-gitlab9

このビューでは、各パイプラインを個別に確認しなければ、単一のパイプラインがどの STACK または SLEEVE を変更しているかを判断することはできません。 1 日に何百ものパイプラインが実行されている場合、特定の STACK を作成または破壊した特定のパイプラインの実行を見つけたり、その STACK に関する特定の詳細を見つけたりするのは面倒な作業になる可能性があります。 この問題を解決するために、AC 開発の初期段階で、簡単な記録保持システムを追加しました。 ジョブは、stack-records と呼ばれるパイプラインの前に実行されます。 このジョブは、作成時にスタックの詳細を収集し、tfstate バックアップを保存するために使用される S3 ストレージ バケットにアップロードされる json ファイルを生成します。 以下にスタック レコードの例を示します。

ダイナミック-gitlab11

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

  • 使用された Volterra テナント環境。
  • 使用されたスリーブ。
  • STACK が現在「適用」状態で実行されているか、またはそのリソースが「破棄」状態で削除されているかのいずれかです。
  • スタックを作成した GitLab ユーザー。
  • STACK を変更するアクセス権を持つ他のユーザーをリストするワークグループ。
  • そして最も重要なのは、スタックに対して実行された各パイプライン実行の Web URL、パイプラインをトリガーしたユーザー、パイプラインがスタックを適用または破棄したかどうか、パイプラインがトリガーされた日時などが含まれるパイプライン配列です。

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

スタック レコードにより、デプロイするパイプラインに対して一定レベルのユーザー制御とエラー キャッチを実装することも可能になりました。 たとえば、AC の作成後に Volterra ソフトウェアに加えられた変更により、Volterra サイトの作成で使用されるサイト クラスター名 (STACK NAME 値から派生した値) を 17 文字に制限する必要が生じました。 そこで、スタック名が文字数制限に違反した場合には、デプロイメント手順を実行する前にパイプラインが失敗するようにするチェックをスタック レコード ジョブに追加しました。 AC によって制御される特定のスタックを変更できるユーザーを制限する AC のユーザー権限レベルの追加など、その他のカスタム コントロールも追加されました。

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

社内使用と現在のテスト範囲

現在、AC はソリューション チームの中心となり、回帰テストと自動化の大部分を提供しています。 主な用途としては、回帰スモーク テスト、スケール テスト、製品課金テスト、製品デモで使用される簡略化された展開などが挙げられます。

自動デプロイメントは、夜間の回帰テストで最も大きな効果を発揮しました。 私たちは毎晩、デプロイメントをトリガーし、作成されたリソースを破棄することで、各 SLEEVES を本番環境とステージング環境に対してテストします。 変更が発生すると、すぐにそれを検出し、バグレポートを送信してガイドを更新することができます。 現在のテスト範囲は次のとおりです。

  • 安全な Kubernetes ゲートウェイ。
  • Webapplicationのセキュリティ。
  • 標準の 10 ポッド「hipster-co」applicationと、より軽量な単一ポッドapplicationを展開するネットワーク エッジapplications。
  • こんにちはクラウド。
  • AWS、GCP、Azure、VSphere、KVM/Vagrant にわたる CE 単一ノード単一ネットワーク インターフェイス Volterra サイト。
  • AWS、GCP、Azure、VSphere、KVM/Vagrant にわたる CE シングル ノード ダブル ネットワーク インターフェイス volterra サイト。
  • スケールされた CE シングル ノード シングル ネットワーク インターフェイス Volterra サイト デプロイメント (GCP、VSphere、KVM を使用) により、多数の CE シングル ノード シングル NIC サイトが作成され、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 サイト。

また、最大 400 のサイトを一度に展開して Volterra ソフトウェアのスケーリング機能をテストするプロセスを自動化する特殊なスケール テスト スリーブもあり、GCP、vSphere、KVM を使用してテストされています。

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

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

AC の使用はすでに非常に成功した結果を生み出しており、近い将来、プロジェクトに追加される機能や改善点はまだ数多くあります。

プロジェクトへの最大の追加は、追加のユースケースの展開をカバーするために新しい SLEEVE オプションが継続的に追加されていることです。 新しい SLEEVE が追加されるたびに、夜間の回帰スモーク テストに新しいジョブが追加され、ソリューション展開プロジェクトの範囲が広がります。 これまでのほとんどのスリーブは、単一ノードおよび単一ネットワーク インターフェイスの使用例に重点を置いていましたが、最近、SLEEVE の対象範囲を、AWS、Azure、GCP、VMWare、KVM/Vagrant プラットフォーム全体のマルチノード Volterra サイト クラスターおよびマルチネットワーク インターフェイスの使用例にまで拡張しました。

スタック記録システムの改善も目指しています。 当社では、AC レコードの詳細レベルを高め、レコード用の RDS データベース ストアを組み込むことで、検索機能を強化していきます。 目標は、AC 環境の検索を高速化し、スタック状態やスタック作成者などに基づいたスタック検索など、より選択的な検索機能を提供できるようにすることです。 これらのレコードを使用してカスタム UI を構築し、AC で作成されたデプロイメントをより効率的に視覚化することも、当社のロードマップに含まれています。