How can you maintain WordPress at scale on RunCloud?
The RunCloud platform opens the doors for developers, designers, freelancers and all manner of web businesses to leverage the benefits of using Cloud hosting, without requiring the in-depth skills of a highly experienced sysadmin.
If you run a WordPress or Web Development business, The benefits of using RunCloud allow you to offer your clients access to high quality cloud hosting that you can manage for them as part of a complete service.
RunCloud makes it easy to:
- Connect many servers from any Cloud hosting provider
- Deploy and manage many Web Applications and Databases
- Secure your website with compliant SSL certificates
- Use the latest web server stack technologies
- Secure your servers and applications with an advanced firewall
And much more.
Growing your WordPress business – WordPress at scale
Now that the power of the cloud has been unlocked and made available, you have a greater potential to grow your business.
In the world of WordPress development, this may mean growing your client business to include the management of many dozens of WordPress sites (or more) belonging to a multitude of different clients across multiples of servers in different datacenters.
Let’s look at an example of growing to not an unreasonable scale. Let us say you have developed and help manage 30 WordPress sites for different clients. With ongoing staging sites and their environments that need maintaining. Already we are looking at managing up to 60 sites in total.
A Time Consuming Process
When WordPress core updates, you need to manage this process.
If we take a rough estimate of 5 minutes for managing updates across staging and live, it suggests that the business in our example could be spending more than a few hours per month on this task. And as the business grows, this burden only increases!
The process of streamlining this process provides an opportunity for a major cost savings. We can achive this through services or through tools and automation.
(And remember, this isn’t even considering plugin updates.)
There are several GUI based platform solutions to this problem, but today we are going to learn how to use the amazing WP-CLI Aliases feature to efficiently manage this process. Saving your business time (and therefore money) that you can invest more wisely into expanding your client base.
Commands executed in this tutorial will be issued by a superuser using the sudo command for root privileges. If you don’t have a superuser, we have an easy to follow tutorial here.
This tutorial also assumes you have already installed WP-CLI on your RunCloud managed servers, if you haven’t then not to worry, we have another easy to follow tutorial here to do that.
Managing Multiple WordPress sites from within the Same Server
For this tutorial, to begin I will just use two websites on the same server. This will keep things simple, but the basic process can be scaled up to many dozens of sites or more.
Here you can see my two site an-example-domain.com and another-example-domain.com in my RunCloud Dashboard:
Example Sites to Manage in the RunCloud Dashboard
And here you can see them live in all their glory:
An Example WordPress Site
Another Example WordPress site
Issuing WP-CLI commands on a server without Aliases.
Initially, after I have installed WP-CLI on my server, if I want to issue a command to either of these WordPress sites I must do it from within that sites WordPress directory:
1 – Login to my server.
$ ssh superuser@server_ip_address
2 – Navigate to the specific WordPress application root folder (from my user folder).
$ cd webapps/an-example-domain/
3 – Execute a WP-CLI command, say update core.
$ wp core update
Not exactly speedy right?
Each command needs to be executed from within the root folder of the WordPress installation, and then I would need to change directory to the other WordPress site root directory and execute commands there.
This is hardly achieving the great efficiencies we require in order to manage many multiples of WordPress sites.
Configure WP-CLI Aliases on your RunCloud Servers
You may remember, in a previous tutorial introducing WP-CLI we created a WP-CLI configuration file config.yml on our RunCloud server.
If you didn’t complete that tutorial, then this is how to do it. First create the hidden .wp-cli directory, navigate into the directory, then create and open the configuration file for editing:
$ mkdir ~/.wp-cli && cd ~/.wp-cli $ nano config.yml
Within our configuration file we are going to add our WP-CLI Aliases.
A WP-CLI Alias contains the Alias name used to issue the command preceded by an @ symbol, followed by the full path to that WordPress applications root folder on the server.
We can also create WP-CLI Alias Groups, using the same naming format, followed by the individual Aliases to include in the group.
In my case that is the following:
# Aliases @example: path: /home/superuser/webapps/an-example-domain/ @another: path: /home/superuser/webapps/another-example-domain/ # Alias Groups @all-examples - @example - @another
WP-CLI Configuration File on a Remote Server
Save and close the configuration file. Now if we issue the wp – -info command we can see that the location of our config file is listed in the WP-CLI installation information next to WP-CLI Global Config:
WP-CLI Info showing our Configuration File Path
Issuing commands on a server using WP-CLI aliases
After everything has been configured we can use the aliases to issue commands on our WordPress sites from anywhere in the server.
For example, from my superuser’s home directory, I can check the status of the plugins on either of my sites with:
$ wp @example plugin list
List plugins on one site using an Alias
Or check the plugins on the other site with:
$ wp @another plugin list
List plugins on the other site using an Alias
That’s better, no more needing to be within the WordPress site root directory to work on it.
Now, remember that Group Alias we added to the config? Let’s put that to work next.
We can check the plugins of both sites at the same time using the Group Alias, like so:
$wp @all-examples plugin list
List plugins on all sites using a Group Alias
In this example, our server only has two WordPress sites, but imagine the efficiencies involved in using Group Aliases to issue commands across 20 or 30 sites, or more. Using a WP-CLI Group Alias we can issue single commands to manage any number of WordPress sites on a server.
But it gets better still…
Managing Multiple WordPress sites across Multiple Remote Servers
Lets scale up a bit and add another server, it’s just enough to illustrate the principles. Rest assured though, the methods outlined here will scale massively.
So I have added another server to the mix:
Two servers with WordPress sites on them
I need to make a note of the IP addresses for each server, these will be needed later.
On this new server I have added another WordPress web application, yet-another-example.com:
Yet Another WordPress Site in the Dashboard
Yet Another WordPress Site Front End
Now that we have several WordPress sites to manage across different servers we need to configure things a little differently.
We will manage them remotely from our local machine. This means we will issue WP-CLI commants locally, and it will connect to our servers and issue the commands by proxy.
Install WP-CLI on your Local Machine.
To manage remote WordPress sites using WP-CLI, we need to have it installed on our local machines as well as the remote servers.
Configure Aliases on your Local Machine
On your local machine create a local config.yml inside the hidden .wp-cli directory in your user directory.
As I am using MacOS the commands are the same as Linux. Windows users will need to adjust these commands to fit that OS:
mkdir ~/.wp-cli && cd ~/.wp-cli nano config.yml
Inside the WP-CLI configuration file you need to add Aliases with full SSH paths to each of your WordPress sites root directories on your various servers.
In my case that is something like the following:
# Aliases @example: ssh: superuser@remote-server-ip/home/superuser/webapps/an-example-domain/ @another: ssh: superuser@remote-server-ip/home/superuser/webapps/another-example-domain/ @yet-another: ssh: superuser@remote-server-ip/home/superuser/webapps/yet-another-example/ # Alias Groups @all-examples - @example - @another - @yet-another
Configure Aliases on your Local machine with SSH paths
Add RunCloud PHP into PATH
If we were to try to issue commands from our local machine to our remote servers now it still wouldn’t work. For example, if we tried to update the plugins we would receive an error:
$ wp @yet-another plugin list
No PHP Error
(If you didn’t receive this error, don’t worry it just means you have already made these configurations for some other reason previously)
One of the benefits of RunCloud is the granular configurability of the PHP stack afforded by the custom PHP configuration. But this means that to get WP-CLI remote aliases to work, we need to add the RunCloud PHP root into our PATH.
On each of your RunCloud managed servers, if you issue the wp –info command, you will be provided the path to your RunCloud PHP binary. Copy the path highlighted here:
$ wp --info
Copy the path to your PHP binary
Now we need to symlink this into our PATH so that the remote WP-CLI connection from our local machine can use it.
Do that like so:
$ sudo ln -s /RunCloud/Packages/php72rc/bin/php /usr/bin/php
Symlink the RunCloud PHP binary into the PATH
Issue WP-CLI commands locally to manage WordPress sites remotely
We can now use these Aliases and Group Aliases to control and manage WordPress sites on our remote servers by issuing commands locally.
Lets list all the plugins on one of our sites. From your local machine terminal execute the following command:
$ wp @yet-another plugin list
This time WP-CLI on your local machine should successfully log in to your remote server and issue the WP-CLI command on it, and return the output in your local terminal. All being well, the terminal on your local machine should look similar to this:
Now Local WP-CLI commands should execute remotely
Using Alias Groups Remotely
Now let’s use the WP-CLI Alias Group we created earlier to explore this potential further.
List the plugins from all the sites on all the different servers:
$ wp @all-examples plugin list
Use a Local Group Alias to list plugins on WordPress across different servers
WP-CLI lists the condition of all my different WordPress sites plugins.
From the terminal output, we can see that I have 5 inactive plugins across the 3 sites on the two different servers, and one of the sites has a plugin that needs updating.
I can update all the plugins on all the sites, and activate them all with the following single compound command:
$ wp @all-example plugin update --all && wp @all-example plugin activate --all
WP-CLI now connects with all the remote WordPress applications and issues my remote commands, updating and activating all plugins on all servers.
Update and Activate Plugins across all the sites
From this I am sure you understand how, using WP-CLI Aliases and Alias Groups, we can manage WordPress updates and maintenance at scale, across no matter how many servers we have provisioned, in a much more efficient manner.
I have illustrated this principle using just 2 servers with 3 WordPress sites between them. But with the availability of affordable cloud servers, this could just as easily have been across 10 servers with 200 sites.
With appropriately configured WP-CLI aliases and carefully constructed strings of WP-CLI commands we can automate the most repetitive and mundane WordPress management tasks. In turn this will lead to efficiency savings and increased productivity that will help us as we grow our Web Development Businesses, perhaps to agency scale and beyond.