Cómo gestionar de forma eficiente varias instalaciones de una aplicación web?

StackOverflow https://stackoverflow.com/questions/502774

Pregunta

Desde mi experiencia, uno de los más grandes problemas que encontramos durante nuestro proceso de desarrollo web es mantener diferentes configuraciones actualizada y segura a través de diferentes servidores.

Mi empresa tiene su propio CMS, que está instalado actualmente a través de más de 100 servidores.Por el momento, vamos a usar un hack-ish FTP basado en el enfoque, combinado con secuencias de comandos de actualización en lugares específicos para la actualización de todos los de nuestro CMS configuraciones.La gestión eficiente de estas configuraciones se vuelve cada vez más difícil y arriesgado cuando hay varios módulos personalizados involucrados.

  • ¿Cuál es la mejor manera de mantener múltiples configuraciones de una aplicación web segura y actualizada?
  • ¿Cómo usted hacerlo?
  • Hay consejos específicos con respecto a la modularidad en las aplicaciones, con el fin de mantener la flexibilidad hacia nuestros clientes, siendo capaz de gestionar de forma eficiente varias "ramas" de una aplicación?

Alguna información contextual:nos desarrollan principalmente en la LÁMPARA de la pila.Uno de los principales factores que nos ayuda a vender nuestro CMS es que podemos plugin bastante mucho nada de lo que nuestro cliente quiere.Esto puede variar de 10 a 10.000 líneas de código personalizado.

Un montón de trabajo a la medida consiste en pequeños trozos de código;la gestión de todos estos pequeños trozos de código en la Subversión parece bastante tedioso e ineficiente para mí (ya que entregamos alrededor de 2 sitios web cada semana, esto resultaría en un mucho de las ramas).

Si hay algo que me domina, me encantaría oír de usted.

Gracias de antemano.

Resumen: primero de todo, gracias por todas sus respuestas.Todos estos son realmente útiles.

Yo más probable es que el uso de un SVN-base, lo que hace que benlumley's la solución más cercana a lo que voy a utilizar.Dado que la respuesta a esta pregunta puede variar en otros escenarios de uso, voy a aceptar la respuesta con más votos al final de la carrera.

Por favor revise las respuestas y votar por los que usted piensa que tiene el mayor valor añadido.

¿Fue útil?

Solución

Creo que usando un sistema de control de versiones y " ramificando " la parte de los códigos que debe modificar podría ser el mejor enfoque en términos de solidez y eficiencia.

Un sistema de versión distribuida podría adaptarse mejor a sus necesidades, ya que le permitiría actualizar su " core " características perfectamente en diferentes " ramas " manteniendo algunos cambios locales si es necesario.

Editar: estoy bastante seguro de que mantener todo eso actualizado con un sistema de versión distribuida sería mucho menos tedioso de lo que parece esperar: puede mantener los cambios de los que está seguro Nunca necesitará ningún otro lugar local, y el aspecto distribuido significa que cada una de las aplicaciones implementadas es realmente independiente de las demás y solo se propagará la solución que quiere propagar.

Otros consejos

Si personalizar su aplicación implica cambiar muchos pequeños trozos de código, esto puede ser una señal de que el diseño de su aplicación es defectuoso. Su aplicación debe tener un conjunto de código central estable, puntos de extensibilidad para que las bibliotecas personalizadas se conecten, la capacidad de cambiar la apariencia usando plantillas y la capacidad de cambiar el comportamiento e instalar complementos usando archivos de configuración. De esta manera, no necesita una rama SVN separada para cada cliente. Por el contrario, mantenga el código central y las bibliotecas de complementos de extensión en el control de origen de forma normal. En otro repositorio, cree una carpeta para cada cliente y mantenga todas sus plantillas y archivos de configuración allí.

Por ahora, crear ramas SVN puede ser la única solución que lo ayude a mantener la cordura. En su estado actual, es casi inevitable que cometa un error y arruine el sitio de un cliente. Al menos con sucursales, se garantiza que tendrá una base de código estable para cada cliente. El único problema con las ramas SVN es que si mueve o cambia el nombre de un archivo en una rama, es imposible fusionar ese cambio nuevamente en el tronco (tendría que hacerlo manualmente).

¡Buena suerte!

EDITAR: para ver un ejemplo de una aplicación bien diseñada que utiliza todos los principios que describí anteriormente, consulte Magento E-Commerce . Magento es la aplicación web más potente, extensible y fácil de personalizar con la que he trabajado hasta ahora.

Puedo estar equivocado, pero me parece que lo que persigue Aron es el control de versión not . El control de versiones es excelente, y estoy seguro de que ya lo están utilizando, pero para administrar actualizaciones en cientos de instalaciones personalizadas, necesita algo más.

Estoy pensando en algo similar a un sistema de paquetes especialmente diseñado . Querrá que cada versión de un módulo realice un seguimiento de sus dependencias individuales y 'compatibilidades garantizadas', y use esta información para actualizar automáticamente solo los módulos 'seguros'.

Por ejemplo. Digamos que ha creado una nueva versión 3 de su módulo 'Wiki'. Desea propagar la nueva versión a todos los servidores que ejecutan su aplicación, pero ha realizado cambios en una de las interfaces dentro del módulo Wiki desde la versión 2. Ahora, para todas las instalaciones predeterminadas, eso no es un problema, pero se rompería instalaciones con extensiones personalizadas en la parte superior de la interfaz anterior. Un sistema de paquetes bien planificado se encargaría de esto.

Para abordar la cuestión de seguridad, debe considerar el uso de firmas digitales en sus parches. Hay muchas buenas bibliotecas disponibles para firmas basadas en claves públicas, así que simplemente elija lo que parezca ser el estándar para la plataforma elegida.

No estoy seguro de si alguien ha dicho esto, hay muchas respuestas largas aquí, y no las he leído todas.

Creo que un mejor enfoque para el control de su versión sería tener su CMS sentado solo en su propio repositorio y cada proyecto en sí mismo. (o, todos estos podrían ser subcarpetas dentro de un repositorio, supongo)

Luego puede usar su troncal (o una rama / etiqueta específica si lo prefiere) como un svn: externo en cada proyecto que lo requiera. De esta manera, cualquier actualización que realice en el CMS puede confirmarse en su repositorio, y se incorporará a otros proyectos a medida que se actualicen svn (o el externo sea svn: switch 'ed).

Como parte de hacer esto más fácil, necesitará asegurarse de que el CMS y la funcionalidad personalizada se encuentren en diferentes carpetas, para que svn externals funcione correctamente.

IE: 

project
 project/cms <-- cms here, via svn external
 project/lib <-- custom bits here
 project/www <-- folder to point apache/iis at

(puede tener cms y lib bajo la carpeta www si es necesario)

Esto le permitirá ramificar / etiquetar cada proyecto como desee. También puede cambiar la ubicación externa svn: por rama / etiqueta.

En términos de obtener cambios en vivo, te sugiero que te deshagas inmediatamente de ftp y uses rsync o svn checkout / exports. Ambos funcionan bien, la elección depende de usted.

Tengo más experiencia con la ruta rsync, rsyncing una exportación svn al servidor. Si sigue esta ruta, escriba algunos scripts de shell, y puede crear un script de shell de prueba para mostrarle los archivos que cargará sin cargarlos también, utilizando el indicador -n. Generalmente uso un par de scripts para cada entorno, uno para una prueba y otro para hacerlo realmente.

La autenticación de clave compartida para que no necesite una contraseña para enviar cargas también puede ser útil, dependiendo de qué tan seguro sea el servidor al que se le dará acceso.

También podría mantener otro script de shell para realizar actualizaciones masivas, que simplemente llama al script de shell relevante para cada proyecto que desea actualizar.

¿Has mirado a Drupal? No, no para implementar y reemplazar lo que tiene, sino para ver cómo manejan las personalizaciones y los módulos específicos del sitio.

Básicamente, hay un " sitios " carpeta que tiene un directorio para cada sitio que aloja. Dentro de cada carpeta hay un settings.php separado que le permite especificar una base de datos diferente. Finalmente, puede (opcionalmente) tener & Quot; themes & Quot; y " módulos " carpetas dentro de los sitios.

Esto le permite realizar personalizaciones específicas del sitio de módulos particulares y limitar ciertos módulos a esos sitios. Como resultado, terminas con un sitio donde la gran mayoría de todo es perfectamente idéntico y solo las diferencias se duplican. Combine eso con la forma en que maneja las actualizaciones y actualizaciones y podría tener un modelo viable.

Construya en el código un proceso de actualización automática.
Buscará actualizaciones y las ejecutará cuando / dónde / cómo lo haya configurado para el cliente.

Tendrá que crear algún tipo de lista de módulos (personalizados o no) que deben probarse con la nueva compilación antes del lanzamiento. Al implementar una actualización, deberá asegurarse de que se prueben e integren correctamente. Esperemos que su diseño pueda manejar esto.

Las actualizaciones son idealmente unos pocos pasos clave.

  1. a) Copia de seguridad para que pueda retroceder. Debería poder retroceder La actualización completa en cualquier momento. Asi que, eso significa crear un archivo local de la aplicación y la base de datos primero.

    b) Actualizar proceso de monitoreo : haga que el sistema CMS llame a su casa para buscar una nueva compilación.

    c) Programar actualización de disponibilidad : es probable que no desee que la actualización se ejecute en el momento en que esté disponible. Esto significa que tendrá que crear un cron / agente de algún tipo para que el sistema se actualice automáticamente en medio de la noche. También puede considerar los requisitos del cliente para actualizar los fines de semana o en días específicos. También puede escalonar el despliegue de sus actualizaciones para no actualizar 1000 clientes en 1 día y obtener soporte técnico. El despliegue escalonado de algún tipo podría ser beneficioso para usted.

    d) Agregar modo de mantenimiento para actualizar el sitio : ponga el sitio en modo de mantenimiento.

    e) SVN checkout o paquetes descargables : idealmente puede implementar a través de svn checkout, y si no, configure su servidor para entregar paquetes generados por svn en un archivo que se puede implementar en los sitios de los clientes.

    f) Implementar scripts de base de datos : haga una copia de seguridad de las bases de datos, actualícelas, complételas

    g) Actualizar código de sitio : todo esto funciona en un solo paso.

    h) Ejecute algunas pruebas en él. Si su código tiene autocomprobaciones integradas, sería ideal.

Aquí es lo que tengo que hacer...

Cliente-específicos incluyen la ruta de acceso

  • Común, compartido código es en shared/current_version/lib/
  • Código de sitio específico es en clientes/foo.com/lib
  • El incluir la ruta de acceso está configurado para incluir a partir de la clientes/foo.com/lib, y , a continuación, share/lib
  • Toda la cosa es que en un sistema de control de versiones

Esto asegura que el código utiliza archivos compartidos siempre que sea posible, pero si tengo que anular una clase en particular o archivo por alguna razón, me puede escribir un cliente específico de la versión en su carpeta.

Alias archivos comunes

Mi configuración del host virtual contendrá una línea como

Alias /common <path>/shared/current_version/public_html/common

Que permite común de elementos de interfaz de usuario, iconos, etc para ser compartidos a través de proyectos

Etiqueta el código común con cada sitio de liberación

Después de cada sitio de liberación, me la etiqueta de código común, mediante la creación de una rama a congelar efectivamente ese punto en el tiempo.Esto me permite desplegar /shared/version_xyz/ a el servidor en vivo.Entonces puedo tener un host virtual el uso de una particular versión de los archivos comunes, o salir de ella apuntando a la current_version, si yo quiero recoger las actualizaciones más recientes.

¿Ha visto herramientas como Puppet (para la administración del sistema, incluida la implementación de la aplicación) o < a href = "http://www.capify.org/" rel = "nofollow noreferrer"> Capistrano (despliegue de aplicaciones en RubyOnRails pero no limitado a estas)

Una opción sería configurar un sistema de control de versiones de solo lectura (Subversion). Puede integrar el acceso al repositorio en su CMS e invocar las actualizaciones a través de un menú, o automáticamente si no desea que el usuario pueda elegir una actualización (podría ser crítico). El uso de un sistema de control de versiones también le permitiría mantener diferentes ramas fácilmente

Como la gente ya ha mencionado que usar el control de versiones (prefiero Subversion debido a la funcionalidad) y la ramificación sería la mejor opción. Otro software de código abierto disponible en sourceforge llamado cruisecontrol. Es sorprendente, usted configura el control de crucero con subversión de una manera tal que cualquier modificación de código o código nuevo agregado en servidor, el control de crucero lo sabrá automáticamente y lo construirá por usted. Le ahorrará su infierno de tiempo.

He hecho lo mismo en mi empresa. Tenemos cuatro proyectos y tenemos que implementar ese proyecto en diferentes servidores. He configurado cruiseconrol de tal manera que cualquier modificación en la base del código desencadena la compilación automática. y otro script implementará esa compilación en el servidor. estás listo para ir.

Si usa una pila LAMP, definitivamente convertiría los archivos de soluciones en un paquete de su distribución y lo usaría para propagar cambios. Para el caso, recomiendo Redhat / Fedora debido a RPM y es en lo que tengo experiencia. De todos modos, también puede usar cualquier distribución basada en Debian.

Hace algún tiempo hice una solución LAMP para administrar un servidor de alojamiento de ISP. Tenían varios servidores para encargarse del alojamiento web y necesitaba una forma de implementar los cambios de mi administrador, porque cada máquina era autónoma y tenía un administrador en línea. Hice un paquete RPM que contenía los archivos de la solución (principalmente php) y algunos scripts de implementación que se ejecutaban con el RPM.

Para la actualización automática, teníamos nuestro propio repositorio RPM configurado en cada servidor en yum.conf. Configuré un trabajo crontab para actualizar los servidores diariamente con los últimos RPM de ese repositorio de confianza.

La confianza también se puede lograr porque puede usar la configuración de confianza en los paquetes RPM, como firmarlos con su archivo de clave pública y aceptar solo paquetes firmados.

Hm, ¿podría ser una idea agregar archivos de configuración? Escribiste que muchos guiones pequeños están haciendo algo. Ahora, si los integrara en las fuentes y los dirigiera con archivos de configuración, ¿no debería eso & "; Facilitar &"; ¿ese?

Por otro lado, tener sucursales para cada cliente me parece un crecimiento exponencial. ¿Y cómo & "; Saber &"; en qué áreas has hecho algo y no te olvides de " make " cambios en todas las demás ramas también. Eso me parece bastante feo.

Parece que una combinación de controles de revisión, opciones de configuración y / o recibos de implementación parece ser un & "; bueno &"; idea .....

Con tantas variaciones en su software principal, creo que realmente necesita un sistema de control de versiones para estar al tanto de las actualizaciones de la troncal a los sitios de clientes individuales.

Entonces, si crees que Subversion sería tedioso, tienes una buena idea de cuáles serán los puntos débiles ... Personalmente, no recomendaría Subversion para esto, ya que no es tan bueno para administrar amp; Rastreo de ramas. Aunque la sugerencia de benlumley de usar elementos externos para su software central es buena, esto se rompe si necesita ajustar el código central para los sitios de sus clientes.

Busque en Git el control de versiones, está diseñado para bifurcación y es rápido.

Visite Capistrano para administrar sus implementaciones. Es un script de ruby, que a menudo se usa con Rails, pero se puede usar para todo tipo de administración de archivos en servidores remotos, incluso sitios que no son de ruby. Puede llevar el contenido al extremo remoto a través de varias estrategias que incluyen ftp, scp, rsync, así como verificar automáticamente la última versión de su repositorio. Las características agradables que ofrece incluyen ganchos de devolución de llamada para cada paso del proceso de implementación (por ejemplo, para que pueda copiar los archivos de configuración específicos del sitio que podrían no estar en el control de versiones) y un sistema de registro de lanzamiento, hecho a través de enlaces simbólicos, para puede retroceder rápidamente a una versión anterior en caso de problemas.

Recomendaría un archivo de configuración con la lista de sucursales y su ubicación alojada, luego lo ejecutaré con un script que comprueba cada sucursal y carga los últimos cambios. Esto podría ser cronificado para hacer actualizaciones nocturnas automáticamente.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top