Making Your Life Easier with the Top 5 Ansible Modules
Tags: devops, ansible
Published: 2021-03-02 07:05:55


Ansible is a radically simple IT automation engine that automates [cloud provisioning](https://www.ansible.com/provisioning?hsLang=en-us), [configuration management](https://www.ansible.com/configuration-management?hsLang=en-us), [application deployment](https://www.ansible.com/application-deployment?hsLang=en-us), [intra-service orchestration](https://www.ansible.com/orchestration?hsLang=en-us), and many other IT needs.

Designed for multi-tier deployments since day one, Ansible models your IT infrastructure by describing how all of your systems inter-relate, rather than just managing one system at a time.

It uses no agents and no additional custom security infrastructure, so it’s easy to deploy — and most importantly, it uses a very simple language (YAML, in the form of Ansible Playbooks) that allow you to describe your automation jobs in a way that approaches plain English.

## 5. [authorized_key](https://docs.ansible.com/ansible/latest/modules/authorized_key_module.html)

Secure shell (SSH) is at the heart of Ansible, at least for almost everything besides Windows. Key (no pun intended) to using SSH efficiently with Ansible is… [keys](https://linux.die.net/man/1/ssh-keygen)! Slight aside — there are a lot of very cool things you can do for security with SSH keys. It’s worth perusing the **authorized_keys **section of the [sshd manual page](https://linux.die.net/man/8/sshd). Managing SSH keys can become laborious if you’re getting into the realms of granular user access, and although we could do it with either of my next two favourites, I prefer to use the module because it [enables easy management through variables](https://github.com/phips/ansible-demos/blob/3bf59df1eb2390b31b5c42333197e2fbb7fec93f/roles/ansible-users/tasks/main.yml#L35).

## 4. [file](https://docs.ansible.com/ansible/latest/modules/file_module.html)

Besides the obvious function of placing a file somewhere, the **file** module also sets ownership and permissions. I’d say that’s a lot of *bang for your buck* with one module. I’d proffer a substantial portion of security relates to setting permissions too, so the **file** module plays nicely with **authorized_keys**.

## 3. [template](https://docs.ansible.com/ansible/latest/modules/template_module.html)

There are so many ways to manipulate the contents of files, and I see lots of folk use [**lineinfile](https://docs.ansible.com/ansible/latest/modules/lineinfile_module.html)**. I’ve used it myself for small tasks. However, the **template** module is so much clearer because you maintain the entire file for context. My preference is to write Ansible content in such a way that anyone can understand it *easily* — which to me means not making it hard to understand what is happening. Use of **template** means being able to see the entire file you’re putting into place, complete with the variables you are using to change pieces.

## 2. [uri](https://docs.ansible.com/ansible/latest/modules/uri_module.html)

Many modules in the current distribution leverage Ansible as an orchestrator. They talk to another service, rather than doing something specific like putting a file into place. Usually, that talking is over HTTP too. In the days before many of these modules existed, you *could* program an API directly using the **uri** module. It’s a powerful access tool, enabling you to do a lot. I wouldn’t be without it in my fictitious Ansible shed.

## 1. [shell](https://docs.ansible.com/ansible/latest/modules/shell_module.html)

The joker card in our pack. The Swiss Army Knife. If you’re absolutely stuck for how to control something else, use **shell**. Some will argue we’re now talking about making Ansible a Bash script — but, I would say it’s still better because with the use of the **name** parameter in your plays and roles, you document every step. To me, that’s as big a bonus as anything. Back in the days when I was still consulting, I once helped a database administrator (DBA) migrate to Ansible. The DBA wasn’t one for change and pushed back at changing working methods. So, to ease into the Ansible way, we called some existing DB management scripts from Ansible using the **shell** module. With an informative **name** statement to accompany the task.

![](https://cdn-images-1.medium.com/max/2000/1*qQqS2gMOOtb7AwBVckEYqg.png)

**Get the book**: [Sysadmin Interview Questions](https://leanpub.com/sysadmin-interview-questions)

**Additional learning resources:**

[Ansible Advanced — Hands-On — DevOps](https://coursesim.com/course/ansible-advanced-hands-on-devops/)

[Mastering Ansible](https://click.linksynergy.com/deeplink?id=NcMZU1aTATA&mid=39197&murl=https%3A%2F%2Fwww.udemy.com%2Fcourse%2Fmastering-ansible%2F)

reference sites: [https://opensource.com/article/19/11/ansible-modules](https://opensource.com/article/19/11/ansible-modules)