Posts Tagged Amazon
Google Storage for developers planta cara a Amazon S3
Posted by Xavi in General, Programación Web on 20/05/2010
Corrían rumores de que Google podía presentar una alternativa al servicio de almaceniamiento de Amazon, pero eran muy pocos los que creían que esto realmente podía pasar (me incluyo en el grupo de los incrédulos). Y Google anunció ayer en el Google I/O la disponibilidad de Google Storage for developers, un servicio de almacenamiento on-line con unas características muy parecidas a Amazon S3. Vamos a ver algunas de sus características:
- Almacenamiento por buckets/objetos: Exactamente igual que su vecino de Amazon.
- Nombre único del bucket en todo el servicio: Igual.
- Ausencia de carpetas o jerarquía pero capacidad de introducir el caracter “/” en el nombre del archivo para simular un árbol de directorios: Igual.
- Privacidad de los objetos 100% y inmutabilidad de los objetos: No recuerdo que Amazon detallara el punto de la privacidad (no estoy seguro), pero en cuanto a la inmutabilidad siguen siendo servicios equivalentes (hace falta reescribir el objeto para modificarlo).
A estas características básicas vamos a añadir un listado de las operaciones básicas. Veremos que siguen cortadas por el mismo patron que S3:
- Crear y eliminar buckets
- Listar buckets y objetos
- Subir y descargar objetos
- Eliminar objetos
- Definir listas de control de acceso (ACL) para los objetos
- Definir metadatos de los objetos
Y una serie de características adicionales, algunas de las cuales sí que marcan alguna diferencia con Amazon:
- Autenticación basada en cookies (no recuerdo que esto este disponible en S3 pero no estoy seguro de ello).
- Soporte a las cuentas de Google para establecer el nivel de seguridad de los objetos.
- Es necesaria una Developer Key (un par de clave de acceso y clave secreta).
- API REST (no existe una API SOAP y no parece que entre en los planes de Google).
- Soporte para SSL.
- Herramientas por linea de comandos y librería basadas en Python (Boto).
- Aplicación web para gestionar buckets y objetos (!!!).
La lista de precios también sigue el mismo patrón que Amazon pero se ofrece una cuota inicial gratuita (“solo” 100 GB de almacenamiento y 300 GB de transferencia al mes). Los precios son los siguientes:
- Almacenamiento: 0’17 US$/GB al mes
- Transferencia (subida): 0’10 US$/GB
- Transferencia (descarga): 0’15 US$/GB en América y EMEA y 0’30 US$/GB en APAC
- Peticiones (PUT,POST,LIST): 0’10 US$/1.000 peticiones
- Peticiones (GET,HEAD): 0’10 US$/10.000 peticiones
¿La mala noticia? Disponible para desarrolladores en los U.S. y con cola de admisión… espero que no tarden lo mismo que Amazon en traer los servicios a Europa!!
Amazon S3 amplia su abanico de posibilidades (RRS)
Posted by Xavi in Programación Web on 19/05/2010
Amazon S3 es un servicio de almacenamiento de objetos que fue definido por Amazon como “highly durable” pero nunca habían aportado datos ni estadísticas relacionadas con la durabilidad de los objetos que se almacenaban. Hoy, para anunciar una ampliación del abanico de posibilidades que ofrece el servicio han dado los primeros datos.
Amazon Web Services publica en su blog que la durabilidad de un archivo en su servicio de almacenamiento es del 99’9999999% (7 nueves) o, como exponen en el auncio, que de cada 10.000 objetos que almacenemos puede perderse uno (de media) cada 10 millones de años. Esta persistencia de ficheros en S3 la podemos considerar como muy alta… mucho más de lo que un gran número de aplicaciones necesitan realmente.
En ocasiones, todos los datos volcados en Amazon tienen su respaldo en máquinas que están más cerca del equipo responsable y simplemente se alojan en Amazon para su difusión por Internet (y su posible reposición está más que asegurada). En estos casos, esforzarse para mantener un porcentaje tan alto de durabilidad es un derroche de recursos que el cliente final no tiene porqué pagar.
¡Dicho y hecho!
A partir de hoy mismo, Amazon pone a disposición de los clientes la opción de reducir la durabilidad de sus archivos a 99’9999% (4 nueves) a cambio de una reducción en el precio del almacenamiento. Esta reducción va asociada a un parámetro que debe definirse de forma explícita (por defecto la durabilidad seguirá como antes) y es de un 33% del precio original. En el intervalo más caro (hasta 50 TB al mes), el almacenamiento “normal” cuesta 0’15€/mes por GB y el nuevo almacenamiento 0’10€/mes por GB.
Lo encontrareis en la página de S3 así como en el artículo del que he leído esta información, pero el nuevo sistema de almacenamiento se llama Reduced Redundancy Storage o RRS para los amigos.
Amazon AWS anuncia la afinidad de servidores en Elastic Load Balancing
Posted by Xavi in Programación Web on 08/04/2010
Uno de los problemas más importantes que existían para desarrollar aplicaciones web en las infraestructuras de Amazon era la falta de un balanceador de carga que presentara afinidad de servidores. Ésto representaba un problema muy grave para la creación de aplicaciones ya que, hoy en dia, se almacenan datos en variables de sesión para facilitar la navegación de los usuarios. Con un servidor único para la aplicación no existe tal problema porqué las variables de sesión siempre están disponibles, pero con diferentes servidores y un balanceador de carga se corre el riesgo de que diferentes peticiones de páginas web se sirvan desde diferentes servidores y las preferencias de los usuarios se pierdan.
Antes, Amazon tenía un balanceador de carga que derivaba las peticiones a diferentes servidores pero no servía para aplicaciones complejas, ya que no se podía configurar para que enviara todas las peticiones de un mismo cliente (navegador web) a un mismo servidor.
A través del blog de Amazon AWS se acaba de anunciar la disponiblidad de la afinidad de servidores en su balanceador de carga Elastic Load Balancer. Esta funcionalidad puede solucionar el problema que comentábamos al principio y facilitar la puesta en marcha de muchas aplicaciones en un entorno de altas prestaciones. Sin duda se trata de una gran notícia para muchos desarrolladores!!
Se puede consultar el post original de Amazon AWS aquí y la documentación aquí.
Amazon RDS – La nube de datos relacional*
Posted by Xavi in Bases de datos, Programación Web on 03/11/2009
Hace tiempo que trabajábamos buscando soluciones al problema de migrar aplicaciones que utilizan una base de datos relacional “clásica” a un entorno de cloud computing (más concretamente a Amazon EC2). Este problema nos llevó a interesantes estudios sobre el clúster y la replicación master-slave de MySQL hasta encontrar una solución bastante aceptable con esta última. Y después de todo este trabajo… va Amazon y lo resuelve con un nuevo servicio llamado Amazon RDS (Relational Database Service).
En pocas palabras, RDS viene a ser una puerta de acceso a una base de datos MySQL Server (de momento la versión 5.1 con InnoDB como motor principal) que corre encima de los servidores de Amazon Web Services. Amazon te proporciona una interfaz idéntica a la que utilizarías con un servidor dedicado a la base de datos pero no preguntes como funciona por debajo, no te preocupes por las actualizaciones de seguridad, no intentes acceder como si fuera un servidor normal y corriente… sólo utilízalo y disfrútalo!
Amazon RDS viene a completar la oferta de sistemas de bases de datos con SimpleDB (una base de datos muy simple para aplicaciones con una baja complejidad de datos) y Amazon EC2 Relational Database AMIs (una selección de AMIs con diferentes software de bases de datos preeinstalados).
Para interactuar con Amazon RDS, como con casi todos los servicios de AWS, tenemos la posibilidad de realizar llamadas a la API directamente o descargarnos las herramientas por linea de comandos (en mi opinión la mejor opción).
Para instalar las herramientas por linea de comandos podemos seguir los siguientes pasos:
- Descargamos las RDS Command Line Tools de la página oficial de Amazon
- Seteamos las variables JAVA_HOME y AWS_RDS_HOME necesarias en /etc/enviroment. Las linias que tendríamos que añadir son las siguientes
AWS_RDS_HOME="/path/a/la/carpeta/commandlinetools"
JAVA_HOME="/path/a/java"
En mi caso el “/path/a/java” es “/usr/lib/jvm/java-6-sun/” y si utilizas Ubuntu no creo que sea muy diferente
- El siguiente paso es añadir en el PATH del sistema el directorio /bin de las herramientas que hemos descargado. Para hacer esto, dentro del mismo archivo /etc/enviroment, añadiremos :$AWS_RDS_HOME/bin antes de las dobles comillas que cierran la expressión PATH=”blabla:/blabla:/blabla” para que quede de la forma PATH=”blabla:/blabla:/blabla:$AWS_RDS_HOME/bin”.
- Lo siguiente es abrir el archivo credential-file-path.template que encontraremos en la raíz del directorio de las herramientas y introducir nuestros datos de acceso a la cuenta de AWS.
- Una vez introducidas nuestras credenciales añadiremos la situación de este archivo en /etc/enviroment también:
AWS_CREDENTIAL_FILE="/path/a/credential-file-path.template"
Si queremos podemos modificar el nombre del fichero y moverlo a la localización que más nos guste, mientras mantengamos la informatcion de /etc/enviroment actualizada. - Una vez tengamos todo ésto solo queda reiniciar el ordenador para cargar todas estas variables y ya estaremos listos para empezar a jugar con Amazon RDS!
Me gustaría descubrir un método para recargar las variables de /etc/enviroment en caliente pero de momento los métodos que he encontrado no han acabado de funcionar correctamente, si tienes alguna sugerencia déjala en los comentarios 
Bueno ahora viene la mala noticia… Amazon RDS de momento solo está disponible para Estados Unidos… Pero prometen tenerlo disponible para Europa en los próximos meses, veremos que tardan.
Os dejo un post del blog de Amazon Web Services en el que se introduce Amazon RDS enlace.
*No me agredais física ni intelectualmente por el juego de palabras!!
S3 Firefox Organizer, un cliente gráfico gratuito para Amazon S3
Posted by Xavi in Programación Web on 11/05/2009
Amazon S3 es un sistema de almacenamiento de datos on-line muy completo en cuanto a funcionalidades. Las diferentes possibilidades que tenemos para acceder a estas funcionalidades desde los lenguajes de programación mayoritarios hacen de él un gran producto para albergar los datos multimedia de una aplicación web. No obstante, mientras realizamos pruebas, es possible que nos haga falta un cliente gráfico para confirmar que las operaciones que han realizado nuestras aplicaciones son las que pretendiamos.
Cuando empecé a trabajar con S3, recurrí a BucketExplorer. Este programa ofrece casi todas las funcionalidades que podríamos pedir de un cliente gráfico pero el hecho de estar programado en Java ofrece una ejecución multiplataforma pero también una ejecución bastante lenta. Su funcionamiento es muy correcto y cumple los requisitos demandados para mis tareas, pero encontrarme un par de “buckets” en mi cuenta de Amazon S3 (que yo no había creado) con su nombre me hizo desconfiar y lo eliminé de mi directorio de programas.
Hasta hace unas horas no tenía ningún cliente gráfico de S3 en mi sistema hasta que me he tropezado con S3 Firefox Organizer, un add-on para Firefox que nos brinda todas las funcionalidades necesarias para gestionar diversas cuentas de S3. Este plugin recuerda sin ninguna duda a FireFTP, un cliente FTP accesible desde las pestañas de Firefox.
Logo FireFTP
Si quereis probar S3 Firefox Organizer sólo teneis que ir al directorio oficial de plugins del navegador y buscarlo, la verdad es que a mi me ha sorprendido agradablemente y creo que me quedaré con el durante un buen tiempo.
Espero que os guste y me conteis que tal vuestra experiencia con él.
Amazon premia la planificación
Posted by Xavi in Programación Web on 16/03/2009
Nos lo avanzaba Santi el sábado por la mañana en su post (a mi a las ocho menos cuarto por mail, que afortunado me siento!). Amazon a abierto una fórmula de contratación para instancias de EC2 alternativa al pago por uso que existía hasta ahora (que sigue estando disponible).
La nueva fórmula premia los clientes que hagan una buena planificación del consumo de recursos que van a realizar. Así, siempre que tengamos activa una instancia más de 143 días al año (24 horas al dia) nos va a salir a cuenta esta nueva fórmula de pago por avanzado. El sistema se basa en una cuota fija por uno o tres años y un precio mucho más reducido por uso (horas de instancia activa).
Este ahorro, que puede parecer un poco escaso a primera vista, es muy significativo en máquinas de altas prestaciones que debamos tener activas 24/7 todos los días del año. Veamos un ejemplo:
- Las instancias del tipo High-CPU Extra Large Tienen un coste de 0.80 $/hora (para Unix/Linux) en la antigua fórmula de contratación. Con estos datos el coste anual de esta máquina si nunca la detuviéramos sería de:
0.80 $/h * 24 h/dia * 365 dias/año = 7,008 $/año - En el nuevo sistema de pago estas instancias tienen un coste de 0.24 $/hora y una cuota anual de 2,600 $. Con estos datos el coste de esta máquina sería el siguiente:
0.24 $/h * 24h/dia * 365 dias/año + 2,600 $/año = 4,702.4 $/año
Podemos discutir si esta nueva fórmula es adecuada o no para partes del sistema que requieran una flexibilidad mayor en cuanto a número de instancias activas, pero un 33% de ahorro para máquinas “estáticas” es una buena noticia, Sin duda.
Añadir un slave a un entorno de replicación MySQL
Posted by Xavi in Bases de datos, Linux on 16/03/2009
Siguiendo el hilo de los artículos de Laura Berdasco sobre levantar un entorno de replicación Master-Slave en MySQL, Vamos a explicar como añadir un esclavo más a un entorno de este tipo funcionando.
Estos pasos se han realizado en instancias de EC2 con acceso al puerto 3306 desde Internet (se pueden endurecer las políticas de seguridad en este punto pero para realizar las pruebas ya nos servirá esta configuración) y acceso por SSH en sistemas Ubuntu 8.10.
Para añadir un esclavo a un entorno debemos seguir los siguientes pasos:
- Paramos el servidor MySQL del esclavo en funcionamiento (de aquí en adelante slave-1). En la consola del slave-1 con el siguiente comando:
sudo /etc/init.d/mysql stopPara ejecutar este comando debemos acceder a la consola del slave-1 por SSH o localmente. - Paramos también le servidor MySQL del esclavo que queremos arrancar (de aquí en adelante slave-2). En la consola del slave-2 con el mismo comando que en paso anterior.
- Copiamos los archivos del direcotrio /var/lib/mysql del slave-1 al slave-2. Para esta operación necesitamos la clave (keypair) para acceder por SSH del slave-1 al slave-2, en nuestro caso se encuentra en /mnt/keypair.pem.
Si no tenemos este archivo en el slave-1 desde el ordenador en que la tengamos deberemos ejecutar este comando:
scp -i /path/to/keypair.pem /path/to/keypair.pem root@dns.slave-1.com:/mnt/keypair.pemEste comando nos sube por SSH el archivo keypair.pem situado en /path/to al directorio /mnt del servidor remoto (dns.slave-2.com) identificandose como root con el mismo archivo (opción -i). Para realizar esta acción debemos identificarnos como root (a veces puede fallar la ejecución con ‘sudo’).Una vez con el archivo keypair.pem en el slave-1 copiaremos tambien con el comando ‘scp’ el contenido del directorio /var/lib/mysql de slave-1 al slave-2. En la consola del slave-1:
scp -r -i /mnt/keypair.pem /var/lib/mysql/* root@dns.slave-2.com:/var/lib/mysql/Cuando se hayan copiado todos los archivos podemos poner en marcha el servidor MySQL del slave-1. - Una vez copiados estos archivos es importante cambiar el propietario. En la consola del slave-2 ejecutar los siguientes comandos:
cd /var/lib/mysqlSi no realizamos este cambio de propietario es posible que el servidor de MySQL del slave-2 no arranque correctamente.
sudo chown -R mysql:mysql * - Cambiar el server-id del slave-2. Editando el archivo con vim o nano tenemos que abrir el archivo /etc/mysql/my.conf y dónde encontremos una linia así (o con otro número):
...Cambiar el número que aparece por un server-id que no se esté utilizando en el entorno de replicación.
server-id=2 - Para poder arrancar el servidor MySQL del slave-2 sólo nos queda dar permisos de replicación en el master. En la consola del master entramos en el cliente mysql:
mysql -u root -pY ejecutamos la siguiente consulta:
mysql> GRANT REPLICATION SLAVE ON *.* TO 'usuario_replica'@'dns-slave-2.com' IDENTIFIED BY 'pwd_del_usuario_replica'; - Arrancamos el servidor MySQL del slave-2. En la consola del slave-2 ejecutamos el comando:
sudo /etc/init.d/mysql start
Para comprovar que todo ha ido correctamente debemos realizar alguna modificación en el master y asegurarnos que se distribuye a las dos replicas afectadas. Para más información podeis visitrar los compeltos artículos que Laura tiene en su blog sobre la replicación en MySQL: Replicación MySQL con Master-Slave sobre Ubuntu 8.10 (master) y Replicación MySQL con Master-Slave sobre Ubuntu 8.10 (slave).
Elasticfox, un buen plugin para gestionar Amazon EC2 desde Firefox
Posted by Xavi in General, Programación Web on 11/03/2009
La gestión de servicios de Amazon EC2 nos obliga a tratar con las API y AMI Tools de Amazon a través de la línea de comandos (hay una expicación de como instalar API y AMI Tools en este mismo blog, aquí y aquí). El tablero de control vía web que nos ofrecen muchas veces resulta insuficiente porque sólo podemos ejecutar un pequeño número de las operaciones disponibles y la gestión de según qué es muy pesada hacerla comando a comando.
Suponogo que conocedores de estos inconvenientes, Amazon pone a servicio de los usuarios un plugin para Firefox llamado Elasticfox. Por cierto, no lo busques en el buscador oficial del navegador porque no està disponible, aquí tienes el enlace.
Elasticfox ofrece una interficie bastante simplificada para gestionar la mayoría de los servicios de Amazon EC2. Para operaciones complicadas se tiene que recurrir igualmente a la línea de comandos pero para conocer el estado de nuestras instancias y bloques de almacenamiento con un vistazo rápido tenemos suficiente.
Y un apunte final… Si estamos mirando en una “availability zone” determinada no vemos los datos de las otras zonas. ¿Esto es una ventaja realmente? Si alguien está gestionando sus instancias de Estados Unidos, ¿No quiere ver las que están corriendo en Europa? Quizás tendría que haber una opción que permetiera esconder la información de otras zonas, pero que no se puedan ver todas de golpe me parece incómodo.
Empaquetar una instancia de EC2 en funcionamiento (II)
Posted by Xavi in Programación Web on 04/03/2009
Este post es la continuación de Empaquetar una instancia de EC2 en funcionamiento (I), si no lo has leído mejor que le des un vistazo antes de continuar, si ya lo has leído adelante…
Empaquetar la instancia
Para empaquetar la instancia debemos encontrarnos en el directorio /tmp de la instancia y correr el siguiente comando (que pertenece a las AMI Tools que hemos instalado en el apunte anterior):
ec2-bundle-vol -k /mnt/pk-xxxx.pem -c /mnt/cert-xxxx.pem -u xxxx-xxxx-xxxx* El campo xxxx-xxxx-xxxx lo tenemos que sustituir por los numeros que aparecen en la parte superior derecha de nuestra página de Access Identifiers (justo debajo de Welcome Nombre Usuario | Sign Out).
Este comando va a tardar un poco y nos va a generar una serie de archivos que luego va a ser los que vamos a tener que subir y registrar.
Subir la AMI empaquetada a Amazon S3
Para poder disponer de la AMI debemos subirla a un bucket de Amazon S3. En el proceso de registro de una cuenta de EC2 se nos obliga a tener una de S3 porque las instancias quedan almacenadas allí, por lo tanto con una cuenta de EC2 seguro que tenemos acceso a una de S3.
El único requisito que debemos cumplir para subir una AMI a una cuenta de S3 es disponer de un bucket en la misma Availability Zone. Para gestionar les servicios de Amazon Simple Storage Service, S3, existe un programa multiplataforma en Java llamado Bucket Explorer; la licencia cuesta unos 40 dólares que para la simplicidad del programa considero justos (existe una licencia de prueba de 30 días).
Una vez creado el bucket debemos recordar su nombre y correr el comando siguiente dentro del directorio /tmp en la máquina virtual:
ec2-upload-bundle -b nombredelbucket -m image.manifest.xml -a accessKeyID -s secretAccessKey* Evidentemente sustituyendo nombredelbucket por el nombre del bucket creado, accessKeyID por la clave de acceso pública y secretAccessKey por la clave secreta. A parte de esto, el nombre del manifest puede variar según las opciones que hayamos descrito en la operación de “bundle”.
Registrar la AMI
Una vez subida la AMI al bucket de S3 sólo tenemos que registrarla para poder instanciarla desde el tablero de control de EC2. Una vez registrada nos aparecerá si seleccionamos Private Images en el desplegable de la sección AMIs y ya podremos arrancar tantas instancias como queramos desde la web.
Para registrar la AMI debemos correr el siguiente comando en la máquina local (dónde deberíamos tener instaladas las API Tools de Amazon, diferentes de las AMI que hemos instalado en la instancia de EC2, para más información lee mi post anterior sobre Amazon EC2):
sudo ec2-register nombredelbucket/image.manifest.xml
La instancia tarda unos segundos en estar disponible en el panel de control pero si todo ha ido bien deberíamos tener nuestra AMI personalizada y privada lista para lanzarse.
Cualquier duda dejadla en comentarios y miraremos de resolverla lo más pronto posible, así quizás ayudamos a otras personas que se encuentren con el mismo problema
Saludos!
Empaquetar una instancia de EC2 en funcionamiento (I)
Posted by Xavi in Programación Web on 04/03/2009
La documentación de Amazon sobre sus servicios es, en muchos casos, bastante confusa. Por este motivo, y enlazando con un apunte anterior en el que hablabamos de crear una página web sencilla con un servidor en Amazon EC2, vamos a revisar el proceso de empaquetado (bundle) de una instancia para crear una AMI de la que podamos correr tantas instancias como nos apetezca.
¿Por qué queremos crear una propia AMI?
Normalmente las AMI que tenemos a nuestra disposición tienen una selección de software bastante estándar, por consiguiente, si el software que queremos correr difiere mucho de la selección preestablecida, sería recomendable crear una AMI propia para no tener que instalar y configurar todo el software adicional cada vez que arrancamos una instancia.
Esta AMI podrá ser completamente privada, así que podremos dejar la configuración muy ajustada a nuestro sistema para ahorrar el máximo tiempo posible en el arranque de cada máquina virtual.
En resumen podríamos decir que crear una AMI propia nos permite dejar guardada una máquina configurada con todo el software necesario para arrancar una instancia y ponernos a trabajar con un tiempo mínimo de start-up.
Prerrequisitos
Para llevar a cabo este mini-tutorial para realizar el “bundling” de una instancia de EC2 necesitaremos lo siguiente:
- Una instancia de EC2 corriendo Ubuntu 8.10
- Conocer y tener acceso a la Private-key y certificado del protocolo de identificación X.509
- Tener acceso a la instancia de EC2 por SSH (esto implica tener acceso al archivo *.pem que nos sirve de identificación en la instancia)
- Conocer las Access Key ID y Private Access Key de la cuenta de Amazon WebServices
Subir la Private Key y el Certificate a la máquina virtual
Para poder identificarnos en las operaciones que realicemos en la máquina virtual nos hará falta tener a nuestra disposción los archivos de identificación (Private Key y Certificate del protocolo X.509). Aún así debemos tener en cuenta que tendremos que subirlos a un directorio que no quede guardado cuando hagamos el empaquetado de la AMI porque sino podríamos estar esparciendo nuestros archivos secretos de identificación por todas nuestras instancias en funcionamiento (¿y eso es algo que no queremos verdad?).
El directorio dónde vamos a subir estos archivos será /mnt y lo haremos con el siguiente comando:
scp -i /ruta/a/llaves/archivo-de-identificacion.pem /ruta/a/llaves/pk-xxxx.pem /ruta/a/llaves/cert-xxxx.pem root@dns.publica.de.amazon :/mntEste comando sube los dos archivos pk-xxxx.pem y cert-xxxx.pem al directorio /mnt de la máquina virtual como usuario root utilizando el mismo sistema de identificación que utilizariamos si quisiéramos acceder por ssh.
No debería hacer falta pero señalamos que tenemos que cambiar la ruta /ruta/a/llaves por la ruta absoluta de los archivos implicados y dns.publica.de.amazon por la DNS pública de la instancia que podemos encontrar en el panel de control de Amazon EC2.
Instalación de las herramientas en la máquina virtual
Para instalar las herramientas de Amazon para gestionar las AMIs vamos a seguir un proceso que nos ha funcionado pero no tiene porqué ser el único ni el mejor. Este proceso utiliza el paquete precompilado *.rpm de Amazon y la herramienta alien para pasarlo a *.deb. Vamos a verlo paso a paso:
- Accedemos a la máquina virtual por ssh (recuerda que todas las operaciones después de esta se realizarán en la linea de comandos de la instancia en Amazon EC2):
ssh -i /ruta/a/llaves/archivo-de-identificacion.pem root@dns.publica.de.amazon - Instalamos el software que necessitamos para instalar y utilizar las AMI Tools de Amazon:
apt-get install ruby alien* es posible que nos encontremos estos dos paquetes ya instalados en la AMI correspondiente pero mejor asegurarnos. - Descargamos las AMI Tools en un directorio que luego no vaya a ser almacenado en el “bundling” como por ejemplo /tmp:
cd /tmp
wget http://s3.amazonaws.com/ec2-downloads/ec2-ami-tools.noarch.rpm - Una vez descargado el archivo rpm vamos a crear el .deb con alien y instalarlo:
alien -d ec2-ami-tools.noarch.rpm* El nombre del paquete .deb generado puede variar según las versiones del software que estemos utilizando.
dpkg -i ec2-ami-tools_1.3-31781_all.deb
Si todo ha funcionado de forma correcta ya tenemos la instancia preparada para ser empaquetada y registrada pero esto lo veremos en un post posterior (aquí).
¿Me sigues? :-)
Comentarios recientes