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.
• Conseils CI/CD & IaC • Place d'Ansible • Approches IaC • Exemple avec Gitlab Développement de plugins • La minute nécessaire • Plugins Actions • Plugins Filter
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 [...]
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
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
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
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)
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…
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
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.
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).
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.
_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.
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
namespace.role_name was created successfully $ ansible-galaxy collection init \ namespace.collection_name - Collection namespace.collection_name was created successfully Ansible-galaxy à la rescousse.
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
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.
[] 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
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)
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
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
• 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
• 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.
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é
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
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
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
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
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
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
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
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.
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
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.