2021年那会儿我正跟着教程补Docker的功课学到容器编排之前卡在了一个很实际的问题上自己构建好的镜像除了躺在本地怎么才能方便地放到服务器上用。官方镜像仓库虽然免费但当时在国内访问的速度很不稳定拉一个镜像经常等到怀疑人生。我把目光转向了阿里云容器镜像服务也就是常说的阿里云镜像仓库结果发现个人版在当年是免费开放的注册完账号就能创建命名空间和镜像仓库然后用 docker login、docker tag、docker push 这一套命令把本地镜像推上去最后在任何一台服务器上 docker pull 拉下来直接用。整个过程不复杂但对刚开始用 Docker 的人来说入口藏得有点深。这篇笔记基于2021年阿里云控制台的界面和操作路径完整记录我当时的创建与使用过程包括命名空间和仓库的创建、命令行推送、常见报错排查以及在服务器上拉取镜像的细节。如果你现在看到的控制台界面和当年略有差异也不用慌核心逻辑是一样的先有命名空间再有仓库然后用 Registry 地址登录、打标签、推拉镜像。适合还没用过私有镜像仓库的人参考。1. 为什么要把自己的镜像放到阿里云镜像仓库里1.1 没有镜像仓库时的部署尴尬新手阶段最容易做的事情是把构建好的镜像用 docker save 导出成 tar 包再传到服务器上 docker load。小镜像还好说一旦镜像里带上了完整的运行环境体积轻松超过几百MB传一次就够难受了更别提系统里有三台服务器需要保持同一个版本。每次更新都手动传文件迟早会漏一台。另一种做法是在服务器上重新构建。听起来很干净但服务器上得准备好全部源代码、依赖、构建缓存甚至还要解决不同服务器之间构建环境不一致导致的“本地能跑、服务器上跑不了”问题。这个坑我踩过之后才明白镜像的意义在于把环境和代码一起打包而不是让每台机器重复造一遍轮子。所以一个绕不开的需求就出现了我需要一个所有服务器都能访问的镜像仓库把镜像存进去再让各台机器拉取。这就像代码要推到代码仓库再分发一样镜像也需要一个“中央仓库”。没有它容器化部署根本跑不起来。1.2 公开仓库与自建仓库的取舍公开的官方镜像仓库确实能存镜像但私有仓库要收费而我不想把内部项目直接暴露在公开仓库里。更麻烦的是网络因素在国内访问官方仓库经常超时一个不常拉的基础镜像可能要重试好几次。自己搭一个 Registry 或者 Harbor 也不是不行但意味着我要维护一台专门跑镜像服务的机器处理 HTTPS 证书、认证、存储扩容和备份。对一个学习 Docker 的个人用户来说这个投入明显不划算。当时我看了一圈阿里云容器镜像服务的个人版是最省心的不用自己搭登录控制台创建仓库就能用还提供了标准的 Registry 推拉地址和本地 Docker 命令完全兼容。对个人用户来说基本没有运维负担。1.3 个人版实际体验怎么样2021年这段时间我用下来的感受是在国内地域推拉镜像速度尚可日常学习和小项目完全够用支持创建多个命名空间每个命名空间下面再放不同项目的镜像结构上不会乱仓库也支持设置公开或私有私有仓库需要登录才能拉取安全性有基本保障。虽然是免费的个人版但对我当时的用途来说已经绰绰有余。后来我在某台服务器上连着拉过好几次镜像都没有遇到什么大问题。2. 控制台里创建命名空间和镜像仓库的完整流程2.1 登录容器镜像服务控制台并选择地域第一步是登录阿里云容器镜像服务控制台。2021年时的入口路径大概是控制台首页里面搜索“容器镜像服务”点击进去会看到“个人实例”或“默认实例”这一类的东西。第一次使用的时候会要求设置 Registry 登录密码这个密码是给 docker 命令行登录用的和后文的 docker login 直接相关。地域选择上我当时选了华东1杭州对应的 Registry 地址是registry.cn-hangzhou.aliyuncs.com后面所有 docker tag 和 docker push 里的地址都会用到它。我建议选一台离你服务器最近的地域比如服务器在华北就选北京在华南就选深圳尽量减少镜像传输的物理距离。跨地域拉镜像不是不能用只是速度会慢一些这一点后面还会再提。2.2 创建命名空间给镜像仓库分好目录创建镜像仓库之前必须先创建命名空间。控制台左侧菜单能找到“命名空间”点进去之后有个“创建命名空间”的按钮。名字我那时候用的是小写字母加中划线比如myns、my-project这类。限定规则我记得是以字母开头只支持小写字母、数字和中划线所以驼峰和大写都是不行的起名的时候直接按这个规则来就行。当时我犯了一个小错误把命名空间起得过于具体比如hello-demo-namespace后来想放别的项目镜像时后悔了因为命名空间创建之后不能改名。正确的做法是命名空间按“归属”或“环境”来分比如personal、company-test不要按单个项目来分。单个项目对应的层级应该是“仓库”每个命名空间下面可以挂很多仓库。2.3 创建镜像仓库从本地仓库类型开始进入“镜像仓库”页面点击“创建镜像仓库”。步骤大概是选择地域注意要和刚才的命名空间在同一个地域下选择命名空间比如personal填写仓库名称比如blog-backend这个会出现在最终镜像地址里选择仓库类型公开或私有。存放内部配置或专属业务代码的镜像建议选私有填写摘要和描述简单说明这个镜像的用途代码源选择2021年的控制台里可以选择“本地仓库”或绑定代码托管平台。我当时选了“本地仓库”。原因很直接我只想手动推镜像不想让平台在我每次提交代码之后自动构建。自动构建这个功能确实存在把代码托管平台授权给阿里云之后仓库会监听代码提交事件自动在后台构建镜像并推送。这个流程适合有持续集成习惯的人但对学习阶段的我来说手动 push 能让我更清楚地看到每一步发生了什么。创建完成之后控制台会跳转到仓库详情页页面下方通常会给出一段操作指南里面有完整的登录、打标签、推送命令。我后来就是用这段命令对照着跑的。3. 推送前必须搞懂的三个概念登录、打标签、仓库地址3.1 在命令行里登录自家仓库控制台给的登录命令长这样docker login --username你的用户名 registry.cn-hangzhou.aliyuncs.com第一次执行会提示输入密码这里输入的密码不是阿里云账号密码而是我们在容器镜像服务控制台里设置的 Registry 登录密码。如果当时没设置可以去控制台“访问凭证”那一栏设置固定密码也可以生成临时密码。临时密码有有效期限制适合临时用但日常建议用固定密码加高复杂度。我看到过不少人在这里卡住明明阿里云账号密码是对的docker login 却报错就是因为搞混了“登录控制台的密码”和“Registry 登录密码”两套凭证。另外需要注意docker login 成功后凭证会保存在~/.docker/config.json文件里以后在同一台机器上再推拉镜像就不需要重复登录了。3.2 docker tag给镜像补上完整的仓库地址Docker 的设计里镜像名称本身就是一个“地址”。本地镜像一般叫blog-backend:latest但要推到阿里云仓库必须把它变成完整的地址格式。docker tag 就是干这个的docker tag blog-backend:latest registry.cn-hangzhou.aliyuncs.com/personal/blog-backend:v1.0可能有人会问为什么不能直接对本地镜像执行 docker push 并指定目标地址非要先 tag 一下因为 docker push 推送的对象是“带完整地址的镜像名”而本地构建出来的镜像是没有归属地址的相当于一份“原件”。tag 相当于给它贴上一张写满收件地址的快递单快递员才知道往哪儿送。而且 tag 并不会复制镜像内容只是多了一个引用名称所以不用担心磁盘空间加倍。3.3 仓库地址结构拆解这段地址看着长实际上结构很清晰拆开就懂了地址片段含义示例registry.cn-hangzhou.aliyuncs.com容器镜像服务的地域入口域名华东1杭州入口personal命名空间相当于一级目录个人项目组blog-backend仓库名相当于二级目录博客后端镜像v1.0版本标签具体版本号如果 tag 后面不写版本号默认是latest。我建议不要在生产环境里裸用 latest因为 latest 会被新的推送覆盖时间一长你根本不知道服务器上跑的是哪一天的代码。我自己的习惯是至少写成blog-backend:20210612这种带日期的版本或者 v1.0、v1.1 这种语义化版本再配合一个 latest 用来指向当前最新。4. 从构建到推送一次完整的推镜像实操4.1 推送的完整命令序列假设你已经有一个本地镜像叫blog-backend:latest现在要推到阿里云仓库。完整流程是这样# 1. 登录输入Registry密码 docker login --username你的用户名 registry.cn-hangzhou.aliyuncs.com # 2. 给镜像打上完整地址标签 docker tag blog-backend:latest registry.cn-hangzhou.aliyuncs.com/personal/blog-backend:v1.0 # 3. 推送 docker push registry.cn-hangzhou.aliyuncs.com/personal/blog-backend:v1.0推送成功的回显大概是这样的The push refers to repository [registry.cn-hangzhou.aliyuncs.com/personal/blog-backend] ... latest: digest: sha256:7b3b4a... size: 2438看到 digest 那一行就说明镜像已经上传成功了。回到控制台刷新仓库详情页镜像版本列表里就会多出 v1.0 这个标签。这里有一个很多人一开始会漏掉的细节镜像推送是分层推送的Docker 会先检查哪些层在仓库里已经存在只上传不存在的层。所以如果这次只改了几行代码可能只需要传几十MB甚至更少第二次之后的推送速度会明显比第一次快很多。4.2 碰到的坑denied、unauthorized和连接超时我总结几个当时实际遇到过的报错以及对应的处理方式。Error response from daemon: denied: requested access to the resource is denied这个报错最磨人原因通常是没登录或者登录的账号对这个仓库没有权限。处理思路是先检查镜像地址里的命名空间和仓库名是否和当前账号匹配确认无误后再登录一次。私有仓库尤其容易出现这个报错如果一直是匿名拉取就会被 denied 拦截。Error response from daemon: unauthorized: authentication required这个和上面有点像本质是登录凭证没通过。常见原因有三个密码输错、访问凭证过期、或者 docker login 之后又切换过阿里云账号。我当时的解决方式是到控制台重新生成一次临时密码再执行一遍 docker login问题就解决了。Error response from daemon: Get https://registry.cn-hangzhou.aliyuncs.com/v2/: net/http: request canceled ...这种是网络层面的连接问题尤其在服务器网络波动的时候容易出现。处理方法一般是检查服务器能否正常访问外网多试几次或者换个网络环境再推。注意不要一股脑重试很多次我看到有人失败一次就登出再登录反而会把正常的凭证弄乱不如先稳定网络再继续。还有个错误不常遇到但我也见过就是 tag 写错了之后 docker push 提示No such image: ...说明本地根本没这个标签。这时候检查一下 docker images很可能镜像名打错了或者忘了先 tag。这类问题不属于网络和权限往往是手滑冷静下来看一遍命令就能发现。4.3 推送成功之后怎么验证推送完不能只看控制台列表就放心。我自己习惯在本地把刚推的镜像删掉然后重新从仓库拉一遍确认仓库里的文件真的完整可用docker rmi registry.cn-hangzhou.aliyuncs.com/personal/blog-backend:v1.0 docker pull registry.cn-hangzhou.aliyuncs.com/personal/blog-backend:v1.0如果 pull 回来之后的镜像能正常 run那就说明整条链路是通的。这一步看着有点多余但确实帮我发现过一次推送成功后仓库内容异常的情况多半是上传中断导致的重新 push 一次就好了。5. 在另一台服务器上拉取镜像并和docker-compose配合使用5.1 换台服务器登录并拉取部署的时候进入另一台安装好 Docker 的服务器同样先登录docker login --username你的用户名 registry.cn-hangzhou.aliyuncs.com docker pull registry.cn-hangzhou.aliyuncs.com/personal/blog-backend:v1.0如果仓库是公开类型拉取不需要登录如果是私有仓库就必须登录并且账号需要有权限。当时我的服务器上都配置好了 Docker 环境直接执行 pull 就行整个拉取时间取决于镜像大小和网络状况几百MB的镜像在国内地域基本可以接受。拉取下来之后docker run 就能用了docker run -d -p 8000:8000 --name blog-backend registry.cn-hangzhou.aliyuncs.com/personal/blog-backend:v1.0这时你可能会意识到有了镜像仓库之后整个部署过程真的变成了一条命令登录、拉取、运行三步走。之前那套传 tar 包、手动解压再 load 的流程彻底可以退休了。5.2 docker-compose里直接引用私有仓库镜像如果你用 docker-compose 管理服务image 字段直接写完整镜像地址就行services: backend: image: registry.cn-hangzhou.aliyuncs.com/personal/blog-backend:v1.0 ports: - 8000:8000但有一个前提容易忽略使用 docker-compose up 之前这台机器需要先执行过 docker login否则 compose 在拉取私有镜像时会报 unauthorized 或者 denied。这个登录凭证是跟随 Docker 守护进程的compose 并不会帮你额外处理登录。5.3 连基础镜像也搬到自家仓库还有个实用的技巧如果你在服务器上构建镜像Dockerfile 里的 FROM 可能还在指向官方仓库的基础镜像而基础镜像拉取慢的问题依然存在。我的做法是把常用基础镜像先拉到本地再推送到阿里云仓库之后把 Dockerfile 里的 FROM 改成阿里云仓库地址# 原来是 FROM node:14 FROM registry.cn-hangzhou.aliyuncs.com/personal/node-base:14这样可以很大程度上避免在构建过程中反复等待基础镜像下载。这个方法不算复杂但对于经常在服务器上构建的人来说体验提升非常明显。6. 用了大半年之后总结的几个操作习惯和教训6.1 命名空间和仓库名一定要一次想好前面提过命名空间创建后不能改名这一点我体验很深。仓库名虽然可以在控制台删除重建但删除重建意味着镜像要重新推一遍版本历史也没了。所以起名之前多花两分钟想清楚这个仓库长期装什么、谁在用比事后折腾省事得多。我的习惯是命名空间按环境分dev、prod、personal仓库名按服务分blog-backend、api-server、web-fronttag 按版本或日期分v1.0、20210612。这样三层层级下来任何人看到完整地址就能猜出镜像归属团队协作的时候很省沟通成本。6.2 关于密码、凭证和泄露风险Registry 固定密码如果设置得太简单等于把整个私有仓库敞开给别人。我后来给自己定了一个原则密码必须是高强度随机串并且和阿里云控制台登录密码完全不同。另外~/.docker/config.json里保存的是登录凭证的 base64 格式如果服务器被其他人读取就等于拿到了仓库的访问权。所以我通常会把存放敏感文件目录的权限收好不给无关人员开放服务器账号。对于需要自动化推送的场景临时密码是更好的选择因为它在短期内有效即使泄露影响也可控。我虽然个人用得少但如果你在写构建脚本建议优先考虑它。6.3 时间点差异2021版的界面和现在的变化这篇文章完全按2021年阿里云容器镜像服务的操作路径来写所以如果你现在打开控制台发现入口名字、按钮位置甚至免费策略都不太一样完全正常。这类云服务改版频率不低个人版和企业版的区分也比2021年更明显。但不管界面怎么变化核心逻辑没有变先开实例再建命名空间再建仓库然后用 Registry 地址在命令行登录推拉。你只要找到页面上的“命名空间”和“镜像仓库”这两个入口顺着走就不会迷路。6.4 其他一些小经验私有仓库不等于保险箱镜像里如果有数据库密码、API 密钥照样会被拿到镜像的人看到所以敏感信息一定要通过环境变量或密钥管理工具注入不要直接写进镜像。摘要和描述字段也建议认真填时间久了镜像一多光靠名字根本分不清哪个是哪个而描述能帮你在控制台里快速定位。关于地域我再强调一次服务器在北京就优先创建北京地域的仓库服务器在杭州就选杭州。跨地域虽然能用但每次拉镜像的网络延迟都会让你体会到什么叫地域差异。最后分享一个小判断方法阿里云控制台的地址通常是cr.console.aliyun.com开头这是网页端而命令行里要用的永远是registry.开头加上地域后缀的地址比如registry.cn-hangzhou.aliyuncs.com。只要看到这两个开头你就能马上分清自己是在网页上操作还是在命令行操作。当初我经常看到有人把网页地址填进 docker tag 里然后百思不得其解为什么找不到镜像其实就是这么一点小区别。
2021年那会儿我正跟着教程补Docker的功课学到容器编排之前卡在了一个很实际的问题上自己构建好的镜像除了躺在本地怎么才能方便地放到服务器上用。官方镜像仓库虽然免费但当时在国内访问的速度很不稳定拉一个镜像经常等到怀疑人生。我把目光转向了阿里云容器镜像服务也就是常说的阿里云镜像仓库结果发现个人版在当年是免费开放的注册完账号就能创建命名空间和镜像仓库然后用 docker login、docker tag、docker push 这一套命令把本地镜像推上去最后在任何一台服务器上 docker pull 拉下来直接用。整个过程不复杂但对刚开始用 Docker 的人来说入口藏得有点深。这篇笔记基于2021年阿里云控制台的界面和操作路径完整记录我当时的创建与使用过程包括命名空间和仓库的创建、命令行推送、常见报错排查以及在服务器上拉取镜像的细节。如果你现在看到的控制台界面和当年略有差异也不用慌核心逻辑是一样的先有命名空间再有仓库然后用 Registry 地址登录、打标签、推拉镜像。适合还没用过私有镜像仓库的人参考。1. 为什么要把自己的镜像放到阿里云镜像仓库里1.1 没有镜像仓库时的部署尴尬新手阶段最容易做的事情是把构建好的镜像用 docker save 导出成 tar 包再传到服务器上 docker load。小镜像还好说一旦镜像里带上了完整的运行环境体积轻松超过几百MB传一次就够难受了更别提系统里有三台服务器需要保持同一个版本。每次更新都手动传文件迟早会漏一台。另一种做法是在服务器上重新构建。听起来很干净但服务器上得准备好全部源代码、依赖、构建缓存甚至还要解决不同服务器之间构建环境不一致导致的“本地能跑、服务器上跑不了”问题。这个坑我踩过之后才明白镜像的意义在于把环境和代码一起打包而不是让每台机器重复造一遍轮子。所以一个绕不开的需求就出现了我需要一个所有服务器都能访问的镜像仓库把镜像存进去再让各台机器拉取。这就像代码要推到代码仓库再分发一样镜像也需要一个“中央仓库”。没有它容器化部署根本跑不起来。1.2 公开仓库与自建仓库的取舍公开的官方镜像仓库确实能存镜像但私有仓库要收费而我不想把内部项目直接暴露在公开仓库里。更麻烦的是网络因素在国内访问官方仓库经常超时一个不常拉的基础镜像可能要重试好几次。自己搭一个 Registry 或者 Harbor 也不是不行但意味着我要维护一台专门跑镜像服务的机器处理 HTTPS 证书、认证、存储扩容和备份。对一个学习 Docker 的个人用户来说这个投入明显不划算。当时我看了一圈阿里云容器镜像服务的个人版是最省心的不用自己搭登录控制台创建仓库就能用还提供了标准的 Registry 推拉地址和本地 Docker 命令完全兼容。对个人用户来说基本没有运维负担。1.3 个人版实际体验怎么样2021年这段时间我用下来的感受是在国内地域推拉镜像速度尚可日常学习和小项目完全够用支持创建多个命名空间每个命名空间下面再放不同项目的镜像结构上不会乱仓库也支持设置公开或私有私有仓库需要登录才能拉取安全性有基本保障。虽然是免费的个人版但对我当时的用途来说已经绰绰有余。后来我在某台服务器上连着拉过好几次镜像都没有遇到什么大问题。2. 控制台里创建命名空间和镜像仓库的完整流程2.1 登录容器镜像服务控制台并选择地域第一步是登录阿里云容器镜像服务控制台。2021年时的入口路径大概是控制台首页里面搜索“容器镜像服务”点击进去会看到“个人实例”或“默认实例”这一类的东西。第一次使用的时候会要求设置 Registry 登录密码这个密码是给 docker 命令行登录用的和后文的 docker login 直接相关。地域选择上我当时选了华东1杭州对应的 Registry 地址是registry.cn-hangzhou.aliyuncs.com后面所有 docker tag 和 docker push 里的地址都会用到它。我建议选一台离你服务器最近的地域比如服务器在华北就选北京在华南就选深圳尽量减少镜像传输的物理距离。跨地域拉镜像不是不能用只是速度会慢一些这一点后面还会再提。2.2 创建命名空间给镜像仓库分好目录创建镜像仓库之前必须先创建命名空间。控制台左侧菜单能找到“命名空间”点进去之后有个“创建命名空间”的按钮。名字我那时候用的是小写字母加中划线比如myns、my-project这类。限定规则我记得是以字母开头只支持小写字母、数字和中划线所以驼峰和大写都是不行的起名的时候直接按这个规则来就行。当时我犯了一个小错误把命名空间起得过于具体比如hello-demo-namespace后来想放别的项目镜像时后悔了因为命名空间创建之后不能改名。正确的做法是命名空间按“归属”或“环境”来分比如personal、company-test不要按单个项目来分。单个项目对应的层级应该是“仓库”每个命名空间下面可以挂很多仓库。2.3 创建镜像仓库从本地仓库类型开始进入“镜像仓库”页面点击“创建镜像仓库”。步骤大概是选择地域注意要和刚才的命名空间在同一个地域下选择命名空间比如personal填写仓库名称比如blog-backend这个会出现在最终镜像地址里选择仓库类型公开或私有。存放内部配置或专属业务代码的镜像建议选私有填写摘要和描述简单说明这个镜像的用途代码源选择2021年的控制台里可以选择“本地仓库”或绑定代码托管平台。我当时选了“本地仓库”。原因很直接我只想手动推镜像不想让平台在我每次提交代码之后自动构建。自动构建这个功能确实存在把代码托管平台授权给阿里云之后仓库会监听代码提交事件自动在后台构建镜像并推送。这个流程适合有持续集成习惯的人但对学习阶段的我来说手动 push 能让我更清楚地看到每一步发生了什么。创建完成之后控制台会跳转到仓库详情页页面下方通常会给出一段操作指南里面有完整的登录、打标签、推送命令。我后来就是用这段命令对照着跑的。3. 推送前必须搞懂的三个概念登录、打标签、仓库地址3.1 在命令行里登录自家仓库控制台给的登录命令长这样docker login --username你的用户名 registry.cn-hangzhou.aliyuncs.com第一次执行会提示输入密码这里输入的密码不是阿里云账号密码而是我们在容器镜像服务控制台里设置的 Registry 登录密码。如果当时没设置可以去控制台“访问凭证”那一栏设置固定密码也可以生成临时密码。临时密码有有效期限制适合临时用但日常建议用固定密码加高复杂度。我看到过不少人在这里卡住明明阿里云账号密码是对的docker login 却报错就是因为搞混了“登录控制台的密码”和“Registry 登录密码”两套凭证。另外需要注意docker login 成功后凭证会保存在~/.docker/config.json文件里以后在同一台机器上再推拉镜像就不需要重复登录了。3.2 docker tag给镜像补上完整的仓库地址Docker 的设计里镜像名称本身就是一个“地址”。本地镜像一般叫blog-backend:latest但要推到阿里云仓库必须把它变成完整的地址格式。docker tag 就是干这个的docker tag blog-backend:latest registry.cn-hangzhou.aliyuncs.com/personal/blog-backend:v1.0可能有人会问为什么不能直接对本地镜像执行 docker push 并指定目标地址非要先 tag 一下因为 docker push 推送的对象是“带完整地址的镜像名”而本地构建出来的镜像是没有归属地址的相当于一份“原件”。tag 相当于给它贴上一张写满收件地址的快递单快递员才知道往哪儿送。而且 tag 并不会复制镜像内容只是多了一个引用名称所以不用担心磁盘空间加倍。3.3 仓库地址结构拆解这段地址看着长实际上结构很清晰拆开就懂了地址片段含义示例registry.cn-hangzhou.aliyuncs.com容器镜像服务的地域入口域名华东1杭州入口personal命名空间相当于一级目录个人项目组blog-backend仓库名相当于二级目录博客后端镜像v1.0版本标签具体版本号如果 tag 后面不写版本号默认是latest。我建议不要在生产环境里裸用 latest因为 latest 会被新的推送覆盖时间一长你根本不知道服务器上跑的是哪一天的代码。我自己的习惯是至少写成blog-backend:20210612这种带日期的版本或者 v1.0、v1.1 这种语义化版本再配合一个 latest 用来指向当前最新。4. 从构建到推送一次完整的推镜像实操4.1 推送的完整命令序列假设你已经有一个本地镜像叫blog-backend:latest现在要推到阿里云仓库。完整流程是这样# 1. 登录输入Registry密码 docker login --username你的用户名 registry.cn-hangzhou.aliyuncs.com # 2. 给镜像打上完整地址标签 docker tag blog-backend:latest registry.cn-hangzhou.aliyuncs.com/personal/blog-backend:v1.0 # 3. 推送 docker push registry.cn-hangzhou.aliyuncs.com/personal/blog-backend:v1.0推送成功的回显大概是这样的The push refers to repository [registry.cn-hangzhou.aliyuncs.com/personal/blog-backend] ... latest: digest: sha256:7b3b4a... size: 2438看到 digest 那一行就说明镜像已经上传成功了。回到控制台刷新仓库详情页镜像版本列表里就会多出 v1.0 这个标签。这里有一个很多人一开始会漏掉的细节镜像推送是分层推送的Docker 会先检查哪些层在仓库里已经存在只上传不存在的层。所以如果这次只改了几行代码可能只需要传几十MB甚至更少第二次之后的推送速度会明显比第一次快很多。4.2 碰到的坑denied、unauthorized和连接超时我总结几个当时实际遇到过的报错以及对应的处理方式。Error response from daemon: denied: requested access to the resource is denied这个报错最磨人原因通常是没登录或者登录的账号对这个仓库没有权限。处理思路是先检查镜像地址里的命名空间和仓库名是否和当前账号匹配确认无误后再登录一次。私有仓库尤其容易出现这个报错如果一直是匿名拉取就会被 denied 拦截。Error response from daemon: unauthorized: authentication required这个和上面有点像本质是登录凭证没通过。常见原因有三个密码输错、访问凭证过期、或者 docker login 之后又切换过阿里云账号。我当时的解决方式是到控制台重新生成一次临时密码再执行一遍 docker login问题就解决了。Error response from daemon: Get https://registry.cn-hangzhou.aliyuncs.com/v2/: net/http: request canceled ...这种是网络层面的连接问题尤其在服务器网络波动的时候容易出现。处理方法一般是检查服务器能否正常访问外网多试几次或者换个网络环境再推。注意不要一股脑重试很多次我看到有人失败一次就登出再登录反而会把正常的凭证弄乱不如先稳定网络再继续。还有个错误不常遇到但我也见过就是 tag 写错了之后 docker push 提示No such image: ...说明本地根本没这个标签。这时候检查一下 docker images很可能镜像名打错了或者忘了先 tag。这类问题不属于网络和权限往往是手滑冷静下来看一遍命令就能发现。4.3 推送成功之后怎么验证推送完不能只看控制台列表就放心。我自己习惯在本地把刚推的镜像删掉然后重新从仓库拉一遍确认仓库里的文件真的完整可用docker rmi registry.cn-hangzhou.aliyuncs.com/personal/blog-backend:v1.0 docker pull registry.cn-hangzhou.aliyuncs.com/personal/blog-backend:v1.0如果 pull 回来之后的镜像能正常 run那就说明整条链路是通的。这一步看着有点多余但确实帮我发现过一次推送成功后仓库内容异常的情况多半是上传中断导致的重新 push 一次就好了。5. 在另一台服务器上拉取镜像并和docker-compose配合使用5.1 换台服务器登录并拉取部署的时候进入另一台安装好 Docker 的服务器同样先登录docker login --username你的用户名 registry.cn-hangzhou.aliyuncs.com docker pull registry.cn-hangzhou.aliyuncs.com/personal/blog-backend:v1.0如果仓库是公开类型拉取不需要登录如果是私有仓库就必须登录并且账号需要有权限。当时我的服务器上都配置好了 Docker 环境直接执行 pull 就行整个拉取时间取决于镜像大小和网络状况几百MB的镜像在国内地域基本可以接受。拉取下来之后docker run 就能用了docker run -d -p 8000:8000 --name blog-backend registry.cn-hangzhou.aliyuncs.com/personal/blog-backend:v1.0这时你可能会意识到有了镜像仓库之后整个部署过程真的变成了一条命令登录、拉取、运行三步走。之前那套传 tar 包、手动解压再 load 的流程彻底可以退休了。5.2 docker-compose里直接引用私有仓库镜像如果你用 docker-compose 管理服务image 字段直接写完整镜像地址就行services: backend: image: registry.cn-hangzhou.aliyuncs.com/personal/blog-backend:v1.0 ports: - 8000:8000但有一个前提容易忽略使用 docker-compose up 之前这台机器需要先执行过 docker login否则 compose 在拉取私有镜像时会报 unauthorized 或者 denied。这个登录凭证是跟随 Docker 守护进程的compose 并不会帮你额外处理登录。5.3 连基础镜像也搬到自家仓库还有个实用的技巧如果你在服务器上构建镜像Dockerfile 里的 FROM 可能还在指向官方仓库的基础镜像而基础镜像拉取慢的问题依然存在。我的做法是把常用基础镜像先拉到本地再推送到阿里云仓库之后把 Dockerfile 里的 FROM 改成阿里云仓库地址# 原来是 FROM node:14 FROM registry.cn-hangzhou.aliyuncs.com/personal/node-base:14这样可以很大程度上避免在构建过程中反复等待基础镜像下载。这个方法不算复杂但对于经常在服务器上构建的人来说体验提升非常明显。6. 用了大半年之后总结的几个操作习惯和教训6.1 命名空间和仓库名一定要一次想好前面提过命名空间创建后不能改名这一点我体验很深。仓库名虽然可以在控制台删除重建但删除重建意味着镜像要重新推一遍版本历史也没了。所以起名之前多花两分钟想清楚这个仓库长期装什么、谁在用比事后折腾省事得多。我的习惯是命名空间按环境分dev、prod、personal仓库名按服务分blog-backend、api-server、web-fronttag 按版本或日期分v1.0、20210612。这样三层层级下来任何人看到完整地址就能猜出镜像归属团队协作的时候很省沟通成本。6.2 关于密码、凭证和泄露风险Registry 固定密码如果设置得太简单等于把整个私有仓库敞开给别人。我后来给自己定了一个原则密码必须是高强度随机串并且和阿里云控制台登录密码完全不同。另外~/.docker/config.json里保存的是登录凭证的 base64 格式如果服务器被其他人读取就等于拿到了仓库的访问权。所以我通常会把存放敏感文件目录的权限收好不给无关人员开放服务器账号。对于需要自动化推送的场景临时密码是更好的选择因为它在短期内有效即使泄露影响也可控。我虽然个人用得少但如果你在写构建脚本建议优先考虑它。6.3 时间点差异2021版的界面和现在的变化这篇文章完全按2021年阿里云容器镜像服务的操作路径来写所以如果你现在打开控制台发现入口名字、按钮位置甚至免费策略都不太一样完全正常。这类云服务改版频率不低个人版和企业版的区分也比2021年更明显。但不管界面怎么变化核心逻辑没有变先开实例再建命名空间再建仓库然后用 Registry 地址在命令行登录推拉。你只要找到页面上的“命名空间”和“镜像仓库”这两个入口顺着走就不会迷路。6.4 其他一些小经验私有仓库不等于保险箱镜像里如果有数据库密码、API 密钥照样会被拿到镜像的人看到所以敏感信息一定要通过环境变量或密钥管理工具注入不要直接写进镜像。摘要和描述字段也建议认真填时间久了镜像一多光靠名字根本分不清哪个是哪个而描述能帮你在控制台里快速定位。关于地域我再强调一次服务器在北京就优先创建北京地域的仓库服务器在杭州就选杭州。跨地域虽然能用但每次拉镜像的网络延迟都会让你体会到什么叫地域差异。最后分享一个小判断方法阿里云控制台的地址通常是cr.console.aliyun.com开头这是网页端而命令行里要用的永远是registry.开头加上地域后缀的地址比如registry.cn-hangzhou.aliyuncs.com。只要看到这两个开头你就能马上分清自己是在网页上操作还是在命令行操作。当初我经常看到有人把网页地址填进 docker tag 里然后百思不得其解为什么找不到镜像其实就是这么一点小区别。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
