Before getting hands-on, make sure you have a gcloud CLI either on your local machine or in Cloud Shell, and ensure you are using the same Google Cloud project as in Chapter 5, using the command:
gcloud
config
get
project
You can set a PROJECT_ID environment variable again to make it easier to copy and paste commands:
export
PROJECT_ID
=
$(
gcloud
config
get-value
project
)
If you are not using the correct project, set it using this command:
gcloud
config
set
project
$PROJECT_ID
Deploy with Cloud Run
You can use the defaults of Cloud Run to deploy directly from the command line to ensure it works. This will create a container and put it into the Artifact Registry, a Google service for storing arifacts, like containers.
The service is using a Go application with no dependencies, so Cloud Run allows you to build directly from the source code alone.
Set an environment variable for the service name (e.g., skill-service):
export
SKILL_SERVICE_NAME
=[
SKILL_SERVICE_NAME
]
Following the 12-factor principle of storing configuration in the environment, you will use an environment variable file to pass the configuration to the service.
If you have created .env files, use this command and apply both the local and parent environment variables again:
set
-a
;
source
../.env
;
source
.env
;
set
+a
Create a file called .env.yaml from env.yaml.template. This command will substitute values from your environment variable, including those set in Chapter 5:
envsubst
<
env.yaml.template
>.env.yaml
Then run the following command to deploy the service to Cloud Run:
gcloud
run
deploy
$SKILL_SERVICE_NAME
–source
–env-vars-file
=
.env.yaml
\
–allow-unauthenticated
If you are asked to create an “Artifact Registry Docker repository to store built containers,” select yes. This is where the container will be stored.
You are deploying the service from the source code in the current directory and passing an environment variable file, as you did in Chapter 5 with Cloud Functions.
This command is a shortcut for two commands. The first command is:
gcloud
builds
submit
–pack
image
=[
IMAGE
]
This builds a container using a buildpack using Cloud Build. A buildpack is a concept that existed in both the Heroku and Cloud Foundry platforms. It automatically identifies the application’s language, installs the necessary dependencies, and packages it all up into a container. Cloud Run is using what is effectively version three of the buildpack concept, Cloud Native Buildpacks.
The buildpack to use is determined automatically; in this case, the presence of go.mod will be enough to determine that the Go Buildpack should be used and the main.go built. It then stores the container image in Google Artifact Registry, where [IMAGE] would be the name for the image. In the shortcut command, the image name is automatically generated.
If there were a Dockerfile in the current directory, it would use that to build the container in preference to the buildpack, meaning you could use a custom container.
This is one way of adding more flexibility if you need that customization, but the good thing about Cloud Run is that you don’t need to worry about how the container is built if you don’t want to.
The second command is:
gcloud
run
deploy
$SKILL_SERVICE_NAME
–image
[
IMAGE
]
This deploys the container to Cloud Run. If you run this command, you will be prompted to Allow unauthenticated invocations to [SERVICE-NAME]?. Select `Y for this for now, but we will come back to the significance of this later.
Securing
As in Chapter 5 with Cloud Functions, this Cloud Run service is currently using a default service account with broad permissions.
Cloud Run is also allowing unauthenticated invocations of the service. This may be OK for testing, but in a production environment, you would want to secure the service, and you will see how to do that in Chapter 11.
However, ultimately, the combination of risks means you have code that can be called by anyone on the internet using a service account with permissions that could do damage if code with security vulnerabilities was accidentally or maliciously deployed.
For safety, you can create a new service account with the minimum permissions required to run the service. In this case, that will be permission to read the object from Cloud Storage and nothing more. This is the principle of the least privilege which was not one of the original 12 factors, as those principles did not have much to say about security. However, security was emphasized when the 12 factors were revisited, and the principle of the least privilege is a good practice recommended by all cloud providers.