You are currently viewing Ansible Playbook Advance Features

Ansible Playbook Advance Features

Ansible Playbook Advance Features

Hello Everyone

Welcome to CloudAffaire and this is Debjeet.

In the last blog post, we have discussed roles in Ansible.

https://cloudaffaire.com/roles-in-ansible/

In this blog post, we will discuss some advance features of Ansible Playbook.

Ansible Playbook Advance Features:

Privilege Escalation in playbook:

Ansible allows you to ‘become’ another user, different from the user that logged into the machine (remote user). This is done using existing privilege escalation tools such as sudo, su, pfexec, doas, pbrun, dzdo, ksu, runas, machinectl and others.

Privilege can be escalated in three ways:

  • Using command-line options
  • Using become directives
  • Using connection variables

Using command-line options: You can directly escalate privilage using command line options.

  • –ask-become-pass, -K: ask for privilege escalation password; does not imply become will be used.
  • –become, -b: run operations with become (no password implied)
  • –become-method=BECOME_METHOD: privilege escalation method to use (default=sudo), valid choices: [ sudo | su | pbrun | pfexec | doas | dzdo | ksu | runas | machinectl ]
  • –become-user=BECOME_USER: run operations as this user (default=root), does not imply –become/-b

Note: become directive will let you execute using root privilege.

Using become directives: You can also escalate privilege using become directive in your playbook.

  • become: set to yes to activate privilege escalation.
  • become_user: set to user with desired privileges — the user you become, NOT the user you login as. Does NOT imply become: yes, to allow it to be set at host level.
  • become_method: (at play or task level) overrides the default method set in ansible.cfg, set to use any of the Become Plugins.
  • become_flags: (at play or task level) permit the use of specific flags for the tasks or role.

Using connection variables: You can also escalate privilege using connection variables (host\group variables) in your inventory file.

  • ansible_become: equivalent of the become directive, decides if privilege escalation is used or not.
  • ansible_become_method: which privilege escalation method should be used
  • ansible_become_user: set the user you become through privilege escalation; does not imply ansible_become: yes
  • ansible_become_password: set the privilege escalation password.

Asynchronous Actions and Polling in playbook:

By default tasks in playbooks block, meaning the connections stay open until the task is done on each node. This may not always be desirable, or you may be running operations that take longer than the SSH timeout. To avoid blocking or timeout issues, you can use asynchronous mode to run all of your tasks at once and then poll until they are done. The behavior of asynchronous mode depends on the value of poll.

Avoid connection timeouts: poll > 0

When poll is a positive value, the playbook will still block on the task until it either completes, fails or times out. In this case, however, async explicitly sets the timeout you wish to apply to this task rather than being limited by the connection method timeout.

Concurrent tasks: poll = 0

When poll is 0, Ansible will start the task and immediately move on to the next one without waiting for a result. From the point of view of sequencing this is asynchronous programming: tasks may now run concurrently. The playbook run will end without checking back on async tasks. The async tasks will run until they either complete, fail or timeout according to their async value. If you need a synchronization point with a task, register it to obtain its job ID and use the async_status module to observe it.

Observe: In the second play, Task2 does not wait for Task 1 completion. If you get any error, increase the retries value.

Dryrun (Checks) in playbook:

When ansible-playbook is executed with –check it will not make any changes on remote systems. Instead, any module instrumented to support ‘check mode’ will report what changes they would have made rather than making them. Other modules that do not support check mode will also take no action, but just will not report what changes they might have made. Check mode is just a simulation, and if you have steps that use conditionals that depend on the results of prior commands, it may be less useful for you. However, it is great for one-node-at-time basic configuration management use cases.

The –diff option to ansible-playbook works great with –check (detailed above) but can also be used by itself. When this flag is supplied and the module supports this, Ansible will report back the changes made or, if used with –check, the changes that would have been made. This is mostly used in modules that manipulate files (i.e. template) but other modules might also show ‘before and after’ information (i.e. user). Since the diff feature produces a large amount of output, it is best used when checking a single host at a time.

Note: The file will not actually get copied, just a check is performed and changes are reported if the file would have been copied.

Debugger in playbook:

Ansible includes a debugger as part of the strategy plugins. This debugger enables you to debug as task. You have access to all of the features of the debugger in the context of the task. You can then, for example, check or set the value of variables, update module arguments, and re-run the task with the new variables and arguments to help resolve the cause of the failure.

Ways to invoke debugger:

  • always: Always invoke the debugger, regardless of the outcome
  • never: Never invoke the debugger, regardless of the outcome
  • on_failed: Only invoke the debugger if a task fails
  • on_unreachable: Only invoke the debugger if the a host was unreachable
  • on_skipped: Only invoke the debugger if the task is skipped

Available debugging commands:

  • p(print) task/task_vars/host/result: Print values used to execute a module
  • task.args[key] = value: Update module’s argument
  • task_vars[key] = value: Update task_vars
  • u(pdate_task): re-creates the task from the original task data structure, and templates with updated task_vars
  • r(edo): Run the task again
  • c(ontinue): Just continue
  • q(uit): Quit from the debugger

Rolling update in playbook:

By default, Ansible will try to manage all of the machines referenced in a play in parallel. For a rolling update use case, you can define how many hosts Ansible should manage at a single time by using the serial keyword. The serial keyword can also be specified as a percentage, which will be applied to the total number of hosts in a play, in order to determine the number of hosts per pass.

Error Handling in playbook:

Ansible normally has defaults that make sure to check the return codes of commands and modules and it fails fast – forcing an error to be dealt with unless you decide otherwise. Sometimes a command that returns different than 0 isn’t an error. Sometimes a command might not always need to report that it ‘changed’ the remote system. You can control all this behavior in your playbook using error handling.

Prompt in playbook:

When running a playbook, you may wish to prompt the user for certain input, and can do so with the ‘vars_prompt’ section. A common use for this might be for asking for sensitive data that you do not want to record. This has uses beyond security, for instance, you may use the same playbook for all software releases and would prompt for a particular release version in a push-script.

Tags in playbook:

If you have a large playbook, it may become useful to be able to run only a specific part of it rather than running everything in the playbook. Ansible supports a “tags:” attribute for this reason.

When you execute a playbook, you can filter tasks based on tags in two ways:

  • On the command line, with the –tags or –skip-tags options
  • In Ansible configuration settings, with the TAGS_RUN and TAGS_SKIP options

Start and Step in playbook:

If you want to start executing your playbook at a particular task, you can do so with the –start-at-task option. Playbooks can also be executed interactively with –step option.

Hope you have enjoyed this article. It is not possible to cover all the playbook advance feature in one blog post. May be in future, I will divide this in two-part series and cover all.

To get a complete list of available playbook features, please refer below Ansible documentation

https://docs.ansible.com/ansible/latest/user_guide/playbooks_special_topics.html

https://docs.ansible.com/ansible/latest/reference_appendices/playbooks_keywords.html

To get more details on Ansible, please refer below Ansible documentation.

https://docs.ansible.com/