1

フロントエンド クライアント、バックエンド API、およびいくつかのサービスで構成されるアプリケーションがある場合 (それぞれ異なる Visual Studio プロジェクトで実行される可能性があります異なるノード) 各コンポーネントは全体的な環境クックブックのレシピにする必要がありますか、それともそれぞれ独自のクックブックを持つべきですか?

各コンポーネントはそれ自体が異なるアプリケーションであるため、独自の環境クックブックが必要だと考えています。

そうしないと、複数のノードがあることを考慮して、環境の app.rb レシピがアプリケーションをデプロイする方法を想像できません。

私はこれを正しく考えていますか？他の人は Chef で分散アプリケーションをどのように実装しましたか?

編集:数日間熟考した後、私は後戻りして、 1 つの環境のクックブックパターン

思考演習 - 「MyApp」

「MyApp」は、別々にコンパイルされ、異なるノードに存在する 2 つのソフトウェア コンポーネントで構成されます。

  1. ウェブアプリ
  2. 残りの API

現在のクックブックのセットアップ:

myapp environment cookbook
- recipes
  - webapp.rb
  - restapi.rb

これは論理的ですか、それとも各ソフトウェア コンポーネントを独自のクックブックにする必要がありますか?

現在のシステムでは、リリース アーティファクトは次のようになります (各レシピはそのアーティファクトをデプロイする方法を知っています)。

myapp-vX.X.X artifact
- webapp.tar.gz
- restapi.tar.gz
- cookbooks.tar.gz
現在のリリース:
  • 1.0.0 - 初期開発
  • 1.0.1 - webapp のバグ修正
  • 1.1.0 - API に追加された新機能と webapp のバグ修正
現在の環境 
Dev        Test        Prod
1.1.0      1.1.0       1.0.1

「1.1.0 の webapp の修正を製品版に移行する必要がありますが、新しい API 機能のテストはまだ完了していません。」-マネージャー

問題: "MyApp" 本番環境の要件は、dev および test にある環境の v1.1.0 クックブックとは異なります。

可能な解決策
  1. API 機能なしで 1.0.2 リリースをカットし、環境を通じてそれを昇格させます。次に、1.1.0 を開発およびテストに昇格させます。今は最初の場所に戻っていますが、バグ修正は希望どおりに製品化されています。
  2. クックブックの再設計: webapp コンポーネントと API コンポーネントを別々のクックブックにします。
    • それぞれに独自のバージョンがあります (API 1.0.0 は、本番環境で webapp 1.0.1 と共存できます)
    • 以前のように独自のデプロイ アーティファクトを生成しますが、アーティファクトは "MyApp" アーティファクト リポジトリではなく、アプリ固有のリポジ​​トリ (例: myapp-webapp) に公開されます。
    • 新しい「myapp」環境は、必要な各アプリケーション コンポーネント クックブックのバージョンを定義するだけです。
    • 結果: API v1.0.0 は、本番環境で webapp v1.0.1 と一緒にデプロイされます。
    • 問題:
      • これらのソフトウェアは同じ論理分散アプリケーションの一部ですが、それらの共有データは論理的にグループ化されていません。例: どちらも属性で API エンドポイントを定義する必要がある場合があります (default[:myapp][:api][:endpoint])。
      • 相互互換性を追跡するのは難しい場合があります。「webapp のバージョン 1.0.1 は API の v1.2.0 と互換性がありますか?」

この猫の皮を剥く方法はたくさんあるようですが、わからない場合は、オプション #1 の方が気に入っています。答えを決める前に、もっと多くのフィードバックを得たいと思っています。これは理にかなっていますか？

4

1 に答える 1