GitLab Registry是否压缩容器镜像？如何控制GitLab中镜像的压缩？

先说说为啥GitLab容器注册表显示的大小，和你本地用docker images看到的不一样：
GitLab存的是压缩后的镜像层总大小，而docker images展示的是镜像解压后在本地磁盘占的空间——不仅是所有层的未压缩大小，还可能因为本地共享层的存在重复计算。这就是数值差的核心原因。

GitLab文档里那句“镜像层以原始（通常为压缩）格式存储在存储后端”，翻译过来就是：Docker镜像推送时本来就会用压缩格式（默认gzip）传输，GitLab直接存推送过来的压缩文件，所以注册表显示的是压缩后的大小；你拉取到本地后，Docker会自动把层解压出来存在本地，所以docker images的数值更大。

怎么控制GitLab里的镜像压缩？ #

1. 构建阶段就搞定（最关键） #

GitLab本身不会额外压缩镜像，它存的就是你推送过去的压缩文件。所以要控制压缩，得在构建镜像的时候让Docker用你想要的压缩方式：

• 用docker build的--compress参数强制压缩层，推送时保持压缩状态，GitLab CI脚本里这么写：

  build:
    script:
      - docker build --compress -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
      - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
  

• Docker 23.0以上版本支持zstd算法（比gzip压缩率更高、速度更快），可以指定算法：

  build:
    script:
      - docker build --compress --compression-algorithm zstd -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
      - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
  

  注意：得确保你的GitLab Runner用的Docker版本支持这个参数。

2. 自托管GitLab的存储端配置 #

如果你用的是自己部署的GitLab实例，还能从存储后端入手：

• GitLab默认直接存储Docker推送的压缩层，不会再二次压缩或解压。推送的是gzip就存gzip，是zstd就存zstd。
• 如果用了对象存储（比如MinIO、S3），可以在存储层面开自动压缩，但这属于存储服务的配置，和GitLab本身无关，得保证镜像层不会被改坏。

3. 清掉冗余镜像层 #

就算压缩了，没用的镜像层也会占空间，定期清理很有必要：

• 在项目的设置 > 仓库 > 容器注册表里设清理规则，比如删掉旧标签、没人用的镜像，减少总存储量。
• 在GitLab Runner上用docker system prune清理本地冗余镜像，避免构建时产生不必要的层。

总结 #

大小差异是正常的，一个是压缩后存储的大小，一个是解压后本地占的空间。要控制压缩，核心是构建时通过Docker参数指定压缩方式，自托管的可以配合存储端优化，再加定期清理冗余镜像，就能有效减小存储占用。

内容的提问来源于stack exchange，提问作者Admineral