
Ask HN: Chef, Ansible, Puppet- When to Use Configuration Management? - fredrb
I wonder where these tools fit today and how they are used. Since a lot of applications are moving to containers and Kubernetes I&#x27;m struggling to understand what&#x27;s the current state these tools.
======
myu701
We use Ansible for all of our legacy tech, the non-container stuff.

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.

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?

Ansible to the rescue (or better, Terraform, which gives you more control IMO)

You need one more environment for testing the changes to a new system? Add a
line in Ansible and rerun the whole thing.

CM systems like Ansible or Terraform let you do Infra As Code and treat your
servers like cattle, not pets.

A server acts weird? take out of load balancer, delete the entire VM, re-run
ansible to recreate it, poof its happy again.

~~~
fredrb
Terraform as a Server Provisioning I can understand. What I don't understand
is: why would you use an Ansible script for server configuration rather than
have a Template Engine (e.g. Packer) with a readymade image?

~~~
rumanator
Ansible is awesome because all it requires is a working ssh connection to a
fleet of instances with python installed, and that's it. You don't need to
worry about anything. Just write your playbooks, run them when needed, and go
on with your lives. No need to install fancy software or run special OS
imagens. You can't beat that.

------
csdreamer7
I am moving away from Chef towards Ansible.

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.

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't supported anymore or chef-zero, the
new tool, which lacks documentation. (So does knife-solo, but I got it to
work.).

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.

Bad documentation was something I was hoping Chef had gotten over a long time
ago.

Some resources of Chef just do not work as documented and I end up using
manual execute commands while Ansible'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.

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 'sudo apt install ansible'.

My biggest issue with Ansible is that the error messages can be very poor.

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.

------
bkovacev
Containers do not stop you to use Chef, Ansible, Puppet or Terraform. Matter
of fact, they make it easier for you.

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'd have to
waste couple of hours/days to get right.

~~~
rumanator
If I'm not mistaken, AWS OpsWorks supports Chef and Puppet document formats to
configure AWS infrastructure. I've never used it, though.

Having said that, it's very weird to hear about using these sorts of tools
with containers. The whole point of containers is that they don't require any
configuration at all at the container level, because that's already handled
when the container image is created. After that point it's a container
orchestration problem, and that's left to the Docker Swarm/Kubernetes systems
out there.

~~~
bkovacev
Sure, you have CloudFormation templates too, which is AWS own solution as
well. There is really multiple ways of doing this. You can always manually set
up each server you plan on running as well.

My question to you is - but who installs the Docker Swarm or Kubernetes system
and make sure it runs and can be accessed by outside world?

I think you are missing the point or maybe I am not understanding where you
are coming from but in order to bring your code to a server you have multiple
layers/steps you go through:

\- Code layer

\- Artifact/Image layer (Docker Image)

\- Orchestration layer (EKS/ECS/Swarm/Compose)

\- Server Layer (Your local env, any hosted 3rd party server, your on-premise
server).

First you write the code, then you build it into an image, then you push the
image to a registry or directly, then you update your orchestration layer that
handles the image. Orchestration layer can't magically setup your server, vpc
and other services.

Containers do not have anything to do with these tools. They are tools that
supplement the workflow. Just like CI is there to help you run the tests,
build those images and push them to a registry and trigger updates to your
orchestration engine or new deploys, that's how terraform/chef/pupet are there
to make configuration changes to those servers.

------
betaby
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 _state_ 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's
compiled package, not dependent on any scripting language.

[https://cfengine.com](https://cfengine.com)

~~~
fredrb
Do you also use cf-engine to provision new nodes?

~~~
betaby
Kind of. New servers are booted from TFTP than dd deploys image, and than cf-
agent --botstrap NNNN ; cf-agent -KIC

------
core-questions
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.

~~~
PopeDotNinja
I had to make a 25GB container once. That was an adventure. Don't recommend
it.

~~~
rumanator
> I had to make a 25GB container once.

Why?

~~~
PopeDotNinja
Had a business requirement to deploy an object storage container running Minio
(S3 clone) with all the objects preloaded. It was not possible to simply
upload to the container after it had been deployed.

~~~
rumanator
Why didn't you just used volumes, and mount them in your containers when
needed?

------
nodesocket
I run and own a DevOps consulting company.

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 "file" or provisioner "remote-exec", but they work. Typically you
want to "bake" 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.

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.

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.

    
    
      [1] https://aws.amazon.com/fargate/
      [2] https://www.terraform.io/docs/providers/kubernetes/index.html

~~~
freedomben
Be aware that you are locking yourself into AWS if you structure everything
around ECS.

IMHO once you hit a certain scale the dream of vendor-independence is a lie
anyway. But while you are still small, I wouldn't box yourself in. Just my
opinion of course.

------
nunez
Containers are the way to go if your application can be containerized. It's
much easier to configure and deploy the application and its environment this
way. It'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.

Assuming that you can't or aren't able to containerize your app, Ansible is a
great all-arounder largely because of it being agentless. It'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't actually used Tower).

I dismiss Puppet these days. It's more legacy compared to Chef, and it's
harder to get recent information when searching for stuff. It's also really
hard to test locally compared to Chef with test-kitchen.

~~~
freedomben
I largely agree. Containerize as much as possible, then use Chef or Ansible
for the rest.

If you know and use Ruby, Chef can be a good choice. Otherwise, go with
Ansible. It's a lot more simple and flexible IMHO, and it's growing rapidly
(for those reasons). A note tho, while Chef is Ruby it is still a DSL that
will take some time to learn, which puts it on the same level as Ansible's
YAML based "language" that you have to learn.

I like Chef but despite being a Ruby fanboi I still use Ansible for all new
development. It's just a better developer experience.

------
twunde
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't offer, are cheaper to run
yourself or requires options that aren't available unless you run it
yourself). I'll note that for those who use immutable infrastructure patterns,
many AMI pipelines will use Packer + configuration management to create the
AMIs.

~~~
fredrb
Packer + Ansible makes a lot of sense

------
atmosx
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

