Réécriture d'URL HAProxy en cas d'erreur 404

Comment faire réécrire HAProxy vers un back-end différent lorsque le premier manque le fichier? Ce dont j'ai besoin, c'est de errorlocfaire une réécriture au lieu d'une redirection, donc le client n'est pas au courant de la redirection.

Nous avons développé une application avec NginX à l'esprit, qui était à la fois un proxy inverse d'équilibrage de charge et un serveur Web pour les fichiers statiques. L'application est basée sur le framework Opa qui nécessite des sessions persistantes basées sur des cookies - prises en charge par NginX et HAproxy. La fonctionnalité d'application avec laquelle nous avons un problème est la génération de contenu dynamique. Il génère des images à la demande, mais après sa génération, il est enregistré sur le disque et peut être consulté de manière statique avec un chemin déterministe.

Le problème a été facilement résolu avec NginX - il essaie de lire le fichier local et d'utiliser le back-end à charge équilibrée uniquement si le fichier est manquant (pas encore généré):

server {
  server_name wkaliszu.pl;
  location /thumb {
    root /path_on_disk/to_cached_content;
    expires 7d;
    # try to access already generated content
    try_files $uri @wkaliszu;
  }
  location / {
    # reverse proxy to the application
    [...]
  }
  location @wkaliszu {
    # reverse proxy to the application
    [...]
  }
}

Le serveur a été migré et utilise maintenant HAPproxy pour l'équilibrage de charge, qui n'est pas un serveur Web et ne prend pas en charge cette fonctionnalité. Maintenant, la génération de logiciels dynamiques est effectuée chaque fois que le client essaie d'accéder à la ressource, ce qui est beaucoup plus lent et gaspille les ressources. Ce serait bien s'il pouvait utiliser le back-end suivant si le premier (serveur Web de mise en cache simple pour les fichiers statiques) échouait avec l'erreur 404, mais je ne peux pas trouver un moyen de le faire de manière simple. La redirection /thumbvers NginX, qui essaie de lire le fichier statique et réécrit à nouveau vers HAproxy avec un nouvel en-tête HTTP ne me vient à l'esprit, mais je voudrais trouver quelque chose de mieux.

Les backends de HAProxy sont en hausse ou en baisse (ou en voie de montée / descente).

Il existe différentes façons de vérifier la santé d'un serveur principal, mais je n'en connais aucun qui offre un suivi basé sur la demande. Une fois qu'une demande échoue, ce backend serait marqué comme étant en panne ou échouerait (sur le point d'être considéré comme étant en panne).

Il s'agit d'une logique très différente de celle de votre configuration Nginx, qui acheminait les demandes par demande.

Je vois quelques options ici:

• Nginx en tant que proxy de mise en cache
• Utiliser les serveurs d'applications pour le contenu statique
• Utilisez un CDN

Mise en cache du proxy

Dans HAProxy, vous utiliseriez des ACL pour acheminer les demandes de contenu statique vers un backend spécifique. Ces nœuds principaux exécuteraient nginx avec un proxy de mise en cache. Si nginx avait le fichier mis en cache, il le servirait simplement. Sinon, il appellerait votre backend.

Utiliser des serveurs d'applications pour le contenu statique

Si vos serveurs d'applications sont efficaces pour diffuser du contenu statique, vous n'aurez peut-être pas besoin de fractionner la demande en haproxy. Envoyez simplement toutes les demandes à vos applications. Intégrez-leur une logique pour servir du contenu statique s'il est disponible et sinon envoyer la demande au backend.

Option CDN

Si vous pouvez utiliser un domaine dédié pour le contenu statique, vous pourrez peut-être utiliser un CDN. Sur le CDN, vous pointez simplement l'URL source vers vos nœuds d'application. Vous pouvez ensuite contrôler la mise en cache au niveau CDN. Ceci est similaire à la mise en cache Nginx ci-dessus, sauf que le fournisseur CDN le gère pour vous.