The serverless gambit: Building ChessMsgs.com on Cloud Run

Interesting read how Greg Wilson built ChessMsgs.com, a website that can track chess games played by sending links to eachother.

Instead of tweeting moves back and forth, players tweet links back and forth, and those links go to a site that renders the current chessboard, allows a new move, and creates a new link to paste back to the opponent. I wanted this to be 100% serverless, meaning that it will scale to zero and have zero maintenance requirements.

The board’s state is represented as a string using the Forsyth–Edwards Notation (FEN)

rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1

That same FEN is also fed to service that generate static images of the board for use in the meta tags.

The serverless gambit: Building ChessMsgs.com on Cloud Run →
ChessMsgs Source (GitHub) →

What’s new / coming to Google Cloud Run?

At Google Cloud Next ’20, Cloud Run Product Manager Steren Giannini (@steren) walked us through some of the new things that are coming to Google Cloud Run.

Some highlights:

  • VPC Peering
  • Gradual Rollouts (with custom URLs per tagged release)
  • New Load-Balancing Features (Multi Region, Cloud CDN, IAP)
  • Easy Continuous Deployment
  • Min instances (no cold starts)
  • 4 cpus/4 GB RAM
  • 1 hour request timeouts
  • Graceful shutdowns (SIGTERM)
  • Server-Side Streaming

🧐 Unfamiliar with Google Cloud Run? Watch the video of a talk I recently gave on the subject.

Going Serverless with Google Cloud Run (JSConf.be)

Back in June I was invited to speak at JSConf.be. This year’s edition focused on DevSecOps and Security. My talk “Going Serverless with Google Cloud Run” — which I have brought forward before at Full Stack Ghent and PHP-WVL — was a perfect match for it.

Cloud Run is a fully managed compute platform by Google that automatically scales stateless containers. By abstracting away all infrastructure management, us developers can focus on what matters most: building great applications.

In this talk I’ll show you not only how to deploy PHP/Node applications onto Cloud Run, but also how to create a build pipeline using either Google Cloud Build or Github Actions.

In mid August the video got released, which I’ve embedded below:

The slides are up on slidr.io, and also embedded below:

Thanks to the organisers for having me, and thanks to the attendees for coming to see me. I hope you all had fun attending this talk. I know I had making it (and whilst bringing it forward) 🙂

💁‍♂️ If you are a conference or meetup organiser, don’t hesitate to contact me to come speak at your event.

Cloud Run Button: Deploy Docker Images from Public Repositories to Google Cloud Run with a Single Click

If you have a public repository with a Dockerfile you can have users automatically deploy the container to Google Cloud Run by adding a Cloud Run Button. It’s no more than an image that links to https://deploy.cloud.run, like so:

[![Run on Google Cloud](https://deploy.cloud.run/button.svg)](https://deploy.cloud.run)

Add that code to your README.md and when a visitor follows that link, Cloud Shell will open and it will Clone, Build, and Deploy the project onto Cloud Run for them. No need to manually create things in the Google Cloud Console nor use the gcloud binary 🙂

You basically only need the button, but you can tweak the source repository parameters through the querystring:

  • When no parameters are passed, the referer is used to detect the git repo and branch
  • To specify a git repo, add a git_repo=URL query parameter
  • To specify a git branch, add a revision=BRANCH_NAME query parameter.
  • To run the build in a subdirectory of the repo, add a dir=SUBDIR query parameter.

There’s also an app.json that you can optionally add to the root of your repo to tweak the deployment parameters.

{
    "name": "foo-app",
    "env": {
        "BACKGROUND_COLOR": {
            "description": "specify a css color",
            "value": "#fefefe",
            "required": false
        },
        "TITLE": {
            "description": "title for your site"
        },
        "APP_SECRET": {
            "generator": "secret"
        }
    },
    "options": {
        "allow-unauthenticated": false
    },
    "hooks": {
        "precreate": {
            "commands": [
                "echo 'test'"
            ]
        },
        "postcreate": {
            "commands": [
                "./setup.sh"
            ]
        }
    }
}

The values defined in the env key will be translated to prompts for Cloud Shell to ask. The props of each prompt is pretty straightforward but the special case of "generator": "secret" will ask/generate a secret.

By default it will deploy with allow-unauthenticated set to true but through the options you can override that.

The hooks part finally allows you to run commands in separate bash shells with the environment variables configured for the application and environment variables for GOOGLE_CLOUD_PROJECT, GOOGLE_CLOUD_REGION, and K_SERVICE.

~

Did this help you out? Like what you see?
Thank me with a coffee.

I don't do this for profit but a small one-time donation would surely put a smile on my face. Thanks!

☕️ Buy me a Coffee (€3)

To stay in the loop you can follow @bramus or follow @bramusblog on Twitter.

Google Cloud Build + Google Cloud Run: Fixing “ERROR: (gcloud.run.deploy) PERMISSION_DENIED: The caller does not have permission

Google Cloud Build is cool. Google Cloud Run is awesome. But when configuring Google Cloud Build to automatically deploy your built container to Google Cloud Run you might see this error:

ERROR: (gcloud.run.deploy) PERMISSION_DENIED: The caller does not have permission

If you’re seeing this error you forgot to set up the required IAM Permissions for the Cloud Build Service Account. Below I’ll show you the commands to fix this error.

~

As detailed in the Cloud Run documentation, a user needs the following permissions to deploy new Cloud Run services or revisions:

  1. run.services.create and run.services.update on the project level. Typically assigned through the roles/run.admin role.
  2. iam.serviceAccounts.actAs for the Cloud Run runtime service account. By default, this is PROJECT_NUMBER-compute@developer.gserviceaccount.com. The permission is typically assigned through the roles/iam.serviceAccountUser role.

By default – for security reasons – the Cloud Build Service Account does not have the permissions to manage Cloud Run, explaining why you’re getting errors.

~

You can set up these required permissions using the Google Cloud Console, yet I prefer to do this from the CLI using the Google Cloud SDK (gcloud), by invoking the commands below:

# Config
GC_PROJECT=your-gcp-project-id
GC_PROJECT_NUMBER=your-gcp-project-number

# Grant the Cloud Run Admin role to the Cloud Build service account
gcloud projects add-iam-policy-binding $GC_PROJECT \
  --member "serviceAccount:$GC_PROJECT_NUMBER@cloudbuild.gserviceaccount.com" \
  --role roles/run.admin

# Grant the IAM Service Account User role to the Cloud Build service account on the Cloud Run runtime service account
gcloud iam service-accounts add-iam-policy-binding \
  $GC_PROJECT_NUMBER-compute@developer.gserviceaccount.com \
  --member="serviceAccount:$GC_PROJECT_NUMBER@cloudbuild.gserviceaccount.com" \
  --role="roles/iam.serviceAccountUser"

💡 To know the values for GC_PROJECT(_ID) and GC_PROJECT_NUMBER, run gcloud projects list or go to the Home of your project inside Cloud Console.

After running these two commands, re-trigger a build and Google Cloud Build will be able to deploy your built container onto Google Cloud Run.

~

Did this help you out? Like what you see?
Thank me with a coffee.

I don't do this for profit but a small one-time donation would surely put a smile on my face. Thanks!

☕️ Buy me a Coffee (€4)

To stay in the loop you can follow @bramus or follow @bramusblog on Twitter.

Cloud Run vs App Engine: What’s the difference?

Simple and to the point article, with a few commands included, by Dirk Hoekstra:

In a nutshell, you give Google’s Cloud Run a Docker container containing a webserver. Google will run this container and create an HTTP endpoint.

With Google’s App Engine however you tell Google how your app should be run. The App Engine will create and run a container from these instructions.

Have been using Cloud Run for a few projects recently and I really like it I must say! It just works™ without me having to think about it all too much, whilst also allowing me to finetune the environment.

Cloud Run vs App Engine →

💵 This linked article is stuck behind Medium’s metered paywall, which may prevent you from reading it. Open the link in an incognito window to bypass Medium’s ridiculous reading limit.

Running the same Node.js code on Google Cloud Functions, App Engine, and Cloud Run

Google Cloud has a number of options to run your code. We can deploy a function to Cloud Functions, an app to App Engine, or an app with a custom runtime (a Docker container) to Cloud Run.

In this post the same code snippet is deployed to all three Google Cloud Platform features. Locally the Functions Framework is used .

Portable code migrating across Google Cloud’s serverless platforms →