Comencemos por el rol de Docker. Un rol se compone de una serie de tareas a ejecutar, en nuestro caso, descargar Docker del repositorio e instalarlo. Dichas tareas se especifican en un fichero .yaml.

- name: anyadir repositorio docker
yum_repository:
name: docker
description: Docker Repository
baseurl: https://yum.dockerproject.org/repo/main/centos/7/
gpgcheck: yes
gpgkey: https://yum.dockerproject.org/gpg
enabled: yes

- name: instalar docker-engine
yum: name=docker-engine state=present

De forma similar, crearemos el rol «data_serving_client», la parte cliente de nuestra aplicación Data Serving (un benchmark de cloud). Para ello, definiremos dos tareas, una que descarga la imagen del repositorio y otra que arrancará el contenedor.

#file: main.yaml - data_serving_client role
- name: get image
shell: docker pull cloudsuite/data-serving:client

- name: start data server
shell: docker run --name cassandra-client --net serving_network cloudsuite/data-serving:client [...]

El componente servidor de nuestra aplicación se creará bajo el rol «data_serving_server». No incluimos el contenido del main.yml, ya que es muy similar al anterior. Una vez definidos los roles, ahora indicaremos las máquinas virtuales. O mejor dicho, una «receta», que será un compendio de roles. En Ansible, cada receta se denomina «playbook». Todo ello se define en el fichero ansible.yaml. Aquí se pueden ver las dos «recetas», la «cliente-sansible», que ejecutará los roles «docker» y «data_serving_client», y la «receta» «servidor-ansible» que reutilizará el rol «docker» y además el de «data_serving_server»:

# file: ansible.yml
- hosts: cliente-ansible
become: yes
become_method: sudo
gather_facts: no
roles:
- docker
- data_serving_client

- hosts: servidor-ansible
become: yes
become_method: sudo
gather_facts: no
roles:
- docker
- data_serving_server

Podemos combinar fácilmente Vagrant y Ansible de la siguiente forma mediante el fichero VagrantFile: para cada Máquina virtual indicaremos la ruta al fichero ansible.yaml y al fichero inventory.

Vagrant.configure(2) do |config|
# Máquina virtual cliente
config.vm.define 'cliente' do |client|
cliente.vm.box = 'centos/7'
cliente.vm.hostname = 'nombre.midominio.es'
cliente.vm.network 'mi_red', ip: "192.168.50.3"
cliente.vm.provider 'virtualbox' do |vb|
vb.memory = '1024'
vb.cpus = 1
end
cliente.vm.provision "ansible" do |ansible|
ansible.inventory_path = 'ansible/environment/inventory'
ansible.verbose = 'vvv'
ansible.playbook = 'ansible/anomaly.yml'
end
end

# Máquina virtual servidora
config.vm.define 'servidor' do |server|
[..]
end
end

Como podemos ver, en Vagrant hemos definido 2 máquinas virtuales de nombres «cliente» y «servidor». Con Ansible tenemos dos «recetas»: cliente-ansible y servidor-ansible. Nos quedaba por ver el fichero de inventario de Ansible, en el cual definimos la relación entre máquina virtual de Vagrant y la «receta» de Ansible:

[client-ansible]
cliente

[servidor-ansible]
servidor

Combinando Ansible y Vagrant tendremos un entorno de experimentación fácilmente reproducible. Docker además nos permite reutilizar imágenes de aplicaciones existentes en el repositorio. Como nota final, Vagrant nos da la opción de crear un «snapshot» de cada máquina virtual, que guardará su estado actual para futuras ejecuciones.

The post Experimentos portables (II) – «Recetas» para VMs appeared first on S3lab.

Vagrant es una herramienta sencilla que nos permite gestionar el ciclo de vida de las maquinas virtuales. Toda la configuración la incluiremos en un fichero llamado Vagrantfile, mayormente declarativo. En el describiremos los recursos asignados a cada máquina, imagen (sistema operativo), y scripts necesarios para crear el entorno.

Vagrant es compatible con varios «proveedores», tales como VirtualBox, VMware o KVM. Adicionalmente, se ofrece un plugin para libvirt, una API que soporta diferentes plataformas de vitalización. Existen diversos repositorios para Vagrant que contienen boxes o imágenes (sistemas operativos) ya listas para descargar y ejecutar.

Una vez creado el fichero VagrantFile, podremos lanzar la maquina virtual desde línea de comandos, conectarnos a ella mediante SSH o destruirla. En muchas ocasiones nos será útil poder crear una red que conecte las maquinas. Todo ello es posible con unas pocas líneas de configuración, muy intuitivas. Aquí creamos una maquinas con CentOS, 1 core y 1GB de RAM, y que tendrá instalado Docker:

config.vm.define "server" do |server|
server.vm.box = "centos/7"
server.vm.hostname = "nombre.midominio.es"
server.vm.network "mi_red", ip: "192.168.50.3"
server.vm.provider "virtualbox" do |vb|
vb.memory = "1024"
vb.cpus = 1
end
server.vm.provision "shell" do |s|
s.path = "instalar_docker.sh"
end

The post Experimentos portables (I) – VMs con Vagrant appeared first on S3lab.

Sin entrar en grandes detalles, VM y contenedores proporcionan una capa de “abstracción” y de aislamiento. A diferencia de las VM que virtualizan todo el “stack” (SO, etc.), los contenedores son mucho más ligeros y comparten el mismo kernel. A costa de un menor aislamiento, el overhead de los contenedores es menor, y permiten escalado de tipo vertical mucho más rápidamente (nos olvidamos de esperar minutos para arrancar una instancia de VM). La limitación de poder usar Docker únicamente en Linux ha sido finalmente resulta, tras introducir soporte para los sistemas operativos Windows y Mac.

El potencial de los contenedores es claro. Sin embargo, no debemos olvidarnos de nuestra aplicación: debe estar diseñada de tal forma que sea escalable. Es el problema de ciertas aplicaciones legacy (típicamente monolíticas o de una única capa), que no se desarrollaron con esta característica en mente. La arquitectura orientada a servicios (SOA) se pensó con este fin y más recientemente, los microservicios se han popularizado. El patrón de diseño de Microservicios tiene adeptos tan conocidos como Spotify, Netflix, Ebay, Amazon, Google y Microsoft Azure.

La idea de un microservicio es que cumpla una función muy específica. Esto tiene ventajas ya que agiliza el ciclo de desarrollo de aplicaciones (incluido el despliegue a producción y reemplazo de versiones antiguas “en caliente”). Además, cuadra perfectamente con la filosofía de los contenedores, pudiendo así desplegar un mismo microservicio en distintos contenedores. La comunicación entre servicios puede darse mediante protocolos síncronos (HTTP/REST) o asíncronos (AMQP).

Google Container Engine, Azure Container Service y Amazon EC2 Container Service (ECS) son ejemplos de proveedores que permiten el uso de contenedores para desplegar nuestras aplicaciones. Tenemos aquí un nuevo modelo de escalado de aplicaciones (microservicios + contenedores) con menos limitaciones que el tradicional escalado horizontal basado en VMs.

The post Tendencia en autoescalado: Microservices y Docker appeared first on S3lab.

La dificultad reside en conocer la carga entrante a la aplicación en todo momento, para así poder adecuar los recursos. Un autoscaler es la pieza del puzzle que cumple esta función. Los proveedores estándar (Amazon EC2, Google Compute Engine) ofrecen un servicio básico basado en reglas: e.g. si la carga del servidor es mayor que un umbral, se añaden varios servidores de respaldo.

Sin embargo, es posible aplicar métodos más sofisticados. Netflix y su servicio Scryer es un claro ejemplo. La carga de peticiones procedente de sus usuarios tiene una forma marcadamente periódica, como se puede ver en la siguiente imagen.

Por ello, es posible utilizar diferentes técnicas de predicción temporal para estimar la carga futura y así hacer un autoescalado proactivo.

Otro factor a tener en cuenta es el esquema de tarificación de nuestro proveedor. En concreto, Netflix utiliza los servicios de Amazon EC2. En su oferta, Amazon nos cobrará unos céntimos según el tipo de instancia (a más recursos, más coste). Además, redondea el coste a una hora: Si sólo ejecutamos la instancia durante 5 minutos, nos va a cobrar por 60. Conviene tener en cuenta este factor para nuestro autoscaler.

Justando todas las piezas, Netflix ha sido capaz de crear Scryer, su propio autoscaler. Falta ver si los proveedores ofrecerán esta herramienta entre su carta de servicios.

The post Autoescalando con Scryer de Netflix appeared first on S3lab.