Here, you will implement the same functionality as the manual implementation but using a Cloud Function scheduled with Cloud Scheduler. This will allow you to automatically update the tags periodically without any manual intervention.
Cloud Functions
As mentioned earlier, Cloud Functions can only be written in certain programming languages. The code accompanying this book includes a Cloud Function written in Go. This effectively performs the same task as the gcloud CLI steps but uses the BigQuery and Cloud Storage client libraries for Go.
Don’t worry too much about the code if you are not familiar with Go, but there are some key points to note:
In the init block above, a BigQuery and Cloud Storage client is created. These are initialized once and then reused for each invocation of the function. This is good practice, as it reduces the time needed to respond to requests. At the end of the block, a function named updateTags is registered as the HTTP trigger. This is the entry point for the function and is called when the function is invoked:
The updateTags function in the code is handling an HTTP request. In response, it calls a function that retrieves the tags from BigQuery Stack Overflow dataset using the BiqQuery client. It then calls another function that writes the tags to Cloud Storage using the Cloud Storage client in a similar way to the gcloud CLI steps. Note that errors are handled by logging the error and returning an HTTP error response; success is handled by logging the success and returning an HTTP success response. This is important, as it is the HTTP response that is used by Cloud Functions to determine whether the function invocation was successful or not.
Configuration
Just like the bash script version, the configuration for the Cloud Function should be externalized. In this case, you don’t have any secrets like passwords, but you do have three arguments to pass as environment variables, shown in Table 5-1.
| Table 5-1. Environment variables Environment variable | Description |
| PROJECT_ID | The ID of the Google Cloud project |
| BUCKET_ID | The ID of the Cloud Storage bucket |
| OBJECT_NAME | Cloud Storage is an object store, so when files are uploaded to it, they are referred to as objects. |
You can provide these as a YAML file when you deploy the function. The code accompanying this book shows an example of the structure:
The main difference between this function and the bash script is that it writes the retrieved tags to an object in Cloud Storage directly rather than storing them to a file and then uploading the file.
The services Cloud Functions needs are not enabled by default, so you need to enable them for the project. As mentioned earlier, the Cloud Build service is used for building a container. The container is stored in Artifact Registry, Google Cloud’s container registry. The container is run using Google’s Cloud Run service. This means you need the following services enabled:
- cloudfunctions.googleapis.com—Cloud Functions
- cloudbuild.googleapis.com—Cloud Build
- artifactregistry.googleapis.com—Artifact Registry
- run.googleapis.com—Cloud Run
Uses the environment variables in the env.yaml file
Executing the command will take a few minutes as it works through building, deploying, and testing that the function is healthy. When it has completed, you will see a URI for the function that looks like this: https://$CLOUD_FUNCTION_NAME-something.a.run.app.
If you open this URI in a web browser, you will see a permission denied message. This is a good thing; it means an unauthenticated person cannot trigger the function.
You can also check that the function has been deployed using the command:
gcloud
functions
list
This should show a result similar to this, with the state showing active:
NAME STATE TRIGGER REGION ENVIRONMENT
tag-updater ACTIVE HTTP Trigger europe-west2 2nd gen
To check the logs for the function to see more details, use the following command:
This will give you more detailed logs, including the system logs when the function was deployed.