Docker入门实战：从核心概念到多容器编排

1. 从“它是什么”到“我为什么需要它”：重新认识Docker

如果你是一名开发者，或者正在向运维、DevOps方向转型，那么“Docker”这个词你肯定不陌生。它几乎成了现代软件开发和部署的“标配”。但很多新手在入门时，往往一上来就照着教程敲命令，docker run hello-world跑通了，却依然一头雾水：这玩意儿到底解决了什么问题？它和虚拟机有什么区别？为什么我的项目非用它不可？

我刚开始接触Docker时也有同样的困惑。直到有一次，我在本地开发环境（macOS）上完美运行的一个Python数据分析项目，交给运维同事部署到CentOS服务器上时，因为Python版本、依赖库版本乃至系统底层库的差异，折腾了整整两天才跑起来。那一刻，我深刻体会到了“环境一致性”这个问题的痛点。而Docker，正是为了解决“在我的机器上能跑，在你的机器上就跑不起来”这个经典难题而生的。

简单来说，Docker是一个用于开发、发布和运行应用程序的开放平台。它允许你将应用程序及其所有依赖项（代码、运行时、系统工具、系统库、设置）打包成一个标准化的单元，这个单元就叫做容器（Container）。容器在任何安装了Docker的环境中运行起来都是一样的，这就像把货物装进标准集装箱，无论用轮船、火车还是卡车运输，里面的货物都不会受损，也无需关心运输工具的内部结构。

2. 核心概念拆解：镜像、容器、仓库与虚拟机对比

要玩转Docker，必须先吃透三个核心概念：镜像、容器和仓库。这是理解所有Docker操作的基础。

2.1 镜像（Image）：容器的“蓝图”与“只读模板”

你可以把Docker镜像理解为一个只读的模板。它包含了运行某个软件所需的所有内容：代码、运行时环境、库、环境变量和配置文件。镜像本身是静态的、不可改变的。

• 生活化类比：镜像就像是一个.iso格式的系统安装光盘。光盘里刻录了完整的Windows系统文件，但这个光盘本身你是不能修改的（只读）。你需要用这个光盘来安装系统。
• 技术本质：镜像采用分层存储结构。每一层都是对前一层的一组文件系统修改。例如，一个基于Ubuntu的Python应用镜像，底层是Ubuntu系统层，上面叠加了Python运行时层，再上面是你的应用代码层。这种分层设计使得镜像复用率极高，下载和存储都非常高效。

2.2 容器（Container）：镜像的运行实例

容器是镜像的一个运行实例。当你从镜像创建并启动一个容器时，Docker会在镜像的最上层创建一个可写的“容器层”，所有对运行中容器的修改（如写入日志、安装临时软件）都发生在这个可写层，而不会影响底层的镜像。

• 生活化类比：用刚才的安装光盘（镜像）在电脑上安装好了一个Windows系统（容器）。你可以在这个系统里安装软件、保存文件。这个运行中的系统就是容器。如果你把系统删了（删除容器），光盘（镜像）还在，随时可以再装一个全新的、一模一样的系统。
• 关键特性：容器是轻量级、可移植的。它共享宿主机的操作系统内核，但拥有自己独立的进程空间、网络配置和文件系统。这意味着启动一个容器只需几秒钟，资源开销远小于虚拟机。

2.3 仓库（Registry）：镜像的“App Store”

仓库是集中存放镜像的地方。最大的公共仓库是 Docker Hub ，你可以在这里找到几乎所有主流软件（如Nginx, MySQL, Redis, Python）的官方镜像。你也可以搭建私有的仓库（如Harbor），用于存放企业内部的应用镜像。

• 操作流程：通常，我们从仓库pull（拉取）镜像到本地，然后run（运行）它来创建容器。开发完成后，将本地构建的镜像push（推送）到仓库，供其他环境（测试、生产）使用。

2.4 Docker vs. 虚拟机：根本性的架构差异

这是新手最容易混淆的点。很多人觉得容器就是轻量级的虚拟机，其实不然，它们的架构有本质区别。

通俗解释：虚拟机好比在一栋大楼（物理服务器）里，用砖墙（Hypervisor）隔出了好几个独立的公寓（VM），每个公寓里都有一套完整的家具、厨房、卫生间（完整的Guest OS）。而Docker容器则像是这栋大楼里的一个个合租房间，大家共享大楼的主体结构和公共设施（宿主机内核），但每个房间有自己独立的门锁、私人物品和规则（独立的进程空间、文件系统），彼此互不干扰。显然，合租（容器）更节省空间和资源，部署速度也快得多。

3. 手把手实战：从安装到运行你的第一个容器

理论懂了，接下来就是实战。我会以Windows/macOS平台为主，因为这是大多数开发者的起点，也会涵盖安装中最大的“拦路虎”——虚拟化问题。

3.1 Docker Desktop安装与“虚拟化支持”踩坑实录

对于Windows和macOS用户，官方推荐使用Docker Desktop。它是一个集成了Docker引擎、CLI客户端、Docker Compose等工具的一体化桌面应用。

Windows安装要点：

1. 版本选择：确保你的Windows 10/11是64位专业版、企业版或教育版（家庭版需要额外步骤）。Windows家庭版默认不支持Hyper-V，这是导致后续“virtualisation support wasn’t detected”错误的常见原因。
2. 开启虚拟化：这是最关键的一步。重启电脑进入BIOS/UEFI设置（开机时按F2、Del等键，因品牌而异），找到Intel Virtualization Technology或AMD-V选项，将其设置为Enabled。保存并退出。
3. 启用Hyper-V和容器功能：在Windows搜索栏输入“启用或关闭Windows功能”，勾选Hyper-V和适用于Linux的Windows子系统（如果你要用WSL2后端的话）。安装Docker Desktop时，安装程序通常会帮你勾选，但最好手动确认。
4. 安装Docker Desktop：从官网下载安装包，一路下一步即可。安装完成后，它可能会要求你重启电脑。

macOS安装要点：macOS安装相对简单，直接从官网下载.dmg文件安装。但请注意，对于使用Apple Silicon（M1/M2/M3芯片）的Mac，Docker Desktop提供了原生ARM版本，运行x86镜像时可能会通过转译，效率略有影响，建议尽量寻找或构建ARM架构的镜像。

经典错误排查：Docker Desktop failed to start because virtualisation support wasn’t detected

这个问题在Windows上高发，尤其是笔记本电脑或某些品牌台式机。如果你确认BIOS中已开启虚拟化，但Docker Desktop依然报错，可以按以下步骤排查：

1. 检查任务管理器：按Ctrl+Shift+Esc打开任务管理器，切换到“性能”标签页，查看CPU部分，确认“虚拟化”是否显示为“已启用”。
2. 关闭冲突的虚拟化软件：某些安全软件（如某些国产杀软的虚拟化保护）、安卓模拟器（如雷电、夜神）、旧版本的VMware或VirtualBox可能会占用虚拟化资源，导致Hyper-V无法启动。尝试暂时关闭或卸载它们。
3. 以管理员身份运行命令：在PowerShell（管理员）中依次执行以下命令，然后重启：

   bcdedit /set hypervisorlaunchtype auto

4. 使用WSL2后端（推荐）：在Docker Desktop设置中，将默认后端从Hyper-V切换到WSL2。WSL2是微软官方推荐的Linux子系统，其虚拟化方案与Hyper-V不同，有时能避开一些兼容性问题。这需要你先安装WSL2。
5. 终极方案：彻底清理重装：如果以上都不行，使用官方的卸载工具彻底清理Docker，然后重新安装，并确保每一步（BIOS、Windows功能）都做到位。

我的踩坑心得：在给团队多台不同品牌的开发笔记本配置Docker时，遇到最多的问题就是虚拟化。联想的笔记本需要在BIOS中额外关闭一个叫“VT-d”的选项（与Hyper-V冲突）；而一些惠普的商务本则需要在BIOS的安全设置里找到“虚拟化技术”并开启。没有万能钥匙，必须根据具体硬件型号搜索解决方案。

3.2 初探Docker CLI：运行Hello World与基础命令

安装成功后，系统托盘会出现Docker鲸鱼图标。打开终端（Windows可用PowerShell或CMD，推荐用Windows Terminal），输入以下命令验证安装：

docker --version docker info

如果能看到版本信息和详细的系统信息，说明安装成功。接下来，运行经典的“Hello World”：

docker run hello-world

这个命令做了以下几件事：

1. Docker客户端（CLI）联系Docker守护进程（后台服务）。
2. 守护进程发现本地没有hello-world这个镜像，于是自动从Docker Hub拉取（pull）最新的hello-world:latest镜像。
3. 拉取成功后，守护进程根据这个镜像创建一个新的容器并运行。
4. 容器执行它唯一的任务：打印一段欢迎信息到终端，然后退出。

几个最常用的基础命令：

• docker ps：列出正在运行的容器。加上-a参数可以查看所有容器（包括已停止的）。
• docker images：列出本地所有的镜像。
• docker pull <镜像名>：从仓库拉取镜像，但不运行。例如docker pull nginx。
• docker run <参数> <镜像名>：创建并运行容器。这是最核心的命令。
  • -d：后台运行（detached mode）。
  • -p 宿主机端口:容器端口：端口映射。例如-p 8080:80将容器的80端口映射到宿主机的8080端口。
  • -v 宿主机目录:容器目录：数据卷挂载，实现数据持久化。
  • --name：给容器起个名字，否则Docker会随机分配一个。
• docker stop <容器ID或名字>：停止一个运行中的容器。
• docker rm <容器ID或名字>：删除一个已停止的容器。
• docker rmi <镜像ID>：删除一个本地镜像（需先删除依赖它的容器）。

3.3 运行一个真正的服务：Nginx Web服务器

让我们运行一个更有实际意义的容器——Nginx。在终端执行：

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

• -d：让容器在后台运行。
• -p 80:80：将容器的80端口（Nginx默认监听端口）映射到宿主机的80端口。
• --name my-nginx：给这个容器起名叫my-nginx，方便后续管理。
• nginx：镜像名。Docker会自动从Docker Hub拉取最新的官方Nginx镜像。

运行后，打开浏览器访问http://localhost，你应该能看到Nginx的欢迎页面。恭喜，你已经在容器中运行了一个Web服务器！

通过docker ps可以看到它正在运行。通过docker logs my-nginx可以查看容器的日志。当你不需要时，用docker stop my-nginx停止它，再用docker rm my-nginx删除容器。注意，删除容器并不会删除nginx镜像。

4. 深入容器操作：日志、进入与数据管理

仅仅运行容器还不够，我们还需要学会如何与它交互、查看状态和管理数据。

4.1 查看日志与容器状态

容器在后台运行时，我们需要了解它的内部状态。

• docker logs <容器名/ID>：查看容器的标准输出日志。加-f参数可以实时跟踪日志输出，就像tail -f一样，这在调试时非常有用。
• docker stats：实时显示所有容器的资源使用情况（CPU、内存、网络IO等），是一个简单的性能监控工具。
• docker inspect <容器名/ID>：以JSON格式显示容器的详细配置信息，包括网络设置、挂载卷、环境变量等。信息非常全，可以用grep或jq工具来过滤查询特定信息。

4.2 进入容器内部：exec命令

有时我们需要进入容器内部执行一些命令，比如检查配置文件、安装调试工具等。注意：docker run是创建新容器，而进入已运行容器的命令是docker exec。

# 进入正在运行的my-nginx容器，并启动一个交互式bash终端 docker exec -it my-nginx /bin/bash

• -i：保持标准输入打开，允许你与容器交互。
• -t：分配一个伪终端（pseudo-TTY），让你感觉像在一个真正的终端里操作。
• /bin/bash：在容器内执行的命令，这里是启动bash shell。有些精简镜像（如Alpine Linux）可能没有bash，需要用/bin/sh。

进入后，你可以像操作一台Linux服务器一样，使用ls,cat,ps等命令。重要原则：任何在容器内通过exec进行的修改（如安装软件、修改文件），都只存在于当前容器的可写层。如果容器被删除，这些修改会全部丢失。因此，生产环境不推荐直接进入容器修改配置，正确做法是通过挂载卷或构建新的镜像。

4.3 数据持久化：绑定挂载与数据卷

容器本身是“无状态”的，删除即消失。但我们的应用（如数据库、上传的文件、日志）需要持久化保存数据。Docker提供了两种主要方式：

1. 绑定挂载（Bind Mount）将宿主机上的一个特定目录或文件直接挂载到容器中。两者完全同步。

docker run -d -p 80:80 -v /宿主机/绝对路径/html:/usr/share/nginx/html --name my-nginx nginx

• 优点：直观，宿主机文件修改立即可见，方便开发调试。
• 缺点：依赖宿主机特定路径，移植性差。宿主机操作系统与容器内文件权限可能冲突。

2. 数据卷（Volume）由Docker管理的数据存储区域，独立于容器生命周期。

# 1. 创建一个数据卷 docker volume create my-nginx-vol # 2. 运行容器并使用该数据卷 docker run -d -p 80:80 -v my-nginx-vol:/usr/share/nginx/html --name my-nginx nginx # 3. 查看所有数据卷 docker volume ls # 4. 查看数据卷详情（如存储路径） docker volume inspect my-nginx-vol

• 优点：是Docker推荐的方式。易于备份、迁移和管理（docker volume命令族）。路径由Docker管理，与宿主机系统解耦，移植性好。
• 缺点：对于开发者，不如绑定挂载直观，需要额外命令管理。

实操心得：在开发阶段，我强烈推荐使用绑定挂载，将你的项目代码目录直接挂载到容器里，实现代码修改实时生效，无需重启容器。而在生产环境，务必使用数据卷来存储数据库文件、应用日志等关键数据，并通过docker-compose.yml或编排工具（如K8s）来声明和管理，这样更规范、更安全。

5. 自定义镜像：编写你的第一个Dockerfile

使用现成的镜像很方便，但我们的最终目标是为自己的应用构建镜像。这就需要用到Dockerfile。Dockerfile是一个文本文件，里面包含了一条条指令（Instruction），每一条指令构建一层，描述了如何构建你的镜像。

5.1 Dockerfile指令详解

让我们从一个最简单的Python应用Dockerfile开始：

# 1. 指定基础镜像（Base Image） FROM python:3.9-slim # 2. 设置工作目录（容器内的默认路径） WORKDIR /app # 3. 将宿主机的当前目录下的所有文件，复制到容器的 /app 目录下 COPY . /app # 4. 安装依赖（利用缓存层，如果requirements.txt没变，这步会跳过） RUN pip install --no-cache-dir -r requirements.txt # 5. 声明容器运行时监听的端口（只是一个声明，方便使用者知道） EXPOSE 5000 # 6. 定义容器启动时执行的命令（只能有一条CMD） CMD ["python", "app.py"]

关键指令解析：

• FROM：必须是第一条指令。指定基础镜像，我们基于一个轻量级的Python 3.9镜像开始构建。好的习惯是使用带标签的官方镜像（如python:3.9-slim），而不是latest，以保证构建的一致性。
• WORKDIR：设置工作目录。后续的RUN,COPY,CMD等命令都会在这个目录下执行。
• COPY：将本地文件复制到镜像中。第一个参数是“构建上下文”中的路径，第二个是镜像内的目标路径。COPY . /app表示把构建上下文的所有文件复制到镜像的/app下。
• RUN：在构建镜像时执行的命令，通常用于安装软件包、编译代码等。每一条RUN都会创建一个新的镜像层。为了减少层数，可以将多个命令用&&连接。
• EXPOSE：仅仅是一个声明，告诉使用者这个容器准备监听哪个端口。它并不会自动进行端口映射。真正的端口映射需要在docker run时用-p参数指定。
• CMD：指定容器启动时默认执行的命令。每个Dockerfile只能有一条CMD指令。格式有 shell 格式（CMD python app.py）和 exec 格式（CMD ["python", "app.py"]），推荐使用 exec 格式，能正确处理信号。

5.2 构建镜像与运行

在包含Dockerfile和app.py、requirements.txt的目录下，打开终端执行：

# 构建镜像，-t 参数给镜像打标签（名称:版本），最后的 . 代表当前目录是构建上下文 docker build -t my-python-app:1.0 . # 查看构建好的镜像 docker images | grep my-python-app # 运行这个自定义镜像的容器 docker run -d -p 5000:5000 --name my-app my-python-app:1.0

构建上下文（Context）概念：docker build命令最后的.指的是构建上下文路径。Docker守护进程会将这个目录下的所有文件打包发送给Docker引擎用于构建。因此，为了构建速度和镜像大小，务必通过.dockerignore文件（类似.gitignore）排除不需要的文件，如__pycache__,.git,node_modules, 日志文件等。

5.3 镜像构建优化技巧

1. 使用.dockerignore文件：这是最容易被忽略但效果最显著的优化。它能显著减少构建上下文大小，加速构建过程，并避免将敏感文件（如密钥）意外打包进镜像。
2. 利用构建缓存：Docker会缓存每一层。如果Dockerfile的某一层及之前的所有层没有变化，Docker会直接使用缓存。因此，将变化频率低的指令放在前面（如安装系统依赖），将变化频率高的指令（如复制应用代码）放在后面。
3. 合并RUN指令：减少镜像层数。将多个RUN命令用&&连接，并在最后清理apt缓存等临时文件。

   # 不推荐 RUN apt-get update RUN apt-get install -y package1 package2 RUN rm -rf /var/lib/apt/lists/* # 推荐 RUN apt-get update && apt-get install -y \ package1 \ package2 \ && rm -rf /var/lib/apt/lists/*

4. 使用更小的基础镜像：python:3.9-slim比python:3.9小很多。对于追求极致体积，可以考虑python:3.9-alpine（基于Alpine Linux，仅5MB），但要注意Alpine使用musl libc，可能与某些依赖glibc的二进制库不兼容。
5. 多阶段构建（Multi-stage Build）：对于需要编译的应用（如Go, Java），这是“神器”。它允许你在一个Dockerfile中使用多个FROM语句。你可以在一个阶段（使用完整的SDK镜像）编译应用，在另一个阶段（使用极简的运行环境镜像）只复制编译好的二进制文件，从而得到非常小的最终镜像。

   # 第一阶段：构建 FROM golang:1.19 AS builder WORKDIR /app COPY . . RUN go build -o myapp . # 第二阶段：运行 FROM alpine:latest WORKDIR /root/ COPY --from=builder /app/myapp . # 从上一阶段只复制编译结果 CMD ["./myapp"]

6. 多容器编排初探：Docker Compose入门

当你的应用由多个服务组成（例如一个Web应用需要Nginx、Python后端、MySQL数据库和Redis缓存），手动用docker run启动每一个容器并配置网络、卷链接会非常繁琐。这时就需要Docker Compose。

Docker Compose是一个用于定义和运行多容器Docker应用程序的工具。通过一个docker-compose.yml文件，你可以配置所有服务，然后用一条命令启动或停止整个应用栈。

6.1 编写docker-compose.yml文件

假设我们有一个经典的三件套应用：Python Flask后端 + MySQL数据库 + Redis缓存。

version: '3.8' # 指定Compose文件格式版本 services: # 定义所有服务 web: # 服务名称：Web应用 build: . # 从当前目录的Dockerfile构建镜像 ports: - "5000:5000" # 端口映射 volumes: - ./app:/app # 代码挂载，方便开发 - log-volume:/app/logs # 日志使用数据卷 environment: # 设置环境变量 - DATABASE_URL=mysql://db:3306/mydb - REDIS_HOST=redis depends_on: # 依赖关系，先启动db和redis - db - redis networks: - app-network db: # 服务名称：数据库 image: mysql:8.0 # 使用官方MySQL镜像 environment: - MYSQL_ROOT_PASSWORD=my-secret-pw - MYSQL_DATABASE=mydb volumes: - db-data:/var/lib/mysql # 数据库数据持久化 networks: - app-network redis: # 服务名称：缓存 image: redis:alpine networks: - app-network nginx: # 服务名称：反向代理 image: nginx:alpine ports: - "80:80" volumes: - ./nginx.conf:/etc/nginx/conf.d/default.conf:ro # 挂载自定义Nginx配置 depends_on: - web networks: - app-network volumes: # 声明数据卷，Compose会自动创建和管理 db-data: log-volume: networks: # 声明网络，所有服务将连接到这个自定义网络，可以通过服务名互相访问 app-network: driver: bridge

6.2 Compose核心命令与工作流

1. 启动所有服务：在包含docker-compose.yml的目录下执行。

   docker-compose up -d

   -d表示后台运行。Compose会根据文件构建镜像（如果定义了build）、拉取镜像、创建网络、数据卷，并按依赖顺序启动所有容器。

2. 查看服务状态：

   docker-compose ps

3. 查看服务日志：

   # 查看所有服务的日志 docker-compose logs # 实时跟踪特定服务（如web）的日志 docker-compose logs -f web

4. 停止服务：

   docker-compose down

   这个命令会停止并删除所有容器、网络（默认的），但不会删除数据卷，以保证你的数据库数据安全。如果需要同时删除数据卷，使用docker-compose down -v（慎用）。

5. 其他常用命令：

   • docker-compose exec web bash：进入名为web的服务容器。
   • docker-compose build：重新构建服务镜像。
   • docker-compose restart web：重启某个服务。

编排实践心得：depends_on只控制容器的启动顺序，并不保证服务已准备好。例如，web服务依赖db，depends_on会让db先启动，但db的MySQL进程可能还需要几秒钟才能接受连接。在生产环境中，需要应用本身具备重试连接数据库的机制，或者使用更高级的健康检查（healthcheck）配置。

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

在实际使用中，你一定会遇到各种问题。这里记录了几个最高频的“坑”和解决方法。

7.1 容器内无法访问外部网络或宿主机服务

现象：在容器内ping www.baidu.com不通，或者应用配置中连接localhost:3306（宿主机MySQL）失败。

• 原因1（Linux）：可能是防火墙（如firewalld, ufw）阻止了Docker网桥的流量。可以暂时关闭防火墙测试，或添加相应规则。
• 原因2（所有系统）：在容器内，localhost或127.0.0.1指的是容器自己，而不是宿主机。
• 解决方案：
  • 访问宿主机服务，需要使用宿主机在Docker网络中的IP。在Mac/Windows的Docker Desktop中，通常是一个特殊的域名host.docker.internal。在Linux中，可以查看docker network inspect bridge找到网关IP（通常是172.17.0.1），用这个IP来访问宿主机服务。
  • 检查宿主机的服务是否监听在0.0.0.0而不是127.0.0.1。例如，MySQL默认只监听127.0.0.1，需要修改配置bind-address = 0.0.0.0才能被容器访问（注意安全风险）。

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

现象：容器内应用打印的日志时间比宿主机慢8小时（或其他时区差）。

• 原因：容器默认使用UTC时区，而宿主机可能是CST（中国标准时间）。
• 解决方案：在运行容器或Dockerfile中设置时区环境变量。
  • 运行命令：docker run -e TZ=Asia/Shanghai ...
  • Dockerfile：

    ENV TZ=Asia/Shanghai RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone

  • docker-compose.yml：

    services: app: environment: - TZ=Asia/Shanghai

7.3 权限问题：容器内进程写入宿主机挂载目录失败

现象：将宿主机目录挂载到容器后，容器内的应用（如Nginx、MySQL）无法向该目录写入文件，报“Permission denied”错误。

• 原因：容器内进程通常以非root用户（如nginx用户，UID=101）运行，而宿主机挂载目录的所有者和权限可能与该UID不匹配。
• 解决方案：
  1. （简单粗暴，适合开发）：在宿主机上修改挂载目录的权限为777（chmod -R 777 /host/path）。不推荐用于生产环境，有安全风险。
  2. （推荐）：在Dockerfile中，让容器内的应用以已知的UID运行，并在宿主机上将该目录的所有者改为同一UID。
     • Dockerfile中创建用户并指定UID：

       RUN groupadd -r -g 1001 appgroup && useradd -r -u 1001 -g appgroup appuser USER appuser

     • 宿主机上修改目录所有者：sudo chown -R 1001:1001 /host/path
  3. （Docker Desktop for Mac/Windows特有）：文件共享存在额外的权限映射层，问题更复杂。通常需要在容器内以root用户运行，或者研究Docker Desktop的文件共享设置。

7.4 镜像构建缓慢与构建缓存失效

现象：修改了一行代码，重新docker build却从第一层开始，非常慢。

• 原因：Docker构建缓存是基于指令字符串的精确匹配。如果COPY . /app之前的某条指令（如RUN apt-get update）的缓存失效，或者你复制了整个项目目录（包含频繁变动的文件），会导致后续所有层缓存失效。
• 优化技巧：
  • 精细化COPY：不要一上来就COPY . /app。先复制依赖管理文件（如package.json,requirements.txt），安装依赖，再复制源代码。这样只要源代码变动，依赖安装层可以利用缓存。

    COPY requirements.txt /app/ RUN pip install -r requirements.txt COPY . /app/ # 这行变动不会导致上一行缓存失效

  • 使用.dockerignore：再次强调，忽略无关文件。
  • 固定基础镜像版本：使用python:3.9-slim而不是python:slim，避免基础镜像更新导致缓存失效。

7.5 容器占用了太多磁盘空间

现象：运行docker system df发现镜像、容器、数据卷占用了大量磁盘空间。

• 清理策略：
  • docker image prune：删除所有悬空镜像（没有被任何容器引用的中间层镜像）。加-a参数删除所有未被使用的镜像（谨慎！）。
  • docker container prune：删除所有已停止的容器。
  • docker volume prune：删除所有未被容器引用的数据卷（非常谨慎！可能误删数据库数据）。
  • docker system prune -a：一键清理所有未使用的镜像、容器、网络和构建缓存。这是最彻底但也最危险的命令，使用前务必确认。
• 日常习惯：给容器和镜像起有意义的名字和标签，定期清理停止的容器和临时测试的镜像。

学习Docker的过程，就是一个不断将本地的手工操作标准化、自动化的过程。从解决环境问题开始，到优化开发流程，再到最终实现持续集成和部署。入门只是第一步，后面还有容器网络、安全、监控、以及更强大的编排工具Kubernetes等着你去探索。但只要你牢牢掌握了镜像、容器、仓库、Dockerfile和Compose这些核心概念，后面的路会顺畅很多。记住，多动手实践，多踩坑，才是最快的学习路径。当你成功将自己的第一个完整项目用Docker Compose编排起来并顺利运行的那一刻，你会觉得之前所有的折腾都是值得的。