- From: Sascha Bates <
- Subject: [chef-dev] Re: MySQL, chef-solo and node.save
- Date: Thu, 04 Oct 2012 07:21:25 -0500
On 10/4/12 2:14 AM, Zac Stevens wrote:
Given all that, I wonder whether we're defining the problem correctly.
Is the real issue with node.save's absence in chef-solo (and its
consequences in chef-client), or is the "initial database password"
problem representative of a use case that wants for a different
This is my thought as well. I've done a fair amount with Chef Server and
Solo in conjunction with small projects and toolchains. I think
chef-solo beats the hell out of a pile of shell scripts for managing an
orchestrated environment install, but I think it's not the entire answer
to the question.
No one can fangirl flail harder than I do over Chef and how much I love
it. But Solo is not an orchestration tool and all the solutions I've
been part of that use it in a toolchain have to do some hacky stuff to
make it work. One of the things I'm seeing more of out there are
orchestration tools that are tool aware, like Go and Maestro. But
everything relies on an agent existing on your target servers, which
doesn't address the initial bootstrapping where you might not have this.
For the specific issue of the password, addressing the ephemeral nature
of proof of concept environments, I don't see anything wrong with
pre-defining a plain-text password for things and either running follow
up configuration management to update the password later or just not.
It's a POC and should only be around to prove something out. If you
really need to keep it around for a while, set up something to change
the password after the install.
If it were me, and my customer's focus were already cloud-based, I'd
have a private Jenkins, or Go or I hear Red Hat has a hosted
orchestration service these days. I've also used Rundeck for this
missing piece. I would use this tool to fill in the missing pieces
where chef-solo wasn't meant to go. You could even have your last step
be to create a cron job that deletes the orchestration agent 30 minutes
after the end of a successful build if you want to cut ties with it.
Your orchestration should be as well thought out as your application and
OS configuration strategy. If Solo is being used to configure servers,
how are things being provisioned in the first place? Knife scripts? AWS
shell scripts? I have a lot of thoughts on this because I've just spent
the last couple of weeks working out how to set up CI to: create
internal Openstack VMs and external RDS Databases, check out specific
branches of code, build a project, run Chef on the VMs based on
information passed in to the orchestration tool, and have several JBoss
JVMs start up successfully. We're doing it with Jenkins and a target
environment attribute with databags keyed to it.
When all you're using is chef-solo, everything starts to look like a
chef-nail. But sometimes you need a bigger toolkit and adding a second
tool to your repertoire will be less hacky, more beautiful and probably
not take any more time to figure out than shoe-horning all your configs
Ok, now I'm late for work. (officelife)
Sascha Bates |
| 612 850 0444 |
- [chef-dev] Re: MySQL, chef-solo and node.save, (continued)
Archive powered by MHonArc 2.6.16.