Collections Ansible¶

Les collections regroupent rôles, modules, plugins et playbooks dans un package versionneable et distribuable. Elles constituent l'unite de distribution officielle depuis Ansible 2.9.

Structure d'une collection¶

Une collection suit une arborescence normalisee :

namespace/
└── collection_name/
    ├── galaxy.yml           # metadonnees, version, dependances
    ├── README.md
    ├── roles/               # roles de la collection
    ├── plugins/
    │   ├── modules/         # modules custom en Python
    │   ├── inventory/       # plugins d'inventaire
    │   └── lookup/          # plugins de lookup
    ├── playbooks/           # playbooks distribues dans la collection
    └── tests/               # tests via ansible-test

Les modules d'une collection s'utilisent via leur FQCN (Fully Qualified Collection Name) :

- name: creer une instance EC2
  amazon.aws.ec2_instance:
    name: mon-serveur
    instance_type: t3.medium
    image_id: ami-0abcdef1234567890

Le format est toujours namespace.collection.module. L'utilisation du FQCN evite les ambiguites entre modules de même nom issus de collections différentes.

Ansible Galaxy¶

Ansible Galaxy est le dépôt public de collections et de rôles. L'installation se fait via la commande ansible-galaxy.

# Installer une collection depuis Galaxy
ansible-galaxy collection install google.cloud

# Installer une version specifique
ansible-galaxy collection install amazon.aws:==7.0.0

# Installer depuis un fichier requirements
ansible-galaxy collection install -r requirements.yml

# Mettre a jour une collection installee
ansible-galaxy collection install google.cloud --upgrade

# Lister les collections installees
ansible-galaxy collection list

Fichier requirements.yml¶

Le fichier requirements.yml centralise les dépendances du projet. Il doit être committe dans le dépôt source et rejoue systematiquement en CI.

# requirements.yml
---
collections:
  - name: google.cloud
    version: ">=1.3.0"
  - name: amazon.aws
    version: "==7.0.0"
  - name: azure.azcollection
    version: ">=2.0.0"
  - name: community.general
    version: ">=8.0.0"
  - name: ansible.posix
    version: ">=1.5.0"

roles:
  - name: geerlingguy.docker
    version: "7.0.0"

Collections de référence¶

Collections privées¶

Pour distribuer des collections internes sans passer par Galaxy public, il existe deux approches : l'installation depuis une archive locale ou depuis un dépôt Git, et la publication vers un registry prive.

Construire et installer manuellement¶

# Construire l'archive de la collection (depuis le repertoire parent)
ansible-galaxy collection build mon_namespace/ma_collection

# Installer depuis l'archive locale generee
ansible-galaxy collection install mon_namespace-ma_collection-1.0.0.tar.gz

# Installer depuis un depot Git (branche ou tag)
ansible-galaxy collection install \
  git+https://git.example.com/ansible-collections/network.git,main

# Installer depuis un tag Git specifique
ansible-galaxy collection install \
  git+https://git.example.com/ansible-collections/network.git,v1.2.0

Registry prive (Nexus, Pulp, Automation Hub)¶

La configuration du registry prive se fait dans ansible.cfg. Plusieurs sources peuvent coexister avec un ordre de priorité.

# ansible.cfg
[galaxy]
server_list = automation_hub, galaxy

[galaxy_server.automation_hub]
url=https://hub.example.com/api/galaxy/
auth_url=https://sso.example.com/auth/token
token=mon_token_prive

[galaxy_server.galaxy]
url=https://galaxy.ansible.com/

Avec cette configuration, ansible-galaxy interroge d'abord automation_hub, puis galaxy en fallback pour les collections non trouvees en interne.

# Installation transparente : resolution selon server_list
ansible-galaxy collection install mon_namespace.ma_collection

Versionnement¶

Les collections suivent le versionnement semantique (semver) : MAJEUR.MINEUR.PATCH.

• MAJEUR : changement incompatible (rupture d'API ou de comportement)
• MINEUR : ajout de fonctionnalité retrocompatible
• PATCH : correction de bug retrocompatible

# galaxy.yml (a la racine de la collection)
---
namespace: mon_namespace
name: infrastructure
version: 2.1.0
description: Collection d'automatisation infrastructure interne
authors:
  - Equipe Infrastructure <infra@example.com>
dependencies:
  ansible.posix: ">=1.5.0"
  community.general: ">=8.0.0"
repository: https://git.example.com/ansible-collections/infrastructure
documentation: https://docs.example.com/ansible
issues: https://git.example.com/ansible-collections/infrastructure/issues

# Preferer en production
- name: google.cloud
  version: "==1.3.0"

# A eviter en production
- name: google.cloud
  version: ">=1.3.0"

Collections par domaine fonctionnel — taxonomie nuevolia¶

L'architecture d'automatisation s'organisé en collections alignees sur les domaines d'exploitation. Chaque collection regroupe des rôles fonctionnels nommes d'après ce qu'ils font, pas d'après les outils qu'ils utilisent. Le provider ou l'outil est un parametre du rôle, pas son nom.

Namespace racine : nuevolia

Vue d'ensemble¶

graph TB
    N["nuevolia"]
    N --> SYS["system"]
    N --> NET["network"]
    N --> MON["monitoring"]
    N --> APP["application"]
    N --> DB["database"]
    N --> ID["identity"]
    N --> CLD["cloud"]

    SYS --> SYS1["hardening"]
    SYS --> SYS2["local_accounts"]
    SYS --> SYS3["time_sync"]
    SYS --> SYS4["backup"]
    SYS --> SYS5["scheduler"]

    NET --> NET1["packet_filter"]
    NET --> NET2["ingress_gateway"]
    NET --> NET3["egress_proxy"]
    NET --> NET4["dns"]
    NET --> NET5["vpn"]

    MON --> MON1["system_metrics"]
    MON --> MON2["app_metrics"]
    MON --> MON3["system_logs"]
    MON --> MON4["app_logs"]
    MON --> MON5["tracing"]
    MON --> MON6["alerting"]

    APP --> APP1["container_engine"]
    APP --> APP2["reverse_proxy"]
    APP --> APP3["runtime"]
    APP --> APP4["message_queue"]

    DB --> DB1["relational_store"]
    DB --> DB2["document_store"]
    DB --> DB3["key_value_store"]
    DB --> DB4["column_store"]
    DB --> DB5["high_availability"]

    ID --> ID1["tls_certificates"]
    ID --> ID2["directory_service"]
    ID --> ID3["authentication"]
    ID --> ID4["secret_management"]

    CLD --> CLD1["compute"]
    CLD --> CLD2["storage"]
    CLD --> CLD3["network"]
    CLD --> CLD4["identity"]
    CLD --> CLD5["image"]
    CLD --> CLD6["guest"]
    CLD --> CLD7["mail_gateway"]

nuevolia.system¶

Socle système local, indépendant du provider.

nuevolia.network¶

Services réseau des cloud providers. Si le provider ne propose pas de service manage, utiliser nuevolia.application.reverse_proxy en fallback pour le load balancing applicatif.

nuevolia.monitoring¶

Observabilité système et applicative. Les agents système et applicatifs sont des rôles distincts pour permettre un déploiement granulaire.

nuevolia.application¶

Déploiement applicatif. Inclut les solutions de fallback réseau quand le provider ne dispose pas de service manage.

nuevolia.database¶

Déploiement de bases de données organisé par famille de topologie de données.

nuevolia.identity¶

Services partages d'identité et de secrets, consommes par toutes les autres collections.

nuevolia.cloud¶

Consommation des services cloud. Chaque rôle représenté un objet cloud unique valide quel que soit le provider cible. Le provider est un parametre du rôle.

galaxy.yml et requirements.yml¶

galaxy.yml d'une collection nuevolia¶

# nuevolia/system/galaxy.yml
---
namespace: nuevolia
name: system
version: 1.0.0
description: Socle systeme — hardening, comptes locaux, synchronisation temps, backup
authors:
  - Equipe Infrastructure <infra@nuevolia.dev>
dependencies:
  ansible.posix: ">=1.5.0"
  community.general: ">=8.0.0"
repository: https://git.nuevolia.dev/ansible-collections/system
documentation: https://docs.nuevolia.dev/ansible/collections/system
issues: https://git.nuevolia.dev/ansible-collections/system/issues

requirements.yml multi-sources¶

Un projet typique consomme des collections nuevolia depuis le registry prive et des collections communautaires depuis Galaxy public.

# requirements.yml
---
collections:
  # Collections internes nuevolia (registry prive)
  - name: nuevolia.system
    version: "==1.2.0"
    source: https://hub.nuevolia.dev/api/galaxy/
  - name: nuevolia.cloud
    version: "==2.0.1"
    source: https://hub.nuevolia.dev/api/galaxy/
  - name: nuevolia.monitoring
    version: "==1.1.0"
    source: https://hub.nuevolia.dev/api/galaxy/
  - name: nuevolia.application
    version: "==1.0.3"
    source: https://hub.nuevolia.dev/api/galaxy/
  - name: nuevolia.identity
    version: "==1.0.0"
    source: https://hub.nuevolia.dev/api/galaxy/

  # Collections communautaires (Galaxy public)
  - name: community.vmware
    version: ">=4.0.0"
  - name: ansible.posix
    version: ">=1.5.0"
  - name: community.general
    version: ">=8.0.0"

ansible.cfg associe¶

# ansible.cfg
[galaxy]
server_list = nuevolia_hub, galaxy

[galaxy_server.nuevolia_hub]
url=https://hub.nuevolia.dev/api/galaxy/
token=<NUEVOLIA_HUB_TOKEN>

[galaxy_server.galaxy]
url=https://galaxy.ansible.com/