For those looking for a way to deploy their app, the Google Cloud Platform (GCP) may not be the first choice that comes to mind. Heroku is simple and easy to use while Amazon’s AWS is by far the most popular platform in the industry. Nevertheless, GCP offers some unique tools that are worth exploring (and is offering a $300 trial credit in addition to its free tier).
It is in the best interest of software companies to offer a low barrier to entry for their products; the easier it is for someone to get started, the faster a user can explore what lies beyond the gate. Offering clear and easy-to-read documentation would go a long way to lowering these barriers. Google has provided excellent documentation for several of their APIs — however, the cloud department can be a bit lacking in clarity.
Deploying my first Node.js app on GCP presented significant frustrations. Part of it is my fault: I chose to play around with a lot of tools that aren’t completely developed. When they’re fully working, they will be awesome additions to the ecosystem. For now, one has to be aware of potential pitfalls, some of which I’ll cover below.
What drew me to GCP was the potential for a combination of Heroku’s ease of deployment (straight from Github with no CLI needed, even though one is provided) with AWS’s firepower. (Oh also, I used the Google Prediction API, which requires the Google Cloud SDK.)
GCP makes it possible to run a Cloud Shell CLI interface, edit files, and deploy an app with App Engine entirely in the browser — features that make it easier for someone to explore GCP without too much investment and our topic of exploration.
Go ahead, log into the GCP console, and create a new project!
On the right hand of the navigation bar that spans the page, you’ll find an icon to launch the Cloud Shell. This will provide you with a Cloud Engine virtual machine that runs Linux and is equipped with plenty of normal goodies (git, npm, and support for Node.js) and some that we’d otherwise have to install locally (Google App Engine SDK, Google Cloud SDK). A complete list of provided tools can be found here. On first appearance, the shell will appear on the bottom of your screen but there’s an option to pop it out into its own window.
Keep in mind that this VM is unique to your Google account, not your project. If you download a repo for one project and re-visit Cloud Shell for another project, you’ll see your old repos. This Compute Engine instance is also distinct and separate from the App Engine instance that will host your deployed app.
Preparing for Deployment
Go ahead and clone your repo into the VM. This is your chance to make sure you have everything before deploying! If you’ve forgotten anything below, feel free to launch Google’s experimental online file editor from the cloud shell toolbar (personally, I’m not a huge fan of VIM and the like).
What you’ll need:
- An app.yaml file. At the bare minimum, it should resemble the sample below. This lets App Engine know what configuration you desire. Using the flex environment allows App Engine to have control over several aspects of your deployment, such as automatic scaling. If you have any process.env variables, this is where they should be specified. For a full list of what this file can contain, read on here.
2. Make sure that your package.json contains a “start” script. After your VM sets up your App Engine instance (e.g. installing any node modules you may need), it will run the this script. Don’t forget to start your server with something like node server.js.
3. (optional) If you choose to launch your server on port 8080 (or 8081–8084) in development, you can get a quick preview from the Cloud Shell. Run the start script and click the first icon in the toolbar to open the preview in a new window.
A word of caution here: the preview is unable to connect to any database, hosted on GCP or elsewhere. Since all my content was behind a login screen, it didn’t particularly help that the preview kept throwing an error whenever I tried to sign in or create a new account. If there are no errors locally, it should (hopefully) work in deployment.
4. If you choose to make any changes with the file editor, I recommend following this step. Go to the hamburger menu inside the GCP console, scroll down to the Tools subsection, hover over Development, and click Repositories.
The list of repositories will initially be empty and the option for Source Code will only be available once the app has been deployed. Eventually, the Source Code tab will show the code that is currently being deployed on App Engine.
For now, let’s create a new repository and title it “default”. This will be repo from which the app will be deployed. Since it’s empty, we can push our finalized code from the Cloud Shell VM after we’ve added our default repo as a remote.
Now we’re ready to deploy our app! Go ahead and run the magic command inside the repo folder: gcloud app deploy. You’ll be guided through a series of prompts. First, a location:
The build log begins to take shape:
If all goes well, this message will be displayed after a few minutes:
You can visit your app by running gcloud app browse or going to https://[PROJECT-ID].appspot.com (if you haven’t changed it).