Let's get right to it: Every configuration management tool in use today sucks. Every. Single. One. Chef, Puppet, Ansible, Salt, Docker, etc. They're all awful in their own way. I use Chef all day long at work and am particularly familiar with the ways that it sucks. I think us DevOps folks can do better. Let's start by examining why the mainstream tools are bad and why they can’t be fixed, then move on to solutions and ideas for the future.
By far the biggest mistake that developers of configuration management tools make is to use a configuration language that is not Turing complete. This is often done to achive a “declartive” interface, where the user describes the system they want and the tool will work realize it.
DSLs are bad (example: Puppet’s “I can’t believe it’s not Ruby!” language)
Templatizing “declarative” YML or JSON is bad (example: ansible jinja2+yml)
Dockerfiles are particularly horrible
Chef is the only one that gets it right, but it has other problems (cookbook abstraction instead of just being regular Ruby libraries)
Explain why EDSLs in general purpose languages are better, use Chef as an example.
Builds dependent upon the “phase of the moon” (example: apt/yum repository fails to add because GPG keyserver was down)
Idempotence is very difficult.
What happens when you re-apply recipes to the same machine? Undefined. (example: removing a package from the config but it not being uninstalled)
“But real DevOps rebuild machines from scratch each time!” This “solution” is a side-effect of using imperative config management. High price to pay when the change to apply is small.
Builds start from an opaque base disk image. How did that image happen? What configuration/software is assumed? What happens when another image is used?
Oftentimes software is acquired in binary form from many sources with no clear provenance or way to reproduce from source. Maybe corporate folks don’t care, but free software folks definitely should care.
Chef server that gets out of sync when someone deletes a VM without telling Chef about it.
Ansible does this right.
Package managers also suck so now we’re building one OS per application. System package managers conforming to the FHS are flawed, need to move on. Proliferation of language package managers compound problem.
Getting your Chef cookbook to be portable to multiple GNU/Linux distributions (Ubuntu, CentOS, etc.) is a huge time sink, saying nothing of trying to port to other operating systems entirely like Windows or MacOS. For private usage it’s not a problem, but for public projects it is a significant burden to keep things portable.
Guix! Nix!
GuixSD! NixOS!
NixOps state files
NixOS service configuration interface (contrast with GuixSD service API)
Overview of architecture for the as-of-yet unwritten ’guix deploy’.