Create a new non-production environment
As noted in #187 (closed), having one staging environment is not going to be enough. This new environment could possibly share state with staging if it is easier to stand it up and save on cost. Alternatively, we can just have a single node installation with a similar data set to avoid having to stand up a full HA environment
Setup overview
- Environment label:
pre
- GCP Project:
gitlab-pre
- Monitoring: dedicated single prometheus / dashboards.gitlab.net
- Deployment with chatops:
/chatops run deploy <version> --pre
Infra
- Single prometheus server for monitoring
- Single bastion host for access
- Object storage buckets for registry, artifacts, etc.
- Single GitLab instance with all services running locally to start
- Configuration;
- Object storage buckets
- gitlab-pre-artifacts
- gitlab-pre-lfs-objects
- gitlab-pre-package-repo
- gitlab-pre-uploads
- gitlab-pre-registry
- Accounts: Google OAUTH only, restricted to
@gitlab.com
- Postgres: local, staging db import
- Redis: local
Deployment
Initially we will be deploying to the pre environment independently so it will not be added to any existing pipeline. Later we may decide to add the pre environment to the production pipeline.
Tasks
(S)mall/(M)edium/(L)arge
-
(M) Create the new terraform environment, gcp-project, gkms key for secrets -
[ ] (M) Update the database with staging data- waiting for approval -
(S) Create the new chef config -
(S) Create and configure the GitLab server, bastion hosts, and prometheus server in the new env -
(S) Create peering between the ops project and the pre GCP project for dashboards.gitlab.net -
(S) Create a single? dashboard on dashboards.gitlab.net for monitoring -
(S) Update chatops to support the --pre
option -
(S) Update .gitlab-ci.yml
for deployer so we can deploy to the new stage, deploy a new version to the environment
MRs
- Environment update in the handbook: gitlab-com/www-gitlab-com!19703 (merged)
Edited by John Jarvis