Consider this: a Dockerfile is a build script. It has a limited syntax, no programmatic functionality, and the moment you want some logic, you're reduced to fir

Consider this: a Dockerfile is a build script. It has a limited syntax, no programmatic functionality, and the moment you want some logic, you're reduced to firing off an inline shell script or running something else within your building container to get things configured correctly. 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're lucky and there'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. 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't use a normal Dockerfile at all. It's not common, but it's certainly an option, if you're looking for a reason why these tools might persist into the future. Other than that, the strongest use cases are: - Provisioning "legacy" stuff like EC2 or VMWare VMs, and bare metal - 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) - 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.