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: domain name verification (after domain name purchase) Google Installing Google Cloud SDK Building a barebones server (using NodeJS) Deploying NodeJS server to Google Cloud (App Engine) Linking purchased domain with your NodeJS server Quick word about Google Cloud versioning deployment Creating and deploying applications on sub-domains Google hosting costs and suggestions Whenever I think about intuitive hosting and well written, up-to-date documentation, is not at the top of the list… hence this tutorial. gcloud 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 … I’ve chosen for my domains. DNS management GoDaddy These days you can purchase a domain for as little as 9€ / year; from this point forward, let’s assume we own You’ll also need a Google Cloud account, feel free to create one . example.com. 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 section subsection. Click the and you should reach a page similar to this: Google Cloud / App Engine / Settings Custom Domains Add a custom domain gcloud: adding custom domains Pick the option, type in your domain name and hit . You’ll end up on Webmaster Central which is Google’s automated domain name verification tool: Verify a new domain Verify You should select your domain name provider (in my case GoDaddy.com) and click ; Google will try to automatically add a TXT record in your domain name provider DNS records. Verify 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 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: Other 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, . 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 button once every 2–3 minutes until it says the verification was successful. fail Verify 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 CNAME record in your DNS Manager like this (needed in order to access your domain with www.example.com): www Go ahead and install the , we’re going to need it later. Once that’s done, run in a terminal to setup the default configuration. Google Cloud SDK gcloud init We’ll need an application which we can deploy to the App Engine; a super basic NodeJS seems appropriate. Here’s our server: Hello World server.js A file with a script is also needed; something along these lines: package.json start {"name": "hello","version": "0.0.1","scripts": {"start": "node server.js"},"engines": {"node": "8.x","npm": "4.x"},"license": "ISC"} Finally we need an file which handles the App Engine setup. Again we’ll go for the most basic one: app.yaml flex nodejs default**skip_files:**- ^(.*/)?.*/(node_modules|anotherFolderHere)/.*$ 1 1 env: runtime: service: automatic_scaling:min_num_instances: max_num_instances: Make sure you read the Google Cloud 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 service. I also added an example on how to skip multiple folders which should not be deployed. documentation on app.yaml default The service part is crucial as you must deploy a service before anything else. Picture services as standalone applications or as microservices that are part of a larger application. default 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 and your backend as the . service: default 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: , and . Open a terminal in this project folder and run: server.js package.json app.yaml gcloud app deploy After a few minutes your deploy will be available at a URL similar to this: Congratulations, your live! https://project-000000.appspot. Next step is to link it with your purchased domain. To achieve this, start by creating a file and add the following lines: dispatch.yaml 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 page you’ll see something like this: App Engine > Services 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 section or by running the command . 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. App Engine > Versions gcloud app versions list 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 redirect, but it can also be achieved through a NodeJS middleware (express was used in this example): 301 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 by selecting the domain we want to use ( ) then specifying the sub-domain we want to create ( ). App Engine > Settings > Custom Domain > Add Custom Domain example.com 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 - "example.com/*" default - "awesome.example.com/*" awesome dispatch: url: service: url: service: Then we have do deploy this once again by running: . dispatch.yaml gcloud app deploy dispatch.yaml Small note here; if you skip this step, all of your sub-domains will point to the . To avoid costs you might want to do that, and manage the sub-domain mapping logic within your main application. ExpressJS has the npm package which could help you with that. default service express-subdomain 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, . Google’s App Engine can get pretty expensive even for our boilerplate which does nothing. Here’s a which can give you an overview of how much you could end up paying for your hosting as well as the App Engine . it will cost you price calculator 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 . Guillermo and his team are doing a great job over there. Zeit Happy coding!