图解DockerRegistry与CharMuseum

前言

        在裸机和虚机时代，（Linux上）我们会使用yum+rpm来管理软件的安装包。到了云原生时代，我们使用“制品库+镜像库”来管理软件。区别在于前者直接安装在裸机或虚机上，而后者是运行在一个个容器中。

        什么是镜像库？什么是制品库？

        通常我们将应用制作成镜像，然后以容器的方式运行，这里的镜像类似于应用的“模板”，容器就是镜像的“运行实例”，要统一管理这些镜像，就需要“镜像仓库”。一个完整的应用或系统可以由多个基础容器组成（一般都会有前台应用、后端服务和底层关系型数据库），我们将这些基础容器的编排过程抽象成一批yaml文件，然后打包成“制品”，然后由K8S调度。要管理这些制品，就需要制品库。

        镜像库和制品库，以及他们与K8S是什么关系呢？先看下方图片：

图1 镜像库&制品库与K8S的关系

        下面我们逐个分析图中的组件。

镜像仓库

        镜像仓库分为2种：本地仓库和云仓库。

本地仓库（图1中local）

        如果想把应用限制在公司内部使用，可以将这些镜像存储在本地仓库中。“本地仓库”这个概念是相对于云仓库的。

        我们通过“docker pull”拉取过来的镜像默认存放在本机的/var/lib/docker路径（可在配置文件中修改）下，但这并不是“本地仓库”，因为你pull过来的镜像还不能被其他节点共享。想要被共享，就需要创建本地仓库。我们可以使用docker官方提供的registry搭建本地仓库，搭建过程比较简单，拿来测试非常方便。

        如果是企业级仓库，或者是对权限有要求的场景，可以使用 Habor 搭建本地仓库。它包含了registry，提供了Web管理界面（HaborUI），也集成了LDAP、定时调度等组件，功能全面，但是部署相对复杂，需要专业人士维护。这里给大家一张 Harbor架构 - 简书 图，其中的Docker Distribution就是registry。

图2 Habor2.0架构

        本地仓库搭建好后，需要在内网环境中每个节点上的/etc/docker/daemon.json中配置好仓库地址，就可以通过“docker pull”命令拉取本地仓库的镜像了。同样，开发人员编写好Dockerfile、生成镜像之后，就可以将镜像push到本地仓库local中（图1中上方“docker push”环节）。

云仓库（图1中Cloud Registry）

        当我们的镜像可以对外公开时，就可以选择存储到云仓库中，如DockerHub、阿里云镜像仓库，等等。我们也可以从这些可信源拉取镜像到本地运行。这些仓库一般都是由专业公司维护的，随取随用。我们可以在本地仓库中进行设置，定期将云仓库中的镜像同步到本地仓库中。

        如果想自己建立“云仓库”，与互联网上所有开发者共享，就可以在“本地仓库”基础上暴露服务端口即可。

注意：云仓库对安全性要求较高，要做好相应的安全、审核策略。

制品库

        “制品”这个概念，我们可以理解为是一系列应用或组件的组合，是能支撑某个业务目标的完整解决方案。

                如前面提到的Habor，除了包含registry组件外，还包含了Redis、Postgre、HaborUI等等组件，如果我们一个个组件单独部署，势必会存在一些集成问题，部署效率也低。在K8S时代，就为我们提供了相应的解决方案：使用K8S专用的包管理工具helm，就可以完成Habor的一键部署。简单来说 ，helm包是由一堆yaml文件组成，作用是以模板+参数的方式将K8S的各种资源和容器镜像进行编排，然后提交给K8S进行调度。当helm包很多时，就需要仓库对这些包进行管理。目前常用的helm仓库是chartmuseum，部署也很方便，在docker环境下一条指令即可完成部署，如：

docker run -d \
  --restart=always \
  --name helmRegistry \
  -p 8899:8080 \
  -e DEBUG=1 \
  -e STORAGE=local \
  -e STORAGE_LOCAL_ROOTDIR=/charts \
  -v /home/charts:/charts \
  chartmuseum/chartmuseum:latest

说明：建议参考专业的文档来完成部署，本文不赘述。

在实践中是如何使用的呢？

        如图1所示（左下角“helm package”分支），当各组件的镜像都制作完成之后，开发人员就可以编写Chart.yaml和Value.yaml等文件，执行“helm package”生成Helm包 xxx.tgz。随后执行“helm cm-push”（也有helm push，这个是插件需要自己安装）将这个包推送到chartmuseum 中。此后，这个包就可以被多个K8S集群中共享。如Harbor的例子，集群A要安装Harbor，只需要在集群A的某个节点上执行“helm install”（前提是配置了helm仓库），这是节点就会到仓库中先拉取helm包，由K8S解析，根据这个包中指定的镜像信息，再到docker本地仓库中拉取镜像、启动。

        这里给出Habor的helm包结构，帮助大家理解：

图3 harbor-helm-1.8.0

说明：

一些常用的开源组件都有helm包，不需要我们自行编写。

我们在项目中只需要仿照这些开源组件的helm包，编写业务应用的helm。

        图中所示helm有v2和v3两个版本，区别是v2版本多了个Tiller服务端，由它负责与K8S进行交互。由于这种方式存在种种弊端，Helm3应运而生。它去掉了Tiller，由helm通过http协议直接与K8S的ApiServer交互，实现资源的调度。

HaborUI

        最后再聊聊图1中的HaborUI。这是Habor自带的Web端，我们可以在这上面配置docker的镜像仓库和helm仓库，实现对镜像和制品库的展示和管理。

---

最后

        阅读本文之后，你是否对镜像库和制品库，以及他们跟K8S之间的关系有了更深入的了解？