最近又上线了一个新的 WordPress 网站。
如果是几年前,我大概率会直接安装:
- Nginx
- PHP
- MySQL
然后开始配置 PHP-FPM、伪静态、SSL 证书。
但现在已经很少这么做了。
不是因为传统方式不好,而是这些年维护过太多服务器之后,发现 Docker 在部署 WordPress 这件事上确实省心太多。
尤其是当网站越来越多的时候。
以前迁移网站,需要:
- 导出数据库
- 导出网站文件
- 安装 PHP 环境
- 安装 MySQL
- 配置 Nginx
- 配置 HTTPS
运气好半小时搞定。
运气不好,一个环境问题能折腾一晚上。
后来开始把 WordPress 放进 Docker 里之后,很多问题就变得简单了。
今天分享一下我目前比较常用的一套部署方案。
为什么选择 Docker 部署 WordPress
先说结论。
如果现在让我重新搭建一个 WordPress 网站。
Docker 一定是首选。
原因主要有三个。
环境统一
无论是腾讯云、阿里云还是海外 VPS。
只要安装了 Docker。
运行结果基本一致。
不会出现:
本地正常
服务器报错
这种情况。
对于开发人员来说,这一点非常重要。
迁移方便
很多个人站长一年总会换几次服务器。
可能是因为:
- 服务器到期
- 想升级配置
- 想换服务商
传统方式迁移网站相对繁琐。
Docker 则简单很多。
整个项目目录复制过去。
执行:
docker compose up -d
网站基本就恢复了。
备份简单
很多时候网站出问题并不是程序问题。
而是误操作。
比如:
- 插件更新失败
- 数据库损坏
- 主题修改出错
Docker 的目录结构非常适合做备份。
直接打包即可。
准备工作
本文环境:
- Ubuntu 24.04
- Docker
- Docker Compose
安装 Docker:
curl -fsSL https://get.docker.com | bash
安装完成后验证:
docker -v
docker compose version
如果能够正常显示版本号,说明安装成功。
创建项目目录
创建一个用于存放 WordPress 的目录:
mkdir wordpress
cd wordpress
后面所有数据都会保存在这里。
创建 Docker Compose 配置
新建:
docker-compose.yml
内容如下:
services:
db:
image: mysql:8.0
container_name: wordpress-db
restart: always
environment:
MYSQL_DATABASE: wordpress
MYSQL_USER: wpuser
MYSQL_PASSWORD: yourpassword
MYSQL_ROOT_PASSWORD: rootpassword
volumes:
- ./mysql:/var/lib/mysql
wordpress:
image: wordpress:latest
container_name: wordpress
restart: always
depends_on:
- db
ports:
- "8082:80"
environment:
WORDPRESS_DB_HOST: db:3306
WORDPRESS_DB_USER: wpuser
WORDPRESS_DB_PASSWORD: yourpassword
WORDPRESS_DB_NAME: wordpress
volumes:
- ./wordpress:/var/www/html
保存后执行:
docker compose up -d
启动容器。
查看容器状态
执行:
docker ps
正常情况下应该看到:
wordpress
wordpress-db
两个容器正在运行。
开始安装 WordPress
浏览器访问:
此时会出现 WordPress 安装界面。
http://服务器IP:8082
填写:
- 网站名称
- 管理员账号
- 登录密码
- 邮箱地址
完成安装。
到这里 WordPress 已经可以正常使用。
为什么我不建议直接开放 8082 端口
很多教程到这里就结束了。
但如果是生产环境。
我并不建议这样访问:
http://ip:8082
或者:
http://domain.com:8082
原因很简单。
用户不会记端口。
搜索引擎也更喜欢规范的 URL。
正确方式应该是:
https://yourdomain.com
因此还需要增加一层 Nginx。
使用 Nginx 反向代理
80 端口负责跳转 HTTPS:
server {
listen 80;
server_name yourdomain.com www.yourdomain.com;
return 301 https://$host$request_uri;
}
HTTPS 配置:
server {
listen 443 ssl;
server_name yourdomain.com www.yourdomain.com;
ssl_certificate /etc/nginx/ssl/cert.pem;
ssl_certificate_key /etc/nginx/ssl/cert.key;
location / {
proxy_pass http://127.0.0.1:8082;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
}
}
配置完成后:
nginx -s reload
即可通过域名访问网站。
WordPress 自动跳转端口的问题
这是很多人第一次部署时都会遇到的问题。
访问:
https://yourdomain.com
结果自动跳转:
https://yourdomain.com:8082
看起来像是 Nginx 配置错误。
实际上大部分时候是 WordPress 设置问题。
进入后台:
设置 → 常规
检查:
WordPress Address(URL)
Site Address(URL)
确保填写的是:
https://yourdomain.com
而不是:
http://服务器IP:8082
否则 WordPress 会按照配置自动跳转。
Cloudflare 用户需要注意什么
如果网站接入了 Cloudflare。
建议 SSL 模式直接选择:
Full (Strict)
不要使用 Flexible。
Flexible 模式容易导致:
- 无限重定向
- Mixed Content
- HTTPS 异常
如果你遇到了 Cloudflare SSL 证书相关问题,可以参考我之前单独写的文章:
👉 WordPress 接入 Cloudflare 后出现 Error 526,我是这样解决的
WordPress 数据如何备份
很多新手以为备份数据库就够了。
实际上还需要备份上传文件。
我的习惯是直接备份整个项目目录。
例如:
wordpress/
├── docker-compose.yml
├── mysql
└── wordpress
执行:
tar -czvf wordpress-backup.tar.gz .
即可完成完整备份。
恢复时:
tar -zxvf wordpress-backup.tar.gz
docker compose up -d
网站就会恢复。
我目前的生产环境配置
对于个人博客。
一般使用:
WordPress
+
MySQL
+
Nginx
+
Cloudflare
已经完全够用。
如果访问量开始增长。
再增加:
Redis
+
对象存储
+
自动备份
即可。
没有必要一开始就堆各种复杂架构。
很多站长网站一天几十个访问。
却搭了一套大型分布式系统。
实际上完全没有必要。
这些年使用 WordPress 的一点经验
这些年做过企业官网、博客站、内容站。
踩过不少坑。
最大的感受是:
不要过度依赖插件。
很多问题其实服务器层面就能解决。
插件装得越多:
- 网站越慢
- 出问题概率越高
- 迁移越麻烦
能少装一个插件就少装一个插件。
Docker 也是同样的道理。
刚开始可能觉得学习成本高一点。
但当你经历过几次网站迁移之后。
你会发现:
docker compose up -d
可能是 WordPress 部署过程中最舒服的一条命令。
至少到目前为止。
Docker 已经成为我部署 WordPress 的默认方案,没有之一。
常见问题
Docker 部署 WordPress 会影响 SEO 吗?
不会。
搜索引擎并不关心你的网站运行在 Docker、宝塔还是传统 LNMP 环境。
影响排名的核心因素仍然是:
- 内容质量
- 页面速度
- 网站结构
- 用户体验
Docker 部署 WordPress 适合生产环境吗?
完全适合。
目前大量企业官网、博客和内容网站都在使用 Docker 部署。
维护和迁移成本更低。
Docker 部署 WordPress 推荐什么服务器配置?
个人博客:
1核CPU
2GB内存
40GB SSD
即可运行。
如果安装插件较多:
2核CPU
4GB内存
体验更好。
[…] 如果是用Docker部署的,那修改起来就会简单许多,所以我现在一直在用Docker部署了 Docker 部署 WordPress 实战记录:为什么我现在建站基本都用 Docker […]