Ubuntu Server 18.04 – Why Ansible?

How to Install Windows Server 2019

In this chapter, I will show you how to set up Ansible, and then we will use it to automate some configuration tasks. By the end of this chapter, you’ll understand the basic concepts you can use to start the process of automating deployments in your organization. You may be wondering, then, why Ansible and not one of the other solutions such as Chef or Puppet?

Most configuration management solutions are relatively heavy from a resource perspective. With other solutions, you’ll generally have a central server which will run a master program. This program will periodically check in with each server under it is control by communicating with the agent installed on each server. Then, the agent will receive instructions from the master and carry them out. This means that you’ll need to maintain a server with modest CPU and RAM requirements, and the agent on the client side of the communication will also spend valuable CPU in order to carry out the instructions. This resource utilization can be very heavy on both the master and client.

Ansible is very different than the other solutions in that there is no agent at all. There is typically a server, but it’s not required to run any resource-intensive software. The entire configuration happens via SSH, so you can even carry out the instructions from your workstation if you want to skip having to maintain a central server. Typically, the administrator will create a user account on each server, and then the central Ansible server (or workstation) will execute commands over SSH to update the configuration on each machine. Since there is no agent installed on each server, the process takes a lot less CPU. Of course, the instructions that Ansible gives your servers will definitely result in CPU usage, but certainly a lot less than the other solutions.

Ansible is typically set up by creating an inventory file, which contains a list of hostnames or IP addresses that Ansible will be instructed to connect to and configure. If you want to add a new server, you simply make sure that a specific user account exists on that server, then you add it to the inventory list. If you want to remove it, you delete the line in the inventory file corresponding to that server. It’s very easy.

However, something that’s magical about Ansible is that you don’t even have to run a central server at all if you don’t want to. You can store your Ansible configuration in a Git repository, and have each server download code from the repository and run it locally. This means that if you do have a dynamic environment where servers come and go all the time (which is very common in cloud deployments), you don’t have to worry about maintaining an inventory file. Just instruct each server to download the code and provision themselves. This is known as the pull┬ámethod of Ansible, which I will also show you.

While solutions such as Chef and Puppet have their merits and are definitely fun to use, I think you’ll find that Ansible scales better and gives you far more control over how these hosts are configured. While it’s up to you to figure out exactly how you want to implement Ansible, the creative freedom it gives you is second to none. I’ve been using Ansible for several years, and I’m still finding new ways to use it. It’s a technology that will grow with you.

Comments are closed.