Infrastructure TuxForge

Restauration des données

L'environnement Monitoring a été le premier à être migré vers la nouvelle infrastructure. Ce choix m'a permis de disposer rapidement d'outils de supervision afin de suivre l'état des nouvelles machines virtuelles pendant la suite du projet.

Après le transfert de l'archive vers la machine virtuelle dédiée au monitoring, j'ai procédé à son extraction puis à la restauration de l'arborescence Docker utilisée sur l'ancienne infrastructure.

L'ensemble des fichiers de configuration ainsi que les données persistantes de Grafana, Prometheus et Uptime Kuma ont ainsi été restaurés.

Remise en service des applications

Une fois les données restaurées, j'ai vérifié le contenu du fichier docker-compose.yml.

Après vérification de la configuration, les conteneurs ont été redémarrés à l'aide de Docker Compose.

Les applications concernées étaient :

• Grafana ;
• Prometheus ;
• Uptime Kuma.

Adaptation de la supervision

La migration vers une architecture composée de plusieurs machines virtuelles a nécessité une évolution de la supervision.

Sur l'ancienne machine Ubuntu, l'ensemble des services étant hébergé sur un seul serveur, Prometheus collectait directement les métriques locales.

Avec la nouvelle architecture, l'environnement de supervision a été isolé dans une machine virtuelle dédiée afin de centraliser la collecte et l'analyse des métriques.

J'ai également déployé Node Exporter et cAdvisor sur les différentes machines virtuelles afin de permettre la collecte centralisée des métriques système et Docker.

J'ai ensuite adapté la configuration de Prometheus afin d'ajouter les nouvelles cibles de supervision.

Mise à jour du reverse proxy

Après la migration des services, j'ai reconfiguré Nginx Proxy Manager afin que les sous-domaines pointent vers la nouvelle machine virtuelle Monitoring.

Les redirections suivantes ont notamment été mises à jour :

Sous-domaine	Destination
grafana.tuxforge.eu	192.168.1.101
status.tuxforge.eu	192.168.1.101

Cette étape a permis de conserver les URL existantes tout en redirigeant les utilisateurs vers les services désormais hébergés sur la nouvelle infrastructure.

Validation

Après le redémarrage des conteneurs, plusieurs vérifications ont été réalisées :

• démarrage des conteneurs ;
• prise en compte de la configuration ;
• collecte des métriques par Prometheus ;
• détection des nouvelles machines virtuelles.

L'environnement de supervision était alors opérationnel et prêt à accompagner les migrations suivantes. Cette première réussite a permis de disposer immédiatement d'une visibilité sur l'état des nouvelles machines virtuelles avant la migration des autres services.

Retour d'expérience

Cette première migration m'a permis de valider la méthode d'archivage, de transfert et de restauration qui sera utilisée pour l'ensemble du projet.

Le choix de migrer l'environnement Monitoring en premier s'est révélé particulièrement pertinent. Une fois la supervision remise en service, j'ai pu suivre l'utilisation des ressources des nouvelles machines virtuelles, valider les déploiements réalisés et identifier rapidement les éventuels problèmes rencontrés lors des migrations suivantes.

Présentation de l'environnement

L'environnement IAM constitue le cœur de l'infrastructure TuxForge. Il regroupe plusieurs services essentiels au fonctionnement de la plateforme :

• Authentik ;
• PostgreSQL ;
• Redis ;
• Nginx Proxy Manager ;
• Le site web TuxForge ;
• le backend TuxForge.

Cette machine virtuelle assure à la fois la gestion des identités, la publication des services sur Internet et l'hébergement du site présentant le projet.

Migration d'Authentik

Authentik étant utilisé comme fournisseur d'identité centralisé de l'infrastructure, sa migration constituait une étape importante du projet. Ce service assure l'authentification des utilisateurs et centralise les accès aux différentes applications auto-hébergées.

Restauration des données

Après le transfert de l'archive vers la machine virtuelle IAM, j'ai procédé à sa décompression puis à la restauration de l'arborescence Docker d'origine.

L'organisation des répertoires a été conservée afin de limiter les modifications de configuration et de simplifier la remise en service des conteneurs.

Les services restaurés étaient :

• PostgreSQL ;
• Redis ;
• Authentik Server ;
• Authentik Worker.

Une attention particulière a été portée aux volumes PostgreSQL contenant l'ensemble des utilisateurs, groupes, applications et paramètres d'Authentik.

Redémarrage des services

Une fois les fichiers restaurés, j'ai relancé l'ensemble des conteneurs.

J'ai ensuite vérifié leur état :

Cette vérification m'a permis de confirmer que les quatre conteneurs étaient correctement démarrés et qu'aucun redémarrage en boucle n'était observé.

Vérification du fonctionnement

La première étape a consisté à contrôler le démarrage de PostgreSQL et Redis en consultant les journaux Docker.

J'ai ensuite vérifié le fonctionnement des composants Authentik :

L'absence d'erreurs liées à PostgreSQL ou Redis a permis de confirmer le bon fonctionnement des dépendances nécessaires à Authentik.

Une connexion à l'interface d'administration a ensuite été réalisée afin de vérifier :

• la présence des utilisateurs ;
• les groupes ;
• les applications ;
• les fournisseurs d'identité ;
• les flux d'authentification.

L'ensemble de la configuration précédemment mise en place était toujours présent après migration.

Validation

Après restauration, les vérifications suivantes ont été réalisées :

• accès à l'interface d'administration ;
• authentification avec les comptes existants ;
• présence des applications configurées ;
• fonctionnement des services PostgreSQL et Redis ;
• absence d'erreurs dans les journaux Docker.

Ces contrôles ont permis de confirmer que la migration s'était déroulée sans perte de données ni reconfiguration majeure.

Retour d'expérience

La migration d'Authentik s'est déroulée sans difficulté majeure grâce à la conservation de l'arborescence Docker d'origine et des volumes PostgreSQL contenant l'ensemble des données de l'application.

Cette étape m'a permis de mieux comprendre les dépendances entre Authentik, PostgreSQL et Redis ainsi que l'importance des volumes persistants dans les applications conteneurisées.

Certaines intégrations avec d'autres applications, notamment Uptime Kuma et Nginx Proxy Manager, n'étaient pas pleinement fonctionnelles avant la migration et sont restées dans le même état après restauration. Ces limitations ne sont donc pas liées à la migration elle-même mais à la configuration des intégrations concernées.

Migration de Nginx Proxy Manager

Nginx Proxy Manager constitue le point d'entrée principal de l'infrastructure TuxForge. Ce service assure la publication des différentes applications sur Internet, la gestion des certificats SSL Let's Encrypt ainsi que les redirections HTTPS.

Sa migration était particulièrement importante car l'ensemble des services hébergés sur l'infrastructure dépendent de son bon fonctionnement.

Restauration des données

Après le transfert de l'archive vers la machine virtuelle IAM, j'ai procédé à sa décompression puis à la restauration de l'arborescence Docker d'origine.

Les volumes Docker contenant la configuration de Nginx Proxy Manager ont été restaurés afin de conserver :

• les Proxy Hosts ;
• les certificats SSL ;
• les redirections ;
• les paramètres de publication des services.

Cette approche a permis d'éviter une reconfiguration complète de l'application.

Redémarrage du service

Une fois les données restaurées, le conteneur a été redémarré à l'aide de Docker Compose.

J'ai ensuite vérifié son état :

Cette vérification m'a permis de confirmer que le conteneur était correctement démarré et qu'aucun redémarrage en boucle n'était observé.

Vérification du fonctionnement

Une fois le conteneur démarré, j'ai contrôlé l'accès à l'interface d'administration.

J'ai également vérifié la présence des différents Proxy Hosts configurés avant la migration ainsi que la conservation des certificats SSL.

Les journaux Docker ont été consultés afin de détecter d'éventuelles erreurs au démarrage.

L'absence d'erreurs critiques dans les journaux a permis de confirmer le bon démarrage du service et le chargement correct de la configuration restaurée.

Adaptation de la configuration

Contrairement aux autres applications migrées, Nginx Proxy Manager dépend directement de l'ensemble des services publiés.

Après la migration, plusieurs destinations ont dû être mises à jour afin de prendre en compte les nouvelles adresses IP des machines virtuelles créées sous Proxmox.

Par exemple :

Service	Nouvelle destination
Grafana	192.168.1.101
Uptime Kuma	192.168.1.101
Forgejo	192.168.1.103
Vaultwarden	192.168.1.104
Nextcloud	192.168.1.105

Cette étape a nécessité une vérification progressive des différents Proxy Hosts au fur et à mesure de la migration des services.

Après chaque modification, j'ai testé l'accès aux différents sous-domaines depuis un navigateur afin de vérifier que les requêtes étaient correctement redirigées vers les nouvelles machines virtuelles.

Vérification des certificats SSL

Une attention particulière a été portée aux certificats Let's Encrypt.

Les vérifications ont porté sur :

• la présence des certificats existants ;
• leur validité ;
• les redirections HTTP vers HTTPS ;
• le renouvellement automatique.

J'ai également vérifié depuis un navigateur la présence du cadenas HTTPS ainsi que les informations des certificats présentés par les différents services publiés.

Ces contrôles ont permis de confirmer que les services restaient accessibles de manière sécurisée après migration.

Difficultés rencontrées

La principale difficulté rencontrée concernait les dépendances entre Nginx Proxy Manager et les autres services de l'infrastructure.

Bien que Nginx Proxy Manager soit parfaitement fonctionnel, certains Proxy Hosts retournaient des erreurs 502 Bad Gateway.

Après analyse, le problème ne provenait pas du reverse proxy lui-même mais des applications cibles qui n'avaient pas encore été migrées ou dont la configuration n'était pas encore finalisée.

Une partie du travail a également consisté à vérifier les enregistrements DNS du domaine tuxforge.eu ainsi que les URL utilisées par les applications protégées par Authentik. Une incohérence entre un nom de domaine, une adresse IP ou une URL de redirection pouvait empêcher l'accès aux services ou perturber le fonctionnement du SSO.

Validation

Après les différentes modifications, les vérifications suivantes ont été réalisées :

• accès à l'interface Nginx Proxy Manager ;
• présence des Proxy Hosts ;
• présence des certificats SSL ;
• fonctionnement des redirections HTTPS ;
• accès aux services déjà migrés.

L'ensemble des fonctionnalités principales de Nginx Proxy Manager était opérationnel après migration.

Retour d'expérience

Cette migration m'a permis de mieux comprendre le rôle central d'un reverse proxy dans une infrastructure distribuée.

Contrairement aux autres applications migrées, Nginx Proxy Manager dépend directement de la disponibilité des services qu'il publie. Cette étape a mis en évidence l'importance de l'ordre de migration ainsi que la nécessité de vérifier systématiquement les adresses IP, les noms de domaine et les certificats SSL lors du déplacement d'applications entre plusieurs serveurs.

Cette migration a également marqué ma première expérience de gestion d'un reverse proxy publiant plusieurs applications réparties sur des machines virtuelles distinctes.

Migration du Backend TuxForge

Le backend TuxForge est une application développée en Node.js permettant de centraliser et fournir les données dynamiques utilisées par le site web. Il assure notamment la récupération d'informations provenant des différents services de l'infrastructure afin d'alimenter les pages du portail TuxForge.

Restauration des données

Après le transfert de l'archive vers la machine virtuelle IAM, j'ai procédé à sa décompression puis à la restauration de l'arborescence Docker d'origine.

L'ensemble des fichiers du projet ainsi que le fichier docker-compose.yml ont été restaurés sans modification de la structure initiale.

Redémarrage du service

Une fois les fichiers restaurés, j'ai relancé le conteneur du backend.

J'ai ensuite vérifié son état :

Cette vérification m'a permis de confirmer que le conteneur était correctement démarré et qu'aucun redémarrage en boucle n'était observé.

Adaptation de la configuration

La migration vers une architecture composée de plusieurs machines virtuelles a nécessité l'adaptation de plusieurs paramètres de configuration.

Dans la première version de l'infrastructure, l'ensemble des services était hébergé sur une unique machine virtuelle Ubuntu. Après la migration, les applications étaient réparties sur plusieurs serveurs disposant chacun de leur propre adresse IP.

J'ai donc dû mettre à jour les différentes références utilisées par le backend afin qu'il puisse continuer à communiquer avec les services de supervision et les applications désormais hébergées sur d'autres machines virtuelles.

Cette étape était indispensable pour permettre au site d'afficher les données réelles de l'infrastructure.

Vérification du fonctionnement

Après le démarrage du service, j'ai consulté les journaux du conteneur afin de détecter d'éventuelles erreurs liées au lancement de l'application.

L'absence d'erreurs critiques dans les journaux a permis de confirmer le bon démarrage du backend.

J'ai ensuite accédé directement à l'endpoint exposé via Nginx Proxy Manager afin de vérifier que l'application retournait correctement les données utilisées par le site TuxForge.

https://backend.tuxforge.eu/status

Cette route retourne les informations collectées par le backend au format JSON, notamment l'état des services supervisés ainsi que certaines statistiques de l'infrastructure.

La présence des informations attendues a permis de confirmer :

• le bon fonctionnement du backend ;
• la récupération des données depuis les différents services ;
• la génération correcte des réponses API.

Cette réponse contenait notamment l'état des principaux services de l'infrastructure ainsi que plusieurs indicateurs système utilisés par le frontend.

Afin de valider l'intégration complète de l'application, j'ai ensuite accédé au site TuxForge et utilisé les outils de développement du navigateur (F12).

L'analyse de l'onglet Console m'a permis de vérifier l'absence d'erreurs JavaScript, tandis que l'onglet Réseau (Network) a permis de contrôler les échanges entre le frontend et le backend.

Les vérifications réalisées ont porté sur :

• le bon déroulement des requêtes API ;
• les codes de réponse retournés par le backend ;
• la récupération des données ;
• l'affichage correct des informations sur le site.

Validation

Après les différentes vérifications, les contrôles suivants ont été réalisés :

• démarrage correct du conteneur ;
• absence d'erreurs dans les journaux Docker ;
• accessibilité de l'API ;
• récupération des données au format JSON ;
• communication entre le frontend et le backend ;
• affichage des informations sur le site TuxForge.

L'ensemble des fonctionnalités du backend était opérationnel après migration.

Retour d'expérience

La migration du backend s'est déroulée sans difficulté majeure grâce à la conservation de l'arborescence Docker d'origine.

Cette étape m'a néanmoins permis de mieux comprendre les problématiques de communication entre applications dans une architecture distribuée. Contrairement à l'ancienne infrastructure où tous les services étaient hébergés sur une seule machine virtuelle, plusieurs composants utilisaient désormais des adresses IP distinctes, nécessitant une adaptation de la configuration du backend.

La validation de l'API et l'utilisation des outils de développement du navigateur m'ont également permis d'acquérir une meilleure compréhension des échanges entre le frontend et le backend ainsi que des mécanismes de diagnostic des applications web.

Cette migration m'a également permis de mieux comprendre le fonctionnement d'une application web développée autour d'une architecture frontend/backend ainsi que les mécanismes de communication entre les différentes couches de l'application.

Migration du Frontend TuxForge

Le frontend TuxForge constitue la partie visible de la plateforme. Développé sous la forme d'un site web statique en HTML, CSS et JavaScript, il regroupe l'ensemble des pages de présentation du projet ainsi que les composants permettant d'afficher les informations récupérées depuis le backend.

Le site est publié à l'aide d'un conteneur Nginx qui assure uniquement la diffusion des fichiers web. L'ensemble du code source et des ressources du projet est conservé dans une arborescence dédiée montée dans le conteneur via un volume Docker.

Restauration des données

Après le transfert de l'archive vers la machine virtuelle IAM, j'ai procédé à sa décompression puis à la restauration de l'arborescence Docker d'origine.

L'ensemble des fichiers du projet a été restauré, notamment :

• les pages HTML ;
• les feuilles de style CSS ;
• les scripts JavaScript ;
• les ressources graphiques ;
• la documentation intégrée au projet.

L'organisation des répertoires a été conservée afin de limiter les modifications nécessaires lors de la remise en service du site.

Vérification de la configuration Docker

Avant le redémarrage du service, j'ai vérifié le fichier docker-compose.yml utilisé pour publier le site.

La configuration repose sur une image Nginx légère (nginx:alpine) et utilise un volume Docker permettant de rendre accessible l'ensemble du contenu du projet depuis le serveur web.

Redémarrage du service

Une fois les fichiers restaurés, j'ai relancé le conteneur Nginx.

J'ai ensuite vérifié son état :

Cette vérification m'a permis de confirmer que le conteneur était correctement démarré et qu'aucun redémarrage en boucle n'était observé.

Adaptation de la configuration

Après la migration, quelques ajustements ont été nécessaires afin d'adapter certains chemins et liens utilisés par le site.

L'organisation générale du projet a été conservée, mais j’ai dû modifier plusieurs références afin de tenir compte de la nouvelle architecture et des emplacements utilisés par certains services.

Ces modifications ont notamment concerné :

• certains liens internes ;
• des chemins de ressources ;
• des URL utilisées pour communiquer avec le backend.

Cette étape a permis de garantir le bon fonctionnement du site dans son nouvel environnement.

Vérification du fonctionnement

Une fois le conteneur démarré, j'ai accédé au site depuis un navigateur afin de vérifier :

• l'affichage des différentes pages ;
• le chargement des feuilles de style ;
• le chargement des images et icônes ;
• le fonctionnement des liens internes ;
• la communication avec le backend.

J'ai également utilisé les outils de développement du navigateur (F12) afin de détecter d'éventuelles erreurs JavaScript ou erreurs de chargement de ressources.

L'analyse de l'onglet Console a permis de vérifier l'absence d'erreurs côté client tandis que l'onglet Réseau (Network) a permis de contrôler les requêtes échangées avec le backend.

Difficultés rencontrées

La principale difficulté rencontrée concernait un comportement intermittent lors de certaines modifications du site.

À plusieurs reprises, les changements effectués semblaient ne pas être pris en compte immédiatement malgré le redémarrage du conteneur.

Après plusieurs vérifications, le problème semblait provenir de mécanismes de cache côté navigateur ou du serveur web. Le fonctionnement du site n'était toutefois pas impacté et aucune correction particulière n'a été nécessaire.

Validation

Après les différentes vérifications, les contrôles suivants ont été réalisés :

• accès au site via son nom de domaine ;
• chargement des ressources statiques ;
• fonctionnement des liens internes ;
• communication avec le backend ;
• absence d'erreurs dans la console du navigateur.

L'ensemble des fonctionnalités du frontend était opérationnel après migration.

Retour d'expérience

La migration du frontend a été la plus simple des différentes étapes de l'environnement IAM. L'absence de base de données et la conservation de l'arborescence Docker d'origine ont permis une remise en service rapide du site.

Cette étape m'a néanmoins permis de mieux comprendre l'organisation d'un projet web structuré, le fonctionnement d'un serveur Nginx utilisé comme serveur de publication ainsi que l'utilisation des outils de développement intégrés aux navigateurs pour diagnostiquer les problèmes d'affichage et de communication avec le backend.

La création et l'évolution du site TuxForge ont également constitué ma première expérience concrète de développement, de maintenance et de déploiement d'une application web intégrée à une infrastructure auto-hébergée. Ce projet m'a permis de mieux comprendre les interactions entre le développement web, les conteneurs Docker et l'administration système.

Conclusion de la migration de l'environnement IAM

Cette migration a été sensiblement plus complexe que celle de l'environnement Monitoring en raison du nombre de services impliqués et des nombreuses dépendances entre les différents composants.

Elle m'a permis de mieux comprendre le fonctionnement d'un reverse proxy, la gestion des certificats SSL, les mécanismes d'authentification centralisée ainsi que les interactions entre plusieurs applications réparties sur différentes machines virtuelles.

Cette étape a également mis en évidence l'importance de l'ordre de déploiement dans une infrastructure distribuée. Un service comme Nginx Proxy Manager peut être parfaitement opérationnel tout en affichant des erreurs tant que les applications qu'il publie ne sont pas elles-mêmes disponibles.

La migration m'a aussi confronté à la problématique des changements d'adressage. Alors que tous les services communiquaient auparavant au sein d'une unique machine virtuelle Ubuntu, la nouvelle architecture reposait désormais sur plusieurs serveurs disposant chacun de leur propre adresse IP. J'ai donc dû adapter les configurations, les URL et les différents points de communication entre les applications afin de garantir leur bon fonctionnement.

Enfin, certaines intégrations entre Authentik et d'autres applications, notamment Uptime Kuma et Nginx Proxy Manager, n'ont pas pu être entièrement finalisées. Ces limitations étaient déjà présentes avant la migration et constituent encore aujourd'hui des pistes d'amélioration pour l'infrastructure TuxForge.

Au-delà de l'aspect technique, cette migration a représenté une étape importante dans ma compréhension d'une infrastructure moderne reposant sur Docker, le SSO, les certificats SSL, les reverse proxies et la communication entre services distribués.

Présentation de l'environnement

L'environnement DevOps regroupe les outils liés au développement et à la gestion du code source. Dans le cadre du projet TuxForge, cette machine virtuelle héberge Forgejo, une forge Git open source permettant de centraliser les dépôts, la documentation et les différents projets personnels.

L'instance héberge notamment :

• le dépôt du site TuxForge ;
• les projets personnels ;
• les utilisateurs ;
• les clés SSH ;
• les dépôts Git.

Migration de Forgejo

Après le transfert de l'archive vers la machine virtuelle DevOps, j'ai procédé à sa décompression puis à la restauration de l'arborescence Docker d'origine.

L'ensemble des données de l'application était stocké dans le volume :

/opt/docker/forgejo/data

La taille relativement faible des données (environ 27 Mo) a permis une restauration rapide.

Les éléments restaurés comprenaient :

• les dépôts Git ;
• les comptes utilisateurs ;
• les clés SSH ;
• les paramètres de configuration ;
• les données de l'application.

Redémarrage du service

Une fois les fichiers restaurés, j'ai relancé le conteneur Forgejo.

J'ai ensuite vérifié son état :

Le service a démarré immédiatement sans nécessiter de modification particulière.

Vérification de l'interface web

La première étape de validation a consisté à vérifier l'accès à l'interface d'administration.

https://forgejo.tuxforge.eu

Les contrôles réalisés ont permis de confirmer :

• la présence des utilisateurs ;
• la présence des dépôts ;
• la conservation de l'historique Git ;
• la conservation des paramètres de l'application.

Validation des dépôts Git

Une fois l'interface web validée, j'ai effectué un premier test de clonage Git en HTTPS.

Cette opération a fonctionné immédiatement.

Le dépôt a été récupéré sans erreur et l'intégralité de l'historique Git était présente.

Ce test a permis de valider simultanément :

• l'interface web ;
• le stockage des dépôts Git ;
• la configuration de Forgejo ;
• l'accès aux dépôts depuis le réseau.

Validation de l'accès SSH

Après validation du fonctionnement en HTTPS, j'ai souhaité vérifier le fonctionnement du protocole SSH utilisé pour les opérations Git.

La configuration du conteneur exposait les ports suivants :

ports:

- "3000:3000"

- "222:22"

J'ai alors réalisé plusieurs tests de connexion SSH.

Le premier résultat obtenu était :

Connection refused

Cette erreur aurait pu laisser penser à un problème de configuration de Forgejo. J'ai donc entrepris plusieurs vérifications afin de déterminer si l'origine du problème était applicative ou réseau.

Après plusieurs vérifications, j'ai constaté que l'accès HTTPS fonctionnait parfaitement mais que le port SSH n'était pas encore accessible depuis Internet.

À ce stade du projet, l'infrastructure réseau définitive n'était pas encore en place et les règles de routage nécessaires au port 222 n'étaient pas encore configurées.

Afin de vérifier le fonctionnement réel de Forgejo, j'ai effectué un test directement depuis la machine virtuelle :

Le résultat obtenu était :

Permission denied (publickey)

Bien que ce message puisse sembler être une erreur, il confirmait en réalité plusieurs points importants :

• le port 222 était ouvert ;
• le service SSH de Forgejo répondait correctement ;
• le conteneur Docker fonctionnait ;
• l'authentification par clé publique était active.

L'absence de clé SSH valide expliquait simplement le refus d'authentification.

Cette vérification a permis de confirmer que le service SSH de Forgejo fonctionnait correctement et que la limitation provenait uniquement de la configuration réseau externe encore en cours de migration.

Validation

Après les différents contrôles, les vérifications suivantes ont été validées :

• accès à l'interface web ;
• présence des utilisateurs ;
• présence des dépôts ;
• conservation de l'historique Git ;
• clonage des dépôts en HTTPS ;
• fonctionnement du service SSH ;
• démarrage correct du conteneur Docker.

L'ensemble des fonctionnalités principales de Forgejo était opérationnel après migration.

Retour d'expérience

Cette migration s'est déroulée sans difficulté majeure grâce à la simplicité de l'architecture de Forgejo et à la faible quantité de données à restaurer.

La partie la plus enrichissante a concerné la validation de l'accès Git via SSH. Cette étape m'a permis de mieux comprendre la différence entre un problème applicatif et un problème réseau. Les tests réalisés ont montré que le service SSH fonctionnait correctement sur la machine virtuelle mais que son accessibilité depuis Internet dépendait également de la configuration du routage et des redirections de ports.

Cette migration m'a également permis de mieux comprendre le fonctionnement d'une forge Git auto-hébergée ainsi que les différents composants nécessaires à son fonctionnement, notamment Docker, HTTPS, SSH et les mécanismes d'authentification associés.

Présentation de l'environnement

L'environnement Sécurité est dédié à l'hébergement de Vaultwarden, un gestionnaire de mots de passe auto-hébergé compatible avec les clients Bitwarden.

Ce service permet de centraliser et sécuriser les identifiants utilisés dans l'infrastructure TuxForge tout en conservant la maîtrise complète des données.

Migration de Vaultwarden

Après le transfert de l'archive vers la machine virtuelle Sécurité, j'ai procédé à sa décompression puis à la restauration de l'arborescence Docker d'origine.

L'ensemble des données de l'application était stocké dans le répertoire :

/opt/docker/vaultwarden/data

La taille relativement faible des données (environ 676 Ko) a permis une restauration très rapide.

Les éléments restaurés comprenaient :

• les comptes utilisateurs ;
• les coffres-forts ;
• les paramètres de l'application ;
• les données chiffrées stockées par Vaultwarden.

Redémarrage du service

Une fois les données restaurées, j'ai relancé le conteneur Vaultwarden.

J'ai ensuite vérifié son état :

Le service a démarré immédiatement sans nécessiter de modification particulière.

Vérification du fonctionnement

Une fois le conteneur démarré, j'ai vérifié l'accès à l'interface web.

https://vault.tuxforge.eu

Les contrôles réalisés ont permis de confirmer :

• l'accès à l'interface de connexion ;
• la présence des comptes existants ;
• la présence des coffres-forts ;
• la conservation des données stockées ;
• le fonctionnement du chiffrement des informations.

Une attention particulière a été portée à la présence des données restaurées, celles-ci constituant l'élément le plus critique de l'application.

Vérification de l'intégration

Après validation du fonctionnement local, j'ai vérifié l'intégration du service avec les autres composants de l'infrastructure.

Les contrôles ont porté sur :

• la publication via Nginx Proxy Manager ;
• l'accès sécurisé en HTTPS ;
• le bon fonctionnement du nom de domaine ;
• l'intégration avec Authentik.

Cette étape a permis de retrouver les conditions d'utilisation identiques à celles de l'ancienne infrastructure.

Difficultés rencontrées

La principale interrogation concernait la taille particulièrement faible des données restaurées.

Avec environ 676 Ko de données, j'ai d'abord envisagé la possibilité qu'une partie du contenu n'ait pas été correctement sauvegardée.

J'ai donc réalisé plusieurs vérifications afin de confirmer la présence des comptes, des coffres-forts et des données enregistrées.

Après contrôle, l'ensemble des informations était bien présent. La faible taille de l'archive s'expliquait simplement par le nombre limité de secrets stockés dans l'instance à ce stade du projet.

Validation

Après les différentes vérifications, les contrôles suivants ont été validés :

• démarrage correct du conteneur ;
• accès à l'interface web ;
• présence des comptes utilisateurs ;
• présence des coffres-forts ;
• fonctionnement du chiffrement ;
• accès HTTPS via le nom de domaine ;
• intégration avec les autres composants de l'infrastructure.

L'ensemble des fonctionnalités de Vaultwarden était opérationnel après migration.

Retour d'expérience

La migration de Vaultwarden s'est déroulée sans incident majeur grâce à la simplicité de l'application et au faible volume de données à restaurer.

Cette étape m'a toutefois sensibilisé à l'importance de la vérification des sauvegardes lorsqu'il s'agit de données sensibles. Même si la restauration s'est révélée très simple techniquement, la validation de l'intégrité des données était essentielle compte tenu du rôle de Vaultwarden dans l'infrastructure.

Cette migration m'a également permis de mieux comprendre le fonctionnement d'un gestionnaire de mots de passe auto-hébergé ainsi que les enjeux liés à la protection et à la disponibilité des données d'authentification.

Cette migration a également confirmé l'intérêt de disposer d'un service dédié pour les informations sensibles, distinct des autres applications de l'infrastructure.

Présentation de l'environnement

L'environnement Collaboration regroupe les services destinés au partage de fichiers et au travail collaboratif. Dans le cadre du projet TuxForge, cette machine virtuelle héberge Nextcloud, MariaDB, Redis et OnlyOffice.

La machine virtuelle dispose de :

• 4 vCPU ;
• 4 Go de mémoire vive ;
• 150 Go d'espace de stockage.

Cette VM constitue l'un des environnements les plus importants de l'infrastructure puisqu'elle héberge les données utilisateurs, les documents ainsi que les outils collaboratifs utilisés quotidiennement.

Migration de Nextcloud

Restauration des données

L'ancienne plateforme Nextcloud était installée sous forme de package Snap sur le serveur Ubuntu de l'infrastructure historique.

Contrairement aux autres services du projet, cette migration ne consistait pas uniquement à déplacer des conteneurs Docker vers une nouvelle machine virtuelle. Il a également fallu migrer une installation Nextcloud basée sur Snap vers une architecture entièrement conteneurisée reposant sur MariaDB, Redis et Docker Compose.

Cette différence a nécessité plusieurs adaptations de configuration ainsi qu'une phase de validation plus importante que pour les autres services migrés.

Avant toute opération de migration, j'ai réalisé plusieurs sauvegardes afin de sécuriser les données :

Ces archives représentaient environ 5 Go de données.

Après leur transfert vers la VM Collaboration, j'ai procédé à leur restauration au sein de la nouvelle architecture Docker composée des conteneurs :

• MariaDB ;
• Redis ;
• Nextcloud.

J'ai fait le choix d'utiliser des bind mounts plutôt que des volumes Docker afin de simplifier les futures sauvegardes et opérations de maintenance.

Difficultés rencontrées lors de la récupération des données

Avant même de débuter la migration vers Docker, une première difficulté importante est apparue sur l'ancienne machine Ubuntu hébergeant Nextcloud.

Les outils d'administration de l'application ne répondaient plus correctement. Plusieurs commandes indispensables à la préparation de la migration restaient bloquées sans retourner de résultat.

Les commandes concernées étaient notamment :

Cette situation était particulièrement problématique car elle empêchait de vérifier l'état de l'application, d'accéder facilement à la base de données et de confirmer l'intégrité des données avant la sauvegarde.

Dans un premier temps, j'ai vérifié l'état général du serveur ainsi que les ressources disponibles afin d'écarter un problème de saturation. Les différents services semblaient actifs, mais les outils d'administration de Nextcloud restaient inaccessibles.

Après plusieurs tentatives de diagnostic, j'ai finalement procédé au redémarrage complet de la machine virtuelle Ubuntu.

Une fois le serveur redémarré, les commandes sont redevenues fonctionnelles et j'ai pu accéder de nouveau à l'environnement Nextcloud.

J'ai alors pu réaliser les sauvegardes nécessaires à la migration et poursuivre les opérations de transfert vers la nouvelle infrastructure.

Cette étape a constitué l'un des moments les plus critiques de la migration. Tant que les commandes d'administration restaient bloquées, il était impossible de vérifier correctement l'état de l'instance ou de préparer sereinement la récupération des données.

Premier démarrage

Une fois les données restaurées, j'ai démarré l'ensemble de la stack.

J'ai ensuite vérifié l'état des différents conteneurs :

MariaDB, Redis et Nextcloud étaient correctement démarrés.

Problème de connexion à MariaDB

Lors du premier accès à l'interface web, Nextcloud affichait une erreur empêchant la connexion à la base de données.

J'ai commencé par consulter les journaux des conteneurs :

L'analyse des messages d'erreur a permis d'identifier un problème dans les paramètres de connexion utilisés par Nextcloud.

J'ai alors vérifié les variables présentes dans le fichier docker-compose.yml ainsi que les informations contenues dans le fichier config.php restauré depuis l'ancienne installation.

Après correction des paramètres et redémarrage de la stack :

la connexion entre Nextcloud et MariaDB a été rétablie.

Adaptation de la configuration Nextcloud

La migration depuis une installation Snap vers Docker a nécessité plusieurs modifications du fichier config.php.

J'ai notamment dû adapter :

• le répertoire de stockage des données ;
• l'hôte MariaDB ;
• la configuration Redis ;
• les domaines de confiance ;
• les proxys de confiance.

Les paramètres suivants ont notamment été modifiés :

'dbhost' => 'db',

'host' => 'redis',

afin de correspondre aux noms des conteneurs Docker utilisés dans la nouvelle infrastructure.

Publication du service

Une fois Nextcloud fonctionnel, j'ai configuré sa publication via Nginx Proxy Manager.

Le service a été rendu accessible via :

https://cloud.tuxforge.eu

Les vérifications réalisées ont porté sur :

• la génération du certificat Let's Encrypt ;
• la redirection HTTP vers HTTPS ;
• le bon fonctionnement du reverse proxy ;
• l'accès depuis Internet.

Déploiement d'OnlyOffice

Une fois Nextcloud validé, j'ai procédé à l'installation d'OnlyOffice.

Ce service avait été désactivé sur l'ancienne infrastructure en raison des ressources limitées disponibles sur la machine virtuelle Ubuntu.

La nouvelle infrastructure Proxmox permettant de disposer de davantage de ressources, j'ai pu remettre en service l'édition collaborative de documents.

Après déploiement du conteneur :

Le service a été publié via :

https://office.tuxforge.eu

Vérification du fonctionnement

J'ai commencé par contrôler l'état du service :

Le résultat obtenu :

true

a permis de confirmer le bon fonctionnement du serveur OnlyOffice.

Problème « Invalid Token »

Lors de la configuration du connecteur OnlyOffice dans Nextcloud, l'erreur suivante était affichée :

Invalid Token

J'ai alors consulté les journaux Docker puis vérifié la configuration du serveur OnlyOffice.

Les vérifications ont permis d'identifier une incohérence entre les secrets JWT utilisés par Nextcloud et OnlyOffice.

Après avoir appliqué le même secret dans les deux applications puis redémarré les conteneurs, la communication entre les services a été rétablie.

Documents bloqués à l'ouverture

Après correction du problème JWT, les documents restaient bloqués lors de leur ouverture.

J'ai commencé par vérifier l'état des services :

Les deux tests étant concluants, l'hypothèse d'un problème d'infrastructure a été écartée.

J'ai ensuite réalisé des essais depuis différents navigateurs.

Les documents s'ouvraient correctement sous Microsoft Edge mais restaient bloqués sous Firefox.

Après plusieurs vérifications, l'origine du problème a été identifiée comme étant l'extension uBlock Origin qui bloquait certaines ressources nécessaires au fonctionnement d'OnlyOffice.

Une fois cette restriction levée, l'ouverture et l'édition des documents sont devenues pleinement fonctionnelles.

Validation

Après les différentes corrections, les contrôles suivants ont été réalisés :

• accès à Nextcloud ;
• présence des comptes utilisateurs ;
• présence des fichiers ;
• fonctionnement de MariaDB ;
• fonctionnement de Redis ;
• synchronisation des données ;
• accès à OnlyOffice ;
• ouverture des documents ;
• édition collaborative ;
• publication HTTPS des services.

Les services sont désormais accessibles via :

• https://cloud.tuxforge.eu
• https://office.tuxforge.eu

L'ensemble de la plateforme collaborative était opérationnel après migration.

Retour d'expérience

La migration de l'environnement Collaboration a été la plus complexe de l'ensemble du projet.

Contrairement aux autres services, Nextcloud repose sur plusieurs composants interdépendants : base de données MariaDB, cache Redis, configuration applicative, stockage des fichiers utilisateurs, reverse proxy et intégration avec OnlyOffice.

Les difficultés ont commencé dès la récupération des données sur l'ancienne plateforme Ubuntu, où plusieurs commandes d'administration Nextcloud ne répondaient plus correctement. La migration s'est ensuite poursuivie avec différents problèmes liés à la connexion à MariaDB, à l'adaptation de la configuration issue de Snap ainsi qu'à l'intégration d'OnlyOffice.

Chaque difficulté a nécessité une phase de diagnostic, d'analyse des journaux et de tests afin d'identifier précisément l'origine du problème avant d'appliquer une correction.

Avec le recul, cette migration a constitué l'expérience la plus enrichissante du projet. Elle m'a permis de développer une méthodologie de dépannage plus rigoureuse et de mieux comprendre les interactions entre les différents composants d'une application moderne conteneurisée.

La remise en service complète de Nextcloud et d'OnlyOffice a également marqué une étape importante dans la modernisation de l'infrastructure TuxForge, en rétablissant des fonctionnalités collaboratives qui n'étaient plus utilisables sur l'ancienne plateforme faute de ressources suffisantes.