Blue-Green et retours en arrière

Chaque déploiement dans sh0 utilise une stratégie blue-green pour des mises en production sans interruption. Si quelque chose ne va pas, revenez instantanément à n'importe quelle version précédente.

Déploiements blue-green

Le déploiement blue-green est une stratégie de mise en production qui élimine les temps d'arrêt en exécutant deux environnements identiques en parallèle. À tout moment, un environnement (blue) sert le trafic en production tandis que l'autre (green) est soit inactif, soit en cours de mise à jour avec la nouvelle version.

Lorsque vous déployez une nouvelle version, sh0 démarre le nouveau conteneur aux côtés du conteneur actuel. Une fois que le nouveau conteneur passe les bilans de santé, le trafic est instantanément basculé de l'ancien conteneur vers le nouveau. L'ancien conteneur est maintenu en exécution brièvement comme solution de repli avant d'être arrêté.

Comment sh0 l'implémente

Voici le processus étape par étape que sh0 suit pour chaque déploiement :

1. Build : La nouvelle image Docker est construite à partir de votre code source ou récupérée depuis un registre
2. Démarrage du conteneur green : Un nouveau conteneur est démarré avec l'image mise à jour, connecté au même réseau et aux mêmes volumes que le conteneur actuel
3. Bilan de santé : sh0 exécute des bilans de santé sur le nouveau conteneur (point de terminaison HTTP, port TCP ou commande personnalisée)
4. Exécution des hooks de pré-déploiement : Si configurés, les hooks de pré-déploiement s'exécutent sur le nouveau conteneur (par ex., migrations de base de données)
5. Basculement du trafic : La configuration du reverse proxy Caddy est mise à jour pour diriger tout le trafic vers le nouveau conteneur
6. Exécution des hooks de post-déploiement : Les hooks de post-déploiement s'exécutent (par ex., vidage du cache, notifications)
7. Drainage de l'ancien conteneur : L'ancien conteneur dispose d'un délai de grâce (par défaut : 30 secondes) pour terminer le traitement des requêtes en cours
8. Arrêt de l'ancien conteneur : L'ancien conteneur est arrêté et supprimé

Le basculement du trafic se fait au niveau du reverse proxy (Caddy), ce qui signifie qu'il est instantané. Il n'y a aucun écart entre l'arrêt de l'ancien conteneur et le démarrage du nouveau -- les deux s'exécutent simultanément pendant la transition.

Déploiements sans interruption

Comme l'ancien conteneur continue de servir le trafic jusqu'à ce que le nouveau soit vérifié comme sain, vos utilisateurs ne subissent jamais d'interruption pendant les déploiements. La transition est transparente :

• Aucune erreur 502 pendant le déploiement
• Aucune connexion interrompue ou requête perdue
• Aucune fenêtre de maintenance requise
• Les connexions WebSocket sur l'ancien conteneur sont autorisées à se terminer naturellement

Bilans de santé

Les bilans de santé sont essentiels pour les déploiements sans interruption. sh0 prend en charge trois types de bilans de santé :

{
  "healthcheck": {
    "type": "http",
    "path": "/health",
    "interval": 10,
    "timeout": 5,
    "retries": 3,
    "start_period": 30
  }
}

Historique des déploiements

sh0 maintient un historique complet de chaque déploiement pour chaque application. L'historique de déploiement inclut :

• Statut du déploiement (réussi, échoué, retour en arrière)
• SHA du commit Git et message
• Tag et digest de l'image Docker
• Durée de build et durée de déploiement
• Qui a déclenché le déploiement (utilisateur, webhook ou API)
• Log de build complet

Cliquez sur n'importe quel déploiement pour voir son log de build complet, les résultats d'exécution des hooks et la sortie des bilans de santé. Le déploiement actuellement en production est mis en évidence dans la liste.

Retour en arrière en un clic

Si un déploiement introduit un bug ou un problème de performance, vous pouvez revenir à n'importe quelle version précédente depuis l'historique de déploiement. Cliquez sur le bouton Retour en arrière à côté de n'importe quel déploiement passé réussi pour redéployer instantanément cette version.

Un retour en arrière suit le même processus blue-green qu'un déploiement normal : l'image Docker de l'ancienne version est utilisée pour démarrer un nouveau conteneur, les bilans de santé s'exécutent et le trafic est basculé. Cela signifie que les retours en arrière sont également sans interruption.

Retour en arrière via l'API

Vous pouvez également déclencher des retours en arrière de manière programmatique via l'API sh0. C'est utile pour les retours en arrière automatiques déclenchés par les systèmes de surveillance.

# Rollback to a specific deployment ID
curl -X POST https://your-sh0-server.com:9000/api/apps/{app_id}/rollback \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"deploy_id": "deploy_abc123"}'

# Rollback to the immediately previous version
curl -X POST https://your-sh0-server.com:9000/api/apps/{app_id}/rollback \
  -H "Authorization: Bearer YOUR_TOKEN"

Lorsqu'aucun deploy_id n'est spécifié, sh0 revient au déploiement réussi le plus récent avant le déploiement actuel.

Comportement du retour en arrière

Détails importants sur le fonctionnement des retours en arrière :

• Code uniquement : Les retours en arrière annulent le code applicatif (image Docker) mais ne révertent pas les modifications de base de données. Si votre déploiement incluait une migration de base de données, vous devrez peut-être écrire une migration inverse manuellement.
• Variables d'environnement : Les retours en arrière utilisent les variables d'environnement actuelles, pas celles du moment du déploiement original. Cela garantit que les secrets et la configuration mis à jour restent en vigueur.
• Exécution des hooks : Les hooks de pré-déploiement et post-déploiement s'exécutent lors d'un retour en arrière, comme pour un déploiement normal.
• Entrée dans l'historique : Les retours en arrière créent une nouvelle entrée dans l'historique de déploiement avec une étiquette « rollback », indiquant quel déploiement a été restauré.