## 1. Mon serveur s’arrête à chaque déploiement, quel est le problème ? {#sec-4f4fee2fcd28}

Lorsque l’on gère des projets personnels, on se retrouve souvent sur des environnements aux ressources limitées (instances micro sur GCP, Raspberry Pi, etc.).
Je possède plusieurs machines : des serveurs puissants pour l’inférence et l’entraînement d’IA, ainsi que des VM minimes qui ne font que tenir un serveur de noms.
Le Raspberry Pi 5 a une place particulière pour moi : il ne coûte presque rien en électricité et offre des performances solides.
Si les autres serveurs vous semblent comme du bétail à gérer, le Pi ressemble plutôt à un animal de compagnie auquel on s’attache.

Mais en lui confiant trop de tâches, le CPU atteint 100 % lors d’un déploiement, à cause du **Celery Worker**.
Lors d’un déploiement Blue‑Green, les deux groupes (Blue et Green) sont actifs simultanément, doublant ainsi le nombre de workers et surchargeant le système.
Réduire le nombre de workers ralentit le traitement, mais les laisser tels quels fait exploser le serveur : une vraie impasse.

![Illustration d’un script d’automatisation sur un PC à faible puissance](/media/editor_temp/6/feadd998-56ed-4ccb-9fca-acbb54ef62f2.png)

Pour surmonter ce problème, j’ai créé un **script de déploiement Blue‑Green sur‑mesure** qui minimise la consommation de ressources tout en garantissant la stabilité.

---

## 2. Stratégie de résolution : économiser les ressources, augmenter la fiabilité {#sec-84df4175f98f}

Un déploiement Blue‑Green classique lance les deux environnements en même temps, mais j’ai adopté les mesures suivantes pour alléger la charge CPU :

1. **Arrêt anticipé des services en arrière‑plan (Celery)** : avant de lancer la nouvelle version du serveur web, j’arrête les workers et le beat lourds de l’ancienne version afin de libérer du CPU.
2. **Démarrage progressif** : je lance d’abord `Web + Redis`, puis je réalise un health‑check avant de déployer le reste.
3. **Human‑in‑the‑loop** : une fois l’automatisation terminée, l’administrateur valide visuellement avant de supprimer l’ancienne version.

Lorsque le CPU est poussé à ses limites, les workers Celery se réinitialisent, reçoivent immédiatement de nouvelles tâches et consomment toute la capacité disponible. Baisser la concurrence du worker aurait pu résoudre le problème, mais cela aurait ralenti le traitement asynchrone pendant le déploiement, ce qui n’était pas souhaitable.

L’idée qui m’est venue : suspendre temporairement les workers Celery lors du redéploiement, libérer le CPU, puis déployer le nouveau code tout en maintenant une disponibilité sans interruption.

---

## 3. Analyse du code clé {#sec-049262c64613}

Le code complet est disponible dans mon [dépôt GitHub](https://github.com/mikihands/linuxscript/tree/main/zero-downtime). Voici quelques extraits essentiels.

### ① Isolation du projet avec Docker Compose {#sec-31c03a8ae526}

En utilisant l’option `docker compose -p`, on crée deux projets (ou espaces de noms) nommés `blue` et `green` à partir du même fichier de configuration.

```bash
dc() {
  # Définir dynamiquement le nom du projet (-p) pour isoler les environnements
  docker compose -f "$COMPOSE_FILE" "$@"
}
```

### ② Vérifications de santé rigoureuses (Health Check) {#sec-d10311b76a14}

On ne bascule le trafic vers la nouvelle version que lorsque les contrôles de santé sont concluants.

```bash
health_check() {
  # Réessayer jusqu’à 10 fois pour vérifier qu’un port répond 200 OK
  if curl -fsSIL --max-time "$HEALTH_TIMEOUT" "$url"; then
    ok "Health check passed"
    return 0
  fi
}
```

### ③ Repli rapide en cas d’échec {#sec-53e921d110b5}

Si la nouvelle version pose problème, on relance immédiatement les services de l’ancienne version afin de masquer toute interruption aux utilisateurs.
Le `stop` est préféré à `rm -f` pour les workers et le beat, ce qui permet de libérer le CPU tout en conservant la possibilité de redémarrer rapidement en cas d’incident.

---

## 4. Astuce d’exploitation : la philosophie du "vérifier avant de supprimer" {#sec-cbbf7ab93b4f}

Le script se termine en affichant un message d’avertissement plutôt qu’en supprimant automatiquement l’ancienne version.

> "Le déploiement a réussi. Connectez‑vous maintenant pour vérifier. Si tout est en ordre, copiez la commande ci‑dessous pour nettoyer l’ancienne version."

Cette petite précaution empêche les 1 % d’erreurs que l’automatisation pourrait négliger.

---

## 5. Conclusion {#sec-942f631956ee}

Ce script reflète les réflexions nécessaires pour obtenir le meilleur rendement avec des ressources limitées. Bien qu’il soit simple, il me satisfait pleinement et je suis convaincu que d’autres développeurs aux contraintes similaires y trouveront leur compte.
J’espère que ce script aidera les petits développeurs confrontés aux mêmes défis.

**Liens associés :**

* [Accéder au dépôt GitHub](https://github.com/mikihands/linuxscript/tree/main/zero-downtime)  
* [Déploiement automatisé avec GitHub Webhook ⑤ Nginx, HTTPS et intégration finale](/ko/whitedec/2025/7/24/github-webhook-final-nginx-https/)  
* N’hésitez pas à laisser un commentaire ou à ouvrir une issue sur GitHub pour toute question !