Comments 11
Что-то как то много букв и слишком сложно. У вас по факту идет сборка не под процессор от Apple, а для архитектуры aarch64. Кэширование слоев в Buildx отрабатывает автоматически. На мой взгляд моя инструкция проще и короче. Вы еще не добавили в текст команду для очистки кэша, а то так место быстро закончится при постоянных сборках:
$ docker buildx prune
Я не видел вашу статью, когда разбирался в этом вопросе. Сейчас я посмотрел её и выглядит так, что обе статьи дополняют друг друга.
У нас, как минимум, разный подход к решению проблемы с binfmtпри каждой перезагрузке.
Автоматическое кэширование в buildx есть, но в рамках одного хоста. Если образы могут собираться на нескольких машинках, то для общего кэша приходится делать дополнительные телодвижения. Это же касается сборкой через обычный docker build (там то же надо использовать опцию --cache-from, но в другом формате - её передаётся только имя ранее собранного образа).
Моя инструкция не отличается оригинальность, а является переводом статьи с блога docker.com с дополнениями в виде картинок. Запуск образа binfmt можно добавить в автозагрузку. У вас в качестве источника кэша используется - registry. В каком-то смысле для большинства случаев это не имеет смысл. Например, у меня Docker-образ который состоит из трех частей: ОС Alpine, слой с Runtime .NET, и слой с компилированной программой. При первой сборке, Alpine и Runtime загрузятся из реестра. При второй сборке, слой с Alpine и Runtime будет взят уже с локального кэша. Слой с компиляцией программы это постоянно изменяемый слой при каждой сборке. Таким образом, нет никакой необходимости в подобной опции для взятия кэша. Кэш имеет смысл применять при большой вариации запуска одного и того же приложения в различных окружениях. Но на практике это сложно представить, потому что многие компании сейчас пытаются реализовать микросервисную архитектуру и не превращать Docker-контейнер в многофункционального динозавра. Если идет речь про локальный репозиторий образов, то тогда следовало бы дополнить пост инструкцией как его создать. Но если у вас есть рабочий кейс, то тогда хотелось бы его увидеть.
Даже в вашем простом случае локальный кэш работает только когда образ собирается на одной и той же машинке.
В нашем случае сборочные машинки живут меньше суток и из-за этого приходится использовать кэш в registry.
Цель у этого проста: получить более быструю сборку, чтобы переиспользовать слои с Runtime и уменьшить объём данных между образами, так как слои с Runtime получаются одинаковыми.
Так, где инструкция по созданию локального registry и его настройка? И еще один нескромный вопрос, а вы не рассматриваете вариант с увеличением время жизни сборочных машин?
К сожалению, эффект от этой команды будет действовать до первой перезагрузки.
замените
docker run --rm --privileged multiarch/qemu-user-static:register --resetна
docker run --restart=unless-stopped --privileged multiarch/qemu-user-static:register --resetНе знаю...
В случае сборки контейнера qemu-user-static живёт пока запущен процесс в контейнере, то есть не более одного шага сборки. В нашем случае это не очень большое время (до 10 минут). Мог просто не заметить.
Ну и сами шаги сборки контейнера обычно достаточно простые.
Но на старой версии qemu была проблема со старой же Java на обновлении ca-сертификатов (оно происходит как раз при установке Java в контейнер). Это полечилось использованием qemu от Ubuntu 20.04.
Я просто с линукс сервера попробовал save а потом на маке load образа из файла и он запускается под амд64, а если из докерфайла собираю то арм контейнер, т.е. сразу можно и то и другое стартовать, но стало интересно как докерфайлы билдить чтобы на линукс серверах файл образа импортировать. Т.е. билд под чужую архитектуру
Сборка Docker-образов для MacBook M1 под Linux