Deployment

This page describes how to deploy the Metrics Configuration Generator (MCG). You can either run MCG locally for development and testing, or deploy it to a cloud environment for team access.

Get the source code

The source code for MCG is hosted on sdv.googlesource.com, which requires authentication as described in Access tooling repositories.

To access the source code, clone the MCG repository:

git clone https://sdv.googlesource.com/external/mcg-external

Run locally

To run MCG from its source directory for local development and testing, use Bazel. Bazel must be installed. You must enable in-memory caching by setting MCG_LOCALCACHE=true when running locally. This supports storage of Vehicle Signal Catalogs. To build and run the service locally, use the following commands from the source directory:

# Build and run on default port 8005
MCG_LOCALCACHE=true bazel run //:mcg

# Or, to change the port, use:
MCG_LOCALCACHE=true bazel run //:mcg -- --listen :9000

Deploy to Google Cloud

The MCG codebase includes Terraform and Google Cloud Build files to deploy MCG to Google Cloud as a Google Cloud Run service. The following sections guide you through the deployment process, which includes creating a variables file, deploying the infrastructure, building and deploying the application, and granting access and verifying deployment.

As Cloud Run is a serverless platform, it conserves resources by only running containers when processing requests, rather than keeping a server active 24/7. This means in-memory data is lost when container instances shut down between requests; therefore, Redis is required to provide persistent storage for catalog data across service invocations. This approach provides a scalable deployment suitable for team or production use.

Prerequisites

Before you begin deployment to Google Cloud, verify you have the following prerequisites:

File structure

Deploying to Google Cloud involves running Terraform commands from the infrastructure/ subdirectory and Cloud Build commands from the repository root. The main files and directories you interact with are:

repository-root/
├── cloudbuild.yaml
└── infrastructure/
    └── terraform.tfvars  <-- you create this file

Create a Terraform variables file

In the infrastructure/ directory, create a file named terraform.tfvars to provide values for variables defined in variables.tf and customize your deployment. You need to define values for project_id and region in this file; all other variables are optional. Add the following to terraform.tfvars:

project_id        = "<var label="Google Cloud project ID">your-gcp-project-id</var>"
region            = "<var label="Google Cloud region">your-gcp-region</var>" # For example, us-central1 or europe-west1

See variables.tf for all available variables and their default values. You can override any default values by setting them in terraform.tfvars.

Deploy the infrastructure

After you create terraform.tfvars, you can initialize and apply the Terraform configuration. This step provisions all required Google Cloud resources, including Artifact Registry, Redis, and Cloud Run. When complete, Terraform creates the Google Cloud Run service, which runs a placeholder container image. This step might take several minutes.

# Run from the infrastructure/ directory
terraform init
terraform apply

When prompted by terraform apply, review the plan and type yes to confirm.

Build and deploy the MCG application

After the infrastructure is provisioned, the next step is to build the MCG source code and deploy it to Google Cloud Run. This is done by submitting the source code to Google Cloud Build, which builds the Docker image, pushes it to Artifact Registry, and updates the Google Cloud Run service to use the new image.

Google Cloud Build uses the COMMIT_SHA substitution variable to tag the built image. You can use a version number (for example, v1.0.0), or the commit SHA of your repository. Tagging helps you distinguish between versions in Artifact Registry, manage deployments, and roll back to a previous version if needed.

Run the following gcloud command to trigger the build and deployment:

# Run from the repository root
#
# The command tags the image with the Git commit SHA.
# To tag with a version number, replace '$(git rev-parse --short HEAD)' with the version number.
gcloud builds submit . \
  --config=cloudbuild.yaml \
  --substitutions=COMMIT_SHA=$(git rev-parse --short HEAD)

This command performs the initial deployment of the application code. To deploy updates to the MCG source code, run this command again.

Grant access and verify deployment

To let users or service accounts call the MCG API, you must grant them the Cloud Run Invoker (roles/run.invoker) IAM role:

gcloud run services add-iam-policy-binding mcg-service \
  --member=<var label="member type, e.g. user or serviceAccount">MEMBER_TYPE</var>:<var label="email address of member">EMAIL_ADDRESS</var> \
  --role=roles/run.invoker \
  --region=<var label="Google Cloud region">your-gcp-region</var>

You can get the service URL by running the following command. The URL remains stable across deployments.

SERVICE_URL=$(gcloud run services describe mcg-service \
  --region <var label="Google Cloud region">your-gcp-region</var> \
  --format='value(status.url)')

After granting permissions, confirm that the service is running and accessible by calling its /health endpoint. Because Google Cloud Run services require authentication, you must include an authorization token from gcloud in the request header when calling the endpoint:

curl -H "Authorization: Bearer $(gcloud auth print-identity-token)" \
  $SERVICE_URL/health

If the service is running, this command returns OK, and you can now call any of the API endpoints as described in Call the API.