La migration de ces outils est composée de deux parties :

  • Les outils du legacy : Kanboard (gestion de projet avec tableau Kanban) et Gitea (stockage et gestion de code/configuration, similaire à GitHub et GitLab)

  • Les outils à migrer : Oxidized (sauvegarde des équipements de backbone), NetBox (inventaire des appareils du réseau, adresses IP, etc.)

Le legacy

Migration de Kanboard

La migration de Kanboard a été simple à réaliser. Elle s’est découpée en plusieurs étapes :

  • Identification des VM
  • Sauvegarde de la base de données PostgreSQL
  • Création du Terraform pour déployer Kanboard et PostgreSQL sur le cluster Kubernetes
  • Importation de la sauvegarde de la base de données
  • Mise en production

Identification des VM

Le legacy dispose d’un schéma qui décrit comment tout est interconnecté et où se trouvent les différentes VM. Dans notre cas, il y avait deux bulles :

  • Business : pour les VM comme celle d’Oxidized (donc avec un accès au réseau de l’entreprise)

  • Management : pour les VM utilisées pour gérer l’infrastructure.

Dans le cas de Kanboard, il y avait deux VM : une pour PostgreSQL et une pour l’application.

Sauvegarde de la base de données

Pour sauvegarder la base de données, j’ai utilisé l’outil intégré à PostgreSQL, pg_dump. La commande avait cette structure :

pg_dump -U <utilisateur> -h <hôte> -F c -b -v -f <chemin/vers/dump> <nom_de_la_base>

Avec les valeurs réelles :

pg_dump -U kanboard -h localhost -F c -b -v -f /root/dumpkanboard kanboard
cp /root/dumpkanboard /home/nphilipsinibaldi/dumpkanboard
chown -R nphilipsinibaldi:nphilipsinibaldi /home/nphilipsinibaldi/dumpkanboard

Ensuite, j’ai copié la base de données sur mon poste avec la commande scp (similaire à cp, mais à travers SSH). J’aurais également pu utiliser un outil comme rsync :

mkdir -p /home/nphilipsinibaldi/workspace/backup/
scp nphilipsinibaldi@kanboard.management.31tls00.ef-fr.net:/root/dumpkanboard /home/nphilipsinibaldi/workspace/backup/dumpkanboard

Création du Terraform pour déployer Kanboard et PostgreSQL sur le cluster Kubernetes

Le code Terraform est présent dans le dépôt Git sur mon GitLab à cette adresse : place holder

Importation de la sauvegarde de la base de données

Pour réimporter la base de données, j’ai d’abord déployé uniquement le manifeste concernant PostgreSQL, puis, avec kubectl, j’ai fait un proxy pour exposer le port de la base en local afin de pouvoir y réimporter les données.

kubectl -n <namespace> port-forward svc/<nom-du-service> 5432:5432

Mise en production

La mise en production est simple : tout déployé.

Migration de Gitea

La migration de Gitea n’a pas été compliquée :

  • Copie en local de tous les dépôts
  • Création du Terraform pour déployer Gitea et PostgreSQL sur le cluster Kubernetes
  • Création d’une clé d’API sur Gitea et utilisation d’un script

Copie en local de tous les dépôts

Pour la copie, j’ai simplement utilisé des commandes git clone.

Création du Terraform pour déployer Gitea et PostgreSQL sur le cluster Kubernetes

Le code Terraform est présent dans le dépôt Git sur mon GitLab à cette adresse : place holder

Création d’une clé d’API sur Gitea et utilisation d’un script

La clé d’API a été créée avec l’utilisateur par défaut, ici eurofiber, disposant de tous les droits d’administration.

Ensuite, j’ai rédigé un script permettant, à partir d’un dossier, de recréer toute l’arborescence des organisations et de réimporter tous les dépôts dans le nouveau Gitea :

mettre le script ici

La nouvelle infrastructure

Oxidized

Pour Oxidized, le procédé était différent. J’ai uniquement eu à écrire le code Terraform permettant de le déployer sur le cluster Kubernetes. Ce code est disponible dans mon GitLab.

La méthode de fonctionnement reste identique à celle du legacy. Les principales différences résident dans la version d’Oxidized et la méthode de déploiement.

NetBox

Concernant Netbox, le procede etait grossierement le meme, il a fallu :

  • Backup la base de donnees
  • Faire le code Terraform pour deployer le Helm Chart avec la meme version de NetBox (Une template avec des manifests Kubernetes qui se genere a l’aide d’un fichier de variables)
  • Reimporter la base de donnees (de la meme maniere que Kanboard)
  • Mettre a jour le netbox
  • Refaire la base d’utilisateur avec tout leurs droits