We are under very early construction, so please indulge us.

Ansible

Introduce host term?

Some reusable SVG picture with schema and flow would be nice.

Control node

Machine with Ansible installed to run commands and playbooks.

Consider Docker image to run the control node quickly.

Typical management pattern?

Managed nodes

Hosts to be managed.

Inventory

A list (structure?) of managed nodes.

Inventory is a nice-to-have thing even without Ansible.

Target expression. Used both in Ad-hoc commands and playbook files when providing "hosts" clause.

Inventory sample

all:
    hosts:
        host1.domain.com:
            custom_var1: ...
        host2.domain.com:
        host3.domain.com:

    children:
        webservers:
            hosts:
                host3.domain.com:

Modules

The unit of execution containing a specific responsibility.

Tasks

Probably module can be considered as function with parameters when task is its call?

Task expression or Module call expression. Used both in Ad-hoc commands via "-m" (module) option and playbook files in "tasks" section.

Playbooks

Ordered list of tasks applied for hosts from inventory.

Playbooks are Ansible’s configuration, deployment, and orchestration language. They can describe a policy you want your remote systems to enforce, or a set of steps in a general IT process.

ansible-playbook playbook.yml -i inventory

Playbook pattern looks like

- hosts: {target_expression}
  tasks:
  - name: test connection
    ping:
  - name: another task
    {module_name}: {task_expresion}
  roles:
    - common
    - web-server

Ad Hoc Commands

ansible all -m ping -i inventory

Where all is a target expression.

Variables

Playbook

Put in vars: section of the host in playbook.

- hosts: docker_servers
  vars:
    recreate: yes #TODO: no
  tasks:
    ...

Group vars

Put in /group_vars/[group_name].yml (e.g. /group_vars/all.yml) something like:

var_1_name: var_1_value
var_2_name: var_2_value

Usefull modules

Debugging

- hosts: all
  tasks:
  - debug:
      msg: System {{ inventory_hostname }} has private IP {{ private_ip }}
    when: private_ip is defined

Secrets

Encryption key can be stored in a file, e.g. if controller is created temporary and this helps to avoid prompting every time. Especially in development mode.

$ echo 'my_vault_password' >> .vault

Then we can encrypt value (for embedding secret) or file

# Encrypting value with prompted key
ansible-vault encrypt_string 'master_password_value' --name 'master_password'

# Encrypting value with key from the file
ansible-vault encrypt_string 'master_password_value' --vault-id .vault --name 'master_password'

# Encrypting file with key from the file
ansible-vault encrypt vars.yml --vault-id .vault

# Creating encrypted file with key prompted
ansible-vault create vars.yml

Generated value can be embedded into the playbook

vars:
    master_password: !vault |
        $ANSIBLE_VAULT;1.1;AES256
        39353161656537303835363537373733663766343264323732643233613933633038303561383562
        3564663530353734306334343033643934373334366463320a303939653631646632386230306537
        39663334353730623531303139613838626635623035346532613264353565656531323734386463
        6530323134663230340a626235396166653939333332303930383334383662623530616362656465
        3733

And later used with password propmpted or provided from the file

# Prompt for the key
ansible-playbook config.yml -i inventory --ask-pass

# Read decryption key from the file
ansible-playbook config.yml -i inventory --vault-id .vault

InBox

Ansible has some benefits compared to Docker Compose. Syntax of compose files and playbooks YAML are almost the same, but for Ansible flexibility of this tool is vital while for Docker it's more an addon.

S