Había una vez un WordPress

Erase una vez un bonito blog WordPress … que corría feliz y libre por las tierras de una instancia. Allí era muy amígo de MySQL que también había nacido en esa misma instancia, y que se dedicaba a guardar los datos que, casi en secreto, le daba WordPress. Entre los dos habían creado una parcela en wp-config donde plantaban y cosechaban archivos. El orgulloso dueño de la instancia agregaba cada tanto algun plugin para lograr mejores resultados o modificaba el entorno para hacerlo más bonito, con cambios desde el galpón de themes.

Fue una época de felicidad.

Pero aparecieron «Los Innovadores» que le plantearon al dueño de la instancia muchas dudas: ¿que pasa si se cae? ¿hasta cuántos clientes simultáneos puedes recibir? ¿cómo lo migras? ¿es resiliente?

Y así el dueño de la instancia no conseguía conciliar el sueño. Por las noches se levantaba y miraba temeroso la instancia, consultaba las gráficas y el monitor, hasta hablaba con otros dueños de otras instancias.

Una noche, en que el dueño de la instancia caminaba por enésima vez en su sala, abrumado por el temor de que algo le pasara a su bonito blog, se presentó un hada que brillaba en la oscuridad y, tras enterarse de las preocupaciones del dueño de la instancia, solo le pronunción un conjuro mágico:

ku-ber-ne-tes

El rostro del dueño de la instancia se iluminó con el brillo equivalente al que emitida el hada. Esa noche, luego de mucho tiempo, logró volver a dormir y se selló el destino del blog.

A la mañana siguiente WordPress fue arrancado de la instancia que lo vió nacer para ser clonado en un laboratorio de última tecnología y nunca más se tuvo noticia ni de él ni de su felicidad. Ahora WordPress era una imágen que se ponía a correr, ya no en una instancia… ahora en un cluster, que es un lugar que no se sabe bien dónde queda.

MySQL, su fiel y productivo compañero, tuvo una peor suerte: fue sacrificado.

De aquella hermosa instancia solo quedó una valija con lo que había en la parcela wp-content y un pequeño estuche que contenía aquello que con amor habían juntado WordPress y MySQL: los datos SQL.

Ahora el blog pasó al control profesional de un Team de Desarrollo. Los datos SQL fueron entregados a la custodia de un Señor RDS, quién con mucha sobriedad entregó a cambio un Contrato de Calidad de Servicio. El contendio de aquella hermosa parcela wp-content fue desplegado en un volúmen (¿EBS?) que con entiquetas y unos pases mágicos de volumen claim permite que accedas a su contenido.

Nunca más se sintió felicidad, pero ahora el Team de Desarrollo tenía respuestas para todas aquellas dudas que atormentaron en el pasado.

Hasta el día que un desarrollador junior del del Team de Desarrollo abríó un mensaje en el Slack que decía:

«Voy a hacer una modificación, pero quisiera hacerlo en una copia ¿cómo hago?»

Eso… eso es otra historia… más triste aún.

screencast

OpenStack Mitaka, instalación Just For Fun

Siguiendo mi anterior artículo sobre mis primeras impresiones sobre OpenStack Mitaka, aquí está un breve screencast de unos minutos sobre como instalarlo en un ambiente virtualizado con Virtualbox y Vagrantfile:

El archivo Vagrantfile necesario para la instalación, es el siguiente:

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure(2) do |config|
  config.vm.box = "puppetlabs/centos-7.2-64-nocm"

  config.vm.network "forwarded_port", guest: 80, host: 8080
  config.vm.synced_folder ".", "/vagrant", disabled: true

  config.vm.provider "virtualbox" do |vb|
    vb.cpus = 2
    vb.memory = "4096"
  end

  config.vm.provision "shell", inline: <<-SHELL
     sed -i s/enabled=1/enabled=0/ /etc/yum.repos.d/epel.repo
     yum -y update
     systemctl stop NetworkManager 
     systemctl stop firewalld
     systemctl disable NetworkManager 
     systemctl disable firewalld
     systemctl enable network
     setenforce 0
     echo -e "LANG=en_US.utf-8\nLC_ALL=en_US.utf-8" > /etc/environment
     yum install -y https://www.rdoproject.org/repos/rdo-release.rpm
     yum update -y
     yum install -y openstack-packstack vim
     packstack --gen-answer-file=/root/answers.txt
     sed -i s/CONFIG_CINDER_INSTALL=y/CONFIG_CINDER_INSTALL=n/ /root/answers.txt
     sed -i s/CONFIG_SWIFT_INSTALL=y/CONFIG_SWIFT_INSTALL=n/ /root/answers.txt
     sed -i s/CONFIG_CEILOMETER_INSTALL=y/CONFIG_CEILOMETER_INSTALL=n/ /root/answers.txt
     sed -i s/CONFIG_AODH_INSTALL=y/CONFIG_AODH_INSTALL=n/ /root/answers.txt
     sed -i s/CONFIG_GNOCCHI_INSTALL=y/CONFIG_GNOCCHI_INSTALL=n/ /root/answers.txt
     sed -i s/CONFIG_NAGIOS_INSTALL=y/CONFIG_NAGIOS_INSTALL=n/ /root/answers.txt
  SHELL
end

Confío esto sea de utilidad para que puedas probar OpenStack.

OpenStack Mitaka

La versión 13 del sistema operativo para computación en la nube ya está entre nosotros: OpenStack Mitaka. Para esta versión de OpenStack han colaborado activamente un total de 2,336 desarrolladores, ingenerios, administradores de sistemas y usuarios que representan un total de 345 organizaciones.

Recién ahora, a los siete días de su release he conseguido hacerme un tiempo para probarla, aunque más no sea instalar y algun uso simple; pero enseguida se aprecian las mejoras que se publicitan en la nota de prensa. Aquí adjunto algunas de mis capturas.

Administración simplificada

Mitaka incluye numerosas mejoras que facilitan el uso y las tareas diarias de quienes interactúan con la nube y la administran. Responde con bastante celeridad a los comandos, lo que evidencia un gran desarrollo en el motor de software:

Comandos OpenStack.

y también la interfaz web Horizon se percibe muy ágil, con mucha interacción de tirar y arrastrar, logrando que las tareas sean más visuales y rápidas.

Mejor escalabilidad

Mitacka tiene muchos avances para mejorar la escalabilidad de las nubes OpenStack, por ejemplo el orquestador Heat ahora puede encargarse de mayores exigencias de trabajo y más complejas acciones de escalabilidad automatizada. Las mejoras en el gestor de permisos y usuarios keystone han reducido mucho los tiempos de respuesta.

Proyecto OpenStack

Mejorar la experiencia de usuario

Es el punto de Mitaka que más he notado, como ya he hecho referencia en la interfaz web Horizon. Por ejemplo así es como se ven la topología de red ahora (utilizando un despliegue gráfico que ya tenía Ceilometer desde versiones anteriores) :

Topologia de Red

Pero también ahora hay un cliente unificado OpenStack Client que permite mediante un solo comando dar instrucciones a todos los servicios del stack OpenStack.

openstack --help

Recién lo estoy mirando y sorpendiéndome, trataré de seguir profundizando sobre Mitaka en futuros artículos.

Packer crea tus imágenes en cualquier lugar

hero_image-d2e0f00a

Desde que Martín Loy me sugirió probar Packer para crear mis propias imágenes (box) para Vagrant he descubierto una herramienta que me ha dado muchas satisfacciones.

A partir de una simple descripción en un archivo json, Packer crea una máquina virtual en múltiples plataformas, instala el sistema operativo y lo aprovisiona, para finalizar creando una imagen de dicha máquina virtual para futuros usos.

Así Packer puede crear una AMI para Amazon EC2,  un snapshot para DigitalOcean, Docker, o Google Compute Engine, una imagen para OpenStack o Qemu, un OVF para Virtualbox, un VMX para VMWare o un box para Vagrant.

A partir de la ejecución un único comando

$ packer build centos-7.1.1503-x86_64.json

se obtiene una imágen pronta para re-utilizar las veces que sea necesarias.

==> Builds finished. The artifacts of successful builds are:
--> virtualbox-iso: 'virtualbox' provider box: build/centos-7.1.1503-x86_64.box

Con la ventaja de poder «perfeccionar» la descripción json y volver a generar una imágen cada vez más adecuada para las necesidades personales.

Hay que reconocer que la gente de HashiCorp tiene muy claro los conceptos de automatización.

docker-machine para embarcar tus contenedores donde quieras

Captura del Puzzle Docker para Android de dockerapps
Imágen del Puzzle Docker para Android de dockerapps

Hacía tiempo, como dos meses, que no me soprendía con «magia informática» ya que acabo de ver docker-machine (sí, dos meses es bastante tiempo en informática, como para empezar a notar óxido intelectual).

Venía utilizando boot2docker para levantar una máquina virtual porta-contenedores que me permitía embarcar en ella mis docker; pero en la última actualización me avisa que es un comando ‘deprecated‘ y me refiere a docker-machine.

Luego de instalarlo (brew install docker-machine) me doy cuenta la notoria evolución que representa docker-machine: permite levantar una instancia/máquina-virtual porta-contenedores en mi notebook (virtualizando con virtualbox o vmware), en una nube (amazon, azure, digitalocean, google, rackspace, openstack, softlayer, etc) o en mi datacenter (openstack, vmwarevsphere), y, a partir de ahí, puedo empezar a embarcar mis contenedores.

El proceso es bien simple:

1. Crear porta-contenedores

Comando para VirtualBox local de nombre ‘vbdev

$ docker-machine create -d virtualbox \
        --virtualbox-memory "5120" \
        vbdev

Comando para DigitalOcean para un ‘droplet‘ en Amsterdam de 1GB ram de nombre ‘dodev

$ docker-machine create --driver digitalocean \
	--digitalocean-access-token "6d0c7..a0bfa" \ 
	--digitalocean-image "ubuntu-14-04-x64" \
	--digitalocean-region "ams1" \
	--digitalocean-size "1gb" \
	dodev

Para hacer esto, docker-machine crea certificados OpenSSH, se valida contra el sistema de cloud o virtualización, provisiona la instancia de acuerdo a la configuración solicitada y registra los accesos.

2. Activar el entorno del porta-contenedores que se va a utilizar

Por ejemplo, el entorno del porta-contenedor en DigitalOcean

$ eval "$(docker-machine env dodev)"

que permitirá a docker hacer las conexiones para administrar los contenedores.

3. Comenzar a embarcar los contenedores de forma acostumbrada

$ docker run hello-world

Como es de esperarse, docker-machine permite toda la administración de nuestro porta-contenedores donde quiera que esté, es decir, iniciarlo, detenerlo, borrarlo, reiniciarlo, obtener su configuración, actualizarlo, etc.

También acceder al porta-contenedor

$ docker-machine ssh dodev

y obtener la lista de todos nuestros porta-contenedores y su estado actual:

$ docker-machine ls
NAME    ACTIVE   DRIVER         STATE     URL                         SWARM
dev              virtualbox     Stopped                               
dodev            digitalocean   Timeout                               
vbdev            virtualbox     Running   tcp://192.168.99.100:2376   

Paso siguiente: docker-compose para instalaciones multi-contenedor.

Diferencias entre Computación en la Nube (cloud) y Virtualización

Water_and_oil

La virtualización es uno de los principales componentes de la computación en la nube (cloud computing), pero virtualización no es computación en la nube.

La computación en la nube se basa en la virtualización para ofrecer infraestructura (cómputo, red, disco) a distintos consumidores (clientes) en la modalidad de servicios (IaaS, PaaS, SaaS, DBaaS).   La virtualización da una visión virtual de algo físico, como el sistema operativo, los dispositivos de red, los servidores.

Con virtualización se toma un determinado dispositivo físico que se divide en virtuales del mismo tipo.  Con computación en la nube se suman dispositivos virtuales que se van alojando sobre múltiples dispositivos físicos.

De esta forma la nube permite tener alta disponibilidad de servicios, rápida escalabilidad, automatización y la posibilidad de que los dispositivos físicos estén en diferentes áreas geográficas.

Entonces, dependiendo de cómo los dispositivos físicos que componen la nube están expuestos sobre Internet podemos tener nubes privadas, públicas, híbridas o cooperativas.

La computación en la nube necesita de la virtualización, es uno de sus componentes básicos.  Pero la virtualización por si sola no es computación en la nube, o sea, es necesaria pero no suficiente.

[ Basado en el artículo de Joaquín Calvo publicado en IngloriousDevOps ]

Datacenter en la nube

Si bien tener servidores hosteados o colocados en datacenter tercerizados o en la nube es algo bastante común, el concepto de tener todo el datacenter en la nube no es habitual.  Cuando me refiero a todo el datacenter quiero decir, obviamente, todo:  a las sub-redes, a los firewall de borde, a las DMZ, a los storage y sus redes, a las bases de datos y sus réplicas, al sistema de respaldo, etc. etc., es decir, todo el datacenter.   Es un concepto fácil de comprobar ya que en la empresa solamente están los desktop y la conexión con Internet.

clouddatacenter

Me presentaron este concepto en el DevOps Meetup de agosto del año pasado, cuando Ignacio Nin mostró como administra un datacenter 100% en la nube.  Y luego tuve la suerte de invitarlo al curso de Cloud Computing en la Universidad Católica del Uruguay y allí volvió sobre el tema «Organizando un Datacenter virtual en la nube«.

Lo que ahora llama mi atención es que esto se ha vuelto una tendencia y ha sido reconocido como uno de los desafíos para el 2015 por varios analistas y expertos.  Tan solo hacer una búsqueda sobre «10 trends cloud computing» vemos que este concepto se repite una y otra vez, por cada uno que ha escrito del tema.

Si bien creo que en Uruguay estamos bastante «en pañales» en el tema cloud computing, también creo que el concepto de tener todo el datacenter fuera de la empresa es bastante inevitable para muchas organizaciones.  No hablo de subir todo a Amazon. Me refiero a crear de infraestructura y prestadores de servicios locales, hablo de empresas y organziaciones solo con desktop y conexión a Internet y un datacenter por ahi.

Y es inevitable también porque me consta el esfuerzo que hacen muchas organizaciones y empresas para tener sus cinco o diez servidores, con respaldo eléctrico, aire acondicionado, cableado estructurado, seguridad física, etc. para algo que perfectamente pueden, digamos, «dibujar» y obtener el mismo nivel de servicio y seguridad.

OpenShift

openshift

A partir del 8 de diciembre de 2014, este blog está alojado en OpenShift, el PaaS de RedHat y quiero compartir mi experiencia de uso y configuración de un PaaS.

Un PaaS es servico al cual se le entrega la aplicación y más o menos auto-mágicamente la aplicación queda presentada en Internet.  En el caso de este blog la aplicación es WordPress por lo que me limité a subir el código  (de mi template, idioma, etc.) y mis datos (archivos) y aquí lo estás viendo.  Por otro lado, el PaaS permite despreocuparse de la infraestructura y la plataforma, es decir, que no debo pensar en la versión del sistema operativo ni su actualización, su configuración, las políticas de seguridad, la red, los usuarios, en fin, nada que no sea estrictamente mi aplicación.

Obviamente, un servicio PaaS es más caro que un servicio de infraestructura de cloud computing (IaaS), el cual a su vez es más caro que un simple VPS fuera de una arquitectura de cloud computing, solamente por el hecho de que hay servicios que alguien está prestando y sobre los que tu no debes preocuparte.

Pero volviendo a OpenShift debo decir que mi primer impresión ha sido muy positiva y creo que hay cosas que diferencian a esta oferta de PaaS sobre otras.

OpenShift ofrece «contenedores» que llama gears y que en la cuenta gratis se pueden tener hasta 3 de los más chicos.  Los gears poseen quota de recursos por cgroups y están orientados a alojar una aplicación cada uno.  Si bien se podría alojar más de una aplicación, solo un dominio internet puede referenciar a cada gear y creo que no vale la pena el esfuerzo intelectual e alojar muchas aplicaciones en uno solo y luego mantenerlas.

Adicionalmente, Openshift ofrece servicios que pueden ser incoprorados a un gear y que llama cartridges. De esta forma se puede levantar un gear con PHP y luego agregarle MySQL, luego CRON, luego POSTFIX, etc., según la aplicación vaya requiriendo.

Aquí dejo un esquema de la arquitectura de openshift completa:

openshiftcompletepicture

aunque sugiero ir a un sitio interactivo que explica cómo OpenShift funciona de una forma muy dinámica y comprensible.

Openshift ofrece aplicaciones pre-instaladas con las cuales iniciar un gear, como WordPress, Cacti, Redmine, Drupal, OwnCloud, Tomcat, Node.JS, etc., o simplemente lenguajes para luego montar nuestra propia aplicación; Ruby, Python, Java, PHP.

Captura de pantalla 2014-12-09 a las 3.28.29 PM

Una vez arrancado el gear con la aplicación pre-instalada se clona un repositorio git y luego se modifica la aplicación localmente, para hacer un ‘git push’ con los cambios, que quedan activados inmediatamente.

Para administrar openshift, además de la interfaz web, existe una herramienta de línea de comando muy simple de instalar con ruby. Pero lo que realmente me enamoró de OpenShift es la posibilidad de poder hacer ssh al gear y tener línea de comandos; poder subir mis datos (yo hice una migración) mediante scp o rsync, lo que acerca OpenShfital nivel que conozco (de IaaS) y en el cual me siento cómodo.

No he utilizado otros PaaS, pero a mi me ha resultado simple poner mi blog y mi wiki a correr en OpenShift; con una pequeña curva de aprendizaje para conocer su filosofía de trabajo para el mantenimiento de mi aplicación y mis datos, ya ven todo online.

 

Servicio de identificación en OpenStack

El servicio de identificación (keystone) de OpenStack realiza las siguientes funciones:

  • Controla los usuarios y sus permisos.
  • Expone el catálogo de los servicios disponibles para ser consumidos mediante API.

Cada servicio instalado se debe registrar en Keystone, de esta forma se estará controlando el acceso a cada uno y cómo está disponible en la red.

Para comprender el servicio de identificación, es necesario entender estos conceptos:

User / usuario
Representación de una persona, sistema o servicio que utiliza OpenStack. El servicio de identificación permite validar los pedidos que son hechos por el usuario.  Los usuarios pueden ingresar y obtener tokens para acceder a recursos.  Los usuarios son asignados a un proyecto en particular y quedan contenidos dentro del proyecto.
Credentials / credenciales
Datos que confirman la identidad de un usuario. Por ejemplo: nombre de usuario y clave,  nombre de usuario y llave API, o token obtenido del sistema de identificación.
Authentication / autenticación
El proceso de confirmar la identidad de un usuario. El servicio de identificación confirma un pedido validando un conjunto de credenciales que envía el usuario.

Estas credenciales son inicialmente el nombre y la clave, o el nombre de usuario y una llave de API. Cuando el usuario se valida, el sistema de identidad emite un token de autenticación que el usuario puede usar para pedidos futuros.

Token / pase
Es una cadena de texto alfanumérica utilizada para acceder a la API y recursos de OpenStack. Este pase puede ser revocado en cualquier momento y es valido por un período determinado.

Actualmente el sistema de identificación de OpeneStack soporta autenticación mediante token aunque la intention es soportar protocolos adicionales en el futuro. El objetivo principal es ser un servicio de integración y no se aspira a dar una solución integral de administración de identificación.

Tenant / beneficiario

Es un contenedor para agrupar o aislar recursos. Dependiendo del servicio, un tenant puede ser un cliente, una cuenta, una organización o un proyecto.
Service / servicio
Un servicio de OpenStack, como ser de cómputo (nova), para guardar objetos (swift), de imágenes (glance). El servicio presenta uno o más endpoints mediante los cuales los usuarios pueden acceder a los recursos y realizar operaciones.
Endpoint / llegada

Es una dirección de red accesible para acceder a un servicio, usualmente una URL. Si se utiliza una extensión de perfiles (templates), un perfil de endpoint puede ser creado, el cual representa todos los servicios que pueden ser consumidos y que están disponibles entre las regiones.

Una personalidad con un conjunto definido de permisos de usuario y privilegios para realizar operaciones específicas.

En el servicio de identificación, un token que es emitido a un usuario que incluye una lista de roles. Los servicios que están siendo invocados por un usuario determinan cómo serán interpretados los conjuntos de roles que dicho usuario tiene y a cuáles operaciones o recursos se tendrá acceso.

Keystone Client / cliente de keystone
Una interfaz de línea de comando para el API keystone de identificación de OpenStack. Por ejemplo, los usuarios podrán ejecutar keystone service-create y keystone endpoint-create para registrar servicios en sus instalaciones de OpenStack.

El siguiente diagrama muestra el proceso de identificación de OpenStack:

Keystone

Este texto es la tradicción directa del manual de OpenStack con algunos agregados y modificaciones básicas que entiendo mejoran la comprension.

Administración de llaves SSH para aplicaciones

Las llaves de SSH permiten, por defecto validar la conexión al destino y cifrar el tráfico entre el cliente y el servidor. Con algo de configuración es posible validar el orígen contra el servidor y de esa forma en lugar de conocer la clave para acceder, la validación es por certificados. Cuando empezamos a utilizar aplicaciones y a automatizar los accesos aparecen los compromisos de seguridad, esta presentación aborda las configuraciones básicas para la administración de las llaves SSH cuando se usan para otorgar accesos a las aplicaciones.

Público objetivo: Casi cualquiera que utilice SSH para vincularse con servidores, equipos y aplicaciones remotas.

Requisitos: Conocimientos de SSH o haberlo utilizado como cliente.

Presentación realizada en:

  • 15 nov 2014 – Techmeetup 2014 – (Meetup Space) – Torre de las Comunicaciones, Montevideo, Uruguay