Life with 🐘 🐳 🐧 💻

Pendant longtemps, j’ai tout hébergé sur un seul serveur bare metal chez OVH. Il hébergeait mon GitLab auto-hébergé, les GitLab runners, les images Docker et toutes mes charges de production. C’était puissant, fiable et prévisible, mais avec le temps, cela devenait coûteux et rigide. Je voulais quelque chose de plus flexible, plus simple à faire évoluer et moins cher à exécuter. C’est à ce moment-là que j’ai découvert Dokploy.

Dans cet article, je partage comment je suis passé de cette configuration monolithique à une infrastructure multi-VPS propulsée par Dokploy. Aujourd’hui, le tout est plus simple, plus rapide et bien moins cher, tout en restant entièrement auto-hébergé.

L’Ancienne Configuration : Un Serveur pour les Gouverner Tous

Mon ancienne configuration était classique : un seul serveur puissant faisait tout.

• Les runners GitLab construisaient mes images Docker.
• Les runners se connectaient ensuite en SSH sur la même machine ou sur un autre hôte Docker.
• Chaque déploiement tirait la dernière image et redémarrait les conteneurs.

Cela fonctionnait, mais avec plusieurs inconvénients :

• Coût : les serveurs bare metal chez OVH sont excellents, mais surdimensionnés (et chers) pour de petits projets.
• Complexité : gérer les runners, les clés SSH et les pulls manuels ajoutait de la friction.
• Scalabilité : tout était étroitement lié à une seule machine.
• Zéro Downtime : difficile à mettre en place.

Chaque fois que je voulais ajouter un environnement de staging ou tester une nouvelle stack, je devais jongler manuellement avec les ports, les conteneurs et les règles du pare-feu.

Pourquoi Quitter le Bare Metal

La principale motivation était la flexibilité et le coût. J’ai réalisé que je n’avais pas besoin d’un seul grand serveur pour tout. À la place, je pouvais exécuter plusieurs petits VPS, chacun pour un rôle spécifique :

• Un VPS pour GitLab
• Un pour le staging
• Un pour la production

Chaque VPS est moins cher, isolé et plus simple à maintenir. Et puisqu’ils tournent tous sous Docker, la cohérence reste totale.

Mettre à jour le kernel d’un serveur bare metal complet impliquait de louer un nouveau serveur et d’espérer migrer tous les projets en un mois pour éviter de payer les deux. Ici, il est bien plus simple de déplacer les projets individuellement vers de nouveaux VPS.

Mais il me fallait un moyen simple d’orchestrer les déploiements entre toutes ces machines. C’est là qu’entre en jeu Dokploy.

Découvrir Dokploy

Dokploy est une plateforme auto-hébergée pour déployer et gérer des applications basées sur Docker. C’est un peu un mélange entre CapRover, Coolify et Portainer, mais avec un accent sur la simplicité et le CI/CD moderne.

Ce qui m’a tout de suite plu, c’est la facilité d’intégration avec les pipelines externes. Au lieu de laisser Dokploy construire les images, je laisse GitLab CI le faire, pousser l’image vers mon registre privé, puis déclencher un webhook Dokploy pour déployer la nouvelle version.

Cela me permet de conserver toute ma configuration GitLab existante tout en déléguant la logique de déploiement à Dokploy.

La Nouvelle Configuration : Un Dokploy tout gérer

Dans ma nouvelle configuration, j’ai maintenant un seul VPS exécutant Dokploy, aux côtés d’autres outils comme Grafana et n8n. Dokploy est responsable du déploiement de plusieurs environnements :

• Il déploie GitLab lui-même sur un autre VPS.
• Il déploie mon environnement de staging sur un deuxième VPS.
• Il déploie mon environnement de production sur un troisième VPS.

Ces autres VPS ne font pas tourner Dokploy : l’instance principale gère tout à distance via son système de déploiement.

Voici le workflow global :

1. GitLab construit l’image Docker.
2. L’image est poussée vers mon registre privé.
3. GitLab déclenche le webhook Dokploy.
4. Dokploy tire la nouvelle image et redéploie le service correspondant.

Voici un extrait simplifié du fichier .gitlab-ci.yml :

deploy:
  stage: deploy
  script:
    - curl -X POST https://dokploy.example.com/webhook/PROJECT_ID?token=$DOKPLOY_TOKEN
  only:
    - main

Aucun script SSH, aucun pull manuel, aucun temps d’arrêt. Juste un webhook propre par environnement.

Staging avec Basic Auth

Une des petites fonctionnalités bien pratiques de Dokploy, c’est la facilité d’activer une authentification Basic Auth pour un projet.

Il suffit d’aller dans Advanced Settings > Security > Add Security > Create.

Ainsi, les visites aléatoires ou le scraping susceptible de marquer votre site comme un duplicata sont évités.

Zéro Downtime avec Docker Swarm

Dokploy utilise Docker Swarm en interne, ce qui permet des mises à jour sans interruption.

Lorsqu’une nouvelle image est déployée, Dokploy effectue une mise à jour progressive : l’ancien conteneur est arrêté uniquement lorsque le nouveau est sain. Pas besoin de règles de load balancer compliquées ni de coordination manuelle. Pour moi, c’est un énorme progrès par rapport à mes anciens scripts docker-compose.

Pour cela, certaines options dans Advanced > Cluster Settings doivent être configurées. Il faut une route de Healthcheck disponible sur le serveur. Elle est appelée localement et, dès qu’elle renvoie un succès, le trafic est redirigé vers le nouveau conteneur tandis que l’ancien est arrêté. Ici, la route debest.fr/uptime est utilisée pour cela.

On peut également définir les limites de ressources, les variables d’environnement et le nombre de réplicas directement depuis l’interface, ce qui rend la gestion de multiples services plus prévisible.

Sauvegardes Automatiques avec MinIO

Autre point fort : la simplicité pour planifier des sauvegardes de volumes et de bases de données. Dans le tableau de bord Dokploy, j’ai configuré des sauvegardes périodiques automatiques vers mon instance MinIO exécutée sur mon NAS local.

Chaque projet peut avoir sa propre planification, et Dokploy gère automatiquement la compression et l’envoi. Cela me rassure d’avoir un contrôle total sur mes sauvegardes sans dépendre d’AWS.

Supervision et Alertes avec Dokploy et Grafana

Le même VPS qui exécute Dokploy héberge également Grafana. Grafana surveille chaque VPS et collecte des métriques comme l’utilisation du CPU, de la RAM et du disque. Lorsqu’un seuil est dépassé, Grafana envoie une alerte sous forme de message sur mon serveur Discord.

Cette configuration légère me permet de garder une vue en temps réel sur tous mes VPS et d’être alerté immédiatement en cas de problème.

Dokploy est aussi configuré pour envoyer des messages sur Discord lorsqu’un déploiement réussit ou échoue, ou lorsqu’une sauvegarde de volume ou de base de données a eu lieu.

Je prévois de détailler cette configuration de monitoring dans un prochain article.

Coûts et Simplicité

Depuis que je suis passé du bare metal aux VPS, j’ai considérablement réduit mes coûts d’hébergement. Chaque VPS a désormais un rôle bien défini, et si l’un d’eux tombe, les autres continuent de fonctionner.

Conclusion

Dokploy s’est révélé être un excellent compromis entre la gestion Docker manuelle et les grandes plateformes PaaS. Il est suffisamment simple pour être compris en une journée, mais assez puissant pour gérer de vrais déploiements avec zéro interruption et des sauvegardes automatiques.

Si vous utilisez encore un gros serveur bare metal, essayez cette approche : une instance Dokploy qui gère plusieurs petits VPS. Combinez cela avec des outils comme Grafana pour la supervision, et vous obtiendrez un environnement entièrement auto-hébergé, automatisé et surveillé, à coût minimal.

Restez à l’écoute pour le prochain article, où je détaillerai comment j’utilise Grafana, n8n et les alertes Discord pour surveiller mon infrastructure.

Dennis de Best