Most of the deployment of Drogue Cloud uses
kustomize as part of
kubectl. However, we do require a few steps
before and after the deployment. Installing dependencies on the cluster and setting URLs afterwards.
For this we have a magic installer script, that does everything for you. It is suited for an easy start on a local test cluster.
The installer package is part of the GitHub release record: https://github.com/drogue-iot/drogue-cloud/releases/tag/v0.3.0
There is one package for each type of Kubernetes cluster:
install-minikube– For using with Minikube
install-kind– For using with Kind
install-openshift– For using with OpenShift
Download the package, matching the cluster you plan to use.
The installer will create a new instance of Drogue Cloud on the cluster you are currently logged in to.
By default, this includes:
Creating a Kafka cluster
Installing the Keycloak operator
Create a custom CA for the endpoints
If you want to install those dependencies manually, for example using OLM, you can opt-out of the installation (see below).
Run the installer script
./script/drogue.sh, adding the options appropriate for your setup.
You can use the environment variable
CLUSTER to define which cluster type you have.
Default cluster type
By default, the cluster type will be
Most options are controlled by using environment variables. You can set them by prefixing the
call to the installation script, using
env and the variable assignment:
env CLUSTER=kind INSTALL_DEPS=false ./script/drogue.sh
If you want to install the dependencies (like Strimzi, KNative) yourself, you can opt out of installing the dependencies.
|Variable Name||Default value||Description|
Control the installation of all dependencies.
Control the installation of the Knative stack.
Control the installation of the Keycloak operator.
You can change the namespace where of the Drogue Cloud components get installed using the variable
|Currently, you can only change the namespace of the Drogue Cloud installation. The namespaces of Knative, Strimzi, are currently not configurable.|
By default, the installer script will create a custom certificate authority. However, if you already have a key and certificate, you can instruct the installer to use these. There are two options to achieve this.
The installer will check if the secrets
mqtt-endpoint-tls exist. If they don’t it will
create them either using provided or generated key and certificate material.
If you manually create these TLS secrets, using those names, before running the installer, it will not override these existing secrets.
Should something go wrong, it should be possible to just re-run the installer script. That should simply set the desired state again, and Kubernetes should reconcile accordingly. In most of the cases, this works just fine.