Implementar código en múltiples servidores front-end

Tenemos una situación en la que tenemos múltiples servidores de carga equilibrada que apuntan a una base de datos común.

En el funcionamiento normal de las cosas, esto funciona bien y proporciona redundancia, escalabilidad, etc.

Sin embargo, estamos descubriendo que la implementación es una tarea difícil.

Estamos utilizando muchas funciones y estamos tratando de automatizar la implementación. La implementación en este momento no es muy confiable.

De forma simplificada, el script de implementación para cada servidor tiene dos etapas

1. Actualizar archivos

2. Revertir características (que administrará dependencias, cambios de configuración, etc.)

¿Existen algunas prácticas recomendadas para implementar en varios servidores sin hacer que se encuentren en un estado inconsistente?

Hasta donde puedo ver si implementa los pasos 1 y 2 en el servidor A, provocará que el servidor B se rompa, si intenta el paso uno en ambos servidores antes de continuar con el paso 2, ambos se romperán por un tiempo.

Probablemente debería buscar en Aegir , que es, con mucho, el sistema de administración / implementación de sitios Drupal más flexible y potente. Es capaz de administrar 'plataformas' que abarcan varios cabezales web o 'clusters', así como una variedad de otras configuraciones.

Sugeriría leer la documentación de su comunidad, que generalmente es bastante buena, así como leer la excelente descripción general de mig5 y el artículo introductorio y algunos de sus otros artículos como este .

También puede obtener un buen soporte en el canal #aegir IRC.

Será un pequeño cambio en el flujo de trabajo, lo que definitivamente puede tomar un tiempo para entenderlo, pero una vez que esté allí, no mirará hacia atrás.

En nuestra empresa mantenemos MUCHOS sitios de Drupal, nuestra configuración actual es más o menos así:

• La base de código de cada sitio tiene su propio repositorio git
• Las nuevas características que probablemente no sean lo suficientemente estables para la próxima versión obtienen su propia rama de características en git

Lo anterior, diría, es bastante común para la mayoría de los sitios de Drupal.

Lo que hacemos especial en nuestra empresa es empaquetar los sitios de Debian para su implementación utilizando un comando drush personalizado: ' Drush Debian Packaging '.

Drush Debian Packaging proporciona un comando Drush para construir paquetes Debian de sitios Drupal como un medio para implementar sitios Drupal en servidores Debian o Ubuntu.

Drush Debian Packaging utiliza el sistema de ganchos Drupal para crear un paquete Debian que mejor se adapte a las necesidades de su sitio. Las características incluyen:

• Configuración automática de host virtual para servidores web Apache2 y Nginx
• Configuración de Cron en /etc/cron.d
• Despliegue de código automatizado con partición dividida para sitios / predeterminados / archivos
• Configuración automatizada a través de la herramienta de configuración dpkg debconf
• Proceso de despliegue automatizado
• controlador GCS VCS personalizado para crear paquetes de Git

¿Qué significa esto?

Para crear una versión:

cd /path/to/drupal-root
drush dh-make

Para implementar una versión, primero SCP el .deb a todos los servidores web en el clúster. Luego, en todos los servidores web ejecutados (puede usar el paquete de Linux cssh para escribir el comando en todos los servidores de la granja al mismo tiempo):

sudo dpkg -i drupal-site-yoursitehere.2011.05.25-1.all.deb

En un servidor web, ejecute:

cd /path/to/drupal-root
sudo -u drupal-site-yoursitehere drush updb && drush fra -y && drush cron

Hecho

Por supuesto, revertir esto ahora es trivial desde el punto de vista de la base de código, simplemente instale la versión anterior de .deb en todos los servidores web y revierta la base de datos.

Estaremos encantados de responder cualquier pregunta sobre esto

¿Qué parte del proceso de implementación es una tarea / poco confiable?

Si se trata del problema "actualizar el servidor A y luego B / inconsistencia", ¿qué pasa con la instalación de la página de mantenimiento durante la duración de sus presiones? Página de mantenimiento arriba, código de actualización en ambos cabezales web, ejecute update.php en uno de ellos, página de mantenimiento abajo. Eso es bastante fácil de escribir.

Otra opción: dependiendo del tipo de sitio que ejecute, podría crear un "modo de solo lectura" que desconecte a todos los usuarios y desactive el inicio de sesión / registro. Clone su base de datos en una segunda base de datos en el mismo cuadro de base de datos, clone su extremo frontal en un nuevo docroot, haga sus actualizaciones allí, luego enlace simbólicamente el docroot de Apache al nuevo docroot frontal. El flujo de trabajo es algo como:

1. Modo de solo lectura en
2. SELECCIONE current_db INTO new_db
3. cp -R current_docroot new_docroot
4. new.yourdomain.com ==> / new_docroot
5. actualizar el código en new_docroot
6. update.php
7. enlace simbólico / new_docroot ==> current_docroot
8. Modo de solo lectura desactivado.

Dependerá de los cambios que esté realizando, como sugiere Entendu. ¿Qué proporción de actualizaciones de código se pueden ejecutar sin causar errores si la base de datos aún no se actualiza? Para cualquier cosa que no dependa de las actualizaciones de la base de datos (y tal vez pueda cambiar un poco el proceso de desarrollo para hacerlo más común), no hay realmente nada especial que hacer. Supongo que desea realizar implementaciones con un tiempo de inactividad mínimo, de lo contrario, esto solo requeriría algunas operaciones básicas de sincronización. En este caso, siempre habrá una ventana de tiempo con efectos no deseados (incluso si solo tiene el sitio en modo de solo lectura), pero creo que podría ser bastante pequeño la mayor parte del tiempo.

Puede hacer una optimización básica, como configurar un "nuevo" directorio en cada servidor con anticipación y luego cambiarlos para apuntar al nuevo directorio al mismo tiempo (tal vez usando enlaces simbólicos como en la respuesta de Entendu) para que pueda obtener todos los los servidores cambiaron a los nuevos archivos en 5-10 segundos.

Eso deja el tema de las actualizaciones de la base de datos. Si son del tipo que se debe hacer desde un solo servidor, es posible que desee poner los otros en modo de mantenimiento o ajustar el equilibrador de carga para que no los use mientras esto sucede. Por supuesto, si no se pueden hacer mientras los usuarios están activos en el sitio, solo necesitará tener todo en modo de mantenimiento, pero para actualizaciones simples, esto podría ser algo que puede hacer en aproximadamente 30 segundos o menos.

Puede valer la pena tener diferentes scripts de implementación para diferentes tipos de cambios, por lo que puede ejecutar el proceso mínimo necesario, ya sea copiando archivos, ejecutando una pequeña actualización de la base de datos o haciendo un cambio importante en la base de datos.

Si puede optimizar sus actualizaciones de archivos y bases de datos y ver si hay cambios simples que puede hacer en la forma en que se desarrollan las cosas, eso podría acercarlo, pero no sé si algo de esto es nuevo para usted :)

Aegir es útil para administrar una red de sitios. Lo usé para implementar y administrar más de 2000 sitios para un solo cliente.

Su pregunta sugiere que desea administrar un solo sitio con múltiples cabezas web. Si ese es el caso, Aegir puede ser menos útil para usted. En cambio, te sugiero que veas el uso de un sistema de archivos que admita redes. Esto no solo garantiza que su código se mantenga sincronizado, sino que sus cargas están disponibles en todos los nodos.

Históricamente, las personas han usado NFS que permite que el sistema de archivos de un servidor se comparta con otros nodos. Desafortunadamente, esto introduce un único punto de falla, porque si el servidor NFS se bloquea o muere, su sitio no puede ser atendido.

Si está dispuesto a comprometer un poco el rendimiento de io en favor de un servidor más confiable, le recomendaría GlusterFS . Lo he usado en algunos entornos de producción. No es perfecto, pero es mejor que NFS. Gluster permite que el webhead lea siempre localmente y las escrituras se replican a los otros nodos.

En términos de su estrategia de implementación, debe tener drush como la primera herramienta en su lista. Con drush deberías poder automatizar los pasos de tu implementación. Debería considerar agregar Jenkins a la mezcla para poder realizar un seguimiento de sus trabajos de implementación e identificar patrones si las cosas fallan. Capistrano puede ser útil para automatizar los pasos involucrados en la implementación. Si hace las cosas correctamente, puede hacerlo para que sus usuarios ni siquiera sepan que hizo una implementación.