Docker on 涯余的博客

关于 OAM 与云原生应用

hang.yan@hotmail.com (涯余) — Thu, 22 Oct 2020 11:34:13 +0800

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 的镜像 GC 问题

hang.yan@hotmail.com (涯余) — Mon, 07 Sep 2020 18:13:47 +0000

需求

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

What is Helm Doing Wrong and How a Helm3 Controller Can Fix It

hang.yan@hotmail.com (涯余) — Sat, 03 Aug 2019 11:26:30 +0000

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.

Docker BuildKit 介绍

hang.yan@hotmail.com (涯余) — Mon, 08 Apr 2019 16:22:48 +0800

对于 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 等方式获取一些加密信息

Docker 1.7 介绍

hang.yan@hotmail.com (涯余) — Sun, 12 Jul 2015 21:37:39 +0800

docker 1.7 features

docker 容器内多进程的管理方案

hang.yan@hotmail.com (涯余) — Fri, 08 May 2015 21:37:39 +0800

容器生来适合的是以单进程为主的独立的微服务架构，而很多传统的组件则是体积庞大，多个进程（组件）之间难以拆分到不同的容器中，所以在单个容器内部署多个组件便成了一种暂时的折衷方案。这便引入了一个问题：如何在容器内管理多个进程？

docker 容器的一些概念辨析

hang.yan@hotmail.com (涯余) — Thu, 16 Apr 2015 21:37:39 +0800

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

docker 源码分析(6) -- 镜像删除

hang.yan@hotmail.com (涯余) — Fri, 03 Apr 2015 21:37:39 +0800

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

docker 源码分析(5) -- 镜像拉取及存储

hang.yan@hotmail.com (涯余) — Mon, 30 Mar 2015 21:37:39 +0800

docker images pulling and store

docker 源码分析(4) -- 网络设置

hang.yan@hotmail.com (涯余) — Mon, 16 Feb 2015 21:37:39 +0800

docker network setttings

docker 源码分析(3) -- daemon 启动流程

hang.yan@hotmail.com (涯余) — Thu, 05 Feb 2015 21:37:39 +0800

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

docker 源码分析(2) -- 主程序及命令行参数解析

hang.yan@hotmail.com (涯余) — Fri, 30 Jan 2015 21:37:39 +0800

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

docker 源码分析(1) -- 开发环境准备

hang.yan@hotmail.com (涯余) — Thu, 29 Jan 2015 21:37:39 +0800

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