企业官网建设流程全解析

第二步，编写MySQL配置文件，把字符集设置好：

[mysqld] character-set-server=utf8mb4 collation-server=utf8mb4_unicode_ci [client] default-character-set=utf8mb4

第三步，启动容器：

docker run -d \ --name mysql8 \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORD=MyPass123! \ -e TZ=Asia/Shanghai \ -v /data/mysql/conf/my.cnf:/etc/mysql/conf.d/my.cnf \ -v /data/mysql/data:/var/lib/mysql \ mysql:8.0

这里几个参数值得细说。-e MYSQL_ROOT_PASSWORD是MySQL官方镜像识别的一个特殊环境变量，容器首次启动时会用它初始化root用户的密码。-v挂载的两个目录分别作用于配置和数据，这样即使容器不小心被删了，数据和配置都还在宿主机的 /data/mysql 目录下，重新启动一个容器直接挂载同一个目录就恢复原样了。

启动之后，用客户端连一下验证：

docker exec -it mysql8 mysql -uroot -p

能进到MySQL命令行就说明部署成功了。如果你想在宿主机上直接访问容器里的MySQL，需要先确保宿主机安装了MySQL客户端，然后用mysql -h127.0.0.1 -P3306 -uroot -p连接试试。

3.5 进阶案例：用Docker Compose编排Redis主从

单容器部署用docker run就够了，但一旦涉及多个容器协同工作，比如应用服务加数据库加缓存，一个个启动和管理就很痛苦。这时候轮到Docker Compose出场了。Compose用YAML格式的配置文件描述整个应用服务栈，一条docker compose up -d就能把服务都拉起。

我用Redis主从架构来演示Compose的用法。先在项目目录下写一个docker-compose.yml文件：

version: "3.8" services: redis-master: image: redis:7.0 container_name: redis-master ports: - "6379:6379" command: ["redis-server", "--appendonly", "yes"] volumes: - ./master-data:/data networks: - redis-net redis-slave: image: redis:7.0 container_name: redis-slave depends_on: - redis-master ports: - "6380:6379" command: ["redis-server", "--slaveof", "redis-master", "6379"] volumes: - ./slave-data:/data networks: - redis-net networks: redis-net: driver: bridge

这个文件定义了两个服务：一个主节点，一个从节点。关键点在于command参数，它覆盖了镜像默认的启动命令，从节点直接通过--slaveof redis-master 6379指定主节点的地址。这里能直接用redis-master这个名字，就是因为在同一个Compose网络里，容器之间可以通过服务名互相解析。

启动方式很简单：

docker compose up -d

查看状态：

docker compose ps

如果你用的老版本是docker-compose命令，注意横杠的区别。新版Docker已经把手写两个单词的docker-compose合并成了docker compose（子命令方式），功能上没有区别，但老版本在某些平台还需要单独安装。

验证主从同步是否生效，进入从节点执行：

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

看到role:slave且master_link_status:up，就说明主从配置成功。整体看下来，用Compose管理多容器应用最大的好处就一个：整个服务栈的定义是代码化、版本化的，换一台机器，把这个YAML文件拿过去，同样一条命令就能完整复现一套环境。

3.6 用Dockerfile打包Java应用的镜像

开发环境搞定之后，还有个高频场景是把项目打包成镜像。这里以Java应用为例，因为经常有同学问IDEA里怎么打Docker镜像。其实做法很简单，在项目根目录写一个Dockerfile：

FROM openjdk:8-jre-alpine WORKDIR /app COPY target/myapp.jar app.jar EXPOSE 8080 ENTRYPOINT ["java", "-jar", "app.jar"]

然后在项目目录执行构建命令：

docker build -t myapp:1.0 .

构建完成之后，用docker run -d -p 8080:8080 myapp:1.0就能把应用跑起来了。IDEA里也有Docker插件，可以直接在run configuration里选择Docker方式构建运行，但底层还是执行了上面这套逻辑。对新手来说，先用命令行体验一遍构建过程，比直接依赖IDE插件更能理解Docker的工作方式。踩着坑学到的才是自己的。

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

4.1 Docker Desktop起不来，提示虚拟化未开启

这个报错在Windows平台上太经典了，文字大概是virtualization support not detected或者virtualisation support wasn't detected。原因和解决方案我梳理一下。

先检查系统层面是否启用了虚拟化功能。打开任务管理器，切到“性能”选项卡，看CPU那一栏，右下角如果有“虚拟化：已启用”就说明系统层没问题。如果显示“已禁用”，那基本可以断定是BIOS里没开。不同品牌的主板进BIOS的按键不一样，一般是Del或者F2，进到Advanced或者Configuration菜单，找到Intel Virtualization Technology或者SVM Mode（AMD），改成Enabled，保存重启。

还有一种情况是：BIOS里开了虚拟化，但系统功能里的Hyper-V和Windows虚拟机监控程序没启用。这种情况在“控制面板 - 程序 - 启用或关闭Windows功能”里勾选“Hyper-V”、“虚拟机平台”和“适用于Linux的Windows子系统”，重启电脑即可。

最后还有一种少见但真实存在的情况：电脑上装了其他第三方虚拟机软件，比如VirtualBox，两者因为Hyper-V的冲突导致Docker Desktop起不来。这种就得权衡一下，或者切换Docker Desktop的后端模式，要么用WSL 2后端，要么用Hyper-V后端，不要两个都占着。

4.2 连接不上Docker API，报错npipe或者permission denied

在Windows上启动容器时遇到failed to connect to the docker api at npipe:////./pipe/dockerdesktoplinux...这种报错，八成是Docker Desktop没启动，或者正在启动中还没就绪。你看一下任务栏右下角的鲸鱼图标是不是稳定绿色，如果一直在转圈或者显示红色，先等它启动完成，或者右键退出再重新打开。

Linux上对应的报错一般是permission denied while trying to connect to the Docker daemon socket，原因就是我前面提到的用户权限问题。执行一下sudo usermod -aG docker $USER，然后退出终端重新登录，这个问题就解决了。如果仍然不行，用sudo systemctl status docker看一下Docker服务本身有没有启动，有些系统安装完成后不会自动启动服务。

4.3 镜像下载慢或者拉取失败

镜像下载慢是另一个高频痛点，尤其是从Docker Hub拉取较大的镜像时。解决办法是给Docker配置镜像加速器。在Docker Desktop的设置里找到“Docker Engine”配置项，或者在Linux上编辑/etc/docker/daemon.json，加入如下配置：

{ "registry-mirrors": ["https://docker.mirrors.example.com"] }

配置完成之后重启Docker服务，再拉取镜像速度就有明显改观。需要说明的是，镜像加速器的可用性和速度在不同时期会有变化，如果发现某个地址不生效了，去搜一下当前可用的公共镜像加速地址，替换一下配置文件再重启Docker就行。

拉取失败还有一种常见原因是镜像名称写错或者镜像不存在。比如有人把nginx写成了ngnix，拉取自然会失败，报错信息里通常会出现manifest unknown或者repository does not exist这样的字样。这时候到Docker Hub上搜索确认一下镜像的确切名称和标签就好。

4.4 容器日志不断刷屏或者频繁重启

容器一直处于Restarting状态，很多新手不知道怎么办。首先要明白，容器重启是因为内部进程崩溃了，Docker会按重启策略尝试拉起它。排查的第一步是看日志：docker logs 容器名，日志的最后几行通常会暴露错误原因，比如配置文件路径不对、环境变量缺失、端口被占用等。

我遇到过最常见的场景是：容器里启动的服务需要依赖数据库，但数据库容器还没完全就绪，应用就尝试连接，连不上就崩了，陷入重启循环。这种情况在Compose编排里尤其常见，所以需要给应用容器加上健康检查逻辑，或者设计启动脚本做重试等待，比单纯依赖depends_on更可靠。

等到容器稳定运行之后，也别忽略日志的管理。长时间运行的容器如果日志没有配置轮转，日志文件会越积越大，占满磁盘。建议启动容器时加上--log-opt max-size=10m --log-opt max-file=3这样的参数，或者通过daemon.json全局配置日志轮转策略。这种小细节，往往到线上出一次事故你才会想起来。

4.5 青龙面板依赖管理这类容器的注意事项

热搜词里出现了“青龙面板依赖管理”，虽然这个名字听起来像是个具体工具，但它容器化部署的方式和一般应用是相通的。这类面板类工具往往需要在容器里安装各种依赖，如果只是用默认镜像跑起来，容器一更新重建，依赖就全没了，所以正确做法是把依赖目录和配置文件都挂载到宿主机上。

具体来说，启动前用docker inspect看一下标准目录结构，把易变动的配置目录、下载缓存目录、依赖安装目录都挂载出来。这样即使某天需要升级镜像，重新跑一个容器挂载同一批目录，所有依赖和配置都在，无缝衔接。这个思路适用于所有基于容器的面板工具，不只是青龙面板。

4.6 常见问题速查表

最后再分享一个小技巧

说了这么多，最后分享一个我自己常用的操作习惯：每次创建容器之前，先用docker search看一下官方镜像是否存在，再用docker pull先把镜像拉好，最后才执行docker run。这样能把“网络问题”和“参数问题”分离开来，排查起来快很多，不至于所有问题都纠缠在一起难定位。

Docker这东西，入门真的不难，难点在于理解它背后的设计思路。只要把镜像和容器这两个概念彻底吃透，再掌握docker run的参数套路，日常部署需求基本都能搞定。接下来你可以自己去试着把一个Node应用、Python应用或者别的什么服务容器化，踩一次坑，进步一大截。这套工具值得你花时间学习，它会让你在“环境部署”这件事上，彻底解脱出来。