Herramientas varias para Docker

Quiero compartir algunas herramientas que me han resultado muy útiles al trabajar con Docker/Kubernetes.

En https://access.redhat.com/containers/ se puede encontrar una interesante cantidad de imágenes Docker curadas por Red Hat.

El Red Hat Container Development Kit, es un conjunto de herramientas para facilitar el desarrollo de contenedores. Entre estas herramientas se encuentra una variante de Minishift.

Minishift una herramienta que permite correr un cluster de OpenShift de forma local en cualquier notebook.

Source to Image es una herramienta que permite crear imágenes de una forma repetible trabajando a un cierto nivel de abstracción sin necesidad de escribir Dockerfiles.

 

Tareas de un DevOp Engineer

Hoy un colega me consultó si tenía alguna descripción de las tareas que debería hacer un DevOp Engineer y eso motivo a escribir este artículo.

Debo empezar diciendo que no estoy muy convencido de que exista la profesión  DevOp Engineer, o sea: me consta que existe pero dudo que sea conceptualmente correcta su existencia. Al margen de esto: actualmente estoy trabajando como DevOps Engineer en un proyecto, ¡ja!.

Vamos por partes: la idea de DevOps es derribar los silos organizacionales para optimizar el flujo de entrega de valor. Si tenemos un área de operaciones y un área de desarrollo, deberíamos apuntar a que comiencen a trabajar de forma más integrada. En principio no creo que eso requiera de la aparición de un nuevo rol porque en principio no hay una nueva tarea. Alguien podría pensar que sí hay una nueva tarea dentro del grupo de operaciones (o del de desarrollo) y que esa tarea es encargarse de la interacción con el otro grupo. Esto podría tener sentido (de hecho es una de las tareas que estoy haciendo en mi proyecto actual) pero no estoy convencido porque se corre el riesgo de seguir operando como silos.

Por otro lado, dependiendo del estado en que nos encontremos, puede que como parte de la iniciativa DevOps decidamos empezar a utilizar nuevas herramientas (por ejemplo para automatizar tareas). Entonces podría tener sentido incorporar un nuevo rol con conocimiento de  dichas herramientas y de los conceptos que las mismas implementan. Este es justamente mi caso: la organización a la que pertenece el proyecto en el que estoy trabajando ha decido dockerizar su infraestructura y justamente esa la razón de mi involucramiento en el proyecto.

Dicho todo esto, podríamos decir que las tareas de un DevOp Engineer incluirían principalmente:

  • Facilitar el trabajo conjunto de las área de Desarrollo y Operaciones
  • Asistir a los equipos de Operaciones y Desarrollo en las tareas de definición e implementación de arquitectura (lógica y física) de aplicaciones
  • Asistir a los equipos de Operaciones y Desarrollo en la definición e implementación de la infraestructura de CI/CD
  • Asistir a los equipos de Operaciones y Desarrollo en la definición de procesos de monitoreo.

De estas tareas se desprenden una serie de habilidades/conocimientos de distinta índole: «soft-skills», configuration management, scripting/programación, operación, etc. A mi me suena que una persona aspirante a un puesto así debería tener bastante experiencia en la profesión.

Para cerrar: lo importante es que desarrollo, operaciones y el negocio trabajen en forma conjunta, coordinada e integrada para optimizar el flujo de entrega de valor, la incorporación de un nuevo rol para lograr esto es un detalle de implementación.

 

FLISoL 2018 en UNTreF

El próximo 28 de Abril se realizará el Festival Latinoamericano de Instalación de Software Libre_ FLISoL.

Este evento de alcance continental está destinado a la difusión del Software Libre, es completamente gratuito y está dirigido a todo público. Durante el evento se realizan instalaciones de software libre, se ofrecen charlas y talleres sobre diversas temáticas relacionadas al software libre. Todo esto en forma totalmente gratuita.

El evento se realiza simultáneamente el diversas sedes y este año por segunda vez, la Universidad Nacional de Tres de Febrero será una de sus sedes. Es en esa sede precisamente donde yo estaré participando.

Fixing the Ubuntu Xenial Vagrant Box

The official vagrant box of Ubuntu Xenial 64 was initially with a issue: it didn’t have a vagrant user (according to Vagrant recommendations all boxes should have a user with name vagrant and password vagrant).

A recent release fixed the problem in a partial way: the user vagrant was added, but it is not possible to use it with password authentication (a feature that I usually need in my workshops).

So to fix this issue I created a new vagrant box based on the official Xenial box. I added the following lines in the shell provisioner:

echo "vagrant:vagrant" | sudo chpasswd
sed -i -e 's/PasswordAuthentication no/PasswordAuthentication yes/' /etc/ssh/sshd_config

The first line set the password vagrant for the user vagrant. The second line enables PasswordAuthentication.

Spring Config: a key tool for DevOps & Continuous Delivery

Spring Cloud Config (scc) is a tool that provides support to externalize application configuration in a REST Service. The big picture is:

  • Add a SCC client your application so when your application starts, it can fetch its configuration from SCC server.
  • Setup a SCC server, which is a Java REST Service (more specifically is a Spring-Boot application).

The following image offers a overview of how Spring Cloud Config fits in you application architecture.

Some benefits of this strategy are:

  • You decouple the evolution of your application from the evolution of the configuration, that is: you application will be the same in every environment while the configuration will be different in each environment. At the same time the change rate of your application is different from the change rate of the configuration.
  • Your application forgets about where the configuration it stored because it delegates that concern to SCC server.
  • SCC server supports several storage options: Git, File System, Vault, Database, ConfigMaps, etc. The default option is Git which is great because it «force» you to have your configuration versioned.
  • SCC provides several common features related to configuration management like: check the current configuration values, configuration reloading, encryption of secrets and support for different configuration formats among other things.

While working with SCC I faced some issues regarding how to specify its configuration so I want to share some details here.

To make SCC Server read configuration from a remote Git repository:

spring.cloud.config.server.git.uri=https://.....

(this would work fine for public repositories, but if you need to use a private repository, which is a common case, you will need to specify some more parameters like strictHostKeyChecking and privateKey that are very well explained in the official documentation). When SCC server starts, it will clone the remote repository into a local directory whose location will be generated randomly at runtime (but it is also possible to specify the clone location).

To make it work with a local git repository (which contains a .git subdirectory), just use:

cloud.config.server.git.uri=file:///your/local/git/repo

To make ir work with a local «plain» directory we need to specify active profile as «native» which makes SCC server to read the config from a plain local directory (not a git directory)

spring.profiles.active=native
spring.cloud.config.server.native.searchLocations=file:/your/directory

It worth mentioning that even when Spring Cloud Config is built on Java, you can use any client technology to consume it because it exposes a REST API. The Spring team provides a Java client, but there are also clients for other technologies.

 

El Perfil de los alumnos de MeMo2 @ Fiuba

La semana pasada comenzaron las clases y de cara a conocer fehacientemente el perfil de los alumnos hice una breve encuesta. Comparto aquí algunos de los resultados.

Respecto de la condición laboral, el 70% trabaja y mayoritariamente lo hace en una actividad afín a la carrera.

Respecto de la cantidad de materias que están cursando este cuatrimestre, la mayoría (55%) contestó 3. Es un número «conservador» pero inferior a la cantidad que prescribe el plan de estudios formal. Esto podría ser una explicación para el hecho de que en general son muy pocos los que completan la carrera en el plazo estipulado por el plan.

Un dato que me llamo mucho la atención es la gran dispersión en la cantidad de materias aprobadas: el alumno con menos materias aprobadas tiene 10, mientras que el alumno con más materias aprobadas tiene 27. Una explicación posible para esto es que quienes tienen más materias, han cursado varias de las electivas, mientras que quienes tienen menos, han cursado solo las obligatorias para llegar a esta materia.

Finalmente, la última pregunta apuntaba al rol en el que les gustaría desempeñarse profesionalmente a largo plazo. Me alegró ver que la gran mayoría eligió roles técnicos.

Nueva edición del Taller de Prácticas DevOps incluyendo OpenShift/Kubernetes

El próximo jueves 3 de mayo voy a dictar una nueva edición de mi taller de prácticas devops, pero esta vez con nuevo agregado: OpenShift, la plataforma de gestión de contenedores desarrollada por Red Hat y basada en Kubernetes.

Hacía tiempo que tenía ganas de incorporar al taller algún ejercicio de Kubernetes pero no lograba buscarle para vuelta para que me dieran los tiempos. Finalmente decidí sacar un ejercicio de Puppet para agregar uno de OpenShift/Kubernetes.

Los interesados en participar pueden completar este formulario y los contactaré en breve:

← Volver

Gracias por tu respuesta. ✨

 

Libros sobre estimación y planificación Ágil

Durante mucho tiempo mi libro de referencia sobre esta temática fue el clásico Agile Estimating and Planning de Mike Cohn. Pero hace un par de años lei otro libro que me pareció mucho mejor: Planning Extreme Programming, de Kent Beck y Martin Fowler. Este libro fue publicado en 2001, 5 años antes del libro de Cohn y si bien tiene mucho puntos en común con este, tiene también un conjunto de cuestiones muy prácticas que no están presentes en el libro de Cohn. Entre las cuestiones que me gustan de este libro es que sugiere como proceder cuando las cosas no funcionan «felizmente». Por otro lado creo que es un libro para leer de punta a punta, ya que -al igual que todos los libros de la serie XP- tiene capítulos cortos que hacen muy amena su lectura.

Resulta que ayer estaba preparando una clase para FIUBA y tomé algunas cosas de este excelente libro de Beck y Fowler y me pareció que sería interesante compartir esta opinión pues tengo la sospecha que no es muy popular.

Presenting at XP2018

This year the Extreme Programming Conference will be held the week of May 21 to 25th in Porto (Portugal) and I will be there.

The conference program looks great, with Kent Beck and Laurie Williams as keynote speakers and several social activities.

I will be presenting 2 sessions: a reduced version of my workshop on DevOps Practices and the paper about Technical and Organizational Agile Practices that is the result of the our research work at UNTREF.

In future posts I will share more details of my session.

Preparando la segunda edición de MeMo2 (95.21 / 75.10)

Dados ciertos cambios a nivel administrativo/curricular, a partir de 2018 el curso que dicto como MeMo2 (95.21) también estará disponible para alumnos que deban cursar TdD (75.10). Entiendo que lo mismo vale para el curso del Ing. Pantaleo que venia dictando TdD y que de ahora en más podrá recibir alumnos de MeMo2.

A partir de este cambio es posible que este cuatrimestre tenga más alumnos que el cuatrimestre pasado, hecho que sin duda podría impactar en la dinámica de la materia. Otro punto que también impactará en la dinámica de cursada será la posibilidad de que la universidad designe un docente auxiliar para el curso, yo ya presenté candidato y estoy a la espera de una respuesta.

Conceptualmente la dinámica está descripta en este artículo que presente en SECM el año pasado. Para quienes cursaron MeMo1 con Sergio Villagra, encontrarán muchas similitudes. Debo aclarar en términos de implementación aún hay un delta con la idea conceptual, pues la materia es aún muy nueva y entre otras cuestiones aún no he generado todos los videos que quisiera.

Para quienes esten considerando cursar 95.21/75.10 este primer cuatrimestre de 2018 les comparto algunos puntos del curso que estará a mi cargo y puede ser relevante tener presente en el momento de la inscripción:

  • Adicionalmente a las 6 horas semanales de clase, se espera una dedicación semanal constante de entre 4 y 8 horas (el cuatrimestre pasado los alumnos reportaron una dedicación promedio extra-clase de 5 horas semanales) .
  • Los contenidos de la materia incluyen varias cuestiones de índole técnica, las cuales en ocasiones suelen generar imprevisto (por alguna cosilla que no funciona) y las tareas pueden terminar llevando más de lo esperado)
  • Los contenidos de MeMo2 están relacionados de una forma tal que hace muy difícil poder completar la tarea N+1 si primero no se completo la tarea N. Esto hace que la hora de hacer las tareas, uno se encuentre casi obligado de hacerlas en el orden estipulado sin poder saltearlas.
  • Las tareas de programación se realizarán con lenguaje Ruby, pero no se enseñará como parte de la materia, habrá una clase de introductoria y links para profundizar, nada más (se espera que a esta altura de la carrera los alumnos sean capaces de aprender un lenguaje por sus propios medios)

Para quienes quieran leer algo más de información de la materia, pueden consultar estos artículos del cuatrimestre pasado.