Multi-arquitectura en Todo
Cuando comenzamos a construir nuestras bases iniciales en Finalis, recuerdo haber tenido la idea de probar Graviton de AWS. No era factible en 2018 sin construir cosas por ti mismo. Cresta, es 2022, y nosotros (como comunidad) todavía luchamos por encontrar soporte ARMv8 en imágenes en Dockerhub.
Pero en 2020, algo grande ocurrió: Apple anunció la transición de los Mac a Apple Silicon con un plazo de 2 años.
En Finalis, nos mantenemos con hardware de Apple para el desarrollo de software. Tienes un Sistema Operativo similar a Unix y una calidad de pantalla y audio fantásticos para ver películas o lo que sea 🍿.
En 2020, empezó a correr un contador. Si queríamos seguir adquiriendo nuevos dispositivos de Apple en el futuro, Finalis necesitaba volverse multi-arquitectura.
Docker
Cuando Apple sacó el M1, y conseguimos uno, Docker estaba empezando a “llevarse bien” con él, pero Docker en ARM tenía algunos problemas en versiones anteriores solo porque el motor estaba siendo probado (por nosotros, los desarrolladores pioneros).
Después parecía que todo estaba bien: herramientas de terceros - la mayoría de las imágenes requeridas ya estaban disponibles para ARM64, pero no todas. browserless fue la que empecé a abordar para conseguir que se construyeran en ARM64, y así envié un pull request con el mínimo de cambios necesarios para que funcionara.
Con las herramientas de terceros cubiertas, era cosa de asegurarse de que Docker construyera nuestras propias imágenes para ARM64. “Oye, usas TypeScript; ¡debería funcionar nomás!”… Bueno, siempre y cuando tus dependencias no requieran que se descarguen binarios mientras corres npm install.
¿El problema principal? No se proporcionan binarios para ARM64, forzando una construcción binaria mientras corres npm install con make (¿scripts post-instalación?). Desde una perspectiva de configuración, un poco de amor en algunos de nuestros archivos Dockerfile fue todo lo que necesitábamos y resolvió todo.
Pipelines
Trabajando con GitHub Actions y lidiando con multi-arquitectura, tienes dos opciones: corres dos runners paralelos (uno construyendo para x86/64 y otro para arm64), o corres un runner para ambas arquitecturas.
Elegí la segunda opción para experimentar, a través de docker buildx. Siguiendo las instrucciones de configuración para build-push-action puedes obtener rápidamente un pipeline operacional.
Dejar que buildx haga la construcción multi-arquitectura te permite subir a Dockerhub sin tener que lidiar con diferentes etiquetas para diferentes arquitecturas. Todas tus etiquetas SERÁN compatibles con multi-arquitectura.
La desventaja es el tiempo de construcción: tener dos runners paralelos en sus arquitecturas apropiadas sería mucho más rápido, pero el pipeline requeriría manejar la fusión de los resultados en una sola etiqueta. Solo si te importa facilitar a los consumidores encontrar la imagen correcta.