{"id":34742,"date":"2019-10-31T22:00:10","date_gmt":"2019-10-31T19:00:10","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-chetvertaya-avtomatizatsiya-templejty\/"},"modified":"2019-10-31T22:00:10","modified_gmt":"2019-10-31T19:00:10","slug":"kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-chetvertaya-avtomatizatsiya-templejty","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-chetvertaya-avtomatizatsiya-templejty","title":{"rendered":"Comment prendre le contr\u00f4le de l'infrastructure r\u00e9seau. Chapitre quatre. Automatisation. Mod\u00e8les","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Cet article est le sixi\u00e8me d'une s\u00e9rie sur \u00ab Comment prendre le contr\u00f4le de son infrastructure r\u00e9seau \u00bb. Vous pouvez trouver le contenu de tous les articles de la s\u00e9rie et les liens. ici<\/a><\/noindex><\/i>.<\/p>\n

Apr\u00e8s avoir laiss\u00e9 quelques sujets derri\u00e8re moi, j'ai d\u00e9cid\u00e9 de commencer un nouveau chapitre.<\/p>\n

Je reviendrai plus tard sur la s\u00e9curit\u00e9. Ici, je souhaite discuter d'une approche simple mais efficace qui, j'en suis s\u00fbr, peut \u00eatre utile \u00e0 beaucoup d'entre vous, d'une mani\u00e8re ou d'une autre. C'est plut\u00f4t une courte histoire sur la fa\u00e7on dont l'automatisation peut transformer la vie d'un ing\u00e9nieur. Je vais parler de l'utilisation de templates. \u00c0 la fin, vous trouverez une liste de mes projets o\u00f9 vous pourrez voir comment tout cela fonctionne.<\/p>\n

DevOps pour le r\u00e9seau<\/h2>\n

\nCr\u00e9er une configuration via un script, utiliser GIT pour le contr\u00f4le des changements dans l'infrastructure IT, le \u00ab push \u00bb \u00e0 distance \u2014 ces id\u00e9es viennent imm\u00e9diatement \u00e0 l'esprit lorsque l'on pense \u00e0 la mise en \u0153uvre technique de l'approche DevOps. Les avantages sont \u00e9vidents. Mais, h\u00e9las, il y a aussi des inconv\u00e9nients.<\/p>\n

Il y a plus de 5 ans, lorsque nos d\u00e9veloppeurs sont venus nous voir, nous, les r\u00e9seaux, avec ces propositions, nous n'\u00e9tions pas enthousiastes.
\n<\/a><\/noindex>
\nIl convient de dire que nous avons h\u00e9rit\u00e9 d'un r\u00e9seau assez h\u00e9t\u00e9roclite, compos\u00e9 d'\u00e9quipements provenant d'une dizaine de diff\u00e9rents fournisseurs. Certaines configurations \u00e9taient faciles \u00e0 r\u00e9aliser via notre cli pr\u00e9f\u00e9r\u00e9, mais pour d'autres, nous pr\u00e9f\u00e9rions utiliser l'interface graphique. De plus, ma longue exp\u00e9rience sur du mat\u00e9riel \u00ab en production \u00bb m'a habitu\u00e9 \u00e0 un contr\u00f4le en temps r\u00e9el. Personnellement, lorsque j'apporte des modifications, je me sens beaucoup plus \u00e0 l'aise de travailler directement via cli. Cela me permet de voir rapidement si quelque chose ne va pas et de \u00ab revenir en arri\u00e8re \u00bb sur les changements. Tout cela contredisait quelque peu leurs id\u00e9es.<\/p>\n

Il y a d'autres questions qui se posent, par exemple que l'interface peut l\u00e9g\u00e8rement changer d'une version de logiciel \u00e0 l'autre. Cela finira par entra\u00eener le fait que votre script produit une \u00ab configuration \u00bb incorrecte. Je ne voudrais pas utiliser la production pour des tests. <\/p>\n

Ou comment savoir si les commandes de configuration ont \u00e9t\u00e9 appliqu\u00e9es correctement et que faire en cas d'erreur ?<\/p>\n

Je ne veux pas dire que toutes ces questions sont insolubles. Il est peut-\u00eatre raisonnable de dire \u00ab A \u00bb et aussi \u00ab B \u00bb et, si vous souhaitez utiliser les m\u00eames processus de contr\u00f4le des changements que ceux de d\u00e9veloppement, vous devez disposer, en plus de la production, des environnements de d\u00e9veloppement et de staging. Alors cette approche semble compl\u00e8te. Mais combien cela va-t-il co\u00fbter ?<\/p>\n

Cependant, il existe une situation o\u00f9 les inconv\u00e9nients sont pratiquement annul\u00e9s et il ne reste que des avantages. Je parle des travaux de projet.<\/p>\n

Projet<\/h2>\n

\nAu cours des deux derni\u00e8res ann\u00e9es, j'ai particip\u00e9 \u00e0 un projet de construction de centre de donn\u00e9es pour un grand fournisseur. Je suis responsable de l'\u00e9quipement F5 et Palo Alto dans ce projet. D'un point de vue Cisco, il s'agit d'\u00e9quipement de \u00ab tiers parti \u00bb.<\/p>\n

Pour moi, il y a deux phases clairement d\u00e9finies dans ce projet. <\/p>\n

Premi\u00e8re phase<\/h3>\n

\nLa premi\u00e8re ann\u00e9e, j'\u00e9tais constamment occup\u00e9, je travaillais la nuit et le week-end. Je ne pouvais pas lever la t\u00eate. La pression de la direction et du client \u00e9tait forte et continue. Dans cette routine quotidienne, je ne pouvais m\u00eame pas essayer d'optimiser le processus. Ce n'\u00e9tait pas seulement, voire pas tant, la configuration de l'\u00e9quipement, mais aussi la pr\u00e9paration de la documentation projet. <\/p>\n

Les premiers tests ont commenc\u00e9, et j'\u00e9tais surpris du nombre d'erreurs et d'inexactitudes qui avaient \u00e9t\u00e9 commises. Bien s\u00fbr, tout fonctionnait, mais il manquait une lettre dans un nom, une ligne \u00e9tait omise dans une commande... Les tests se poursuivaient, et j'\u00e9tais d\u00e9j\u00e0 en lutte permanente, quotidienne, avec les erreurs, les tests et la documentation. <\/p>\n

Cela a dur\u00e9 un an. Selon ma compr\u00e9hension, le projet n'\u00e9tait pas simple pour tout le monde, mais progressivement, le client devenait de plus en plus satisfait, ce qui a permis d'engager des ing\u00e9nieurs suppl\u00e9mentaires pouvant prendre en charge une partie de la routine.<\/p>\n

Maintenant, je pouvais un peu lever les yeux.
\nEt cela marquait le d\u00e9but de la deuxi\u00e8me \u00e9tape. <\/p>\n

Deuxi\u00e8me phase<\/h3>\n

\nJ'ai d\u00e9cid\u00e9 d'automatiser le processus.<\/p>\n

Ce que j'ai compris \u00e0 l'\u00e9poque \u00e0 travers les \u00e9changes avec les d\u00e9veloppeurs (et il faut reconna\u00eetre que nous avions une \u00e9quipe solide), c'est que le format texte, bien qu'il semble d'abord appartenir \u00e0 l'univers des syst\u00e8mes d'exploitation DOS, poss\u00e8de plusieurs propri\u00e9t\u00e9s pr\u00e9cieuses.
\nPar exemple, le format texte sera utile si vous souhaitez pleinement tirer parti de GIT et de tous ses d\u00e9riv\u00e9s. Et je le voulais. <\/p>\n

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\u00e2che importante se pose. Vous devez disposer d'une documentation d\u00e9crivant votre conception dans son ensemble (Low Level Design) et une mise en \u0153uvre sp\u00e9cifique (Network Implementation Plan). Dans ce cas, l'utilisation de mod\u00e8les semble \u00eatre une option tr\u00e8s appropri\u00e9e.<\/p>\n

Ainsi, en utilisant YAML et Jinja2, le fichier YAML avec les param\u00e8tres de configuration, tels que les adresses IP, les num\u00e9ros BGP AS, etc., joue parfaitement le r\u00f4le de NIP, tandis que les mod\u00e8les Jinja2 comprennent une syntaxe correspondant au design, c'est-\u00e0-dire qu'ils refl\u00e8tent en essence le LLD. <\/p>\n

L'\u00e9tude des langages YAML et Jinja2 a pris deux jours. Pour comprendre comment cela fonctionne, quelques bons exemples suffisent. Ensuite, environ deux semaines ont \u00e9t\u00e9 n\u00e9cessaires pour cr\u00e9er tous les mod\u00e8les correspondant \u00e0 notre design : une semaine pour Palo Alto et une autre semaine pour F5. Tout cela a \u00e9t\u00e9 mis en ligne sur notre githab d'entreprise.<\/p>\n

Le processus de modification se pr\u00e9sentait d\u00e9sormais comme suit :<\/p>\n