Cómo instalar una aplicación Django en OpenShift

OpenShift es la plataforma PaaS de Red Hat. Aunque este post trata sobre consejos y experiencia de instalar una app de Django, hay que decir que OpenShift está actualmente montado sobre Amazon Web Services y que utiliza el concepto de recurso (gear o cartucho).  Un “cartucho” puede ser una aplicación web, una base de datos MySql, una instancia de memcached, etc. La cuenta gratuita permite tener 3 cartuchos. La idea es que si tu solución necesita escalar, fácilmente se puede añadir nuevos cartuchos bajo demanda.

Aquí os presento algunos tips o problemas con los que me he encontrado:

  • Lo primero es instalar el toolkit de OpenShift, rhc. Se trata de un script Ruby con el que se puede crear aplicaciones, ver logs, acceder via SSH etc. Se instala con “gem install rhc”. A mi me dio un error al instalar parte de la documentación pero funciona sin problemas.
  • La primera vez que se ejecuta rhc nos pedirá los credenciales de OpenShift (login/password) y permite crear y subir una clave pública de SSH para acceder sin tener que recordar clave alguna.
  • Para acceder vía SSH, ejecutamos “rhc ssh <app>“. Esto llama a SSH utilizando la clave pública. Como usuario, se utiliza un string-ID bastante largo. Al acceder nos situa en el “home” virtualizado: /var/lib/openshift/<UserID>. En ese directorio aparecen los componentes principales de tu aplicación. Para una aplicación Django son: app-root, git y python. La mayoria de los directorios son de sólo lectura. Solo en $HOME/app-root/data, $HOME/app-root/repo y algún que otro directorio podemos escribir.
  • Si necesitamos instalar algún componente Python, deberemos de ejecutar el script de Virtualenv. Esto se hace con “source $HOME//python/virtenv/bin/activate”. Luego ya llamaos a “pip install <paquete>“.
  • En caso de tener que copiar algo vía SCP, deberemos tener cuidado de que el directorio destino tenga permiso de escritura. Esta seria una sintaxis válida “scp <fichero> <userID>@<app>-<cuenta>.rhcloud.com:/var/lib/openshift/<userID>/app-root/data“.
  • El entorno de OpenShift establece un número grande de variables de entorno que será de gran utilidad para configurar tu aplicación. Todas comienzan por “OPENSHIFT_”. Por ejemplo OPENSHIFT_APP_DNS nos da el host,  OPENSHIFT_REPO_DIR el directorio donde se ubica el repositorio o OPENSHIFT_PYTHON_LOG_DIR donde se encuentran los logs de Apache.
  • El equivalente a “service httpd restart” es “ctl_app restart“. Lo utilizaremos cada vez que hagamos algún cambio en la aplicación.
  • La mejor forma de enlazar nuestra aplicación con wsgi es fijarnos en el ejemplo que viene. Apache ejecuta $HOME/app-root/repo/wsgi/application para cada request. Este script prepara el entorno de virtualenv e invoca al manejador wsgi de Django. Debemos ajustar los paths y nuestro “project.settings”.
  • Lo más normal es que durante la instalación de nuestra app nos encontremos con errores tipo 500. Con “rhc tail”, veremos los logs de Apache.
  • Los contenidos estáticos deben ir a $HOME/app-root/repo/wsgi/static, luego debemos configurar correctamente la variable STATIC_ROOT para que apunte al path correcto dentro de settings.py.
  • Si nuestra aplicación usa base de datos, se recomienda la ubicacion $HOME/app-root/data, ya que $HOME/app-root/repo se destina al repositorio de código.
  • Es posible tener una configuración especifica según el entorno de ejecución mirando las variables de entorno. En el ejemplo que viene por defecto, se crea una variable booleana ON_OPENSHIFT dentro settings.py que se usa para determinar la ubicación de la base de datos sqlite3.
  • Si queremos obtener la IP de aquellos que nos visitan, tenemos que usar el meta “HTTP_X_FORWARDED_FOR” en lugar “REMOTE_ADDR”.
  • Por último, si queremos asociar un CNAME a nuestra app, usamos “rhc alias <app> <cname>” para crear dicho alias (imagino que añadirá un ServerAlias a la configuración de Apache).

Sin duda OpenShift es de las plataformas más económicas (o gratis) de hospedar un proyecto Django. Muy recomendable para aplicaciones inicialmente pequeñas o prototipos.

 

GoLang, nuevo modelo de programación

GoLang logo

GoLang logo

Translate to:English

Estos días he estado mirando la sintaxis (y semántica) de programación de GoLang.

Desarrollo siempre que puedo en C. Pero recurro a Python cuando tengo que hacer alguna GUI (PyQt4) o desarrollo web (Django).

Con GoLang se abre (a priori) una opción que llevaba tiempo buscando: “código nativo con la flexibilidad de Python“.

Mis objetivos se verán cumplidos si la relación tiempo de ejecución/tiempo de desarrollo sale más favorable que respecto a Python. El tiempo lo dirá.

Ahora mismo necesito cambiar el chip para este nuevo lenguaje.

Voy a resumir (desde mi punto de vista, claro) las principales claves del nuevo modelo de programación que GoLang presenta:

  • Inicialización de las variables: ¿cuántas veces no habeis tenido un segmentation fault por variables no inicializadas? Es sin duda una característica que echaba de menos.
  • Switch de cualquier tipo: poder hacer switch sobre strings es una característica muy necesitada por mi, tuve que recurrir a macros para poder emularla.
  • Defer: esta nueva keyword es muy interesante. En la mayoría de funciones relacionadas con I/O, es posible que no se cumpla una condición y por ejemplo tengamos que cerrar un archivo y salir. Si la cóndición se cumple, al final de la operación es necesario cerrar dicho archivo. Actualmente yo usaba un if para comprobar la condición a falso, cerrar el fichero en el cuerpo del if, y retornar. En casos más complidados usaba el peligroso goto. Pues bien, con “defer fclose(fd)” justo despúes del fopen(), conseguimos que justo antes de retornar la función, se cierre el fichero. Es decir, defer, encola llamadas a función en una cola LIFO a ejecutar una vez terminada la ejecución de la función. Creo que esto es muy útil y genera un código muy limpio.
  • Campos vectoriales o funciones con retorno múltiple: desde el punto de vista algebraico, las funciones de C son campos escalares, y = f(x1,x2,…,xn), en GoLang podemos devolver más de un valor. Ésto es tremendamente útil y ayuda que los programas sean más limpos. Hasta ahora lo habitual era devolver un código de retorno (Success o el nº de error) y pasar el puntero de la variable a devolver. Ej: En C, int getData(FILE* fd, char** data,int* len), con GoLang:  func getData(fd *FILE) (data *char,len int)
  • (Casi) Adiós al “;”: con GoLang no es necesario el uso del “;” en los bloques top level. La verdad es que no acabo de entender muy bien donde es necesario o no. En los códigos de ejemplo he encontrado sitios donde hay “;” y no es necesario. Eliminándolo el programa sigue compilando. Creo que se colará más de un “;” innecesario.
  • Literales ideales: las constantes y demás literales tienen un tamaño de ¡1024 bits! Podemos tener el número Pi con una gran precisión. Luego su manejo dependerá del tipo de variable donde lo almacenemos.
  • El tipo “map” (diccionario): el diccionario es unos de mis tipos preferidos en Python. Ahora lo puedo usar en GoLang :).
  • Los threads con Go: adiós al uso de la libreria pthread para crear hilos. Crear un hilo en GoLang es tan sencillo como ” go <funcion>”. Simplemente impresionante.
  • Sincronización y comunicación con CSP: Según mi profesor de programación concurrente, Dijkstra sólo consideraba como sincronización segura de threads la que estaba hecha mediante canales. GoLang implementa la semántica de programación CSP por canales. Esta característica dará mucho que hablar (y escribir).
  • Declaración implicita: ya no es necesario declarar la variable. Con “:=” creamos una variable con el tipo más acertado para el literal que usamos. Ej; ” i := 1″.
  • Test unitarios: los test de unidad son un latazo. GoLang incorpora en su framework soporte para realizar estos test. Sin duda ganaremos tiempo para otras cosas.

Creo que estas son las principales características de GoLang que harán cambiar la forma de programar a más de uno.

Por último os quiero comentar unos detalles sobre GoLang que me llaman la atención.

  • Ahora mismo hay soporte para i586, amd64 y ARM. ¿Por qué ARM? Creo que Google pretende recompilar las aplicaciones o el propio Android con GoLang.
  • ¿Qué pasa con Windows? Ahora mismo no podemos crear código que corra en Windows. Los desarrolladores de GoLang dicen que por ahora no va a ver soporte para Windows. Creo que soportar o no Windows será decisivo en el futuro de este nuevo lenguaje.

Bueno, ahora toca empezar a programar con GoLang 🙂

Entradas relacionadas:

GoLang no es para Windows
Benchmark a GoLang: servidor web en Go vs Python

Translate to:English
MenefanteMenéame TwitterTwitter