Docker

需求 一个轻量级的 docker registry 方案讨论 Harbor 的功能丰富，但是过于重量级了，与其他平台集成并不方便。Portus 类似。这一类产品都比较侧重 UI 和认证，一般都带有数据库， 与K8S 的集成也比较麻烦。最终看起来还是 registry 最合适，不过就是功能太简陋了。需要考虑的东西很多: HTTPS 暴露方式 -> Ingress/NodePort. 最好的方式当然是 Ingress, 但虽然 registry 支持 SubPath, 但docker client 不支持。所以只能退而求其次用 NodePort. 对外地址的暴露只能设计 CR 来做了 GC -> 这块看起来都受限于 registry 本身的能力。它提供了命令行工具能手工清除 blob, 但其他的 metadata 没删完。导致做完 GC 还得重启下 registry. 同时还得保持 GC 时 readonly. 这里面最繁琐的就是 GC, 目前提供的工具非常的原始。harbor 集成了 gc 的功能，应该是在 admin 页面提供了按钮来手动触发。那么在 K8S + registry 的限定范围内应该怎么做，目前想好的流程是： 在 registry 的 deployment 里加一个 container 来处理 GC， 这样的好处是可以共享配置，存储和 PID gc container 和 registry container 共用同样的镜像，但 CMD 不一样 gc container 的 CMD 是一个 while 循环，用来周期性地跑 GC 命令 跑完 GC 之后，如果确实清理了一些 blob, 还需要重启 registry. 不然因为其他一些 metadata 没有清理， 直接 push 和 pull 会出错。 这样就组成了一个低成本的可用的 GC 方案。缺点就是没法方便地将 registry 置为 readonly. 理论上来讲, gc 的周期设置长一点，问题不大. ...

为什么需要 BuildKit BuildKit 长什么样子 LLB 有用的新功能 Links 对于 Docker 和 Kubernetes 来说，在自身发展的壮大过程中，都会经历一个因为功能不断增加导致的软件结构庞杂的问题。对于 Kubernetes 来说，出于架构上的考量，kubectl 等项目的代码都会逐渐从主项目中移除。对于 Docker 来说，事情更为复杂，它既要考虑开源，又要考虑自己的商业化，所以有了 moby 以及 *kit 等一系列项目。 下图清晰地展示出了 Docker 对于相关项目的一个架构规划: 总体来说，Docker 希望将容器技术与容器产品分离开，核心技术是开源的，可扩展的，这样允许有其他人来基于同样的技术来构建类似于 Docker CE/Docker EE 这样的产品。 BuildKit 自 2017 年年底便已经实现，但似乎关注度不是很高(在国内)，在 CI/CD 系统中的应用也不是很广泛。本文是关于 BuildKit 的一个相关介绍。 为什么需要 BuildKit 除了上面说的商业以及架构上的考量，本身在构建这一块，Dockerfile 以及相应的机制也面临着一些问题 并发程度不够好 很多步骤都是可以并行执行的，比如两部构建中的两次 pull 镜像，以及各种 run 命令 对 cache 的支持不好 像 golang 这样的语言，每次构建都要从头开始，没法复用缓存 对 secret 的支持不好 难以支持在 dockerfile 中通过 username-password/ssl key 等方式获取一些加密信息 ...

实验特性 很多软件在发布的时候都会分为开发板和稳定版，稳定版可以供生产环境使用，开发版是让 感兴趣的用户使用，体验新特性，并报告 BUG 以助于官方改进。现在 Docker 在提供稳定版的 同时，也提供了集成了很多新特性的开发版供下载使用。 正式版的安装方式是用 https://get.docker.com/上的脚本， 开发版的安装类似，只不过用的脚本不一样 : https://experimental.docker.com/，二者最终会 启用不一样的软件源。目前开发版的版本是:1.8.0-dev,如下图所示: 注意其中的Experimental字段为TRUE。 下面我就先来看看开发版里的比较重要的更新，以便了解 Docker 后续的发展状况: 插件支持 在介绍插件之前，我们首先回顾一下 Docker 本身的架构发展。Docker 从一开始就是 REST API + JSON 的架构，这是整个 Docker 生态体系能迅速壮大的原因之一。但就 Docker Server 端的后台 Engine 来说，仍然是好多功能交织在一块,过于复杂。所以在 Docker 的后续版本中， 对 Engine 进行模块化重构一直是重中之重。从最初分离出来的 libcontainer,到 libtrust,然后现在的libnetwork,libkv，越来越多的子模块被独立出来，既简化了架 构，也增强了 Docker 对各个异构系统的适应能力。很多模块在使用上都有点类似于最早的 GraphDriver这一块，Docker 只提供一个通用的 Driver接口，各个文件系统 (aufs,overlay等)自己实现这些接口即可。如今的插件机制便是对这一功能的扩充。 如今的插件机制只支持 volume plugin和network driver plugins，后续肯定也会支持其他的 插件。如果你想现在自己尝试编写一个插件，请参考以下文档: Experimental: Docker Plugin API 官方文档里也列出了几个现存的插件，如下所示: Flocker plugin volume plugin,是数据卷可在多个主机间无缝迁移。 Weave plugin netwrok driver plugin,提供虚拟的多主机间的容器网络环境 Calico plugin network driver plugin, 提供多主机间基于 BGP 的虚拟网络 网络和服务 大家期待已久的关于网络和服务的特性终于在这一版里有了重大更新。如今network和 server都已经成了Docker里面的一等公民，像Image和Container一样,在命令行 里试一下: ...

本篇的主要内容是为了澄清 docker 容器的一些容易混淆的概念，主要分两部分， 一是容器端口的publish和expose,二是 Dockerfile 中ENTRYPOINT和CMD的区分。 ...

本篇的主要内容是关于如何删除镜像的.听起来是挺简单的一件事,但是docker本身的删除 策略定义并不清除，而且在实际的使用过程中,似乎总是与我们预计的结果不符,比如磁盘空间并没有被释放.所以在此单列一篇,详细解析镜 像删除的过程. ...

本篇的内容主要是关于docker镜像的。在我们安装好docker之后，要想使用它，第 一步就是要下载一些镜像。本文将依据此流程分析docker中镜像的拉取、存储等相关内容。 ...

本篇的主要内容是关于docker daemon启动时网络设置的相关部分，在上一篇中已经简要 提到(Docker daemon 启动流程) 。主要内容集中在InitDriver函数的解析上。 ...

本篇的主要内容是关于docker daemon的启动流程。其主要内容均包含在 github.com/docker/docker/docker/daemon.go文件中的mainDaemon函数中，本文即按 其执行流程分析源码。因为所涉源码较多，所以所涉部分多是点到为止，详细分析会在后续 分专篇讲述。 ...

研究一个大项目的源码，最好是从main函数入口，一步一步与实际程序相结合，将实际代 码与相应相印证。所以本篇的主要内容就是 docker 主程序的启动流程以及命令行参数解析的 过程。 ...

之前看过一遍docker的代码，但比较粗略。第二遍准备详细过一遍并且用博客的方式将其 整理一下。目前为止docker的稳定版本为1.4.1,所以就以此版本的代码为基础进行阅读，分 析。 ...