Ask HN: Chef, Ansible, Puppet- When to Use Configuration Management?

We use Ansible for all of our legacy tech, the non-container stuff.<p>Rather than a dev ask a server guy to make a vm, then join it to the domain, then move it to the right OU, then install anti-virus, etc. then ask a dba to install SQL server, import the database schema, setup permissions, and enable network access, we write an ansible playbook that does it all in a repeatable manner, the same way every time.<p>You have an n-tier app with a reverse proxy load balancing for 3 web servers and 1 database server, and you want one copy of this app for dev, one for staging, and one for prod, and you want them all the same?<p>Ansible to the rescue (or better, Terraform, which gives you more control IMO)<p>You need one more environment for testing the changes to a new system? Add a line in Ansible and rerun the whole thing.<p>CM systems like Ansible or Terraform let you do Infra As Code and treat your servers like cattle, not pets.<p>A server acts weird? take out of load balancer, delete the entire VM, re-run ansible to recreate it, poof its happy again.

I am moving away from Chef towards Ansible.<p>Chef even now lacks a good ad-hoc mode that makes it easy to run one liners. Little info on Puppet. Do know that Puppet uses a separate tool called Bolt for ad hoc commands, while Ansible has it built in.<p>Chef really tries to force you to use their Chef server to really run anything. If you just want to provision a single server you needed to use an unofficial tool, knife-solo, which isn&#x27;t supported anymore or chef-zero, the new tool, which lacks documentation. (So does knife-solo, but I got it to work.).<p>The binary builds of Chef now require an EULA license agreement to use run it. Even thou the open source version is under Apache2. The annoying part is you have to place a file on every machine to keep running it. This is also not documented properly.<p>Bad documentation was something I was hoping Chef had gotten over a long time ago.<p>Some resources of Chef just do not work as documented and I end up using manual execute commands while Ansible&#x27;s providers usually consistently works. Ansible documents which providers are by the community (and are included in the main package) and which are maintained by the Ansible team and are guaranteed to have a stable API. Something I really appreciate and gives me confidence in my Ansible scripts. Ansible also a Docker provider.<p>Chef also really requires you to use a Ruby gem manager which is a hassle if you are not using Ruby right now. Since I have stopped using Ruby it is a lot easier to just &#x27;sudo apt install ansible&#x27;.<p>My biggest issue with Ansible is that the error messages can be very poor.<p>Take the snap provider for example. The older version on Ubuntu 18.04 does not support the later snap provider in later version of Ansible that my dotfile manager uses. This by itself is a small issue, but the error message it gives is very makes you think you have a syntax issue with an unrelated part rather than an undocumented keyword.

Containers do not stop you to use Chef, Ansible, Puppet or Terraform. Matter of fact, they make it easier for you.<p>We use Terraform to setup new reproducible environments for all of our projects. We have full modules for ECS, EC2 and various others combination of services that we repeatedly use on AWS. It makes it really easy to set something up and not worry about it. Helps us setup bastions, rds, clusters, task definitions, scaling, vpc, alb and all the other things you&#x27;d have to waste couple of hours&#x2F;days to get right.

Well, someone still have to manage hardware nodes! So I use cf-engine to install smatrd, manage ssh keys, to install packages an so on. Also configuration management for the servers where <i>state</i> lives, like your git repos, db, documentation, internal knowledge systems. To ensure backup software is installed and running. I prefer cf-engine due to the fact it&#x27;s compiled package, not dependent on any scripting language.<p><a href="https:&#x2F;&#x2F;cfengine.com" rel="nofollow">https:&#x2F;&#x2F;cfengine.com</a>

Consider this: a Dockerfile is a build script. It has a limited syntax, no programmatic functionality, and the moment you want some logic, you&#x27;re reduced to firing off an inline shell script or running something else within your building container to get things configured correctly.<p>At a certain point, you may start to need more logic in your build. If you have a big container designed to run an older app, you may need to install a lot of dependencies; and maybe you&#x27;re lucky and there&#x27;s a Makefile, maybe not. The result might be some ugly shell script that gets more complex and harder to read over time, as you re-implement more and more of what would already be in the wheelhouse of a good config manager.<p>You could instead just use Ansible or Chef Zero to run all of that logic inside your container. Packer is happy to run Chef Zero and output totally compliant Docker containers for you that don&#x27;t use a normal Dockerfile at all. It&#x27;s not common, but it&#x27;s certainly an option, if you&#x27;re looking for a reason why these tools might persist into the future.<p>Other than that, the strongest use cases are:<p>- Provisioning &quot;legacy&quot; stuff like EC2 or VMWare VMs, and bare metal<p>- Keeping long-lived servers up to date and maintaining their replace-ability as best as possible (i.e. the next best thing to immutable infra is replaceable infra)<p>- Automating integrations, i.e. Ansible and Chef have a ton of modules for services like Zabbix, Consul, etc. you can use as part of your script to get a machine totally ready to serve on the network without you re-implementing API calls.

I run and own a DevOps consulting company.<p>Huge proponent of Packer + Terraform. Running commands and copying files on boot of VM instances can be a bit dodgy (cloud-init) or using Terraform provisioner &quot;file&quot; or provisioner &quot;remote-exec&quot;, but they work. Typically you want to &quot;bake&quot; as much as possible into the AMI using Packer and anything that is runtime dependent, can be setup by Terraform on instance create using the methods described above.<p>If you running standard Docker containers and AWS, highly recommend AWS ECS using Fargate[1]. No servers to manage, just define the services and container details and ECS runs the containers for you. Blue-green deploys and auto-scaling out of the box with health checks.<p>If you running Kubernetes, I highly recommend looking at using Terraform to manage the Kubernetes resources[2]. Helm, while nearly a defacto standard is full of edge cases, weird quirks, and utter frustration. Oftentimes Helm is required though to work within the Kubernetes ecosystem.<p><pre><code> [1] https:&#x2F;&#x2F;aws.amazon.com&#x2F;fargate&#x2F; [2] https:&#x2F;&#x2F;www.terraform.io&#x2F;docs&#x2F;providers&#x2F;kubernetes&#x2F;index.html</code></pre>

Containers are the way to go if your application can be containerized. It&#x27;s much easier to configure and deploy the application and its environment this way. It&#x27;s also much easier to test a production-like copy of the application in development without having to spin up a bunch of infrastructure locally.<p>Assuming that you can&#x27;t or aren&#x27;t able to containerize your app, Ansible is a great all-arounder largely because of it being agentless. It&#x27;s easy to install and easy to scale. However, really large organizations usually want to use their configuration management as a CMDB of sorts. While Red Hat has Ansible Tower for this, Chef provides a much more mature offering (from hearsay; I haven&#x27;t actually used Tower).<p>I dismiss Puppet these days. It&#x27;s more legacy compared to Chef, and it&#x27;s harder to get recent information when searching for stuff. It&#x27;s also really hard to test locally compared to Chef with test-kitchen.

For cloud-based systems, configuration management is really used primarily for configuring kubernetes hosts and more traditional run-your-own services like SFTP (these may be things that your cloud doesn&#x27;t offer, are cheaper to run yourself or requires options that aren&#x27;t available unless you run it yourself). I&#x27;ll note that for those who use immutable infrastructure patterns, many AMI pipelines will use Packer + configuration management to create the AMIs.

Ideally never. The only reason to work with CF tools is through Hashicorp packer or legacy staff that doesn’t make sense to setup on orchestrators. The infra should be immutable