Multi-Arch für alles

Als wir bei Finalis unsere ersten Grundlagen legten, erinnere ich mich an die Idee, AWS’s Graviton zu testen. Das war 2018 nicht machbar, ohne Dinge selbst zu bauen. Schnell vorwärts, es ist 2022, und wir (als Gemeinschaft) kämpfen immer noch darum, ARMv8-Unterstützung in Dockerhub-Bildern zu finden.

Aber 2020 passierte etwas Großes: Apple kündigte den Übergang von Macs zu Apple Silicon mit einem Zeitplan von 2 Jahren an.

Bei Finalis halten wir uns an Apple-Hardware für die Softwareentwicklung. Man bekommt ein Unix-ähnliches Betriebssystem und fantastische Bild- und Tonqualität für das Anschauen von Filmen oder was auch immer 🍿.

Im Jahr 2020 begann ein Countdown. Wenn wir in Zukunft weiterhin neue Apple-Geräte erwerben wollten, musste Finalis multi-architekturfähig werden.

Docker

Als Apple den M1 herausbrachte und wir einen bekamen, begann Docker, sich damit zu “vertragen”, aber Docker auf ARM hatte in früheren Versionen einige Probleme, einfach weil die Engine getestet wurde (von uns, den Pionierentwicklern).

Später schien alles in Ordnung zu sein: Drittanbieter-Tools - die meisten der benötigten Bilder waren bereits für ARM64 verfügbar, aber nicht alle. browserless war das, was ich anpackte, um es auf ARM64 zu bauen, und so schickte ich einen Pull-Request mit den minimalen Änderungen, die notwendig waren, um es zum Laufen zu bringen.

Mit den Drittanbieter-Tools abgedeckt, war es nur noch eine Frage der Sicherstellung, dass Docker unsere eigenen Bilder für ARM64 baute. “Hey, du verwendest TypeScript; es sollte einfach funktionieren!”… Nun, solange deine Abhängigkeiten nicht erfordern, dass Binärdateien während des Ausführens von npm install heruntergeladen werden.

Das Hauptproblem? Keine Binärdateien werden für ARM64 bereitgestellt, was einen Binärbau erzwingt, während man npm install mit make ausführt (Post-Installation-Skripte?). Aus Konfigurationssicht war ein wenig Liebe in einigen unserer Dockerfile-Dateien alles, was wir brauchten, und es löste alles.

Pipelines

Wenn man mit GitHub Actions arbeitet und sich mit Multi-Architektur beschäftigt, hat man zwei Optionen: zwei parallele Runner betreiben (einer baut für x86/64 und der andere für arm64), oder einen Runner für beide Architekturen laufen lassen.

Ich wählte die zweite Option, um zu experimentieren, durch docker buildx. Wenn man den Einrichtungsanweisungen für build-push-action folgt, kann man schnell eine betriebsbereite Pipeline erhalten.

Wenn man buildx die Multi-Architektur-Builds überlassen kann, kann man zu Dockerhub pushen, ohne sich mit verschiedenen Tags für verschiedene Architekturen auseinandersetzen zu müssen. Alle deine Tags WERDEN multi-architekturkompatibel sein.

Der Nachteil ist die Bauzeit: Zwei parallele Runner auf ihren entsprechenden Architekturen wären viel schneller, aber die Pipeline würde das Management des Zusammenführens der Ergebnisse in einen einzigen Tag erfordern. Nur wenn es dir darum geht, es den Verbrauchern leichter zu machen, das richtige Bild zu finden.