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. 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.

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. 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. 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. 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. Dès lors, chaque fichier uploadé par un utilisateur via l'interface web était écrit directement dans le bucket distant.

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. 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é. Cette manipulation technique complexe m'a permis d'attacher le nouveau disque virtuel à mon hyperviseur local et de redémarrer le système d'exploitation Debian initialement hébergé chez Scaleway, validant le processus de migration.

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, la clôture de la semaine de formation s'est soldée par la validation de mes compétences sur cet environnement simulé et la destruction des ressources provisionnées sur Scaleway. À distance, et encore aujourd'hui, mon entreprise d'alternance dispose d'une infrastructure 100% on-premise. Cette manipulation n'a donc pas été reproduite en production dans mon contexte professionnel direct. Toutefois, ce projet académique m'a permis de valider officiellement mes compétences fondamentales sur le Cloud, m'armant techniquement pour mes futures missions où l'hybridation des systèmes d'information est devenue la norme.