- From: Nilesh <
>
- To: "
" <
>
- Subject: [chef] Re: Re: Re: Re: Chef Solo experience / best practices?
- Date: Wed, 7 Nov 2012 10:36:56 -0800 (PST)
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=1zu7dOsPGowMLU0IIafy5sXnFKLVP0LgLi/RYAAWTpdyvDk30BqWZDeM//hHSipiygTFJDdsmeQSlqjLJ+RAAL7EEx5EmWp3VwAP7LasO39c2K1p0skcSEJUPdSscwcSDz98a34wuaHRTyn3l/0NqohPTqm4nNBwmhq7R6Fy+yQ=;
I would like to know what are the best practices for bootstrap/deployment on ec2/openstack/hpcloud/azure etc. while using chef-solo for config management. Appreciate any pointers. Thanks.
From: Booker Bense <
>
To:
Sent: Tuesday, November 6, 2012 7:11 AM
Subject: [chef] Re: Re: Re: Chef Solo experience / best practices?
The primary difference between solo and server is the ability to use search in the cookbooks. For instance, I could search for nodes that have the "dns server" role and use the results of that search to populate /etc/resolv.conf. That's a kind of trivial example, but the ability to search adds an extra layer of
automation. When I was looking at puppet vs chef, the search capabilities and database available in server were the primary deciding points in Chef's favor.
We need that desperately, you may not.
In the current version, the server is a bit of a "mystery box" to set up and run. It really depends on the scale and scope of where you are starting in your
deployment.
This podcast ( Episode 28 ) might offer some insights.
Archive powered by MHonArc 2.6.16.