Cómo configurar un servidor de caché de Barniz: los Swapps
Los sitios web con alto tráfico necesitan servir el mismo contenido varias veces a diferentes usuarios. Dependiendo de su aplicación, puede ser muy costoso (los recursos hablan) procesar toda la lógica de la aplicación cada vez que un usuario solicita una página web. Aquí es donde viene el almacenamiento en caché del servidor, puede guardar una copia temporal del contenido en memoria y servir este contenido a todos los usuarios.
Varnish es excelente para almacenar contenido en caché en el lado del servidor. Esencialmente, debe almacenar contenido HTML en caché, pero también puede almacenar archivos en caché: CSS, JS, imágenes, documentos.
Suena bien, pero la verdad es que por defecto Barniz no hace nada, o al menos podrías estar desperdiciando las ventajas de esta pieza de software, y la documentación no ayuda, así que he escrito este artículo, para que puedas obtener el mayor beneficio de Barniz. Voy a explicar dónde y cómo configurar, probar e implementar un servidor de caché de Barniz para su aplicación.
Para fines de demostración, digamos que tenemos 2 instancias de servidor para nuestra aplicación y servidores de caché con las siguientes direcciones IP locales:
- Servidor de aplicaciones: 192.168.1.2
- Servidor de caché: 192.168.1.3
Instalar Varnish Cache Server
Para este propósito de artículos, vamos a instalar un Ubuntu server 16.04 con Varnish 4.0. Para instalar Barniz, solo necesita ejecutar:
sudo apt install varnish
Instalaré Varnish 4.0, y a partir de ahora estará prestando especial atención a 2 archivos específicos:/etc/default/varnishy /etc/varnish/default.vcl
Configuración del Backend
Lo primero que debe hacer es configurar el backend o indicar a Varnish dónde vivirá la aplicación web:
- ¿Cuál es el nombre de host o la dirección IP?
- ¿Qué es el puerto?
Para definir que necesita ir y actualizar el archivo /etc/varnish/default.vcly encontrar la siguiente sección, que se configurará para nuestro propósito de ejemplo como este:
backend default { .host = "192.168.1.2"; .port = "8080"; .first_byte_timeout = 60s; .connect_timeout = 300s;}
Le indicará a Varnish que escuche la aplicación que se ejecuta en IP 192.168.1.2 y puerto 8080.
Configure el demonio Varnish
Lo primero que necesita para definir dónde se ejecutará Varnish. Vamos a dejarlo ejecutándose en el puerto predeterminado 6081. Es muy común ejecutar este demonio en los puertos 80 y 443 para SSL, pero preferimos poner NGINX en el frente y dejarlo para atender el tráfico.
Con respecto a la memoria, una instalación en blanco de Barniz se ejecutará con 256 MB de memoria, que podría ser suficiente para algunas aplicaciones, pero para aplicaciones de alto tráfico, podría no ser suficiente, y más si ha reservado un servidor dedicado solo para caché.
Puede cambiar eso en:
/etc/default/varnish
Encuentre la siguiente sección:
DAEMON_OPTS="-a :6081 \-T localhost:6082 \-f /etc/varnish/default.vcl \-S /etc/varnish/secret \-s malloc,256m"
Para actualizar la cantidad de RAM, cambie la última línea donde dice 256m y actualice el valor requerido, en mi caso, quiero dedicar 3 GB de RAM a Barnizar, para que el bloque se vea como:
DAEMON_OPTS="-a :6081 \-T localhost:6082 \-f /etc/varnish/default.vcl \-S /etc/varnish/secret \-s malloc,3G"
Valide que se está ejecutando con la configuración correcta
Confirme que se está ejecutando como se esperaba, verifique el proceso ps aux | grep varnishy debería ver algo como:
/usr/sbin/varnishd -j unix,user=vcache -F -a :6081 -T :6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s malloc,3G
Reparar el demonio de inicio de Varnish en algunas instalaciones de Ubuntu
Hemos detectado un error en el que el servicio no sigue las instrucciones definidas en el archivo varnish y es posible que deba editar el servicio de inicio.
Para hacer eso, abra y edite el archivo
/lib/systemd/system/varnish.service
y verá algo como esto:
Description=Varnish HTTP acceleratorDocumentation=https://www.varnish-cache.org/docs/4.1/ man:varnishdType=simpleLimitNOFILE=131072LimitMEMLOCK=infinityExecStart=/usr/sbin/varnishd -j unix,user=vcache -F -a :6081 -T :6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s malloc,256MExecReload=/usr/share/varnish/reload-vclProtectSystem=fullProtectHome=truePrivateTmp=truePrivateDevices=trueWantedBy=multi-user.target
Para que funcione, deberá actualizar la sección dentro de la línea ExecStart y reemplazarla para la configuración requerida:
ExecStart=/usr/sbin/varnishd -j unix,user=vcache -F -a :6081 -T :6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s malloc,3G
Una vez que haya terminado con eso, debe recargar el demonio de servicio: systemctl daemon-reload y, a continuación, reinicie el barniz.
Cómo configurar para PURGAR la caché
Hay 2 formas de borrar la caché de Barniz:
- Reinicie el servicio de barniz.
- Enviar una solicitud de PURGA al servidor Varnish.
Reiniciar Barniz Se trata solo de reiniciar el servicio:
sudo service varnish restart
Pero lo que realmente necesitamos es poder enviar una solicitud de PURGA desde el servidor de aplicaciones. Se puede lograr instruyendo al servidor para que purgue una RUTA específica o todas ellas. Al usar CURL, la solicitud se vería como:
curl -X PURGE http://192.168.1.3:6181
De forma predeterminada, Varnish no permite una solicitud de PURGA desde un servidor externo, por lo que debe permitir solicitudes desde el servidor de aplicaciones. Para hacerlo, vaya a editar /etc/varnish/default.vcly busque la sección de purga donde necesita agregar la dirección IP del servidor de aplicaciones:
acl purge { "localhost"; "127.0.0.1"; "192.168.1.2"/24;}
Cómo depurar la PURGA
Tendrá que validar que todo funciona correctamente. Para ello, puede utilizar el siguiente comando:
varnishlog -g request -q 'ReqMethod eq "PURGE"'
Luego puede enviar una solicitud de PURGA y debería ver algo como esto para confirmar que se recibió la solicitud de PURGA:
* << Request >> 1179851- Begin req 1179850 rxreq- ReqStart 192.168.195.197 39700- ReqMethod PURGE- ReqURL /.*- ReqProtocol HTTP/1.1- ReqHeader Host: swapps.com- ReqHeader User-Agent: W3 Total Cache- ReqHeader Connection: close- ReqHeader X-Forwarded-For: 192.168.195.197- VCL_call RECV- Timestamp Process: 1531199642.768541 0.000094 0.000094- RespHeader Date: Tue, 10 Jul 2018 05:14:02 GMT- RespHeader Server: Varnish- RespHeader X-Varnish: 1179851- RespProtocol HTTP/1.1- RespStatus 200- RespReason OK- RespReason Purged- End
Un estado de aprobación de 200 significa que todo salió bien y Varnish ha borrado la caché de la URL solicitada, y debería tener todo lo que necesita para comenzar a almacenar contenido en caché en su servidor.
El siguiente paso si no lo ha hecho es configurar las reglas de qué contenido desea almacenar en caché y cuál no, pero ese es el tema para otra publicación de blog y dependerá en gran medida del tipo de aplicación, marco o CMS utilizado.