Provider Lab Part 1

Vamos a crear un laboratorio con todo lo que necesitamos para nuestro estudio de Crossplane. La propuesta es crear un lab con varios providers de cosas que utilizamos en nuestro día a día.

Vamos a reaprovechar el lab de Backstage y agregar Crossplane, pero vamos a agregar varios providers extras para poder explorar diferentes escenarios en el futuro.

Vamos a instalar utilizando values.yaml abajo.

Provider GitHub

Aplica el yaml abajo.

apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
  name: provider-github
spec:
  package: xpkg.upbound.io/coopnorge/provider-github:v0.13.0

Vamos a configurar el provider de GitHub usando un personal token.

Vamos a crear un secret conteniendo dentro de credentials el token y el owner que son los valores que necesita buscar.

Crea el archivo github.yaml

# github.yaml
apiVersion: v1
kind: Secret
metadata:
  name: github-davidpuziol # Nombre del secret, cambia para el tuyo
  namespace: crossplane-system
type: Opaque
stringData:
  credentials: "{\"token\":\"${GITHUB_TOKEN}\",\"owner\":\"${GITHUB_ACCOUNT}\"}"
---
apiVersion: github.upbound.io/v1beta1
kind: ProviderConfig
metadata:
# Este es un provider config de github conforme podemos ver por el apiversion.
# Una buena práctica es que por el nombre ya consigamos saber cuál cuenta será usada
# Cambia para tu cuenta para que quede fácil.
  name: github-provider-davidpuziol
spec:
  credentials:
    source: Secret
    secretRef:
      name: github-davidpuziol # Referenciará el secret que creamos arriba.
      namespace: crossplane-system
      key: credentials

Cada provider tiene su propio Kind ProviderConfig que utiliza su propia apiVersion.

Podemos tener varios provider config para el mismo tipo de provider. Por ejemplo dos cuentas diferentes en GitHub.

Ahora vamos a aplicar lo que tenemos arriba.

export GITHUB_TOKEN="tu-token"
export GITHUB_ACCOUNT="tu-cuenta"
# Como el yaml no tiene la capacidad de sustituir las variables, debemos hacer eso antes de aplicar.
envsubst < gitlab.yaml | kubectl apply -f -

Para probar vamos a aplicar el manifiesto abajo para crear un nuevo repositorio.

apiVersion: repo.github.upbound.io/v1alpha1
kind: Repository
metadata:
  name: test-repo-crossplane
  namespace: default
spec:
  forProvider:
    name: test-repo-crossplane
    description: "Repositorio de prueba creado vía Crossplane"
    visibility: "public"
    hasIssues: true
    hasWiki: true
    autoInit: true
  providerConfigRef:
    name: github-provider-davidpuziol # Mira que estamos utilizando este provider config, es decir, va para mi cuenta.

kubectl apply -f githubrepotest.yaml
repository.repo.github.upbound.io/test-repo-crossplane created

Una curiosidad es que este recurso es cluster scope, es decir, por más que definamos el namespace default, no hace diferencia. En realidad todos los custom resources de GitHub están a nivel de clúster.

❯ k get repositories.repo.github.upbound.io -n default
NAME                   SYNCED   READY   EXTERNAL-NAME          AGE
test-repo-crossplane   True     True    test-repo-crossplane   2m2s

❯ k get repositories.repo.github.upbound.io -n crossplane-system
NAME                   SYNCED   READY   EXTERNAL-NAME          AGE
test-repo-crossplane   True     True    test-repo-crossplane   2m15s

Eliminando este recurso.

kubectl delete repositories.repo.github.upbound.io test-repo-crossplane
repository.repo.github.upbound.io "test-repo-crossplane" deleted

Varios nuevos custom resources fueron creados para uso de GitHub, a pesar de usar el repositories.repo.github.upbound.io.

k get customresourcedefinitions.apiextensions.k8s.io -n crossplane-system -o custom-columns=NAME:.metadata.name | grep github.upbound.io

actionssecrets.actions.github.upbound.io
actionsvariables.actions.github.upbound.io
branches.repo.github.upbound.io
branchprotections.repo.github.upbound.io
defaultbranches.repo.github.upbound.io
deploykeys.repo.github.upbound.io
emugroupmappings.team.github.upbound.io
memberships.user.github.upbound.io
organizationrulesets.enterprise.github.upbound.io
organizations.enterprise.github.upbound.io
providerconfigs.github.upbound.io
providerconfigusages.github.upbound.io
pullrequests.repo.github.upbound.io
repositories.repo.github.upbound.io
repositoryautolinkreferences.repo.github.upbound.io
repositoryfiles.repo.github.upbound.io
repositorywebhooks.repo.github.upbound.io
storeconfigs.github.upbound.io
teammemberships.team.github.upbound.io
teamrepositories.team.github.upbound.io
teams.team.github.upbound.io
teamsettings.team.github.upbound.io
teamsyncgroupmappings.team.github.upbound.io

Provider GitLab

Creamos el secret con el token que necesitamos.

apiVersion: v1
kind: Secret
metadata:
  name: gitlab-davidpuziol
  namespace: crossplane-system
type: Opaque
stringData:
  token: "${GITLAB_TOKEN}"
---
apiVersion: gitlab.crossplane.io/v1beta1
kind: ProviderConfig ## Una vez más mira que es kind ProviderConfig para un apiVersion diferente.
metadata:
  name: gitlab-provider-davidpuziol
  namespace: crossplane-system
spec:
  baseURL: https://gitlab.com/
  credentials:
    source: Secret
    method: PersonalAccessToken
    secretRef:
      namespace: crossplane-system
      name: gitlab-davidpuziol
      key: token

Y tenemos los custom resources abajo, todos a nivel de clúster también.

k get customresourcedefinitions.apiextensions.k8s.io -n crossplane-system -o custom-columns=NAME:.metadata.name | grep gitlab.crossplane.io
accesstokens.groups.gitlab.crossplane.io
accesstokens.projects.gitlab.crossplane.io
deploykeys.projects.gitlab.crossplane.io
deploytokens.groups.gitlab.crossplane.io
deploytokens.projects.gitlab.crossplane.io
groups.groups.gitlab.crossplane.io
hooks.projects.gitlab.crossplane.io
members.groups.gitlab.crossplane.io
members.projects.gitlab.crossplane.io
pipelineschedules.projects.gitlab.crossplane.io
projects.projects.gitlab.crossplane.io
providerconfigs.gitlab.crossplane.io
providerconfigusages.gitlab.crossplane.io
samlgrouplinks.groups.gitlab.crossplane.io
storeconfigs.gitlab.crossplane.io
variables.groups.gitlab.crossplane.io
variables.projects.gitlab.crossplane.io

Para crear un repositorio ya sería otro custom resource diferente de GitHub. En GitLab definimos un proyecto.

apiVersion: projects.gitlab.crossplane.io/v1alpha1
kind: Project
metadata:
  name: test-project-crossplane
  namespace: default
spec:
  forProvider:
    name: test-project-crossplane
    description: "Proyecto de prueba creado vía Crossplane"
    visibility: private
    initializeWithReadme: true
  providerConfigRef:
    name: gitlab-provider-davidpuziol

Aplicando este manifiesto tenemos.

kubectl apply -f /docs/iac/crossplane/resources/providers-configs/gitlabrepo.yaml
project.projects.gitlab.crossplane.io/test-project-crossplane created

k get projects.projects.gitlab.crossplane.io
NAME                      READY   SYNCED   AGE   PATH WITH NAMESPACE
test-project-crossplane   True    True     23s   davidpuziol/test-project-crossplane

Para eliminar.

❯ k delete projects.projects.gitlab.crossplane.io test-project-crossplane
project.projects.gitlab.crossplane.io "test-project-crossplane" deleted