ltmo:/Django server setup

Lo que buscamos es aumentar el aislamiento de los componentes expuestos a la web y las partes móviles de la aplicación. Mi idea es referirnos a tecnologías favoritas, considerar algunos aspectos generales para buscar que sea más mantenible cada entorno.

Vamos a dividir los requisitos en cinco áreas:

1- Dependencias manejadas por el sistema operativo (postgres, intérprete de python, etc). 2- Dependencias python (django, etc). 3- Código de la aplicación. 4- Archivos estáticos de la aplicación (static assets: javascript, css, imágenes provistas). 5- Archivos subidos por los usuarios (media files).

1- Son pasible de ser compartidos por más de una instancia de la aplicación, deberían ser listadas en la sección de setup del readme del sitio que vamos a desplegar (deploy). Acá van las recomendaciones de entorno: - Python 3.4. Casi todo lo que depende en alguna versión reciente de django está listo para correr en python 3.3+. Python 3.4 (la versión estable actual) está instalado por defecto en ubuntu 14.04 LTS. - PostgreSQL 9.3. - Apache2 + mod_wsgi. Preferible por facilidad de configuración.

2- Estos deben estar listados en el archivo requirements.txt, encapsulados en un entorno virtual. Este entorno debe estar separado de la carpeta de carpeta que dispongamos para el punto siguiente en una carpeta donde tengamos permiso de escritura. Sugiero algo como ~/venvs/nombre-del-sitio. Hay notas específicas para la configuración de mod_wsgi en https://code.google.com/p/modwsgi/wiki/VirtualEnvironments. Estas se reducen a definir la directiva WSGIPythonPath: WSGIPythonPath /home/fudepan/venvs/web-o/lib/python2.5/site-packages 3- La carpeta de la aplicación estará expuesta a apache. Por lo que es importante que no incluyamos: - Historia de control de versiones: .hg, .git, etc - Documentación. - Otras carpetas que no hagan a la aplicación.

Esta carpeta debe tener permisos suficientes para que sea leída por apache (sugiero ~/sites/nombre-del-sitio). Finalmente, hace falta decirle a apache que busque el punto de entrada del middleware wsgi para nuestra aplicación. Generalmente el siguiente snippet alcanza

WSGIPythonPath /home/fudepan/sites/visiui:/home/fudepan/venvs/visi/lib/python2.7/site-packages:home/fudepan/venvs/visi/

<VirtualHost *:80>
        ServerName visi.zapto.com

        ServerAdmin info@fudepan.org.ar

        ErrorLog ${APACHE_LOG_DIR}/visi-error.log
        CustomLog ${APACHE_LOG_DIR}/visi-access.log combined

WSGIScriptAlias / /home/fudepan/sites/visiui/visiui/wsgi.py WSGIDaemonProcess visiui python-path=/home/fudepan/sites/visiui:/home/fudepan/venvs/visi/lib/python2.7/site-packages:home/fudepan/venvs/visi/

</VirtualHost>

4- Es importante que estos archivos sean servidos por un proceso diferente al que sirve la aplicación django (~/static/static_nombre-del-sitio). Para esto: - Configurar un virtualhost (o equivalente) que apunte a una carpeta diferente a la definida para el código de la aplicación. - Modificar STATIC_ROOT y STATIC_URL para que apunten al lugar que definimos en esta instancia. Esto debe ser hecho en un archivo local_settings.py al nivel de nuestro proyecto django. - Ejecutar manage.py collectstatic para que mueva todos los archivos requeridos a esta ubicación.

Más información en https://docs.djangoproject.com/en/dev/howto/static-files/

5- Similar al punto anterior, pero con ~/media/static_nombre-del-sitio. Consultar las mismas notas referidas en el punto anterior. La diferencia nodal es que probablemente esta carpeta exista en otro servidor enteramente, tenga permisos más restringidos y carezca de caching.

Sumarizando hasta acá deberíamos contar con una estructura más o menos como la siguiente:

/home/fudepan/ sites/web-o/ venvs/web-o/ static/static-web-o/ media/static-web-o/

Y tres virtualhosts:

/etc/apache2/sites-enabled/ web-o.conf static-web-o.conf media-web-o.conf

Con este entorno podemos incorporar un fabfile como este http://dpaste.com/0SQR8E5 para automatizar la parte rutinaria del deployment y permitir a los devs subir versiones nuevas periodicamente.

Este entorno permite escalar, ya que las ubicaciones de cada componente no están acopladas, mañana static puede ir a un CDN, media a un S3 de amazon y sólo necesitamos cambiar dos lineas en local_settings. Una idea que estabamos barajando es que la parte que es manejada por el sistema operativo (punto 1) sea documentada en un dockerfile o alguna otra solución de virtualización de manera aislada de manera que repliquemos estos entornos en un solo paso. De momento con sólo este entorno ya cubrimos la mayor parte de las buenas prácticas que hay en el libro

a e frase gif i imagen r video

Django server setup , Ago. 5, 2014, django, server,