Maven + Mac M1 (aarch64) + Fabric8 docker-maven-plugin

Ya llevamos tiempo con los nuevos Mac con chip M1 (aarch64) en el mercado y la verdad es que tenemos muchísimas aplicaciones ya migradas y las que no funcionan bastante bien con Rosetta (de hecho en lagunas ocasiones funciona hasta mejor 🤯).

Sin embargo todavía hay cosas que no van finas y ese es el caso si usas: Maven + Mac M1 aarch64 + io.fabric8 docker-maven-plugin.

En este tutorial vamos a ver como solucionarlo.

Índice

1. El problema
2. La solución: Redireccionar la comunicación a través de socat
3. Bola extra
4. Conclusiones
5. Sobre el autor

1. El problema

Cuando ejecutas Maven verás que da un error similar a:

[INFO] --- docker-maven-plugin:0.37.0:start (start) @ test-project ---
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  4.660 s
[INFO] Finished at: 2021-11-09T10:02:52+01:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal io.fabric8:docker-maven-plugin:0.37.0:start (start) on project test-project: Execution start of goal io.fabric8:docker-maven-plugin:0.37.0:start failed: An API incompatibility was encountered while executing io.fabric8:docker-maven-plugin:0.37.0:start: java.lang.UnsatisfiedLinkError: could not load FFI provider jnr.ffi.provider.jffi.Provider
[ERROR] -----------------------------------------------------
[ERROR] realm =    plugin>io.fabric8:docker-maven-plugin:0.37.0
[ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
[ERROR] urls[0] = file:~/.m2/repository/io/fabric8/docker-maven-plugin/0.37.0/docker-maven-plugin-0.37.0.jar

...

[ERROR] : could not get native definition for type `POINTER`, original error message follows: java.lang.UnsatisfiedLinkError: Unable to execute or load jffi binary stub from `/var/folders/8r/_69wbkk57hj3x489xf8r0fh40000gn/T/`. Set `TMPDIR` or Java property `java.io.tmpdir` to a read/write path that is not mounted "noexec".
[ERROR] ~/src/test-project/jffi13802233681866717935.dylib: dlopen(~/src/test-project/jffi13802233681866717935.dylib, 0x0001): tried: '~/src/test-project/jffi13802233681866717935.dylib' (fat file, but missing compatible architecture (have 'i386,x86_64', need 'arm64e')), '/usr/lib/jffi13802233681866717935.dylib' (no such file)
[ERROR]     at com.kenai.jffi.internal.StubLoader.tempLoadError(StubLoader.java:424)
[ERROR]     at com.kenai.jffi.internal.StubLoader.loadFromJar(StubLoader.java:409)

...

Este error ocurre porque la librería de bajo nivel que usa Fabric8 para conectar con el socket del Docker daemon todavía no está adaptada a la nueva arquitectura, así que básicamente el problema es que el docker-maven-plugin de Fabric8 no es capaz de encontrar al Docker daemon.

Puedes encontrar más información de este problema en: https://github.com/fabric8io/docker-maven-plugin/issues/1257

Y también en: https://github.com/jnr/jnr-unixsocket/issues/95

Y un poco más en: https://github.com/jnr/jffi/issues/105

Así que seguramente es cuestión de tiempo que acaben dando soporte (si alguien se anima igual les puede echar una mano 😉).

Pero mientras tanto aquí podemos ver una solución (que encontraréis en inglés en los enlaces anteriores).

2. La solución: Redireccionar la comunicación a través de socat

El truco que vamos a hacer es “engañar” a docker-maven-plugin para que haga la comunicación a través de URL en lugar de socket directo. Y para ello vamos usar la utilidad de línea de comandos socat.

socat se define a sí mismo como:

Socat is a command line based utility that establishes two bidirectional byte streams and transfers data between them.

¿Qué quiere decir esto? Que con socat vamos a ser capaces de redireccionar el tráfico entre docker-maven-plugin y el Docker daemon.

Primero tendremos que instalar socat ya que no viene en el sistema operativo:

brew install socat

Ahora tendremos que definir la variable de entorno:

export DOCKER_HOST=tcp://127.0.0.1:2375

Con esto le estamos diciendo a docker-maven-plugin que en vez de usar el socket use la URL indicada en la variable DOCKER_HOST. Ojo con esta variable porque si la ponéis en los scripts .xxxrc de vuestra shell entonces todos los clientes de Docker van a intentar usar esa URL y esto igual no os interesa, ahí cada uno verá que se adapta mejor al uso que le quiere dar.

Ahora levantamos socat:

socat TCP-LISTEN:2375,range=127.0.0.1/32,reuseaddr,fork UNIX-CLIENT:/var/run/docker.sock

Con esto lo que estamos haciendo es que todo el tráfico que vaya a la URL que habíamos definido con DOCKER_HOST, socat se va a encargar de mandarlo al puerto del Docker dameon, y viceversa (es decir socat establece una comunicación bidireccional).

Este comando lo podemos lanzar en otra pestaña de nuestro terminal o incluso en background añadiendo la clásica “&” al final, aunque a mi esta opción no me gusta mucho ya que no quiero dejar encendido siempre el socat, sino levantarlo o tirarlo en función de cuando lo necesito.

Y con esto estaría todo, ya deberíamos poder lanzar Maven para ejecutar el plugin docker-maven-plugin con normalidad 👌.

3. Bola extra

Simplemente para que tengáis una referencia rápida, os dejo aquí un ejemplo de configuración del pom.xml de Maven con el plugin docker-maven-plugin para, por ejemplo, levantar una base de datos PostgreSQL para ejecutar los tests de integración.

...
<properties>
  ...
  <docker-maven-plugin.version>0.37.0</docker-maven-plugin.version>
  <it.postgresql.image>postgres:13.3-alpine</it.postgresql.image>
  <it.postgresql.port>5432</it.postgresql.port>
  <it.postgresql.db>postgres</it.postgresql.db>
  <it.postgresql.password>indescifrable</it.postgresql.password>
  <it.postgresql.removeVolumesOnStop>true</it.postgresql.removeVolumesOnStop>
  ...
</properties>
...
<plugin>
    <!-- Run database Docker container during integration tests-->
    <groupId>io.fabric8</groupId>
    <artifactId>docker-maven-plugin</artifactId>
    <version>${docker-maven-plugin.version}</version>
    <configuration>
        <images>
            <image>
                <name>${it.postgresql.image}</name>
                <run>
                    <ports>
                        <port>${it.postgresql.port}:5432</port>
                    </ports>
                    <env>
                        <POSTGRES_DB>${it.postgresql.db}</POSTGRES_DB>
                        <POSTGRES_PASSWORD>${it.postgresql.password}</POSTGRES_PASSWORD>
                    </env>
                    <wait>
                        <log>database system is ready to accept connections</log>
                    </wait>
                </run>
            </image>
        </images>
    </configuration>
    <executions>
        <execution>
            <id>start</id>
            <phase>pre-integration-test</phase>
            <goals>
                <goal>start</goal>
            </goals>
        </execution>
        <execution>
            <id>stop</id>
            <phase>post-integration-test</phase>
            <goals>
                <goal>stop</goal>
            </goals>
            <configuration>
                <removeVolumes>${it.postgresql.removeVolumesOnStop}</removeVolumes>
            </configuration>
        </execution>
    </executions>
</plugin>
...

4. Conclusiones

No siempre tenemos el tiempo para esperar a la solución oficial, pero siempre podemos buscarnos las mañas para conseguir un workaround, mas en el mundo Unix donde las opciones son prácticamente infinitas.

5. Sobre el autor

Alejandro Pérez García (@alejandropgarci).

Ingeniero en Informática (especialidad de Ingeniería del Software) y Certified ScrumMaster.

Socio fundador de Autentia Real Business Solutions S.L. – “Soporte a Desarrollo”.