Cet article est le sixième d'une série d'articles intitulée «Comment prendre l'infrastructure réseau sous votre contrôle». Le contenu de tous les articles de la série et les liens peuvent être trouvés ici .
Laissant quelques sujets de côté, j'ai décidé de commencer un nouveau chapitre.
Je serai de retour en sécurité un peu plus tard. Ici, je veux 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. Il s'agira de l'utilisation des temlates. À la fin est une liste de mes projets, où vous pouvez voir comment tout ce qui est décrit ici fonctionne.
DevOps pour le Web
Création d'une configuration avec un script, utilisation de GIT pour contrôler les changements dans l'infrastructure informatique, «remplissage» à distance - ces idées viennent en premier lorsque vous pensez à la mise en œuvre technique de l'approche DevOps. Les avantages sont évidents. Mais il y a malheureusement aussi des inconvénients.
Il y a plus de 5 ans, nos développeurs sont venus vers nous, les networkers, avec ces offres, nous n'étions pas enthousiastes.
Je dois dire que nous avons hérité d'un réseau plutôt hétéroclite composé de l'équipement d'une dizaine de fournisseurs différents. Quelque chose était pratique à configurer via notre interface utilisateur préférée, mais quelque part, nous avons préféré utiliser l'interface graphique. De plus, un long travail sur les équipements "sous tension" a été enseigné au contrôle en temps réel. Par exemple, lorsque je fais des changements, je me sens beaucoup plus à l'aise de travailler directement via cli. Je peux donc rapidement voir que quelque chose s'est mal passé et «annuler» les changements. Tout cela était en contradiction avec leurs idées.
D'autres questions se posent, par exemple, de la version à la version du logiciel, l'interface peut varier légèrement. En fin de compte, votre script créera la mauvaise «configuration». Je ne voudrais pas utiliser la production pour une effraction.
Ou, comment comprendre que 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 suffit de dire «A», il est probablement judicieux de dire «B», et si vous souhaitez utiliser les mêmes processus de contrôle des modifications qu'en développement, vous devez disposer d'environnements de développement et de transfert en plus de la production. Cette approche semble alors complète. Mais combien cela coûtera-t-il?
Mais il y a une situation où les inconvénients sont presque égalisés, et seuls les avantages restent. Je parle de travail de conception.
Projet
Au cours des deux dernières années, j'ai participé à un projet de construction d'un centre de données pour un fournisseur majeur. Je suis responsable du F5 et du Palo Alto dans ce projet. Du point de vue de Cisco, il s'agit de «l'équipement tiers».
Pour moi personnellement, il y a deux étapes distinctes dans ce projet.
Première étape
La première année, j'étais infiniment occupée, je travaillais la nuit et le week-end. Je n'ai pas pu 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. Ce n'était pas seulement et pas tant la configuration des équipements que la préparation de la documentation de conception.
Les premiers tests ont donc commencé et je serais étonné du nombre d'erreurs et d'inexactitudes mineures commises. Bien sûr, tout a fonctionné, mais la lettre dans le nom manquait, la ligne dans l'équipe manquait ici ... Les tests continuaient et continuaient, 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, si je comprends bien, n'a pas été facile pour tout le monde, mais progressivement le client est devenu de plus en plus satisfait, ce qui a permis d'engager des ingénieurs supplémentaires qui ont pu assumer une partie de la routine.
Maintenant, il était possible de regarder un peu autour.
Et ce fut 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 la communication avec les développeurs à l'époque (et nous devons rendre hommage, nous avions une équipe solide) est que le format texte, bien qu'il semble à première vue quelque chose du monde du système d'exploitation DOS, possède un certain nombre de propriétés précieuses .
Par exemple, un format texte sera utile si vous souhaitez profiter pleinement de GIT et de tous ses dérivés. Je le voulais.
Eh bien, il semblerait que vous puissiez simplement stocker une configuration ou une liste de commandes, mais faire des changements est plutôt gênant. De plus, lors de la conception, il y a une autre tâche importante. Vous devez disposer d'une documentation décrivant votre conception globale (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, lorsque vous utilisez YAML et Jinja2, le fichier YAML avec des paramètres de configuration, tels que les adresses IP, les numéros BGP AS, ... remplit parfaitement le rôle de NIP, tandis que les modèles Jinja2 incluent la syntaxe appropriée à la conception, c'est-à-dire, en fait, le reflet du LLD.
Il a fallu deux jours pour apprendre les langues 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 qui correspondent à notre conception: une semaine pour Palo Alto et une autre semaine pour F5. Tout cela a été publié sur Corporate Githab.
Maintenant, le processus de changement était le suivant:
- fichier yaml modifié
- 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
- vu une erreur
- fichier YAML ou modèle Jinja2 modifié
- 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é à l'édition, mais après une semaine ou deux, c'était déjà plus probablement une rareté.
Un bon test et la capacité de tout déboguer étaient le désir du client de changer la convention de dénomination. Qui a travaillé avec F5 comprend le piquant de la situation. Mais pour moi, c'était assez simple. J'ai changé les noms dans le fichier YAML, supprimé toute la configuration de l'équipement, généré un nouveau et téléchargé. Tout, en tenant compte des 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 des centres de données DEV et Staging.
Dev et mise en scène
La mise en scène répète en fait complètement la production. Dev est une copie fortement allégée construite principalement sur du matériel virtuel. Situation idéale pour une nouvelle approche. Si j'isoler le temps que j'ai passé du processus général, alors le travail, je pense, n'a pas pris plus de 2 semaines. Le temps principal est le temps d'attente de l'autre côté et une recherche commune des problèmes. La mise en œuvre de la 3e partie était presque invisible pour les autres. Il y avait même du temps pour enseigner quelque chose et écrire quelques articles sur Habré :)
Pour résumer
Alors qu'est-ce que j'ai en bout de ligne?
- tout ce qui est nécessaire pour moi de changer la configuration est de modifier un fichier YAML simple, 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 Jinja2
- du point de vue de la documentation, on obtient une situation presque idéale. Vous modifiez la documentation (les fichiers YAML agissent comme NIP) et téléchargez cette configuration sur l'équipement. Ainsi, votre documentation est toujours à jour.
Tout cela a conduit au fait que
- le pourcentage d'erreurs est passé à presque 0
- il a fallu 90 pour cent de la routine
- 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 brève (et bien sûr modifiée) de ce qui a été créé au cours de mon travail.
PAY = déploiement
P alo
A lto de
Y aml = Palo Alto de Yaml
F5Y = déploiement
F5 de
Y aml =
F5 de
Y aml (à venir bientôt)
ACY = déploiement
AC i de
Y aml =
F5 de
Y aml
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 pas été créé par des networkers :). Oubliez tout ce que vous saviez sur le réseau - il ne vous sera pas utile!
C'est un peu exagéré, mais cela donne à peu près le sentiment que je ressens constamment depuis 3 ans maintenant, en travaillant avec ACI.
Et dans ce cas, ACY n'est pas seulement une opportunité de construire un processus de contrôle des changements (ce qui est particulièrement important dans le cas d'ACI, car il est supposé qu'il s'agit de la partie centrale et la plus critique de votre centre de données), mais vous offre également une interface conviviale pour créer une configuration.
Les ingénieurs de ce projet utilisent Excel pour utiliser ACI au lieu de YAML dans le même but. Bien sûr, l'utilisation d'Excel présente certains avantages:
- votre pincement dans un seul fichier
- beaux signes que le client est content de regarder
- vous pouvez utiliser des 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 applique en fait les mêmes approches que celles que j'ai utilisées pour les tiers pour configurer ACI.