Development usage

Developing with an ephemeral version of self-hosted stack

For customers, it may be useful to develop with non-production versions of the management plane either hosted locally with a tool (such as KIND, Minikube, or Minishift) or in a non-production cloud cluster.

To develop locally, ensure you have the following tools installed:

A separate local Kubernetes (or even a remote one) can be used, this guide is primarily focused on using it rather than which Kubernetes provider you end up using.

Provision cluster

For KIND you can create a cluster by using kind create cluster.

Other tools have similar equivalent approaches, one thing to be aware of is whether your Kubernetes distribution provides a Load Balancer Controller or Ingress support. KIND does neither by default but they can be added following the official documentation:

You can also set up a local or private registry to use.

Deploy management plane

Deploy using the standard helm chart with any customisation required (for example, for a different registry or with pull secrets).

For KIND, deploy using ClusterIP services to prevent the need for a Load Balancer controller but it will then require the use of kubectl port-forward ... to access the services.

helm repo add calyptia https://helm.calyptia.com --force-update
helm update
helm upgrade --install \
    --create-namespace --namespace "calyptia" \
    --set cloudApi.service.type="ClusterIP" \
    --set frontend.service.type="ClusterIP" \
    --set vivo.service.type="ClusterIP" \
    --wait --debug \
    calyptia-cloud calyptia/calyptia-standalone

Remember to provide image credentials to pull the images

If using ClusterIP then data needs to be ingested into the cluster somehow, a simple technique is to use port-forwarding (for example, kubectl -n <namespace> port-forward svc/<service> <port>:<port>). This will expose the port locally for use. For example, to access the UI on http://localhost:3000:

kubectl port-forward -n calyptia svc/core 3000:3000

Last updated