¿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!

Building a free develop enviroment at EC2 - Introduction

Amazon gives us the possibility of building a free develop enviroment. What does that means? They offer for us alone, a self-managed virtual server, or a hosting, for whom thinks i'm speaking double-Dutch. Resources are some limited, but never look a gift horse in the mouth! :)

That means we can save our time and increase our efficiency. You do not have to install a WAMP server on your local machine, and configure any software. Even with only a little knowledge of Linux commands, we will succeed in connecting throught SSH or FTP. Furthermore, Amazon does provide a framework on which you can build an application that will easily scale, but with care, or we will have to pay. But don't worry: they offers you track any charges. Amazon CloudWatch enables monitoring your estimated charges as well as allows you to set billing alerts for specified amounts, even 1$.

As the issue is a vast subject, thus, the first thing i'm going to do is to divide it in sections:

• 1) How to build my first (free) micro instance?
• 2) How to configure the FTP server? How to connect throught SSH with this micro instance?
• 3) How to track any charges? How to set billing alerts?
• 4) Introduction to CloudFormation Stacks, - to put it in plain language - preconfigured environments (LAMP width Wordpress, os Drupal, etc.)
• 5) How to install PHP, MySQL, phpmyadmin, node.js, etc. on our own?
• 6) How to launch a RDS Database Instance? How to connect with it from our micro instance?
• 7) How to install a continous integration system on our own? Git, SVN, Jenkins, etc.
• 8) How to connect with external repositories? BitBucket, GitHub, etc.
• 9) Hoy to connect with online IDE like Cloud9?

All these issues, will be written in subsequent post. Hope this helps you!

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?