Investigation into dogfooding GitLab application features for running the GitLab docker registry (https://github.com/docker/distribution) in a GKE cluster

This issue is to explore using Auto-devops and other application features for deploying the registry service for GitLab.com.

Currently the registry service runs on a fleet of VMs. Soon this service will run in a GKE cluster. We want to dogfood auto-devops and other GitLab application features that connects GitLab to Kubernetes and allows you to monitor and deploy an application.

Summary

  • : Currently Dogfooding feature
  • : Feature gaps in the GitLab Application prevent us from using the feature
  • : Feature gaps in the GitLab application prevent us from using some of the feature
  • N/A : Not applicable to Dogfooding (feature not used outside of GitLab)

See the Kubernetes Dogfooding Board for all related dogfooding issues

Status Feature Notes
GitLab Code/MRs/Issues All code/issues/MRs for Kubernetes is sourced on GitLab.com
Repository mirroring Code is mirrored to ops.gitlab.net
CI Pipelines All changes are applied via CI, a private runner is used for deployments on https://ops.GitLab.net which ensures we can deploy when GitLab.com is unavailable
Packages Registry A common registry image is used for all projects that deploy to Kubernetes clusters
Registry Helm Chart The CI pipeline is using the GitLab Registry Helm Chart
AutoDevops: Environments Environments are used for deployments of the Cluster in CI
AutoDevops: Container Scanning In the Kubernetes configuration CI pipeline container scanning is run on the registry image
AutoDevops: Kubernetes An existing Kubernetes cluster is attached at the project level. It was not possible to create the cluster directly from GitLab https://gitlab.com/gitlab-org/gitlab-ce/issues/65987 . This integration would be cleaner if we could customize an attached Kubernetes at the group level https://gitlab.com/gitlab-org/gitlab-ce/issues/59638 . Because of this we are required to attach the same cluster to every project in the group.
AutoDevops: AutoDeploy Auto deployments are configured through CI but we are not currently using the shell functions provided by GitLab . These are not being used so we have more control over the helm upgrade and also so we do not depend on the availability of the GitLab.com registry for deploying to GitLab.com registry. https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues/7527 tracks being able to dogfood these wrappers.
AutoDevops: DeployBoards We currently have Deploy Boards connected to the Kubernetes cluster and can see them for all of our environments
AutoDevops: Metrics While it was possible to connect our Prometheus server to GitLab, the built in metrics are not sufficient for what we currently require for monitoring and managing alerts. The following issues track feature gaps that would need to be addressed before adopting this feature https://gitlab.com/gitlab-org/gitlab-ce/issues/65979 https://gitlab.com/gitlab-org/gitlab-ce/issues/65981 https://gitlab.com/gitlab-org/gitlab-ce/issues/65982 https://gitlab.com/gitlab-org/gitlab-ce/issues/65983 https://gitlab.com/gitlab-org/gitlab-ce/issues/65984 https://gitlab.com/gitlab-org/gitlab-ce/issues/67036

Other Operation Features that not used

The following AutoDevops CI scanning jobs are mentioned here but are not applicable to the Registry service:

Status Feature Notes
N/A Ops Tracing There is no tracing for the Registry service as it does not currently implement Jaeger
N/A Ops Error Tracking There is no error tracking for the Registry service as it currently does not integrate with Sentry
N/A Ops Serverless There is no need for serverless feature as there is no integration or need for Knative
N/A Ops Feature Flags There are currently no need for feature flags in this project since development of the Registry is external and we are only using GitLab for deployments
N/A auto test checks using heroku buildpacks, not applicable to the registry service.
N/A code quality checks using CodeClimate, not applicable because the registry service is developed outside of GitLab
N/A container_scanning checks for vulnerabilities in the docker container, not applicable because the registry service is developed outside of GitLab
N/A dependency_scanning check for dependency vulnerability, not applicable because the registry service is developed outside of GitLab
N/A license_management scans for licenses, not applicable because the registry service is developed outside of GitLab

Dogfooding Issues

Issue Team Action
https://gitlab.com/gitlab-org/gitlab-ce/issues/65979 devopsmonitor Investigate building in GitLab
https://gitlab.com/gitlab-org/gitlab-ce/issues/65981 devopsmonitor Investigate building in GitLab
https://gitlab.com/gitlab-org/gitlab-ce/issues/65982 devopsmonitor Investigate building in GitLab
https://gitlab.com/gitlab-org/gitlab-ce/issues/65983 devopsmonitor Investigate building in GitLab
https://gitlab.com/gitlab-org/gitlab-ce/issues/65984 devopsmonitor Investigate building in GitLab
https://gitlab.com/gitlab-org/gitlab-ce/issues/65987 devopsconfigure Investigate building in GitLab
https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues/7530 teamDelivery Investigate
https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues/7527 teamDelivery Actionable
https://gitlab.com/gitlab-org/gitlab-ce/issues/59638 devopsconfigure Actionable
Edited by 🤖 GitLab Bot 🤖