Desplegando con Cero Inactividad (ZDT) | ELASTICSERVER.CO S.A.S.

Desplegando con Cero Inactividad

ZDT (Zero Deploy Time)

La mayoría de los servicios web modernos deben ser accesibles para los usuarios en todo momento. Un problema común pero que a menudo se pasa por alto aquí es el proceso de reinstalación del proyecto (es decir, actualización), que hace que su aplicación se caiga o devuelva errores hasta que finalice la operación. Esto se puede resolver con una variedad de herramientas como Capistrano, Fabric y otras. Sin embargo, estos suplementos a menudo requieren tiempo, gastos y conocimientos especializados adicionales para integrarse y configurarse correctamente(por ejemplo, esto se puede realizar mediante la configuración de varios servidores con un equilibrador de carga en frente de ellos; mientras la implementación se ejecuta en un servidor, se excluye de la lista de rutas, luego de que otros servidores podrían actualizarse). Obviamente, tal implementación es bastante complicada y requiere muchos recursos adicionales, por lo tanto, se necesita un mejor método .

Una tal nueva solución fue propuesto para las aplicaciones PHP, que se ejecuta en la parte superior de Apache, por Rasmus Lerdorf, el fundador de este lenguaje de programación y, al mismo tiempo, el equipo de Jelastic . Como se usa activamente en Etsy y, por lo tanto, es un enfoque probado en la batalla, posteriormente se tomó como la base para la característica de Despliegue atómico y tiempo de inactividad cero en Elasticserver. La idea principal de este método se basa en los siguientes dos puntos:

cada vez que se ejecuta un nuevo proceso de implementación, los archivos de la aplicación correspondiente se duplican y se almacenan en un directorio de servidor separado (que se nombra automáticamente de acuerdo con su fecha / hora de creación para una fácil identificación)
un re director de solicitudes especiales, llamado enlace simbólico , cambia entre las diferentes versiones de la aplicación después de cada actualización, señalando la que debería usarse actualmente

De esta manera, los archivos de proyecto actualizados se pueden implementar sin problemas, mientras que la versión del código inicial continúa funcionando y manejando las sesiones de los usuarios. Y cuando la implementación se completa por completo, el enlace simbólico cambia instantáneamente a la versión más reciente de la aplicación implementada con éxito, comenzando a redirigir todas las solicitudes entrantes. Todo esto en conjunto hace que el proceso de implementación sea completamente atómico e implícito para sus clientes, al mismo tiempo que lo libera de realizar muchas operaciones manuales previstas .

A continuación, exploraremos este mecanismo con más detalle describiendo :

Entonces, ¡sigamos!

Flujo de trabajo e implementación en ZDT

En primer lugar, consideraremos más específicamente cómo el mecanismo de implementación de tiempo de inactividad PHP descrito anteriormente funciona realmente en Elasticserver; examinemos todos estos procesos paso a paso con un ejemplo real.

1. Para empezar, necesitará un ambiente PHP (ya sea nuevo o existente). Usaremos Apache para este ejemplo :

2. A continuación, proceda a la implementación de la aplicación requerida. Durante este procedimiento, debe marcar la casilla correspondiente en el marco de confirmación apropiado (según el tipo de fuente de proyecto utilizado) para habilitar la opción de implementación de ZDT:

para la implementación a través de un archivo local o URL directa

Tenga en cuenta que mientras realiza esto por primera vez para la aplicación ya existente, implementada en el contexto ROOT , todos los datos anteriores normalmente se borrarán y se sobrescribirán con la instalación de la aplicación «desnuda» (solo para la implementación a través de archivo / URL).

para la implementación a través de VCS (por ejemplo, desde GIT / SVN o repositorio de Bitbucket ):

Nota:

el indicador Habilitar implementación de tiempo de inactividad cero se activa solo cuando se implementa en el contexto ROOT de su servidor de aplicaciones PHP. De lo contrario, se utilizará el método clásico.
mientras trabaja con repositorios VCS, el modo de implementación elegido será recordado y utilizado para todas las actualizaciones automáticas adicionales de esta aplicación hasta que la cambie manualmente
en general, recomendamos no usar las rutas absolutas «codificadas» en el código y las configuraciones de su aplicación mientras usa la función de implementación atómica, para garantizar que permanezca operativa independientemente del nombre del directorio del proyecto

3. Durante la implementación inicial , se crea una carpeta ROOT_timestamp (es decir, ROOT_year.mm.dd-hh.mm.ss ) y un archivo ROOT especial como enlace simbólico a esta carpeta dentro del directorio webroot de su servidor de aplicaciones.

Como es normal, la aplicación está lista para manejar solicitudes justo después de que finalice el proceso de implementación.

Si navega dentro del directorio ROOT , en un círculo arriba, se verá el contenido de la versión de la aplicación utilizada actualmente, es decir, se cambia cada vez que se cambia el enlace simbólico.

Esto se puede ver claramente si ingresa el contenedor de su servidor de aplicaciones a través de SSH y ejecuta el comando de listado de archivos de formato largo para su carpeta webroot , es decir:

ls -l /var/www/webroot

De esta manera, puede localizar fácilmente el enlace simbólico, ya que está marcado en color dentro de la lista, y ver la ruta de redireccionamiento real.

4. Durante la segunda implementación (es decir, cuando se implementa una actualización), se crea una nueva carpeta ROOT_timestamp , de tal manera que la versión de la aplicación real y los clientes que actualmente trabajan con ella no se ven afectados.

Justo después de desempaquetar los nuevos archivos, el enlace simbólico cambia a esta nueva carpeta, redirigiendo todas las solicitudes recién recibidas. Con esto, la primera carpeta se guarda para procesar las sesiones de los usuarios «antiguos» (es decir, dónde comenzó el manejo antes del cambio de enlace simbólico).

Tenga en cuenta que al actualizar una versión de la aplicación utilizando el archivo / URL, todo el contenido generado por el usuario (si lo hay) debe moverse manualmente al directorio de la aplicación recién creado desde el anterior, almacenado junto (anteriormente, tal operación implica la anulación completa de todos los datos de contexto).

Si usa VCS, el contenido del directorio de la aplicación se copia por completo (archivos con seguimiento y sin seguimiento), por lo que no se requieren operaciones manuales. Sin embargo, recomendamos adoptar la práctica del uso de la lista .gitignore para los archivos innecesarios de su proyecto, ya que esto le ahorraría una cantidad de recursos y tiempo durante las repeticiones de las implementaciones.

5. Todos los siguientes despliegues atómicos se realizarán de la misma manera. Durante cada uno de ellos, se elimina la carpeta de proyecto más antigua, mientras se agrega un nuevo directorio ROOT_timestamp para la versión de proyecto más reciente.

De esta manera, solo 2 versiones de la aplicación implementada, la última y la anterior, se almacenan simultáneamente en un servidor de aplicaciones (sin embargo, la versión anterior también se puede quitar fácilmente manualmente cuando ya no es necesaria). Esto asegura que no se consuma más espacio en el disco.

Nota: Si desea evitar que alguna versión del proyecto se borre automáticamente, simplemente cambie el nombre de la carpeta correspondiente antes de ejecutar la nueva implementación.

Todas las operaciones están completamente automatizadas, por lo que no se requiere la participación de un desarrollador adicional, mientras que la implementación en sí se realiza en un modo «suave», es decir, incluso sin necesidad de reiniciar el servidor de aplicaciones y, como resultado, sin ningún tiempo de inactividad de la aplicación.

Implementación de ZDT en servidores PHP

Profundizando en los detalles de la implementación técnica, el soporte de la opción de implementación atómica en Elasticserver está garantizado por los siguientes ajustes, aplicados a las instancias PHP correspondientes :

Apache PHP
La funcionalidad adecuada se maneja con la ayuda del módulo mod_realdoc , que controla el cambio de enlace simbólico mencionado anteriormente. Se puede configurar adicionalmente (si es necesario) a través del panel de Elasticserver dentro del archivo conf.d> mod_realdoc.conf .

Consejo: Aquí, el parámetro RealpathEvery define el período de tiempo durante el cual se almacena la ruta del enlace simbólico y la frecuencia de su actualización. Su valor predeterminado ( 0 , como se indica en los comentarios del código) se cambió a 2 para garantizar que se completen todas las operaciones requeridas (es decir, implementación y cambio) antes de redirigir las solicitudes a la nueva versión del proyecto y, como tal, evitar ralentizaciones.

Este valor puede cambiarse fácilmente a uno personalizado si es necesario (solo no olvide reiniciar el nodo del servidor de aplicaciones para su dispositivo). Sin embargo, si usa la función de implementación de ZDT, no recomendamos establecerla demasiado alta, ya que esto causaría demoras en el cambio de enlace simbólico.

Para obtener más información sobre los detalles de este módulo, visite su página de origen .

Comparación y resumen

Para probar los beneficios del enfoque de actualización ZDT, se ejecutó una prueba de carga simple, con los siguientes parámetros como base:

aplicación : se implementa una versión básica de WordPress CMS (es decir, su distribución predeterminada sin contenido pesado)
herramienta de generación de carga : Apache JMeter , configurada para enviar continuamente la cantidad requerida de solicitudes concurrentes a nuestra aplicación durante el proceso de redistribución
marco de tiempo : la prueba comienza poco tiempo antes de que se ejecute el proceso de redistribución y finaliza unos segundos después de completarse

Entonces, evalúe los resultados para ambos métodos de implementación con las estadísticas simples que hemos recibido.

Implementación de archivo

Comencemos con la variante más utilizada de la implementación del proyecto, a saber: clásica , es decir, instalación desde un único paquete archivado sin opciones adicionales como ZDT habilitado:

Como puede ver, en realidad obtenemos resultados bastante buenos:

tiempo de respuesta rápido y constante (el gráfico azul), solo 1.2 segundos en promedio
restauración rápida a la operatividad normal (es decir, cuando todas las solicitudes entrantes se procesan con éxito (la línea verde) sin errores (el gráfico rojo)) después de la implementación del nuevo paquete
no aparece solo durante dos segundos: vea el pico de la línea roja (sin embargo, la implementación de un proyecto más pesado y repleto de contenido aumentará este intervalo con certeza)

Ahora, realicemos la misma prueba con el segundo competidor: ZDT . Para una mejor percepción de comparación, conservaremos la misma leyenda de color que antes:

El tiempo de respuesta se mantiene estable y casi sin cambios, pero puede notar su leve aumento durante el procedimiento de actualización, que es causado por el proceso de implementación adicional que se ejecuta junto con el servicio de solicitudes. Con esto, ni siquiera hay un solo error durante toda la prueba.

Por lo tanto, de esta manera, podemos suponer que la implementación de tiempo de inactividad cero supera el problema de las solicitudes fallidas durante la redistribución de aplicaciones, manteniendo simultáneamente el tiempo de respuesta promedio en el mismo nivel. Además, la opción atómica le permite guardar todo el contenido generado por el usuario, ubicado dentro del directorio de la aplicación, y moverlo fácilmente a la nueva versión de la aplicación si es necesario (mientras que el método clásico normalmente implica solo la versión de la aplicación completamente nueva despliegue)

También puede notar que el tiempo mínimo de manejo de solicitudes para el método clásico es significativamente menor que para el método atómico y, por lo tanto, parece brindar un mejor rendimiento. Pero no se engañe, ya que es solo un efecto secundario de la presencia de solicitudes fallidas (donde el tiempo de servicio también se cuenta, a pesar de que no se procesa), mientras que el tiempo de respuesta promedio es casi el mismo para ambos métodos.

Implementación de VCS

A continuación, repitamos nuestra prueba para el segundo tipo de implementación Elasticserver (es decir, si usa repositorios Git / SVN) para averiguar si ZDT conserva sus ventajas en este caso. Y nuevamente comenzaremos con el método clásico :

A medida que las fuentes de implementación se colocan en el recurso remoto, esto requerirá un poco más de tiempo en comparación con la instalación del archivo ya cargado, lo que, de hecho, nos ayuda a ver claramente la diferencia. El tiempo de respuesta ahora tiene un menú desplegable bastante largo (durante casi 4 segundos en nuestro caso), causado por la falta de disponibilidad de la aplicación (puede ver que las solicitudes entrantes comienzan a fallar al mismo tiempo; esto se muestra con un pico en el gráfico de errores ). Todo lo demás sigue siendo similar al tipo de implementación anterior.

Tenga en cuenta que, a diferencia de la implementación del archivo (donde el proyecto anterior se elimina por completo antes de la redistribución, lo que siempre causará tiempo de inactividad), aquí el procedimiento de actualización supone el cambio de los diferentes archivos solamente. Por lo tanto, es posible que no se enfrente a ninguna interrupción en el trabajo del servicio si los archivos que deben cambiarse no se utilizan actualmente.

Finalmente, la última prueba para el enfoque de implementación de ZDT a través de VCS también está en línea con nuestras expectativas al brindar un tiempo de respuesta estable con su pequeño incremento durante la ejecución simultánea de operaciones tales como el manejo de sesiones de usuarios y la copia / actualización de proyectos.

Al mismo tiempo, puede ver que no aparecieron errores y que todas las solicitudes entrantes se procesaron con éxito .

Conclusión

Ahora, cuando tenga toda la información (tanto técnica como visualizada en gráficos prácticos) sobre la investigación y haya visto cómo de fácil es usar la opción ZDT dentro de Elasticserver Cloud, es hora de resumir y llegar a una conclusión sobre los beneficios clave que trae para el alojamiento de su aplicación PHP:

ZDT no requiere ningún recurso adicional, como instancias / herramientas separadas para su aplicación; todo lo que necesita es suficiente espacio en disco para almacenar dos versiones del proyecto (la actual y la anterior). Podría considerarse como una solución casi gratuita, especialmente en comparación con la mayoría de otras opciones posibles, que pueden requerir servidores de aplicaciones adicionales, equilibradores, servicios externos, etc.
la implementación sigue siendo tan simple como antes: no se requieren configuraciones adicionales o intervención humana
el tiempo necesario para el despliegue atómico es exactamente el mismo que para el método clásico, por lo que no se esperan demoras
finalmente, el despliegue de Tiempo de inactividad cero mantiene su nombre al garantizar que esté completamente implícito para sus clientes con un procedimiento de actualización sin errores (en contraste con la variante clásica, que, sin ser mejorada adicionalmente, causa una gran cantidad de errores incluso en el caso de un pequeño despliegue de la aplicación)

De esta manera, el uso de la implementación de ZDT hace que la actualización de sus proyectos sea completamente sencilla e invisible para los clientes, ¡ayudándole a aprovechar al máximo su aplicación!