Skip to content
faresweb.net labs Main blog

labs / experience

De zéro à production : l’architecture cible sur OVH

stable updated: 2026-08-04 reading: 7 min

Avant de provisionner une instance ou d’installer Docker, il faut savoir ce que l’on construit. Sinon, l’infrastructure devient vite une accumulation de commandes : une VM, quelques ports ouverts, un reverse proxy bricolé, des conteneurs lancés à la main, puis des décisions impossibles à expliquer six mois plus tard.

Cet article pose l’architecture cible de la série : un mono-serveur OVHcloud sérieux, automatisé et exploitable, conçu pour héberger plusieurs applications sans prétendre être une plateforme haute disponibilité. C’est une base volontairement pragmatique : assez simple pour être comprise et opérée à la main, mais assez structurée pour servir de socle à des projets réels.

Objectif

À la fin de cet article, le lecteur doit pouvoir expliquer :

  • pourquoi le mono-serveur est choisi au départ ;
  • quelles briques composent la plateforme ;
  • quels flux réseau sont publics ou internes ;
  • quelles limites sont acceptées ;
  • quelle trajectoire permet de grandir sans tout réécrire.

L’enjeu n’est pas de vendre une architecture universelle. L’enjeu est de rendre les choix explicites, vérifiables et réversibles.

Décision technique

Le point de départ de la série est le suivant :

  • OVHcloud Public Cloud comme fournisseur d’infrastructure ;
  • Ubuntu Server 24.04 LTS comme système d’exploitation ;
  • une instance principale pour démarrer ;
  • Docker Engine et Docker Compose pour empaqueter les services ;
  • Nginx en reverse proxy frontal ;
  • Let’s Encrypt pour les certificats TLS ;
  • MariaDB pour Joomla ;
  • PostgreSQL pour les applications métier ;
  • GitHub Actions et GHCR pour construire et distribuer les images ;
  • Ansible pour configurer, déployer et opérer le serveur.

Ce n’est pas la seule stack possible. C’est une stack lisible, documentée, reproductible et adaptée à un contexte où l’on veut comprendre ce que l’on fait avant d’automatiser davantage.

Architecture logique

La plateforme se lit comme une chaîne de responsabilité simple.

  1. Le code applicatif et l’infrastructure déclarative vivent dans GitHub.
  2. GitHub Actions vérifie le dépôt, construit les images Docker et les pousse dans GHCR.
  3. Terraform provisionne les ressources OVHcloud nécessaires, notamment l’instance et les éléments réseau.
  4. Ansible configure Ubuntu, durcit le système, installe Docker, prépare les répertoires et déploie la stack.
  5. Docker Compose lance Joomla, les applications, les bases de données, le monitoring et les services d’exploitation.
  6. Nginx reçoit le trafic web public et route vers les conteneurs internes.
  7. Les sauvegardes, les logs, les smoke tests et les runbooks permettent d’opérer la plateforme dans la durée.

La logique importante est la séparation des responsabilités. Terraform ne configure pas l’application. Ansible ne remplace pas Docker Compose. Docker Compose ne doit pas décider des règles réseau publiques. Nginx n’est pas une base de données. Chaque brique a un rôle clair.

Flux réseau

Flux publics

  • 80/tcp pour HTTP et les challenges Let’s Encrypt HTTP-01 ;
  • 443/tcp pour HTTPS ;
  • 22/tcp pour SSH administrateur, idéalement restreint par adresse IP ou par règle de sécurité.

Flux internes

  • Joomla communique avec MariaDB sur le réseau Docker interne ;
  • les applications métier communiquent avec PostgreSQL sans exposition publique ;
  • Nginx route vers les conteneurs applicatifs via des upstreams internes ;
  • les outils de monitoring lisent des métriques locales ;
  • les jobs de backup exportent les sauvegardes vers un stockage externe.

Flux interdits par défaut

  • PostgreSQL public ;
  • MariaDB public ;
  • MongoDB public ;
  • phpMyAdmin public ;
  • Portainer public ;
  • Grafana public sans authentification forte ;
  • ports applicatifs publiés directement sur l’hôte sans passer par Nginx.

Le principe est simple : le serveur peut héberger plusieurs services, mais le web public ne doit voir qu’une façade maîtrisée.

Convention de domaines

Pour la série, on utilise une convention de lab :

  • example.faresweb.dev : domaine de base ;
  • cms.example.faresweb.dev : Joomla ;
  • app.example.faresweb.dev : frontend ;
  • api.example.faresweb.dev : API Java ;
  • worker.example.faresweb.dev : API Python ou worker exposé si besoin ;
  • monitoring.example.faresweb.dev : monitoring protégé.

Ces valeurs sont des exemples. Le dépôt associé refuse certaines actions si le domaine reste sur une valeur de démonstration, afin d’éviter de lancer un déploiement en pensant être déjà en configuration réelle.

Pourquoi Nginx d’abord

Nginx rend visibles les concepts importants d’une plateforme web :

  • serveur virtuel ;
  • upstream applicatif ;
  • headers ;
  • timeouts ;
  • taille d’upload ;
  • logs d’accès et d’erreur ;
  • diagnostic des erreurs 502 ;
  • interaction avec Certbot.

Traefik et Caddy sont des alternatives modernes crédibles. Elles peuvent être très pertinentes. Le parcours principal reste Nginx parce qu’il oblige à comprendre le routage HTTP, les certificats, les proxys et les responsabilités réseau. Cette compréhension reste utile même si l’on migre ensuite vers un outil plus automatisé.

Pourquoi Docker Compose d’abord

Docker Compose est suffisant pour de nombreux cas de départ :

  • MVP ;
  • backoffice interne ;
  • blog ou CMS ;
  • SaaS early-stage ;
  • environnement d’apprentissage sérieux ;
  • prototype client maintenable.

Kubernetes devient pertinent quand plusieurs limites apparaissent ensemble : scheduling, haute disponibilité, autoscaling, rollouts complexes, multi-noeuds, politiques réseau avancées, séparation forte des responsabilités et besoin d’une plateforme opérée par plusieurs équipes. L’introduire trop tôt masque souvent les problèmes de base : sauvegardes, observabilité, sécurité, secrets, restauration, discipline de déploiement.

Limites acceptées

Le mono-serveur accepte explicitement :

  • pas de haute disponibilité ;
  • downtime possible pendant maintenance ;
  • dépendance forte à la restauration ;
  • capacité verticale limitée ;
  • risque concentré sur une VM ;
  • besoin de discipline sur les backups et mises à jour.

Ces limites ne sont pas des détails. Elles doivent être annoncées avant le premier terraform apply. Une architecture simple n’est acceptable que si ses risques sont connus et compensés par des procédures concrètes.

Trajectoire d’évolution

La trajectoire naturelle est progressive :

  1. mono-serveur propre ;
  2. environnement de staging séparé ;
  3. base de données séparée ou managée ;
  4. Object Storage pour fichiers et backups ;
  5. monitoring externe ;
  6. load balancer ;
  7. orchestration avancée si le besoin est réel.

Une bonne architecture de départ ne prétend pas être finale. Elle évite surtout de bloquer la suite. Le but est de pouvoir évoluer sans renier les choix initiaux.

Vérification locale

À ce stade, rien n’est encore provisionné. La vérification consiste à contrôler que le dépôt contient les bons garde-fous :

make doctor

Résultat attendu :

  • les outils manquants sont listés clairement ;
  • aucun secret évident n’est présent ;
  • les fichiers d’exemple sont présents ;
  • les commandes dangereuses ne s’exécutent pas sans confirmation.

Le dépôt associé est disponible ici : github.com/fareswebnet/ovh-production-server-from-scratch.

Sécurité

Les décisions de sécurité sont déjà présentes dans l’architecture :

  • Nginx est le seul point d’entrée web public ;
  • les bases restent internes ;
  • les outils d’administration sont restreints ;
  • les secrets restent hors Git ;
  • les sauvegardes sont externes ;
  • les smoke tests sont lancés après déploiement ;
  • les runbooks décrivent les actions d’incident et de restauration.

Ce n’est pas encore une plateforme certifiée ni un environnement haute sécurité. C’est un socle propre, explicite, testable, et beaucoup plus sain qu’un serveur construit par copier-coller de commandes non reliées entre elles.

Où on en est

On a maintenant une carte. L’article suivant explique pourquoi le mono-serveur est un choix pragmatique, où il devient insuffisant, et comment préparer la sortie sans surconcevoir dès le départ.

Sources et versions

Date de vérification : 2026-08-04.

Sources primaires utilisées pour cadrer cette série :

  • documentation OVHcloud Public Cloud ;
  • Terraform Registry pour les providers OVH et OpenStack ;
  • documentation Docker Engine Ubuntu ;
  • documentation Certbot avec Nginx ;
  • documentation Ansible.

Le dépôt contient aussi un fichier de références : docs/references/official-sources.md.