## Ansible
### Ansible Exercises
|Name|Topic|Objective & Instructions|Solution|Comments|
|--------|--------|------|----|----|
| My First Task | Tasks | [Exercise](my_first_task.md) | [Solution](solutions/my_first_task.md)
| Upgrade and Update Task | Tasks | [Exercise](update_upgrade_task.md) | [Solution](solutions/update_upgrade_task.md)
| My First Playbook | Playbooks | [Exercise](my_first_playbook.md) | [Solution](solutions/my_first_playbook.md)
### Ansible Self Assessment
Describe each of the following components in Ansible, including the relationship between them:
* Task
* Module
* Play
* Playbook
* Role
Task – a call to a specific Ansible module
Module – the actual unit of code executed by Ansible on your own host or a remote host. Modules are indexed by category (database, file, network, …) and also referred to as task plugins.
Play – One or more tasks executed on a given host(s)
Playbook – One or more plays. Each play can be executed on the same or different hosts
Role – Ansible roles allows you to group resources based on certain functionality/service such that they can be easily reused. In a role, you have directories for variables, defaults, files, templates, handlers, tasks, and metadata. You can then use the role by simply specifying it in your playbook.
How Ansible is different from other automation tools? (e.g. Chef, Puppet, etc.)
Ansible is:
* Agentless
* Minimal run requirements (Python & SSH) and simple to use
* Default mode is "push" (it supports also pull)
* Focus on simpleness and ease-of-use
True or False? Ansible follows the mutable infrastructure paradigm
True. In immutable infrastructure approach, you'll replace infrastructure instead of modifying it.
Ansible rather follows the mutable infrastructure paradigm where it allows you to change the configuration of different components, but this approach is not perfect and has its own disadvantages like "configuration drift" where different components may reach different state for different reasons.
True or False? Ansible uses declarative style to describe the expected end state
False. It uses a procedural style.
What kind of automation you wouldn't do with Ansible and why?
While it's possible to provision resources with Ansible, some prefer to use tools that follow immutable infrastructure paradigm.
Ansible doesn't saves state by default. So a task that creates 5 instances for example, when executed again will create additional 5 instances (unless
additional check is implemented or explicit names are provided) while other tools might check if 5 instances exist. If only 4 exist (by checking the state file for example), one additional instance will be created to reach the end goal of 5 instances.
How do you list all modules and how can you see details on a specific module?
1. Ansible online docs
2. `ansible-doc -l` for list of modules and `ansible-doc [module_name]` for detailed information on a specific module
#### Ansible - Inventory
What is an inventory file and how do you define one?
An inventory file defines hosts and/or groups of hosts on which Ansible tasks executed upon.
An example of inventory file:
```
192.168.1.2
192.168.1.3
192.168.1.4
[web_servers]
190.40.2.20
190.40.2.21
190.40.2.22
```
What is a dynamic inventory file? When you would use one?
A dynamic inventory file tracks hosts from one or more sources like cloud providers and CMDB systems.
You should use one when using external sources and especially when the hosts in your environment are being automatically
spun up and shut down, without you tracking every change in these sources.
#### Ansible - Variables
Modify the following task to use a variable instead of the value "zlib" and have "zlib" as the default in case the variable is not defined
```
- name: Install a package
package:
name: "zlib"
state: present
```
```
- name: Install a package
package:
name: "{{ package_name|default('zlib') }}"
state: present
```
How to make the variable "use_var" optional?
```
- name: Install a package
package:
name: "zlib"
state: present
use: "{{ use_var }}"
```
With "default(omit)"
```
- name: Install a package
package:
name: "zlib"
state: present
use: "{{ use_var|default(omit) }}"
```
What would be the result of the following play?
```
---
- name: Print information about my host
hosts: localhost
gather_facts: 'no'
tasks:
- name: Print hostname
debug:
msg: "It's me, {{ ansible_hostname }}"
```
When given a written code, always inspect it thoroughly. If your answer is “this will fail” then you are right. We are using a fact (ansible_hostname), which is a gathered piece of information from the host we are running on. But in this case, we disabled facts gathering (gather_facts: no) so the variable would be undefined which will result in failure.
When the value '2017'' will be used in this case: `{{ lookup('env', 'BEST_YEAR') | default('2017', true) }}`?
when the environment variable 'BEST_YEAR' is empty or false.
If the value of certain variable is 1, you would like to use the value "one", otherwise, use "two". How would you do it?
`{{ (certain_variable == 1) | ternary("one", "two") }}`
The value of a certain variable you use is the string "True". You would like the value to be a boolean. How would you cast it?
`{{ some_string_var | bool }}`
You want to run Ansible playbook only on specific minor version of your OS, how would you achieve that?
What the "become" directive used for in Ansible?
What are facts? How to see all the facts of a certain host?
What would be the result of running the following task? How to fix it?
```
- hosts: localhost
tasks:
- name: Install zlib
package:
name: zlib
state: present
```
Which Ansible best practices are you familiar with?. Name at least three
Explain the directory layout of an Ansible role
What 'blocks' are used for in Ansible?
How do you handle errors in Ansible?
You would like to run a certain command if a task fails. How would you achieve that?
Write a playbook to install ‘zlib’ and ‘vim’ on all hosts if the file ‘/tmp/mario’ exists on the system.
```
---
- hosts: all
vars:
mario_file: /tmp/mario
package_list:
- 'zlib'
- 'vim'
tasks:
- name: Check for mario file
stat:
path: "{{ mario_file }}"
register: mario_f
- name: Install zlib and vim if mario file exists
become: "yes"
package:
name: "{{ item }}"
state: present
with_items: "{{ package_list }}"
when: mario_f.stat.exists
```
Write a single task that verifies all the files in files_list variable exist on the host
```
- name: Ensure all files exist
assert:
that:
- item.stat.exists
loop: "{{ files_list }}"
```
Write a playbook to deploy the file ‘/tmp/system_info’ on all hosts except for controllers group, with the following content
```
I'm and my operating system is
```
Replace and with the actual data for the specific host you are running on
The playbook to deploy the system_info file
```
---
- name: Deploy /tmp/system_info file
hosts: all:!controllers
tasks:
- name: Deploy /tmp/system_info
template:
src: system_info.j2
dest: /tmp/system_info
```
The content of the system_info.j2 template
```
# {{ ansible_managed }}
I'm {{ ansible_hostname }} and my operating system is {{ ansible_distribution }
```
The variable 'whoami' defined in the following places:
* role defaults -> whoami: mario
* extra vars (variables you pass to Ansible CLI with -e) -> whoami: toad
* host facts -> whoami: luigi
* inventory variables (doesn’t matter which type) -> whoami: browser
According to variable precedence, which one will be used?
The right answer is ‘toad’.
Variable precedence is about how variables override each other when they set in different locations. If you didn’t experience it so far I’m sure at some point you will, which makes it a useful topic to be aware of.
In the context of our question, the order will be extra vars (always override any other variable) -> host facts -> inventory variables -> role defaults (the weakest).
Here is the order of precedence from least to greatest (the last listed variables winning prioritization):
1. command line values (eg “-u user”)
2. role defaults [[1\]](https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#id15)
3. inventory file or script group vars [[2\]](https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#id16)
4. inventory group_vars/all [[3\]](https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#id17)
5. playbook group_vars/all [[3\]](https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#id17)
6. inventory group_vars/* [[3\]](https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#id17)
7. playbook group_vars/* [[3\]](https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#id17)
8. inventory file or script host vars [[2\]](https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#id16)
9. inventory host_vars/* [[3\]](https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#id17)
10. playbook host_vars/* [[3\]](https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#id17)
11. host facts / cached set_facts [[4\]](https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#id18)
12. play vars
13. play vars_prompt
14. play vars_files
15. role vars (defined in role/vars/main.yml)
16. block vars (only for tasks in block)
17. task vars (only for the task)
18. include_vars
19. set_facts / registered vars
20. role (and include_role) params
21. include params
22. extra vars (always win precedence)
A full list can be found at [PlayBook Variables](https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#ansible-variable-precedence) . Also, note there is a significant difference between Ansible 1.x and 2.x.
For each of the following statements determine if it's true or false:
* A module is a collection of tasks
* It’s better to use shell or command instead of a specific module
* Host facts override play variables
* A role might include the following: vars, meta, and handlers
* Dynamic inventory is generated by extracting information from external sources
* It’s a best practice to use indention of 2 spaces instead of 4
* ‘notify’ used to trigger handlers
* This “hosts: all:!controllers” means ‘run only on controllers group hosts
Explain the Difference between Forks and Serial & Throttle.
`Serial` is like running the playbook for each host in turn, waiting for completion of the complete playbook before moving on to the next host. `forks`=1 means run the first task in a play on one host before running the same task on the next host, so the first task will be run for each host before the next task is touched. Default fork is 5 in ansible.
```
[defaults]
forks = 30
```
```
- hosts: webservers
serial: 1
tasks:
- name: ...
```
Ansible also supports `throttle` This keyword limits the number of workers up to the maximum set via the forks setting or serial. This can be useful in restricting tasks that may be CPU-intensive or interact with a rate-limiting API
```
tasks:
- command: /path/to/cpu_intensive_command
throttle: 1
```
What is ansible-pull? How is it different from how ansible-playbook works?
What is Ansible Vault?
Demonstrate each of the following with Ansible:
* Conditionals
* Loops
What are filters? Do you have experience with writing filters?
Write a filter to capitalize a string
```
def cap(self, string):
return string.capitalize()
```
You would like to run a task only if previous task changed anything. How would you achieve that?
What are callback plugins? What can you achieve by using callback plugins?
What is Ansible Collections?
What is the difference between `include_task` and `import_task`?
File '/tmp/exercise' includes the following content
```
Goku = 9001
Vegeta = 5200
Trunks = 6000
Gotenks = 32
```
With one task, switch the content to:
```
Goku = 9001
Vegeta = 250
Trunks = 40
Gotenks = 32
```
```
- name: Change saiyans levels
lineinfile:
dest: /tmp/exercise
regexp: "{{ item.regexp }}"
line: "{{ item.line }}"
with_items:
- { regexp: '^Vegeta', line: 'Vegeta = 250' }
- { regexp: '^Trunks', line: 'Trunks = 40' }
...
```
#### Ansible - Execution and Strategy
True or False? By default, Ansible will execute all the tasks in play on a single host before proceeding to the next host
False. Ansible will execute a single task on all hosts before moving to the next task in a play. As for today, it uses 5 forks by default.
This behavior is described as "strategy" in Ansible and it's configurable.
What is a "strategy" in Ansible? What is the default strategy?
A strategy in Ansible describes how Ansible will execute the different tasks on the hosts. By default Ansible is using the "Linear strategy" which defines that each task will run on all hosts before proceeding to the next task.
What strategies are you familiar with in Ansible?
- Linear: the default strategy in Ansible. Run each task on all hosts before proceeding.
- Free: For each host, run all the tasks until the end of the play as soon as possible
- Debug: Run tasks in an interactive way
What the serial keyword is used for?
It's used to specify the number (or percentage) of hosts to run the full play on, before moving to next number of hosts in the group.
For example:
```
- name: Some play
hosts: databases
serial: 4
```
If your group has 8 hosts. It will run the whole play on 4 hosts and then the same play on another 4 hosts.
#### Ansible Testing
How do you test your Ansible based projects?
What is Molecule? How does it works?
You run Ansible tests and you get "idempotence test failed". What does it mean? Why idempotence is important?
#### Ansible - Debugging
How to find out the data type of a certain variable in one of the playbooks?
"{{ some_var | type_debug }}"
#### Ansible - Collections
What are collections in Ansible?