Ansible Modules¶

Introduction¶

Ansible ships with a number of modules (called the ‘module library’) that can be executed directly on remote hosts or through Playbooks. Users can also write their own modules. These modules can control system resources, like services, packages, or files (anything really), or handle executing system commands.

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

ansible webservers -m service -a "name=httpd state=running"
ansible webservers -m ping
ansible webservers -m command -a "/sbin/reboot -t now"

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

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

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

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 about that. 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 are idempotent, meaning they will seek to avoid changes to the system unless a change needs to be made. When using Ansible playbooks, these modules can trigger ‘change events’ in the form of notifying ‘handlers’ to run additional tasks.

Let’s see what’s available in the Ansible module library, out of the box:

apt_repository¶

New in version 0.7.

Manages apt repositores

Example action from Ansible Playbooks:

apt_repository repo=ppa:nginx/stable
apt_repository repo='deb http://archive.canonical.com/ubuntu hardy partner'

apt¶

Manages apt-packages (such as for Debian/Ubuntu).

Example action from Ansible Playbooks:

apt pkg=foo update-cache=yes
apt pkg=foo state=removed
apt pkg=foo state=installed
apt pkg=foo=1.00 state=installed
apt pkg=nginx state=latest default-release=squeeze-backports update-cache=yes
apt pkg=openjdk-6-jdk state=latest install-recommends=no

assemble¶

New in version 0.5.

Assembles a configuration file from fragments. Often a particular program will take a single configuration file and does not support a conf.d style structure where it is easy to build up the configuration from multiple sources. Assemble will take a directory of files that have already been transferred to the system, and concatenate them together to produce a destination file. Files are assembled in string sorting order. Puppet calls this idea “fragments”.

Example action from Ansible Playbooks:

assemble src=/etc/someapp/fragments dest=/etc/someapp/someapp.conf

authorized_key¶

New in version 0.5.

Adds or removes an authorized key for a user from a remote host.

Example action from Ansible Playbooks:

authorized_key user=charlie key="ssh-dss ASDF1234L+8BTwaRYr/rycsBF1D8e5pTxEsXHQs4iq+mZdyWqlW++L6pMiam1A8yweP+rKtgjK2httVS6GigVsuWWfOd7/sdWippefq74nppVUELHPKkaIOjJNN1zUHFoL/YMwAAAEBALnAsQN10TNGsRDe5arBsW8cTOjqLyYBcIqgPYTZW8zENErFxt7ij3fW3Jh/sCpnmy8rkS7FyK8ULX0PEy/2yDx8/5rXgMIICbRH/XaBy9Ud5bRBFVkEDu/r+rXP33wFPHjWjwvHAtfci1NRBAudQI/98DbcGQw5HmE89CjgZRo5ktkC5yu/8agEPocVjdHyZr7PaHfxZGUDGKtGRL2QzRYukCmWo1cZbMBHcI5FzImvTHS9/8B3SATjXMPgbfBuEeBwuBK5EjL+CtHY5bWs9kmYjmeo0KfUMH8hY4MAXDoKhQ7DhBPIrcjS5jPtoGxIREZjba67r6/P2XKXaCZH6Fc= charlie@example.org 2011-01-17"

command¶

The command module takes the command name followed by a list of arguments, space delimited.

The given command will be executed on all selected nodes. It will not be processed through the shell, so variables like “$HOME” and operations like “<”, “>”, “|”, and “&” will not work. As such, all paths to commands must be fully qualified.

Example action from Ansible Playbooks:

command /sbin/shutdown -t now

creates and chdir can be specified after the command. For instance, if you only want to run a command if a certain file does not exist, you can do the following:

command /usr/bin/make_database.sh arg1 arg2 creates=/path/to/database

The creates= and chdir options will not be passed to the actual executable.

copy¶

The copy module moves a file on the local box to remote locations. In addition to the options listed below, the arguments available to the file module can also be passed to the copy module.

Example action from Ansible Playbooks:

copy src=/srv/myfiles/foo.conf dest=/etc/foo.conf owner=foo group=foo mode=0644

Copy a new ntp.conf file into place, backing up the original if it differs from the copied version:

copy src=/srv/myfiles/ntp.conf dest=/etc/ntp.conf owner=root group=root mode=644 backup=yes

easy_install¶

New in version 0.7.

The easy_install module installs Python libraries.

Please note that the easy_install command can only install Python libraries. Thus this module is not able to remove libraries. It is generally recommended to use the pip module which you can first install using easy_install.

Also note that virtualenv must be installed on the remote host if the virtualenv parameter is specified.

Example action from Ansible Playbooks:

easy_install name=pip
easy_install name=flask==0.8
easy_install name=flask virtualenv=/srv/webapps/my_app/venv

facter¶

Runs the discovery program ‘facter’ on the remote system, returning JSON data that can be useful for inventory purposes.

Requires that ‘facter’ and ‘ruby-json’ be installed on the remote end.

Playbooks do not actually use this module, they use the setup module behind the scenes.

Example from /usr/bin/ansible:

ansible foo.example.org -m facter

fetch¶

This module works like ‘copy’, but in reverse. It is used for fetching files from remote machines and storing them locally in a file tree, organized by hostname.

Example:

fetch src=/var/log/messages dest=/home/logtree

file¶

New in version 0.1.

Sets attributes of files, symlinks, and directories, or removes files/symlinks/directories. Many other modules support the same options as the file module - including copy, template, and assmeble.

Example from Ansible Playbooks

file path=/etc/foo.conf owner=foo group=foo mode=0644

get_url¶

New in version 0.6.

Downloads files from HTTP, HTTPS, or FTP to the remote server. The remote server must have direct access to the remote resource.

Example from Ansible Playbooks

get_url url=http://example.com/path/file.conf dest=/etc/foo.conf mode=0440

git¶

Deploys software (or files) from git checkouts.

Example action from Ansible Playbooks:

git repo=git://foosball.example.org/path/to/repo.git dest=/srv/checkout version=release-0.22

group¶

Adds or removes groups.

To control members of the group, see the users resource.

Example action from Ansible Playbooks:

group name=somegroup state=present

ini_file¶

New in version 0.9.

Manage (add, remove, change) individual settings in an INI-style file without having to manage the file as a whole with, say, template or assemble. Adds missing sections if they don’t exist.

lineinfile¶

New in version 0.7.

This module will search a file for a line, and ensure that it is present or absent. This is primarily useful when you want to change a single line in a file only. For other cases, see the copy or template modules.

lineinfile name=/etc/selinux/config regexp=^SELINUX= line=SELINUX=disabled

lineinfile name=/etc/sudoers state=absent regexp="^%wheel"

mount¶

New in version 0.6.

The mount module controls active and configured mount points (fstab).

mysql_db¶

New in version 0.6.

Add or remove MySQL databases from a remote host.

Requires the MySQLdb Python package on the remote host. For Ubuntu, this is as easy as apt-get install python-mysqldb.

Both ‘login_password’ and ‘login_username’ are required when you are passing credentials. If none are present, the module will attempt to read the credentials from ~/.my.cnf, and finally fall back to using the MySQL default login of ‘root’ with no password.

Example action from Ansible Playbooks:

- name: Create database
  action: mysql_db db=bobdata state=present

mysql_user¶

New in version 0.6.

Adds or removes a user from a MySQL database.

Requires the MySQLdb Python package on the remote host. For Ubuntu, this is as easy as apt-get install python-mysqldb.

Both ‘login_password’ and ‘login_username’ are required when you are passing credentials. If none are present, the module will attempt to read the credentials from ~/.my.cnf, and finally fall back to using the MySQL default login of ‘root’ with no password.

Example privileges string format:

mydb.*:INSERT,UPDATE/anotherdb.*:SELECT/yetanotherdb.*:ALL

Example action from Ansible Playbooks:

- name: Create database user
  action: mysql_user name=bob password=12345 priv=*.*:ALL state=present

- name: Ensure no user named 'sally' exists, also passing in the auth credentials.
  action: mysql_user login_user=root login_password=123456 name=sally state=absent

nagios¶

New in version 0.7.

Perform common tasks in Nagios related to downtime and notifications.

The Nagios module has two basic functions: scheduling downtime and toggling alerts for services or hosts.

The following parameters are common to all actions in the nagios module:

The following parameters may be used with the downtime action:

The following parameter must be used with the enable_alerts and disable_alerts actions:

All actions require the host parameter to be given explicitly. In playbooks you can use the $inventory_hostname variable to refer to the host the playbook is currently running on.

You can specify multiple services at once by separating them with commas, .e.g., services=httpd,nfs,puppet.

When specifying what service to handle there is a special service value, host, which will handle alerts/downtime for the host itself, e.g., service=host. This keyword may not be given with other services at the same time. Handling alerts/downtime for a host does not affect alerts/downtime for any of the services running on it.

Examples from Playbooks:

---
- hosts: webservers
  user: root
  tasks:
    - name: set 30 minutes of apache downtime
      action: nagios action=downtime minutes=30 service=httpd host=$inventory_hostname
      delegate_to: nagios.example.com

    - name: schedule an hour of HOST downtime
      action: nagios action=downtime minutes=60 service=host host=$inventory_hostname
      delegate_to: nagios.example.com

    # Use the default of 30 minutes
    # Schedule downtime for three services at once
    - name: schedule downtime for a few services
      action: nagios action=downtime services=frob,foobar,qeuz host=$inventory_hostname
      delegate_to: nagios.example.com

    - name: enable SMART disk alerts
      action: nagios action=enable_alerts service=smart host=$inventory_hostname
      delegate_to: nagios.example.com

    # you can disable multiple at once
    - name: disable httpd alerts
      action: nagios action=disable_alerts service=httpd,nfs host=$inventory_hostname
      delegate_to: nagios.example.com

    # host alerts must be disabled as a seperate action
    - name: disable HOST alerts
      action: nagios action=disable_alerts service=host host=$inventory_hostname
      delegate_to: nagios.example.com

    - name: silence ALL alerts
      action: nagios action=silence host=$inventory_hostname
      delegate_to: nagios.example.com

    - name: unsilence all alerts
      action: nagios action=unsilence host=$inventory_hostname
      delegate_to: nagios.example.com

Troubleshooting Tips

The nagios module may not operate for you out of the box. The most likely problem is with your cmdfile permissions/paths. You will receive this error if that is the case:

{"msg": "unable to write to nagios command file", "failed": true, "cmdfile": "/var/spool/nagios/cmd/nagios.cmd"}

Steps to correct this:

1. Ensure you are running the nagios module as a user who has write permissions to the cmdfile.
2. Ensure you have cmdfile set correctly.

ohai¶

Similar to the facter module, this returns JSON inventory data. Ohai data is a bit more verbose and nested than facter.

Requires that ‘ohai’ be installed on the remote end.

Playbooks should not call the ohai module, playbooks call the setup module behind the scenes instead.

Example:

ansible foo.example.org -m ohai

ping¶

A trivial test module, this module always returns ‘pong’ on successful contact. It does not make sense in playbooks, but is useful from /usr/bin/ansible:

ansible webservers -m ping

pip¶

New in version 0.7.

Manages Python library dependencies.

Please note that virtualenv must be installed on the remote host if the virtualenv parameter is specified.

Examples:

pip name=flask
pip name=flask version=0.8
pip name=flask virtualenv=/srv/webapps/my_app/venv
pip requirements=/srv/webapps/my_app/src/requirements.txt
pip requirements=/srv/webapps/my_app/src/requirements.txt virtualenv=/srv/webapps/my_app/venv

postgresql_db¶

New in version 0.6.

Add or remove PostgreSQL databases from a remote host.

The default authentication assumes that you are either logging in as or sudo’ing to the postgres account on the host.

This module uses psycopg2, a Python PostgreSQL database adapter. You must ensure that psycopg2 is installed on the host before using this module. If the remote host is the PostgreSQL server (which is the default case), then PostgreSQL must also be installed on the remote host. For Ubuntu-based systems, install the postgresql, libpq-dev, and python-psycopg2 packages on the remote host before using this module.

Example action from Ansible Playbooks:

postgresql_db db=acme

postgresql_user¶

New in version 0.6.

Add or remove PostgreSQL users (roles) from a remote host and, optionally, grant the users access to an existing database or tables.

The default authentication assumes that you are either logging in as or sudo’ing to the postgres account on the host.

This module uses psycopg2, a Python PostgreSQL database adapter. You must ensure that psycopg2 is installed on the host before using this module. If the remote host is the PostgreSQL server (which is the default case), then PostgreSQL must also be installed on the remote host. For Ubuntu-based systems, install the postgresql, libpq-dev, and python-psycopg2 packages on the remote host before using this module.

The fundamental function of the module is to create, or delete, roles from a PostgreSQL cluster. Privilege assignment, or removal, is an optional step, which works on one database at a time. This allows for the module to be called several times in the same module to modify the permissions on different databases, or to grant permissions to already existing users.

A user cannot be removed untill all the privileges have been stripped from the user. In such situation, if the module tries to remove the user it will fail. To avoid this from happening the fail_on_user option signals the module to try to remove the user, but if not possible keep going; the module will report if changes happened and separately if the user was removed or not.

Example privileges string format:

INSERT,UPDATE/table:SELECT/anothertable:ALL

Example action from Ansible Playbooks:

- name: Create django user and grant access to database and products table
  postgresql_user db=acme user=django password=ceec4eif7ya priv=CONNECT/products:ALL

- name: Remove test user privileges from acme
  postgresql_user db=acme user=test priv=ALL/products:ALL state=absent fail_on_user=no
- name: Remove test user from test database and the cluster
  postgresql_user db=test user=test priv=ALL state=absent

raw¶

Executes a low-down and dirty SSH command, not going through the module subsystem. This is useful and should only be done in two cases. The first case is installing python-simplejson on older (Python 2.4 and before) hosts that need it as a dependency to run modules, since nearly all core modules require it. Another is speaking to any devices such as routers that do not have any Python installed. In any other case, using the shell or command module is much more appropriate. Arguments given to raw are run directly through the configured remote shell and only output is returned. There is no error detection or change handler support for this module

Example from /usr/bin/ansible to bootstrap a legacy python 2.4 host

ansible newhost.example.com -m raw -a "yum -y install python-simplejson"

service¶

Controls services on remote machines.

Example actions from Ansible Playbooks:

service name=httpd state=started
service name=httpd state=stopped
service name=httpd state=restarted
service name=httpd state=reloaded
service name=foo pattern=/usr/bin/foo state=started

seboolean¶

New in version 0.7.

Toggles SELinux booleans.

Example from Ansible Playbooks:

seboolean name=httpd_can_network_connect state=true persistent=yes

selinux¶

New in version 0.7.

Configures the SELinux mode and policy. A reboot may be required after usage. Ansible will not issue this reboot but will let you know when it is required.

Example from Ansible Playbooks:

selinux policy=targeted state=enforcing
selinux policy=targeted state=disabled

setup¶

This module is automatically called by playbooks to gather useful variables about remote hosts that can be used in playbooks. It can also be executed directly by /usr/bin/ansible to check what variables are available to a host. Ansible provides many facts about the system, automatically.

Obtain facts from all hosts and store them indexed by hostname at /tmp/facts.

ansible all -m setup -tree /tmp/facts

shell¶

The shell module takes the command name followed by a list of arguments, space delimited. It is almost exactly like the command module but runs the command through the user’s configured shell on the remote node.

The given command will be executed on all selected nodes.

Example action from a playbook:

shell somescript.sh >> somelog.txt

subversion¶

New in version 0.7.

Deploys a subversion repository.

Example action from Ansible Playbooks:

subversion repo=svn+ssh://an.example.org/path/to/repo dest=/src/checkout

supervisorctl¶

New in version 0.7.

Manage the state of a program or group of programs running via Supervisord

Example action from a playbook:

supervisorctl name=my_app state=started

template¶

Templates a file out to a remote server.

Templates are processed by the Jinja2 templating language - documentation on the template formatting can be found in the Template Designer Documentation

Example action from a playbook:

template src=/srv/mytemplates/foo.j2 dest=/etc/foo.conf owner=foo group=foo mode=0644

user¶

Creates user accounts, manipulates existing user accounts, and removes user accounts.

Example action from Ansible Playbooks:

user name=mdehaan comment=awesome password=awWxVV.JvmdHw createhome=yes
user name=mdehaan groups=wheel,skynet
user name=mdehaan state=absent force=yes

wait_for¶

New in version 0.7.

Waits for a given port to become accessible (or inaccessible) on a local or remote server.

This is useful for when services are not immediately available after their init scripts return – which is true of certain Java application servers. It is also useful when starting guests with the virt module and needing to pause until they are ready.

Example from Ansible Playbooks:

wait_for port=8080 delay=10

virt¶

Manages virtual machines supported by libvirt. Requires that libvirt be installed on the managed machine.

Example action from Ansible Playbooks:

virt guest=alpha state=running
virt guest=alpha state=shutdown
virt guest=alpha state=destroyed
virt guest=alpha state=undefined

Example guest management commands from /usr/bin/ansible:

ansible host -m virt -a "guest=foo command=status"
ansible host -m virt -a "guest=foo command=pause"
ansible host -m virt -a "guest=foo command=unpause"
ansible host -m virt -a "guest=foo command=get_xml"
ansible host -m virt -a "guest=foo command=autostart"

Example host (hypervisor) management commands from /usr/bin/ansible:

ansible host -m virt -a "command=freemem"
ansible host -m virt -a "command=list_vms"
ansible host -m virt -a "command=info"
ansible host -m virt -a "command=nodeinfo"
ansible host -m virt -a "command=virttype"

yum¶

Will install, upgrade, remove, and list packages with the yum package manager.

Example action from Ansible Playbooks:

yum name=httpd state=latest
yum name=httpd state=removed
yum name=httpd state=installed

Additional Contrib Modules¶

In addition to the following built-in modules, community modules are available at Ansible Resources.

Writing your own modules¶

See Module Development.