Use Varnish con Magento 2 para una mejor experiencia de usuario final

¡Hola a los lectores del blog de Amasty!

Hoy vamos a tocar el caché de Varnish, su sintaxis: los lados del cliente y del backend, el servidor web y la configuración de Magento 2, y más.

¿Te parece algo que te interese?

Deje las cosas atrás durante 15 minutos para leer la publicación hasta el final.

 

¿Qué es el barniz? ¿Cómo funciona con Magento 2?

Varnish Cache es un acelerador de aplicaciones web, que también se conoce como proxy inverso HTTP de almacenamiento en caché. A diferencia de servidores web como Apache y Nginx, Varnish fue diseñado para usarlo exclusivamente con el protocolo HTTP. Es un acelerador HTTP diseñado para sitios web dinámicos con mucho contenido, como su tienda Magento 2.

Al ejecutar una tienda en línea en Magento 2, debe saber que la plataforma admite versiones de Varnish a partir de la 3.0.5 y posteriores o cualquier versión de Varnish 4.x. Digamos que eligió una versión apropiada y lanzó Varnish para su tienda Magento 2. Entonces, ¿cómo funcionan las solicitudes de los clientes con Varnish y el servidor? Un esquema simple a continuación da una explicación visual del proceso:

Ahora, profundicemos en el proceso y hablemos en detalle.

Como puede ver, las solicitudes HTTP de los usuarios pasan por Internet y dan como resultado numerosas solicitudes de CSS, HTML, JavaScript e imágenes. Todos juntos se llaman activos. Del esquema anterior, vemos que Varnish Proxy pasa a continuación y pasa todas estas solicitudes al servidor web.

Al regresar del servidor web, los activos almacenables en caché se almacenan en Varnish. Varnish cumple con las solicitudes de esos activos de los usuarios futuros (es decir, las solicitudes ya no llegan al servidor web). Al hacerlo, Varnish devuelve el contenido almacenado en caché extremadamente rápido sin hacer esperar a sus visitantes por mucho tiempo . Como resultado, obtiene un tiempo de respuesta más rápido y una cantidad reducida de solicitudes que pasan directamente a Magento. Por lo tanto, Varnish permite reducir el tiempo de respuesta y el consumo de ancho de banda de la red para solicitudes similares en el futuro.

Pero, ¿qué pasa con las actualizaciones de activos? ¿Los usuarios obtienen el contenido desactualizado?

No es del todo cierto. Los activos almacenados en caché por Varnish caducan automáticamente en un período preconfigurado o son reemplazados por versiones más nuevas de los mismos activos. También puede borrar el caché manualmente a través del Panel de administración de Magento→Sistema→Gestión de caché o usando este comando de Magento → caché: limpiar .

¿Qué hace que Varnish sea un procesador HTTP en el que todos ganan?

¿Qué hace que Varnish sea un procesador HTTP en el que todos ganan?

¿Ha oído hablar del lenguaje de configuración de barniz (VCL) y su objetivo principal?

VCL es el principal mecanismo de configuración de Varnish. Es un lenguaje específico de dominio (DSL) utilizado para escribir ganchos. Los ganchos se llaman en puntos críticos del manejo de una solicitud.

Es este elemento el que hace que Varnish sea más configurable y ajustable en comparación con otros aceleradores HTTP. Una vez cargado, un script VCL se traduce a C y luego el compilador del sistema lo compila en un objeto compartido. Después de eso, se carga directamente en el acelerador, que se puede reconfigurar sin reiniciar.

Cada solicitud pasa por Varnish, lo que le permite influir en la forma en que se maneja la solicitud. Todo lo que necesita es modificar el código VCL .

Por ejemplo, puedes:

• dirigir ciertas solicitudes a backends particulares;
• alterar las solicitudes y respuestas;
• hacer que Varnish aplique diferentes acciones basándose en las propiedades de solicitud/respuesta.

Es exactamente por eso que Varnish es un procesador HTTP en el que todos ganan, no solo para el almacenamiento en caché.

Varnish traduce VCL a un código binario, que se ejecuta cuando llegan las solicitudes, lo que hace que el impacto de VCL en el rendimiento sea insignificante. Todos los archivos VCL están organizados en subrutinas, que se ejecutan en diferentes momentos. Por lo tanto, una subrutina se ejecuta cuando recibimos una solicitud, otra, cuando se obtienen archivos del servidor backend:

Cubriremos cómo funcionan las subrutinas en la siguiente parte.

Entonces, ¡sigue leyendo!

Barniz: Sintaxis VCL

La VCL tiene una sintaxis simple que heredó mucho de C y Perl. Así, los bloques están delimitados por llaves, las declaraciones terminan en punto y coma y los comentarios pueden escribirse de la misma forma que en C, C++ o Perl, eso depende de sus preferencias personales.

 Nota: VCL no contiene bucles ni sentencias de salto. Para obtener una documentación completa de la sintaxis de VCL, siga el enlace .

Subrutinas integradas

VCL no le permite comenzar con un archivo vacío, le permite interferir con ciertos aspectos del flujo de ejecución de Varnish. El flujo, a su vez, se define en una máquina de estados finitos. Estos aspectos o hooks (como decíamos antes) presentan etapas específicas del flujo donde el comportamiento de Varnish en las etapas se expresa a través de diferentes subrutinas integradas .

Para habilitar un comportamiento necesario, debe:

• definir una subrutina en su archivo VCL,
• extender el comportamiento en esta subrutina,
• y emita la recarga del archivo.

Para determinar cómo continuará el procesamiento en la máquina de estado de procesamiento de solicitudes, debe usar palabras clave. En cuanto al comportamiento de las palabras clave return(), es similar a otras subrutinas. Por lo tanto, las diferencias se documentan solo cuando es necesario.

Lado del cliente

vcl_recv

Se llama (a) al comienzo de una solicitud, (b) después de recibir una solicitud completa, (c) analizada o (d) después de reiniciar. El propósito de la subrutina es decidir si atender o no la solicitud; modificar la solicitud y elegir cómo procesarla más.

Al llamar a return() en una de estas palabras clave: código de error [motivo], pasar, canalizar, buscar, puede terminar la subrutina.

tubo_vcl

La subrutina se llama en todo el modo de canalización. Al hacerlo, la solicitud se pasa al backend. Después, los datos adicionales del cliente o backend se transmiten sin cambios hasta que uno de los extremos completa la conexión. En este modo de tubería, no se llamará a ninguna otra subrutina VCL después de vcl_pipe .

Al llamar a return() en una de estas palabras clave: código de error [razón], tubería, puede terminar la subrutina.

vcl_pass

La subrutina se llama al entrar en el modo de paso. En esto, la solicitud se envía al backend y la respuesta del backend se pasa al cliente sin ingresar en el caché.

Al llamar a return() en una de estas palabras clave: código de error [motivo], pasar, puede terminar la subrutina.

vcl_hash

La subrutina se llama después de vcl_recv para crear un valor hash de la solicitud. Se utiliza como clave para buscar el objeto en Varnish.

Al llamar a return() en una de estas palabras clave: hash, puede terminar la subrutina.

vcl_purga

La subrutina se llama cuando se completa la purga y se descartan todas las variantes.

Al llamar a return() en una de estas palabras clave: fallar, reiniciar, sintetizar (código de estado, razón), puede terminar la subrutina.

vcl_hit

La subrutina se llama si una búsqueda de caché se corona con éxito. En esto, el objeto hit puede estar desactualizado.

Al llamar a return() en una de estas palabras clave: fallar, reiniciar, sintetizar (código de estado, motivo), aprobar, fallar, entregar, puede finalizar la subrutina.

vcl_miss

La subrutina se llama en caso de que el documento necesario no se haya encontrado durante una búsqueda en caché o si vcl_hit devolvió la búsqueda. El propósito de la subrutina es elegir si intentar obtener el documento requerido desde el backend o no.

Al llamar a return() en una de estas palabras clave: fallar, reiniciar, sintetizar (código de estado, motivo), aprobar, fallar, recuperar, puede finalizar la subrutina.

vcl_deliver

La subrutina se llama antes de que cualquier objeto (excepción: vcl_synth ) se lleve al cliente.

Al llamar a return() en una de estas palabras clave: fallar, reiniciar, sintetizar (código de estado, razón), entregar, puede terminar la subrutina.

vcl_synth

La subrutina se llama para entregar un objeto sintético. En este, el objeto sintético se genera en VCL, pero no se toma del backend. En contraste con el objeto definido vcl_backend_error , el objeto definido vcl_synth nunca ingresa al caché.

Al llamar a return() en una de estas palabras clave: fallar, reiniciar, entregar, puede terminar la subrutina.

Lado de fondo

vcl_backend_fetch

La subrutina se llama antes de enviar la solicitud de backend. En esto, normalmente modifica la solicitud antes de que llegue al backend.

Al llamar a return() en una de estas palabras clave: fail, fetch, puede terminar la subrutina.

vcl_backend_respuesta

La subrutina se llama cuando los encabezados de respuesta se recuperan correctamente del backend.

Al llamar a return() en una de estas palabras clave: fallar, entregar, reintentar, aprobar, puede finalizar la subrutina.

vcl_backend_error

La subrutina se puede llamar en dos casos, el primero es si fallamos en la recuperación del backend, el segundo es cuando se excede max_retries .

Al llamar a return() en una de estas palabras clave: fallar, entregar, reintentar, puede terminar la subrutina.

Esta ilustración muestra cómo estas subrutinas están interrelacionadas y funcionan juntas:

Solicitar y responder a objetos VCL

Hay varios objetos importantes que debe tener en cuenta en VCL. Los objetos se pueden manipular usando VCL.

requerimiento

Este es un objeto de solicitud. Cuando Varnish recibe la solicitud , se crea y completa el objeto req . La mayor parte del trabajo que realiza en vcl_recv se realiza en/con el objeto req .

bereq

Este es un objeto de solicitud de back-end. Varnish lo crea antes de pasar al backend y se basa en el objeto req .

beresp

Este es un objeto de respuesta de back-end. Lleva consigo los encabezados del objeto que proviene del backend. En caso de que desee cambiar la respuesta que proviene del servidor, modifique este objeto en vcl_backend_response .

resp.

Esta es una respuesta HTTP antes de que se entregue al cliente. Normalmente se modifica en vcl_deliver .

objeto

El objeto se almacena en la memoria caché y está destinado solo para lectura.

Puede encontrar el archivo con todas las configuraciones a través de la dirección: nano /etc/varnish/default.vcl o ver un archivo default.vcl aquí .

Para obtener más información, haga clic en el enlace .

¿Cómo instalar Varnish y configurar el servidor web?

La teoría es una cosa, pero la práctica “en el campo” es otra muy distinta. Precisamente por eso, a continuación vamos a explicar cómo instalar Varnish y realizar todas las configuraciones del servidor web.

Instalación de barniz

Para que Varnish se comunique con su servidor web, modifique la configuración en el archivo de host virtual de su sitio web. Después de eso, es hora de instalar Varnish en el sistema. Puedes hacerlo usando este comando apt :

#sudo apt install barniz -y

Luego deberá iniciar Varnish y ejecutarlo en el arranque del sistema usando estos comandos systemctl :

#systemctl iniciar barniz
#systemctl habilitar barniz

Varnish está preestablecido para usar el puerto 6081 para accesos públicos y el puerto 6082 para la interfaz web de administración de forma predeterminada. Para verificar las condiciones predeterminadas, use este comando netstat :

#netstat-plntu

Luego inícielo y verifique el caché HTTP de Varnish:

Como vemos en el ejemplo anterior, Varnish HTTP Accelerator se instaló correctamente.

Configuraciones del servidor web

 Nota:  en caso de que ejecute Nginx, omita este paso. Si está ejecutando Apache, abra ports.conf para cambiar el 80 en Listen 80 a otro puerto.

Apache:

#cd /etc/apache2/sitios-disponibles/
#vim ejemplo.com.conf
<VirtualHost *:8080>

Nginx:

#cd /etc/nginx/sites-disponible/
#vim example.com
escucha 8080;
escucha [::]:8080;

Verifique su archivo /etc/varnish/user.vcl y asegúrese de que el backend predeterminado esté configurado para usar el puerto 8080:

Vuelva a cargar la configuración para su servidor web (Apache o Nginx respectivamente): #sudo systemctl reload apache2 #sudo systemctl restart nginx Después de eso, pruebe su servidor web una vez más usando el comando netstat : #netstat -plntu y verifique si está funcionando con el no predeterminado Puerto HTTP 8080:

Varnish como servidor web proxy

Si desea configurar Varnish para que funcione como un servidor proxy, asegúrese de que Varnish se ejecute en el puerto HTTP 8080, como lo explicamos anteriormente. Una vez hecho esto, debemos definir el servidor backend y modificar Varnish para que se ejecute en el puerto HTTP 80. (1) Primero, navegue hasta el directorio de configuración de Varnish para editar el archivo default.vcl : #cd /etc/varnish #vim default. vcl Encuentre la línea de fondo para realizar la configuración como se muestra a continuación:

Guarde los cambios y deje el archivo.

(2)  En segundo lugar, debemos configurar Varnish para que funcione con el puerto HTTP 80. Para ello, vaya al directorio /etc/default y modifique el archivo de configuración de Varnish :

#cd /etc/default/
#vim barniz

Cambie el puerto predeterminado 6081 al puerto HTTP 80 en la línea DAEMON_OPTS=”-a :80 :

Guarde los cambios y salga.

(3) Vaya al directorio systemd para editar el archivo varnish.service:

#cd /lib/systemd/system
#vim barniz.servicio

Luego cambie el puerto de barniz 6081 al puerto HTTP 80:

ExecStart=/usr/sbin/varnishd -j unix,user=vcache -F -a :80 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s malloc,256m

Guarde los cambios y omita el directorio.

Ahora necesita volver a cargar la configuración de systemd y reiniciar Varnish. Usa los comandos:

#systemctl daemon-reload
#systemctl reiniciar barniz

Cuando todo esté listo, revisa Varnish:

#netstat-plntu

Luego, asegúrese de que Varnish se esté ejecutando en el puerto HTTP 80, como se muestra a continuación. Para esto, prueba la configuración de Varnish:

Configuraciones de Magento 2

Para configurar su Magento para usar Varnish, inicie sesión en el Panel de administración , luego vaya a
Tiendas → Configuración → Avanzado → Sistema → Caché de página completa :

En la lista de aplicaciones de almacenamiento en caché , elija Varnish Cache . Ingrese un valor en el campo TTL para contenido público , expanda la configuración de Varnish Configuration e ingrese la siguiente información:

lista de acceso

Ingrese el nombre de host completo, la dirección IP o el rango de direcciones IP de notación de enrutamiento entre dominios sin clase (CIDR) para el cual invalidar el contenido.

host de back-end

Ingrese el nombre de host completo o la dirección IP y escuche el puerto del backend de Varnish o el servidor de origen. En nuestro caso, es 127.0.0.1

puerto back-end

Complete la escucha del número de puerto. En nuestro caso es 8080.

En Magento, también puede obtener un archivo vcl preconfigurado, exportarlo y usarlo como predeterminado.
Una vez hecho esto, guarda los cambios.

Barniz de prueba

Puede probar su Varnish de varias maneras. Elige cuál te conviene más y simplemente hazlo.

#1. Probar Varnish usando cURL

Puede probar Varnish con el comando curl , por lo que verá los encabezados HTTP del servidor:

#curl -I tudominio.com

#2. Pruebe Varnish utilizando navegadores web

Para probar Varnish en su navegador, abra el navegador web para escribir la URL o dirección de su servidor:

#3. Registro de prueba de barniz

Varnish proporciona algunos comandos para administrar y ver registros. Para obtener el registro de acceso de Varnish, usaremos varnishncsa :

Así, habiendo probado el trabajo de Varnish, podemos decir que se completó su instalación y configuración como proxy inverso para el servidor web Nginx.

Haga clic aquí para encontrar útiles herramientas de línea de comandos de Varnish que pueden ayudarlo a ver registros detallados, estadísticas y más.

Envolver

Entonces, ¿qué beneficios puedes obtener al usar Varnish?

Estos son:

• velocidad y rendimiento;
• ahorro de ancho de banda;
• escalabilidad, su sitio se ajustará a la demanda de cualquier cliente, no hay más sobrecargas;
• Varnish continúa sirviendo contenido almacenado en caché a los visitantes incluso si su sitio falla;
• utilizando VCL puede crear soluciones, reglas y módulos personalizados;
• y, como resultado de la implementación de Varnish, logra una experiencia de usuario final mejorada.

Esperamos que el post te haya sido de utilidad.

¿Aún tienes preguntas?

Siéntase libre de plantear cualquiera en los comentarios a continuación.