Deploying a NodeJS Application on GCP with App Engine & CloudBuild (Part 1)

Initializing App Engine and Setting Up Cloud Build Triggers

This three-part tutorial will walk you through all the steps you need to deploy your NodeJS application to Google App Engine, replete with build triggers from Github and environment variables as the sprinkles on top. This is the first installment of the series — the second part is found here, and the third part is found here.

Before we begin, make sure that you have the following:

• A Google Cloud Platform Account
• A NodeJS application backend
• A Javascript-based application frontend (such as React, Angular, etc.) — before moving forward, make sure that all backend calls are formatted as “/api/…” (ex: “localhost:3000/api/users/” should just be “/api/users”)

If your application uses server-side rendering, you can still follow this tutorial, but you’ll need to adjust for only having one repository (which will likely be easier).

So let’s get started!

Creating a New Application

First, inside a new project (if you need to make a project, use this awesome video tutorial for help), head to the App Engine tab using the sidebar, and you should see the following screen.

Click on the “Create Application”, and you’ll be presented with a region selector. At RiceApps, due to our location in Houston, TX, it typically makes the most sense for us to select us-central . However, if a client is located outside of Houston, we will set the region to the datacenter nearest to their location.

The next screen will ask about the environment, but we will change this later so just continue with the default for now. After this, you should see the following page:

This is your App Engine “Dashboard”. There isn’t much we can do with it right now, though, since it has none of our code on it yet. Thus, let’s move onto the next part of our journey: setting up a Cloud Build trigger.

Setting Up Google Cloud Build

First, let’s head on over to Google Cloud Build using the sidebar. Click on the sidebar, scroll down a little ways and you should see the following tab. Hover over it to display a list of options, and click on the first one, “Dashboard”.

We don’t currently have Cloud Build enabled, so let’s click “Enable”.

Now that Cloud Build is active, we should see the following screen representing our Cloud Build “Dashboard”.

On the lefthand side, you’ll see four tabs — click on the third one, “Triggers”, before continuing to the next section.

Connect Repos

Before we setup our triggers, we must tell Cloud Build where we want to pull our code from. That is, we need to connect Cloud Build to our Github repositories (this also works with BitBucket and other popular source repositories).

On the “Triggers” page shown below, click on the button towards the top of the page that says “Connect Repository”.

You should be greeted by the following page. Next, we’ll select Github as our source, although as previously mentioned this should work with other source repository locations supported by Google Cloud Build as well.

Once you click “Continue”, you must authorize GCP to access your Github account. After that, you’ll see the following screen which will allow you to connect any repositories you’d like to this GCP project. In our case, we’ll be selecting the front and backend repositories for our Carpool app, listed in the RiceApps Github repository as carpool-angular and carpool-expressjs (frontend and backend, respectively).

After clicking the checkbox at the bottom and “Connect (#) respositories”, it will provide you with an optional screen where you can create a “default trigger”. But we will setup our own more advanced trigger in the next section, so just click “Skip for now” and move on.

We return back to the “Triggers” page and see that it has changed! Unfortunately, both our repositories have been set to “Inactive” as they don’t have any triggers associated with them. Let’s change that.

Click on the “Create a Trigger” button at the top, right next to the “Connect Repository” button, and you’re now ready for the next section.

Create a Trigger

First, we’ll be setting up the trigger for our frontend, and then we’ll repeat the process for our backend (as the steps are just about the same).

You’ll see a page like this where we can fill in the details to a new trigger.

Fill in the “Name” and “Description” fields as you wish, and then set the “Event” selection to “Push to a branch” — this way, the trigger will only run when a push is made to a certain branch. In the future, this will allow you to create multiple triggers corresponding to multiple branches, where each trigger can deploy to a separate environment. This means we can easily have the deployment of develop, staging, and production environments easily separated through triggers! I’m getting ahead of myself, but in a future article we will go further into this idea.

In the “Source” section, select the repository for the frontend, which in our case is carpool-angular . Then select the branch that you want the trigger to correspond to. This branch should exist on Github, or else the trigger will never fire. We’ve created a branch gcp-deploy for our purposes, but this branch could be called anything — production , develop , abracadabra — it’s up to you. If you’re advanced, you could implement a regex expression which matches several branches — for example, if you wanted to connect your trigger to any branch that had the word gcp in it, you could write a regex expression for that. We won’t get into that here, but it speaks to the capabilities of GCP.

Scroll down, and you’ll see one last section of the page called “Build Configuration”.

In this section, we must specify that we will be using a “Cloud Build configuration file” (which we’ll be creating shortly in this article). Ensure the file location subsection remains the same (should be “/cloudbuild.yaml”) and then inside the “Substitution Variables” subsection, use the “+ Add Variable” button to add the following:

• _GAE_VERSION — this will specify the “version” of the application we want this trigger to overwrite; in this case, we’ll be writing to the production version (again, the value could be anything — “develop”, “medium”, etc.)
• _GAE_TRAFFIC — in the future, we can use this to conduct A/B testing where we direct some users to one version of the site and other users to another version. In this case, we just want everyone to see the “production” version.

We’ll be using these inside of our cloudbuild.yaml file that we create later.

Now, click “Create” and your trigger will be ready and running.

Next, we need to setup a separate trigger for our backend repository, so we click on the “Create Trigger” button at the top and go through the same steps as before for the first set of options, only this time we replace the repository with carpool-expressjs . If you have a separate branch that you’d like to track, you can also change that.

After scrolling, inside the “Build Configuration” section we’ll again set our file type to “Cloud Build configuration file” and add the _GAE_VERSION and _GAE_TRAFFIC variables to our “Substitution Variables” subsection. We’ll also add _MY_ENV_VAR, just so that we can see later how easy it is to add our own environment variables into the mix. Set the value to anything you’d like!

After clicking “Create”, we can see on the resulting page how both of our repositories are now “Active” and our triggers are enabled.

In other words, we’re locked and loaded. The next step is to setup the mysterious configuration files we hinted at.

We’ll do this in the next part, located here. See you in the next part of the series!