There are two situations in which we need to launch fully-fledged Stackable clusters:
-
in our CI/CD pipelines' integration tests
-
when we want to help customers with issues by reproducing their environments (troubleshooting)
The following diagram shows at a very high level how T2 is integrated into the workflow of setting up a Stackable environment on a cloud provider.
-
The user sends a cluster definition to T2, this can optionally already include a definition of services that should be set up on the platform (see The Stackable cluster definition YAML).
-
T2 generates Terraform and Ansible code from this cluster definition and executes this against a cloud provider to instantiate VMs (4 in this example) and provision them with the base Stackable components.
-
After the base platform has been provisioned T2 acts as a Stackable client and posts the initial product config - if one was specified in the call to T2.
From a technical point of view this means creating custom resources in the Kubernetes that backs the Stackable platform. -
At this point the user can interact with the cluster via the kube-apiserver to add / remove / manage the needed tools.
T2 does not (yet?) have a graphical UI but is providing a REST API.
We host an instance of T2 at our company which is only accessible for ourselves.
The product T2 is tailor-made for us, but if you like to use it in your organization, feel free to do so. T2 and the templates it is shipped with come without any warranty. Be aware of the costs which cloud computing might generate!
The following documents provide further information about T2 and its usage:
-
Running T2 describes how to run T2 on your (cloud) infrastructure.
-
cluster lifecycle explains the REST API and the lifecycle of T2 clusters.
-
cluster definition YAML is a reference documentation of the document which describes the desired state of a T2 cluster.
-
T2 testdriver describes how to use the "T2 testdriver", a Docker image to be used as a T2 client for test automation and other useful tasks.