Déploiement Java sans interruption : comment ne pas faire tomber la production

Déploiement Java sans interruption : comment ne pas faire tomber la production

Imaginez : vendredi, 17h45, vous déployez une nouvelle version du service, vous allez chercher un café, vous revenez — et le site est en panne. Erreur 500, les clients sont nerveux, le lead technique écrit sur Slack "Que s'est-il passé ?". Une douleur familière ? Si vous travaillez avec Java et les microservices, vous savez : arrêter un service pour un déploiement n'est pas seulement un contretemps technique, c'est une perte d'argent et de réputation.

Bonne nouvelle : le déploiement sans interruption (zero-downtime deployment) n'est pas de la magie, mais un ensemble de pratiques éprouvées. Dans cet article, nous allons voir comment organiser un déploiement fluide d'applications Java : des concepts au code réel sur Spring Boot. Vous apprendrez à utiliser les rolling update, blue-green et canary deployment pour que vos utilisateurs ne remarquent même pas les mises à jour.

Pourquoi les services Java tombent-ils lors du déploiement ?

Le problème classique : l'application démarre, mais l'ancien processus traite encore les requêtes. Vous tuez l'ancien processus — et les nouvelles requêtes tombent dans le vide. Ou inversement : la nouvelle instance n'est pas encore chaude, mais le trafic arrive déjà. En Java, cela est aggravé par le démarrage lent de la JVM, l'initialisation d'Hibernate, le chargement des caches.

Les principales causes des temps d'arrêt :

• Arrêt brutal de l'ancien processus — les requêtes sont interrompues en plein milieu.
• Nouvelle instance non chaude — la première requête ralentit, le cache est vide.
• Rupture des sessions — l'utilisateur perd les données du panier ou l'authentification.
• Incompatibilité des bases de données — les migrations cassent l'ancienne version.

Le déploiement Java sans interruption résout tous ces problèmes, si on l'aborde de manière systématique. Examinons les trois principaux modèles.

Modèle 1 : Rolling Update (mise à jour progressive)

C'est l'approche la plus populaire dans le monde de Kubernetes et des plateformes cloud. L'idée est simple : vous avez plusieurs instances du service (réplicas). Vous les mettez à jour une par une : l'ancienne instance s'arrête, la nouvelle démarre — et ainsi de suite jusqu'à ce que tous les réplicas soient nouveaux.

Comment cela se présente-t-il en pratique avec Spring Boot et Kubernetes

Supposons que vous ayez un microservice sur Spring Boot déployé dans Kubernetes. Pour un rolling update, une configuration correcte du Deployment et la configuration du graceful shutdown (arrêt progressif) suffisent.

Étape 1 : Configurez Spring Boot pour le graceful shutdown :

// application.ymlserver:  shutdown: graceful

spring:  lifecycle:    timeout-per-shutdown-phase: 30s

Qu'est-ce que cela apporte ? Lorsque Kubernetes envoie le signal SIGTERM, Spring Boot cesse d'accepter de nouvelles requêtes, mais termine celles en cours dans les 30 secondes. Sans cette configuration, la JVM tuerait simplement le processus, interrompant les requêtes.

Étape 2 : Configurez la readiness probe et la liveness probe :

@RestControllerpublic class HealthController {

    @GetMapping("/actuator/health/readiness")    public ResponseEntity<String> readiness() {        // Vérifie que le service est prêt à accepter le trafic        // Par exemple, la base de données est connectée, le cache est chaud        return ResponseEntity.ok("OK");    }

    @GetMapping("/actuator/health/liveness")    public ResponseEntity<String> liveness() {        // Vérifie que la JVM est vivante        return ResponseEntity.ok("OK");    }}

Étape 3 : Configuration du Deployment Kubernetes :

apiVersion: apps/v1kind: Deploymentmetadata:  name: my-java-servicespec:  replicas: 3  strategy:    type: RollingUpdate    rollingUpdate:      maxSurge: 1        # combien de nouveaux pods peuvent être créés en plus de la norme      maxUnavailable: 0  # aucun pod ne doit être indisponible  template:    spec:      containers:      - name: app        image: myregistry/my-java-service:2.0        readinessProbe: