Disaster Recovery
Background
Deployments normally take place from gitlab.com, however certain projects (e.g., Cells topology-service) are critical to the availability of gitlab.com so to decouple any reliance on gitlab.com, we support deploying workloads from ops.gitlab.net instead.
Architecture Diagram
Refer to the migration guide on how to set up service and deployment projects for ops deployments.
Components
Push mirror
The push mirror is configured with a personal access token (PAT) from the ops-gitlab-net bot account. This is to allow commits created by the push mirror to trigger downstream pipelines in the deployment project.
Refer to the migration guide for more information on configuring the push mirror.
Refer to this issue for more background context.
ops.gitlab.net-specific resources
In the provisioner, workloads configured to deploy from ops will have the following additional resources created:
- service account and iam member configured
- deployment project, vault and OIDC module
RUNWAY_DEPLOY_HOST_PROJECT_IDGitLab project variable on the canonical deployment project
In infra-mgmt, the following resources will be created:
RUNWAY_DEPLOY_HOST_PRATGitLab project variable on the canonical deployment project- GitLab project variable and project access token for the ops.gitlab.net deployment project
Terraform state backend
The GitLab-managed terraform state is stored in the deployment project on ops.gitlab.net to decouple deployment from gitlab.com.The canonical deployment project is still able to run execute dry-run jobs by using the RUNWAY_DEPLOY_HOST_PRAT and RUNWAY_DEPLOY_HOST_PROJECT_ID. This allows reconciler to execute gitlab-terraform commands configured to the remote backend on ops.gitlab.net.
Refer to this issue for more background context.