Puppet: administrando (muchos) Apache VirtualHosts


9

Estoy aprendiendo mi camino a través de la gestión de la configuración en general y usando Puppet para implementarlo en particular. Ya he hecho una investigación genérica ( también en SF ) y ahora estoy considerando Apache VirtualHosts.

Hospedamos muchos sitios web de LAMP (actualmente está en el rango de cientos) en dos sistemas: uno Apache2 / mod_php y uno MySQL , básicamente lo opuesto a otra pregunta que ya está en SF, donde administra muchos servidores con pocos vhosts cada uno (si en realidad no uno, no lo sé). Todavía no he reunido una configuración de trabajo en Puppet, pero no debería ser un problema, hay muchos ejemplos y recetas por ahí.

Además de los archivos de configuración de Apache obvios (no hay problema aquí, supongo), cada vhost necesitaría crear algunos directorios y verificar los permisos (por ejemplo, un directorio raíz para cada vhost que contenga una raíz documental, un directorio tmp dedicado, un directorio dedicado directorio de archivos de sesión php, posiblemente certificados SSL, etc.) en el servidor web y un usuario + una o más bases de datos en el servidor MySQL.

Agregar un nuevo vhost requeriría una marioneta para crearlos, eliminar uno requeriría que marioneta ejecutara un script que respaldaría los datos del usuario y luego eliminaría los datos en vivo de los dos servidores, pero también todos y cada uno de los agentes de marionetas ejecutados verificarían la existencia de los directorios, el db, los permisos, etc.

¿Estoy pidiendo problemas al subir a cientos de servidores virtuales con todas esas comprobaciones ejecutándose en cada ejecución de marionetas, especialmente las del sistema de archivos (en el servidor web), y especialmente cuando en el futuro los sistemas se cargarán más? (supongamos que apuntamos al rango de 1000 ~ 2000 sitios web como un máximo razonable por servidor).

¿Hay alguna experiencia en hacer eso en la red? Busqué en Google pero no encontré nada, también porque hay una baja relación señal / ruido al buscar "títere" y "apache" ...

Respuestas:


4

Sospecho que administrar muchos hosts virtuales apache no será un problema, pero no puedo decirlo con certeza. El rendimiento aceptable está definido por las necesidades de su negocio. Solo tú puedes decidir si es lo suficientemente rápido. Aquí hay un hilo decente sobre la reducción de la carga de la CPU: https://groups.google.com/forum/?fromgroups#!topic/puppet-users/sxtMvCnKnys[1-25]

Para resumir el hilo:

  • Aumente el retraso entre las ejecuciones del agente de marionetas
  • no programe títeres y solo use títeres o mcollective para disparar carreras
  • programar los cambios de Apache para que solo ocurran en ciertos momentos
  • use dos entornos diferentes (mantenimiento y producción) para administrar las cosas. Mantenga la producción ligera y utilice el mantenimiento para realizar cambios.

Aquí hay un ejemplo de cómo administrar un host virtual apache desde el sitio web de PuppetLabs: http://docs.puppetlabs.com/learning/definedtypes.html#an-example-apache-vhosts

Configurar y eliminar la configuración no debería ser un problema. El mayor problema sería eliminar archivos de datos para las aplicaciones / sitios web. Para eso, recomendaría almacenamiento compartido, como NFS / AFS. Si no está utilizando el almacenamiento compartido, asegúrese de que los datos generados por el usuario se mantengan intactos, respaldados o migrados al nuevo servidor.

Sospecho que se encuentra en una situación de alojamiento masivo, como una empresa de alojamiento web, por lo que recomiendo que los nombres de sitios individuales del sitio no se codifiquen en su manifiesto de títeres. Para esto, recomiendo usar Hiera < http://puppetlabs.com/blog/first-look-installing-and-using-hiera/ . Hiera le permite utilizar una forma separada para almacenar la lista de mapeo de host virtual a servidores reales. Puede usar archivos planos o una base de datos con Hiera. Lamentablemente, no conozco a Hiera lo suficiente como para guiarte sobre cómo configurar la estructura de datos de niveles múltiples de Hiera que puedas necesitar, pero al menos puedo señalarte en la dirección general de Hiera.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.