Pila de lámpara ideal para varios desarrolladores?

Question

Me gustaría construir una pila de desarrollo de lámpara "ideal".

• servidor dual (virtualizado, ESX)
  • Apache/PHP en uno, bases de datos (MySQL, PgSQL, etc) en el otro.
• Usuario (desarrollador) Manejables mini entornos, o instancia.
  • Cada instancia desarrollador comparte el nivel de configuración de la parte superior (módulos disponibles y por defecto de configuración etc)
  • Un desarrollador debe tener control sobre su versión de Apache y PHP para cada proyecto.
  • Un desarrollador puede cambiar las configuraciones menores, es decir, las comillas mágicas para el código heredado.
  • Cada proyecto determinaría su proveedor de base de datos en su código

La idea es que se trata de un servidor Administrar factible que puedo controlar, y proporcionar las cosas configuradas a nivel mundial como APC, Memcached, XDebug etc. Luego, al pasar a subconjuntos para cada proyecto, puedo permitir a mis usuarios controlar rápidamente sus entornos para varios proyectos.

Básicamente estoy proponiendo el sistema típico de un desarrollador que ejecuta su propia pila en su propia máquina, pero centralizada. De esta forma, espero evitar problemas como problemas de código de Cross OS, incoherencias de bases de datos, instalaciones ligeramente diferentes que producen errores, etc.

Me complace administrar esto en compilaciones personalizadas desde el origen, pero si es posible, lo haría Sería bueno tener una gran parte de él gestionado con algún tipo de gestión de paquetes. Usualmente usamos CentOS, ¿yam?

¿Alguien ha construido algo así antes? ¿Hay algo llave en mano que sea similar a lo que he descrito? ¿Hay alguna guía útil que debería leer para construir algo como esto?

Answer 1

Mi opinión sobre el tema, no creo que cubre todas sus necesidades, pero es bastante estrecha:

• tiene un servidor CentOS con la pila LAMP (yum install apache2 mysql php, etc.) - o 2 servidores, uno httpd y uno mysqld
• Para n desarrolladores tienen n carpetas con n hosts virtuales www.developer-n.com en el host que ejecuta el servidor Apache
• Cada desarrollador monta su carpeta del servidor (digamos //192.168 .0.1/home/developer-n/www) en la máquina local a través de CIFS en/etc/fstab de la estación local y edita los archivos de local sin embargo, ellos máquina se ejecuta en el servidor (única)
• Cada mini-entorno de desarrollo es ajustado a través de .htaccess

Answer 2

bien, la forma en que estábamos corriendo configuración LAMP se desarrollo en mi trabajo anterior, era así. Un solo servidor ejecutando MySQL y Apache.A cada desarrollador se le asigna una dirección IP en el servidor (la máquina ejecuta múltiples direcciones IP en la misma interfaz, todas las direcciones IP están en la misma subred), de modo que cada desarrollador puede tener al menos un host virtual basado en IP y tantos nombres como ellos quieren (nuestro sitio web usó SSL, por lo que necesitábamos direcciones IP separadas, wigthout SSL, puedes salirte con un solo IP y vhosts basados ​​en el nombre). Hicimos que el servidor DNS local sirviera registros comodín A para cada desarrollador de esta manera * .john.dev.company EN A 10.1.1.123, donde 10.1.1.123 era una dirección IP asignada a John. De esta forma, John podría definir tantos fantasmas basados ​​en el nombre como quisiera y todos se resolverían correctamente siempre que finalizaran en john.dev.company (como project1.john.dev.company). Cada desarrollador tenía su propio archivo de configuración de Apache con sus hosts virtuales y utilizamos la directiva Incluir para extraer todos estos archivos en la configuración principal de Apache. Se establecieron los permisos, por lo que estos archivos de configuración serían editables por los desarrolladores respectivos y cada desarrollador tenía un enlace suave a su configuración en su directorio de inicio. Además, a cada desarrollador se le permitió usar sudo para reiniciar Apache. La desventaja de esta configuración era que de vez en cuando un desarrollador en particular bloqueaba todo el servidor atornillando su archivo de configuración. Usamos una base de datos común, ya que todos estaban trabajando en un solo proyecto, pero no debería ser difícil configurar múltiples bases de datos individuales.