Posts Tagged EC2

Instalar PostgreSQL 8.3 en CentOS desde Yum

Trabajar con servidores Linux, muchas veces comporta trabajar con CentOS. CentOS es una distribución de Linux muy orientada a servidores corporativos y ofrece un rendimiento muy alto en una amplia gama de entornos.

Para trabajar con este sistema es mejor estar habituado al trabajo con el gestor de paquetes de Red Hat (RPM) y Yum, sino tendremos que buscar información sobre como manipular los repositorios y encontrar el software necesario para nuestras aplicaciones. En el siguiente artículo intentaré detallar como instalar un servidor de bases de datos PostgreSQL 8.3 en un CentOS 5.2 (mis pruebas se han realizado en una instancia de Amazon EC2 con una imagen de CentOS 5.2 proporcionada por RightScale).

Desactivar los repositorios por defecto de CentOS

Para poder instalar la versión 8.3 de PostgreSQL tenemos que deshabilitar los repositorios de PostgreSQL que vienen con nuestro sistema operativo. Si no hicieramos este paso es posible que sólo consiguiéramos instalar la vesión que proporcionan los paquetes de la distribución en cuestión.

Para desactivar dichos repositorios debemos editar el fichero /etc/yum.repos.d/CentOS-Base.repo. Yo lo hago con Nano porque me parece un editor más ligero que otros pero el editor cada uno prefiere el suyo:
$> nano /etc/yum.repos.d/CentOS-Base.repo
Y en las secciones base y updates tenemos que excluir PostgreSQL, Para ello añadiremos exclude=postgresql* al final de cada sección. Dichas secciones deben acabar pareciendose a lo siguiente:
[base]
name=CentOS-$releasever - Base
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&rep$
#baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/
gpgcheck=1
gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-5
exclude=postgresql*

[updates]
name=CentOS-$releasever - Updates
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&rep$
#baseurl=http://mirror.centos.org/centos/$releasever/updates/$basearch/
gpgcheck=1
gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-5
exclude=postgresql*

Añadir los repositorios de PostgreSQL 8.3

Una vez desactivados los repositorios por defecto debemos definir los nuevos repositorios. Para ello utilizaremos los RPM de la página de repositorios de PostgreSQL. En la página copiaremos en enlace de la última versión de la rama 8.3 y iremos a la línea de comandos:
$> cd /tmp
$> wget http://yum.pgsqlrpms.org/reporpms/8.3/pgdg-centos-8.3-6.noarch.rpm
$> rpm -ivh pgdg-centos-8.3-6.noarch.rpm

NOTA: Recuerda que debes cambiar la URL de descarga del paquete RPM por la que corresponda en el momento que realices la operación.

Instalar el servidor de base de datos

Una vez activados los repositorios tenemos que instalar el servidor de base de datos:
$> yum install postgresql postgresql-server
Es posible que en este paso nos de un problema de librerías por culpa de un paquete llamado apr-util. En este caso deberemos instalar primero este paquete (por separado) y luego volver a lanzar la instalación del servidor:
$> yum install apr-util
$> yum install postgresql postgresql-server

La solución al problema de dependencias no debería reproducirse si instalamos el servidor de bases de datos en estos dos pasos.

Arrancar el servidor y habilitar conexiones remotas

Para arrancar el servidor seguiremos los pasos siguientes:
$> service postgresql initdb
$> service postgresql start

Con esto ya tendremos el servidor de base de datos arrancado y aceptando conexiones en local, pero no podremos acceder al servidor desde conexiones remotas. Para habilitar las conexiones remotas debemos asegurarnos que no hay ningún tipo de bloqueo que no sea el del servidor Postgre, modificar dos ficheros y reiniciar el servicio. El primer fichero que vamos a modificar es /var/lib/pgsql/data/pg_hba.conf.

En pg_hba.conf se tiene que dar acceso a la red desde la que vamos a acceder (dirección IP), en el ejemplo vamos a usar 0.0.0.0/0 pero se debería cambiar por nuestra dirección para tener un control más estricto. Para dar acceso a una red añadiremos los siguiente al fichero:
host all all 0.0.0.0/0 trust

El segundo fichero que debemos modificar es /var/lib/pgsql/data/postgresql.conf. En este debemos buscar la línea que pone:
listen_addresses='localhost'
Y poner:
listen_addresses='*'

Una vez realizados estos cambios se tiene que reiniciar el servicio:
$> /etc/init.d/postgresql restart

En teoria, cuando el servicio arranque de nuevo debería ser posible establecer conexiones remotas al servidor con el usuario postgres y el password que le corresponda. En caso de que no se haya definido password para dicho usuario, éste se puede setear de forma manual. Como usuario ROOT ejecutamos el siguiente comando:
passwd postgres
El sistema nos pedirá que introduzcamos dos veces el password y listo! Espero que les sirva de ayuda.

, , , , , ,

No Comments

Amazon premia la planificación

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.

, , , ,

3 Comments

Añadir un slave a un entorno de replicación MySQL

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/mysql
    sudo chown -R mysql:mysql *
    Si no realizamos este cambio de propietario es posible que el servidor de MySQL del slave-2 no arranque correctamente.
  • 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):
    ...
    server-id=2
    Cambiar el número que aparece por un server-id que no se esté utilizando en el entorno de replicación.
  • 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).

, , , , ,

No Comments

Elasticfox, un buen plugin para gestionar Amazon EC2 desde Firefox

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.

, , , ,

No Comments

Empaquetar una instancia de EC2 en funcionamiento (II)

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!

, , , , , ,

No Comments

Empaquetar una instancia de EC2 en funcionamiento (I)

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
    dpkg -i ec2-ami-tools_1.3-31781_all.deb
    * El nombre del paquete .deb generado puede variar según las versiones del software que estemos utilizando.

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í).

, , , , ,

No Comments

Tu primera página web con Amazon EC2

En la actualidad, Amazon posee uno de los recursos más interesantes para el hospedaje de aplicaciones web que necesiten gran escalabilidad (tanto para aumentar la capacidad de cómputo como para disminuirla y no pagar por recursos que no nos van a hacer falta). Este recurso es un grupo de servicios web entre los cuales podemos encontrar almacenamiento en S3, bases de datos muy simples con SimpleDB o, el que nos va a centrar en este post, servidores escalables en EC2 (EC2 viene de Elastic Cloud Computing).
aws-tutorial
La explicación teórica de qué es y qué no es EC2 voy a dejarla para un posible post posterior, de la misma forma, tampoco vamos a entrar a describir el proceso de alta en una cuenta de Amazon EC2, que en el fondo se trata de una simple gestión administrativa. Por consiguiente, a partir de aquí sólo vamos a cubrir el cómo visualizar una página web simple partiendo de una cuenta “virgen” de Amazon EC2.

Prerrequisitos

Los prerrequisitos para afrontar el proceso que vamos a describir son los siguientes:

  • Tener localizadas los ficheros de certificado y clave privada del certificado X.509 que nos identifican en los servicios de Amazon.
  • Tener acceso total a la cuenta de Amazon AWS (es lógico pero no está de más comentarlo).

Escoger y arrancar la AMI

Una vez identificados en el sistema de Amazon (ALERTA: dependiendo del navegador y el sistema operativo que estemos utilizando es posible que se nos pida nuestra identificación más de una vez en el proceso) debemos dirigirnos al ‘AWS Management Console’ y dentro de este a la pestaña ‘Amazon EC2′.

Nuestro primer objetivo cuando nos encontremos en dicha pestaña será arrancar una AMI (Amazon Machine Image, en otras palabras un servidor virtual). Esto lo podemos llevar a cabo desde el Dashboard y desde las secciones de Instances y AMIs. Sea cual sea el camino escogido iremos a parar al siguiente diálogo:

aws-tutorial

Como ya hemos comentado en anteriores posts, en este blog hay un aprecio bastante grande a Ubuntu y, por tanto, basaremos esta primera instalación en nuestra distribución favorita. En la pestaña comunity AMIs seleccionaremos sólo los sistemas de 32-bits (para poder escoger la máquina más económica posible) y el sistema operativo Ubuntu. Para la realización de este proceso yo he escogido la imagen con el manifest: alestic/ubuntu-8.10-intrepid-base-20081222.manifest.xml. Es de las primeras opciones que nos aparecen con la versión 8.10 del sistema operativo. Cuando localicemos la AMI sólo tenemos que pinchar en el link “select” y pasar al siguiente paso.

En un primer momento tendremos que crear una clave para identificar nuestras instancias (en el paso ‘Create Key Pair’). Tenemos que ir con sumo cuidado a la hora de guardar esta clave porque nos permitirá el acceso a la instancia por diferentes métodos más adelante. Después de haber creado esta instancia debemos configurar el Firewall de la máquina de forma que sea lo más segura posible pero que podamos acceder a ella por SSH (en un entorno de producción dejaríamos cerrado el puerto para posteriormente dar acceso sólo desde las IP que consideráramos seguras con las herramientas de EC2).

Para acabar de arrancar la máquina virtual sólo nos quedará definir el número de instancias (poned 1), el tipo (poned small, la más barata), seleccionar la Key Pair que acabámos de crear para identificar la instancia y dejar seleccionados los dos grupos en Security groups. No vamos a entrar en las opciones avanzadas porque para mostrar una página web estática no nos afectan pero existe un gran abanico de posibilidades para configurar las AMIs que queremos arrancar.

aws-tutorial1

Una vez pulsado el botón “Launch” vamos a tener que esperar unos segundos para que la máquina arranque definitivamente.

Conectarse de forma remota a la instancia

En la sección de Instances ahora deberíamos ver un registro nuevo (con el status running) que podemos seleccionar. Una vez seleccionado, si hacemos click en el botón Connect nos dará los datos para acceder a la máquina via SSH.

El ejemplo de comando que nos ponen en el diálogo que se abre cuando hacemos click en Connect es un buen ejemplo, si sustituimos el nombredelakeypair.pem por el path completo donde está este archivo en nuestro ordenador podremos acceder a la instancia sin ningún problema. En Ubuntu el path podría ser /home/user/Keys/nombredelakeypair.pem

Instalar un servidor web

Para poder mostrar una página web deberemos instalar un servidor web en la instancia. Podemos decantarnos por Apache2 o Lighttpd para poner un par de ejemplos. En la consola de la instancia con ejecutar el siguiente comando tendríamos el servidor Lighttpd corriendo sin más problemas:
sudo apt-get install lighttpd*En el post anterior hay una explicación más extensa de las posibilidades de este servidor web.

Dar acceso a través del puerto 80 a la instancia

Una vez instalado el servidor web, si nos dirijimos a la DNS pública que nos indica el panel de instancias veremos como el navegador no acaba de encontrar la página que deseamos. Esto es porque por defecto las instancias tienen cerrados los puertos de comunicación (al pagarse por tráfico es conveniente que estén cerrados por defecto). Para poder abrir estos puertos debemos tener instaladas las herramientas de EC2 en nuestro ordenador local.

El siguiente apartado sólo está probado sobre Ubuntu 8.10 y por lo tanto no puedo asegurar que funcione ni en otras versiones de la misma distribución:

Para instalar las herramientas de EC2 en nuestra Ubuntu 8.10 debemos seguir estos pasos:

  • Instalar la versión 5 de Java (pero la versión de Sun, nada de OpenJDK)
  • Descargar la herramientas de su web (podeis encontrar el enlace en su guia)
  • Descomprimir las herramientas en un directorio accesible
  • Seguir las intrucciones de como setear las herramientas que hay en el apartado Setting up the Tools de la guía oficial. NOTA: En Ubuntu, antes de empezar a ejecutar el comando ‘export’ debemos ejecutar el comando ‘bash’ para que arranque este interprete y no intentar lanzar las instrucciones con el comando ‘sudo’ se deben introducir todas los comandos tal como se exponen en la web de Amazon.
  • bash
    export EC2_HOME=/ruta/a/las/herramientas
    export PATH=$PATH:$EC2_HOME/bin
    export EC2_PRIVATE_KEY=/ruta/a/las/claves/pk-XXXXXXXXXXXXXXXXX.pem
    export EC2_CERT=/ruta/a/las/claves/cert-XXXXXXXXXXXXXXXXX.pem
    *Esto es un recopilatorio de los comandos que se tienen que ejecutar POR SEPARADO. Para saber el significado de cada uno consulta la sección Setting up the Tools de la guía.

  • Una vez instaladas las herramientas sólo debemos correr el comando siguiente y ya podremos acceder a la página web de ejemplo del servidor que hayamos instalado en la instancia de Amazon

ec2-authorize default -p 80A partir de aquí… lo dejo a vuestra imaginación.

, , , , ,

No Comments