目录
镜像仓库:怎么用好docker hub这个宝藏
什么是镜像仓库(Registry)
什么是docker hub
如何在docker hub上挑选镜像
docker hub上进行概念股命名规则是什么
该怎么上传自己的镜像
离线环境该怎么办
小结
好,我们继续来说一下往后的章节,上章节里面呢,我们学习了dockerfile和docker build的用法,知道了如何创建自己的镜像,那么镜像文件应该如何管理呢,具体来说,应该如何存储,检索,分发,共享镜像呢?不解决这些问题,我们容器化应用还是无法顺利地实施。
今天,我们来谈一下这个话题,聊聊什么是镜像仓库,还有该怎么用好镜像仓库。
之前我们已经用过docker pull命令拉取镜像,也说过有一个镜像仓库(Registry)的概念,那到底什么是镜像仓库呢?
还是来看看docker的官方架构图:
图里右边的区域就是镜像仓库,术语叫Registry,直译是所有镜像的Repository都在这里登记保管,就像是一个巨大的档案馆。
然后我们再来看看左边的docker pull,虚线显示了它的工作流程,先到docker daemon,再到Registry,只有当Registry里存有镜像才能真正把他下载到本地。
当然了,拉取镜像只是镜像仓库最基本的一个功能,他还会提供更多的功能,比如上传,查询,删除等等,是一个全面的镜像管理服务站点。
你也可以把镜像仓库比成手机上的应用商店,里面分门别类放了许多容器化的应用,需要什么去找一下就行了,有了它,我们使用镜像才能免除后顾之忧。
不过,你应该没有注意到,在使用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公司官方提供的高质量镜像,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
确定了这个镜像还不够,因为镜像还会有许多不同的版本,也就是标签(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,说说他们两个在功能,服务对象,影响范围,等方面的异同点呢?
记得在留言区参与讨论哦,我看到后会第一时间回复,我们下个章节再见~