WordPressing the Cloud – Part 2
Building/Upgrading a Bitnami LAMP stack with WordPress in the Google Cloud.
This is part 2 of “WordPressing” in the Google Cloud. In this part, I will discuss upgrading/building a new VM server in the Google cloud utilizing Bitnami’s LAMP stack and WordPress module, migrating the sites, and a new structural layout.
(I am providing links to the documentation from Bitnami, their community forums, and Google. These will show the procedure to follow. In some instances I am providing the procedure myself, where I found the answer in several different sources.)
Why should you use Bitnami packaged Applications?
I am an avid believer in the phrase, “There is no need to reinvent the wheel.” When it comes to servers, I use pre-configured packages for the base. I prefer to use Bitnami LAMP stack and then install WordPress as a module, also utilizing a Bitnami module.
It is a very secure package and their documentation is good. They also use the most recent stable versions of the different components and modules. Security on the Google cloud is also great, but Bitnami adds the extra level that lets me sleep at night.
What server configuration should I choose when launching the server in Google Cloud?
The server configuration I choose when launching the build is as follows:
- n1-standard-1 (1 vCPU, 3.75 GB memory)
- 20GB SSD persistent disk
I would recommend the 20GB for the fact that I use 5GB for the disc cache for mod_pagespeed.
Compared to my previous server which was a dedicated 4 core CPU with 16GB memory and 500GB hard drive.
The configuration in the cloud may not seem like much, but it is 3 times faster than my old dedicated and costs 80% less. My average bill with Google is around $30 a month.
How do I download, edit, and upload files to the LAMP server on Google Cloud?
Dealing with such a secure server can be a hassle at times. Working with the files is not as easy as firing up the FTP or SFTP, editing the code, and just uploading it back. The default permissions in this LAMP build will not allow it where the Bitnami user does not have write permissions.
You have a few options. One is changing the permissions on files, make the changes, then change the permissions back. I usually use Google’s command line utilities from my KDE Neon workstation and upload the files to one of my 3 storage buckets, and then move them via command line to where they need to go.
How do I setup or upgrade my Bitnami LAMP server and WordPress on Google Cloud?
You upgrade WordPress, themes, and plugins the same way you do on any server, by using the upgrade section of the WordPress admin panel. In this instance, I wanted to upgrade the server itself and not just WordPress.
Bitnami had released a new LAMP build I had been waiting patiently for. This build had a newer version of mod_pagespeed, which had some features I wanted. I was tempted to try the LEMP stack (Linux/Nginx/MySQL/PHP) but I am more familiar with the Apache stack. Also, personally I feel that a properly configured LAMP stack utilizing PHP-FPM can be just as fast.
If you are new to Bitnami and Google Cloud, take the time to look over this guide on getting started. It takes no time at all really to spin off the new LAMP server, about 8 minutes. It does take some time to set up the access and configure the new server. I wanted to make sure all the access points were pre-configured here and all the tools I would need were also.
After the build completed, the first thing I did was to assign the server a static external IP address. After doing that I pointed dev.proweb.agency to that server. That propagated quickly. After that I modified my local hosts file on my workstation with the URLs of the sites I was moving with the new server’s IP for testing purposes. I leave them commented out at first, then uncomment them when needed.
During my planning phase, a few weeks prior, I decided to change the structural layout. This is what I mean by that. In my current cloud VM, I have a LAMP stack with 2 WordPress modules installed. I had 3 other sites I wanted to bring over but did not want to install 3 more modules.
I decided to stay with the 2 WordPress modules and add one more that would be multisite. I would use the multisite for the demo sites for our Timber Boot theme for WordPress, allowing me to make variations easily, such as demo-store, demo-restaurant, etc. Each being a subdomain.
For the other 2 single WordPress modules, one would be the main site, the other a testing ground for clients.
The next change to the structure was to use one of the 3 buckets to serve the static resources. Rather than use a CDN, I was going to make my own, utilizing the static storage bucket that came with my Google cloud account.
The third change was to turn on mod_pagespeed and configure it properly to work with WordPress and HTTP/2. HTTP/2 had been out long enough that there were some great articles on configuring it properly with mod_pagespeed.
A note here about optimization and mod_pagespeed. I believe that one should use best practices at all times, and not rely solely on a module to do it for them. Nothing beats optimizing your images before uploading them, and minimizing your CSS and JS, writing clean code, minimizing plugins (write the code instead), and using Timber/Twig for templating.
HTTP/2 is a great tool because it eliminates the need for some optimizations. These include concatenating CSS and JS files, image spriting, and domain sharding. Some say that inlining CSS and JS is no longer necessary with HTTP/2, but I still do it on the home page and still notice a faster load time.
So after spinning off the new server, the process was:
- Assign the new server an external IP address.
- Set up SSH to the new server.
- Set up gcloud authentication to use gsutil cp to move files to the new server and the static storage bucket.
- Set up Filezilla for SFTP access to the new server
- Copied all the SSL certs and keys over to the new server.
- Used All in one WP Migration on my previous server to do a backup of the main site and the current project I was working on and moved those to the static bucket.
- Backup the template directory for the demo site and a WordPress export of the data (this is going to the multisite)
- Install the 2 single site WordPress modules first. Follow this guide for installing additional modules.
- Install the multisite WordPress. This is really the single module but you turn on multisite.
- Configure the server for virtual hosts and create a configuration file for each WordPress module.
- Uncommented the local host file modifications so my workstation was pointing to the new server for the sites I was moving.
- Restored the main site and the working project
- Configures Multisite to use subdomains
- Moved over the template backup for the demo site and imported the WordPress data from the XML exports.
- Set up the SSLs
Test everything using your local hosts file.
In the next part of this series, I will discuss enabling HTTP/2, configuring mod_pagespeed, and using the storage bucket as a CDN.