典型的なシナリオは、ソースをビルドし、jenkins などの CI システムを使用して deb を生成/公開し、deb にその依存関係を宣言させることです。
使用しているビルド システムに応じて、deb を生成するためのかなりの数のオプションがあります。多くの人が gradle と nebula ( https://nebula-plugins.github.io/ ) と呼ばれる Netflix OSS プラグインを使用しています。
ここ ( http://www.spinnaker.io/docs/from-source-to-prod ) に包括的なチュートリアルがあり、次の方法を示しています。適切なローカル リポジトリ) - Spinnaker パイプラインをトリガーし、新しいイメージをベイクして、テスト クラスターにデプロイする - 手動で判断を実行する - テスト クラスターで検証済みのイメージを見つけて、prod クラスターに昇格させる
この Codelab の概念はほとんどが一般的なものですが、既定の GCE イメージを使用して、構成なしで稼働させることができます。GCEで実行していると述べたように、それはうまくいくはずです。
もちろん、他のベイク/デプロイ戦略を採用することもできますが (起動時に構成管理システムに依存する人もいます)、deb をビルドしてイメージにベイクするのが、説明したシナリオに最も適しているようです。
新しくベイクしたイメージに webapp のクローンを作成したい場合は、カスタム パッカー テンプレートを作成することでこれを行うことができます。パッカー テンプレートはすべてこのディレクトリ ( https://github.com/spinnaker/rosco/tree/master/rosco-web/config/packer ) にあり、使用できます ( https://github.com/spinnaker/rosco/ blob/master/rosco-web/config/packer/gce.json ) を出発点として使用します。
次に、この行 ( https://github.com/spinnaker/rosco/blob/master/rosco-web/config/packer/gce.json#L33 ) を変更して、独自のシェル スクリプトを呼び出します。シェルスクリプトは、必要なレポを複製し、好きなようにビルド/テストできます。ここでは packer に依存しているため、packer でサポートされている他のプロビジョナーもここで使用できます。
最後のステップは、Bake Stage 構成 UI で新しいカスタム パッカー テンプレートを、必要なパラメーター (ある場合) と共に指定することです。