Docker

OAM 是指阿里开源的一个应用模型，主要是云原生场景。年初的时候出来到现在，断断续续地了解过一些，之前一直没有特别想清楚，其实现在也是，但多多少少有一点点感悟，在这里记录一下. 云原生应用的现状 这里主要就是说围绕 kubernetes 生态的应用现状，基本上就是一团糟。没有标准，没有好的开源产品，没有社区来推动这个事情。先看看目前有啥: Helm: 适合作为rpm/apt类似的东西，不适合直接给 end user 用 Application CRD: 社区不活跃，结构定义也不好 Operator: 过于复杂，目前仅有的统一规范是 ocp 弄的 operator framework. 尚未推广开来 其他林林总总的各种 ad-hoc 方案 这就导致云厂商要么是完全自己做一套新的应用模型，要么是用上面这一类现成的，但功能受限，扩展不易。且用户需要有一定的前置知识才能用好。 OAM 的主要优点 目前看来其最主要的优点是角色分离。Kubernetes YAML 的一个主要问题就是，它是一个大而全的 cofig 方案，不宜手写，只适合运维方向。如果想要做成用户友好的模型，OAM提供了一种可能性: 将大的 config 按角色分拆开，开发人员写一部分，运维人员写一部分，各自只关心各自的部分，最终再合并成一个整体的 config. 细节问题比如具体分成几个角色，谁来合并，可以再迭代改进。但这个分离的设计可以认为是走在一个正确的方向上。 其他的几个重要的方面有： 跨平台性。从设计上来讲，一开始设计成跨平台的思路当然是对的。但实际上可能还是90%以上的人主要是用在 k8s 上，所以 spec 设计时比较贴近于 k8s 的设计。其他平台的实现估计会花不少时间，这也是导致目前没有其他平台实现的主要原因 插件系统。OAM 提供的 traits 能力，可以理解为对应用的一个插件系统。之前国内有厂商做过类似的东西，是一个非常好的尝试。以插件形式给应用附加能力，是一种非常自然和方便的用户体验，traits可以用来提供类似的能力。 用户体验 即使做了职责分离，OAM 看起来仍然是非常难以直接 edit 的东西。这也是之前我一直比较纠结的一个点。因为它更像一个面向开发者的 spec, 而不是一个对 end user 的产品。我们如何让用户方便地使用这个功能呢，有下面几种可能: 纯 UI 封装。这里需要 UI 设计的比较好，能够隐藏比较多的细节，不要暴露太多的底层名词给用户，不然用户就要去理解 OAM 是个什么东西了。而我们理想的形式就是让用户不去学习新概念。一个可能的点就是我上面说的，把 traits 叫做 插件等等。这里需要考虑的一个点是API怎么设计，因为一般UI/API都是必须的产品。如果直接把 OAM 用 API 暴露出来也不怎么友好，这就涉及到下面的第二点 我们能否再设计一层 spec, 简单一点的，能提供便捷的API,UI也方便？ 这个诱惑力比较大，但其实又回到了远点，因为又回到了老的大的 config 上? 假设我们想做的更简单一些，那势必又无法全面覆盖 OAM 的能力。似乎唯一的可能性就是，我们换了一种 spec 格式，让用户更容易理解，但可以和 OAM 一一对应。 因为之前有厂商放出了一些 OAM UI 的截图，比如: ...

需求 一个轻量级的 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 的周期设置长一点，问题不大. ...

Helm is big success for sure, it’s nearly the standard application package format in kubernetes.You only need to provide some metadata about your application’s name, version, description….Helm can help you package up and upload to a central or custom chart repo.Just like npm,rpm,docker image, or whatever other package management system. About a year ago, Helm3 was drafted. Since it’s still on the proposal stage, most users are still using helm2, include us. The journey we spent with helm was not a very pleasant one, we struggled very hard to make it work. In the end, we decided to create a kubernetes controller based on Helm3 proposal, it works well and we open source it on github: captain. ...

为什么需要 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,所以就以此版本的代码为基础进行阅读，分 析。 ...