¿Qué "configuración" ha visto que funciona mejor? Usé virtualenv y moví mi proyecto django dentro de este entorno, sin embargo, he visto otras configuraciones donde hay una carpeta para entornos virtuales y otra para proyectos.
virtualenv es una forma de aislar entornos Python; como tal, no tiene un papel importante que desempeñar en la implementación ; sin embargo, durante el desarrollo y las pruebas , es un requisito, si no muy recomendable.
El valor que obtendría de virtualenv es que le permite asegurarse de que las versiones correctas de las bibliotecas estén instaladas para la aplicación. Por lo tanto, no importa dónde coloque el entorno virtual en sí. Solo asegúrese de no incluirlo como parte del sistema de control de versiones del código fuente.
El diseño del sistema de archivos no es crítico. Verá muchos artículos que ensalzan las virtudes de los diseños de directorios e incluso proyectos esqueléticos que puede clonar como punto de partida. Siento que esto es más una preferencia personal que un requisito estricto. Seguro que es bueno tenerlo; pero a menos que sepa por qué , no agrega ningún valor a su proceso de implementación, así que no lo haga porque algún blog lo recomienda a menos que tenga sentido para su escenario. Por ejemplo, no es necesario crear un setup.py
archivo si no tiene un servidor PyPi privado que sea parte de su flujo de trabajo de implementación.
¿Cómo puedo configurar las cosas de una manera que permita alojar varios sitios en un solo servidor?
Hay dos cosas que necesita para realizar configuraciones de varios sitios:
- Un servidor que está escuchando en la IP pública en el puerto 80 y / o el puerto 443 si tiene SSL.
- Un montón de "procesos" que ejecutan el código fuente real de django.
La gente usa nginx para el n. ° 1 porque es un proxy muy rápido y no viene con la sobrecarga de un servidor completo como Apache. Puede utilizar Apache si se siente cómodo con él. No hay ningún requisito de que "para varios sitios, utilice nginx"; solo necesita un servicio que esté escuchando en ese puerto, sepa cómo redirigir (proxy) a sus procesos que ejecutan el código django real.
Para el n. ° 2, hay algunas formas de iniciar estos procesos. gevent / uwsgi son los más populares. Lo único que debe recordar aquí es no usar runserver en producción .
Esos son los requisitos mínimos absolutos. Normalmente la gente agrega algún tipo de administrador de procesos para controlar todos los "servidores django" (# 2) en ejecución. Aquí verás upstart
y supervisor
mencionaste. Prefiero supervisor, ya que no necesita hacerse cargo de todo el sistema (a diferencia de los advenedizos). Sin embargo, nuevamente, este no es un requisito estricto . Puede ejecutar perfectamente un montón de screen
sesiones y separarlas. La desventaja es que, si su servidor se reinicia, tendría que reiniciar las sesiones de pantalla.
Personalmente recomendaría:
- Nginx para el n. ° 1
- Elija entre uwsgi y gunicorn, yo uso uwsgi.
- supervisor para la gestión de los procesos de backend.
- Cuentas de sistema individuales (usuarios) para cada aplicación que aloja.
La razón por la que recomiendo el # 4 es para aislar los permisos; de nuevo, no es un requisito.
¿Por qué algunas personas sugieren usar gunicorn_django -b 0.0.0.0:8000 y otras sugieren gunicorn_django -b 127.0.0.1:8000? Probé este último en una instancia de Amazon EC2 pero no funcionó mientras que el primero funcionó sin problemas.
0.0.0.0
significa "todas las direcciones IP" - es una meta dirección (es decir, una dirección de marcador de posición). 127.0.0.1
es una dirección reservada que siempre apunta a la máquina local. Por eso se llama "localhost". Solo es accesible para procesos que se ejecutan en el mismo sistema.
Normalmente, el servidor de aplicaciones para el usuario (el número 1 de la lista anterior) escucha la dirección IP pública. Usted debe asociarla explícitamente el servidor a una dirección IP .
Sin embargo, si por alguna razón está en DHCP o no sabe cuál será la dirección IP (por ejemplo, es un sistema recién aprovisionado), puede decirle a nginx / apache / cualquier otro proceso al que unirse 0.0.0.0
. Esta debería ser una medida provisional temporal .
Para los servidores de producción, tendrá una IP estática. Si tiene una IP dinámica (DHCP), puede dejarla 0.0.0.0
. Sin embargo, es muy raro que tenga DHCP para sus máquinas de producción.
Encuadernación gunicorn / uwsgi a esta dirección se no se recomienda en la producción. Si vincula su proceso de backend (gunicorn / uwsgi) a 0.0.0.0
, puede ser accesible "directamente", sin pasar por su proxy de front-end (nginx / apache / etc); alguien podría simplemente solicitar http://your.public.ip.address:9000/
y acceder a su aplicación directamente, especialmente si su servidor front-end (nginx) y su proceso back-end (django / uwsgi / gevent) se están ejecutando en la misma máquina .
Sin embargo, es libre de hacerlo si no quiere tener la molestia de ejecutar un servidor proxy de front-end.
¿Cuál es la lógica detrás del archivo de configuración de nginx? Hay tantos tutoriales que usan archivos de configuración drásticamente diferentes que estoy confundido sobre cuál es mejor. Por ejemplo, algunas personas usan "alias / ruta / a / carpeta / estática" y otras "raíz / ruta / a / carpeta / estática". Tal vez puedas compartir tu archivo de configuración preferido.
Lo primero que debe saber sobre nginx es que no es un servidor web como Apache o IIS. Es un proxy. Entonces verá diferentes términos como 'upstream' / 'downstream' y múltiples "servidores" que se definen. Tómate un tiempo y revisa primero el manual de nginx.
Hay muchas formas diferentes de configurar nginx; pero aquí es una respuesta a su pregunta en alias
frente root
. root
es una directiva explícita que vincula la raíz del documento (el "directorio de inicio") de nginx. Este es el directorio que verá cuando realice una solicitud sin una ruta comohttp://www.example.com/
alias
significa "asignar un nombre a un directorio". Los directorios con alias pueden no ser un subdirectorio de la raíz del documento.
¿Por qué creamos un enlace simbólico entre los sitios disponibles y los sitios habilitados en / etc / nginx?
Esto es algo exclusivo de debian (y sistemas similares a debian como ubuntu). sites-available
enumera los archivos de configuración para todos los hosts / sitios virtuales del sistema. Un enlace simbólico de sites-enabled
a sites-available
"activa" ese sitio o host virtual. Es una forma de separar archivos de configuración y habilitar / deshabilitar hosts fácilmente.