Laisser le RP nginx démarrer si l'hôte en amont est indisponible ou en panne

Si vous utilisez les définitions proxy_pass ou fastcgi_pass dans la configuration de votre serveur nginx, nginx vérifie le nom d'hôte pendant la phase de démarrage. Si l'un de ces serveurs n'est pas disponible, nginx ne démarrera pas.

Si vous utilisez nginx comme RP, pourquoi tous les services devraient-ils être inaccessibles si un seul service est en panne ou q'un service est plus long à démarrer complètement ?

Voici une astuce pour éviter un tel comportement et expose également l'adresse IP interne du DNS Docker au Docker DNS resolver .

 

 

Utiliser les variables nginx

L'astuce est d'utiliser des variables pour le nom de domaine en amont.

#exemple de config 
server {
  listen        443 ssl http2;
  server_name   exemple.sneo.fr;

  location / {
       # nginx start échouera si l'hôte n'est pas accessible
        proxy_pass http://service_name_exemple:8001;
  }
}

 

L'exemple suivant remplace le proxy_pass par une variable, ainsi nginx ne vérifiera pas si l'hôte est accessible au démarrage.
Cela se traduit par un message 502 Bad Gateway si l'hôte n'est pas disponible.

Dès que le service est de retour, tout fonctionne comme prévu.

#exemple de config
server {
  listen        443 ssl http2;
  server_name   exemple.sneo.fr;

  location / {
       # nginx va maintenant démarrer si l'hôte n'est pas accessible
        set $upstream service_name_exemple;
        proxy_pass http://$upstream;
  }
}

 

IP interne du Docker DNS resolver

Nous devons utiliser l'adresse IP interne du Docker DNS resolver qui est 127.0.0.11.

Pour raccourcir le temps d'arrêt, réduisez le temps de résolution du cache à 30 secondes au lieu des 5 minutes par défaut.

#exemple de config
server {
  listen        443 ssl http2;
  server_name   exemple.sneo.fr;

  # ceci est le DNS Docker interne, cache 30 secondes
  resolver 127.0.0.11 valid=30s; 

  location / {
       # nginx va maintenant démarrer si l'hôte n'est pas accessible
        set $upstream service_name_exemple;
        proxy_pass http://$upstream;
  }
}

 

Conclusion

Cette astuce permet de rendre votre infra plus robuste et vous permet d'avoir plusieurs services sous 1 reverse proxy sans attendre que tous les services soit Up pour que ceux-ci, soit accessible.

Ajouter un commentaire