Crossplane as GitLab Managed App (Phase 1)
Problem to solve
This issue describes the phase 1 WIP to provide Crossplane as a managed service capable of provisioning Postgres in the Gitlab 12.5 release shipping 11/17. This work is being implemented by our partner InfraCloud. It is a subset of the deeper integration outlined in master Epic &1866 for provisioning and managing a broader range of services to be delivered across multiple GitLab releases. This issue provides context for GitLab reviewer.
Since this integration has dependencies on Crossplane v0.4.0, it’s important these dependencies are satisfied in that timeframe, so GitLab 12.5 can rely on a stable Crossplane release and not master. The only hard dependency is the Crossplane Helm chart accepting a value for infra stack enum: [aws, gcp, azure].
The Phase 1 work was originally outlined and discussed in the note &1866 (comment 216080986)
The target timeline is based on our understanding of the GitLab release schedule: 10/16 - Kickoff, open Merge Requests 10/25 - Initial alpha drop of ruby installation, helm install, and PostgreSQL config. 11/03 - Code Freeze and submit to GitLab, Upbound/Infracloud reviews 11/04 - 11/10 Bug fixes and reviewer feedback, GitLab reviewer roulette sign off 11/17 - All Merge Requests approved for GitLab 12.5 Release.
Enable a 3 step process to enable managed service provisioning from GitLab ADO pipelines as follows:
- Cluster Admin: Install Crossplane as GitLab-managed app with infra stack
- Cluster Admin: configure managed service provisioning on the Kubernetes target cluster
- App Project Team: Provision managed PostgreSQL via Auto DevOps Helm Chart with:
- postgres.enabled: true (exists today to install in-cluster Postgres via Helm)
- postgres.managed:true (adds default Crossplane managed PostgreSQL)
- postgres.managedClass: postgres-ha (optional - pick named class of service)
- Cluster Admin: Install Crossplane as a GitLab-managed app w/ infra Stack: GCP, AWS, Azure:
- Cluster Admin: configure managed service provisioning on the Kubernetes target cluster: Connect a cloud provider account to a shared infrastructure namespace. Create cloud-specific classes of service with best-practice configurations. Add portable classes of service for managed service provisioning using kubectl into each app project namespace Mark a subset as the default classes of service for a given claim kind in an app project namespace. See https://crossplane.io/docs/v0.3/services-guide.html for detailed configuration steps.
Note: in the future we can simplify 1st time setup via GitOps + group config repo, but this is not included the phase 1 scope of work.
- App project team updates GitLab ADO helm chart to use managed DBaaS and optional class-of service: Done!
An app project team can start using managed PostgreSQL from their GitLab ADO pipelines with just 1 or 2 lines of YAML in their existing app configuration.
Cluster Admin: One-time cluster setup
- Add GKE cluster to GitLab project via built-in GitLab functionality
- Install Helm as a GitLab managed app into GKE cluster
- Install Crossplane as a GitLab managed app into the GKE cluster w/ selected Infra Stack: GCP, AWS, Azure
- Manually configure Crossplane provider creds, settings, resource classes, and secure connectivity to cluster directly on target k8s cluster by following https://crossplane.io/docs/v0.3/services-guide.html.
Cluster Admin: Onboard app projects to the k8s cluster for CD w/ managed service provisioning
- On-board a GitLab app project into the k8s cluster resulting in a separate Kubernetes namespace (sandbox) on the k8s cluster (e.g. app-project1-dev, app-project1-staging, app-project1-prod).
- Populate each project namespace with the classes of service (portable resource classes) that should be made available to the app project for Crossplane self-service provisioning: e.g. postgres-standard, postgres-ha, ...
- Set default resource classes in each app project namespace by marking a class of service as
App Project: Provision managed PostgreSQL instance from a GitLab AutoDeployApp helm chart
- Set "postgres.managed=true" in the GitLab AutoDeployApp helm chart which would use the default class of service defined by the cluster admin when adding the portable resources classes to app project namespaces (app-project1-dev, app-project1-prod). The AutoDeployApp helm chart will then create a postgres-claim.yaml in an app project k8s namespace.
- (optional) Set postgres.managedClass="postgres-class-name" to pick from a specific named class-of-service from the classes of service made available by the Cluster Admin when configuring an app project k8s namespace.
Not in scope for phase 1: Use of GitLab our latest plans for the first iteration of cluster config is #32810 (closed) . This will cover group level clusters. https://gitlab.com/gitlab-org/gitlab-ee/issues/7983
- MR 18797: Support for Crossplane as a managed app
- MR 16: Provision PostgreSQL via Crossplane
- MR 31: Addition of managed postgress
- MR 19675: documentation
- MR 19946: Role binding
Permissions and Security
Test deployment path of Postgres.
What does success look like, and how can we measure that?
GitLab customers are able to see this feature in 12.5 and begin using this feature to deploy Postgres in their chosen cloud provider via Crossplane.