GVC (Global Virtual Cloud)

Overview

A Global Virtual Cloud (GVC) defines a set of cloud providers and their locations.

When creating a GVC you are in essence building an uber-cloud that is comprised of the specified locations. Workloads are deployed to the GVC which are then served from all the locations specified.

Each org can have multiple GVCs, each with its own unique set of locations.

A domain name can be assigned to a GVC. Callers can reach workloads using the assigned domain name.

Benefits

• GVCs enable your workload to be deployed with ease to multiple cloud providers and locations
  • You choose the provider (AWS, Azure, and GCP) and their different locations
  • Select locations that are close to your end-users
  • Select the locations that fulfill the requirements of your workloads
  • Ensure maximum availability if a cloud provider has an occasional outage
• You get granular controls to define the scaling characteristics of your workload

Domain Name

Each GVC can be set to use one of the fully qualified domain names that have been mapped to an org.

The selected domain name will be used by all workloads when serving their containers.

The default domain name cpln.app will be used if an org does not have any domains configured, or if you do not select a domain name.

Pull Secrets

Pull secrets are secrets that are assigned to a GVC and used by workloads when authentication is required when pulling an image from a private registry. Only the Docker, Amazon ECR, and GCP secret types are supported.

Multiple pull secrets can be assigned to a GVC. A workload's container will use the appropriate secret when pulling the image from a private registry. If there are multiple secrets, the container will cycle through each one.

If authentication fails, the deployment will not be updated and the image pull will have an exponential backoff retry starting at 10 seconds until 5 minutes (e.g., 10 seconds, 20 seconds, 40 seconds, etc.).

Reference

Visit the GVC reference page for additional details.