Ansible Collection 1.3.0 pour OmniSwitch AOS

La collection est disponible dans la Galaxy Ansible et attend vos tests et propositions d’améliorations, le dépôt officiel des modules étant dans le GitHub public. La licence utilisée permet toutes les améliorations des Network Modules et Filtres sur la branche main, mais n’autorise pas la redistributions des forks, afin d’éviter la perte d’énergie (licence Attribution-NonCommercial-NoDerivatives 4.0 International / CC BY-NC-ND 4.0).

Modules

  • gmoisio.ale.ale_aos_ping : Vérifie la connectivité en SSH à un équipement.
  • gmoisio.ale.ale_aos_command : Exécute une liste de commandes sur un équipement. Il est possible de chercher une chaîne de caractères dans le résultat de chaque commande en passant un dictionnaire dans la liste. Dès qu’une chaine de caractère n’est pas trouvée, l’exécution des commandes s’arrête.
  • gmoisio.ale.ale_aos_config : Exécute un ensemble de commandes, généralement pour effectuer une configuration. L’ensemble des commandes peut être transmis sous la forme d’une liste ou sous la forme d’un fichier texte pouvant être généré via un template Jinja2.
  • gmoisio.ale.ale_aos_facts : Module expérimental permettant de récupérer des informations (vlans, interfaces et serveurs ntp) sous la forme d’un dictionnaire de listes pour effectuer des boucles.

Filtres

gmoisio.ale.validate : Ce filtre permet de valider des variables en les confrontant à un schéma YAML. La génération d’un template Jinja2 s’arrête en affichant les causes d’erreurs si les variables ne sont pas conformes au schéma. Le filtre peut être utilisé dans un playbook pour seulement valider la Source de Vérité.

Vous l’aurez noté, la nouveauté de la version 1.3.0 est la mise en place d’un filtre qui est utilisable dans les templates Jinja2 et les playbooks pour valider la conformité des variables utilisées.

Dans l’approche « Network as Code », c’est un problème récurant que de se demander si la ou les personnes qui gèrent la Source de Vérité maîtrisent les règles et contraintes qui avaient été établies lors de la construction. Il est possible de vouloir tout documenter, mais il arrivera le moment où un détail échappera et les règles seront transgressées.

L’objectif de ce nouveau filtre, est d’utiliser la notion de schéma de données dont il est beaucoup question dans les approches YANG. La librairie Python Cerberus permet de décrire des structures de variables sous forme de schéma, représenté soit par un dictionnaire Python, soit par un mapping YAML ou même tout autre moyen de sérialisation.

A titre d’exemple, voici un dictionnaire décrivant une liste de VLANs applicables sur des équipements OmniSwitch.

---
vlans:
  - name: test600
    id: 600
  - name: test4094
    id: 2000

Un exemple de schéma YAML correspondant pourrait être le suivant :

---
vlans_schema:
  type: list
  schema:
    type: dict
    require_all: True
    schema:
      name:
        type: string
        regex: '^[a-z0-9]+$'
        maxlength: 10
      id:
        type: integer
        min: 1
        max: 3000

Ce que décrit ce schéma dans un dictionnaire, c’est :

  • Il s’agit d’une liste
  • Chaque élément de la liste est un dictionnaire
  • Chaque paire (clé, valeur) du dictionnaire est obligatoire
  • La première clé est le « name »
  • La valeur du « name » est de type « string »
  • La valeur du « name » est constituée de lettre minuscules et de chiffres
  • La valeur du « name » ne peut pas excéder 10 caractères de long
  • La deuxième clé est le « id »
  • La valeur de « id » est de type « integer »
  • Le « id » prend au minimum la valeur 1 et au maximum la valeur 3000

Lorsque ce filtre est appliqué dans un template Jinja2, il valide la conformité des valeurs qui vont être utilisées.

{% for vlan in vlans | gmoisio.ale.validate(vlans_schema) %}
vlan {{ vlan.id }} admin-state enable name {{ vlan.name }}
{% endfor %}

Si les valeurs de la liste « vlans » sont conformes, le template effectue sont travail, mais en cas de non conformité, l’exécution est interrompue en donnant les raisons. Pour le test ci-dessous, les informations de VLANs ont été adaptées de façon à ne plus être conformes.

gmoisio.ale.validate
Non conformité des valeurs utilisées

Il convient de noter que pour utiliser cette nouvelle fonctionnalité, il est nécessaire d’installer la librairie Cerberus qui est autonome et ne dépend d’aucune autre librairie : pip install cerberus.

Pour terminer, voici une autre façon d’utiliser le filtre qui permet de valider tout ou partie d’une Source de Vérité depuis une tâche dans un playbook Ansible. Le booléen « True » indique que l’on souhaite uniquement faire un « check » et savoir si la Source de vérité est conforme ou non.

vlans:
  - name: test600
    id: 600
  - name: test4094
    id: 2000

ntp_servers:
  - 0.fr.pool.ntp.org
  - 1.fr.pool.ntp.org
  - 2.fr.pool.ntp.org
  - 3.fr.pool.ntp.org
---
vlans_schema:
  type: list
  schema:
    type: dict
    require_all: True
    schema:
      name:
        type: string
        regex: '^[a-z0-9]+$'
        maxlength: 10
      id:
        type: integer
        min: 1
        max: 3000

ntp_servers_schema:
  type: list
  schema:
    regex: '^[0-3]\.fr\.pool\.ntp\.org$'
- name: Validate Source of Truth
  ansible.builtin.assert:
    that :
      - hostvars[inventory_hostname]['vlans'] | gmoisio.ale.validate(vlans_schema, True)
      - hostvars[inventory_hostname]['ntp_servers'] | gmoisio.ale.validate(ntp_servers_schema, True)
Validate Source of Truth passed
Assertion passed
Validate Source of Truth failed
Assertion failed