DEV Community: RUARO Thibault

Developer tools for Cloud Run

RUARO Thibault — Tue, 04 May 2021 18:19:36 +0000

Developer tools to enhance Cloud Run development

Cloud Run is the next generation of serverless solution offered by Google Cloud. It allows you to execute an OCI image (Docker image for instance) of your choice on Google Cloud servers.

For those who are more familiar with App Engine Standard environment, the main difference is that Cloud Run gives you the choice of the runtime environment for your application. Usually, App Engine provides a set of runtimes (Java, Node, Python...) that will execute your application. It frees the developer from the burden of packaging the application. However, it restricts the possibilities to use the latest version of a runtime environment (like Java 16 for instance).

Running OCI image gives you a lot of flexibility. But at what cost? You now need to provide such an image to package your application. A common way to do so, can be to create a Dockerfile that contains the instructions to containerize your application.

As a developer, we, sometimes, like having access to some metrics, data or resources computation used by our application. In this article, we will see how you can:

See the logs of your Cloud Run application
Debug on production your application with no impact on performance
Profile your applications to monitor CPU usages and other metrics

Cloud Logging - Check your application logs

Logs have always been an important aspect for an application whose lifetime is intended to be for couples of years. You need to keep in mind that one day, something will go wrong on your application. And when it does, you better be ready to investigate.

The first reflex everybody has when the application is down, either partially or totally, is to check the logs trying to find the root cause of the issue. That makes total sense, since it is easier to fix something when we know what to look for.

The 12 factor apps (a set of best practices when developing containerized application) states "[An application] should not attempt to write to or manage log files. Instead, each running process writes its event stream, unbuffered, to stdout". This means you should only focus on logging behaviours and data to the console. Leave log capture & aggregation to the Ops.

If you respect this principle, you can easily use Cloud Logging to monitor your Cloud Run services logs, aggregate them and define alerts, or custom metrics about your application.

In this screenshot, we see the output for the revisions cloudrun-developer-00005-xuh (a revision is an immutable running instance of your application). But we could filter for the Cloud Run service cloudrun-developer for instance, or all Cloud Run resources...

You do not have to access the server anymore, making a tail -1000f /my/log/file.log or any command you were used to. You have a great Web Interface, collecting and showing the logs of all your services. Therefore, it is easy to apply filters to see the output of a specific Cloud Run service, or filter by Correlation-ID to track a transaction across all your services.

If you wish to access the global documentation about Cloud Logging and Cloud Run, here is the link.

Cloud debugger

I know, I know... My code is perfect, and there is no such thing as a "Bug"... So why bother using a Debugger in the first place...

As great and magnificent you and your code can be, I am sorry to break it to you, but you (of course, not me 😝) will face undesired behaviors in your application. When it happens, you will be happy to be easily able to debug your application.

What if I told you there is a way. You can debug your application while it is running in production, with no impact on your user experience ? Sounds too good to be true, keep reading.

If you were familiar with App Engine, you might have already used the Cloud Debugger service of Google Cloud. Any AppEngine application can be linked to Cloud Debugger in order to debug your application while it is running. If you tried Cloud Run recently, maybe you realized this feature was not natively provided and you felt betrayed... But it is still possible to enable it.

Cloud Debugger lets you inspect the state of your application by providing:

The possibility to take snapshots of your code. If you run a Java application, you will see the stacktrace and the variables/parameters value.
The possibility to create logpoints in your code. This logpoint will send a log in Cloud Logging when the user hits the logpoint. Following a specification, you can log existing variables or statements to help you monitor your application directly in production.

Installing the Agent

Deploying an application on app engine includes in the container, an agent capable of interacting with Cloud Debugger. To enable the same service for Cloud Run, it is as easy as it sounds: you need to install the same agent in the OCI image you provide to Cloud Run.

Following this documentation, here is how you can install the agent:

# Create a directory for the Debugger. Add and unzip the agent in the directory.
RUN mkdir /opt/cdbg && \
    wget -qO- https://storage.googleapis.com/cloud-debugger/compute-java/debian-wheezy/cdbg_java_agent_gce.tar.gz | \
    tar xvz -C /opt/cdbg

Once installed, just add some variables to your java -jar command line:

CMD java \
   -Dcom.google.cdbg.breakpoints.enable_canary=true \
   -jar PATH_TO_JAR_FILE

Then, when running your Cloud Run service, you need to provide environment variables to complete the Debugger agent setup.

JAVA_TOOL_OPTIONS=-agentpath:/opt/cdbg/cdbg_java_agent.so

Using Source Repositories

To be able to create snapshots and logpoints, Cloud Debugger needs to have access to your source code. Cloud Debugger then displays your source code in the UI, and you just have to navigate to your code to create a snapshot or a logpoint.

A practice for such use cases would be to sync your github repository with Source repositories. Follow this link to do so.

Example of logpoints and snapshots

You can manage logpoints and snapshots through the Debugger service in Google Cloud. Once the Cloud Run service is deployed with the Debugger Agent, and Source Repositories sync with your code, you can simply use the Debugger service. If you want a step by step procedure, you can follow this link

Logpoints are points in the program that will send a log message into your service logs. These logs are collected by Cloud Logging as well, fitting nicely into your existing application logs. [To know how to create Logpoints, follow this link].(https://cloud.google.com/debugger/docs/using/logpoints#console)

In this example, I created 3 logpoints in the same method of my Controller. When the user asks for a new Todo creation, the logpoint will be triggered and will send the message to Cloud Logging.

logpoint("task={createTodoDTO.task}, dueDate={createTodoDTO.dueDate}")
logpoint("createTodoDTO={createTodoDTO}")
logpoint("{createTodoDTO.toString()}")

You need to follow some Google Cloud logpoints specification in order to know what expressions you can use (For now, I am not able to find the complete documentation...). Here is the result in Cloud Logging.

For Java, I noticed 2 interesting things:

Logging object does not seem to perform a deep reflection LOGPOINT: createTodoDTO={ task: "a todo", dueDate: <Object> }. Here, you see the dueDate is logged as object.
You can't make any method call. The logpoint createTodoDTO.toString() logged an error: LOGPOINT: Method dev.truaro.blog.cloudrundeveloper.CreateTodoDTO.toString blocked (INVOKEDYNAMIC instruction not supported)

A snapshot works in a similar way, but the output is different. Instead of seeing logs output, you can directly inspect the stacktrace, and the current state of the object in the scope (this, parameters, variables...). To have a step by step snapshot creation, follow this link.

In this example, I created a snaphshot before calling the todoRepository. Here is the result:

You can see on the right side 2 interesting panels:

Variables: Display the content of this, your method parameters and the variables you created.
Call Stack: Display the stacktrace the lead you to your current snapshot.

Please note a snapshot does not stop your execution, it simply collects data, but does not affect the user experience.

Be also careful, the debugger is linked to a revision of your service. If you deploy a new revision, you will have to configure the Debugger to communicate with the new services.

Besides, your application needs to be running before creating LogPoints and Snapshots, otherwise the debugger agents will not send data to the Debugger service.

Cloud Profiler

Cloud Profiler is a service provided by Google Cloud to help understands the performance bottlenecks of your application. By analysing your application with Cloud Profiler, you can quickly spot what is causing the slowness in your application, and take actions to fix it.

Installing the Agent

Just like Cloud Debugger, profiling an application requires the installation of the Profiler Agent in the OCI image deployed on Cloud Run.

Following this documentation, here is how you can install the agent:

# Create a directory for the Profiler. Add and unzip the agent in the directory.
RUN mkdir -p /opt/cprof && \
   wget -q -O- https://storage.googleapis.com/cloud-profiler/java/latest/profiler_java_agent.tar.gz \
   | tar xzv -C /opt/cprof

Then, when running your Cloud Run service, you need to provide environment variables to complete the Profiler agent setup. Here is a combination I found useful to monitor a Spring Boot application:

JAVA_TOOL_OPTIONS=-agentpath:/opt/cprof/profiler_java_agent.so=-cprof_service=<SERVICE_NAME>,-cprof_enable_heap_sampling=true,-cprof_cpu_use_per_thread_timers=true

-cprof_service=<SERVICE_NAME>: provide the name of the service that will be used in Cloud Profiler. Usually, use the same name as the Cloud Run service.
-cprof_enable_heap_sampling=true: Enable Heap sampling. Only available for Java 11 and higher.
-cprof_cpu_use_per_thread_timers=true: Samples the CPU times per thread more precisely. Can add a little overhead, but as you run your application with multiple threads, it can be a useful metrics to have.

Profiling your application

Cloud Profiler works by collecting profiles of your running application. The profile agent communicates with the Cloud Profile backend API and sends profiling data every minute on average.

The Profiler can manage different information:

CPU Time: The most basic metrics every developer should be familiar with. It is the time spent by the CPU on your method execution. It doesn't calculate the time spent on other resources. Of course, if your application spent most of its time waiting for a resource, you might find that the CPU time does not reflect well your application execution process. That is why, you need other metrics to know how long a method took.
Wall Time: The total amount of time spent between the method call until the method returns. The Wall time will always be higher than the CPU times, as it will also track the time you spent waiting for a resource.
Heap memory usage:
- Heap: The amount of memory allocated in the program at a single point of time. It does not store the allocation during the program execution. To do so, there is the Allocated Heap metric.
- Allocated Heap: The allocated heap during the interval. Takes into account memory that has been allocated and memory that has been freed.

Unfortunately, not all metrics are available for all languages. For the full list of supported metrics, check the official documentation.

Data representation in Cloud Profiler UI

Before showing you a screenshot of the UI for my sample application, I think it is necessary to tell you how the data is represented. The final representation is a Flame Graph, which is an optimized and space efficient representation for a very large amount of information.

You can find more information in this documentation. It is unfamiliar at first, but once you are used to it, it is easier to read.

Example

In my example, I profile a Spring Boot Java 11 application. Therefore, I can only monitor:

CPU Time
Wall Time
And Heap usage

I created a Controller designed specifically for time consuming resources. Here is the code of the Controller:

@RestController
public class TimeConsumerController {

   @GetMapping("/consume")
   public void consume() {
       for(int i = 0; i < 1000000; i++) {
           Random random = new Random();
           int i1 = random.nextInt();
           int i2 = random.nextInt();
           int i3 = i1 + i2 + i;
           System.out.println("i3 = " + i3);
       }
   }
}

A simple loop, that generates random numbers, sums them and displays the result in the standard output.

After a couple of API calls, I got the following CPU time graph:

As a reference, here is the Wall Time graph:

In terms of seconds spent on the method, the Wall Time is 8.95s and the CPU Time is 5.13s.

With an application dealing with multiple users, you could have more useful metrics and time spent in specific methods, helping identify bottlenecks.

IMHO, the Cloud Profiler with Spring Boot is not very practical to profile specific business code and not framework code. Indeed, I spared you from the global Profiler graph, but you mostly see framework related methods, which can make it harder to find bottlenecks in your business code. Obviously, your application needs to be used in order to overcome the cost of the framework.

Cloud Trace

The last service you need to know is Cloud Trace. Its purpose is to monitor the latency of your requests when users call your application. In a nutshell, latency is the time delay the user waits before receiving the response from your application.

This service is automatically configured to monitor your Cloud Run services, which makes it very easy to use. Here is a screenshot of the latency of several requests I have made for the test.

Reading this graph is quite straightforward:

The blue dots represents the latency of a request
You can see the request with the longest latency took 15 seconds. This request started the Cloud Run service, which is why it took so long
You can see some requests taking around 10 seconds. These requests were hitting the /consume API (remember the API I created earlier ?)
For most of the requests, it took around 50ms to handle a GET on /todos, which is great. It means the user almost never waits to get a request that went through your Cloud Run and Datastore.

Of course, by default, not all requests are logged. Doing so would increase too much the volume of data, and your usage bill at the same time.

Cloud Trace offers other features that are not detailed here, like:

Building insightful graph to monitor accurately your application
Monitoring requests made by your application to another application to calculate the global latency
Exporting the data to aggregate your trace the way you need
Providing data about the user who generated the request, like its country, its region, its city...

The tool I used to generate some traffic is siege, a Linux tool to generate concurrent traffic on an endpoint. Here is the command line I used: siege -c 3 https://...

Conclusion

I hope you have a better view of some developer tools that could make your life with Cloud Run easier. To go further, there are also tools about latency and error reporting. Please, find below the list of the resources we went through together:

Improving Cloud Build pipeline with dependencies cache on Cloud Storage

RUARO Thibault — Sun, 28 Mar 2021 17:00:53 +0000

Introduction

Building a Continuous Deployment pipeline is amazing as you collect feedback on a daily basis. At first, the pipeline is quite quick and deploying applications is easy. But as your application is growing, you might have faced more and more latency... This article is here to show you how you can reduce the build time by adding dependencies cache on Cloud Storage.

For this focus, I'll simply use this cloudbuild.yaml file, watch the current deployment time, and explore how we improved it using Google Storage cache.

steps:
 - id: 'build-project'
   name: adoptopenjdk/openjdk11:jdk-11.0.8_10-slim
   dir: gcpcloudrunback
   entrypoint: bash
   args:
     - '-c'
     - |
       ./mvnw package

 - id: 'dockerize-project'
   name: gcr.io/cloud-builders/docker
   dir: gcpcloudrunback
   args: [ 'build',
           '-t', 'gcr.io/$PROJECT_ID/gcp-cloudrun-back:$SHORT_SHA',
           '-t', 'gcr.io/$PROJECT_ID/gcp-cloudrun-back:latest',
           '.' ]

 - id: 'push-to-cloud-registry'
   name: gcr.io/cloud-builders/docker
   args: [ 'push', 'gcr.io/$PROJECT_ID/gcp-cloudrun-back:$SHORT_SHA' ]

 - id: 'deploy-cloud-run'
   name: gcr.io/cloud-builders/gcloud
   dir: gcpcloudrunback
   entrypoint: bash
   args:
     - '-c'
     - |
       apt-get update
       apt-get install -qq -y gettext
       export PROJECT_ID=$PROJECT_ID
       export IMAGE_VERSION=$SHORT_SHA
       export SCALING_INSTANCE_COUNT=${_SCALING_INSTANCE_COUNT}
       envsubst < gcp-cloudrun-back.yaml > gcp-cloudrun-back_with_env.yaml
       gcloud beta run services replace gcp-cloudrun-back_with_env.yaml \
         --platform=managed --region=europe-west1
       gcloud run services add-iam-policy-binding gcp-cloudrun-back \
         --platform=managed --region=europe-west1 \
         --member="allUsers" --role="roles/run.invoker"

images:
 - 'gcr.io/$PROJECT_ID/gcp-cloudrun-back:$SHORT_SHA'
 - 'gcr.io/$PROJECT_ID/gcp-cloudrun-back:latest'

Here is the associated Dockerfile

# Use AdoptOpenJDK for base image.
FROM adoptopenjdk/openjdk11:jre-11.0.8_10-alpine

# Copy the jar to the production image from the previous step
COPY target/*.jar /app.jar

# Run the web service on container startup.
CMD ["java", "-jar", "/app.jar"]

In this pipeline, we build our application using the maven wrapper from our project. Besides, we use a simple Dockerfile, not a multi-staged one.

Also note you need to grant Cloud Build service account the Cloud Run and Service Accounts roles.

Reducing the build time with cache

Currently, when deploying this pipeline (based on this Github project), it takes my build 1 minute and 45 seconds on average to complete. Let's first understand this build time, to see what can be improved.

The longest step is the one where the dependencies need to be installed build-project, where we see all the dependencies are downloaded. If you think that those dependencies will not change so often, it clearly needs some optimization to avoid unnecessary resources to be used.

Add maven cache

Reading Google Cloud build optimizations documentation, we can manually add Google Storage cache to reduce build time.

Note that some Cloud Build competitors offer easily managed caching solutions... such a shame Cloud Build is not and we have to do everything manually.

Create a storage bucket

We will store our dependencies cache into a specific bucket. Let's create one:

gsutil mb gs://${PROJECT_ID}-cache-dependencies

Creating gs://${PROJECT_ID}-cache-dependencies/...

Replace ${PROJECT_ID} with your actual project Id. Cloud storage needs a unique name among all the buckets in the system. By prefixing your bucket with your project Id, there is a low chance to collide with another bucket name.

Add steps to fetch and save the cache

To fetch and save the cache downloaded by Maven:

We will use the volumes features of Cloud Build. By default, Cloud Build persists the folder /workspace across your build steps. We can specify other volumes to be persisted.
Cloud Build does not offer yet an easy way to cache dependencies for any usage across different builds.
It does not offer also the possibility for a step to fail silently without stopping the pipeline.

Knowing this, here is what the final cloudbuild.yaml with dependencies cache looks like:

steps:
 - id: 'download-cached-maven-dependencies'
   name: gcr.io/cloud-builders/gsutil
   entrypoint: bash
   volumes:
     - name: 'maven-repository'
       path: '/root/.m2'
   args:
     - '-c'
     - |
       gsutil cp gs://${PROJECT_ID}-cache-dependencies/cache/maven-dependencies.tgz maven-dependencies.tgz || exit 0
       tar -zxf maven-dependencies.tgz --directory / || exit 0

 - id: 'build-project'
   name: adoptopenjdk/openjdk11:jdk-11.0.8_10
   dir: mavencachecloudbuild/gcpcloudrunback
   entrypoint: bash
   volumes:
     - name: 'maven-repository'
       path: '/root/.m2'
   args:
     - '-c'
     - |
       ./mvnw package

 - id: 'dockerize-project'
   name: gcr.io/cloud-builders/docker
   dir: mavencachecloudbuild/gcpcloudrunback
   args: [ 'build',
           '-t', 'gcr.io/$PROJECT_ID/gcp-cloudrun-back:$SHORT_SHA',
           '-t', 'gcr.io/$PROJECT_ID/gcp-cloudrun-back:latest',
           '.' ]

 - id: 'push-to-cloud-registry'
   name: gcr.io/cloud-builders/docker
   args: [ 'push', 'gcr.io/$PROJECT_ID/gcp-cloudrun-back:$SHORT_SHA' ]

 - id: 'deploy-cloud-run'
   name: gcr.io/cloud-builders/gcloud
   dir: mavencachecloudbuild/gcpcloudrunback
   entrypoint: bash
   args:
     - '-c'
     - |
       apt-get update
       apt-get install -qq -y gettext
       export PROJECT_ID=$PROJECT_ID
       export IMAGE_VERSION=$SHORT_SHA
       export SCALING_INSTANCE_COUNT=${_SCALING_INSTANCE_COUNT}
       envsubst < gcp-cloudrun-back.yaml > gcp-cloudrun-back_with_env.yaml
       gcloud beta run services replace gcp-cloudrun-back_with_env.yaml \
         --platform=managed --region=europe-west1
       gcloud run services add-iam-policy-binding gcp-cloudrun-back \
         --platform=managed --region=europe-west1 \
         --member="allUsers" --role="roles/run.invoker"

 - id: 'upload-cached-maven-dependencies'
   waitFor: [ 'build-project']
   name: gcr.io/cloud-builders/gsutil
   entrypoint: bash
   volumes:
     - name: 'maven-repository'
       path: '/root/.m2'
   args:
     - '-c'
     - |
       tar -zcf maven-dependencies.tgz /root/.m2
       gsutil cp maven-dependencies.tgz gs://${PROJECT_ID}-cache-dependencies/cache/maven-dependencies.tgz

images:
 - 'gcr.io/$PROJECT_ID/gcp-cloudrun-back:$SHORT_SHA'
 - 'gcr.io/$PROJECT_ID/gcp-cloudrun-back:latest'

Let's review the important part.

The first is about downloading the maven from the Cloud Storage bucket.

 - id: 'download-cached-maven-dependencies'
   name: gcr.io/cloud-builders/gsutil
   entrypoint: bash
   volumes:
     - name: 'maven-repository'
       path: '/root/.m2'
   args:
     - '-c'
     - |
       gsutil cp gs://${PROJECT_ID}-cache-dependencies/cache/maven-dependencies.tgz maven-dependencies.tgz || exit 0
       tar -zxf maven-dependencies.tgz --directory / || exit 0

name: gcr.io/cloud-builders/gsutil: use a provided Google image with gsutil to manage buckets.

volumes:: persist a volume across build steps. With maven, the default volume is /${USER_HOME}/.m2, which is /root/.m2 in our different images.

gsutil cp && tar -xzf: downloading the files from the bucket (in .tgz to reduce dependencies size).

|| exit 0: As mentioned earlier, there is no easy way to ignore steps on error. Just add exit 0 to make sure if the folder does not exist on the bucket your build does not fail. I know it is not a perfect solution, but the step is small enough not to damage the entire pipeline. Besides, if you don’t have cache, you can still build the application.

Use the volume persisted by the previous steps to enhance the ./mvnw command

 - id: 'build-project'
   name: adoptopenjdk/openjdk11:jdk-11.0.8_10-slim
   dir: mavencachecloudbuild/gcpcloudrunback
   entrypoint: bash
   volumes:
     - name: 'maven-repository'
       path: '/root/.m2'
   args:
     - '-c'
     - |
       ./mvnw package

Thanks to the shared volume, when the step will execute ./mvnw package it will rely on the dependencies provided by Cloud Storage.

Upload the dependencies. Very useful if you changed your pom.xml and you need to update the cache with the new dependencies

 - id: 'upload-cached-maven-dependencies'
   waitFor: [ 'build-project']
   name: gcr.io/cloud-builders/gsutil
   entrypoint: bash
   volumes:
     - name: 'maven-repository'
       path: '/root/.m2'
   args:
     - '-c'
     - |
       tar -zcf maven-dependencies.tgz /root/.m2
       gsutil cp maven-dependencies.tgz gs://${PROJECT_ID}-cache-dependencies/cache/maven-dependencies.tgz

In this step, we expect it not to fail, so we don't use exit 0.

We reuse the volume created by download-cached-maven-dependencies and potentially modified by build-project.

We use the waitFor to start this step right after the build-project, as this volume will no longer be modified later.

Results

The first build will be slightly longer, as you added 2 steps and there is no cached yet. But the next ones will be faster !

Here is the result of the first build, before the cache was created.

Here is the result of the second build, after the cache was created.

For now, we save couple of seconds (30 seconds), not worth it you might say. But keep in mind your build will get bigger and bigger, and if you do not optimize it, it will take minutes before completion. Today, we simply deploy one single Cloud Run service, but we can deploy 2 or 3, with Cloud Functions as well. If you download maven dependencies each time, you will waste a lot of time and resources. So keep that in mind.

Bonus: the same for a frontend project with yarn

Here is the cloudbuild.yaml file to also save yarn dependencies.

steps:
 - id: 'download-cached-yarn-dependencies'
   name: gcr.io/cloud-builders/gsutil
   dir: gcpfirebasefront
   entrypoint: bash
   args:
     - '-c'
     - |
       gsutil cp gs://${PROJECT_ID}-cache-dependencies/cache/yarn-dependencies.tgz yarn-dependencies.tgz || exit 0
       tar -zxf yarn-dependencies.tgz || exit 0

 - id: 'install-yarn'
   name: node
   entrypoint: yarn
   dir: gcpfirebasefront
   args: ['install', '--silent']

 - id: 'build-front'
   name: node
   entrypoint: yarn
   dir: gcpfirebasefront
   args: [ 'build' ]

 - id: 'deploy-firebase'
   name: gcr.io/$PROJECT_ID/firebase
   dir: gcpfirebasefront
   args: [ 'deploy', '--project=$PROJECT_ID', '--only', 'hosting' ]

 - id: 'upload-cached-yarn-dependencies'
   waitFor: ['build-front']
   name: gcr.io/cloud-builders/gsutil
   entrypoint: bash
   dir: cloudcmr-front
   args:
     - '-c'
     - |
       tar -zcf yarn-dependencies.tgz ./node_modules
       gsutil cp yarn-dependencies.tgz gs://${PROJECT_ID}-cache-dependencies/cache/yarn-dependencies.tgz

Note for yarn the dependencies are located under /workspace folder hierarchies. Therefore, there is no need to add a custom volume to be persisted by Cloud Build

Summary

In this article focused on optimizing Cloud Build with Maven and Yarn build steps, we covered:

Common issues when not caching dependencies, by wasting resources and times
Creation a bucket using gsutil to store dependencies
Ignore steps in error, which is not provided out-of-the-box by Cloud Build at this time
Persistence of other folders across a build
Downloading and fetching files from a Cloud Storage bucket

Please note using Cloud Storage as cache storage will incur small fees as you pay for the GigaBytes stored. But don't worry, the cached maven folder is 61MB, which is free for your usage.

To go further

If you feel like it, you can improve some parts of the build by:

Instead of downloading a file from a bucket, why not build an image containing all the dependencies you need ?
Use a hash to make upload the dependencies only if they changed since last build
You can also store docker image in a Bucket, which make the build even faster (using Google Jib)
Improve the build avoiding hiding the errors when downloading the files from the cache folder
Configure your bucket to delete files older than 2 weeks, in order to save some money for a cache that is no longer used.

Resources

Continuous Deployment on Firebase using Cloud Build

RUARO Thibault — Mon, 25 Jan 2021 13:16:36 +0000

Introduction

We just created a simple Vue application deployed in Firebase in the previous article. Like I mentioned many times in this blog, regular feedback is key to build a successful application.

Let's enhance the Continuous Deployment pipeline we created in Continuous Deployment pipeline with Cloud Build on Cloud Run to add automatic deployment of the frontend part of our application.

To remind you, we previously created a nice Vue application communicating with a Cloud Run backend application. The application was deployed on Firebase to have an international audience with no effort. Let's automate this deployment.

Here is the Github project you can clone to follow the article.

Create the Continuous Deployment pipeline for a Firebase deployed application

I won't cover all the subjects like I did in Continuous Deployment pipeline with Cloud Build on Cloud Run. If you started from here and you wish to configure your GCP project to use Cloud Build, please check previous articles.

Create a Firebase deployment image

To deploy using Firebase, you need to create an image containing the Firebase CLI, making it easy to deploy your application. Here is the official link to create a Firebase image to deploy your application. At the time of the article, here are the commands:

git clone https://github.com/GoogleCloudPlatform/cloud-builders-community.git
cd cloud-builders-community/firebase
gcloud builds submit .
cd ../..
rm -rf cloud-builders-community/

If these steps do not work for you, check the official link to make sure it didn't change since the article was written (which is very likely)

The steps above create and push a Firebase ready image on your Container Registry which can be used in a Cloud Build pipeline.

To make sure the image is in your container, try executing this command:

gcloud container images list --filter="name:firebase"      

NAME
gcr.io/truaro-resources/firebase

Cloud Build pipeline for Vue application in Firebase

Now you have a Firebase image, let's add new steps to deploy our Vue application. As a reminder, you should have the following project structure:

* gcpapplication/
|--- gcpcloudrunback/
|--- gcpfirebasefront/
|--- cloudbuild.yaml

The content of cloudbuild.yaml after the first pipeline is:

steps:
 - id: 'dockerize-project'
   name: gcr.io/cloud-builders/docker
   dir: gcpcloudrunback
   args: ['build',
          '-t', 'gcr.io/$PROJECT_ID/gcp-cloudrun-back:$SHORT_SHA',
          '-t', 'gcr.io/$PROJECT_ID/gcp-cloudrun-back:latest',
          '.']

 - id: 'push-to-cloud-registry'
   name: gcr.io/cloud-builders/docker
   args: ['push', 'gcr.io/$PROJECT_ID/gcp-cloudrun-back:$SHORT_SHA']

 - id: 'deploy-cloud-run'
   name: gcr.io/cloud-builders/gcloud
   dir: gcpcloudrunback
   entrypoint: bash
   args:
     - '-c'
     - |
       apt-get update
       apt-get install -qq -y gettext
       export PROJECT_ID=$PROJECT_ID
       export IMAGE_VERSION=$SHORT_SHA
       export SCALING_INSTANCE_COUNT=${_SCALING_INSTANCE_COUNT}
       envsubst < gcp-cloudrun-back.yaml > gcp-cloudrun-back_with_env.yaml
       gcloud beta run services replace gcp-cloudrun-back_with_env.yaml \
         --platform=managed --region=europe-west1
       gcloud run services add-iam-policy-binding gcp-cloudrun-back \
         --platform=managed --region=europe-west1 \
         --member="allUsers" --role="roles/run.invoker"

images:
 - 'gcr.io/$PROJECT_ID/gcp-cloudrun-back:$SHORT_SHA'
 - 'gcr.io/$PROJECT_ID/gcp-cloudrun-back:latest'

It is deploying only the backend part of our application.

Let's add the Frontend part now.

Configuring Cloud Build to deploy on Firebase

To deploy on Firebase, your Cloud Build service account must have the role Firebase Admin. Grant the role to your service account with:

gcloud projects add-iam-policy-binding ${YOUR_PROJECT_ID} \
    --member=serviceAccount:XXXX@cloudbuild.gserviceaccount.com \
    --role=roles/firebase.admin

Replace ${YOUR_PROJECT_ID} and XXXX by your actual value

roles/firebase.admin: To allow the Cloud Build service account to deploy on Firebase

Or, if you follow this, you can also manually enable the Firebase Admin role.

Adding steps to deploy Vue in Firebase

Just add the following 3 steps between the step deploy-cloud-run and the images part:

 - id: 'install-yarn'
   waitFor: ['-']
   name: node
   entrypoint: yarn
   dir: gcpfirebasefront
   args: ['install', '--silent']

 - id: 'build-front'
   waitFor: [ 'install-yarn' ]
   name: node
   entrypoint: yarn
   dir: gcpfirebasefront
   args: [ 'build' ]

 - id: 'deploy-firebase'
   waitFor: [ 'build-front' ]
   name: gcr.io/${PROJECT_ID}/firebase
   args: [ 'deploy', '--project=$PROJECT_ID', '--only', 'hosting' ]
   dir: gcpfirebasefront

As always, let's review the important part.

Install the yarn dependencies

- id: 'install-yarn'
 waitFor: ['-']
 name: node
 entrypoint: yarn
 dir: gcpfirebasefront
 args: ['install', '--silent']

waitFor: [ '-' ]: Run this step in parallel with the others. Indeed, we don't need to wait for the backend to be deployed in order to deploy the front. It is a performance improvement of your CD pipeline.

name: node: We use the official node image from the Docker hub registry.

entrypoint: yarn: yarn is the package manager we use to build the application.

dir: gcpfirebasefront: We change the directory to go in the gcpfirebasefront.

args: [ 'install', '--silent' ]: Just run the yarn install --silent command, to package our application for production. Not mandatory, but I find yarn install to be quite verbose.

Build the Vue application

- id: 'build-front'
 waitFor: [ 'install-yarn' ]
 name: node
 entrypoint: yarn
 dir: gcpfirebasefront
 args: [ 'build' ]

waitFor: [ 'install-yarn' ]: yarn install needs to be done before moving further

args: [ 'build' ]: Just run the yarn build command, to package our application for production

As you can see, we do not create any Docker image. We simply build the application using yarn build. The dist folder is located under /workspace, the shared volumes of Cloud Build. The next step will be able to deploy on Firebase what has been built at this step.

Deploy on Firebase

- id: 'deploy-firebase'
 waitFor: [ 'build-front' ]
 name: gcr.io/$PROJECT_ID/firebase
 args: [ 'deploy', '--project=$PROJECT_ID', '--only', 'hosting' ]
 dir: gcpfirebasefront

waitFor: [ 'build-front' ]: Just wait for the previous step, not the backend steps.

name: gcr.io/$PROJECT_ID/firebase: Step based on the image we created earlier to use the Firebase CLI

args: [ 'deploy', '--project=$PROJECT_ID', '--only', 'hosting' ]: The args to be passed to firebase command

$PROJECT_ID: As always, a substitution variable provided by Cloud Build

This step simply executes the command firebase deploy --project=${PROJECT_ID} --only hosting. If you remember well, it was the same command we used in the previous article from our local machine.

Once again, do not go too fast, start slow with easy steps. You can only create a Continuous Deployment pipeline if you have something to automate...

Review the Cloud Build deployment file

The final file looks like:

steps:
 - id: 'dockerize-project'
   name: gcr.io/cloud-builders/docker
   dir: gcpcloudrunback
   args: [ 'build',
           '-t', 'gcr.io/$PROJECT_ID/gcp-cloudrun-back:$SHORT_SHA',
           '-t', 'gcr.io/$PROJECT_ID/gcp-cloudrun-back:latest',
           '.' ]

 - id: 'push-to-cloud-registry'
   name: gcr.io/cloud-builders/docker
   args: [ 'push', 'gcr.io/$PROJECT_ID/gcp-cloudrun-back:$SHORT_SHA' ]

 - id: 'deploy-cloud-run'
   name: gcr.io/cloud-builders/gcloud
   dir: gcpcloudrunback
   entrypoint: bash
   args:
     - '-c'
     - |
       apt-get update
       apt-get install -qq -y gettext
       export PROJECT_ID=$PROJECT_ID
       export IMAGE_VERSION=$SHORT_SHA
       export SCALING_INSTANCE_COUNT=${_SCALING_INSTANCE_COUNT}
       envsubst < gcp-cloudrun-back.yaml > gcp-cloudrun-back_with_env.yaml
       gcloud beta run services replace gcp-cloudrun-back_with_env.yaml \
         --platform=managed --region=europe-west1
       gcloud run services add-iam-policy-binding gcp-cloudrun-back \
         --platform=managed --region=europe-west1 \
         --member="allUsers" --role="roles/run.invoker"

 - id: 'install-yarn'
   waitFor: ['-']
   name: node
   entrypoint: yarn
   dir: gcpfirebasefront
   args: ['install', '--silent']

 - id: 'build-front'
   waitFor: [ 'install-yarn' ]
   name: node
   entrypoint: yarn
   dir: gcpfirebasefront
   args: [ 'build' ]

 - id: 'deploy-firebase'
   waitFor: [ 'build-front' ]
   name: gcr.io/$PROJECT_ID/firebase
   args: [ 'deploy', '--project=$PROJECT_ID', '--only', 'hosting' ]
   dir: gcpfirebasefront

images:
 - 'gcr.io/$PROJECT_ID/gcp-cloudrun-back:$SHORT_SHA'
 - 'gcr.io/$PROJECT_ID/gcp-cloudrun-back:latest'

Change the Vue application to see a change

Just change the gcpfirebasefront/src/HelloWorld.vue file. Update the <h1> to see the Frontend has been deployed:

<template>
 <div class="hello">
   <h1>From firebase: {{ msg }}</h1>

As we already have the Cloud Build triggers created in a previous article, simply push your application and everything will be automatically deployed.

To follow up the build execution, go on the GCP console, you will have the logs. Or just use this command to see if the deployment is still ongoing:

gcloud builds list --ongoing
46e2992d-24f4-4df5-8190-a6c132a4827b  2020-12-05T12:37:43+00:00            github_truar_try-gcp-deploy@80c5b6d1eb9bc5425e2abec092535ff2a30ee5b6  -       WORKING

Once the build is finished (i.e the command output is empty), just access your firebase web application page. Here is my result:

Summary

In this article, we covered:

Creating a Firebase image to use the firebase CLI in a Cloud Build step
Configuring the Cloud Build service account to deploy applications on Firebase
Configuring Cloud Build steps to build and deploy a static frontend application on Firebase

With all the previous articles, we are starting to have a nice view of the tools and services we can lever to easily deploy an application on the Cloud. You might have noticed, the pricing is very appealing for an application that is available 24/7 everywhere in the world. This is one of the main advantages of GCP platform, you can build international applications for a very attractive price.

What's next

To go further, we could:

Configure a cache to improve build speed to avoid downloading frontend dependencies at each build
Use the multi-site Firebase feature to have a staging and production website
Use the new preview channel feature
Split the cloudbuild.yaml file to deploy independently the frontend and the backend

Resources

Build a Vue app with Firebase and Cloud Run

RUARO Thibault — Mon, 25 Jan 2021 13:04:19 +0000

Introduction

Building a rich and powerful web application has never been so easy and so complicated at the same time. The web expanded really fast, and with it, the need to build more and more advanced applications. Empowered by some great frameworks wishing to simplify your life as a Frontend developer, you can easily start following some tutorials and documentation, and in the meantime, being totally lost in the wide eco-system you can now face. The time when we manipulated the DOM ourselves is now gone, and we must embrace advanced architectural style whose purpose is to ease the application maintenance and evolution.

Those famous Web frameworks, you might know them already, even only by name. There are three main ones:

Angular, supported by Google developers team
React supported by Facebook developers team
Vue, supported by a community of developers sharing passion for frontend development

Despite the fact Vue was not maintained by one of the GAFAM, it is nowadays a great framework used widely, even by the GAFAM themselves. Besides, as Vue is the framework I enjoyed the most, it is the one I chose in this article to build the frontend part of the application.

Developing an application is now accessible quickly to the most, but deploying this application and making it accessible is quite another challenge. Not everyone is comfortable with server administration and deployment tasks. Hopefully, Google comes with an answer: Firebase.

Firebase is a platform developed by Google for creating mobile and web applications. It was originally an independent company founded in 2011. In 2014, Google acquired the platform and it is now their flagship offering for app development. -- Google

In other words, Firebase makes it easier for you to host your application by offering complete server management. Your app is easily scalable, which means it can support load peaks, and accessible worldwide, for almost a penny. Under the hood, Firebase uses Google Cloud Platform technology to host your application. This makes easy to have a Vue application accessible 100% of the time for free (almost but clearly, you won't pay much) communicating with another backend application hosted on GCP, like Cloud Functions or Cloud Run.

In this article, we will focus on developing a Vue application communicating with the Spring Boot application hosted on Cloud Run we developed in the previous article. We will host it using Firebase and deploy it by improving the Cloud Build pipeline we covered in the second article.

Prerequisites

Node.js: an open-source javascript runtime environment. You need it in order to run javascript code outside of a browser. To install Node, follow this link
Yarn or NPM: a package manager to download the different libs you need to build your application. If you come from the Java world, you might know Maven or Gradle. Those are famous package manager for java application. For frontend development, I will use Yarn. To install Yarn, click here

Building the VusJS application

Vue team released recently the third version of Vue. We will not cover differences between Vue 2 and Vue 3, but let's use the latest versions available.

Remember the folder trees we had in the previous articles?

* gcpapplication
|--- gcpcloudrunback (this one has been created in the first part)
|--- gcpfirebasefront (you migh not have this one yet)

In this article, we will create the gcpfirebasefront folder. Don't do it manually, we will create it automatically in the next section.

Creating the application using vue-cli

First, follow the official documentation to install or upgrade the vue-cli. If you already have, I recommend upgrading to the latest version (4.5.9 at the time of the article creation), as you can use Vue 3.

Considering your are located in the gcpapplication folder, run

vue create gcpfirebasefront --preset __default_vue_3__

It might take a couple of minutes, just be patient.

The preset Vue 3 is very minimal using babel and eslint. It will be more than enough for our application.

For the rest of this part, we will only be located inside the folder gcpfirebasefront.

Configuring the application

Let's create a file vue.config.js at the root of gcpfirebasefront:

// vue.config.js
module.exports = {
    devServer: {
        port: 8088,
        proxy: {
            '/api': {
                target: 'http://localhost:8080',
                ws: true,
                changeOrigin: true
            }
        }
    }
}

devServer.port: By default, the development server port is 8080, which will conflict with our backend application. Let's change it to 8088

devServer.proxy: Create a middleware proxy to change the origin of request targeting the target attribute. This is very convenient in order to avoid CORS configuration. This way, the browser sends a request to the same server as the Frontend, and the proxy is in charge of calling the backend service by changing the Origin.

Calling the backend server to change the display

If you take a look into the Vue application generated by vue-cli, you can see several folders. The interesting one in our use case will be src, which contains the application js files. Let's update src/App.vue to add an interaction with our server, and display the Welcome message coming from the server:

// src/App.vue
<template>
  <img alt="Vue logo" src="./assets/logo.png">
  <HelloWorld :msg="message"/>
</template>

<script>
import HelloWorld from './components/HelloWorld.vue'

export default {
  name: 'App',
  components: {
    HelloWorld
  },
  data() {
    return {
      message: 'Loading...'
    };
  },
  async created() {
    const response = await fetch('/api/')
    this.message = await response.text()
  }
}
</script>

<style>
#app {
  font-family: Avenir, Helvetica, Arial, sans-serif;
  -webkit-font-smoothing: antialiased;
  -moz-osx-font-smoothing: grayscale;
  text-align: center;
  color: #2c3e50;
  margin-top: 60px;
}
</style>

Let's focus on the changed lines:

<HelloWorld :msg="message"/>

We bind the property msg of the HelloWorld component to an attribute from our component inner data.

Here is the creation and the modification of the data part:

export default {
  // ...
  data() {
    return {
      message: 'Loading...'
    };
  },
  async created() {
    const response = await fetch('/api/')
    this.message = await response.text()
  }
}

Set Loading... in the message attribute by default.

Fetch the data from the server when Vue calls the created method. This method is part if vue lifecycle and is called automatically at component creation.

As you might notice, fetch('/api/') shows the backend server is not directly targeted. Instead, the proxy intercepts the request and change apply corresponding changes according to the devServer.proxy configuration.

Test locally the application

Just like a cook tasting every part of his meals to make sure it is delicious and has the expected taste, you must taste (😅) your application at each step. We could have done one to test the creation using vue-cli but for the article length sake, I decided not to.

Now, let's try if our frontend is properly communicating with our backend. Open 2 terminals, and from the folder gcpapplication, run:

# terminal 1
cd gcpcloudrunback
./mvnw spring-boot:run

# terminal 2
cd gcpfirebasefront
yarn serve
# or npm run serve depending on what is installed on your application

Open your browser and navigate to localhost:8088. You should see something like this:

If you see something different than Hello World. I am deployed automatically, that means you may have missed a step. Read back, and come back again when it is working. Otherwise, you'll miss the best part: deploying in Firebase.

Deploying the application on Firebase Hosting

Firebase Hosting is a great solution to host static websites (like Single Page Application) where the content of the files is static (like a javascript application). With the Hosting solution, you pay depending on your website size. The more files you have, the more expensive is the bill. For this article, the Hosting solution is free given our very small project.

Connect on Firebase and add your project

Import your GCP project to Firebase

The first thing is to add your GCP project to Firebase (created in the first article). Quickly, just log in to firebase and go on this URL. From there:

Click on Add Project.
Select the one you created previously.
Accept or not using Google analytics. For this project, we don't need it. It is up to you.
Accept the terms and conditions
Let firebase prepare your project.

Prepare your environment

Once the project is set, install the Firebase CLI locally to execute some commands. To do so, follow the official documentation.

After the installation, run this to make sure it works:

firebase --version
8.16.2

8.16.2 was at the time of the article creation. You might have a different output.

Initialize your Firebase project

The Firebase CLI has an init command, but it does not support passing all options at once. You need to interact with the CLI, and it is really not convenient for this article. So if you feel like it, you can try running firebase init. But for the sake of the article, I'll give the file you need to create.

If you want to run firebase init make sure you are located in gcpfirebasefront

Create a file called firebase.json in gcpfirebasefront with the following content:

{
  "hosting": {
    "public": "dist",
    "ignore": [
      "firebase.json",
      "**/.*",
      "**/node_modules/**"
    ],
    "rewrites": [
      {
        "source": "**",
        "destination": "/index.html"
      }
    ]
  }
}

Quick explanation:

public: the folder in which are located the production files built by yarn build

ignore: ignores folders/files to be uploaded onto Firebase. As you only pay for the storage, make sure you don't upload unused files.

rewrites: A rewrite rules mandatory in the case of Single Page Application, to make sure all URLs use the index.html file.

These files should be the result if you ran the command firebase init. Besides, the firebase init command generates a file .firebaserc, but we won't need it.

Connect your Firebase site to Cloud Run

Since recently, Firebase has a convenient way to redirect some HTTP requests to a Managed Cloud Run service. To do so, the firebase.json file needs to configure the rewrites rule. Add a new rewrite rule like this as the first rewrites array element:

{
    "source": "/api/**",
    "run": {
        "serviceId": "gcp-cloudrun-back",
        "region": "europe-west1"
    }
}

source: Redirect HTTP request api to the Cloud Run service

run: The Cloud Run service name serviceId and the region. Remember from the first article, we deployed a Cloud Run service called gcp-cloudrun-back in the region europe-west1.

This configuration is really great to avoid CORS configuration, where most of the time, this can lead to security issues if not thought carefully. So if possible, let's avoid those problems.

Here is the final form of the firebase.json file:

{
  "hosting": {
    "public": "dist",
    "ignore": [
      "firebase.json",
      "**/.*",
      "**/node_modules/**"
    ],
    "rewrites": [
    {
        "source": "/api/**",
        "run": {
          "serviceId": "gcp-cloudrun-back",
          "region": "europe-west1"
        }
      },
      {
        "source": "**",
        "destination": "/index.html"
      }
    ]
  }
}

Note the rewrites rules order, first matched first served.

Deploy the application on Firebase

Now, let's use the firebase CLI to deploy our application:

yarn build
firebase deploy --project=${PROJECT_ID} --only hosting

...
✔  Deploy complete!

Project Console: https://console.firebase.google.com/project/truaro-resources/overview
Hosting URL: https://truaro-resources.web.app

Replace ${PROJECT_ID} with your Firebase Project Id.

HOSTING_URL is your application URL.

Now, you can access your application on Firebase using the Hosting URL firebase gave you after the execution of the deployment command. The webpage displayed should be the same as the local test we did earlier:

You might first see Loading... a couple of seconds before seeing Hello World. I am automatically deployed. Don't worry, it only means your Cloud Run service is booting. Once Cloud Run is up, the communication with the server is very fast and you won't even see Loading... anymore.

Summary

🎉 Congratulations !! If you made it, here is what you accomplished:

Creating a Vue 3 application using the vue-cli
Fetching data from your server with a Proxy configuration to avoid CORS request
Configuring a Firebase project to use the great Hosting solution
Use the firebase CLI to deploy your first website on Firebase
Configure your Firebase website to communicate with a Cloud Run service

What's next

To go further with this vue application, you could:

Enhance it by adding a router
Improve the design using a nice component library, like Vuetify or Quasar
Use a CD pipeline using Cloud Build to automatically deploy your application using Cloud Build (coming in a next article)

Resources

Continuous Deployment pipeline with Cloud Build on Cloud Run

RUARO Thibault — Sat, 12 Dec 2020 10:05:02 +0000

Introduction

Building software is a long and difficult process that takes time and skills. In order to succeed in our tasks, we as software developers need to craft the software steps by steps. There are a lot of good development practices for writing code, in order to get feedback as soon as possible. But if we set the boundaries at the code itself, we will miss a lot.

A great team understands the importance of giving users access to the software as soon as possible. Even if the software is not yet complete, allowing the users to play with the application gives you way better feedback than any other things you could do. In other words, the new functionalities need to be deployed as soon as they are done, to collect those precious feedback.

That is why building a Continuous Deployment pipeline as soon as possible will put your product on the best track to become a successful software. Once the pipeline set, you don't bother anymore with feature deployments. You give at ease access to the user almost instantaneously, and collect its feedback on a daily basis.

In my journey as a Cloud Architect, I have decided to try some GCP features to create a CD pipeline. The ones we cover today are:

Cloud Source Repositories: Mirroring a Github repository, it keeps your code sync on the GCP platform.
Cloud Build: Create a Continuous Deployment pipeline and trigger builds when a change occurs in your repository.

This article is based on the first one where we created a Spring application and deployed it on Cloud Run. You can directly get the code by cloning the repository

As a reminder, you should have the following folder structure:

* gcpapplication
|--- gcpcloudrunback (this one has been created in the first part)
|--- gcpfirebasefront (you migh not have this one yet)

Please note we will use gcpapplication as the root folder in this article.

Creating a Continuous Deployment pipeline using Cloud Build

Cloud Build is a service that executes your builds on Google infrastructure. De facto, you can create a Continuous Deployment pipeline using Google provided image to build and deploy your application on GCP.

Together, we will use Cloud Build to deploy our previously created Spring Application hosted on Cloud Run.

Cloud Build allows you to define steps executed on a Docker container. Among the features, we will be using:

GCP provided image to enhance our build. Indeed, Google provided images are already available on build execution, there is no need to download them from Docker registry, which could slow down your build.
Steps which are the main concept of Cloud Build: defines sequential or parallel steps to execute your build.
Substitutions variables that enrich our build to favor re-usability.

Before using the Cloud Build API, as always, we need to activate it:

gcloud services enable cloudbuild.googleapis.com

Under the hood, Cloud Build uses Cloud Storage bucket to store logs and other metadata for the build. This might incur very small fees.

Building and Pushing our Docker image using Cloud Build

The first step is to build and push our Dockerfile on Container Registry with Cloud Build. To do so, we will simply add a new file called cloudbuild.yaml at the root of our project.

steps:
  - id: 'dockerize-project'
    name: gcr.io/cloud-builders/docker
    dir: gcpcloudrunback
    args: ['build',
           '-t', 'gcr.io/$PROJECT_ID/gcp-cloudrun-back:$SHORT_SHA',
           '-t', 'gcr.io/$PROJECT_ID/gcp-cloudrun-back:latest',
           '.']

images:
  - 'gcr.io/$PROJECT_ID/gcp-cloudrun-back:$SHORT_SHA'
  - 'gcr.io/$PROJECT_ID/gcp-cloudrun-back:latest'

Let's split this file.

The first step is about building our Dockerfile to generate the Docker image.

steps:
  - id: 'dockerize-project'
    name: gcr.io/cloud-builders/docker
    dir: gcpcloudrunback
    args: ['build',
           '-t', 'gcr.io/$PROJECT_ID/gcp-cloudrun-back:$SHORT_SHA',
           '-t', 'gcr.io/$PROJECT_ID/gcp-cloudrun-back:latest',
           '.']

steps: Specifies a list of actions that you want Cloud Build to perform on the GCP environment. Here we define a first step to build our multi-stage Dockerfile.

id: a unique name across the file that can be used as a reference for parallel build.

name: The docker image name used to execute the command. You can reference image that will be fetched from Docker registry, or from Google Container Registry. Please note the predefined images fetched from Container Registry are cached by Google.

dir: The current folder you want to execute the command in. In our project, the cloudbuild.yaml file is at the root of our project, but the Dockerfile is in gcpcloudrunback folder.

args: The list of arguments passed to the entrypoint statement of the Dockerfile referenced in the name part.

$PROJECT_ID: A substitution variable automatically replaced by Cloud Build when running your build.

$SHORT_SHA: A substitution variable provided by a Cloud Build trigger. By default, the SHORT_SHA is not available as the build needs to be triggered. But we will see how to provide substitutions variables when testing our Cloud Build config without trigger.

The final statement pushes images to Container Registry.

images:
  - 'gcr.io/$PROJECT_ID/gcp-cloudrun-back:$SHORT_SHA'
  - 'gcr.io/$PROJECT_ID/gcp-cloudrun-back:latest'

You can specify all the images built during your build to Container Registry, they will all be pushed.

In order to check if our configuration works as expected, we can use gcloud builds submit command. This command uploads your current folder into a Storage Bucket used by Cloud Build to perform the build.

To reduce the size of the uploaded archive, I recommend creating a .cloudignore file containing:

.git
dist
node_modules
vendor
*.jar
target
.firebase
.mvn
.idea
*.iml
mvnw*
build
.gradle

This file covers many things, like maven, gradle, firebase... not all of them are mandatory at the moment for your simple application, but it might get bigger, so let's keep those folders excluded. It doesn't hurt anyway.

Now, from the root folder, run the command (it might take a few minutes):

gcloud builds submit . --substitutions SHORT_SHA=local

DONE
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

ID                                    CREATE_TIME                DURATION  SOURCE                                                                                          IMAGES                                                     STATUS
926b58b7-d97e-406e-b971-378cf190ab3f  2020-11-19T15:30:09+00:00  1M54S     gs://truaro-resources_cloudbuild/source/1605799808.257327-c27971b7200a4f50ba7f84621e119d6a.tgz  gcr.io/truaro-resources/gcp-cloudrun-back:local (+2 more)  SUCCESS

To make sure the image is pushed, you can also list the image on Container Registry using the command:

gcloud container images list-tags gcr.io/${PROJECT_ID}/gcp-cloudrun-back

DIGEST        TAGS          TIMESTAMP
f594672dce19  latest,local  2020-11-19T16:31:56

Replace ${PROJECT_ID} with your actual Project Id.

Deploying the image on Cloud Run using Cloud Build

When using Cloud Build, GCP uses a service account dedicated to Cloud Build. This service account will communicate with your GCP resources, such as Cloud Run in our case. To allow Cloud Build service account managing Cloud Run resources, we need to add the proper roles to Cloud Build service account.

Granting access at Cloud Run to the Cloud Build service account

First, figure out what service account your Cloud Build is using by going on the GCP web interface > Cloud Build > Settings. Once you have the service account name, you can use it in the next commamd.

You should only replace the XXXX, the email domain name should remain the same.

Grant the roles/run.admin and roles/iam.serviceAccountUser roles to XXXX@cloudbuild.gserviceaccount.com

gcloud projects add-iam-policy-binding ${YOUR_PROJECT_ID} \
    --member=serviceAccount:XXXX@cloudbuild.gserviceaccount.com \
    --role=roles/run.admin

gcloud projects add-iam-policy-binding ${YOUR_PROJECT_ID} \
    --member=serviceAccount:XXXX@cloudbuild.gserviceaccount.com \
    --role=roles/iam.serviceAccountUser

Replace ${YOUR_PROJECT_ID} and XXXX by your actual value

roles/run.admin: To allow the Cloud Build service account to perform creation and modification of Cloud Run revisions.

roles/iam.serviceAccountUser: To allow the Cloud Build service account to use our specific Cloud Run service account created in the previous article to ensure the Principle of least privileges.

Or, if you follow this, you can also manually enable the Cloud Run Admin and Service Account User roles.

Adding new steps to deploy to Cloud Run

To make the most of Cloud Build, let's update the gcpcloudrunback/gcp-cloudrun-back.yaml description file to use some substitutions variables:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: gcp-cloudrun-back
  labels:
    cloud.googleapis.com/location: europe-west1
  annotations:
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/maxScale: '${SCALING_INSTANCE_COUNT}'
    spec:
      serviceAccountName: gcp-cloudrun-back
      containerConcurrency: 80
      timeoutSeconds: 300
      containers:
        - image: gcr.io/${PROJECT_ID}/gcp-cloudrun-back:${IMAGE_VERSION}
          resources:
            limits:
              cpu: 1000m
              memory: 256Mi
  traffic:
    - percent: 100
      latestRevision: true

From the previous article, we just replaces some value with placeholders. Please do not modify them in the file, we will Cloud Build and envsubst, a linux tool, to deploy the revision with correct values.

Now we can add new steps to the cloudbuild.yaml file that pushes early in the build the image and executes the Cloud Run deployment commands. Add those steps after the step dockerize-project.

- id: 'push-to-cloud-registry'
  name: gcr.io/cloud-builders/docker
  args: ['push', 'gcr.io/$PROJECT_ID/gcp-cloudrun-back:$SHORT_SHA']

- id: 'deploy-cloud-run'
  name: gcr.io/cloud-builders/gcloud
  dir: gcpcloudrunback
  entrypoint: bash
  args:
    - '-c'
    - |
      apt-get update
      apt-get install -qq -y gettext
      export PROJECT_ID=$PROJECT_ID
      export IMAGE_VERSION=$SHORT_SHA
      export SCALING_INSTANCE_COUNT=${_SCALING_INSTANCE_COUNT}
      envsubst < gcp-cloudrun-back.yaml > gcp-cloudrun-back_with_env.yaml
      gcloud beta run services replace gcp-cloudrun-back_with_env.yaml \
        --platform=managed --region=europe-west1
      gcloud run services add-iam-policy-binding gcp-cloudrun-back \
        --platform=managed --region=europe-west1 \
        --member="allUsers" --role="roles/run.invoker"

push-to-cloud-registry pushes the image early in the build. Cloud Run needs the image to be accessible in Container Registry to work. If we rely only on the images at the end of the pipeline, Cloud Run will not be able to push the image because the image will not be pushed in Container Registry yet.

envsubst is a tool replacing ${ENV_VAR} statements with the actual value from your environment in the target file. Very handy !

${_SCALING_INSTANCE_COUNT} is a substitution variable we will define in a Cloud Build Trigger.

As you can see, we reused the gcloud beta run commands we executed in the previous article. Which is why I insist: start slow with manual command and once you are comfortable, improve gradually and introduce new concepts, like automation script.

To execute multiple commands in a single step, you can change the entrypoint to bash and use the -c option.

Execute the deployment command again, and don't forget to add the new substitution variable:

gcloud builds submit . --substitutions SHORT_SHA=local,_SCALING_INSTANCE_COUNT=3

Check if the deployment is successful:

gcloud run revisions list \
  --service=gcp-cloudrun-back \
  --platform=managed \
  --region=europe-west1

   REVISION                 ACTIVE  SERVICE            DEPLOYED                 DEPLOYED BY
✔  gcp-cloudrun-back-n8tcg  yes     gcp-cloudrun-back  2020-11-21 15:12:10 UTC  957758254747@cloudbuild.gserviceaccount.com
✔  gcp-cloudrun-back-jrr7l          gcp-cloudrun-back  2020-11-17 18:18:58 UTC  thibault.ruaro@zenika.com
✔  gcp-cloudrun-back-qfv4q          gcp-cloudrun-back  2020-11-16 20:09:37 UTC  thibault.ruaro@zenika.com

Automating the build with a Cloud Build trigger

Pushing your code into Cloud Source Repositories

Cloud Source Repositories is a Google solution that host a Git server, like Github, to store your code on a remote server. Having your code on Cloud Source Repositories enables some features like :

Live application profiling
Deploying with Cloud Build
Code search
And even more

I won't comment much in this article, you basically have to follow the Google documentation to get started.

If you want to mirror your Github repository, follow this link
If you want to use Cloud Source Repositories as your remote git directory, follow this link

In my opinion, I like having my code open source on Github, so I prefer mirroring my repository. But I leave that choice to you.

Create the Cloud Build trigger

Execute the command to create a trigger on your synchronized cloud-source-repositories:

gcloud beta builds triggers create cloud-source-repositories \
    --name=gcpapplication-trigger \
    --repo=${REPO_NAME} \
    --branch-pattern=".*" \
    --build-config=cloudbuild.yaml \
    --substitutions _SCALING_INSTANCE_COUNT=3

Created [https://cloudbuild.googleapis.com/v1/projects/...].
NAME     CREATE_TIME                STATUS
trigger  2020-11-20T08:26:07+00:00

Hint: To find your ${REPO_NAME}, you can execute the command gcloud source repos list.

branch-pattern: Let's say that every branch will trigger a build. In real life scenario, you could have a trigger for master, and a trigger for the development branches.

We add a substitution variable _SCALING_INSTANCE_COUNT to dynamically modify the scalability of our Cloud Run service. Every user substitution variable must start with _.

For our Cloud Build deployment file, Cloud Build Trigger provides predefined substitutions variables, like PROJECT_ID or SHORT_SHA.

You could also directly connect your trigger to Github, but I didn't try it. Here is the documentation of you want to try.

Trigger the build with a code modification

Modify the class gcpcloudrunback/src/main/java/dev/truaro/blog/gcpcloudrunback/HelloWorldController.java:

@RestController
public class HelloWorldController {
    @GetMapping("/")
    public String helloWorld() {
        return "Hello World. I am automatically deployed";
    }
}

Commit and push your modification:

git add .
git commit -am "Triggering a build"
git push

If everything is properly configured, after several minutes, you should see a new revision for the Cloud Run service:

gcloud run revisions list \
  --service=gcp-cloudrun-back \
  --platform=managed \
  --region=europe-west1

   REVISION                 ACTIVE  SERVICE            DEPLOYED                 DEPLOYED BY
✔  gcp-cloudrun-back-62jvq  yes     gcp-cloudrun-back  2020-11-21 16:14:18 UTC  957758254747@cloudbuild.gserviceaccount.com
✔  gcp-cloudrun-back-n8tcg          gcp-cloudrun-back  2020-11-21 15:12:10 UTC  957758254747@cloudbuild.gserviceaccount.com
✔  gcp-cloudrun-back-jrr7l          gcp-cloudrun-back  2020-11-17 18:18:58 UTC  thibault.ruaro@zenika.com
✔  gcp-cloudrun-back-qfv4q          gcp-cloudrun-back  2020-11-16 20:09:37 UTC  thibault.ruaro@zenika.com

Final check, request the service (change this link with the one corresponding to the your Cloud Run service):

curl https://gcp-cloudrun-back-a75acdipmq-ew.a.run.app/

Hello World. I am automatically deployed

Summary

Congratulations, you created an entire Continuous Deployment pipeline:

Respecting Google best practices in terms of security (Service Account specific to your service) and development (PORT environment for your container)
Using mostly gcloud to increase your productivity and favor re-usability
Using Source Repositories to host or mirror your Github project
Using Cloud Build to define the CD pipeline
Using Cloud Build Triggers to activate the CD pipeline on any branch pushed to your repository

My opinion about Cloud Build

I have to admit, I had some fun doing this. But it is not always easy to use, as you have to scroll all over the Google documentation to move on properly (configuring the service account and setting the proper roles took me a while).

If you looked as the Cloud Build platform you could see it is not yet very user-friendly. This will strike you when dealing with parallel steps, you won't have a nice output to know what steps are sequential and what steps are parallel. Comparing to its current opponents on the market, like CircleCi or TravisCi, Cloud Build has a long way to go.
The fact that only steps can be declared does not favor re-usability when creating your pipeline and obfuscate your step intent. Indeed, when dealing with multiples stages and parallel execution, I find my yaml file less and less clear, as I have to add comments in order to keep a clear view of my steps purposes. I think adding a notion of pipeline, in which you easily configure your steps execution order can favor readability.

To go further with Cloud Build

You might have realized that Cloud Build does not keep your Docker image in a cache. Which means for each build, you end up downloading your maven repositories. To go further, you could:

Extract the project compilation from the multi-stage Dockerfile and build your projects in a Cloud Build step. This way, you could download and upload cached maven dependencies easily in a Cloud Storage bucket, and reduce your build time. (I won't even mention storage fees, as your might be string no more than 1Gb...).
Use what is called Kaniko cache, where every step of your Dockerfile is cached. This also reduce your build time, but incurs in higher storage fees, as Kaniko stores every Dockerfile steps in a Cloud Storage Bucket.
Check this link for a full list of possible optimizations

I will try to provide short articles for those optimizations later.

What's next

Define application security based on Firebase token
Developing a Frontend application to communicate with the Cloud Run service

Resources

Deploying your Spring Boot application in Cloud Run

RUARO Thibault — Tue, 08 Dec 2020 13:23:53 +0000

Introduction

Nowadays, it is possible for anyone to start an application using the latest Google Cloud Technologies to deploy an entire application. Modern web application requires most of the time splitting the front, what users see, and the back, what handles user requests.

In this series of articles, we will see how to deploy step by step a complete application. We will progressively cover topics like:

Hosting docker container on Cloud Run. Very useful when you have a low budget and enterprise needs.
Continuous deployment. Using Cloud builds to trigger a build and deploying your last version in your environment.
Configuring application security of a Spring based application with Firebase Identity. How to handle user authentication using JWT.
Hosting a Vue application in Firebase. Enjoy Firebase CDN and deploy your SPA to target an international audience easily.

Prerequisites

A Github Account

If you don't have it, I highly recommend you to create one, right now. I'll be using a public repository hosted on my account. My examples will use my repository in the command, but you will need yours when we will communicate with Cloud Repository. Click here to create an account on Github

Also, make sure Git is installed on your machine, and you can execute commands like git clone...

A Google Cloud Platform Account

The examples will deploy your application in your GCP environment. To do so, you need your own GCP account.

If you create the account, you will get $300 (270€) credit to use their infrastructure during a year. Please note you will have to use a credit card to create the account on Google. Click here to sign up on GCP

If you already have an account, please note things we do together will incur very small fees on your account. If you follow all articles rigorously, you might have no more than 1€ on your billing account at the end of the month.

Make sure you also create a first project that will contain the resources created in the articles.

Install the gcloud CLI

Even if you could use the Cloud Shell, I recommend you using the gcloud CLI on your machine. Trust me, it is really handy. To install the CLI, click here
Check the CLI is installed on your machine, by running gcloud version in your shell.

Then, execute the following command, to make sure you are pointing to the correct project

gcloud config set core/project ${PROJECT_ID}

Docker installed locally

Docker is not 100% mandatory, but personally I like testing locally if my development or Dockerfile are correct. It shortens the feedback loop, which gives me more flexibility to adapt when things don't work out.

Therefore, I suggest you to install Docker locally. Here are the resources to do so

Building the Spring application

You can now start building the first application. We will create a Hello world application, that exposes an endpoint.
The application can evolve later, but let's keep it simple and build it step by step. Just like software development should be done gradually, deploying your application with short iterations shortens the feedback loop. Detect bugs as soon as they appear to reduce the time needed to fix it.

Create the application backend

I invite you to create a skeleton using the Spring Initializer website. Here are the information I use:

Maven project
Java
Spring Boot version: 2.4.0
Group: dev.truaro.blog
Artifact: gcpcloudrunback
Name: GCP Cloud Run Backend
Description: My awesome back office fully managed by Cloud Run
Package name: dev.truaro.blog.gcpcloudrunback
Dependencies: Spring Web

This generates a zip file you can unzip. Having in mind what comes after this article, I recommend you to have the following folder structure:

* gcpapplication
|--- gcpcloudrunback <- unzipped folder
|--- gcpfirebasefront <- will come in another article

Please note for the rest of this article, the root folder is gcpapplication/gcpcloudrunback

Let's review the important part together:

In /pom.xml, make sure you have a dependency to spring-boot-starter-web and the plugin spring-boot-maven-plugin. This will activate Spring Boot's autoconfiguration to embed a Tomcat, and enable the Fat JAR generation.

...
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>
...
<build>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
        </plugin>
    </plugins>
</build>

In src/main/java/dev/truaro/blog/gcpcloudrunback/GcpCloudRunBackendApplication.java

@SpringBootApplication
public class GcpCloudRunBackendApplication {

    public static void main(String[] args) {
        SpringApplication.run(GcpCloudRunBackendApplication.class, args);
    }
}

Classic @SpringBootApplication class to start Spring and the Application Context.

Add your first controller

Let's add a simple controller that says Hello World on a GET request at /.

Create a file src/main/java/dev/truaro/blog/gcpcloudrunback/HelloWorldController.java

@RestController
public class HelloWorldController {

    @GetMapping("/")
    public String helloWorld() {
        return "Hello World";
    }

}

Briefly, this class sends a 200 HTTP Response containing the body Hello World in plain text:

@RestController -> the class is returning only data to the clients. This annotation bypasses the view resolver of Spring MVC.
@GetMapping -> Listen a GET request on the endpoint /.

Configure the server port

A recommendation of Cloud Run is to enable your application to listen the port provided by the PORT environment variable (for more information, check this link).

To do so with Spring, just a property to the application.properties file:

server.port=${PORT:8080}

If you want to set a property based on an environment variable with a default, use this: ${MY_ENV_VARIABLE:my default value}. Here, we get the PORT from the environment, or we fall back to 8080.

When developing an API, a common practice is to prefix all URLs with /api. With Spring, add a new property in application.properties.

server.servlet.context-path=/api

Request the server to see if it works

Make sure your controller can handle requests with a provided PORT by executing:

./mvnw install
PORT=8088 java -jar target/gcpcloudrunback-0.0.1-SNAPSHOT.jar

Go check the URL http://localhost:8088/api, and you should see Hello World displayed.

Overview

This step wasn't much, but at least you have the basis to go on when we will deploy this resource into GCP using Cloud Run.

Deploying the application into Cloud Run

Before talking about Continuous Deployment, let's first deploy our application manually on Cloud Run.

Quick words on Cloud Run

Cloud Run "Fully managed" is a service provided by GCP that allows you to run a container (Docker for instance) on the Google infrastructure. It has many advantages:

The cost is very attractive. Indeed, you pay only for the CPU allocated, and the CPU is allocated only when your container receives an HTTP request. In other words, you only pay when your container is being used.
You run a container, which makes you independent of the runtime environment provided by Google in a case of App engine Standard for instance. Besides, it is easy for you to test your container locally.
As a container, you can easily host your application elsewhere, in another provider for instance.

See the resources part for full resources URL on Cloud Run.

Containerize the application

Let's add this Dockerfile at the root of our application. We will use a multistage build, as it is an even more portable solution.

FROM maven:3.6.3-openjdk-11-slim as builder

WORKDIR /app
COPY pom.xml .
# Use this optimization to cache the local dependencies. Works as long as the POM doesn't change
RUN mvn dependency:go-offline

COPY src/ /app/src/
RUN mvn package

# Use AdoptOpenJDK for base image.
FROM adoptopenjdk/openjdk11:jre-11.0.8_10-alpine

# Copy the jar to the production image from the builder stage.
COPY --from=builder /app/target/*.jar /app.jar

# Run the web service on container startup.
CMD ["java", "-jar", "/app.jar"]

Try building the image locally and then run it to make sure it works as expected

docker build -t gcr.io/truaro-resources/gcp-cloudrun-back:latest .
docker run -d -p 8080:8080 gcr.io/truaro-resources/gcp-cloudrun-back:latest
> 6b7fd5ca6136af33589c100d6d45884c304cdaf2299b9f1416a33dc607db08e2
curl http://localhost:8080/
> Hello World
docker stop 6b7fd5ca6136af33589c100d6d45884c304cdaf2299b9f1416a33dc607db08e2

Then, we need to push it to our repository. Run this command:

# Connect docker to google registry. This put your credentials for Cloud Registry into your Docker configuration to authenticate on GCP
gcloud auth configure-docker
# Enable the repository API for your project
gcloud services enable containerregistry.googleapis.com
# Push the image to the google registry
docker push gcr.io/truaro-resources/gcp-cloudrun-back:latest

Create the Cloud Run service description file

If you are familiar with kubernetes you might have seen already the kubernetes description file. The process is similar for Cloud Run. Let's create a /gcp-cloudrun-back.yaml description file for our Cloud Run service, and go through it step by step.

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: gcp-cloudrun-back
  labels:
    cloud.googleapis.com/location: europe-west1
  annotations:
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/maxScale: '3'
    spec:
      serviceAccountName: gcp-cloudrun-back
      containerConcurrency: 80
      timeoutSeconds: 300
      containers:
      - image: gcr.io/${PROJECT_ID}/gcp-cloudrun-back:latest
        resources:
          limits:
            cpu: 1000m
            memory: 256Mi
  traffic:
    - percent: 100
      latestRevision: true

Please update the ${PROJECT_ID} with your own project ID

Let's explain each important part.

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: gcp-cloudrun-back
  labels:
    cloud.googleapis.com/location: europe-west1

metadata.name: the name of the service being deployed in Cloud Run. You can then use this name to get your Cloud Run service.

metadata.labels.cloud.googleapis.com/location: The region in which you want to deploy your application. I chose europe/west1, but you can choose another one if you want to.

spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/maxScale: '3'

Here we define the maximum number of instances Cloud Run is allowed to generate if your service is handling lots of requests. The limit we set is 3, making sure you won't get a nice surprise at the end of month on your GCP invoice.

  spec:
    serviceAccountName: gcp-cloudrun-back
    containerConcurrency: 80
    timeoutSeconds: 300

serviceAccountName: It is a good practice to use specific service account in order to respect more easily the Principle of least privilege. Gives this service account only access to what it is allowed.

containerConcurrency: The number of request to handle on a single instance before scaling up. 80 is the default value.

timeoutSeconds: The time within a response must be returned by your service. Failure to do so will result in a 504 error sent to the client.

    containers:
      - image: gcr.io/${PROJECT_ID}/gcp-cloudrun-back:latest

image: The image name the container will execute. As you guessed it, the image needs to be accessible by Cloud Run. We will see later how to add the image to Container registry.

    resources:
          limits:
            cpu: 1000m
            memory: 256Mi

cpu: We allocate the equivalence of 1 CPU to our service. Read more here.

memory: We allocate 256Mi to the container. Please consider this carefully, as your container can run out of memory on production. Read more here.

  traffic:
    - percent: 100
      latestRevision: true

At each revision, the new one takes 100% of the incoming traffic.

Deploy to Cloud Run

Now we are all setup, let's deploy our first revision, and make it public.

Enable the Cloud Run API.

gcloud services enable run.googleapis.com

Create a service account for the Cloud Run service. This ensures the respect of the Principle of least privilege.

gcloud iam service-accounts create gcp-cloudrun-back \
    --description="Service account that executes the gcp-cloudrun-back application" \
    --display-name="GCP Cloudrun Back service account"

Deploy on Cloud Run (it might take some minutes).

gcloud beta run services replace gcp-cloudrun-back.yaml \
  --platform=managed \
  --region=europe-west1

Applying new configuration to Cloud Run service [gcp-cloudrun-back] in project [truaro-resources] region [europe-west1]
New configuration has been applied to service [gcp-cloudrun-back].

URL: https://gcp-cloudrun-back-a75acdipmq-ew.a.run.app

Allow public access to invoke your service.

gcloud run services add-iam-policy-binding gcp-cloudrun-back \
  --platform=managed \
  --region=europe-west1 \
  --member="allUsers" \
  --role="roles/run.invoker"

Updated IAM policy for service [gcp-cloudrun-back]

Check if the service is responding (the first request could be a bit long because of the startup time).

curl https://gcp-cloudrun-back-a75acdipmq-ew.a.run.app/api/

Hello World

Check your container logs (Follow this). Here are mine:

2020-11-16 21:14:01.573 CET . ____ _ __ _ _
2020-11-16 21:14:01.573 CET /\\ / ___'_ __ _ _(_)_ __ __ _ \ \ \ \
2020-11-16 21:14:01.573 CET( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
2020-11-16 21:14:01.573 CET \\/ ___)| |_)| | | | | || (_| | ) ) ) )
2020-11-16 21:14:01.573 CET ' |____| .__|_| |_|_| |_\__, | / / / /
2020-11-16 21:14:01.573 CET =========|_|==============|___/=/_/_/_/
2020-11-16 21:14:01.574 CET :: Spring Boot :: (v2.4.0)
2020-11-16 21:14:01.574 CET
2020-11-16 21:14:01.856 CET2020-11-16 20:14:01.853 INFO 1 --- [ main] d.t.b.g.GcpSkeletonApplication : Starting GcpSkeletonApplication v0.0.1-SNAPSHOT using Java 11.0.8 on localhost with PID 1 (/app.jar started by root in /)
2020-11-16 21:14:01.857 CET2020-11-16 20:14:01.857 INFO 1 --- [ main] d.t.b.g.GcpSkeletonApplication : No active profile set, falling back to default profiles: default
2020-11-16 21:14:05.265 CET2020-11-16 20:14:05.265 INFO 1 --- [ main] o.s.b.w.embedded.tomcat.TomcatWebServer : Tomcat initialized with port(s): 8080 (http)
2020-11-16 21:14:05.284 CET2020-11-16 20:14:05.284 INFO 1 --- [ main] o.apache.catalina.core.StandardService : Starting service [Tomcat]
2020-11-16 21:14:05.284 CET2020-11-16 20:14:05.284 INFO 1 --- [ main] org.apache.catalina.core.StandardEngine : Starting Servlet engine: [Apache Tomcat/9.0.39]
2020-11-16 21:14:05.473 CET2020-11-16 20:14:05.473 INFO 1 --- [ main] o.a.c.c.C.[Tomcat].[localhost].[/] : Initializing Spring embedded WebApplicationContext
2020-11-16 21:14:05.473 CET2020-11-16 20:14:05.473 INFO 1 --- [ main] w.s.c.ServletWebServerApplicationContext : Root WebApplicationContext: initialization completed in 3394 ms
2020-11-16 21:14:06.778 CET2020-11-16 20:14:06.777 INFO 1 --- [ main] o.s.s.concurrent.ThreadPoolTaskExecutor : Initializing ExecutorService 'applicationTaskExecutor'
2020-11-16 21:14:07.391 CET2020-11-16 20:14:07.390 INFO 1 --- [ main] d.t.b.g.GcpSkeletonApplication : Started GcpSkeletonApplication in 7.221 seconds (JVM running for 8.938)
2020-11-16 21:14:07.653 CET2020-11-16 20:14:07.652 INFO 1 --- [nio-8080-exec-9] o.a.c.c.C.[Tomcat].[localhost].[/] : Initializing Spring DispatcherServlet 'dispatcherServlet'
2020-11-16 21:14:07.653 CET2020-11-16 20:14:07.652 INFO 1 --- [nio-8080-exec-9] o.s.web.servlet.DispatcherServlet : Initializing Servlet 'dispatcherServlet'
2020-11-16 21:14:07.654 CET2020-11-16 20:14:07.654 INFO 1 --- [nio-8080-exec-9] o.s.web.servlet.DispatcherServlet : Completed initialization in 0 ms

As you could see, my application took 7.221 seconds to start. In some infrastructure, this could be too long... I will leave the startup time optimization for another article.

Summary

In this article, we covered:

How to create a Spring Boot application with a single non-protected endpoint
How to activate Google APIs using gcloud services enable...
How to dockerize a Spring Boot application with a multi-stage build
How to push on Container registry
How to deploy an image on Cloud Run using a description file

What's next

In further articles, we will cover subjects like:

Configuring a Continuous deployment pipeline using Cloud Build
Securing your application using Firebase and Spring security
Developing a static VueJS App that requests our Cloud Run service
Deploying this application on Firebase Hosting
Optimizing the Boot time of your application to improve the scalability