Ansible pull

Sep 2, 2025 - Last update: Sep 1, 2025

Pull ?

Ansible est un outil de configuration en mode « push », et donc par définition se connecte aux machines pour effectuer des actions.

Il n’a pas vocation initiale à être joué de façon régulières pour effectuer ce que l’on va qualifier de gestion de conformité.

Ansible Pull permet de mettre en place ce fonctionnement tout en restant dans un environnement connu et maitrisé.
À contrario d’Ansible, il est orienté exécution locale. Bien sur celà reste possible d’aller plus loin, mais dans le cas présent, on va discuter conformité sur la machine locale.

Rappel sur les notions de conformité

La gestion de la conformité de configuration est un mode de gestion où l’on vérifie à intervales réguliers que ce qui a été défini est bien appliqué.

Celà permet d’éviter des glissements (drifts) de configuration entre l’état initial et l’état courant.

Fonctionnement

Le modèle Ansible Pull est basé sur la récupération de matériel Ansible depuis un dépot Git, et le rejeu du playbook définit lors de l’exécution de la commande.

Concrètement, il va aller interroger à intervales réguliers un dépot Git qui contient les configurations que vous souhaitez garder sous contrôle de conformité, et exécuter Ansible sur la machine locale pour valider ou réappliquer les configurations si nécessaire.

Préparation des machines

Les machines qui devront exécuter ansible-pull doivent avoir le paquet ansible-core d’installé sur le système.

Autant dans le cas d’un contrôleur Ansible, il est conseillé d’installer Ansible dans un virtualenv Python pour pouvoir récupérer les dernières versions, mais dans le cas d’Ansible Pull, je vous conseille d’utiliser les paquets système afin de ne pas avoir à gérer la création du virtualenv.

Dépot Git

Le dépot Git qui contiendra votre configuration utilisable par Ansible Pull à un modèle assez classique :

Directoryinventories/
- inventory.yaml
Directoryplaybooks/
- playbook.yaml
- requirements.yaml
Directoryroles/
- …
ansible.cfg

On va retrouver les dossiers :

inventories : Dossier qui contiendra votre/vos inventaires Ansible
playbooks : Dossier qui contiendra votre/vos playbooks Ansible
roles : Dossier qui contiendra vos roles Ansible qui seront utilisé hors collections
ansible.cfg : Fichier de configuration Ansible

Contenu des différents fichiers

all:
  hosts:
    localhost:
      ansible_connection: local

---
- name: 'Perform'
  hosts:
    - localhost
  vars:
    timer_sync_interval: '*:0/10:00' # Every 10 minutes
  handlers:
  - name: 'Enable ansible-pull.timer'
    become: true
    ansible.builtin.systemd:
      name: 'ansible-pull.timer'
      enabled: true
      daemon_reload: true
      state: restarted

  pre_tasks:
    - name: 'Deploy Ansible pull systemd unit'
      become: true
      ansible.builtin.copy:
        dest: '/etc/systemd/system/ansible-pull.service'
        content: |
          [Unit]
          Description=Runs ansible-pull to get common server configuration
          Wants=ansible-pull.timer

          [Service]
          Type=oneshot
          ExecStart=/usr/bin/ansible-pull --accept-host-key -U https://<votre_forge>/<path_of>/<ansible_repository>.git playbooks/playbook.yaml

          [Install]
          WantedBy=multi-user.target
          owner: 'root'
          group: 'root'
          seuser: system_u
          serole: object_r
          setype: systemd_unit_file_t
          selevel: s0

    - name: 'Configure systemd timer for Ansible pull'
      become: true
      notify: 'Enable ansible-pull.timer'
      ansible.builtin.copy:
        dest: '/etc/systemd/system/ansible-pull.timer'
        content: |
          [Unit]
          Description=starts ansible-pull to get common server configuration
          Requires=ansible-pull.service

          [Timer]
          Unit=ansible-pull.service
          OnCalendar={{ timer_sync_interval }}

          [Install]
          WantedBy=timers.target
          owner: 'root'
          group: 'root'
          seuser: system_u
          serole: object_r
          setype: systemd_unit_file_t
          selevel: s0

    - name: 'Install galaxy collection community.general'
      become: true
      changed_when: false
      ansible.builtin.command:
        cmd: '/usr/bin/ansible-galaxy collection install community.general'

    - name: 'Install galaxy'
      become: true
      community.general.ansible_galaxy_install:
        type: collection
        requirements_file: requirements.yaml
        state: present
        force: true

    - name: 'Ensure required packages are installed'
      become: true
      ansible.builtin.package:
        state: present
        name: python3-pip

---
collections:
  - name: vfricou.apps
    type: git
    source: https://github.com/vfricou/vfricou.apps.git
    version: "master"
  - name: vfricou.system
    type: git
    source: https://github.com/vfricou/vfricou.system.git
    version: "master"

[defaults]
roles_path = ./roles
playbook_dir = ./playbooks
inventory = ./inventories/inventory.yaml

Je m’attarde un peu sur le fichier playbook.yaml, parce qu’il y a plusieurs choses à dire dessus.

Tout d’abord, la déclaration de la variable de trigger pour le timer systemd à intervales de 10 minutes.

Ensuite les tâches effectuées :

Création du l’unit « timer » systemd ansible-pull.timer qui servira au déclenchement régulier d’Ansible Pull
Création de l’unit « service » systemd ansible-pull.service qui est la commande qui sera exécutée pour Ansible Pull
Installation de la collection community.general pour pouvoir effectuer l’installation de ce qui est spécifié dans le fichier requirements.yaml
Installation des requirements galaxy
Installation du package python3-pip s’il n’est pas présent sur le système

Ce que l’on souhaite faire avec ces pre_tasks c’est d’avoir tout ce qui sera nécessaire pour l’application des rôles ou des tâches qui seront contenues dans le playbook par la suite.
Il faut les voir comme des « pré-requis » à l’exécution du playbook.

Première exécution

Vu que c’est Ansible Pull lui-même qui a pour charge de gérer la configuration du timer et de l’unit systemd, vous avez deux solutions :

Soit, vous déposez vous-même vos fichiers de timer / units, mais ce n’est pas fou
Soit, vous exécutez vous-même la commande ansible-pull qui sera exécuté par l’unit systemd.

Personnellement, j’ai une très forte tendance à préférer la deuxième solution.
Tout d’abord parce que ça ne vous fait faire qu’une seule action sur la machine, mais ensuite parce que ça vous permet de valider que l’exécution de votre timer systemd va bien se faire sans erreurs.

Et après ?

Et bien après, vous pouvez ajouter des rôles ou des tâches au playbook pour configurer et valider les points que vous souhaitez faire gérer à Ansible Pull.

Vous poussez vos configurations dans le dépot qui sert de référence à Ansible Pull, et le tour est joué, à intervales réguliers, vous pourrez voir les exécutions de votre playbook sur les machines avec un simple journalctl -u ansible-pull.service.