Question Comment configurer Nginx en tant que proxy inverse de mise en cache?


J'ai entendu dire récemment que Nginx avait ajouté la mise en cache à sa fonctionnalité de proxy inverse. J'ai regardé autour de moi mais je n'ai pas trouvé beaucoup d'informations à ce sujet.

Je souhaite configurer Nginx en tant que proxy inverse de mise en cache devant Apache / Django: pour avoir des requêtes de proxy Nginx pour certaines pages dynamiques (mais pas toutes) vers Apache, puis pour mettre en cache les pages générées et pour servir les demandes ultérieures de ces pages à partir du cache.

Idéalement, je voudrais invalider le cache de 2 manières:

  1. Définir une date d'expiration sur l'élément mis en cache
  2. Pour invalider explicitement l'élément mis en cache. Par exemple. si mon serveur Django a mis à jour certaines données, je voudrais dire à Nginx d'invalider le cache des pages affectées

Est-il possible de configurer Nginx pour le faire? Comment?


139
2018-06-24 01:35


origine




Réponses:


Je ne pense pas qu'il existe un moyen d'invalider explicitement les éléments mis en cache, mais voici un exemple montrant comment faire pour le reste. Mettre à jour: Comme mentionné par Piotr dans une autre réponse, il existe un module de purge de cache que vous pouvez utiliser. Vous pouvez également forcer l'actualisation d'un élément mis en cache à l'aide de proxy_cache_bypass de nginx - voir La réponse de Cherian pour plus d'informations.

Dans cette configuration, les éléments non mis en cache seront extraits de example.net et stockés. Les versions en cache seront servies aux futurs clients jusqu'à ce qu'elles ne soient plus valides (60 minutes).

Vos en-têtes HTTP Cache-Control et Expires HTTP seront pris en compte. Par conséquent, si vous souhaitez définir explicitement une date d'expiration, vous pouvez le faire en définissant les en-têtes corrects dans tout ce à quoi vous êtes mandaté.

Vous pouvez régler de nombreux paramètres - reportez-vous à la documentation du module Proxy de nginx pour plus d'informations à propos de tout cela, y compris des informations détaillées sur la signification des différents paramètres / paramètres: http://nginx.org/r/proxy_cache_path

http {
  proxy_cache_path  /var/www/cache levels=1:2 keys_zone=my-cache:8m max_size=1000m inactive=600m;
  proxy_temp_path /var/www/cache/tmp; 


  server {
    location / {
      proxy_pass http://example.net;
      proxy_cache my-cache;
      proxy_cache_valid  200 302  60m;
      proxy_cache_valid  404      1m;
    }
  }
}

94
2017-09-23 20:01



C'est une première étape raisonnable pour les nouvelles applications qui n'ont pas 20k / req / s. - Barry
@Barry, quel sera le deuxième pas? - Jürgen Paul
@ Legit - Je ne sais pas, mais traditionnellement la dernière étape est "Profit" :-) - Stephen C
Malheureusement, cela ne fonctionne pas avec nginx 1.11. Depuis la dernière mise à jour, il y a environ 3 ans, il semble que ce ne soit plus la solution. - izogfif


Vous pouvez spécifiquement invalider en cache pages à travers

proxy_cache_bypass       

Dites que vous voulez mettre en cache une page, définissez le cache de cette façon

location = /pageid {
  proxy_pass http://localhost:82;
  proxy_set_header   Host             $host;
  proxy_set_header   X-Real-IP        $remote_addr;
  proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
  proxy_ignore_headers Set-Cookie; 
  proxy_ignore_headers Cache-Control; 
  proxy_cache_bypass        $http_secret_header;
  add_header X-Cache-Status $upstream_cache_status;
}

Maintenant, quand tu veux invalide cette page et cache à nouveau 

Faire un appel secret curl avec l'en-tête

curl "www.site.com/pageid" -s -I -H "secret_header:true" 

Il sera invalidé et mis en cache.

Fonctionne à partir de nginx 0.7.

En prime, le add_header X-Cache-Status peut être utilisé pour vérifier si la page provient du cache ou non.


46
2017-11-26 04:00



Cela ne peut mettre à jour que les pages mises en cache lorsque la nouvelle page peut également être mise en cache. Si vous avez supprimé une page (404 ou d'autres erreurs sont maintenant résolues par le serveur), la page envoie maintenant un en-tête Set-Cookie ou un en-tête "Content-Control: private", le contenu mis en cache ne sera pas "invalidé". - rbu


Je vous suggère de donner Vernis un essai. Varnish est spécifiquement conçu comme un cache de proxy inverse. Il honorera tous les en-têtes de contrôle de cache que vous envoyez à partir du serveur d'origine, ce qui satisfait votre première demande.

Pour votre deuxième demande, invalidation explicite. Ma recommandation est fortement de changer le nom de l'URL de la ressource que vous souhaitez invalider, soit en renommant le fichier, soit en utilisant une forme de bus de cache de chaîne de requête. Le vernis a un PURGE Opération qui supprimera la ressource du cache de Varnish, mais ne vous permettra pas de contrôler d'autres caches entre vous et l'utilisateur. Comme vous avez dit vouloir purger explicitement une ressource, les en-têtes de contrôle http standard ne vous aideront pas. Dans ce cas, le moyen le plus sûr de vaincre la mise en cache d'une ressource est de la renommer.


36
2018-06-24 02:43



Pourriez-vous expliquer ce que vous vouliez dire par "renommer le fichier ou utiliser une forme de requête de cache de chaînes de requête"? Je ne suis pas sûr de comprendre pourquoi ce n'est pas une bonne idée d'utiliser une opération comme PURGE. - Continuation
+1 pour le vernis. Il est toujours préférable d'utiliser les bons outils pour le travail. - Tom O'Connor
@below: Il n'y a presque aucun espoir de toucher au vernis dans les domaines de la performance et de la polyvalence. Ceci est soutenu par l’un des principaux développeurs du noyau FreeBSD et une équipe dédiée basée en Europe. Le vernis est en production sur twitter, heroku et beaucoup d'autres. - Barry
L'exemple le plus simple d'un cache-buster consiste à ajouter un numéro de version dans une chaîne de requête à une ressource statique, afin que style.css devienne style.css? 123. Lorsque vous souhaitez publier une nouvelle version du fichier, vous modifiez l'URL de la ressource en style.css? 124. Les caches la récupèrent désormais comme un tout nouvel élément à mettre en cache séparément. Apache servira le fichier style.css avec n'importe quelle chaîne de requête ajoutée. Par conséquent, aucune modification du fichier n'est requise. - chmac
Si possible, il est préférable de placer le buster de cache dans le nom de fichier lui-même, tel que style.v123.css car certains caches ne mettront pas en cache les demandes comportant une chaîne de requête. - Noah McIlraith


Pour invalider les pages sélectionnées, vous pouvez utiliser le correctif "cache_purge" pour nginx-0.8.x qui fait exactement ce que vous voulez;)

C'est disponible ici.


7
2017-11-17 07:38





La plupart des outils de mise en cache (Citrix) permettent une actualisation forcée (Ctrl + r) pour repeupler une page mise en cache.

Voici une astuce que j'ai trouvée pour faire quelque chose de similaire dans nginx.

server  {
        # Other settings
        proxy_pass_header       Set-Cookie; # I want to cache logged-in users
        proxy_ignore_headers    X-Accel-Redirect;
        proxy_ignore_headers    X-Accel-Expires Expires Cache-Control;
        if ($http_cache_control ~ "max-age=0") {set $eac 1;}
        proxy_cache_bypass $eac;
}

Cela suppose que lorsque vous faites un Ctrl + r dans votre navigateur, l'en-tête Cache-Control a max-age = 0 dans sa requête. Je sais que Chrome le fait, mais je n'ai pas essayé dans d'autres navigateurs. Il est facile d’ajouter d’autres champs d’en-tête. Il suffit d’en ajouter d’autres si les instructions définissant la $eac variable à 1.


6
2018-04-10 23:02





La mise en cache est une fonction assez nouvelle dans nginx (et pas si bien documentée pour le moment), mais suffisamment stable pour être utilisée en production.


4
2018-06-24 02:25





Je crois NginxHttpProxyModule est capable de caheing des requêtes http. Recherchez les directives commençant par:

proxy_cache

Oui, il est possible de contrôler le comportement du cache via des directives telles que:

proxy_cache_valid

3
2018-06-24 10:12





Sur la base du fait que vous ne pouvez pas trouver de documents sur celui-ci, je serais un peu méfiant quant à son utilisation en production. Avez-vous envisagé de vernir? C'est mon "nginx de proxys inversés", petit, léger, qui fait un travail et le fait bien.


2
2018-06-24 01:38



La documentation est ici: wiki.nginx.org/NginxHttpProxyModule#proxy_cache - rmalayter


Si vous utilisez les balises eTags sur votre application et que vous placez nginx devant elle, elle se chargera de l'expiration, car si eTag change, le cache sera invalidé.


1
2017-11-16 15:20



Vraiment? Il semble que ngnix correspond à l'etag et ne parle jamais à l'application pour savoir s'il existe un etag mis à jour. - John Naegle