Shipa Provider Install

Providers extend Crossplane to enable infrastructure resource provisioning. In order to provision a resource, a Custom Resource Definition(CRD) needs to be registered in your Kubernetes cluster and its controller should be watching the Custom Resources those CRDs define. Provider packages contain many Custom Resource Definitions and their controllers.

For this integration, Shipa is implemented as a provider for Crossplane, implementing controllers for:

  • Application management
  • Cluster management
  • Framework management
  • Plan management
  • Role management
  • Team and user management

Installing Crossplane

Crossplane can be easily installed into any existing Kubernetes cluster using the regularly published Helm chart and the steps below:

kubectl create namespace crossplane-system
helm repo add crossplane-stable https://charts.crossplane.io/stable
helm repo update
helm install crossplane --namespace crossplane-system crossplane-stable/crossplane --set packageCache.sizeLimit=512Mi

📘

Crossplane install details

You can find detailed instructions on how to install Crossplane directly from Crossplane's official documentation available here

Installing the Shipa Provider

To install the Shipa provider package, apply the following resource to the cluster where Crossplane is running:

apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
  name: provider-shipa
spec:
  package: "shipasoftware/provider-shipa:0.0.6"

📘

Crossplane 1.6+ API Graduation

As off Crossplane 1.6, the API version of pkg.crossplane has moved from "pkg.crossplane.io/v1beta1" to "pkg.crossplane.io/v1". If using Crossplane less than 1.6, use v1beta1.

You can apply the file above by using the command:

kubectl apply -f crossplane-provider-shipa.yaml

Configuring the Provider

To authenticate with the Shipa API, the provider controllers need to have access to credentials. Therefore, we use a type called Provider with information about how to authenticate to the Shipa API.

The file above configures the connection between Crossplane and the Shipa API:

apiVersion: v1
kind: Secret
metadata:
  name: crossplane-secret
  namespace: crossplane-system
stringData:
  endpoint: "https://target.shipa.cloud:443"
  token: "your token"

type: Opaque

📘

Endpoint

For Self-Managed Shipa installations, you can find your endpoint e.g the Shipa Target Address [same used by the CLI] by going to Settings -> Target Address. Got HTTPS-based targets, the port will be 8081.
If using an HTTP not HTTPS based endpoint in the crossplane-secret, the port with be 8080 e.g endpoint: http://amazingelb.us-east-1.elb.amazonaws.com:8080

You can apply the file above using the command:

kubectl apply -f crossplane-secret.yaml

📘

Finding your Shipa token

You can find your Shipa user token by using the following command:

shipa token show

Next, you need to create the Provider Config. You can do so using the following file:

apiVersion: shipa.crossplane.io/v1alpha1
kind: ProviderConfig
metadata:
  name: default
spec:
  credentials:
    source: ShipaConnectionSecret
    connectionSecretRef:
      name: crossplane-secret
      namespace: crossplane-system

You can apply the file above using the command:

kubectl apply -f crossplane-shipa-config.yaml

Your Shipa provider is now installed and ready to be used with Crossplane.

Troubleshooting

As CrossPlane is an up-and-coming paradigm, there will be changes as the CrossPlane community grows.

Resource States in ArgoCD

A known limitation as of the time of this documentation in CrossPlane is that ArgoCD does not pick up on the XRD status in CrossPlane.

🚧

CrossPlane Resource States in ArgoCD

At the time of this documentation, ArgoCD focuses on the state of the CRDs that CrossPlane creates, not the underlying resources that need to be created. For example, if there is a failure for the underlying resource, ArgoCD would show the synch as successful. This is universal for all CrossPlane providers.
Project GitHub Issue

To debug why a Shipa Object has not been successful, will need to describe the CrossPlane Kubernetes Object.

kubectl get object.shipa.crossplane.io/name -A
e.g
kubectl describe appdeploy.shipa.crossplane.io/deploy-of-portal-application 

Stuck Deleting Items / Orphan Items Delete

Like in any IaC, there is the possibility of Orphan Objects. As observed, sometimes this is due to a stuck Kubernetes Finalizer. This will manifest itself differently in different CD stacks. The below steps are based on this GitHub Issue.

#Try
kubectl delete -f sample-cp-app-cname.yaml

#Describe
kubectl describe appcname.shipa.crossplane.io/cp-app-cname

#Patch
kubectl patch appcname.shipa.crossplane.io/cp-app-cname -p '{"metadata":{"finalizers":[]}}' --type=merge

Did this page help you?