Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Ansible Ultimate Edition

WeScale
April 20, 2022

Ansible Ultimate Edition

Supports de l'université Devoxx 2022

WeScale

April 20, 2022
Tweet

More Decks by WeScale

Other Decks in Technology

Transcript

  1. #DevoxxFR WeScale est une société de service regroupant 50 passionnés,

    basés à Paris, Nantes et en agence Full Remote. Notre mission, c’est d’accompagner les entreprises à devenir Cloud Native. Nous avons l’ambition d’aider nos clients à Penser, Construire et Maîtriser leurs infrastructures et applications Cloud.
  2. 3 heures de bonheur intense Intro Concepts • Définitions •

    Terminologie • CLI Toolbox Syntaxe • Variables • Templating • Fil d'exécution Organisation de projet • Initialisation • Gestion de dépendances • Packaging
  3. 3 heures de bonheur intense Testing • Molecule • Verifiers

    • Conseils CI/CD & IaC • Place d'Ansible • Approches IaC • Exemple avec Gitlab Développement de plugins • La minute nécessaire • Plugins Actions • Plugins Filter
  4. 3 heures de bonheur intense SI Ansible-centré • AWX •

    ARA • Stratégies de déploiement Anatomie d'un projet • HashiStack Project • Intégration Terraform • Vault-Consul-Nomad Le mot de la fin
  5. Et la famille ? Imhotep ? • Ruby • Abstraction

    plus élevée • Avec agent • Bibliothèques plus fournies • Communauté de relecteurs
  6. Ça va, Imhotep. • Python • Avec agent • Salt-SSH

    • Fédération de master • Preprocessing YAML
  7. Inventaires Liste de machines avec lesquelles interagir, organisées en groupes.

    Un inventaire peut être statique ou dynamique. # hosts.ini est un fichier statique écrit ou généré :~$ ansible --inventory=hosts.ini [...] # dyn_inventory est un exécutable retournant du JSON sur la sortie standard :~$ ansible --inventory=dyn_inventory [...]
  8. Inventaire statique Écrit avec amour ou généré avec passion. web_1

    ansible_host=10.10.10.101 ansible_ssh_private_key_file=... web_2 ansible_host=10.10.10.102 ansible_ssh_private_key_file=... [web_servers] web_1 web_2 [databases] db_1 ansible_host=10.10.20.201 ansible_ssh_private_key_file=... 10.10.20.202 ansible_ssh_private_key_file=... [production:children] web_servers databases
  9. Inventaire dynamique Exécutable retournant du JSON sur la sortie standard.

    2 options à supporter pour être conforme. Branchez vos inventaires dynamiques sur des plateformes connaissant les machines (AWS, OpenStack, Cobbler, Consul, …). :~$ ./dyn_inventory --list { "databases" : { "hosts" : [ "db_1", "10.10.20.202" ] }, "web_servers" : [ "web_1", "web_2" ], "production" : { "children": [ "web_servers", "databases" ] } } :~$ ./dyn_inventory --host web_1 { "ansible_host": "10.10.10.101" }
  10. Tasks Plus petite unité d'action disponible. A l'exécution peut être

    : • changed • ok • failed --- - name: un joli titre c’est mieux apt: pkg: "tmux" state: present
  11. Playbook Liste de Play. Un play étant une liste de

    rôles et/ou de tâches à appliquer sur un groupe de machines. --- - name: SSH restart hosts: web_servers become: yes tasks: - service: name: sshd state: restarted - name: Nginx install hosts: web_servers become: yes tasks: - apt: name: nginx state: present - service: name: nginx enable: yes state: restarted
  12. Handler Task lancée en fin de play si notifiée par

    une autre task. Un handler notifié plusieurs fois ne sera exécuté qu’une fois. --- - hosts: webservers tasks: - template: [...] notify: restart my service handlers: - name: restart my service service: name: my_service state: restarted
  13. Rôle Unité de réutilisation de code Ansible. Peut contenir :

    • des tasks • des handlers • des templates • des fichiers statiques • des variables role/ ├── defaults │ └── main.yml --> variables par défaut ├── files --> fichiers statiques ├── handlers │ └── main.yml --> handlers ├── meta │ └── main.yml --> fiche d'info et dépendances ├── tasks │ └── main.yml --> tâches (appels de modules) ├── templates --> templates Jinja2 ├── tests │ ├── inventory │ └── test.yml └── vars └── main.yml --> variables fortes
  14. Collection Unité de réutilisation de code Ansible. Peut contenir :

    • des rôles • des playbooks • des plugins collection/ ├── docs/ ├── galaxy.yml ├── meta/ │ └── runtime.yml ├── plugins/ │ ├── modules/ │ │ └── module1.py │ ├── inventory/ │ └── .../ ├── README.md ├── roles/ │ ├── role1/ │ ├── role2/ │ └── .../ ├── playbooks/ │ ├── files/ │ ├── vars/ │ ├── templates/ │ └── tasks/ └── tests/
  15. ansible Lancement unitaire d’un module sur un ensemble de machines,

    sans playbook. :~$ ansible --inventory=hosts.ini -m service -a "name=ntp state=restarted" all
  16. ansible-pull Clone un repository git et exécute le playbook.yml ou

    local.yml se trouvant à la racine. :~$ ansible-pull -U [email protected]:me/myrepo.git
  17. ansible-galaxy Installe un ou plusieurs rôles et/ou collections depuis des

    sources distantes. Génère le squelette d'un nouveau rôle ou d’une collection Publie rôle et collection vers un repository Galaxy. :~$ ansible-galaxy role install bennojoy.nginx :~$ ansible-galaxy collection install -fr requirements.yml :~$ ansible-galaxy role init mon_role_amoi
  18. requirements.yml Fichier de requirements pour ansible-galaxy --- # requirements.yml -

    src: yatesr.timezone - src: https://github.com/bennojoy/nginx - src: https://github.com/bennojoy/nginx version: master name: nginx-role - src: https://example.com/files/master.tar.gz name: http-role
  19. ansible-doc Obtenir la documentation d’un module en ligne de commande.

    # liste de tous les modules disponibles :~$ ansible-doc --list # documentation d’un module :~$ ansible-doc $module
  20. ansible-vault Chiffre/déchiffre des fichiers de variables Un fichier de variable

    chiffré peut être utilisé par un playbook : • par prompt si l'option --ask-vault-pass est passée • de façon transparente si la variable d'env ANSIBLE_VAULT_PASSWORD_FILE est définie :~$ ansible-vault [create|decrypt|edit|encrypt|rekey|view] vaultfile.yml
  21. Précédence des variables Une variable peut être définie à différents

    endroits. Si elle est définie plusieurs fois au même niveau, ça lève un Warning et seule la dernière définition est prise en compte. 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_prompt play vars_files role vars (defined in role/vars/main.yml) block vars (only for tasks in block) task vars (only for the task) include_vars set_facts / registered vars role (and include_role) params * include params extra vars (always win precedence)
  22. 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_prompt play vars_files role vars (defined in role/vars/main.yml) block vars (only for tasks in block) task vars (only for the task) include_vars set_facts / registered vars role (and include_role) params * include params extra vars (always win precedence) Précédence des variables Plus on s'étale, plus le troubleshooting se complexifie…
  23. Norme de nommage Le nom d’une variable doit : •

    commencer par une lettre • contenir uniquement lettres, chiffres et underscores
  24. Convention pour les variables de rôles defaults/main.yml : configuration du

    rôle • rolename_* set_fact : valeurs de sortie • rolename_fact_* vars/main.yml : variables interne • __rolename_*
  25. Facts Le module setup, lancé par défaut au démarrage de

    chaque playbook, collecte des ansible_facts sur le host : • ansible_processor_cores : Nombre de coeurs • ansible_memtotal_mb : Mémoire • ansible_interfaces : Interfaces réseaux • ansible_distribution : Distribution • ansible_architecture : Architecture $ ansible -m setup localhost
  26. Custom Facts Vous pouvez créer des fichiers dans /etc/ansible/facts.d/*.fact pour

    créer des facts collectés par le module setup. Ces fichiers doivent contenir du JSON, du INI ou être exécutable et retourner du JSON. Ces facts seront rangés dans la variable ansible_local. /etc/ansible/facts.d/mes_miens.fact ==> contenus dans la variable ansible_local.mes_miens
  27. Interpolation - name: Common private ssl directory exist file: path:

    "{{ vault_tls_dir }}" owner: root group: ssl-cert state: directory mode: 0750 - name: Upload CA certificate copy: src: "{{ vault_local_ca_cert }}" dest: "{{ vault_ca_certificate }}" owner: root group: ssl-cert mode: 0644 notify: Update ca trust when: vault_use_custom_ca
  28. {% for partner_peer in vault_master_partners %} # Peer index in

    list is {{ loop.index0 }} retry_join { leader_api_addr = "{{ vault_api_protocol }}://{{ partner_peer }}:{{ vault_api_port }}" {% if vault_use_custom_ca %} # Truth must be said leader_ca_cert_file = "{{ vault_ca_certificate }}" {% endif %} leader_client_key_file = "{{ vault_self_private_key }}" leader_client_cert_file = "{{ vault_self_certificate }}" } {% endfor %} {% raw %} # Fin de boucle {% for partner_peer in vault_master_partners %} {% endraw %}
  29. Filters "{{ input_var | from_json }}" "{{ input_var | to_json

    }}" "{{ input_var | to_nice_json(indent=2) }}" "{{ input_var | from_yaml }}" "{{ input_var | to_yaml }}" "{{ input_var | to_nice_yaml(indent=2) }}" "{{ username | default('admin') }}" Ansible propose un système de transformateurs pipables nommés filters. Les filters sont utilisables partout où une interpolation est faite.
  30. default - name: touch files with an optional mode file:

    dest: "{{ item.path | default('/tmp/void.tmp')}}" state: touch mode: "{{ item.mode | default(omit) }}" loop: - path: /tmp/foo - mode: "0444" - path: /tmp/baz mode: "0444" Permet de gérer les cas où une variable utilisée n'est pas définie. La valeur spéciale omit invalide le set de l'attribut.
  31. Listes "{{ list1 | unique }}" "{{ list1 | union(list2)

    }}" "{{ list1 | intersect(list2) }}" "{{ list1 | difference(list2) }}" "{{ list1 | symmetric_difference(list2) }}" Filtres de manipulation de listes de valeurs.
  32. Point d'entrée Une exécution Ansible commence par un playbook Ansible.

    Seront exécutés (dans cet ordre) : • pre_tasks • roles • tasks • post_tasks • (handlers)
  33. Condition d'exécution tasks: - name: Shut down CentOS 6 systems

    ansible.builtin.command: /sbin/shutdown -t now when: - ansible_distribution == "CentOS" - ansible_distribution_major_version == "6" Chaque appel de module peut être conditionné à une évaluation booléenne avec un attribut when. Si on fourni une liste à when, tous les éléments sont liés par un ET logique. Un when est systématiquement considéré comme une interpolation (pas de moustache).
  34. Imports & Includes import_playbook – Importe un playbook import_role –

    Importe un role dans un play import_tasks – Importe un fichier de tasks include – Inclut un play / fichier de tasks include_role – Charge et exécute un role include_tasks – Charge un fichier de tasks include_vars – Charge les variables d'un fichier Les import_* sont évalués statiquement au chargement du plan d'exécution du playbook. Les include_* sont évalués en cours d'exécution et peuvent être soumis à des conditions when, des boucles, etc.
  35. Loops - name: add several users user: name: "{{ item

    }}" state: present groups: "wheel" loop: - testuser1 - testuser2 - name: add several users user: name: "{{ item }}" state: present groups: "wheel" loop: "{{ user_list }}" Un appel de module peut être bouclé par l'ajout d'un attribut loop.
  36. Better Loops - name: add several users user: name: "{{

    _current_user }}" state: present groups: "wheel" loop: - testuser1 - testuser2 loop_control: loop_var: _current_user Pour éviter les collisions de nommage et les effets de bords associés, prenez l'habitude de nommer votre variable de boucle.
  37. Dict Loops - name: add several users user: name: "{{

    _current_user.name }}" state: present groups: "{{ _current_user.groups }}" loop: - name: "testuser1" groups: "wheel" - name: "testuser2" groups: "root" loop_control: loop_var: _current_user Bouclage sur des liste de dict.
  38. Nested Loops vars: list_one: - "a" - "b" list_two: -

    "1" - "2" tasks: - name: with_nested -> loop debug: msg: "{{ _tuple.0 }} - {{ _tuple.1 }}" loop: "{{ list_one|product(list_two)|list }}" loop_control: loop_var: _tuple Le filtre product permet de construire des boucles imbriquées. Cet exemple donnera les messages de debug successifs : "a - 1" "a - 2" "b - 1" "b - 2"
  39. Playbook ? Rôle ? Collection ? Il n'y a que

    2 cas : • soit vous développez un rôle qui sera une dépendance plusieurs projets • soit vous développez une collection Rôle consommé uniquement par une même collection ? => dans la collection
  40. Init de projet $ ansible-galaxy role init namespace.role_name - Role

    namespace.role_name was created successfully $ ansible-galaxy collection init \ namespace.collection_name - Collection namespace.collection_name was created successfully Ansible-galaxy à la rescousse.
  41. Ayez un Virtualenv dédié Une dépendance mal considérée : •

    Ansible lui-même Un virtualenv dédié vous permet d'installer des versions fixes sans perturber vos autres projets.
  42. Retour de terrain Gérez vos virtualenv avec direnv, c'est ok,

    et ça peut rendre d'autres services (gros teasing).
  43. Automatisez votre environnement de Dev • Le démarrage doit demander

    un minimum de prérequis. • Les prérequis doivent être simples à installer et documentés. • Le projet doit contenir l'automatisation pour rapatrier ses dépendances. • Faites en une convention. ◦ git clone ◦ direnv allow ◦ make env
  44. Release privée # EMITTER $ git tag vX.Y.Z $ git

    push --tags # CONSUMER - requirements.yml - src: [email protected]:mygroup/ansible-role.git scm: git version: "v0.1.2" Tirez vos dépendances directement depuis git.
  45. Release publique $ ansible-galaxy collection build $ ansible-galaxy collection publish

    ns-name-version.tar.gz Upload d'archive pour les collections. Réglages du compte Galaxy pour les rôles, directement branché sur les tags. ansible-galaxy travaille sur le répertoire courant.
  46. Automatiser le processus playbook: build/release_collection.yml play #1 (localhost): localhost TAGS:

    [] tasks: Ensure the ANSIBLE_GALAXY_TOKEN environment variable is set. Ensure $HOME/.ansible directory exists Write the galaxy token to $HOME/.ansible/galaxy_token Delete old clone Clone project at desired gitref Render galaxy.yml Build the collection Publish the collection
  47. Molecule • Framework de test pour les rôles et playbooks

    Ansible • Permet de tester : ◦ plusieurs instances en parallèle ◦ plusieurs OS ◦ différents scénarios • Supporte 2 versions majeures d'Ansible (N et N-1)
  48. Terminologie • driver (provider) ◦ gestionnaire du cycle de vie

    des hosts de test • scenario ◦ un test fonctionnel • verifier ◦ un outil pour valider le bon fonctionnement
  49. Cycle complet • lint ◦ Analyse statique du code •

    destroy ◦ Destruction des éventuels environnements de tests encore existants • dependency ◦ Rapatriement des dépendances nécessaires listées dans le fichier meta.yml • syntax ◦ Validation de syntaxe avec Ansible • create ◦ Création de l'environnement de test du scénario • prepare ◦ Playbook de préparation de l'environnement de test
  50. Cycle complet • converge ◦ Application du rôle testé, doit

    s'exécuter sans erreur • idempotence ◦ Seconde application du rôle testé, qui ne doit générer aucune task en état changed • side_effect ◦ Partie obscure du framework, cette phase doit permettre d'introduire des effets de bord à l'environnement (modification contextuelle au rôle, simulation de pannes) • verify ◦ Exécution du code de test • destroy ◦ Destruction des environnements de test
  51. Dans la vraie vie • molecule create • code code

    code • molecule verify • repeat jusqu'à ce que … • molecule destroy • molecule test
  52. Drivers • Core ◦ Delegated (aka DIY) • Plugins ◦

    Docker ◦ Podman ◦ Azure ◦ EC2 ◦ GCE ◦ Openstack ◦ Vagrant ◦ LXD ◦ libvirt ◦ …
  53. Ansible Verifier • verifier par défaut • un playbook verify.yml

    qui s'exécute sans erreur == OK Avantages • Simplicité Inconvénients • Complexe de tester sans impacter • Temps d'exécution
  54. TestInfra Verifier • plugin pytest • Script Python de validation

    Avantages • Maturité • Pur Python Inconvénients • Changement de paradigme
  55. Goss Verifier • Plugin binaire Go • Description de l'état

    attendu en YAML Avantages • Pur déclaratif • Exécution rapide Inconvénients • YAML?
  56. Goss : juste ce qu'il faut • addr • command

    • dns • file • gossfile • group • http • interface • kernel-param • mount • matching • package • port • process • service • user addr: tcp://ip-address-or-domain-name:80: reachable: true timeout: 500 # optional attributes local-address: 127.0.0.1
  57. Goss : juste ce qu'il faut • addr • command

    • dns • file • gossfile • group • http • interface • kernel-param • mount • matching • package • port • process • service • user command: version: # required attributes exit-status: 0 # defaults to hash key exec: >- go version # optional attributes stdout: - go version go1.6 linux/amd64 stderr: [] timeout: 10000 # in milliseconds skip: false
  58. Goss : juste ce qu'il faut • addr • command

    • dns • file • gossfile • group • http • interface • kernel-param • mount • matching • package • port • process • service • user file: /etc/passwd: exists: true mode: "0644" size: 2118 owner: root group: root filetype: file contains: [] md5: ... sha256: ... sha512: ... /etc/alternatives/mta: exists: true filetype: symlink linked-to: /usr/sbin/sendmail.sendmail skip: false
  59. Goss : juste ce qu'il faut • addr • command

    • dns • file • gossfile • group • http • interface • kernel-param • mount • matching • package • port • process • service • user http: https://www.google.com: # required attributes status: 200 # optional attributes method: PUT # http method allow-insecure: false # Setting this to true will NOT follow redirects no-follow-redirects: false timeout: 1000 request-headers: # Set request header values - "Content-Type: text/html" # Check http response headers for these patterns headers: [] request-body: '{"key": "value"}' # request body body: [] # Check http response content for these patterns username: "" # username for basic auth password: "" # password for basic auth proxy: "" skip: false
  60. Goss : juste ce qu'il faut • addr • command

    • dns • file • gossfile • group • http • interface • kernel-param • mount • matching • package • port • process • service • user package: httpd: # required attributes installed: true # optional attributes versions: - 2.2.15 skip: false
  61. Goss : juste ce qu'il faut • addr • command

    • dns • file • gossfile • group • http • interface • kernel-param • mount • matching • package • port • process • service • user service: sshd: # required attributes enabled: true running: true skip: false # NOTE: status checked from systemd/upstart/init.
  62. Pour le Dev Cas • Tests locaux • Validation des

    développements • Exécution manuelles plusieurs fois par jour Conseils • Driver Docker • Verifier Goss • Architecture minimale • Objectif de performance
  63. Pour tous les jours Cas • Tests de pipeline •

    Validation pré-release • Exécution quotidienne Conseils • Driver Delegated Terraform • Verifier Goss • Architecture proche de la cible de déploiement • Objectif de pertinence
  64. Utilité d'Ansible dans un chaîne de CI/CD • Beaucoup plus

    en CD qu'en CI • Langage de scripting de premier plan • Orchestrer les déploiements complexes • Combler les manques de certains outils Infra-as-Code
  65. Infrastructure as Code axée Ansible • Ansible doit être le

    point d'entrée d'exécution de vos procédure • Les variables Ansible sont le référentiel de travail • Ansible est chargé des pré et post actions • Tous les autres outils sont nourris et pilotés par Ansible • N'utilisez PAS les modules Infra-as-Code d'Ansible pour la beauté de l'exercice • Utilisez le meilleur outil pour l'usage considéré
  66. Infrastructure as Code axée Ansible playbook pre_tasks tasks IaC avec

    des variables Ansible post_tasks • Activation de page de maintenance • Drain de flux réseau • Rétablissement des flux réseau • Désactivation de page de maintenance
  67. Infrastructure as Code renforcée par Ansible terraform apply null_resource •

    local-exec construction d'inventaire • local-exec construction de fichier de variables • local-exec ansible-playbook
  68. Immutable Infrastructure • Packer est un outil de Hashicorp qui

    permet de construire des images système de machine virtuelles, physique, Docker. • Les Builders gèrent le cycle de vie du host et la prise d'instantané • Les provisionners… provisionnent • 2 provisionners Ansible sont disponibles : ◦ ansible : processus ansible lancé à côté de Packer ◦ ansible-local : processus ansible lancé sur la machine distante
  69. CICD Cas • Déploiement et gestion de configuration continus •

    Validation pré-release et tests • Gestion multi environnements • Exécution automatique Conseils • Avoir son image Docker avec Ansible dedans • Définir votre propre GitFlow • Cadrez Packer finement (VPC, cleanup, etc)
  70. Alpine FROM alpine:latest MAINTAINER <[email protected]> RUN apk --no-cache update &&

    apk --no-cache upgrade RUN apk --no-cache add \ python3 py3-pip py3-setuptools py3-wheel RUN apk --no-cache add --virtual \ ansible-build-dependencies python3-dev \ libffi-dev openssl-dev gcc musl-dev && \ pip install --no-cache-dir -U \ pip setuptools wheel && \ pip install --no-cache-dir ansible-core && \ apk del ansible-build-dependencies ENV ANSIBLE_HOST_KEY_CHECKING False ENTRYPOINT ["/bin/sh"] Alpine Linux a tout ce qu'il faut pour une bonne image de worker Ansible.
  71. Généralités • Préparez vos runners ! • Organisez votre bibliothèque

    de rôles • Organisez votre inventaire commun (si statique) • Organisez vos secrets (clé SSH, variable d’env, etc.) • GitlabFlow/GitFlow
  72. gitlab-ci.yml stages: - build - release - deploy # Template

    build .build: &build image: docker:stable stage: build services: - docker:dind before_script: - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY script: - docker build -t "$CI_REGISTRY_IMAGE:latest" . - docker push "$CI_REGISTRY_IMAGE:latest" - echo Successfully push to registry ! only: - branches La description de la pipeline Stages : Les étapes de la pipeline. Le job de build pour construire l’image Docker de l’application.
  73. gitlab-ci.yml .deploy: &deploy image: "$CI_REGISTRY_IMAGE:latest" stage: deploy variables: FLASK_APP: hello

    FLASK_ENV: development script: - flask run & - ansible-playbook playbooks/ci-quickstart.yml - echo "Successfully deployed !" Le job de déploiement
  74. • Votre script Python préféré, qui vous facilite la vie

    au quotidien • Une enveloppe de moins de 25 lignes de code • L'effort d'adopter une méthode de développement documentée Les termes du troc : Vous apportez
  75. • Un moteur de parallélisation • Un moteur de templating

    • La possibilité d'orchestrer l'exécution de votre script à travers tout le SI • Un cadre de travail pérenne Les termes du troc : Vous obtenez
  76. Ansible est une grosse multiprise à plugin • Action :

    Enveloppe d'exécution d'un module • Cache : Collecter des variables • Callback : Réagir à des évènements • Connection : Initier une connexion à une cible • Filter : Traiter de données en mode pipe • Inventory : Renseigner l'inventaire • Lookup : Collecter des la données sur une source autre que la cible • Test : Valider format ou valeur de données • Vars : Injecter des variables dans le registre runtime de Ansible https://docs.ansible.com/ansible/latest/dev_guide/developing_plugins.html
  77. • Intégration avec un SI existant et complexe • Dialogue

    et interactions entre Ansible et moult API ◦ CMDB ◦ Supervision ◦ Réseau ◦ Stockage ◦ ITSM Développement de plugin dans la vraie vie
  78. • être codé en Python • lever des erreurs "proprement"

    • renvoyer des strings unicode • se conformer aux standards Ansible de configuration et de documentation Un plugin DOIT
  79. # # pour que Ansible retrouve vos modules de collection

    # export ANSIBLE_LIBRARY="${PWD}/plugins/modules:${ANSIBLE_LIBRARY}" # # Pour que Ansible retrouve vos filtres de collection # export ANSIBLE_FILTER_PLUGINS="${PWD}/plugins/filter_plugins:${ANSIBLE_FILTER_PLUGINS}" # Ansible Config # .envrc
  80. • Moteur de lancement de playbook • WebUI • Gestion

    des utilisateurs et permissions • Console d'administration AWX
  81. AWX

  82. ARA (ARA Records Ansible) • Besoin de traçabilité de toute

    action sur le périmètre • Historique des plays • Drilldown à la task • WebUI & CLI
  83. L'éternel dilemme • Ranger au coffre ! • Oui mais

    qui a les clés du coffre ? • Donner les droits sur le coffre-fort est … problématique • Réduire le périmètre de diffusion • Faire des rotations régulières
  84. ansible-vault • Permet de chiffrer des fichiers de variables •

    Pour ranger du multi-line dans une variable Ansible : ◦ stored_multi: "{{ multi | base64encode }}" ◦ {{ stored_multi | base64decode }} • Le password peut être injecté : ◦ en prompt ◦ via une indirection avec un fichier dans lequel le password est en clair
  85. ansible-vault • Réduction du problème à un secret unique •

    Au bout de la chaîne, gérer les secrets retombe sur des cérémonies et des humains • Tant que le temps de rotation est plus rapide que le temps de cassage du chiffrement, on est bien. • ansible-vault rekey permet de déchiffrer et rechiffrer en automatique sans écrire en clair sur le disque
  86. Jamais d'accès à la clé maîtresse Admin Rotation automatique via

    AWX Cron L1 L2 L3 Accès possible uniquement durant une intervention.
  87. Problème repoussé • Notre zone sensible/de fragilité est réduite au

    seul serveur AWX… • Possibilité de pousser la clé dans un cluster Vault pour backup. ◦ Spoiler : il faudra gérer les secrets pour la gestion du cluster • Pensez à conserver une procédure "bris de glace" avec accès à un secret.
  88. Le but Worker Ingress gateway Ingress gateway config entry Connect

    Service Connect Service mTLS mTLS mTLS exécute TCP HTTP déploie configure exécute exécute
  89. Chorégraphie • Let's Encrypt • DNS Challenge • Wildcard •

    Distribution Infra OS DNS • VM • Réseau • Security groups • Update • Prérequis • DNS resolver local • Délégation de sous-domaine • Masters • Minions core Certificats
  90. Chorégraphie Install Policies • Packages officiels • Intégration des certificats

    • Récupération du root token • Moindre privilège • Consul token • Nomad token Vault Auto Unseal
  91. Chorégraphie Install Policies • Package officiels • Intégration des certificats

    • Service Mesh • Vault en CA • Nomad token Configure Consul
  92. Chorégraphie Install Policies • Package officiels • Intégration des certificats

    • Intégration du token Consul • À venir Configure Nomad
  93. Le centre de gravité DevSecOps • Ansible peut être le

    point de rendez-vous des équipes Dev, Sec et Ops. • Les Ops savent quoi faire avec les systèmes et comment le faire bien. • Les Dev savent comment optimiser du code en restant iso-fonctionnel pour exploiter un moteur. • Les Sec surveillent, analysent, et viennent ajouter leur expertise au mix.