Docker入门实战的核心，不是把几十条命令背下来，而是搞清楚镜像、容器、网络和存储之间的关系。刚开始接触容器时，可以先把它理解为一种轻量级虚拟化：镜像相当于安装光盘，容器就是光盘启动后的运行实例，仓库则负责存放和分发这些光盘。

实际动手之前，建议先在本机装好Docker Desktop或者Linux服务器上的Docker Engine。安装完成后执行docker version，如果客户端和服务端都能返回版本号，说明基础环境已经就绪。接下来的所有操作，都会围绕一条主线展开：先学会跑别人的镜像，再学会做自己的镜像，最后用Compose把多个容器组合起来。

一、镜像、容器和仓库：把概念落到命令上

镜像是Docker里最基础的概念，它由多层只读文件系统叠加而成。你可以用docker pull nginx拉取一个Nginx镜像，命令执行时会看到每一层都在下载。这个层叠结构带来的好处是复用和分发效率高，坏处是一旦某一层缓存失效，后面所有层都要重新构建，这也是Dockerfile体积膨胀的常见根源。

容器是镜像的运行实例，启动时会在镜像层之上加一个可写层。理解这一点很重要：容器删除后，可写层里的数据如果没有挂载到宿主机，就会直接丢失。所以只要数据需要保留，就必须使用卷挂载。容器之间的隔离由内核命名空间和控制组提供，但默认网络下容器之间通过IP通信并不直观，更常用的方式是用端口映射把容器端口暴露到宿主机。

仓库则是镜像的集中存储位置，Docker Hub是默认仓库。国内网络环境下，如果拉取镜像速度很慢，可以配置镜像加速器。不过生产环境不建议直接依赖公共加速器，更稳妥的做法是搭建私有仓库或使用云厂商提供的镜像仓库。

二、第一个实战容器：运行Nginx并访问服务

第一次跑容器，很多人会卡在端口映射上。下面的命令可以把宿主机的8080端口映射到容器的80端口，并且让容器在后台运行：

docker run -d --name my-nginx -p 8080:80 nginx

命令执行后，打开浏览器访问http://127.0.0.1:8080就能看到Nginx欢迎页。这里-d表示后台运行，--name给容器起一个方便管理的名字，-p 8080:80是端口映射，左侧是宿主机端口，右侧是容器端口。如果8080被占用，换一个宿主机端口即可，容器内部端口仍然保持80。

运行成功后，可以用docker logs my-nginx查看访问日志，用docker exec -it my-nginx bash进入容器内部。注意容器内的Nginx配置路径和宿主机不一样，除非已经挂载了配置文件，否则在容器内改配置并不利于维护。更推荐的做法是在运行时挂载宿主机目录或配置文件，例如-v /home/user/nginx.conf:/etc/nginx/nginx.conf:ro，其中:ro表示只读挂载。

三、用Dockerfile构建自己的应用镜像

只会跑官方镜像远远不够，入门实战的关键一步是把自己的应用打包成镜像。假设有一个简单的Python Flask应用，入口文件为app.py，依赖记录在requirements.txt中。可以新建一个名为Dockerfile的文件，内容如下：

# Dockerfile
FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
EXPOSE 5000
CMD ["python", "app.py"]

这段Dockerfile有几个值得注意的地方。WORKDIR /app指定了后续命令的工作目录；COPY requirements.txt .和RUN pip install单独分开，是为了利用镜像层缓存。只要依赖文件不变化，重新构建时安装依赖这一层就不会重新执行，从而大幅加快构建速度。

构建命令为docker build -t my-flask-app:1.0 .。最后那个点表示构建上下文为当前目录，不要忽略。构建完成后用docker run -d -p 5000:5000 my-flask-app:1.0启动。这里建议给镜像打上明确的版本标签，不要一直用latest，否则回滚和记录变更都非常麻烦。构建过程中如果遇到包下载慢，可以考虑更换基础镜像源或在Dockerfile中临时配置镜像源。

四、用Docker Compose编排多容器服务

单个容器只能承载一个进程，实际项目里往往是前端、后端、数据库多个服务一起工作。Docker Compose用YAML文件描述一组服务，一条命令就能批量启动。以下是一个包含Flask和Redis的简化示例：

version: "3.9"
services:
  web:
    build: .
    ports:
      - "5000:5000"
    depends_on:
      - redis
    environment:
      REDIS_HOST: redis
  redis:
    image: redis:7-alpine
    volumes:
      - redis-data:/data
volumes:
  redis-data:

在这个配置中，depends_on只表示启动顺序，并不保证Redis完全就绪。对于需要等待数据库初始化的应用，应在应用侧添加重试机制，或者使用健康检查。默认网络下，两个服务可以通过服务名互相访问，例如Flask里连接Redis时主机名直接写redis即可，不需要填写IP地址。

启动整个编排栈只需在配置文件所在目录执行docker compose up -d，停止用docker compose down。如果执行down时不加-v参数，具名卷redis-data会保留，下次启动数据还在。很多新手误以为down会删数据，其实只有在显式加-v时才会删除卷，这是需要提前确认的细节。

五、容易被忽略的坑与实用建议

第一个常踩的坑是容器内以root身份运行。默认情况下，很多镜像的容器进程是root，一旦容器被攻破，宿主机可能受到更大影响。在Dockerfile中应该创建普通用户并切换到该用户，例如使用useradd和USER指令。对于已经构建好的镜像，也可以在启动时用--user参数指定运行用户。

第二个问题是镜像体积和构建缓存。不要把所有文件都COPY进镜像，应该配合.dockerignore文件排除.git、node_modules、本地日志等无用内容。安装依赖时要清理包管理器缓存，例如pip install --no-cache-dir，否则镜像会莫名其妙地变大。构建时先拷贝依赖清单再安装，再拷贝业务代码，这个顺序对缓存命中率影响很大。

第三个常见问题是端口冲突和网络不通。容器A映射宿主机的8000端口后，容器B再映射8000就会失败。多容器通信时，优先使用Docker网络而不是通过宿主机IP去绕。用docker network create创建自定义网络，再把相关容器加入同一网络，比使用默认网桥更可控，也支持DNS服务名解析。

最后要强调数据持久化。凡是数据库、上传文件、配置文件，都要挂载卷或绑定宿主机目录。临时数据可以放在容器可写层，但重要数据不行。入门阶段把匿名卷、具名卷和绑定挂载的区别搞清楚，后面排查数据丢失问题会省很多时间。建议每次启动容器前先确认数据目录在哪，删除容器前检查是否已经停止，而不是直接删掉。

Docker入门实战真正难的不是几条命令，而是形成容器化思维：服务无状态、数据有状态、配置外置、日志收集。把这些原则贯穿到镜像构建和容器运行中，后续再接触Kubernetes等编排工具时，会更容易理解为什么Docker只是容器运行时的其中一种选择。