Ansible Modules From The Command Line

To get you ready for bigger things.

Vince Sesto
Splunk User Developer Administrator
5 min readFeb 8, 2018

--

Ansible comes with over 1,300 modules as part of the installation and you’re most likely wanting to get these modules running with playbooks. But before you get started with playbooks, it could be good to get used to the syntax and arguments used for a lot of the more popular modules you might be using.

If you need to run through the basics of Ansible first, click here to go to our first post in this series.

Ansible provides a handy index to all their modules. Due to the large number provided, the documentation has separated them into specific categories to help you search through for the specific ones you need. The full index of modules can be located at the following location:
http://docs.ansible.com/ansible/latest/modules_by_category.html

In our earlier post we got through the basics of installing and configuring Ansible. So now let’s have a look at some more modules and run them from the command line.

For more information and projects on using Ansible in your day to day projects, check out the new book, Practical Ansible

Ping

One of the first modules a lot of people will learn is the ping module. As it suggests, the module performs a ping test on the specified host requesting a reply if the host is accessible and powered on:

Setup

The setup module provides us with over six hundred lines of information out our system. All of which presented in a friendly to view JSON format, with all values being preceded with “ansible_” as you can see from the cut down output provided below.

Git

The git module allows you to perform git commands via Ansible. If you need to deploy software directly from a git repository, this would be the perfect reason to use this module:

In the above example, we have called the git module with the -m option and used the -a option to provide all the relevant arguments for it to successfully complete. In this case, we have specified the repository with repo and then provided a destination folder. If the folder is not present, Ansible will create it, so we should see the file downloaded and available in our destination folder.

Shell

We have used the shell module previously, but we can now use it to verify our previous command worked by performing a listing of the files in the ~/test/ directory

All of this should be looking very familiar by now as we are simply specifying the arguments of a directory listing with the -a option.

Apt(or Yum)

A majority of modules will be able to be run across different versions of Linux, but one which may differ is the package manager which is being used on the system. The command below uses apt as the module, but of course for Red Hat or Centos, you would use the yum module with the name being equal to httpd.

We have removed quite a few lines of output above to help with our explanation. The new options you will notice is the — become -K options, which ensures Ansible becomes a user which can install programs on this system, such as the root user, and it then requests a password for allow the install to continue. You will then see the arguments then provided as name of the application we want to install and the state, which in this case is present. If we wanted to remove the application, we would use the same command but change the state to absent.

Get_url

We can now test the above command with the get_url module which grabs content from HTTP, HTTPS or other internet protocols. As we should have a working Apache server running, we can now download the default page running at localhost.

Once again, we need to specify the destination as part of the arguments, as the module needs somewhere to place the content it downloads.

User

Setting up users is a snap with this module. We can control the state of the account on the system as being absent or present to determine if they are created or removed.

Our output from the Ansible command give us clear details of the account created. Even though the user would not be accessible as it does not have a password set. We could also add the password as an argument to set this upon creation.

Found this post useful? Kindly tap the clap button below! :)

About The Author

Vince has worked with Splunk for over 5 years, developing apps and reporting applications around Splunk, and now works hard to advocate its success. He has worked as a system engineer in big data companies and development departments, where he has regularly supported, built, and developed with Splunk. He has now published his first book via Packt Publishing — Learning Splunk Web Framework.

--

--

Vince Sesto
Splunk User Developer Administrator

Vincent Sesto is a DevOps Engineer, Endurance Athlete, Coach and Author. One of his passion’s in life is endurance sports as both an athlete, coach and author.