Chef for immutable docker deployments?


It seems Chef isn’t good at deploying cloud infrastructure. According to this, Chef is procedural, not declarative. This means the following pseudocode in Chef:

spin-up four web-servers using AMI: LAMP-Server-AMI

Will result in four new web-servers being deployed each time the code is run. Whereas declarative tools like Terraform and Puppet will ignore the code after the first time because the web-servers already exist. The latter is preferable since it is idempotent and automation-pipeline friendly. Can of course use Terraform for the infrastructure alongside Chef to do any in-OS config, but there shouldn’t be any in-OS config if you’re running a microservices environment, since you should just be changing AMIs and re-deploying instances\environments.

My question is: does the same apply to docker? If I want to run the following pseudocode:

spin-up four web-servers in docker containers using image: LAMP-Server-Docker-Image

Will Chef be aware that either the docker-host or cluster being deployed to already has four such web-servers, or will it re-provision them every time?

Many thanks.

The information in the article linked has a number of incorrect assumptions and assertions. The most important one worth noting is the procedural vs declarative definition proffered is incorrect about Chef - like Puppet, it is about converging toward a declared state and not doing work that isn’t needed (idempotence). Orchestration and config management are two separate things which is noted in the article but then they are still compared together to misleading/confusing conclusions.

In the general case chef doesn’t do ‘provisioning’ of anything, this is chef-client making configuration changes to your OS and ensuring desired state. Now you can mix and match these tools and tools in their respective ecosystems to accomplish lots of the same goals. For example you can have immutable images (whether docker or AMIs) that are configured with chef but don’t actually use chef at runtime. It really depends what you want your infrastructure pipeline and model to be as to what is the best approach.

I think the better question here is what are you trying to achieve?