LogicaAlternativa.com está en la(s) nube(s), en OpenShift

“Si lees esto significa que Lógica Alternativa está ya en la nube”… Lo siento no he podido resistir la tentación de empezar esta entrada como los epílogos de las pelis 🙂

[OpenShift]OpenShift es un servicio de Red Hat encuadrado en la capa PaaS (Plataforma como Servicio), enfocado por lo tanto al desarrollador. Permite desplegar un montón de tipos de aplicaciones, J2EE (jbossas-7, jenkins-1.4, Tomcat 6, Tomcat 7, ..) PHP, Perl, Pyton, Ruby, JavaScript (node.js) contra base de datos como MySql, PostgreSQL, ¡MongoDb!. Y realizar integración continua con Jenkins (se más de uno que al llegar aquí ya se le está haciendo la boca agua).

Tiene una mecánica ‘alternativa’, aquí que no hay un ftp al uso. Se utiliza Git y el cliente por linea de comandos rhc.

Empezando por el final, la conclusión

Permitidme empezar por el final y que este párrafo sirva como resumen. Si lees lo de más abajo seguro que piensas “.. en que ‘fregao’ se ha metido este chaval para instalar un simple WordPress..”, y te doy la razón. Es un poco ‘heavy‘ porque es verdad que un hosting compartido te soluciona el problema muy bien.

Pero el objetivo no era el de complicarme la vida. La migración me ha permitido entender como funciona un servicio en la capa PaaS. Si no lo hubiera pegado con ello no hubiera comprendido del todo como era su mecánica. Otros servicios tendrán una idiosincrasia similar, o diferente, pero la idea era ‘pillar’ la esencia.

Una vez te acostumbras y asimilas su ‘logica alternativa‘ resulta cómodo trabajar con ella. Si lo necesito no tengo ninguna duda para utilizarlo para despliegue de demos y prototipos y es una opción más a valorar para su uso en producción.

Pongo un índice de lo que viene a continuación

Las Capas… ↑

Antes que nada, para ponerlo todo en contexto explico por encima las capas de las que se compone el “Cloud computing”. Son tres.

  • IaaS (Infraestructura como Servicio). Enfocada al técnico de sistemas. Un ejemplo representativo es el servicio EC2 de Amazon. Es el técnico de sistemas el que define la estructura y los servidores que va a necesitar. La ventaja es que puede replicar y añadir servidores, fácil e inmediatamente, según sea la demanda. Enlace muy interesante que lo explica “Como montamos meneamé en Amazon EC2”
  • PaaS (Plataforma como Servicio). El caso que nos ocupa, orientada al desarrollador. A este perfil lo que realmente le interesa es desplegar sus aplicaciones y que estas estén siempre disponibles. La infraestructura que hay detrás, si tiene que haber o no balanceo o el número de servidores, etc, realmente “no es su negocio”. Servicios como OpenShift abstraen esta parte.
  • SaaS (Software como Servicio). Para el usuario final. Google Apps y Microsoft Office 365 son conocidos por todos.

… las pruebas …↑

Me pareció interesante, estuve trasteando, de hecho he desplegado el proyecto de ejemplo de login con sha1 en un Tomcat 7. Lo puedes ver aquí:

http://loginsha1.logicaalternativa.com/index.jsp

Ya aviso que este enlace puede que no funcione dentro de un tiempo porque ya os he dicho que esto de OpenShift es muy goloso y este despliegue pase a mejor vida en pos de un proyecto mejor.

Después de las pruebas, …

… la migración …↑

Como preámbulo indicar que el blog de LogicaAlternativa.com es un WorPress (PHP y MySQL) y antes estaba alojado en un hosting compartido. Todo esto lo he hecho desde mi “máquina” de desarrollo que es un Debian virtualizado corriendo en un Ubuntu.

Instalando lo necesario ↑

Lo primero que hice fue darme de alta en OpenShift. Para poder crear aplicaciones, añadir módulos, desplegar, ver los logs, redireccionar puertos, etc es necesario tener instalado ‘Git‘ (sistema de control de versiones) y el cliente en línea de comandos ‘rhc‘. Git ya lo tenía instalado. La instalación no tiene complicación en Debian/Ubuntu.

Sólo explico esquemáticamente la instalación del cliente ‘rhc‘. Una guía sencilla y completa la puedes seguir en está página de OpenShift

‘rhc‘ está programado en Ruby por lo que primero hay que instalar Ruby, junto a ‘gem‘ que es un gestor de paquetes de este lenguaje.

1
$ sudo apt-get install ruby-full rubygems

01

 y ya podemos instalar ‘rhc‘

1
$ sudo gem install rhc

02

Puedes comprobar que todo es correcto ejecutando el comando

1
$ rhc

03

Ejecutado sin argumentos te muestra todas las opciones. La primera vez que se ejecute te pedirá definir el espacio de nombres con el que irá la url de tus aplicaciones que serán del tipo

http://<id_aplicacion>-<espacio_nombre>.rhcloud.com

Creando la aplicación ↑

Necesita crear una aplicación en PHP por lo que el comando es:

1
$ rhc app create <id_aplicacion> php-5.3

04

Donde ‘id_aplicacion‘ es el nombre de aplicación que le quieras dar. Si quieres ver todos los tipos de aplicación que puedes desplegar (JAVA, Perl, Ruby, Pyton, etc.), ejecuta sin argumentos el comando

1
$ rhc app create

05

Una vez que se ha ejecutado correctamente verás que se ha creado en tu equipo el directorio ‘id_aplicacion‘. Dentro se creará una estructura que dependerá de la plataforma. Para PHP consulta este enlace que explica para que sirve cada uno de los directorios.

Añadiendo MySQL ↑

El siguiente paso era añadir el ‘módulo’ de MySql. El comando es:

1
$ rhc add-cartridge mysql-5.1 --app <id_aplicacion>

06

Con esto ya tenemos montado el entorno.

Creando la BBDD y su usuario ↑

Había que crear la base de datos y el usuario de BBDD que utilizará WordPress. Para esto tenía 3 opciones.

Una de ellas es entrar por ssh y desde ahí ejecutar el cliente de mysql, accediendo entonces como administrador de la BBDD. Para ver los datos de la conexión ssh y las credenciales del usuario administrador se puede ejecutar el comando:

1
$ rhc apps

07

Otra solución es hacer una redirección de puertos de la máquina de producción a tu máquina con el comando.

1
$ rhc port-forward <id_aplicacion>

08

Una vez redirigido puedes conectarte con tu cliente favorito de MySQL poniendo como host ‘localhost’ y puerto el que te indique la redirección.

Y una tercera opción es instalarle a tu aplicación otro ‘módulo’ ‘phpMyAdmin‘ con el comando

1
$ rhc add-cartridge phpmyadmin-3.4 --app <id_aplicacion>

09

Para crear la base de datos y el usuario puedes seguir los pasos que indica WordPress

Recuerda que siempre puedes ver las credenciales y las URLs ejecutando el comando

1
$ rhc apps

10

Importar la BBDD ↑

Para pasar los datos tuve que hacer un export de la BBDD del hosting compartido e importarla en la nueva BBDD.

Organizando los fuentes ↑

Antes de explicar este punto, hay que explicar un poco como funciona OpenShift.

Cómo se despliega en OpenShift ↑

Para desplegar OpenShift utiliza el control de versiones Git. Cada vez que se hace un

1
$ git push

11

se sube tus cambios (los commit que hayas hecho en local) al repositorio remoto y se despliega. Tiene la ventaja de obligar a que todos los despliegues estén  bajo control de versiones. Tiene la pega que el directorio de aplicación de la máquina remota se regenera cada vez que se hace un despliegue, perdiéndose por ejemplo los archivos que se han subido por la web o las bases de datos basadas en fichero.

Variables de entorno ↑

Para guardar estos tipo de archivos en OpenShift existe un directorio ‘data‘ en la máquina remota, accesible desde la variable de entorno ‘OPENSHIFT_DATA_DIR » y que sirve como directorio para almacenar datos de manera permanentemente.

Otras variables de entorno predefinidas y que me interesaban en este caso son:

  • OPENSHIFT_REPO_DIR define el directorio del repositorio
  • OPENSHIFT_MYSQL_DB_HOST cargada con el valor del host de MySql
  • OPENSHIFT_MYSQL_DB_PORT cargada con el valor del puerto de MySql

Ejecución de scripts mientras se compila y se despliega ↑

Existe hay un directorio especial

1
~./.openshift/action_hooks

12

En el que se añaden los scripts que puedes necesitar que se lancen durante el proceso de construcción de binarios y en el despliegue. Para más información lee el archivo ‘README.md‘ de este directorio .

Copiando los fuentes y los archivos multimedia ↑

Dicho esto, lo que hice fue bajarme todo el código del hosting compartido y copiarlo todo en el directorio

1
~./php

13

Excepto el directorio ‘uploads‘. Es donde WordPress guarda los archivos que se suben para los artículos y normalmente está en:

1
<directorio_instalacion>/wp-content/uploads

14

Para la migración me cree un directorio

1
~./data_local/uploads

15

donde copie los archivos que había en el directorio ‘wp-content/uploads’

Creación del script deploy ↑

Dentro del directorio

1
~./.openshift/action_hooks

16

Creé un fichero con el nombre ‘deploy‘. Si tiene este nombre, este será el script que se ejecuta a la hora de desplegar. Su contenido es:

01
#!/bin/bash
02
# Se crea el directorio uploads en la parte permanente si no existe
03
if [ ! -d $OPENSHIFT_DATA_DIR/uploads ]; then
04
mkdir $OPENSHIFT_DATA_DIR/uploads
05
fi
06
# Se crea el enlace simbólico desde el directorio permanente al de despligue
07
ln -sf $OPENSHIFT_DATA_DIR/uploads $OPENSHIFT_REPO_DIR/php/wp-content/
08
 
09
# Se copia los archivos de Upload. Importante: sólo para la primer
10
# despliegue. Para el resto de despliegues se comenta la línea
11
cp -rv $OPENSHIFT_REPO_DIR/data_local/uploads/* $OPENSHIFT_DATA_DIR/uploads/

17

Crea un enlace simbólico desde el directorio ‘data/uploads‘ hasta el directorio del repositorio. La línea 11 sólo es para realizar la carga inicial de los archivos multimedia, en el segundo despliegue que se haga se deberá comentar.

Es muy importante que ha este fichero se le de permisos de ejecución

1
$ chmod 755 .openshift/action_hooks/deploy

18

Configurando la conexión a BBDD ↑

Tenía que modificar el fichero ‘php/wp-config.php‘ para configurar la conexión

1
/** Host de MySQL (es muy probable que no necesites cambiarlo) */
2
define('DB_HOST', getenv('OPENSHIFT_MYSQL_DB_HOST') . ':' . getenv('OPENSHIFT_MYSQL_DB_PORT') );

19

Donde se utiliza la función de PHP ‘getenv()‘ para obtener el valor de la variable de entorno que definen el host y el puerto de MySQL

Desplegando ↑

Ya sólo queda hacer ‘commit’ de los cambios:

1
$ git commit -m 'Aquí va mi comentario'

20

y subirlos al repositorio remoto y desplegar con el comando

1
$ git push

21

Con esto ya puedes ver el resultado. Es ahora cuando comenté la línea en el script de ‘deploy‘ que copia los ficheros multimedia (línea 11del trozo de código 17) para que no se ejecute en el próximo despliegue

Crear los alias y añadir las entradas de DNS ↑

El final del final. Para que la nueva aplicación respondiera a la url ‘wlocalhost:8080’, primero debía añadir el alias. El comando es

1
$ rhc alias-add <id_aplicacion> www.aquivatudominio.com

22

y añadir una entrada de DNS CNAME para que se resuelva:

www.aquivatudominio.com => <id_aplicacion>-<espacio_nombre>.rhcloud.com

Y por fin ya está.

Espero que os sirva.

M.E.