Progtwigción web en python

Buenos días.

Como lo indica el título, tengo algunas preguntas sobre el uso de python para el desarrollo web.

  • Cuál es la mejor configuración para un entorno de desarrollo, más específicamente, qué servidor web usar, cómo enlazar python con él. Preferiblemente, me gustaría que sea implementable en ambos entornos, * nix y win.

Mi principal preocupación la última vez que probé apache + mod_python + CherryPy fue tener que volver a cargar el servidor web para ver los cambios. ¿Se considera normal? Por alguna razón, la carga automática de Cherrypy no funcionó en absoluto.

¡Muchas gracias!

Así que aquí están mis pensamientos al respecto:

Estoy utilizando Python Paste para desarrollar mi aplicación y, finalmente, también ejecutarla (o cualquier otro servidor web de Python). Normalmente no uso mod_python o mod_wsgi, ya que hace que la configuración del desarrollo sea más compleja.

Estoy usando zc.buildout para administrar mi entorno de desarrollo y todas las dependencias junto con virtualenv . Esto me da una caja de arena aislada que no interfiere con ningún módulo de Python instalado en todo el sistema.

Para la implementación también estoy usando buildout / virtualenv, eventualmente con un buildout.cfg diferente. También estoy usando Paste Deploy y su mecanismo de configuración donde tengo diferentes archivos de configuración para el desarrollo y la implementación.

Como por lo general ejecuto paste / cherrypy, etc., estoy usando Apache, NGINX o tal vez solo un barniz solo delante de él. Depende de las opciones de configuración que necesites. Por ejemplo, si no se necesita un alojamiento virtual, reglas de reescritura, etc., entonces no necesito un servidor web completo en el frente. Cuando uso un servidor web, generalmente uso ProxyPass o una reescritura más compleja usando mod_rewrite.

El framework web de Python que uso en este momento está repoze.bfg en este momento por cierto.

En cuanto a sus preguntas sobre la recarga, conozco estos problemas cuando lo ejecuto, por ejemplo, con mod_python, pero cuando utilizo un “servicio de descarga … independiente”, etc., hasta ahora funciona muy bien. Además, repoze.bfg tiene algunos ajustes para volver a cargar las plantillas automáticamente cuando cambian. Si el marco que usa tiene que estar documentado.

En cuanto a los subprocesos múltiples que se utilizan habitualmente, se utilizan en el servidor web de Python. Como CherryPy admite esto, supongo que no tiene que preocuparse por eso, debe usarse automáticamente. Simplemente debe hacer algunos puntos de referencia para averiguar en qué cantidad de subprocesos se realiza mejor su aplicación.

Espero que ayude.

¿Cuál es la mejor configuración para un entorno de desarrollo?

No importa mucho Usamos Django, que funciona muy bien en Windows y Unix. Para la producción, usamos Apache en Red Hat.

¿Es necesario volver a cargar el servidor web para ver los cambios que se consideran normales?

Sí. No está claro por qué querrías algo diferente. El software de aplicación web no debería ser dynamic. Contenido sí. Número de software

En Django, desarrollamos sin utilizar un servidor web de ningún tipo en nuestro escritorio. El comando “runserver” de Django vuelve a cargar la aplicación en la mayoría de los casos. Para el desarrollo, esto funciona muy bien. Los momentos en que no se vuelve a cargar son cuando dañamos las cosas tanto que la aplicación no funciona correctamente.

¿Cuál es la mejor configuración para implementar una aplicación Python que funcione en producción y por qué?

“Mejor” no está definido en este contexto. Por lo tanto, proporcione alguna calificación para “nido” (por ejemplo, “más rápido”, “más barato”, “más azul”)

¿Vale la pena bucear directamente con un marco o rodar algo simple por mi cuenta?

No pierdas el tiempo rodando el tuyo. Usamos Django debido a la página de administración incorporada que no tenemos que escribir o mantener. Guarda montañas de trabajo.

¿Cómo se sirven exactamente las aplicaciones de Python si tengo que volver a cargar httpd para ver los cambios?

Dos métodos:

  • Daemon – mod_wsgi o mod_fastcgi tienen un proceso de daemon de Python al que se conectan. Cambia tu software. Reinicie el demonio.

  • Embedded: mod_wsgi o mod_python tienen un modo incorporado en el que el intérprete de Python está dentro del mod, dentro de Apache. Debe reiniciar httpd para reiniciar el intérprete incorporado.

¿Debo considerar el uso de subprocesos múltiples?

Si y no. Sí, necesitas ser consciente de esto. No, no necesitas hacer mucho. Apache y mod_wsgi y Django deberían manejar esto por ti.

+1 a la respuesta de MrTopf, pero agregaré algunas opiniones adicionales.

Servidor web

Apache es el servidor web que le dará la mayor capacidad de configuración. Evite mod_python porque es básicamente no compatible. Por otro lado, mod_wsgi está muy bien soportado y le brinda una mejor estabilidad (en otras palabras, es más fácil de configurar para que el uso de la CPU / memoria sea estable en lugar de puntiagudo e impredecible).

Otro gran beneficio, puede configurar mod_wsgi para recargar su aplicación si se toca el script de la aplicación wsgi, sin necesidad de reiniciar Apache. Para los servidores de desarrollo / prueba, incluso puede configurar mod_wsgi para recargarse cuando se modifique cualquier archivo en su aplicación. Esto es tan útil que incluso ejecuto Apache + mod_wsgi en mi computadora portátil durante el desarrollo.

Nginx y lighttpd se usan comúnmente para servidores web, ya sea sirviendo aplicaciones Python directamente a través de una interfaz fastCGI (no se moleste con ninguna interfaz WSGI en estos servidores) o usándolas como una interfaz frente a Apache. Las llamadas a la aplicación se transfieren (mediante proxy) a Apache + mod_wsgi y luego nginx / lighttpd sirve el contenido estático directamente.

Nginx tiene la ventaja adicional de poder servir contenido directamente desde memcached si desea obtener ese nivel sofisticado. He escuchado comentarios despectivos sobre lighttpd y parece que tiene algunos problemas de desarrollo, pero ciertamente hay algunas grandes empresas que lo utilizan con éxito.

Pila de python

En el nivel más bajo, puede progtwigr directamente a WSGI para obtener el mejor rendimiento. Hay muchos módulos útiles de WSGI para ayudarle en áreas que no desea desarrollar. En este nivel, probablemente querrá elegir componentes WSGI de terceros para hacer cosas como la resolución de URL y el manejo de solicitudes / respuestas HTTP. Un gran componente de solicitud / respuesta es WebOb .

Si te fijas en Pylons , puedes ver su idea de los componentes WSGI “mejores de su clase” y un marco que hace que sea más fácil que Django elegir tus propios componentes, como el motor de plantillas.

Django podría ser una exageración, pero no creo que sea un buen argumento en contra. Django hace las cosas fáciles más fáciles. Cuando comienzas a entrar en aplicaciones muy complicadas, es donde realmente necesitas mirar para moverte a marcos de niveles inferiores.

Mira el motor de aplicaciones de Google. Desde su página web:

Google App Engine te permite ejecutar tus aplicaciones web en la infraestructura de Google. Las aplicaciones de App Engine son fáciles de construir, de mantener y de escalar a medida que aumentan sus necesidades de almacenamiento de datos y tráfico. Con App Engine, no hay servidores que mantener: simplemente carga su aplicación y está lista para servir a sus usuarios.

Puede servir su aplicación usando un nombre de dominio gratuito en el dominio appspot.com, o usar Google Apps para servirla desde su propio dominio. Puede compartir su aplicación con el mundo o limitar el acceso a los miembros de su organización.

App Engine no cuesta nada para empezar. Regístrese para obtener una cuenta gratuita y podrá desarrollar y publicar su aplicación para que el mundo la vea, sin cargo y sin compromiso. Una cuenta gratuita puede usar hasta 500 MB de almacenamiento persistente y suficiente CPU y ancho de banda para aproximadamente 5 millones de páginas vistas al mes.

Lo mejor de todo: incluye soporte Python, incluido Django. Vaya a http://code.google.com/appengine/docs/whatisgoogleappengine.html

Cuando utiliza mod_python en un servidor de Apache con hilos (el predeterminado en Windows), CherryPy se ejecuta en el mismo proceso que Apache. En ese caso, es casi seguro que no desea que CP reinicie el proceso.

Solución: utilice mod_rewrite o mod_proxy para que CherryPy se ejecute en su propio proceso. Entonces puedes cargar automáticamente al contenido de tu corazón. 🙂