Trials and tribulations of Google Cloud hosting — a tutorial

If you ever wanted know all of the steps that go into deploying a live site, from buying a domain, to hosting it, to running multiple sub-domains then you’re in the right place. We’ll cover the following:

1. Google domain name verification (after domain name purchase)
2. Installing Google Cloud SDK
3. Building a barebones server (using NodeJS)
4. Deploying NodeJS server to Google Cloud (App Engine)
5. Linking purchased domain with your NodeJS server
6. Quick word about Google Cloud deployment versioning
7. Creating and deploying applications on sub-domains
8. Google hosting costs and suggestions

Whenever I think about intuitive hosting and well written, up-to-date documentation, gcloud is not at the top of the list… hence this tutorial.

To get things started, you’ll need to purchase / be the owner of a domain. Feel free to pick whichever domain registrar you want, as long as it allows DNS management… I’ve chosen GoDaddy for my domains.

These days you can purchase a domain for as little as 9€ / year; from this point forward, let’s assume we own example.com. You’ll also need a Google Cloud account, feel free to create one here.

Create a new Google Cloud project from the Dashboard. We’ll need it later as our deployments need to be within the context of a project:

Once created, the project will be automatically selected. The next step is to go through Google’s domain verification process. This is needed to prove our domain name ownership.

Go to your Google Cloud / App Engine / Settings section Custom Domains subsection. Click the Add a custom domain and you should reach a page similar to this:

gcloud: adding custom domains

Pick the Verify a new domain option, type in your domain name and hit Verify. You’ll end up on Webmaster Central which is Google’s automated domain name verification tool:

You should select your domain name provider (in my case GoDaddy.com) and click Verify; Google will try to automatically add a TXT record in your domain name provider DNS records.

Don’t worry if your domain provider doesn’t appear here, it just means Google won’t be able to automatically create the required DNS record.

If that’s the case, simply select Other from the domain name provider dropdown and you’ll be given a TXT record which you need to copy over to your domain name DNS Manager like shown bellow:

Log into your domain name provider and select the option which allows you to manage the DNS records for your domain, then add the TXT record provided by Google (shown above). Your DNS Manager should look similar to this:

After this step is done the Google domain name verification will fail. Yes, fail. This is something you’ll get used to, as changes in DNS take a while to propagate. It can take anywhere from a few minutes to 24 hours (maybe more). In my case it took around 8 minutes. Keep clicking the Verify button once every 2–3 minutes until it says the verification was successful.

If you’ve gotten this far, then congratulations! Google now recognizes you as your domains owner. If it’s not automatically added, you should also add a www CNAME record in your DNS Manager like this (needed in order to access your domain with www.example.com):

Go ahead and install the Google Cloud SDK, we’re going to need it later. Once that’s done, run gcloud init in a terminal to setup the default configuration.

We’ll need an application which we can deploy to the App Engine; a super basic NodeJS Hello World seems appropriate. Here’s our server:

server.js

A package.json file with a start script is also needed; something along these lines:

{"name": "hello","version": "0.0.1","scripts": {"start": "node server.js"},"engines": {"node": "8.x","npm": "4.x"},"license": "ISC"}

Finally we need an app.yaml file which handles the App Engine setup. Again we’ll go for the most basic one:

env: flexruntime: nodejsservice: default**skip_files:**- ^(.*/)?.*/(node_modules|anotherFolderHere)/.*$automatic_scaling:min_num_instances: 1max_num_instances: 1

Make sure you read the Google Cloud documentation on app.yaml files. Ours basically instructs App Engine to keep the automatic scaling to 1 instance, have a NodeJS runtime with a flexible environment and it targets this service (our application) as the default service. I also added an example on how to skip multiple folders which should not be deployed.

The service part is crucial as you must deploy a default service before anything else. Picture services as standalone applications or as microservices that are part of a larger application.

To better visualize this, imagine you have 2 applications: The first is your frontend and the second is your backend API. In this scenario you could deploy your frontend application as the service: default and your backend as the service: api.

Keep in mind that the more services you have, the more you’ll pay. Having multiple services is probably best suited for large applications. You can actually create a single service and point all of your domains and sub-domains to it. We’ll cover sub-domains later.

There’s our basic application, it only has 3 files: server.js , package.json and app.yaml. Open a terminal in this project folder and run: gcloud app deploy

After a few minutes your deploy will be available at a URL similar to this: https://project-000000.appspot. Congratulations, your live!

Next step is to link it with your purchased domain. To achieve this, start by creating a dispatch.yaml file and add the following lines:

dispatch:

• 
  

  url: "example.com/*"service: default

Pretty straight forward, you specify the domain you’ve linked to your project and the service it points to. Now we need to upload it to Google cloud and that’s done by running this command: gcloud app deploy dispatch.yaml

Once this is done, if you visit your App Engine > Services page you’ll see something like this:

linking dispatch routes

Every time you deploy the default service, another version will be created and all traffic will be ported to it. You can see all deployed versions in your App Engine > Versions section or by running the command gcloud app versions list. You can also choose to split traffic between two or more deployed versions in case you want more control on how many users hit a specific version of your app.

Now, you’re truly live and you SSL certificates are automatically regenerated by Google (by default) but there’s more that could be done; for instance, restricting your traffic to HTTPS only. You’d normally do this in Apache or Nginx through a 301 redirect, but it can also be achieved through a NodeJS middleware (express was used in this example):

express HTTPS redirect middleware

Assuming you’d also want to run a sub-domain, it’s just as simple. First, we add the sub-domain in our App Engine > Settings > Custom Domain > Add Custom Domain by selecting the domain we want to use (example.com) then specifying the sub-domain we want to create (awesome.example.com).

We’re then instructed by Google to create a CNAME for our sub-domain in our domain registrar DNS Manager… it’s the same thing we had to do for www:

The last thing we need to do is point our newly created sub-domain to a service. Which we already know how to do… enter dispatch.yaml:

dispatch: - url: "example.com/*"service: default - url: "awesome.example.com/*"service: awesome

Then we have do deploy this dispatch.yaml once again by running: gcloud app deploy dispatch.yaml.

Small note here; if you skip this step, all of your sub-domains will point to the default service. To avoid costs you might want to do that, and manage the sub-domain mapping logic within your main application. ExpressJS has the express-subdomain npm package which could help you with that.

That’s quite a lot of information but it should get you up and running pretty fast… only one problem remains… how much does this all cost?

There’s no denying it… if you want flexibility, it will cost you. Google’s App Engine can get pretty expensive even for our boilerplate which does nothing. Here’s a price calculator which can give you an overview of how much you could end up paying for your hosting as well as the App Engine pricing list.

You can however reduce the cost significantly by lowering the maximum number of allowed instances to 1 and sticking to a single service (the default one).

In the 10 days I’ve been running my domain the total hosting costs have been around ~$13 for one service on one domain. Not really what you want to see while prototyping your application. Currently however Google is offering a 1 year free trial + $300 spending credit so you can get a feel of how it works and how much you’ll pay.

If you’re looking to further improve costs there’s always Google’s Compute Engine, which can be configured to go as low as $6~8 / month… but don’t expect you’ll be running a full blown application with hard core traffic on it. Probably the best choice for small businesses, personal websites and portfolios.

A small “Gotcha!” I should mention is that you can’t delete the default service once it’s created. You can only stop the versions running within it. Even if you stop all versions and delete them, one will still remain, the one with 100% traffic allocation on it. If you really want to get out… delete the entire project.

If however you still want scalability, versioning, easy and fast deploys, while maintaining humanly decent costs, I would recommend Zeit. Guillermo and his team are doing a great job over there.

Happy coding!