Ansible自动化部署LAMP+WordPress实战（Ubuntu 18.04）

1. 项目概述：用Ansible在Ubuntu 18.04上一键部署LAMP+WordPress，不是“跑个playbook”就完事

你是不是也经历过——花两小时手动配好Apache、MySQL、PHP，刚把WordPress解压进/var/www/html，一刷新页面却跳出“Error establishing a database connection”？或者改完wp-config.php里第十七次数据库密码，发现MySQL服务根本没启动？更别提下次要在三台测试机上重复这套流程时，那种想砸键盘的疲惫感。这正是我2019年接手客户网站运维时的真实状态：Ubuntu 18.04是当时LTS主力系统，LAMP栈稳定但配置细节琐碎，WordPress版本迭代快、权限要求严，而Ansible还没在团队普及。直到我把整个部署过程拆解成可复用、可验证、可回滚的Playbook，才真正从“救火队员”变成“架构守门人”。这个标题说的不是“用Ansible装个WordPress”，而是构建一套生产就绪的自动化交付流水线：它要能自动处理Ubuntu 18.04特有的systemd服务管理逻辑，要规避MySQL 5.7默认严格模式对WordPress表结构的报错，要解决PHP 7.2扩展缺失导致的插件兼容问题，还要在部署后自动执行安全加固——比如禁用XML-RPC接口（那年已有大量扫描器利用该接口暴力爆破），重命名wp-admin路径（虽然后来被证明效果有限，但客户坚持）。关键词里反复出现的“ansible安装部署”“wordpress靶场”，恰恰说明这不是一次性的实验，而是面向真实场景的工程实践：既要扛住日常更新，也要经得起安全审计。如果你正卡在“Ansible写了一半playbook却不知道下一步该校验什么”，或者“WordPress能跑但总被提示‘缺少GD库’”，这篇就是为你写的——所有步骤我都实测过三轮，连/tmp目录权限这种冷门坑都记在了注意事项里。

2. 整体设计思路与方案选型逻辑：为什么不用Docker，也不用一键脚本？

2.1 拒绝Docker：Ubuntu 18.04生产环境的现实约束

看到标题里“LAMP on Ubuntu 18.04”，第一反应可能是“直接上Docker Compose不香吗”？我试过。但在2019-2021年的真实客户环境中，Docker存在三个硬伤：一是客户服务器内核版本老旧（3.10.0-957），Docker CE 19.03要求最低3.10.0-1062，升级内核需重启且影响其他业务；二是SELinux策略未适配容器，Apache容器内无法绑定80端口（报错“Permission denied”）；三是日志审计要求——客户安全规范明确要求所有Web访问日志必须落盘到/var/log/apache2/并按月轮转，而容器日志默认走journald，对接现有ELK体系成本太高。所以最终选择原生LAMP栈，用Ansible精准控制每个服务的配置文件、服务状态和文件权限。

2.2 拒绝Shell一键脚本：可维护性才是核心瓶颈

网上搜“WordPress一键安装脚本”，十有八九是wget下载、chmod +x、./install.sh三连击。这类脚本在单机测试时很爽，但到生产环境立刻暴雷：没有错误处理（MySQL启动失败后脚本仍继续执行），没有幂等性（重复运行会覆盖已修改的wp-config.php），更没有状态校验（你以为PHP扩展装好了，其实gd.so路径写错了）。Ansible的changed_when、failed_when、check_mode: yes这些特性，本质是在构建基础设施的单元测试框架。比如MySQL服务检查，我们不用service mysql status这种模糊命令，而是用mysql -u root -e "SELECT 1;"直连验证，失败时明确提示“数据库连接拒绝，请检查root密码或socket路径”。

2.3 为什么锁定Ubuntu 18.04而非20.04？

标题明确指定18.04，这不是随意选择。Ubuntu 18.04 LTS支持周期到2023年4月（标准支持）+2028年4月（ESM扩展支持），而当时客户所有物理服务器BIOS固件仅兼容18.04的内核启动参数。更重要的是软件源差异：18.04默认PHP是7.2，而20.04是7.4——WordPress 5.3+虽支持7.4，但客户使用的付费主题（如Divi）在7.4下存在json_last_error_msg()函数兼容问题。我们通过apt_repository模块固定添加ppa:ondrej/php源，确保PHP版本可控，这比盲目升级系统更稳妥。

2.4 LAMP组件选型的深层考量

• Apache vs Nginx：客户CDN已启用Brotli压缩，而Nginx 1.14（18.04默认）不支持Brotli，需编译安装；Apache 2.4.29则通过mod_brotli模块原生支持。
• MySQL vs MariaDB：虽然MariaDB性能更好，但客户旧站数据备份是.sql格式，MySQL 5.7的mysqldump --skip-extended-insert生成的SQL在MariaDB 10.3中会出现ROW_FORMAT=COMPACT语法错误。
• PHP扩展取舍：除WordPress官方要求的curl,gd,mbstring,xml,zip外，我们额外启用opcache（提升PHP执行速度）和apcu（替代WordPress的object-cache.php插件），但禁用xdebug（生产环境严禁开启）。

提示：所有组件版本均来自Ubuntu 18.04官方仓库，避免手动编译。例如PHP扩展统一用apt install php7.2-gd php7.2-mbstring安装，而非pecl install——后者在离线环境会失败，且版本无法通过Ansible的package模块统一管理。

3. 核心细节解析与实操要点：从Playbook结构到每一行代码的深意

3.1 Playbook整体结构：为什么分四个Role而不是一个大文件？

初学者常把所有任务写进一个site.yml，结果200行代码里混着Apache配置、数据库创建、WordPress解压、安全加固……一旦某步失败，调试像大海捞针。我们采用标准Ansible Role结构：

roles/ ├── lamp-base # 基础环境：系统更新、时区、基础工具 ├── apache # Apache安装、虚拟主机配置、SSL证书申请（Let's Encrypt） ├── mysql # MySQL安装、root密码加固、WordPress专用数据库创建 └── wordpress # WordPress下载、解压、wp-config.php生成、权限设置

这种拆分不是为了“看起来专业”，而是解决职责隔离问题。比如mysqlRole里定义mysql_root_password变量，wordpressRole通过vars_files引用，避免密码硬编码；apacheRole的templates/vhost.conf.j2模板里用{{ wordpress_domain }}变量，由主Playbook传入，实现同一套代码部署多个站点。实测表明，当需要为新客户增加Redis缓存时，只需新建redisRole并调整依赖顺序，原有代码零修改。

3.2 关键任务详解：那些教科书不会告诉你的细节

3.2.1 系统初始化：lamp-baseRole里的生存法则

- name: Set timezone to Asia/Shanghai timezone: name: Asia/Shanghai - name: Configure apt to use mirrors.tuna.tsinghua.edu.cn lineinfile: path: /etc/apt/sources.list regexp: '^deb http://archive.ubuntu.com' line: 'deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic main restricted universe multiverse' backup: yes

为什么必须改源？Ubuntu 18.04默认源archive.ubuntu.com在国内延迟高达800ms，apt update常超时失败。清华源镜像同步延迟<5分钟，且支持HTTPS。注意backup: yes——Ansible执行前自动备份原文件，这是灾难恢复的第一道防线。

3.2.2 Apache虚拟主机：SSL证书的自动化生死线

- name: Install certbot and dependencies apt: name: - python3-certbot-apache - python3-acme state: present - name: Obtain and install SSL certificate command: certbot --apache -d {{ wordpress_domain }} --non-interactive --agree-tos --email {{ admin_email }} args: creates: /etc/letsencrypt/live/{{ wordpress_domain }}/fullchain.pem

这里有两个致命细节：

1. --non-interactive参数必须显式声明，否则certbot会等待用户输入，导致Ansible卡死；
2. args.creates指定证书文件路径，Ansible据此判断任务是否已执行（幂等性核心）。若证书已存在，该任务跳过，避免重复申请触发Let's Encrypt速率限制（每周5次）。

注意：生产环境务必先用--staging参数测试，确认DNS解析正常后再切到正式环境。我曾因DNS传播延迟，在 staging 环境申请成功，正式环境却报“Failed to connect to domain”，白白浪费一次额度。

3.2.3 MySQL安全加固：不止是改root密码

- name: Remove anonymous users mysql_user: name: '' host_all: yes state: absent login_user: root login_password: "{{ mysql_root_password }}" - name: Disallow root login remotely mysql_user: name: root host: '%' state: absent login_user: root login_password: "{{ mysql_root_password }}"

这两步针对的是MySQL 5.7默认安装的两个高危配置：匿名用户（空用户名）可无密码登录，root用户允许从任意IP连接。mysql_user模块的host_all: yes会匹配所有host，比手动写DELETE FROM mysql.user WHERE User='';更可靠。特别提醒：login_password必须用双大括号包裹变量，若写成login_password: mysql_root_password（无括号），Ansible会当作字符串字面量，导致认证失败。

3.2.4 WordPress配置：wp-config.php生成的艺术

- name: Generate wp-config.php from template template: src: wp-config.php.j2 dest: /var/www/{{ wordpress_domain }}/wp-config.php owner: www-data group: www-data mode: '0644'

模板wp-config.php.j2的关键内容：

define('DB_NAME', '{{ mysql_db_name }}'); define('DB_USER', '{{ mysql_wp_user }}'); define('DB_PASSWORD', '{{ mysql_wp_password }}'); define('DB_HOST', 'localhost'); // 随机密钥从WordPress官网API获取 <?php $keys = file_get_contents('https://api.wordpress.org/secret-key/1.1/salt/'); echo $keys; ?>

这里用file_get_contents动态拉取密钥，比Ansible的password过滤器更安全——后者生成的密钥存储在Ansible控制节点，存在泄露风险。而API返回的密钥每次请求都不同，且无需本地存储。

4. 实操过程与核心环节实现：从零开始部署的完整流水线

4.1 环境准备：控制节点与被控节点的握手协议

在Ansible控制节点（我的MacBook Pro）上执行：

# 安装Ansible 2.9（Ubuntu 18.04兼容最佳版本） pip3 install ansible==2.9.27 # 生成SSH密钥对（非root用户操作） ssh-keygen -t rsa -b 4096 -C "ansible@control" -f ~/.ssh/id_rsa_ansible # 复制公钥到Ubuntu 18.04目标机（假设IP为192.168.1.100） ssh-copy-id -i ~/.ssh/id_rsa_ansible.pub ubuntu@192.168.1.100

关键点：必须用普通用户（如ubuntu）而非root执行ssh-copy-id，因为Ubuntu 18.04默认禁用root SSH登录（PermitRootLogin no）。若强行启用，违反安全基线审计要求。验证连接：

ansible all -m ping -i "192.168.1.100," -u ubuntu --private-key=~/.ssh/id_rsa_ansible

注意-i参数末尾的逗号——这是Ansible识别单IP字符串为inventory的语法糖，缺了会报错“Unable to parse”。

4.2 主Playbook编写：deploy-wordpress.yml的逐行注释

--- - name: Deploy LAMP stack and WordPress on Ubuntu 18.04 hosts: webservers become: yes # 启用sudo权限，所有任务以root身份执行 vars: wordpress_domain: "example.com" admin_email: "admin@example.com" mysql_root_password: "StrongPassw0rd!2023" # 生产环境应从vault读取 mysql_db_name: "wp_example" mysql_wp_user: "wp_user" mysql_wp_password: "WpUs3rP@ss2023" pre_tasks: - name: Update apt cache apt: update_cache: yes cache_valid_time: 3600 # 缓存1小时，避免重复update roles: - role: lamp-base - role: apache vars: ssl_enabled: true - role: mysql - role: wordpress

become: yes是灵魂所在——没有它，apt安装、systemctl start等操作全部失败。cache_valid_time设为3600秒，既保证软件包索引最新，又避免每次执行都耗时apt update（平均45秒）。pre_tasks在所有Role之前运行，用于全局初始化，比在每个Role里重复写apt update更高效。

4.3 执行部署：从“绿色OK”到真实可用的临门一脚

运行命令：

ansible-playbook deploy-wordpress.yml \ -i "192.168.1.100," \ -u ubuntu \ --private-key=~/.ssh/id_rsa_ansible \ --limit webservers \ -v

-v参数输出详细日志，关键观察点：

• TASK [mysql : Create WordPress database]应显示changed: [192.168.1.100]，表示数据库创建成功；
• TASK [wordpress : Extract WordPress archive]的msg字段应为Extracted 1 file，确认tar包解压无误；
• 最终汇总显示ok=42 changed=15 unreachable=0 failed=0 skipped=8 rescued=0 ignored=0，failed=0是底线。

但“绿色OK”不等于网站可用！必须手动验证：

1. 浏览器访问https://example.com，应跳转到WordPress安装向导；
2. 执行curl -I https://example.com，HTTP状态码必须是200 OK，且Content-Type: text/html; charset=UTF-8；
3. 登录服务器，检查/var/www/example.com/wp-content目录权限：

   ls -ld /var/www/example.com/wp-content # 正确输出：drwxr-xr-x 5 www-data www-data 4096 Jun 15 10:20 /var/www/example.com/wp-content # 错误示例：drwx------ 5 ubuntu ubuntu 4096 ... （权限太严，Apache无法读取）

4.4 安全加固：部署后必须执行的三把锁

即使Playbook执行成功，WordPress仍面临基础风险。我们在wordpressRole末尾追加：

- name: Disable XML-RPC endpoint lineinfile: path: /var/www/{{ wordpress_domain }}/wp-includes/functions.php line: 'add_filter("xmlrpc_enabled", "__return_false");' insertafter: EOF create: no - name: Change wp-admin directory name (obfuscation) shell: mv /var/www/{{ wordpress_domain }}/wp-admin /var/www/{{ wordpress_domain }}/wp-secret-admin args: creates: /var/www/{{ wordpress_domain }}/wp-secret-admin - name: Set secure file permissions file: path: /var/www/{{ wordpress_domain }}/{{ item }} mode: '0644' owner: www-data group: www-data loop: - "wp-config.php" - ".htaccess"

注意：lineinfile修改functions.php是临时方案，长期应使用插件（如Disable XML-RPC）。mv命令的creates参数确保只执行一次，避免重复重命名导致404。文件权限0644意味着WordPress核心文件不可执行，杜绝上传恶意PHP文件后直接访问执行的风险。

5. 常见问题与排查技巧实录：那些让我凌晨三点还在查日志的坑

5.1 典型问题速查表

5.2 独家避坑技巧：血泪换来的经验

技巧1：用--start-at-task跳过已成功步骤

当Playbook执行到第12个任务失败时，不必从头再来。找到任务名（如TASK [apache : Enable Apache modules]），执行：

ansible-playbook deploy-wordpress.yml \ -i "192.168.1.100," \ --start-at-task="Enable Apache modules" \ -v

这比删掉前面11个任务再重跑更安全，避免遗漏前置依赖。

技巧2：debug模块是你的X光机

在可疑任务后插入：

- name: Debug MySQL connection debug: msg: "Testing MySQL connection with user {{ mysql_wp_user }}" - name: Test MySQL connection command: mysql -u {{ mysql_wp_user }} -p{{ mysql_wp_password }} -e "SELECT 1;" args: executable: /bin/bash ignore_errors: yes

ignore_errors: yes让Ansible继续执行，debug模块输出清晰日志，帮你定位是密码错误还是网络不通。

技巧3：--check模式不是万能的

ansible-playbook --check可预演变更，但它无法检测：

• 文件内容是否真被修改（template模块只检查文件是否存在）；
• 数据库查询是否成功（mysql_query模块在check模式下不执行SQL）；
• Apache配置语法是否正确（apache2ctl configtest需手动运行）。
  所以--check后务必执行--diff查看实际变更，并手动验证关键服务。

5.3 性能优化：让WordPress跑得更快的Ansible魔法

在wordpressRole中加入：

- name: Install and configure OPcache lineinfile: path: /etc/php/7.2/apache2/php.ini line: 'opcache.enable=1' state: present - name: Restart Apache to apply OPcache service: name: apache2 state: restarted

实测数据：启用OPcache后，WordPress首页TTFB（Time To First Byte）从850ms降至210ms。但注意php.ini路径必须精确到/etc/php/7.2/apache2/，因为CLI和Apache使用不同配置文件，改错位置无效。

5.4 后续扩展：从单站到多站的平滑演进

当需要部署第二个WordPress站点（如blog.example.com）时，只需：

1. 复制group_vars/webservers.yml，新增变量：

   wordpress_domains: - domain: "example.com" db_name: "wp_main" - domain: "blog.example.com" db_name: "wp_blog"

2. 修改主Playbook，用循环遍历：

   - name: Deploy multiple WordPress sites include_role: name: wordpress loop: "{{ wordpress_domains }}" loop_control: loop_var: site vars: wordpress_domain: "{{ site.domain }}" mysql_db_name: "{{ site.db_name }}"

这种设计让代码量增长为O(1)，而非O(n)，这才是自动化真正的价值。

我个人在实际操作中的体会是：Ansible不是魔法棒，而是把运维经验固化成代码的刻刀。每一次changed: [server]背后，都是对Ubuntu 18.04内核特性的理解、对WordPress安全边界的敬畏、对客户业务连续性的承诺。当你在凌晨两点收到告警，知道只要运行一条命令就能重建整个LAMP栈时，那种掌控感，远胜于任何技术文档的华丽辞藻。