mjhjmtu

I have an Ansible playbook for establishing LAMP environments on remote machines.

Part of this playbook deals with installing Composer:

- name: Install Composer
 get_url:
 url: https://getcomposer.org/installer
 dest: /tmp/composer-setup.php
 command: php /tmp/composer-setup.php --install-dir=/usr/local/bin --filename=composer

My consideration

Instead these 5-lines structure I was thinking of using this ansible-galaxy command inside the playbook:

ansible-galaxy install geerlingguy.composer

geerlingguy.composer is the most communally supported AG role with more than million users (so I assume that if there is a problem and Jeff isn't around at the moment - say, took vacation in Hawaii or something, there will be many community members to fix the problem and ensure stability.

Using this will also shorten my already quite-long playbook.

My question

In general, is it a best practice to use Ansible-Galaxy roles with tasks and tests in an Ansible playbook instead a set of ansible-modules in playbooks that should apparently achieve the same goal (maybe some redundant extras that might not matter and wouldn't interrupt being there as part of the AG role)? I would assume that yes, because it's more communal and stabler.

Whether to use a Galaxy-provided role is a decision you need to evaluate in your specific context (for every role you’re considering).

Good roles on Galaxy will often handle many more situations than your specific role (look at the contents of tasks here, compared to your playbook), but those capabilities come at a cost: you’re adding an external dependency to your system, and relying on a community to handle your requirements.

You need to look at the cost of evaluating a Galaxy role compared to developing a playbook (or your own Galaxy role); both now, and in the future. There’s no hard-and-fast rule.