A playbook and state modules

A playbook is the same ad-hoc commands written down in a file. The run report shows which tasks changed something.

A playbook is a YAML file with a list of plays. A play says which machines to work on (hosts: web), as whom (become: true — the same as the -b option) and what to do (tasks). A task is a name (name) and a module with arguments, as in an ad-hoc command:

yaml

- name: Application settings
  hosts: web
  become: true
  tasks:
    - name: Environment file
      copy:
        content: "MODE=prod\n"
        dest: /etc/app.env

ansible-playbook site.yml runs the plays in order. First Ansible gathers information about the machine — the Gathering Facts task, which is always ok. At the end comes PLAY RECAP: a line per machine, ok is how many tasks passed without errors, changed is how many of them changed something; failed, unreachable and skipped are the failed, unreachable and skipped ones (in the Wiki).

The shell module is command run through a shell: > and && work in it. And like command, it answers changed on every run. State modules describe what the machine should be like and change only the difference:

A shell task	A state module
`mkdir -p /srv/shop`	`file` with `path` and `state: directory`
`echo … > file`	`copy` with `content` and `dest`
`systemctl start nginx`	`service` with `name` and `state: started`

Exercise · do it

Rewrite the tasks with modules

Rewrite the tasks of ~/ansible-lab/site.yml with the file, copy and service modules: the /srv/shop directory, the index.html page and the nginx config on port 8080 — with the same content as your colleague's — while nginx just has to be running. Run the playbook and look at PLAY RECAP.

Goals · 0 of 2

Describe the tasks with modules instead of shell not done yet
Make a run change nothing while the site on 8080 works not done yet

A playbook: tasks, handlers, templates