次の設定があります。
Vagrantを使用してVagrantファイルを各リポジトリに含めたいので、チームメンバーがリポジトリを複製してvagrant up
と準備が整いました。
私の質問は今プロビジョニングに向けられています。 Apache、git、mysql、いくつかのphpパッケージなどのいくつかのツールとパッケージをインストールしてから、いくつかのファイル(最近の開発DBダンプなど)をダウンロードし、すべてを/ var/wwwに設定して、composerインストールコマンド。
したがって、これを行う1つのオプションは、シェフや人形などのレシピを使用するマネージャーを使用することです。代わりの方法は、bashファイルを作成してシェルプロビジョニングを使用することです。
私はシェフ/人形の経験があまりないので、当然のことながら、シェルオプションを使用する方が簡単に思えますが、長期的には、これが適切で実行可能なオプションではないかどうかを理解したいと思います。
なぜ私にとって、人形/シェフと一緒に行くのは悪いアプローチのようです:
私はいくつかの異なるレシピを使用する必要があり、ほとんどの場合、異なるリポジトリに同じレシピを使用することを理解しているため、すべてのリポジトリにそれらのすべてを含める必要があります。 20個のリポジトリと10個のレシピが必要であることを考慮してください。つまり、200個のレシピをgitサブモジュールなどとして追加する必要があります(各チームメンバーはリポジトリを複製し、次に10個のレシピリポジトリを複製して、それぞれに対してvagrantを実行する必要があります)事業)。対照的に、シェルスクリプトを含む小さなリポジトリを用意し、それを20回複製するだけで済みます。
私はおそらく何かが足りないので、chef/puppetを選択する必要があるかどうか、およびすべてのリポジトリに非常に類似したサーバー設定がある場合でもそれが理にかなっている理由をアドバイスしてください。
次の記事はさらに別のCMツール( ansible )に関するものですが、著者はシェルスクリプトから移行することの利点を説明する優れた仕事をしていると思います。
http://devopsu.com/blog/ansible-vs-Shell-scripts/
引用1:
私を本当に驚かせたのは、これらのより有名な開発者からの反応でした。彼らは基本的に「これは本当に素晴らしいですが、私の手動インストール/シェルスクリプトワークフローは今のところ問題ないので、おそらく読まないでしょう」と述べました。
私は少しショックを受けましたが、数分間考えてみると、彼らがCMツールについて知っていることを考えると、彼らの選択は完全に正気で合理的であることがわかりました。
引用2:
彼らにとって、CMツールを使用するということは、複雑な概念を学び、複雑なインストールプロセスに苦労し、その複雑なシステムを長期にわたって維持するための数週間の努力を意味しました。彼らは多少の利点を認識していましたが、CMツールを使用するコストは高すぎて努力に値しないように思われました。
シェルスクリプトよりも優れている点は最後にまとめられており、それらはすべてのCMツール、パペット、シェフ、ソルト、アンシブルに当てはまると思います...
お役に立てれば。
2016年更新
グーグルを通じてこれを見つけた人にとって、それは 多数の開発者 が単純化のためにAnsibleに向かっているようです。投稿から:
「Ansibleは、デプロイメントツールが嫌いな人のためのデプロイメントツールです。スクリプトに近く、エージェントや集中型サーバーでサーバーを汚染せず、すぐに理解できます。」
最近、マイクロサービスアーキテクチャに実装しました。
人形/シェフは常に私の心/スタックの場所を持っていますが、Ansibleの方が簡単です。