我最近在 GitChat 写了一些 Docker 构建镜像相关的文章，这个系列写了三篇，通过这三篇将 Docker 构建镜像相关的事情基本就讲明白了，感兴趣的朋友扫描二维码或者点击链接即可。 高效构建 Docker 镜像的最佳实践 Docker 可谓是开启了容器化技术的新时代，现在无论大中小公司基本上都对容器化技术有不同程度的尝试，或是已经进行了大量容器化的改造。伴随着 Kubernetes 和 Cloud Native 等技术和理念的普及，也大大增加了业务容器化需求。 而这一切的推进，不可避免的技术之一便是构建容器镜像。 在本场 Chat 中，会讲到如下内容： Docker 镜像是什么 Docker 镜像常规管理操作 如何构建 Docker 镜像 逐步分解构建 Docker 镜像的最佳实践 如何提升构建效率 适合人群： 对高效构建 Docker 镜像有兴趣的技术人员 地址：https://gitbook.cn/gitchat/activity/5cd527e864de19331ba79278 进阶：Dockerfile 高阶使用指南及镜像优化 在上次的 Chat 高效构建 Docker 镜像的最佳实践 中，我们重点深入内部介绍了 Docker 镜像是什么；以及构建 Docker 镜像的最佳实践等。 即将发布的 Docker 19.03 版本中 Dockerfile 及构建系统有了很多变化。 在本场 Chat 中，会讲到如下内容： Dockerfile 高阶使用及新特性解读 Docker 19.03 构建系统解读 Docker 镜像安全实践 发现并优化镜像大小 地址：https://gitbook.

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Kubernetes v1.15.0-beta.1 发布 随着 KubeCon EU 的结束，Kubernetes 的开发工作继续回归正常，本周相继发布了 v1.12.9 和 v1.15.0-beta.1。 随着 v1.15 的正式版临近，维护期的 Kubernetes 版本也将变成 1.12~1.15，请尽快升级。 这个版本的变化，等正式版发布时候再进行介绍好了，有兴趣可以先看 ReleaseNote Docker v19.03.0-beta5 发布 按照正常规律 Docker 19.03 正式版也将在近期进行发布，而最近的所有测试版本中，其实变化比较大的东西主要在 构建系统 上；构建系统的升级可以使构建速度更快，同时也增加了更多的安全特性。 这次的 beta5 也是常规修复，有兴趣可以先看 ReleaseNote Docker CVE-2018-15664 安全漏洞 在 5 月 29 日我看到了 CVE 的信息，这个漏洞会影响 Docker 的全部版本，漏洞攻击的主要途径是 docker cp 相关的操作。 但是不必太过紧张，因为这个漏洞的攻击范围其实不算太大；最主要可能被攻击的对象其实是公有云。对于普通用户而言，如果受此攻击，那前提是攻击者已经具备了机器的权限和 Docker 的操作权限（一般用户只要自行控制权限便可避免攻击的发生）。 漏洞发现者 Aleksa Sarai 开始提了一个 PR (他的实现方式是在 docker cp 操作的同时暂停容器)，不过现在已经被一个新的 PR 给取代了，毕竟暂停容器意味着停止服务，这是难以接受的。 类似 Podman 之类的其实也存在相同的问题，不过现在也已经被修复了。

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 KubeCon EU 举办 2019 年第一个 KubeCon + CloudNativeCon 于 5 月 20 ~ 23 日在巴塞罗那成功举办，这次大会吸引了七千多名参会者远超去年的参会人数。 这也从另一个侧面反映了 Kubernetes 和云原生在大大的普及 在大会上宣布了不少值得关注的信息, 我在此大致列一下我认为值得关注的信息（虽然有些内容之前已经关注到了）： OpenTracing, OpenCensus 合并为 OpenTelemetry； 微软推出 Service Mesh Interface（SMI）规范； NGINX Ingress Controller 发布 1.5.0 版本； Google 宣布 GKE 将会支持 Windows Server Container； Helm 3 的发展历程；（推荐阅读我之前写的 初试 Helm 3） 当然，大会上公布的信息还有很多，还有一些 CNCF 的计划等，这里暂且不提，感兴趣的朋友可以自行搜索或者参加下个月在上海举办的 KubeCon + CloudNativeCon 微软推出 Service Mesh Interface （SMI） Service Mesh 也是一个趋势，但现在并没有一个统一的规范，各个厂商的实现也都各有不同。微软本次提出的 SMI 主要是为 Kubernetes 服务网格提供通用接口，以便能让 Service Mesh 有更加通用的规范 （就像当初 CNI/CRI 那样子）

云原生（Cloud Native）应用是伴随着 Kubernetes 应用范围的扩大，基于云模型而提出的一种概念。 本文来介绍一个云原生应用开发的工具 Kui, 这是一款由 IBM 开源的工具，使用 Electron 提供 GUI 能力。 Kui Shell offers a new development experience for building cloud-native applications. By combining the power of familiar CLIs with visualizations in high-impact areas, Kui enables you to manipulate complex JSON and YAML data models, integrate disparate tooling, and provides quick access to aggregate views of operational data. 正如以上介绍中提到的，Kui 提供了一种新的开发体验（原先大多数时候我们是通过 kubectl 与 Kubernetes 中的资源进行交互），Kui 结合了原有 CLI 的强大功能，并提供一种可视化的方式，方便我们对 Kubernetes 中 YAML 或者 JSON 格式数据的处理。

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 kind v0.3.0 正式发布 kind (Kubernetes In Docker) 是我很喜欢并且一直持续参与贡献的项目，本周发布了 v0.3.0 版本。关于 Kind 的介绍和基础使用，可以参考我之前写的文章 《使用 Kind 搭建你的本地 Kubernetes 集群》 本次的发布主要侧重于加速集群的启动速度及提高稳定性，优化镜像大小，以及对网络的优化和一些 bugfix 等；其中最主要的内容是将默认的 CRI 从 Docker 换成了 Containerd，以此可以缩小镜像体积，以及加快集群的启动。 v0.3.0 版本中，可以通过配置文件自行部署不同的 CNI，更有利于用户测试实际的集群情况；现在版本中已经将默认的 Kubernetes 版本升级到了最新的 v1.14.2 。 当然，也还有一些正在增加的特性，预计会在 v0.4.0 版本中发布，主要集中于 IPv6 和集群重启的支持（相信很快就可以完成了）。 顺便公布一个数据，Kind 目前的 star 数是 1.8k 还在持续增长中 :) 更多的细节和信息请参考 ReleaseNote Kubernetes v1.14.2 正式发布 这是一个常规的 bugfix 版本，但有个值得关注的点： 升级到了 golang v1.12.5 版本。 你可能要问为什么需要关注 golang 版本的升级？这是因为在此版本中 golang 有一些关于运行时的修改，尤其是其中关于二叉树查找部分的修改等部分的修改，可有效的降低 Kubernetes API server 的延迟。

经过了长时间的开发，Helm 3 终于在今天发布了第一个 alpha 版本。本文将简单介绍 Helm 3 新特性。 移除 Tiller Helm 2 是 C/S 架构，主要分为客户端 helm 和服务端 Tiller; 与之前版本相同，Helm 3 同样在 Release 页面提供了预编译好的二进制文件。差别在于原先的二进制包下载下来你会看到 helm 和 tiller 。而 Helm 3 则只有 helm 的存在了。 Tiller 主要用于在 Kubernetes 集群中管理各种应用发布的版本，在 Helm 3 中移除了 Tiller, 版本相关的数据直接存储在了 Kubernetes 中。 现在我们直接在一个新创建的集群上来使用 Helm。测试集群的创建可以参考我之前的文章 使用 Kind 搭建你的本地 Kubernetes 集群。 与之前版本相同，我们需要先执行 helm init 来进行初始化。但现在的初始化就简单了很多，不再需要给集群中部署 Tiller 了 (MoeLove) ➜ ~ export HELM_HOME=/tmp/helm3 (MoeLove) ➜ ~ helm3 init Creating /tmp/helm3/repository Creating /tmp/helm3/repository/cache Creating /tmp/helm3/plugins Creating /tmp/helm3/starters Creating /tmp/helm3/cache/archive Creating /tmp/helm3/repository/repositories.

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Alpine Linux Docker 镜像漏洞 CVE-2019-5021 本周比较吓人的是 CVE-2019-5021, 根据漏洞报告，自 Alpine Linux 3.3 版本开始的所有 Docker 镜像中，root 用户包含一个空密码，这可能会导致攻击者获得 root 权限，今儿造成攻击。 报告中称：受影响范围是 Alpine Linux Docker 镜像 3.3、3.4、3.5、3.6、3.7、3.8、3.9、edge 等全部版本。 要知道由于 Alpine Linux 镜像体积较小，所以在构建 Docker 镜像时，很多人都会推荐使用 Alpine Linux 作为基础镜像；包括很多 Docker 官方镜像也基本上都提供了基于 Alpine Linux 的镜像，甚至像 Docker 镜像等是只提供了使用 Alpine Linux 作为基础镜像的版本。 当前漏洞已经修复，更多内容请阅读 关于 Alpine Docker 镜像漏洞 CVE-2019-5021 。 istio-operator 发布 0.1.12 版本 banzaicloud/istio-operator 发布 0.1.12 版本，默认已支持 istio 1.1.5 。（虽然截至目前 istio 发布了 1.

关于 CVE-2019-5021 带来的一点思考。 本周比较吓人的是 CVE-2019-5021, 根据漏洞报告，自 Alpine Linux 3.3 版本开始的所有 Docker 镜像中，root 用户包含一个空密码，这可能会导致攻击者获得 root 权限，进而造成攻击。 报告中称：受影响范围是 Alpine Linux Docker 镜像 3.3、3.4、3.5、3.6、3.7、3.8、3.9、edge 等全部版本。 要知道由于 Alpine Linux 镜像体积较小，所以在构建 Docker 镜像时，很多人都会推荐使用 Alpine Linux 作为基础镜像；包括很多 Docker 官方镜像也基本上都提供了基于 Alpine Linux 的镜像，甚至像 Docker 镜像等，是只提供了使用 Alpine Linux 作为基础镜像的版本。 报告一出，瞬间这个消息就被传播成了 “Alpine Linux Docker 镜像不安全”/“不要再使用 Alpine Linux 了”。当然 Google 的开发者也顺便推了一次自家的 distroless 镜像。 我们来看一下 CVE-2019-5021 到底是什么以及如何复现吧。 CVE-2019-5021 (MoeLove) ➜ ~ docker run --rm -it alpine:3.9 / # grep root /etc/passwd root❌0:0:root:/root:/bin/ash operator❌11:0:operator:/root:/bin/sh / # grep root /etc/shadow root:::0::::: / # 以上是一个 alpine:3.

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Docker Hub 只读维护 在上周的推送中，有写到 Docker Hub 用户隐私数据泄漏。受此事件影响，5 月 4 日 Docker Hub 进行升级维护，在此期间 Docker Hub 有一段时间处于只读模式，包括自动构建等服务不可用；在最后有小于 15 分钟的完全宕机时间，服务完全不可用。 如果只是看事情表面的话，可能这就是一个由于发现“安全问题”而进行的升级/维护；但如果仔细考虑下，作为云原生服务，升级为何会有宕机的情况，为何会有服务完全不可用的时候？ 摘录一段来自本次维护的公告内容： Q: Is this maintenance related to recent Docker Hub data breach? A: While we discovered unauthorized access to a single Hub database storing a subset of non-financial user data last week, which has since been remediated, we are always looking at ways to improve and enhance our security practices to protect our customers and their data.

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Docker Hub 用户隐私数据泄漏 2019 年 4 月 25 日，Docker Hub 团队发现了对存储非财务用户数据子集的单个 Hub 数据库的未授权访问。 在发现异常后官方团队迅速采取行动并保护网站免受攻击。 经过官方团队的调查，目前大概有 190000 帐号的敏感信息（小于总用户数的 5% ）包括用户名和哈希后的用户密码，当然也包括 GitHub 及 Bitbucket 等的用于自动构建的 Token 。 当前的主要措施是对可能被泄漏信息的用户发送了邮件通知，对于可能泄漏哈希密码的用户发送了重置密码的邮件，并且 主动 将密码失效，以及自动构建的 Token 也都被失效。( 所以如果你收到了 Docker Hub 团队关于此次事件的直接报告邮件，很大概率是因为你的信息已经被泄漏了 ) 附上官方声明中关于此次事件的处理声明： During a brief period of unauthorized access to a Docker Hub database, sensitive data from approximately 190,000 accounts may have been exposed (less than 5% of Hub users).