Introduction

Ansible is one of the most widely used Infra as Code (IaC) tools for deploying IT services. At WhaTap, we also utilize Ansible for SaaS service deployment, and in today's post, we will show you how to use it through the example of deploying the WhaTap Server Monitoring Agent with Ansible.

Installing Server Agent Using apt plugin

We will start by installing the server agent. If the process of adding a gpg key and installing a package distributed as a debian file is written as an Ansible, it would look like the following.

hosts:serversbecome:truebecome_user:rootvars:tasks:-name:AddWhataprepositoryGPGkeyansible.builtin.apt_key:url:http://repo.whatap.io/debian/release.gpg-name:Getwhatap-infradebansible.builtin.apt:deb:http://repo.whatap.io/debian/whatap-repo_1.0_all.deb-name:Installwhatap-infraansible.builtin.apt:update_cache:truename:whatap-infra

This playbook performs the same actions as the following shell script from the WhaTap installation guide.

wget http://repo.whatap.io/debian/release.gpg -O -|sudo apt-key add -wget http://repo.whatap.io/debian/whatap-repo_1.0_all.debsudo dpkg -i whatap-repo_1.0_all.debsudo apt-get updatesudo apt-get install whatap-infra

Because it is a simple action, there is nothing wrong with doing it as a shell script, but there are some differences.

An Ansible will stop running if certain actions fail, but a shell script will not. For example, if a deb file download via wget fails, it will continue to run the subsequent steps.

An Ansible will not run the download if the gpg or deb file already exists on the server; a shell script will download it anew each time.

Of course, there are plenty of ways to compensate for the above shortcomings in shell scripts. However, adding a lot of defensive code can make your code longer and have a bad impact on readability, so the more complex your deployment becomes, the better you should consider adopting IaC.

Creating configuration files using the template plugin

If you are using WhaTap Server Monitoring for a service with 10 VMs, you will have 10 configuration files for the agent, which means you will need to modify 10 files every time you change a setting. If you use the same agent settings for all servers, you can just copy the files over and over again, but if you have to make slightly different configuration files for each server, the chances of making mistakes increase.

For example, WhaTap allows you to give your agents unique names, and if you manually copy the configuration file from an existing server, there is a chance you will accidentally rename the agent. This confusion can be avoided if the configuration file is created dynamically through a template plugin.

First, create an inventory like the following.            

[web-severs]web01 AGENT_NAME=web01web02 AGENT_NAME=web02web03 AGENT_NAME=web03[webapp]was01 AGENT_NAME=was01was02 AGENT_NAME=was02was03 AGENT_NAME=was03


Then write a template for the shell script that generates the configuration file as follows.



#!/bin/bashCONF="/usr/whatap/infra/conf/whatap.conf"#...echo"license=xxxxx-aaaa-bbbb-cccc"echo"oname={{ AGENT_NAME }}" |tee -a $CONFecho"createdtime=`date +%s%N`" |tee -a $CONF#...

Now, when you deploy the configuration file via the template plugin, it will automatically have the appropriate name.

What if you want to monitor the web server and WAS server in separate projects? You can do this by declaring the project access key as a group variable, like the following.

[web-severs]web01 AGENT_NAME=web01web02 AGENT_NAME=web02web03 AGENT_NAME=web03[web-servers:vars]ACCESS_KEY=aaaa-bbbb-cccc-dddd[webapp:vars]ACCESS_KEY=zzzzz-yyyyy-xxxxx-vvvvv

The shell script template is written as follows.

#!/bin/bashCONF="/usr/whatap/infra/conf/whatap.conf"#...echo"license={{ ACCESS_KEY }}" |tee -a $CONFecho"oname={{ AGENT_NAME }}" |tee -a $CONFecho"createdtime=`date +%s%N`" |tee -a $CONF#...

When you run the deployed script file, it automatically creates an access key for the group the server belongs to, and a unique agent name for each server.

In our example, we have only shown a simple way to reference a value by the name of a variable, but Ansible's template engine, jinja2, is powerful enough to be used by the web framework Flask to generate html files. With a good understanding of jinja2 syntax, there is scope to fully automate even more complex configuration file deployments.

Closing Thoughts

how to use the Template plugin in Ansible by deploying the WhaTap Server Agent as an Ansible. One of the situations where an Ansible is most useful is when you need to deploy the same application with slightly different settings, like in the example. If you understand the example well, you should be able to apply it to deploy other applications as well.

How do I get started with WhaTap Server Monitoring?

Sign up for WhaTap and start monitoring your server