00 - Pourquoi automatiser son déploiement
Ce que tu vas apprendre
- Pourquoi le déploiement manuel finit toujours par te coûter du temps
- La différence entre GitHub Actions et GitLab Runner (shell executor)
- Ce que cette serie couvre, de A a Z
Prerequisites
Aucun. C'est le point de depart de la serie.
Le déploiement manuel, c'est pour les masochistes
SSH dans le serveur. git pull. docker compose build. docker compose up -d. Verifier que ca tourne. Se deconnecter. Ca prend 2 minutes. Ca parait rien.
Sauf que le jour ou tu fais 15 déploiements dans la meme journee, ces 2 minutes deviennent 30 minutes de ta vie passees a taper les memes commandes dans le meme terminal. C'est exactement ce qui m'est arrive la semaine dernière. Je bossais sur paltemps.fr, un projet avec une API Bun, un reverse proxy Caddy, un serveur mail et un Chrome headless. Chaque petit fix CSS, chaque correction de bug, chaque ajout de route : SSH, pull, build, up. A la 8eme fois, j'ai craque.
Le pire, c'est pas la répétition. C'est les erreurs. Tu oublies le --no-cache et Docker te sert le CSS d'il y a 3 commits. Tu oublies le docker image prune et ton disque se remplit. Tu fais un docker compose up sans le -d et tu bloques ton terminal. Des trucs betes, mais qui arrivent quand tu fais les choses machinalement.
Ce que "push to deploy" change
L'idee est simple : tu pushes sur main, et 30 secondes plus tard, ton site est à jour en production. Pas de SSH. Pas de commande manuelle. Pas d'erreur d'inattention.
Concretement, voici ce qui se passe :
- Tu fais
git push origin main - GitLab détecté le push et déclenché un pipeline CI/CD
- Le GitLab Runner installe sur ton VPS exécuté le job
- Le job fait
git pull,docker compose build,docker compose up -d - Ton site est à jour
C'est du déploiement automatique dans sa forme la plus directe. Pas de Kubernetes, pas de cluster, pas d'orchestrateur complexe. Juste un VPS, Docker Compose et un runner.
GitHub Actions vs GitLab Runner : deux philosophies
Si tu viens de GitHub, tu connais peut-etre GitHub Actions. Le principe : tes jobs tournent sur les serveurs de GitHub (ou sur un runner self-hosted). Pour déployer sur ton VPS, il faut configurer une connexion SSH, stocker des clés privees dans les secrets du repo, et écrire un workflow qui se connecte à distance pour exécuter des commandes.
GitLab Runner avec un shell executor, c'est l'inverse. Le runner tourne directement sur ton VPS. Quand un job se lance, il exécuté les commandes localement, comme si tu etais connecte en SSH toi-meme. Pas besoin de clés SSH dans les variables CI. Pas de tunnel réseau. Le runner est deja là où il doit déployer.
Comparaison rapide :
| GitHub Actions | GitLab Runner (shell) | |
|---|---|---|
| Ou ca tourne | Serveurs GitHub (ou self-hosted) | Directement sur ton VPS |
| Acces au serveur | SSH + clés dans les secrets | Local, pas besoin de SSH |
| Complexite | Moyenne (gestion des secrets) | Faible (c'est du bash local) |
| Prix | 2000 min/mois gratuit | Gratuit (c'est ton serveur) |
Pour un projet perso ou une petite équipe avec un seul VPS, le shell executor est franchement plus simple. Tu n'as pas a gerer de secrets SSH, pas de risque de clé qui expire, pas de debug réseau entre GitHub et ton serveur.
Ce que cette serie couvre
On va construire un pipeline de déploiement automatique complet, étape par étape :
- L'architecture du projet (VPS, Docker Compose, Caddy)
- Installer et configurer GitLab Runner sur le VPS
- Écrire le
.gitlab-ci.yml - Gerer le cache Docker et les rebuilds
- Tous les problèmes qu'on a rencontres (et comment les résoudre)
Tout est base sur un vrai projet en production. Pas de theorie abstraite, pas de "dans un monde ideal". Les vrais fichiers de config, les vraies erreurs, les vrais correctifs.
A qui s'adresse cette serie
Tu as un projet qui tourne avec Docker Compose sur un VPS. Tu le deploies a la main et tu en as marre. Tu veux que ca se fasse tout seul quand tu pushes. Tu utilises GitLab (pas GitHub). Tu ne veux pas passer 3 jours a configurer une usine a gaz.
Si ca te parle, cette serie est pour toi.
Navigation : Introduction | Suivant : 01 - L'architecture
Sources
- GitLab Runner documentation par GitLab
- What is CI/CD? par GitLab Docs
- GitHub Actions vs GitLab CI/CD par GitLab
Retrouve d'autres articles techniques sur paltemps.fr.