Hi folks-
We’re curious about how people are managing the chef server components
(Chef Server API/webui, CouchDB, Solr Indexer, rabbitMQ, etc) and the
machine all this is running on.
First, the machine: it seems feasible to assign a role to the node
running the server, and to use that role to manage the prosaic stuff:
packages, iptables, ntp, accounts, etc; all the stuff we’re managing on
the all the other nodes. Are there any gotcha’s to just running
chef-client on the chef server node?
Second, the chef server components: this seems much more complicated. Do
people try to manage updates to the chef server components with chef
itself, or do you simply use chef-solo to do the initial install and
then manage updates by hand?
-Jim
Knife has a bootstrap option to setup a box as a chef client which you can
use chef solo to then run the bootstrap cookbook for server components.
There's no magic with chef server and client living on the same machine
except that the validation key is already on the machine so it saves you a
step
On Oct 10, 2010 11:49 AM, "Jim Hopp" jim.hopp@workday.com wrote:
Hi folks-
We're curious about how people are managing the chef server components
(Chef Server API/webui, CouchDB, Solr Indexer, rabbitMQ, etc) and the
machine all this is running on.
First, the machine: it seems feasible to assign a role to the node
running the server, and to use that role to manage the prosaic stuff:
packages, iptables, ntp, accounts, etc; all the stuff we're managing on
the all the other nodes. Are there any gotcha's to just running
chef-client on the chef server node?
Second, the chef server components: this seems much more complicated. Do
people try to manage updates to the chef server components with chef
itself, or do you simply use chef-solo to do the initial install and
then manage updates by hand?
-Jim
Right, we do use chef-solo for the initial install of chef server. I'm
wondering how people manage on-going updates to the chef server
components. But I guess we won't be changing the chef server components
very often; most of the changes to the machine will be the standard
machine config stuff. Thanks for the affirmation that we can just use
chef-client for that.
-Jim
On 10/10/2010 12:35 PM, sahil.cooner@gmail.com wrote:
Knife has a bootstrap option to setup a box as a chef client which you
can use chef solo to then run the bootstrap cookbook for server
components.
There's no magic with chef server and client living on the same
machine except that the validation key is already on the machine so it
saves you a step
On Oct 10, 2010 11:49 AM, "Jim Hopp" <jim.hopp@workday.com
mailto:jim.hopp@workday.com> wrote:
Hi folks-
We're curious about how people are managing the chef server components
(Chef Server API/webui, CouchDB, Solr Indexer, rabbitMQ, etc) and the
machine all this is running on.
First, the machine: it seems feasible to assign a role to the node
running the server, and to use that role to manage the prosaic stuff:
packages, iptables, ntp, accounts, etc; all the stuff we're managing on
the all the other nodes. Are there any gotcha's to just running
chef-client on the chef server node?
Second, the chef server components: this seems much more
complicated. Do
people try to manage updates to the chef server components with chef
itself, or do you simply use chef-solo to do the initial install and
then manage updates by hand?
-Jim
The Opscode repository contains a cookbook to manage Chef, which has a
server recipe included - the same one used when doing a chef-solo
bootstrap of the server.
That's capable of keeping your Chef server up to date, and runs
maintenance tasks to reduce the size of your CouchDB database.
Jon
On 10 October 2010 21:16, Jim Hopp jim.hopp@workday.com wrote:
Right, we do use chef-solo for the initial install of chef server. I'm
wondering how people manage on-going updates to the chef server components.
But I guess we won't be changing the chef server components very often; most
of the changes to the machine will be the standard machine config stuff.
Thanks for the affirmation that we can just use chef-client for that.
-Jim
On 10/10/2010 12:35 PM, sahil.cooner@gmail.com wrote:
Knife has a bootstrap option to setup a box as a chef client which you can
use chef solo to then run the bootstrap cookbook for server components.
There's no magic with chef server and client living on the same machine
except that the validation key is already on the machine so it saves you a
step
On Oct 10, 2010 11:49 AM, "Jim Hopp" jim.hopp@workday.com wrote:
Hi folks-
We're curious about how people are managing the chef server components
(Chef Server API/webui, CouchDB, Solr Indexer, rabbitMQ, etc) and the
machine all this is running on.
First, the machine: it seems feasible to assign a role to the node
running the server, and to use that role to manage the prosaic stuff:
packages, iptables, ntp, accounts, etc; all the stuff we're managing on
the all the other nodes. Are there any gotcha's to just running
chef-client on the chef server node?
Second, the chef server components: this seems much more complicated. Do
people try to manage updates to the chef server components with chef
itself, or do you simply use chef-solo to do the initial install and
then manage updates by hand?
-Jim
--
Jon Wood
Blank Pad Development
07827 888143
OK, being Chef novices, we weren't clear whether there was anything
particularly clever needed to upgrade and restart a running chef server.
Perhaps not, since I suppose the restart would be initiated in any case by
a chef-client or chef-solo process which is basically independent of the
chef-server it's restarting (though it's also not clear to me whether or not
the chef-client or chef-solo might not subsequently try to make requests to
the chef-server process e.g. for data-bags used by later resources while it
is rebooting, and what would happen if these requests failed with an
ECONNREFUSED).
Also, assuming that you're referring to the chef/recipes/server.rb recipe,
we've actually had difficulties with it failing to restart chef-server at
all if you are running chef-server-webui due, I think, to
COOK-364http://tickets.opscode.com/browse/COOK-364
.
Thanks,
Michael
On Mon, Oct 11, 2010 at 2:00 AM, Jon Wood jon@blankpad.net wrote:
The Opscode repository contains a cookbook to manage Chef, which has a
server recipe included - the same one used when doing a chef-solo
bootstrap of the server.
That's capable of keeping your Chef server up to date, and runs
maintenance tasks to reduce the size of your CouchDB database.
Jon
On 10 October 2010 21:16, Jim Hopp jim.hopp@workday.com wrote:
Right, we do use chef-solo for the initial install of chef server. I'm
wondering how people manage on-going updates to the chef server
components.
But I guess we won't be changing the chef server components very often;
most
of the changes to the machine will be the standard machine config stuff.
Thanks for the affirmation that we can just use chef-client for that.
-Jim
On 10/10/2010 12:35 PM, sahil.cooner@gmail.com wrote:
Knife has a bootstrap option to setup a box as a chef client which you
can
use chef solo to then run the bootstrap cookbook for server components.
There's no magic with chef server and client living on the same machine
except that the validation key is already on the machine so it saves you
a
step
On Oct 10, 2010 11:49 AM, "Jim Hopp" jim.hopp@workday.com wrote:
Hi folks-
We're curious about how people are managing the chef server components
(Chef Server API/webui, CouchDB, Solr Indexer, rabbitMQ, etc) and the
machine all this is running on.
First, the machine: it seems feasible to assign a role to the node
running the server, and to use that role to manage the prosaic stuff:
packages, iptables, ntp, accounts, etc; all the stuff we're managing on
the all the other nodes. Are there any gotcha's to just running
chef-client on the chef server node?
Second, the chef server components: this seems much more complicated. Do
people try to manage updates to the chef server components with chef
itself, or do you simply use chef-solo to do the initial install and
then manage updates by hand?
-Jim
--
Jon Wood
Blank Pad Development
07827 888143