Ansible Ultimate Edition

Supports de l'université Devoxx 2022

Transcript

1. #DevoxxFR Ansible Ultimate Edition Université Devoxx 2022 Aurélien MAURY Gautier LOTERMAN 1
3. #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.
4. NOS PARTENARIATS 2015 +50 Création de WeScale Passionné(e)s de Cloud PARIS NANTES FULL REMOTE ON RECRUTE
5. Aurélien MAURY Gautier LOTERMAN
6. 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
7. 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
8. 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
9. Ça… c'était le plan…
10. Le format
11. Prouver par l'exemple
12. À voir et à revoir en famille https://ansible-ultimate-edition.rtfd.io
13. Techniques validées sur le terrain
14. Mode d'emploi
15. Concepts Parés ?
16. Concepts
17. Définition Concepts
18. Orchestrateur
19. Ingrédients Jinja
20. Provisioning
21. Connectivité
22. Sans agent
23. Idempotence
24. User Space
25. Et la famille ? Imhotep ? • Ruby • Abstraction plus élevée • Avec agent • Bibliothèques plus fournies • Communauté de relecteurs
26. Ça va, Imhotep. • Python • Avec agent • Salt-SSH • Fédération de master • Preprocessing YAML
27. Et là, normalement vous vous dites…
28. C'est décidé on adopte.
29. Terminologie Concepts
30. 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 [...]
31. 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
32. 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" }
33. 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
34. 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
35. 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
36. 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
37. 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/
38. Un playbook sauvage apparaît
39. CLI Toolbox Concepts
40. 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
41. ansible-playbook Lancement d’un playbook. :~$ ansible-playbook --inventory=hosts.ini mon_playbook.yml
42. ansible-pull Clone un repository git et exécute le playbook.yml ou local.yml se trouvant à la racine. :~$ ansible-pull -U git@github.com:me/myrepo.git
43. 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
44. 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
45. 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
46. 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
47. Syntaxe
48. Variables Syntaxe
49. 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)
50. 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…
51. Norme de nommage Le nom d’une variable doit : • commencer par une lettre • contenir uniquement lettres, chiffres et underscores
52. 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_*
53. Variables magiques • inventory_dir • group_names • groups • hostvars • playbook_dir • role_path
54. 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
55. 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
56. Templating Syntaxe
57. 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
58. {% 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 %}
59. 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.
60. 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.
61. Listes "{{ list1 | unique }}" "{{ list1 | union(list2) }}" "{{ list1 | intersect(list2) }}" "{{ list1 | difference(list2) }}" "{{ list1 | symmetric_difference(list2) }}" Filtres de manipulation de listes de valeurs.
62. Jinja Filters
63. Fil d'exécution Syntaxe
64. 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)
65. 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).
66. 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.
67. 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.
68. 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.
69. 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.
70. 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"
71. Organisation de projet
72. Initialisation Organisation de projet
73. 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
74. 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.
75. Les choses sérieuses commencent.
76. Gestion de dépendances Organisation de projet
77. 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.
78. Retour de terrain Gérez vos virtualenv avec direnv, c'est ok, et ça peut rendre d'autres services (gros teasing).
79. 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
80. Aucun projet n'est un île.
81. Packaging Organisation de projet
82. Release privée # EMITTER $ git tag vX.Y.Z $ git push --tags # CONSUMER - requirements.yml - src: git@gitlab.company.com:mygroup/ansible-role.git scm: git version: "v0.1.2" Tirez vos dépendances directement depuis git.
83. 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.
84. 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
85. Testing
86. Molecule Testing
87. 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)
88. Terminologie • driver (provider) ◦ gestionnaire du cycle de vie des hosts de test • scenario ◦ un test fonctionnel • verifier ◦ un outil pour valider le bon fonctionnement
89. 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
90. 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
91. Dans la vraie vie • molecule create • code code code • molecule verify • repeat jusqu'à ce que … • molecule destroy • molecule test
92. Drivers • Core ◦ Delegated (aka DIY) • Plugins ◦ Docker ◦ Podman ◦ Azure ◦ EC2 ◦ GCE ◦ Openstack ◦ Vagrant ◦ LXD ◦ libvirt ◦ …
93. Verifiers Testing
94. 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
95. TestInfra Verifier • plugin pytest • Script Python de validation Avantages • Maturité • Pur Python Inconvénients • Changement de paradigme
96. Goss Verifier • Plugin binaire Go • Description de l'état attendu en YAML Avantages • Pur déclaratif • Exécution rapide Inconvénients • YAML?
97. 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
98. 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
99. 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
100. 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
101. 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
102. 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.
104. Stratégie Testing
105. 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
106. 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
107. CI/CD & IaC
108. 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
109. Infra-as-Code CI/CD
110. 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é
111. 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
112. 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
113. 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
114. Une usine d'AMI full-AWS
115. 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)
116. Gitlab CI/CD
117. Builder le buildeur ansible-worker https://docs.gitlab.com/ee/ci/docker/using_kaniko.html docker push docker build
118. Alpine FROM alpine:latest MAINTAINER <oss@wescale.fr> 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.
119. 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
120. 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.
121. 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
122. gitlab-ci.yml # STAGES build: <<: *build deploy: <<: *deploy only: - tags Les déclenchements
123. Extension
124. La minute nécessaire Extension
125. • 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
126. • 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
127. 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
128. • 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
129. • ê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
130. Module & Filter plugins Extension
131. # # 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
133. SI Ansible-centré
134. Boîte à outil
135. AWX SI Ansible-centré
136. • Moteur de lancement de playbook • WebUI • Gestion des utilisateurs et permissions • Console d'administration AWX
137. AWX
138. Panorama DMZ Private Zone
139. Admin DMZ Private Zone Sas d'administration
140. Admin DMZ Private Zone Ops Teams L1 L2 L3
141. Admin DMZ Private Zone Contribution L1 L2 L3
142. Admin DMZ Private Zone Opérations courantes L1 L2 L3
143. Admin DMZ Private Zone Escalade L1 L2 L3
144. Admin DMZ Private Zone Escalade L1 L2 L3
145. ARA SI Ansible-centré
146. ARA (ARA Records Ansible) • Besoin de traçabilité de toute action sur le périmètre • Historique des plays • Drilldown à la task • WebUI & CLI
147. ARA enregistre vos playbook
148. Admin DMZ Private Zone Intervention L1 L2 L3
149. Gestion des secrets SI Ansible-centré
150. 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
151. 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
152. 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
153. Admin DMZ Private Zone Secrets L1 L2 L3
154. Jamais d'accès à la clé maîtresse Admin Rotation automatique via AWX Cron L1 L2 L3 Accès possible uniquement durant une intervention.
155. 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.
156. Anatomie d'un projet
157. The HashiStack Project Anatomie d'un projet
158. Le but
159. 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
160. Chorégraphie core vault consul nomad
161. 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
162. 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
163. Chorégraphie Install Policies • Package officiels • Intégration des certificats • Service Mesh • Vault en CA • Nomad token Configure Consul
164. Chorégraphie Install Policies • Package officiels • Intégration des certificats • Intégration du token Consul • À venir Configure Nomad
166. Intégration Terraform Anatomie d'un projet
167. Vault-Consul-Nomad Anatomie d'un projet
168. Concepts Le mot de la fin
169. • Culture • Automation • Lean • Measurement • Sharing Le centre de gravité DevSecOps
170. 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.
171. #DevoxxFR Merci à tous ! Rejoignez le mouvement !