Docker 容器时间不对？三种方案修复时区偏差

最近在部署定时任务时，遇到了一个让人头秃的问题：任务总是比预期晚了8小时执行，查看日志时，时间也对不上。一开始怀疑是 cron 表达式写错了，反反复复改了半天也没解决问题。最后实在没辙，用 docker exec 进入容器敲了个 date 命令，结果当场裂开——容器时间显示的是 UTC，而宿主机却是 CST（中国标准时间）。折腾了半个多小时，终于找到了原因，原来罪魁祸首是容器时区没配置对。

为了防止大家踩同一个坑，我把排查和解决过程整理了一下，顺便分享三种修复方案，看看哪种最适合你。

容器默认使用 UTC 时间（左），而国内应用通常需要 CST 时间（右）。

原因分析

Docker 容器默认使用 UTC 时间，而我们的服务器和应用通常期望的是本地时间（比如 CST）。如果容器没有配置为正确的时区，即使宿主机时间是正确的，容器内部的时间也会偏差。这会导致定时任务、日志记录等功能出现时间错误。比如 cron 任务可能会在错误的时间触发，或者日志显示的时间让你摸不着头脑。

方案一：挂载宿主机时区文件（推荐）

这是最干净、最直接的方法，直接把宿主机的时区文件挂载到容器里，容器时间会自动和宿主机保持一致。在 docker-compose.yml 中添加以下配置：

在 docker-compose.yml 中挂载宿主机时区文件。

volumes:
  - /etc/localtime:/etc/localtime:ro
  - /etc/timezone:/etc/timezone:ro

这里挂载了两个文件：

• /etc/localtime：用于从系统读取时区信息。
• /etc/timezone：用于明确指定时区名称，避免某些应用（如 cron）误判。

优点：

• 简单直接，不用修改镜像或容器内部配置。
• 宿主机时区变更后，容器会自动同步。
• 适合大多数场景，尤其是临时或频繁调整时区的情况。

注意：

• 确保宿主机时区配置正确。
• 挂载模式设为 ro（只读），安全性稍好一些。

方案二：设置环境变量 TZ

第二种方法是通过环境变量指定时区。在容器的环境变量中添加 TZ=Asia/Shanghai（或其他时区），前提是镜像中已经安装了 tzdata 包。如果没有安装，这个环境变量可能不会生效。

例如在 docker-compose.yml 中配置：

environment:
  - TZ=Asia/Shanghai

优点：

• 配置简单，适合用环境变量管理的场景。
• 不需要挂载文件。

缺点：

• 依赖镜像安装 tzdata，某些精简镜像可能不支持。
• 可能需要重启容器才能生效。

方案三：在 Dockerfile 中修改时区

如果你是从源代码构建镜像，可以在 Dockerfile 中直接修改时区。这样生成的镜像会直接包含正确的时区配置，不需要额外挂载或设置环境变量。

在 Dockerfile 中添加以下命令：

RUN ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime

优点：

• 镜像自带时区配置，部署时无需额外配置。
• 适合定制化镜像，确保一致性。

缺点：

• 每次修改时区都需要重新构建镜像。
• 不适合频繁调整时区的情况。

最佳实践建议

综合比较下来，我更倾向于方案一：挂载宿主机时区文件。原因如下：

1. 改动最小，风险最低。
2. 不需要修改镜像或依赖包，适用于大多数镜像。
3. 宿主机时区更新后，容器自动同步，维护成本低。

当然，如果你想完全控制镜像的时区配置，或者需要跨平台部署，方案三也是个不错的选择。而方案二则适合临时测试或快速启动的场景。

总结

容器时区问题看似小坑，但排查起来确实费时费力。希望以上三种方案能帮你快速解决类似问题。如果你有其他更好的方法，欢迎一起讨论！