Cet article est le sixième d'une série sur « Comment prendre le contrôle de son infrastructure réseau ». Vous pouvez trouver le contenu de tous les articles de la série et les liens. .
Après avoir laissé quelques sujets derrière moi, j'ai décidé de commencer un nouveau chapitre.
Je reviendrai plus tard sur la sécurité. Ici, je souhaite discuter d'une approche simple mais efficace qui, j'en suis sûr, peut être utile à beaucoup d'entre vous, d'une manière ou d'une autre. C'est plutôt une courte histoire sur la façon dont l'automatisation peut transformer la vie d'un ingénieur. Je vais parler de l'utilisation de templates. À la fin, vous trouverez une liste de mes projets où vous pourrez voir comment tout cela fonctionne.
DevOps pour le réseau
Créer une configuration via un script, utiliser GIT pour le contrôle des changements dans l'infrastructure IT, le « push » à distance — ces idées viennent immédiatement à l'esprit lorsque l'on pense à la mise en œuvre technique de l'approche DevOps. Les avantages sont évidents. Mais, hélas, il y a aussi des inconvénients.
Il y a plus de 5 ans, lorsque nos développeurs sont venus nous voir, nous, les réseaux, avec ces propositions, nous n'étions pas enthousiastes.
Il convient de dire que nous avons hérité d'un réseau assez hétéroclite, composé d'équipements provenant d'une dizaine de différents fournisseurs. Certaines configurations étaient faciles à réaliser via notre cli préféré, mais pour d'autres, nous préférions utiliser l'interface graphique. De plus, ma longue expérience sur du matériel « en production » m'a habitué à un contrôle en temps réel. Personnellement, lorsque j'apporte des modifications, je me sens beaucoup plus à l'aise de travailler directement via cli. Cela me permet de voir rapidement si quelque chose ne va pas et de « revenir en arrière » sur les changements. Tout cela contredisait quelque peu leurs idées.
Il y a d'autres questions qui se posent, par exemple que l'interface peut légèrement changer d'une version de logiciel à l'autre. Cela finira par entraîner le fait que votre script produit une « configuration » incorrecte. Je ne voudrais pas utiliser la production pour des tests.
Ou comment savoir si les commandes de configuration ont été appliquées correctement et que faire en cas d'erreur ?
Je ne veux pas dire que toutes ces questions sont insolubles. Il est peut-être raisonnable de dire « A » et aussi « B » et, si vous souhaitez utiliser les mêmes processus de contrôle des changements que ceux de développement, vous devez disposer, en plus de la production, des environnements de développement et de staging. Alors cette approche semble complète. Mais combien cela va-t-il coûter ?
Cependant, il existe une situation où les inconvénients sont pratiquement annulés et il ne reste que des avantages. Je parle des travaux de projet.
Projet
Au cours des deux dernières années, j'ai participé à un projet de construction de centre de données pour un grand fournisseur. Je suis responsable de l'équipement F5 et Palo Alto dans ce projet. D'un point de vue Cisco, il s'agit d'équipement de « tiers parti ».
Pour moi, il y a deux phases clairement définies dans ce projet.
Première phase
La première année, j'étais constamment occupé, je travaillais la nuit et le week-end. Je ne pouvais pas lever la tête. La pression de la direction et du client était forte et continue. Dans cette routine quotidienne, je ne pouvais même pas essayer d'optimiser le processus. Ce n'était pas seulement, voire pas tant, la configuration de l'équipement, mais aussi la préparation de la documentation projet.
Les premiers tests ont commencé, et j'étais surpris du nombre d'erreurs et d'inexactitudes qui avaient été commises. Bien sûr, tout fonctionnait, mais il manquait une lettre dans un nom, une ligne était omise dans une commande... Les tests se poursuivaient, et j'étais déjà en lutte permanente, quotidienne, avec les erreurs, les tests et la documentation.
Cela a duré un an. Selon ma compréhension, le projet n'était pas simple pour tout le monde, mais progressivement, le client devenait de plus en plus satisfait, ce qui a permis d'engager des ingénieurs supplémentaires pouvant prendre en charge une partie de la routine.
Maintenant, je pouvais un peu lever les yeux.
Et cela marquait le début de la deuxième étape.
Deuxième phase
J'ai décidé d'automatiser le processus.
Ce que j'ai compris à l'époque à travers les échanges avec les développeurs (et il faut reconnaître que nous avions une équipe solide), c'est que le format texte, bien qu'il semble d'abord appartenir à l'univers des systèmes d'exploitation DOS, possède plusieurs propriétés précieuses.
Par exemple, le format texte sera utile si vous souhaitez pleinement tirer parti de GIT et de tous ses dérivés. Et je le voulais.
Eh bien, on pourrait penser qu'il suffit de stocker la configuration ou la liste des commandes, mais il est assez inconfortable de faire des modifications dans ce cas. De plus, lors de la conception, une autre tâche importante se pose. Vous devez disposer d'une documentation décrivant votre conception dans son ensemble (Low Level Design) et une mise en œuvre spécifique (Network Implementation Plan). Dans ce cas, l'utilisation de modèles semble être une option très appropriée.
Ainsi, en utilisant YAML et Jinja2, le fichier YAML avec les paramètres de configuration, tels que les adresses IP, les numéros BGP AS, etc., joue parfaitement le rôle de NIP, tandis que les modèles Jinja2 comprennent une syntaxe correspondant au design, c'est-à-dire qu'ils reflètent en essence le LLD.
L'étude des langages YAML et Jinja2 a pris deux jours. Pour comprendre comment cela fonctionne, quelques bons exemples suffisent. Ensuite, environ deux semaines ont été nécessaires pour créer tous les modèles correspondant à notre design : une semaine pour Palo Alto et une autre semaine pour F5. Tout cela a été mis en ligne sur notre githab d'entreprise.
Le processus de modification se présentait désormais comme suit :
- j'ai modifié le fichier YAML
- j'ai créé un fichier de configuration à l'aide d'un modèle (Jinja2)
- enregistré dans le dépôt distant
- j'ai téléchargé la configuration créée sur le matériel
- j'ai vu une erreur
- j'ai modifié le fichier YAML ou le modèle Jinja2
- j'ai créé un fichier de configuration à l'aide d'un modèle (Jinja2)
- …
Il est clair qu'au début, beaucoup de temps était consacré aux modifications, mais après une semaine ou deux, cela est devenu plutôt rare.
Une bonne vérification et une occasion de tout déboguer a été le désir du client de changer la convention de nommage. Qui a travaillé avec F5 comprend la délicatesse de la situation. Mais pour moi, tout était assez simple. J'ai changé les noms dans le fichier YAML, supprimé toute la configuration du matériel, généré une nouvelle et l'ai téléchargée. En tout, y compris le temps pour corriger les bugs, cela a pris 4 jours : deux jours pour chaque technologie. Après cela, j'étais prêt pour la prochaine étape, à savoir la création des centres de données DEV et Staging.
Dev et Staging
Le Staging répète en fait presque entièrement la production. Dev est une copie fortement réduite et principalement construite sur du matériel virtuel. Une situation idéale pour appliquer la nouvelle approche. Si l'on extrait le temps que j'ai passé, je pense que le travail n'a pas duré plus de 2 semaines. Le principal temps est celui d'attente de l'autre partie et les recherches conjointes de problèmes. L'implémentation du 3rd party s'est déroulée presque sans que les autres s'en aperçoivent. J'ai même eu le temps d'apprendre quelque chose et d'écrire quelques articles sur Habr 🙂
En résumé
Alors, que me reste-t-il en fin de compte ?
- tout ce dont j'ai besoin pour modifier la configuration — c'est de modifier un fichier YAML simple et clairement structuré avec les paramètres de configuration. Je ne change jamais le script python et très rarement (uniquement en cas d'erreur) je change le modèle Jinja2.
- Du point de vue de la documentation, la situation est presque idéale. Vous modifiez la documentation (les fichiers YAML jouent le rôle de NIP) et vous téléchargez cette configuration sur le matériel. Ainsi, votre documentation est toujours à jour.
Tout cela a conduit au fait que
- le pourcentage d'erreurs a chuté presque à 0.
- 90 % de la routine a disparu.
- la vitesse de déploiement a considérablement augmenté.
PAY, F5Y, ACY
J'ai dit que quelques exemples suffisent pour comprendre comment cela fonctionne.
Voici une version succincte (et bien sûr modifiée) de ce qui a été créé au cours de mon travail.
= déploiement redicted Frame)alo Alto from Yaml = Palo Alto from Yaml
= déploiement F5 from Yaml = F5 from Yaml (bientôt disponible)
= déploiement ACi from Yaml = F5 from Yaml
J'ajouterai quelques mots sur ACY (ne pas confondre avec ACI).
Ceux qui ont travaillé avec ACI savent que ce miracle (et dans le bon sens aussi) a été créé non pas par des spécialistes réseau :). Oubliez tout ce que vous savez sur le réseau — cela ne vous sera pas utile !
C'est un peu exagéré, mais cela traduit approximativement le sentiment que j'éprouve constamment depuis 3 ans en travaillant avec ACI.
Dans ce cas, ACY est non seulement une possibilité de mettre en place un processus de contrôle des modifications (ce qui est particulièrement important dans le cas de l'ACI, car il est supposé que c'est la partie centrale et la plus critique de votre centre de données), mais cela vous donne aussi une interface conviviale pour créer des configurations.
Les ingénieurs dans ce projet utilisent Excel pour configurer l'ACI au lieu de YAML pour atteindre les mêmes objectifs. L'utilisation d'Excel a certes ses avantages :
- votre NIP dans un seul fichier.
- de belles tables qui plaisent à voir pour le client.
- vous pouvez utiliser certains outils d'Excel.
Mais il y a un inconvénient, et à mon avis, il l'emporte sur les avantages. Contrôler les modifications et coordonner le travail de l'équipe devient beaucoup plus compliqué.
ACY est en fait l'application des mêmes approches que celles que j'ai utilisées pour le tiers, pour la configuration de l'ACI.
Source : habr.com
