Elixir application deployment on Google Cloud Run with Google Cloud Build

This article was originally published here.

In my previous article (here) i have shown how to properly build an Elixir application using Distillery; now i’d like to show how to deploy it on Google Cloud Run, using Google Cloud Build.

What is Google Cloud Run ?

Google Cloud Run is a managed infrastructure that you can use to deploy your container and have it served as one (or more) serverless functions without the usual limitations. If you want to use Amazon Lambda functions or Google Cloud Functions must adopt one of the allowed runtime environments (most common ones are python, javascript, java, and few others), and so you implicitly must embrace all the characteristics of the chosen language.
Cloud Run instead tells you: "give me your container, do in it what you need, i'll deploy and serve it for you". This is an interesting chance to have the flexibility of lamba architectures without limits. Also, billing is per invocations, with also a pretty generous free tier.

And what about Google Cloud Build ?

Cloud Build executes your builds importing source code from sources like Google Cloud Storage, Cloud Source Repositories, GitHub, or Bitbucket, inject ingconfiguration bits and producing artifacts (so, docker images to deploy). It comes, at the moment, with 120 minutes/day of free build time. It can be orchestrated via a Dockerfile or a cloudbuild.yaml .

The deployment procedure

We assume that you have created a google cloud project (the id of the one i have created will be cloud-run-example-01); so be sure you have enable cloud run api, cloud build api and project billing (these steps are all explained in the official guides i have linked above).

The code for my previous article is here, and contains a Dockerfile which builds the super easy application we used for the article, which will be perfect for our problem here.

At this point, all will be driven by the cloudbuild.yaml file present in the repository. Its structure is the following:

Gist

The part of interest is the env: section, where we have to mention the variables that we want to inject into the container, which is basically the very reason for which i have created this article

Also, we need to use the --set-env-vars flag to properly pass the variables to the run command (basically like we do when we use -e flag for docker run command).

A very important thing is that, in order to execute, build and deploy the artifact, you must grant 3 roles to the service account user, which is normally named as PROJECT_ID@cloudbuild.gserviceaccount.com:

• Cloud Build Service Account (should be granted by default)
• Service Account User
• Cloud Run Admin

With this given, you are all set to add a proper cloud build trigger, in the web console (the address should be something like this: https://console.cloud.google.com/cloud-build/triggers?project=YOUR-PROJECT-ID). By clicking “Add Trigger” you will be asked to:

• choose the repository (Cloud Source Repository, BitBucker or Github)
• select the repository from a list
• configure the trigger

Take into account that the master value we type in the Branch field means that the trigger will be run when a push to the master branch will happen (we can block explicit pushes to master branch and only accept pull requests merge — after code reviews, of course  — and this will be already a good setup for this).

When you click “save”, you’ll be taken to the page with the list of the triggers, where you’ll just find the only one that you have create.

Click “Run trigger” and the build will start.

Once the build is ready, you can run curl <function url>/api/keys with the following result:

{
    "keys": {
        "payment_key": "my custom key"
    }
}

which is exactly the value we have injected in the trigger.