Resources attached to the Road To DevOps tutorial https://blog.noobtoroot.xyz/road-to-devops/

7.3 KiB

Raw Blame History

ansible-vault

Sécuriser les données sensibles.

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

$ ansible-vault create test.yaml
Vault password:

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

Le contenu en clair :

mon_super_mot_de_passe: 12345678

devient après chiffrement :

$ 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 :

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

Travaux pratiques

TP Ansible vault

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 :

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)

register + debug + verbosity

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

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

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

$ 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

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

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

Permet de tester des Roles Ansible

https://molecule.readthedocs.io/en/latest/

Création de tests unitaire en langage 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.

https://testinfra.readthedocs.io/en/latest/

Ansible Lint

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

https://ansible-lint.readthedocs.io/en/latest/

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.

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

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

Développer un module personnalisé

./library/mymodule.py

#!/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()

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

https://docs.ansible.com/ansible/latest/dev_guide/developing_modules_general.html

Utiliser un module personnalisé

playbook-demo-mymodule.yaml

- hosts: web
  tasks:
  - name: Test that my module works
    mymodule:
    register: result
  - debug: var=result

$ 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.

https://www.ansible.com/products/tower

Tableau de bord d'Ansible Tower

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.

https://www.ansible.com/products/awx-project

7.3 KiB Raw Blame History