企业官网建设流程全解析

说到docker容器技术，很多人第一反应是“又一个部署工具”，但其实它已经成了现代软件交付的基础设施。我自己刚接触Docker时，也被镜像、容器、仓库、数据卷、网络模式这些概念绕得晕头转向，后来在Windows、Ubuntu、CentOS这些环境里反复折腾，又亲手部署过MySQL、Redis、GitLab、微服务这些常见场景，才慢慢把这块拼图补完整。这篇文章不打算照着官方文档念，而是从一个实操者的角度，把装环境时踩过的坑、日常用得最多的命令、以及问题排查的思路一次性讲清楚。无论你是在自己电脑上装Docker Desktop，还是在服务器上部署应用，这篇都值得存下来当参考。

1. Docker容器技术到底解决了什么问题

先说一个很多初学者最容易忽略的点：Docker不是让你“换个方式装软件”，它解决的是整个软件交付链路里最头疼的“环境一致性”问题。我以前部署一个Java应用，本地环境一切正常，到了测试服务器上就各种乱套：JDK版本不对、Tomcat配置丢了一段、MySQL的字符集不一样，最后查下来全是环境差异引起的。有了Docker，应用和它依赖的运行环境会被一起打包成镜像，只要服务器上有Docker引擎，跑出来的效果就完全一样。

打个比方，传统部署像是“你搬到一个新城市，需要重新买房、装修、买家电”，而Docker像是“你把整个房间连同家具一起快照打包，到了新地方直接解压入住”。当然这个比喻不完全准确，因为容器比整机迁移轻量得多，但它确实道出了最核心的价值。

1.1 镜像、容器、仓库，三个概念先分清

很多人学Docker时被术语劝退，其实搞清楚三个词就够了：

• 镜像：一个只读模板，里面包含应用代码、运行时、库文件、系统工具和环境配置。它就像是软件安装包，但比安装包更完整。
• 容器：镜像运行后的实例。同一个镜像可以同时跑出多个容器，互不干扰。
• 仓库：存放镜像的地方，最常用的是Docker Hub，也可以自建私有仓库。

日常操作基本就是“从仓库拉镜像，用镜像起容器，在容器里跑应用”。理解这条主线后，后面再学数据卷、网络、编排这些概念就有了抓手。

1.2 容器和虚拟机，看着像但本质不同

Docker容器和虚拟机最大的区别在于：虚拟机自带一个完整的Guest OS，会消耗大量CPU、内存和磁盘空间，启动通常以分钟计；而容器直接共享宿主机内核，镜像只有几百MB，启动基本是秒级。这也是为什么一台机器上跑几十个容器很常见，但跑几十个虚拟机基本不现实。

但代价是容器的隔离性不如虚拟机彻底。虚拟机之间是硬隔离，容器本质上还是共享内核的进程，只是通过Linux的namespace和cgroups做了资源隔离。所以如果你对安全隔离要求极高，比如要在同一台机器上运行互不信任的业务，虚拟机仍然更稳妥。

另外有一点容易被新手误解：不要真把容器当成虚拟机来用。容器内一般没有systemd，不适合在同一个容器里跑一堆服务并托管进程。我自己最开始就干过把MySQL、Redis、Nginx全装进一个容器的蠢事，后来容器越来越大，日志难查，重启一次全家跟着遭殃。现在我的原则是：一个容器尽量只跑一个主进程，多个服务用Docker Compose串联。

1.3 什么时候该用，什么时候别硬用

如果你遇到下面这些场景，用Docker会非常舒服：

• 团队多人协作，希望开发环境一键拉起，不再出现“我机器上明明是好的”。
• 想要快速部署中间件，比如MySQL、Redis、Nginx，不用下载安装包、配置一堆参数。
• 做CI/CD流水线，用一次性容器跑测试、打包，用完即弃。
• 自己写的小项目要部署到服务器，不想在服务器上手工装依赖。

但有些场景不推荐硬上：需要加载特殊内核模块的应用，容器里很难搞；强GUI交互的桌面软件，哪怕有方案也比裸机麻烦；对性能损耗极其敏感的高性能计算场景，容器网络和存储转发还是会有点开销。选型从来不是“新东西就一定好”，关键是看场景是否匹配。

2. Docker安装避坑：从Windows到Linux的实战记录

安装这步卡住的人特别多，尤其是Windows用户。我自己在不同系统上都装过，这里把容易翻车的点逐个说一遍。

2.1 Windows安装Docker Desktop，最容易卡在虚拟化

Windows上主要用Docker Desktop，但很多人第一次启动就遇到报错：Virtualization support not detected或者Docker Desktop failed to start because virtualisation support wasn't detected。看到这个不要慌，基本就是CPU虚拟化没开。

第一步先确认虚拟化是否开启：打开任务管理器 -> 性能 -> CPU，右下角能看到“虚拟化：已启用”或“已禁用”。如果显示已禁用，需要进BIOS/UEFI，找到Intel VT-x或AMD SVM相关的选项并打开。注意不同主板的位置不一样，有的叫“Intel Virtualization Technology”，有的叫“SVM Mode”，还有的藏得比较深，建议搜一下自己主板的型号。

开启虚拟化后，Docker Desktop还依赖Hyper-V或WSL2。目前推荐用WSL2方式，在管理员PowerShell里执行：

wsl --install

安装完成后重启，然后执行：

wsl --set-default-version 2

接着装Docker Desktop，安装时勾选“Use WSL 2 based engine”就行。如果你机器上WSL1的老版本，可能会有兼容问题，建议先升级到WSL2再装。

还有一个常见坑是公司电脑或老机器上已经开了Hyper-V，但Docker Desktop依然启动失败。这时候可以试试以管理员身份运行PowerShell，检查Windows功能里“Hyper-V”、“虚拟机平台”、“适用于Linux的Windows子系统”是否都开了。改完系统功能通常需要再重启一次。

2.2 Linux安装Docker：别只知道 curl 脚本

Linux上装Docker相对简单，Ubuntu和CentOS我都试过。很多教程喜欢直接给一条curl ... | sh的官方脚本，确实省事，但我不建议在生产环境这么干。原因很简单：你在执行一个远程脚本，你完全不知道它会在你机器上做什么。稳妥做法是按官方文档配置好软件源后安装：

Ubuntu/Debian大致是：

sudo apt update sudo apt install docker-ce docker-ce-cli containerd.io

CentOS/RHEL系统则用yum，先配置Docker的yum仓库，再安装docker-ce。安装完成后执行：

sudo systemctl enable --now docker sudo docker info

看到Server Version信息就说明Docker引擎正常了。顺便说一句，网上有些教程教你直接改Docker的软件源为“国内源”，这种做法本身没问题，但要注意平台规则和自己所在企业的软件源策略，按官方渠道配置最省心。

如果执行docker命令时报Cannot connect to the Docker daemon，先检查服务是不是没起来：

sudo systemctl status docker sudo journalctl -u docker -n 100

这种报错八成是服务没启动，或者Docker服务启动时崩了，后面第五部分我会专门讲排查方法。

2.3 镜像下载慢？配置镜像加速器才是正道

很多新手第一次拉镜像时都会遇到超时或速度感人。Docker Hub毕竟是海外公共仓库，受网络链路影响，拉取速度不稳定是常见现象。解决办法是配置镜像加速器，也就是registry-mirrors。

Linux下修改/etc/docker/daemon.json：

{ "registry-mirrors": ["https://你的加速器地址"] }

然后重启Docker：

sudo systemctl restart docker

Windows用户在Docker Desktop的Settings里找到Docker Engine，把同样的JSON合并进去，点Apply & Restart即生效。镜像加速地址怎么找？很多云厂商的容器镜像服务控制台里会提供一个专属加速地址，格式类似https://xxxx.mirror.example.com，登录控制台就能看到。配置完可以用docker info查看Registry Mirrors一栏是否生效。

注意：加速地址不是每个都好用，如果配置后拉取仍然很慢，可以多换几个地址测试，或者干脆用其他镜像仓库。另外，改daemon.json之前最好备份原文件，手滑写错JSON会导致Docker启动失败。

3. 第一次容器化部署：以MySQL为例

环境准备好之后，最好的入门方式就是真实跑一个服务。MySQL是绝大多数后端项目绕不开的中间件，用Docker部署它顺便能把镜像、容器、端口映射、数据卷这些概念全部串起来。

3.1 拉镜像、起容器，一条命令跑通

先拉取MySQL 8.0镜像，再启动容器。新手可以直接用这条命令：

docker run -d --name mysql8 \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORD=123456 \ mysql:8.0

我来逐个解释每个参数：

• -d：后台运行容器，执行完命令后不会一直挂在前台。
• --name mysql8：给容器起个名字，后面操作都用这个名称代替容器ID。
• -p 3306:3306：端口映射，格式是“宿主机端口:容器端口”，宿主机的3306端口会转发到容器内的3306端口。
• -e MYSQL_ROOT_PASSWORD=123456：设置环境变量，这是MySQL镜像要求必须提供的root密码。
• mysql:8.0：镜像名称和标签，只写mysql的话默认拉取latest标签。

执行后用docker ps看容器状态，如果STATUS是Up就说明成功了。我再强调一句：明文密码写在命令里只是本地测试图省事，生产环境千万别这么干，后面可以改用环境变量文件或密钥管理。

3.2 端口冲突、数据持久化和字符集，一个都不能少

不少人在跑上面命令时翻车，最常见的是宿主机3306端口已经被本机MySQL或其他服务占用了。解决办法很简单，换一个宿主端口，比如-p 3307:3306，之后就用3307去连。

第二个必须注意的是数据持久化。默认情况下容器一删，里面的数据全没了。原因在于容器是可写层是临时的，重启容器还在，但容器删除后再用镜像重新创建一个，原本写进容器内部的数据就丢了。所以正式使用MySQL一定要挂载数据卷：

docker run -d --name mysql8 \ -p 3306:3306 \ -v /data/mysql:/var/lib/mysql \ -e MYSQL_ROOT_PASSWORD=123456 \ --character-set-server=utf8mb4 \ --collation-server=utf8mb4_unicode_ci \ mysql:8.0

这里的-v /data/mysql:/var/lib/mysql把宿主机目录映射到容器内部MySQL的数据目录，数据就落在宿主机上，即使容器删了数据还在。后面两个参数是让MySQL使用utf8mb4字符集，否则默认字符集在中文场景下很容易乱码。UTF-8和UTF8MB4的区别就是后者能完整支持emoji和一些特殊汉字，现在新项目基本无脑选utf8mb4。

3.3 从容器内、宿主机、远程访问MySQL的三种方式

容器启动后用docker exec进入容器内部操作：

docker exec -it mysql8 mysql -uroot -p

从宿主机访问时，直接用MySQL客户端连：

mysql -h127.0.0.1 -P3306 -uroot -p

局域网其他机器访问，则把地址改成宿主机IP，比如mysql -h192.168.1.100 -P3306 -uroot -p。前提是宿主机防火墙放行了对应端口。

访问失败是高频问题，常见原因有四个：

1. 启动时忘了加-p参数，容器端口没有映射出来。
2. 防火墙拦截，Linux用ss -lntp或firewall-cmd查端口状态。
3. MySQL用户权限的host限制，默认root可能只允许localhost登录。Docker镜像默认会放开root，但如果你自己建了用户，就要注意授权。
4. 客户端用了旧版密码协议，MySQL 8.0默认的caching_sha2_password和老的客户端不兼容，报错会提示插件问题。

遇到访问问题，第一步永远是docker logs mysql8，很多信息在启动日志里已经写得很明白。学会看日志，比满世界搜报错有用得多。

4. Docker Compose：多容器编排才是日常

单容器玩溜之后，你会很快发现只用docker run管理多个服务会变得非常痛苦。今天我部署MySQL要敲一条长命令，明天部署Redis又要敲一条，服务器重启后还要按顺序一个个拉起来。这时候就需要Docker Compose出场。

4.1 Compose的核心价值：用配置代替命令

Docker Compose的思路很简单：把所有容器的启动配置写进一个YAML文件，执行docker compose up -d就批量搞定。相比一连串记忆困难的长命令，YAML文件本身可以被版本管理，团队其他人拉到代码后一条命令就能复现一整套环境。

新版的Docker Compose已经集成到Docker CLI里，命令是带空格的docker compose，老版本的独立命令是docker-compose，我用的时候总喜欢先确认环境里装的是哪版，不然命令敲错了还得排查一脸懵。新版Compose在定义文件里不强制要求写version字段了，直接写services即可。

4.2 用Compose部署Redis一主一从，图文式拆解

我这里用Redis主从来演示Compose。以前用命令手动起两个容器，还得把网络配置搞定，现在一个文件完事：

services: redis-master: image: redis:7 container_name: redis-master restart: always command: ["redis-server", "--appendonly", "yes"] ports: - "6379:6379" redis-slave: image: redis:7 container_name: redis-slave restart: always depends_on: - redis-master command: ["redis-server", "--replicaof", "redis-master", "6379"] ports: - "6380:6379"

这里有几个关键点需要解释。

第一，Compose会自动创建默认网络，而容器之间可以直接用服务名互相通信。比如slave节点里面写redis-master，Compose会把redis-master解析成master容器的IP，不需要自己手动查IP，也不需要--link那种老办法。

第二，--replicaof是Redis 5.0之后推荐的写法，旧版叫--slaveof。如果你拿Redis 6.x的镜像，两者都能用，但从一开始用新写法可以少踩兼容性的雷。

第三，master容器把宿主机的6379映射出去，slave容器因为6379已经被master占用了，所以宿主端口换成6380，容器内部还是6379，这是端口映射最基础的理解。

启动命令和执行验证：

docker compose up -d docker exec -it redis-master redis-cli info replication

在输出里看到role:master并且connected_slaves:1，说明主从已经通了。我经常会再补一刀，进入slave容器执行：

docker exec -it redis-slave redis-cli info replication

确认role:slave，并且master_link_status是up。配置完成后，还可以往master里写一个key，再到slave里读，验证数据同步是否正常。

4.3 从Compose到微服务部署，其实只差一层镜像构建

如果你搞过微服务项目，一定对“一堆服务要按顺序启动”这事有心理阴影。Compose解决的就是这个场景。以一个典型项目为例，你可能有：

• 前端Nginx服务
• 后端Java服务
• MySQL数据库
• Redis缓存

用Compose可以把这些服务全部写在一个文件里：

services: mysql: image: mysql:8.0 environment: MYSQL_DATABASE: appdb MYSQL_ROOT_PASSWORD: rootpass volumes: - mysql_data:/var/lib/mysql redis: image: redis:7 backend: build: ./backend depends_on: - mysql - redis environment: SPRING_DATASOURCE_URL: jdbc:mysql://mysql:3306/appdb SPRING_DATA_REDIS_HOST: redis nginx: image: nginx:1.25 ports: - "80:80" depends_on: - backend volumes: mysql_data:

build: ./backend表示后端服务不是直接拉现有镜像，而是用当前目录下的Dockerfile来构建。这种“本地Build + Compose编排 + 私有仓库分发”的组合，就是日常微服务部署最常见的一条路线。数据库、Redis用现成镜像，你自己的业务服务用定制镜像，入口用Nginx统一代理，一套环境几分钟就能起来。

5. Docker高频报错与排查技巧实录

用Docker时间久了，几乎每个人都会遇到几个经典报错。我把遇到频率最高的几类问题整理成一个排查清单，这些坑不是我编的，全是实际操练中撞出来的。

5.1 权限报错：permission denied while trying to connect to the Docker daemon socket

在Linux刚装完Docker时，普通用户执行docker命令很容易遇到这个报错：

permission denied while trying to connect to the docker daemon socket at unix:///var/run/docker.sock

原因很简单：Docker守护进程以root身份运行，socket文件/var/run/docker.sock默认只允许root或docker组的用户访问。解决办法是把当前用户加入docker组：

sudo usermod -aG docker $USER newgrp docker

然后重新执行docker命令就好了。要注意的是，newgrp docker只是临时切换当前会话的组，重新打开终端依然生效。如果你是在CI/CD环境遇到这个报错，多半是脚本执行用户不在docker组，要么把用户加进组，要么在管道里用sudo执行docker命令。

但这里我必须提醒一句：加入docker组，相当于给了这个用户接近root的权限。因为docker组用户理论上可以挂载宿主机目录进入容器并随意读写，也可以直接操作宿主机的cgroup。所以不要把docker组随便授予不信任的用户，尤其在多人共用的服务器上要谨慎。

5.2 Docker服务启动失败：先看日志，再下结论

Linux下Docker服务起不来，不要盲目重装。先看服务状态：

sudo systemctl status docker sudo journalctl -u docker -n 100

常见的原因有这么几类。一是磁盘写满导致Docker数据目录无法写入，清理方式是用docker system prune删掉没用的镜像和缓存容器。二是有旧版本Docker残留，和当前配置冲突，需要彻底卸载后重装。三是iptables相关报错，这在CentOS上比较常见，多半是防火墙和Docker的网桥规则冲突。

我自己遇到最阴间的一次是/var/lib/docker所在分区满了后，Docker服务直接起不来，而且journal日志里只提示一句“No space left on device”，不仔细看根本找不到原因。后来清理出一批悬空镜像和日志文件就好了。所以建议养成定期清理的习惯，但docker system prune -af会删除所有未使用的镜像和数据卷，手滑一次代价很大，用的时候要想清楚。

5.3 容器间网络不通：先确认是否在同一个网络

很多场景下我们需要让容器之间互相通信，比如后端服务要连数据库容器。如果发现网络不通，第一步就是检查两者是否在同一个Docker网络里。

用下面的命令查看当前所有网络：

docker network ls docker network inspect bridge

Docker默认有三种网络模式：bridge、host、none。用docker run直接起的容器，默认都会进到bridge网络里，但bridge网络内的容器默认是不支持通过容器名直接解析的，必须用IP或配置自定义网络才能互相访问。

如果你想用服务名访问另一个容器，正确做法是建一个自定义bridge网络：

docker network create app-net docker run -d --name mysql8 --network app-net mysql:8.0 docker run -d --name backend --network app-net myapp:1.0

这样backend容器里通过mysql8:3306就能访问数据库了。如果是Compose启动的服务，Compose会自动创建网络，同一份Compose里的服务名天然可解析，比较省心。

还有个高频疑问是“宿主机访问容器服务为什么时通时不通”。如果你在Linux上跑了一个容器并映射了端口，宿主机访问127.0.0.1:映射端口通常没问题；但局域网其他机器访问时会发现不通，大半原因是宿主机防火墙没放行端口，少半原因是容器绑定的IP不是0.0.0.0。

5.4 打包业务镜像：从Dockerfile到私有仓库

前面一直在“用别人的镜像”，但真正把自己的项目容器化，才是Docker价值的体现。以Spring Boot项目为例，最简单的一个Dockerfile长这样：

FROM openjdk:17-jdk-slim WORKDIR /app COPY target/app.jar app.jar ENTRYPOINT ["java", "-jar", "app.jar"]

在项目根目录执行：

docker build -t myapp:1.0 .

就会基于项目打成镜像。这个流程确实够用，但镜像体积往往很大，因为有整个JDK。更好的做法是多阶段构建，先在一个Maven镜像里完成编译，再只把成品Jar复制到精简运行时镜像里：

FROM maven:3.9-eclipse-temurin-17 AS build WORKDIR /build COPY pom.xml . RUN mvn dependency:go-offline COPY src ./src RUN mvn package -DskipTests FROM openjdk:17-jdk-slim WORKDIR /app COPY --from=build /build/target/app.jar app.jar ENTRYPOINT ["java", "-jar", "app.jar"]

多阶段构建的好处一个是用不到Maven仓库这些中间产物，最终镜像更小；另一个是能利用缓存，只要pom.xml没变，依赖下载这一步就不会重新执行，本地构建速度快很多。

打包完后不要只留在本机，推到私有仓库才能让服务器拉取：

docker tag myapp:1.0 registry.example.com/myapp:1.0 docker push registry.example.com/myapp:1.0

服务器上再执行docker pull registry.example.com/myapp:1.0即可。至于IDEA这个IDE怎么打包镜像，其实原理一样，配置好Docker插件后可以直接在Run面板创建Docker运行配置，IDE会自动调用Docker CLI帮你构建。当然，手写Dockerfile永远是基本功，工具只是帮你调用命令。

再分享一个打包时的细节：一定要写.dockerignore文件，把target/、.git/、IDE配置文件都排除掉。否则构建上下文会把你整个项目目录打包发给Docker守护进程，项目一大就慢得离谱，甚至把不该进镜像的敏感文件也带了进去。

最后说点自己的体会

如果你问我Docker学起来最忌讳什么，我的答案不是“命令背不熟”，而是“拿它当虚拟机用”。我刚入门时总想在一个容器里装下所有东西，结果容器动不动几百MB起步，日志又多又乱，出了问题都不知道从哪个进程查起。后来慢慢习惯了“一个容器一个进程”的玩法，再用Compose把一堆容器组织起来，反而觉得世界清静了。

实际操作中我还发现，遇到问题先不要急着重装Docker。很多报错只需要看两个地方：一个是容器的日志，docker logs 容器名；另一个是系统日志，journalctl -u docker -n 100。这两个命令能解决我日常遇到的八成问题。剩下的两成，多半是权限、网络、磁盘空间，按前面说的思路逐项排查就行。

这篇内容对应的路线，也是我建议新手去走的路：先装好Docker环境，然后部署一个MySQL，再尝试用Compose拉起一个Redis主从，最后把你的业务代码打成镜像跑起来。这一套走完，你对docker容器技术的理解就不会只停留在背命令的层面了。如果你也在安装、部署或编排上踩到了坑，欢迎拿这篇里的排查思路去对照，大概率能找到头绪。