Tengo Varnish frente a varios servidores web, puedo ejecutarlos como nativos de Barniz o mediante comprobaciones ascendentes a través de nginx, pero solo se almacena en caché el contenido estático (no es de extrañar), respetando también las cadenas de consulta, es decir
/main.css?v=1y /main.css?=v2se almacenan en caché por separado
Actualizo los servidores uno por uno, de hecho, todo esto no se puede hacer exactamente al mismo tiempo sin tiempo de inactividad, implementación general.
Si main.cssse actualiza enunobackend y envío la solicitud de acuerdo con la nueva versión de la página web al barniz y la solicitud /main.css?=v2, es posible que aún busque un archivo en la máquina que tiene una versión anterior y que main.cssaún no se ha actualizado, por lo que ahora obtengo v1 en el caché como v2 y no hay nada que pueda hacer, a menos que caduque el TTL (lo cual es demasiado tarde).
Puedo invalidar el caché manualmente mediante solicitudes, está bien.
¿Existe alguna solución automatizada sin que el manual interfiera en el software de reescritura para obtener información sobre el barniz? como:
- ¿Es posible caducar el caché cuando aparece el backend, después de que la sonda sea buena?
- ¿algo más?
Gracias
Respuesta1
Si carga este código, o lo adapta a su versión de barniz, puede enviar solicitudes de tipo PURGE, con la URL de solicitud que coincida con el elemento que desea purgar, para borrar el elemento del caché de barniz. Puede usar esto básicamente para automatizar la purga selectiva al final del proceso de implementación en sus servidores Varnish, mediante comandos cURL o similares.
https://github.com/dreamhost/varnish-vcl-collection/blob/master/lib/purge.vcl