Apple m1 docker x86

Docker Desktop for Apple silicon

Estimated reading time: 3 minutes

Docker Desktop for Mac on Apple silicon is now available as a GA release. This enables you to develop applications with your choice of local development environments, and extends development pipelines for ARM-based applications.

Docker Desktop for Apple silicon also supports multi-platform images, which allows you to build and run images for both x86 and ARM architectures without having to set up a complex cross-compilation development environment. Additionally, you can use docker buildx to seamlessly integrate multi-platform builds into your build pipeline, and use Docker Hub to identify and share repositories that provide multi-platform images.

Download Docker Desktop for Mac on Apple silicon:

System requirements

Beginning with Docker Desktop 4.3.0, we have removed the hard requirement to install Rosetta 2. There are a few optional command line tools that still require Rosetta 2 when using Darwin/AMD64. See the Known issues section below. However, to get the best experience, we recommend that you install Rosetta 2. To install Rosetta 2 manually from the command line, run the following command:

Known issues

• Some command line tools do not work when Rosetta 2 is not installed.
  • The old version 1.x of docker-compose . We recommend that you use Compose V2 instead. Either type docker compose or enable the Use Docker Compose V2 option in the General preferences tab.
  • The docker scan command and the underlying snyk binary.
  • The docker-credential-ecr-login credential helper.

• Not all images are available for ARM64 architecture. You can add —platform linux/amd64 to run an Intel image under emulation. In particular, the mysql image is not available for ARM64. You can work around this issue by using a mariadb image.

  However, attempts to run Intel-based containers on Apple silicon machines under emulation can crash as qemu sometimes fails to run the container. In addition, filesystem change notification APIs ( inotify ) do not work under qemu emulation. Even when the containers do run correctly under emulation, they will be slower and use more memory than the native equivalent.

  In summary, running Intel-based containers on Arm-based machines should be regarded as “best effort” only. We recommend running arm64 containers on Apple silicon machines whenever possible, and encouraging container authors to produce arm64, or multi-arch, versions of their containers. We expect this issue to become less common over time, as more and more images are rebuilt supporting multiple architectures.

• ping from inside a container to the Internet does not work as expected. To test the network, we recommend using curl or wget . See docker/for-mac#5322.
• Users may occasionally experience data drop when a TCP stream is half-closed.

Fixes since Docker Desktop RC 3

• Docker Desktop now ensures the permissions of /dev/null and other devices are correctly set to 0666 ( rw-rw-rw- ) inside —privileged containers. Fixes docker/for-mac#5527.
• Docker Desktop now reduces the idle CPU consumption.

Fixes since Docker Desktop RC 2

• Update to Linux kernel 5.10.25 to improve reliability.

Fixes since Docker Desktop RC 1

• Inter-container HTTP and HTTPS traffic is now routed correctly. Fixes docker/for-mac#5476.

Fixes since Docker Desktop preview 3.1.0

• The build should update automatically to future versions.
• HTTP proxy support is working, including support for domain name based no_proxy rules via TLS SNI. Fixes docker/for-mac#2732.

Fixes since the Apple Silicon preview 7

• Kubernetes now works (although you might need to reset the cluster in our Troubleshoot menu one time to regenerate the certificates).
• osxfs file sharing works.
• The host.docker.internal and vm.docker.internal DNS entries now resolve.
• Removed hard-coded IP addresses: Docker Desktop now dynamically discovers the IP allocated by macOS.
• The updated version includes a change that should improve disk performance.
• The Restart option in the Docker menu works.

Feedback

Your feedback is important to us. Let us know your feedback by creating an issue in the Docker Desktop for Mac GitHub repository.

We also recommend that you join the Docker Community Slack and ask questions in #docker-desktop-mac channel.

Источник

Я запустил Docker на MacBook Air с процессором M1. Разработчики, это для вас

Привет, я лид мобильной разработĸи – iOS разработчиĸ из РосДомофон. И у меня Air на M1 в базовой ĸонфигурации, впечатлениями от которого с поделился в декабре.

Коллеги по всему миру, даже в комментариях к обзору MacBook Air на M1, уже два месяца задают один и тот же вопрос:

Что там с доĸером? Доĸер работает? Меня тольĸо доĸер интересует, если работает – буду брать. Доĸер? Доĸер! Доĸер.

Это крайне важный инструмент для разработчиков, поэтому такое требование неудивительно. А обычный Docker с сайта запустить не выйдет:

Так вот, я Docker запустил успешно. С 16 декабря у него есть специальная бета-сборĸа под ARM, просто её надо качать и ставить отдельно с этой страницы.

Есть тред на github и специальная страничĸа в доĸе доĸера для, там же есть списоĸ известных проблем.

Да, судя по доĸументации, пока что для него нужна Rosetta. Но всё-таĸи это полноценная сборĸа под M1:

С ходу я запустил пару сэмплов – всё запусĸается, alpine работает, сайтиĸи отĸрываются. Пошёл ĸ ĸоллегам, чтобы узнать, какие задачи в Docker им нужно проверить.

«Убунту подними:»

Microsoft SQL Server подними:

Пробовал всяĸо, ĸаĸ описано на хабе – не поднимается. При запусĸе выдаёт вот это:

MySQL подними:

Попробовал, нет под ARM:

А вот mysql/mysql-server есть сборĸи под arm:

И он поднимается:

Пошёл по остальным базам, ĸоторые наĸидали.

Все, что в списĸе на сĸриншоте – работают: Redis, Postgres, Mongo, Mariadb.

Docker под M1 «ест» памяти и ресурсов обыденно, по запросам. Чем больше запустишь, тем больше отожрёт. Ничего удивительного.

Вторая строчĸа – это ĸаĸ раз под виртуалĸи доĸера:

Опять же, за всё время на M1 проблем с тем, что у меня 8 ГБ оперативĸи, не было. В своп уводит, но всё оĸ. Кстати, доводил своп до 10+ ГБ и… всё работает преĸрасно, даже не почувствовал.

В целом-то и всё. Для разработĸи мне доĸер не особо нужен, но думаю этой информации достаточно для понимания ситуации. В чатах уже видел ребят на M1, ĸоторые используют доĸер для поднятия «бека» лоĸально для своих мобильных приложений.

Думаю на этом, по большей части, вопрос с доĸером заĸрыт.

Источник

Docker получил поддержку Apple M1

Один из самых популярных инструментов разработки Docker теперь поддерживает новый процессор Apple M1. Предыдущая версия Docker работала через Apple Rosetta, однако внедрение новой версии с поддержкой M1 обеспечит оптимальный запуск всего набора инструментов.

Docker стал популярным среди разработчиков, потому что он позволил относительно легко использовать контейнеры.

Публичный выпуск версии Docker Desktop для Mac на Apple Silicon в техническом предпросмотре установили 45 тысяч раз, и разработчики заявили, что приложение работает «быстрее и тише».

Apple пока выпустила только несколько версий Mac с M1, и все они являются компьютерами с достаточно низкой максимальной конфигурацией ОЗУ, поддержкой только одного внешнего монитора и меньшим количеством портов Thunderbolt, чем у высокопроизводительных машин с чипами Intel.

Новые Mac будут иметь соответствующие чипы с улучшенной производительностью и функциями. Ожидается, что чип Apple M1X появится во втором квартале этого года. Согласно утечкам, он будет производиться с использованием 5-нанометрового техпроцесса TSMC N5 и иметь 12 ядер вместо 8. Новый чип получит 128-битную ОЗУ LPDDR4X-4266 до 32 ГБ.

Как отмечают разработчики, нет причин ожидать, что версии Docker и другого ПО с поддержкой M1 будут работать хуже на чипах нового поколения.

Microsoft выпустила стабильную сборку Visual Studio Code версии 1.54 с нативной поддержкой Apple Silicon М1. Версия OpenBSD 6.9-beta уже также поддерживает чип. Adobe представила адаптированную версию Photoshop для устройств на M1. Parallels выпустила версию Parallels Desktop 16.5 с полноценной встроенной поддержкой компьютеров Mac на базе Apple M1 и Intel. Приложения Parallels Access и Parallels Toolbox стали полностью совместимы с новыми Mac. Разработчики Homebrew также выпустили версию утилиты для компьютеров на чипе M1.

Источник

Docker и Apple M1

Любопытный казус привел к исследованию совместимости процессора Apple M1, и оказалось, что не все так просто.

Впрочем, обо всем по порядку. Мой коллега, владелец MacBook Pro с M1 обратился ко мне с просьбой помочь с установкой библиотеки.

У меня почти такой же MacBook, но на Intel Core i5, macOS Big Sur. При попытке поставить библиотеку

ERROR: Could not find a version that satisfies the requirement qvd (from versions: none)

ERROR: No matching distribution found for qvd

Обычно такое бывает, когда в составе пакета есть какой-то модуль, несовместимый с текущей ОС. В такой ситуации первое, что я делаю — пытаюсь установить библиотеку в docker container, там у меня очень широкий выбор возможных ОС и настроек.

Далее выполняем команду:

И оп-ля, все работает, библиотека встает, образ собирается, контейнер запускается:

Добавлю (не имеет отношения к данной теме), что библиотека работает по-настоящему, я подключал настоящие файлы и обрабатывал их этой библиотекой.

Отдаю проект коллеге, но у него не собирается!

Docker version 20.10.7, build f0df350

У нас обоих версия docker совпадает. В чем может быть причина? Ведь выполнение кода из Dockerfile реально идет в образе python:3.8-slim-buster, он одинаковый у нас. Надо погружаться глубже, разбираться с pip

Для начала посмотрим, почему qvd не ставится на Big Sur:

Эта команда выводит очень много текста, но главное, что понятно — none of the wheel’s tags (cp37-none-win_amd64) are compatible (run pip debug —verbose to show compatible tags), таких строчек очень много и среди них встречаются только win и manylinux.

и получим список подходящих тэгов pip. Никаких win там, конечно, нет, а есть py32-none-macosx_10_13_x86_64 (и похожие). Всех интересующихся, что это значит отсылаю сюда: https://github.com/pypa/manylinux

Тэги совместимости не совпадают, вероятно, по веским причинам — есть библиотеки, которые не смогут запуститься на Big Sur. ОК, понятно, нет вопросов, но есть вопросы, почему при сборке образа на одной и той же ОС из одного и того же источника есть такое существенное отличие.

Добавляю в Dockerfile строчку:

и запускаю сборку вот такой командой:

docker build -t testqvd:latest -o /tmp/buildlogs

В результате получаю файл /tmp/buildlogs/tmp/pip.txt с результатами тэгов pip во время сборки. То же самое делает мой коллега. И они (тэги) получаются разными, у меня, например, — py38-none-manylinux_2_16_x86_64, у коллеги py37-none-manylinux_2_28_aarch64

Вот так, процессор M1 (очевидно) не совпадает с Intel Core и никакими хитрыми docker — технологиями исправить ничего нельзя. Я пока поостерегусь переходить на M1 и другим разработчикам отсоветую.

Источник

Сборка Docker-образов для MacBook M1 под Linux

Мы собираем зависимости для нашего тестового окружения в Docker-образ, что оказалось очень удобно. Но недавно у нас появился разработчик с MacBook M1, и резко встал вопрос о возможности поддержки двух платформ.

Особенности поведения Docker на MacBook M1

Для начала пара слов о том, как повёл себя MacBook M1. В самом M1 предусмотрена неплохая поддержка программ, собранных для процессоров Intel (Rosetta 2). То есть большинство программ, которые собраны для процессоров Intel, запускаются на нём без проблем.

В Docker подобное поведение тоже реализовано, но несколько другим образом: Docker использует виртуальную машину для запуска образов (как минимум потому, что им нужно ядро Linux). Но в этой виртуальной машине есть поддержка исполнения бинарных файлов для архитектуры x86_64 .

В случае с MacBook M1 родной архитектурой для него будет являться aarch64 :

Сборка образа для другой архитектуры

Docker-образы мы собираем под Linux.

К счастью, под Linux можно собрать Docker-образ для другой архитектуры без особых проблем.

Для примера возьмём простой Dockerfile:

Чтобы его собрать для M1 проще всего воспользоваться BuildKit.

Для этого нужно выполнить команду вида:

Но скорее всего результат будет другим:

Для того чтобы собрать образы под другую платформу, нужно поставить эмулятор для этой платформы.

Установка эмулятора (быстрый метод)

Для установки эмулятора можно воспользоваться проектом:

Этот Docker-образ скопирует в систему qemu-user-static и зарегистрирует его для исполнения бинарных файлов соответствующей платформы.

После этого, кстати, можно будет запускать статически слинкованные исполняемые файлы от другой платформы (подобные файлы по умолчанию создаёт компилятор Go).

К сожалению, эффект от этой команды будет действовать до первой перезагрузки.

Установка эмулятора (ручной метод)

Если мы по каким-то причинам не хотим воспользоваться первым методом, то можно сделать всё это вручную.

Установка qemu-user-static

Нужно установить qemu-user-static для вашего дистрибутива, например:

Если в вашем дистрибутиве используется qemu-user-static очень старой версии, то можно скачать пакет от дистрибутива более свежей версии. У qemu-user-static нет внешних зависимостей и, к примеру, пакет от Ubuntu 21.04 (qemu version 5.2) хорошо встаёт на Ubuntu 18.04 (qemu version 2.11).

Зарегистрировать qemu-user-static в binfmt

Теоретически установки qemu-user-static должно быть достаточно. Но на некоторых дистрибутивах она не прописывается в binfmt.

Проверить работоспособность можно командой:

Я исправлял эту ситуацию по инструкции:

Сборка образов по отдельности

После того как мы научились собирать образ для другой платформы, надо научиться собирать образ для двух платформ одновременно.

Это можно сделать несколькими способами.

Для начала рассмотрим сборку образа для нескольких платформ вручную.

Проверить, что образ собрался успешно, можно командой вида:

Сборка при помощи docker buildx

С недавнего времени в Docker появилась возможность собрать образ под несколько платформ одной командой:

Что здесь происходит:

docker buildx create создаёт в DOCKER_CONFIG (по умолчанию

/.docker ) описание сборщика. Флаг —use помечает этот сборщик используемым по умолчанию (без этого его имя надо было бы протаскивать в последующие команды). Кроме конфигурационных файлов текущего пользователя эта команда не меняет и не использует ничего.

buildx inspect —bootstrap выводит информацию о сборщике. Если он не запущен, то запускает его. Сам сборщик представляет собой Docker-контейнер.

docker buildx build собственно собирает образ.

Особенности поведения на CI

При сборке на CI возникают следующие проблемы:

docker buildx create при создании контейнера по умолчанию прописывает в конфигурацию образ с DockerHub;

docker buildx inspect —bootstrap создаёт контейнер со сборщиком и подвержен гонкам;

единожды созданный сборщик используется между несколькими сборками.

Для решения этих проблем мы перенесли запуск сборщика на этап старта сборочного агента.

Таким образом при запуске агента мы выполняем команды вида:

Это запускает сборщик образов на старте агента с нужными нам параметрами.

При старте задачи на сборку мы выполняем команды вида ( DOCKER_CONFIG переопределяется на каждую сборку):

Кэширование сборки образов

В качестве бонуса при использовании BuildKit мы получаем возможность использовать внешний кэш для Docker-образов:

Особенность такого кэширования: в отличие от кэша на базе предыдущего Docker-образа, хорошо работает с Dockerfile, в которых используется несколько FROM директив.

Источник