容器部署入门：从拉第一个镜像到服务长期稳定运行

2026-10-05 14:28 1008 次浏览

刚接触容器的人常有种错觉：命令就那几条，应该不难。真上手才发现，run起来容易，让它连续跑一个月不出事才是难点。镜像从哪拉、数据存哪、进程崩了谁负责拉起来，这三件事没想清楚，后面全是补丁。

下面按从零到稳定的路径走一遍。前半段是能立刻跑起来的操作，后半段是决定这套东西能不能长期用的配置。

第一条命令：先让容器跑起来

装好引擎之后，验证环境用 docker run hello-world。能打印出那段欢迎文字，说明引擎和镜像拉取都正常。

接着跑一个真实服务，比如Nginx：docker run -d -p 8080:80 nginx。参数含义拆开看，-d 是后台运行，-p 把宿主机的8080映射到容器的80。访问宿主机的8080端口，应该能看到默认页。

这里有个新手高频错误：把端口写成 -p 80:8080。顺序反了，外面访问不到，容器内部日志还一切正常，排查起来容易绕远路。记住左边是宿主机、右边是容器。

想进容器里看看：docker exec -it 容器ID bash。容器里没有bash的（比如alpine镜像）换成 sh。退出用 exit，注意别在里面乱改配置，容器一重建改动就没了。

拉取慢，通常是网络路径问题，配加速地址能缓解。拉不到，往往是镜像名或标签写错了。

标签不写默认是 latest，这个习惯在生产环境要改掉。latest会随时间变化，今天部署和三个月后重部署拿到的可能不是同一个镜像。写死版本号，比如 nginx:1.27，行为才可复现。

另一个实际问题是镜像体积。基础镜像选 alpine 能小很多，但要注意它用的是musl libc，某些依赖glibc的二进制跑不起来。省下的几百MB换来一堆兼容性排查，这笔账不一定划算。

依赖外部仓库有风险，重要服务建议把镜像导出留底：docker save -o nginx.tar nginx:1.27，需要时 docker load -i nginx.tar。上线当天仓库抽风，这个tar能救急。

如果服务本身就在海外机房跑，拉取路径会短很多。像硅谷裸机云 XII，双路E5-2683v4加64G内存、100M带宽，月付149美元，跑容器集群的调度和镜像分发都比较从容。选它的理由很直接：部署阶段的时间成本，往往比机器本身的差价更值钱。

这部分是全文最该细看的地方，前面跑通只是入门，这里决定你能不能睡好觉。

数据卷：容器内的数据随容器生命周期走，删容器就没了。数据库、上传目录这类必须挂出来，-v /host/path:/container/path。用命名卷也行，docker volume create 建一个，比直接绑宿主目录更好管理。
重启策略：--restart unless-stopped 是常驻服务的默认选择。always 会在你手动停掉后又被拉起来，调试时很烦；no 则意味着机器重启后服务不会自己回来。
日志限制：默认日志驱动不设上限，长期跑能把磁盘写满。在 /etc/docker/daemon.json 里配 log-opts，max-size 设50m、max-file 设3，滚动覆盖，基本够用。

多容器用 compose 管。docker-compose.yml 里写清镜像、端口、卷和依赖关系，一条 docker compose up -d 全部起来。改配置后 docker compose up -d 会自动重建变化的容器，不用手动删旧的。

depends_on 控制启动顺序，但它不等服务就绪。数据库初始化要十几秒，应用启动只要两秒，那应用一定连不上。解决办法是在应用侧做连接重试，别指望编排工具替你等。

监控方面，docker stats 看实时资源占用，docker logs --tail 100 看最近日志。这两条命令够应付大部分日常排查。真出问题时，先看容器状态是 running 还是 exited，再看退出码，方向就清晰了。

最后给个判断标准：个人测试用，随便跑跑无所谓；对外提供服务，数据卷和重启策略必须配齐，日志上限也别忘了。这三样加起来花不了十分钟，省下的是半夜被告警叫醒的次数。