> - Introduced in GitLab 12.5 for project-level clusters.
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/34702) in GitLab 12.5 for project-level clusters.
[Crossplane](https://crossplane.io/docs) is a multicloud control plane useful in management of applications and infrastructure across multiple clouds by extending the Kubernetes API using custom resources and controllers watching those custom resources. Crossplane allows provisioning and lifecycle management of infrastructure components across cloud providers in a uniform manner abstracting away cloud provider specific configurations.
[Crossplane](https://crossplane.io/docs) is a multi-cloud control plane useful for
managing applications and infrastructure across multiple clouds. It extends the
Kubernetes API using:
The Crossplane GitLab managed application installs Crossplane with a provider of choice on a kubernetes cluster attached to the project repository. Crossplane can then be used to provision infrastructure or managed applications such as postgresql (e.g.: CloudSQL from GCP or RDS from AWS) and other services required by the application via the Auto DevOps pipeline.
- Custom resources.
- Controllers that watch those custom resources.
Crossplane allows provisioning and lifecycle management of infrastructure components
across cloud providers in a uniform manner by abstracting cloud provider-specific
configurations.
The Crossplane GitLab-managed application:
- Installs Crossplane with a provider of choice on a Kubernetes cluster attached to the
project repository.
- Can then be used to provision infrastructure or managed applications such as
PostgreSQL (for example, CloudSQL from GCP or RDS from AWS) and other services
required by the application via the Auto DevOps pipeline.
For configuring Crossplane on the cluster navigate to [Crossplane configuration with GitLab](./crossplane.md).
For configuring Crossplane on the cluster navigate to [Crossplane configuration with GitLab](./crossplane.md).
@@ -15,16 +15,20 @@ We will use the GCP stack as an example in this guide. The instructions for AWS
...
@@ -15,16 +15,20 @@ We will use the GCP stack as an example in this guide. The instructions for AWS
First, we need to declare some environment variables with configuration that will be used throughout this guide:
First, we need to declare some environment variables with configuration that will be used throughout this guide:
```sh
```sh
export PROJECT_ID=crossplane-playground # the project that all resources reside.
export PROJECT_ID=crossplane-playground # the GCP project where all resources reside.
export NETWORK_NAME=default # the network that your GKE cluster lives in.
export NETWORK_NAME=default # the GCP network where your GKE is provisioned.
export REGION=us-central1 # the region where the GKE cluster lives in.
export REGION=us-central1 # the GCP region where the GKE cluster is provisioned.
```
```
### Configure RBAC permissions
### Configure RBAC permissions
- For a non-GitLab managed cluster(s), ensure that the service account for the token provided can manage resources in the `database.crossplane.io` API group.
- For a non-GitLab managed cluster(s), ensure that the service account for the token provided can manage resources in the `database.crossplane.io` API group.
We need to manually grant GitLab's service account the ability to manage resources in the database.crossplane.io API group. The Aggregated ClusterRole allows us to do that.
Manually grant GitLab's service account the ability to manage resources in the
First, save the following YAML as `crossplane-database-role.yaml`
`database.crossplane.io` API group. The Aggregated ClusterRole allows us to do that.
NOTE: **Note:**
For a non-GitLab managed cluster, ensure that the service account for the token provided can manage resources in the `database.crossplane.io` API group.
1. Save the following YAML as `crossplane-database-role.yaml`:
```sh
```sh
cat> crossplane-database-role.yaml <<EOF
cat> crossplane-database-role.yaml <<EOF
...
@@ -50,23 +54,31 @@ rules:
...
@@ -50,23 +54,31 @@ rules:
EOF
EOF
```
```
Once the file is created, apply it with the following command in order to create the necessary role:
```sh
```sh
kubectl apply -f crossplane-database-role.yaml
kubectl apply -f crossplane-database-role.yaml
```
```
### Configure Crossplane with the cloud provider
### Configure Crossplane with the cloud provider
Follow the steps to configure the installed cloud provider stack with a user account.
See [Configure Your Cloud Provider Account](https://crossplane.io/docs/v0.4/cloud-providers.html)
> **Note: The Secret and the Provider resource referencing the Secret needs to be applied to the `gitlab-managed-apps` namespace in the guide. Make sure you change that while following the guide**
to configure the installed cloud provider stack with a user account.
Note that the Secret and the Provider resource referencing the Secret needs to be
applied to the `gitlab-managed-apps` namespace in the guide. Make sure you change that
We need to configure connectivity between the Postgres database and the GKE cluster. This can be configured by creating a [Private Service Connection](https://cloud.google.com/vpc/docs/configure-private-services-access)
We need to configure connectivity between the PostgreSQL database and the GKE cluster.
This can done by either:
We can either use Crossplane to achieve this as demonstrated below or directly in the GCP console by following the above link.
Apply the resource class configuration with the following command:
```sh
```sh
kubectl apply -f gcp-postgres-standard.yaml
kubectl apply -f gcp-postgres-standard.yaml
```
```
Verify creation of the Resource class
Verify creation of the Resource class with the following command:
```sh
```sh
kubectl get cloudsqlinstanceclasses
kubectl get cloudsqlinstanceclasses
...
@@ -193,11 +207,20 @@ The Resource Classes allow you to define classes of service for a managed servic
...
@@ -193,11 +207,20 @@ The Resource Classes allow you to define classes of service for a managed servic
The Auto DevOps pipeline can be run with the following options:
The Auto DevOps pipeline can be run with the following options:
1.`postgres.managed` set to true which will select a default resourceclass. The resourceclass needs to be marked with the annotation `resourceclass.crossplane.io/is-default-class: "true"` (As per the guide the CloudSQLInstanceClass `cloudsqlinstancepostgresql-standard-default` will be used to satisfy the claim )
The Environment variables, `AUTO_DEVOPS_POSTGRES_MANAGED` and `AUTO_DEVOPS_POSTGRES_MANAGED_CLASS_SELECTOR` need to be set to provision PostgresQL using Crossplane
1.`postgres.managed` set to true with `postgres.managedClassSelector` providing the resource class to choose based on labels. In this case the value of `postgres.managedClassSelector.matchLabels.gitlab-ad-demo="true"` will select the CloudSQLInstance class `cloudsqlinstancepostgresql-standard` to satisfy the claim request.
Alertnatively, the following options can be overridden from the values for the helm chart.
Alertnatively, the Environment variables `AUTO_DEVOPS_POSTGRES_MANAGED` and `AUTO_DEVOPS_POSTGRES_MANAGED_CLASS_SELECTOR` could also be used in the Auto DevOps pipeline.
-`postgres.managed` set to true which will select a default resource class.
The resource class needs to be marked with the annotation
`resourceclass.crossplane.io/is-default-class: "true"`. The CloudSQLInstanceClass
`cloudsqlinstancepostgresql-standard-default` will be used to satisfy the claim.
-`postgres.managed` set to `true` with `postgres.managedClassSelector`
providing the resource class to choose based on labels. In this case, the
value of `postgres.managedClassSelector.matchLabels.gitlab-ad-demo="true"`
will select the CloudSQLInstance class `cloudsqlinstancepostgresql-standard`
to satisfy the claim request.
The Auto DevOps pipeline should provision a PostgresqlInstance when it runs succesfully.
The Auto DevOps pipeline should provision a PostgresqlInstance when it runs succesfully.
