Automatisation backup réseau

Présentation du projet

La gestion manuelle des sauvegardes de configuration sur un parc réseau mondial induit des risques réels : oublis, incohérences de version, et en cas de remplacement d'équipement non planifié ou de besoin de rollback suite à un change mal effectué, une reconfiguration depuis zéro. J'ai développé une solution NetDevOps pour automatiser l'extraction des configurations de l'ensemble des réseaux Criteo via l'API REST Meraki, l'API Palo Alto et du scripting avec un task scheduler pour le backup de Kemp et la création d'ARM templates.

Ce projet a été mené en autonomie totale de l'analyse du besoin au déploiement en production, avec la supervision de mon maître d'apprentissage via une présentation finale du code et de la documentation à l'équipe Network pour validation.

Étapes et acteurs

Ce projet a été mené en autonomie totale. La première étape a été de faire l'inventaire précis de tout ce qu'il fallait couvrir : 11 réseaux Meraki à l'échelle mondiale (plus de 350 devices au total), 1 firewall Palo Alto, 4 nœuds VPN ASA et 2 VM Kemp. À partir de là, j'ai défini le périmètre fonctionnel avec mon maître d'apprentissage et j'ai commencé l'étude des APIs disponibles sur chaque plateforme.

L'étude a mis en évidence des contraintes différentes selon les constructeurs. Pour Meraki, l'API REST est bien documentée et une clé Read Only suffit. Pour Palo Alto, c'est plus délicat : il n'existe pas de clé Read Only possible pour les exports de config, ce qui m'a obligé à utiliser une clé Read/Write et à gérer le risque associé (isolation des permissions, stockage sécurisé), confirmé avec le support Palo Alto. Pour Kemp, pas d'API REST exploitable pour ce cas d'usage : j'ai utilisé la fonction native des LoadMasters permettant de pousser leur configuration directement vers un serveur FTP de backup, sans passer par le script Python.

Plutôt que de monter un nouveau serveur, j'ai réutilisé un ancien serveur FTP déjà en place (sous FileZilla), derrière notre firewall, pour stocker les backups de façon sécurisée et isolée du reste du réseau. J'y ai défini la structure des dossiers : un répertoire par type d'appliance, avec un fichier de configuration par équipement horodaté pour garder l'historique et détecter toute dérive entre deux backups.

Le script est développé en Python 3.x avec la librairie Requests. Les clés API sont stockées en variables d'environnement pour éviter toute fuite dans le code. Il appelle les endpoints de chaque constructeur, récupère la configuration au format natif (JSON pour Meraki, XML pour Palo Alto), et dépose le fichier sur le FTP avec un nommage incluant le nom de l'équipement et la date d'exécution. Son exécution est planifiée via le task scheduler du serveur, le samedi vers 3 h du matin. Les Kemp alimentent le même FTP en direct via leur option de backup native. En complément, j'ai produit des ARM templates pour sauvegarder non seulement la configuration des appliances, mais aussi les machines (VM) sur lesquelles elles tournent.

Le monitoring était un point critique : les backups s'exécutent une fois par semaine sans personne pour surveiller. J'ai développé un script de vérification qui maintient une baseline du nombre de fichiers attendus par dossier. Si chaque dossier contient bien X+1 fichiers après exécution, le backup est considéré comme réussi et un mail récapitulatif est envoyé automatiquement à toute l'équipe réseau avec le statut de chaque équipement.

Une fois le code stabilisé sur plusieurs exécutions, j'ai présenté la solution à l'équipe Network avec la documentation associée. Mon maître d'apprentissage a validé avant la mise en production. Le script tourne depuis en automatique chaque weekend, sans aucune intervention manuelle.