Meilleures pratiques pour l’automatisation du réseau DIY

by

L’automatisation est essentielle pour gérer les réseaux rapidement et à grande échelle, de manière sécurisée et fiable. La plupart des équipes réseau écrivent certains des scripts d’automatisation qu’elles utilisent pour provisionner et gérer les ressources sur le réseau.

Vous trouverez ci-dessous des exemples de tâches d’automatisation de réseau DIY :

  • déployer des appliances virtuelles ;
  • installer des mises à jour de logiciels et de micrologiciels sur des appareils physiques ;
  • pousser une configuration de périphérique ;
  • déployer les modifications apportées aux configurations ; et
  • extrayez les informations des appareils et branchez-les dans un fichier ou une base de données.

Les praticiens du réseau écrivent leurs propres scripts pour économiser de l’argent sur les outils de gestion ou pour combler les lacunes des outils dont ils disposent. Par exemple, ils peuvent avoir une automatisation complète via une console de gestion pour leur infrastructure Wi-Fi, mais pas leur filaire ; ou pour l’équipement d’un fournisseur de réseau mais pas d’autres.

Parfois, les équipes utilisent des scripts pour diriger les efforts d’un outil de gestion via son API plutôt que via une interface graphique. Ils peuvent même créer des scripts pour assembler des outils de gestion qui contrôlent différents segments du réseau.

L’objectif est d’automatiser les tâches chronophages ou sujettes aux erreurs. L’automatisation de ces opérations réduit les erreurs qui affectent les services ou la sécurité. La réduction des erreurs ajoute l’avantage de faire gagner du temps à l’administrateur, en particulier le temps qui aurait été consacré au dépannage et à la correction des erreurs.

Dans certains centres de données et environnements cloud, ce type de contrôle scripté ou programmatique du réseau est inclus dans une culture DevOps. Les équipes réseau en dehors de ces environnements sont moins susceptibles de “faire du DevOps” et ne sont même pas près d’être des développeurs à plein temps. Même s’ils poursuivent une méthodologie Agile, cela ne dicte pas les meilleurs efforts spécifiques pour leurs pratiques de codage comme le font les cultures DevOps.

Ainsi, les équipes réseau qui sont seules peuvent suivre certaines des meilleures pratiques pour s’assurer que leurs efforts soutiennent la fiabilité, la sécurité et la maintenabilité dans le temps.

Meilleures pratiques pour l'automatisation du réseau DIY
Ces meilleures pratiques peuvent aider les équipes réseau à rationaliser leurs initiatives d’automatisation du réseau DIY.

Développez pour les gens — c’est-à-dire partager, c’est prendre soin

Une information clé que le personnel du réseau doit intégrer lors de l’écriture de scripts d’automatisation est : “Ce script n’est pas seulement pour moi”. Les auteurs de scripts qui écrivent dans l’espoir de l’utiliser plus d’une fois devraient supposer que quelqu’un d’autre pourrait ou l’utilisera un jour. Cette personne peut être un collègue, un successeur ou l’auteur original – un laps de temps suffisant peut brouiller les détails et les idées qui étaient prioritaires lorsque l’auteur a écrit le code.

Lorsque les auteurs écrivent du code sans penser aux autres, il peut être difficile et fastidieux pour les administrateurs réseau de comprendre les fonctions, le comportement, les exigences, le contexte attendu et les conséquences du code.

Le personnel peut éviter le problème du code en écriture seule en mettant en œuvre les bonnes pratiques suivantes :

  • Établissez un petit ensemble de normes de codage. Par exemple, les équipes peuvent décider qu’un script donné suivra snake_format ou CamelFormat pour tous les noms d’objet. Peu importe le format qu’ils utilisent ; ce qui compte, c’est la cohérence au sein d’un programme donné. Certains voient un avantage à aller plus loin et à encoder dans des noms de variables des informations sur la variable elle-même — par exemple, s’il s’agit d’un entier ou d’une chaîne — généralement en ajoutant un préfixe ou un suffixe, tel que str_username pour une chaîne contenant un nom d’utilisateur.
  • Nommez les variables, les fonctions, les sous-programmes, les programmes et les fichiers de manière significative. Si un auteur veut qu’une variable identifie un appareil réseau, l’appeler appliance_id est bien plus utile aux autres que de le nommer fou.
  • Insérez des commentaires en haut d’un script expliquant les faits généraux. Ces commentaires expliquent à quoi sert le programme, les conditions préalables à son exécution et le processus de base qu’il utilise pour résoudre le problème en cours.
  • Insérez des commentaires avant les principales sections d’un long morceau de code. Ces commentaires expliquent ce que la prochaine section de code va faire et comment elle le fait, à un niveau élevé.

Une information clé que le personnel du réseau doit intégrer lors de l’écriture de scripts d’automatisation est : “Ce script n’est pas seulement pour moi”.

Il est également utile pour les équipes d’établir un ensemble d’outils standard. Lorsque le choix de l’outil est libre pour tous, une équipe peut se retrouver avec chaque administrateur utilisant une langue ou une plate-forme différente et sans compréhension mutuelle.

Une taille ne conviendra pas à tous, cependant. Tout le monde, partout, n’a pas besoin d’écrire tout son code en Python, ou quelque chose comme ça. Au lieu de cela, les équipes doivent définir un petit ensemble contrôlé de langages ou de plates-formes qu’elles peuvent utiliser pour l’automatisation ad hoc qu’elles écrivent. Cette stratégie permet à tous les membres de l’équipe d’avoir au moins des compétences de base avec tous les outils utilisés. À leur tour, ils pourront utiliser, étendre, mettre à jour ou corriger le travail de n’importe qui d’autre. Les équipes peuvent abandonner des langues ou des plates-formes au profit de meilleures, selon les besoins.

Gérez soigneusement le code et les modifications

Dans la plupart des organisations, lorsque le service informatique déploie une nouvelle version d’une application ou d’un système d’exploitation majeur, il suit un processus de gestion du changement. Les équipes examinent le changement proposé. Le service informatique a-t-il un plan pour effectuer le changement ? A-t-il un plan pour revenir au statu quo ante si le changement cause un problème? L’équipe a-t-elle bien testé le changement ? A-t-il un plan pour informer les utilisateurs qui seront concernés ? Une fois que les équipes ont approuvé le changement, elles planifient son déploiement, en choisissant souvent une fenêtre de changement qui limite les effets négatifs en cas de problème et minimise les inconvénients pour les utilisateurs, quelle que soit la manière dont le changement se déroule.

L’automatisation du réseau est un logiciel informatique essentiel. Ainsi, lorsque les équipes réseau souhaitent modifier un programme en cours d’utilisation, elles doivent utiliser un processus similaire et rationalisé. Au minimum, le processus de gestion des modifications du réseau doit garantir que les équipes effectuent les actions suivantes :

  • tester les modifications apportées à un script avant de déployer une nouvelle version en production ; et
  • à l’avance lorsqu’ils remplaceront l’ancienne version par la nouvelle.

Le terme nouvelle version soulève la question de la gestion du code. Les équipes réseau doivent savoir quelle est la version actuelle d’un script donné, où il peut être trouvé, qui l’a mis à jour pour la dernière fois et quand. Toutes ces informations constituent le niveau minimum de gestion de code. Les équipes réseau peuvent utiliser des outils de gestion de code pour appliquer le contrôle de version – via l’archivage et l’extraction – et suivre les auteurs.

N’oubliez pas l’immuabilité

Enfin, les équipes réseau devraient envisager une approche commune aux équipes DevOps qui pratiquent l’infrastructure en tant que gestion de code dans leurs environnements : l’immuabilité. Avec l’immuabilité, une valeur ou une configuration ne peut pas être modifiée, seulement remplacée ou supprimée.

Par exemple, une fois que les équipes réseau ont déployé une appliance virtuelle, elles doivent traiter sa configuration comme immuable, c’est-à-dire qu’elle ne doit pas être modifiée. Si l’appliance virtuelle nécessite une modification de configuration, l’équipe réseau sort une nouvelle appliance virtuelle avec une configuration qui inclut la modification, et déprovisionne l’ancienne instance mal configurée. Ou, si l’équipe apporte des modifications à la configuration d’un appareil physique, elle envoie une configuration complète qui inclut la modification, plutôt que de simplement appliquer la modification elle-même.

L’objectif des configurations immuables est de minimiser ou d’éliminer la dérive de configuration dans l’environnement. Pousser des configurations ou des images complètes efface toutes les modifications non autorisées sur l’appareil.

L’immuabilité résout également un problème courant dans lequel une poussée vers un périphérique (incorporant la modification A) échoue, mais une poussée ultérieure (pour implémenter la modification B) réussit. Si la deuxième poussée inclut uniquement la modification B, l’appareil est toujours mal configuré car il manque la modification A. Cependant, si la deuxième poussée est une configuration complète, qui inclut à la fois A et B, la deuxième poussée remet l’appareil en conformité. De plus, notamment, si le changement B dépend du changement A, pousser une configuration complète signifie que le changement B n’échouera pas automatiquement pour tout périphérique sur lequel le changement A a échoué.

Les équipes réseau utilisent beaucoup d’automatisation ad hoc et en utiliseront probablement davantage chaque année. Une meilleure utilisation de ces scripts d’automatisation peut contribuer à rendre leurs efforts plus fructueux et à réduire leur stress au travail.

Leave a Comment