Resource Orchestration Service:Deploy a WordPress environment with phpMyAdmin

What are WordPress and phpMyAdmin?

• WordPress: An open source blog and content management system (CMS) platform developed with PHP and MySQL. More than 40% of websites worldwide are built with WordPress.

• phpMyAdmin: A PHP-based web tool for managing MySQL databases. It lets you manage MySQL databases through a browser interface, for example, viewing table schemas, running SQL statements, and importing or exporting data.

List of resource types to be created

Results after deployment

After the template runs successfully, you get:

• A complete VPC network environment (VPC + vSwitch)

• An ECS instance on which WordPress and phpMyAdmin are installed, with a public IP address for direct access

• An ApsaraDB RDS for MySQL instance, with the WordPress database and account created

• An SLB instance that serves as the public access point for WordPress

• A scaling group that automatically adds or removes WordPress ECS nodes based on load

• A NAT Gateway that provides public network access for the ECS instances newly created in the scaling group

• The WordPress access URL and the phpMyAdmin management address in the stack Outputs

User access
                          ↓
                          Classic Load Balancer (CLB) ←──  Internet (yum repositories, etc.) ←── NAT Gateway
                     ↙     ↓     ↘
               ECS-1    ECS-2    ECS-N    ← Automatically managed by the scaling group
               (WordPress + phpMyAdmin)
                     ↘     ↓     ↙
                    ApsaraDB RDS for MySQL (shared database)

Why is elastic scaling required?

A single ECS instance that hosts WordPress works well when traffic is low. However, a traffic spike, such as when a popular article is shared, can cause the website to respond slowly or even become unavailable. The scaling group does the following:

1. Monitors the CPU utilization or network traffic of the existing ECS instances

2. When the load exceeds a threshold, automatically creates ECS instances based on the scaling configuration template

3. Automatically registers new ECS instances as SLB backend servers so that they start sharing traffic

4. When the load decreases, automatically releases excess ECS instances to reduce costs

Why use ApsaraDB RDS instead of local MySQL on ECS?

• Data persistence: ECS instances are created and released during scaling, so data in a local MySQL database is lost. An ApsaraDB RDS instance exists independently and stores the data persistently.

• Multi-node sharing: Multiple WordPress ECS nodes read and write the same data and therefore require a centralized database.

• Professional operations and maintenance (O&M): ApsaraDB RDS provides enterprise-grade database features such as automatic backup, primary/secondary replication, monitoring, and alerting.

Why is a NAT Gateway required?

For security reasons, the ECS nodes newly created in the scaling group have no public IP address, but they need Internet access to:

• Install WordPress and dependency packages from yum or apt repositories

• Download WordPress plug-ins and themes

  A NAT Gateway uses an SNAT rule to let all nodes in the VPC share one EIP for outbound access, so you do not need to assign a public IP address to each ECS instance.

How SLB works with a scaling group

Parameter settings

Deployment methods

# Prompt
Create a WordPress cluster that provides high availability (HA) and elastic scaling.
Requirements:
1. Create a VPC and a VSwitch as the basic network.
2. Create an ApsaraDB RDS for MySQL 5.7 instance as the WordPress database. Set the database name to wordpress.
3. Create an ECS instance and install WordPress and phpMyAdmin on it.
4. Create an SLB instance as the website access point.
5. Create an ESS scaling group and use the same configuration template as the initial ECS instance.
6. Create a NAT Gateway and an SNAT rule to provide public network access for the ECS instances in the scaling group.
7. Open port 80 (HTTP) and port 22 (Secure Shell) in the security group.
8. Include the WordPress access URL in the stack Outputs.

Post-deployment operations

Q1: The deployment fails and returns "The specified InstanceType is not available"

Cause: The selected ECS or ApsaraDB RDS instance type is out of stock in the specified zone.

Solutions:

• Select another zone and deploy the stack again.

• Check the instance type available in the target zone on the Elastic Compute Service (ECS) Pricing page.

• Do the same for ApsaraDB RDS: check the instance type available in the target zone on the ApsaraDB RDS Pricing Details page.

Q2: The WordPress page loads slowly or times out

Troubleshooting steps:

1. Check the SLB status: Confirm that the SLB health check is normal (SLB console > Instances > Backend Servers). If the health check of an ECS instance fails, SLB does not forward traffic to that ECS instance.

2. Check the ApsaraDB RDS connection: Log on to the ECS instance and run mysql -h<RDS internal endpoint> -u<username> -p to test database connectivity.

3. Check ECS resources: Run top or free -m to check whether CPU and memory usage is saturated. If it is, the cluster needs to scale out.

Q3: The scaling group does not scale out automatically

Causes and troubleshooting:

1. Go to the Auto Scaling console, and confirm that the scaling group is in the Enabled state.

2. Check whether a scaling rule and an alert task, such as an alert triggered based on CPU utilization, are configured.

3. This public template creates a scaling group and a scaling configuration, but you need to manually add a scaling rule:

   • Go to the Auto Scaling console, find the target scaling group, click the Scaling Rules and Event-triggered Tasks tab.

   • Add rules: add 1 instance when CPU > 70%, and remove 1 instance when CPU < 30%.

     For more information, see Configure scaling rules.