chef-soloの代わりにchef-serverを実行する利点は何ですか？
私はチームの自動デプロイメントソリューションを検討しており、過去数日間Chefで遊んでいます。ベースのRed HatからシンプルなWebアプリを実行できるようになりましたVM chef-soloを使用しています。
最終目標は、ビルドを実行するときにChef（または別のシステム）を使用してアプリケーショントポロジをクラウドに自動的にデプロイすることです。プロセスは基本的に次のように実行されます。
- Webアプリのコード、依存関係、シェフのクックブックはSCMに保存されています
- ビルドが実行され、取得してテストするイメージの単一パッケージが作成されます
- 次に、ビルドエンジンは、chefクライアントを実行してパッケージをインストールする新しいクラウドイメージをデプロイします。
- イメージはSCMまたはChefサーバーからクックブックを取得し、すべてをインストールして起動および実行します
Chef Serverを実行するメリットと使用例は何ですか？
chef-soloを使用し、SCMからクックブックをプルするスクリプトを使用する場合と比較して、ChefサーバーにSCMからクックブックを保持して取得させることには大きなメリットがありますか？
この答えは、「シェフソロの利点は何ですか」のように方向付けます。これは、アプローチ間の違いをカバーするために知っている最良の方法だからです。
私の概要の推奨事項は他のものと一致しています。ノードを頻繁に追加および削除する動的な仮想化環境を管理する必要がある場合は、chef-serverを使用してください。 chefサーバーも必要です [〜＃〜] cmdb [〜＃〜] （必要な場合）。ノードがあまり頻繁に変更されないが、役割とレシピは変更される、それほど動的でない環境がある場合は、chef-soloを使用します。環境のサイズと複雑さは多かれ少なかれ無関係です。どちらのアプローチも非常によく拡張されます。
Chef-soloをデプロイする場合は、rsync、 'git pull'、または他のべき等ファイル転送メカニズムを使用してcronjobを使用し、各ノードでchefリポジトリの完全なコピーを維持します。 cronjobは、（a）まったく実行されない、（b）ローカルリポジトリを同期せずに実行されるように簡単に設定できる必要があります。各ノードのjsonファイルを使用して、chefリポジトリにnodes /ディレクトリを追加します。 cronjobは、適切なノードファイルを特定するという点で望みどおりに洗練させることができます（ただし、単純に$（hostname -s）.jsonをお勧めします。opscodeアカウントを作成し、ホストされたchefを使用してクライアントを構成することもできます）。ナイフを使用してコミュニティのクックブックをダウンロードし、スケルトンを作成できること以外に理由はありません。
このアプローチには、「サーバーを管理する必要がない」という明らかなこと以外にもいくつかの利点があります。ソース管理は、すべての構成変更の最終的な調停者となり、リポジトリにはすべてのノードとランリストが含まれ、各サーバーは完全に独立しているため、いくつかの便利なテストシナリオが容易になります。
Chef-serverは、「ナイフのアップロード」を使用してクックブックを更新するホールを導入します。このホールを自分で（コミット後フックなどで）パッチする必要があります。そうしないと、「ナイフのアップロード」をした人によってサイトの変更がサイレントに上書きされるリスクがあります。ラップトップの古いローカルリポジトリからの古いレシピ。すべての変更はマスターリポジトリから直接サーバーに同期されるため、これはchef-soloで発生する可能性が低くなります。ここでの問題は、規律と協力者の数です。あなたが一人の開発者または非常に小さなチームである場合、APIを介してクックブックをアップロードすることはそれほど危険ではありません。より大きなチームでは、適切な管理を適切に行わない場合があります。
さらに、chef-soloを使用すると、すべてのノードの役割、カスタム属性、およびランリストをメインのchefリポジトリにnode.jsonファイルとして保存できます。 chef-serverでは、APIを使用してロールとランリストがオンザフライで変更されます。 chef-soloを使用すると、この情報をリビジョン管理で追跡できます。これは、静的環境と動的環境の競合が明確にわかる場所です。ノードのリスト（長さがどれほど長くても）が頻繁に変更されない場合、このデータをリビジョン管理に含めると非常に便利です。一方、新しいノードを頻繁に生成して古いノードを破棄する場合（それらのホスト名またはfqdnを再び表示する必要がない場合）、すべてをリビジョン管理に保持することは不必要な手間であり、変更を行うAPIがあると非常に便利です。 Chef-serverには、ノードを識別するデフォルトの方法としてfqdnを置き換えることができる「ナイフブートストラップ」の名前オプションなど、動的クラウド環境の管理に向けた機能全体があります。しかし、静的な環境では、これらの機能の価値は限られています。特に、リビジョン管理で他のすべてのロールとランリストを使用する場合と比較すると、そうした機能は限られています。
最後に、レシピテスト環境をオンザフライでセットアップして、追加の作業をほとんど必要としません。サーバーで実行されているcronjobsを無効にして、ローカルリポジトリに直接変更を加えることができます。 chef-soloを実行して変更をテストすると、サーバーが本番環境でどのように構成されるかを正確に確認できます。すべてがテストされたら、変更をチェックインして、ローカルのcronjobsを再度有効にできます。ただし、レシピを作成する場合、「検索」APIを使用することはできません。つまり、動的レシピ（ロードバランサーなど）を作成する場合は、この制限を回避してjsonファイルからデータを収集する必要があります。ノード/ディレクトリ。利便性が低くなる可能性が高く、フルCMDBで利用可能なデータの一部が不足します。繰り返しになりますが、より動的な環境ではデータベース主導のアプローチが優先され、動的でない環境ではローカルディスク上のjsonファイルで問題ありません。 chef runが中央データベースに対してAPI呼び出しを行う必要があるサーバー環境では、そのデータベース内のすべてのテスト環境の管理に依存します。
最後は緊急時にも使用できます。本番サーバーの重大な問題をトラブルシューティングし、構成の変更で解決する場合は、サーバーのリポジトリにすぐに変更を加えてから、それを上流のマスターにプッシュできます。
それらはシェフソロの主な利点です。サーバーを管理したり、ホストされたシェフにお金を払ったりする必要がないなど、他にもいくつかありますが、それらは比較的軽微な問題です。
要約すると、動的で高度に仮想化されている場合、chef-serverは多数の優れた機能（他の場所で説明）を提供し、chef-soloの利点のほとんどはあまり目立ちません。しかし、特により伝統的な環境では、シェフソロには明確でしばしば言及されていないいくつかの利点があります。クラウドにデプロイされているからといって、必ずしも動的な環境があるとは限らないことに注意してください。たとえば、ソフトウェアの新しいバージョンをリリースせずにシステムにノードを追加できない場合は、おそらく動的ではありません。最後に、高レベルの観点から、CMDBは、チーム間のアカウンティングや情報共有など、システムの管理と構成に接線的にのみ関連する多くのことに役立ちます。 chef-serverを使用することは、その機能だけでも価値があります。
開示：私はOpscodeで働いています。
Soloに対するChef Serverの主な利点は、インフラストラクチャで検索を使用できることです。典型的な例は、Webサーバーを備えたロードバランサーです。ロードバランサーは、Webサーバーがインフラストラクチャに追加および削除されるときに、検索するだけで、その構成を自動的に更新できます。 Soloはそれだけの1台のマシンですが、Chef Serverは「4 GBを超えるRAMを搭載したすべてのマシン」や「データベースマスター」などのクエリ機能を提供します。
Chef Serverには、tarballをコピーせずにインフラストラクチャを管理したり、管理コンソールでインフラストラクチャを視覚化したり、環境でクックブックのどのバージョンを実行しているマシンを管理したりする機能もあります。他の利点もありますが、それらは私の頭の先にあるものです。 Chefサーバーをインストールせずに試してみたい場合は、Opscode Hosted Chefアカウントにサインアップするだけで、最初の5つのノードは無料です。
chef-serverは、ノードのクックブックと構成データを管理します。
ナイフツールを使用してクックブックをchef-serverに追加し、各ノードにレシピの実行リストを提供して、ノードがchef-clientを使用して自分自身を設定するときに必要なクックブックを取得します。 chef-clientはバックグラウンドで実行されるため、ノードはchef-serverに更新されたクックブックがあるかどうかを定期的にチェックします。
chef-serverは構成データと変数も保持するため、ノードの設定を変更して自動的に取得することができます。これは、レシピでハードコーディングしてはいけない、またはハードコードできない、より動的な設定に適しています。