容器化落地避坑：从镜像源、构建缓存到清理策略的实战记录

背景

最近在一台 Huawei Cloud EulerOS 2.0 的云服务器上从零部署 Docker，并把一个内部服务容器化。整个过程踩了几个很典型的坑，记录一下，给同样在国产化环境里落地的同学省点时间。

坑一：默认镜像源拉不动

装完 docker-engine 后执行 docker pull hello-world，直接超时：

Error response from daemon: Get "https://registry-1.docker.io/v2/":
net/http: request canceled while waiting for connection
(Client.Timeout exceeded while awaiting headers)

国内环境访问 Docker Hub 基本不可用，需要配镜像加速。编辑 /etc/docker/daemon.json：

{
  "registry-mirrors": [
    "https://swr.cn-north-4.myhuaweicloud.com",
    "https://docker.m.daocloud.io"
  ]
}

然后重载配置：

systemctl daemon-reload
systemctl restart docker
docker info | grep -A3 'Registry Mirrors'

配完之后 hello-world 和 busybox 都能正常拉取。需要注意 SWR 镜像站对部分公共镜像返回 404，实际生效的是第二个源，所以建议至少配两个镜像源做兜底。

坑二：构建上下文过大导致构建变慢

第一次 docker build 时把整个项目目录当上下文发给了 daemon，包含 node_modules 和日志目录，上下文接近 800MB，构建卡了几分钟。

解决方式是加 .dockerignore：

node_modules
.git
*.log
dist
coverage
.DS_Store
*.tar.gz

加上之后上下文降到 2MB 左右，构建时间从几分钟降到十几秒。这个文件建议在项目初始化时就建好，而不是等构建慢了才回头补。

坑三：镜像和容器堆积无人清理

反复构建和调试几天后，docker images 列出了几十个 dangling 镜像，磁盘占用涨到几十 GB。常用清理命令：

# 删除所有悬空镜像
docker image prune -f

# 删除已停止的容器
docker container prune -f

# 清理未被使用的网络
docker network prune -f

# 一次性清理镜像、容器、网络、构建缓存（慎用）
docker system prune -a -f

# 查看当前占用
docker system df -v

建议把 docker system df 加进日常巡检，或者在 CI 里每周跑一次 docker image prune -f。

一个可复用的 Dockerfile 骨架

FROM eclipse-temurin:17-jre-alpine

WORKDIR /app

# 先拷依赖描述文件，利用层缓存
COPY pom.xml .
RUN mvn dependency:go-offline -B || true

# 再拷源码构建
COPY src ./src
RUN mvn package -DskipTests -B

ENV TZ=Asia/Shanghai
EXPOSE 8080
ENTRYPOINT ["java","-jar","/app/target/app.jar"]

关键点是"先拷依赖描述、再拷源码"，这样只要 pom.xml 没变，依赖下载这一层就能命中缓存，改业务代码不会重复下载依赖。

容器运维常用命令速查

# 后台运行并挂载配置
docker run -d --name svc   -p 8080:8080   -v /opt/svc/conf:/app/conf:ro   --restart unless-stopped   my-service:v1

# 查看日志（跟随，最近 200 行）
docker logs -f --tail 200 svc

# 进入容器排查
docker exec -it svc /bin/sh

# 查看资源占用
docker stats --no-stream

# 导出/导入镜像（离线环境迁移）
docker save my-service:v1 | gzip > svc-v1.tar.gz
docker load < svc-v1.tar.gz

小结

在国产化环境里用 Docker，技术本身不是难点，难的是网络环境和运维习惯。镜像源要配兜底、构建上下文要瘦身、镜像要定期清理，这三件事做好，容器化落地基本就顺了。