Ansible Galaxy roles install in to a specific directory?

Question

So I figured I should start using Ansible Galaxy when possible, instead of writing my own roles. I just installed my first role and it was installed to /etc/local/ansible/roles (I am on OSX).

Now I wonder how you install this roles where I actually need it? Do I just copy the role to where I need it or is there an Ansible way of doing it?

Solution 1

Yes, you would copy them according to a sample project structure:

site.yml
webservers.yml
fooservers.yml
kubernetes.yaml
roles/
   common/
     files/
     templates/
     tasks/
     handlers/
     vars/
     meta/
   webservers/
     files/
     templates/
     tasks/
     handlers/
     vars/
     meta/
   kubernetes/
     files/
     templates/
     tasks/
     handlers/
     vars/
     meta/

or you can just run ansible-galaxy with the -p ROLES_PATH or --roles-path=ROLES_PATH option to install it under /your/project/root

You can also use the /etc/local/ansible directory as your project root if you'd like to.

Additionally, you can get help by running the command ansible-galaxy install --help

Solution 2

In general, I stick all my shared roles in a single master folder that gets shared across all my projects. This avoids the tediousness of manual copy/pasting and updating multiple copies of the same role.

Than I modify each project's ansible.cfg to tell ansible to look for roles in that master folder in addition to the local project folder.

Sample ansible.cfg:

[defaults]
roles_path = ~/Code/ansible_roles 

Ansible first searches the local project for a role, then searches the roles_path. You can specify multiple paths by separating them with colons.

By default, ansible-galaxy install username.rolename will install the role to the roles_path configured in ansible.cfg, so that's pretty much all you need to do.

Occasionally I want to install the role into the specific project and not the master folder. For example, to avoid version conflicts when two roles have role dependencies that require different versions of the same role. In that case, you can use the -p ROLES_PATH or --roles-path=ROLES_PATH option:

ansible-galaxy install username.rolename -p ~/Code/project_deploy/ansible/roles/

In Ansible 1.9, you can manually specify where you want a role to be installed in your project's requirements.yml. Unfortunately, this path param was removed in Ansible 2:

# from galaxy
- src: jeffwidman.elasticsearch

# from private github repo, installing to a relative path
- src: https://github.com/jeffwidman/private_ansible_role
  path: vagrant/roles/

If you want to customize things further, there's an open issue to add support for multiple ansible.cfg files which would let you easily set roles_path at varying levels of specificity. Ansible will read ANSIBLE_CONFIG, ansible.cfg in the current working directory, .ansible.cfg in the home directory or /etc/ansible/ansible.cfg, whichever it finds first.

Solution 3

Here is how I solved the problem of dealing with galaxy roles and works for any platform.

Edit your ansible.cfg file, which should be part of your source control and add this to it:

roles_path = roles.galaxy:roles

Create a directory named roles.galaxy and from now on, when you do ansible-galaxy install xxx.yyy, it will install into roles.galaxy.

You will continue to keep your local roles inside the roles directory and the community ones in roles.galaxy. Both of them are supposed to be kept in your git repo.

Don't ever consider installing them on from galaxy, this would be a big security risk in addition to adding several additional points of failure.

Solution 4

I am probably answering this question too late. But what you want can be done with a single command:

ansible-galaxy install -p ./roles thefinn93.letsencrypt

will install the letsencrypt role to the roles directory and you don't need to copy things around.

Solution 5

To have your roles saved within your repository folder (which is what you likely want, having all your stuff version-controlled is one of the infrastructure-as-code), and assuming this is your directory layout:

repo-folder
    inventory     << likely you have this already
    roles         << this, too
    roles.galaxy  << create if you dont have it
    site.yml      << or whatever your playbook is called
    ansible.cfg   << repo-local config overriding gloabal ~/.ansible.cfg

Open the above shown ansible.cfg (or create it anew if you do not already have one), and add this content:

[defaults]
roles_path = roles.galaxy:roles

Running ansible-galaxy install SOMETHING will then save its contents within the roles.galaxy folder.

View more solutions

Comments

[StenW]

Awesome @Rico! I thought there would be such a command, but its tricky to find any proper documentation on Galaxy at this point.

[geerlingguy]

The ansible-galaxy help is slightly obtuse as well, but run ansible-galaxy [command] --help to get command-specific help (in this case, install command).

[thom_nic]

I prefer using tools like virtualenv and nvm which keep every project's dependencies sandboxed. I just tried roles_path = .galaxy in my project's ansible.cfg and galaxy happily installed dependencies there! It even created the folder. Seems like a great way to manage galaxy dependencies.

[Jeff Widman]

The downside of that approach is that if you are reusing the same role across separate projects, then when you do a bugfix in the role, you'll need to remember to fix all copies. Most bugfixes in the generic roles that I use are due to linux changes, etc so they aren't local to a single project.

[Kevin London]

Could you further explain the security risk and additional points of failure? How would it differ from running pip install -r requirements.txt if the version is properly pinned?

[aerickson]

I think @KevinLondon is saying that you shouldn't continually install from Galaxy or other package providers, you should 'vendor' the code (commit your code to your repository).

[Greg Bell]

Yuck, really? I don't do that for npm or composer. Or does the lock file reduce the security risk?

[David Pärsson]

Is galaxy.roles and roles.galaxy the same (but misspelled), or should they differ?

[Everspace]

@GregBell You should pin dependencies so that you aren't surprised or put into trouble when a new version releases and breaks something, or when multiple people are using different versions. I'm not sure there's any supported lockfile stuff, so vendoring is proabably what ends up making the most sense. It's pretty easy to upgrade however so I wouldn't personally mind doing that.

[Henry Yang]

If I run the install with --roles-path=relative/folder/from/my/project, does that means the role will be installed in the folder relative/folder/from/my/project?

[Tony Cesaro]

This was the most useful answer for me. It's especially useful in automation pipelines that pull down roles/collections on demand and you can then place them in a path that's not part of the version control repository.