镜像构建时区配置：别让时间差毁了你的备份计划

做数据备份的时候，你有没有遇到过日志时间对不上、定时任务莫名其妙提前或延后执行的情况？问题很可能出在镜像构建时的时区配置上。很多人在打包 Docker 镜像时只关心应用能不能跑起来，忽略了时区这个细节，结果上线后日志全是 UTC 时间，排查问题像在破案。

默认时区是 UTC，不是北京时间

Docker 官方基础镜像比如 Ubuntu、Alpine、CentOS，出厂默认时区都是 UTC。这意味着你在容器里用 date 命令看到的时间比北京时间慢 8 小时。如果你的备份脚本依赖系统时间判断执行周期，或者日志记录用于审计追踪，这种偏差会带来严重误判。

如何在构建镜像时设置正确时区

以常见的 Ubuntu 镜像为例，在 Dockerfile 中加入时区配置：

RUN ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime \ 
    && echo 'Asia/Shanghai' > /etc/timezone

如果是基于 Alpine 的轻量镜像，操作稍有不同：

RUN apk add --no-cache tzdata \ 
    && cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime \ 
    && echo 'Asia/Shanghai' > /etc/timezone \ 
    && apk del tzdata

这里先安装 tzdata 包，复制时区文件，再删掉包节省空间，适合对镜像体积敏感的场景。

环境变量也能起作用

有些应用通过 TZ 环境变量读取时区，可以在 Dockerfile 里直接声明：

ENV TZ=Asia/Shanghai

或者运行容器时传入：-e TZ=Asia/Shanghai。但这只是补充手段，不能替代系统级时区设置，特别是涉及 cron 任务或系统调用时。

实际影响：备份脚本的时间陷阱

假设你写了个每天凌晨 2 点执行的备份脚本，用的是宿主机挂载的 crontab。如果容器时区还是 UTC，那实际上对应北京时间是上午 10 点——等你发现时，黄金恢复窗口可能已经错过了。更糟的是，监控报警按时间过滤日志，UTC 和 CST 混在一起，查故障得靠猜。

统一时区是一种运维习惯

团队协作时，有人在上海，有人在东京，服务器分布在不同时区。只要所有镜像在构建阶段就明确指定时区，后续不管部署到哪台机器，时间行为都是一致的。与其每次运行时加参数，不如从源头解决。

下次构建镜像前，花 10 秒钟加上那行时区配置。别让“时间”成为你备份链路上那个被忽略的薄弱环节。