Configuration management tools have as their primary objective the task of making a server always be in the desired state. If a web server stops, it will be started again. If a configuration file changed, it will be restored. No matter what happens to a server, its desired state will be restored. Except, when there is no fix to the issue. If a hard disk fails, there’s nothing configuration management can do.

The problem with configuration management tools is that they were designed to work with physical, not virtual servers. Why would we fix a faulty virtual server when we can create a new one in a matter of seconds. Terraform understands how cloud computing works better than anyone and embraces the idea that our servers are not pets anymore. The are cattle. It’ll make sure that all your resources are available. When something is wrong on a server, it will not try to fix it. Instead, it will destroy it and create a new one based on the image we choose.

Does that mean that there is no place for Puppet, Chef, Ansible, and other similar tools? Are they obsolete when operating in the cloud? Some are more outdated than others. Puppet and Chef are designed to run an agent on each server continuously monitoring its state and modifying it if things go astray. There is no place for such tools when we start treating our servers as cattle. Ansible is in a bit better position since it is more useful than others as a tool designed to configure a server instead to monitor it. As such, it could be very helpful when creating images.

We can combine Ansible with Packer. Packer would create a new VM, Ansible would provision that VM with everything we need and leave it to Packer to create an image out of it. If the server setup is complicated, that makes a lot of sense. The question is how complex a server setup should be? With AWS, many of the resources that would traditionally run on a server are now services. We do not set up a firewall on each server but use VPC and security group services. We don’t create a lot of system users since we do not log into a machine to deploy software. Swarm, Kubernetes, or Mesos do that for us. We do not install web servers and runtime dependencies anymore. They are inside containers. Is there a true benefit from using configuration management tools to install a few things into VMs that will be converted into images? More often than not, the answer is no. A few things we need to have can be just as easily installed and configured with a few Shell commands. Configuration management of our cattle can, and often should, be done with bash.

I might have been too harsh. Ansible is still a great tool if you know when to use it and for what purpose. If you prefer it over bash to install and configure a server before it becomes an image, go for it. If you try to use it to control your nodes and create AWS resources, you’re on a wrong path. Terraform does that much better. If you think that it is better to provision a running node instead instantiating images that already have everything inside, you must have much more patience than I do.

Now that we established my bias towards tools that are designed from the ground up to work with cloud (as opposed to on-premise physical servers), you might be wondering whether to use CloudFormation instead Terraform.

The major problem with CloudFormation is that it is designed to lock you into AWS. It manages Amazon services and not much more. Personally, I think that vendor locking is unacceptable if there is a good alternative. If you are already using AWS services to their fullest, feel free to disregard my opinion on that subject. I prefer the freedom of choice. I’m usually trying to design systems that have as little dependency on the provider as it makes sense. I’ll use a service in AWS if it’s truly better or easier to setup than some other. In some cases, that’s true, while in many others it isn’t. AWS VPCs and security groups are a good example of services that provide a lot of value. I don’t see a reason not to use them, especially since they are easy to replace if I move to a different provider. CloudWatch would be an opposite example. ELK is a better solution than CloudWatch, it’s free, and it can be ported to any provider. The same can be said, for example, for ELB. It is mostly obsolete with Docker Networking. If you need a proxy, choose HAProxy or nginx.

For you, vendor locking argument might be irrelevant. You might have chosen AWS and will stick with it for time to come. Fair enough. However, Terraform’s ability to work with a myriad of hosting providers is not the only advantage it has. When compared with CloudFormation, its configuration is easier to understand, it works well with other types of resources like DNSSimple, and its ability to display a plan before applying it can save us from a lot of painful errors. When combined with Packer, it is, in my opinion, the best combination for managing a cloud infrastructure.

The article you just finished reading is an extract from the Creating And Managing A Docker Swarm Cluster in Amazon Web Services (AWS) chapter of The DevOps 2.1 Toolkit: Docker Swarm book.

The DevOps 2.1 Toolkit: Docker Swarm

If you liked this article, you might be interested in The DevOps 2.1 Toolkit: Docker Swarm book. Unlike the previous title in the series (The DevOps 2.0 Toolkit: Automating the Continuous Deployment Pipeline with Containerized Microservices) that provided a general overlook of some of the latest DevOps practices and tools, this book is dedicated entirely to Docker Swarm and the processes and tools we might need to build, test, deploy, and monitor services running inside a cluster.

You can get a copy from Amazon.com (and the other worldwide sites) or LeanPub. It is also available as The DevOps Toolkit Series bundle.

Give the book a try and let me know what you think.