Hola! ¿como están? Espero que se encuentren muy bien, se que he tardado un poco estaba investigando otras opciones que recientemente llegaron a mi inbox relacionado con otros tipos de plataformas estilo PaaS que mas bien son BaaS (backend As Service) que no se tratan de otra cosa mas que un dashboard para gestionar la base de datos y las notificaciones push de una aplicación móvil algo bastante interesante para los desarrolladores enfocados en moviles(Android, IOS y Windows) que no quieran lidiar con las tripas sueltas de un servidor.
Pero no es lo que me ataña este dia si no continuar con la serie, les mostrare la 4 entrega de este tutorial para programar aplicaciones utilizando 100% código en la nube, ya vimos las dos primeras partes importantes(la primera era una parte introductoria de lo que queríamos o pretendíamos hacer con esta idea). Si no saben de que hablo ingresen a los dos primeros tutoriales y síganlos en secuencia, es información bastante reciente y hasta el dia de hoy (19 de Febrero 2015) no hay cambios en la forma de ingreso ni demás cosas. En esta parte veremos ¿Como hacer para que el codigo que escribamos en Cloud9 se actualice en Openshift? Lamentablemente para este tutorial nos tenemos que poner algo técnicos y explicar que sucederá, el flujo-grama del como se hará el deploy(como se cargara el código que escribamos en Cloud9 se cargue a openshift) es similar al siguiente
.jpg) |
| Flujo del código de Cloud9 a Openshift |
Bien es así como el código parte de Cloud9 que no es mas que el editor de texto que actualiza vía Git al servidor de Openshift dependiendo de la selección que hagamos, sea Hot Deploy o Normal Deploy.
¿Que es Hot Deploy?
Es una forma de depositar el código en el servidor de Openshift sin detener los servicios, es decir que escribe en este mientras las instancias están corriendo, es bastante practico para entornos de producción o desarrollo pues no es necesario esperar que se reinicie el servidor, su principal desventaja es que puede ocasionar errores si se estaban haciendo peticiones al servidor porque todas las peticiones get/post se reinician o tratan de seguir con los archivos fuentes mientras se cambian.
Su principal ventaja es que es bastante rapido pues no tiene que esperar que el servidor de openshift le diga "Estoy apagando todo, espera un momento..." , "Ok ya puedo recibir el código ya apague todo" estas dos frases se traduccen en un par de minutos extras y si somos de frágil paciencia podemos romper algo o alguien.
Por defecto viene desactivado, para activarlo solo es necesario buscar la carpeta:
./openshift/markers/
Ahi crear un nuevo archivo de texto sin extension (sin contenido)
./openshift/markers/hot_deploy
Y con esto queda configurado, bastante sencillo en realidad, no olvidar añadirlo al proyecto mediante Git
$ cd /.../openshift/markers
/../opeshift/markers:$ git add hot_deploy
para que git lo tome encuenta en el proximo commit y push que realizemos, una vez escrito este archivo en openshift no resta mas empezar a hacer "git add . ; commit ; push"
¿Que es Normal Deploy?
El normal deploy es el deploy que viene por defecto en openshift esta orientado para entornos de ejecucion donde tengamos que para el servidor por cada cambio para no afectar a los clientes que se encuentren conectados o usando nuestra aplicación, realmente una sana costumbre y habito seria comenzar con hot_deploy y hasta que la aplicación este configurada por completo(o bien casi terminada) y desactivar para cambiar al normal deploy para no tener problemas con los clientes que escriban o utilicen la aplicacion, normal deploy también tiene un estilo o forma de pensar y es realizar la mayor cantidad de cambios antes de subir el código al servidor a diferencia de hot_deploy que con un par de lineas es suficiente esto por el tiempo de espera para apagar todo y reiniciar
Empezando: Como configurar openshift y cloud9
Vamos a hacer 2 cosas la primera sera instalar las herramientas de Openshift en Cloud9 y la segunda sera hacer una llave SSH publica para poder entrar a la aplicación la llave(public key ssh) si es publica es un hash de varios caracteres alfanuméricos, ademas de eso solicitara acceso en el terminal via correo y password asi que tranquilo, la seguridad no esta comprometida.
Esto lo haremos paso a paso con imágenes porque lo considero menos traumatico y mas didáctico:
Lo primero que haremos sera entrar al Workspace en Cloud9 esperaremos que configure todo si el caso fuere que nunca entramos al Workspace.
Luego buscaremos el terminal situado en la parte de abajo (en el caso de que no sea visto solamente hay que activarlo en el menú "View" y darle en "Console"
Aquí lo que tenemos que hacer es instalar los archivos de configuración para las herramientas de Openshift, estas están escritas en ruby por suerte cloud9 tiene instalado ruby con su gestor de paquetes gem (todo fríamente calculado)
solo basta iniciar este comando:
$ gem install rhc
y a esperar un par de segundos, no tarda mucho recuerden que ni siquiera usamos nuestro ancho de banda es Cloud9 quien usa su ancho de banda por lo tanto es bastante rápido la descarga.
Luego de eso estamos listos para configurar la llave publica y la llave de acceso local, la llave de acceso loca es útil para no ingresar el correo y contraseña cada vez que realicemos un deploy dentro de la terminal, quedan nuestras credenciales dentro de un archivo en Cloud9.
Para configurar la instancia de Openshift basta con iniciar:
$ rhc setup
Como es un asistente (wizard) no tendremos mas que proporcionarle los datos que requiera según el caso, la primera pregunta que nos detalla es en que servidor esta alojado, como Openshift es una plataforma bastante grande esta segmentada por continentes, sin embargo los Gears pequeños y gratis se encuentran en EEUU por lo que presionar Enter es mas que suficiente.
Después de presionar Enter (no se queden viendo la pantalla esperando que suceda algo, esto es un proceso rápido descuiden) ingresamos nuestro correo y contraseña recuerden que son las credenciales de Openshift y no las de Cloud9
Aquí nos preguntan si queremos generar el token del que les hable mas arriba es el token para dejar por default el acceso y las credenciales dentro del servidor para no tener que escribirles, yo en mi caso escribí "yes"
Despues nos preguntara si queremos subir el código de SSH a los servidores de Openshift, la respuesta es "yes" porque le necesitamos para conectarle y poder clonar el repositorio de Git dentro de Cloud9.
Una vez que tenemos esto no queda mas que clonar el repositorio de Git dentro de Cloud9, es decir recoger todos los archivos y código fuente de Openshift y pegarlos en Cloud9 recuerden que ahí en Openshift hicimos y configuramos una instancia de Node.js (en mi caso) y necesitamos todos los fuentes para poder configurar los y modificar los.
Para recuperar el código de git para clonarlo solo tenemos que ingresar a Openshift y buscar nuestro Gear con Node.js (igual con cualquier framework) y pegarlo dentro del terminal de Cloud9.
En rojo se encuentra la clave para clonar el directorio, esta se pegara dentro de la terminal de Cloud9 quedando de esta manera:
$ git clone ssh://<clave del Gear de Openshift>
La parte de color naranja es para usar la consola de forma remota si utilizan alguna consola remota programa al estilo Openssh, PuTTY si no saben de lo que hablo descuiden no le necesitan utilizaremos solo la consola de Cloud9 para realizar gestiones dentro de la consola SSH de Openshift.
 |
| Clonando la llave ssh desde el servidor de Openshift |
Les pedirá permiso para clonar por primera vez desde este servidor, justo donde esta la flecha, no continuara hasta que le demos "yes" después copiara los archivos de Openshift dentro de Cloud9
y se actualizara el arbol de archivos, idéntico a como esta estructurado en el servidor.
Y con esto tenemos todo listo ya solo resta hacer mas pequeña la terminal para tener mas espacio arriba y poder editar los archivos fuentes con mayor comodidad. Tambien no hay que olvidar salvar y cambiar los fuentes usando los comandos de git (add . ~ commit ~ push).
y con esto estamos listos para desplegar nuestro código, los comandos de rhc para obtener la llave publica son necesarios en cada Gear que tengan, en su cuenta.
Con esto termino el ultimo tutorial de esta serie, estaré subiendo un par de trucos relacionados con estos dos entornos para trabajar un poco mas rápido usando un par de filosofías de desarrollo ágil de software útiles para nosotros que somos programadores solos contra el mundo. Saludos!
