info dump, useful when starting out
playbook
play -> targets a subset of the inventory
task -> targets a module
task -> module
task -> module
play
task -> targets a module
task -> module
# Interpolation:
server[a:z].lab.example.com
server[1:100].lab.example.com
server[001:100].lab.example.com
# Grouping
[supergroupName:children] # indicates that entries will be group names not host names
groupA
groupB
# vars
Broadly speaking, in three classes: Global, Play, Host
Within each class there's a very specific ordering of precedence, mostly don't need to worry too much
## In a play:
```
- name: my play
hosts: foo bar baz
become: true
vars:
key1: val1
key2: val1
packages:
- foo
- baz
- etc
tasks:
- name: install packages
yum:
name: "{{ packages }}"
```
{{ foo }} needs to be quoted if it's a bare value, but doesn't need to be quoted if it's in the middle of another string, eg. `name: now installing {{ packages }} packages`
This is because a value can be a straight JSON-format dict
You can also throw your vars in a file, and reference it in the play:
vars_files:
- file1.yml
You can define vars in a task, but they'll be scoped to the play. They remain visible for the remainder of the play (eg. fetch dynamic content, use in a later task.
## Defining in inventory
```
[webservers]
foo.example.com ansible_user=joe # overrides the SSH login-user to be joe, cute runtime feature
bar.example.com
baz.example.com ansible_host=baz.testing.com # refer as baz.example, actually connect to baz.testing
[webservers:vars]
foo=bar
; for the whole group here
```
Note that you can only do basic key-values here, no deeper structures possible.
if you use IP addresses in the inventory, that's the inventory name. Setting ansible_host lets you override that in your playbooks
group_vars and host_vars are a much better idea.
FS tree:
- inventory
host_vars
- demo.example.com (yaml formatted file of vars, applies to the named host as per filename)
demo.example.com can ALSO be a directory. In that directory you have any number of YAML files, containing YAML-formatted vars. Lets you have plain and encrypted vars!
# Looping
`item` is implicit here
```
- name: enable all services
service:
name: "{{ item }}"
state: started
enabled: true
loop:
- httpd
- mariadb
- firewalld
```
# Facts
ansible_foo is the old way
ansible_facts['varname'] is the new way
You can have custom facts on each host too. it's ini-style, and you might need to create dir tree manually. Files in there must have extension of .fact
/etc/ansible/facts.d/myfacts.fact
[default_section]
important = "we are cool"
Comes out in ansible_local fact section:
ansible_local: {
myfacts: { # filename without extension
default_section: {
important: "we are cool"
}
}
}
## Magic variables
hostvars: lets you inspect vars for all managed hosts, not just your own
group_names: all the groups that this host is a member of
groups: all groups and hosts in the inventory
inventory_hostname: the name as according to the inventory file, the left column not the possibly-override value