已知问题
- Docker Desktop 尚未支持 IPv6。
Mac 活动监视器报告 Docker 使用的内存量是实际使用量的两倍。这是由于 MacOS 中的错误导致的。我们已经编写了 一份详细的报告 关于此问题。
在从
.dmg
中运行Docker.app
后强制弹出.dmg
会导致鲸鱼图标无响应,Docker 任务在活动监视器中显示为未响应,以及某些进程消耗大量的 CPU 资源。重新启动并重启 Docker 以解决这些问题。即使在 **设置** 中启用,Docker 也不会在登录后自动启动。这与 Docker 助手、注册和版本控制中的一组问题有关。
Docker Desktop 在 macOS 10.10 Yosemite 及更高版本中使用
HyperKit
虚拟机管理器 ( https://github.com/docker/hyperkit)。如果您使用与HyperKit
冲突的工具进行开发,例如 英特尔硬件加速执行管理器 (HAXM),当前的解决方法是不同时运行它们。您可以通过暂时退出 Docker Desktop 来暂停HyperKit
,同时您使用 HAXM。这使您可以继续使用其他工具并防止HyperKit
干扰。如果您正在使用诸如 Apache Maven 等工具,这些工具需要
DOCKER_HOST
和DOCKER_CERT_PATH
环境变量的设置,请指定它们以通过 Unix 套接字连接到 Docker 实例。例如$ export DOCKER_HOST=unix:///var/run/docker.sock
绑定到容器中的目录的性能存在许多问题。特别是,小块的写入和大型目录的遍历目前速度很慢。此外,执行大量目录操作的容器(例如对大型目录树的重复扫描)可能会遇到性能低下。表现出这种行为的应用程序包括
rake
ember build
- Symfony
- Magento
- Zend Framework
- 使用 Composer 安装
vendor
文件夹中的依赖项的 PHP 应用程序
作为此行为的解决方法,您可以将供应商或第三方库目录放在 Docker 卷中,在绑定挂载之外执行临时文件系统操作,并使用 Unison 或
rsync
等第三方工具在容器目录和绑定挂载的目录之间同步。我们正在积极使用多种不同的技术来改进性能。要了解更多信息,请参阅 我们路线图中的主题。
在原生
arm64
容器中的 Apple 芯片上,debian:buster
、ubuntu:20.04
和centos:8
等旧版本libssl
在连接到某些 TLS 服务器(例如curl https://dl.yarnpkg.com
)时会发生段错误。此错误在debian:bullseye
、ubuntu:21.04
和fedora:35
中的libssl
的较新版本中已修复。某些命令行工具在未安装 Rosetta 2 时无法正常工作。
- 旧版本 1.x 的
docker-compose
。请改用 Compose V2 - 键入docker compose
。 docker-credential-ecr-login
凭据助手。
- 旧版本 1.x 的
某些镜像不支持 ARM64 架构。您可以添加
--platform linux/amd64
来使用仿真运行(或构建)英特尔镜像。但是,尝试在使用仿真的 Apple 芯片机器上运行基于英特尔的容器可能会崩溃,因为 qemu 有时无法运行容器。此外,文件系统更改通知 API (
inotify
) 在 qemu 仿真下无法正常工作。即使容器在仿真下正确运行,它们也会比原生等效容器速度更慢并使用更多内存。总之,在基于 Arm 的机器上运行基于英特尔的容器应该被视为“尽力而为”。我们建议尽可能在 Apple 芯片机器上运行 arm64 容器,并鼓励容器作者生成 arm64 或多架构版本的容器。随着越来越多的镜像重建 支持多种架构,这个问题应该会随着时间的推移而变得不那么普遍。
容器内部到互联网的
ping
无法按预期工作。要测试网络,请使用curl
或wget
。请参阅 docker/for-mac#5322。用户可能偶尔会在 TCP 流半关闭时遇到数据丢失。