Instalar Jenkins en CentOS 6.3

sudo wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins-ci.org/redhat/jenkins.repo
sudo rpm --import http://pkg.jenkins-ci.org/redhat/jenkins-ci.org.key
sudo yum -y install jenkins

Instalamos JDK

sudo yum -y install java-1.7.0-openjdk.x86_64

Cambiamos a usuario jenkins, y especificamos el shell, ya que por defecto para la mayoría de las instalaciones, éste viene capado a /bin/false

sudo su jenkins -s /bin/bash
ssh-keygen
exit

Arrancamos el servicio:

sudo service jenkins start

Con esto, si todo ha ido bien, podremos acceder a nuestro Jenkins en: http://localhost:8080, o el dominio donde lo hayamos instalado. Recordar protegerlo, porque de lo contrario, permanecerá abierto para cualquier usuario.

Nested Revealing Module Pattern

Uno de los patrones que más utilizo para el desarrollo de pequeñas aplicaciones, es el patrón "Revealing Module". Me gusta porque te permite encapsular funciones públicas y privadas, y dejar el global scope limpio.

Sin embargo, bajo determinadas circunstancias, dicho patrón puede quedarse pequeño, especialmente si nos gusta modularizar, u organizar el código de un modo más fácil de cara a mantenerlo y a futuras expansiones.

Imaginemos que tenemos una web con tabs, menus y un par de carruseles. Podríamos organizar nuestro código de muchas maneras. Una de ellas es usando el patrón "Module":

var AppUI = {

  Tabs: {
    show: function(){},
    hide: function(){},
    init: function(){}
  },

  Menus: {
    show: function(){},
    toggle: function(){},
    Options: {
      add: function(){},
      remove: function(){}
    },
    init: function() {}
  },

  Carruseles: {
    start: function(){},
    stop: function(){},
    next: function(){},
    prev: function(){},
    init: function(){}
  }

};

La ventaja de este sistema, es que tengo el código organizado, y el global scope sólo se ve afectado por una nueva variable, o namespace, llamada AppUI, pero todas las funciones dentro de AppUI son públicas, lo que no es muy correcto. Fíjate que por error, yo podría escribir AppUI.Tabs.show(), en vez de AppUI.Menus.show(), y estar obteniendo una funcionalidad indeseada. Lo cual, podría arreglarlo escribiendo nombres de propiedades más descriptivas, como Tabs.showTabs(), o Menus.showMenus(), de tal modo que no pudiese cometer el error anterior, pero esto no deja de tener cierta redundancia, y con objetos con muchas propiedades, me obligaría a poner nombres quizá demasiado extensos, para hacerlos más descriptivos, y puede que perdiese algo de legibilidad.

No digo que lo anterior sea incorrecto, todo depende de la solución que más se adapte a nuestras necesidades. Si lo que queremos es evitar que todo sea público dentro de AppUI, lo anterior no es la mejor manera.

Me gusta que el global scope sólo se vea afectado por una única variable nueva, AppUI. Pero quiero evitar que dentro de ella, todas las funciones sean públicas. Es decir, quiero mantener lo más limpio posible, el scope de AppUI. ¿Cómo resolverlo? Pues aquí es donde entran en juego otros patrones, en concreto el "Revealing Module".

Refactorizando el anterior objeto AppUI, para adaptarlo a dicho patrón, nos quedaría algo como esto:

var AppUI = {};

AppUI = (function(){

  function init(){}

  return {
    init:init
  }

})();

AppUI.Tabs = (function(){

  function show(){}
  function hide(){}
  function init(){}

  return {
    init:init
  }

})();

AppUI.Menus = (function(){

  function show(){}
  function toggle(){}
  function init(){}

  return {
    init:init
  }

})();

AppUI.Menus.Options = (function(){

  function add(){}
  function remove(){}

  return {
    add:add,
    remove:remove
  }

})();

AppUI.Carruseles = (function(){

  function start(){}
  function stop(){}
  function next(){}
  function prev(){}
  function init(){}

  return {
    start:start,
    stop:stop,
    init:init
  }

})();

Lo que tenemos ahora es un patrón "Module", con varios patrones "Revealing Module" en su interior. Nos vamos acercando. Mantenemos la modularidad, ya que AppUI.Carruseles, así como el resto, los puedo definir en archivos distintos. Y hemos conseguido ocultar algunas funciones, haciéndolas privadas para el global scope y nuestro namespace. Por ejemplo, AppUI.Carruseles.next() es totalmente invisible. Sin embargo, me sigue sin gustar... Desde el global scope puedo acceder a todos los objetos de AppUI: Tabs, Menus y Carruseles. Desde AppUI.Carruseles, puedo acceder a AppUI.Menus.Options.add(), etc., y puede que no me interese.

Entonces se me ocurrió anidar el patrón "Revealing Module", dentro de otro "Revealing Module". Esto solo puede ser fruto de una mente retorcida... Veamos el resultado:

var AppUI = (function(){

  var Tabs = (function(){

    function show(){}
    function hide(){}
    function init(){
      show();
    }

    return {
      init:init
    }

  })();

  var Menus = (function(){

    var Options = (function(){

      function add(){}
      function remove(){}
      function init(){
        add(4);
      }

      return {
        init:init
      }

    })();

    function show(){}
    function toggle(){}
    function init(){
      show();
    }

    return {
      init:init
    }

  })();

  var Carruseles = (function(){

    function show(){}
    function start(){}
    function stop(){}
    function next(){}
    function prev(){}
    function init(){
      show();
      start();
    }

    return {
      init:init
    }

  })();

  function init(){
    Tabs.init();
    Menus.init();
    Carruseles.init();
  }

  return {
    init:init
  }

})();

De este modo, lo único que es visible desde el global scope, es AppUI.init(). Y por supuesto, desde Carruseles, no puedo ver a Menu.Options, como sucedía antes. A lo sumo, desde AppUI, tendría acceso únicamente a las funciones de Tabs, Menus y Carruseles, que hayamos querido hacer públicas, como por ejemplo, Menus.init(). Pero nada más.

El inconveniente, es que no podría dividirlo en varios archivos, por lo que hemos perdido toda modularidad: mal. Me sigue sin servir. Aunque puede que esto no suponga un inconveniente para el proyecto en el que estés...

Este patrón anidado, no es ni mejor ni peor que otros. Todo depende de lo que necesites, y supone simplemente una vuelta de tuerca más, para aquellos que sean un poco maniáticos con la limpieza del scope, en todos sus ámbitos. A mi personalmente me gusta más un namespece muuuuy limpio.

Si lo único que necesitamos es un lugar donde encapsular e inicializar todo un conjunto de funciones estancas entre ellas, pero mantener el scope lo más limpio posible, nos sobra más de la mitad del código anterior, y nos serviría con:

var AppUI = function(){
  
  (function Tabs (){
    function show(){}
    function hide(){}
    show()
  })();

  (function Menus (){
    (function Options (){
      function add(){}
      function remove(){}
      add(4);
    })();
    function show(){}
    function toggle(){}
    show();
  })();

  (function Carruseles (){
    function show(){}
    function start(){}
    function stop(){}
    function next(){}
    function prev(){}
    show();
    start();
  })();

}

Y cuando queramos iniciarlizar nuestra función, por ejemplo, una vez cargado el DOM:

AppUI();

Node.js: qué es y cuándo utilizarlo

Se trata de una "nueva" tecnología del lado del servidor, como pueda ser PHP, Ruby, .NET, etc., basada en el motor de JavaScript V8 de Google: una potente máquina virtual creada por Lars Bak

Ventajas de Node.js a nivel de servidor

Una ventaja de Node.js es el lenguaje con el que se crean sus aplicaciones: JavaScript. Si! Ahora podemos realizar consultas a base de datos, lectura de ficheros, procesamiento de imágenes, todo con javascript en el lado del servidor. Esto está haciendo que JavaScript, sea el lenguaje del momento, como lo fue PHP en su día, o Ruby.

Utilizando un servidor web tradicional, como pueda ser Apache, cada vez que solicitas un recurso web, éste crea un hilo separado, o invoca un nuevo proceso, para atender dicha solicitud. A pesar de que Apache responde rápidamente a las solicitudes, y limpia el proceso una vez que ha terminado, este sistema puede necesitar un montón de recursos. Una aplicación web con muchas visitas, puede tener serios problemas de rendimiento.

Node.js, por el contrario, utiliza un sistema de E/S asíncrono y basado en eventos y callbacks de funciones. Es decir, todo lo realiza en un único hilo: se queda escuchando a ciertos eventos que ocurran en nuestra aplicación, y cuando ocurren, responde en consecuencia, de modo asíncrono, es decir, un evento no bloquea a otro. Dicho de otro modo, crea miles de subprocesos y trata a sus outputs como streams. Esto supone una mayor velocidad de respuesta. Os dejo un enlace donde podéis comprobar vosotros mismos, que Node.js es muchísimo más rápido sirviendo peticiones que Apache: https://code.google.com/p/node-js-vs-apache-php-benchmark/wiki/Tests

Ventajas de Node.js a nivel de desarrollador

Dejo para el final, la que para mi supone a día de hoy la principal ventaja: tener Node.js instalado en tu entorno de desarrollo local, te abre la puerta a una inmensa cantidad de herramientas, con las que automatizar tediosos procesos y mejorar tu rendimiento como desarrollador: es decir, te permite centrarte en el desarrollo y olvidarte de lo demás. Independientemente del lenguaje que uses después, con Node.js instalado en local, puedes utilizar:

• Grunt.js: imprescindible procesador de tareas, y watchers, con el que automatizar el compilado de tus archivos a varios entornos. Es decir, podemos trabajar con preprocesadores como Sass, Haml, CoffeScript, etc., con la ventaja que esto ya supone, pero además, unificar todos sus watchers en un único lugar, y compilar varias salidas al mismo tiempo, en diferentes formatos, según lo necesitemos. Por ejemplo, si trabajas con Sass, Less o Stylus, puedes decidir compilar para producción un CSS minificado, y al mismo tiempo, compilar para un entorno de desarrollo, otro sin minificar en otra carpeta. Con Grunt puedes también usar JSHint, que en tiempo real irá diciéndote si en tus .js estás cometiendo errores sintácticos, en qué linea, y cómo resolverlos. Y si a la vez le pones Haml, Yaml, Ugligy, etc. pues lo mismo, puedes minificar la salida para producción, pero para tu entorno de pruebas, dejarlo sin minificar. Más información sobre Grunt.
• Bower: gestor de paquetes o librerías desarrollado por Twitter. Cada vez que inicias un proyecto, Bower se encargará por ti, de descargar las versiones que necesites de las librerías javascript que necesites, o si lo prefieres, que descargue siempre la última versión, y coloque los archivos donde tu le digas: jQuery, bootstrap, CoffeeScript, etc.: aquí tenéis toda la lista de paquetes: http://sindresorhus.com/bower-components/. Más información sobre Bower.
• Yo: un paquetizador de entornos, por decirlo de alguna manera, que se integra con Grunt. Te permite configurar el árbol de directorios de cada nuevo proyecto como a ti te guste: él te crea la estructura por ejemplo, para un proyecto con HTML5, o PHP. Aún no he conseguido que funcione demasiado bien bajo Windows, y estoy en búsqueda de alternativas... Más información sobre Yo.
• All together now!: Yeoman, un conjunto de herramientas integradas entre sí: el gestor de entornos Yo, el gestor de librerías Bower, y el automatizador de tareas Grunt. Más información sobre Yeoman.

¿Cúando utilizar Node.js?

Existen varios casos donde no tiene sentido utilizar Node.js. Por ejemplo, cuando nuestra aplicación necesite muchísima CPU, y tenga pocos procesos de E/S, como podría ser, codificando vídeo. Para eso, casi mejor utilizar otros lenguajes como C o C++.

Otro ejemplo donde no vamos a ver una gran ventaja utilizando Node.js, es si estamos programando una aplicación clásica contra base de datos: alta, baja, edición y modificación de registros. Aquí, Node.js no te va a dar más ventajas de las que te pueda dar PHP, o Ruby, ya que trabajarás con un único canal de E/S.

Donde si es adecuado Node.js, es en aplicaciones de una sola página, con mucho AJAX, o cuando necesitas hacer muchas cosas al mismo tiempo, sobre todo muchas operaciones E/S (acceso a ficheros, bases de datos,...) a la vez.

También obtendrás una gran ventaja en velocidad y rendimiento, con aplicaciones en tiempo real, que necesitan mantener una conexión persistente entre el navegador y el servidor (juegos online, chats, herramientas de colaboración, etc ).

Otro punto interesante, es que para Node.js, las peticiones y respuestas HTTP son streams, lo que supone poder parsear subidas de archivo en tiempo real: http://nodejs.org/api/stream.html

Conclusiones

Por supuesto, no a todo el mundo le gusta Node.js, especialmente cuando se convierte en un lenguaje de moda. Hace poco leí en un post que las gráficas de rendimiento y velocidad, se hacen contra Apache, y no contra PHP con Nginx, para favorecer a Node.js, y que éste último, era inseguro. Obviamente, sus conclusiones tampoco eran del todo ciertas: Nginx es un servidor web/proxy inverso, y puede ser usado también con Node.js. Es decir, para ser justos, habría que comparar PHP/Nginx, con Node/Nginx. Y respecto a la seguridad, depende del desarrollador, no de la herramienta.

Está claro, que cada tecnología, tiene su sentido en un determinado contexto, y hay que saber aplicar la mejor según las necesidades del proyecto. Supongo que por esto es importante conocer bien qué opciones tenemos, para ofrecer siempre el mejor servicio, y no quedarse atascado en tecnologías clásicas. Dicho de otro modo: todos los caminos conducen a Roma, pero por unos llegas antes que por otros. Cuantas más opciones conozcas, mejor para ti como desarrollador.

¿Cómo conectar por SSH a nuestra microinstancia EC2 con Windows?

Este tutorial, forma parte de una serie de artículos comprendidos dentro de: Cómo crear un entorno de desarrollo gratuito, en Amazon EC2.

En este caso, suponemos que ya hemos creado nuestra microinstancia, y tenemos nuestro archivo .pem descargado. Si aun no lo has hecho, te recomiendo entonces que leas el artículo Crear un entorno de desarrollo gratis en Amazon EC2: microinstancias

Descargamos el PuTTY

La herramienta que utilizaremos para conectar por SSH con nuestra clave .pem que nos generó Amazon al crear la microinstancia, desde Windows a nuestro servidor, se llama PuTTY y la podéis descargar aquí. Os sugiero que descarguéis el instalador de Windows: a día de hoy es putty-0.62-installer.exe, que incluye el PuTTY, el generador de claves PuTTYGen, y el gestor de claves Peagent

Convertimos el archivo .pem a .ppk

Una vez que tenemos instalado el PuTTY, ejecutamos el generador de claves PuTTYGen. Lo necesitaremos, para generar el archivo .ppk a partir del .pem, porque con Windows, los .pem no funcionan muy bien. Los archivos .pem son certificados X.509 o claves RSA, pero tampoco hace falta que sepamos mucho más de ellos para lo que pretendemos hacer. Simplemente, guárdalo en un lugar seguro, y no se lo des a nadie. Por decirlo de alguna manera, es un certificado que asegura que eres tu, y no otra persona, a Amazon.

Bueno, pues una vez que hayamos arrancado el PuTTYGen, veremos algo como esto:

Hacemos click en File > Load private key, y nos pedirá que le indiquemos dónde está el archivo .pem a transformar. Recordar que debéis seleccionar "All files", para que os lo muestre. A veces, viene seleccionada la opción de mostrar únicamente los archivos .ppk:

Lo siguiente que nos debe aparecer, es un aviso de que la llave, ha sido correctamente importada, como este:

Podemos ponerle un nombre a dicha llave, si modificamos el campo "Key comment", y añadirle una contraseña si modificamos el campo, que por defecto viene en blanco "Key passphrase". No es necesario hacer ninguna de las dos cosas, aunque en un futuro nos puede venir bien que el comentario, al menos, sea algo más descriptivo. Lo más importante es que la opción SSH2 esté seleccionada. Una vez hecho esto, pulsamos en "Save private key":

Nos preguntará si estamos seguros de querer guardar el archivo .ppk sin contraseña, en caso de que no le hayamos puesto ninguna. Le decimos que si, y guardamos nuestro .ppk en un lugar seguro, pero que recordemos, porque lo vamos a necesitar varias veces.

Con esto, hemos terminado con PuTTYGen, y abrimos ahora el PuTTY, que será la herramienta que usaremos para conectar. Si ya tienes convertido tu .pem en un .ppk, puedes empezar por este paso directamente:

Configurando el PuTTY para conectar a EC2 por SSH

Al abrir el programa, debemos ver una ventana como esta:

• En el campo Host, ponemos la dirección de nuestra microinstancia. Debe ser algo como ec2-111-111-111-111.eu-west-1.compute.amazonaws.com. Os explicaré más adelante cómo convertir esta URL, en una IP más asequible, creando desde el panel de gestión de EC2, una "Elastic IP". En caso de que ya tengáis una "Elastic IP" asociada a vuestra microinstancia, en host siemplemente podéis meter dicha IP, en vez del nombre ec2-111-111-111-111.eu-west-1.compute.amazonaws.com
• En el campo Port, ponemos 22. Recordad que tenéis que haber abierto dicho puerto, en vuestra microinstancia, o si no, no podréis acceder.
• En Conection Type: SSH
• En el campo "Saved sessions", ponemos el nombre con el que queramos guardar nuestra conexión, y por último...
• Pulsamos en "Save"

A continuación, sin cerrar esa ventana, en el menú de la izquierda, seleccionamos Conection > Data, y en el campo "Auto-login username", escribimos el usuario con el que queramos acceder por defecto. En mi caso, es ubuntu, en otros tutoriales he visto que ponen root... Yo probaría primero con ubuntu, si habéis montado un Ubuntu 12.04.

Seguimos en esa ventana, sin cerrarla, y vamos a Connection > SSH > Auth, y allí indicamos dónde está nuestro archivo .ppk que creamos antes

Importante: este paso, si se os olvida, tendréis que volver a configurarlo todo. Sin cerrar la ventana del PuTTY, tenéis que volver, desde el menú de la izquierda, a la opción "Session", ponerle un nombre a la configuración de sesión, y darle a "Save". De este modo, se os guardará la configuración en la lista de abajo, y la próxima vez que queráis acceder, ya simplemente es pinchar en ella, y "Load".

Para terminar, una vez hayamos guardado la configuración, sólo nos queda conectarnos: pulsamos en "Open":

Y si todo ha ido bien, debemos ver una ventana como esta:

Y listo! Estamos en nuestro EC2, en el directorio home del usuario!!. Espero que os haya ayudado este tutorial.

Cómo crear una alarma de costes en AWS

Este tutorial, es la continuación de cómo crear un entorno de desarrollo gratuito, en Amazon EC2.

Las alarmas de coste, sirven para notificar a los usuarios de AWS de cuándo se exceden del plan gratuito, o de una determinada cantidad. Valen para cualquier servicio que utilicemos: EC2, RDS, etc. Desde el perfil de usuario (My account), dentremos monitorizado casi en tiempo real, los costes que se realizarán sobre nuestra cuenta, y por qué razón.

Una vez que ya tenemos creada nuestra microinstancia, lo siguiente que debemos hacer, por tanto, es configurar una alarma de costes. En nuestro caso, el límite a partir del cual debe avisarnos, es si se superan los 0€. Para ello, hacemos accedemos con nuestro email y contraseña a AWS, y vamos a "My account":

Importante: Amazon trabaja con varias regiones. Yo recomiendo que las microinstancias y todo lo que podamos, lo creéis en EU (Ireland). Sin embargo, las alarmas de costes, sólo pueden ser creadas en N.Virginia, así pues, seleccionamos dicha región:

Esto de las regiones, si no estás pendiente, puede marearte un poco, porque crees que estás en una, y Amazon de golpe te cambia a otra, sin avisar. O al hacer login, entras en una región que no es la tuya, y cuando te das cuenta, ya has instalado 4 instancias, que tienes que borrar, para crearlas de nuevo en tu región. Ojo con eso. Si alguien sabe cómo evitar esto, que me lo comente por favor! :)

Bueno, una vez seleccionada la región de N.Virginia, que es la única donde se pueden crear alarmas de costes, vamos a "Account Activity"

Esto nos conducirá a una página donde veremos la factura que nos tiene Amazon preparada para el mes que viene, en función de los recursos utilizados. En nuestro caso, debe estar a 0. Además, desde aquí podremos crear alarmas de costes. Para ello hacemos click en crear nuestra primera alarma de coste: (lo marco en amarillo)

Nos debe aparecer una pantalla como esta:

En ella elegimos, que nos envíe un email, siempre que el coste total de los servicios con Amazon (AWS), supere la cantidad que le indiquemos, en este caso 0. ¡Y listo! Podemos dormir tranquilos, que si nos excedemos del plan gratuito que nos ofrece Amazon, nos llegará un email avisando.

Como nota curiosa, os cuento que configuré la alarma, y sin saberlo, cree dos instancias micro: una en N.Virginia, y otra en EU Ireland. Con esto de que cambian de zona sin enterarte... pues me lié. Enseguida me llegó un email, diciéndome que los costes se habían incrementado en 5 dólares. Así que me puse en contacto con el servicio técnico, cual cliente indignado que se queja sin enterarse ni del nodo. Me atendieron estupendamente, me explicaron que es que había dado de alta dos microinstancias, y que me devolvían 25 dólares por las molestias, pero que espabilase. Así que gané con el error 20 pavos... Con esto quiero decir, que si por alguna razón hacéis algo mal, si tenéis una alarma configurada, tampoco os van a sacar los ojos... porque el coste cuenta por horas, como los taxistas. Y si ponéis remedio enseguida, no creo que el coste sea muy alto. E incluso si lloráis un poco, igual los de soporte se tiran al royo. Calidad del servicio: 10

Crear un entorno de desarrollo gratis en Amazon EC2: microinstancias

Tal y como describen en su web, Amazon nos ofrece con sus Servicios Web (AWS), un conjunto completo de servicios de infraestructuras y aplicaciones para ejecutar prácticamente todo en la nube, desde aplicaciones empresariales y proyectos de grandes datos hasta juegos sociales y aplicaciones móviles. Es decir, podremos tener nuestro entorno de desarrollo en la nube.

El hecho de ser un cluod service, significa que los servicios que contratemos tendrán total escalabilidad, y se adaptarán en tiempo real a los recursos que el proyecto vaya necesitando. Es decir, pagamos por lo que necesitemos, y nada más.

Pero además, Amazon nos ofrece una capa gratuita, para los que queramos empezar en el mundillo cloud, trastear con ella y aprender. Aquí podéis encontrar toda la información que necesitéis sobre dicha capa, y en español: http://aws.amazon.com/es/free/. Yo básicamente la voy a resumir, centrándome simplemente en el servicio EC2. Aquí os dejo un enlace con más características del servicio EC2: https://aws.amazon.com/es/ec2/

¿Qué nos ofrece?

Básicamente, la instancia de EC2 gratuita, la llaman "micro", y ofrece 750 horas al mes durante un año, de un servidor Windows o Linux. 750 horas al mes, equivalen a 31 días, 24 horas al día, que es lo mismo que decir, un año "by the face". Lo miden por horas, porque nuestro servidor lo podremos arrancar o detener según lo necesitemos, y el tiempo y coste, dejan de correr. Esto no lo puedes hacer con los sistemas de alojamiento tradicionales, es una de las ventajas de la nube.

Crear una cuenta en Amazon

Lo primero que debemos hacer, es crearnos una cuenta en AWS: https://aws.amazon.com/

Lo más seguro, es que nos pida los datos de una tarjeta de crédito, o una cuenta Paypal, y tengamos que hacer todo el proceso de comprobación de que dicha cuenta realmente es vuestra. Esto lo hace Amazon, porque no tiene una cuota fija mensual, como en las empresas de hosting clásicas, sino que cobra bajo demanda: pagas por lo que usas, y si no usas nada no pagas nada. No os preocupéis. Yo llevo casi un año con ellos y no me han cobrado nada. Siempre que no os salgáis del paquete gratuito, no tendréis problema. Además podréis configuraros un aviso, para que en el caso de que empiecen a cobraros, desde el primer céntimo, os llegue un email a vuestra cuenta de correo. Es importante, que deis una cuenta de correo que soléis mirar a diario... no sea que... os avisen ¡y no os enteréis!

Todo este proceso de alta de la cuenta o tarjeta de crédito, me lo salto porque es bastante intuitivo, y es seguir los pasos: no tiene misterio. Una vez que lo hayáis termiando, vais a la consola de gestión de nuestro AWS (Dashboard), y hacemos click en EC2

Crear nuestra primera instancia gratuita

Una vez dentro de la pantalla de gestión de nuestro EC2, deberemos ver algo como esto, y hacemos click en "Launch instance" para crear nuestra primera instancia:

Amazon, dispone de una serie de máquinas preconfiguradas, listas para usar con el software que necesitems ya instalado (php, mysql, apache, etc, etc), con lo cual no tendremos que preocuparnos de nada y ganaremos bastante tiempo. Ellos las llaman "AMI", y hay casi 2000 disponibles (aquí tienes la lista completa). Puedes elegir la que quieras, pero OJO: las gratuitas son las que llevan una estrella.

Volviendo a nuestra instancia, acabamos de pulsar en "Launch instance", y debe aparecernos una pantalla como esta, donde podremos elegir qué queremos instalar, si una máquina preconfigurada, una máquina comprada en la tienda de ámazon, o arrancar el asistente, y que nos vaya guiando. Para el tutorial, voy a elegir la opción de máquina preconfigurada, o "Quick Launch", en concreto, una Ubuntu 12.04, que es gratis.

He marcado en amarillo, lo más importante:

• Debemos especificar el nombre a dicha instancia, con un nombre que sirva para luego identificarla, porque podremos tener más de una instancia micro, aunque luego sólo arranquemos una a la vez, para que no nos cueste dinero.
• Para poder conectarnos a la instancia por SSH, o sFTP, necesitaremos una clave pública y otra privada, es decir un par de claves (Key pair). Debemos especificar el nombre a dicha clave, y descargarla a una carpeta segura (se trata de un archivo con extensión .pem), donde nadie más tenga acceso a ella. A las máquinas de EC2, se accede con dicha clave, no se pide usuario ni contraseña. Si le das a alguien esa clave, que es un archivito que pesa muy poco, pues le estarás dando el acceso a todas las instancias que lleven dicha clave asociada. Es como una llave que puede abrir las puertas (instancias) que tu indiques. Así que cuidado dónde la guardas :)
• Debemos elegir el AMI preconfigurado que queramos
• Y por último pulsamos en continuar

La siguiente pantalla que nos aparecerá, será un resumen de la configuración. En general, aquí no tenemos que tocar nada, salvo la configuración de seguridad. Así que le damos a "Edit details", luego marcamos el checkbox de "Security Setting", después marcamos el checkbox de "Create new Security Group", le ponemos un nombre, una descripción, y añadimos unas cuantas reglas.

Estas reglas, no son otra cosa, que puertos a través de los cuales podremos acceder a nuestra microinstancia. Tendremos que habilitar el 21 si queremos FTP, el 22 si queremos sFTP, o conexión por SSH, el 80 si queremos tener acceso a la máquina con un navegador web, el 3306 si queremos acceder a un mysql que le instalemos, etc. Desde el menú desplegable, veremos ya unas cuantas reglas preconfiguradas. Una vez que terminemos, pulsamos en "Save details", y a continuación "Launch".

El siguiente paso, es crearnos alarmas. Nuestro sistema estará continuamente monitorizado, y como nos cobran por tiempo que tengamos la instancia encendida, como los taxistas, pues está bien que nos avisen de si, por la razón que sea, ha dejado de funcionar. Incluso, podemos decirle que pare la máquina, y no nos siga cobrando... (por algo que no funciona). Está bien pensado, ¿no?

Para configurar alarmas, lo siguiente que tenemos que hacer por tanto, es pulsar en "Create Status Check Alarm". Como verás, debajo en pequeñito, pone que puede costar dinero. Efectivamente, puede, si se te va la olla añadiendo alarmas como si no hubiese mañana. En este tutoríal, vamos a dar de alta sólo una de ejemplo.

Elegiremos que nos mande un email a nuestro correo, y que además detenga la instancia, en caso de que ésta falle más de dos veces seguidas, en periodos de 5 minutos

Pulsamos en siguiente, y ¡enhorabuena! Ya tienes tu servidor de desarrollo funcionando!! Deberías verlo en una pantalla como esta, que se llama la consola de gestión de EC2. En concreto, esta es la lista de instancias.

Desde aquí, si marcamos su checkbox y pulsamos en Acciones, podremos ver todo lo que podemos hacer con ella. Por ejemplo, pararla si no la vamos a usar, para que no nos sigan cobrando por ella, en caso de que no estemos usando la microinstancia gratuita.

Otra ventaja que nos ofrece Amazon, son las gráficas de monitorización, que tiene para aburrir. Podemos verlas, en la misma pantalla donde estamos, es decir, donde la lista de instancias, pinchando en la pestaña "Monitoring":

Creando una alarma de costes

Lo siguiente, y más importante que debemos hacer, es configurar una alarma de coste, desde nuestra cuenta de Amazon Web Services (AWS). Es decir, que nos manden un correo en cuanto empiecen a cobrarnos, para que podamos enseguida, entrar y parar las instancias que nos estén causando coste, si lo deseamos.

Para eso, puedes visitar el siguiente artículo de la saga: ¿Cómo configurar una alarma de costes en AWS? :) Espero que os haya ayudado este minitutorial!

Instalar Cloud9 en una instancia micro Amazon EC2, con Ubuntu 12.04

Últimamente no hago más que alucinar con Cloud9, y las cosas que se pueden hacer con este estupendo IDE en la nube. Incluso he estado a punto de pagar por sus servicios, una pequeña y bien merecida cuota de 12$/mes. Pero me echaba un poco para atrás, la idea de tener sólo 512Mb por workspace. Así que dándole vueltas, se me ocurrió instalarlo en una instancia micro de Amazon EC2, con Ubuntu 12.04, ¡gratis! y sin restricciones. Os cuento cómo:

Abrimos el puerto 3131 en nuestro EC2

Para este tutorial, vamos a utilizar dicho puerto como ejemplo, aunque podría ser cualquier otro

Para ello vamos a nuestra consola de gestión del EC2, y hacemos click en "Security Groups". Editamos el grupo de seguridad que tengamos asociado a nuestra micro instancia, sobre la que correrá Cloud9 con Node.js:

Instalamos las dependencias

Para que Cloud9 pueda funcionar, necesita ciertas dependencias, que debemos tener instaladas previamente en nuestro servidor. Para ello, ejecutamos en el terminal, la siguiente instrucción:

sudo apt-get install -y build-essential g++ curl libssl0.9.8 libssl-dev apache2-utils git libxml2-dev

Preparamos el directorio de instalación

Para evitar problemas de permisos, mejor crearnos un directorio en la carpeta home del usuario con el que vayamos a lanzar Cloud9, e instalar ahí todo lo que necesitemos ejecutar. Lo puedes llamar como quieras. Yo he usado "c9": si eliges otro nombre, recuerda cambiarlo en todos los comandos que veas de este tutorial. Ejecuta desde el terminal lo siguiente:

mkdir ~/c9
echo 'export PATH=$HOME/c9/bin:$PATH' >> ~/.bashrc
. ~/.bashrc

El resto de instrucciones, las ejecutaremos sobre el directorio que nos hemos creado:

cd ~/c9

Instalamos Node Version Manager (NVM)

Este paso es opcional, aunque no viene mal hacerlo. Con Node Version Manager, podrás tener las versiones de node que necesites instaladas en tu sistema, y ejecutar aplicaciones con una o con otra. Por ejemplo, Cloud9 no siempre funciona con la última versión de Node.js. Es posible que necesites ejecutar Cloud9, con otra versión anterior. Aquí es donde nos vendrá bien tener instalado el NVM. Para ello, primero debemos eliminar cualquier versión que tengamos instalada previamente de Node.js
Con los siguientes comandos, nos bajamos de GitHub la última versión de Node Version Manager, en la carpeta c9/nvm/ dentro del directorio home:

sudo apt-get remove nodejs
git clone git://github.com/creationix/nvm.git ~/c9/nvm
echo '. ~/c9/nvm/nvm.sh' >> ~/.bashrc && . ~/.bashrc

Instalamos Node.js desde NVM

Ahora ya podremos instalar la versión de Node.js que queramos. Incluso podemos tener varias simultáneamente:

nvm install v0.8.18
nvm install v0.10.12
nvm use 0.10.12

Descargamos e instalamos Cloud9 desde el repo de GitHub

Los siguientes comandos, descargan la última versión de Cloud9 en GitHub, creamos un directorio en la carpeta c9/cloud9/ de home, y dentro de éste cambiamos a la última rama de desarrollo, para después, actualizar todos los submódulos:

git clone git://github.com/ajaxorg/cloud9.git ~/c9/cloud9
cd ~/c9/cloud9
git checkout devel
git submodule update --init --recursive
bin/cloud9.sh
cd ..

Instalamos sourcemint

sudo npm install -g sm
cd ~/c9/cloud9
sudo sm install

Arrancamos Cloud9 con la versión de Node.js que necesitemos

Cloud9 puede ser usado con cualquier navegador. Todo lo que necesitas es arrancar el servidor con tu ruta de proyecto. Se arranca ejecutando el script ~/c9/cloud9/bin/cloud9.sh, y podemos pasarle algunos parámetros de configuración:

• -l: indicamos la IP desde la que se puede acceder:
  
  • 127.0.0.0: si queremos que sólo se pueda acceder a nuestro Cloud9 desde http://localhost/
  • 0.0.0.0: si queremos que se pueda acceder desde cualquier IP
• -p: indicamos el puerto (que tendremos que abrir desde EC2)
• -w: indicamos la ruta al workspace a cargar

Por ejemplo, si quisiéramos ejecutar Cloud9, con la versión 0.10.12 de Node.js, y que fuese accesible desde cualquier IP, a través del puerto 3131, y que el directorio de trabajo fuese lo que tengamos en /var/www, tendríamos que escribir lo siguiente:

nvm use 0.10.12 && cd ~/c9/cloud9 && bin/cloud9.sh -l 0.0.0.0 -p 3131 -w /var/www

En este momento, debemos ver la siguiente imagen en nuestra consola:

Detener el servicio Cloud9

Por normal general, simplemente con CTRL+C, en la consola desde donde se ha lanzado el servicio, basta con detenerlo. Pero si por alguna razón, este método no nos funciona, podemos detener los procesos de Cloud9 manualmente.

Lo primero que tenemos que hacer, es abrir otra consola, o terminal, y ejecutar el comando que nos permita ver qué procesos hay asociados a Cloud9. Para ello:

ps aux | grep cloud9

Con esto nos aparecerá un listado de los procesos involucrados. Para detenerlos manualmente, ya sólo tenemos que hacer:

kill PID

Si quisiésemos ver los procesos de node:

ps aux | grep node
kill PID

Si esto no funciona, podemos probar con:

killall node

Desinstalando Cloud9

En caso de que Cloud9 no te guste, puedes borrarlo completamente, eliminando el directorio de instalación que nos creamos antes, de tu ~/.bashrc. En este tutorial es ~/c9, por tanto:

nano ~/.bashrc

Y eliminamos la siguiente linea:

export PATH=$HOME/c9/bin:$PATH

Después borramos las dependencias (opcional)

sudo apt-get remove build-essential g++ curl libssl-dev apache2-utils git libxml2-dev

Cambiar fácilmente de un proyecto a otro (opcional)

Por defecto, Cloud9 está preparado para trabajar con un único proyecto, o espacio de trabajo. Tengo muchos proyectos en sendos repositorios Git. Intenté meter cada uno en un directorio independiente, dentro de un mismo espacio de trabajo, pero no funcionó como debería. Lo puedes hacer, pero perderás la integración con Git.

La instalación de un único proyecto, tiene sentido en un servidor cloud, pero es un inconveniente cuando trabajas con una instalación local. De cualquier forma, es fácil cambiar de un proyecto a otro con un simple shell script. Lo primero que tienes que hacer es tener instalado Zenity:

sudo apt-get install zenity

Después editamos el script

nano gedit ~/c9/projectswitcher.sh

Añadimos el siguiente código y guardamos:

#!/bin/bash
PROJECT=$(zenity --file-selection --directory --title 'Select a Project Directory')

if test -d "${PROJECT}";then
  killall node
  nvm use 0.10.12 && cd ~/c9/cloud9 && bin/cloud9.sh -l 0.0.0.0 -p 3131 -w ${PROJECT} &
fi
exit

Le cambiamos los permisos para hacerlo ejecutable:

chmod +x ~/c9/projectswitcher.sh

Bibliografía

• Cloud9 en GitHub (oficial)
• ubuntuforums.org (obsoleto)
• samclarke.com (medio obsoleto)
• Blog jorgeivanmeza.com

Agradecimientos

Quiero agradecer especialmente a mi excompañero de trabajo: Víctor Gutiérrez, por haberme enseñado este estupendo IDE. Sin él, nunca lo habría descubierto!

Creando un entorno gratis en Amazon EC2 - introducción

Amazon nos ofrece la posibilidad de crear gratuitamente un entorno de desarrollo. ¿Esto qué significa? Pues que nos regala un servidor virtutal autoadministrado, un hosting para los que os suene a chino lo anterior, para nosotros solitos. Los recursos son bastante limitados, pero... a caballo regalado... Y tengo que reconocer que va más que bien para el precio que tiene :)

Esto supone que podemos ahorrarnos el instalar un WAMP en nuestro PC, y con pocos conocimientos de linux que veremos más adelante, poder acceder a nuestro entorno desde cualquier lugar con conexión a Internet, por FTP, o SSH. Otra ventaja, es que dichos recursos podremos ampliarlos según necesitemos, y es aquí donde tendremos que pagar. No os preocupéis, se pueden configurar alarmas, que me avisen de cuándo me estoy excediendo del plan gratuito (micro).

Como el tema es algo extenso, dividiré el post en varias entradas, las cuales trataré de resumir brevemente:

• ¿Cómo crear mi primera instancia micro EC2?
• ¿Cómo configurar el acceso a ella por FTP y SSH?
• ¿Cómo configurar alertas de precio? (Por si se me excedo de los recursos gratuitos)
• Introducción a los CloudFormation Stacks, o dicho en cristiano, entornos prefabricados: entornos llave en mano previamente configurados, como por ejemplo, un LAMP, o un WordPress, o un Joomla, o un Redmine, etc.
• ¿Cómo instalar por nuestra cuenta, en nuestro micro EC2: PHP, MySQL, phpmyadmin, node.js, ruby, etc.?
• ¿Cómo dar de alta una base de datos en una instancia RDS (Relational Database System), y conectarla con nuestra instancia micro EC2?
• ¿Cómo instalar un sistema de integración contínua? Git, SVN, Jenkins, etc.
• ¿Cómo conectar con repositorios externos? Bitbucket, GitHub, etc.
• ¿Cómo conectar nuestro EC2 con IDEs online, como Cloud9?

¡Hola mundo!

¡Hola mundo! La idea principal por la que me animo a abrir este blog, es compartir mis experiencias a medida que voy aprendiendo cosas sobre programación, especialmente de front-end, y configuración de entornos de trabajo, plugins, y herramientas varias que puedan ser útiles para ser más eficientes :)

Espero que os pueda ayudar de algún modo.