Tools/Ansible/Use Cases

Accueil	SysAdmin	Hobbies

Ansible - Cas d'usage

Include des variables depuis un fichier Ansible Vault

Utilisation de plusieurs "tasks"

Ex, le fichier de variables dépend de l’environnement (prod,dev, qual etc ...)

---
# ./configure_app_servers.yml

- name: configure app servers
  hosts: app_servers
  pre_tasks:
    - name: include env vars
      include_vars: "{{ env }}.yml"
      tags: ["always"]

    - name: include vault for env
      include_vars: "{{ env }}.vault.yml"
      tags: ["always"]
  roles:
    ...

Vous pouvez régler env en passant l'option --extra-vars à ansible-playbook :

$ ansible-playbook configure_app_servers.yml --extra-vars "env=prod"

Exemples de fichier de param :

---
# ./vars/prod.yml

domain: example.com
rails_env: production
https: true

Le fichier prod.vault.yml peut ressembler à ceci (en texte brut) :

$ANSIBLE_VAULT;1.1;AES256
3462353065386462383165626...
...

Mais à ceci si on utilise la commande ansible-vault view ./vars/prod.vault.yml:

---
# ./vars/prod.vault.yml

database_password: "94BqEabtebgzbQItkqPEVMyqjKbp57Gc"
api_key: "xVQKRARKgcwDktPCJjYRFiqmHGsvNFd9"

Utilisation d'une boucle

L'exemple précédent peut être plus clair et concis si on utilise une boucle avec des include_vars plutôt que deux tâches séparées :

---
# ./configure_app_servers.yml

- name: configure app servers
  hosts: app_servers
  pre_tasks:
    - name: include vars and vault for env
      include_vars: "{{ item }}.yml"
      tags: ["always"]
      loop:
        - "{{ env }}"
        - "{{ env }}.vault"
  roles:
    ...

Inclure des "tasks"

gestion de boucles

Cette technique est utile chaque fois que vous devez exécuter plusieurs tâches pour chaque élément d'une boucle.

exemple :

---
# ./greet_tasks.yml

- name: set greeting fact
  set_fact: 
    greeting: "Greeting {{ index }}: Hello, {{ name }}!"

- name: print greeting fact
  debug: var=greeting

Vous pouvez exécuter ces tâches dans une bloucle comme ceci :

# ./greet.yml

- name: greet people
  hosts: "*"
  tasks:
    - include_tasks: greet_tasks.yml
      loop:
        - World
        - Percy
      loop_control:
        loop_var: name
        index_var: index

Ce qui donne à l'exécution du playbook :

TASK [set greeting fact]
ok: [123.123.123.123]

TASK [print greeting fact]
ok: [123.123.123.123] => {
    "greeting": "Greeting 0: Hello, World!"
}

TASK [set greeting fact]
ok: [123.123.123.123]

TASK [print greeting fact]
ok: [123.123.123.123] => {
    "greeting": "Greeting 1: Hello, Percy!"
}

Inclure des "tasks" à partir de fichier dynamiques

L'inclusion de tâches avec un nom de fichier dynamique est le plus souvent utilisée pour faire varier les tâches en fonction du système d'exploitation de l'hôte distant.

Prenons l'exemple suivant :

# ./roles/redis/tasks/main.yml

- name: install redis on Debian based distros 
  apt:
    name: redis-server
    state: present
    update_cache: true
  become: true
  when: ansible_os_family == 'Debian'

- name: ensure epel-release repo is installed on RHEL based distros
  yum:
    name: epel-release
    state: present
    update_cache: true
  become: true
  when: ansible_os_family == 'RedHat'

- name: install redis on RHEL based distros
  yum:
    name: redis
    state: present
    update_cache: true
  become: true
  when: ansible_os_family == 'RedHat'

Il peut être avantageusement factorisé en 3 tâches distinctes de la façon suivante :

---
# ./roles/redis/tasks/setup-Debian.yml

- name: install redis on Debian based distros 
  apt:
    name: redis-server
    state: present
    update_cache: true
  become: true
  when: ansible_os_family == 'Debian'

---
# ./roles/redis/tasks/setup-RedHat.yml

- name: ensure epel-release repo is installed on RHEL based distros
  yum:
    name: epel-release
    state: present
    update_cache: true
  become: true
  when: ansible_os_family == 'RedHat'

- name: install redis on RHEL based distros
  yum:
    name: redis
    state: present
    update_cache: true
  become: true
  when: ansible_os_family == 'RedHat'

# ./roles/redis/tasks/main.yml

- include_tasks: "setup-{{ ansible_os_family }}.yml"

Utilisation de import_playbook & fichiers YAML dynamiques

---
# ./master.yml

- import_playbook: common_roles.yml

- import_playbook: staging_roles.yml
  when: env == 'staging'

- import_playbook: "{{ server_type }}.yml"

You can modify the server-specific playbooks to contain only a single play each: On peut les playbooks specifiques aux servers pour qu'ils ne contiennent qu'une tâche chacun :

---
'''# ./web.yml'''

- name: configure web servers
  hosts: "{{ env }}_web"
  roles:
    - nginx
    - my_site

---
'''# ./database.yml'''

- name: configure database servers
  hosts: "{{ env }}_database"
  roles:
    - postgres

A partir le là, il est possible de configurer à la fois les serverus web et base de données en utilisant seulement l'unique fichier master.yml playbook et en utilisant env et server_type pour specifier quels serveurs on désire configurer :

$ ansible-playbook master.yml --extra-vars "env=staging server_type=web"

$ ansible-playbook master.yml --extra-vars "env=staging server_type=database"