Tester un Nouveau Conteneur sans Tout Casser

Dans le monde du développement et de la gestion d'infrastructures cloud ou conteneurisées, une des plus grandes peurs est de déployer une nouvelle version d'un service et de tout faire planter. Imaginez : vous avez un backend API critique qui tourne parfaitement, mais vous voulez tester une mise à jour – peut-être une optimisation, une correction de bug, ou une nouvelle fonctionnalité. Comment faire pour l'essayer en conditions réelles sans risquer une interruption de service pour tous vos utilisateurs ? C'est là qu'intervient le canary deployment, une technique de déploiement progressif inspirée des mineurs qui utilisaient des canaris pour détecter les dangers.

Sur Mesh-Box.fr, nous explorons souvent des solutions open-source pour gérer des réseaux mesh et des setups conteneurisés. Aujourd'hui, on se penche sur HAProxy, un load balancer puissant et gratuit, pour implémenter un canary testing. L'idée ? Rediriger une infime partie du trafic vers votre nouveau conteneur (le "canari"), tout en gardant la majorité sur la version stable. Si le canari "meurt" (c'est-à-dire qu'il y a des erreurs), vous le retirez sans impact majeur. On va voir comment configurer ça pour une route spécifique, comme /api/backend, avec un ratio de 1/1000 pour le test.

Pourquoi le Canary Deployment ?

Avant de plonger dans le code, rappelons les enjeux :

Risque minimisé : Au lieu de tout basculer d'un coup (big bang deployment), vous testez sur une fraction du trafic réel.
Feedback rapide : Observez les métriques (erreurs, latence, logs) en production sans tout casser.
Rollback facile : Si ça foire, arrêtez simplement le routage vers le nouveau conteneur.
Idéal pour les conteneurs : Avec Docker, Kubernetes ou même un setup simple sur une box mesh, HAProxy s'intègre facilement comme proxy inverse.

C'est particulièrement utile pour des environnements comme ceux de Mesh-Box, où la stabilité est clé pour des réseaux décentralisés ou des apps IoT.

La Solution : HAProxy pour du Traffic Splitting Probabiliste

HAProxy excelle dans le load balancing, mais il peut aussi faire du routage conditionnel basé sur des règles aléatoires. Voici une configuration exemple qui envoie 1 requête sur 1000 vers un nouveau backend de test (backend_2 sur port 8081), et les 999 autres vers le backend stable (backend_1 sur port 8080). Le tout uniquement pour la route /api/backend.

Configuration HAProxy

Installez HAProxy si ce n'est pas fait (sur Ubuntu : sudo apt install haproxy), puis éditez /etc/haproxy/haproxy.cfg avec ceci :

frontend mon_api_frontend
    bind *:80

    # 1. Définir l'ACL qui matche votre route
    acl is_api_path path_beg /api/backend
    # 2. Définir l'ACL de "loterie" (1 chance sur 1000)
    # rand(1000) génère un entier entre 0 et 999.
    # On vérifie si cet entier est inférieur à 1 (donc égal à 0).
    acl is_lucky_winner rand(1000) -m int lt 1
    # 3. Règles de routage
    # Si c'est le bon chemin ET que le tirage au sort est gagnant :
    use_backend backend_2 if is_api_path is_lucky_winner

    # Sinon, si c'est le bon chemin, on envoie vers le standard :
    use_backend backend_1 if is_api_path
    # Backend par défaut pour le reste du trafic
    default_backend default_servers

# Définition de vos backends
backend backend_2
    server srv_ts 127.0.0.1:8081 check
backend backend_1
    server srv_main 127.0.0.1:8080 check
backend default_servers
    server srv_def 127.0.0.1:8000 check

Explications pas à pas :

Frontend : Écoute sur le port 80 (ou 443 pour HTTPS). Les ACL (Access Control Lists) définissent les conditions.
ACL pour le chemin : path_beg /api/backend cible uniquement les requêtes commençant par cette URL.
ACL aléatoire : rand(1000) lt 1 crée une probabilité de 0,1% (1/1000). HAProxy génère un nombre aléatoire par requête – si c'est 0, bingo pour le test !
Routage : Priorité aux règles : d'abord le cas rare (test), puis le standard, et enfin un default pour le reste.
Backends : Chaque backend pointe vers un conteneur (ici localhost pour simplicité, mais remplacez par des IPs ou noms de services Docker/K8s). Le check active les health checks pour détecter si un serveur tombe.

Redémarrez HAProxy (sudo systemctl restart haproxy) et c'est parti !

Comment Tester Ça ?

Simulation locale : Lancez deux conteneurs Docker simulant vos backends (ex. : un Node.js ou Python sur 8080 et 8081).
Générez du trafic : Utilisez curl en boucle ou un outil comme Apache Benchmark (ab -n 10000 -c 10 http://localhost/api/backend).
Monitoring : Activez les logs HAProxy (option httplog) et vérifiez la distribution. Sur 10 000 requêtes, attendez-vous à ~10 vers le test. Utilisez Prometheus ou ELK pour des stats avancées.
Ajustements : Pour un ratio différent (ex. 1/100), changez rand(100) et lt 1. Pour plus de serveurs, ajoutez-en dans les backends avec des weights.

Avantages et Limites

Avantages : Gratuit, performant, et intégré à des outils comme Docker Compose ou Kubernetes Ingress. Pas besoin de services cloud payants comme AWS Canary ou Google Cloud Traffic Director.
Limites : C'est probabiliste, pas déterministe – des écarts statistiques sont possibles sur peu de trafic. Pas idéal pour des sessions stateful sans sticky routing. En prod, ajoutez de la redondance et des alerts.

Si vous gérez un mesh network sur une box Raspberry Pi ou un setup plus complexe, cette approche s'adapte bien pour tester des updates firmware ou apps sans downtime.

Conclusion

Le canary deployment avec HAProxy est une arme secrète pour des tests en production sans peur. Chez Mesh-Box.fr, on encourage l'expérimentation sécurisée – commencez petit, mesurez tout, et scalez ! Si vous avez des questions ou des setups spécifiques (comme intégrer ça à un mesh VPN), commentez ci-dessous ou contactez-nous. Bonne implémentation !

Sources : Basé sur la documentation officielle HAProxy et des best practices DevOps. Testé en local pour cet article.