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 }}}