問題タブ [berkshelf]

gem install berkshelfFailed to build gecode libraryCentos 6 で失敗します。次の出力で失敗します。

私は Berkshelf に慣れ始めています (ちなみにこれはシェフを学ぶのに最適な方法でした)。現在、ローカル/VM 環境を提供したい PHP 開発者のために開発環境を管理/ロールアウトする方法を考えています。 Chef クックブックからプロビジョニングされます。

私は、Chef 開発者とアプリケーション開発者 (私の場合は PHP 開発者) の両方にとって理想的な環境が何であるかを理解したいと考えています。クックブックを使用する PHP 開発者のために、反復可能なローカル (または VM) 環境が必要です。

Vagrantfile を使用して、開発者が自分の証明書を使用してシェフ サーバーを構成し、プロビジョニングして、環境の使用を開始できるようにすることを考えていました。私が確信していないこと: 各開発者は、アプリケーションごとに Chef Server にリストされている独自の Vagrant ノードを持っている必要がありますか? または、vagrant ノードを登録せずに Chef クライアント プロビジョナーを使用する方法はありますか?

基本的には、ローカル マシンのノードはあまり気にしませんが、開発者が Chef サーバーから Vagrant をプロビジョニングして、他の環境と一致させることができれば素晴らしいと思います。

次に、Berkshelf で生成されたリポジトリはすべて、Chef クライアントを使用してプロビジョニングしています。それは良い習慣ですか、それとも開発運用としてクックブックを開発/テストするためだけにchef-soloを使用する必要がありますか?

主な質問 シェフがクックブック パスのクックブック ファイルを認識しないのはなぜですか? どうすれば解決できますか？

インストール済み

• rbenv
• シェフドク
• vagrant-berkshelf プラグイン

私がすでにしたこと

これを私の.zshrcに入れてください

berksのインストールも行いましたが、うまくいきました！

Vagrant プロビジョニング (エラー):

さらに詳しい情報が必要な場合は、お尋ねください。

vagrant ファイルを更新して追加します。

更新 metadata.rb が追加されました

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

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

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

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

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

思考演習 - 「MyApp」

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

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

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

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

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

• 1.0.0 - 初期開発
• 1.0.1 - webapp のバグ修正
• 1.1.0 - API に追加された新機能と webapp のバグ修正

「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 の方が気に入っています。答えを決める前に、もっと多くのフィードバックを得たいと思っています。これは理にかなっていますか？