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.

Monitoreo de Docker

Podemos poner a correr uno, dos o más dockers sin problema, podemos armarnos un docker-compose.yml que se encargue de levantar redes, definir volúmenes, correr dockers en órden de dependencia, en fin, podemos tener dockers corriendo… pero después, ¿cómo sabemos por qué nuestro sistema está lento? ¿por qué el host se queda sin memoria?

Claro que tenemos las herramientas de siempre: top, vmstat, htop … por nombrar algunas. Pero desde el host vemos el 100% de los procesos, pero no los contenedores responsables.

Asi que esta es una lista de las herramientas que utilizo para monitoreo de docker:

CTOP

Un top, pero por contenedor, como si cada contenedor fuera un proceso

ctop

https://github.com/bcicen/ctop

y en mis servidores lo incluyo (mediante una task de ansible) en este alias:

alias ctop='docker run --rm -ti \
   -v /var/run/docker.sock:/var/run/docker.sock:ro \
   quay.io/vektorlab/ctop:latest'

LazyDocker

Un panel en la consola para todo tu docker (imágenes, docker corriendo, volúmenes) que te permite ver logs, stats, etc. y algunas acciones basicas como stop/start, delete, etc…. y todo todo sensible al mouse (click!) y por SSH

lazydocker

https://github.com/jesseduffield/lazydocker

y en mis servidores ansible lo deja configurado asi:

alias lazydocker='docker run --rm -it \
  -v /var/run/docker.sock:/var/run/docker.sock \
  lazyteam/lazydocker'

Si conoces alguna otra herramienta, compártela en los comentarios.

Vagrant: Ignoring gem because its extensions are not built.

Comenzando cursos actualicé a la última version de vagrant y comencé a tener un error en las gemas de ruby instaladas:

$ vagrant version
Ignoring nokogiri-1.10.5 because its extensions are not built.  Try: gem pristine nokogiri --version 1.10.5
Ignoring ovirt-engine-sdk-4.3.0 because its extensions are not built.  Try: gem pristine ovirt-engine-sdk --version 4.3.0
Installed Version: 2.2.7
Latest Version: 2.2.7

You're running an up-to-date version of Vagrant!

Si bien todo el funcionamiento de vagrant que probé no tenía problemas, el error aparecía previo a la ejecución de cada comando vagrant.

Las sugerencias sugeridas de correccion de ejecutar gem no funcionaron tuve unos errores de permisos.

Revisando documentación vi que el error podría estar en el código de los plugins de vagrant (que agregan funcionalidad) y ejecuté el comando para borrarlos y reinstalarlos:

$ vagrant plugin expunge --reinstall

This command permanently deletes all currently installed user plugins. It
should only be used when a repair command is unable to properly fix the
system.

Continue? [N]: y

All user installed plugins have been removed from this Vagrant environment!

Vagrant will now attempt to reinstall user plugins that were removed.
Installing the 'vagrant-aws' plugin. This can take a few minutes...
Fetching: iniparse-1.5.0.gem (100%)
Fetching: xmlrpc-0.3.0.gem (100%)
Fetching: formatador-0.2.5.gem (100%)
[...]
Fetching: faraday_middleware-0.14.0.gem (100%)
Fetching: vultr-0.4.3.gem (100%)
Fetching: vagrant-vultr-0.1.2.gem (100%)
Installed the plugin 'vagrant-aws (0.7.2)'!
Installing the 'vagrant-cachier' plugin. This can take a few minutes...
Installed the plugin 'vagrant-cachier (1.2.1)'!
Installing the 'vagrant-scp' plugin. This can take a few minutes...
Installed the plugin 'vagrant-scp (0.5.7)'!
Installing the 'vagrant-vultr' plugin. This can take a few minutes...
Installed the plugin 'vagrant-vultr (0.1.2)'!

La reinstalación como se puede ver, descargó nuevamente las gemas y las compiló junto con el plugin actualizado. Esto solucionó el problema definitivamente:

$ vagrant version
Installed Version: 2.2.7
Latest Version: 2.2.7

You're running an up-to-date version of Vagrant!

Espero esta información sea de utilidad pues me llevó un rato interesante llegar a la solución.

El primer contenedor Docker

La primera vez que se presentó un contenedor Docker en forma pública lo hizo Solomon Hykes en la conferencia PyCon Santa Clara de 2013.

Es increíble y emocionante cómo Solomon describe rápidamente lo que hace un contenedor (minuto 2:30) que ejecuta un simple echo hello world.

  1. se genera la configuración de un contenedor
  2. se aloja el filesystem (se copia la imagen a una carpeta)
  3. se monta la capa de escritura del contenedor
  4. se configura la interfaz de red
  5. se gestiona una dirección IP y se configura
  6. se configura un NAT para comunicar el contenedor
  7. se ejecuta el comando y se despliega la salida
  8. se apaga el contenedor (o se destruye)

e inmediatamente recibe un aplauso del público, que asiste emocionado a lo que nosotros hoy día hacemos normalmente, sin emoción.

Publicar la llave pública SSH

Los principales repositorios (Gitlab y Github) exponen las llaves públicas SSH de sus usuarios de forma que están accesibles para descarga:

https://(gitlab|github).com/<usuario>.keys

Es la URL de donde se obtienen, y aquí las mías:

La ventaja es tener un sitio disponible donde está nuestra clave (y la de nuestros colegas) para usar en automatismos como esta task de Ansible:

- name: Enable pilasguru root access
  authorized_key:
    user: root
    state: present
    key: https://gitlab.com/pilasguru.keys
    validate_certs: False

Tabla periódica del DevOps

La empresa XebiaLabs mantiene una tabla periódica de las herramientas para DevOps que es una forma muy interesante de tener tanto nombre y herramientas ordenados en una forma visual y comprensible.

Las herramientas listadas tiene cada una un enlace que lleva a información adicional.

Fuente: PERIODIC TABLE OF DEVOPS TOOLS