Crea tu propio AMI basado en Ubuntu, para EC2

En el anterior post explicaba los primeros pasos EC2 donde explicaba todo el proceso desde que nos creamos una cuenta AWS para EC2 , hasta que teníamos nuestra instancia levantada y con con acceso ssh.

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