Renombrar volumen Docker

El cliente docker tiene un conjunto de opciones destinadas a administrar volúmenes (docker volume), pero ninguna de ellas permite renombrar un volumen existente.

Me puse a investigar cómo hacerlo y me fui a ver el filesystem y a buscar la carpeta que representa el volumen y hacer el cambio allí, pero cuando investigaba para no dañar la configuración me encontré con esta solución que me pareció muy filosofía docker, inclusive es lo que se hace para copiar un disco en una nueva unidad:

docker volume create --name <nuevo_volumen>
docker run --rm -it -v <viejo_volumen>:/from -v <nuevo_volumen>:/to alpine ash -c "cd /from ; cp -av . /to"
docker volume rm <viejo_volumen>

En definitiva se trata de crear un nuevo volumen, lanzar un contenedor que monta el volumen viejo y el volumen nuevo y copia los datos de uno a otro, y finalizar borrando el viejo volumen. Simple, seguro, y elegante.

La idea no es mía, la obtuve de este issue de Github, donde incluso alguien propone un script:

$ docker-rename-vol viejo-volumen nuevo-volumen

#/bin/bash
docker volume create --name $2
docker run --rm -it -v $1:/from -v $2:/to alpine ash -c "cd /from ; cp -av . /to"
[ $? -eq 0 ] && docker volume rm $1

Y ahora, está aquí mi blog para tenerlo presente.

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.

Remover dominio de certificado Let’s Encrypt

Tengo un sitio que responde por varios dominios y, a su vez, con y sin www, por lo que el certificado let’s encrypt tiene un Nombre Común y varios Nombres Alternativos.

$ certbot-auto certificates
  Certificate Name: cert.com
    Serial Number: 40d6f1a43875cf95b5eeb284c2902060d8e
    Key Type: RSA
    Domains: cert.com dom.com test.us play.cert.com win.cert.com www.cert.com www.dom.com www.test.us
    Expiry Date: 2021-04-04 15:33:09+00:00 (VALID: 79 days)
    Certificate Path: /etc/letsencrypt/live/cert.com/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/cert.com/privkey.pem

resulta que de este certificado se había cancelado, borrado, eliminado el sitio win.cert.com por lo que necesitabamos bajarlo del DNS también. Si no modificamos el certificado, la próxima renovación automática de Let’s Encrypt produciría un error al no poder validar la existencia del sitio.

El procedimiento para eliminar un dominio es borrar el certificado en primer lugar:

$ certbot-auto delete --cert-name cert.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
The following certificate(s) are selected for deletion:

  * cert.com

Are you sure you want to delete the above certificate(s)?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
(Y)es/(N)o: (Y)es/(N)o: (Y)es/(N)o: (Y)es/(N)o: (Y)es/(N)o: 

Al borrar el certificado no se afecta el servidor web que está corriendo, mientras el servidor no sea reiniciado.

Y se puede volver a tramitar un certificado, ahora con la lista de dominios excluyendo el que se quiere elimintar:

$ certbot-auto certonly -d cert.com -d cert.com -d dom.com \
  -d test.us -d play.cert.com -d www.cert.com -d www.dom.com \
  -d www.test.us

How would you like to authenticate with the ACME CA?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
1: Nginx Web Server plugin (nginx) [Misconfigured]
2: Spin up a temporary webserver (standalone)
3: Place files in webroot directory (webroot)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
Select the appropriate number [1-3] then [enter] (press 'c' to cancel): 2
Plugins selected: Authenticator standalone, Installer None
Requesting a certificate for cert.com and 6 more domains

Espero le sea útil a alguien más.

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

Deepin

Ya hace tiempo que vengo utilizando Deepin como mi distribución de escritorio de Linux. Es algo que podemos cambiar, pero hace tiempo que Deepin es mi distribución preferida a la hora de montar un desktop.

Se trata de una distribución para desktop que busca ser elegante y fácil de utilizar para el usuario promedio.

No solo viene out-of-the-box con el software que uno espera (navegador Chrome, Correo Thunderbird, etc.) sino que trae algunas aplicaciones propias que buscan seguir la misma idea de sencillez y elegancia como un centro de aplicaciones (Deepin Store), Deepin ScreenShot y multimedia con Deepin Music y Deepin Movie.

Para ofimática viene ya pre-instalado todo el WPS Office que busca seguir la estética de los ciéntos de íconos y sub-menúes del MS-Office.

La base es GNU/Debian Linux, por lo que esta todo, todo lo demás que quieras instalar para personalizar tu deepin.

Hay una barra de aplciaciones preferidas donde puedes anclar tus aplicaciones más usadas y un launcher para buscar y lanzar tus aplciaciones.

El Centro de Control es un panel que se despliegua a la derecha y permite hacer tus configuraciones.

Es lindo, me gusta y lo uso y recomiendo y aquí está el enlace al sitio en español.

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