Docker容器化部署实战：从镜像到Compose管理多服务-港品优选

很多开发团队都会遇到一个熟悉的场景：本地开发环境一切正常，代码一提交到同事或者服务器上，就变成“在我机器上明明能跑”。尤其是同时维护前端、后端、数据库、缓存多个服务的“双栈工坊”这类小团队，环境问题几乎每个月都要浪费一整天。有人用虚拟机解决，结果镜像文件十几个G，启动慢、占用高；有人干脆手动装依赖，换一台机器就要重新排查一遍版本。

Docker 解决的不是“软件安装”问题，而是“环境交付”问题。本文用“双栈工坊”这个典型场景，完整走一遍 Docker 管理部署容器的过程：从概念、环境准备，到镜像操作、容器生命周期，再到用 Docker Compose 一键部署前端+后端+MySQL+Redis 的完整项目，最后给出生产环境常用的排查思路和最佳实践。读完你不仅能跑通一套完整的容器化部署流程，还能避开新手最常见的那些坑。

1. 这篇文章真正要解决的问题

1.1 为什么“双栈”团队特别需要容器化

“双栈工坊”可以理解为同时使用两种技术栈做开发的团队：比如前端用 Vue 或 React，后端用 Python 或 Java；数据库用 MySQL，缓存用 Redis。这种组合在中小团队里非常常见，但依赖环境也极其脆弱。

Node.js 版本不对，前端构建报错；Python 版本不对，后端启动失败；MySQL 字符集设置不对，数据写入乱码；Redis 版本不一致，生产环境出现本地复现不了的问题。这些问题的根源不是代码，而是环境。

Docker 把应用和它的运行环境一起打包成一个标准单元。团队里任何一个人拉取同一个镜像，运行同一个容器，得到的就是完全一致的环境。这才是“在我机器上能跑”的最终解释。

1.2 容器化管理要解决的核心痛点

从“双栈工坊”的日常任务看，容器化管理主要有四个收益：环境一致性、部署效率、资源利用率和隔离性。环境一致性让开发、测试、生产环境保持一致；部署效率让一条命令启动整套服务；资源利用率让多个服务共享一台服务器；隔离性让不同应用互不干扰。

但这篇文章不只是讲 Docker 命令，而是回答几个更实际的问题：镜像和容器到底什么关系？数据存在容器里丢了怎么办？多个容器之间怎么通信？为什么我按教程写完 docker run，容器一下就被杀了？这些问题才是新手真正卡住的地方。

2. 基础概念与核心原理

2.1 镜像、容器、数据卷、Dockerfile、Compose

Docker 最核心的几个概念必须搞清楚，否则后续所有操作都是背命令。

概念	通俗解释	类比
镜像（Image）	一个只读的、打包好的运行环境模板	软件安装包
容器（Container）	镜像运行起来后的实例，可读可写	安装运行后的软件进程
数据卷（Volume）	容器外部的持久化存储，容器删除后数据不丢	移动硬盘
Dockerfile	描述如何构建镜像的脚本	安装说明书
Docker Compose	用 YAML 文件定义多个容器如何协作	启动脚本/编排文件

镜像和容器的关系最容易混淆。镜像不启动，就是一个静态文件；镜像运行起来，才变成容器。容器可以启动、停止、删除，但删除容器不会影响镜像本身。你下次用同一个镜像还能再启动一个新容器。

数据卷是很多人一开始不重视、出事才后悔的概念。容器内部是临时存储，一旦容器被删除，容器内写入的文件和数据库数据都会消失。所以 MySQL、Redis、PostgreSQL 这类有状态服务，必须把数据目录挂载到宿主机或数据卷上。

2.2 Docker 容器和 C++ 容器不是一回事

在 CSDN 的搜索热词里，“vector 容器”“deque 容器”“STL 容器”经常和“Docker 容器”一起出现，很多刚接触的同学会误解：容器是不是一种数据结构？完全不是。

C++ 里的容器是 STL 标准模板库中用来存储数据的类，比如 vector、list、map；Java 里的容器指 Collection 集合框架，比如 List、Set、Map。它们是程序运行在内存中的数据组织方式。Docker 容器则是一个操作系统层面的隔离运行时，拥有自己的文件系统、进程空间、网络栈和资源限制。两者完全不同，只是都叫“容器”。如果面试时把 Docker 容器说成“一种存储数据的结构”，会非常尴尬。

2.3 Docker 与虚拟机的核心差异

很多人拿 Docker 和虚拟机对比。虚拟机里跑的是一个完整的操作系统，需要占用大量内存和磁盘；Docker 容器共享宿主机内核，没有独立的操作系统，所以启动速度是秒级，资源占用也更小。

可以这样理解：虚拟机是“在一套房子里再隔出几间带完整家具的小房子”，Docker 是“大家住在一个大客厅里，但每个人有自己的隔间和行李”。隔离性上虚拟机更强，但 Docker 在开发效率、部署速度和资源利用率上优势明显。对于“双栈工坊”这类需要快速启动多个开发服务的场景，Docker 是更合适的选择。

3. 环境准备与前置条件

动手操作之前，先准备 Docker 运行环境。不同操作系统安装方式差别很大，这里只讲关键步骤和容易出错的点。

3.1 Windows 环境安装 Docker Desktop

Windows 上最主流的方式是安装 Docker Desktop。安装前需要确保 Windows 版本满足要求，家庭版通常需要开启 WSL2，专业版/企业版可以使用 Hyper-V。

安装步骤可以简化为四步：下载 Docker Desktop 安装包并运行；安装时勾选“使用 WSL 2 代替 Hyper-V”（如果版本支持）；安装完成后重启电脑；启动 Docker Desktop，等待右下角鲸鱼图标变绿，表示引擎已启动。

这里有一个非常高频的报错，搜索热词里也反复出现：Docker Desktop failed to start because virtualisation support wasn't detected。这个报错的意思是系统没有检测到虚拟化支持。排查路径是：进入 BIOS/UEFI，找到 Intel Virtualization Technology 或 AMD SVM Mode，将它开启；然后在 Windows 功能里确认“适用于 Linux 的 Windows 子系统”和“虚拟机平台”两个选项已勾选启用；最后确认 WSL2 已安装。

3.2 Linux 环境安装 Docker Engine

Linux 服务器上更推荐安装 Docker Engine，而不是 Docker Desktop。以 Ubuntu 为例，标准安装流程需要更新 apt 索引、安装依赖包、添加 Docker 官方 GPG 密钥和仓库、最后安装 docker-ce。

安装完成后需要将当前用户加入 docker 用户组，否则每次执行 docker 命令都要加 sudo：

sudo usermod -aG docker $USER newgrp docker

加入用户组后重新登录终端，执行docker version验证是否成功。

3.3 验证 Docker 是否安装成功

无论哪个系统，安装完成后都需要做一个最小验证。在终端执行：

docker --version docker compose version docker info

如果docker info能正常输出 Docker 引擎信息，说明环境已经就绪。接下来可以拉取一个最小镜像测试：

docker run hello-world

如果输出Hello from Docker!，说明 Docker 能正常拉取镜像并运行容器，整套环境没有问题。

4. 核心流程拆解：从镜像拉取到容器运行

环境准备好之后，开始掌握 Docker 的核心操作流程。这里按“镜像管理、容器生命周期、端口映射、数据持久化”四个环节拆解。

4.1 镜像管理

镜像管理是 Docker 使用频率最高的操作，尤其是刚接触 Docker 的同学，大部分时间都在和镜像打交道。

命令	作用
`docker pull 镜像名:标签`	从镜像仓库拉取镜像
`docker images`	查看本地所有镜像
`docker rmi 镜像ID`	删除本地镜像
`docker search 关键词`	搜索镜像仓库中的镜像

拉取镜像示例：

docker pull mysql:8.0 docker pull redis:7.2-alpine docker pull python:3.11-slim

这里有两个值得注意的细节。第一，标签不要写latest。latest是动态标签，今天拉和半年后拉的内容可能完全不同，这会导致环境不一致。生产环境一定要固定具体版本，比如mysql:8.0.36。第二，alpine后缀表示基于 Alpine Linux 的精简镜像，体积更小，适合对系统库依赖不复杂的场景。

4.2 容器生命周期

容器生命周期是 Docker 操作的核心，主要包括创建、启动、查看、停止、删除。

命令	作用
`docker run`	创建并启动一个新容器
`docker ps`	查看正在运行的容器
`docker ps -a`	查看所有容器，包括已停止的
`docker start 容器名`	启动已存在的容器
`docker stop 容器名`	停止容器
`docker rm 容器名`	删除已停止的容器
`docker logs 容器名`	查看容器日志

最常用的是docker run，它有很多参数，下面通过一个部署 MySQL 的完整例子来理解。在“双栈工坊”项目中，MySQL 是核心数据服务，部署命令如下：

docker run -d \ --name shuangstack-mysql \ -e MYSQL_ROOT_PASSWORD=root123456 \ -e MYSQL_DATABASE=shuangstack \ -e MYSQL_USER=app \ -e MYSQL_PASSWORD=app123456 \ -p 3306:3306 \ -v mysql_data:/var/lib/mysql \ mysql:8.0

每个参数的含义需要真正理解：-d表示后台运行；--name给容器命名；-e设置环境变量，MySQL 镜像通过环境变量完成初始化；-p 3306:3306把宿主机的 3306 端口映射到容器内的 3306；-v mysql_data:/var/lib/mysql把数据持久化到名为mysql_data的命名卷中。

4.3 端口映射和网络通信

默认情况下，容器有自己的网络空间，宿主机的网络无法直接访问容器内部。想让外部访问容器内的服务，必须做端口映射。

端口映射的格式是宿主机端口:容器端口。比如-p 3306:3306，宿主机上访问localhost:3306，请求会被转发到容器的 3306 端口。

如果端口被占用，可以改成其他宿主机端口：

docker run -d -p 3307:3306 --name mysql8 mysql:8.0

这样宿主机就要访问localhost:3307。

容器之间通信有另一套逻辑。同一个自定义网络下的容器，可以通过“容器名”互相访问，不需要再映射端口。这一点在使用 Docker Compose 编排时非常重要，因为 MySQL 服务名就是后端代码里的数据库地址。

4.4 数据持久化与备份

数据持久化是容器化部署中最容易出问题的地方。如果只是用docker run mysql:8.0启动 MySQL，没有挂载数据卷，那么这个 MySQL 容器一旦被删除，所有数据库数据都会消失，无法找回。

前面使用的-v mysql_data:/var/lib/mysql就是解决这个问题。mysql_data是命名卷，由 Docker 管理，存放在宿主机的 Docker 目录中。容器删除后，命名卷里的数据依然存在，下次用同一个卷名启动新容器，数据就还在。

用 docker run 方式要记住这个规则：有状态服务必须挂载数据卷。对于数据库、缓存、消息队列这类服务，如果你没有把握确认数据目录在哪，先查镜像文档；查不到就用全量数据路径挂载，宁可多挂也不要漏挂。

5. 完整示例与代码实现

前面的命令是打基础。现在模拟“双栈工坊”的真实项目，用 Docker Compose 一键部署四个服务：MySQL 数据库、Redis 缓存、Python 后端 API、Vue/React 前端页面。这就是本文标题里“管理部署容器”最直接的落地方式。

5.1 项目目录结构

shuangstack-workshop/ ├── docker-compose.yml ├── init.sql ├── backend/ │ ├── Dockerfile │ ├── requirements.txt │ └── app/ │ └── main.py └── frontend/ ├── Dockerfile ├── nginx.conf └── dist/

5.2 编写 docker-compose.yml

在项目根目录创建docker-compose.yml：

# 文件路径：shuangstack-workshop/docker-compose.yml services: mysql: image: mysql:8.0 container_name: sf-mysql restart: unless-stopped environment: MYSQL_ROOT_PASSWORD: root123456 MYSQL_DATABASE: shuangstack MYSQL_USER: app MYSQL_PASSWORD: app123456 volumes: - mysql_data:/var/lib/mysql - ./init.sql:/docker-entrypoint-initdb.d/init.sql:ro ports: - "3306:3306" networks: - sf-network healthcheck: test: ["CMD", "mysqladmin", "ping", "-h", "localhost"] interval: 5s timeout: 3s retries: 20 redis: image: redis:7.2-alpine container_name: sf-redis restart: unless-stopped command: ["redis-server", "--appendonly", "yes"] volumes: - redis_data:/data ports: - "6379:6379" networks: - sf-network backend: build: context: ./backend container_name: sf-backend restart: unless-stopped depends_on: mysql: condition: service_healthy redis: condition: service_started environment: DB_HOST: mysql DB_PORT: 3306 DB_NAME: shuangstack DB_USER: app DB_PASSWORD: app123456 REDIS_HOST: redis REDIS_PORT: 6379 ports: - "8080:8080" networks: - sf-network frontend: build: context: ./frontend container_name: sf-frontend restart: unless-stopped ports: - "3000:80" depends_on: - backend networks: - sf-network volumes: mysql_data: redis_data: networks: sf-network: driver: bridge

这段配置有几个关键点需要解释。

services定义四个服务，每个服务对应一个容器。build.context指定构建镜像的目录，Compose 会读取该目录下的 Dockerfile 自动构建。environment是环境变量，后端连接数据库用的地址是服务名mysql，而不是localhost，这是 Compose 网络自动完成的容器间解析。depends_on控制启动顺序，condition: service_healthy表示要等 MySQL 健康检查通过后才启动后端，避免后端启动时数据库还没就绪而崩溃。

5.3 编写后端 Dockerfile

后端使用 Python 的 FastAPI 框架做一个最小 API 服务，逻辑很简单：启动时连接 MySQL 和 Redis，提供一个返回当前服务状态的接口。

创建backend/requirements.txt：

fastapi==0.115.0 uvicorn==0.30.6 pymysql==1.1.1 redis==5.0.8 cryptography==43.0.1

创建backend/Dockerfile：

# 文件路径：backend/Dockerfile FROM python:3.11-slim WORKDIR /app ENV PYTHONDONTWRITEBYTECODE=1 \ PYTHONUNBUFFERED=1 COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . EXPOSE 8080 CMD ["uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "8080"]

创建后端主程序backend/app/main.py：

# 文件路径：backend/app/main.py import os import time import redis import pymysql from fastapi import FastAPI app = FastAPI() def get_db_connection(): return pymysql.connect( host=os.getenv("DB_HOST", "localhost"), port=int(os.getenv("DB_PORT", "3306")), user=os.getenv("DB_USER", "app"), password=os.getenv("DB_PASSWORD", "app123456"), database=os.getenv("DB_NAME", "shuangstack"), charset="utf8mb4", cursorclass=pymysql.cursors.DictCursor, ) def get_redis_client(): return redis.Redis( host=os.getenv("REDIS_HOST", "localhost"), port=int(os.getenv("REDIS_PORT", "6379")), decode_responses=True, ) @app.get("/") def read_root(): return {"message": "Shuangstack Workshop API is running"} @app.get("/health") def health_check(): status = {"mysql": "down", "redis": "down"} try: conn = get_db_connection() with conn.cursor() as cursor: cursor.execute("SELECT 1") cursor.fetchone() conn.close() status["mysql"] = "up" except Exception as e: status["mysql_error"] = str(e) try: r = get_redis_client() r.ping() status["redis"] = "up" except Exception as e: status["redis_error"] = str(e) return status if __name__ == "__main__": import uvicorn uvicorn.run("app.main:app", host="0.0.0.0", port=8080)

这个示例代码并没有引入复杂的业务逻辑，目的是验证容器间网络、数据库连接、Redis 连接是否正常。/health接口会实际探测 MySQL 和 Redis，只要这个接口返回两个up，就说明整套容器编排是通的。

5.4 编写前端 Dockerfile 和 Nginx 配置

前端项目重点是构建产物加 Nginx 静态托管。在真实项目中，前端源码通过npm run build生成dist目录。这里直接用 Dockerfile 完成构建和托管两个阶段。

创建frontend/Dockerfile：

# 文件路径：frontend/Dockerfile FROM node:20-alpine AS builder WORKDIR /app COPY package.json package-lock.json ./ RUN npm install COPY . . RUN npm run build FROM nginx:1.27-alpine COPY --from=builder /app/dist /usr/share/nginx/html COPY nginx.conf /etc/nginx/conf.d/default.conf EXPOSE 80

创建frontend/nginx.conf：

server { listen 80; server_name localhost; root /usr/share/nginx/html; index index.html; location / { try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://backend:8080/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }

proxy_pass http://backend:8080/实现前端请求的反向代理，backend是 Compose 网络中的服务名，浏览器不需要直接访问后端端口。

5.5 创建 MySQL 初始化脚本

创建init.sql，用于 MySQL 容器首次启动时自动建表：

-- 文件路径：shuangstack-workshop/init.sql USE shuangstack; CREATE TABLE IF NOT EXISTS user ( id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(64) NOT NULL, email VARCHAR(128) NOT NULL UNIQUE, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; INSERT INTO user (name, email) VALUES ('admin', 'admin@shuangstack.local');

MySQL 官方镜像会首次启动时执行/docker-entrypoint-initdb.d/目录下的.sql脚本，这是镜像内置机制，不需要额外配置。

5.6 启动命令

全部文件准备好后，在项目根目录执行：

docker compose up -d --build

解释一下：-d是后台运行，--build是启动前重新构建镜像。第一次执行会拉取镜像并构建，耗时取决于网络和机器性能。如果只想看日志，用docker compose up不加-d，前台运行可以直接看到输出，方便调试。

5.7 停止和清理命令

# 停止所有容器 docker compose down # 停止并删除容器、网络，但保留数据卷 docker compose down # 停止并删除容器、网络、数据卷（危险，数据会丢） docker compose down -v

down -v会连数据卷一起删除，执行前必须确认数据不需要保留。

6. 运行结果与效果验证

6.1 查看容器状态

启动完成后，查看所有容器运行状态：

docker compose ps

预期输出四个服务状态都为running。如果某个服务处于restarting或exited，说明启动过程中出现了问题，第一时间用下面的命令查看日志。

6.2 验证后端连接数据库和 Redis

在后端容器运行后，请求健康检查接口：

curl http://localhost:8080/health

如果一切正常，返回：

{"mysql": "up", "redis": "up"}

这一步说明后端容器能通过mysql和redis服务名访问数据库与缓存，容器间网络通信正常。

6.3 验证前端页面

浏览器访问http://localhost:3000，能看到前端页面。打开一个需要请求后端的操作，打开浏览器开发者工具 Network 面板，确认http://localhost:3000/api/...的请求由 Nginx 转发到后端服务成功。

6.4 验证数据持久化

执行一条 SQL 写入数据，然后删除容器重建，确认数据还在。先在 MySQL 容器中插入一条记录：

docker exec -it sf-mysql mysql -uapp -papp123456 shuangstack \ -e "INSERT INTO user (name, email) VALUES ('test', 'test@shuangstack.local');"

然后停止并删除 MySQL 容器，再启动：

docker compose stop mysql docker compose rm mysql docker compose up -d mysql

启动后查询数据：

docker exec -it sf-mysql mysql -uapp -papp123456 shuangstack \ -e "SELECT * FROM user;"

如果之前插入的数据还在，说明mysql_data命名卷生效，数据持久化成功。

6.5 查看实时日志

需要观察服务运行状态时，查看日志：

# 查看所有服务日志 docker compose logs -f # 只查看后端日志 docker compose logs -f backend

Java 或 Python 容器出现异常重启时，日志里的堆栈和错误信息是排错的第一入口。

7. 常见问题与排查思路

下面是 Docker 容器管理部署中最常见的几类问题，按优先级整理成表格。

问题现象	可能原因	排查方式	解决方案
镜像拉取非常慢或超时	网络原因，默认镜像仓库访问不稳定	观察`docker pull`输出	为 Docker 配置镜像加速器，Docker Desktop 或`/etc/docker/daemon.json`中设置 registry-mirrors
Docker Desktop 启动报 virtualisation support wasn't detected	BIOS/UEFI 未开启虚拟化，或 WSL2/虚拟机平台未启用	检查 Windows 功能、BIOS 设置	开启 CPU 虚拟化，启用“适用于 Linux 的 Windows 子系统”和“虚拟机平台”，重装 WSL2
Windows 提示 incompatible version of Windows	Windows 版本过低，不满足 Docker Desktop 要求	查看 Windows 版本号	升级到受支持的 Windows 版本，或改用 Docker Toolbox 旧方案（不推荐）
容器启动后立即退出	应用启动失败、连接依赖服务超时、端口被占用	`docker logs 容器名`查看退出日志	根据日志修依赖服务地址、端口或环境变量；使用`depends_on`加健康检查控制启动顺序
宿主机访问不到容器端口	未做端口映射，或防火墙拦截	`docker ps`查看 PORTS 列、测试`curl localhost:端口`	用`-p 宿主机端口:容器端口`重新启动容器，检查防火墙
容器访问外部地址失败	DNS 配置错误、网络模式限制	`docker exec 容器名 ping 域名`	为容器指定 DNS，如`--dns 223.5.5.5`，或检查宿主机防火墙
MySQL 8.0 连接报 caching_sha2_password 错误	MySQL 8.0 默认认证插件是 caching_sha2_password	检查数据库连接日志	创建用户时指定`mysql_native_password`认证插件，或升级客户端驱动
删除容器后数据库数据丢失	没有挂载数据卷	检查启动命令是否包含`-v`	使用命名卷或 bind mount 持久化数据，数据无价

这里特别想强调两点。第一，docker run启动失败时，不要盲目删容器重来，第一步永远是docker logs。第二，在 Linux 服务器上操作 MySQL、生产数据库时，删除容器属于危险操作，建议先备份数据卷或使用docker rename保留容器再排查。

8. 最佳实践与工程建议

8.1 镜像管理：固定版本、多阶段构建、使用可信镜像

镜像管理直接关系到安全和稳定性。

第一，不要在生产环境使用latest标签。任何镜像都要固定到具体版本，比如mysql:8.0.36、nginx:1.27.4，这样镜像内容可预期、可回滚。

第二，Dockerfile 优先使用多阶段构建。前端构建需要 Node 环境，但运行只需要 Nginx；后端构建需要编译工具，但运行只需要运行时。多阶段构建能显著减小最终镜像体积。

第三，只从可信来源拉取镜像。Docker Hub 上有大量镜像，但安全性参差不齐。优先选择官方镜像（如mysql、redis、nginx），或经过验证的知名开源项目镜像，避免使用来路不明的第三方镜像，防止镜像被植入恶意脚本。

8.2 容器安全：最小权限、最小暴露、不覆盖缺失配置

容器不是越权运行的免罪符。一个容易被忽视的问题是：容器中运行的应用默认是 root 用户，这扩大了攻击面。更稳妥的做法是在 Dockerfile 中创建普通用户，并用USER指令切换。

减少端口暴露也是重要的安全习惯。ports中只映射必要的宿主机端口。比如后端 API 如果只给前端容器通过内网访问，就不需要映射到宿主机。Redis 默认没有密码，如果直接映射到宿主机，可能被扫描器攻击，建议设置requirepass或用仅内网访问的端口映射方式。

8.3 数据持久化与备份

数据库、文件存储这类有状态服务，必须使用数据卷或绑定挂载。生产环境建议把数据卷目录纳入定时备份策略中。

备份可以简单分两步：一是利用 Docker 自身的卷复制机制；二是直接用数据库自带工具备份，比如 MySQL 的mysqldump。容器化不等于不需要备份，反而因为容器删除太方便，备份更要前置。

8.4 日志与监控

容器日志默认写到 stdout/stderr，使用docker logs即可查看。后端 Java 应用建议把日志输出到 stdout，而不是写容器内文件。如果应用 JVM 异常重启，排查顺序是：先docker ps看容器状态，再docker logs 容器名看 JVM 崩溃日志，必要时用docker stats查看资源占用。

8.5 资源限制

不设置资源限制的容器可能把宿主机内存吃满。生产环境推荐在 compose 文件中为每个服务设置资源限制：

services: backend: deploy: resources: limits: memory: 512M cpus: "0.5"

这样即使后端出现内存泄漏，也不会拖垮宿主机上的其他容器。

8.6 开发阶段的热更新

“双栈工坊”这类团队在开发阶段经常需要频繁修改代码，重新构建镜像很浪费时间。Compose 支持开发模式热更新，一种方式是挂载源码到容器并用开发服务器运行（如uvicorn --reload），另一种是使用 Compose 的watch功能自动同步代码到容器。开发与生产配置建议拆分，生产环境保持构建镜像的方式，开发环境使用源码挂载提升效率。

9. 总结与后续学习方向

通过“双栈工坊”的完整例子，本文把 Docker 管理部署容器的核心链路走了一遍：镜像与容器的关系、环境准备、镜像拉取、容器运行、端口映射、数据持久化，再到 Docker Compose 一键编排多服务，最后是常见问题排查和最佳实践。

真正重要的判断是：Docker 不是把软件“装”到一个容器里那么简单，它把环境变成了可版本化、可分发、可回滚的资产。对开发团队来说，环境一致性的价值远大于少敲几条命令。

下一步值得学习的知识方向包括：Dockerfile 多阶段构建技巧；容器网络模型（bridge、host、none 的区别）；容器健康检查与启动依赖的正确姿势；镜像仓库私有化部署；以及服务规模变大以后 Kubernetes 是如何在容器之上做调度和编排的。

最后提醒一件事：如果你刚开始学 Docker，不要急着背命令，先老老实实把 MySQL、Redis 这类基础服务容器化跑通，再逐步加入自己的应用代码。容器技术本身不复杂，复杂的是把数据、网络、权限、安全和业务边界想清楚。把基础服务管好，你的“双栈工坊”就已经迈出了容器化管理最关键的一步。

企业官网建设流程全解析