Introduction

Modules (also referred to as “task plugins” or “library plugins”) are discrete units of code that can be used from the command line or in a playbook task.

Let’s review how we execute three different modules from the command line:

  1. ansible webservers -m service -a "name=httpd state=started"
  2. ansible webservers -m ping
  3. ansible webservers -m command -a "/sbin/reboot -t now"

Each module supports taking arguments. Nearly all modules take key=valuearguments, space delimited. Some modules take no arguments, and the command/shell modules simplytake the string of the command you want to run.

From playbooks, Ansible modules are executed in a very similar way:

  1. - name: reboot the servers
  2.   action: command /sbin/reboot -t now

Which can be abbreviated to:

  1. - name: reboot the servers
  2.   command: /sbin/reboot -t now

Another way to pass arguments to a module is using yaml syntax also called ‘complex args’

  1. - name: restart webserver
  2.   service:
  3.     name: httpd
  4.     state: restarted

All modules technically return JSON format data, though if you are using the command line or playbooks, you don’t really need to know much aboutthat. If you’re writing your own module, you care, and this means you do not have to write modules in any particular language – you get to choose.

Modules should be idempotent, and should avoid making any changes ifthey detect that the current state matches the desired final state. When usingAnsible playbooks, these modules can trigger ‘change events’ in the form ofnotifying ‘handlers’ to run additional tasks.

Documentation for each module can be accessed from the command line with the ansible-doc tool:

  1. ansible-doc yum

For a list of all available modules, see Module Index, or run the following at a command prompt:

  1. ansible-doc -l

See also