New day, new tasks as always. Of course, there is always something new to learn and that is the case for me today with Ansible.
At first, Ansible sounds very easy and fun but it’s not as you could go very deep and do lots of different things with it. You could build a whole infrastructure and manage multiple instances, networks, or actually anything related to the system configuration itself. Possibilities are endless really. So let’s begin.
What is Ansible?
Ansible is a simple yet powerful agentless automation solution that you could learn quickly in order to configure systems, deploy software, and generally orchestrate some more advanced IT tasks and continuous deployments with zero downtime rolling updates. It’s using OpenSSH and WinRM and it takes only a few minutes to install and it’s using an easy human-readable language. It’s secured and documentation is easy to pick up. Therefore you won’t be needing any special coding skills to use it and all the tasks you write will be executed in order.
How Does it Work?
It’s using an automation engine that runs so-called Playbooks. Playbooks contain Plays and Plays contain Tasks that are triggered by Handlers. It’s free to use since it’s open-source but there is a paid enterprise framework called Ansible Tower made by Red Hat that you could use for a little bit easier management. In order to run it, you will need one instance just for Ansible to serve you as a control station in addition to other instances that you are planning to automate.
Ansible can do things like:
- Config management
- App Deployment
- Continuous Delivery
- Security and Compliance
- Orchestration of Infrastructure
I’ve mentioned how it works with Playbooks but here is a picture that could explain it better:
You can install Ansible from multiple sources. It’s recommended to install it via OS Packages like EPEL or APT but it’s also available to install it from Pypi and other sources like GitHub. I’ve forgotten to mention that is using a Python language for automation. So the only requirement before you start would be a Python 2.7 or higher version. This might change as time passes just to know. I always install the latest stable version of Python anyway. You will also have to enable Extras and Optional yum repositories on some systems, depending on what you are using. To install it on Ubuntu for example, all it takes it’s one simple command and you are ready to go:
sudo apt install ansible
After you run the command you can validate your installation by checking your current ansible version with the command:
You should get some info in return that looks similar to this:
So now that you have it installed there are three ways to run Ansible:
- Directly calling the module from the command line
Runs a command or calls module directly from the command line, which means there is no Playbook required.
ansible <inventory> <options>
ansible web -a /bin/date
ansible web -m ping
ansible web -m yum -a “name=openssl state-latest”
As cool as this all looks to you right now, in order to do a more complex set of instructions we would have to use Playbook
- Calling a Playbook from the command line
For more serious automation we must use a Playbook. Here is an example that runs a Playbook on selected inventories from the command line:
- Using an Ansible Tower
A very useful good feature to mention that Ansible has is a so called Dry-run which validates your Playbooks before making state changes on target systems. Here is an example:
ansible web -C -m yum -a "name=httpd state=latest"
ansible-playbook -C my-playbook.yml
They also call it a check mode so I assume -C is for that.
What are Ansible Modules?
Modules control the system resources that you are automating yourself. They also control packages, files, or actually anything else that you might need in order for your infrastructure system to work. They enable more regular users to work with more complex systems.
There are over 450 Ansible-provided modules that can automate nearly every part of your environment. A standard module structure looks like this for example:
module: directive1=value directive2=value
What are Ansible Playbooks?
Playbooks as already mentioned above are containing all the possible instructions. Those are Plays, Tasks, etc. They are written in ansible automation language which is YAML based files that are describing the state of something. As I’ve said already above, they are both human and machine-readable and can be used to build entire application environments.
They can be really simple containing just a few lines or very complex nested into multiple files and systems. It all depends from your needs. There are also variables that can alter the way Playbooks run.
There are many different and interesting ways to source variables:
- Inventories (group variables, host variables, etc)
- Discovered variables (facts)
- Ansible Tower
Simply said, variables can be used anywhere inside the Playbooks.
So to summarize, Playbooks contain plays, Plays contain tasks, Tasks call modules and Tasks run sequentially. Handlers are triggered by tasks, and are run once, at the end of each play. Hopefully this makes a lot of sense to you like it does to me.
Here is an example of Playbook which has one Play, three Tasks and a Handler:
- name: install and start apache
- name: install httpd
yum: name=httpd state-latest
- name: write apache config file
template: src=srv/https.j2 dest=/etc/httpd.config
- restart apache
- name: start httpd
service: name=httpd state=running
- name: restart apache
service: name=httpd state=restarted
The three dashes at the top indicate that this is the YAML file. All other instructions are more or less self-explanatory. Oh, and you can use Ansible without the root access but you will be limited as you would normally be when not using root access.
There are many some advanced Playbook capabilities that can help Ansible run in many different ways:
with_items, failed_when, changed_when, until, ignore_errors
There are also Ansible Roles that are special kind of Playbook that are fully self-contained with tasks, variables, configurations templates and other resources and supporting files you might need. Like i’ve said at first, it can be easy and simple but you can also dive much deeper and customize everything.
What are Ansible Inventories?
In order to run a Playbook you will need an Inventory, look at it as a list of targets to be automated if that makes sense.
Inventories can be a lot of different, even customized things, very often dynamic. It could be a static line containing server info or a range of IP addresses or a dynamic list of servers from AWS, Azure, GCP, Linode, etc.
Here is an example of a static inventory list:
I know it’s not free and it might not be needed for your personal needs but it saves a lot of time and sometimes nerves when it comes to more complex IT systems. Tower actually expands automation to another layer of your free version. Here is a picture that explains it in a simple way:
Tower has a beautiful graphical interface that also helps you out managing your automation. It also helps you manage roles and permissions for improved access control.
Before moving on I also want to mention that there is a free alternative of Tower that might be worth considering for some of you. It’s called AWX and it’s actively being maintained as it seems right now.
This is my favorite part of Ansible. Galaxy is a source of community and also vendor-provided Ansible Roles templates to help you get started faster. This is very good since you could learn a lot from others that are also using Ansible. Galaxy Roles are often directly runnable with very little modification which of course saves you a lot of time. You can find thousands of Playbooks and Modules on Ansible Galaxy. The great thing about this is that if you are trying to automate something, there is a big chance many people have already done it before you so why not save yourself time and frustrations and go the right way with Galaxy.
So that would be all. If I made some mistakes or if you have any questions for me, please let me know and I will give my best to help you out with Ansible.