企业官网建设流程全解析

去年有个朋友想搭个人博客，机器买了三天还在登录界面前打转——不是他笨，是市面上的教程默认你"已经懂一点"。这次我用雨云的云服务器完整走了一遍，从下单到博客打开页面用了不到二十分钟，全程没有写过一行手工配环境的命令。这篇攻略就按我当时的操作顺序来，把零基础会卡的每个点都拆开讲透。

先说结论：零基础部署博客，最稳的不是手动装环境，而是用 Docker Compose 一把拉起 WordPress。这套方案的好处是——服务器系统坏了可以重建，博客数据不会丢；换机器搬家，一条命令恢复原样。下面从选机器开始，逐步走完整个链路。

1. 为什么要用 Docker Compose：三条路径的对比与选择

部署博客这件事，本质上是往一台服务器里塞三个东西：Web 服务（处理 HTTP 请求）、数据库（存储文章和配置）、博客程序本体（WordPress 文件）。三样配齐了，浏览器才能访问到你的内容。

零基础常见的选择有三条路，我对比一下。

第一条：传统懒人包，典型代表是宝塔面板。装上之后有图形界面，鼠标点点就能建站。优点是直观，缺点是面板自身也要维护，而且会把不少新手一直圈在图形界面里，出了问题很难定位。

第二条：纯手动搭建，也就是自己装 Nginx、装 MySQL、装 PHP，然后下载 WordPress 手动配置。这条路适合想系统学习服务器原理的人。缺点很明显——Mysql 版本兼容、PHP 扩展缺失、目录权限不对，任何一环报错都能卡住新手半天。

第三条：Docker Compose 编排。Docker 可以把 WordPress 和 MySQL 分别打包成两个独立的"集装箱"，Compose 则是集装箱的调度单，定义两个容器如何协同。你要做的只是写一份配置文件、执行一条命令。

三条路的对比：

我最终选 Docker Compose，还有一个实际原因：雨云这类面向个人开发者的云服务器，新用户拿到手就是一个干净的系统盘，Docker 装上之后完全不用管底层依赖，WordPress 官方镜像和 MySQL 官方镜像的兼容性已经被全球无数人验证过了。

对零基础用户，我的建议是走第三条路。先把博客跑起来建立信心，之后再慢慢研究 Nginx 配置、性能优化那些进阶内容。

1.1 你只需要理解一条数据流

整个博客系统跑起来之后，本质上是这么一条链路：

浏览器输入域名 → DNS 解析到服务器 IP → 服务器上的 Nginx 容器接收请求 → 找到 WordPress 容器 → WordPress 程序向 MySQL 容器查询数据 → 拼装成网页返回给浏览器。

Docker Compose 把这条链路中的 WordPress 和 MySQL 串联起来，Nginx 则负责对外提供访问入口。初学者不需要深究每一层，只需要理解：WordPress 存"内容逻辑"，MySQL 存"数据"，Nginx 管"进出口"。后面配置文件里出现的每一项，都是为了让这三个角色各司其职。

1.2 配置你自己的第一个 yml 文件之前，先了解容器技术

Docker 镜像可以理解成一套"预制好的运行环境"，里面有程序代码、依赖库、配置文件，全都打包好了。容器则是镜像运行起来的实例。MySQL 镜像装好数据库引擎，WordPress 镜像装好 PHP 环境和博客程序。

Compose 则是把这些容器的启动参数统一写入一个 yml 文件，包括：

• 每个容器用什么镜像
• 端口怎么映射到宿主机
• 数据存在哪个目录
• 容器之间的启动顺序和依赖关系

这样一来，以前需要手动执行的十几条 docker run 命令，变成一条 docker compose up -d。

2. 选机器和初始化：买服务器前先想清楚三件事

雨云这类云平台的控制台通常有几个核心入口：重置密码、防火墙规则、操作系统重装。把这几项搞清楚，服务器就算入门了。

2.1 配置怎么选：别一上来就买高配

个人博客初期流量很小，一台 1核2G 的实例完全够用，预算紧张的话甚至可以先选按量付费，等博客真有了访客再升级。我见过不少新手一上来买 4核8G，结果博客跑起来内存占用不到10%，纯属浪费。

对雨云这种面向个人开发者的平台，新用户一般有体验金或低价套餐，先用小配置走通流程，比什么都重要。等后面需要装更多服务、跑更大流量，再升级配置也不迟。

2.2 系统选哪个：Ubuntu 22.04 LTS 是目前最优解

云平台一般提供好几种 Linux 发行版。对新手，我推荐 Ubuntu 22.04 LTS：

• LTS 代表长期支持，安全更新维护周期长
• 社区资料最多，遇到问题搜出来的解决方案基本都能直接复制
• 默认的 apt 包管理器和 Docker 官方安装文档的适配度很高

CentOS 7 已经停服，旧教程里的 yum 命令在新系统上已经不适用，新手很容易踩坑。Windows Server 更不建议，同样的配置下资源占用高，且与主流博客部署文档的兼容性差。

2.3 SSH 连接：拿到服务器后的第一道关卡

服务器本质上是一台没有显示器的远程电脑，你要通过 SSH 协议连上它的终端下命令。Windows 用户可以打开 PowerShell 直接输命令，也可以用 Termius 这类带图形界面的终端工具。不过更常用的是 Xshell、FinalShell 这类国产免费工具——下载安装后，新建会话，填入公网 IP、root 用户名和密码就能连上。

首次连接之后，建议立刻做两件事：

1. 修改默认登录密码，使用包含大小写字母和数字的强密码
2. 更新系统软件源和已装软件

sudo apt update && sudo apt upgrade -y

这一步会花几分钟，但能解决大量潜在的系统漏洞和依赖版本问题。我习惯在拿到新机器后先跑一遍 update，再开始后面的安装，避免装 Docker 时因为源的问题报奇怪错误。

2.4 防火墙和安全组：别让服务器裸奔

云平台通常有两层安全控制：控制台里的"防火墙规则"和系统内的 ufw。雨云控制台会把默认端口 22（SSH）、80（HTTP）、443（HTTPS）开放好，但有些用户自己误操作关掉了，导致网页一直打不开。

建议规则如下：

3306 端口千万别对外开放，否则数据库被扫描爆破的风险很高。MySQL 容器通过 Docker 内部网络访问，根本不需要暴露给外网。

系统内部的 ufw 防火墙，新手阶段可以不启用。控制台的安全组规则已经能挡住绝大多数非法请求，多一层 ufw 可能反而把自己拦在外面。

3. Docker 环境搭建：把服务器变成一台通用部署机

选好系统、连上 SSH 之后，下一步就是安装 Docker 和 Docker Compose。这一步相当于给服务器装一个"程序运行仓库"，以后部署任何软件都能复用这套环境。

3.1 安装 Docker：一条官方脚本搞定

Docker 官方提供了一键安装脚本，对 Ubuntu 系统最稳妥的方式是直接用官方源安装。国内用户可以配置国内镜像加速器，否则拉取镜像时可能会超时。

curl -fsSL https://get.docker.com -o get-docker.sh sudo sh get-docker.sh

脚本执行完，验证一下：

sudo docker version

看到 client 和 server 两段版本信息就说明安装成功。没有报错的话，可以把当前用户加入 docker 用户组，省得每条命令都加 sudo：

sudo usermod -aG docker $USER

执行完这条命令需要退出 SSH 重新登录一次，再执行 docker 命令就不用加 sudo 了。

3.2 Docker Compose：现在不需要单独装了

新版 Docker 里已经集成了 Compose 插件，直接用 docker compose 命令（注意是带空格的两个词），老版本的 docker-compose 不用再装。验证：

sudo docker compose version

能看到版本信息即可。接下来所有编排操作都通过这个命令完成。

3.3 配置镜像加速器：避免拉取卡死

国内用户直接拉 Docker Hub 官方的镜像，偶发超时很常见，尤其是 WordPress 和 MySQL 这种体积较大的镜像。建议在 /etc/docker/daemon.json 里配置镜像加速器：

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

保存之后重启 Docker：

sudo systemctl restart docker

这一步不配也能跑，但配了能省去很多等待时间。我记得第一次拉 WordPress 镜像没配加速器，卡了几分钟还没动，配上之后几十秒就完了。这是个纯国内环境问题，跟服务器本身性能无关。

3.4 为什么要用 Docker 而不是直接在系统里装环境

我用一个生活化的类比解释：手动在系统里装 MySQL 和 PHP，就像在你家客厅里同时装修厨房和浴室——墙要砸、管道要改、电路要重新走，搞不好还影响原来的客厅（系统其他软件）。

而 Docker 容器相当于在客厅里放两个全装修好的"独立集装箱"：里面自带厨房设备和浴室管道，跟客厅互不影响。哪天浴室坏了，把整个集装箱拖走换一个就行，客厅干干净净。这份省心，对零基础用户来说是最有价值的。

4. 用 docker-compose.yml 一把拉起 WordPress：完整配置逐行讲解

这是整个部署的核心环节。我先把完整的配置文件贴出来，然后逐段解释每一行是干什么的。还在 SSH 终端里没退出的话，直接操作就行。

4.1 创建项目目录和配置文件

mkdir -p ~/wordpress && cd ~/wordpress

然后创建一个名为 docker-compose.yml 的文件：

nano docker-compose.yml

4.2 完整的 docker-compose.yml

services: db: image: mysql:8.0 container_name: wp_db restart: always environment: MYSQL_DATABASE: wordpress MYSQL_USER: wp_user MYSQL_PASSWORD: "你的强密码" MYSQL_ROOT_PASSWORD: "另一个强密码" volumes: - db_data:/var/lib/mysql wordpress: image: wordpress:latest container_name: wp_app restart: always depends_on: - db ports: - "80:80" environment: WORDPRESS_DB_HOST: db:3306 WORDPRESS_DB_USER: wp_user WORDPRESS_DB_PASSWORD: "你的强密码" WORDPRESS_DB_NAME: wordpress volumes: - wp_data:/var/www/html volumes: db_data: wp_data:

4.3 逐项拆解：每行配置都在干嘛

db 服务：用的是 MySQL 8.0 官方镜像。container_name 指定容器名字，方便后面用 docker exec 进入操作。restart: always 表示 Docker 服务重启或容器异常退出时自动拉起，这是生产环境保证可用性的关键。

environment 里的四个变量是 MySQL 镜像约定的配置方式：

• MYSQL_DATABASE：创建名为 wordpress 的数据库
• MYSQL_USER / MYSQL_PASSWORD：创建一个专用账号，让 WordPress 用它连数据库
• MYSQL_ROOT_PASSWORD：数据库 root 超级管理员密码，平时用不到，但必须设置

volumes 里 db_data:/var/lib/mysql 是数据持久化。没有这行，容器删掉后你的文章全部消失；有了这行，MySQL 数据落在宿主机上的一个 Docker 管理卷里，容器销毁重建数据还在。

wordpress 服务：用的是 WordPress 最新官方镜像。depends_on: db 确保了数据库容器先启动。ports 的 "80:80" 把容器内的 80 端口映射到服务器的 80 端口，这样外部 HTTP 请求才能打到 WordPress 容器上。

environment 里四个 WORDPRESS_DB_ 开头的变量，对应刚才 MySQL 里的配置。特别说明：WORDPRESS_DB_HOST 要填 db:3306，而不是 127.0.0.1。因为在 Docker 内部网络中，db 是 MySQL 容器的别名，WordPress 容器通过这个名字访问数据库。

4.4 启动命令与验证

docker compose up -d

第一次执行要拉取两个镜像，耐心等一会儿。之后查看容器状态：

docker compose ps

看到两个容器状态都是 Up 就成功了。这时候在浏览器输入服务器的公网 IP，应该能看到 WordPress 的安装界面。

如果暂时看不到，先检查 80 端口是否被占用：

sudo lsof -i:80

有别的服务占了，先停掉再重启容器。云控制台的防火墙规则里 80 端口也确认开放。

4.5 初始化 WordPress：五步填完就能写文章

浏览器打开 IP 地址后，会进入 WordPress 的语言选择界面。选简体中文，然后填站点标题、管理员用户名、邮箱、密码。这些信息很重要，建议密码用强密码并截图存好。

安装完成后进入后台仪表盘，博客就算上线了。现在可以写第一篇文章测试。这时候再去访问公网 IP，看到的是你自己站点的页面，那种成就感是看教程体会不来的。

5. 用域名和 HTTPS 把博客真正"立"起来

用 IP 地址访问博客有两个问题：难记；搜索引擎不友好。而且没有 HTTPS 加密，浏览器会提示"不安全"。

5.1 购买域名和解析

域名在哪里买都有，国内域名通常需要完成实名认证。买好之后去域名服务商的控制台添加一条 A 记录：

解析生效时间一般几分钟到几小时。可以用 ping 命令验证：

ping yourdomain.com

返回的 IP 和服务器公网 IP 一致就说明解析成功。

5.2 域名绑定到底层 Web 服务

WordPress 容器默认监听 80 端口，域名访问和 IP 访问本质上都是走 80 端口。但对于 HTTPS 来说，需要让 Nginx 这层知道域名和证书。

常见做法有两种：

1. 宿主机直接安装 Nginx 做反向代理，把 80/443 端口接收到的请求转发给 WordPress 容器的 80 端口。

2. 用容器化的 Nginx Proxy Manager（NPM），在图形界面里配置域名转发和 SSL 证书，对新手更友好。

我用 NPM 比较多，因为它把证书申请这个最容易出错的环节做了可视化。先调整 docker-compose.yml，把 WordPress 的端口从"80:80"改成"127.0.0.1:8080:80"，避免和 NPM 的 80 端口冲突，然后单独创建 NPM 容器：

services: npm: image: jc21/nginx-proxy-manager container_name: npm restart: always ports: - "80:80" - "443:443" - "81:81" volumes: - npm_data:/data - npm_letsencrypt:/etc/letsencrypt volumes: npm_data: npm_letsencrypt:

启动后访问"服务器IP:81"，首次登录默认账号 admin@example.com 密码 changeme，登录后强制改密码。然后在 NPM 界面添加 Proxy Host：

• Domain Names 填你的域名
• Forward Hostname 填 wordpress
• Forward Port 填 80

保存后访问域名，博客就能正常打开。

5.3 申请 HTTPS 证书

NPM 自带 Let's Encrypt 证书申请功能。在刚才配置的 Proxy Host 编辑页，打开 SSL 选项卡，勾选"Request a new SSL Certificate"，填入你的邮箱，同意条款后保存。

证书会自动申请并续期。这步是很多新手自己手动配 certbot 时容易卡住的地方——因为涉及到 80/443 端口的验证流程和 Web 服务器的配合。NPM 把这一切封装好了。

配好之后访问 https://你的域名，地址栏出现小锁图标。这一步做完，博客就属于"正式上线"状态了。

6. 上线之后的日常运维：备份、日志和常见故障排查

博客跑起来只是第一步，真正的"部署成功"还包括数据安全、故障恢复这些背后工作。这一章我分享几个实战中最高频的运维操作。

6.1 数据备份：一个脚本搞定博客全部家当

WordPress 的数据分两处：文章和设置存在 MySQL 数据库里，主题、插件、上传的图片存在 WordPress 容器的 /var/www/html 目录里。两处都要备份。

写一个备份脚本，放入 /usr/local/bin/backup_blog.sh：

#!/bin/bash BACKUP_DIR="/home/backup/wordpress" DATE=$(date +%Y%m%d%H%M) mkdir -p $BACKUP_DIR cd /home/wordpress # 备份数据库 docker compose exec -T db mysqldump -u root -p"你的数据库root密码" wordpress > $BACKUP_DIR/db_$DATE.sql # 备份博客文件 docker run --rm --volumes-from wp_app -v $BACKUP_DIR:/backup ubuntu tar czf /backup/files_$DATE.tar.gz /var/www/html # 删除7天前的备份 find $BACKUP_DIR -name "*.sql" -mtime +7 -delete find $BACKUP_DIR -name "*.tar.gz" -mtime +7 -delete

给脚本执行权限，并加到 crontab 里每天凌晨执行：

chmod +x /usr/local/bin/backup_blog.sh crontab -e

0 3 * * * /usr/local/bin/backup_blog.sh

这样每天凌晨三点自动备份一次。真遇到过博客被误删文章、或插件升级把站点搞挂的情况，这份备份是唯一的后悔药。备份文件建议定期下载到本地电脑，或同步到云存储，服务器本身出故障时备份还在外部。

6.2 查看日志：定位问题的最快路径

博客突然打不开，第一步去看容器日志：

docker compose logs -f --tail=100 wordpress

• 看到"Error establishing a database connection"，多半是数据库容器挂了或环境变量不匹配
• 看到"File not found"，WordPress 入口文件缺失，先重启容器
• 看到权限相关报错，检查 wp_data 卷的目录权限

数据库的日志也一样：

docker compose logs -f --tail=100 db

日志会明确告诉你是密码错误、端口冲突，还是磁盘空间不足。我排查线上故障时，八成以上问题靠这两条命令定位，远比一句句搜搜索引擎高效。

6.3 常见故障排查：几个我踩过的具体坑

坑一：数据库连接错误。表现是博客页面提示"Error establishing a database connection"。原因通常是 docker-compose.yml 里的 MYSQL_PASSWORD 和 WORDPRESS_DB_PASSWORD 不一致，或者数据库容器没起来。检查方法就是对比配置文件和 docker compose ps 的结果。我后来养成的习惯是：密码类配置统一先写进环境变量文件，避免手滑不一致。

坑二：80 端口被占用。表现是 docker compose up 报"port is already allocated"。服务器上如果装了 Nginx 或其他 Web 服务，先停掉它，或者把 WordPress 映射端口改成 8080（此时访问"IP:8080"）。确认没问题后再决定要不要迁回到 80。

坑三：502 Bad Gateway。NPM 或 Nginx 反代转发失败。检查 NPM 里 Forward Hostname 是否正确——容器之间要用容器名，不能填 localhost。我因为把 Forward Hostname 填成 127.0.0.1 而卡过半小时，改成 wordpress 后立刻恢复。

坑四：服务器内存不足导致容器被杀。1核2G 的小配置下 MySQL + WordPress 两个容器跑起来接近内存上限，偶发出现容器自动停止。解决方法是给 swap 文件增加虚拟内存，或者升级配置。我一般会在新服务器上顺手配置一个 2G 的 swap 文件，几行命令，能省很多麻烦：

sudo fallocate -l 2G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile

6.4 换机器迁移：一条命令复制整个站点

我换服务器时最常用的是 Docker 自带的方式。在新机器上同样安装 Docker，把整个 ~/wordpress 目录（包含 docker-compose.yml）和备份数据复制过去，然后：

cd ~/wordpress docker compose up -d

再恢复最近一次数据库备份和文件备份，站点就完整搬家了。这正是一开始选择 Docker 的最大红利：环境、依赖、配置全部在镜像和 Compose 文件里，不需要在新机器上重新折腾一遍安装过程。

7. 项目管理层面的经验沉淀：这套部署方式能复用到哪里

如果你以为这篇文章只能用来搭博客，那就低估了这套方案。雨云这类云服务器上，用 Docker Compose 部署的思路可以覆盖很广的需求场景。

7.1 用同一台服务器跑多个项目

很多人的个人服务器不止跑一个博客，还挂相册、导航页、RSS 订阅工具。在 Docker Compose 的体系里，每个项目一个目录，各写各的 docker-compose.yml，用不同的端口映射互不干扰。

比如在 ~/nav 目录部署一个导航站点，在 ~/rss 目录部署一个订阅服务，各自的容器和数据卷完全隔离。管理上也清晰：哪个项目不需要了，进到对应目录执行 docker compose down 就行，不会误删其他项目的数据。

7.2 部署其他主流应用

WordPress 只是 Docker 官方镜像里的一个。GitLab、Nextcloud、Gitea 这些常用的开源应用都有官方镜像，部署逻辑和本文完全一样——写 yml、填环境变量、定义数据卷、up 起服务。会了这一套，等于解锁了云服务器上大部分应用的部署能力。

7.3 记录与文档化的习惯

操作服务器时随手把命令记录到本地笔记，这样半年后服务器出了问题、或换新机器时，不需要回忆到底装了什么、改过什么配置。我每台服务器都维护一份简单的部署日志，包含：系统版本、Docker 版本、每个容器的用途和端口、关键环境变量、备份策略。这份文档的价值在出故障的时候才会真正体现——不用从头排查。

8. 给零基础用户的最终建议和踩坑清单

最后把这次部署的要点浓缩成一份可以直接照做的清单。按这个顺序操作，大概率一次成功。

8.1 执行顺序清单

1. 买一台雨云云服务器，1核2G 起，系统选 Ubuntu 22.04 LTS
2. SSH 连上后先 apt update 升级系统
3. 安装 Docker，配置镜像加速器
4. 创建 ~/wordpress 目录，写入 docker-compose.yml
5. docker compose up -d 启动
6. 公网 IP 打开浏览器完成 WordPress 初始化
7. 域名做 A 记录解析
8. 部署 NPM，配置反向代理和 HTTPS 证书
9. 写备份脚本并加入 crontab

8.2 过程中最容易踩的五个坑

• 3306 端口对外开放：数据库成为攻击目标，千万别开
• WordPress 容器和 MySQL 容器的数据库密码不一致：初始化时反复报错
• 修改 yml 后没有 docker compose down 直接 up：端口冲突，需要先 down 再 up
• HTTPS 证书申请失败：先确认域名解析已生效、80/443 端口从公网可访问
• 备份脚本没加执行权限：crontab 静默失败，备份一直没执行

8.3 最后分享一个我的习惯

博客上线之后，我第一时间去后台把固定链接改成"文章名"格式，在设置里把评论开启人工审核。前者让 URL 更简洁，后者防止垃圾评论直接把站点淹没。这些小细节不在部署教程里，但会影响日后的使用体验。

这次用雨云部署的整套流程，我最大的体会是：零基础部署不是记住每条命令，而是理解数据流和容器隔离的思路。思路通了，用什么云厂商、装什么系统，都只是换个入口的事。按照上面的步骤走完一遍，你收获的不只是一个能访问的博客，还有今后操作任何云服务器时的底气和判断力。