Most of the deployment of Drogue Cloud uses
Helm in combination with
kubectl for installing dependencies. However,
we do require a few steps before and after the deployment. Installing dependencies on the cluster and setting URLs
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.
Pure Helm based installation
While we describe the installation of Drogue Cloud using our installer script, it is also possible to install it using just Helm charts. In fact, the installer uses an opinionated value set for the Helm charts, and you can simply create your own wrapper chart, tweaking the values as needed.
This is what we do for our public sandbox too. The installer script is just there to get you started quickly.
The installer package is part of the GitHub release record: https://github.com/drogue-iot/drogue-cloud/releases/latest
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).
Additionally, it installs Knative and an example application and can install digital twin feature as well. Deployment of these components can be configured using installer arguments as explained below.
Run the installer script
./script/drgadm deploy, adding the options appropriate for your setup.
You can use the
-c argument to define which cluster type you have.
Default cluster type
By default, the cluster type will be
deploy command of
drgadm supports the following argument
Don’t install any dependency by default.
Set additional Helm values. May be repeated multiple times.
Minimize: Reduces the default resource requests to allow deploying on more constrained environments.
Manually provide the application DNS domain.
Specify the cluster type (any of
Adds an additional Helm value file, named
Helm installation timeout (default: 15m)
Changes the target Drogue IoT namespace.
Install digital twin feature.
Don’t install examples.
Example: Install Drogue Cloud on
kind cluster without dependencies.
./script/drgadm deploy -c kind -k
-k argument will skip installing all dependencies. If you want to install of just some of the dependencies (like Strimzi or Keycloak) yourself,
you can opt out of installing them by the script.
The installer has a few additional options which 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 INSTALL_STRIMZI=false ./script/drgadm deploy
|Variable Name||Default value||Description|
Control the installation of Strimzi.
Control the installation of the Keycloak operator.
By default the example dashboard is installed by the script. You can turn it off by using
Additionally, digital twin feature can be installed by specifying
Knative will be installed only if either examples or digital twin feature are installed.
To deploy minimal installation without any examples (and Knative) use:
./script/drgadm deploy -e
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
coap-endpoint-tls exist. If they don’t it will
create them using 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. You can do that by running shell commands similar to these:
kubectl -n drogue-iot create secret tls http-endpoint-tls --key $PATH_TO_CERT/tls.key --cert $PATH_TO_CERT/tls.crt --dry-run=client -o json | kubectl -n drogue-iot apply -f - kubectl -n drogue-iot create secret tls mqtt-endpoint-tls --key $PATH_TO_CERT/tls.key --cert $PATH_TO_CERT/tls.crt --dry-run=client -o json | kubectl -n drogue-iot apply -f - kubectl -n drogue-iot create secret tls coap-endpoint-tls --key $PATH_TO_CERT/tls.key --cert $PATH_TO_CERT/tls.crt --dry-run=client -o json | kubectl -n drogue-iot apply -f -
$PATH_TO_CERT should point to the path location of your certificate.
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.