Ansible Galaxy (https://galaxy.ansible.com/) is a community hub for finding and sharing Ansible roles. Anybody can visit the website to browse the roles and reviews; plus, users who create a login can provide reviews of the roles they've tested. Roles from Galaxy can be downloaded using the ansible-galaxy utility provided with Ansible.

The ansible-galaxy utility can connect to and install roles from the Ansible Galaxy website. This utility will default to installing roles into /etc/ansible/roles. If roles_path is configured, or if a runtime path is provided with the --roles-path (or -p) option, the roles will be installed there instead. If any roles have been installed to the roles_path or the provided path, ansible-galaxy can list those and show information about those as well. To demonstrate the usage of ansible-galaxy, let's use it to install a role for installing and managing Docker on Ubuntu from Ansible Galaxy into the roles directory we've been working with. Installing roles from Ansible Galaxy requires username.rolename, as multiple users may have uploaded roles with the same name. In this case, we want the docker_ubuntu role from the user angstwad:

Now we can make use of this role by referencing angstwad.docker_ubuntu in a play or another role's dependencies block. We can also list it and gain information about it using the ansible-galaxy utility:

The output was capped at 25 lines, to avoid displaying the entire information set and README.md contents. Some of the data being displayed by the info command lives within the role itself, in the meta/main.yaml file. Previously, we've only seen dependency information in this file, and it may not have made much sense to name the directory meta, but now we see that other metadata lives in this file as well:

The ansible-galaxy utility can also help with the creation of new roles. The init method will create a skeleton directory tree for the role, as well as populate the meta/main.yaml file with placeholders for Galaxy-related data. The init method takes a variety of options, as shown in the help output:

Let's demonstrate this capability by creating a new role in our working directory named autogen:

Note that where we have used the -p switch in the past for specifying the local roles/ directory, we have to use the --init-path switch instead with the init command. For roles that are not suitable for Ansible Galaxy, such as roles dealing with in-house systems, ansible-galaxy can install directly from a Git URL. Instead of just providing a role name to the install method, a full Git URL with an optional version can be provided instead. For example, if we wanted to install the foowhiz role from our internal Git server, we could simply do the following:

Without version information, the master branch will be used. Without name data, the name will be determined from the URL itself. To provide a version, append a comma and the version string that Git can understand, such as a tag or branch name, such as v1:

A name for the role can be added with another comma followed by the name string. If you need to supply a name but do not wish to supply a version, an empty slot is still required for the version:

Roles can also be installed directly from tarballs as well, by providing a URL to the tarball in lieu of a full Git URL or a role name to fetch from Ansible Galaxy.

When you need to install many roles for a project, it's possible to define multiple roles to download and install in a YAML-formatted file that ends with .yaml (or .yml). The format of this file allows you to specify multiple roles from multiple sources and retain the ability to specify versions and role names. In addition, the source control method can be listed (currently, only git and hg are supported):

--- 
- src: <name or url> 
  version: <optional version> 
  name: <optional name override> 
  scm: <optional defined source control mechanism>

To install all the roles within a file, use the --roles-file (-r) option with the install method:

In this manner, it is very easy to gather all your role dependencies prior to running your playbooks, and whether the roles you need are publicly available on Ansible Galaxy or held in your own internal source-control management system, this simple step can greatly speed along playbook deployment while supporting code reuse.