Deploy Webserver on AWS using Ansible Automation
When automation comes into play, all we need is just one command and a whole webserver with a running webpage is deployed on the top of AWS cloud!!
Ansible is an open-source software provisioning, configuration management, and application-deployment tool enabling infrastructure as code. It runs on many Unix-like systems, and can configure both Unix-like systems as well as Microsoft Windows. It is managed primarily by Redhat and uses Python as the backend.
Unlike most configuration-management software, Ansible does not require a single controlling machine where orchestration begins. Ansible works against multiple systems in your infrastructure by selecting portions of Ansible’s inventory, stored as edit-able, version-able ASCII text files. Not only is this inventory configurable, but you can also use multiple inventory files at the same time and pull inventory from dynamic or cloud sources or different formats (YAML, INI, etc.) Any machine with Ansible utilities installed can leverage a set of files/directories to orchestrate other nodes.
Modules are mostly standalone and can be written in a standard scripting language (such as Python, Perl, Ruby, Bash, etc.). One of the guiding properties of modules is idempotency, which means that even if an operation is repeated multiple times (e.g., upon recovery from an outage), it will always place the system into the same state.
Playbooks are YAML files that express configurations, deployment, and orchestration in Ansible, and allow Ansible to perform operations on managed nodes. Each Playbook maps a group of hosts to a set of roles. Each role is represented by calls to Ansible tasks.
But the question that arises is, why should we use Ansible? Moreover, the practical that is going to be demonstrated here can be very easily automated using Terraform, so what’s the need of shifting to Ansible? Well, let us sum up some cool features of ansible that’re going to play a role in this practical :-
- Very simple to set up and use: No special coding skills are necessary to use Ansible’s playbooks
- Powerful: Ansible lets us model even highly complex IT workflows.
- Flexible: We can orchestrate the entire application environment no matter where it’s deployed.
- Agentless: We don’t need to install any other software or firewall ports on the client systems you want to automate.
And however, its always interesting to try out new automation techniques, isn’t it? :)
So, let’s jump into technology and get a quick glance at the problem statement to be dealt here —
- Provision EC2 instance using Ansible
- Retrieve the IP address of the instance using dynamic inventory concept
- Configure webserver through Ansible
- Create tasks for the host to customize the instance and deploy the webpage to root directory.
For integrating AWS with Ansible, it is very essential to provide the Access key and Secret key for an account. However, providing these keys directly in the code is never appreciable as any user can retrieve the keys and use the AWS account for uncalled for reasons, so we would hardcode the keys in an Ansible vault and secure it with a unique password using the command —
ansible-vault create keys.yml
The configuration file for Ansible is at the location /etc/ansible/ansible.cfg.
Next step is to write a playbook that would create and provision an ec2 instance. This is done using the ec2_instance module in ansible. The code snippet for the same is as follows —
Here, we can notice a keyword “register”. Ansible registers are used when we want to capture the output of a task in a variable (here x). In simpler words, the variable carry the value returned by the task. Here, the output to provision of an instance is the instance’s public IP, that’s what has been stored so that it can be used in the concept of dynamic inventory.
Now let’s have a look at our dynamic inventory which is coded in jinja format and included in the playbook.
Once the instance has been provisioned and we have proper access to it, the next step would be to configure it as a webserver and copy our webpage to the document root for deployment. The relevant code snippet for the same is —
That marks a good playbook for the complete provision!
Now, let’s deploy our playbook….
- A check on the ansible version —
ansible --version
- Since we would be using the ec2_instance module, we would require Boto3 to be installed in the controller node.
pip3 install boto3
- Once the environment is ready, we are good to go with running the playbook.
ansible-playbook aws-webserver.yml --vault-password-file passwd The output of running the playbook would look somewhat like the following
Once the playbook has been run successfully, we can see an instance launched on AWS.
On running the public DNS of the instance on a new tab, we can verify that our coded webpage will be successfully deployed!
→ Now, a note to be done here is that we have kept the host file as a jinja template and never manually appended the instance IP in it. Now here is the part where dynamic inventory plays its role, if we give a look at the host file once our instance is launched, we can find the instance IP there!
Well, that’s the magic of a configuration management tool!!