php - ejecutar - ejemplos de proyectos en laravel
¿Cómo administrar eficientemente múltiples instalaciones de una aplicación web? (13)
¿Ha analizado herramientas como Puppet (para administración de sistemas, incluida la implementación de aplicaciones) o Capistrano (implementación de aplicaciones en RubyOnRails, pero no se limita a estas)?
Desde mi experiencia, uno de los problemas más grandes que enfrentamos durante nuestro proceso de desarrollo web es mantener diferentes configuraciones actualizadas y seguras en diferentes servidores.
Mi compañía tiene su propio CMS que actualmente está instalado en más de 100 servidores. Por el momento, utilizamos un enfoque basado en FTP de hack-ish, combinado con scripts de actualización en ubicaciones específicas para actualizar todas nuestras configuraciones de CMS. La gestión eficiente de estas configuraciones se vuelve cada vez más difícil y arriesgada cuando hay varios módulos personalizados involucrados.
- ¿Cuál es la mejor manera de mantener múltiples configuraciones de una aplicación web seguras y actualizadas?
- ¿Cómo lo haces?
- ¿Hay algún consejo específico sobre la modularidad en las aplicaciones, para mantener la flexibilidad con nuestros clientes, pero aún así poder administrar de manera eficiente múltiples "ramas" de una aplicación?
Alguna información contextual: desarrollamos principalmente en la pila LAMP. Uno de los principales factores que nos ayuda a vender nuestro CMS es que podemos agregar prácticamente todo lo que nuestro cliente desee. Esto puede variar de 10 a 10.000 líneas de código personalizado.
Un montón de trabajo personalizado consiste en fragmentos de código muy pequeños; administrar todas estas pequeñas piezas de código en Subversion me parece bastante tedioso e ineficiente (ya que entregamos alrededor de 2 sitios web cada semana, esto daría lugar a una gran cantidad de sucursales).
Si hay algo que estoy pasando por alto, me encantaría saberlo de usted.
Gracias por adelantado.
Resumen: antes que nada, gracias por todas sus respuestas. Todos estos son realmente útiles.
Lo más probable es que use un enfoque basado en SVN, que hace que la solución de Benlumley sea la más cercana a la que usaré . Dado que la respuesta a esta pregunta puede diferir en otros usos, aceptaré la respuesta con la mayoría de los votos al final de la ejecución.
Por favor, examine las respuestas y vote por las que cree que tienen el mayor valor agregado.
¿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 una carpeta de "sitios" que tiene un directorio para cada sitio que está alojando. Dentro de cada carpeta hay un settings.php separado que le permite especificar una base de datos diferente. Finalmente, puede (opcionalmente) tener carpetas de "temas" y "módulos" dentro de los sitios.
Esto le permite hacer personalizaciones específicas del sitio de módulos particulares y limitar ciertos módulos a esos sitios. Como resultado, terminas con un sitio que 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 es posible que tenga un modelo viable.
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 de forma automática si no desea que el usuario tenga una opción sobre una actualización (podría ser crítico). Usar un sistema de control de versiones también te permitirá mantener diferentes ramas fácilmente
Creo que usar un sistema de control de versiones y "ramificar" la parte de los códigos que debe modificar podría ser el mejor enfoque en términos de robustez y eficiencia.
Un sistema de versión distribuida podría adaptarse mejor a sus necesidades, ya que le permitiría actualizar sus funciones "centrales" sin problemas en diferentes "ramas" mientras mantiene algunos cambios locales si es necesario.
Editar: estoy bastante seguro de que mantener todo al día con un sistema de versión distribuida sería mucho menos tedioso de lo que parece esperar: puede mantener los cambios que está seguro de que nunca va a necesitar en otro lugar, y el aspecto distribuido significa que cada una de las aplicaciones desplegadas es realmente independiente de las demás y solo se propagará la solución que pretendes propagar.
Como las personas ya han mencionado que usar la versión de control (prefiero Subversion debido a la funcionalidad) y la bifurcación sería la mejor opción. Otro software de código abierto disponible en sourceforge llamado cruisecontrol. Es sorprendente que configure el control de crucero con subversión de manera que cualquier modificación de código o código nuevo agregado en la servidor, el control de crucero lo sabrá automáticamente y lo hará para usted. Salvará tu infierno de tiempo.
He hecho lo mismo en mi compañía. tenemos cuatro proyectos y tenemos que implementar ese proyecto en diferentes servidores. Configuré cruiseconrol de tal manera que cualquier modificación en la base de código desencadena la compilación automática. y otro script desplegará esa compilación en el servidor. tu eres bueno para ir
Puedo estar equivocado, pero me parece que lo que busca Aron no es el control de versiones. El control de versiones es excelente, y estoy seguro de que ya lo están usando, pero para administrar actualizaciones en cientos de instalaciones personalizadas, necesita algo más.
Estoy pensando en algo parecido a un sistema de paquete 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, supongamos 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 problema, pero se rompería instalaciones con extensiones personalizadas en la parte superior de la interfaz anterior. Un sistema de paquetes bien planeado 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 las firmas basadas en claves públicas, así que simplemente haga lo que parezca ser el estándar para su plataforma elegida.
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. Recomiendo para ese asunto Redhat / Fedora por RPM y es en lo que tengo experiencia. De todas formas, puedes usar cualquier distribución basada en Debian.
Hace algún tiempo, creé una solución LAMP para gestionar servidores de alojamiento ISP. Tenían varios servidores para encargarse del alojamiento web y necesitaba una forma de implementar los cambios de mi administrador, ya que cada máquina era autónoma y tenía un administrador en línea. Hice un paquete de RPM que contiene los archivos de la solución (principalmente php) y algunos scripts de implementación que se ejecutan con el RPM.
Para la actualización automática, teníamos nuestro propio repositorio de RPM configurado en cada servidor en yum.conf. Establecí un trabajo crontab para actualizar los servidores diariamente con los últimos RPM de ese repositorio de confianza.
También se puede lograr la confianza porque puede usar la configuración de confianza en los paquetes de RPM, como firmarlos con su archivo de clave pública y aceptar solo paquetes firmados.
Si la personalización de su aplicación implica el cambio de pequeñas piezas 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 de núcleo estable, puntos de extensibilidad para que las bibliotecas personalizadas se conecten, la capacidad de cambiar apariencia mediante plantillas y la capacidad de cambiar el comportamiento e instalar complementos mediante el uso de archivos de configuración. De esta forma, no necesita una sucursal SVN separada para cada cliente. Por el contrario, mantenga el código del núcleo y las bibliotecas del complemento de extensión en control de fuente como es normal. En otro repositorio, cree una carpeta para cada cliente y mantenga allí todas sus plantillas y archivos de configuración.
Por ahora, crear sucursales SVN puede ser la única solución que te ayude a mantener tu 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 tienes una base de código estable para cada cliente. El único inconveniente con las ramas de SVN es que si mueve o cambia el nombre de un archivo en una rama, es imposible fusionar ese cambio de vuelta al 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.
¿Podría ser una idea agregar archivos de configuración? Usted escribió que muchos pequeños guiones están haciendo algo. Ahora bien, si los compilara en las fuentes y los dirigiera con archivos de configuración, ¿no debería eso "aliviarlo"?
Por otro lado, tener sucursales para cada cliente me parece un crecimiento exponencial. Y cómo "sabrías" qué áreas has hecho algo y no olvides "hacer" cambios en todas las otras ramas también. Eso se ve bastante feo para mí.
Parece que una combinación de controles de revisión, opciones de configuración y / o recibos de implementación parece ser una "buena" idea .....
No estoy seguro de si alguien dijo 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 por sí 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 forma, cualquier actualización que realice en el CMS se puede volver a enviar a su repositorio, y se enviará a otros proyectos cuando se actualicen (o el externo se svn: switch ''ed).
Como parte de facilitar esto, deberá asegurarse de que el CMS y la funcionalidad personalizada se encuentren en diferentes carpetas, de modo que svn externals funcione correctamente.
ES DECIR:
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 en la carpeta www si es necesario)
Esto le permitirá ramificar / etiquetar cada proyecto como lo desee. También puede cambiar el svn: ubicación externa por rama / etiqueta.
En términos de obtener cambios en vivo, le sugiero que se deshaga inmediatamente de ftp y use rsync o svn checkout / exports. Ambos funcionan bien, la elección depende de ti.
Tengo más experiencia con la ruta rsync, sincronizando 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 mostrar los archivos que cargará sin cargarlos también, utilizando el indicador -n. Generalmente utilizo un par de scripts para cada entorno, uno para prueba y otro para hacerlo.
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 acceso del servidor.
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.
Con tantas variaciones en su software principal, creo que realmente necesita un sistema de control de versiones para estar al tanto de las actualizaciones del tronco 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 y rastrear sucursales. Aunque la sugerencia de Benlumley de utilizar 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 ramificaciones y es rápido.
Consulte Capistrano para administrar sus implementaciones. Es un script de ruby, a menudo utilizado con Rails, pero se puede usar para todo tipo de administración de archivos en servidores remotos, incluso en sitios que no sean de ruby. Puede llevar el contenido al extremo remoto a través de varias estrategias, incluidas ftp, scp, rsync, así como también verificar automáticamente la última versión de su repositorio. Las agradables funciones que proporciona incluyen enlaces de devolución de llamada para cada paso del proceso de implementación (por ejemplo, para copiar los archivos de configuración específicos del sitio que podrían no estar en control de versiones) y un sistema de registro de versiones, hecho a través de enlaces simbólicos, para que puede retroceder rápidamente a una versión anterior en caso de problemas.
Yo recomendaría un archivo de configuración con la lista de sucursales y su ubicación alojada, luego lo ejecutaré con un script que verificará cada rama por turno y cargará los últimos cambios. Esto podría cronon para hacer actualizaciones nocturnas automáticamente.
Esto es lo que hago ...
Ruta de inclusión específica del cliente
- El código común compartido está en shared / current_version / lib /
- El código específico del sitio está en los clientes / foo.com / lib
- La ruta de inclusión se establece para incluir desde los clientes / foo.com / lib , y luego compartir / lib
- Todo está en un sistema de control de versiones
Esto garantiza que el código use archivos compartidos siempre que sea posible, pero si necesito anular una clase o archivo en particular por algún motivo, puedo escribir una versión específica del cliente en su carpeta.
Alias archivos comunes
Mi configuración de host virtual contendrá una línea como
Alias /common <path>/shared/current_version/public_html/common
Que permite compartir elementos comunes de UI, iconos, etc. en todos los proyectos
Etiquetar el código común con cada versión del sitio
Después de cada lanzamiento del sitio, etiqueto el código común creando una rama para congelar ese punto en el tiempo. Esto me permite implementar / shared / version_xyz / en el servidor en vivo. Entonces puedo hacer que un host virtual use una versión particular de los archivos comunes, o dejarlo apuntando a la versión actual si quiero que recoja las últimas actualizaciones.
Incorpore al código un proceso de auto actualización.
Verificará las actualizaciones y las ejecutará cuando / dónde / cómo lo haya configurado para el cliente.
Deberá crear algún tipo de lista de módulos (personalizados o no) que deba probarse con la nueva compilación antes del despliegue. Al implementar una actualización, deberá asegurarse de que se prueban e integran correctamente. Con suerte su diseño puede manejar esto.
Las actualizaciones son, idealmente, algunos pasos clave.
a) Copia de seguridad para que pueda retroceder. Debería poder anular la actualización completa en cualquier momento. Entonces, eso significa crear primero un archivo local de la aplicación y la base de datos.
b) Actualizar el proceso de monitoreo : haga que el sistema CMS llame a su casa para buscar una nueva versión.
c) Programar actualización sobre disponibilidad : es probable que no desee que la actualización se ejecute en el segundo momento en que esté disponible. Esto significa que tendrá que crear un cron / agente de algún tipo para hacer la actualización del sistema automáticamente en el 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 infierno. El despliegue escalonado de algún tipo podría ser beneficioso para ti.
d) Agregue el modo de mantenimiento para actualizar el sitio : ponga el sitio en modo de mantenimiento.
e) Pago de SVN o paquetes descargables : lo ideal es que pueda implementarlo a través de svn checkout, y si no, configure su servidor para entregar paquetes svn generados en un archivo que pueda implementarse en sitios de clientes.
f) Desplegar scripts DB - Hacer una copia de seguridad de las bases de datos, actualizarlas, completarlas
g) Actualizar el código del sitio : todo esto funciona para un paso.
h) Ejecutar algunas pruebas sobre él. Si su código tiene autocomprobaciones incorporadas, sería ideal.