Categories
General Social

Docker Workshop in Barcelona

Como ya comentamos anteriormente en cloudadmins ha irrumpido con mucha fuerza una nueva forma de virtualizar a través de LxC. Docker empezó como un proyecto interno de Solomon Hykes en dotCloud, un proveedor PaaS (plataforma como servicio) y fue publicado en marzo de 2013. Se trata de una herramienta de virtualización construida sobre LinuX Containers que utiliza funcionalidades de CGROUPS para crear y ejecutar múltiples entornos virtuales de forma aislada. A diferencia de una máquina virtual Docker no permite crear un entorno virtualizado distinto al del OS, procesador y harwarde emulado. En cambio conseguimos un rendimiento mayor ya que el overhead es mucho menor ha diferencia de la virtualización tradicional con hypervisor.

Tuvimos el placer de asistir al workshop sobre dockers que se llevó a cabo en itnig. En ella repasamos comandos básicos de docker de la mano de Dimtris Kapanidis, podéis reproducir el workshop a través de su cuenta de github docker-workshop. Si no tenéis instalado docker y queréis trastear un poco es posible dar los primeros pasos en su propia web try it! O darle un vistazo a la presentación que tiene colgada en slidshare Xabier Larrakoetxea llamada Ship it with Docker”
Dimitri nos recomendo utilizar el parámetro -s al buscar imágenes para obtener imágenes de un sitio de confianza.

sudo docker search -s 10 nginx
NAME                             DESCRIPTION                                     STARS 
nginx                            Official build of Nginx.                        110     

A continuación Nicolas Poggi M. presento un caso de uso de como utilizar Docker como proveedor de Vagrant para crear múltiples entornos de desarrollo (link presentación y link desarrollo) y Pep Turró de Redhat nos presento el proyecto ATOMIC y como se esta redefiniendo a través de GearD.
Finalmente Dimitri de nuevo nos mostro como enlazar contenedores entre distintos hosts a través de Ambassador Pattern Lo que nos abre un extenso abanico de possibilidades en cuanto a la portabilidad y despliegue de LxC. Los 60 asistentes del workshop pudimos disfrutar de unas cervezas por cortesía de Estrella Damm 🙂
Feliz sysadminday!!
 
Ref: http://www.meetup.com/docker-barcelona-spain/events/193336922/comments/388505892/

Categories
OpenSource

Ansible, automatización de tareas y despliegues de forma simple

índex
Hoy en día el número de servidores, virtuales o físicos, sigue creciendo a un ritmo muy alto y a los sysadmin no se nos debe pasar por alto esta realidad. Este hecho nos obliga a buscar nuevos métodos para desplegar, configurar y actualizar máquinas de forma que estas tareas mecánicas y que llegan a ser idénticas en muchos grupos de servidores nos hagan perder el menor tiempo posible.
A raíz de esta necesidad han surgido diferentes herramientas que nos permiten automatizar muchas tareas que se volverían repetitivas si las tuviéramos que aplicar en muchos de nuestros servidores. Algunas de las herramientas a las que me refiero son Puppet, Chef, Salt y de la que vamos a hablar hoy, Ansible.
Ansible es una herramienta open-source desarrollada en python y comercialmente ofrecida por AnsibleWorks que la definen como un motor de orquestación muy simple que automatiza las tareas necesarias en el campo de las TI. La palabra clave en esta definición es simple y es que Ansible posee unas características que junto su amplia e inteligible documentación hacen esta herramienta realmente atractiva para aquellos que aún no automatizan sus tareas de administración ya que su curva de aprendizaje crece muy rápido.
Estas son quizás las características más importantes:

  • Clientes sin agentes (Overhead muy bajo)
  • Método de autenticación por ssh (preferiblemente con claves) en paralelo
  • No necesita usuario root (permite la utilización de sudo)
  • Permite utilizar comandos básicos
  • Para configurar tareas complejas utiliza lenguaje YAML (Playbooks)

Como hemos remarcado Ansible funciona sin agentes y como único requisito necesita que el cliente tenga instalado python 2.4 o posterior.
Ansible permite diferentes formas de configuración, una podría ser mediante un solo fichero llamado playbook que contendría todos los parámetros para hacer una determinada tarea sobre un determinado grupo de servidores o mediante una estructura de directorios por cada proyecto separando los parámetros en ficheros, que luego nos permitirán importarlos desde otros playbooks.
A continuación haremos una introducción de la estructura simple de Ansible definiendo sus componentes para un proyecto concreto

.
├── hosts <- inventory
├── playbook.yml <-playbook
└── roles
    └── webserver <- role webserver
        ├── files
        │   └── index.php
        └── tasks
            └── main.yml <- fichero de tareas

Modules: Los módulos son las librerías que utiliza para controlar servicios, ficheros, paquetes o comandos. Por ejemplo más abajo veremos que en el fichero main.yml tenemos definidos tres tipos de módulos, apt, copy y service. Cualquiera puede crear sus propios módulos. Debido a que es una herramienta muy nueva todavía faltan por desarrollar muchos módulos, actualmente, existen módulos para EC2 y Rackspace en lo que a cloud se refiere.
Inventory: Fichero donde se definen hosts, o grupos de hosts y sus variables como podria ser el puerto ssh al que hay que conectarse. Por defecto /etc/ansible/hosts aunque también se puede crear uno por proyecto en la raiź del directorio.

# hosts
[webserver]
10.0.0.1    ansible_ssh_user=usuario    ansible_ssh_private_key_file=~/.ssh/id_rsa    ansible_ssh_port=2322
[dbserver]
10.0.0.2    ansible_ssh_user=usuario_db    ansible_ssh_private_key_file=~/.ssh/id_rsa    ansible_ssh_port=2022

Playbook: Este fichero es el encargado de definir todas las tareas que debemos realizar sobre un conjunto de hosts.

# playbook.yml
---
- hosts: all
  roles:
    - webserver

Roles: Los roles son grupos de ficheros y tareas parecidos sobre un determinado grupo de hosts, por ejemplo, en el caso de la instalación de un LAMP podríamos tener un role para webserver y otro para dbserver.
Files: En este directorio se almacenarán los ficheros que se deben copiar en los hosts que pertencen a ese role.
Tasks: Dentro de este directorio se debe crear el fichero main.yml donde definiremos las tareas que se deben ejecutar en los hosts que pertenecen a ese role.

# roles/webserver/tasks/main.yml
---
- name: 1. Instalar Apache
  apt: name=apache2 state=present
- name: 2. Instalar PHP
  apt: name=libapache2-mod-php5 state=present
- name: 3. Start Apache
  service: name=apache2 state=running enabled=yes
- name: 4. Copiar index.php
  copy: src=index.php dest=/var/www/index.php mode=0664

Una vez tenemos los ficheros ejecutamos Ansible.

ansible-playbook -i hosts playbook.yml --sudo --verbose
PLAY [webserver] **************************************************************
GATHERING FACTS ***************************************************************
ok: [10.0.0.1]
TASK: [webserver | 1. Instalar Apache] ****************************************
ok: [10.0.0.1] => {"changed": false, "item": ""}
TASK: [webserver | 2. Instalar PHP] *******************************************
ok: [10.0.0.1] => {"changed": false, "item": ""}
TASK: [webserver | 3. start Apache] *******************************************
ok: [10.0.0.1] => {"changed": false, "enabled": true, "item": "", "name": "apache2", "state": "started"}
TASK: [webserver | 4. Copiar index.php] ***************************************
changed: [10.0.0.1] => {"changed": true, "dest": "/var/www/index.php", "gid": 1000, "group": "xavi", "item": "", "md5sum": "d41d8cd98f00b204e9800998ecf8427e", "mode": "0664", "owner": "xavi", "size": 0, "src": "/home/xavi/.ansible/tmp/ansible-tmp-1398516303.41-96546412744806/source", "state": "file", "uid": 1000}
PLAY RECAP ********************************************************************
10.0.0.1                  : ok=5    changed=1    unreachable=0    failed=0

Si nos fijamos en el resumen de la última linea vemos que solo una tarea ha cambiado de estado y que las demás están OK. Esto significa que ya estaban en el estado correcto excepto la tarea 4 que ahora sí, está en el estado correcto después de ejecutar Ansible.
Instalar Ansible es tan sencillo como añadir los repositorios e instalarlo vía repositorios aunque también lo puedes instalar a través de pip.

sudo apt-add-repository ppa:rquillo/ansible
sudo apt-get update
sudo apt-get install ansible

Este es un pequeño resumen de la infinidad de posibilidades que ofrece Ansible. En su página web se pueden encontrar vídeos y documentación donde se explica con mucho detalle todo lo que puede hacer por nosotros.
Xavier Peralta
www.cloudadmins.org

Categories
Guide In detail OpenSource

Alta disponibilidad en la capa de balanceo con HAProxy y Keepalived




Prácticamente ya no cabe pensar en servicios en la nube sin suponerles alta disponibilidad (HA). Como usuarios estamos mal acostumbrados,  ¿por qué quien sigue utilizando un servicio que no se encuentre disponible, aunque sea de manera casual?
La alta disponibilidad ha pasado a ser una commodity. Y ya no hay empresa, con un modelo de negocio capaz de soportar periodos regulares de no disponibilidad de su servicio, ya que eso implica grandes pérdidas económicas. ¡Más que nunca el tiempo es oro!
Existen diferentes herramientas o servicios que nos facilitaran el despliegue de nuestras aplicaciones con garantías HA, como: Keepalived, Pacemaker, Heartbeat, HAProxy, etc. Siendo éstas de diferente naturaleza (unas funcionan a nivel de aplicación, otras a nivel de HTTP/TCP…) y pudiendo ser combinadas según nuestras necesidades. Por ejemplo, una combinación muy común es Heartbeat y Pacemaker.

Quisiera hacer especial mención a HAProxy un projecto matenido por Willy Tarreau. Es un proyecto ya consolidado, la primera versión es del 2001 y empezó siendo proxy con balanceador de carga muy sencillo. Ha ido evolucionando y a día de hoy se haya convertido una herramienta muy interesante. El projecto se mantiene activo y van saliendo nuevas versiones que van incorporando nuevas funcionalidades como servir de terminación de SSL, analizador de logs, protocolo RDP, soporte para autenticación HTTP, estadísticas y monitorización… incluso incluye una interfaz web donde consultar el estado actual del proxy.

Si el servicio de balanceo de tu proveedor de cloud no te convence, ya que quieres llegar más allá y como el objetivo es no introducir un nuevo punto único de fallo en nuestras aplicaciones, vamos a ver un ejemplo práctico de como configurar un par de instancias HAProxy en modo activo-pasivo mediante Keepalived. Básicamente lo que haremos será mover dirección IP del servidor activo al pasivo cuando el primero deje de estar disponible.
Direcciones IP utilizadas

  • 10.1.1.10 Servidor Syslog
  • 10.1.1.30 Backend Web #1
  • 10.1.1.31 Backend Web #2
  • 10.1.1.20 Servidor HAProxy #1 dirección de gestión
  • 10.1.1.21 Servidor HAProxy #2 dirección de gestión
  • 10.1.1.80 Esta es la dirección del proxy que los usuarios conocen, Keepalived hará que apunte a un servidor disponible.
  • 10.1.1.25 Servidor SMTP

Instalación y configuración de HAProxy

En Ubuntu basta con hacer sudo apt-get install haproxy, poner ENABLED=1 en el fichero /etc/default/haproxy para habilitar el script de inicio y aplicar la siguiente configuración en /etc/haproxy/haproxy.cfg:

global
     log 10.1.1.10 local0
     user haproxy
     group haproxy
     daemon
     maxconn 20000
     defaults
     log global
     option dontlognull
     balance leastconn
     clitimeout 60000
     srvtimeout 60000
     contimeout 5000
     retries 3
     option redispatch
listen stats 10.1.1.20:80 # se podría poner 10.1.1.21:80
     mode http
     stats enable
     stats uri /stats
     stats realm HAProxy\ Statistics
     stats auth admin:PASSWORD
listen http 10.1.1.80:80
     mode tcp
     option tcplog
     balance source
     maxconn 10000
     server web01 10.1.1.30:80 maxconn 6000
     server web02 10.1.1.31:80 maxconn 6000
listen https 10.1.1.80:443
     mode tcp
     option tcplog
     balance roundrobin
     maxconn 10000
     server web01 10.1.1.30:443 maxconn 6000
     server web02 10.1.1.31:443 maxconn 6000

Finalmente iniciamos el servicio service haproxy start.
Instalación y configuración de Keepalived
En Ubuntu basta con hacer sudo apt-get install keepalived, y aplicar la siguiente configuración en /etc/keepalived/keepalived.conf:

global_defs {
    notification_email {
        alerts@cloudadmins.org
    }
    notification_email_from keepalived@haproxy01.cloudadmins.org
    smtp_server 10.1.1.25
    smtp_connect_timeout 30
}
vrrp_script chk_haproxy {
    script "killall -0 haproxy"
    interval 2 # check cada 2 segundos
    weight 2 # añade 2 puntos de prioridad si OK
}
vrrp_instance VI_1 {
    interface eth0
    state MASTER # "BACKUP" en el servidor de respaldo
    priority 101 # 101 en el master, 100 en el respaldo
    virtual_router_id 51
    smtp_alert # Activar notificaciones SMTP
    authentication {
        auth_type AH
        auth_pass PASSWORD
    }
    virtual_ipaddress {
        10.1.1.80
    }
    track_script {
        chk_haproxy
    }
}

Finalmente iniciamos el servicio service keepalived start.
Y con estos sencillos pasos ya tenemos nuestro frontend web balanceado en alta disponibilidad.
Espero que los disfrutéis 😉
Referencia usada http://haproxy.1wt.eu/download/1.3/doc/architecture.txt