Migrating a Joomla Website From Dreamhost to Google Cloud Platform
This website has been an on-and-off project for a while. I started the site when I was finishing graduate school in order to post some of my writing and code samples, and in order to get more familiar with Joomla. I spent a few months here and there tweaking the site, changing themes, fine-tuning the one I finally selected, adding content, and so on. For the first few months, I didn’t have any trouble with the site. Everything at Dreamhost worked fine, and I was just on a $10/mo shared hosting plan that let me host several websites, so it was a really good deal. The few sites I hosted there didn’t get much traffic or have any special needs, so the setup worked fine.
Then, a few months back, I got in let’s-make-changes mode and made a series of changes to my Dreamhost sites. I swapped domains around, borrowed some blog data from one site for another site, reconfigured databases, etc. I was focused on getting my personal website up and running so I could post fiction and non-work related material. The systemscienceguy.com site was moved to a different domain, and then down for a little while while I was kind of unsatisfied with it and decided to work on some other things.
Fast-forward to last week, when I decided to get the systems science website up and running again. For a while I had considered moving the site to GCP, but it had been working fine, and Dreamhost was cheap (you get what you pay for!) and it was going to be a bit of work to migrate, so I put it off. Then, last week, when I sat down to get the site up and running again, the parade of headaches began immediately. I won’t go into all the sordid details, but suffice it to say that the site, and Dreamhost, were just not cooperating.
I tried to reattach the domain to the existing files, but got an error I couldn’t easily fix. That wasn’t too surprising, since the site had been down for a while. I decided to do a clean Joomla install and restore from a backup. The first time, I got the dreaded redirect to installation/index.php that wouldn’t go away after installing. So I reinstalled AGAIN, and this time it worked fine. A couple of different times, I had to get someone from Dreamhost support to fix things that I couldn’t do through the control panel. But after a couple of days of work, everything was back up and looking good. Problem solved. Right?
Then, last night, after not touching the site since it was working, I went to the site to make a blog post, and got the least helpful error I’ve ever seen. Every single page on the site was blank except for the single word ‘Error.’ Thanks for the helpful information. I looked at the logs and saw various Joomla errors, which again I could not easily track down. I thought to do the reinstall against, but then stopped myself and asked, “Why I am doing this? This is way too hard.” Once a site is up and running, it shouldn’t be subject to mysterious configuration changes on the server side that you can’t control. Dreamhost has mostly been good to me, but this isn’t the first time that a site has just suddenly stopped working for me on Dreamhost when I didn’t touch anything.
Dreamhost offers account backups, but there was not an automatic one in the time window that I needed. And I stupidly did not take a manual backup (though, in my defense, that was largely because it’s pretty clunky to do in Dreamhost). I knew that, in GCP, I could easily make backups using machine images or snapshots, and that those could be reastored easily without having to copy files around. Sounds great, right? Dreamhost offers cloud services, but if I’m going to go full cloud, I’ll move the site to one of the major providers, thank you. So I took a deep breath and decided that this was the kick in the pants that I needed to finally migrate this site over to Google Cloud. I knew it would be at least a few hours of work, but it was long overdue. And what’s a few hours
FIRST STEPS: GCP PROJECT SETUP AND VM IMAGE SELECTION
One of the many things to like about the major cloud providers is that their marketplaces offer lots of pre-built images for major software packages in different formats. Let’s take a look at what google offers for Joomla:
So many options! This can be a blessing and curse with the cloud providers. Searching for ‘Joomla’ gives ten different prepackages images that we can use for deployment. I chose the one just titled ‘Joomla!’, because I knew it would give me something closest to what I had on Dreamhost. Some of the other images are for containerized apps, which is overkill for this application. I just wanted a normal webserver running my app in the standard way, without containers. And I just wanted to set up a single Compute Engine instance to serve the site.
Virtual compute machines were state of the art in around 2005 when Amazon first launched AWS. Now there are more updated deployment methods, like the serverless App Engine, which have some advantages and disadvantages. For my purposes, a regular old VM running on Compute Engine was perfectly fine for the job, and in some way it’s easier to set up, since I can just start from a machine image. One thing I have learned in tech is that sometimes the simplest and most reliable option is the best. Sometimes people get caught up in the groupthink of whatever latest and greatest trend is hot at the moment; but for a lot of purposes good old virtual machines work great, so I’m sticking with that.
Once I selected a Joomla VM image in the marketplace deployment is simple, just click ‘deploy’ from the marketplace page and the deployment manager takes care of the initial setup. Here’s a shot of the manager after the deployment is up and running:
You can see that the deployment manager very helpfully shows us all the relevant information in one place: project resources, addresses and passwords, what software the machine is running, and suggested next configuration steps. The cloud consoles gives so much information that it can be overwhelming at times, but once you learn your way around a bit, it’s astonishing how much you can get done with just a few clicks and keystrokes. And this sort of deployment isn’t for everyone. This Joomla website is about a 1.5 on the 10-point scale of cloud deployment complexity, but for some users it might be worth just sticking with a traditional dedicated website hosting company that provides one-click installs and doesn’t offer any of the other heavy machinery, at least with a basic hosting plan.
So after a rapid deployment of the Joomla VM image, we have everything set up and ready for the next steps. The VM image includes all the installation files for Joomla so that the user can install and configure it in the way that they need to. But the next thing, before running the Joomla installation, is to make sure that the database is configured and ready for the Joomla setup. I knew this would be a part of the procedure that was different from what I was used to at my old hosting provider. For one thing, Dreamhost installed databases to separate addresses from the server itself, and required that the user use an address like ‘mysql.mydomain.com’ to access the MySQL server.
On GCP, there are more options for how to deploye the database, and this point deserves a bit of discussion. One option would be to set up a separate Cloud SQL instance for the MySQL database, which would give me more options and be preferable if this was a more complex app deployment that needed to use microservices or was going to have multiple database instances. More details can be found in the official documentation:
But there are a number of reasons, in this case, to just use the MySQL installation that’s included with the Joomla VM image, which includes the full LAMP stack. The first reason is just ease of setup - the marketplace VM image I selected for deployment contains the full LAMP (Linux Apache MySQL PHP) stack, so setting up a Cloud SQL instance would take another step or two and be duplicative. Of course, then I would have a decoupled architecture with more flexibility, but that would again be overkill for this purpose.
Cost is one place where traditional web hosting and cloud can differ quite a bit, and a key decision factor in thinking about how to deploy your site. With Dreamhost, I have a shared hosting plan for $10/month that lets me run multiple websites, with SSH and FTP access, ability to configure databases, and other admin capabilities. I was honestly pretty impressed with what you get for $10/mo with Dreamhost. At that price, it was costing me about $2/month to run this website. I knew that GCP would be more expensive, and I tried to get an estimate of what the cost would be before migrating.
When I selected the Joomla machine image from the marketplace, the given cost estimate was $27/month, using a small virtual machine (I believe 2cpu and 4gb ram - complete pricing details here). As you can see, there are a TON of options, and a huge range of prices. For my website, I just needed a single small machine for now, so at first I selected a g1-small, which is one of the smallest available VMs. This proved not to be quite enough horsepower, as Joomla was hanging when I tried to update articles. After switching to a e2-small VM, the site now performs beautifully, and I’m still within my $30/month cost estimate.
PERFORMANCE AND FEATURES
The service may be more expensive, but you get what you pay for. The first obvious benefit is speed. Even with just a small VM (2cpu, 4gb), the site is noticeably faster than at Dreamhost. I’m sure I could have gotten better performance by upgrading my Dreamhost to dedicated hosting, but then I would have been paying the same and not had the same level of control and features as I do with GCP.
One thing I do miss about Dreamhost is the support. Even with a basic hosting plan, chat support was available 24⁄7, and the support people were always super helpful. With GCP, you only get billing support with the free plan, so if you need additional support, you’ll have to pay for it. For serious deployments, this is certainly worth it, but if you’re just deploying a small site, then paying for support is going to be out of budget. Just one of many things to consider when deciding how to host your site.
GETTING SSH KEYS FOR MY INSTANCE
By default, you can access your compute instances using cloud shell. Cloud shell is convenient (it runs in your browser) but kind of buggy - it just flat out doesn’t work in the current version of Firefox, apparently. The better way is to set up SSH through whatever terminal application you normally use.
gcloud provides a built-in SSH function, so you can do
gcloud compute ssh my-instance and ssh through
gcloud (which is convenient, for one, because you don’t have to know IP or other addresses).
SETTING UP SSL ON THE SITE
Dreamhost made it easy, through the control panel, to set up a free SSL certificate on your site to get the all-important lock icon and made people feel secure in using your site. But some issues with SSL certs is one reason I decided to migrate to GCP. But at first, it was NOT obvious how to set up a basic SSL certificate on Google Cloud. The support person sent me to a page which described setting up an SSL certificate for a load balancer, which is way overkill for my site (though perhaps useful in the future). I knew there had to be some easy, few-commands way to get a free cert up and running, but I just could not find out how in the Google docs. Eventually I found this extremely helpful and concise guide:
That guide will walk you through installing the certbot from Let’s Encrypt and getting your certificate up and running in literally a minute or two. In retrospect, I feel silly, since I spent hours and hours trying to figure out something that, in the end, just took two minutes. But lesson learned!
This is where the benefits of cloud become obvious. At some point in trying to set the certificate up, I hosed my Apache configuration, and could not easily restore the backup. This is where snapshots come in super handy! Since I had taken a snapshot once I got the site up and running at first, it was just a matter of a few clicks to restore my machine to the baseline configuration.
Finally, I learned a bit about the details of SSL certificates. When I initially set the cert up, I only specified systemscienceguy.com, and not www.systemscienceguy.com (not sure if this was my oversight, I thought I gave both to the certbot). So after getting the certificate working partially, I had to add www.systemscienceguy.com to the existing certificate. That easy procedure is described here:
All told, it was about a day’s worth of work to move the site over. Knowing what I know now, I could do it in an hour or two. GCP is extremely powerful, and might be overkill for a basic website deployment. But if you’re looking to step up your game and have more control over your site and its configuration, then cloud is the way to go!