Qu’est-ce que le NetDevOps ?
Le NetDevOps, c’est tout simplement les techniques et la culture DevOps appliquées au domaine du réseau. Cela prend doucement de l’ampleur depuis quelques années.On trouve parfois aussi l’appellation DevNetOps. Je ne vais pas m’étendre sur le DevOps, tout le monde en a entendu parler, il y a déjà beaucoup d’article sur le sujet, mais rappelons en tout de même les principes de base avec le modèle CAMS : Culture Automation Measurement Sharing
- Culture : Le DevOps est une culture, et tous les outils du monde ne feront pas d’un ingénieur réseau un NetDevOps sans adhérer à cette nouvelle façon de travailler.
- Automation : Il faut automatiser au maximum tous les processus : tests, déploiement, configuration …
- Measurement : La surveillance de l’infrastructure est un point clé pour l’objectif numéro 1 : l’amélioration continue.
- Sharing : Il est essentiel de partager le savoir, les bonnes pratiques et les responsabilités. D’abord au sein de l’équipe réseau, mais aussi plus largement avec l’ensemble de la production.
Pourquoi faire ?
L’objectif est d’augmenter l’efficacité et la fiabilité des changements sur l’infrastructure réseau et sécurité. Le DevOps et l’automatisation sont maintenant devenus standards sur le système et les applications. On déploie des machines virtuelles pour des utilisateurs ou des applications en quelques minutes, personne n’a envie d’être bloqué parce qu’il faut attendre l’intervention de l’équipe réseau pour une configuration Load Balancer, ou pour une ouverture d’un flux firewall qui prendra des jours.
Les pratiques
Voyons quelles sont les pratiques DevOps applicables au réseau.
Programmabilité du réseau
C’est la clé pour mettre en place la suite des pratiques NetDevOps. Il faut automatiser toutes les étapes : le déploiement, les tests, la surveillance, etc. Contrairement à une idée reçue, l’automatisation des tâches de configuration de notre infrastructure ne va pas réduire la charge de travail de l’équipe réseau. Cela va permettre de livrer plus rapidement, et les ressources économisées sur les tâches répétitives seront déplacées sur des tâches à plus forte valeur ajoutée. Il faut penser, développer et maintenir l’outillage nécessaire et cela prend du temps : on a pas envie de modifier la configuration de son parc entier avant d’avoir pris le soin de tester et valider cette automatisation sur un environnement de test, et des évolutions seront toujours nécessaires avec l’arrivée de nouveaux cas d’usage. La plus grosse plus-value de l’automatisation, c’est que les machines ne se trompent pas. Elles peuvent répéter cent fois la même configuration, elle sera à chaque fois identique. Les changements manuels sont toujours soumis au risque d’erreur humaine et provoquent des configurations disparates. Chaque ingénieur peut configurer de manière légèrement différente un équipement par rapport à son collègue, parce qu’il applique une nomenclature différente pour nommer les objets, parce qu’il customise un timer, ou ajoute une option qui n’est pas forcément dans le standard. L’automatisation impose de facto l’uniformisation des configurations, et minimise les erreurs sur les changements courants.
Infrastructure as Code
L’IaC est une pratique DevOps facilement transposable au NetDevOps. Il faut traiter les configurations réseau comme si c’était du code. Cela veut dire utiliser un outil de gestion de version de code. Git est le standard de facto pour le moteur de gestion de code, plusieurs outils sont basés dessus : GitHub, Bitbucket, Gitlab, Gitea … Cela à plusieurs bénéfices :
- La configuration présente dans le repository devient le standard, la source de confiance. C’est cette configuration qui doit être déployée sur tout nouvel équipement, et les déviations entre les configurations en production et celle-ci doivent être comblées.
- Le versioning permet de pouvoir suivre les changements (ou commit) effectués sur notre standard. Grâce aux fonctionnalités de Git on sait qui a fait quoi, quand et pour quelle raison. On peut également facilement revenir à une version antérieure en cas de problème.
- Git va nous permettre, grâce au système de branches, de gérer des configurations de production qu’on sait stables, et des versions de développement qui ont encore besoin d’être testées.
CI/CD
Un des principes du DevOps est de banaliser le changement. Il ne doit plus être vu comme une opération importante, complexe et risquée, mais comme un événement régulier, minime et maîtrisé grâce à une chaîne de CI/CD : Continuous Integration / Continuous Delivery L’intégration continue consiste à mettre en place des tests automatisés pour valider chaque changement sur notre code et donc sur notre infrastructure. Des outils comme Jenkins ou Gitlab CI peuvent être utilisés. En général le déroulé est le suivant :
- La modification sur notre infrastructure : Comme l’infrastructure est traitée comme du code, cela se traduit par un commit sur une branche de développement qu’on pousse ensuite sur notre repository central.
- Continuous Integration : la nouvelle configuration est déployée sur une infrastructure d’intégration (qui peut être virtualisée grâce à des outils comme GNS3 ou VIRL) et ensuite validée via des tests automatisés.
- Continuous Delivery : Si les tests détectent une erreur, le commit sera rejeté et il faudra le corriger. Sinon il sera automatiquement intégré à notre branche de production (merge de la branche de développement sur la branche de production) et prêt à être déployé en production
- Continuous Deployment : Cette dernière étape optionnelle permet d’aller encore plus loin, en déployant de façon automatisée tous les changements qui sont acceptés sur la branche de production. Cela demande bien sûr d’avoir absolument confiance dans les tests effectués, et en général on préfère déclencher le déploiement manuellement (mais ce déploiement doit bien sûr être automatisé !)
Comment devenir un NetDevOps ?
Évidemment un tel changement ne peut pas se faire en un jour. On ne peut pas directement mettre en place une chaîne de CI/CD si on part de zéro. Il faut donc commencer par cibler les activités que l’on peut automatiser. On cherchera en premier lieu les tâches qui apporteront le meilleur retour sur investissement : des tâches répétitives, peu complexes et peu risquées comme par exemple la configuration de VLANs sur une interface, où bien les tests après mise à jour d’un équipement. Ensuite il faut choisir ses armes. Et pour savoir quels outils utiliser, la première chose à prendre en compte, c’est l’existant : quelles sont les pratiques dans les autres équipes, quels outils sont déjà utilisés, quelles sont les compétences dans l’équipe. On peut quand même citer quelques outils incontournable qui seront toujours bénéfiques à connaître :
- Git : c’est devenu le standard de la gestion de code, il est important d’en appréhender les principes
- Python : S’il faut choisir un langage de programmation aujourd’hui, ce serait sûrement celui-là. On le trouve partout
- Ansible : c’est un outil de gestion de configuration qui est très utilisé pour la partie réseau. Il y a bien sûr d’autres concurrents (Chef, Puppet …)
Conclusion
Cet article a permis d’introduire les concepts liés à cette mouvance qu’est le NetDevOps. Dans des prochains articles, nous pourrons approfondir certains aspects particuliers et expliquer plus en détails quelques mises en pratique.