Cloud Run Implementation Guide

1
Table of Contents

Introduction 3
Configuration Details 3
Implementation Details 3
Service Name & Revision Name 5
Traffic Split 5
Deleting Active Server Group 5
Testing 6
Service Creation 7
Second Revision Creation 11
Spitting Traffic between the Revisions 13
Deleting a Revision 14
Deleting a Service 17
Service Creation thru Artifact 18
Sample Cloudrun Deployment Pipeline 22

2
Introduction

This document is intended to provide details of the implementation changes that are added
to the Spinnaker code base, in order to support Google Cloud Run as a cloud provider.

Configuration Details

The following configuration details need to be added in the clouddriver-local.yml file before
proceeding with the implementation.

cloudrun:
enabled: true
accounts:
- name: my-cloudrun-account
requiredGroupMembership: []
permissions: {}
project: my-orbit-project-71824
jsonPath: /home/ubuntu/.gcp/my-orbit-project-71824-ce91bf940a59.json

Implementation Details

The following Spinnaker microservices have been modified to support Cloud Run.

● Cloud driver
● Orca
● Halyard
● Deck

Cloud Run deployment includes Service and Revision components.The following table
represents the mapping between CloudRun and Spinnaker resources:

Spinnaker Resource Cloud Run Resource

Account GCP Project

Load Balancer Cloud Run Service

Server Group Cloud Run Revision

3
 Instance Cloud Run Container Instance

In Spinnaker, a user can create a Server Group from the CLUSTERS pane by clicking the
Create Server Group button. Similarly, a Load Balancer can be created from the LOAD
BALANCERS pane. But, as in Google App engine, the load balancer (Cloud Run Service)
cannot be created without a Cloud Run Revision. So, Create Server Group action leads to
the creation of Cloud Run Service and Revision.

A service yaml needs to be added in the Service Yaml text box that appears when the
Create Server Group button is clicked. When the Create button is clicked, a series of
actions take place resulting in the creation of Cloud Run Service and Revision resources in
the Google Cloud and display of the information related to these resources in the Spinnaker
UI.

After creating the server group, the load balancer gets displayed with service details and
options such as

● Edit Load Balancer (for splitting traffic)

● Delete Load Balancer (to delete a Service)

4
Service Name & Revision Name
The Service name & Revision names are managed by Spinnaker irrespective of their values
in the Service Yaml. This helps Spinnaker to manage the segregation of server groups and
clusters. So any other names given to the service and revision in the Service yaml will be
overridden by Spinnaker using the Account name, Stack and Detail field values.

Traffic Split
There is a section in the Service yaml for representing traffic split but as part of this
implementation we are ignoring the section because the user needs to know the existing
traffic routing in order to change it. And if a user doesn’t add the traffic section in the Service
yaml, a gcloud command will route 100% traffic to the newly created revision which is not
needed. Hence the better way is to preserve the existing traffic split until the user performs
an explicit split using Edit Load Balancer action to route some or total percentage of traffic
to the newly created Revision.

Deleting Active Server Group

A Revision cannot be deleted if it’s serving traffic. Hence the Destroy option is disabled for
those server groups having non-zero traffic percent.

5
Testing

Apart from the unit test cases, the following manual tests have been done in the
development environment.

● Service Creation
● Second Revision Creation
● Spitting Traffic between the Revisions
● Deleting a Revision
● Deleting a Service
● Service Creation thru Artifact

The setup used for testing is given below:

● Google Project: my-orbit-project-71824 (ID: 135005621049)

● Service Account:
spinnaker-cloudrun-account@my-orbit-project-71824.iam.gserviceaccount.com
● Image: us-docker.pkg.dev/cloudrun/container/hello

The Service Account requires permissions to deploy the CloudRun Services. A Service
Account credentials key(a json file) is added in Spinnaker in the form of cloudrun account as
given below:

cloudrun:
enabled: true
accounts:
- name: my-cloudrun-account
requiredGroupMembership: []
permissions: {}
project: my-orbit-project-71824
jsonPath:
/home/ubuntu/.gcp/my-orbit-project-71824-ce91bf940a59.json

6
Service Creation
● Create an application in Spinnaker - cloudrunsvc.
● Enter the values in the Stack and Detail fields.

● Create a server group using the following service yaml:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: cloudrunsvc
namespace: '135005621049'
labels:
cloud.googleapis.com/location: us-central1
annotations:
run.googleapis.com/client-name: cloud-console
serving.knative.dev/creator:
spinnaker-cloudrun-account@my-orbit-project-71824.iam.gserviceaccount.com
serving.knative.dev/lastModifier:
spinnaker-cloudrun-account@my-orbit-project-71824.iam.gserviceaccount.com
client.knative.dev/user-image:
us-docker.pkg.dev/cloudrun/container/hello
run.googleapis.com/ingress: all
run.googleapis.com/ingress-status: all
spec:

7
 template:
metadata:
name: cloudrunsvc-hkb-v001
annotations:
run.googleapis.com/client-name: cloud-console
autoscaling.knative.dev/minScale: '1'
autoscaling.knative.dev/maxScale: '3'
spec:
containerConcurrency: 80
timeoutSeconds: 200
serviceAccountName:
spinnaker-cloudrun-account@my-orbit-project-71824.iam.gserviceaccount.com
containers:
- image: us-docker.pkg.dev/cloudrun/container/hello
ports:
- name: http1
containerPort: 8080
resources:
limits:
cpu: 1000m
memory: 256Mi

● Verify that the operation is successful.

● Verify that the Service and Revision are created in the cloud.

8
9
● Verify if the load balancer and server group are created.

10
Second Revision Creation

1. Create a server group using the following service yaml:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: cloudrunsvc
namespace: '135005621049'
labels:
cloud.googleapis.com/location: us-central1
annotations:
run.googleapis.com/client-name: cloud-console
serving.knative.dev/creator:
spinnaker-cloudrun-account@my-orbit-project-71824.iam.gserviceaccount.com
serving.knative.dev/lastModifier:
spinnaker-cloudrun-account@my-orbit-project-71824.iam.gserviceaccount.com
client.knative.dev/user-image:
us-docker.pkg.dev/cloudrun/container/hello
run.googleapis.com/ingress: all
run.googleapis.com/ingress-status: all
spec:
template:
metadata:
name: cloudrunsvc-hkb-v002
annotations:
run.googleapis.com/client-name: cloud-console
autoscaling.knative.dev/minScale: '1'
autoscaling.knative.dev/maxScale: '3'
spec:
containerConcurrency: 80
timeoutSeconds: 200
serviceAccountName:
spinnaker-cloudrun-account@my-orbit-project-71824.iam.gserviceaccount.com
containers:
- image: us-docker.pkg.dev/cloudrun/container/hello
ports:
- name: http1
containerPort: 8080
resources:
limits:
cpu: 1000m
memory: 256Mi

11
2. Verify if the second revision is created.

3. Verify if the changes are reflected in Spinnaker.

12
Spitting Traffic between the Revisions

1. Choose Edit Load Balancer from the Load Balancer Actions.

2. Allocate traffic between the two revisions equally and click Update.

3. Verify if the split happened properly in the cloud console.

13
 4. Verify if the Load Balancers details are updated with the latest traffic split.

Deleting a Revision
1. Select a Server Group having zero traffic and click Destroy. Before this step, another
version was created and traffic was split between the latest two revisions(v002 &
v001).

14
2. Verify that the deletion is successful.

15
3. Also, verify that the Revision is deleted from the Cloud.

16
Deleting a Service
1. Select the service that you need to delete and click Delete Load Balancer.

2. A popup appears asking for confirmation.

3. Once confirming the deletion, verify that the delete operation is successful in
Spinnaker.

17
 4. Also, verify if the Service is deleted from the cloud.

Service Creation thru Artifact

1. Create an application in Spinnaker - googletestcase001.
2. Create a pipeline named test1.
3. Enter the artifact details in the configuration section, as shown in the screenshots
below:

18
19
4. Add the Deploy(Cloudrun) stage to the existing pipeline and enter the values in the
Stack and Detail fields as shown in the screenshot below.

5. Save the pipeline and trigger it.

6. Ensure that the deploy(Cloudrun) stage is run successfully and all the tasks are
completed.

20
7. Verify that the service(googletestcase001-s1-d1) is created successfully.

21
To know more about artifacts, refer to the below spinnaker documentation.

1. https://spinnaker.io/docs/reference/ref-artifacts/types/

2. https://spinnaker.io/docs/setup/other_config/artifacts/

Sample Cloudrun Deployment Pipeline

A sample Cloudrun deployment pipeline is given below. It includes the following

stages:

● Trigger on a GitHub webhook - github webhook is triggered by a push to the

forked repository.
● Deploy - the updated app is deployed in Cloudrun.
● Edit Load Balancer - the traffic is split between the two server groups.
● Manual Judgement - verification is done to know if all the traffic can be
moved to the new server group. This stage could be a stand-in for integration
tests or canary analysis.
● Enable - 100% of traffic is sent to the new server group.

22
 ● Wait - before destroying the old server group 2 minutes of wait time is
followed, to be sure everything is OK. In a real deployment pipeline, it’s likely
that this wait time would be longer (an hour or more).
● Destroy - the old server group is destroyed.

To know more about deployment pipelines, refer to the below spinnaker

documentation.

https://spinnaker.io/docs/guides/tutorials/codelabs/appengine-source-to-prod/

23