Road-to-DevOps/Pepiniere/Ansible/Formation/8.notions-avancees.md

<!-- .slide: data-state="nologo-slide" style="text-align: center" -->
![Logo Ansible](images/logo-ansible.svg)
# ansible-vault

Sécuriser les données sensibles.


* La commande `ansible-vault` permet la création de conteneurs chiffrés pour les variables sensibles.

```nohighlight
$ ansible-vault create test.yaml
Vault password:
```

* Le choix d'un un mot de passe est obligatoire lors de la création du fichier.


<!-- .slide: data-state="small-code" -->
Le contenu en clair :

```nohighlight
mon_super_mot_de_passe: 12345678
```

devient après chiffrement :

```nohighlight
$ cat test.yaml
$ANSIBLE_VAULT;1.1;AES256
62366463643661313763313135376434303535646637653237633233306663623635643761643161
3834383236386535366533303733613838653836623661340a383263633435336234333335343539
30333664666364613731666666636235373633346463353766356364623039656262363238363830
3236656664353565620a303034643732636166376535386436616231653363386334663065326337
3561
```


Le mot de passe sera demandé lors de chacune des exécutions du playbook :

```nohighlight
$ ansible-playbook mon-playbook.yaml –ask-vault-pass
Vault password:
```


### Travaux pratiques
<!-- .slide: data-state="nologo-slide" style="text-align: center" -->

![Travaux pratiques](images/tp.gif)

<small>[TP Ansible vault](travaux-pratiques/tp-ansible-vault.html)</small>



<!-- .slide: data-state="nologo-slide" style="text-align: center" -->
![Logo Ansible](images/logo-ansible.svg)
# Notions avancées


## Surcharge de variables

* Ansible permet la déclaration de variables en de multiples endroits.

* Ansible supporte la surcharge de variables, cette surcharge dépend de l’endroit où les variables sont déclarées.


Ordre de priorité croissant lors de la surcharge :

<small>

* role defaults
* inventory file or script group vars
* inventory group_vars/all
* playbook group_vars/all
* inventory group_vars/*
* playbook group_vars/*
* inventory file or script host vars
* inventory host_vars/*
* playbook host_vars/*
* host facts / cached set_facts
* play vars
* play vars_files
* role vars (defined in role/vars/main.yaml)
* task vars (only for the task)
* include_vars
* set_facts / registered vars
* role (and include_role) params
* include params
* extra vars (always win precedence)

</small>


## register + debug + verbosity
<!-- .slide: data-state="medium-code" -->

```yaml
- shell: /usr/bin/uptime
  register: result

- name: Display uptime
  debug:
    var: result
    verbosity: 2   # affiché à partir du niveau -vv

- name: Display all variables/facts known for a host
  debug:
    var: hostvars[inventory_hostname]
    verbosity: 4   # affiché à partir du niveau -vvvv
```


## Niveau de verbosité

```nohighlight
$ ansible-playbook -i ./hosts playbook.yaml
```

```nohighlight
$ ansible-playbook -vv -i ./hosts playbook.yaml
```

```nohighlight
$ ansible-playbook -vvvv -i ./hosts playbook.yaml
```


## Check mode (« Dry Run »)

* Simulation de l'exécution d'un Playbook.

* Aucun changement n'est effectué sur les hosts lors du check.

* Utiliser l’option `--check`.

* _Attention_ ! Certains modules sont incompatibles avec le Check mode.


Forcer ou non une tâche en check : `check_mode: yes/no`

<!-- .slide: data-state="small-code" -->
```yaml
tasks:
  - name: this task will make changes to the system even in check mode
    command: /something/to/run --even-in-check-mode
    check_mode: no

  - name: this task will always run under checkmode and not change the system
    lineinfile:
        line: "important config"
        dest: /path/to/myconfig.conf
        state: present
    check_mode: yes
```


## Autres options de ansible-playbook
<!-- .slide: data-state="medium-table" -->
Option | Description
- | -
`--list-hosts` | Affiche les machines concernées par le Play
`--list-tags` | Affiche les tags disponibles
`--list-tasks` | Affiche les tâches qui seront exécutées
`--step` | Demande confirmation avant l'exécution de chaque tâche
`--syntax-check` | Analyse syntaxique du Playbook (sans l'exécuter)


## Tester du code Ansible


![Logo Molecule](images/logo-molecule.png) <!-- .element: width="150px" -->

* Permet de tester des Roles Ansible

<small>https://molecule.readthedocs.io/en/latest/</small>


![Logo TestInfra](images/logo-testinfra.svg) <!-- .element: width="150px" -->

Création de tests unitaire en langage Python

<!-- .slide: data-state="small-table" -->
```python
def test_passwd_file(host):
    passwd = host.file("/etc/passwd")
    assert passwd.contains("root")
    assert passwd.user == "root"
    assert passwd.group == "root"
    assert passwd.mode == 0o644
```

Combiné avec GitLab-CI/Jenkins et Docker, il permet d'automatiser le test de code Ansible.

<small>https://testinfra.readthedocs.io/en/latest/</small>


## Ansible Lint

* Permet de détecter les comportements et les pratiques qui peuvent être améliorés.

<small>https://ansible-lint.readthedocs.io/en/latest/</small>


## Ansible en mode Pull

* Ansible fonctionne traditionnellement en mode `Push`.

* Il est possible de passer en mode `Pull` à l'aide de la commande `ansible-pull`.

* Intérêt du mode Pull

    - Adresser un grand nombre de machines,

    - Remediation des systèmes en continu.


* Pré-requis du mode Pull

    * Playbooks disponibles sur un dépôt git,

    * Ansible installé sur chaque machine cible.

<small>https://docs.ansible.com/ansible/latest/cli/ansible-pull.html</small>

<small>https://github.com/ansible/ansible-examples/blob/master/language_features/ansible_pull.yaml</small>


## Développer un module personnalisé

`./library/mymodule.py`
```python
#!/usr/bin/python

from ansible.module_utils.basic import *

def main():
    module = AnsibleModule(argument_spec={})
    response = {"hello": "world"}
    module.exit_json(changed=False, meta=response)
if __name__ == '__main__':
    main()
```

<small>https://blog.toast38coza.me/custom-ansible-module-hello-world/</small>

<small>https://docs.ansible.com/ansible/latest/dev_guide/developing_modules_general.html</small>


## Utiliser un module personnalisé
<!-- .slide: data-state="small-code" -->

`playbook-demo-mymodule.yaml`
```yaml
- hosts: web
  tasks:
  - name: Test that my module works
    mymodule:
    register: result
  - debug: var=result
```
```nohighlight
$ ansible-playbook -i ./hosts playbook-demo-mymodule.yaml
...
TASK [Test that my module works] ***********************************************
ok: [web2.formation.sii.fr]
ok: [web1.formation.sii.fr]

TASK [debug] *******************************************************************
ok: [web1.formation.sii.fr] => {
    "result": { "changed": false, "meta": { "hello": "world" } }
}
ok: [web2.formation.sii.fr] => {
    "result": { "changed": false, "meta": { "hello": "world" } }
}
...
```


## Ansible Tower

* Interface Web propriétaire pour le lancement de playbooks.

* Accès à l’historique des playbooks lancés et aux logs d'exécution.

* Gestion des utilisateurs et de l'inventaire.

* Pilotable via API.

<small>https://www.ansible.com/products/tower</small>


### Tableau de bord d'Ansible Tower
![Tower dashboard](images/tower-dashboard.png)


### AWX

* Version opensource de Ansible Tower (sous licence Apache 2.0.)

* AWX est à Ansible Tower ce que Fedora est à Red Hat Enterprise Linux.

* Non recommandé pour les environnements de production.

* Aucun support n'est fourni par Red Hat.

<small>https://www.ansible.com/products/awx-project</small>