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.
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! 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. 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.
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.
There are so many ways to manipulate the contents of files, and I see lots of folk use lineinfile. 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.
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.
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.
Get the book: Sysadmin Interview Questions
reference sites: https://opensource.com/article/19/11/ansible-modules
Other Posts from The Programming Hub:
Top 10 Answers to SysAdmin Interview Questions that Might Save your Life
What does a System Administrator do?
12 Tools Successful DevOps Engineers are using today for the Most Efficient Operation
There is a lot of misconception regarding — Who is a DevOps Engineer? Is he the guy who writes code and is also…
Best Analogy to Explain Kubernetes in under 10 mins
Having trouble understanding Kubernetes? Try this analogy of using a rental house to explain how it works.
The Ultimate Guide for Ansible Total Domination
Ansible is a radically simple IT automation engine that automates cloud provisioning, configuration management…