I’m starting to look at alternatives for the current deployment and orchestration methods here and was wondering on the capabilities of Chef Provisioning.
I’ve never used Chef provisioning before so a couple of basic questions first might help me on my way and then I’ll ask a few orchestration related questions.
How does chef provisioning store state? As in you have chef provisioning code which states to create machine “foo” in AWS, how does Chef map that created instance id or Chef node to that resource in code for idempotency?
Can recipes reference resources created in another recipe? So say a recipe is used to create a bunch of machines and attach them to a load balancer in one recipe, can another recipe then reference those machines and remove them from the load balancer?
‘What is on about?’ you may ask. I know that Chef provisioning can support a full tear down of infrastructure and recreation. I can also see that you could probably tear down an individual layer and remake based on specific recipes, but what about something like blue-green for the web layer in a separate recipe (and rollback in another recipe).
One of the problems I see is that Chef provisioning uses named resources.
For example, you have a recipe which stands up your stack and your current web layer is created by a machine_batch statement called “web layer blue” and is attached to a load balancer. If you want to deploy a release then you need to stand up your “web layer green,” test they provisioned okay, then add green to your load balancer and take off blue.
If all goes well and there’s no rollback then green becomes blue for the next deploy so you can run the same code. How can this be handled in Chef provisioning if the chef code states the the name of the resource by reference?
How have people tackled this?
One way I suppose is to have green-to-blue and blue-to-green recipes depending on current active, as well as rollbacks for both, plus the glue code to work out which one to run, etc.
Another option I suppose is to actually update your Chef code resource names based on release names as time goes on. For example deploy.rb has machine_batch “1.0.0” and update.rb has machine_batch “1.1.0.” until it’s time for 1.2.0 and then deploy.rb gets updated with “1.1.0” and machine_batch “1.2.0,” but this adds overhead to managing the code (and relies on Chef being aware of machine resources by name, which I’m not sure it does).
Or am I totally barking up the wrong tree and Chef provisioning shouldn’t be used for orchestration but rather as more foundational layer for standing up stacks and then managing them otherwise (i.e. glorified cloudformation templates)? But even in this case there would be a need to stand up a new stack but keep the existing one, is this possible?