企业官网建设流程全解析

1. 为什么我最终选择这套方案：CentOS 7 + Docker + IDEA 镜像部署

先说一下这套组合解决了什么问题。很多做 Java 后端的同学应该都有类似的经历：本地开发用的是 Windows 或 macOS，代码在 IntelliJ IDEA 里跑得好好的，Spring Boot 项目一启动就能访问，但一旦要把项目交给测试、部署到服务器，就各种踩坑——本地环境没问题、服务器上却起不来，端口被占用、JDK 版本不一致、依赖缺失，甚至操作系统层面的兼容性问题，光是排除这些环境差异就能耗掉大半天。

而 Docker 出现之后，这个问题被很好地解决了。把 Spring Boot 应用连同它依赖的 JRE、运行参数、配置文件一起打包成镜像，在任何装了 Docker 的机器上都能以一致的方式运行。但问题又来了：很多同学对 Docker 的认知停留在“听说过”“看过教程”，真要让它在自己的工作流里跑起来，需要一台 Linux 机器来承载 Docker 引擎。云服务器需要花钱，买实体机更不现实，这时候 VirtualBox 就派上用场了——在本机虚拟一台 CentOS 7，把 Docker 装进去，再用 IDEA 把 Spring Boot 项目构建成镜像丢进去跑，整个过程完全免费，还能随时销毁重建。

这套链路走通之后，你其实就掌握了一条非常完整的“本地开发 → 镜像构建 → 容器部署”的 DevOps 闭环。它适合谁？适合刚接触 Docker 的 Java 开发者，适合想模拟真实服务器部署环境又没有云服务器的学生党，也适合需要给团队做内部培训的工程师。这篇内容就是把我自己从头到尾踩过的坑、验证过的步骤、调试过的问题完整记录一遍，照着做基本不会卡死在半路上。

2. VirtualBox 搭建 CentOS 7：网络模式、系统安装与 SSH 连接

2.1 VirtualBox 虚拟机配置的参数选择与理由

VirtualBox 的安装和 CentOS 7 的 ISO 镜像下载我就不展开说了，网上一搜一大把，重点说创建虚拟机时的几个关键配置。

内存分配上，如果宿主机内存是 16GB，我给虚拟机划 2GB 到 4GB 都比较合理。Docker 引擎本身占用很小，真正吃内存的是 CentOS 7 系统 + 构建镜像时的编译压力。Spring Boot 镜像构建如果用 Dockerfile 方式，实际构建阶段是直接用宿主机（也就是 CentOS 7 虚拟机）上的 Maven 来打 jar 包吗？并不是，如果用多阶段构建的话，构建容器也需要内存。我当时给的是 4GB，跑起来很舒服，少于 2GB 的话，docker build过程中 Maven 构建容器可能会内存不足直接失败。

处理器核心数，建议给 2 核以上。Docker 镜像构建时 Maven 会有多线程下载依赖、编译模块，单核会非常煎熬。

磁盘容量这块，我给的是 20GB 动态分配。注意，CentOS 7 装完之后系统本身占 4-6GB，Docker 镜像和容器日志又会占一部分。如果你打算后面在虚拟机里再玩玩 Jenkins、GitLab 之类的，建议直接给 40GB 动态分配——VirtualBox 的“动态分配”意味着实际用了多少才占宿主机多少空间，所以别怕给大。

图形界面方面，CentOS 7 安装时可以选择 Minimal 版本，没有桌面环境，省资源。但我们后面要通过 SSH 连接操作，配好了网络就直接用终端操作，根本不需要图形界面。这也是很多新手不理解的地方——明明装了 VirtualBox 有窗口，为什么还要 SSH？原因很简单：真实服务器是没有屏幕的，你只能通过 SSH 操作，从一开始就养成这种习惯，后面上了云服务器自然无缝衔接。

2.2 网络模式选择：NAT + 桥接的取舍和最终方案

这是搭建过程中最容易困惑的一步。VirtualBox 给虚拟机提供了好几种网络模式，最常用的就是 NAT 和桥接。我直接说结论，如果你和我一样，只是为了在虚拟机里跑 Docker，然后被宿主机上的 IDEA 连接访问，推荐 Host-Only 加 NAT 的组合方式；但如果嫌麻烦，先用 NAT 模式配端口转发也行。

NAT 模式的本质是虚拟机通过宿主机共享一个内网 IP 出去，外部网络无法主动访问虚拟机，只能由虚拟机主动对外发起连接。好处是虚拟机可以上网，能拉取 Docker 镜像、下载软件包。坏处是宿主机访问虚拟机里的服务需要做端口转发，而且多端口转发配置起来比较繁琐。桥接模式则是让虚拟机直接和宿主机处在同一个局域网里，相当于虚拟机和宿主机都各自拿到了局域网 IP，互相访问零障碍，但桥接模式依赖的路由器 DHCP 环境，不同的办公网络下可能受限。

我当时图省事，直接在 NAT 模式下给 SSH（22 端口）加了一条端口转发规则。具体操作为：虚拟机设置 → 网络 → 高级 → 端口转发 → 添加规则，主机端口填 2222，子系统端口填 22。这样宿主机上执行ssh root@localhost -p 2222就能连进虚拟机里的 CentOS 7。

但这里有个大坑，后面部署 Spring Boot 容器的时候还会遇到：NAT 模式下，你每跑一个容器就要加一条端口转发，比如 8080 → 8080、3306 → 3306，非常不灵活。所以如果你确定要长期用这台虚拟机折腾东西，建议直接用桥接模式，或者干脆再加一块 Host-Only 网卡。我最后的稳定方案是"NAT + 桥接双网卡"：NAT 负责虚拟机上网，桥接负责宿主机和虚拟机互相访问。VirtualBox 允许一张网卡设成 NAT、另一张设成桥接，操作上完全没问题。

2.3 安装后的系统初始化：关防火墙、配时区、换源

CentOS 7 装完后，有一堆初始化工作要做。有些人装完就直接开始装 Docker，结果后面各种连接超时、下载慢、容器重启失败，其实很多问题在系统初始化阶段就可以避免。

第一个是防火墙。CentOS 7 默认带 firewalld，如果你在后面用端口转发方式访问容器服务，防火墙会把外部请求挡掉。我当时图省事，直接用systemctl stop firewalld和systemctl disable firewalld把防火墙关了。生产环境当然不建议这么干，但本地虚拟机折腾阶段，关掉防火墙能大幅降低入门门槛。

第二个是 SELinux。CentOS 7 默认开启 SELinux，它对文件权限的管控非常严格，Docker 容器挂载目录时经常出现权限不足的问题。我建议在/etc/selinux/config里把SELINUX=enforcing改成SELINUX=permissive，然后重启系统。这一步很多人忽略，后面跑容器挂载数据卷时就会莫名报Permission denied，排查半天才发现是这个。

第三个是 YUM 源。CentOS 7 默认的官方源在国内访问速度不稳定，建议直接换成国内镜像源。步骤是备份/etc/yum.repos.d/CentOS-Base.repo，然后下载对应版本的镜像源文件替换。替换后执行yum clean all && yum makecache。这一步做完，后面安装 Docker、安装依赖包的速度会有质的提升。

第四个是时区。Docker 容器默认时区是 UTC，和北京时间差 8 小时，Spring Boot 应用打出来的日志时间全是错的。虽然可以在 Dockerfile 里处理时区问题，但系统层面先统一一下更好：timedatectl set-timezone Asia/Shanghai。装完 Docker 后创建的容器，只要挂载了/etc/localtime就能自动对齐时间。

这几个步骤做完，记得拍一个 VirtualBox 快照。快照是白嫖的后悔药，后面如果 Docker 配置搞坏了、系统搞崩了，一键恢复比你重新装一遍系统省事一百倍。

3. CentOS 7 上部署 Docker：安装源、加速器与引擎验证

3.1 用官方脚本安装还是手动配源安装

Docker 的安装方式常见的有两种：官方脚本一键安装，或者手动配置 Docker 源后安装。我个人的建议是：在 CentOS 7 上，手动配置源安装，别用官方脚本。

官方脚本curl -fsSL https://get.docker.com | bash在国内环境经常因为网络原因卡住，或者下载的包不完整。而且官方脚本安装的 Docker 版本可能和你预期的不一致，出了问题不好定位。手动配源的好处是可控、可重复、方便后续指定版本。

CentOS 7 配置 Docker 源，网上有好几种写法，但核心就两步。先添加 YUM 仓库文件/etc/yum.repos.d/docker-ce.repo，内容指向国内镜像源；然后yum install -y docker-ce。我这里贴一下我用的配置：

sudo yum install -y yum-utils device-mapper-persistent-data lvm2 sudo yum-config-manager --add-repo https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo sudo sed -i 's/download.docker.com/mirrors.aliyun.com\/docker-ce/g' /etc/yum.repos.d/docker-ce.repo sudo yum makecache fast sudo yum install -y docker-ce

这里有个细节：yum-config-manager --add-repo默认添加的是 Docker 官方源，我们需要把它替换成国内镜像源，这就是第三行sed的作用。如果不执行这一步，后续yum install docker-ce会非常慢，甚至直接卡死在下载阶段。

3.2 Docker 启动、开机自启与镜像加速配置

Docker 装好之后，不会自动启动，必须手动执行：

sudo systemctl start docker sudo systemctl enable docker

enable这一步很关键，它把 Docker 服务注册为开机自启。否则虚拟机重启后 Docker 引擎不工作，容器全部处于停止状态，Spring Boot 服务就挂了。

启动后执行docker version验证引擎状态。看到Server: Docker Engine - Community部分正常显示版本号，说明引擎已经在运行了。这里有个小细节：docker version会同时显示 Client 和 Server 两个部分，如果 Server 部分报错或者显示Cannot connect to the Docker daemon，说明引擎没启动起来，先检查systemctl status docker看具体报错。

镜像加速配置也不能省。Docker 默认从 Docker Hub 拉取镜像，在国内网络环境下经常超时。配置/etc/docker/daemon.json，加入镜像加速器地址：

{ "registry-mirrors": [ "https://docker.m.daocloud.io", "https://dockerproxy.com", "https://docker.nju.edu.cn" ] }

改完重启 Docker：sudo systemctl daemon-reload && sudo systemctl restart docker。配置镜像加速后，拉取openjdk:8-jdk-alpine这类基础镜像的速度会有质的提升，完整日志里能看到是从镜像加速器地址下载的。

3.3 用 hello-world 和 alpine 验证 Docker 可用性

配置完后，先拉一个极小的测试镜像验证可用性：

docker pull hello-world docker run hello-world

这个镜像非常小，主要用来验证 Docker 引擎能否正常拉取镜像、创建容器、运行程序。看到Hello from Docker!的输出就算通过。接着再拉一个alpine镜像：

docker pull alpine docker run -it alpine /bin/sh

alpine是一个体积只有几 MB 的极简 Linux，运行它主要是验证交互式容器的创建和进入能正常工作。能在容器内执行cat /etc/os-release，看到 Alpine Linux 的版本信息，说明 Docker 的容器创建能力没问题，可以进入下一步了。

4. IntelliJ IDEA 构建 Spring Boot 镜像：三种方案对比与 Dockerfile 编写

4.1 为什么不用 Maven 插件直接构建，而是用 Dockerfile

到了这一步，核心问题来了：怎么把 IDEA 里的 Spring Boot 项目变成 Docker 镜像？

主流的方案有三条路。第一条是用 Maven 插件，比如dockerfile-maven-plugin或者com.spotify的docker-maven-plugin，在pom.xml里配置好，然后mvn package docker:build一条命令完成构建。第二条是用 IDEA 自带的 Docker 插件——把 Docker 引擎的连接信息配置到 IDEA 里，然后在编辑器里右键Dockerfile直接 Build Image。第三条是手动写 Dockerfile，然后通过命令行docker build构建。

三条路我全都试过。第一条方案的问题在于插件配置繁琐，docker-maven-plugin已经多年不更新，在新版 IDEA 和高版本 Docker 下有兼容性隐患；而且插件需要在 pom 里加一堆 docker 相关的依赖配置，耦合度太高。第二条方案体验最好，但 IDEA 里操作 Docker 构建镜像，需要 IDEA 能连上虚拟机里的 Docker 引擎，这涉及 Docker 对外开放 TCP 端口的配置，有安全风险，而且一旦 IDEA 里配置的连接串出错，报错信息不够直观。第三条方案看起来“土”，但最符合生产环境的真实操作——你在 CI/CD 流水线里写 Dockerfile 构建镜像，本来就是在命令行做的。

所以我的推荐是：日常开发调试用第三种方案，手动写 Dockerfile 用命令行构建。但为了让构建过程更顺畅，IDEA 里也可以配置远程 Docker 连接，方便查看镜像和容器状态。

4.2 手写一个生产可用的 Spring Boot Dockerfile

这里我给出一个我实际在用的 Dockerfile 模板。它在多阶段构建和依赖缓存这两点上花了不少心思。

# 1. 构建阶段：用 Maven 镜像编译 Spring Boot 应用 FROM maven:3.8.6-openjdk-8 AS builder WORKDIR /app # 2. 先复制 pom.xml，单独的依赖下载阶段，利用 Docker 层缓存 COPY pom.xml . RUN mvn dependency:go-offline # 3. 复制源码并打包 COPY src ./src RUN mvn clean package -DskipTests # 4. 运行阶段：用轻量的 JRE 镜像 FROM openjdk:8-jdk-alpine WORKDIR /app # 5. 设置时区，避免容器和宿主机时间差 8 小时 RUN apk add --no-cache tzdata \ && cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime \ && echo "Asia/Shanghai" > /etc/timezone # 6. 从构建阶段复制 jar 包 COPY --from=builder /app/target/*.jar app.jar # 7. 暴露端口 EXPOSE 8080 # 8. 启动命令 ENTRYPOINT ["java", "-jar", "app.jar"]

这个 Dockerfile 有两个设计点值得说明：

第一个是多阶段构建。第一阶段用maven:3.8.6-openjdk-8这个包含了 Maven 和 JDK 的完整镜像来编译项目，第二阶段只留一个openjdk:8-jdk-alpine的轻量运行环境。这样最终镜像不会包含 Maven、编译中间文件，体积小很多。alpine版本号称只有 100 多 MB，相比直接用带 Maven 的镜像少了 300MB 不止。

第二个是dependency:go-offline这一步。把pom.xml先复制进容器，单独执行一次依赖下载，这样如果源码改了但 pom 没变，Docker 会直接命中缓存层，不会重新下载依赖。我实测下来，缓存命中的前提下，整个docker build时间可以从 5 分钟缩短到 30 秒。

4.3 IDEA 中操作 Docker：连接配置与镜像构建

虽然推荐命令行构建，但 IDEA 里连上 Docker 引擎后，管理镜像和容器会有很大的便利性。IDEA 连接 Docker 的配置在Settings → Build, Execution, Deployment → Docker，填入tcp://192.168.56.101:2375就可以了。

但要让 IDEA 能连上虚拟机的 Docker，Docker 引擎需要对外开放 TCP 接口。这需要修改 Docker 服务配置：

sudo mkdir -p /etc/systemd/system/docker.service.d sudo vim /etc/systemd/system/docker.service.d/override.conf

写入以下内容：

[Service] ExecStart= ExecStart=/usr/bin/dockerd -H unix:///var/run/docker.sock -H tcp://0.0.0.0:2375

然后重启：

sudo systemctl daemon-reload sudo systemctl restart docker

注意，-H tcp://0.0.0.0:2375意味着虚拟机里的 Docker 引擎对网络上的所有主机开放了管理端口，这是有安全风险的。本地虚拟机环境可以接受，生产环境绝对不要这么干。更安全的做法是用 TLS 加密，或者只在本地用 SSH 隧道。我本地这么干纯粹是因为虚拟网络环境隔离，图省事。

配置好之后，IDEA 的 Docker 面板能看到镜像列表、容器列表、日志流，还能直接在编辑器里对 Dockerfile 右键Run on Docker。但构建镜像时，IDEA 其实也是调用 Docker 引擎去 build，和命令行跑docker build没本质区别。所以我平时构建还是用命令行，IDEA 只用来观察容器日志和状态，因为这个界面比docker logs -f直观很多。

4.4 手动构建 Spring Boot 镜像

在 IDEA 终端里进入项目根目录，直接执行：

docker build -t springboot-demo:latest .

-t参数给镜像打标签，springboot-demo:latest中冒号前是仓库名，冒号后是版本标签，.表示当前目录作为构建上下文。构建过程会看到分步骤执行，每一步的输出前面都有一个Step N/8的编号，对应 Dockerfile 里的指令。

构建过程中最容易遇到的问题就是依赖下载卡住。如果 Maven 镜像源用默认的中央仓库，下载速度会很考验耐心。解决办法是在pom.xml里配置阿里云镜像，或者更直接的方式是在settings.xml里配置镜像源。但这属于项目本身的问题，和 Docker 构建没有直接关系。另一个问题是构建上下文太大——如果项目目录下有.git目录和target目录，docker build命令会把它们全部传到 Docker 引擎，速度慢且容易出问题。正确的做法是写一个.dockerignore文件，排除这些目录：

target/ .git/ .idea/ *.iml

target目录尤其要排除，因为里面有项目编译后的 class 文件、jar 包，动辄几十上百 MB，根本不需要传给 Docker 引擎。

构建完成后，执行docker images就能看到springboot-demo镜像已经生成了，大约 200MB 大小。这比直接用 fat jar 的方式镜像体积小不少，也印证了多阶段构建的价值。

5. 从镜像到容器：启动 Spring Boot 服务与端口映射排查

5.1 启动容器时必须要面对的端口映射问题

镜像构建完成只是第一步，真正跑起来才是考验。启动容器：

docker run -d --name demo -p 8080:8080 springboot-demo:latest

-d表示后台运行，--name给容器取个名字方便后续管理，-p 8080:8080把宿主机的 8080 端口映射到容器的 8080 端口。

这里要再提一下前面说的网络模式问题。如果你用的是 NAT 模式的 VirtualBox，虚拟机里的 8080 端口还不能被宿主机直接访问，必须在 VirtualBox 的端口转发规则里再添加一条：主机端口 8080 转发到子系统端口 8080。用桥接模式的话，虚拟机和宿主机在同一个网段，宿主机直接访问虚拟机的 IP 加端口就行。

启动后执行docker ps查看容器状态。看到Status: Up的绿色状态说明容器在运行中。但还在运行不等于服务可用，Spring Boot 应用启动需要时间，通常 10-30 秒，这个阶段如果立刻访问会连接拒绝，这是正常的。

为了确认容器是否就绪，我一般这样检查：

docker logs -f demo

看到Started DemoApplication in X seconds的日志，说明应用启动成功。这时候再去浏览器访问http://虚拟机IP:8080，如果项目的 Application 配置了/hello接口，可以在后面拼上路径验证。

5.2 宿主机访问不了容器服务的排查路径

这一步是我见过最多的踩坑环节。我梳理一下典型问题，按排查顺序排好：

第一，Docker 容器是否正常启动。docker ps -a查看容器状态。如果显示Exited，说明容器启动后崩了，用docker logs demo查日志。最常见的原因是 Spring Boot 应用端口被占用，或者 jar 包启动参数有问题。我们前面的 Dockerfile 直接用ENTRYPOINT ["java", "-jar", "app.jar"]，如果项目依赖了外部数据库，数据库连不上也会导致启动失败。

第二，宿主机能否 ping 通虚拟机。ping 虚拟机IP，不通用就排查网络模式配置。桥接模式下要注意虚拟机 IP 是否和宿主机在同一个网段，NAT 模式则必须依赖端口转发。

第三，虚拟机上直接访问服务是否正常。在虚拟机里执行curl http://localhost:8080/你的接口路径。如果虚拟机本地访问正常，说明容器没问题，问题出在宿主机到虚拟机的网络链路；如果虚拟机本地访问都不正常，说明应用本身有问题，继续查日志。

第四，防火墙是否拦截。前面说初始化时关掉了 firewalld，但如果没关，需要在firewall-cmd里放行 8080 端口：

sudo firewall-cmd --zone=public --add-port=8080/tcp --permanent sudo firewall-cmd --reload

第五，端口映射是否冲突。-p 8080:8080映射的是宿主机 8080 端口，如果虚拟机里已经有一个服务占用了 8080，会映射失败。我用netstat -tlnp | grep 8080查占用情况。

这一套走完，90% 的访问不了问题都能定位到。

5.3 容器的启动、停止、重启与删除操作记录

部署过程中，容器的生命周期管理也是高频操作。几个最常用的命令我记录在这里：

# 停止容器 docker stop demo # 启动已停止的容器 docker start demo # 重启容器 docker restart demo # 删除容器（需先停止） docker rm demo # 删除镜像 docker rmi springboot-demo:latest # 进入容器内部 docker exec -it demo /bin/sh

需要特别提醒的是，docker exec进入容器后，看到的是容器内的文件系统，不是宿主机。很多新手进去之后找不到项目文件，其实应该看/app/app.jar，容器的工作目录已经在 Dockerfile 里用WORKDIR /app指定了。

还有一个我经常用的技巧：如果容器启动失败，想在启动时临时覆盖启动命令来排查，可以这样：

docker run -it --entrypoint /bin/sh springboot-demo:latest

这会跳过 Dockerfile 里的启动命令，直接进入一个 shell，可以在容器内手动执行java -jar app.jar观察报错。

6. 基于镜像的迭代开发：重新构建与增量更新

6.1 改代码后如何最快地重新部署

实际开发中，代码总会改的。改完之后重新部署的完整链路是这样的：

mvn clean package -DskipTests docker build -t springboot-demo:v2.0 . docker stop demo docker rm demo docker run -d --name demo -p 8080:8080 springboot-demo:v2.0

这五条命令就是一次标准的迭代。docker build打好新镜像，docker stop停旧容器，docker rm删掉旧容器，再docker run用新镜像创建容器。之所以要先 stop 再 rm，是因为 Docker 不允许直接删一个正在运行的容器。

但每次都要手动执行五条命令，太繁琐了。我后来优化了一下，写了一个简单的部署脚本deploy.sh：

#!/bin/bash mvn clean package -DskipTests && \ docker build -t springboot-demo:latest . && \ docker stop demo || true && \ docker rm demo || true && \ docker run -d --name demo -p 8080:8080 springboot-demo:latest

注意|| true的用法：如果容器不存在，docker stop demo会报错，但脚本不想因为这个错误停下来，所以加上|| true让它继续执行。这个脚本能省掉很多重复操作，尤其是在频繁调试的时候，效率提升非常明显。

6.2 镜像层的复用原理：为什么第二次构建快这么多

接触过几次docker build后，你可能会有个疑问：为什么第一次构建要下载依赖、编译打包，花了好几分钟，第二次快得离谱？

这得益于 Docker 的分层存储机制。Dockerfile 里每一行指令都会生成一个只读层，后面的层会复用前面已有的层。比如我们的 Dockerfile 里，COPY pom.xml .和RUN mvn dependency:go-offline这两步，只要pom.xml文件没有变化，Docker 就直接复用上次构建缓存下来的层，跳过依赖下载。COPY src ./src这一步，只要源码有任何改动，这个层和后面的层就会全部重建。

但如果每次构建都把所有依赖重新下，那不仅浪费时间，还会因为网络问题时不时失败。利用好这个缓存机制，能让开发效率大幅提升。前面 Dockerfile 里我特意把COPY pom.xml放在COPY src前面，目的就在这里。

还有一个细节：COPY --from=builder /app/target/*.jar app.jar这一层，只要 jar 包的内容变了，最终层就会重建，这也意味着镜像是新的，和旧镜像的 ID 不一样。

6.3 清理镜像和容器占用的磁盘空间

经过几轮迭代更新，虚拟机的磁盘会被各种悬空镜像、旧容器、构建缓存占满。我吃过一次亏：构建一个新的镜像时提示no space left on device，查了半天发现是/var/lib/docker目录满了。

清理方式：

# 删除所有已停止的容器 docker container prune # 删除所有悬空镜像（没有标签且没有容器引用的镜像） docker image prune # 清理所有未被使用的资源 docker system prune -a

docker system prune -a是核弹级的，它会删除所有未被正在运行的容器使用的镜像，连着旧版本镜像一起删掉，所以执行之前要仔细确认。我平时的习惯是，保留最近一个版本的镜像，把更早的旧镜像手动删掉：

docker rmi springboot-demo:v1.0 springboot-demo:v1.1

如果构建时使用了 BuildKit，构建缓存也会占空间，用docker builder prune -f清理。

7. 我踩过的坑与最后的操作建议

7.1 典型问题速查与排查记录

把这段时间踩过的坑整理成一张表，方便后面遇到问题直接对着查：

7.2 关于这套方案后续还能怎么扩展

这套 VirtualBox + Docker + IDEA 的环境搭好之后，其实不只是部署一个 Spring Boot 项目这么简单。

最直接的扩展是引入 Docker Compose。如果项目依赖 MySQL、Redis，可以写一个docker-compose.yml，把数据库、缓存、应用编排在一起，一次命令全部启动。这对本地开发联调非常有用。

再进一步，可以在虚拟机里装一个 Jenkins，把“代码提交 → 自动构建镜像 → 自动部署容器”的流水线串起来。前端同学也可以用这套环境部署 Nginx + 静态资源，把前后端分离的环境全部在虚拟机里模拟出来。只要有 Docker，整个服务的部署逻辑都是相通的。

我自己在这套环境上反复折腾了一段时间后，最大的体会是：Docker 本身不难，难的是那些隐藏在网络、权限、存储、时区这些地底下的细节。把这些细节都搞清楚之后，再去看生产环境里 Kubernetes 那套东西，理解起来会轻松很多。

7.3 给新手的三个实操建议

最后分享三个我觉得最重要的建议。

第一，遇到问题先看日志。不管是docker logs看容器日志，还是journalctl -u docker看 Docker 引擎日志，日志永远是定位问题的第一入口。不要凭感觉去猜，不要一上来就重启重启再重启。我曾经因为这个吃过不少苦头，后来习惯性地在任何操作前先收集日志。

第二，构建镜像要养成写.dockerignore的习惯。排除target、.git、.idea这些目录，不仅能显著加快docker build速度，还能避免一些诡异的问题。比如项目里的敏感配置文件和本地调试缓存被打进镜像里，这在工作场景下是绝对不能出现的。

第三，Version 标签要有语义。不要总是用latest，给每个镜像打上明确的版本号，比如springboot-demo:v1.2。这在回滚场景下价值极大——服务出问题，一条docker run旧版本镜像的命令就能原地回滚，不用重新构建。latest标签指向的是最后一次构建的镜像，回滚时反而分不清哪个是哪个。

这套环境搭完，后面做任何跟服务部署相关的事情都有底了。遇到问题先翻上面的速查表，大部分情况都能直接命中。剩下的边边角角问题，多看日志多看文档，总能解决。