20250514154644-Running_Ansible_Playbooks

Running Ansible Playbooks

From bib. source

To run the Ansible Playbook (in this case, a file named playbook.yml […]), you would call it using the ansible-playbook command:

# (From the same directory in which the playbook resides).
ansible-playbook playbook.yml

This ansible-playbook command is used to play Ansible playbook files, and it can “limit the hosts on which the playbook is run” regardless of the playbook file itself having already specified hosts (Geerling 2023, 53). This is done using the limit option of the command, exemplified like so (Ibid):

ansible-playbook playbook.yml --limit webservers

Or, revised to be more general:

ansible-playbook $PLAYBOOK_FILENAME --limit $HOSTNAMES

Insofar as HOSTNAME is to be a hostname / public IP address / FQDN, a list of hostnames / public IP addresses / FQDNs, the name of a group under which hostnames / public IP addresses / FQDNs exist.

Clearly, it is apparent that ansible-playbook can introduce option arguments that override field values in the playbook to be played by it (Ibid).

One can also list the hosts on which the playbook will be played by the ansible-playbook command (Ibid):

ansible-playbook playbook.yml --list-hosts

Alternatively:

ansible-playbook $PLAYBOOK_FILENAME --list-hosts

Another thing that ansible-playbook can override for a playbook which it will play is the user its tasks will be run as on the given host(s), using the user option (Geerling 2023, 54). Otherwise (Ibid):

From bib. source

If no remote_user is defined alongside the hosts in a playbook, Ansible assumes you’ll connect as the user defined in your inventory file for a particular host, and then will fall back to your local user account name.

Further (Ibid):

From bib. source

In some situations, you will need to pass along your sudo password to the remote server to perform commands via sudo. In these situations, you’ll need use the --ask-become-pass (-K) option. You can also explicitly force all tasks in a playbook to use sudo with --become (-b). Finally, you can define the sudo user for tasks run via sudo (the default is root) with the --become-user option.

That is (Geerling 2023, 54):

• The ask-become-pass (K) option will allow for running things with sudo once the playbook is playing its tasks on the target server(s) if sudo requires a password.
• The become-user option allows one to use a user other than root (the default for sudo) for sudo on the target server.
• The become (b) option will make all tasks use sudo.

For example (Ibid):

ansible-playbook playbook.yml --become --become-user=janedoe --ask-become-pass

This command above would play the tasks in playbook.yml on the hosts specified in it, with sudo, and perform these tasks as the sudo user janedoe whilst prompting for the that user’s sudo password (Ibid).

Finally, variables used in the playbook whose tasks ansible-playbook will play can have their values specified by that ansible-playbook command, using the option extra-vars, which takes in a comma-separated list of key-value pairs conjoined by equal signs as a value: --extra-vars="key1=value1,key2=value2" (Ibid).

host commands options command_line command_lines command_line_interface command_line_interfaces fully_qualified_domain_name fully_qualified_domain_names domain_name domain_names Internet_Protocol Internet_Protocol_address superuser superuser_do argument task configuration_management ad-hoc_command ad-hoc_commands

---

bibliography

• “Ansible Playbooks.” In Ansible for DevOps: Server and Configuration Management for Humans, 2nd ed., 47-83. Leanpub, 2023.