Otro año más llega la vuelta de vacaciones y con ello FixedBuffer cumple un año más. Tres años hace desde que empece esta andadura donde voy publicando mis notas sobre nuevas tecnologías y sobre cosas que en general me parecen interesantes.

Es cierto que este último año he estado sin escribir desde febrero, la muerte de mi padre, el COVID, cambios de trabajo y demás cosas me han alejado de escribir en el blog (principalmente por no tener ganas o simplemente no creer que tenía nada interesante para contar). La parte buena es que aunque no he escrito activamente si he seguido participando activamente en la comunidad así que al menos si alguien ha querido saber de mí (no alcanzo a imaginar por qué… xD), no se ha quedado sin la oportunidad.

También voy a aclarar que no todo ha sido malo, y que he cumplido con otras metas personales: he comprado mi casita, sigo siendo MVP y mi mujer todavía no se ha cansado de mí y de todo el tiempo que dedico a estas cosas (toda una santa he de añadir).

Dicho esto, ¿qué va a ser de FixedBuffer de aquí en adelante? Pues la verdad no tengo una idea clara… Me gustaría y voy a intentar escribir una entrada nueva cada 2-3 semanas, el verano me ha servido para recuperar fuerzas y llevo lo suficiente en mi nuevo trabajo como para haber descubierto varias tecnologías muy interesantes de las que escribir, o de cosas que si bien son básicas, no todo el mundo las conoce. Veremos en que se traduce y si no acabaré solo con las charlas (‘traccionando’ que diría alguno )

Y ya como despedida, solo 2 cosas más. La primera es agradecer a la gente que seguís aquí pese a que no haya escrito demasiado últimamente, la verdad es que ver que el contenido sigue siendo útil es una de las principales razones para seguir tirando líneas
La segunda, como ya empieza a ser tradición, es el top 5 de las entradas del último año:

1. Haciendo fácil el acceso a datos con Entity Framework Core (Parte 2)
2. Inyección de Dependencias en .Net Framework
3. Worker Service: Cómo crear un servicio .Net Core 3 multiplataforma
4. Cómo medir tiempos en C# y .Net con precisión
5. Generación de ficheros «Excel» (xlsx) con ClosedXML

**La entrada ¡¡FixedBuffer ha cumplido su tercer año!! se publicó primero en Fixed Buffer.**

¡Después de muchos meses sin escribir, por fin volvemos a la carga! Han pasado muchas cosas durante estos meses (de las que supongo que hablaré en la entrada de los 3 años), pero entre ellas hay una que ha empujado el tema de esta entrada:
Docker está moviendo ficha en lo referente a sus políticas de precios.

Lo que nos lleva a una pregunta obvia, ¿en qué me afecta eso a mí? Pues seguramente en nada, pero tal vez seas una de esas personas que estaban utilizando utilidades como las «builds automáticas» de DockerHub.

Esta es precisamente la parte que más me ha impactado a mí, tengo algunas imágenes Docker que hasta hace poco generaba directamente usando DockerHub, pero ese tiempo se acabó, y ha tocado buscarse otra solución. Esta solución, en la mayoría de los casos va a pasar por utilizar los propios sistemas de CI/CD que ofrecen muchos proveedores, y ya que estamos en GitHub, ¿por qué no usar GitHub Actions para construir la imagen Docker?

Generando una imagen Docker con GitHub

No es la primera entrada en este blog sobre qué son y cómo utilizar GitHub Actions, así que podemos ir al turrón y centrarnos en como generar nuestras imágenes Docker. Esto en sí mismo ya es algo muy útil que podemos utilizar como parte de nuestro proceso de integración continua, para validar que no se está rompiendo nada con un cambio.

Para este pequeño ejemplo que estamos haciendo, vamos a utilizar un Dockerfile muy sencillo, ya que solo queremos ver como generar la imagen Docker con Github Actions, no recrearnos en Docker Algo como esto por ejemplo:

FROM alpine
ENTRYPOINT ["echo", "Hello World!"]

Simplemente usando una imagen ‘alpine’, imprimimos por consola ‘Hello World!’.

El primer paso, como toda GitHub Action, es crear el yam correspondiente dentro de la carpata ‘.github/workflows’, en este caso, algo tan simple como esto:

name: Docker GitHub

on: [push, pull_request,workflow_dispatch]

jobs:
  build-and-push-images:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v2

Sobre esta Action que de momento no hace nada, vamos a añadir el paso que generará la imagen. Para ello vamos a utilizar la acción build-push-action, que es su modo más simple, basta con añadir el paso a nuestro ‘yaml’:

      - name: Build and push Docker image
        uses: docker/build-push-action@ad44023a93711e3deb337508980b4b5e9bcdc5dc
        with:
          context: .  //Contexto para el comando Docker
          push: false //Indicamos si queremos hacer push de la imagen

Con esto ya tenemos todo listo, nuestra GitHub Action va a generar una imagen Docker automáticamente.

Publicando una imagen Docker en DockerHub con GitHub

Muy bien, tenemos lista nuestra Action y ya genera la imagen Docker, pero esto aún no resuelve el problema inicial, de que no tengo las auto builds de DockerHub para mantener las imágenes actualizadas. Precisamente por eso, hay que ir un paso más allá y subir la imagen al registro.

Lo primero que vamos a hacer, es añadir una nueva GitHub Action más a nuestro ‘yaml’ (antes de hacer el build & push, obviamente), con la que haremos un login en DockerHub:

      - name: Login to DockerHub
        if: github.ref == 'refs/heads/master'
        uses: docker/login-action@v1 
        with:
          username: ${{ secrets.DOCKERHUB_USERNAME }}
          password: ${{ secrets.DOCKERHUB_TOKEN }}

Ten en cuenta que es necesario crear un token en DockerHub y añadirlo junto al usuario como secreto para el repositorio.

Una vez hecho esto, basta con un par de cositas más, editar el paso donde hacemos el build, para indicarle que queremos también hacer un push por un lado, y por otro lado, darle un tag a la imagen:

      - name: Build and push Docker image
        uses: docker/build-push-action@ad44023a93711e3deb337508980b4b5e9bcdc5dc
        with:
          context: .
          push: true
          tags: 'fixedbuffer/hello'

Con esto, ya tenemos lista nuestra imagen Docker, y subida a DockerHub. Pero… ¿Y si quiero más de un tag? Es muy habitual que cuando creamos una nueva imagen, le demos un tag especifico y además ‘latest’.

Gestionando múltiples nombres y etiquetas

Vale, ya tenemos el proceso listo, pero como hemos comentado con el tema de los tags, es mejorable para simplificarnos la vida. Es por eso que mi propuesta es utilizar otra GitHub Action que nos va a generar diferentes tags según la configuremos. Esta Action es metadata-action.

Simplemente vamos a tener que configurar la Action y editar un poco la Action con la que generamos la imagen Docker, de modo que utilice como entrada la salida de esta. Lo primero será configurar los metadatos, para lo que añadimos esto a nuestro ‘yaml’:

      - name: Docker meta
        id: meta
        uses: docker/metadata-action@v3
        with:
          images: |
            fixedbuffer/hello
          tags: |
            latest
            type=sha

Como resultado de esta Action, se van a generar las etiquetas ‘fixedbuffer/hello:latest’ y ‘fixedbuffer/hello:sha-COMMIT-SHA’. Esta solo es una configuración muy simple para poder probar que funciona, pero realmente ofrece una gran cantidad de opciones, que puedes consultar en el mismo repositorio.

Ahora, vamos a usar esas etiquetas. La Action que genera y publica la imagen se verá así:

      - name: Build and push Docker image
        uses: docker/build-push-action@ad44023a93711e3deb337508980b4b5e9bcdc5dc
        with:
          context: .
          push: true
          tags: ${{ steps.meta.outputs.tags }}
          labels: ${{ steps.meta.outputs.labels }}

Listo, ya tenemos solucionado el problema y se va a generar y subir la imagen con ambos tags.

¿Y si quiero usar otro regristry? (El de GitHub por ejemplo)

Buena pregunta, y la verdad es que tal cual hemos planteado nuestro ‘yaml’, es algo muy muy sencillo. Bastaría con hacer login en el regritry que queramos usar (ghcr, acr, ecs…) y añadir el nombre. Por ejemplo, con DockerHub Y el registry de GitHub nos quedaría una cosa así:

name: Github Registry

on: [push, pull_request, workflow_dispatch]

env:
  IMAGE_NAME: fixedbuffer/hello

jobs:
  build-and-push-images:
    runs-on: ubuntu-latest
    # Asignamos los permisos sobre los recursos de GitHub
    permissions:
      contents: read
      packages: write

    steps:
      - name: Checkout repository
        uses: actions/checkout@v2

      - name: Docker meta
        id: meta
        uses: docker/metadata-action@v3
        with:
          images: |
            ${{ env.IMAGE_NAME}}
            ghcr.io/${{ env.IMAGE_NAME}}
          tags: |
            latest
            type=sha

      - name: Login to DockerHub
        if: github.ref == 'refs/heads/master' # Solo master
        uses: docker/login-action@v1 
        with:
          username: ${{ secrets.DOCKERHUB_USERNAME }}
          password: ${{ secrets.DOCKERHUB_TOKEN }}

      - name: Login to GHCR
        if: github.ref == 'refs/heads/master' # Solo master
        uses: docker/login-action@v1
        with:
          registry: ghcr.io
          username: ${{ github.repository_owner }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Build and push Docker image
        uses: docker/build-push-action@ad44023a93711e3deb337508980b4b5e9bcdc5dc
        with:
          context: .
          push: github.ref == 'refs/heads/master' # Solo master
          tags: ${{ steps.meta.outputs.tags }}
          labels: ${{ steps.meta.outputs.labels }}

Conclusión

La verdad es que en mi caso concreto, perder las auto builds de DockerHub fue un problema, ya que tuve que hacer un trabajo extra para añadir la generación de imágenes directamente desde GitHub.

De todos modos, como puedes comprobar es muy muy sencillo utilizar GitHub Actions para generar imágenes Docker. En este artículo hemos hecho una pequeña review de alto nivel, pero usando las dos Actions principales (docker/build-push-action y docker/metadata-action) podemos configurar incluso las plataformas de destino, usar buildx, …

Puedes verlo en marcha en este repo de GitHub (obviamente xD)

**La entrada Generando y publicando imágenes Docker con GitHub Actions se publicó primero en Fixed Buffer.**

Ha llegado la vuelta de las vacaciones y con ello la vuelta a las buenas costumbres. He de reconocer que después del parón de navidades me ha costado más de lo habitual volver a escribir. Muchos frentes abiertos durante las fiestas y no acababa de encontrar ningún tema del que me apeteciese hablar… Pero eso por fin ha cambiado y he encontrado algo que personalmente me parece realmente interesante, Github ha añadido soporte para entornos y aprobaciones manuales.

He de aclarar aquí, que el soporte a diferentes entornos es anterior a los aprobadores manuales aunque yo los nombre a la vez.

De dónde venimos

A la gente que me conoce no le sorprende el hecho de que siempre este con un ojo puesto en como avanzan los procesos de CI/CD en diferentes proveedores. Soy firme defensor de los procesos automatizados tanto para la integración como para el despliegue. Muestra de ello son las entradas sobre el tema durante estos años.

Es por eso que cuando aparecieron las Github Actions fue una grata sorpresa, Microsoft hacia una fuerte apuesta por llevar sus herramientas a Github. De hecho, hay una entrada específica hablando sobre Github Actions, y tuve la suerte de charlar un rato con Alberto Gimeno (@gimenete) en Github Actions: ¿Hasta dónde podemos llegar?.

El titular de ese momento es que Github Actions estaba todavía muy por detrás de otras herramientas como Azure Pipelines, ya que las posibilidades de CI/CD que teníamos a nuestra disposición se limitaban prácticamente a hacer integraciones y algún despliegue sencillo. Esto por suerte a cambiado como vamos a ver.

¿Por qué son tan importantes los aprobadores manuales en Github Actions?

Pues aquí no hay mucho donde rascar, los despliegues a producción tienen que ser controlados, cualquier código no puede llegar a producción. De acuerdo que trabajamos con metodologías agiles y desplegamos a producción en ciclos cortos, pero eso no es carta blanca para que los despliegues a producción sean «la jungla».

Aquí vamos a aclarar que desde luego una aprobación manual no tiene por qué ser ni el requisito elegido, ni el único. Existen otros tipos de aprobaciones que no son manuales, pero esto es el mínimo que nos permite tener despliegues controlados.

¿Y eso de los entornos?

Más allá de opiniones personales (posiblemente con muchos sesgos), vamos a lo que no tiene discusión, que es el proceso para poder tener aprobadores. El concepto de aprobador manual en Github Actions (y otros muchos proveedores) no es otra cosa más que una acción que debe hacer una persona para poder iniciar los pasos contra cierto entorno.

Esto nos lleva a otro punto interesante entre las novedades de Github, los entornos. Es muy habitual que diferentes etapas del desarrollo tengan diferentes requisitos, por poner un ejemplo, si trabajamos con kubernetes en producción, posiblemente tengamos un cluster potente, autoescalable y bien monitorizado y supervisado con alertas. En cambio, un cluster de desarrollo puede ser algo sencillito, con apenas configuraciones de seguridad y sin monitorización y/o alertas.

Esto se traduce en una ‘entidad’ llamada entorno (‘environment’) que contendrá valores específicos para ciertas variables de los despliegues como el tamaño del cluster del ejemplo anterior. Este entorno es además sobre el que añadiremos a los distintos aprobadores que deben dar su autorización para que el proceso pueda seguir en él.

Para poder comprobar que efectivamente tenemos diferentes valores en las mismas variables, vamos a utilizar un programa de consola al que vamos a llamar desde los diferentes entornos:

class Program
{
    static void Main(string[] args)
    {
        var env = Environment.GetEnvironmentVariable("MYVAL");
        int.TryParse(env, out var id);
        var message = id switch
        {
            1 => "Development",
            2 => "Production",
            _ => "MYVAL is not defined"
        };
        Console.WriteLine(message);
    }
}

Con ese programa listo, simplemente vamos a crear los entornos y a registrar un secreto llamado ‘MYVAL’ en ellos, cuyo valor sea 1 y 2 en desarrollo y producción respectivamente.

Para esto, basta con ir a la pestaña de ‘Settings’, dentro de ella al menú ‘Environments’ y después pulsar sobre ‘New environment’:

Esto nos permitirá darle un nombre al entorno. Tras esto, pasamos directamente a configurarlo. Es desde esta sección precisamente donde vamos a añadir nuestro secreto de ejemplo ‘MYVAL’ con su valor concreto:

Para poder probar que nuestros entornos funcionan correctamente, vamos a crear nuestro workflow para Github Actions donde vamos a compilar nuestro programa de ejemplo y lo vamos a ejecutar tanto en desarrollo como en producción:

name: CI/CD

on:
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]

env:
  PACKAGE_PATH: ./package
  PACKAGE_NAME: console_sample
  CONFIGURATION: Release
  DOTNET_CORE_VERSION: 5.0.x
  DOTNET_CLI_TELEMETRY_OPTOUT: 1
  DOTNET_SKIP_FIRST_TIME_EXPERIENCE: 1

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    - name: Setup .NET
      uses: actions/setup-dotnet@v1
      with:
        dotnet-version: ${{ env.DOTNET_CORE_VERSION}}
    - name: Restore dependencies
      run: dotnet restore
    - name: Build
      run: dotnet build --no-restore --configuration ${{ env.CONFIGURATION }}
    - name: Publish
      run: dotnet publish --no-build --configuration ${{ env.CONFIGURATION }} --output "${{ env.PACKAGE_PATH }}"
    - name: Publish Artifacts
      uses: actions/upload-artifact@v1.0.0
      with:
        name: ${{ env.PACKAGE_NAME }}
        path: ${{ env.PACKAGE_PATH }}

  development:
    # Avoid to continue if the trigger is a PR
    if: github.event_name == 'push'
    needs: build
    name: Deploy Development Environment
    runs-on: ubuntu-latest
    environment:
      name: Development
    env:
      MYVAL: ${{ secrets.MYVAL }}
    steps:
    # Download artifacts
    - name: Download artifacts
      uses: actions/download-artifact@v2
      with:
        name: ${{ env.PACKAGE_NAME }}
    - name: Setup .NET
      uses: actions/setup-dotnet@v1
      with:
        dotnet-version: ${{ env.DOTNET_CORE_VERSION}}
    - name: Execute 
      run: dotnet ManualApproval.dll    

  # This stage doesn't need to use if because the previous stage applies it
  production:
    needs: development
    name: Deploy Production Environment
    runs-on: ubuntu-latest
    environment:
      name: Production
    env:
      MYVAL: ${{ secrets.MYVAL }}
    steps:
    # Download artifacts
    - name: Download artifacts
      uses: actions/download-artifact@v2
      with:
        name: ${{ env.PACKAGE_NAME }}
    - name: Setup .NET
      uses: actions/setup-dotnet@v1
      with:
        dotnet-version: ${{ env.DOTNET_CORE_VERSION}}
    - name: Execute 
      run: dotnet ManualApproval.dll    

Nada raro en el fichero, simplemente es un workflow con 3 jobs, uno donde vamos a generar el artefacto, y 2 para nuestra ejecución (uno por entorno). La novedad aquí es que dentro del job, vamos a indicar el entorno al que pertenece utilizando:

environment:
  name: Nombre_Entorno

Además, para probar que cambia en función del valor que hemos asignado al entorno, creamos una variable que utiliza ese secreto:

env:
  MYVAL: ${{ secrets.MYVAL }}

Basta con hacer un push al repositorio para que automáticamente se ejecute, y si vamos a la sección de acciones, vamos a poder encontrarnos con que el paso ‘Execute’ de cada uno de los jobs, muestra el valor correcto:

Añadiendo aprobadores manuales a nuestra Github Action

Con esto que hemos hecho hasta ahora, ya tenemos 2 entornos diferenciados. Con esto hecho, ya nos queda lo más fácil, añadir aprobaciones manuales a nuestras Github Actions.

Para esto, es suficiente con que vayamos al entorno en concreto que queremos que tenga una aprobación manual, y marcar el check ‘Required reviewers’. Esto nos mostrará un campo de entrada donde vamos a poder buscar a integrantes del repositorio a los que añadir. Aquí hay que tener en cuenta que ahora mismo el número máximo de aprobadores es de 6. Una vez añadidos, simplemente pulsamos el botón ‘Save protection rules’.

Una vez que hemos guardado los cambios, las nuevas ejecuciones de nuestra acción se pararán cuando lleguen al entorno de producción:

En este punto, se habrá enviado un email a las personas con capacidad de aprobar el proceso, y una vez se tenga la aprobación, el proceso continuará con normalidad.

Conclusión

Aunque Github Actions sigue estando un paso por detrás de su hermano mayor Azure Pipelines, está dando unos saltos agigantados para alcanzarlo y seguramente superarlo. Es todo un placer ver como esta herramienta evoluciona y va añadiendo nuevas características.

No olvidemos que es una herramienta gratuita en una gran cantidad de casos, pero que aporta mucho valor en nuestros proyectos. Quizás todavía no esté preparada para grandes proyectos con despliegues extremadamente complejos, pero sí que tiene una madurez suficiente para proyectos pequeños y medianos. En este ejemplo nos hemos limitado a ejecutar una aplicación de consola por sencillez, pero lo habitual sería hacer despliegues directamente.

Por último, aunque la aprobación manual es insuficiente para automatizar totalmente los procesos, abre la puerta a otro tipo de aprobaciones más sofisticadas en el futuro. Y eso sin hablar de que acciones manuales es más que suficiente para una cantidad de casos enorme.

Si quieres, puedes echarle un ojo en detalle al repositorio en Github que es como mejor se aprende

**La entrada Añadiendo aprobaciones manuales en despliegues con Github Actions se publicó primero en Fixed Buffer.**

Se acercan las navidades y este año en mi carta he pedido una Raspberry Pi 4 con la que poder jugar en mis ratos libres. No soy una persona a la que le guste esperar, y no he podido aguantar las ganas de ponerme a probarla con varios proyectos que tenía pendientes. De ahí, que me haya parecido muy interesante dedicar la última entrada del año a uno de esos proyectos que tenía pendiente

Del título queda bastante claro cuál va a ser el tema de esta entrada, cómo poder gestionar el GPIO (general-purpose input/output) de una Raspberry Pi con un módulo de IoT Edge, y con ella pretendo dar fin a la temática de estas últimas entradas dedicadas al mundo IoT relacionado con Azure y Docker. Por si tienes interés, son todas estas:

• Cómo crear una imagen docker multiarquitectura desde cero (fixedbuffer.com)
• IoT Hub DPS: Creando dispositivos bajo demanda (fixedbuffer.com)
• Creando módulos especializados para Azure IoT Edge (fixedbuffer.com)
• IoT Edge: Desplegando cargas de trabajo «on-prem» desde IoT Hub (plainconcepts.com)
• IoT Hub: Enrutando mensajes hacia diferentes destinos (plainconcepts.com)

¿Por qué una Raspberry Pi?

La verdad es que cuando hablamos de IoT, normalmente una pensamos en placas hechas a medida, que trabajan con muy pocos recursos y tienen una función específica muy concreta. Aunque Raspberry Pi es una placa que en su última versión no es precisamente un hardware simplón (hay que tener en cuenta que soporta el 4K, más que muchos ordenadores actuales), sí que es un hardware muy asequible. Además, el número de entradas que nos ofrece no es nada desdeñable:

Precisamente del hecho de que sea un PC sencillo y de muy bajo consumo (11W y eso que tengo un overclock de un 40%), junto a un precio muy razonable, es lo que ha motivado el que esta entrada se haga en base a ella. Realmente, todo lo que vamos a ver aquí es susceptible de aplicar en cualquier otro hardware sobre el que estemos desplegando módulos de IoT Edge y no solo en una Raspberry Pi, incluso el uso de sus GPIO.

Llegados a este punto, voy a hacer una aclaración importante: Todo lo dicho en esta entrada aplica solo cuando estemos utilizando IoT Edge y no Docker en general.

Esto es porque hoy en día, el runtime de IoT Edge no nos permite levantar contenedores con cualquier configuración. Esta limitación nos va a obligar a dar más permisos de los que se consideran deseables puesto que nuestro módulo va a necesitar correr con permisos privilegiados como veremos más adelante.

Si por el contrario, queremos acceder al GPIO de Raspberry Pi desde Docker directamente, yo utilizaría un modelo en el que asigne un usuario especifico con acceso al GPIO.

Probando las GPIOs de una Raspberry Pi

Llegados a este punto, si sigues leyendo esto es porque asumes que quieres utilizar IoT Edge y que por tanto vas a crear un módulo que se despliegue en una Raspberry Pi y que opere su GPIOs.

Como es importante aprender a andar antes de aprender a correr, lo primero que he hecho es crear un pequeño programa que sea capaz de leer una entrada y escribir una salida de las GPIO de Raspberry Pi directamente, sin IoT Edge de por medio.

Para esto, hay que decir que .Net Core tiene soporte directo para este tipo de GPIO a través del paquete ‘System.Device.Gpio‘, con lo que el proceso se simplifica bastante.

using System;
using System.Device.Gpio;

namespace Sample
{
    class Program
    {
        static void Main(string[] args)
        {
            // GPIO 6 which is physical pin 31
            int outPin = 6;
            // GPIO 12 is physical pin 32
            int inPin = 12;

            var controller = new GpioController();

            // Sets the LED pin to output mode so we can switch something on
            controller.OpenPin(outPin, PinMode.Output);

            // Sets the button pin to input mode so we can read a value
            controller.OpenPin(inPin, PinMode.Input);

            // Read pin value
            Console.WriteLine(controller.Read(inPin));

            // Set pin value
            controller.Write(outPin, PinValue.High);

            // Reset pin value
            controller.Write(outPin, PinValue.Low);
        }
    }
}

Básicamente, este programa lo que hace es abrir los pines 31 y 32 en modo salida y entrada respectivamente, lee la entrada y escribe la salida. Es un programa muy sencillo pero valida que tenemos nuestro sistema funciona bien si vamos directos a sobre la Raspberry Pi.

Una cosa que me gusta de este paquete NuGet es que podemos crear un callback para los cambios sobre un pin en concreto, por lo que no necesitamos leer todo el tiempo ese pin, sino que se ejecutará el callback siempre que haya cambios.

Por otro lado, en caso de que nuestras entradas no estén soportadas por ese paquete, siempre podemos añadir ‘Iot.Device.Bindings‘ para ampliar la gama de GPIOs soportados.

Creando un módulo de IoT Edge que opere el GPIO de una Raspberry Pi

Hemos conseguido leer y escribir las GPIO sin problemas, por lo que vamos a llevarnos el código a un módulo de IoT Edge. Esto no tiene mucho misterio si has leído las entradas anteriores relacionadas con el tema, pero por si acaso, he dejado el código completo en GitHub.

Para no complicar mucho el proceso de manera innecesaria, simplemente estamos haciendo 3 cosas:

• Inicializar tanto el GPIO como el módulo.
• Escribir una salida cada 300 milisegundos.
• Leer una entrada cada segundo y enviando el valor a la cola llamada ‘output’.

Una cosa a tener en cuenta, el código no es importante en esta entrada, con lo que hemos visto antes podría ser suficiente. Simplemente lo estamos ‘integrando’ un poco más el GPIO de Raspberry Pi en el módulo de IoT Edge.

Digo que el código no es importante, porque precisamente el reto aquí es conseguir que un módulo que corre como un contenedor Docker, gestionado totalmente por el runtime de IoT Edge, sea capaz de acceder al hardware subyacente para poder operar las salidas.

Adaptando el módulo creado para poder operar las GPIOs

Al principio de la entrada hacia un disclaimer sobre que esta no es la mejor manera si estamos trabajando con Docker directamente en lugar de IoT Edge, y es el momento de explicarlo.

pi@raspberrypi:/sys/class $ ls -l
total 0
...
drwxrwx--- 2 root gpio 0 Dec 13 16:57 gpio
...

Es precisamente por esto, que para que nuestro módulo funcione vamos a necesitar hacer 2 cosas:

• Ejecutar nuestro contenedor como root
• Montar el directorio dentro de nuestro módulo

Aunque sinceramente, el tener que ejecutar el contenedor con privilegios de root me parece algo que se deba evitar siempre que sea posible. El problema aquí es que IoT Edge nos permite definir dentro de su plantilla algunas opciones propias de la creación de contenedores, pero a día de hoy, no se soportan todas (o al menos yo he sido incapaz de hacerlas funcionar, estaré encantado si alguien lo ha conseguido que me deje un comentario).

"modules": {
  "IO": {
    "version": "1.0",
    "type": "docker",
    "status": "running",
    "restartPolicy": "always",
    "settings": {
      "image": "${MODULES.IO}",
      "createOptions": {
        "Privileged": true,
        "HostConfig": {
          "Binds": [
            "/sys:/sys"
          ]
        }
      }
    }
  }
}

RUN useradd -ms /bin/bash moduleuser
USER moduleuser

Probando nuestro módulo

[IoTHubMonitor] [12:05:44 AM] Message received from [Raspi/IO]:
"High"
[IoTHubMonitor] [12:05:45 AM] Message received from [Raspi/IO]:
"High"
[IoTHubMonitor] [12:05:46 AM] Message received from [Raspi/IO]:
"Low"
[IoTHubMonitor] [12:05:47 AM] Message received from [Raspi/IO]:
"High"
[IoTHubMonitor] [12:05:48 AM] Message received from [Raspi/IO]:
"Low"

Llegados a este punto y si vas siguiendo paso a paso, seguramente en tu caso no esté cambiando el mensaje que recibes. ¿Y dónde está la magia entonces? Pues en algo que no se puede ver, un cable que une físicamente esos dos pines (31 y 32, indicados en el programa):

Con este simple cable, estamos consiguiendo que la entrada que leemos y enviamos a la cola ‘output’ este constantemente cambiando de valor. Con esto tan simple, estamos comprobando que de verdad estamos accediendo a las GPIOs de las Raspberry Pi desde el módulo IoT Edge, ya que estamos cambiando el mensaje en función del valor de la entrada.

Conclusión

Aunque hay que hacer algunas cosas que podríamos considerar ‘feas’ desde el punto de vista de las buenas prácticas de Docker, deberíamos tener en cuenta que realmente nuestro objetivo es IoT Edge y no Docker. Aclaro esto porque podemos encontrarnos con otras situaciones donde tampoco podamos cumplir al 100% las buenas prácticas y no nos queda otra que esperar a que el soporte vaya siendo más completo.

Dicho esto, personalmente pienso que es una buenísima manera de conseguir mejorar el ciclo de vida de una aplicación que opere entradas y salidas. Estamos aprovechando toda la potencia que nos ofrece IoT Edge (y de la que ya hemos hablado largo y tendido) con el añadido de que podemos operar sensórica real que esté conectada a la Raspberry Pi. Las GPIO integradas nos ofrecen tanto entradas como salidas digitales y PWM de serie, con posibilidad de ampliar con entradas y salidas analógicas.

**La entrada Cómo crear un módulo IoT Edge que use las GPIOs de Raspberry Pi 4 se publicó primero en Fixed Buffer.**

Estas últimas semanas han sido apasionantes, Kubecon, DotNetConf,… Un montón de novedades y nuevas versiones de diferentes softwares y herramientas de las que hablaremos en las próximas semanas. Hoy vengo a hablar de algo más ‘mundano’, como generar imágenes Docker. Solo que esta vez vamos a hacer que nuestra imagen sea multiarquitectura.

DISCLAIMER: La idea de esta entrada es hablar de cómo crear imágenes Docker multiarquitectura, por lo que no se entra en los detalles sobre crear imágenes Docker en si mismo, sino que se pasa por encima para dar el contexto.

¿Qué es y cómo funciona Docker?

Antes de empezar a hablar sobre imágenes multiarquitectura, conviene empezar aclarando que es Docker y como funciona. Docker es un sistema de empaquetado de contenedores que nos permite añadir aplicaciones y dependencias en un mismo ‘paquete’, de modo que corra donde corra, siempre funcionará igual. Podríamos decir que es como si cogiéramos una máquina virtual y la distribuyésemos. De este modo, podemos preparar el sistema operativo, sus dependencias y nuestra aplicación, generar un ‘paquete’ y ponerlo en marcha allá donde queramos.

Con esto mente, hay que aclarar que docker es como correr una maquina virtual, pero no es correr una máquina virtual. Esto quiere decir que, a diferencia de una máquina virtual, aquí no movemos todo el sistema operativo, sino simplemente las ‘particularidades’ que tiene, dejando la base común intacta ya que esta base común se comparte con el sistema operativo anfitrión.

A esta tecnología se la conoce como contenedores y no es algo nuevo, si no que lleva existiendo varios años ya. Su funcionamiento (simplificado) es que vamos a crear imágenes que con las dependencias y aplicaciones, y estas son las que vamos a distribuir. Precisamente del hecho de que la parte común se comparta con el sistema operativo anfitrión, es por lo que tenemos que hablar de imágenes Docker para una arquitectura concreta. Por poner un símil, diferentes distribuciones de Linux comparten la misma base común que es el kernel de Linux, diferentes imágenes comparten la misma arquitectura.

¿Por qué me puede interesar crear imágenes Docker multiarquitectura?

En las últimas entradas estuvimos hablando sobre módulos para IoT Edge y sobre aprovisionamiento de dispositivos con IoT Hub. Pues bien, en ese momento no entramos en detalle, aunque hicimos referencia a ello:

Actualmente, Docker soporta de forma experimental el crear manifiestos de imágenes para múltiples arquitecturas simultáneamente, siendo el runtime de Docker el que se descarga la imagen de su arquitectura especifica.

Creando módulos especializados para Azure IoT Edge

Pues efectivamente, este es un caso muy claro donde seguramente nos interese crear imágenes Docker multiarquitectura. Esto es porque es un escenario común que queramos crear módulos de IoT Edge que trabajen por ejemplo de igual manera si los desplegamos en un microprocesador amd64, arm32, arm64, …

Estos escenarios solían requerir de diferentes imágenes con una imagen base diferente, y cuyo uso requería de mantener un tag diferente para identificarlos. De este modo no es nada raro encontrarnos con que muchos repositorios de Docker Hub tienen soporte especifico mediante tags para diferentes arquitecturas.

Esto tiene un problema evidente y es que te obliga a especificar un tag concreto en el que indicamos la arquitectura, y dificulta mucho el generalizar en situaciones de despliegue masivo. ¿Realmente necesito saber la arquitectura del dispositivo IoT Edge para ejecutar el un módulo? ¿Realmente es algo que quiera tener en cuenta?

En Python sin ir más lejos, su imagen soporta hasta 10 arquitecturas distintas:

En cambio, todas ellas se sirven desde el mismo tag, es decir, están agrupadas y es el propio cliente de Docker el que se baja la imagen concreta que necesita para el caso concreto.

Creando nuestra primera imagen Docker multiarquitectura (Docker Manifest)

Vamos a partir plantear un ejemplo muy sencillo. Partimos de un escenario donde todas las arquitecturas que queremos soportar ya están soportadas por la imagen base que utilicemos.

Lo primero que vamos a necesitar, es habilitar el soporte para ‘Docker Manifest‘. Esta es una característica experimental de Docker por lo que para habilitarlas debemos (extraído y traducido de la documentación oficial):

Para habilitar las características experimentales en el Docker CLI, edite el archivo config.json y ponga experimental a habilitado.
Para habilitar las características experimentales en el menú del escritorio de la base Docker, haz clic en Configuración (Preferencias en macOS) > Línea de comandos y luego activa la opción Habilitar características experimentales. Haz clic en Aplicar y reiniciar.

Una vez teniendo eso listo, vamos a crear las diferentes imágenes que queremos que se sirvan desde nuestra ‘meta imagen’ multiarquitectura. Por ejemplo, podríamos tener un par de Dockerfiles como estos (en el repositorio de Github puedes encontrar más arquitecturas):

# Dockerfile.amd64
FROM amd64/alpine
CMD echo "Hello world desde amd64/alpine"

# Dockerfile.arm32v6
FROM arm32v6/alpine
CMD echo "Hello world desde arm32v6/alpine"

Una vez que tenemos estos dos Dockerfile, vamos a generar sus respectivas imágenes y subirlas a Docker Hub con los comandos:

# Generamos las imágenes
docker build -f .\Dockerfile.amd64 -t fixedbuffer/multi-arch:amd64  .
docker build -f .\Dockerfile.arm32v6 -t fixedbuffer/multi-arch:arm32v6  .

# Pusheamos las imágenes a Docker Hub
docker push fixedbuffer/multi-arch:amd64
docker push fixedbuffer/multi-arch:arm32v6

Una vez que hemos subido las imágenes, vamos a crear nuestro manifiesto que genere esa anhelada imagen Docker multiarquitectura. Para ello simplemente vamos a ejecutar el comando ‘docker manifest create‘ indicandole el nombre del manifiesto y su tag (que será el nombre de esa ‘meta imagen’) y las imágenes que queramos que la compongan:

docker manifest create fixedbuffer/multi-arch:latest fixedbuffer/multi-arch:amd64 fixedbuffer/multi-arch:arm32v6

En caso de que queramos añadir nuevas imágenes, basta con ejecutar de nuevo el comando con el modificador ‘–amend‘. Una vez que hemos terminado de crear nuestro manifiesto, basta con subirlo a Docker Hub ejecutando:

docker manifest push docker.io/fixedbuffer/multi-arch:latest

Si ahora vamos a Docker Hub, vamos a encontrarnos con que nuestro repositorio tiene una nueva imagen multiarquitectura son la misma etiqueta que nuestro manifiesto. Esta nueva imagen soporta varias arquitecturas:

Si ahora ejecutamos la imagen en diferentes equipos, vamos a poder comprobar como dependiendo del sistema, se utiliza de manera transparente una u otra imagen:

Creando nuestra segunda imagen Docker multiarquitectura (Docker Buildx)

Si bien es cierto que esto funciona y funciona bien, se queda un poco a medias en el sentido de que es necesario generar las diferentes imágenes previamente a hacer el manifiesto. Esto significa que vamos a necesitar tener hardware que pueda ejecutar los Dockerfiles y subirlos a Docker Hub.

Otra opción, que personalmente me gusta más por ser muy sencilla de automatizar es 'docker buildx‘. Este comando nos va a permitir definir las diferentes arquitecturas que queremos que soporte nuestra imagen multiarquitectura, y será suficiente con que recibamos ese argumento en nuestro Dockerfile. Por ejemplo:

ARG ARCH=
FROM ${ARCH}debian:buster-slim

CMD echo "Hello world desde ${ARCH}debian:buster-slim"

Este Dockerfile simplemente recibe como parámetro el tipo de arquitectura que tiene que utilizar, el cual obtendrá desde la propia ejecución del comando:

docker buildx build --push --tag fixedbuffer/multi-arch:action --platform linux/amd64,linux/arm/v7,linux/arm64 -f Dockerfile.multi .

El comando ‘docker buildx build‘ soporta los mismos parámetros que soporta ‘docker build‘ de manera normal, pero además nos va a permitir utilizar algunos adicionales como –push para subir la imagen al terminar, o –platform para indicarle las diferentes plataformas que queremos soportar.

Una de las grandes ventajas que le veo respecto a Docker Manifest, es que es muy fácil de automatizar, como se puede comprobar en la entrada del propio blog de Docker (en inglés): Multi-arch build and images, the simple way – Docker Blog

Conclusión

En esta entrada hemos planteado un par de soluciones para poder generar imágenes Docker multiarquitectura, de modo que podamos utilizar la misma ‘meta imagen’ en todos nuestros dispositivos, sin tener que preocuparnos de cuál sea la arquitectura de dicho dispositivo.

Si bien es cierto que no es un escenario muy habitual, ya que normalmente las aplicaciones tienen una plataforma objetivo, no está de más conocer este tipo de posibilidades ya que como a mí, pueden sacarte de un apuro cuando generalizas las imágenes Docker.

**La entrada Cómo crear una imagen docker multiarquitectura desde cero se publicó primero en Fixed Buffer.**

¡Otra semana más! parece que fue ayer cuando estábamos de vacaciones todavía, pero nada más lejos de la realidad. Arrancan nuevos proyectos en mi trabajo y por suerte siempre estoy ahí moviéndome en lo que me gusta, Kubernetes y IoT.
Es por eso qué hoy toca seguir hablando de IoT en Azure

En la última entrada planteamos cómo crear módulos especializados para desplegar sobre un dispositivo IoT Edge y hoy toca hablar de otra situación muy habitual al hablar de IoT: cómo aprovisionar los dispositivos.

¿En qué consiste aprovisionar dispositivos?

Hasta ahora, siempre que hemos trabajado con IoT Hub, hemos creado individualmente cada dispositivo, sea de IoT Hub o de IoT Edge, y hemos recuperado su cadena de conexión.

Existe otro modo en el que podemos registrar esos diferentes dispositivos que consiste en utilizar un servicio de Azure llamado Azure IoT Hub Device Provisioning Service (DPS). Este servicio nos va a permitir asociar diferentes IoT Hub, sobre los cuales se van a crear los dispositivos de manera automática.

Este gráfico (sacado de la documentación oficial) describe muy claramente cuál es el flujo que sigue IoT Hub DPS para crear un dispositivo nuevo:

1. El fabricante del dispositivo agrega la información de registro del dispositivo a la lista de inscripción en Azure Portal.
2. El dispositivo contacta con el punto de conexión de DPS configurado de fábrica. 
3. DPS valida la identidad del dispositivo.
4. DPS registra el dispositivo con un IoT Hub.
5. El centro de IoT devuelve la información del identificador de dispositivo a DPS.
6. DPS devuelve la información de conexión del centro de IoT al dispositivo. El dispositivo ya puede empezar a enviar datos directamente a la instancia de IoT Hub.
7. El dispositivo se conecta a IoT Hub.
8. Obtiene el estado deseado del dispositivo gemelo en la instancia de IoT Hub.

¿Por qué aprovisionar dispositivos con IoT Hub DPS?

Crear manualmente los dispositivos está bien siempre que el número de dispositivos que queremos registrar no sea excesivamente grande, o siempre que cada dispositivo que creamos físicamente tenga algún proceso de fabricación individual.

Por ejemplo, si cada dispositivo es arrancado por un técnico para hacer algún proceso propio de la fabricación, no es descabellado que durante ese proceso se cree el dispositivo y se registre.

En cambio, imagina un escenario en el que no existe ese proceso manual y se fabrican en serie cientos de dispositivos iguales, que pueden ir a parar a cualquier lugar del mundo y caer en cualquier mano. En caso de estar en un escenario como el que acabo de describir, seguramente nos interese tener diferentes IoT Hub distintos desplegados en diferentes regiones y que los dispositivos se creen y conecten en el Hub más cercano pare reducir la latencia (geolocalización). Eso en el caso más exigente, pero otro caso quizás más común es aquél donde el usuario final no tiene los conocimientos o interés en configurar el dispositivo.

En este tipo de escenarios masivos en los que no hay intervención humana especializada durante el proceso de fabricación, es vital tener un sistema de aprovisionamiento automático.

Creando nuestro IoT Hub DPS

Doy por hecho que si estas leyendo esto, es porque conoces IoT Hub y como crearlo, por lo que voy a partir del punto en el que conoces como crear un IoT Hub y como funciona, así como en que consiste IoT Edge. En caso de que no sea así, te dejo unas entradas sobre el tema:

• Creación de una instancia de IoT Hub mediante Azure Portal
• IoT Edge: Desplegando cargas de trabajo ‘on-prem’ desde IoT Hub
• Creando módulos especializados para Azure IoT Edge

Aunque existen varias maneras de crear un IoT Hub DPS, a fin de simplificar al máximo vamos a utilizar Az Cli con su extension ‘iot‘.

Lo primero va a ser crear el servicio, para ello, basta con ejecutar:

 az iot dps create --name $dpsName --resource-group $rg --location $region

Esto nos va a devolver entre otras cosas, dos datos que necesitamos guardar para utilizar más adelante (aunque también los podemos recuperar más adelante desde Az Cli o desde el portal). Estos datos son ‘idScope‘ y ‘serviceOperationsHostName‘ y los vamos a necesitar cuando estemos configurando los dispositivos para auto aprovisionarse con IoT Hub DPS.

Lo siguiente que vamos a hacer una vez que se ha creado el servicio, es asociarlo con las instancias de IoT Hub donde queremos que sea posible aprovisionar dispositivos. Para esto vamos a necesitar tener una cadena de conexión con permisos de administración sobre cada uno de los IoT Hub que queremos conectar. Podemos conseguirla desde el portal o simplemente ejecutando:

$hubConnectionString=$(az iot hub show-connection-string --name $iotHubName --key primary --query connectionString -o tsv)

Y una vez que la tengamos, asociamos IoT Hub DPS con la instancia de IoT Hub ejecutando:

az iot dps linked-hub create --dps-name $dpsName --resource-group $rg --connection-string $hubConnectionString --location $region

Adicionalmente, podemos añadir el parámetro ‘–allocation-weight‘, que no es más que un valor de prioridad que podemos utilizar en el siguiente paso para decidir en que IoT Hub se van aprovisionar los dispositivos en caso de que exista más de uno asociado a la instancia de IoT Hub DPS.

Manejando las inscripciones

Vamos a pasar revista de lo que tenemos hasta el momento:

• Tenemos un IoT Hub o varios.
• Tenemos un IoT Hub DPS junto a su idScope y serviceOperationsHostName.
• Hemos asociado nuestro/s IoT Hub con el DPS.

Ya casi estamos listos para poder empezar a utilizar nuestro IoT Hub DPS, solo nos falta registrar dentro del propio servicio el método por el que vamos a identificar a los dispositivos. Para esto tenemos 2 modelos:

• Registrar dispositivos individualmente.
• Crear grupos de registro.

Estos dos modelos nos van a permitir gestionar como queremos que se inscriban los diferentes dispositivos. Llegados a este punto, puede parecer un poco absurdo el hecho de registrar dispositivos individualmente, ¿no? Pues la verdad es que tiene todo el sentido del mundo ya que el hecho de utilizar IoT Hub DPS para un dispositivo individual nos garantiza que en caso de que borremos el dispositivo de IoT Hub por cualquier razón, se volverá a crear automáticamente sin necesidad de interacción humana. Por ejemplo, puede darse el caso de que una instancia de IoT Hub este sobrecargada y no la podamos escalar por ‘x’ razón, gracias a este aprovisionamiento individual, podríamos cambiar dispositivos concretos de un Hub a otro con un mínimo esfuerzo.
Por su parte en cambio, la inscripción de grupos nos va a permitir registrar múltiples dispositivos con un mismo sistema.

Independientemente del sistema de inscripción que elijamos, vamos a tener 2 mecanismos para que un dispositivo se identifique ante IoT Hub DPS y un tercero en caso de dispositivos individuales:

• X.509
• Clave Simétrica
• TPM (dispositivos individuales)

Teniendo en cuenta estos dos tipos de registros y sus diferentes modos de identificación, vamos a crear una inscripción de grupo a modo de ejemplo (aunque una individual sería prácticamente igual). Para este proceso, vamos a necesitar tomar algunas decisiones: ¿Qué criterio vamos a usar para elegir el IoT Hub? Las opciones disponibles son:

• Latencia mínima.
• Peso de los IoT Hub.
• Siempre al mismo.
• Utilizar una Azure Function.

¿Qué instancias de IoT Hub queremos que sean elegibles para registrar el dispositivo? ¿Qué propiedades y/o tags queremos que tengan automáticamente los dispositivos? Estas últimas por ejemplo son muy útiles cuando queremos que un deployment de módulos se aplique directamente a los dispositivos IoT Edge.

Para eso, vamos a ejecutar:

# Grupo para IoT Edge
az iot dps enrollment-group create -g $rg --dps-name $dpsName --enrollment-id "IoTEdge" --primary-key $primaryKey --secondary-key $secondayKey --initial-twin-tags "{'IoTEdge' : 'FixedBuffer'}" --edge-enabled=true
# Grupo para IoT Hub
az iot dps enrollment-group create -g $rg --dps-name $dpsName --enrollment-id "IoTHub" --primary-key $primaryKey --secondary-key $secondayKey --initial-twin-tags "{'IoTHub' : 'FixedBuffer'}" --edge-enabled=false
# Verificamos que se han creado
az iot dps enrollment-group list --dps-name $dpsName --resource-group $rg

Probando IoT Hub DPS

Con esto que hemos hecho ya estamos preparados para poder empezar a aprovisionar nuestros dispositivos. Bueno, en realidad no del todo… He elegido aprovisionar grupos ya que tiene un paso más respecto a aprovisionar dispositivos individuales.

No es una buena idea el distribuir de manera masiva una clave que permite registrar tantos dispositivos quieras de manera automática. Es por esto que IoT Hub DPS trabaja con una clave derivada cuando se trata de inscripción de grupos. Esta clave derivada se puede calcular utilizando HMACSHA256, para lo cual la propia documentación nos ofrece un código de ejemplo.

Probar el aprovisionamiento de un dispositivo IoT Hub es muy sencillo ya que basta con que nos bajemos el repositorio de ejemplos de IoT, y ejecutemos el ejemplo ‘ProvisioningDeviceSamples‘ seleccionando el proyecto de inicio en ‘SymmetricKeySample‘. El propio fichero Program.cs nos guía mediante comentarios sobre que tenemos que rellenar y donde para poder validar el funcionamiento.

{
  "IoTHub": "FixedBuffer"
}

De igual modo, vamos a probar que se registra correctamente si el dispositivo es de tipo Edge. Esto requiere que configuremos su fichero config.yaml y le indiquemos los datos que necesita para poder conectarse (que son los mismos que en el caso anterior). Para poder probar que todo esto funciona de manera más sencilla, he creado una imagen Docker que a la que indicándole las variables de entorno ‘SCOPE_ID‘ y ‘SYMMETRIC_KEY‘, va a registrar un dispositivo IoT Edge con el nombre del contenedor utilizando IoT Hub DPS. No es una imagen 100% funcional, pero para la prueba que vamos a hacer nosotros es suficiente. Puedes ver el código de la imagen en GitHub si tienes interés

docker run --privileged=true -e SCOPE_ID=$SCOPE_ID -e SYMMETRIC_KEY=$primaryKey jorturfer/iot-edge-dps-post

{
  "IoTEdge": "FixedBuffer"
}

Conclusión

Una vez más, me dejo muchas cosas chulas en el tintero, pero la verdad es que si las revisásemos todas en detalle, ni yo mismo leería mi entrada por el tamaño final…

Hemos hecho una pequeña aproximación al aprovisionamiento de dispositivos utilizando IoT Hub DPS ya que es una herramienta que personalmente me parece muy potente y útil. Respecto a su coste hay que decir también que, aunque sí tiene coste, es ridículo a cambio del trabajo que ahorra, nada más y nada menos que €0,085 por cada 1.000 operaciones.

En futuras entradas, me gustaría unificar todos y cada uno de estos conceptos que hemos ido planteando tanto aquí como en las entradas que escribí para Plain Concepts en una entrada con una ejemplo funcional E2E. ¿Qué opinas? ¿Crees que sería interesante? ¿Conocías previamente IoT Hub Device Provisioning Service?

**La entrada IoT Hub DPS: Creando dispositivos bajo demanda se publicó primero en Fixed Buffer.**

Después de unas semanas muy liado con unas complicaciones personales (solo he tenido tiempo de publicar la review de NDepend), ya estamos de vuelta y además con una entrada que toca muchos palos. Vamos a hablar de Azure, vamos a hablar de C# y vamos a hablar de Docker.

Por el título de la entrada, no es ningún secreto el tema del que vamos a hablar de Azure IoT Edge y sus módulos. La idea de escribir esto es porque no hace mucho escribí en el blog de Plain Concepts una entrada sobre cómo desplegar cargas de trabajo ‘on-prem’ utilizando IoT Hub.

Aunque lo que se plantea en la entrada es totalmente cierto y el runtime de IoT Edge permite correr imágenes Docker sin más, la verdad es que nos permite ir un paso más allá. IoT Edge nos va a permitir crear módulos especializados con los que vamos a poder utilizar las funcionalidades propias de IoT Hub y todo ello empaquetado en una imagen Docker. Con esto vamos a conseguir que nuestro IoT Edge deje de ser un ‘nodo’ de Docker al que podemos mandar cosas y se convierta en un verdadero punto de computación de borde.

¿Por qué debería usar módulos de IoT Hub en lugar de imágenes Docker normales?

Es cierto que con una imagen Docker las cosas soy mucho más simples comunes a la hora de desarrollar. Tienes un fichero Dockerfile, expones unos puertos, creas tus APIs, y si necesitas comunicarte con IoT Hub para enviar mensajes, puedes utilizar directamente el cliente de IoT Hub para el lenguaje con el que estés trabajando. ¿Por qué debería entonces complicarme la vida?

Pues, aunque los módulos implican añadir ciertos cambios a la hora de programar (más bien de desplegar), no dejan de ser una aplicación de consola sin más, al que se le ha dotado de funcionalidad para interactuar con el runtime sobre el que está corriendo. Esto se traduce en 2 grandes ventajas:

• Delegamos en el runtime el enrutado de los mensajes entre los diferentes módulos.
• Tenemos a nuestra disposición toda la potencia de IoT Hub en cada módulo (envío de métricas/mensajes, dispositivo gemelo, mensajes desde la nube al dispositivo, etc…), utilizando la conexión del runtime de IoT Edge.

¿Las ventajas son realmente ventajas?

Vale, he planteado las 2 cosas que a mi parecer son las principales mejoras, ¿pero esto realmente son mejoras? Analicemos la primera de ellas, el enrutado de mensajes.

El planteamiento de IoT Edge es tener pequeños programas que vayan añadiendo procesado sobre los datos de entrada. Imaginemos un caso donde tenemos una cámara capturando imágenes de una autopista, las imágenes que se obtienen se procesan y por último se etiquetan. Es cierto que esto se podría hacer de manera monolítica todo en el mismo proceso, pero eso dificulta el reutilizar código. Si separamos la adquisición en una imagen, el procesado en otra y el etiquetado en otra, vamos a poder cambiar una de las piezas por otra y reutilizar al máximo.

Por poner un caso, podríamos tener otro escenario en el que solo queramos capturar imágenes y mandarlas a un almacenamiento, el hecho de que la adquisición este modularizada, nos va a permitir reaprovechar ese módulo y añadir solo la parte nueva de persistencia.

Hecha esta aclaración sobre la modularización y reutilización, podríamos extraer varios módulos del conjunto de los dos escenarios:

• Adquisición de imágenes.
• Procesado de las imágenes.
• Etiquetado de las imágenes.
• Persistencia de las imágenes.

Y su representación sería algo así:

En una situación multi contenedor corriendo sobre Docker, simplemente podríamos decirle a un contenedor, por ejemplo, Captura, que una vez que tenga una imagen la mande al siguiente contenedor siguiendo un modelo push (es el propio contenedor el que se encarga de empujar los datos al siguiente). Incluso podríamos cambiar el planteamiento y utilizar un modelo pull donde cada paso obtenga los datos del paso previo.

Esto tiene problemas a la hora de reutilizar los módulos, ya que cada módulo necesita tener consciencia o desde donde obtiene los datos o a donde los tiene que enviar. Tenemos acoplamiento entre los módulos. Si por ejemplo quisiéramos añadir al escenario 1 la persistencia entre la captura y el procesado (o en cualquier otra posición), tendríamos que modificar el código del módulo para que se adapte al nuevo escenario, no nos vale solo con modificar las configuraciones.

En este punto, voy a aclarar que en programación casi todo es posible, e incluso esto se puede solucionar añadiendo código o creando nosotros mismos sistemas complejos que lo solucionen. En algunos casos puede que sea necesario, pero generalmente es tiempo y esfuerzo en balde.

Para evitar esto, podríamos añadir algún sistema de colas donde cada módulo publique los resultados a una cola y lea las entradas desde otra cola. De este modo cada módulo no necesita saber nada al respecto del anterior ni del siguiente, simplemente lee los datos desde una cola y los deja en otra cola. El problema de este planteamiento es que somos nosotros los que vamos a tener que mantener la infraestructura de colas… y aquí es donde coge importancia el delegar en el runtime el enrutado de mensajes.

IoT Edge nos proporciona de serie un sistema de enrutado que podemos utilizar desde los módulos especializados de IoT Edge. Nosotros simplemente vamos a definir una o más entradas para nuestro módulo de IoT Edge, y de igual manera vamos a escribir una serie de salidas del módulo. Después, desde la propia configuración de IoT Edge vamos a definir mediante lenguaje de consulta el coger las salidas un el módulo A y enviarlas a la cola de entrada del módulo B. Es importante aquí el punto de lenguaje de consulta, ya que vamos a poder aplicar condiciones para que la ruta se cumpla.

Esto desacopla totalmente los módulos entre si, ya que estamos usando un sistema de colas, pero en este caso es el propio runtime quien lo gestiona.

Por otro lado, comentaba que la segunda gran ventaja era que el propio módulo de IoT Edge era capaz de ser un dispositivo IoT en si mismo, aprovechando la conexión del runtime. Esto significa que por ejemplo que podemos utilizar el sistema de rutas para enviar métricas a IoT Hub, es decir, es posible especificarle a IoT Edge que coja la cola de salida del módulo A y que directamente la envíe como una métrica a IoT Hub.

Creando la solución IoT Edge

Como hablar siempre es muy fácil, vamos a crear un módulo IoT Edge desde 0, que enrute los mensajes generados desde el simulador de pruebas que ofrece Microsoft. Lo primero de todo es preparar el entorno, el resumen ejecutivo de los elementos que necesitamos es .Net Core y una extensión para Visual Studio o Visual Studio Code que nos de soporte para desarrollar módulos IoT Edge. Una vez instalada la extensión, seguiremos la documentación específica para configurar la extensión con nuestro IoT Hub.

En este caso por versatilidad, yo estoy utilizando Visual Studio Code, por lo que, una vez instalada y configurada la extensión, basta con escribir «Azure IoT Edge: New IoT Edge solution» en la paleta de comandos.

Esto iniciará un pequeño asistente en el que nos va a pedir una ruta, un nombre para la solución, y nos va a ofrecer una plantilla de módulo IoT Edge en varios lenguajes diferentes. Una vez seleccionado el nombre del módulo, nos va a pedir el último paso que es decirle cual es el registro de Docker en el que se tiene que subir la imagen con el módulo. Este registro puede ser público o privado.

Una vez hecho esto, ya tenemos listo el andamiaje del proyecto, y ya podemos editar y generar el módulo, desplegarlo, depurarlo,… Este andamiaje está compuesto de varios ficheros que vamos a analizar.

El fichero .env contendrá variables que se reemplazan durante el proceso de generación. Principalmente valores sobre el registro de Docker.

Dentro de la carpeta .vscode, se ha creado el código necesario para ejecutar en local el código (que no deja de ser una aplicación de consola), o para depurarlo dentro de un contenedor Docker.

La carpeta config va a contener los ficheros de configuración que generamos como artefacto de salida del proceso. Estos ficheros son muy útiles ya que son el json que podemos utilizar para desplegar sobre un dispositivo IoT Edge el conjunto de módulos que definamos. Esto es así porque realmente hemos creado una solución completa de IoT Edge que contiene módulos, algunos pueden ser de terceros y algunos nuestros (como es el caso).

En la carpeta modules es donde encontramos la magia. Aquí es donde vamos a encontrar los diferentes módulos que estemos creando. Ahora entraremos en detalle.

Por último, nos encontramos los ficheros deployment.template.json y deployment.debug.template.json. Estos ficheros son los que van a servir de entrada para que durante el proceso de generación del módulo se cree el artefacto de salida en la carpeta config. La principal diferencia entre ellos es que el que contiene debug nos va a permitir depurar el código del contenedor.

El módulo IoT Edge

Para acabar de revisar que tenemos, cuando entramos en la carpeta modules nos encontramos con un buen número de ficheros Dockerfile, un fichero module.json y un program.cs.

Si comprobamos que contiene el fichero program.cs, nos encontramos con que no es más que una aplicación de consola. Hay que reconocer que la plantilla no es todo lo óptimo que debería ser en cuanto a buenas prácticas, pero podríamos reducirlo a algo así:

using System;
using System.Runtime.Loader;
using System.Threading;
using System.Threading.Tasks;
using Microsoft.Azure.Devices.Client;
using Microsoft.Azure.Devices.Client.Transport.Mqtt;

namespace SampleModule
{
    class Program
    {
        static int counter;

        static async Task Main(string[] args)
        {
            await InitAsync();

            var cts = new CancellationTokenSource();
            AssemblyLoadContext.Default.Unloading += (ctx) => cts.Cancel();
            Console.CancelKeyPress += (sender, cpe) => cts.Cancel();
            await WhenCancelledAsync(cts.Token);
        }

        public static Task WhenCancelledAsync(CancellationToken cancellationToken)
        {
            var tcs = new TaskCompletionSource<bool>();
            cancellationToken.Register(s => ((TaskCompletionSource<bool>)s).SetResult(true), tcs);
            return tcs.Task;
        }

        static async Task InitAsync()
        {
            MqttTransportSettings mqttSetting = new MqttTransportSettings(TransportType.Mqtt_Tcp_Only);
            ITransportSettings[] settings = { mqttSetting };

            ModuleClient ioTHubModuleClient = await ModuleClient.CreateFromEnvironmentAsync(settings);
            await ioTHubModuleClient.OpenAsync();

            await ioTHubModuleClient.SetInputMessageHandlerAsync("input1", PipeMessage, ioTHubModuleClient);
        }

        static async Task<MessageResponse> PipeMessage(Message message, object userContext)
        {
            int counterValue = Interlocked.Increment(ref counter);

            var moduleClient = userContext as ModuleClient;
            if (moduleClient == null)
            {
                throw new InvalidOperationException("UserContext doesn't contain " + "expected values");
            }           
            
            //Encolamos el mensaje como salida
            await moduleClient.SendEventAsync("output1", message);
            return MessageResponse.Completed;
        }
    }
}

Si analizamos el código (he cambiado ligeramente para usar await en vez de .Wait() respecto a la plantilla y borrado código que no aporta), podemos comprobar que tenemos un Main que inicializa el dispositivo llamando a InitAsync (Init en la plantilla original). Dentro de este método, se inicializa el módulo IoT Edge a través del tipo ModuleClient.

Sobre este módulo registramos un manejador para cada vez que llegue un mensaje por la cola «input1» con la línea:

await ioTHubModuleClient.SetInputMessageHandlerAsync("input1", PipeMessage, ioTHubModuleClient);

Añadir nuevas entradas es tan simple como registrar más manejadores para otras colas de entrada.

Para escribir los mensajes a una cola de salida, se utiliza la línea:

await moduleClient.SendEventAsync("output1", message);

En este caso, simplemente estamos utilizando el mensaje de la cola de entrada «input1» del módulo IoT Edge y lo estamos colocando en la cola de salida «output1».

Adicionalmente a lo que nos ofrece la plantilla, el módulo nos ofrece también varios métodos con los que vamos a poder ampliar la utilidad del módulo mediante configuración de dispositivo gemelo, recepción de mensajes CloudToDevice, o llamadas a métodos directos. Esto se consigue simplemente añadiendo a la inicialización las líneas:

await ioTHubModuleClient.SetDesiredPropertyUpdateCallbackAsync(OnDesiredPropertiesUpdateAsync, ioTHubModuleClient);
await ioTHubModuleClient.SetMessageHandlerAsync(HandleMessageAsync,ioTHubModuleClient);
await ioTHubModuleClient.SetMethodHandlerAsync("hello",HelloMethodHandlerAsync,ioTHubModuleClient);

A este código hay que añadirle los callback de los manejadores, para no alargar una entrada ya de por si larga, puedes consultar el código completo en el repositorio de Github.

Hay que tener en cuenta que tanto las colas de entrada y salida, como el resto de las funcionalidades como métodos directos o dispositivo gemelo están ligados al módulo y estarán disponibles en cualquier runtime de IoT Edge donde despleguemos el módulo y dependerá de si queremos usarlos o no.

Una vez visto el código, ¿por qué tantos Dockerfile?. La idea de que haya tantos es que estamos creando un módulo que queremos que se pueda desplegar en cualquier sitio que pueda correr IoT Edge, y esto son muchas arquitecturas de microprocesador diferente. Gracias a tener todos esos Dockerfile ya en la plantilla, nos abre la puerta a poder hacer que nuestro módulo de IoT Edge corra en Linux, Windows, en microprocesadores AMD, ARM,…

Vamos a poder configurar la arquitectura de destino simplemente ejecutando en la paleta de comandos «Azure IoT Edge: Set Default Target Platform for Edge Solution«. Esto nos va a dar varias opciones disponibles, que son las que están definidas en el fichero module.json, donde vamos a relacionar las arquitecturas con los Dockerfile concretos entre otras cosas como especificar la versión del módulo.

Actualmente, Docker soporta de forma experimental el crear manifiestos de imágenes para múltiples arquitecturas simultáneamente, siendo el runtime de Docker el que se descarga la imagen de su arquitectura especifica. Si tienes interés en el tema, hablo de ello en la entrada Cómo crear una imagen docker multiarquitectura desde cero.

Una vez que hemos terminado de configurar y programar nuestro módulo, vamos a poder generar la imagen o imágenes y subirlas al repositorio haciendo click derecho sobre el json del módulo o de la solución y pulsando sobre «Build and Push IoT Edge Module Image» o «Build and Push IoT Edge Solution» respectivamente.

En caso de que hayamos elegido la segunda opción, además de generar las imágenes y subirlas, va a generar el fichero de deployment en la carpeta config de la solución.

Configurando las rutas y desplegando la solución

Ya casi estamos listos para desplegar la solución con nuestro módulo en un dispositivo IoT Edge. Tenemos el módulo listo, pero para poder probar el sistema de módulos de manera sencilla, vamos a necesitar desplegar varios módulos juntos.

Por suerte la plantilla de la solución de IoT que hemos usado, ya nos ha creado los ficheros deployment con un módulo extra de simulación, que va a sacar por su cola de salida «temperatureOutput«. En la sección de rutas (routes) del json de despliegue deployment.template.json vamos a definir los diferentes enrutados internos y externos de los mensajes como parte de $edgeHub. En este caso la plantilla ya nos ofrece 2 rutas que son desde la salida del simulador a la entrada del módulo, y desde la salida del módulo a $upstream. Es importante aclarar $upstream significa que el mensaje será enviado directamente a IoT Hub como una métrica del dispositivo:

"routes": {
  "SampleModuleToIoTHub": "FROM /messages/modules/SampleModule/outputs/* INTO $upstream",
  "sensorToSampleModule": "FROM /messages/modules/SimulatedTemperatureSensor/outputs/temperatureOutput INTO BrokeredEndpoint(\"/modules/SampleModule/inputs/input1\")"
}

Cada vez que actualicemos la plantilla de despliegue, será necesario generar de nuevo el manifiesto de despliegue para la arquitectura concreta. Para esto vale con hacer click derecho sobre el json de la plantilla y seleccionar «Generate IoT Edge Deployment Manifest«.

Por último, ya solo queda desplegar la solución. Para esto es suficiente con hacer click derecho sobre el json del manifiesto en la carpeta de config y seleccionar «Create Deployment for Single Device«. Con esto vamos a poder elegir el dispositivo sobre el que queremos desplegar y «et voilà«. Ya hemos desplegado nuestro propio módulo IoT Edge y hemos configurado sus mensajes.

Conclusión

Soy consciente de que se han quedado muchas cosas en el tintero, no he entrado a como depurar el código, usar el simulador, configuraciones complejas,… La idea detrás de todo esto era dar una visión de alto nivel sobre cómo es posible crear y desplegar módulos IoT Edge sin sufrir mucho por el camino.

Siempre que he usado IoT Edge he intentado usar directamente imágenes stand-alone porque pensaba que el sistema de módulos era complejo y que no valía la pena entrar en él, pero evidentemente me equivocaba.

Una cosa importante que no he dicho pero que también es importante, es que IoT Edge no tiene coste adicional, sobre el coste de mensajes que tengas en IoT Hub y además funciona con el tier gratuito, por lo que es posible utilizar IoT Edge gratis siempre que no mandemos más de 8 mil mensajes al día, momento en el que se cortará la comunicación con IoT Hub hasta el día siguiente.

De momento, te dejo el enlace a la documentación oficial de IoT Edge, donde vas a poder encontrar no solo como desarrollar módulos, sino como hacer ajustes finos en muchas partes del sistema.

¿Y tú qué opinas? ¿Conocías los módulos para IoT Edge? Déjame en los comentarios si quieres que haga otra entrada más en detalle sobre cómo desarrollar módulos, depurarlos y hacer configuraciones más complejas.

**La entrada Creando módulos especializados para Azure IoT Edge se publicó primero en Fixed Buffer.**

Hace ya unos meses, me escribió Patrick Smacchia, autor y lead del equipo de desarrollo de NDepend para ofrecerme probar su herramienta y hacer una review sobre ella.

Me ha costado sacar tiempo para trastear la herramienta (lo siento Patrick ), pero finalmente lo he podido hacer y ahí vamos con ello.

Disclaimer: Nada de lo que digo aquí está condicionado, Patrick me ofreció una licencia para probar el software y hacer una review objetiva sobre lo que ofrece si me parecía interesante, pero en ningún caso ha revisado ni opinado sobre lo que aquí estoy escribiendo

¿Qué es NDepend?

NDepend es un analizador de código con el que vamos a poder generar informes interactivos con métricas sobre la calidad del código analizado. Cada métrica está documentada y es monitorizable.

Se trata por tanto de una herramienta, enfocada a desarrolladores y arquitectos software, que realiza análisis estático de proyectos .NET y .NET Core.

Además, puede utilizarse tanto en nuestro propio equipo durante el proceso de desarrollo (ejecutable standalone e integraciones con Visual Studio), como en varios sistemas de integración continua como pueden ser Azure DevOps, TFS, Teamcity, Jenkins y algunas más.

¿Para qué me puede servir NDepend?

Detectar errores y demás está muy bien, pero eso ya lo consigo con FxCop Analyzers, ¿no?. La verdad es que NDepend llega bastante más alla de los que puede ser análisis de código estático simplemente. Una de las ventajas que nos aporta es la detección automática de puntos donde algo raro está pasando (code smells), así como la detección de buenas prácticas (o ausencia de ellas). Obviamente, también tenemos métricas sobre cantidad de lineas, complejidad ciclomática, etc…

En resumen (de brocha gorda):

• Detección de código sospechoso (code smells)
• Detección de zonas donde el código es complejo (complejidad ciclomática)
• Detección de referencias (que partes de nuestro código son las más utilizadas)
• Detección de acoplamiento
• Cálculo de deuda técnica (sí, aunque no lo reconozcas, no todo tu código es perfecto)
• Tendencias y gráficos de evolución sobre la calidad del código
• Estimación del tiempo invertido

Un caso práctico

Como siempre, hablar es fácil y por eso quiero poner un caso práctico del análisis de una aplicación. En mi caso concreto yo he probado NDepend con un cliente en el que tenemos nada más y nada menos que 36 proyectos dentro de la misma solución (pequeñito el sistema… xD). Como evidentemente no puedo dar datos sobre los clientes de mi trabajo, el caso práctico lo vamos a plantear sobre un proyecto público que a más de uno os puede resultar familiar como es Dapper, un micro-ORM desarrollado por la gente de Stack Exchange (casi nada…)

Lo primero de todo, es que yo he optado por utilizar la versión standalone directamente en lugar de la integración con Visual Studio, ya que en muchos proyectos utilizo Visual Studio Code. No obstante, en una prueba rápida con su integración en VS he podido comprobar que ofrece prácticamente lo mismo.

Para esto simplemente he tenido que ejecutar la aplicación que me he descargado sin necesidad de hacer ninguna instalación extra. Una vez dentro de Visual NDepend, basta con ir al menú de archivo y decirle que queremos analizar un proyecto o solución de VS.

Tras unos instantes analizando el proyecto (que dependerá del tamaño del proyecto que estemos analizando), podremos acceder a los diferentes paneles con la información.

Panel general (dashboard)

Este es el cuadro de mando general con las métricas del análisis, por ejemplo, en el proyecto de Dapper:

• 13059 líneas de código
• 129 archivos de código fuente
• 11 ensamblados
• 40 espacios de nombres
• 6385 líneas de comentarios
• Estimación del esfuerzo para realizar la aplicación: 345 días
• Deuda técnica: 40 días
• 5 días y 6 horas de esfuerzo para reducir la deuda técnica de C a B
• 2 alertas de fallos primordiales a revisar
• 8 alertas de reglas críticas no superadas

Vista de métricas

Este es otro panel que aporta a mi modo de ver una información importante de manera muy visual. Gracias a sus tres selectores vamos a poder configurar el nivel de agrupación (cantidad de métodos, campos, espacios de nombres,…), dentro de la agrupación, vamos a poder seleccionar en base a que métrica queremos que tenga el tamaño, y por último vamos a poder seleccionar en base a que métrica queremos que tenga el color.

De este modo vamos a poder hacer una revisión visual muy rápida, por ejemplo, de la complejidad ciclomática de cada método, haciendo que se represente más grande cuantas más referencias tiene:

Gráfico y matriz de dependencias

Otros de los paneles que ofrece y que me parecen extremadamente interesantes son los referentes a las dependencias dentro de la solución. Estos paneles de dependencias nos van a mostrar, valga la redundancia, las dependencias.

De manera gráfica:

Y para proyectos más grandes, en forma de matriz:

Conclusión

Aunque he tenido poco trato con NDepend en batallas del día a día, la verdad es que creo que es una herramienta con mucho potencial. La posibilidad de crear reglas de análisis propias le otorga un grado extra de flexibilidad que creo que puede conseguir que se adapte a más escenarios.

El soporte que ofrece para diferentes entornos de integración y despliegue continuo la verdad que me parece una maravilla también, ya que simplifica mucho el proceso de utilización de la herramienta.

Más allá del coste de licenciamiento, que puede ser o no una barrera para adoptar NDepend (como cualquier otro software), si que creo importante resaltar que es una herramienta muy focalizada en .Net.

También he de añadir que NDepend se integra con SonarQube y puede hacer su trabajo también junto a este si necesitas encajarlo con esta herramienta.

Si con todo esto que he comentado, crees que puede encajarte esta herramienta, te recomiendo echarle un ojo tanto a sus costes como a su versión de prueba.

¡Participa en el sorteo!

Como comentaba en el titulo, NDepend ha cedido muy amablemente una licencia de desarrollador, valorada en 399 Euros, para sortear entre los lectores de FixedBuffer.

Para participar, basta con escribir un comentario en este post (OJO, en la sección de correo electrónico hay que poner uno válido o no podré contactar), podéis aprovechar también para contarnos qué os parece NDepend o en qué pensáis que os podría ayudar, todo lo que os gusta FixedBuffer, o si hace frío o calor. La cosa es comentar algo para participar

El sorteo se realizará el próximo domingo día 10 octubre de 2020 y consistirá en elegir al azar entre uno de los comentarios. Tras ello, me pondré en contacto con el autor para detallarle los pasos a dar para reclamar su licencia gratuita.

¡No dejéis de participar! ¡Suerte!

Edición 10-10-2020:
Felicidades Lorenzo, tu comentario ha sido el ganador!!!

**La entrada Mejorando la calidad del código con NDepend (con sorteo de licencia!) se publicó primero en Fixed Buffer.**

Fin del verano y vuelta a la rutina. Parece mentira que hoy hace 2 años empezase la andadura de este blog. Han sido dos años de descubrimiento personal y la verdad no pensaría que llegaría hasta aquí

Con esta entrada ya se convierte en tradición (2 de 2 veces) el día del aniversario echar la vista hacia atrás y hacer un resumen (breve, que no quiero aburrir) de los principales hitos del año anterior.

En primer lugar, el hecho más evidente, FixedBuffer sigue dando guerra y para celebrarlo, el blog ha tenido un lavado de cara para darle un aire más moderno y minimalista, pero sobre todo mejor optimizado para ordenador y móvil. El número de lectores desde móvil y tablet, aunque es mucho menor que el de ordenador, va creciendo poco a poco y todos os merecéis la mejor experiencia posible el tiempo que pasáis aquí.

Estaré encantado de leer en los comentarios opiniones sobre el nuevo estilo

En segundo lugar, he sido renovado de nuevo como MVP en la categoría de ‘Tecnologías de desarrollo’ y ya llevo 2 anillos. Este año he recibido el premio en la mejor compañía como os contaba en su momento.

Tercero y no por eso menos importante, me he convertido en tutor de mi propio curso en CampusMVP: Testing de aplicaciones .NET y .NET Core con xUnit y Moq. Han sido muchos meses haciendo un gran esfuerzo para sacar el curso adelante, pero todo ha ido genial y la gente está muy contenta con él (cosa que me hace tremendamente feliz).

Por cierto, con motivo del aniversario la gente de CampusMVP hace un descuento del 10% utilizando el código FIXED2Y antes del 20 de septiembre de 2020. Si estabas pensando en hacer el curso, es la oportunidad perfecta.

Además, he podido coincidir con algunos de vosotros en las charlas que me han dejado dar por diferentes comunidades (esas cosas que hacíamos antes del COVID-19 como excusa para juntarnos y beber cerveza). Eso es algo que siempre gusta y es de agradecer porque echamos muy buenos ratos

Otra cosa que me gustaría decir es que por fin he puesto al día la sección de colaboraciones, donde si os habéis quedado con ganas de leer más cosillas de las que he escrito, podéis ir y consultar ya que hay cerca de 20 artículos más publicados en otros blogs.

Se avecina un año muy interesante por delante. De antemano os quiero dar las gracias a todos ya que, si no fuese por vosotros, FixedBuffer no estaría cumpliendo su segundo año online, y es que como he dicho ya muchas veces, un blog sin lectores no es un blog. Dicho esto, vamos a ver el top 5 de entradas del último año:

1. Haciendo fácil el acceso a datos con Entity Framework Core (Parte 2)
2. Worker Service: Cómo crear un servicio .Net Core 3 multiplataforma
3. Generación de ficheros «Excel» (xlsx) con ClosedXML
4. ClosedXML, una manera fácil de dar formato a nuestros .xlsx
5. Haciendo fácil el acceso a datos con Entity Framework Core

Y seguido muy de cerca se ha quedado Escribiendo código de alto rendimiento en .Net Core. Una entrada muy especial por conseguir la friolera de 473 visitas en un solo día, un record nada despreciable para un pequeño blog como este

¡¡Muchas gracias a todos los seguidores de FixedBuffer, que sois los que hacéis que esto valga la pena!!

**La entrada ¡¡FixedBuffer ha cumplido su segundo año!! se publicó primero en Fixed Buffer.**

EDITADO: Por fin he actualizado la imagen y así es como se ve la caseta

Un año más llega el veranito y con él las vacaciones. Es momento de coger aire, descansar y recuperar fuerzas para seguir adelante. Este año debido a los problemas de movilidad por esta pandemia mundial me ha pillado el toro y repito foto :(.

He de decir que la casa está terminada (recordemos que a eso me dediqué el verano pasado) y a la vuelta de vacaciones prometo actualizar la foto por la de la casita terminada

Dicho esto, es hora de decir adiós hasta septiembre, momento en el que volveremos a la carga con unas ideas a las que estoy dando forma y que espero poner en marcha antes del segundo aniversario de FixedBuffer. Además de eso, ya me conocéis, no puedo parar, así que estoy preparando contenido para algunos otros blogs con los que colaboro así que estad atentos a la sección de colaboraciones

Muchas gracias a todos los que hacéis que este proyecto siga adelante y nos vemos en septiembre

**La entrada ¡A descansar! se publicó primero en Fixed Buffer.**