すべてをマルチアーキテクチャ化

私たちがFinalisで最初の基盤を築き始めたとき、AWSのGravitonをテストするというアイデアを思いついたのを覚えています。 2018年には、自分で構築しない限り、それは現実的ではありませんでした。時が進み、2022年になっても、私たち（コミュニティ全体）はDockerhubイメージでARMv8のサポートを見つけるのに苦労しています。

しかし、2020年に大きな出来事がありました。AppleがMacをApple Siliconに移行することを、2年間のタイムラインで発表したのです。

Finalisでは、ソフトウェア開発のためにAppleのハードウェアを使用しています。Unixライクなオペレーティングシステムが手に入り、映画鑑賞やその他の用途に素晴らしい画面と音質が得られます🍿。

2020年、カウントダウンが始まりました。将来的に新しいAppleデバイスを購入し続けたいのであれば、Finalisはマルチアーキテクチャ化する必要がありました。

Docker

AppleがM1をリリースし、私たちがそれを手に入れたとき、Dockerはそれと「うまくやっていく」ようになり始めましたが、初期のバージョンではARM上のDockerにいくつかの問題がありました。これは単にエンジンがテストされていたからです（私たち、先駆的な開発者によって）。

その後、すべてが順調に進んでいるように見えました。サードパーティツール - 必要なイメージのほとんどはすでにARM64用に利用可能でしたが、すべてではありませんでした。browserlessは、私がARM64上でビルドするために取り組み始めたもので、最小限の変更で動作するようにするためにプルリクエストを送りました。

サードパーティツールがカバーされた後は、Dockerが自分たちのイメージをARM64用にビルドすることを確認するだけでした。「TypeScriptを使っているなら、うまくいくはずだよ！」… まあ、依存関係がnpm installを実行中にバイナリをダウンロードする必要がなければね。

主な問題は？ ARM64用のバイナリが提供されていないため、npm installを実行中にmake（インストール後のスクリプト？）でバイナリをビルドする必要があることです。設定の観点からは、いくつかのDockerfileに少し手を加えるだけで、すべてが解決しました。

パイプライン

GitHub Actionsでマルチアーキテクチャを扱う場合、2つのオプションがあります。1つは2つの並列ランナーを実行する（1つはx86/64用、もう1つはarm64用）、もう1つは1つのランナーで両方のアーキテクチャをビルドする方法です。

私は2番目のオプションを選び、docker buildxを使って実験しました。build-push-actionのセットアップ手順に従えば、すぐに動作するパイプラインを構築できます。

buildxにマルチアーキテクチャビルドを任せることで、異なるアーキテクチャごとに異なるタグを扱う必要なく、Dockerhubにプッシュできます。すべてのタグがマルチアーキテクチャ対応になります。

デメリットはビルド時間です。適切なアーキテクチャで2つの並列ランナーを実行する方がはるかに速いですが、その場合、結果を1つのタグに統合する管理が必要になります。消費者が正しいイメージを見つけやすくすることを気にする場合のみです。