Tengo la fortuna y la desgracia de tener que escalar mi sitio Drupal inmediatamente. Está consiguiendo más tráfico de lo que ahora puedo acomodar - y por lo que los próximos pasos de escalado tienen que ser tomados.

Creo que el sitio estaba funcionando bien en Drupal 9. Pero mejoré a Drupal 10 y se volvió muy, muy lento. Ahora, no voy a volver a Drupal 9, pero es otro punto de conversación y otra razón para no actualizar. Como escribí anteriormente, nos gusta mantener nuestra pila inclinada, así que cuando actualizar a una próxima versión principal (1) no aporta ningún beneficio notable, y (2) aumenta el consumo de recursos - realmente preguntamos si vale la pena. Lo cual no lo es. Muchas veces no vale la pena mejorar.

Sigamos, paseemos por los pasos que estoy tomando para abordar los problemas de rendimiento y mejorar el rendimiento general del sitio.

Un primer paso que estoy dando es reconstruir el sitio web con ansible. Eso significa escribir y configurar libros y roles ansibles para instalar el sitio web en un sistema operativo desnudo. Estoy usando docker para esto internamente. Dirías que es una gran tarea, y es una gran tarea. Sin embargo, me siento mucho más cómodo con la infraestructura como código que si no tengo esta capacidad. ¡Así que vamos!

También intentaré abrir la mayoría de mi código mientras avanzamos. El código disponible está disponible aquí: https://github.com/wasya-co/wasya co ansible.git Si no encuentras alguno de los códigos que menciono, o crees que no ha sido de código abierto y te gustaría una copia - contacta conmigo directamente. Nota: `la rama del maestro nunca es más reciente. La mejor rama a utilizar es la rama alfabéticamente más reciente.

Nota: Estoy usando mis propias imágenes de taquilla, como piousbox/php83:0.0.2 Puede conectar su propia imagen, o púlsame si la mía no funciona en nuestro caso o necesita algo específico, como otro módulo de apache.

Trabajaré en mi sitio más popular, https://piousbox.com Ahora después de unos días, obtuve el libro de juegos que instala el sitio web trabajando: playbooks/setup all drupal site.yml y necesitas todos los valores de configuración para estar en vars/según el nombre del sitio web.yml o algo similar. Puedes ejecutarlo con:

   ansible-playbook -i inventory/aws.yml -e @vars/piousbox_com.yml \ 
     --limit aws4 playbooks/setup_all_drupal_site.yml    -vv

Después de escribirlo, descubrí que quiero reescribirlo para que pueda solucionar la instalación localmente sin posibilidad. Es decir, aunque quiero conducir todo esto con ansible, quiero estar seguro de que funciona de antemano. La forma de hacerlo es empaquetar la aplicación como un proyecto docker-compose. Así que me dividí https://github.com/wasya-co/docker drupal.git fuera del reposo ansible.

Por supuesto, entonces podría tener dos sistemas de tentación, a los valores de configuración de plugin. Esto ya es posible y pensé que la cabeza no es demasiado grande. En el proyecto docker drupal.git tengo scripts/update all , sripts/update dc (para docker-compose.yml) y scripts/update settings - estos scripts toman una plantilla y sustituyen los valores .env en la plantilla.

Luego reescribió el papel ansible para, en lugar de colocar cada archivo necesario en el servidor, colocar el docker drupal.git repo allí, y plantilla-sustituir algunos archivos. Esto me permite conducir la automatización con y sin ansible.

El proyecto incluye una base de datos mysql. Creo que es la base de datos que es el cuello de botella de rendimiento, pero también quiero estar seguro, y quiero tener la herramienta para resolver estos problemas precisamente en el futuro.

Luego, para simplificar las cosas, empaqué todos mis temas y módulos drupales como módulos reales para el compositor. Anteriormente, me registré todo lo que necesitaba de mis bases de código, sin embargo, con la automatización creciente el método más fácil se ha convertido en incluir todo en el archivo composer.json, que he hecho. el docker drupal.git/compose.json tiene los detalles y es un ejemplo de hacer eso. (Uso etiquetas de versión semántica, sobresalto en mi formalismo 1.0.0 es siempre una rama, mientras que v1.0.0 es una etiqueta de liberación. El v en el principio deja claro que no es, de hecho, una versión, ya que el v no es parte del formalismo semver.)

De hecho, reescribió mi ansible espacio de trabajo repo - o más bien, decidí que las únicas cosas que pueden compartir serán los papeles. Así que cada papel ansible es fuente abierta en su propio repo. Ejemplo: wasya-co/wasya co ansible role.git Y los playboors y variables y las instrucciones para ejecutar, están en otro lugar, probablemente en la documentación. De esta manera, no tengo que abrir mi espacio de trabajo inestable, y todavía tengo el beneficio de la contratación abierta todo el levantamiento pesado, que está dentro de los papeles ansibles.