Thanks for the insight. I have decided to move the logic to the recipe as
this was the simplest solution at this point. I hope to not have to many
such cases and not have to make too much of a case out of this. Furthermore
my recipe is rather simple. It copies files from a build server and adds
links to the ‘latest’ set of files.
I have opted to create a ‘uat-prod’ environment that at least makes this
particular situation very clear.
Again not the cleanest but pretty simple at this point.
From: Arnold Krille [mailto:firstname.lastname@example.org]
Sent: 14 August 2013 20:57
Subject: [chef] Re: Re: 2 environments on one machine
On Wed, 14 Aug 2013 09:55:39 -0700 “steve .” email@example.com
A Chef node can only be in one environment at a time.
Here are the options I can think of, in ascending order of complexity:
- Spin up another machine. (Hey, we’re ordering by complexity, not
You may reduce complexity by running one of the chef-clients (and their
resources) inside an lxc-container.
Or define two lxc containers on the host (via chef:-), one for PROD with its
chef-“node” and one for UAT.
- Move your per-environment logic into roles, data bags or an
application cookbook. Roles and data bags won’t let you constrain
cookbook versions, though.
This gets messy on the chef-side.
- Run two Chef clients/nodes on the same host. You’ll need to pay
special attention to all of your cookbooks to ensure that they either
don’t share any resources or, if they absolutely have to share
resources, that they agree on the state of those resources.
Otherwise the conflicting resources will toggle back and forth between
the state that production wants it and the state that UAT wants it.
This gets messy (and unreproducible) on the client-side.
Since I started using the pxe-dust cookbook, I would just fire up another vm
with like 2 minutes of work (have to tell the dhcp-server and libvirt about
the new vm) and while the base installs, define the machine in chef and then
do something else until the machine is ready to serve…