Blair's Book Blog

Deploying WordPress on Google Cloud

Twenty years late to the blogging party, I deployed a blog using a virtual machine on Google Cloud. This article captures the steps I followed, next steps I intend to figure out, and what I’d do different if I did this again.

Registering a domain

Google Domains offers domain registration in a fairly simple process. I opted for a .com for ease of typing and recognition, and because a domain ending in something like .blog costs $30/year, wheras a .com costs $12/yr.

During registration, Google offers an option to register and pay for a Google Workspace. This can be a great for new businesses to access Google tools such as Gmail, Google Docs, Google Drive, and so forth. If you’re used to using Google tools for collaboration, this is a quick way to take advantage of those tools with your own domain name.

Google Workspace offers several different plans. As I don’t intend to replace my personal email with that for my domain name and I don’t want to expose my personal email on the blog, I chose a Business Starter plan. That’s $6/month per user, with 30GB of storage. I expect that will be more than plenty for now.

Deploying WordPress

Google Cloud offers a click-to-deploy option for installing WordPress on a Cloud virtual machine. This option does several things:

I found this is deceptively easy. I had a running WordPress install within 15 minutes, but I was left without knowing what exactly was installed, how it was configured, and for software that was installed outside of Debian’s package manager, where that software resided.

I read the support statement in the marketplace before I installed the software:


Google does not offer support for this solution. However, community support is available on Stack Overflow (the link goes to all items tagged with “WordPress”). Additional support is available on community forums (which is a link to WordPress’ documentation, not community forums).

But I didn’t click the links, trusting that they would be helpful (they weren’t). At this point having a pointer on how to configure the installed software, remove optional software installed outside of apt-get, and next steps would be helpful.

Everything after this point is me working without any script, with a bit of an idea of what I wanted, and a lot of things out of order (I could have done without the domain through Google Domains, too, and used Cloud Domains, I suppose).

Obtaining an SSL certificate

I thought I could get an SSL certificate through Cloud Console, but that was because I’d confused a couple of other Cloud products that you can get SSL certs for (Cloud Load Balancing) through Google Cloud.

Since I’m not doing anything so fancy, I used Electronic Frontier Foundation’s EFF Certbot to obtain a signed SSL certificate. You essentially download and run Certbot, and it does the work of obtaining an SSL certificate, installing it, and verifying it.

Certbot needs an exposed HTTP port to complete the installation, though, so that it can test the installation. Changing a virtual machine’s firewall rules in Cloud Console is quite easy.

My only gripe was that I’d expected I could install Certbot via Debian’s package manager, but I discovered that it is installed via a snap package. I have some feelings about Canonical’s use of snap packages, and more so with those packages on a Debian system, that I’m not quite ready to poke at.

Gripes aside, Certbot is pleasantly easy to use. If you need an SSL certificate (and you’re rolling your own little server somewhere), I highly recommend it. When you’re done, consider a donation to EFF.

Updating MySQL and WordPress passwords

Cloud’s Deployment page listed the default passwords set during the initial install. These passwords are for the WordPress and root MySQL accounts, and for the WordPress admin account.

To change the WordPress and root MySQL accounts, I did the following:

  1. Connected to the virtual machine via SSH.
  2. Ran the following commands, replacing USERNAME with root or wordpress, and PASSWORD with new a password:
    1. sudo mysql -u root
    2. set password for 'USERNAME'@'localhost' = password('PASSWORD');

It’s quite possible that I could have logged into MySQL without sudo (this does seem rather redundant), but I’ve recorded what I used.

Changing the WordPress admin password was a matter of changing it on the Profile page, http://ADDRESS/wp-admin/profile.php.

Disabling access to phpMyAdmin

As I understand it, phpMyAdmin is a web interface for administrating MySQL. I’m happy enough to run an ssh session to my virtual machine and running queries via the command line. I’m also not comfortable exposing my database like this, so I wanted to remove it.

For this installation, /var/www/html/myphpadmin is a symlink to /opt/c2d/downloads/phpmyadmin/. This particular Click-to-Deploy feature avoids using a Debian package. In the interest of avoiding damage to the installation, I first tried disabling the root MySQL user’s access to myPhpAdmin:

  1. Connect to the virtual machine via SSH.
  2. $ cd /var/www/html/myphpadmin
  3. $ sudo vim config.inc.php
  4. Added the line $cfg ['servers'][$i]['AllowRoot'] = FALSE; to the configuration file.

Seeing no damage to the WordPress install, I later removed remote access to phpMyAdmin. I figured I could do this and use an ssh tunnel later if I discovered I actually need it. The following are the steps I followed:

Connected to the virtual machine via SSH.

  1. cd /etc/apache2
  2. sudo vim apache2.conf

  3. Added the following lines below existing Directory lines:

    <Directory /var/www/html/myphpadmin>
         Order Allow, Deny
         Allow from localhost
</Directory>
  4. sudo systemctl restart apache2

I expect that medium-term, I can delete these four lines from /etc/apache2/apache2.conf and delete the symlink to /opt/c2d/downloads/phpmyadmin/. Long-term, I’d move to deleting everything under /opt/c2d/downloads/phpmyadmin/.

Hardening WordPress

WordPress has a guide to hardening a WordPress installation, or suggestions and avenues that are available to help make a WordPress install less tempting for an attack. I’m not a security expert, but I did follow a few tips.

First, I did the following to harden the wp-includes/ directory:

  1. cd /var/www/html
  2. sudo vim .htaccess
  3. Copied the code displayed at Securing wp-includes into the file.cd.

Then I did the following to move wp-config.php out of the web root directory:

  1. cd /var/www/html
  2. sudo mv wp-config.php ..

Next steps

Next steps that I intend to figure out at some point include:

Final thoughts

If I did this again, I’d follow a different order after the install completed:

  1. Change default passwords.
  2. Block phpMyAdmin from remote access.
  3. Disable root login phpMyAdmin.
  4. Apply hardening to the WordPress install.
  5. Install certbot.
  6. Turn on HTTP(S) at the firewall.
  7. Run certbot to obtain and install SSL certificates.
read more