Cet article est le sixième de la série « Comment prendre le contrôle de votre infrastructure réseau ». Le contenu de tous les articles de la série et les liens peuvent être trouvés .
Ayant laissé plusieurs sujets derrière moi, j'ai décidé de commencer un nouveau chapitre.
Je reviendrai à la sécurité un peu plus tard. Je souhaite ici discuter d’une approche simple mais efficace qui, j’en suis sûr, sous une forme ou une autre, peut être utile à beaucoup. Il s’agit plutôt d’une courte histoire sur la façon dont l’automatisation peut changer la vie d’un ingénieur. Nous parlerons de l'utilisation de modèles. À la fin, il y a une liste de mes projets où vous pouvez voir comment tout ce qui est décrit ici fonctionne.
DevOps pour le réseau
Créer une configuration avec un script, utiliser GIT pour contrôler les modifications de l'infrastructure informatique, « télécharger » à distance, ces idées viennent en premier lorsque l'on réfléchit à la mise en œuvre technique de l'approche DevOps. Les avantages sont évidents. Mais malheureusement, il y a aussi des inconvénients.
Lorsqu'il y a plus de 5 ans, nos développeurs sont venus nous voir, les networkers, avec ces propositions, nous n'étions pas ravis.
Je dois dire que nous avons hérité d'un réseau assez hétéroclite, composé d'équipements provenant d'une dizaine de fournisseurs différents. C'était pratique de configurer certaines choses via notre cli préféré, mais dans d'autres, nous avons préféré utiliser l'interface graphique. De plus, de longs travaux sur des équipements « sous tension » nous ont appris le contrôle en temps réel. Par exemple, lorsque j'apporte des modifications, je me sens beaucoup plus à l'aise en travaillant directement via la cli. De cette façon, je peux rapidement voir que quelque chose s'est mal passé et annuler les modifications. Tout cela était en contradiction avec leurs idées.
D'autres questions se posent également, par exemple l'interface peut légèrement changer d'une version à l'autre du logiciel. Cela finira par amener votre script à créer une mauvaise "configuration". Je ne voudrais pas utiliser la production pour le « rodage ».
Ou, comment comprendre que les commandes de configuration ont été correctement appliquées et que faire en cas d'erreur ?
Je ne veux pas dire que tous ces problèmes sont insolubles. Il est probablement logique de dire simplement « A » pour dire « B » également, et si vous souhaitez utiliser les mêmes processus de contrôle des modifications qu'en développement, vous devez alors disposer d'environnements de développement et de préparation en plus de la production. Cette approche semble alors complète. Mais combien cela coûtera-t-il ?
Mais il existe une situation où les inconvénients sont pratiquement compensés et où seuls les avantages subsistent. Je parle du travail de conception.
Projet
Depuis deux ans, je participe à un projet de construction d'un centre de données pour un grand fournisseur. Je suis responsable de F5 et Palo Alto dans ce projet. Du point de vue de Cisco, il s'agit d'un « équipement tiers ».
Pour moi personnellement, il y a deux étapes distinctes dans ce projet.
Première étape
La première année, j’étais très 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 une routine constante, je ne pouvais même pas essayer d'optimiser le processus. Il ne s'agissait pas seulement et pas tant de configuration de l'équipement que de préparation de la documentation de conception.
Les premiers tests ont commencé et je serais étonné du nombre de petites erreurs et d'inexactitudes qui ont été commises. Bien sûr, tout fonctionnait, mais il manquait une lettre dans le nom, il manquait une ligne dans la commande... Les tests se poursuivaient encore et encore, et j'étais déjà dans une lutte constante et quotidienne avec les erreurs, les tests et la documentation. .
Cela a duré un an. Le projet, d'après ce que je comprends, n'a pas été facile pour tout le monde, mais peu à peu le client est devenu de plus en plus satisfait, ce qui a permis d'embaucher des ingénieurs supplémentaires qui ont pu prendre eux-mêmes en charge une partie de la routine.
Maintenant, nous pourrions regarder un peu autour de nous.
Et c'était le début de la deuxième étape.
Deuxième étape
J'ai décidé d'automatiser le processus.
Ce que j'ai compris de ma communication avec les développeurs à cette époque (et il faut leur rendre hommage, nous avions une équipe solide) c'est que le format texte, bien qu'à première vue ressemble à quelque chose du monde du système d'exploitation DOS, a un certain nombre de de propriétés précieuses.
Ainsi, par exemple, le format texte sera utile si vous souhaitez profiter pleinement de GIT et de tous ses dérivés. Et je le voulais.
Eh bien, il semblerait que vous puissiez simplement stocker une configuration ou une liste de commandes, mais apporter des modifications est assez gênant. De plus, il existe une autre tâche importante lors de la conception. Vous devez disposer d'une documentation décrivant votre conception dans son ensemble (conception de bas niveau) et sa mise en œuvre spécifique (plan de mise en œuvre du réseau). Et dans ce cas, l’utilisation de modèles semble être une option très appropriée.
Ainsi, lors de l'utilisation de YAML et Jinja2, un fichier YAML avec des paramètres de configuration tels que des adresses IP, des numéros BGP AS, ... remplit parfaitement le rôle de NIP, tandis que les modèles Jinja2 incluent une syntaxe correspondant à la conception, c'est-à-dire qu'il s'agit essentiellement d'un reflet du LLD.
Il a fallu deux jours pour apprendre YAML et Jinja2. Quelques bons exemples suffisent pour comprendre comment cela fonctionne. Ensuite, il a fallu environ deux semaines 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é publié sur le githab d'entreprise.
Maintenant, le processus de changement ressemblait à ceci :
- changé le fichier YAML
- créé un fichier de configuration à l'aide d'un modèle (Jinja2)
- enregistré dans un référentiel distant
- téléchargé la configuration créée sur l'équipement
- J'ai vu une erreur
- modifié le fichier YAML ou le modèle Jinja2
- créé un fichier de configuration à l'aide d'un modèle (Jinja2)
- ...
Il est clair qu'au début, beaucoup de temps a été consacré aux modifications, mais après une semaine ou deux, cela est devenu plutôt rare.
Un bon test et une opportunité de tout déboguer était le désir du client de changer la convention de dénomination. Ceux qui ont travaillé avec F5 comprennent le piquant de la situation. Mais pour moi, tout était assez simple. J'ai changé les noms dans le fichier YAML, supprimé toute la configuration de l'équipement, en ai généré une nouvelle et l'ai téléchargée. Tout, y compris les corrections de bugs, a pris 4 jours : deux jours pour chaque technologie. Après cela, j’étais prêt pour la prochaine étape, à savoir la création de datacenters DEV et Staging.
Développement et mise en scène
La mise en scène reproduit en fait complètement la production. Dev est une copie fortement allégée construite principalement sur du matériel virtuel. Une situation idéale pour une nouvelle approche. Si j'isole le temps que j'ai passé du processus global, alors je pense que le travail n'a pas pris plus de 2 semaines. Le temps principal est d'attendre l'autre côté et de rechercher ensemble les problèmes. La mise en œuvre d’un tiers est passée presque inaperçue auprès des autres. Il y avait même le temps d'apprendre quelque chose et d'écrire quelques articles sur Habré :)
Pour résumer
Alors, qu’est-ce que j’ai en fin de compte ?
- Tout ce que j'ai à faire pour modifier la configuration est de modifier un fichier YAML simple et clairement structuré avec des paramètres de configuration. Je ne change jamais le script python et très rarement (seulement s'il y a une erreur) je change le heatlate Jinja2
- Du point de vue de la documentation, c'est une situation presque idéale. Vous modifiez la documentation (les fichiers YAML servent de NIP) et téléchargez cette configuration sur l'équipement. De cette façon, votre documentation est toujours à jour
Tout cela a conduit au fait que
- le taux d'erreur est tombé à presque 0
- 90 pour cent de la routine a disparu
- la vitesse de mise en œuvre a considérablement augmenté
PAYER, F5Y, ACY
J'ai dit que quelques exemples suffisent pour comprendre comment cela fonctionne.
Voici une version courte (et bien sûr modifiée) de ce qui a été créé lors de mon travail.
= déploiement Palo Alto de Yaml = Palo Alto de Yaml
= déploiement F5 de Yaml = F5 de Yaml (à venir)
= déploiement ACje de Yaml = F5 de 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) n'a certainement pas été créé par des réseauteurs :). Oubliez tout ce que vous saviez sur le réseau, cela ne vous sera pas utile !
C’est un peu exagéré, mais cela traduit à peu près le sentiment que j’éprouve constamment, depuis 3 ans, en travaillant avec ACI.
Et dans ce cas, ACY n'est pas seulement l'opportunité de construire un processus de contrôle des modifications (ce qui est particulièrement important dans le cas d'ACI, car il est censé être la partie centrale et la plus critique de votre centre de données), mais vous donne également une interface conviviale pour créer une configuration.
Les ingénieurs de ce projet utilisent Excel pour configurer ACI au lieu de YAML exactement aux mêmes fins. Il y a bien sûr des avantages à utiliser Excel :
- votre NIP dans un seul fichier
- de belles enseignes agréables à regarder pour le client
- vous pouvez utiliser certains outils Excel
Mais il y a un inconvénient, et à mon avis, il l'emporte sur les avantages. Contrôler les changements et coordonner le travail d’équipe devient beaucoup plus difficile.
ACY est en fait une application des mêmes approches que celles que j'ai utilisées pour configurer ACI par un tiers.
Source: habr.com