Docker Engine 23.0 发行说明

注意

从 Docker Engine 版本 23.0.0 开始,Buildx 在一个单独的包中分发:docker-buildx-plugin. 在早期版本中,Buildx 包含在docker-ce-cli包。 升级到此版本的 Docker Engine 时,请确保更新所有 包。例如,在 Ubuntu 上:

$ sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

请参阅适用于您的作系统的 Docker Engine 安装说明 了解有关升级 Docker Engine 的更多详细信息。

本页介绍了 Docker Engine 版本 23.0 的最新更改、新增功能、已知问题和修复。

有关以下内容的更多信息:

从 23.0.0 版本开始,Docker Engine 不再使用 CalVer 版本控制, 并开始使用 SemVer 版本控制格式。 更改版本格式是实现 Go 模块兼容性的垫脚石, 但仓库尚未使用 Go 模块,并且仍然需要使用 “+incompatible” 版本。 在未来版本中,Go 模块兼容性的工作将继续进行。

23.0.6

2023-05-08

有关此版本中拉取请求和更改的完整列表,请参阅相关的 GitHub 里程碑:

错误修复和增强功能

打包更新

23.0.5

2023-04-26

有关此版本中拉取请求和更改的完整列表,请参阅相关的 GitHub 里程碑:

错误修复和增强功能

打包更新

23.0.4

2023-04-17

有关此版本中拉取请求和更改的完整列表,请参阅相关的 GitHub 里程碑:

错误修复和增强功能

打包更新

23.0.3

2023-04-04

注意

由于 CentOS 9 Stream 的软件包仓库存在问题,因此 CentOS 9 目前不可用。CentOS 9 的组件可能在稍后加入, 或作为下一个 (23.0.4) 补丁版本的一部分。

错误修复和增强功能

  • 修复了可能导致 Swarm 加密覆盖网络的许多问题 未能履行其保证,解决 CVE-2023-28841CVE-2023-28840CVE-2023-28842
    • 现在报告缺乏对加密覆盖网络的内核支持 作为错误。
    • 加密的覆盖网络是热切建立的,而不是等待 要附加的多个节点。
    • 加密的覆盖网络现在可以在 Red Hat Enterprise Linux 9 上使用 通过使用xt_bpfkernel 模块。
    • Swarm 叠加网络的用户应查看 GHSA-vwm3-crmr-xfxw,以确保没有发生意外暴露。

打包更新

23.0.2

2023-03-28

有关此版本中拉取请求和更改的完整列表,请参阅相关的 GitHub 里程碑:

错误修复和增强功能

包装

23.0.1

2023-02-09

有关此版本中拉取请求和更改的完整列表,请参阅相关的 GitHub 里程碑:

错误修复和增强功能

  • 修复了在内核启用了 AppArmor 但apparmor_parser不可用。白鲸/白鲸#44942
  • 修复了启用了 BuildKit 的内联缓存构建导致守护程序崩溃的问题。白鲸/白鲸#44944
  • 修复了 BuildKit 无法正确加载由先前版本创建的缓存层的问题。白鲸/白鲸#44959
  • 修复ipvlan在升级之前创建的网络会阻止守护程序启动。白鲸/白鲸#44937
  • 修复overlay2存储驱动程序在早期失败metacopytesting 在不支持的后备文件系统上初始化时。白鲸/白鲸 #44922
  • 修复execexit 事件在某些运行时(如 Kata Containers)下被误解为容器 exit。白鲸/白鲸 #44892
  • 改进 API 在请求中途挂起导致收到截断的 JSON 响应时,CLI 返回的错误消息。docker/cli #4004
  • 修复在尝试执行带有runc使用 Go 1.20 编译。docker/cli #4004
  • 修复 size 参数的误处理--device-write-bps作为路径。docker/cli #4004

包装

23.0.0

2023-02-01

有关此版本中拉取请求和更改的完整列表,请参阅相关的 GitHub 里程碑:

新增功能

删除

荒废的

升级

安全

错误修复和增强功能

  • 促进overlay2作为默认存储驱动程序 (btrfszfs现在是选择加入的)。白鲸/白鲸#42661
  • 将加载微调器添加到docker cp命令。docker/cli 的 #2708
  • 弃用ElectAuthServer函数,并使其返回默认注册表,而不调用GET /infoAPI 端点。docker/cli 的 #2819
  • 回滚 Swarm 服务时,进度条不再反转。docker/cli #2940 命令
  • net.JoinHostPort()修复使用 IPv6 地址的格式。docker/cli 的 #2972
  • CLI 错误消息现在打印到stderr.docker/cli #3044
  • 提高性能docker info如果自定义--format,则仅使用本地信息。通过此更改,CLI 仅在检测到需要来自守护程序的信息时才使用守护程序 API。docker/cli 的 #3179
  • --stop-signal标志,因为它可能无法反映守护进程使用的实际默认值。docker/cli 的 #3245
  • 添加 Compose 架构3.10docker stack;允许省略version字段(导致latest).docker/cli 命令 #3257
  • 编写版本3现在等效于3.x(最新) 在docker stack.docker/cli 命令 #3445
  • 修复<Ctrl-c>hanging on Windows 以在非交互模式下运行容器后退出。docker/cli 的 #3302
  • 将相对源路径添加到run命令中的-v/--volume-m/--mount标志。docker/cli 的 #3469
  • docker exec -t现在,在创建已执行流程时,会立即设置该流程的控制台大小。docker/cli 命令 #3627
  • 更新 pretty-print 格式docker info以提供有关已安装插件的更多详细信息。docker/cli 的 #3645
  • 打印docker context listdocker context use命令。docker/cli 的 #3668
  • 添加自定义aliases可用于打印命令的所有可用别名的注释。docker/cli #3694
  • CLI 在运行时不再创建或更新 CLI 配置文件docker context use并选择当前上下文。docker/cli 命令 #3721
  • 现在,在运行时会忽略不存在的上下文docker context rm --force.docker/cli 命令 #3791
  • 添加了将整数覆盖为0在 Compose files 中。docker/cli 命令 #3812
  • 信号 (<Ctrl-c>) 现在传递到正在运行的容器,而不是导致 CLI 退出。docker/cli 命令 #3849
  • 提高docker port CONTAINERUX 通过在打印前对端口进行排序。docker/cli 命令 #3892
  • 应用程序接口:GET /containers/{id}/logsPOST /containers/{id}/attach现在使用Content-typeAPI 版本 >= 1.42 的响应标头。白鲸/白鲸#39812
  • 将 Windows 图层的默认沙箱大小设置为 127GB,并确保--storage-opts标志适用于 Windows 上的所有存储。白鲸/白鲸#41636
  • 从 containerd 配置文件中删除 plugin 部分 (/var/run/docker/containerd/containerd.toml).白鲸/白鲸#41675
  • 拒绝null在 tar 导入期间出现。白鲸/白鲸#41842
  • 为插件的自定义运行时添加 shim 配置。白鲸/白鲸#41854
  • 现在,当守护程序重新启动时,容器运行状况检查会恢复。白鲸/白鲸#41935
  • 在清理btrfs司机。白鲸/白鲸#42273
  • 可访问的主机设备现在可以挂载在--privileged无根容器。白鲸/白鲸#42638
  • 修复**/foo中的递归通配符目录模式.dockerignore.白鲸/白鲸#42676
  • 扩展docker import --platform以允许将导入的镜像标记为外部体系结构。白鲸/白鲸 #43103
  • 现在,在守护程序启动时执行 CPU 实时选项的验证,而不是对每个单独的容器执行验证,从而允许启动提前失败。白鲸/白鲸#43131
  • 冻结namesgeneratorpackage 来防止新增内容。用户必须对现有的 25359 个形容词-名称组合感到满意。白鲸/白鲸 #43210
  • 应用程序接口:containers/{id}/attach/ws仅根据stdin,stdoutstderrAPI 版本 >= 1.42 上的参数。白鲸/白鲸 #43322
  • 修复了在持续流量下重启容器后容器中的 UDP 流量无法正常工作的问题。白鲸/白鲸 #43409
  • 添加了对使用最新版本的 Go、GCC、LLVM 和其他编译器工具支持的自定义 amd64 微架构功能级别拉取镜像的支持。白鲸/白鲸 #43434
  • 改进 API 中无效 JSON 请求的验证。白鲸/白鲸 #43463
  • 减轻慢的影响exec从运行状况检查开始。检查超时现在仅适用于运行状况检查命令运行的持续时间。启动命令所需的时间不再计入超时。白鲸/白鲸 #43480
  • 安慰ttysize 在创建时立即设置。白鲸/白鲸 #43593白鲸/白鲸 #43622
  • 修复overlay2容器启动失败或守护程序关闭后未清理挂载。白鲸/白鲸#43659
  • 将清单列表解析与containerd.白鲸/白鲸#43675
  • 跳过使用firewalld用于 networking,当守护程序以无根模式运行时。白鲸/白鲸 #43813
  • 现在,如果 Windows 上缺少守护程序重新启动,则会在守护程序重新启动后重新创建自定义 NAT 网络。白鲸/白鲸#43858
  • 修复了在容器运行状况检查进程超时时终止该进程的问题。白鲸/白鲸#43994
  • 修复live-restore使用重启策略和卷引用。白鲸/白鲸 #44237
  • API:现在,在 API 版本 >= v1.42 上默认仅修剪匿名卷。传递过滤器all=true除了 Anonymous 之外,还删除命名卷。白鲸/白鲸#44259
  • API:支持GET /system/df端点。白鲸/白鲸#42715
  • 提高守护进程转储堆栈并在发送 SIGQUIT 时以代码 2 退出的可靠性。白鲸/白鲸 #44831
  • 提高docker logs -f,并防止在 Windows 上的locallog 驱动程序。白鲸/白鲸#43294
  • 修复了由缓冲容器日志导致的守护进程中罕见的死锁。白鲸/白鲸#44856
  • 改进 misc 文件系统作中的错误处理,以便守护程序可以在 overlayfs 后备文件系统上启动。白鲸/白鲸#44834
  • 修复--ipc=host当守护程序以无根模式运行时,未正确处理。白鲸/白鲸#44863
  • 修复了一组长期存在的问题,这些问题导致过时的 conntrack 条目导致容器的 UDP 流量路由错误。白鲸/白鲸 #44752
  • 修复了 API 中列出的半注册容器,以及因在 API 调用中使用部分注册的容器而导致的 nil 指针取消引用和恐慌。白鲸/白鲸#44633
  • 修复创建DOCKER-USERip6tables 链。白鲸/白鲸#44845
  • 修复了当ip6tables命令不可用。白鲸/白鲸#44727
  • 修复了启用 userland 代理后某些 iptables NAT 规则未清理的问题。白鲸/白鲸#44811
  • 在极少数情况下,修复可能泄漏的进程,即清理启动容器的失败尝试处理不当。白鲸/白鲸#44400
  • 修复CreatedAt反映 initialization 而不是 creation 的卷的时间。白鲸/白鲸#44725
  • 修复了 CLI 在某些命令中错误地报告不兼容的服务器而不是无法访问的服务器的问题。docker/cli#3901docker/cli#3904
  • 修复 Zsh 中卷补全中断的问题。docker/cli#2998
  • 提高docker context当存在无效的上下文时。docker/cli 的 #3847
  • 当输出不是 TTY 时,删除 CLI 帮助注释的 ANSI 修饰,并添加了一个换行符以提高可读性。docker/cli 的 #3973
  • docker container remove作为docker container rm.docker/cli 的 #3986

已知问题

apparmor_parser ( 跟踪问题)

一些 Debian 用户报告了容器在升级到 23.0 分支后无法启动的问题。 错误消息指示问题是由于缺少apparmor_parser二元的:

Error response from daemon: AppArmor enabled on system but the docker-default profile could not be loaded: running `apparmor_parser apparmor_parser --version` failed with output:
error: exec: "apparmor_parser": executable file not found in $PATH
Error: failed to start containers: somecontainer

此问题的解决方法是安装apparmor手动打包:

apt-get install apparmor

BuildKit 内联缓存 ( 跟踪问题)

尝试使用 BuildKit 的内联缓存功能构建镜像(例如docker build --build-arg BUILDKIT_INLINE_CACHE=1 .,docker buildx build --cache-to type=inline .) 将导致守护进程意外退出:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0x147ff00]

goroutine 693 [running]:
github.com/docker/docker/vendor/github.com/moby/buildkit/cache.computeBlobChain.func4.1({0x245cca8, 0x4001394960})
        /go/src/github.com/docker/docker/vendor/github.com/moby/buildkit/cache/blobs.go:206 +0xc90
github.com/docker/docker/vendor/github.com/moby/buildkit/util/flightcontrol.(*call).run(0x40013c2240)
        /go/src/github.com/docker/docker/vendor/github.com/moby/buildkit/util/flightcontrol/flightcontrol.go:121 +0x64
sync.(*Once).doSlow(0x0?, 0x4001328240?)
        /usr/local/go/src/sync/once.go:74 +0x100
sync.(*Once).Do(0x4001328240?, 0x0?)
        /usr/local/go/src/sync/once.go:65 +0x24
created by github.com/docker/docker/vendor/github.com/moby/buildkit/util/flightcontrol.(*call).wait

如果配置为在此类崩溃后重新启动(例如通过 systemd),守护进程将重新启动。此版本中唯一可用的缓解措施是避免在启用内联缓存功能的情况下执行构建。

带有热缓存的 BuildKit(跟踪问题)

如果镜像是使用 BuildKit 在以前版本的守护程序上构建的,并且是使用 23.0 守护程序构建的,则以前缓存的层将无法正确恢复。如果 Dockerfile 中没有更改任何行,则镜像可能会显示正确构建;但是,如果由于更改 Dockerfile 中的某些行而导致部分缓存失效,则仍然有效和以前缓存的层将无法正确加载。

这通常表现为应该出现在镜像中的文件,但并不存在于RUN阶段或任何其他引用文件的阶段,在更改 Dockerfile 中的某些行后:

[+] Building 0.4s (6/6) FINISHED
 => [internal] load build definition from Dockerfile
 => => transferring dockerfile: 102B
 => [internal] load .dockerignore
 => => transferring context: 2B
 => [internal] load metadata for docker.io/library/node:18-alpine
 => [base 1/2] FROM docker.io/library/node:18-alpine@sha256:bc329c7332cffc30c2d4801e38df03cbfa8dcbae2a7a52a449db104794f168a3
 => CACHED [base 2/2] WORKDIR /app
 => ERROR [stage-1 1/1] RUN uname -a
------
 > [stage-1 1/1] RUN uname -a:
#0 0.138 runc run failed: unable to start container process: exec: "/bin/sh": stat /bin/sh: no such file or directory
------
Dockerfile:5
--------------------
   3 |
   4 |     FROM base
   5 | >>> RUN uname -a
   6 |
--------------------
ERROR: failed to solve: process "/bin/sh -c uname -a" did not complete successfully: exit code: 1

要缓解这种情况,必须丢弃以前的构建缓存。docker builder prune -a将完全清空构建缓存,并通过删除处理不当的缓存层来允许受影响的构建再次继续。

IPvlan 网络(跟踪问题)

当升级到 23.0 分支时,任何 ipvlan 网络的存在都会阻止守护进程启动:

panic: interface conversion: interface {} is nil, not string

goroutine 1 [running]:
github.com/docker/docker/libnetwork/drivers/ipvlan.(*configuration).UnmarshalJSON(0x40011533b0, {0x400069c2d0, 0xef, 0xef})
        /go/src/github.com/docker/docker/libnetwork/drivers/ipvlan/ipvlan_store.go:196 +0x414
encoding/json.(*decodeState).object(0x4001153440, {0x5597157640?, 0x40011533b0?, 0x559524115c?})
        /usr/local/go/src/encoding/json/decode.go:613 +0x650
encoding/json.(*decodeState).value(0x4001153440, {0x5597157640?, 0x40011533b0?, 0x559524005c?})
        /usr/local/go/src/encoding/json/decode.go:374 +0x40
encoding/json.(*decodeState).unmarshal(0x4001153440, {0x5597157640?, 0x40011533b0?})
        /usr/local/go/src/encoding/json/decode.go:181 +0x204
encoding/json.Unmarshal({0x400069c2d0, 0xef, 0xef}, {0x5597157640, 0x40011533b0})
        /usr/local/go/src/encoding/json/decode.go:108 +0xf4
github.com/docker/docker/libnetwork/drivers/ipvlan.(*configuration).SetValue(0x4000d18050?, {0x400069c2d0?, 0x23?, 0x23?})
        /go/src/github.com/docker/docker/libnetwork/drivers/ipvlan/ipvlan_store.go:230 +0x38

为了缓解这种情况,受影响的用户可以降级并删除网络,然后再次升级。 或者,可以删除整个网络存储,并在升级后重新创建网络。网络存储位于/var/lib/docker/network/files/local-kv.db.如果守护程序正在使用备用--data-root替代/var/lib/docker对于备用路径。

Kata Containers ( 跟踪问题)

23.0 分支带来了对备用 containerd 填充程序的支持,例如io.containerd.runsc.v1(gVisor) 和io.containerd.kata.v2(Kata Containers)。

使用 Kata Containers 运行时时,退出execsession 会停止正在运行的容器,如果打开了 TTY,则会挂起连接的 CLI。目前,除了避免执行到 Kata 运行时上运行的容器之外,没有缓解措施。

此问题的根本原因是 Moby 中长期存在的错误。此问题将在将来的版本中得到解决。请注意,支持备用 OCI 运行时是一项新功能,随着更多用户开始使用此功能,可能会发现类似问题。