Custom services

Les Custom services permettent de créer des modèles de services (configuration) personnalisés. Une fois définis, ces services sont disponibles sur toute la plateforme : dans les pages Maps, Schedule et Engineering Rules.

Ces services sont principalement conçus pour le déploiement de configurations, mais ils peuvent également exécuter des commandes en mode "enable" (par ex., purger des fichiers locaux).

Point de départ : créer les services comme modèles avant instanciation.

Concept

Le principe est de créer un service réseau qui pourra être utilisé dans les intefaces de votre choix.

Un service est caractérisé par :

• Name : un nom unique pour identifier le service
• Description : permet à tous les utilisateurs de comprendre ce que produit le service
• Category : la catégorie permet de créer des menus hiérarchiques pour ranger vos services.

• Template :

  • Le template doit être écrit en jinja2
  • les paramètres du template sont détectés par Avalon et vous devrez leur affecter un type
  • Vous pouvez définir un template par plateforme ou réutiliser un template pour plusieurs plateformes quand cela est possible (certains templates IOS XE peuvent fonctionner sur NX-OS par exemple)

Héritage d'un modèle d'une plateforme à une autre pour accélérer le développement.

Définition de réponses automatisées pour les invites CLI interactives.

• Options :

  • Configuration service : indique que le service va créer des configurations sur l'équipement. Cela permet à notre moteur d'injection de configuration d'entrer dans le mode de configuration de l'équipement, d'activer la détection d'erreur appropriée et de créer les points de restauration nécessaire au Rollback.
  • ReRun : indique si le service peut être rejouer en cas d'échec
  • Map : rend le service disponible depuis les cartes
  • Engineering : rend le service disponible dans les règles d'ingénierie.

Warning

Certains paramètres sont masqués dans les règles d'ingénierie car ce mode de déploiement n'est pas prévu pour définir manuellement les paramètres pour chaque équipement.

• Prompt responses : Pour les commandes nécessitant confirmation, Avalon gère l'interaction via un flux Q/R. Plusieurs prompts peuvent être configurés.

Roadmap : Catégories définies par l'utilisateur

Les catégories définies par l'utilisateur pour les services personnalisés sont prévues pour S1 2026.

Templating Jinja2

Avalon utilise Jinja2 pour générer les configurations. Jinja2 permet d'ajouter des variables, d'itérer sur des données avec des boucles et d'introduire des structures conditionnelles.

Variables réservées Avalon

Avalon fournit automatiquement des variables contextuelles pendant l'exécution :

• hostname : Le nom de l'équipement actuel tel que stocké dans la base de données.
• device_model : Le SKU matériel de l'équipement ciblé.

Syntaxe de base et structures de contrôle

• Expressions : Affichent la valeur d'une variable. {{ interface_id }}

• Statements : Contrôle logique (boucles, conditionnelles). {% ... %}

• Loops : Itération sur des listes.

{% for item in list %}
 Do something with {{ item }}
{% endfor %}

• Conditionals : Applique la configuration selon des critères.

{% if '2960' in device_model %}
 authentication convert-to new-style
{% endif %}

L'ensemble des possibilités est détaillé dans la documentation officielle Jinja2.

Validation en temps réel

Avalon vérifie la syntaxe de votre template Jinja2 en permanence. Si une balise est ouverte ou une erreur détectée, Avalon identifie la ligne et l'erreur.

Le validateur en temps réel détectant une boucle 'for' non fermée.

Un modèle valide itérant sur une liste d'interfaces pour définir des descriptions.

Le template utilisé pour Cisco IOS est le suivant pour boucler sur une liste d'interface et y ajouter une descrption :

{% for interface in interfaces %}
interface {{ interface }}
  description {{ description }}
{% endfor %}

Typage des paramètres et objets de base de données

Après avoir cliqué sur Refresh from template, Avalon détecte les variables et vous demandera de définir leur Type:

• Generics : Entrées standard (Text, Numbers, VLAN IDs).

• Specifics (Objets de base de données) : Lient les paramètres aux objets dans la base de données d'Avalon.

  • Configured Services : Instances globales d'un service (ex : serveur RADIUS, compte utilisateur).
  • Interfaces : Lie le service aux interfaces réelles de l'équipement.

Comportement du paramètre Interface

Lorsqu'un paramètre est typé Interfaces, vous pouvez définir sa contrainte via la case à cocher Single :

• Décochée (défaut) : Le paramètre est traité comme une liste, permettant l'utilisation de boucles Jinja2 pour la configuration de ports en masse.

• Cochée : Le service accepte une seule interface :

  • Règle d'ingénierie : Avalon déclenchera une erreur si plusieurs interfaces sont trouvées dynamiquement.
  • Map et Schedule : le composant visuel utilisé ne permettra la sélection que d'une seule interface.

Mapping des variables Jinja à des types de données simples ou complexes.

Configuration d'un paramètre 'Interfaces' comme liste pour déploiement multi-interfaces.

Exemple : déploiement depuis la carte d'un site

Service disponible dans Services > Custom sur la carte. Custom correspond à la catégorie du service.

Déclenchement d'un service personnalisé pour un équipement spécifique sur la carte.

Saisie de paramètres et Dry Run

Lors du lancement du service, vous devez fournir les paramètres définis dans le modèle. Pour les paramètres de type interface, vous pouvez choisir depuis l'inventaire réel de l'équipement.

Le mode de déploiement Dry Run génère la sortie CLI finale avant déploiement.

Sélection d'interfaces spécifiques et saisie de la description.

Examen de la configuration rendue avant exécution à l'échelle du réseau.

Gestion et historique de déploiement

Avalon maintient un tableau de bord complet pour chaque service personnalisé, affichant sa définition et son historique de déploiement sur le parc.

• Tableau des instances : Instanciation globale pour réutilisation en tant que Configured Service par d'autres services ou directement dans une règle d'ingénierie.

Vue globale d'un modèle de service personnalisé.

• History : Vous pouvez consulter l'historique pour voir quels paramètres ont été utilisés pour chaque équipement lors des déploiements précédents.

Historique des instances déployées par équipement.