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

Ansible Ultimate Edition

78605f82de8b2ea497603533d022f1e0?s=47 WeScale
April 20, 2022

Ansible Ultimate Edition

Supports de l'université Devoxx 2022

78605f82de8b2ea497603533d022f1e0?s=128

WeScale

April 20, 2022
Tweet

More Decks by WeScale

Other Decks in Technology

Transcript

  1. #DevoxxFR Ansible Ultimate Edition Université Devoxx 2022 Aurélien MAURY Gautier

    LOTERMAN 1
  2. None
  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.
  103. None
  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
  132. None
  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
  165. None
  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 !