1
Docker CE v19.03 正式发布
7 月 22 日,正式发布了 Docker CE v19.03 版本,按照 Docker CE 版本的生命周期,此次的 v19.03 可以说是千呼万唤始出来,原本按语义应该是在 3 月,不过之前的发布计划中开始是设定在了 5 月份,而一转眼现在已经到 7 月底了。先跳过这次发布时间延期的问题,我们来看看此版本中最值得注意的一些变化。
首先来看看被废弃的部分:
aufs
存储驱动,在此版本之前 devicemapper
和 overlay
也都已经被废弃;其次,我们看看功能增强的部分:
docker run
命令中添加了 --gpus
参数,用于为容器添加 GPU 设备。事实上,大家需要注意的是,这里严格的表述应该是它目前是对 NVIDIA GPU的支持而不是很多国内媒体报道的,对 GPU 的支持(毕竟做 GPU 的有很多家),而且现在对 NVIDIA 的支持,也都是硬编码在代码中的,之后还有很长的路要走。至于很多人可能想问,它添加这个支持后,是否还需要安装驱动,安装 CUDA 是否需要安装 nvidia-docker2 之类的, 我在这部分逻辑刚合并后就在机器上实验过了, 代码中硬编码了对 nvidia-container-cli
的依赖,现在修改成了对 vidia-container-runtime-hook
的依赖, 所以,像驱动啊 nvidia-container-cli
之类的东西还是需要装的,只不过用户使用上和原先用法不一样了罢了。(这里非常希望大家能自行尝试下)/_ping
接口添加了对 HEAD
请求的支持,返回结果中会包含当前 docker daemon 的 API 和版本,系统类型等信息;Rootless
模式,事实上这个功能在去年就已经在逐步推进了,但即使是现在,我也尚不推荐将此功能应用于生产环境。(国内有很多媒体对此大肆宣扬来着,说以后可以不用 root
权限了如何如何 - - 我只想说你们有没有真的用过 Rootless
模式,或者有没有在生产实践中验证过) 这个功能确实是有了,但尚不完善,也尚并不能达到替代当前 docker 全部能力的时候,包括它的网络能力,它的存储能力等目前都还有很多路要走;docker network
支持了 dangling
状态的筛选支持。以上便是 v19.03 中我个人认为最值得注意的内容。当然,现在我还要额外多说一点(划重点):
使用此版本,我们可以在一台机器上同时管理多个 Docker Engine 这是我用了很长时间的功能,特别有用,与大家分享一下具体使用方法:
(MoeLove) ➜ ~ docker context create build-context --description "build context" --docker "host=tcp://172.17.0.3:2375"
build-context
Successfully created context "build-context"
(MoeLove) ➜ ~ docker context ls
NAME DESCRIPTION DOCKER ENDPOINT KUBERNETES ENDPOINT ORCHESTRATOR
build-context build context tcp://172.17.0.3:2375
default * Current DOCKER_HOST based configuration unix:///var/run/docker.sock https://10.234.9.30:8443 (default) swarm
使用该 context
(MoeLove) ➜ ~ docker context use build-context
build-context
Current context is now "build-context"
这样,我们便可以直接在本机管理远程的一台机器上的 Docker Engine 了,当然它也可以支持用 ssh
连接远程主机的模式。
好了,关于此版本的介绍就到这里,对此版本中构建系统有想深入的了解的还是同样建议阅读 「Docker 镜像构建原理及源码分析」 关于此版本中更多的更新内容请参考 ReleaseNote
2
Helm v3.0.0-alpha.2 发布
这个版本中主要是对 Helm 3 内部的架构进行了优化,所以外部看到的功能特性变化并不是很大。如果对 Helm 3 还不了解的朋友,推荐阅读 初试 Helm 3 。
更多关于此版本的信息请参考 ReleaseNote
3
Kubernetes 上游开发进展
按照预期,特性冻结的 deadline 是 7 月 30 日,过段时间,下一个版本就将会正式发布了。
最近合并的 PR 中最值得注意的我个人认为应该是 #59416 将 Ephemeral Containers 添加到 Kubernetes 核心 API 这个 PR 应该归属于 Ephemeral Containers 相关 KEP 的一部分。
其主要目的在于提供一种机制,方便进行容器的在线调试或者监测。可以理解为启动一个与待调试容器具备相同网络和 Namespace 的容器,以此来进行调试。现在我们一般做这个事情一般是手动完成或者借助一些其他工具,但其实不够"优雅",随着这个 KEP 的完善,希望能弥补这部分的空缺。