Rebuilding a static website into WordPress on AWS Lightsail
In this post I bring you the story of a client who’s chosen to rebuild the company static website into WordPress, out of a custom frontend application developed using Node.js, Nunjucks, bootstrap and some other things, exposed via Nginx in Google Cloud into a kubernetes cluster (let’s call it “k8s”), along with the backend services also hosted in there.
The motivation for investing on rebuilding the site was both due to the need of easily managing the static pages, at the time handled only by devs familiar with the tech stack, and also the high costs for scaling, due to the nature of the architecture solution, as illustrated and explained below.
The context is this e-commerce startup which decided to dive into the Black Friday frenzy for the first time, its website was brand new and an appealing promo has been announced on the media, although, the site started not responding to the volume of requests on the week towards day X.
Our immediate response was scaling up the kubernetes cluster nodes, also updating deployments to the use of more memory and cpu, scaling up the pods as a consequence, and that solved the accessing issue, cloud rules!
Still, the solution taken wasn’t meant to be definitive, since there are most effective ways for dealing with static sites deployment in prod..
So once the firedrill was over, we’ve dedicated sometime for handling the separation of the static site from the Node.js part, which was based on building all together during CI, but separating them during CD, hosting the static site under a Nginx image with caching enabled on a pod, and the other part unchanged in the pre-existing pod, all on same namespace in k8s, and access based on paths in the Nginx ingress.
Let’s revisit this flow very briefly: 1) new commits in the github website repository on a specific branch trigger the pipeline in GCP; 2) the build starts in Cloud Build and the docker images are built with helm creating the charts; 3) with the previous step succeeding, the deployment of the services into the namespace starts, and if nothing goes wrong, the pods are created replacing the previous ones (rolling update), so the apps are up-to-date.
However, the client was still unsatisfied since anything he asked, from the replacement of a promo banner to a minor page text, had to be handled by devs, hence this idea of investing to rebuild the site using some Content Management System (CMS) came to life.
The most sensitive part of the custom e-commerce was actually the one interacting with the backend, therefore, building the static pages under similar layout with a CMS solution wasn’t complex at all, and WordPress has been elected with an agency hired for preparing the site package.
With the WordPress site about to get ready for deployment, integrated with the dynamic site still exposed via Nginx in the k8s cluster in GCP, it was time for sharing the estimates with the client, thus we followed creating an instance in Amazon Lightsail, given there was a customer account in AWS already, and this solution has presented itself as the cheapest, but also appropriate for future maintainability with minimum effort.
Just like described in the official page, Lightsail facilitates the work of deploying instances providing a useful list of pre-built images, including databases, and once a given instance is ready and also its db, it’s a matter of linking them both— more details described here.
Once the WordPress instance is set in Lightsail, we can access the public IP created and follow the instructions provided on the homepage to log in for the first time using default credentials, and handle the site package import via the administrative console using a variety of plugins.
Finally, the tricky part was linking the website in Lightsail with the dynamic site in GCP, what had to be done creating a subdomain for the dynamic site to be accessed by the Wordpress site and vice-versa, setting it up in Nginx ingress and exposing them all via AWS Route53, as shown below.
As a result, moving the static site to Wordpress helped in non-tech folks to start playing around with it, almost or totally without dev intervention, due to its friendly interface and available documentation, along with the ease of maintenance enabling caching and security settings right from the admin console, not counting that changes in the dynamic site are handled in separate and even faster, cool right?
Do you have any similar stories to tell? Please let us know in the comments!
