The step of the challenge requires that the URL pointing to my resume should use HTTPS for security. I should do this via Cloud Load Balancer, and ensure that the site uses Cloud CDN for caching purposes. There are a few terms to unpack there, so let’s take them one at a time:
HTTPS – This is the secure version of the Hypertext Transfer Protocol (HTTP) used to send data between websites and browsers. With regular HTTP, packets of data are sent in an unencrypted, plain text format, leaving them human readable and open to various types of attack. HTTPS prevents this by encrypting traffic, following the validation of website’s SSL certificate, which proves that the website is who it says it is (more on this later.)
Load Balancer – This a technology designed to maximise the availability of online systems by sharing out the traffic amongst a number of different backend resources. As I’m hosting a static site from a single storage bucket I don’t actually need that functionality but I can use a load balancer to point a domain name to it, directing traffic from the load balancer to my storage bucket, and associating the load balancer with my SSL certificate in order to use HTTPS.
CDN – A content delivery network (CDN) increase page load times and save server resources by caching and serving content close to where users are located, rather than the request having to travel all the way to the content’s physical point of origin each time. With GCP, this is a simple matter of checking a box, so I’ll definitely be doing that!
With the above terms defined, my first step is to create my SSL certificate. There are a number of ways and other providers that will allow me to do this but I’ll keep it GCP and head over to the gcloud CLI tool, where I can do this in one step:
$ gcloud compute ssl-certificates create crc-resume-ssl \--project=MY-PROJECT-ID \--global \--domains=chrisjohnson.tech
Here, I’m asking to create a global SSL certificate called “crc-resume-ssl” in this particular project for the domain “chrisjohnson.tech”.
Next I’m going to reserve a static IP address to point to my load balancer. This is an optional step, as an ephemeral IP address will remain constant as long as my load balancer forwarding rule exists but it helps to have an single IP to point my domain name at, so I’ll do that here:
$ gcloud compute addresses create resume-ip \
--network-tier=PREMIUM \
--ip-version=IPV4 \
--global
I can then check which IP address was reserved using the following step, so that I can make a note of it for later:
$ gcloud compute addresses describe example-ip \
--format="get(address)" \
--global
So now I have my SSL certificate and my static IP, I can start to set up the load balancer itself. I’m going to hop over to the GCP console to do this, as I find that to be faster and more intuitive than the CLI in this case.
Navigating to to the Load Balancing area of the console, I select the “From Internet to my VMs or serverless services” option – as I’m creating a load balancer to service external rather than internal traffic – and the type of load balancer that I want to employ. There are a few considerations here but the “classic” option is fine for what I’m doing.
After adding a name for my load balancer and its frontend, I can select HTTPS as the transfer protocol, which should unhide the option to select the SSL certificate I created earlier. In the “IP address” dropdown, I can also now select my reserved static IP”:
At the bottom of this page, I can also select the “Enable HTTP to HTTPS redirect” option to send any requests attempting to use the HTTP protcol via HTTPS.
It’s possible to add multiple frontend access points to our load balancer here but I only need one, so I can move on 🙂
Moving to the backend configuration section, I now need to create the backend bucket to point my inbound traffic to. Clicking the empty field, I can then choose the option to create a backend bucket (rather than service.) In the resulting dialogue, I then just need to name it, and navigate to the Cloud Storage bucket where my content lives:
You also note that, in what is surely the simplest step in this entire challenge(!) we’ve also enabled Cloud CDN here with a single click.
The final step is to define host and path rules to determine, by top-level-domain and URL structure, which backend resource my traffic is sent to. For example, I could create a rule to send any URL with /accounts/ or /video/ in the path structure to the relevant dedicated service. By default, all traffic will simply be sent to whatever backend resource I specify so, here, I just need to select our already defined backend bucket from the “Backend 1” dropdown.
All I need to do now is click “CREATE”, and I’m done! I can now see my load balancer (as well as my HTTP -> HTTPS forwarding rule), and my newly created backend and frontend:
There’s still one final step though, and that’s to point the domain name associated with the SSL to my load balancer’s IP address. I’m going to do this with Cloud DNS…