Development Environment

Development Environment#

This section does describe how to set up an environment for working on this setup.

At the moment it is assumed that different flavors are useful depending on the specific need:

  • A “local environment” for fast iteration. This is basically a functional cluster and a deployment of Flux into it so that one can add components as needed instead of deploying the whole setup.

    Some features like SSL, announcing IP addresses on the local network, backup are optional in this case.

  • A “full environment” would be a temporary full deployment of the setup. This would be needed to verify that the whole bootstrap procedure work as expected.

  • An “acceptance environment” is technically the same as a “full environment”, in contrast it would be bootstrapped based on a production snapshot.

The best approach still has to be found and evolve over time.

Local development#

A fast feedback loop is required when working on a change. A restore from a backup is optional, instead a bootstrap from scratch can be more useful.

Basis: a cluster#

Suggested: Use minikube:

# Optional
export DOCKER_HOST=ssh://user@192.0.2.1

# Start it
minikube start --driver=docker

The basis must be an existing cluster. This can be a virtual machine with a single node cluster, a kind based cluster or a virtual cluster in a given host cluster.

Not all features are possible in every variant:

  • L2 IP Announcements via Cilium may be limited or not possible.

  • Ceph based storage.

Opinionated Flux deployment#

Quickstart:

# Be inside of the directory ./kubernetes/dev-env/
task c:bootstrap

An opinionated Flux deployment into the cluster is required. The deployment should match the production cluster overlay, so that it provides an environment with sufficient similarity to production.

A git push into the cluster should be possible based on the integrated Gitea instance.

Template for Flux based development#

A template could also be a repository in which one would create a branch for the specific environment. Then it would also provide an easy way to share environments based on publishing the branch or creating a fork.

Currently using ./kubernetes/dev-env inside of the instance repository.

Plain Helm, Helmfile and kubectl based development#

Working with plain Helm, Helmfile and kubectl or any other Kubernetes tooling is an alternative for fast local iteration.