Мультиархитектурность во всём

Когда мы начинали закладывать наши первоначальные основы в Finalis, я помню, как у меня возникла идея протестировать Graviton от AWS. Это было неосуществимо в 2018 году без самостоятельной сборки. Но вот наступил 2022 год, и мы (как сообщество) все еще испытываем трудности с поиском поддержки ARMv8 в образах Dockerhub.

Но в 2020 году произошло кое-что важное: Apple объявила о переходе Mac на Apple Silicon с двухлетним планом.

В Finalis мы придерживаемся использования оборудования Apple для разработки программного обеспечения. Вы получаете операционную систему, похожую на Unix, и фантастическое качество экрана и звука для просмотра фильмов или чего-то еще 🍿.

В 2020 году начался обратный отсчет. Если мы хотели продолжать приобретать новые устройства Apple в будущем, Finalis нужно было стать мультиархитектурной.

Docker

Когда Apple выпустила M1, и мы его получили, Docker начал “ладить” с ним, но Docker на ARM имел некоторые проблемы в более ранних версиях, просто потому, что движок тестировался (нами, пионерными разработчиками).

Позже казалось, что все в порядке: сторонние инструменты - большинство необходимых образов уже были доступны для ARM64, но не все. browserless был тем, с чем я начал бороться, чтобы собрать его на ARM64, и поэтому я отправил pull request с минимальными изменениями, необходимыми для его работы.

Со сторонними инструментами все было покрыто, оставалось лишь убедиться, что Docker собирает наши собственные образы для ARM64. “Эй, вы используете TypeScript; это должно просто работать!”… Ну, если только ваши зависимости не требуют загрузки бинарных файлов во время выполнения npm install.

Основная проблема? Бинарные файлы для ARM64 не предоставляются, что вынуждает собирать бинарные файлы во время выполнения npm install с помощью make (скрипты после установки?). С точки зрения конфигурации, немного любви в некоторых наших файлах Dockerfile было всем, что нам нужно, и это решило все проблемы.

Пайплайны

Работая с GitHub Actions и имея дело с мультиархитектурностью, у вас есть два варианта: запустить два параллельных раннера (один сборка для x86/64 и другой для arm64) или запустить одного раннера для обеих архитектур.

Я выбрал второй вариант для экспериментов через docker buildx. Следуя инструкциям по настройке для build-push-action, вы можете быстро получить рабочий пайплайн.

Позволяя buildx управлять сборкой мультиархитектурности, вы можете пушить в Dockerhub, не имея дело с разными тегами для разных архитектур. Все ваши теги БУДУТ совместимы с мультиархитектурностью.

Недостаток - время сборки: иметь два параллельных раннера на соответствующих архитектурах было бы намного быстрее, но пайплайн потребовал бы управления слиянием результатов в один тег. Только если вам важно облегчить потребителям поиск правильного образа.