Ansible一键部署LAMP+WordPress生产级流水线

1. 项目概述：用Ansible在Ubuntu 18.04上一键部署LAMP+WordPress，不是“写脚本”，而是构建可复现的生产级交付流水线

你有没有过这样的经历：在三台新买的云服务器上装WordPress，第一台手动敲命令，花了两小时，中途被运维叫去处理告警；第二台照着第一台的笔记操作，漏改了一个Apache虚拟主机配置，网站打不开，又花四十分钟排查；第三台想用Shell脚本自动化，结果发现PHP版本不一致、MySQL密码策略变了、防火墙规则没开80端口——最后还是得挨个登录调试。这不是效率问题，是交付方式本身出了问题。这个标题“Cómo usar Ansible para instalar y configurar WordPress con LAMP en Ubuntu 18.04”表面看是个西班牙语教程，但背后真正要解决的，是Linux系统管理员和DevOps工程师每天都在面对的“环境漂移”顽疾：同一套应用，在不同时间、不同机器、不同人手上，部署结果永远无法保证完全一致。Ansible在这里不是替代Shell的“高级命令行”，而是一套声明式基础设施即代码（IaC）的实践范式——你告诉它“我要一个能跑WordPress的LAMP环境”，而不是“先apt update，再apt install apache2，然后改/etc/apache2/sites-available/000-default.conf……”。Ubuntu 18.04作为当时LTS版本，其软件源中PHP 7.2、MySQL 5.7、Apache 2.4的组合，恰好构成了一个稳定但需要精细调优的黄金栈，而Ansible的role机制、变量分层、条件判断和幂等性设计，正是驾驭这套栈最贴合的缰绳。我从2016年开始用Ansible管理上百台生产服务器，踩过无数坑：比如MySQL 5.7默认启用严格模式导致WordPress安装失败；比如Apache的mpm_prefork模块在Ubuntu 18.04中默认未启用，导致高并发下直接503；比如WordPress自动更新插件时因权限问题写入失败却无日志提示。这些都不是“配置错误”，而是对操作系统底层行为、服务启动顺序、文件系统权限模型理解不足导致的必然结果。所以这篇内容，不会教你“复制粘贴几行ansible-playbook命令”，而是带你拆解：为什么必须用Ansible的handlers来重启Apache而不是tasks？为什么WordPress数据库密码不能硬编码在playbook里？为什么LAMP各组件的安装顺序必须是Apache→MySQL→PHP→WordPress，颠倒任何一环都会触发不可逆的依赖错误？如果你正被重复性部署折磨，或者刚接触Ansible却总在“playbook跑不通”和“role看不懂”之间反复横跳，那接下来的内容，就是你真正需要的、能直接抄作业的实战手册。

2. 整体架构设计与核心思路拆解：为什么不用Docker而坚持原生LAMP？Ansible的role分层逻辑如何映射真实运维场景？

很多人看到“部署WordPress”第一反应是Docker Compose，三行yaml搞定。但现实中的生产环境远比这复杂：客户要求所有服务必须运行在物理机或KVM虚拟机上，禁用容器；安全审计要求每个服务有独立的systemd单元、独立的日志路径、独立的用户隔离；监控系统只认传统进程名（如apache2、mysqld），不识别容器ID。这就是我们坚持用Ansible原生部署LAMP的真实原因——不是技术保守，而是业务约束下的理性选择。整个方案采用三层role架构：lamp-base、lamp-stack、wordpress-site，每一层都对应一个明确的运维责任域。lamp-base负责操作系统层加固：禁用root SSH登录、配置UFW防火墙默认拒绝、设置时区和NTP同步、创建专用部署用户（如wpadmin）并赋予sudo免密权限。这里有个关键细节：Ubuntu 18.04的/etc/sudoers.d/目录默认存在，但文件后缀必须是.conf，否则visudo -c校验会失败，而Ansible的copy模块默认不加后缀，必须显式指定dest: /etc/sudoers.d/wpadmin.conf。lamp-stack是真正的LAMP核心，但它被拆成三个子role：apache2、mysql57、php72。这种拆分不是为了炫技，而是源于真实运维痛点——Apache和PHP的配置耦合度极高，但MySQL的升级周期和Apache完全不同。当客户要求将MySQL从5.7升级到8.0时，你绝不想重跑整个LAMP playbook，只更新mysql57为mysql80角色即可。wordpress-site则完全解耦：它不关心底层是Apache还是Nginx，只通过template模块渲染wp-config.php.j2模板，从Ansible变量中注入数据库地址、表前缀、密钥盐值。这种设计让整个部署流程具备了真正的“可组合性”：你可以用同一个lamp-stackrole部署十个不同客户的WordPress站点，只需切换不同的wordpress-site变量文件。更关键的是幂等性保障——Ansible的service模块在state: started时，如果服务已运行，它什么也不做；而command模块执行systemctl start apache2则每次都会触发一次启动，可能中断正在处理的请求。我见过太多新手在playbook里滥用command，结果在生产环境造成服务闪断。所以整个架构的底层逻辑就一句话：用Ansible的原生模块（而非shell命令）表达意图，用role分层隔离变更域，用变量文件抽象环境差异。这不仅是技术选型，更是运维思维的升级。

2.1 为什么Ubuntu 18.04的LAMP栈需要特殊对待？三个被官方文档刻意忽略的关键陷阱

Ubuntu 18.04的LAMP栈看似标准，实则埋着三个深坑，任何一份“通用教程”都不会告诉你，因为它们只在特定负载下才会暴露。第一个是MySQL 5.7的sql_mode默认值。官方文档说“默认启用严格模式”，但没说清楚具体启用了哪些模式。实测发现，默认sql_mode='STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION'，其中STRICT_TRANS_TABLES会导致WordPress安装时创建wp_options表失败——因为WordPress的SQL语句中有INSERT INTO wp_options (option_name, option_value, autoload) VALUES ('cron', 'xxx', 'yes')，而option_value字段定义为longtext，但某些旧版WordPress插件会尝试插入超长字符串，严格模式下直接报错。解决方案不是关掉严格模式（安全风险），而是用Ansible的mysql_variables模块动态修改：name: sql_mode value: "NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"，主动剔除STRICT_TRANS_TABLES。第二个坑是Apache的MPM（Multi-Processing Module）选择。Ubuntu 18.04默认安装apache2-bin包，但mpm_prefork模块并未启用。而WordPress的PHP模块（libapache2-mod-php7.2）强制依赖prefork，否则Apache启动时会报Invalid MPM。很多教程让你手动执行a2enmod mpm_prefork，但在Ansible中，这必须放在apache2role的handlers里，并确保它在apache2服务启动前执行，否则playbook会卡死。第三个坑最隐蔽：PHP 7.2的opcache配置。Ubuntu源里的php7.2-opcache默认opcache.enable=0，而WordPress重度依赖OPcache加速，不开启会导致首页加载时间从300ms飙升到1.2秒。Ansible必须用lineinfile模块精准定位/etc/php/7.2/apache2/php.ini中的opcache.enable行，将其改为1，且要确保该行不在注释状态（即前面不能有;）。这三个问题，没有一个能在ansible-galaxy社区role里直接找到现成解决方案，因为它们是Ubuntu 18.04特定版本与WordPress特定生态碰撞出的独特产物。你的playbook如果没覆盖这三点，就算语法全对，部署出来的WordPress也注定是“能跑但很慢、偶发报错”的残缺品。

2.2 Ansible role的变量分层设计：如何用group_vars和host_vars实现“一套代码，百种环境”

新手常犯的错误，是把所有变量都写在playbook顶部的vars:块里，结果换一台服务器就要改一次playbook。真正的Ansible工程化实践，是建立四层变量作用域：inventory变量 → group_vars → host_vars → playbook vars，优先级从低到高。以这个WordPress部署为例，group_vars/all.yml存放所有环境共用的基础变量：

# group_vars/all.yml php_version: "7.2" mysql_root_password: "{{ vault_mysql_root_password }}" wp_admin_user: "wpadmin" wp_admin_ssh_key: "ssh-rsa AAAAB3NzaC1yc2E... user@host"

注意mysql_root_password用了vault_前缀，这是Ansible Vault加密变量的标准命名约定，避免明文密码泄露。group_vars/webservers.yml则定义Web服务器特有变量：

# group_vars/webservers.yml apache_vhosts: - name: "example.com" document_root: "/var/www/example.com/public_html" server_name: "example.com" ssl_enabled: true

而host_vars/web01.example.com.yml存放单台主机的唯一标识信息：

# host_vars/web01.example.com.yml hostname: "web01" ip_address: "192.168.1.101" disk_partitions: - { mount: "/", size: "20G" } - { mount: "/var/www", size: "50G" }

最后，playbook本身只保留最顶层的逻辑控制变量：

# site.yml - hosts: webservers become: true vars: deploy_wordpress: true enable_ssl: "{{ ssl_enabled | default(false) }}" roles: - lamp-base - lamp-stack - { role: wordpress-site, when: deploy_wordpress }

这种分层不是为了炫技，而是解决真实协作问题。运维团队负责维护group_vars，开发团队提供host_vars中的应用路径和域名，安全团队审核group_vars/all.yml中的密码策略。当客户要求“给测试环境加一个临时子域名”，你只需在group_vars/staging.yml里新增一条apache_vhosts记录，无需动任何role代码。我曾用这套体系管理过47个不同客户的WordPress站点，所有环境变更都通过Git提交，回滚只需git checkout上一个commit，比任何“一键回滚脚本”都可靠。变量分层的本质，是把“环境差异”从代码中剥离出来，变成可版本控制、可审计、可协作的配置数据。

3. 核心组件实现与关键参数详解：从Apache虚拟主机到WordPress密钥盐值，每一步都附带生产环境验证数据

部署WordPress不是终点，而是性能与安全调优的起点。下面拆解四个核心环节的实现细节，全部基于我在生产环境实测的数据：Apache并发连接数、MySQL查询缓存命中率、PHP OPcache内存占用、WordPress密钥盐值生成算法。

3.1 Apache 2.4虚拟主机配置：为什么必须用template模块而非copy？SSL证书路径的动态拼接逻辑

很多教程用copy模块把写死的000-default.conf复制过去，这在单站环境可行，但多站环境下会崩溃。正确做法是用Jinja2模板templates/vhost.conf.j2，结合Ansible的loop和dict2items过滤器动态生成：

# templates/vhost.conf.j2 {% for vhost in apache_vhosts %} <VirtualHost *:80> ServerAdmin webmaster@localhost ServerName {{ vhost.server_name }} DocumentRoot {{ vhost.document_root }} <Directory "{{ vhost.document_root }}"> Options Indexes FollowSymLinks AllowOverride All Require all granted </Directory> ErrorLog ${APACHE_LOG_DIR}/{{ vhost.name }}_error.log CustomLog ${APACHE_LOG_DIR}/{{ vhost.name }}_access.log combined {% if vhost.ssl_enabled | default(false) %} Redirect permanent / https://{{ vhost.server_name }}/ {% endif %} </VirtualHost> {% if vhost.ssl_enabled | default(false) %} <VirtualHost *:443> ServerAdmin webmaster@localhost ServerName {{ vhost.server_name }} DocumentRoot {{ vhost.document_root }} SSLEngine on SSLCertificateFile /etc/ssl/certs/{{ vhost.name }}.crt SSLCertificateKeyFile /etc/ssl/private/{{ vhost.name }}.key {% if vhost.ssl_chain_file is defined %} SSLCertificateChainFile /etc/ssl/certs/{{ vhost.ssl_chain_file }} {% endif %} <Directory "{{ vhost.document_root }}"> Options Indexes FollowSymLinks AllowOverride All Require all granted </Directory> ErrorLog ${APACHE_LOG_DIR}/{{ vhost.name }}_ssl_error.log CustomLog ${APACHE_LOG_DIR}/{{ vhost.name }}_ssl_access.log combined </VirtualHost> {% endif %} {% endfor %}

关键点在于SSL证书路径的动态拼接。SSLCertificateFile的值不是硬编码/etc/ssl/certs/example.com.crt，而是/etc/ssl/certs/{{ vhost.name }}.crt，这样当apache_vhosts列表里有{name: "blog.example.com", server_name: "blog.example.com"}时，Ansible会自动渲染为/etc/ssl/certs/blog.example.com.crt。证书文件本身由另一个role（如ssl-certs）提前部署，路径完全解耦。实测数据：在4核8G的云服务器上，启用mod_ssl后Apache内存占用增加约120MB，但HTTPS握手延迟从平均85ms降至32ms（使用OCSP Stapling优化后）。更重要的是，这种模板方式让添加新站点变成“改一行YAML”，而不是“登录服务器改三处配置”。

3.2 MySQL 5.7数据库初始化：为什么用mysql_db模块创建数据库，却必须用mysql_user模块单独授权？

Ansible的mysql_db模块可以创建数据库，mysql_user模块可以创建用户并授权，但新手常犯的错误是试图用mysql_db的login_user参数直接授予权限。这是行不通的，因为mysql_db模块的login_user仅用于连接认证，不涉及权限分配。正确的链路是：先用mysql_db创建数据库，再用mysql_user创建用户并授予ALL PRIVILEGES ON database_name.* TO 'user'@'localhost'。更关键的是mysql_user的priv参数写法：

- name: Create WordPress database user mysql_user: login_user: "{{ mysql_root_user }}" login_password: "{{ mysql_root_password }}" name: "{{ wp_db_user }}" password: "{{ wp_db_password }}" priv: "{{ wp_db_name }}.*:ALL" state: present

注意priv值是"{{ wp_db_name }}.*:ALL"，不是"{{ wp_db_name }}.*:ALL PRIVILEGES"。后者会报错，因为Ansible的mysql_user模块内部调用的是GRANT ALL ON ...语句，不需要显式写PRIVILEGES。实测发现，如果省略priv参数，Ansible会创建用户但不授予权限，WordPress安装时连数据库都连不上，错误日志里只显示“Can't connect to database”，根本看不出是权限问题。另一个易错点是mysql_user的host参数。WordPress默认用localhost连接，但MySQL的localhost和127.0.0.1是两个不同的host（前者走socket，后者走TCP），必须明确指定host: localhost，否则用户创建在'user'@'%'上，安全性大打折扣。我在一次安全审计中发现，某客户环境因host参数缺失，WordPress数据库用户被授予了'wpuser'@'%'权限，导致内网任意机器都能连接该数据库。

3.3 PHP 7.2配置调优：OPcache内存大小计算公式与realpath_cache_size的实际影响

PHP的opcache.memory_consumption不是越大越好。计算公式是：OPcache内存 = (单个PHP文件平均大小 × 并发请求数 × 文件数) × 1.2。实测WordPress 5.8核心文件约1200个，平均大小12KB，4核CPU典型并发按200计算，则12KB × 200 × 1200 × 1.2 ≈ 3.4MB。但考虑到插件和主题，我们设为128（单位MB），这是经过压力测试验证的安全值。Ansible配置如下：

- name: Configure PHP OPcache lineinfile: path: "/etc/php/{{ php_version }}/apache2/php.ini" regexp: "^opcache.memory_consumption=" line: "opcache.memory_consumption=128" state: present

另一个常被忽视的参数是realpath_cache_size。WordPress大量使用include_once和require_once，每次都会触发realpath()系统调用。Ubuntu 18.04默认realpath_cache_size=4096，但实测在WordPress多插件环境下，缓存命中率仅68%。我们将它提升到1024K：

- name: Increase realpath cache size lineinfile: path: "/etc/php/{{ php_version }}/apache2/php.ini" regexp: "^realpath_cache_size=" line: "realpath_cache_size=1024K" state: present

压力测试对比：realpath_cache_size=4096时，ab -n 1000 -c 100 http://example.com/平均响应时间210ms；提升到1024K后，降至165ms，性能提升21.4%。这证明，PHP调优不是盲目堆参数，而是基于真实请求链路的精准干预。

3.4 WordPress核心配置：wp-config.php模板中的密钥盐值生成逻辑与数据库连接池控制

wp-config.php是WordPress的命脉，其安全性直接决定站点生死。Ansible必须用template模块生成，而非copy，因为密钥盐值（salts）必须每次部署都重新生成。Jinja2模板templates/wp-config.php.j2关键片段：

// templates/wp-config.php.j2 <?php define('DB_NAME', '{{ wp_db_name }}'); define('DB_USER', '{{ wp_db_user }}'); define('DB_PASSWORD', '{{ wp_db_password }}'); define('DB_HOST', '{{ wp_db_host | default("localhost") }}'); define('DB_CHARSET', 'utf8mb4'); define('DB_COLLATE', ''); // 自动生成密钥盐值 define('AUTH_KEY', '{{ salt_auth_key }}'); define('SECURE_AUTH_KEY', '{{ salt_secure_auth_key }}'); define('LOGGED_IN_KEY', '{{ salt_logged_in_key }}'); define('NONCE_KEY', '{{ salt_nonce_key }}'); define('AUTH_SALT', '{{ salt_auth_salt }}'); define('SECURE_AUTH_SALT', '{{ salt_secure_auth_salt }}'); define('LOGGED_IN_SALT', '{{ salt_logged_in_salt }}'); define('NONCE_SALT', '{{ salt_nonce_salt }}'); // 数据库连接池控制 define('WP_ALLOW_REPAIR', false); define('WP_MEMORY_LIMIT', '256M'); if (!defined('WP_DEBUG')) { define('WP_DEBUG', false); }

密钥盐值从哪里来？Ansible没有内置函数，但我们用password_hash过滤器结合lookup('pipe', 'openssl rand -base64 48')生成：

- name: Generate WordPress salts set_fact: salt_auth_key: "{{ lookup('pipe', 'openssl rand -base64 48') | regex_replace('[^a-zA-Z0-9!@#$%^&*()_+-=[]{}|;:,.<>]', '') }}" salt_secure_auth_key: "{{ lookup('pipe', 'openssl rand -base64 48') | regex_replace('[^a-zA-Z0-9!@#$%^&*()_+-=[]{}|;:,.<>]', '') }}" # ... 其他7个salt同理

regex_replace是为了过滤掉openssl生成的+、/等可能导致PHP解析错误的字符。数据库连接池控制体现在DB_HOST参数——不要写死localhost，而要用{{ wp_db_host | default("localhost") }}，这样当需要迁移到RDS时，只需在host_vars里覆盖wp_db_host: my-rds-instance.us-east-1.rds.amazonaws.com，无需改任何模板。实测数据：在高并发场景下，DB_HOST设为127.0.0.1（强制TCP）比localhost（默认socket）连接建立时间快15%，但socket在低延迟内网更优。Ansible的变量默认机制，让我们能根据网络拓扑动态选择最优路径。

4. 完整实操流程与部署验证：从inventory初始化到WordPress安装完成，每步附带命令行输出与故障快照

现在进入真正的动手环节。以下流程基于真实生产环境记录，所有命令和输出均来自2023年对Ubuntu 18.04服务器的实测。假设你已有一台全新安装的Ubuntu 18.04服务器，IP为192.168.1.101，SSH密钥已配置。

4.1 初始化Ansible环境与inventory配置：为什么inventory必须用INI格式而非YAML？

Ansible官方推荐YAML格式inventory，但生产环境强烈建议用INI格式，因为它的注释支持和分组语法更直观。创建inventory/production：

# inventory/production [webservers] web01 ansible_host=192.168.1.101 ansible_user=ubuntu [webservers:vars] ansible_become=true ansible_become_method=sudo [all:vars] # 全局变量在此定义，但实际应放入group_vars

关键点：ansible_become=true表示所有任务默认提权，ansible_become_method=sudo指定提权方式。为什么不用YAML？因为YAML inventory在大型环境中难以快速定位主机，且注释语法（#）不如INI直观。执行首次连接测试：

$ ansible -i inventory/production webservers -m ping web01 | SUCCESS => { "ansible_facts": { "discovered_interpreter_python": "/usr/bin/python3" }, "changed": false, "ping": "pong" }

如果出现UNREACHABLE!，90%概率是SSH密钥未正确配置。此时不要急着查Ansible，先手动SSH：ssh -i ~/.ssh/id_rsa ubuntu@192.168.1.101。如果手动能连，检查Ansible的ansible_ssh_private_key_file变量是否指向正确密钥路径。

4.2 执行LAMP基础环境部署：从系统更新到Apache启动，关键日志截取与状态确认

运行基础环境playbook：

$ ansible-playbook -i inventory/production site.yml --tags "lamp-base,lamp-stack"

--tags参数确保只运行指定role，避免误触WordPress部署。成功输出节选：

TASK [lamp-base : Update apt cache] ******************************************** ok: [web01] TASK [lamp-base : Install system packages] ************************************* ok: [web01] => (item=ufw) ok: [web01] => (item=ntp) TASK [apache2 : Enable mpm_prefork module] *********************************** changed: [web01] TASK [apache2 : Start and enable apache2 service] **************************** changed: [web01] RUNNING HANDLER [apache2 : restart apache2] ********************************** changed: [web01]

注意RUNNING HANDLER行——这证明handlers被正确触发。验证Apache状态：

$ ansible -i inventory/production web01 -m command -a "systemctl is-active apache2" web01 | SUCCESS | rc=0 >> active $ ansible -i inventory/production web01 -m command -a "curl -s http://localhost | head -n 5" web01 | SUCCESS | rc=0 >> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> <title>Apache2 Ubuntu Default Page</title>

看到Apache2 Ubuntu Default Page，说明LAMP基础环境已就绪。如果curl返回空或超时，立即检查UFW状态：ansible -i inventory/production web01 -m command -a "ufw status verbose"，确保80/tcp端口是ALLOW状态。

4.3 部署WordPress并验证安装：从数据库创建到wp-admin访问，完整HTTP状态码追踪

执行完整部署：

$ ansible-playbook -i inventory/production site.yml

关键任务输出：

TASK [mysql57 : Create WordPress database] *********************************** changed: [web01] TASK [mysql57 : Create WordPress database user] ****************************** changed: [web01] TASK [wordpress-site : Download WordPress archive] *************************** changed: [web01] TASK [wordpress-site : Extract WordPress archive] **************************** changed: [web01] TASK [wordpress-site : Copy wp-config.php from template] ********************* changed: [web01] TASK [wordpress-site : Set permissions for WordPress files] ****************** changed: [web01]

验证WordPress文件权限：

$ ansible -i inventory/production web01 -m command -a "ls -la /var/www/example.com/public_html/" web01 | SUCCESS | rc=0 >> total 212 drwxr-xr-x 5 wpadmin wpadmin 4096 Apr 10 14:22 . drwxr-xr-x 3 root root 4096 Apr 10 14:22 .. -rw-r--r-- 1 wpadmin wpadmin 418 Apr 10 14:22 index.php -rw-r--r-- 1 wpadmin wpadmin 19935 Apr 10 14:22 license.txt ...

wp-admin目录权限必须是755，wp-config.php必须是644，且属主为wpadmin。最后，用curl模拟浏览器访问安装页面：

$ ansible -i inventory/production web01 -m command -a "curl -I http://example.com/wp-admin/install.php" web01 | SUCCESS | rc=0 >> HTTP/1.1 200 OK Date: Tue, 10 Apr 2023 14:25:33 GMT Server: Apache/2.4.29 (Ubuntu) X-Powered-By: PHP/7.2.24-0ubuntu0.18.04.12 Content-Type: text/html; charset=utf-8

HTTP/1.1 200 OK是关键信号。如果返回302 Found跳转到install.php?step=1，说明WordPress已检测到未安装状态，准备就绪。此时在浏览器打开http://your-server-ip/wp-admin/install.php，即可进行图形化安装。整个过程从零开始，耗时约4分30秒，且全程无人工干预。

4.4 部署后安全加固：禁用XML-RPC与强制HTTPS重定向的Ansible实现

WordPress安装完成后，必须立即加固。两个最高危项：XML-RPC接口（被用于暴力破解和DDoS反射攻击）和HTTP明文传输。Ansible实现：

# roles/wordpress-security/tasks/main.yml - name: Disable XML-RPC via .htaccess copy: content: | # Block XML-RPC <Files "xmlrpc.php"> Order Deny,Allow Deny from all </Files> dest: /var/www/example.com/public_html/.htaccess owner: wpadmin group: www-data mode: '0644' - name: Force HTTPS redirect in Apache vhost lineinfile: path: "/etc/apache2/sites-available/{{ apache_vhosts[0].name }}.conf" regexp: '^(\s*)Redirect permanent / https://' line: ' Redirect permanent / https://{{ apache_vhosts[0].server_name }}/' insertbefore: '^</VirtualHost>' state: present

验证XML-RPC禁用：

$ ansible -i inventory/production web01 -m command -a "curl -I http://example.com/xmlrpc.php" web01 | SUCCESS | rc=0 >> HTTP/1.1 403 Forbidden Date: Tue, 10 Apr 2023 14:30:22 GMT Server: Apache/2.4.29 (Ubuntu) Content-Type: text/html; charset=iso-8859-1

403 Forbidden证明生效。验证HTTPS重定向：

$ ansible -i inventory/production web01 -m command -a "curl -I http://example.com/" web01 | SUCCESS | rc=0 >> HTTP/1.1 301 Moved Permanently Date: Tue, 10 Apr 2023 14:31:05 GMT Server: Apache/2.4.29 (Ubuntu) Location: https://example.com/ Content-Type: text/html; charset=iso-8859-1

301 Moved Permanently和Location头证明重定向配置正确。这两步加固，能在部署完成5分钟内，将WordPress站点从“高危目标”转变为“基础防护达标”。

5. 常见问题与深度排查技巧实录：从“playbook卡在mysql_user”到“WordPress白屏”，一线工程师的排错清单

即使最完美的playbook，在真实世界也会遇到各种意外。以下是我在过去三年处理过的127个WordPress部署问题中，高频TOP5问题的完整排错指南，每一条都附带真实终端输出和根因分析。

5.1 问题：playbook在mysql_user任务卡住，SSH连接超时，但手动登录MySQL正常

现象：Ansible输出卡在TASK [mysql57 : Create WordPress database user]，10分钟后报错FAILED! => {"msg": "Timeout when waiting for search string..."，但手动mysql -u root -p能正常登录。

根因分析：Ubuntu 18.04的MySQL 5.7默认启用validate_password插件，要求密码必须包含大小写字母、数字和特殊字符。而Ansible的mysql_user模块生成的密码（如wp_db_password: "wordpress123"）不满足此策略，MySQL拒绝创建用户，但Ansible的错误处理机制未能捕获此异常，导致无限等待。

排查步骤：

1. 登录服务器，查看MySQL错误日志：sudo tail -f /var/log/mysql/error.log
2. 发现关键日志：[Warning] Failed to load validation plugin 'validate_password'和ERROR 1819 (HY000): Your password does not satisfy the current policy requirements
3. 临时禁用密码策略：sudo mysql -u root -e "SET GLOBAL validate_password_policy=LOW;"

Ansible修复方案：在mysql57role的tasks/main.yml开头添加预检任务：

- name: Check and disable MySQL password policy if needed mysql_query: login_user: "{{ mysql_root_user }}" login_password: "{{ mysql_root_password }}" state: query query: "SET GLOBAL validate_password_policy=LOW;" ignore_errors: yes

提示：ignore_errors: yes是关键，因为该命令在密码策略未启用时会报错，但不影响后续执行。

5.2 问题：WordPress安装页面显示“Error establishing a database connection”，但mysql命令行能连通

现象：浏览器访问/wp-admin/install.php显示经典错误，但mysql -u wpuser -p -h localhost wordpressdb能成功登录。

根因分析：wp-config.php中DB_HOST写成了127.0.0.1，而MySQL用户权限是'wpuser'@'localhost'。在MySQL中，localhost和127.0.0.1是两个不同的host，前者走Unix socket，后者走TCP/IP。WordPress用mysqli扩展连接时，若DB_HOST为127.0.0.1，会强制走TCP，但用户权限只给了localhost，导致拒绝连接。

排查步骤：

1. 检查wp-config.php：grep "DB_HOST" /var/www/example.com/public_html/wp-config.php
2. 输出：define('DB_HOST', '127.0.0.1');
3. 检查MySQL用户权限：sudo mysql -u root -e "SELECT User,Host FROM mysql.user WHERE User='wpuser';"
4. 输出：| wpuser | localhost |

Ansible修复方案：在wordpress-siterole的templates/wp-config.php.j2中，强制DB_HOST为localhost：

define('DB_HOST', 'localhost');

或更灵活地，用Ansible变量控制：

define('DB_HOST', '{{ wp_db_host | default("localhost") }}');

并在host_vars中明确设置wp_db_host: "localhost"。

5.3 问题：Apache启动失败，journalctl显示AH00526: Syntax error on line 23 of /etc/apache2/sites-enabled/000-default.conf

现象：systemctl status apache2显示failed，journalctl -u apache2报上述语法错误。

根因分析：Ansible的template模块渲染虚拟主机配置时