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 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 for 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.