Categoría: AWS

JuJu: el domador Ubuntu de servicios en la nube

Tercera ley de Clarke: «Cualquier tecnología lo suficientemente avanzada es indistinguible de la magia». Eso es lo que me pasó por la cabeza la primera vez que ví éste vídeo sobre JuJu:

En 5 minutos y un puñado de comandos, JuJu permite ensamblar, desplegar y escalar un sistema MediaWiki de dos unidades, con la capa de persistencia en un cluster MySQL, dos instancias memcached para acelerar las peticiones y HAProxy como balanceador de carga. Y eso es sólo un ejemplo… Podríamos definir JuJu (antes conocido como Ensemble) como una mezcla entre gestor de paquetes para lanzar aplicaciones en la nube y un sistema de orquestación de servicios (una especie de domador con látigo que pone a cada servicio en su sitio y los junta/ensambla con otros animales/servicios 😉 Este software ha sido desarollado por Canonical bajo licencia AGPL y es un paso más en los movimientos de Canonical por situarse en el territorio cloud.

Para que JuJu funcione, hace uso de «encantamientos» o charms, que son simples recetas en un lenguaje de scripting que permiten instalar, configurar y enlazar servicios. Hay ya una bonita colección de charms disponibles, pero todavía quedan muchos por hacer. Usando estos charms, podemos lanzar un WordPress en la nube con MySQL como Base de Datos, con 4 comandos:

$ juju deploy –repository=. wordpress myblog
$ juju deploy –repository=. mysql mydb
$ juju add-relation mydb:db myblog
$ juju expose wordpress

Bonito, ¿eh? Pues ahora piensa que con el comando add-unit puedes lanzar otra unidad WordPress y comenzar el escalado horizontal a partir de comandos juju, como se muestra en el vídeo 🙂 ¿Magia?

Te recomiendo éste post en castellano con un ejemplo más elaborado del uso de JuJu, o si estás interesado, esta presentación en PDF para que revises el funcionamiento interno de esta tecnología.

Trabajando en la nube Amazon desde la línea de comandos (I)

Hello World! Sí, tras un parón de casi 2 meses sigo vivo 🙂 ¿En qué he estado divirtiéndome todo este tiempo? En redactar mi tesis (y lo que te rondaré, morena), en leer -mucho- sobre análisis de datos con R -y el maravilloso entorno RStudio-, en seguir con el desarrollo de Babelium – API, HTML5, integración con Moodle… – y sus implantaciones en distintos cursos universitarios. Usando para esto último la nube de Amazon (AWS, Amazon Web Services).

Precisamente de AWS quería hablar un poco hoy. Hacía tiempo que no disfrutaba tanto con alguna novedad informática. Desde la línea de comandos puedes lanzar máquinas virtuales (instancias), asignarles IP, cambiarles el disco, ampliar la memoria, la CPU… todo desde la terminal y tu intérprete (ba)sh favorito (o desde scripts en PHP, Python, Perl, Ruby, Java…).

Basta con definir 3 variables de entorno

export EC2_PRIVATE_KEY=/opt/juanan/pk-6OZ6AAAAAAUUXZGNIAAWE63AMBBBBBB.pem
export EC2_CERT=/opt/juanan/cert-6OZ6AAAAAAUUXZGNIAAWE63AMOBBBBBB.pem
export EC2_URL=http://eu-west-1.ec2.amazonaws.com

La primera y la segunda forman tus credenciales (clave privada y certificado X.509).

(sáltate el siguiente párrafo si no quieres saber para qué quiere Amazon estas credenciales, porque no es necesario saberlo para usar el API)

Las consultas/peticiones al API de Amazon se firman con la clave privada. Estas consultas van acompañadas del certificado X.509. Cuando la petición llega a Amazon, el sistema extrae la clave pública de dicho certificado y descifra la firma digital que has realizado con tu clave privada. Si todo va bien, comprueba además que el certificado coincide con el que Amazon tiene guardado y asignado a tu persona (al que firma la petición). Menudo tinglado para una llamada al API, eh? Puedes ver más info en la ayuda de AWS.

La tercera variable de entorno, EC2_URL, sirve para indicar que tus máquinas virtuales (instancias, en terminología Amazon) quieres tenerlas «alojadas», por defecto, en la región de Europa Occidental. Las regiones son: US East – Northern Virginia, US West (Northern California), EU (Ireland), Asia Pacific (Singapore) y Asia Pacific (Tokyo). Hay varias zonas en cada región (realmente hay una región más: AWS GovCloud, destinada en exclusiva a las necesidades del gobierno de EEUU).

Los precios por tener una instancia en marcha varían dependiendo de la región, del tipo de instancia y características que pongas en marcha y del tiempo que estén lanzadas. Supuestamente habría que tener en cuenta no sólo el precio, sino la velocidad de respuesta de las instancias al cliente. Se supone que los clientes de Europa recibirán respuesta más rápida desde instancias alojadas en esa zona… pero tampoco es que lo haya comprobado empíricamente. Por otro lado, por cuestiones de disponibilidad, conviene no dejar todos los huevos (instancias) en el mismo cesto (región y zona), sino diversificar.

Declaradas dichas variables de entorno, ya podemos lanzar nuestra primera orden en la línea de comandos (una simple descripción de regiones disponibles):

$ ec2-describe-regions
REGION	eu-west-1	ec2.eu-west-1.amazonaws.com
REGION	us-east-1	ec2.us-east-1.amazonaws.com
REGION	ap-northeast-1	ec2.ap-northeast-1.amazonaws.com
REGION	us-west-1	ec2.us-west-1.amazonaws.com
REGION	ap-southeast-1	ec2.ap-southeast-1.amazonaws.com

Otro ejemplo, para ver las zonas disponibles para la región eu-west-1:

$ ec2-describe-availability-zones --region=eu-west-1
AVAILABILITYZONE	eu-west-1a	available	eu-west-1	
AVAILABILITYZONE	eu-west-1b	available	eu-west-1	
AVAILABILITYZONE	eu-west-1c	available	eu-west-1

Sin embargo, los ejemplos anteriores son un poco pobres. Veamos un ejemplo final más interesante para finalizar esta primera parte:

$ ec2-run-instances  ami-359ea941  --instance-count 1 --instance-type t1.micro --key juanan --group default

Aquí hemos lanzado una instancia EC2 (una máquina virtual en la nube Elastic Cloud de Amazon) usando como base la AMI con identificador ami-359ea941. Una AMI, o Amazon Machine Image, es una especie de plantilla de máquina virtual. En términos de Prog. Orientada a Objetos, sería una Clase que puede ser instanciada y generar… je :-), instancias. AWS tiene su propio buscador de imágenes pero yo recomiendo éste otro catálogo: http://thecloudmarket.com/. Por cierto, la ami-359ea941 es una AMI oficial de Ubuntu, y tiene una «plantilla» con Ubuntu 11.04 en arquitectura x86 de 32 bits, para la región eu-west-1.

Siguiendo con la línea de lanzamiento de nueva instancia, la parte «–instance-count 1» indica que sólo queremos una unidad (puedes lanzar hasta 20 de este tipo a la vez…). La parte «–instance-type t1.micro» indica el tipo de máquina virtual que quieres: t1.micro es lo más pequeño que hay (y gratis por un año!). A partir de ahí, puedes tener gigantescos monstruos a 1 click de distancia.

La parte «–key juanan» indica que quieres acceder vía SSH a tu instancia con una clave privada SSH que lleva asociado este nombre. Al lanzar la instancia, Amazon deja la parte pública de esa clave SSH en el archivo .ssh/authorized-keys y sólo si tienes la parte privada en tu PC podrás acceder a esa instancia.

Finalmente, la parte «–group default» identifica la lista que define qué puertos TCP/UDP quieres tener abiertos o cerrados. Como sólo tengo una, especifico default (sin poner el nombre en concreto)

Nota: todo lo que indico sólo funcionará si tienes instalado el paquete ec2-api-tools de Ubuntu.

Ale, cierro el post, y sigo otro día con el tema AWS que da mucho, pero que mucho juego. Espero que os sea de utilidad.