Hola drupaler@s en Chile... es tiempo de junta drupalera. El próximo martes 13 de Junio, tendremos nuestra reunión mensual donde hablaremos de Drupal y la web en general.
En esta ocasión nos reuniremos en Canal 13, que está ubicado en Inés Matte Urrejola 0848 (los esperamos en recepción, preguntar por reunión Drupal). Para asegurar su acceso, les solicitamos confirmar su asistencia al evento antes de las 17hrs de ese día.
Si te interesa Drupal o los temas web en general, si estás empezando y quieres saber más o si eres un experto, eres bienvenido, queremos tener tu visión. No sólo es una buena oportunidad para aprender algo nuevo técnicamente sino para conocer otras personas que están trabajando con Drupal e interesantes temas web en Chile.
Para ese día tenemos programado hablar de infraestructura para ambientes productivos y trabajo.
Dockerizando Drupal y como llevarlo a instancias de Amazon Web Services (AWS)
Revisaremos los conceptos básicos sobre Docker y los aplicaremos en la contenerización de Drupal 7. Además veremos como llevar nuestro contenedor a una instancia de Amazon creando y montando en minutos nuestra infraestructura cloud con Terraform.
Es importante registrarse en el evento para que los anfitriones tengan en cuenta la cantidad de asistentes y así planificar mejor. (Por razones de espacio, el registro será requisito para la asistencia).
Cuando: Martes 13 de Junio, 19:00 hrs.
Donde: Canal 13. Inés Matte Urrejola 0848, Providencia, Santiago.
Mapa
Comments
Escalamiento horizontal de Drupal
Hola... dejaré el comentario por el caso que se planteo en la discusión post-charla.
El caso es resolver alguna arquitectura de plataforma para soportar el escalamiento horizontal de Drupal (sea con maquinas fisicas, virtuales o contenedores, ...). Cabe destacar también que esta instalación de drupal era multisitio, es decir, tenia distintas bases de datos conectadas, según el dominio por el que se accede. También aprovecho de comentar (para el caso) que estos sitios usaban como "core", a Drupal 6.
En algún momento me tocó presenciar el intento de migración de un sitio a Drupal (con alta concurrencia 24/7) de visitas a Amazon, donde se pretendió armar una plataforma que pretendió escalar el procesamiento de PHP.
En esta plataforma, se usaron directamente instancias EC2 con una AMI, donde:
* 1 instancia se destino a Base de datos (MySQL instalado a mano, debido a que se usó como destino de replicación mientras se preparaba la migración del sitio, listo para hacer un switch para ser la BD principal)
* 1 instancia para storage común (vía NFS), también una máquina AMI con instalación custom.
* 2 instancias para servidor web, sirviendo clones idénticos del mismo Drupal.
* 1 balanceador frontal (el de Amazon)
Podría decir que básicamente funcionó hasta que encontramos algunos problemas y nunca vi como se resolvieron:
Los request que llegaban a las instancias podían ser aleatorios, es decir, el visitante que llegó, le podria pegar a cualquier instancia de drupal mientras navega, no necesariamente se queda en la primera que llegó. Este comportamiento es lo que se esperaría de un balanceador y entiendo que esta bien que sea así.
La sesión no era crítica para los visitantes de este sitio pero si para los editores. Si se logeaban en una de las instancias, a veces perdían la sesión cuando el LB (load balancer) lo mandaba a la otra instancia.
Sobre la sesión, también hubo que haer algunas configuraciones extra en el setting.php de los Drupal y en los webservers para que el proxy reverso propagara el dominio hacia adentro (el sitio se podia acceder por varios dominios) y para que la cookie fuera válida también. Creo que esto si se resolvió, no recuerdo como, pero lo que habría hecho yo, habría sido levantar una tercera instancia, para "lectura-escritura", exclusiva para los editores, con algún subdominio alternativo) y nunca pasar por el LB, sino que directo a esa instancia exclusiva.
El problema grave fue compartir los archivos del sites/default/files. Drupal no solo guarda los archivos de las imágenes, sino que también hace caching de otras cosas según las paginas que se visitan, lo cual hace que sea muy dependiente de escribir y leer. La solución que se planteó fue montar el directorio sites/default/files en ambas instancias, mediante NFS. El problema es que resultó contraproducente, el la frecuencia de las operaciones I/O fue demasiado grande y muchas veces "se bloqueaba", haciendo que PHP se quedara pegado rendereando algunas paginas aleatoriamente, haciendo que la navegación fuera sumamente lenta. Aparte, en ocasiones, si el request respondía bien, a veces las imágenes recién subidas en una instancia, no se veían si el request siguiente llegaba a la otra instancia. Me pareció interesante "probar" la idea de levantar una arquitectura similar usando volumenes docker vía red, o quizás "reemplazando" alguna parte del storage de Drupal para no usar el filesystem directamente y en cambio usar una CDN. Según la conversación, se que un equipo logró montar un directorio de storage vía NFS "sin problemas", lo cual me hace pensar que quizás nuestra instalación pudo no haber sido bien "tuneada", o pasamos por alto alguna otra cosa.
Dejo el problema planteado, dado que a todos nos importa estar preparados para eventualmente enfrentar un proceso de escalamiento si es que nuestros sitios crecen. También dejo planteada la inquietud para quienes conozcan más a Drupal 8, si eventualmente para un escenario como este, cuenta o no con más facilidades para enfrentar este proceso, respecto de Drupal 7 y 6.
También aprovecho de dejar planteada la idea de eventualmente mostrar algunas cosas que estaba haciendo para darle un uso alternativo a Drupal, en torno al tema de microservicios, que consiste en plantear a Drupal solo como "productor" o "procesador" de datos y nada más.
(*)Unix es mi copiloto
Buen resumen
muy buen resumen, muchas gracias Gonzalo.
buen planteamiento
Hola Gonzalo. Primero que todo muchas gracias por tu consulta. Intentaré desarrollar la respuesta entre esta y la próxima semana. Disculpa el retraso
Lo que planteas es bastante interesante. De nuestro lado (INTA), hemos estado avanzando en el concepto de escalamiento y versionamiento. De alguna manera, queremos plantear una aproximación y compartirla con la comunidad, pero te puedo adelantar que no hay "receta mágica". Muchas de las estrategias de optimización, depende de la cultura del lugar de trabajo
Un saludo
Seba