Développer et déployer un serveur OVH de A à Z : la méthode complète

Une application ne devient pas sérieuse parce qu’elle tourne dans un conteneur. Elle devient exploitable quand l’infrastructure est compréhensible, reproductible, sécurisée, surveillée, sauvegardée et déployable sans improvisation.

Cette série part d’un cas volontairement concret : un serveur OVHcloud neuf, un domaine, une stack Docker, un CMS Joomla, une API Java, une API Python, une app frontend, des bases de données, un reverse proxy, du HTTPS, du CI/CD, du monitoring, des backups et des procédures de rollback.

L’objectif n’est pas de créer une usine complexe. L’objectif est de construire une plateforme pragmatique que l’on peut comprendre, refaire et maintenir.

Le problème

Beaucoup de déploiements commencent par une succession de commandes copiées depuis plusieurs tutoriels :

• une règle firewall ajoutée ici ;
• un conteneur lancé à la main là ;
• un certificat généré avec une option oubliée ;
• une base exposée temporairement, puis jamais refermée ;
• un fichier .env qui traîne ;
• un backup que personne n’a jamais restauré.

Le système finit par fonctionner, mais personne ne sait exactement pourquoi. Le jour où il faut migrer, restaurer, auditer ou corriger un incident, l’équipe découvre que le vrai risque n’était pas Docker, Nginx ou OVH. Le vrai risque était l’absence de méthode.

La posture

On apprend à le faire à la main pour comprendre. On l’automatise pour ne plus dépendre de la mémoire humaine.

Chaque brique est donc présentée en trois temps : la décision technique, la version manuelle minimale, puis la version automatisée dans le repo. La pédagogie ne remplace pas l’exploitation. Elle la prépare.

L’architecture cible

Le premier palier est un mono-serveur OVHcloud sous Ubuntu Server 24.04 LTS. Il héberge plusieurs services, mais un seul point d’entrée public : Nginx.

• DNS OVH vers l’IP publique du serveur ;
• Nginx en reverse proxy HTTPS ;
• Joomla derrière Nginx, avec MariaDB en réseau interne ;
• une API Java Spring Boot derrière Nginx, avec PostgreSQL en réseau interne ;
• une API Python FastAPI ou un worker exposé uniquement si nécessaire ;
• une app frontend Vue/Nuxt servie derrière Nginx ;
• des sauvegardes chiffrées vers un stockage externe ;
• des healthchecks, logs, alertes et runbooks d’exploitation.

Ce choix est assumé. Un mono-serveur n’est pas de la haute disponibilité. Il concentre le risque, peut avoir des fenêtres de maintenance et exige des backups testés. Mais il est lisible, économique, rapide à mettre en place et pertinent pour un MVP, un blog sérieux, un backoffice, une API métier ou un SaaS early-stage.

La série explique aussi quand sortir de ce modèle : base de données séparée, Object Storage, staging dédié, load balancer, Kubernetes ou services managés.

Le fil rouge technique

La plateforme est construite avec :

• Terraform pour provisionner l’instance OVHcloud et les records DNS ;
• Ansible pour configurer Ubuntu, SSH, UFW, Docker, Nginx et les apps ;
• Docker Engine et Docker Compose pour exécuter les services ;
• Nginx comme reverse proxy principal ;
• Let’s Encrypt et Certbot pour le HTTPS ;
• MariaDB pour Joomla ;
• PostgreSQL pour les apps métier ;
• MongoDB en module optionnel ;
• GitHub Actions et GHCR pour builder et publier les images ;
• SSH/Ansible pour déployer ;
• scripts de smoke test, backup, restore-check et rollback.

Le craftsmanship dans le processus

Déployer proprement ne suffit pas si le code est produit sans discipline. La série intègre donc le craftsmanship dans le cycle applicatif :

• BDD en amont pour clarifier le comportement attendu ;
• TDD quand une règle métier mérite un test avant code ;
• red-green-refactor pour éviter les changements non démontrés ;
• feature flags pour déployer sans activer ;
• migrations de base versionnées ;
• Definition of Ready avant développement ;
• Definition of Done avant déploiement ;
• quality gates CI ;
• smoke tests après release ;
• rollback documenté.

Le but n’est pas de réciter des bonnes pratiques. Le but est de les rendre exécutables.

Sécurité et exploitation

La sécurité n’est pas un article final. Elle apparaît dès le bootstrap :

• SSH par clé uniquement ;
• pas de login root ;
• ports publics limités à 22, 80, 443 ;
• bases et apps non exposées directement ;
• secrets hors Git ;
• admin tools non publics par défaut ;
• TLS vérifié et renouvellement testé ;
• backups chiffrés hors serveur ;
• restauration testée ;
• logs et alertes.

Un point mérite d’être clair : Docker et UFW peuvent surprendre. Publier un port Docker revient souvent à contourner l’intention initiale du firewall. Le parcours principal n’expose donc publiquement que Nginx. Les bases et services restent sur des réseaux Docker internes.

Pourquoi OVHcloud

OVHcloud donne un terrain intéressant pour apprendre : Public Cloud, API, OpenStack, DNS, Object Storage, snapshots, régions, coûts maîtrisables. Le tutoriel est adapté à OVH, mais les principes restent portables.

Alternatives crédibles :

• Hetzner pour des VPS simples et économiques ;
• Scaleway pour un environnement européen proche ;
• AWS, GCP ou Azure pour les services managés et l’écosystème enterprise ;
• Render, Railway, Fly.io ou Heroku-like pour réduire l’exploitation.

Ici, le choix est volontaire : apprendre le socle serveur, pas déléguer toute la plateforme.

Ce que la série ne promet pas

Cette série ne promet pas une production invincible. Elle ne promet pas de haute disponibilité. Elle ne remplace pas une équipe SRE, un audit de sécurité ou une architecture réglementaire.

Elle fournit une base propre pour comprendre et maîtriser :

• ce qui tourne ;
• où sont les données ;
• comment déployer ;
• comment vérifier ;
• comment revenir en arrière ;
• comment restaurer ;
• quand changer d’architecture.

Le repo

Le repo GitHub associé est la source de vérité :

https://github.com/fareswebnet/ovh-production-server-from-scratch

Les articles sont versionnés en Markdown dans articles/. Les exports Joomla vivent dans exports/joomla/. Les fichiers Terraform, Ansible, Compose, scripts, runbooks et exemples applicatifs sont dans le même dépôt.

Déroulé de la série

1. Architecture cible ;
2. Mono-serveur, limites et trajectoire ;
3. Poste local et secrets ;
4. Terraform OVH ;
5. DNS et sous-domaines ;
6. Bootstrap Ubuntu avec Ansible ;
7. Docker Engine et firewall ;
8. Docker Compose multi-apps ;
9. Nginx reverse proxy ;
10. HTTPS Let’s Encrypt ;
11. Joomla ;
12. API Java ;
13. API Python ;
14. Frontend Vue/Nuxt ;
15. Bases de données ;
16. CI/CD et rollback ;
17. Monitoring et logs ;
18. Backups, restauration et PRA minimal.

Conclusion

Le vrai sujet n’est pas d’installer Docker sur un VPS. Le vrai sujet est de construire une chaîne cohérente entre décision, code, infrastructure, sécurité, exploitation et retour arrière.

Une bonne plateforme de départ doit être suffisamment simple pour être comprise, suffisamment automatisée pour être répétable, et suffisamment honnête pour documenter ses limites.

Ce sera le fil conducteur de toute la série.