Chef Server vs Chef Solo [duplicate]
I'm putting together a structure to run a Rails application. The application itself runs on Heroku. However, it makes requests to a cluster, which performs the call through a program in C.
To be able to recover from crashes faster, I want to create a routine using Chef. I managed to write a "cookbook" that installs everything you need, and it works perfectly when I use a Vagrant virtual machine.
However, when I apply for a real server, it fails. Besides, I'm using Chef Solo, and I need to manually install some things on the machine before running the script, which is not very practical.
I do not know if I should take the Chef Server in this case. I'm afraid that is a "great" tool for a "small" need.
This cluster is composed of only three machines, this should not increase much. However, the application also makes requests to another cluster slightly larger (6 machines), which despite being very quick to install, could also make use of the Chef Server.
Should go with the Chef or Chef Solo Server? Is there any didactic guide about it? The developer documentation is very confusing.
Solution 1:
This question seems subjective, but I'll try to approach this answer objectively.
The Chef Server provides a publishing system and search index with a RESTful API.
This means you can:
Distribute cookbooks for nodes through a single location that has an API, and primitives for creating version constraints, retrieval, all the things you'd probably expect out of a publishing system.
Store data (attributes) about nodes you're managing. Whether it is one or one thousand, you can get information about the nodes directly through the API. You can also use it to tell nodes to run different recipes.
Store arbitrary information about your infrastructure in what Opscode calls "data bags." This is any information you like, such as user information, application information, or anything else you can think of about your infrastructure.
Query the server for information about nodes, "what are the webservers in production?"
How does this differ from Chef Solo? Glad you asked!
With Chef Solo, you have to get the cookbooks, node attributes, data bags, etc, to the nodes yourself. This means publishing them somewhere that multiple nodes can get them, or rsync/scp a repository over to each node that is managed. There is no centralized store of the node data, and no search index for any of it.
In the beginning, it's all very small, and easy to distribute. Between 1, 3 or even 5 nodes this often isn't a problem. But then most folks find themselves with some problems.
- "It sure would be nice to have a way to upload the cookbooks to the nodes easier"
- "Man, every time we update a cookbook, production goes down because we didn't want that change done there"
- "How can we gather all the node data in one place and query it?"
The list goes on. What happens is that many people don't want to "run a chef server" so they build their own on top of git repos, http servers and the like.
The use case you're talking about (approximately 5 nodes) is the target for Opscode Hosted Chef's "5 node free" plan, then you don't have to manage a special system to be your Chef Server, at least to see if it's something that will work for your infrastructure. You can then continue to grow into larger paid plans, or move your data (easily through the API) to your own Chef Server in the future.