2008-10-19 11 views
5

La mayoría de los frameworks de python tendrán un servidor web de desarrollo de algún tipo que tendrá una advertencia de que no es para usar como servidores de producción. ¿Qué tan diferentes tienden a ser de sus equivalentes de producción?¿Qué tan cerca están los servidores web de desarrollo a los servidores web de producción?

No he decidido exactamente qué marco utilizar, y mucho menos qué servidor de producción utilizar, por lo que es un poco difícil para mí anclar esto a un "servidor de desarrollo de comparación x al servidor de producción y". Entonces, con eso dicho, permítanme hacer la pregunta un poco más precisa: en su experiencia pasada con un framework python, ¿cuánto tiempo tuvo que pasar para que su aplicación funcione con un sistema de producción una vez desarrollada en un desarrollo? ¿servidor? ¿O saltó el servidor de desarrollo y desarrolló su aplicación en un servidor que se parece más a lo que usará en producción?

Respuesta

5

Los entornos inferiores deben intentar hacer coincidir el entorno de producción lo más fielmente posible dados los recursos disponibles. Esto se aplica a todos los esfuerzos de desarrollo, independientemente de si están basados ​​en Python o incluso en la web. En términos prácticos, la mayoría de las organizaciones no están dispuestas a gastar ese tipo de dinero. En este caso, trate de hacer que al menos el entorno que se encuentra directamente debajo de la producción sea lo más cercano posible a la producción.

Algunas de las variables a tener en cuenta son:

  • muchas veces hay múltiples máquinas (servidor de aplicaciones, servidor de base de datos, servidor web, balanceadores de carga, muros cortafuegos, etc.) en una producción. Mantenga todo esto en mente.

  • Sistemas operativos

  • número de CPU.Pasar de un entorno inferior de una CPU a un entorno de producción de varios núcleos puede exponer problemas de subprocesos múltiples que no se probaron

  • equilibrio de carga. Muchas veces los entornos más bajos no tienen carga equilibrada. Si va a replicar las sesiones (por ejemplo) a través de múltiples servidores de aplicaciones de producción, debe tratar de hacer lo mismo en un entorno de menor

  • versiones de software/biblioteca

2

En general, son los mismos en términos de la configuración que se requiere para ejecutar las aplicaciones que incluyen la configuración de entorno.
Sin embargo, los clientes generalmente tienen sistemas de desarrollo que son menos poderosos en términos de la potencia de procesamiento y otros recursos h/w. He visto usar servidores virtuales en desarrollo, ya que generalmente tienen varios proyectos en paralelo y esto les ayuda a reducir el costo.

1

Lo ideal es que la configuración lógica del servidor de desarrollo, prueba y producción sea la misma. Deben tener la misma versión de SO, servidor web y todos los demás activos de software utilizados para ejecutar la aplicación. Sin embargo, dependiendo de qué tan fuerte sea su entorno, las cosas se recortarán: copias de imágenes, secuencias de comandos, etc. en la máquina de desarrollo que no pasan por la prueba ni la producción.

Para minimizar esto, probablemente necesite algún tipo de script de inserción que pueda moverlo de una etapa a la siguiente, es decir, PushVersionDev, PushVesionTest, PushVersionProd. idealmente, esta debería ser la misma secuencia de comandos con parámetros para los servidores de destino que representan todo lo que necesita para mover la aplicación a través de las diversas etapas.

Recomendaría una lectura del libro de Theo Schlossnagle Scalable Internet Architectures para obtener más ideas al respecto.

Para responder a su pregunta directamente .... una vez que obtenga su aplicación probada e implementada, el tiempo para rodar a productoin no es genial - implementar SO, servidor web, marcos de apoyo si necesitan instalación, aplicación y está bien ir. Del metal desnudo, he visto que los servidores Linux se conectan en línea en 1 hora, Windows tarda unos 90 minutos. si tiene el sistema operativo y el servidor web aún menos ... minutos.

2

que desarrollo con Django. El servidor de producción que tenemos es remoto, por lo que es complicado utilizarlo para el desarrollo. Por lo tanto, al principio, creé un vm e intenté hacer coincidir lo más posible el entorno del servidor de prod. En algún momento, vm recibió una manguera (debido a un incidente no relacionado). Hice un balance de la situación en ese momento y me di cuenta de que realmente no había una buena razón para usar una versión personalizada para el desarrollo. Dado que los recursos disponibles para la aplicación no eran los mismos que los del servidor de prod, no era bueno para las consultas de tiempo de todos modos (en un sentido absoluto).

Dicho esto, ahora uso el servidor de desarrollo integrado de django con sqlite para el desarrollo, y apache/wsgi y postgresql para la producción. Siempre que las dependencias de Python se cumplan en ambos lados, es 100% compatible. El único problema potencial sería escribir raw sql en lugar de usar orm.

0

Su entorno de ensayo debe imitar su entorno de producción. El desarrollo es más parecido a un patio de recreo, y el control en el entorno de desarrollo no debería ser tan estricto. Sin embargo, el entorno de desarrollo debe actualizarse periódicamente desde el entorno de producción (por ejemplo, los datos prod copiados al dev db, cerrar los puertos en dev que están cerrados en prod, etc.).

Idealmente, dev, stage y prod están en máquinas separadas. Las máquinas separadas pueden ser cajas físicas separadas o máquinas virtuales en la misma caja física, dependiendo del presupuesto/necesidades.

Cuestiones relacionadas