Ansible Training – 4. Ansible Playbooks - Basics

Docs: 4.1 Ansible Playbooks - Variables and Loops

Mon, 01 Jan 0001 00:00:00 +0000

In this lab we’ll start to use variables and loops.

Task 1

In your playbook webserver.yml you have two tasks for starting and enabling httpd and firewalld. Merge these 2 tasks into one.

Tip

Remember loop: or with_items:

Solution Task 1

Delete the 2 tasks “start and enable [httpd,firewalld]”. Add a new task with the following content:

1
2
3
4
5
6
7
8


- name: start and enable services
 ansible.builtin.systemd_service:
 name: "{{ item }}"
 state: started
 enabled: true
 loop:
 - httpd
 - firewalld

Tip

Make sure your indentations are correct! Older versions of Ansible used with_items instead of loop

Task 2

In your playbook webserver.yml, ensure that the package firewalld is installed. Do the installation of httpd and firewalld in one task. Do you really need to use a loop? Have a look at the description of Ansible’s ansible.builtin.dnf module.

Solution Task 2

1
2
3
4
5
6
7


tasks:
 - name: install httpd and firewalld
 ansible.builtin.dnf:
 name:
 - httpd
 - firewalld
 state: installed

Tip

See Ansible Docs - Dnf Module

Task 3

Write a new playbook motd.yml which sets the content of /etc/motd on all servers to a custom text. Use the variable motd_content and the ansible.builtin.copy module with the option content containing the variable.

Solution Task 3

Content of motd.yml:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


---
- hosts: all
 become: true
 vars:
 motd_content: "Thi5 1s some r3ally stR4nge teXT!\n"
 tasks:
 - name: set content of /etc/motd
 ansible.builtin.copy:
 dest: /etc/motd
 content: "{{ motd_content }}"
 mode: "0644"

1

ansible-playbook motd.yml

Take a look at what your playbook just did:

1
2
3
4


$ ssh -l ansible <node1-ip>
Last login: Fri Nov 1 14:16:08 2019 from 5-102-146-174.cust.cloudscale.ch
Thi5 1s some r3ally stR4nge teXT! # <-- it worked!
[ansible@node1 ~]$

Task 4

Using the command line, overwrite the content of motd by providing the variable motd_content with a different value.
Modify the content again, but use a vars.yml file.

Solution Task 4

1
2
3
4
5
6


$ ansible-playbook motd.yml --extra-vars motd_content="0th3r_5trang3_TExt"

$ ssh -l ansible <node1-ip>
Last login: Fri Nov 1 14:18:52 2019 from 5-102-146-174.cust.cloudscale.ch
0th3r_5trang3_TExt # <-- it worked
[ansible@node1 ~]$

1
2
3
4


$ cat vars.yml
---
motd_content: "st1ll m0r3 str4ng3 TexT!"
$ ansible-playbook motd.yml --extra-vars @vars.yml

Task 5

Set the motd_content from Task 4 using group_vars for node1 and host_vars for node2.
Make sure you remove the variable definition in motd.yml. Reason being it will have a higher priority.
Limit the run to node1 and node2.

Tip

Think about where you have to create the folders for your host and group variables

Solution Task 5

Your motd.yml should look something like this:

1
2
3
4
5
6
7
8
9


---
- hosts: all
 become: true
 tasks:
 - name: set content of /etc/motd
 ansible.builtin.copy:
 dest: /etc/motd
 content: "{{ motd_content }}"
 mode: "0644"

After creating the new directories and files you should have something similar to this:

1
2
3
4
5
6


$ cat inventory/group_vars/web.yml
---
motd_content: "This is a webserver\n"
$ cat inventory/host_vars/node2.yml
---
motd_content: "This is node2\n"

Run your playbook and check if the text was changed accordingly on the two nodes:

1
2
3


ansible-playbook motd.yml -l node1,node2

ansible web,node2 -a "cat /etc/motd"

Task 6

Get a feeling for errors: Remove the quotes around the curly brackets and have a look at the output.

Solution Task 6

1
2
3
4
5
6
7
8
9


---
- hosts: all
 become: true
 tasks:
 - name: set content of /etc/motd
 ansible.builtin.copy:
 dest: /etc/motd
 content: {{ motd_content }} #<-- missing quotes here
 mode: "0644"

Task 7 (BONUS!)

Create a playbook takemehome.yml that does the following:
- Create a compressed archive containing all the content from your /home/ansible/techlab/ folder
- Don’t include the subfolder /home/ansible/techlab/awx with all its content in the archive.
- Compress the archive using any supported type of compression.
- Ensure an archive is created even if the source is one single file.
- Send this file via mail to your own email address. Note that you have to have valid credentials for a smtp server. Put these credentials into a password file password_file.yml.
- Run the playbook using the smtp password from the file password_file.yml
- remove the password file password_file.yml

Warning

It’s NOT secure to put the smtp password unencrypted in a file. We will learn in the labs about ansible-vault how to encrypt sensitive data in a secure way.

Solution Task 7

Write your SMTP Password to a file:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


$ cat password_file.yml
password: "<my_secret_password>"

Create the playbook:
$ cat takemehome.yml
---
- hosts: localhost
 #vars_files: # if the vars file is not provided here, you'll have to use it with
 # - password_file.yml # --extra-vars on cmdline as shown below
 tasks:
 - name: Create archive, excluding awx folder
 community.general.archive:
 path: /home/ansible/techlab/*
 dest: /home/ansible/techlab.tar.bz2
 exclude_path: /home/ansible/techlab/awx
 format: bz2
 force_archive: true
 mode: "0440"
 - name: Send archive via email
 community.general.mail:
 host: smtp.puzzle.ch
 port: 587
 username: "tux.puzzler@puzzle.ch"
 password: "{{ password }}"
 secure: starttls
 sender: tux.puzzler@puzzle.ch
 to: bill.gates@gmail.com
 subject: Techlab stuff
 body: Sending my stuff home
 attach: /home/ansible/techlab.tar.bz2
 no_log: true

Run the playbook by using the SMTP password from the file created before. After the playbook was sent, delete the password file.

1
2
3


ansible-playbook takemehome.yml --extra-vars "@password_file.yml"
ansible-playbook takemehome.yml # if vars file provided in playbook
rm -f password_file.yml

All done?

Wow! Well done. :-)

Docs: 4.2 Ansible Playbooks - Templates

Mon, 01 Jan 0001 00:00:00 +0000

In this lab we start to use templates!

Task 1

Rewrite your playbook motd.yml without using the ansible.builtin.copy module, but rather using the ansbile.builtin.template module.
Use a Jinja2 template file called motd.j2 which uses the variable motd_content.

Solution Task 1

Create the file motd.j2 with the following one-liner:

1
2


$ cat motd.j2
{{ motd_content }}

Edit your motd.yml playbook to something like this:

1
2
3
4
5
6
7
8
9


---
- hosts: all
 become: true
 tasks:
 - name: set content of /etc/motd
 ansible.builtin.template:
 src: motd.j2
 dest: /etc/motd
 mode: "0644"

Run the playbook again.

1

 ansible-playbook motd.yml -l node1,node2

Task 2

Improve the template motd.j2 by adding the default IP address of the server to the template.
Add information about the installed operating system to the motd file as well.

Tip

Remember using the ansible.builtin.setup module to get a list of all facts! Ensure, that gather_facts was set to true.

Solution Task 2

Add IP and OS to motd.j2:

1
2
3
4


$ cat motd.j2
{{ motd_content }}
IP ADDRESS: {{ ansible_default_ipv4.address }}
OS: {{ ansible_os_family }}

Rerun the playbook and check if the text has been changed accordingly:

1
2


ansible-playbook motd.yml -l node1,node2
ansible all -a "cat /etc/motd"

Task 3 (Advanced)

Create a variable users like the following:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


users:
 - name: jim
 food: pizza
 - name: sabrina
 food: burger
 - name: hans
 food: vegan
 - name: eveline
 food: burger
 - name: santos

Put the variable in an appropriate place of your choice.

Create a playbook userplay.yml doing the following and running on node1 and node2:

On node1: Create a file /etc/dinner.txt with the content below by using the ansible.builtin.template module:
```
<name_of_user> <food_for_user>
```
On node1: There should be an entry in the file /etc/dinner.txt for each user in the variable users. Use a for loop in the template.
On node1: If a user has no food specified, use “kebab”. Look for filters in the online docs. You should be familiar with searching the online docs by now.
On node2: The same playbook userplay.yml should create a (Linux) group for every different food specified in the variable users. If a user has no food defined, create the group “kebab” instead.
On node2: Create a user for every entry in the users variable. Ensure that this user is also in the group with the same name as his food. Again, if no food is defined for this user, add group “kebab”.

Bonus 1

On node2: Set the login shell to /bin/zsh for all users.

Bonus 2

On node2: If (and only if) the user is “santos”, disable login. Do this by setting santos’ login shell to /usr/sbin/nologin. Use an if/else statement in the template for that purpose.

Bonus 3

All on node2:
- Set the default password for all the newly created users to “N0t_5o_s3cur3”
- Once the password has been set, your playbook should not set it again. Not even when it got changed.
- Hash the password using the sha512 algorithm.
- Don’t define a salt for the password.
- Verify that you are able to log in as one of the users via SSH providing the password.

Warning

Be aware that it is NOT a good idea to set passwords in clear text. We will learn in the lab about ansible-vault how to handle this in a better way. Never ever do this in a productive environment.

Solution Task 3

Note

Be aware that there are multiple possible solutions.

Documentation about filters

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55


$ pwd
/home/ansible/techlab

$ cat uservars.yml
users:
 - name: jim
 food: pizza
 - name: sabrina
 food: burger
 - name: hans
 food: vegan
 - name: eveline
 food: burger
 - name: santos

$ cat userplay.yml
---
- hosts: node1
 become: true
 vars_files:
 - uservars.yml
 tasks:
 - name: put template
 ansible.builtin.template:
 src: user_template.j2
 dest: /etc/dinner.txt
 mode: "0644"

- hosts: node2
 become: true
 vars_files:
 - uservars.yml
 tasks:
 - name: create groups
 ansible.builtin.group:
 name: "{{ item.food | default('kebab') }}"
 loop: "{{ users }}"
 - name: ensure zsh is installed
 ansible.builtin.dnf:
 name: zsh
 state: installed
 - name: create users
 ansible.builtin.user:
 name: "{{ item.name }}"
 group: "{{ item.food | default('kebab') }}"
 append: true
 shell: "{% if item.name == 'santos' %}/usr/sbin/nologin{% else %}/usr/bin/zsh{% endif %}"
 password: "{{ 'N0t_5o_s3cur3' | password_hash('sha512') }}"
 update_password: on_create
 loop: "{{ users }}"

$ cat user_template.j2
{% for person in users %}
{{ person.name }} {{ person.food | default('kebab') }}
{% endfor %}

Tip

See the ansible.builtin.user module for how to set the password and search for a link to additional documentation about how to set passwords in Ansible. Note, that it would be even better to create a hash of the password beforehand and then set the hash in the task above and not create it in the task itself. Reason being the above would result in a state changed everytime it runs and is therefore not idempotent. You can find in the documentation mentioned how to get the hash in advance.

Run the playbook, then check on node1 (as user root) if everything is as expected:

1
2
3
4
5
6


# cat /etc/dinner.txt
jim pizza
sabrina burger
hans vegan
eveline burger
santos kebab

Check as well on node2 (as user root):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# grep 'jim\|sabrina\|hans\|eveline\|santos' /etc/passwd
jim:x:1002:1002::/home/jim:/usr/bin/zsh
sabrina:x:1003:1003::/home/sabrina:/usr/bin/zsh
hans:x:1004:1004::/home/hans:/usr/bin/zsh
eveline:x:1005:1003::/home/eveline:/usr/bin/zsh
santos:x:1006:1005::/home/santos:/usr/sbin/nologin

# grep 'pizza\|burger\|vegan\|kebab' /etc/group
pizza:x:1002:
burger:x:1003:
vegan:x:1004:
kebab:x:1005:

1
2


ssh -l jim <IP address of node2>
jim@192.168.122.31's password:

Task 4 (Maester)

Create a playbook serverinfo.yml that does the following:

On all nodes: Place a file /root/serverinfo.txt with a line like the following repeated for each and every server in the inventory:

<hostname>: OS: <operating system> IP: <IP address> Virtualization Role: <hardware type>

Replace hostname, operating system, IP address and hardware type with a reasonable fact.
Run your playbook and check on all servers by using an ansible ad hoc command if the content of the file /root/serverinfo.txt is as expected.
Are you an Ansible Maester already? Solve the solution once by using a template and once without using a template!

Solution Task 4

Possible solution 1:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


$ cat serverinfo.txt.j2
{% for host in groups['all'] %}
{{ hostvars[host].ansible_hostname }}: OS: {{ hostvars[host].ansible_os_family }} IP: {{ hostvars[host].ansible_default_ipv4.address }} Virtualization Role: {{ hostvars[host].ansible_virtualization_role }}
{% endfor %}

$ cat serverinfo.yml
---
- hosts: all
 become: true
 tasks:
 - name: put serverinfo.txt
 ansible.builtin.template:
 src: serverinfo.txt.j2
 dest: /root/serverinfo.txt
 mode: "0640"

Note

Have a good look at where to set quotes and where not! hostvars[host] without the quotes around host is not really intuitive. More about that in the FAQ.

Possible solution 2:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


$ cat serverinfo.yml
---
- hosts: localhost
 tasks:
 - name: create the serverinfo file to be distributed later
 ansible.builtin.file:
 path: /home/ansible/techlab/serverinfo.txt
 state: touch
 mode: "0644"

- hosts: all
 tasks:
 - name: fill in stuff to local serverinfo.txt
 ansible.builtin.lineinfile:
 path: /home/ansible/techlab/serverinfo.txt
 regexp: "^{{ ansible_hostname }}"
 line: "{{ ansible_hostname }}: OS: {{ ansible_os_family }} IP: {{ ansible_default_ipv4.address }} Virtualization Role: {{ ansible_virtualization_role }}"
 delegate_to: localhost

- hosts: all
 become: true
 tasks:
 - name: place the file serverinfo.txt
 ansible.builtin.copy:
 src: /home/ansible/techlab/serverinfo.txt
 dest: /root/serverinfo.txt
 mode: "0640"

$ ansible-playbook serverinfo.yml
$ ansible all -b -a "cat /root/serverinfo.txt"

All done?

Using filters to manipulate data

Docs: 4.3 Ansible Playbooks - Output

Mon, 01 Jan 0001 00:00:00 +0000

In this lab we learn how to handle output of tasks.

Task 1

Write a playbook output.yml that uses the ansible.builtin.command module to find all config files of postfix. These files are located under /etc/postfix/ and end with .cf. Targeted server is node1.
Register the result to a variable called output by using the register keyword.
Include a task using the ansible.builtin.debug module to print out all content of the variable output. If unsure, consult the documentation about the ansible.builtin.debug module.

Note

You might need to install the postfix package on node1.

Solution Task 1

Documentation about debug module Example output.yml:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


---
- hosts: node1
 become: true
 tasks:
 - name:
 ansible.builtin.command:
 cmd: "find /etc/postfix -type f -name *.cf"
 register: output
 - name: Print the output
 ansible.builtin.debug:
 var: output

Task 2

Add another task to the playbook output.yml using the ansible.builtin.debug module and print out the resulting filenames of the search above.

Tip

Use an appropriate return value to show the output. Information about return values can be found here: Ansible Docs - Common Return Values

Now, loop over the results and create a backup file called <filename.cf>.bak for each file <filename.cf> that was found. Use the ansible.builtin.command module. Remember, that the result is probably a list with multiple elements.

Solution Task 2

Example output.yml:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


---
- hosts: node1
 become: true
 tasks:
 - name: Find the files
 command:
 cmd: "find /etc/postfix -type f -name *.cf"
 register: output
 - name: Printb the output
 ansible.builtin.debug:
 var: output.stdout_lines
 - name: create backup
 ansible.builtin.command:
 cmd: "cp {{ item }} {{ item }}.bak"
 loop: "{{ output.stdout_lines }}"

Task 3 (Advanced)

Now we enhance our playbook output.yml to only create the backup if no backup file is present.
Solve this task by searching for files ending with .bak and registering the result to a variable. Then do tasks only if certain conditions are met.

Tip

Have a look at the documentation about the ansible.builtin.command module: Ansible Docs - command

Solution Task 3

Possible solution 1: Example output.yml:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


---
- hosts: node1
 become: true
 tasks:
 - name: Find the files
 ansible.builtin.command:
 cmd: "find /etc/postfix -type f -name *.cf"
 register: output
 - name: create backup only when no backup file is present
 ansible.builtin.command:
 cmd: "cp {{ item }} {{ item }}.bak"
 creates: "{{ item }}.bak" # only do this if there is no .bak for file: item
 loop: "{{ output.stdout_lines }}"

Possible solution 2: Example output.yml:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


---
- hosts: node1
 become: true
 tasks:
 - name: Find the backups
 ansible.builtin.command:
 cmd: "find /etc/postfix -type f -name *.cf.bak"
 register: search
 - name: Find the files
 ansible.builtin.command:
 cmd: "find /etc/postfix -type f -name *.cf"
 register: output
 - name: create backup only when no backup file is present
 ansible.builtin.command:
 cmd: "cp {{ item }} {{ item }}.bak"
 loop: "{{ output.stdout_lines }}"
 when: search.stdout.find(item) == -1 # only do this if there is no .bak for file: item

Task 4 (Advanced)

Ensure httpd is stopped on the group web by using an Ansible ad hoc command.
Write a play servicehandler.yml that does the following:
Install httpd by using the ansible.builtin.dnf module
Start the service httpd with the ansible.builtin.command module. Don’t use ansible.builtin.service or ansible.builtin.systemd_service module.
Start the service only if it is not started and running already. (The output of systemctl status httpd doesn’t contains the string Active: active (running))

Note

Have a look at the documentation about conditionals: Ansible Docs - Playbook Conditionals

systemctl status returns status failed when a service is not running. Therefore, we use ignore_errors: true in the corresponding task to let Ansible continue anyway.

Solution Task 4

Stop the httpd service with Ansible:

1

ansible web -b -a "systemctl stop httpd"

Content of servicehandler.yml:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


---
- hosts: web
 become: true
 tasks:
 - name: install httpd
 ansible.builtin.dnf:
 name: httpd
 state: present
 - name: check state of service httpd
 ansible.builtin.command:
 cmd: 'systemctl status httpd'
 register: status
 ignore_errors: true
 - name: See the status
 ansible.builtin.debug:
 var: status.stdout
 - name: start httpd
 ansible.builtin.command:
 cmd: 'systemctl start httpd'
 when: "'Active: active (running)' not in status.stdout"

Task 5 (Advanced)

Rewrite the playbook servicehandler.yml and ensure that the ignore_errors: true line is removed. Instead, set the state of the task to failed if and only if the output of systemctl status httpd contains the string “failed”.

Note

Have a look at the documentation about error handling: Ansible Docs - Playbooks Error Handling

Rerun your playbook and ensure it still runs fine.
By using an ansible ad hoc command, place an invalid configuration file /etc/httpd/conf/httpd.conf and backup the file before. Use the ansible.builtin.copy module to do this in ad hoc command.
Restart httpd by using an Ansible ad hoc command. This should fail since the config file is not valid.
Rerun your playbook and ensure it fails.
Fix the errors in the config file, restart httpd on node1 and rerun your playbook. Everything should be fine again.

Solution Task 5

Example servicehandler.yml:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


---
- hosts: web
 become: true
 tasks:
 - name: install httpd
 ansible.builtin.dnf:
 name: httpd
 state: present
 - name: check state of service httpd
 ansible.builtin.command:
 cmd: 'systemctl status httpd'
 register: status
 failed_when: "'failed' in status.stdout"
 - name: Look at the status
 ansible.builtin.debug:
 var: status.stdout
 - name: start httpd
 ansible.builtin.command:
 cmd: 'systemctl start httpd'
 when: "'Active: active (running)' not in status.stdout"

1

ansible web -b -m ansible.builtin.copy -a "content='bli bla blup' dest=/etc/httpd/conf/httpd.conf backup=true"

Now fix your apache config. You could use the backup of the file created in the previous ad-hoc command.

1

ansible web -b -m ansible.builtin.systemd_service -a "name=httpd state=restarted"

All done?

Output as YAML instead of JSON

Docs: 4.4 Ansible-Pull

Mon, 01 Jan 0001 00:00:00 +0000

In this lab we’ll have a short glimpse at how ansible-pull works.

Task 1

Search docs.ansible.com for information about the ansible-pull command.
Look for a way to execute a playbook using ansible-pull
Search for an example playbook

Solution Task 1

ansible-pull Ansible-pull GitHub ansible-examples

Task 2

On node1:

Install all needed packages to use ansible-pull
Use an ansible-pull command that uses the resources in the folder resources/ansible-pull/ of our GitHub repository located at https://github.com/puzzle/ansible-techlab. This command should do the following:
- Apply the playbook local.yml located at the resource/ansible-pull folder and run it on all hosts in the inventory file hosts
- Show the content of /etc/motd and verify, that the file was copied using ansible-pull
- Also verify, that no content of the git repository was copied to the local folder.

Tip

Note the following:

If no playbook is specified, ansible-pull looks for a playbook local.yml.
The location of files given as parameters to the ansible-pull command are always relative to the top level of the git repository.
All information to run the ansible-pull command is taken from the git repository (playbook, inventory, MOTD-file to be copied). No local configuration is used!

Solution Task 2

1
2
3
4


sudo dnf install -y ansible
/usr/bin/ansible-pull -U https://github.com/puzzle/ansible-techlab -i resources/ansible-pull/hosts resources/ansible-pull/local.yml
cat /etc/motd
ll #no file here...

Task 3

It’s a best practice to use cronjobs to trigger ansible-pull run at a regular basis. Do the following on node1:

Create a cronjob /etc/cron.d/ansible-pull. This cronjob should run every minute as user ansible the ansible-pull command from Task 2.
Now remove the existing /etc/motd file and use the command watch to show the content of /etc/motd every second. We want to observe that our cronjob runs the ansible-pull command again and restore the previously deleted MOTD-file.

Solution Task 3

1
2
3
4


$ sudo vim /etc/cron.d/ansible-pull #create the file with the content ->
$ cat /etc/cron.d/ansible-pull
* * * * * ansible /usr/bin/ansible-pull -U https://github.com/puzzle/ansible-techlab -i resources/ansible-pull/hosts resources/ansible-pull/local.yml
$ sudo rm -f /etc/motd; watch -n 1 cat /etc/motd

Task 4

This task has nothing to do with ansible-pull, we just clean up the ansible-pull configurations. Create a playbook revert_motd.yml that runs on node1. It should:

uninstall ansible
remove the cronjob /etc/cron.d/ansible-pull
empty the file /etc/motd

Run the playbook.

Solution Task 4

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


$ cat revert_motd.yml
---
- hosts: node1
 become: true
 tasks:
 - name: uninstall ansible
 ansible.builtin.dnf:
 name: ansible
 state: absent
 - name: ensure cronjob not present
 ansible.builtin.file:
 path: /etc/cron.d/ansible-pull
 state: absent
 mode: "0640"
 - name: ensure MOTD file empty
 ansible.builtin.copy:
 content: ""
 dest: /etc/motd
 mode: "0640"

$ ansible-playbook revert_motd.yml

All done?

ansible-pull

Docs: 4.5 Task control

Mon, 01 Jan 0001 00:00:00 +0000

In this lab we learn about task control.

Task 1

Write an ad-hoc command that sleeps for 1000 seconds and runs on node1
Ensure that the command times out after 10 seconds if not completed by then. Run the task.
Use the time command to see how long your ad-hoc command had to run. Use man time to see how time works.
Now add a polling interval of 30 seconds. Run the task, and ensure with the time command, that it had a longer runtime.
See what happens if you only specify the polling interval but no async timeout. Tip: set a sleep duration of only 10 seconds.

Solution Task 1

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


$ ansible node1 -B 10 -a "/usr/bin/sleep 1000"
node1 | FAILED | rc=-1 >>
Timeout exceeded

$ time ansible node1 -B 10 -a "/usr/bin/sleep 1000"
node1 | FAILED | rc=-1 >>
Timeout exceeded

real 0m17.461s
user 0m1.564s
sys 0m0.253s

$ time ansible node1 -B 10 -P 30 -a "/usr/bin/sleep 1000"
node1 | FAILED | rc=-1 >>
Timeout exceeded

real 0m32.625s #<- more than the polling interval
user 0m5.541s
sys 0m0.684s

Setting the poll parameter without the async parameter results in the job not beeing put in background.

1
2
3


$ ansible node1 -P 30 -a "/usr/bin/sleep 10"
node1 | CHANGED | rc=0 >>
$

Task 2

Write a playbook async.yml that does the same as in the task above:
Run a command that sleeps for 1000 second and runs on node1.
Let the task wait at most for 10 seconds before timing out.
Run the task.

Solution Task 2

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


$ cat async.yml
---
- hosts: node1
 tasks:
 - name: sleeping beauty
 ansible.builtin.command: "/usr/bin/sleep 1000"
 async: 10

$ ansible-playbook async.yml

PLAY [node1] **********************************************************************************************************

TASK [Gathering Facts] ************************************************************************************************
ok: [node1]

TASK [sleeping beauty] ************************************************************************************************
fatal: [node1]: FAILED! => {"changed": false, "msg": "async task did not complete within the requested time - 10s"}

PLAY RECAP ************************************************************************************************************
node1 : ok=1 changed=0 unreachable=0 failed=1 skipped=0 rescued=0 ignored=0

$

Task 3 (Advanced)

In the playbook async.yml do the following:

Put the task above in the background and change the values of the sleepduration, polling interval and async time to reasonable values.
Check back with an async_status task if the sleep-task has finished.
Run the playbook.

Tip

If unsure, check the documentation about async_status for an example.

Solution Task 3

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39


$ cat async.yml
---
- hosts: node1
 tasks:
 - name: sleeping beauty
 ansible.builtin.command: "/usr/bin/sleep 30"
 async: 60
 poll: 0
 register: sleepingbeauty

 - name: check back if task in background has finished
 ansible.builtin.async_status:
 jid: '{{ sleepingbeauty.ansible_job_id }}'
 register: beauty_status
 until: beauty_status.finished
 retries: 50

$ ansible-playbook async.yml

PLAY [node1] **********************************************************************************************************
TASK [Gathering Facts] ************************************************************************************************
ok: [node1]

TASK [sleeping beauty] ************************************************************************************************
changed: [node1]

TASK [check back if task in background has finished] ******************************************************************
FAILED - RETRYING: check back if task in background has finished (50 retries left).
FAILED - RETRYING: check back if task in background has finished (49 retries left).
FAILED - RETRYING: check back if task in background has finished (48 retries left).
FAILED - RETRYING: check back if task in background has finished (47 retries left).
FAILED - RETRYING: check back if task in background has finished (46 retries left).
FAILED - RETRYING: check back if task in background has finished (45 retries left).
changed: [node1]

PLAY RECAP ************************************************************************************************************
node1 : ok=3 changed=2 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0

$

All done?

Controlling Playbooks