差别

这里会显示出您选择的修订版和当前版本之间的差别。

--- docker:registrymirror [2025/12/24 17:33] – [配置存储配额（高级）] admin
+++ docker:registrymirror [2025/12/25 13:46] (当前版本) – [存储缓存镜像迁移] admin
@@ 行 223: / 行 223: @@
 delete.enabled	必须设为 true，否则配额限制和垃圾回收命令都无法删除旧镜像（核心）	true
+**四、配置生效步骤**
+重启 Registry 服务：
+```
+cd /opt/docker-registry
+docker-compose down && docker-compose up -d
+```
+**五、配额 + 垃圾回收的最佳实践**
+存储配额只是 “上限限制”，结合定时垃圾回收才能更灵活地管理空间：
+、手动执行垃圾回收（清理未被引用的镜像）：
+```
+# 清理悬空镜像（不影响正在使用的镜像）
+docker exec docker-registry-mirror registry garbage-collect /etc/docker/registry/config.yml
+```
+、配置定时任务（每天凌晨 2 点自动清理）：
+```
+# 编辑 crontab 定时任务
+crontab -e
+```
+添加以下内容：
+```
+# 每天凌晨 2 点执行垃圾回收
+2 * * * docker exec docker-registry-mirror registry garbage-collect /etc/docker/registry/config.yml > /var/log/registry-gc.log 2>&1
+```
+**注意事项**
+maxsize 的值需根据服务器磁盘实际可用空间设置（建议预留 20% 余量）；
+配额生效后，若空间已满，需先执行垃圾回收释放空间，才能继续缓存新镜像；
+该配额仅限制 Registry 自身缓存的镜像，不会影响服务器上的其他 Docker 容器 / 镜像。
+**总结**
+配置存储配额的核心是在 storage.filesystem 下添加 maxsize（总空间）和 maxblobsize（单镜像大小），且必须开启 delete.enabled: true；
+配额仅为 “上限限制”，需结合垃圾回收命令 / 定时任务，才能主动释放过期缓存空间；
+配置后需重启 Registry 服务，配额才能生效。
+===== 存储缓存镜像迁移 =====
+Docker 镜像加速器的 data 目录（存储缓存镜像的目录）能否复制给其他镜像加速器服务器使用 —— 答案是完全可以，但需要遵循特定的规则和步骤，确保复制后的数据能被新的 Registry 实例正常识别和使用。
+**核心原理**
+./data 目录是 Registry 容器的 /var/lib/registry 挂载目录，里面存储了：
+  * 普通列表项目镜像的分层数据（blobs）；
+  * 普通列表项目镜像的元数据（manifests）；
+  * 普通列表项目Registry 的存储索引（registry.db）。
+这些数据是平台无关、可移植的（只要 Registry 版本一致），复制后新的加速器服务器可直接复用已有缓存，无需重新从 Docker Hub 拉取镜像。
+**查看缓存大小**
+```
+du -sh /opt/docker-registry/data
+```
+**复制 / 迁移的前提条件**
+、**Registry 版本一致**：新服务器的 Registry 镜像必须和原服务器一致（推荐用 registry:2 固定版本，避免 latest 导致版本差异）；
+、**权限一致**：复制后的目录权限需与 Registry 容器的运行用户（默认 root 或 1000:1000）匹配；
+、**停止原服务再复制**：避免复制过程中数据写入导致文件损坏（核心！）。
+**完整的复制 / 迁移步骤**
+、**停止原 Registry 服务（关键）**
+```
+# 进入原加速器服务器的配置目录
+cd /opt/docker-registry
+# 停止容器（避免数据写入）
+docker-compose down
+```
+、**打包 data 目录**
+```
+# 打包data目录（保留权限和目录结构）
+tar -zcvf registry-data.tar.gz ./data
+```
+、**传输打包文件到新服务器**
+用 scp 或 rsync 传输（假设新服务器 IP 为 192.168.1.100）：
+```
+scp registry-data.tar.gz root@192.168.1.100:/opt/docker-registry/
+```
+、**新服务器准备环境**
+确保新服务器已创建相同的目录结构（和原服务器的 docker-compose.yml 配置一致）：
+```
+# 新服务器创建目录
+mkdir -p /opt/docker-registry/{conf,data}
+# 解压数据（保留权限）
+cd /opt/docker-registry
+tar -zxvf registry-data.tar.gz
+# 修复目录权限（关键！Registry 容器需读写权限）
+chown -R 1000:1000 ./data  # 或 chmod -R 755 ./data（简单通用）
+```
+、**新服务器启动 Registry**
+确保新服务器的 docker-compose.yml 和 conf/config.yml 与原服务器完全一致，然后启动：
+```
+docker-compose up -d
+# 检查容器状态
+docker-compose ps
+```
+、**验证迁移效果**
+在新服务器的客户端拉取一个原缓存过的镜像（如 nginx:alpine），会发现拉取速度极快（直接读取本地缓存）：
+```
+docker pull nginx:alpine
+```
+**注意事项（避坑关键）**
+、**禁止在线复制**：如果不停止原 Registry 就复制 data 目录，可能导致镜像分层文件（blobs）不完整，新服务器启动后出现「镜像拉取失败」「manifest 不存在」等错误；
+、**版本兼容**：
+  * 普通列表项目低版本 Registry（如 2.7）的数据可迁移到高版本（如 2.8+），但高版本数据不能回退到低版本；
+  * 普通列表项目建议所有服务器统一使用 registry:2（固定大版本），避免版本兼容问题；
+、**路径一致性**：
+新服务器的 docker-compose.yml 中，./data 必须挂载到容器的 /var/lib/registry（和原服务器一致），否则 Registry 找不到缓存数据；
+、**清理无效数据**：如果迁移后发现部分镜像无法访问，可执行垃圾回收清理无效数据：
+```
+docker exec docker-registry-mirror registry garbage-collect /etc/docker/registry/config.yml
+```
+**总结**
+、data 目录（缓存镜像的目录）可以复制给其他镜像加速器使用，核心是保证 Registry 版本一致、停止服务后复制、修复目录权限；
+、迁移后新加速器可直接复用已有缓存，无需重新拉取镜像，大幅节省带宽和时间；
+、关键步骤：停止原服务 → 打包数据 → 传输 → 解压并修复权限 → 启动新服务。