企业官网建设流程全解析

先声明一下，我写技术文章有个习惯：不打算整虚的。《范进说八股》这个系列，是我自己复盘技术栈的固定栏目，标题里的“八股”不是骂人，是承认技术在核心场景下就那么几条硬规矩，记住了按规矩办，能帮你少踩很多坑。今天开讲 Docker，顺带把题目写完整：你可以永远相信这只鲸鱼。

Docker 是什么？一句话，它是一个把应用和运行环境一起打包、隔离、分发、运行的工具。它解决什么问题？环境不一致、部署迁移、依赖冲突、资源浪费，这些日常开发里最恶心的事，基本都能按下去。适合谁看？刚接触容器的新人、被本地环境各种奇怪报错折磨的开发，以及想用 MySQL、Redis 快速起一套可迁移环境的运维同学。

先说结论：这只鲸鱼确实值得信，但前提是你知道自己在干什么。下面我从原理讲到实战，再踩几个常见坑，尽量一次讲透。

1. 为什么是这只鲸鱼：Docker的核心价值与原理底牌

1.1 从“环境地狱”到集装箱：Docker解决的是什么问题

早些年做项目部署，最常听到的一句话是“我本地上是好的啊”。代码在你机器上跑得飞起，交到服务器上就报各种依赖缺失、版本冲突、路径不对。这种环境不一致带来的问题，不是靠多写两句文档就能解决的，因为每个团队的机器基础环境都不一样。

Docker 的思路是集装箱化。就像港口运输，以前你要把一堆货物直接堆在甲板上，形状各异、互相影响；现在全部先装进统一规格的集装箱，起重机能直接吊装，船能稳定堆放。镜像就是集装箱，应用、依赖、配置、系统库全封在里面，无论是到了开发机、测试机还是生产服务器，打开集装箱里面的东西都一样。

这个类比虽然老，但非常贴近本质：Docker 创建了一套标准化的分发和运行流程。你不需要再给新同事写一份“先装 JDK 1.8，再改 /etc/hosts，记得配环境变量”的长篇文档，直接给他一个镜像，pull 下来跑就行。

实际开发中我见过太多团队，因为环境配置耽误一两天时间。用 Docker 之后，新人入职当天就能把整套中间件跑起来，这个效率提升是立竿见影的。所以“永远相信这只鲸鱼”不是玄学，是容器化带来的确定性和可预测性。

1.2 镜像、容器、守护进程：三个必须搞清的概念

很多教程上来就让你敲docker run，结果敲完发现一堆概念看不懂。我先把最核心的三个概念讲清楚：

• 镜像（Image）：只读的模板，包含操作系统基础层、运行库、应用代码和启动命令。你可以把它理解成一个软件安装包，但它比安装包更完整，连系统依赖都带上了。镜像由多层组成，每一层都是在上一层之上叠加产生的，所以镜像可以复用。
• 容器（Container）：镜像运行后的实例。镜像没有状态，容器有状态，你可以启动、停止、删除、进入容器，也可以在容器里写文件。容器启动时会基于镜像添加一个可写层，运行时所有修改都写在这一层，不影响镜像本身。
• 守护进程（Docker daemon）：负责管理镜像、容器、网络、数据卷的后台服务。你敲的docker命令只是一个客户端，真正干活的是守护进程。

镜像分层这个特性我特别想多说一句：因为所有镜像都是分层的，所以多个镜像可以共用底层，比如 MySQL、Redis、Nginx 的镜像底层可能都是同一个 Debian 或 Alpine 基础层。拉取新镜像时，公共层只需要拉一次，省带宽也省磁盘。这也是 Docker 比传统虚拟机镜像更轻量的原因之一。

Docker 官方提供了一个集中存储镜像的地方，叫 Docker Hub。你可以把镜像推上去，也可以从上面拉取公共镜像。企业内部通常还会搭建私有仓库，方便固定版本和权限管理。

1.3 容器不是轻量虚拟机：隔离原理与性能真相

新手最容易犯的认知错误，是把容器当成虚拟机。虚拟机模拟的是整个硬件设备，每个虚拟机里都要跑一个完整的操作系统内核；而 Docker 容器直接共享宿主机内核，通过 Linux 内核的 namespace 和 cgroups 做隔离。

namespace 负责隔离视图，让容器内的进程以为自己在独占系统。它有几种类型：PID namespace 隔离进程号，Network namespace 隔离网络栈，Mount namespace 隔离文件系统挂载点，UTS namespace 隔离主机名，IPC namespace 隔离进程间通信。cgroups 负责限制资源，比如 CPU 使用率、内存限制、磁盘 IO 权重。两者配合，实现“看起来独立，用起来共享”。

正因为共享内核，容器启动不用经历完整的系统引导过程，所以能在毫秒甚至秒级启动。同样一台物理机上，跑十几个虚拟机可能资源就吃紧了，但跑几十个容器依然轻松。这个优势让容器非常适合微服务、批量任务和弹性扩缩容场景。

但这也带来了边界：容器不能运行和宿主机不同操作系统的环境，比如在 Linux 内核上不能跑 Windows 容器，除非有额外虚拟化层。容器内也不应该直接操作内核模块、特殊设备驱动，需要的时候要用--privileged或有其他方案，但那样做会降低隔离性，属于高风险操作。所以“永远相信鲸鱼”的前提，是尊重它的边界。

2. 上船第一步：Docker安装与Docker Desktop的大坑

2.1 Windows下选型：Docker Desktop、WSL2与Hyper-V

Windows 上装 Docker，绕不开 Docker Desktop。Docker Desktop 是官方桌面客户端，集成了 Docker 引擎、命令行工具和图形配置界面，是目前 Windows/macOS 用户的主流选择。但它在 Windows 上运行时，底层需要真实的 Linux 内核环境，所以实际上它不是直接跑在 Windows 上的。

Docker Desktop 在 Windows 上有两种后端：旧版 Hyper-V 后端和 WSL2 后端。WSL2 是微软提供的 Linux 子系统，新版基于轻量虚拟机实现完整 Linux 内核，Docker Desktop 把整个 Docker daemon 跑在 WSL2 里，和 Windows 文件系统也能互操作。WSL2 的优势是启动更快、内存占用更可控，所以新版本默认推荐 WSL2 模式。

这里有个常见误区：Windows 10 家庭版没有 Hyper-V，但不代表不能装 Docker Desktop。只要能启用“虚拟机平台”和 WSL，家庭版一样可以用 WSL2 后端。我自己就在一台家庭版笔记本上把 Docker Desktop 跑起来了，所以别被网上某些教程吓到，先看系统版本和功能支持情况。

2.2 完整安装步骤：从BIOS虚拟化到第一个容器

Windows 下我建议按这个顺序走：

1. 确认系统版本：按Win + R输入winver，至少是 Windows 10 2004 以上，建议直接 Windows 11。
2. 检查 CPU 虚拟化是否开启：打开任务管理器，切到“性能”选项卡，选择“CPU”，看右下角“虚拟化”是不是“已启用”。如果不是，需要重启进 BIOS，找到 Intel Virtualization Technology（VT-x）或 AMD SVM Mode，设为 Enabled。
3. 启用 Windows 功能：进入“控制面板 → 程序 → 启用或关闭 Windows 功能”，勾选“适用于 Linux 的 Windows 子系统”和“虚拟机平台”。如果找不到这两个选项，用管理员身份打开 PowerShell，执行两条命令效果一样：

dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

4. 重启电脑。重启后装 WSL2 内核更新包，老版本需要手动下载安装，新版本可以直接在管理员 PowerShell 里执行：

wsl --set-default-version 2 wsl --update

5. 安装 Docker Desktop，安装过程中记得勾选“Use WSL 2 based engine”。装完打开，它会自动创建一个默认的 WSL 发行版并启动后端。
6. 验证安装：打开终端执行：

docker version docker run hello-world

能输出版本信息并且 hello-world 容器正常打印提示，就说明环境通了。如果拉取 hello-world 耗时较长，别急，一般和网络环境有关，等一会儿或检查网络配置。

我个人的建议是，不要跳过检查虚拟化这一步。很多人花了半小时下载 Docker Desktop，装完一启动就报 “virtualization support not detected”，然后回来猛查资料，其实问题往往在 BIOS 设置。

2.3 Docker Desktop启动失败：virtualization support not detected 排查实录

这个报错几乎是 Windows 用户绕不过的坎，完整提示类似：

Docker Desktop failed to start because virtualization support is disabled or not detected.

字面意思是虚拟化支持被禁用或检测不到线索。我在实际排查中遇到的情况主要有这几类：

如果按上面还不行，可以直接在管理员 PowerShell 里跑一句：

systeminfo | findstr /C:"Hyper-V"

看输出里的“虚拟机监控程序模式”是不是都写“已检测到”和“已启用”。有一个不是，就说明虚拟化支持没有被系统完整识别，优先回头查 BIOS 和 Windows 功能。

还有一个容易被忽略的点：安全软件、优化软件可能会关闭系统服务或修改启动项，导致 Docker Desktop 后端无法启动。如果你电脑上装了各种“管家”“大师”，先把它们退出再试。

2.4 设置里的隐藏坑：资源限制和WSL集成

Docker Desktop 跑起来之后，别急着用，先看看设置面板。我见过不少同事，装好后什么都不调，结果 Docker 把整个电脑的内存吃满，开发环境卡到没法用。

在 Docker Desktop 的 Settings → Resources 里，可以调整 CPU、内存、Swap 和磁盘镜像大小。默认配置不一定适合你的电脑，如果平时只跑两三个中间件容器，给 4GB 内存足够了；如果还要在 WSL 里跑前端编译、Java 服务，就得多分点。这个设置和 WSL2 共享，因为 Docker Desktop 的 Linux 后端跑在 WSL2 里。

另一个经常踩坑的是 WSL 集成设置。Settings → Resources → WSL Integration 里，可以选择让 Docker CLI 在哪些 WSL 发行版中可用。如果你平时把代码放在某个特定的 WSL 发行版里，一定要勾选它，否则在 WSL 里敲docker会提示命令找不到。我习惯只在项目常用的发行版里启用，避免每个发行版都装一份工具链。

数据存储位置也建议在刚开始就确认好。Windows 下默认虚拟磁盘文件会放在C:\Users\你的用户\AppData\Local\Docker\wsl下，如果 C 盘空间紧张，运行大量容器后这个文件会膨胀。我建议在安装或设置阶段就把它迁移到其他盘，方法是在 Docker Desktop 设置里也能选 new location，或者手动移动 WSL 虚拟磁盘。否则某天 C 盘突然爆满，你会非常痛苦。

3. 实战三连：MySQL 8.0、Redis主从与Docker Compose

3.1 用Docker跑MySQL 8.0：数据必须活下来

很多教程喜欢直接给一个docker run mysql就完事，但真正要把 MySQL 用在项目里，有几个细节必须注意。我最常用的完整启动命令是这样：

docker run -d \ --name mysql8 \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORD=YourStrongPass \ -e MYSQL_ROOT_HOST=% \ -e TZ=Asia/Shanghai \ -v mysql-data:/var/lib/mysql \ --restart unless-stopped \ mysql:8.0 \ --character-set-server=utf8mb4 \ --collation-server=utf8mb4_unicode_ci

逐个拆开解释一下：

• -d表示后台运行；--name mysql8给容器固定名字，后续操作方便。
• -p 3306:3306是端口映射。冒号左边是宿主机端口，右边是容器内端口。不映射的话，容器里的 MySQL 只有容器自己能用，宿主机上的工具连不上。
• -e MYSQL_ROOT_PASSWORD=YourStrongPass是镜像要求的初始化环境变量。MySQL 官方镜像在首次创建数据目录时读取这个变量来设置 root 密码。
• -e MYSQL_ROOT_HOST=%是为了允许 root 从任何主机连接。默认只允许容器内 localhost 连接，你在宿主机或远程连接会直接报拒绝。
• -v mysql-data:/var/lib/mysql是数据卷挂载。MySQL 数据文件存在容器里的/var/lib/mysql目录，如果不挂出来，容器一删数据全没。这里我用的命名数据卷，由 Docker 管理，不用关心宿主机具体路径。
• --restart unless-stopped意思是重启策略：Docker 重启后自动拉起容器，除非你手动停过它。适合生产长期挂载。
• 命令后面的--character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci是传给 MySQL 进程的参数，目的是把默认字符集设为 utf8mb4，避免存中文乱码。

跑起来之后，先看日志确认初始化成功：

docker logs mysql8 docker exec -it mysql8 mysql -uroot -p

宿主机如果有 MySQL 客户端，直接mysql -h127.0.0.1 -P3306 -uroot -p也能连。

MySQL 8.0 有个让老客户端翻车的点：默认身份认证插件是caching_sha2_password，很老版本的客户端不支持。遇到Authentication plugin 'caching_sha2_password' cannot be loaded，要么升级客户端驱动，要么启动时加参数改成旧版插件：

--default-authentication-plugin=mysql_native_password

这属于兼容性妥协，能解决旧环境连接问题，但安全性上新插件更推荐。看具体场景取舍。

3.2 三分钟拉起Redis主从复制

Redis 主从复制是高频需求，用 Docker 拉一套非常简单。先说原理：主从复制就是把主节点的数据异步同步到从节点，从库只读，主要用来分担读压力或者做数据冗余。

我习惯先创建一个自定义网络，让容器之间可以用名字互相访问：

docker network create redis-net docker run -d \ --name redis-master \ -p 6379:6379 \ --network redis-net \ -v redis-master-data:/data \ -e TZ=Asia/Shanghai \ redis:7.0 \ redis-server --requirepass 123456 --appendonly yes

主节点注意--requirepass设置密码，--appendonly yes开启 AOF 持久化。接着起从节点：

docker run -d \ --name redis-slave1 \ -p 6380:6379 \ --network redis-net \ -v redis-slave1-data:/data \ -e TZ=Asia/Shanghai \ redis:7.0 \ redis-server --port 6379 \ --replicaof redis-master 6379 \ --requirepass 123456 \ --masterauth 123456 \ --appendonly yes

注意几个关键点：

• --replicaof redis-master 6379让从节点知道主的地址。这里填的是容器名redis-master，而不是 IP。因为容器重启后 IP 会变，而自定义网络会提供基于名字的 DNS 解析，所以填名字最稳。
• 从节点也要--requirepass，否则公共端口上的查询不需要密码。
• --masterauth是给从节点用的，主节点如果设置了密码，从节点必须带着这个密码去请求同步。
• 容器内 Redis 端口保持 6379 即可，宿主机上换 6380 访问从库，不影响复制。

验证是否同步成功：

docker exec -it redis-master redis-cli -a 123456 --no-auth-warning info replication docker exec -it redis-slave1 redis-cli -a 123456 --no-auth-warning info replication

主节点看重的是role:master、connected_slaves:1；从节点看重role:slave和master_link_status:up。

还要泼一盆冷水：Redis 主从只解决读写分离和数据备份，不解决自动故障切换。主节点挂了，需要人工把从节点提升为主，或者上 Redis Sentinel。容器化环境下 Sentinel 同样可以编排起来，但那个复杂度是另一个量级的，别在主从还没搞懂的情况下一上来就追高可用。

3.3 docker compose一把梭：编排多个服务的正确姿势

单容器命令适合临时验证，但当你的项目要同时跑 MySQL、Redis、后端服务，一个个敲docker run显然不现实。这时候用 Docker Compose，用一份 YAML 文件描述所有服务，一个命令全部拉起。

下面是一份同时包含 MySQL 和 Redis 的docker-compose.yml示例，新版 Compose v2 不需要写version也能识别：

services: mysql8: image: mysql:8.0 container_name: mysql8 restart: unless-stopped environment: MYSQL_ROOT_PASSWORD: "YourStrongPass" MYSQL_ROOT_HOST: "%" TZ: "Asia/Shanghai" ports: - "3306:3306" volumes: - mysql-data:/var/lib/mysql command: - --character-set-server=utf8mb4 - --collation-server=utf8mb4_unicode_ci healthcheck: test: ["CMD", "mysqladmin", "ping", "-h", "127.0.0.1", "-pYourStrongPass"] interval: 10s timeout: 5s retries: 5 redis: image: redis:7.0 container_name: redis-master restart: unless-stopped command: - redis-server - --requirepass - 123456 - --appendonly - "yes" ports: - "6379:6379" volumes: - redis-data:/data healthcheck: test: ["CMD", "redis-cli", "-a", "123456", "ping"] interval: 10s timeout: 3s retries: 5 volumes: mysql-data: redis-data:

启动：

docker compose up -d docker compose ps docker compose logs -f

Compose 会自动创建默认网络，所有 service 用服务名互相访问。这就是它的价值：整个环境像一套“清单”一样可复现，团队成员拿到同一个 YAML 文件，拉起的环境几乎完全一致。

这里有个很多人会误解的配置：depends_on只控制启动顺序，不保证依赖服务已经就绪。比如后端依赖 MySQL，depends_on只是让 MySQL 容器先启动，不代表 MySQL 已经能接受连接。想在依赖就绪后再启动主服务，需要配合healthcheck，或者代码里做重试。上面示例里我给 MySQL 和 Redis 都加了健康检查，实战中这一步可以不省。

4. 容易翻车的地方：网络、数据与排障实录

4.1 容器之间到底怎么互通：网络模式速览

Docker 的网络模式是很多人头疼的地方。默认情况下，每个容器有自己的网络栈，通过虚拟网卡和宿主机上的 docker0 网桥通信。核心有三种模式：

• bridge（默认）：容器通过网桥连接宿主机，多个容器之间可以用 IP 互通，但 IP 会变。端口映射就是在这个模式下用的。
• host：容器直接用宿主机网络栈，没有独立 IP，也不存在端口映射，监听什么端口宿主机就是什么端口。性能好，但隔离性弱，也不适合需要端口转发的场景。特别提醒，macOS 和 Windows 的 Docker Desktop 对 host 网络支持有限，别在两个平台上想当然。
• none：只有 loopback 网卡，适合对网络隔离要求极高的场景，一般用不到。

我的建议很简单：同一业务下的容器，都放进同一个自定义 bridge 网络。自定义网络比默认 bridge 多一个杀手级能力——DNS 解析。在自定义网络里，容器可以直接用容器名互访，不用去查 IP。上面 Redis 主从配置里的redis-master就是靠这个解析的。

排查网络问题，先确认容器在哪个网络、能不能互相 ping 通：

docker network inspect redis-net docker exec -it redis-master ping redis-slave1 docker port mysql8

docker port可以查当前端口映射情况，非常实用。

4.2 高频排障清单

把日常使用中容易踩的坑整理成一张速查表，按“现象 → 原因 → 方案”查就行：

另外补充几个经验。第一个是 MySQL 容器跑起来后，docker logs里如果出现 “Database directory ... is not empty. Skipping” 这种提示，说明挂载的数据卷里已经有历史数据，环境变量初始化配置会被跳过，这是正常的，别慌。这时候改密码要进容器执行 SQL，而不是重新指定环境变量。

第二个经验是不要随便用docker exec进入容器去改配置文件，因为容器可写层没有持久化，容器一删就没了。想改配置，要么重新拼接启动命令，要么把自定义配置文件放到数据卷里挂载。

第三个经验是给容器打日志上限。很多中间件容器跑时间长了，日志文件能把几百 GB 磁盘填满。最省心的方式是在 Docker Desktop 的 daemon 配置里加一行"log-opts": {"max-size": "10m", "max-file": "3"}，或者在运行容器时手动加--log-opt参数。这个坑我踩过不止一次，现在默认操作都会带上。

4.3 “永远相信鲸鱼”的边界：容器化不适合做什么

写了这么多，别把 Docker 理解成万能灵药。有些场景容器化收益很高，有些场景则要谨慎。

不适合用容器的典型场景：需要加载内核模块、需要直接操作宿主机硬件、对网络延迟极度敏感、有强状态存储且数据量极大的系统。比如一两个 TB 的数据库实例，你非要用容器跑，虽然技术上可行，但备份、恢复、跨版本升级的复杂度会明显上升。另一个例子是某些依赖特殊文件系统特性的应用，因为容器共享宿主机内核，文件系统行为是宿主机的，不是镜像能决定的。

适合用容器的场景：无状态 Web 服务、微服务、中间件、CI/CD 流水线、一次性任务、本地开发环境。在这些场景下，容器的可编排、可扩展优势能完全发挥出来。我的判断标准很简单：如果这东西删了能无损重建，就大胆容器化；如果删了需要找三天数据，先想清楚备份方案再说。

还有一个人为上的边界：容器不是说扔进生产就能高枕无忧。监控、日志采集、资源配额、安全扫描，这些周边配套一个都不能少。Docker 负责让你的应用“跑得起来”，但要“跑得稳”还需要一套完整的运维体系。

我自己长期用下来的体验是：Docker 最值钱的地方不是“快”，而是确定性。它把不可控的环境问题变成了可控的配置问题。你可以因为一套docker-compose.yml三条命令拉起整个开发环境，也可以在凌晨三点部署时不再担心“为什么这台机器起不来”。但越是依赖它，越要理解它背后的原理。

最后留一个小建议：每创建一个容器，都顺手把--restart和日志上限配上；每个自定义网络，都给容器起个有意义的名字。这些你现在觉得琐碎的操作，会在两个月后的某次深夜故障里，变成最值钱的前瞻性决定。范进的八股第一篇先写到这，下次换一个容器外的主题，咱们继续拆。