This section describes the infrastructural prerequisites and components required for deploying and integrating the Vionlabs Edge Processing environment on Google Cloud Platform (GCP). It consolidates requirements from both the Shared/Org Terraform stack and the Customer/Edge Terraform stack.
 

Projects and Environments

The solution is structured across two separate Google Cloud projects:

Shared/Organization Project
This project contains central resources that apply across all customer integrations. It provides the remote Terraform state storage, the custom IAM role used for Artifact Registry, and the corresponding IAM bindings that allow external service accounts to pull container images.
 

Customer/Edge Project
This project contains customer-specific resources. It includes the virtual machine (VM) used for edge processing, Cloud Storage buckets for input and output data, Pub/Sub topics and subscriptions for messaging, and the IAM bindings required for service accounts.

Two environments are supported, development and production, which are managed separately using Terraform workspaces and dedicated variable files (dev.tfvars and prod.tfvars).

Required GCP Services

In order for the Terraform configuration to apply successfully, the following Google Cloud services must be enabled in the respective projects:
 

• Identity and Access Management: iam.googleapis.com
• Artifact Registry: artifactregistry.googleapis.com
• Cloud Resource Manager: cloudresourcemanager.googleapis.com
• Service Usage API: serviceusage.googleapis.com
• Compute Engine: compute.googleapis.com
• Pub/Sub Messaging: pubsub.googleapis.com
• Cloud Storage: storage.googleapis.com

These services provide the foundation for identity management, container image distribution, virtual machine hosting, messaging, and storage.

Terraform Execution and State

• Terraform is the primary tool for managing infrastructure.
• Terraform Version: The code requires Terraform version 1.0 or higher.
• Google Provider: The supported range is version >= 4.45 and < 7.0.
• Remote State: Terraform state is stored in a Google Cloud Storage bucket. A specific prefix is defined to separate environments and modules within the bucket.
• Workspaces: Terraform enforces a check to ensure that the selected workspace (dev or prod) matches the env variable defined in the configuration, reducing the risk of accidental deployments.

Shared/Organization-Level Components

The Shared/Org project manages Artifact Registry access:
 

Custom IAM Role
A custom role is defined for Artifact Registry. In development, the role is created by Terraform (role_create = true). In production, the role must already exist and is only referenced (role_create = false). This ensures consistent permissions between environments.
 

IAM Bindings:
External VM service accounts from customer projects are granted this custom role. The effect is that customer edge VMs can pull container images from Artifact Registry but cannot push or modify them.

Inputs: The list of remote VM service accounts is passed in as a variable, and each of these accounts receives the appropriate IAM binding.

Customer/Edge Components

Storage (Cloud Storage Buckets)

Two buckets are created in the customer project:

• An input bucket for storing assets that will be processed.
• An output bucket for storing the results of processing, including any logs or generated artifacts.

The bucket names are automatically prefixed with the customer identifier to ensure uniqueness across environments.

Messaging (Pub/Sub)

Messaging between the Edge VM and backend services is handled via Pub/Sub.

Topics:

topic-batches: used by the VM to publish batch processing jobs.

topic-events: used by backend services to publish events.
 

Subscription:
A subscription is created on topic-events. The subscription is configured with an expiration policy of “never,” ensuring that it remains active indefinitely and does not expire automatically.

Compute VM

A single virtual machine is deployed in the customer project to perform edge processing:
 

• Machine Type: e2-standard-16, which provides 16 vCPUs and 64 GB of memory.
• Operating System: A Debian-family base image is used, obtained via the Google provider data source.
• Startup Script: The VM includes metadata that injects a startup script (vm-startup-script.cfg) rendered from Terraform templates. This script configures the VM at boot time.
• SSH Access: An SSH public key, provided as a variable, is added to the VM metadata to allow administrative access.
• Firewall Tag: The VM is tagged with internal-ssh, which can be referenced in firewall rules to control network access.

IAM Bindings

The Terraform configuration explicitly defines which service accounts receive which roles.
 

VM Service Account (VM-GSA)

• Granted the role of Publisher on the topic-batches Pub/Sub topic.
• Granted the role of Writer on the output bucket.
   

Cloud Run Service Account (Cloud Run GSA)

• Granted the role of Subscriber on the topic-events subscription.
• Granted the role of Publisher on the topic-events topic.
• Granted the role of Reader on the output bucket.

These bindings ensure that the VM can publish processing jobs and write results, while the backend Cloud Run service can consume events and access processed data.

Variables and Inputs

The Terraform code relies on several input variables, which must be provided at deployment time: