Déploiement Nextcloud sur Scaleway

1. Introduction

Cette réalisation s'est déroulée dans le cadre d'une semaine de formation intensive dédiée à l'apprentissage des technologies du Cloud durant ma formation. Le projet consistait à déployer en autonomie une infrastructure de stockage et de partage de fichiers (Nextcloud) hébergée sur une machine virtuelle chez le fournisseur Cloud Scaleway, en simulant un environnement d'entreprise. Ensuite, nous devions faire exactement la même chose mais en migrant une machine virtuelle on-premise sur le cloud, puis en la remigrant du cloud vers le on-premise.

2. Les objectifs

2.1. Objectifs techniques

• Déployer et configurer une machine virtuelle Linux (VM) sur Scaleway
• Installer Nextcloud avec une base de données en Cloud
• Connecter l'instance à un stockage objet de type Bucket S3
• Manipuler les disques virtuels et effectuer des tests de sauvegarde/migration

2.2. Objectifs non techniques

• Comprendre les concepts de scalabilité et de souveraineté des données
• Gérer un environnement Cloud de bout en bout en un temps limité

3. Le contexte et les enjeux

Ce projet académique visait à nous faire sortir des environnements virtualisés locaux pour nous confronter aux réalités et aux outils des fournisseurs Cloud publics. Nextcloud a été choisi comme cas pratique car il cumule plusieurs briques techniques essentielles : serveur web, base de données, pare-feu et stockage externe. De plus, c'est une entreprise française.

Enjeux : L'enjeu de cette semaine de formation était de comprendre la logique du Cloud : séparer le traitement (la machine virtuelle) du stockage des données (le bucket S3). Bien que l'infrastructure ait été dimensionnée comme une preuve de concept (POC) pour quatre ou cinq utilisateurs, l'enjeu architectural était de concevoir un système capable d'absorber beaucoup plus d'utilisateurs par simple augmentation des spécifications de notre solution.

Risques : Le risque technique principal dans le Cloud est l'exposition des ports. Une mauvaise configuration du pare-feu aurait rendu l'instance vulnérable. De plus, les manipulations de sauvegarde et de transfert de machine virtuelle entre différents environnements comportent un fort risque de corruption de données si les formats ne sont pas compatibles. C'est d'ailleurs ce qui a été le cas lors de mon premier essai.

4. Les différentes étapes du projet

4.1. Provisioning de l'instance et durcissement périmétrique

À l'aide de la console du fournisseur IaaS Scaleway, j'ai provisionné une machine virtuelle (Compute Instance) tournant sous une distribution Linux Debian. Avant même d'installer l'application, j'ai vérifié les paramètres de base de l'instance, comme l'adresse IP publique, la taille de la machine et le niveau d'exposition réseau, afin de partir sur une base saine. Dès l'obtention de l'adresse IP publique, la sécurisation a été l'étape prioritaire.

Je me suis connecté en SSH et j'ai activé le pare-feu logiciel natif UFW. J'ai configuré une politique de rejet par défaut (« drop all ») et j'ai autorisé explicitement uniquement les flux nécessaires : le port 22 pour mon administration distante et les ports 80/443 pour le trafic HTTP/HTTPS du serveur web. Les ports d'écoute de la base de données ont été volontairement exclus des règles d'autorisation, la rendant inaccessible depuis l'extérieur et fermant ainsi une vulnérabilité critique. Cette approche m'a permis de partir sur un socle sécurisé avant d'ouvrir le moindre service applicatif.

4.2. Déploiement applicatif et intégration de l'Object Storage (S3)

J'ai préparé l'environnement d'exécution en installant les moteurs de conteneurisation Docker et Docker Compose, afin de séparer proprement les différents composants du projet. J'ai ensuite déployé la stack applicative Nextcloud couplée à une base de données isolée dans un réseau virtuel Docker interne. L'enjeu de ce TP était de concevoir une architecture scalable en séparant le traitement de la donnée du stockage lui-même.

Au lieu de monter un volume Block Storage local de type ext4 sur l'instance Debian, j'ai utilisé l'API S3 de Scaleway. J'ai édité le fichier config.php situé dans le dossier de configuration de Nextcloud et j'y ai déclaré la classe native d'Object Storage en paramétrant l'URL de l'endpoint, la région, le nom du bucket créé ainsi que les clés d'accès publiques et privées générées via la console IAM du cloud provider. J'ai vérifié ensuite que la connexion au bucket fonctionnait correctement et que chaque fichier uploadé par un utilisateur via l'interface web était bien écrit directement dans le stockage distant. Cette étape a été importante, car elle a transformé une simple installation Nextcloud en architecture réellement orientée cloud.

4.3. Export de la VM et conversion des disques virtuels

Pour finaliser la logique d'ingénierie, j'ai dû prouver la réversibilité du système en rapatriant l'infrastructure cloud vers un environnement on-premise. J'ai utilisé l'outil de création d'images de Scaleway pour générer un snapshot complet du disque racine de mon instance, puis je l'ai téléchargé en local. Avant la conversion, j'ai vérifié le format exact de l'image et les contraintes de l'hyperviseur local afin d'éviter une tentative inutile ou mal orientée. Le fichier obtenu était un format brut (RAW/QCOW2), inutilisable en l'état par la majorité des hyperviseurs de postes de travail (comme VMware ou Hyper-V).

Pour résoudre cette incompatibilité de formats de virtualisation, j'ai installé l'utilitaire bas niveau qemu-img. En ouvrant un terminal de commandes, j'ai exécuté l'instruction de conversion pour transposer les blocs du disque cloud vers un format VMDK standardisé. J'ai ensuite contrôlé l'intégrité du disque converti avant de l'attacher à mon hyperviseur local, puis j'ai redémarré le système d'exploitation Debian initialement hébergé chez Scaleway. Cette manipulation technique complexe m'a permis de valider le processus de migration de bout en bout et de confirmer que l'on pouvait récupérer l'environnement dans un contexte local sans repartir de zéro.

5. Les résultats

5.1. Pour moi

D'un point de vue technique, j'ai démystifié l'utilisation d'un Object Storage (S3), implémenté la sécurisation périmétrique via un Bastion SSH, et validé de solides compétences en manipulation de disques virtuels hétérogènes. D'un point de vue personnel, cette formation m'a donné une véritable aisance sur les environnements IaaS (Infrastructure as a Service). J'ai perdu mon appréhension des plateformes cloud publiques et j'ai acquis la certitude de pouvoir concevoir et opérer des architectures hybrides.

5.2. Pour le projet

L'infrastructure livrée en fin de semaine était parfaitement fonctionnelle et sécurisée. Les données s'écrivaient correctement sur le Bucket S3, prouvant la séparation du calcul et du stockage, et le test de reprise d'activité en local via la conversion des disques a été un succès technique absolu.

6. Ce que je retiens

Ce projet Cloud m'a confronté à la dure réalité de la « réversibilité » des données. Exporter une machine virtuelle depuis un Cloud public vers une infrastructure locale n'est pas une simple formalité : l'incompatibilité des formats de disques virtuels a été un obstacle majeur. Mon apport a été de prouver qu'une architecture hybride demande des compétences système bas-niveau (comme l'utilisation de QEMU) bien au-delà de la simple manipulation d'une interface web Cloud. Si je devais refaire ce déploiement, j'abandonnerais la configuration manuelle via la console Scaleway pour utiliser des outils d'Infrastructure as Code comme Terraform et Ansible, ce qui rendrait le déploiement reproductible instantanément.

7. Les lendemains du projet

Dans l'immédiat après la fin de la semaine de formation, j'ai procédé à la destruction complète des ressources provisionnées sur Scaleway (instance, bucket S3, snapshots) pour arrêter les coûts d'hébergement. La clôture de cette semaine de formation académique s'est traduite par la validation officielle de mes compétences cloud.

À distance, et encore aujourd'hui en 2026, mon entreprise d'alternance (SCA Qualisol) dispose d'une infrastructure 100 % on-premise. Le projet de migration cloud n'a donc jamais été reproduit en environnement de production dans mon contexte professionnel direct. Cependant, cette formation m'a armé techniquement pour les futures missions où l'hybridation des systèmes d'information (mix on-premise et cloud public) est devenue la norme dans le secteur informatique.

Aujourd'hui, je reste attentif aux évolutions cloud et j'envisage, dans mes rôles futurs, de proposer des solutions IaaS (Infrastructure as a Service) pour des clients ayant besoin d'une scalabilité rapide sans investissement matériel lourd. Cette compétence en cloud constitue un véritable avantage concurrentiel dans mon projet de micro-entreprise informatique.