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