kubernetes入门到进阶（5）

镜像仓库：怎么用好docker hub这个宝藏

什么是镜像仓库（Registry）

什么是docker hub

如何在docker hub上挑选镜像

docker hub上进行概念股命名规则是什么

该怎么上传自己的镜像

离线环境该怎么办

小结

镜像仓库：怎么用好docker hub这个宝藏

好，我们继续来说一下往后的章节，上章节里面呢，我们学习了dockerfile和docker build的用法，知道了如何创建自己的镜像，那么镜像文件应该如何管理呢，具体来说，应该如何存储，检索，分发，共享镜像呢？不解决这些问题，我们容器化应用还是无法顺利地实施。

今天，我们来谈一下这个话题，聊聊什么是镜像仓库，还有该怎么用好镜像仓库。

什么是镜像仓库（Registry）

之前我们已经用过docker pull命令拉取镜像，也说过有一个镜像仓库（Registry）的概念，那到底什么是镜像仓库呢？

还是来看看docker的官方架构图：

图里右边的区域就是镜像仓库，术语叫Registry，直译是所有镜像的Repository都在这里登记保管，就像是一个巨大的档案馆。

然后我们再来看看左边的docker pull，虚线显示了它的工作流程，先到docker daemon，再到Registry，只有当Registry里存有镜像才能真正把他下载到本地。

当然了，拉取镜像只是镜像仓库最基本的一个功能，他还会提供更多的功能，比如上传，查询，删除等等，是一个全面的镜像管理服务站点。

你也可以把镜像仓库比成手机上的应用商店，里面分门别类放了许多容器化的应用，需要什么去找一下就行了，有了它，我们使用镜像才能免除后顾之忧。

什么是docker hub

不过，你应该没有注意到，在使用docker pull 获取镜像的时候我们并没有明确指定镜像仓库，在这种情况下，动车可就会使用一个默认的镜像仓库，也就是大名鼎鼎的docker hub

https://hub.docker.com

docker hub是docker公司搭建的官方registry服务，创立于2014年6月，和docker 1.0同时发布，他号称是世界上最大的镜像仓库，和Git hub一样，几乎成为了容器世界的基础设施。

docker hub里面不仅有docker自己打包的镜像，而且还对公众免费开放，任何人都可以上传自己的作品，经过这8年的发展，docker hub已经不再是一个单纯的镜像仓库了，更应该说是一个丰富而繁荣的容器社区

你可以看看下面的这张截图，里面列出的都是下载量超过十亿次的最受欢迎的应用程序，比如nginx，MongoDB，node.js，Redis，openJDK，等等，显然，把这些容器化的应用引入到我们自己的系统里，就像是站在了巨人的肩膀上，一开始就会有一个高水平的起点

但和Github，App Store一样，面向所有人公开的docker hub也有一个不可避免的缺点，就是良莠不齐。

在docker hub搜索框里输入关键字，比如NGINX，MySQL，她立即就会给出几百上千个搜索结果，有点乱花迷人眼的感觉，这么多镜像，应该如何挑选出最适合自己的呢？下面我们来说说自己在这方面的一些经验。

如何在docker hub上挑选镜像

首先，你应该知道，在docker hub上有官方镜像，认证镜像，和非官镜像的区别

官方镜像是指docker公司官方提供的高质量镜像，GitHub - docker-library/official-images: Primary source of truth for the Docker "Official Images" program

都经过了严格的漏洞扫描和安全检查，支持x86，arm64等多种硬件架构，还具有清晰易读的文档，一般来说使我们构建镜像的首选，也是我们编写dockerfile的最佳范例

官方镜像目前大概100多个，基本上囊括了现在的各种流行技术，下面就是官方的nginx镜像网页截图：

你会看到，官方镜像会有一个特殊的Official image的标记，这就表示这个镜像经过了docker公司的认证，有专门的团队负责审核，发布，更新，质量上绝对可以放心。

第二类是认证镜像，标记是Verified publisher，也就是认证发行商，比如Bitnami，Rancher，ubuntu等，他们都是颇具规模的大公司，具有不逊于docker公司的实力，所以就在docker hub上开了个认证账号，发布自己打包的镜像，有点类似我们微博上的大V。

这些镜像有公司背书，当然也很值得信赖，不过他们难免会有戴上一些各自公司的烙印，比如Bitnami的镜像就统一以minideb为基础，灵活性上比docker官方镜像略差，有的时候也许会不符合我们的需求。

除了官方镜像和认证镜像，剩下的就都属于非官方镜像了，不过这里面也可以分出两类。

第一类是“半官网”镜像，因为成为Verified publisher 是要给docker公司交钱的，而很多公司不想花这个冤枉钱，所以只在docker hub上开了公司账号，但并不加入认证

这里我以openresty为例，看一下它的docker hub页面，可以看到显示的是openresty官方发布的，但并没有经过docker正式认证，所以难免就会存在一些风险，有被冒名顶替的可能，需要我们在使用的时候留心鉴别一下，不过一般来说，这种办官方镜像也是比较可靠的

第二类就是纯粹的民间镜像了，通常是个人上传到docker hub的，因为条件有限，测试不完全甚至没有测试，质量上难得以保证，下载的时候需要小心谨慎。

除了查看镜像是否为官方认证，我们还可以再结合其他的条件来判断镜像质量是否足够好，做法和GitHub差不多，就是看它的下载量，星数，还有更新历史，简单的来说就是好评数量

一般来说下载量是最重要的参考依据，好的镜像下载量通常都在百万级别（超过1M）而有的镜像虽然也是官方认证，但缺乏维护，更新不及时，用的人很少，星数，下载数都寥寥无几，那么还是应该选择下载量最多的镜像，通俗来说就是随大流

下面这张截图就是openresty在docker hub上的搜索结果，可以看到，有两个认证发行商的镜像（Bitnami ， IBM），但是下载量都很少，还有一个民间镜像下载量虽然超过了1M，但更新时间是三年前，所以毫无疑问，我们应该选择排在前三位，但下载量超过10m，有360多个星的半官方镜像

看了这么多docker hub上的镜像，你一定注意到了，应用都是一样的名字，比如都是NGINX，redis，openresty，该怎么区分不同作者打包出的镜像呢？

如果你很熟悉GitHub，就会发现docker hub也使用了同样的规则，就是用户名/应用名的形式，比如bitnami/nginx、ubuntu/nginx、rancher/nginx等等

所以，我们在使用docker pull下载这些非官方镜像的时候，就必须把用户名也带上，否则默认就会使用官方镜像：

docker pull bitnami/nginx

docker pull ubuntu/nginx

docker hub上进行概念股命名规则是什么

确定了这个镜像还不够，因为镜像还会有许多不同的版本，也就是标签（tag）

直接使用默认的latest虽然简单方便，但在生产环境里是一种非常不负责任的做法，会导致版本不可控，所以我们还需要理解dockerhub标签命名的含义，才能挑选出最适合我们自己的镜像版本。

下面我就那官方的redis镜像作为例子，解释一下这些标签都是什么意思

通常来说，镜像标签的格式是应用的版本号加上操作系统，

版本号你应该比较了解吧，及把他那都是主版本号+次版本号+补丁号的形式，有的还会在正式发布前出rc版（候选版本，release candidate），而操作系统的情况略微复杂一些，应为各个Linux发型版的命名方式太多了

alpine，centos的命令比较简单明了，就是数字的版本号，像这里的alpine3.15.而ubuntu、Debian则才用了代号的形式，比如ubuntu.18.04是bionic，ubuntu20.04是focal，Debian9是stretch，Debian10是buster，Debian11是bullseye

另外，有的标签还会加上slim，fat，来进一步表示这个镜像的内容是经过精简的，还是包含了较多的辅助工具，通常slim镜像会比较小。运行效率高，而fat镜像会比较大，适合用来开发调试

下面我就列出几个标签的例子来说明一下。

- nginx:1.21.6-alpine，表示版本号是1.21.6，基础镜像是最新的Alpine。

- redis:7.0-rc-bullseye，表示版本号是7.0候选版，基础镜像是Debian 11。

- node:17-buster-slim，表示版本号是17，基础镜像是精简的Debian 10。