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。

该怎么上传自己的镜像

现在，我想你应该对如何在docker hub上选择镜像有了比较全面的了解，那么接下来的问题就是我们用dockerfile创建的镜像该如何上传到docker hub上呢？

这件事其实一点也不难，只需要4个步骤就能完成

第一步，你需要在docker hub上注册一个用户，这个就不必再多说了

第二步，你需要在本机上使用docker login命令，用刚才注册的用户名和密码认证身份登录，像这里就用了我的用户名chronolaw

第三步很关键，需要使用docker tag 命令，给镜像改成带用户名的完整名字，表示镜像是属于还整个用户的，或者简单一点，直接用docker build -t在创建镜像的时候就起好名字，这里我就用上次章节里的ngx-app作为例子，给他改名成chronolaw/ngx-app：1.0

docker tag ngx-app chronolaw/ngx-app:1.0

第四步，用docker push 把这个镜像推上去，我们的镜像发布工作就大功告成了：

docker push chronolaw/ngx-app:1.0

你还可以登录docker hub网站验证一下镜像发布的效果，可以看到他会自动为我们生成一个页面模板。，里面还可以进一步丰富完善，比如添加描述信息，使用说明等等；

现在你就可以把这个镜像的名字（用户名/应用名：标签）告诉你的同事，让他去用docker pull 下载部署了

离线环境该怎么办

使用docke hub来管理镜像的确是非常方便，不过有一种场景它却是无法发挥作用，那就是企业内网的离线环境，连不上外网，自然也就不能使用docker push。docker pull来同送拉取镜像了

那这种情况有没有解决办法呢？

方法当然有，而且有很多，最佳的方法就是在内网环境里仿造docker hub，创建一个自己的私有registry服务，有他来管理我们的镜像，就想我们自己搭建gitlab做版本管理一样

自建registry已经有很多成熟的解决方案，比如docker registry，还有CNCF Harbor，不用使用他们还需要一些目前没有讲到的知识，步骤也有点繁琐，所以我会在后续的章节里再介绍

下面我们说一说存储，分发镜像的一种笨方法，虽然比较原始，但简单易行，可以作为临时的应急手段

docker提供了save和load这两个镜像归档命令，可以把镜像导出成压缩包，或者从压缩包导入docker，而压缩包是非常容易保管和传输的，可以联机拷贝，FTP共享，甚至存在U盘上随身携带

需要注意的是，这两个命令默认使用标准流作为输入输出（为了方便linux管道操作）所以一般会用-o、-i参数来使用文件的形式，例如：

docker save ngx-app:latest -o ngx.tar

docker load -i ngx.tar

小结

好了，今天我们一起学习了镜像仓库，了解了docker hub的使用方法，整理一下要点方便你加深理解：

1-镜像仓库（registry）是一个提供综合镜像服务的网站，最基本的功能是长传和下载

2-docker hub是目前最大的镜像仓库，拥有很多高质量的镜像和，尚明的镜像非常多，选择的标准有官方认证，下载量，星数等，需要综合评估

3-镜像也有很多版本，应该根据版本号和操作系统仔细确认合适的标签

4-在docker hub注册之后就可以上传自己的镜像，用docker tag打上标签再用docker push推送

5-离线环境可以自己搭建私有镜像仓库，或者使用docker save把镜像存成压缩包，再用docker load从压缩包恢复成镜像

最后我还是提问几个问题，留给大家来思考：

1-很多应用，比如nginx，redis，go，都已经有了docker官方镜像，为什么其他公司（Bitnami，Rancher）还要重复劳动，发布自己打包的镜像呢？

2-你能否对比一下GitHub和docker hub，说说他们两个在功能，服务对象，影响范围，等方面的异同点呢？

记得在留言区参与讨论哦，我看到后会第一时间回复，我们下个章节再见~