Afortunadamente, Amazon lanzó EBS (Elastic Block Store), un servicio de almacenamiento persistente que nos permite montar un volumen de datos como unidad de almacenamiento sobre EC2.

Vamos a ver cómo aprovechar EBS para configurar una máquina en EC2 como servidor MySQL con almacenamiento persistente.

1. Reservar un volumen EBS

Lo primero de todo, es solicitar un nuevo volumen EBS para poder montarlo en nuestra instancia EC2.
Para ello, abrimos Elasticfox (que vimos en una entrada anterior) y accedemos a la sección "Volumes and Snapshots". La primera sección corresponde a los volúmenes (EBS) que tenemos reservados, y la segunda a los backups de esos volúmenes. Cada snapshot (backup) nos servirá para lanzar un nuevo volumen que incluya nuestros datos previamente salvados.
El procedimiento es de lo más sencillo. Simplemente hacemos click en el botón verde (+) de la sección "Volumes" y nos aparecerá un pequeño formulario para configurar nuestro nuevo volumen.

Definir el tamaño en GB del volumen: Esa será la cantidad máxima de datos que podrá almacenar nuestro nuevo volumen, por lo que es recomendable tener una idea de para qué vamos a utilizarlo antes de crearlo y así poder estimar el espacio que necesitaremos.
Elegir el snapshot a partir del cual queremos iniciar nuestro nuevo volumen: Para un nuevo volumen, simplemente dejamos este campo por defecto en "<none>"
Zona de disponibilidad: Este es uno de los puntos más importantes a la hora de crear nuestro volumen, ya que un volumen sólo puede ser accesible desde una instancia EC2 en la misma zona de disponibilidad. En caso de equivocarnos, o querer adjuntarlo a una nueva instancia en otra zona, podremos crear un snapshot, y a partir de él lanzar un nuevo volumen en otra zona.
Tag: Este campo es totalmente opcional y sirve para etiquetar nuestro nuevo volumen. Es bastante útil a la hora de manejar muchos volúmenes distintos y automatizar su gestión.

2. Adjuntar el volumen a una intancia

Ningún misterio. Simplemente hacemos click en el botón verde en forma de "tick" (o click derecho sobre el volumen y elegimos "Attach this volume"), y accederemos a un nuevo formulario en el que podremos elegir una de nuestras instancias disponibles en nuestra zona, y un campo donde definiremos el dispositivo desde el que queremos hacer disponible nuestro volumen. Como véis, Elasticfox nos avisa de que, para una máquina Linux, tenemos disponible cualquier dispositivo desde /dev/sda hasta /dev/sdp. Para este tutorial yo he elegido /dev/sdh. Por supuesto, podéis usar el que queráis (pero tenedlo en cuenta en los comandos y scripts que veamos).

3. Formatear y montar nuestra unidad

Una vez adjuntado el volumen a nuestra instancia a través del dispositivo /dev/sdh, lo formatearemos en ext3 para tener acceso a él como unidad de almacenamiento (vosotros lo formateáis con el sistema de archivos que más os guste ). Para ello ejecutamos

Creamos un nuevo directorio

Y montamos la unidad en él

4. Llevar MySQL a nuestro EBS

No voy a explicar cómo instalar MySQL en vuestra máquina, porque presuponemos que ese paso ya está superado. Aún así, si no sabes cómo, seguro que fácilmente encontrarás algún tutorial de cómo instalar MySQL en vuestra distro preferida (como éste para Ubuntu).
El procedimiento para mover MySQL a EBS es sencillo. Simplemente moveremos el directorio mysql a nuestra nueva unidad, y crearemos un enlace simbólico desde su directorio original. De ésta manera, los datos estarán físicamente en EBS y virtualmente en el directorio original de mysql.

Primero movemos los datos ejecutando (Es importante haber apagado el servicio de mysql antes de proceder)

Y creamos el enlace

(si vuestro mysql no está instalado en /var/lib/mysql, usais vuestro directorio)

Ya sólo nos queda volver a arrancar el servicio de mysql y volver a generar nuestro AMI para no perder los cambios.

5. Automatizar el montaje de nuestra unidad EBS

Como os imaginaréis, si lanzamos una nueva instancia de nuestra AMI, aunque tendrá creado el enlace simbólico en /var/lib, nuestro volumen EBS no estará montado en /mnt/ebs.
Para facilitaros un poco el trabajo, he creado un pequeño script de bash que "escucha" hasta que está disponible el dispositivo /dev/sdh , para crear el directorio /mnt/ebs y montar en él el dispositivo. Como es evidente, este script nos "obliga" a adjuntar siempre el volumen en /dev/sdh.

Para que el script se ejecute nada más encender nuestra instancia, podemos editar nuestro archivo /etc/rc.local y añadir el siguiente comando

Esto ejecutará el script en background en el momento de arrancar la máquina.

Después de esto, ya simplemente tendremos que levantar una nueva instancia y adjuntarle el volumen EBS que hemos creado, y tendremos nuestra máquina EC2 con servicio MySQL con almacenamiento de datos persistente.

Por supuesto, se podría automatizar el proceso de adjuntar el volumen a la nueva instancia, de manera que sólo tuviéramos que levantar una nueva instancia y listo. Pero para ello habría que trabajar con la API de EBS y eso es otra guerra. Quizás en un futuro hable de ello.

Espero que, aún así, lo visto en esta entrada os sea útil.

Un saludo !!

En esta nueva entrega, voy a contar los pasos a seguir para crear nuestro propio AMI a partir de la instancia que hayamos levantado, y almacenarla en nuestra cuenta de S3 para posteriormente lanzar nuevas instancias con ella.

¿Por qué me interesa crearme un AMI?

Lo primero de todo es entender por qué nos interesa crearnos un AMI y no utilizar AMIs ya generadas.
Una de las características de EC2, es que la única manera de levantar una instancia es a partir de un AMI. Esto quiere decir que si apagamos nuestra instancia o, por algún problema en Amazon, se apagara accidentalmente (a mí en dos años nunca me ha pasado, pero nunca se sabe...), o necesitamos de una instancia adicional para multiplicar nuestra capacidad de procesamiento, la única manera de levantarla es volviendo a utilizar un AMI.
Como es más que probale, las necesidades de nuestra aplicación requerirá que la instancia esté provista de determinado software o configuración, diferente a la que nos ofrece un sistema base. Por eso, tanto por seguridad (backup) como por escalabilidad, es imprescindible generar nuestra propia AMI.

Primer paso: Instalando el software necesario

Basándome en el anterior tutorial, supondremos que para levantar nuestra instancia utilizamos el AMI ami-bf5eb9d6 , una Ubuntu 9.04 base sin software adicional preinstalado.

Si usamos Ubuntu 9.04 es muy muy sencillo el proceso de creación de un AMI (de ahí mi recomendación), por lo que si no eres muy experto como administrador de sistemas Linux/Unix, y es la primera vez que te enfrentas al proceso de crear un AMI, piénsatelo dos veces antes de elegir otra distribución. Yo personalmente tuve muchísimos quebraderos de cabeza con otras distros como Fedora o Gentoo (módulos del kernel necesarios no instalados, repositorios desactualizados, librerías no instaladas, necesidad de compilar las aplicaciones, etc... )

Esto no quiere decir ni mucho menos, que sólo se pueda utilizar Ubuntu. De hecho hay muchísima gente que utiliza Fedora en EC2. Todo depende de tus necesidades, de tu nivel de conocimientos, y del tiempo que quieras/puedas dedicarle a preparar tu instancia antes de generar un AMI. Lo que si te puedo asegurar es que esta es la forma más sencilla, rápida y cómoda para hacerlo. Sobre todo si te estás iniciando en EC2.

Para generar nuestro AMI necesitaremos la herramienta oficial de Amazon ec2-ami-tools, que nos permitirá tanto generar el AMI como subirlo a nuestra cuenta de S3.

En Ubuntu 9.04 tendremos que tener activados los repositorios Multiverse (fijate que en el link explica cómo activar los repositorios universe y multiverse para hardy, y la 9.04 es jaunty). Es probable que si elegiste el AMI que yo propongo para levantar la primera instancia, los repositorios multiverse ya vengan activados, pero no está de más asegurarse.
Una vez hecho esto, simplemente ejecuta por consola y ya tendremos instalado el EC2 AMI Tools

Si has preferido utilizar como base otra distro de Linux distinta a Ubuntu, también puedes descargar EC2 AMI Tools en .rpm, y si tu distro no soporta rpm, puedes tratar de convertirlo con algún conversor de paquetes. Si usas una versión antigua de Ubuntu, puedes utilizar Alien para crear tu .deb

Segundo Paso: Obteniendo los Certificados X.509

Cuando creamos un AMI, esta pasa a pertenecer al usuario AWS que la creó, certificadas internamente por certificados X.509 que autentican la pertenencia al usuario en el momento de intentar instanciarlas.

Lo primero que tenemos que hacer es acceder a nuestro perfil de AWS en la sección Access Identifiers. Allí encontremos una sección llamada X.509 donde podremos pedir a Amazon que nos genere nuestro certificado ("Create New").

Si ya habías creado un certificado anteriormente, nos avisará de que sólamente podemos tener un único certificado por cuenta, por lo que si continuamos el anterior certificado quedará inservible.

Inmediatamente llegaremos a una página donde podemos descargar dos archivos .pem. El primero es el archivo de Clave Privada, y el segundo el Certificado X.509

Amazon lo avisa en ésta misma página, pero yo vuelvo a insistir : Guarda en un lugar seguro el archivo de clave Privada !!
El Certificado lo podrás descargar nuevamente si lo pierdes, pero el archivo de Clave Privada no. Tendrás que generar uno nuevo, y no es algo que te recomiendo. Como comenté, el certificado (y por ende, la clave privada) se utilizan para autenticar la pertenencia de cada AMI. Como podrás imaginar, si generas un AMI con un certificado y lo pierdes, al generar un nuevo certificado tu cuenta de AWS quedará asociada a éste nuevo, por lo que el AMI generada será como si no fuera tuya. Aunque esté alojada en tu propia cuenta de S3. Avisado quedas !

El siguiente paso será subir los dos archivos .pem a nuestra instancia.

¿Cómo?

Pues como más cómodo te resulte...
Si tienes una consola Unix puedes ejecutar
scp <private_keyfile> <certificate_file> root@<dns_location>:/mnt

Donde <private_keyfile> <certificate_file> sean las rutas de tus dos archivos .pem

Yo personalmente prefiero usar un cliente scp/sftp con GUI. En MAC OSX uso Transmit (29.95 $), y en Windows usaba WinSCP (gratuito).
Pero ya es cuestión de gustos.

Tercer Paso: Generando nuestro AMI

Ya tenemos todo lo necesario para generar el AMI. Para facilitar el trabajo y no tener que escribir el mismo comando cada vez que queramos regenerar el AMI, os pongo adjunto (al final del post), dos scripts sh que harán el trabajo sucio por tí : ec-bundle.sh (para generar el AMI) y ec-upload.sh (para subir el AMI a tu cuenta de S3)

Simplemente tienes que editarlo para incluir los datos de tu cuenta, y dejarlos alojados en un directorio que se incluyan en el AMI (yo dejo los mios en /root que es el directorio que accedo por defecto al entrar por ssh).

Para empezar editamos ec-bundle.sh, que incluye la siguiente linea de código:

El primer grupo de "*", como podréis intuir, corresponde a la ruta del archivo de clave privada (el que empieza por pk-). El segundo es la ruta al archivo de certificado (el que empieza por cert-), y el último grupo corresponde a tu identificador de usuario EC2. Si no sabes cuál es tu identificador de usuario, simplemente abre tu Elasticfox (con el que levantamos la instancia en el tutorial anterior), y en la pestaña Instances, haz click derecho sobre tu instancia y entra en View Details. Ahí encontraremos un campo llamado Owner ID. Ese es nuestro identificador de usuario !!

Una vez guardados los cambios, ya podemos ejecutar el script escribiendo

Deberíais obtener algo parecidoa a :

Si es así , es que todo ha ido bien y ya tenemos nuestra AMI creada. Si te fijas, hay un listado de directorios que son omitidos a la hora de generar el AMI, por lo que procura que tu aplicación no incluya ninguno de esos directorios o ficheros. Si por algún casual la lista de directorios excluidos por defecto no satisficiera tus necesidades, consulta la documentación de ec-bundle-vol para especificar otra lista de directorios o fichero a excluir.

Quinto Paso: Subir nuestro AMI personalizado a S3

Ya sólo nos queda modificar ec-upload.sh con nuestros datos de acceso a S3. Si lo editas verás la linea

El primer grupo de "*" corresponde a tu Access Key Id, y el segundo a tu Secret Access Key. Ambas las puedes encontrar en tu perfil de usuario AWS en la sección Access Identifiers. El parametro siguiente al modificador -b corresponde al nombre del bucket de nuestra cuenta S3 donde queremos almacenar el AMI.
Te habrás fijado que como nombre del bucket he puesto $1. Si no estás familiarizado con el Shell Scripting, simplemente tienes que saber que esa es la forma de acceder al primer parámetro que le hayamos pasado al ejecutar el script. Esto lo he dejado así porque es probable que cada vez que quieras rehacer el AMI lo quieras guardar en un bucket distinto (para guardar de forma incremental el ami en buckets que incluyan la fecha  de generación por ejemplo).

De ésta manera, simplemente ejecutaríamos

Y comenzaría el proceso de upload.
Si lo que quisieramos es guardar siempre el AMI en el mismo bucket, simplemente sustituye "$1" por el nombre del bucket y listo.

Nota: ec2-upload-bundle genera el bucket en S3 si no existe, por lo que no es imprescindible crear el bucket previamente para subir nuestro AMI

Sexto y último Paso: Registrar nuestro AMI

Como habrás podido comprobar al lanzar una instancia, siempre se hace utilizando un id de ami. Esto es porque Amazon tiene una base de datos de todas las AMIs generadas y listas para instanciar, lo que nos obliga a registrar nuestro AMI recién creado para que nos asignen un id.

Para ello simplemente abrimos Elasticfox, y nos vamos a la sección de Images. Allí encontrarás un botón de "Registe AMI". Hacemos click en él y nos preguntará el AMI Manifest Path.

Siemplemente tenemos que poner : nombre-de-nuestro-bucket/image.manifest.xml

En unos pocos segundos veremos como una nueva AMI aparece en nuestra lista de AMIs disponibles, con su nuevo id asignado. Para encontrarla en un futuro podemos apuntarnos su id y utilizarlo, buscarla por el nombre del bucket, o simplemente ordenar por Visibility y aparecerá entre las "private".

Comentarios Finales...

Ya tenemos lista nuestra propia AMI !
Simplemente añadir que cuando registramos un AMI, Amazon asocia el id generado con la ruta del Manifest (el archivo .xml que se genera junto a nuestra AMI). Si queremos rehacer nuestro AMI para incluir nuevos cambios en nuestra aplicación, y lo guardamos en el mismo bucket, sin modificar el nombre del Manifest, no será necesario volver a registrar el AMI.

Bueno, espero que os haya sido útil y os haya gustado

Cualquier comentario, crítica o alguna cosilla más que queráis que añada, no dudéis en avisarme.

Un Saludo !!

Scripts Adjuntos:

ec-ubundle
ec-upload

En éste pequeño tutorial voy a exponer los primeros pasos que hay que dar para utilizar EC2, y algunos consejos basados en mi experiencia en éste proceso.

El funcionamiento es muy sencillo.
Una vez hayamos creado nuestra cuenta de EC2 , tendremos a nuestra disposición un enorme catálogo de AMIs (Amazon Machine Image), que no son otra cosa que imágenes pregeneradas de distintos sistemas operativos, con las que levantar nuestra instancia de procesado EC2.
Existen dos tipos de AMI's :

- Públicas: Disponibles para cualquier usuario de forma gratuita y puestas a disposición tanto por Amazon, como por otros usuarios que deseen comprartir su propia AMI con el resto de la comunidad
- Privadas: Que solo estarán disponibles para el propietario de esta AMI, o para el resto de la comunidad, previo pago, en el caso de que el usuario haya configurado el servicio de AMIs de pago.

Lo normal cuando trabajemos con EC2, es que nos creemos nuestra propia AMI privada con todas las aplicaciones que necesitemos en nuestras tareas, para así poder levantar instancias de ésta en cualquier momento.

Ya tengo mi cuenta creada ¿ Ahora qué ?

Amazón pone a disposición una API con la que interactuar para todas las acciones relacionadas con EC2. Con ésta API puedes solicitar una instancia, apagar las que ya tienes levantadas, etc...
Todo ésto nos requeriría un gran trabajo en desarrollo para crearnos nuestra propia interfaz para interactuar con la API de EC2, lo que no es muy grato si lo que quieres es probar el servicio.

Afortunadamente, existen alguna herramientas desarrolladas por Amazon que nos facilitarán todo el trabajo de interacción con las APIs de EC2. (ojalá hubieran existido cuando yo empecé a trabajar con EC2 ...)

Una de ellas (la que yo utilizo y con la que guiaré este tutorial) es Elasticfox, una extensión para firefox que incorpora en tu navegador todas las funciones necesarias para administrar tu cuenta de EC2. Yo repasaré las funciones básicas en este tutorial, pero si quieres información más detallada y extendida, consulta la guía oficial.

Otra herramienta de muy reciente aparición es AWS Managment Console. Una completa consola de administración de EC2 y otros servicios de AWS (de momento sólo Elastic MapReduce) vía web.

Primer Paso: Autenticación

En nuestro perfil de AWS podemos encontrar nuestras claves de acceso a AWS: el Access Key ID , y el Secret Access Key. Ambas necesarias para todas nuestras autenticaciones.

Una vez hayamos instalado Elasticfox, creamos un perfil introduciendo nuestras dos claves de AWS.
La autenticación para acceder a una instancia de EC2, no se realiza con un usuario y contraseña, sino con un archivo de claves privada RSA. Si no tienes experiencia con éste tipo de autenticaciones, no te preocupes, porque es muy sencillo.

Lo primero que tenemos que hacer es generar nuestro archivo de clave privada. Para ello, simplemente vamos a la pestaña Keypairs de Elasticfox y hacemos click en el botón verde de "Create new keypair". Elasticfox nos pedirá un nombre para el nuevo keypair. Podéis usar el que más os guste. Yo en mi caso la he llamado "fillito-keypair".
En cuanto aceptemos el nombre, nuestro navegador tratará de descargar el archivo keypair, que debería tener como nombre "id-nombre-de-vuestro-keypair".

Nota : Es muy importante guardar a buen recaudo éste archivo, ya que si lo perdemos, perderemos el acceso a todas las instancias que hayamos levantado usando este keypair.

Segundo Paso: Security Groups

El siguiente paso es el de crear un security group, o modificar el que viene creado por defecto. Un security group, es un conjunto de reglas de acceso a nuestra instancia. En él definimos los puertos a los que queremos permitir acceso, desde qué máquinas , etc...  Algo así como un firewall, pero más sencillo.

Si quieres definir una regla para cualquier máquina externa a la instancia (servicios ssh, web, ftp ... ) tendrás que poner 0.0.0.0/0 en el campo Host.

Tercer Paso: Elegir un AMI para lanzar nuestra instancia

Ya sólo nos queda elegir el AMI que queremos lanzar para nuestra nueva instancia.

Como ya comenté, tienes un amplio catálogo de AMIs entre las que se incluyen imágenes Linux (Fedora, Ubuntu, Gentoo,... ) o Windows, tanto e arquitectura i386 como x64. Incluso encontraremos imágenes con software precargado y preconfigurado.

Yo personalmente prefiero usar una Ubuntu limpia para poder instalar mis aplicaciones. Últimamente estoy usando una Ubuntu 9.04.

La elección del AMI es uno de los puntos más sensibles de todo el proceso, ya que elegir una mala distribución nos puede traer problemas en el futuro por no tener determinados paquetes disponibles.

Después de muchas pruebas, muchos dolores de cabeza, y muchos problemas que me llevaron más de 2 o 3 días solucionar, he encontrado la que para mí es el AMI más compatible con mis necesidades. Su id , por si queréis empezar a trabajar con ella es ami-bf5eb9d6, y fué generada por Alestic, un grupo que genera imágenes públicas gratuitas de Ubuntu para EC2. Podéis probar a lanzar cualquiera de sus otras AMIs, pero os recomiendo encarecidamente que lancéis Ubuntu Server si no queréis tener problemas a la hora de generar vuestra propia AMI basada en éstas.

Para lanzar una instancia del AMI que hayamos elegido, simplemente nos vamos a la pestaña Images de Elasticfox, introducimos el id del AMI en el buscador de AMIs (o seleccionamos de la lista inferior). Una vez tengamos localizada el AMI que queremos, la seleccionamos y hacemos click en el botón verde "Launch Instance(s)" y nos aparecerá la ventana que vemos en la captura.

Si os fijáis, aquí tendremos que seleccionar el Keypair y el Security Group con el que queremos lanzar la instancia.

Dependiendo de dónde esté alojada el AMI, podremos lanzar la instancia en una u otra Availability Zone (USA o Europe). Yo he dejado seleccionado <any> para que escoja él mismo cualquiera de las zonas disponibles (en éste caso, el AMI está en USA, por lo que las instancias estarán en USA). Existe la posibilidad de traspasar un AMI de una zona a otra, para poder lanzar instancias en otra zona. Pero eso ya lo explicaré en otro tutorial

Unos pocos segundos después de hacer click en Launch, ya tendremos disponible nuestra instancia para poder acceder a ella.

Cuando nuestra instancia haya cambiado su status a "running", ya estará lista para acceder a ella.

Para ello simplemente hacemos click derecho sobre la instancia, y seleccionamos "Copy Public DNS Name to clipboard", para obtener el nombre de dominio que se nos ha asignado y así poder acceder por ssh.

¿ Cómo hago para acceder por ssh, intento acceder y me da Access Denied ?

Si has intentado acceder vía ssh y no has podido, lo más probable es que no estés accediendo usando la keypair para autenticarte.

Lo normal, es que el usuario de acceso sea root (lo suele especificar la documentación que hay publicado el que creó la instancia).  Como estamos usando una clave privada para acceder, no tenemos que usar  ningún password.

Accediendo con clave privada desde Windows

La mejor forma de acceder con clave privada por ssh, es usando Putty. Tenéis que fijaros que Putty no utiliza el RSA que nos ha generado Amazon, sino que utiliza un archivo propio de claves (.ppk). En la propia página de descarga de Putty, podéis encontrar una aplicación llamada puttygen, con la que crear un .ppk a partir de vuestro archivo keypair.

Aquí podéis ver los pasos necesarios para generar vuestro ppk y crear una conexión que la use.

Accediendo con clave privada desde MAC OSX

Yo no he encontrado ningún programa que me permita acceder por ssh usando clave privada, así que la mejor manera es la de instalar la propia clave en un gestor de claves ssh. Yo uso SSHKeychain, que es gratuito.

Para añadir nuestro archivo, simplemente vamos al apartado SSH Keys del programa, hacemos click en el "+", y añadimos nuestro archivo.

Esto habilitará de forma global en nuestra máquina el keypair , para que podamos acceder utilizando cualquier programa sin tener que especificarle dónde está situado el archivo.
Si abres una consola de terminal, puedes acceder a la instancia simplemente escribiendo ssh root@dns-name-de-nuestra-instancia

Próximamente más...

En breve publicaré una nueva entrega, explicando paso a paso cómo crear tu propia AMI, con todo el software y configuraciónes que hayamos hecho, desde una instancia que ya hayamos levantado.

Espero que sea útil.

Un saludo !!

Esta tarde hemos recibido la visita de dos miembros del equipo de Abiquo, que nos venían a contar un poco sobre su proyecto.
Hasta hace unas semanas, que recibimos información sobre ellos y charlamos sobre la posibilidad de conocernos, no conocía su proyecto, y la verdad es que nos hemos quedados totalmente maravillados.

Para el que no conozca Abiquo, se trata de una plataforma destinada a facilitar la gestión y configuración de entornos de Cloud Computing. Entre sus muchas posibilidades, nos ofrece la posibilidad de montar nuestro propio Cloud Computing con nuestras máquinas basandonos en sistemas de virtualización, y tener conexiones con otros servicios de Cloud Computing (como Amazon Web Services) y/o data centers, que nos permita contar con sistemas de alta disponibilidad, muy muy fácilmente escalables.
En resumidas cuentas: Si nuestras máquinas se quedan cortas por un inesperado pico de tráfico o de carga, nuestro sistema podrá levantar de forma transparente y automatizada nuevas máquinas usando servicios de Cloud Computing externos, para posteriormente reestablecer la configuración original pasada la tormenta.

Nos impresionó la aparente (aún no he tenido ocasión de probarla) fácilidad de uso de la interfaz de gestión, y la sencillez y comodidad que supone a la hora de escalar nuestros sistemas.

Otra de sus grandes bazas, es que es un proyecto que ha sido liberado como Open Source, por lo que podéis probarlo gratuitamente y jugar tanto como queráis con él.

Como dato curioso de la reunión, y que me hizo especial ilusión al enterarme cuando ya nos despedíamos. Es que junto a Helena Torras (Partner & Interim Manager de Abiquo),  vino Diego Parrilla (Business Development Manager and Technology Strategist de Abiquo),  que es fundador de nubeblog. Un gran blog  sobre Cloud Computing que sigo hace bastante.

Espero poder probar pronto su plataforma y comprobar todas sus ventajas

Voy a explicar cómo, con un sencillo script en php conseguiremos que nuestros archivos de S3 estén totalmente protegidos y que sólo puedan ser accesibles desde nuestro dominio.

Lo primero de todo, es conocer dos características que Amazon nos prové con sus APIs:
- Los ACL (Access Control List) : que nos permite definir los permisos de lectura-escritura-ejecución de nuestros bucket y objetos.
- Las URLs Firmadas : que nos permite acceder temporalmente a nuestros archivos protegidos, a través de una url que incluye una firma y un tiempo de expiración de los permisos. Éstas URLs las podremos generar con nuestro script, y llevarán como parámetro nuestra firma generada en tiempo de ejecución, que lleva implicita el tiempo de caducidad de la url.

La primera medida es aplicar permisos exclusivo de lectura para nuestro usuario (usando los ACLs) a todos los archivos que queramos proteger, para que sea imprescindible una validación al acceder a ellos.
Para generar nuestro script , necesitaremos echar mano de la clase Crypt/HMAC para construir el hash en sha1 que Amazon S3 requiere.
Lo primero será crear nuestra función para  generar nuestra firma:

Lo siguiente, será crearnos una función para construir nuestra URL firmada :

Ésta función nos devolverá la url firmada, que estará disponible durante el tiempo (en segundos) que hayamos establecido en el parametro $expires (120seg por defecto)

Ahora ya sólamente nos falta un script que nos lance al contenido, pero que nos proteja de links externos a nuestro dominio.
Para ésto simplemente comprobaremos si existe el campo HTTP_REFERER en nuestra variable $_SERVER , que nos indicará que estamos accediendo a ésta url desde otra url de referencia , y que nuestro dominio (extraido desde $_SERVER['HTTP_HOST']) esté contenido en él.

Al llamar a ésta función, seremos automáticamente redirigidos al contenido en amazon siempre que el link provenga desde nuestro mismo dominio. Por supuesto, si quisieramos permitir el acceso desde una determinada lista de dominios, simplemente tendríamos que modificar un poco la condición if , para que compruebe que cada uno de los dominios están incluido en el HTTP_REFERER.

Espero que sea útil.
Un Saludo !!

Dos de los inconvenientes más grandes del servicio de procesamiento EC2 eran que al arrancar una instancia de procesado, ésta no disponía de una IP (sino que accedíamos a ella a través de un nombre de domino), y que al apagarla, toda la información que no formara parte de la imagen que instanciamos se volatilizaba. Esto era un problema grande, ya que en caso de un fallo en el servicio y caida perderíamos toda la información de la instancia, y hacía EC2 un servicio totalmente inútil si lo que buscamos es montar por ejemplo un servidor de bases de datos.
Todo ésto queda solventado con EBS, que nos permite instanciar múltiples bloques de entre 1GB y 1TB de almacenamiento que pueden ser montados como un dispositivo en nuestro sistema operativo. Cada bloque instanciado se monta como una unidad RAW sin formato, por lo que serán perfectamente compatible con cualquier sistema operativo que estemos usando en nuestra instancia y formatearla con el sistema de gestión de ficheros que mejor nos venga.
Además Amazon asegura la replicación automática de los datos dentro de la "Zona de Disponibilidad" de nuestra instancia, lo que garantiza la preservación de nuestros datos en caso de fallo hardware en las máquinas.
Otra de las características que me ha sorprendido gratamente es que cada bloque de datos es autónomo e independiente de la instancia, lo que los hace accesible desde cualquiera de nuestras intancias (aunque sólo a una de ellas al mismo tiempo).

En cuanto a los costes, Amazon mantiene su política de varios criterios de tarificación según transferencia, accesos y datos almacenados. Aunque como dato orientativo el almacenamiento nos costará 0,10$/GB cada mes.

Una gran mejora para EC2 que lo hace aún más útil. Esperemos que Amazon siga con el ritmo de mejoras para sus servicios, que están revolucionando el desarrollo web y facilitando que pequeños proyectos puedan crecer y crear grandes aplicaciones con unos costes más que asequibles.

Y vaya sitio... para el que no conozca Maestros del Web, es la comunidad de desarrolladores web de habla hispana más importante del mundo.

Aquí podeis leer el artículo sobre S3 de Amazon . Se aceptan críticas y todo tipo de comentarios.

Gracias desde aquí a Christian y a todo su equipo por la oportunidad.