WSO2 Identity Server deployment with Ansible — Part I
This blog is the first part of the series WSO2 Identity Server deployment with Ansible. This series aims to provide a brief introduction to Ansible and how it's used for deploying WSO2 Identity Server cluster setup.
Introduction to Ansible
Ansible is a simple, open-source IT automation tool that allows you to automate provisioning software, applying configurations, managing configurations, deploying applications and many other IT needs.
Why Ansible?
Let’s say we have an admin who is maintaining a hundred servers. If he wants to install tomcat on each of these servers then he has to install tomcat on server one, server two, and on all the other servers separately. Sometimes he has to repeat all the steps again and there are chances that he can make mistakes. Also, servers may not look the same.
Therefore we desperately needed a tool that makes life easier. A few years back, Chef and Puppet were the two popular names when asked about tools for software automation. But Ansible has become more popular than other tools.
How Ansible works?
Ansible playbook is a blueprint of automation tasks that automatically execute against hosts. Whatever tasks that you write in a playbook, get executed in the same order that you have written them. For example, if you have written that install tomcat first and then start, it will do the same. Playbooks are very simple to write YAML code.
Ansible comes with hundreds of inbuilt modules. Each module within an Ansible playbook performs a specific task. Each module contains metadata that determines when and where a task is executed, as well as which user executes it. You can make your custom modules as well.
The Ansible management node is the controller node, which controls the entire execution of the Playbook. It is the node from which you are running the installation, and the inventory file provides the list of the host where the modules need to be run. The controller node makes an SSH connection, and then it executes the modules on the host machines and installs the product. It removes the modules once they are installed. That is how Ansible works.
Here instead of issuing commands to the servers individually, admin will issue commands to the Ansible controller machine and that machine will communicate with the other machines(remote hosts). Hence admin can just issue one command say install tomcat on all the web servers. Then the ansible controller machine will actually go ahead and install tomcat on the other machines in our infrastructure.
Ansible communicates with remote hosts over the SSH protocol and does the setup. By default, Ansible uses native OpenSSH and connects to remote machines using your current user name, just as SSH does. And also no software needed to be installed beforehand on remote hosts.
There are several advantages to using Ansible over the other automation tools like puppet, chef, etc.
- It is agentless. You do not need to install additional software on your server nodes. This helps keep the installation clean while ensuring that there are no conflicts with our software.
- Playbooks are easy to read and edit. They are mostly written in YAML, and this is a great advantage when compared to other solutions, such as Puppet.
- Simple to Learn. You can learn the logic of Ansible operations and the workflow in a limited time period. Troubleshooting becomes a lot easier, even in the initial stages of learning about Ansible.
- It is written in Python, a very popular programming language that is familiar to engineers, making it easy to extend.
In the next article let’s discuss about how to deploy WSO2 Identity Server cluster setup using Ansible.
Reference — To know more about Ansible: https://www.ansible.com/overview/it-automation
