Hi,
I have the unfortunate situation of having to deploy UAT and PROD artefacts on a single machine. Is there an efficient way to manage this with environments? Or should I look into doing it some other way? It feels very natural to use the environment to store the attributes for the version I want to release in each situation.
Cheers,
Florian
On Aug 14, 2013, at 11:31 AM, Florian Hehlen florian.hehlen@gmail.com wrote:
I have the unfortunate situation of having to deploy UAT and PROD artefacts on a single machine. Is there an efficient way to manage this with environments? Or should I look into doing it some other way? It feels very natural to use the environment to store the attributes for the version I want to release in each situation.
My understanding is that each machine should be in one and only one environment at a time.
If you need to deploy both types of artifacts, then maybe you want to do separate runs and move the machine from one environment to the other between the runs?
Or maybe Chef environments is not the right method to use for separating these types of artifacts?
--
Brad Knowles brad@shub-internet.org
LinkedIn Profile: http://tinyurl.com/y8kpxu
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:
Good luck!
On Wed, Aug 14, 2013 at 9:31 AM, Florian Hehlen florian.hehlen@gmail.comwrote:
Hi,****
I have the unfortunate situation of having to deploy UAT and PROD
artefacts on a single machine. Is there an efficient way to manage this
with environments? Or should I look into doing it some other way? It feels
very natural to use the environment to store the attributes for the version
I want to release in each situation.****
Cheers,****
Florian****
Hi,
On Wed, 14 Aug 2013 09:55:39 -0700 "steve ." leftathome@gmail.com
wrote:
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
cost...)
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...
Have fun,
Arnold
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.
Cheers,
Florian
-----Original Message-----
From: Arnold Krille [mailto:arnold@arnoldarts.de]
Sent: 14 August 2013 20:57
To: chef@lists.opscode.com
Subject: [chef] Re: Re: 2 environments on one machine
Hi,
On Wed, 14 Aug 2013 09:55:39 -0700 "steve ." leftathome@gmail.com
wrote:
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
cost...)
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...
Have fun,
Arnold