• 要約
• Docker Machine上でのビルドの継続
• 提案
  • 💡 ユーザーがその上に構築できるような、シンプルな抽象化を設計します。
  • 💡 既存のDocker Machineソリューションのプラグインへのマイグレーション
  • 💡 AWS、Google Cloud Platform、Azure用のプラグインを構築します。
  • 💡 独自のプラグインを構築する方法について、しっかりとしたドキュメントを書きましょう。
  • 💡 1台のマシンで複数のビルドを実行するPoCを構築します。
• 詳細
  • 関心の分離
    • 現在の状態
  • 設計原則
    • 一般的な高レベルの原則
    • 新しいプラグインシステムの原則
    • 最も重要な技術的詳細
• プラグイン境界の提案
  • カスタムプロバイダー
  • タスクスケーラ・プロバイダ
• 用語解説
• ステータス
• 誰

ネクスト・ランナー・オートスケーリング・アーキテクチャ

要約

GitLab RunnerはGitLab CI/CDのコアコンポーネントです。信頼性の高い並行環境でCI/CDジョブを実行することができます。2015年初頭にKamil Trzciński氏によってRuby版の同サービスを置き換えるために導入されました。Goで書かれたGitLab Runnerは、より広いコミュニティで使いやすく、以前のRubyベースのバージョンよりも効率的で信頼できることがわかりました。

2016年2月、Kamil Trzcińskiはクラウドインフラを活用して多くのCI/CDジョブを並行して実行するための自動スケーリング機能を実装しました。この機能は、GitLab.comでのCI/CD採用を長年にわたって支える基盤となり、現在ではピーク時に1日あたり約400万ビルドを実行しています。

最初の実装では、Docker Machineを使用することが決定されました：

使いやすい。ドキュメントが充実していること。サポートが充実しており、常に拡張されています。ほとんどのクラウドプロバイダや仮想化インフラをサポートしています。Docker Machineをサポートするために必要な変更は最小限です：マシンの列挙と検査。クラウド特有の」機能を実装する必要はありません。

この設計の選択は、GitLab Runnerの成功に不可欠でした。それ以来、自動スケーリング機能は多くのユーザーや顧客に利用され、GitLab.comでのCI/CDの急速な普及を可能にしました。

しかし、私たちはDocker Machineを使い続けることはできません。そのプロジェクトでの作業は2018年7月に一時停止され、それ以降開発者はいませんでした（いくつかの非常に重要なセキュリティ修正を除いて）。2018年、Docker Machineが “メンテナンスモード “に入った後、私たちはこれを使い続け、私たちのユースケースに必要な修正とアップデートを出荷できるよう、独自のフォークを作成することにしました。2021年9月26日、プロジェクトはアーカイブされ、公式ページからドキュメントが削除されました。これは、Docker Machineを使用する本来の理由がもはや有効でないことを意味します。

私たちの顧客や幅広いコミュニティをサポートし続け、SaaS Runnerのメンテナンスを改善するために、私たちはGitLab Runnerの自動スケーリングのための新しいメカニズムを設計する必要があります。それは自動スケーリングをサポートするだけでなく、効率性、信頼性、可用性を向上させるためにその上に構築できるような方法で行う必要があります。

私たちはこの新しいメカニズムを “next GitLab Runner Scaling architecture “と呼んでいます。

Docker Machine上でのビルドの継続

現在、私たちのコア製品の1つであるGitLab Runnerとその最も重要な機能の1つであるジョブ実行環境の自動スケール機能は、放棄された外部製品に依存しています。

Docker Machineプロジェクト自体のメンテナーも大変です。その設計は古さを見せ始め、新しい機能や修正をもたらすことを難しくしています。巨大なコードベースとそれに関する内部知識の不足により、私たちのメンテナーがサポートし、入ってくる機能要求やコミュニティの貢献を適切に処理することが難しくなっています。

Docker Machineとクラウドおよび仮想化プロバイダ用の統合された20以上のドライバは、次のような別の問題のサブセットも生み出しています：

• 各クラウド/仮想化環境は、行ったり来たりする機能をもたらし、私たちはそれらのサポートをメンテナーする必要があります（新機能の追加、バグの修正）。

• 私たちは基本的に、仮想化/クラウドプロバイダーのAPIとのインテグレーションを適切にサポートするために、それぞれの専門家になる必要があります、

• Docker Machineがインテグレーションする全てのプロバイダには、バグやセキュリティリリース、脆弱性があります。プロジェクトを適切にメンテナーするためには、私たちはそれら全てを把握し、必要な時にはいつでもアップデートに対応する必要があります。

もう一つの問題は、Docker Machineがその始まりからLinuxベースのインスタンスだけを管理することに集中していたという事実です。ある時点でDockerはWindows上で公式かつネイティブなインテグレーションを得たにもかかわらず、Docker Machineはこのステップに従うことはありませんでした。また、そのようなインテグレーションを容易にするように設計されてもいません。

MacOSのサポートもありません。Docker MachineはDocker Engine用のホストをメンテナーするツールであり、MacOS用のネイティブDocker Engineは存在しません。ネイティブとはMacOSオペレーティングシステム内で実行されるMacOSコンテナのことです。Docker for MacOS製品はネイティブサポートではありません - それは単なるツールであり、MacOS開発インスタンス上でLinuxコンテナを開発しやすくするためにインストールされた仮想化Linuxインスタンスです。

つまり、私たちが公式にサポートしている3つのプラットフォーム（Linux、Windows、MacOS）のうち、CI/CDオートスケーリングに完全に対応しているのは1つだけです。Windowsの場合はKubernetesを使う可能性があり（場合によっては制限があります）、おそらく多くの努力でDocker MachineにWindowsのサポートをもたらすことができるでしょう。しかしMacOSでは、GitLab Runnerがネイティブで提供するオートスケーリングソリューションはありません。

これはユーザーにとって大きな制限であり、よくリクエストされる機能です。また、私たちのSaaS Runnerの限界でもあります。私たちはSaaSのWindowsとSaaSのMacOSランナーのために、Custom executorをハックして何らかの自動スケーリングを作ることをメンテナーとしてきました。しかし、過去3年間の経験から、それは最善の方法ではないことがわかりました。しかし、過去3年間の経験から、WindowsとMacOSランナーのオートスケーリングは、SaaS Linuxランナーで行っているようなパフォーマンスや機能のサポートに欠けています。

私たちの顧客や幅広いコミュニティをサポートし続け、SaaS Runnerのメンテナンスを改善するために、私たちはGitLab Runnerのオートスケーリングのための新しいメカニズムを設計する必要があります。自動スケーリングをサポートするだけでなく、効率性、信頼性、可用性を向上させるためにその上に構築できるようにする必要があります。

提案

現在、GitLab Runnerのオートスケーリングはいくつかの方法で設定することができます。Kubernetesで自動スケーリングされた環境をうまく使っている顧客もいます。私たちは、Kubernetes上での自動スケーリングをより信頼性の高いものにするために、カスタムかつ非公式なGitLab Runnerバージョンが構築されていることを知っています。私たちは、複数のジョブを並行して実行するために本当に優れたKubernetesソリューションを持つことの重要性を認識していますが、この分野での改良はこのアーキテクチャ・イニシアチブの範囲外です。

私たちはDocker Machineの問題を解決し、このメカニズムを信頼性が高く柔軟なメカニズムに置き換えることに集中したいと考えています。Docker Machineが非推奨になった理由はたくさんあると思われるので、私たちはDocker Machineのドロップイン代替を構築できないかもしれません。非常に多くのクラウドプロバイダとの互換性をメンテナーするのは非常に難しく、Docker MachineはDocker Desktopに取って代わられ、私たちにとって実行可能な代替にはならないようです。このイシューでは、Docker Machineを今どのように使っているのかについて議論しており、GitLab CIがDocker Machineを使い続ける最も多い理由の1つになっているようです。

また、オプションで複数のジョブを1つの大きな仮想マシンで実行できる機会もあります。今日それを行うことはできませんが、潜在的に効率を大幅に改善できる可能性があることは分かっています。それを容易にする新しいアーキテクチャを構築し、PoCでどれだけ効率的かをテストできるようにしたいかもしれません。1台のマシンで複数のジョブを実行することで、私たちが「スティッキーコンテキスト」と呼んでいる、ジョブの実行間で共有できるビルドアーティファクトやユーザーデータのためのスペースを再利用することも可能になります。

💡 ユーザーがその上に構築できるような、シンプルな抽象化を設計します。

Dockerがサポートしていた全てのクラウドプロバイダーをサポートすることはできないかもしれません。そのため、重要な設計要件は、より広いコミュニティがどんなクラウドプロバイダーを使っていても、GitLabのカスタムプラグインを本当にシンプルで簡単に書けるようにすることです。私たちは、GitLab.com上の既存のワークフローをサポートするのと同様に、ユーザーがその上に構築できるようなシンプルな抽象化を設計したいと考えています。

設計されたメカニズムは、Docker Machine executorがこれまで行ってきたことを抽象化するものでなければなりません：外部のDocker環境を作成する方法を提供し、この環境をプロビジョニングすることでジョブの実行を待ち、これらのオペレーションを実行するために必要なクレデンシャルを返します。

新しいプラグインシステムは、すべての主要なプラットフォームで利用できるはずです：Linux、Windows、MacOS。

💡 既存のDocker Machineソリューションのプラグインへのマイグレーション

新しい抽象化を設計し実装したら、既存のDocker Machineメカニズムをプラグインにマイグレーションできるはずです。これにより、ユーザーや顧客は新しいアーキテクチャをすぐに使い始めることができ、Docker Machineの既存のワークフローや設定は維持することができます。これにより、レガシーオートスケーリングのサポートを完全に停止する前に、新しいアーキテクチャにマイグレーションする時間が皆に与えられます。

💡 AWS、Google Cloud Platform、Azure用のプラグインを構築します。

Docker Machineがサポートしていた全てのクラウドプロバイダのサポートを追加することはできないかもしれませんが、AWSやGoogle Cloud Platform、Azureのような主要なクラウドプロバイダのためにGitLabがメンテナンスするプラグインを提供することは重要だと思われます。

貢献したり、フォークしたり、より広いコミュニティのメンバーが持っている特定のニーズに合わせて変更したりしやすいように、おそらく別々のリポジトリにビルドする必要があります。GitLab Runnerを再構築することなく、新しいプラグインをインストールするのも簡単であるべきです。

💡 独自のプラグインを構築する方法について、しっかりとしたドキュメントを書きましょう。

ユーザーが自分のクラウドインフラのサポートを実装できるように、プラグインの構築方法を示すことは重要です。

新しいプラグインの構築はシンプルで、優れたドキュメントでサポートされるべきです。私たちは、新しいプラグインを貢献するための参入障壁が非常に低くなるようにプラグインシステムを設計したいと考えています。

💡 1台のマシンで複数のビルドを実行するPoCを構築します。

1台のマシンで複数のジョブを実行することで、どのような効率が得られるかをよりよく理解したいと思います。それを予測するのは難しいので、PoCを構築するのが理想的です。

この実験を実行するためには、おそらく実験的なプラグインを構築する必要があるでしょう。このプラグインは、1台のマシンで複数のビルドを実行するスケジューリングを可能にするだけでなく、そのパフォーマンスを理解しやすくするための包括的なメトリクスセットも組み込まれています。

詳細

具体的にどのように抽象化するかは、プロトタイプを作成し、PoCを行い、データに基づいた方法で決定する必要があります。私たちが詳細に説明し、要件を開発し、PoCし、採点すべきいくつかの提案があります。私たちの目標を最もサポートしてくれそうなソリューションを選びます。

提案を説明するためには、まずGitLab Runnerのどの部分を抽象化する必要があるのかをよりよく説明する必要があります。これらの概念を把握しやすくするために、現在の自動スケーリングアーキテクチャとシーケンス図を見てみましょう。

上の図では、現在ランナーマネージャーがクラウドプロバイダーのAPIにアクセスできるマシン上で動いていることがわかります。Dockerエンジンをインストールした新しい仮想マシンをプロビジョニングするためにDocker Machineを使用しており、外部からの認証済みリクエストを許可するようにDockerデーモンを設定しています。このようなエフェメラルなDocker環境への認証情報をディスクに保存します。マシンがプロビジョニングされ、Runnerマネージャがビルドを実行できるようになると、既存のExecutorの1つを使用してユーザーが提供したスクリプトを実行します。自動スケーリングでは、これは通常Docker Executorを使用して行われます。

関心の分離

現在のアーキテクチャにはいくつかの懸念があります。現在の実装ではそれらは結合しているので、ここではそれらを分けてそれぞれを考えます。

• 仮想マシン(VM) 形状。VMの基礎となるプロバイダは、どのような種類のマシンを作成するかを知るための設定を必要とします。例えば、Core、メモリ、障害ドメインなどです。この情報は非常にプロバイダー固有です。
• VMのライフサイクル管理。複数のマシンが作成され、システムはどのマシンがこのエクゼキューターに属するかを追跡しなければなりません。通常、クラウドプロバイダーは同種のマシンの集合を管理する方法を持っています。例えば、GCEインスタンスグループです。基本的なオペレーションは、特定のマシンの増加、減少、そして通常は削除です。
• VMのオートスケール。低レベルのライフサイクル管理に加えて、必要なときにキャパシティを提供する一方で、コスト上の理由から過剰なキャパシティをメンテナーしないように、ジョブを意識したキャパシティ決定をマシンのセットに対して行う必要があります。
• ジョブからVMへのマッピング（ルーティング）。現在、システムは1つのマシンに1つのジョブしか割り当てません。マシンは特定のエクゼキュータ設定に基づいて再利用される可能性があります。
• VM内でのジョブ実行。各VM内でジョブは事前に定義された様々なステージを通過し、結果とトレース情報をRunnerシステムに返さなければなりません。これらの詳細は、エクゼキュータの種類だけでなく、VMアーキテクチャやオペレーションシステムにも大きく依存します。

以下の用語集も参照してください。

現在の状態

現在のアーキテクチャには、懸念事項間にいくつかの結合点があります。結合は抽象化の機会を減らし（例えばコミュニティがサポートするプラグイン）、複雑さを増し、コードの理解、テスト、メンテナー、拡張を難しくします。

主な設計上の決定は、どの関心事をプラグインに外部化し、どれをランナーシステムに残すかということです。現在の実装には、新しい抽象化のためのカットポイントとして使用できるいくつかの抽象化が内部にあります。

例えばBuild タイプはGetExecutorProvider 関数を使い、ディスパッチされたエクゼキュータ文字列に基づいてエクゼキュータ・プロバイダを取得します。様々なエクゼキューター・タイプはインポートされ、初期化中にRegisterExecutorProvider を呼び出すことでシステムに登録されます。ここで抽象化されているのはExecutorProvider とExecutor インターフェースです。

docker+autoscaling Executorの中で、machineExecutor タイプは、共通のPrepare フェーズの間にVMを獲得するために使用するMachine インターフェースを持っています。この抽象化は主にVMの作成、アクセス、削除を行います。

VMのオートスケーリング・ロジックは現在、抽象化されていません。これはVMライフサイクルやジョブ・ルーティング・ロジックと緊密に結合しています。アイドル・キャパシティの作成は、ジョブを VM にバインドしている間にmachineProvider でAcquire を呼び出す副作用として発生します。

また、VM内ジョブ実行のための抽象化は現在ありません。VM固有のコマンドはGenerateShellScript 関数を使用してRunnerマネージャによって生成され、マネージャがジョブの実行ステージを駆動する際にVMに注入されます。

設計原則

私たちのゴールは、GitLab Runnerプラグインシステムのインターフェイスを、より多くのコミュニティが利用できるように柔軟かつシンプルにデザインすることです。すべてのクラウドプラットフォーム用のプラグインを作ることはできないので、プラグインを開発する必要がある人にとって参入障壁が低くなるようにしたいと考えています。誰もが貢献できるようにしたいのです。

この目標を達成するために、私たちはいくつかの重要な設計原則に従います。これらの原則は、新しいプラグインシステムの抽象化のための私たちの開発プロセスの指針となります。

一般的な高レベルの原則

• 新しいオートスケーリング・アーキテクチャは、新たな制約を課すのではなく、将来的により多くの選択肢と柔軟性を持つことを目指して設計します。
• 新しい自動スケーリングアーキテクチャを設計して、1台のマシンで複数のジョブを並行して実行する実験を行います。
• Docker Machineを置き換える新しいプロビジョニングアーキテクチャを設計し、より広いコミュニティが新しい抽象化の上に簡単に構築できるようにします。
• 新しい自動スケーリング方式はGitLab Runner製品のコアコンポーネントとなり、メンテナンスを簡素化し、他の主要製品と同じツール、テスト設定、Go言語設定を使用できるようにします。

• Linuxオペレーティングシステム上のDockerコンテナだけでなく、複数のジョブ実行環境をサポートする必要があります。

  最適な設計は、DockerやShellのような現在のエクゼキュータにラップされた機能としてオートスケーリングをもたらすことでしょう。

新しいプラグインシステムの原則

• 新しいプラグインを書くための参入障壁を低くします。
• 新しいプラグインを開発するのは簡単で、プログラミング言語とクラウドプロバイダーのAPIに関する基本的な知識があればよいはずです。
• プラグインシステムのシンプルさと柔軟性のバランスに努めましょう。これらは互いに排他的なものではありません。
• 技術的な細部はできる限り隠しますが、完全に隠さないようにしましょう。
• 私たちのコミュニティにとって有益で、かつ迅速に出荷できるような抽象化を構築してください。
• 柔軟なソリューションに投資し、一方通行の決定を避け、反復を促進します。
• 迷ったときは、より広いコミュニティにとってよりシンプルになる側に立ちましょう。
• システムをよりシンプルで拡張性のあるものにするために、懸念事項間の結合を制限してください。
• コンツェルンはプラグの片側かもう片側にあるべきで、両方にあるべきではありません。

最も重要な技術的詳細

• プラグインと GitLab Runner の間の gRPC 通信を支援します。
• 通信インターフェースのバージョンアップを可能にし、多くのバージョンをサポートします。
• Goをプラグインを書くための主要言語にしてください。

• オートスケーリングメカニズムは完全にGitLabが所有すべきです。

  クラウドプロバイダのオートスケーラーは、スケールダウンするときにどのVMを削除すればいいのか分からないので、最適とは言えない判断をしてしまいます。全てのオートスケーラーにGitLabのジョブを教えるよりも、GitLabが所有するオートスケーラーを1つ持つ方が望ましいです（プラグインにはありません）。

  そうすることで、私たちがこの仕組みの将来を形成し、私たちのニーズや要件に合った決定を下せるようになります。

プラグイン境界の提案

以下はプラグインの境界をどこに引くかについての提案です。これらの提案や他の提案を、上に挙げた設計原則と技術的制約によって評価します。

カスタムプロバイダー

作業範囲を縮小するため、新しい抽象化レイヤーを導入するのは1か所だけにしたいと思います。

数年前、私たちは GitLab Runner にCustom Executor機能を導入しました。これにより、ユーザーはカスタムビルドの実行方法を設計することができます。カスタムエグゼキュータードライバは、シンプルなシェルスクリプトから専用のバイナリまで、どのような方法でも実装することができます。

カスタムエグゼキューターの抽象化のおかげで、Runner内部で新しいエクゼキューターを実装する必要がなくなりました。特定のニーズがあるユーザーは独自のドライバを実装することができ、私たちがその作業を “公式 “GitLab Runnerの一部にするのを待つ必要はありません。各ドライバは独立したプロジェクトであるため、そのドライバを中心としたコミュニティを作ることも簡単になり、興味のある人たちが一緒に改善やバグフィックスを行うことができます。

新しい Custom Provider は、Custom Executor の成功を再現するように設計したいと考えています。Custom Executor の一つによってビルドが実行されるコンテキストや環境を提供するために、ユーザーが独自の方法を構築しやすくなります。

カスタムプロバイダの抽象化を実装する方法は複数あります。生のGoプラグイン、HashiCorpのGoプラグイン、HTTPインターフェース、gRPCベースのファサードサービスなどです。多くのソリューションがありますが、最も最適なものを選択したいと思います。そのために、別のドキュメントにソリューションを記述し、要件を定義し、それに応じてソリューションを採点します。これによって、私たちとより広いコミュニティにとって最適なソリューションを選択することができます。

この提案では、ジョブからVMへのマッピング（ルーティング）と同様に、VMのライフサイクルとオートスケールに関する関心事をプラグインに配置します。ビルドはVMを要求するだけでよく、ライフサイクルとルーティングのすべての側面がすでにプラグインによって説明されているVMを取得します。

根拠Custom Executor Provider 提案の説明

タスクスケーラ・プロバイダ

Fleeting “インターフェースの形で、Machine 抽象化のよりシンプルなバージョンを導入することができます。Fleetingは均質なVMグループに低レベルのインターフェイスを提供し、セット・サイズの増減やセット内からのVMの消費を可能にします。

クラウドプロバイダや他のVMソース用のプラグインは、HashiCorp go-pluginライブラリ経由で実装されています。これは実際にはSTDIN/STDOUT上のgRPCですが、他のワイヤプロトコルも使用できます。

新しいインターフェイスを利用するために、オートスケーリングロジックはDocker Executorから引き抜かれ、新しいTaskscalerライブラリに配置されます。

これにより、VMのライフサイクル、VMの形状、ジョブのルーティングがプラグイン内に配置されます。また、VM の自動スケーリングに関する問題を別のコンポーネントに置き、複数の Runner Executor (docker+autoscaling だけではありません) で使用できるようにします。

理由：InstanceGroup / Fleeting 提案の説明POC:マージリクエスト

用語解説

• GitLab Runner（ギットラボランナー - インストールと管理を選択できるソフトウェアアプリケーションで、ソースコードはgitlab.com/gitlab-org/gitlab-runner でホストされています。
• ランナー - Runner は GitLab CI/CD ジョブを環境で実行し、結果を GitLab インスタンスにレポーターするエージェントです。1/GitLabからジョブを取得し、/2/ローカルまたはリモートのビルド環境を設定し、/3/プロビジョニングされた環境内でジョブを実行し、ログデータとステータスの更新をGitLabに伝えます。
• runner manager- runner プロセスは、runnersconfig.toml ファイルで定義された[[runners]] ワーカーである複数の runner を管理するため、しばしばRunner Manager と呼ばれます。
• Executor- ジョブを実行するために準備され使用される具体的な環境。ジョブごとに新しい Executor が作成されます。
• エクゼキュータ・プロバイダ- オンデマンドでエクゼキュータを提供できる実装。Executor プロバイダはインポート時に登録され、Runner 起動時に一度初期化されます。
• カスタムエクゼキュータ- GitLab Runnerと、任意のホストコンピューティング環境でCIジョブを実行できるバイナリまたはシェルスクリプトのセット（環境変数入力）との間のインターフェースとして機能します。GitLab Runnerのコードベースに変更を加えることなく、新しいカスタムエクゼキュータをシステムに追加することができます。
• カスタムエクゼキュータープロバイダー- GitLab Runnerのコードベースを変更することなく新しいエクゼキュータープロバイダーを作成できるようにする新しい抽象化で、上記のプラグイン境界提案セクションのカスタムプロバイダーの見出しで提案されています。プロトコルはカスタムエクゼキューターと似ているかもしれませんし、gRPC上で行われるかもしれません。この抽象化によって、エクゼキュータ生成の仕組みはすべてプラグイン内に置かれ、オートスケーリングやライフサイクル管理はそれぞれの実装に委ねられることになります。
• taskscaler- 上記のプラグイン境界提案セクションのtaskscalerプロバイダの見出しで提案された新しいライブラリで、具体的なexecutorプロバイダとfleetingプロバイダでパラメータ化されています。Taskscalerはオートスケールを担当し、任意のVMシェイプを使用する任意のエクゼキュータ・プロバイダのオートスケールに使用できます。TaskscalerはVMライフサイクルのRunner固有の側面も担当し、与えられたVMを使用しているジョブの数と、VMが何回使用されたかを追跡します。
• fleeting- taskscalerと共に提案された新しいライブラリで、クラウドプロバイダのVMの抽象化を提供します。
• fleeting instance group- fleetingがVMのようなプールを表現するために使用する抽象化。これはGCP IGMやAWS ASG（自動スケーリングなし）を表します。インスタンスグループは増減することができ、特定のVMの接続詳細を提供することもできます。
• fleeting plugin- 特定のIGMまたはASGを表すfleetingインスタンスグループの具体的な実装（初期化時）。各プロバイダに1つずつ、それぞれ独自のプロジェクトにN個のプラグインがあります。私たちはコアなものを所有し、メンテナーしますが、いくつかはコミュニティがサポートします。新しいfleetingプラグインは、Runner、taskscaler、fleetingのコードベースに変更を加えることなく作成できます。これは、セルフサービスとデカップリングという点で、カスタムエグゼキュータープロバイダーに似ていますが、異なる懸念に沿っています。
• fleeting plugin Google Compute- GCPインスタンスを作成するfleetingプラグイン。これはfleetingやtaskscalerとは別のプロジェクトにあります。
• fleeting plugin AWS- AWSインスタンスを作成するfleetingプラグイン。fleetingやtaskscalerとは別のプロジェクトにあります。

ステータス

ステータスRFC.

誰

提案

DRI

ドメインの専門家