Primero un poco de contexto. APT son las siglas de Advanced Package Tool, una interface del sistema de paquetes de Debian Linux (y derivados). APT ofrece un conjunto utilidades para administrar paquetes (librerías y aplicaciones). Adicionalmente existen aplicaciones de más alto nivel como (Aptitude o Synaptic) que utilizan APT. A su vez APT utiliza otro utilitario llamado dpgk. O sea que la cadena de dependencias es: Aptitude => APT => dpgk. En particular quiero referirme a APT pues es la herramienta que más suelo utilizar de este conjunto.

APT (apt-get o simplemente apt dependiendo de la versión de sistema operativo que se utilice) permite utilizar el comando install para instalar paquetes: apt install X. Así de simple. Esta sentencia en términos simplificados consulta un conjunto de repositorios en la nube para ubicar el paquete en cuestión, lo descarga y lo instala junto con sus dependencias. De entrada el gestor de paquetes viene con una lista de repositorios y es posible agregarle repositorios adicionales. Hasta aquí todo feliz. Mucha gente utiliza APT para instalar aplicaciones en sus computadoras sin mayores complicaciones.

Sin embargo cuando uno quiere utilizar APT para configurar servidores en un contexto de software delivery pueden surgir algunas complicaciones si no se toman ciertas precauciones. Es aquí donde esta herramienta se convierte en un arma de doble filo y de ahí la idea de escribir este artículo.

El punto clave a tener presente es que muchas veces cuando uno ejecuta apt install X no especifica la versión de X, con lo cual los resultados pueden no ser los esperados. Cada versión de sistema operativo viene con ciertas referencias a repositorios y esos repositorios contienen ciertas versiones de paquetes que pueden o no ser las que uno requiere. Se abren aquí un par de opciones:

• Verificar la versión del paquete que instalaría APT por default
• Si la versión default a instalar por APT no es la buscada, ver si existe algún paquete con la versión que queremos. Esto podría requerir agregar alguna nueva entrada a la lista de repositorios.
• Si no se encuentra un paquete APT para la versión que buscamos, entonces tendremos que utilizar algún método alternativo.

Más allá de esto, cuando se trata de servidores de aplicaciones/runtimes yo me inclino por seguir las instrucciones de instalación del propio producto en lugar de utilizar APT (en algunos casos el propio producto recomienda APT como método de instalación).

A partir de un pedido de un cliente he empezado trabajar en un nuevo módulo para la versión 5 del taller. Este módulo estará enfocado en el ecosistema Docker (particularmente Swarm, Compose y Kubernetes) y en cuestiones de monitoreo y logging. Estimo que esto podría llegar a extender la duración del taller unas 3 o 4 horas adicionales.

Esta semana debería terminar de completar el contenido conceptual (diapositivas) y la semana próxima debería comenzar a trabajar en el diseño de los ejercicios. Una vez tenga estos ejercicios completos será hora poner fecha para el estreno de esta versión, lo cual con viento a favor será hacia fines de agosto.

Recientemente me he encontrado hablando con varios colegas sobre posibles estrategias para «adoptar» DevOps y eso me llevó a poner por escrito lo que viene siendo mi estrategia preferida cuando me toca participar.

De cara  lograr una adopción efectiva de una estrategia DevOps y considerando las experiencias en organizaciones de distinta índole en las que he estado involucrado mi propuesta consiste en 3 fases:

Fase 1: assessment
Me gusta comenzar realizando una primer reunión con quien será el sponsor de esta iniciativa de cara a  asegurar la intención/motivación de todos los sectores involucrados: negocio + desarrollo + operaciones.
Luego suelo pedir al sponsor que encuentre dos equipo de desarrollo que quieran recorrer este camino y que actualmente sea conscientes de algunas limitaciones/situaciones que quieran resolver/mejorar a partir de una iniciativa DevOps. Como siguiente paso propongo realizar un par de entrevistas (~30 minutos) con los equipos identificados y también con gente de las otras área (negocio y operaciones)
Esta fase cierra con un informe y una propuesta de plan a corto plazo y una visión a largo plazo. Para este trabajo estimo un esfuerzo de unas 10 horas máximo y debería poder ejecutarse en 1 semana (o eventualmente 2 semanas si se complica agendar las reuniones). Más allá de las particularidades del caso, la propuesta es trabajar bottom-up, generando consenso desde la gente que realiza el trabajo en el día a día. Esto difiere de otras estrategias muy comunes, generalmente de tipo top-down: los jefes/gerentes/directivos definen como los developers deben trabajar.

Fase 2: exploración
Partiendo de lo realizado en la fase anterior, empiezo a trabajar con 1 de los equipos identificados durante 3 iteraciones (asumiendo que el equipo trabaja en forma iterativa). Yo me sumo al equipo en forma part-time para ayudar en la mejora actuando de coach tanto en lo técnico como en la gestión y coordinación con las otras areas.
Durante la primer iteración relevo el proceso y los impedimentos, y establecemos métricas que nos permitan medir objetivamente el estado actual y la potencial mejora.
Al cabo de dos iteraciones más, debería empezar a notarse alguna mejora en las métricas. En este punto hacemos un checkpoint y vemos si mi participación ha generado alguna mejora razonable y en base a ello decidimos mi continuidad o no.
Aproximadamente en la sexta iteración el equipo ya debería tener una mejora visible y podríamos empezar a replicar el proceso con un segundo equipo.
Habiendo recorrido este camino de mejora con al menos 2 equipos, estamos en condiciones de refinar la visión y definir un plan de implementación a mediano plazo.

Fase 3: expansión
En esta fase trabajamos en implementar el plan de mediano plazo y deberíamos poder generar líderes internos que serán los encargado de materializar el plan de largo plazo. Es aquí donde comenzar a intentar formalizar acuerdos y convención sumando iterativamente más gente a la iniciativa.

 

El miércoles pasado estuve dando una charla en el meetup de Madriagil en las oficnias de RyanAir Madrid.

Agradezco a Israel Alcázar por la coordinación y a David Cuesta por ser anfitrión de este encuentro

Hubo alrededor de unos ~20 participantes. La evaluación general de la charla fue de 4.1/5.

Los slides de la utilizados durante la presentación está disponibles aquí.

Comparto aquí algunas fotos del encuentro.

My DevOps Practices Tutorial covers a set of tools that my not be easy to setup, so I created a Vagrant configuration to simplify this setup. It does not matter if have no idea about vagrant (you will learn about it during the tutorial) but ensure to perform the following tasks before attending the tutorial session:

1. Install Git
2. Install Virtual Box (version 5 o newer)
3. Install Vagrant (version 2 o newer)
4. Download this vagrantfile and place it in a directory
5. Open a terminal and move to the directory where you placed the vagrantfile
6. Run the command vagrant up, it will download some stuff from the cloud, so it may take some time (depending on your connection it could take around ~10 minutes)
7. When the vagrant up completes, you should the message «Welcome to NicoPaez DevOps tutorial»