Docker容器核心操作全解析：从启动停止到日志诊断与资源管理

1. 容器操作入门：从启动到停止的全流程解析

刚接触Docker那会儿，我总觉得它像是个黑盒子，把应用打包进去，然后docker run一下，服务就跑起来了，挺神奇的。但真到了生产环境，或者只是想本地调试个服务，才发现只会run是远远不够的。容器怎么优雅地停掉？怎么查看它内部的日志？怎么进去改个配置文件？这些看似“基本”的操作，恰恰是日常开发运维中最频繁、也最容易踩坑的地方。今天，我就结合自己这些年从开发到运维一路用过来的经验，把Docker容器的运行、停止、查看这些核心操作掰开揉碎了讲清楚。无论你是刚入门的新手，还是想梳理一下最佳实践的老手，相信都能找到有用的东西。

Docker的核心价值在于“一次构建，处处运行”，但这个“运行”的生命周期管理，才是体现我们功力的地方。一个容器从创建到销毁，中间的状态转换、资源查看、问题诊断，每一步都有讲究。操作不当，轻则服务中断、数据丢失，重则留下安全隐患。所以，别小看这些基础命令，它们是你驾驭容器化技术的地基。接下来，我们就从最核心的docker run开始，一步步深入。

2. 容器生命周期的核心：运行与创建

容器的起点永远是docker run，但这个命令背后的门道，比想象中要多。

2.1 深入理解docker run：不仅仅是启动

很多人把docker run简单地理解为“运行容器”，这其实不准确。docker run实际上是一个复合操作，它依次完成了：检查本地是否存在指定的镜像 -> 如果不存在则从仓库拉取（Pull） -> 基于该镜像创建一个新的容器（Create） -> 启动（Start）这个容器。理解这一点很重要，因为它解释了为什么第一次运行某个镜像时会比较慢（需要拉取），以及“运行”和“创建”的区别。

一个最基础的运行命令是这样的：

docker run nginx:latest

这行命令会以后台模式运行最新的Nginx镜像。但这样运行，容器一启动就占据了你的终端，按Ctrl+C会直接终止容器，并且容器没有任何网络端口映射到宿主机，你实际上访问不了这个Nginx服务。这显然不是我们想要的常规用法。

所以，我们几乎总是需要加上一些参数来定制容器的行为。下面是一个更贴近生产实践的例子：

docker run -d --name my-nginx -p 8080:80 -v /宿主机/nginx.conf:/etc/nginx/nginx.conf:ro nginx:latest

我们来拆解一下这个命令：

• -d：这是--detach的缩写，意为“分离模式”。加上这个参数，容器会在后台运行，并把容器ID打印到终端，之后还你一个干净的终端。这是运行长期服务容器的标准姿势。
• --name my-nginx：给容器起一个有意义的名字。如果不指定，Docker会随机分配一个有趣但难记的名字（比如gracious_curie）。有了名字，后续的stop、exec等操作就不用去记冗长的容器ID了，直接用名字即可。
• -p 8080:80：端口映射，这是容器网络访问的关键。格式是-p <宿主机端口>:<容器内端口>。这里将宿主机的8080端口映射到容器内的80端口（Nginx默认端口）。这样，你访问http://localhost:8080就能看到容器内的Nginx页面了。
• -v /宿主机/nginx.conf:/etc/nginx/nginx.conf:ro：数据卷挂载。格式是-v <宿主机路径>:<容器内路径>:<可选权限>。这里把宿主机的一个自定义Nginx配置文件挂载到容器内，覆盖默认配置。ro表示read-only（只读），防止容器内进程意外修改你的配置文件。这是实现配置外部化、数据持久化的核心手段。
• nginx:latest：指定要运行的镜像名和标签。始终建议明确指定标签（如nginx:1.25），而不是依赖默认的latest，因为latest标签可能随时指向新版本，导致运行环境不一致。

注意：-v挂载的宿主机路径必须是绝对路径。使用相对路径会导致意想不到的错误，因为Docker守护进程对路径的解释可能和你的当前目录理解不同。

2.2 创建而不运行：docker create的应用场景

有时候，我们只是想准备好一个容器，但并不想立即启动它。比如，在复杂的编排或CI/CD流水线中，可能需要先创建容器，配置好网络、存储等资源，再在某个特定时刻统一启动。这时候就需要docker create。

docker create --name my-redis -p 6379:6379 redis:alpine

执行这个命令后，你会得到一个容器的ID。此时容器处于Created状态，并没有运行。你可以使用docker start my-redis来启动它。docker create支持绝大多数docker run的参数（除了那些与运行状态相关的，如-d），这为精细化的容器生命周期管理提供了可能。

2.3 运行参数进阶：资源限制与环境变量

对于生产环境，我们还需要关心容器的资源占用，避免单个容器耗尽宿主机资源。

• CPU限制：--cpus可以限制容器使用的CPU核心数。例如--cpus="1.5"表示容器最多使用1.5个CPU核心的计算能力。--cpuset-cpus可以指定容器运行在哪些具体的CPU核上，用于实现CPU绑核，提升缓存命中率。
• 内存限制：-m或--memory限制容器可用的最大内存，例如-m 512m。强烈建议始终为容器设置内存限制，这是防止“内存泄漏”应用拖垮整个宿主机的关键防线。
• 环境变量：-e用于向容器内传递环境变量，这是配置应用程序的常用方式。例如运行一个MySQL容器：docker run -d --name mysql -e MYSQL_ROOT_PASSWORD=my-secret-pw mysql:8.0。环境变量对于解耦镜像与配置至关重要。

一个综合性的运行示例如下：

docker run -d \ --name my-app \ --cpus="2" \ -m "1g" \ -p 8080:3000 \ -e NODE_ENV=production \ -e DATABASE_URL=postgres://user:pass@db:5432/db \ -v /app/data:/usr/src/app/data \ my-app-image:v1.0

3. 容器状态管理：停止、暂停与重启

容器运行起来后，我们需要管理它的状态。粗暴的管理方式可能导致数据损坏或服务异常。

3.1 停止容器：docker stop与docker kill的本质区别

这是最容易混淆的一组命令。它们的目标都是让容器停止运行，但行为截然不同。

• docker stop [容器名/ID]：优雅停止（Graceful Shutdown）。这是推荐的首选方式。

  1. Docker会向容器内的主进程（PID 1）发送SIGTERM信号。
  2. 进程收到SIGTERM后，应该开始执行清理工作：关闭网络连接、保存数据、释放资源等。
  3. 默认等待10秒（可通过-t参数修改，如docker stop -t 30 my-container），如果进程仍未退出，Docker将发送SIGKILL信号强制终止。 这个过程给了应用一个“体面退出”的机会，对于数据库、消息队列等有状态服务至关重要，能最大程度保证数据一致性。

• docker kill [容器名/ID]：强制终止。Docker会直接向容器主进程发送SIGKILL信号（默认），进程会立即被终止，没有机会做任何清理工作。这相当于直接拔电源。

  • 你可以指定其他信号，例如docker kill --signal=SIGINT my-container发送中断信号。
  • 使用场景：通常只在容器完全无响应（比如死锁），docker stop无效时，作为最后手段使用。

实操心得：养成使用docker stop的习惯。在编写Dockerfile时，也要确保你的应用能够正确响应SIGTERM信号。例如，在Node.js应用中使用process.on('SIGTERM', ...)，在Python中使用signal.signal(signal.SIGTERM, ...)来注册清理函数。

3.2 暂停与恢复：docker pause和docker unpause

这两个命令用于“冻结”和“解冻”一个运行中的容器。

• docker pause my-container：暂停容器内所有进程。这些进程不会被调度运行，但它们占用的内存等资源依然保留。容器状态变为Paused。
• docker unpause my-container：恢复被暂停的容器。

应用场景：这个功能非常有用。比如，你需要对容器的底层文件系统做一次快照备份，为了确保数据一致性，可以先pause容器，再做快照，完成后unpause。这样比停止再启动要快得多，因为进程上下文都在内存里。再比如，临时释放CPU资源给更重要的任务。

3.3 重启容器：docker restart

docker restart相当于依次执行了docker stop和docker start。它同样会先尝试优雅停止容器，然后再启动。常用于应用配置更新后，需要重启生效的场景。命令很简单：docker restart my-container。同样支持-t参数设置停止超时时间。

4. 信息查看与诊断：掌握容器内情

运维容器，不能当“黑盒”来处理。我们必须有能力洞察其内部状态。

4.1 查看容器列表：docker ps的学问

docker ps是使用频率最高的命令之一，用于列出容器。但很多人只记得docker ps -a。

• docker ps：默认只显示正在运行的容器。
• docker ps -a：显示所有状态的容器（包括已停止、已退出、已创建）。
• docker ps -q：只输出容器ID，这在写脚本时特别有用，例如docker stop $(docker ps -q)可以停止所有运行中的容器（慎用！）。
• docker ps --filter：强大的过滤器。例如：
  • docker ps --filter "status=exited"：查看所有已退出的容器。
  • docker ps --filter "name=web"：查看名字包含web的容器。
  • docker ps --filter "ancestor=nginx"：查看所有基于nginx镜像运行的容器。
• docker ps --format：自定义输出格式。默认输出信息较多，有时我们只关心几项。例如：

  docker ps --format "table {{.Names}}\t{{.Status}}\t{{.Ports}}"

  这会输出一个更简洁的表格，只包含容器名、状态和端口映射。

4.2 洞察容器详情：docker inspect

如果说docker ps是看清单，那docker inspect就是做全面体检。它返回指定容器或镜像的底层详细信息，一个巨大的JSON对象。

docker inspect my-nginx

输出包含了一切：容器的ID、创建时间、路径、状态、镜像、启动参数、网络设置（IP地址、网关、端口映射）、挂载的卷、资源配置（CPU、内存）等等。

我们通常不会看完整的JSON，而是结合--format参数来提取特定信息，这是排查问题的利器：

• 查看容器的IP地址：docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' my-nginx
• 查看容器使用的镜像ID：docker inspect -f '{{.Image}}' my-nginx
• 查看容器的日志文件路径：docker inspect -f '{{.LogPath}}' my-nginx
• 查看容器的启动命令：docker inspect -f '{{.Config.Cmd}}' my-nginx

4.3 实时追踪日志：docker logs

日志是诊断问题的生命线。Docker将容器内主进程的标准输出（STDOUT）和标准错误（STDERR）捕获为日志。

• docker logs my-container：查看容器从启动到现在的所有日志。
• docker logs -f my-container：-f或--follow，实时跟踪（类似tail -f）日志输出。这是调试和监控服务状态的必备操作。
• docker logs --tail 50 my-container：只看最后50行日志。
• docker logs --since 2024-05-01T10:00:00 my-container：查看指定时间之后的日志。
• docker logs -t my-container：-t或--timestamps，在每条日志前加上时间戳，对于分析事件序列非常重要。

注意：默认的Docker日志驱动（json-file）会将日志以JSON格式存储在宿主机上，长期运行可能导致日志文件巨大，占用磁盘。需要定期清理或配置日志轮转（log-rotation）。可以使用docker run时的--log-opt参数进行配置，例如--log-opt max-size=10m --log-opt max-file=3来限制单个日志文件最大10M，最多保留3个。

4.4 容器内执行命令：docker exec的灵活运用

有时我们需要进入容器内部进行操作，比如检查文件、调试进程、执行临时命令。

• docker exec -it my-container /bin/bash：这是最经典的用法。-i保持标准输入打开，-t分配一个伪终端，两者结合让我们获得一个交互式的Shell。注意，容器内必须存在/bin/bash或/bin/sh等Shell程序。Alpine等精简镜像可能只有/bin/sh。
• docker exec my-container ls /app：不进入交互模式，直接在容器内执行一条命令并返回结果。这在脚本中非常有用。
• docker exec -u root my-container ...：以root用户身份执行命令（如果当前用户不是root）。
• docker exec -e MY_VAR=value my-container ...：在执行命令时传入环境变量。

重要提醒：docker exec应该仅用于调试和临时任务。任何对容器内文件系统的持久化修改（如安装软件、修改配置），都应该通过重建镜像（修改Dockerfile）或使用数据卷挂载的方式来实现。因为exec内的修改只对当前容器实例有效，容器销毁即丢失，且无法版本化管理。

5. 容器日常维护与清理操作

日常使用中，会积累很多停止的容器、无用的镜像、悬空的卷，占用磁盘空间。

5.1 删除容器：docker rm

停止的容器不会自动删除，需要手动清理。

• docker rm my-container：删除一个已停止的容器。
• docker rm -f my-container：-f强制删除一个正在运行的容器（先kill再rm）。
• docker container prune：交互式地删除所有已停止的容器。也可以加-f跳过确认。
• 批量删除所有已停止的容器：docker rm $(docker ps -aq -f status=exited)。这是一个经典组合命令。

5.2 清理资源的一站式命令：docker system

Docker提供了一系列系统级清理命令：

• docker system df：查看Docker磁盘使用情况，清晰展示镜像、容器、数据卷、构建缓存各占用了多少空间。
• docker system prune：这是一个需要谨慎使用的命令。它会删除所有已停止的容器、所有未被任何容器使用的网络、所有悬空的镜像（没有被任何容器引用的镜像），以及所有构建缓存。相当于一次大扫除。使用前务必确认。
• docker system prune -a：更激进的清理，在prune的基础上，还会删除所有未被容器使用的镜像（而不仅仅是悬空镜像）。这可能会把你一些暂时没在运行但需要的镜像也删掉。

我的习惯是定期运行docker system df查看情况，然后有针对性地清理。对于开发机，每周一次docker system prune可以保持系统清爽。对于生产环境的宿主机，清理要格外小心，需要有严格的流程。

6. 常见问题与排查技巧实录

在实际操作中，你一定会遇到各种“诡异”的情况。这里记录几个我踩过的坑和解决方法。

6.1 容器启动后立即退出

这是新手最常见的问题。你运行docker run，容器ID一闪而过，然后docker ps就看不到了，用docker ps -a看到状态是Exited (0)或Exited (非0)。

排查思路：

1. 查看退出日志：首先运行docker logs <容器ID>，即使容器已退出，只要没被删除，它的日志仍然存在。这里往往有直接错误信息，比如“配置文件找不到”、“端口被占用”、“依赖服务连接不上”。
2. 检查容器进程：Docker容器要求前台必须有一个持续运行的进程。如果你的启动命令是执行一个脚本，脚本执行完就结束了，那么容器任务完成，自然就退出了。例如，你的Dockerfile的CMD是[“npm”, “test”]，测试跑完容器就停了。
   • 解决方法：确保CMD或ENTRYPOINT是启动一个长期运行的服务，如nginx -g ‘daemon off;’或node server.js。对于需要同时运行多个进程的复杂场景，需要使用Supervisor等进程管理工具，但这通常违背了“一个容器一个进程”的最佳实践，应考虑拆分为多个容器。
3. 交互式运行调试：使用docker run -it --entrypoint /bin/sh your-image。-it让你获得一个交互式Shell，--entrypoint覆盖默认的入口点。这样你可以手动在容器内执行你的启动命令，直接观察错误输出，或者检查环境、文件是否存在。

6.2 端口绑定失败：Bind for 0.0.0.0:8080 failed: port is already allocated

这个错误意思是宿主机上的8080端口已经被其他进程（可能是另一个容器，也可能是宿主机上的其他服务）占用了。

排查与解决：

1. 找出占用者：在宿主机上运行sudo lsof -i :8080或netstat -tulpn | grep :8080，查看是哪个进程在监听8080端口。
2. 解决方案：
   • 停止占用进程：如果是一个无关紧要的旧容器，用docker stop停掉它。
   • 更换宿主机端口：修改-p参数，例如改为-p 8081:80。
   • 让Docker自动分配宿主机端口：使用-p 80（只写容器端口），Docker会随机选择一个宿主机的高位端口（如32768）进行映射。可以通过docker ps查看具体映射到了哪个端口。

6.3 数据卷（Volume）权限问题

当你使用-v将宿主机目录挂载到容器内时，常常会遇到容器内应用没有权限写入挂载目录的问题。尤其是在容器内进程以非root用户（如node、nginx用户）运行时。

典型错误：日志中提示“Permission denied” when writing to /app/data。

原因：容器内进程的用户UID（例如UID=1000）在宿主机上对应UID=1000的用户，但如果宿主机上的挂载目录所属用户和权限不允许UID=1000写入，就会失败。

解决方法：

1. （推荐）在宿主机上调整目录权限：在运行容器前，确保宿主机目录对容器内进程用户可写。你可以：
   • 将目录改为宽泛的权限：chmod 777 /宿主机/数据目录（不安全，仅用于测试）。
   • 更安全的方式是，在Dockerfile中明确应用运行的用户UID（如USER 1000），然后在宿主机上将该目录的所属用户改为同一个UID（需要宿主机存在该UID的用户）或改为对该UID的组可写。
2. 使用命名卷（Named Volume）：Docker管理的命名卷会自动处理权限问题，更适合生产环境的数据持久化。docker volume create my-data然后-v my-data:/app/data。
3. （慎用）在容器内以root运行：这不是好办法，会降低安全性。仅作为临时调试手段。

6.4 容器时间与宿主机时间不一致

容器默认使用UTC时间，而宿主机可能是本地时间（如CST）。这会导致容器内应用打印的日志时间对不上。

解决方法：在运行容器时，将宿主机的时区文件挂载到容器内。

docker run -d -v /etc/localtime:/etc/localtime:ro -v /etc/timezone:/etc/timezone:ro your-image

:ro表示只读挂载。这样容器就会使用和宿主机相同的时区设置。

6.5 如何查看容器消耗的真实资源？

docker stats命令可以提供容器实时资源占用视图，包括CPU、内存、网络IO、磁盘IO等。

docker stats

或者查看特定容器：docker stats my-container。这个命令对于监控容器性能、发现内存泄漏或CPU瓶颈非常直观。

对于更历史、更详细的数据，可以查看容器的底层cgroup信息，或者使用docker inspect查看OOMKilled等状态，判断容器是否因内存超限而被系统终止。

掌握这些基本操作，就像是拿到了驾驶容器的驾照。它们是你每天都会用到的“肌肉记忆”命令。但记住，命令是工具，背后的原理和最佳实践才是关键。比如，始终思考数据如何持久化、日志如何管理、网络如何配置、资源如何限制。把这些基础打牢，再去学习Docker Compose、Swarm或Kubernetes这些编排工具，就会感觉顺理成章，因为它们无非是在更高的维度上，对这些基本操作和概念进行抽象和编排。