Multi-architecture en Tout

Lorsque nous avons commencé à construire nos bases initiales chez Finalis, je me souviens avoir eu l’idée d’essayer Graviton d’AWS. Ce n’était pas faisable en 2018 sans construire des choses par soi-même. Nous sommes en 2022, et nous (en tant que communauté) luttons encore pour trouver un support ARMv8 dans les images sur Dockerhub.

Mais en 2020, quelque chose d’important s’est produit : Apple a annoncé la transition des Mac vers Apple Silicon avec un délai de 2 ans.

Chez Finalis, nous restons équipés de matériel Apple pour le développement logiciel. Vous avez un système d’exploitation similaire à Unix et une qualité d’écran et audio fantastiques pour regarder des films ou quoi que ce soit 🍿.

En 2020, un compte à rebours a commencé. Si nous voulions continuer à acquérir de nouveaux appareils Apple à l’avenir, Finalis devait devenir multi-architecture.

Docker

Quand Apple a sorti le M1, et que nous en avons obtenu un, Docker commençait à “bien s’entendre” avec lui, mais Docker sur ARM avait quelques problèmes dans les versions précédentes simplement parce que le moteur était en cours de test (par nous, les développeurs pionniers).

Ensuite, il semblait que tout allait bien : les outils tiers - la plupart des images requises étaient déjà disponibles pour ARM64, mais pas toutes. browserless a été celui que j’ai commencé à aborder pour obtenir qu’il soit construit en ARM64, et j’ai donc envoyé une pull request avec le minimum de changements nécessaires pour qu’il fonctionne.

Avec les outils tiers couverts, il s’agissait de s’assurer que Docker construise nos propres images pour ARM64. “Hé, tu utilises TypeScript ; ça devrait juste marcher !” … Eh bien, tant que vos dépendances ne nécessitent pas de télécharger des binaires pendant que vous exécutez npm install.

Le problème principal ? Aucun binaire n’est fourni pour ARM64, forçant une construction binaire pendant que vous exécutez npm install avec make (des scripts post-installation ?). D’un point de vue configuration, un peu d’amour dans certains de nos fichiers Dockerfile a été tout ce dont nous avions besoin et a tout résolu.

Pipelines

En travaillant avec GitHub Actions et en gérant le multi-architecture, vous avez deux options : exécuter deux runners en parallèle (un pour x86/64 et un autre pour arm64), ou exécuter un runner pour les deux architectures.

J’ai choisi la deuxième option pour expérimenter, via docker buildx. En suivant les instructions de configuration pour build-push-action, vous pouvez rapidement obtenir un pipeline opérationnel.

Laisser buildx gérer la construction multi-architecture vous permet de pousser sur Dockerhub sans avoir à gérer différentes étiquettes pour différentes architectures. Toutes vos étiquettes SERONT compatibles multi-architecture.

L’inconvénient est le temps de construction : avoir deux runners parallèles sur leurs architectures appropriées serait beaucoup plus rapide, mais le pipeline nécessiterait de gérer la fusion des résultats en une seule étiquette. Seulement si vous vous souciez de faciliter aux consommateurs la recherche de l’image correcte.