3.5 自建私有堆场：Registry 搭建

本节摘要：主线任务的收官站——用官方 registry 镜像十分钟搭起内网专属堆场，完成 push 与 pull 的闭环，并讲清访问控制与证书这两个生产级问题。从此你的业务镜像有了一个不依赖外网的家。

为什么不把业务货放进公共堆场

装箱造出来的货总要有个家。选择只有两个：公共堆场或自建堆场。业务镜像放公共堆场有三个过不去的坎：密钥与业务数据风险（镜像层里可能的配置残留）、网络依赖（发布时堆场不可达，整条流水线趴窝）、带宽与配额（内网机器互相拉货却要绕公网）。企业环境的标准答案是自建私有堆场——本质上就是一套存镜像、发镜像的仓库服务，Docker 官方提供的发行版叫 Registry。

与"直接在服务器上开个共享目录"的本质区别要说清：Registry 是内容寻址的仓库——每层按哈希存储、按摘要校验，天然防篡改；配合分层的增量传输，同一团队推拉镜像的开销极低。自己用文件系统拼凑的"镜像库"不具备这些性质。

上手版：十分钟起一座堆场

堆场本身也是一只集装箱——官方把 Registry 打成了镜像。起吊它：


# 起一座内网堆场：数据落在容器内（先跑通，数据盘挂载见下一步）
docker run -d -p 5000:5000 --name local-registry --restart always registry:2
# Unable to find image 'registry:2' locally ...（首次自动提货）
# 输出容器编号即启动成功

# 验证堆场在线：访问它的健康检查接口
curl -s http://localhost:5000/v2/
# 输出：{}   <- 空对象是正常的，表示仓库服务可用

把你的第一个镜像推上去：


# 打上指向本地堆场的完整名称（堆场地址:端口/命名空间/货名:标签）
docker tag myapp:0.1 localhost:5000/team-a/myapp:0.1

# 推送
docker push localhost:5000/team-a/myapp:0.1
# The push refers to repository [localhost:5000/team-a/myapp]
# 8e5f2a1c3d7b: Pushed
# 0.1: digest: sha256:7d1f2a... size: 1570

# 从堆场查询库存（列出该命名空间下的全部镜像）
curl -s http://localhost:5000/v2/_catalog
# 输出：{"repositories":["team-a/myapp"]}

# 删掉本地镜像，再从自己的堆场原样提回——闭环验证
docker rmi localhost:5000/team-a/myapp:0.1
docker pull localhost:5000/team-a/myapp:0.1
# 0.1: Pulling from team-a/myapp ... Status: Downloaded newer image

看到最后一行 Downloaded，闭环完成：你推上去的货，任何能连到这座堆场的机器都能原样提走。

转正版：数据落盘与访问控制

刚才的版本有两个生产级缺陷：数据在容器可写层里（堆场一拆，货全没了——3.1 节讲过的铁律），以及谁都能推拉（没有门禁）。转正版把两件事补上。

数据落盘：把堆场数据目录挂载到宿主机卷（挂载机制第 5 章系统讲，此处照做即可）：


# 转正版起吊：数据卷 + 基本认证两件一起配
docker run -d -p 5000:5000 --restart always --name corp-registry \
  -v registry-data:/var/lib/registry \
  -e REGISTRY_STORAGE_DELETE_ENABLED=true \
  registry:2
# -v registry-data:/var/lib/registry：堆场库存落进名为 registry-data 的卷

访问控制：Registry 原生支持 HTTP 基本认证。先用工具生成一张密码档案，再把它挂进堆场：


# 生成认证档案（htpasswd 格式）：为用户 pusher 设置密码
docker run --entrypoint htpasswd httpd:2.4-alpine -Bbn pusher s3cret! \
  > /etc/registry/htpasswd

# 带认证重新起吊堆场
docker run -d -p 5000:5000 --restart always --name corp-registry \
  -v registry-data:/var/lib/registry \
  -v /etc/registry/htpasswd:/auth/htpasswd \
  -e REGISTRY_AUTH=htpasswd \
  -e REGISTRY_AUTH_HTPASSWD_REALM=Registry-Realm \
  -e REGISTRY_AUTH_HTPASSWD_PATH=/auth/htpasswd \
  registry:2

之后客户端必须先登录才能推拉：


# 客户端登录堆场（输入密码后凭证被记住）
docker login localhost:5000
# Username: pusher
# Password:
# Login Succeeded

# 未登录直接推送会被拒绝（错误示例）
# denied: requested access to the resource is denied

关于 TLS 的实话：Registry 默认只接受 HTTPS，上面的 localhost 示例能用是因为引擎对本地回环有豁免。内网其他机器要用 HTTP 直连，需要在各客户端的引擎配置里把这座堆场地址加进"不安全注册表"白名单（insecure-registries）——这只推荐给纯内网测试环境；正式环境应当配证书走 HTTPS，把白名单从根上免掉。

堆场的日常运营

运营一座堆场，三件事要形成制度。版本纪律：同一货名用不可变版本标签（1.4.2）而非漂移标签（latest），配合 3.2 节的摘要引用，让任何一次部署都可复现。空间治理：堆场会随构建次数无限膨胀，定期清理旧版本层；企业场景推荐配自动化策略（如保留每货最近若干版）。备份：数据卷挂载的存储目录纳入常规备份体系——堆场丢了不可怕，库存没了才可怕。


# 库存对账与清理（运维视角）
curl -s http://localhost:5000/v2/_catalog | head -c 300
# {"repositories":["team-a/myapp","team-b/billing","infra/base-image"]}

# 堆场磁盘占用一目了然（数据卷的真实物理位置可由 volume inspect 查到，第 5 章详解）
docker system df
# TYPE            TOTAL     ACTIVE    SIZE
# Images          42        12        9.31GB

至此主线任务全部完成：分层原理、货单规则、装箱单、瘦身、专属堆场——你已具备独立交付镜像的完整能力。下一章把箱子吊上船。

本节要点回顾

业务镜像不进公共堆场：密钥风险、网络依赖、带宽配额三道坎，企业标准答案是自建 Registry。
Registry 是内容寻址仓库：按哈希存层、按摘要校验，配合分层增量传输。
上手版十分钟可用：起容器、推镜像、查库存、提回验证四步闭环。
转正版两件套：数据卷落盘（防拆箱丢货）+ htpasswd 认证（防无门禁推拉）；正式环境必须 TLS。
运营三制度：不可变版本标签、定期清理旧层、数据卷纳入备份。

装箱车间毕业。下一章起吊作业——让箱子真正跑起来，并学会监控它的每一次呼吸。

作者与出处

原作者：灏天文库

来源：灏天文库

整理：灏天文库整理

由灏天文库平台收录，内容或由平台用户上传，仅供学习交流