Using Raftt for Orchestrating Helm-Based Ephemeral Environments

Working with helm provides a lot of benefits for application distribution and management. It even helps accelerate the development of complex deployment manifests by bundling and allowing incremental deployment. For this reason, helm has become one of the most widespread tools used to deploy applications on Kubernetes.

There are two things that helm is missing, that require additional effort to make it effective as a base for ephemeral development environments:

1. Environment lifecycle management - bringing up and taking down environments as needed by developers
2. Application-code development experience - fast iterations, debugging, and a general full-fledged dev experience for the code itself.

These aren’t missing from helm - they are outside of Helm’s goals.

In this blog post we’ll cover using Raftt for orchestrating helm-based environments and developing their application code. We’ll start with a brief intro on helm, and then move on to orchestrating and finally development.

### A short intro on helm [skip if you know]

Helm is a package manager for Kubernetes that simplifies the deployment and management of applications. It introduces the “chart” - a package of files that describe a set of Kubernetes resources that together make up an application. Helm can deploy charts from anywhere on the internet, providing a simple way to share applications as ready-to-run Kubernetes deployments. It's a crucial and extremely popular tool for deploying and maintaining complex Kubernetes applications.

### Simple orchestration of helm charts with Raftt

Raftt can orchestrate any number of definitions as part of a single environment - you could have helm charts, docker-compose, Kustomize files, and more for various parts of our application. If we are onboarding a new project, generate a skeleton:

```bash
raftt setup
```

Next, we’ll open up the `env.raftt` file and modify it. We’ll want to deploy our helm chart, so let’s replace it’s default contents with the following line (make sure to replace the values as needed):

```python
deploy(helm_local_chart("release-name", "path/to/chart"))
```

Now, let’s see it in action:

```bash
raftt up
```

You should be seeing something like this (of course, the workloads names will be different). This is for the Online Boutique, our demo project - [https://github.com/rafttio/online-boutique](https://github.com/rafttio/online-boutique)).

We can bring it down using `raftt down`. If we don’t do that, Raftt’s cluster controller will detect when the environment is no longer used and will bring it down itself. The detection is based on traffic to the environment, files being synced and API requests to the environment-specific controller.

### Development on Raftt environments

The environments brought up by Raftt are intended for use for development, and come OOTB with several critical features:

1. A supervisor process that manages the container’s process lifecycle
2. The repository from which the environment was spawned is already synced to the environment controller in Kubernetes
3. A rich configuration language that allows modifying the Kubernetes resources, mounting volumes, and more.

We get (1) and (2) out of the box, so no additional setup required there. (3) allows us to slightly modify the resources so we can get a great development experience. For example, let’s say we have a microservice using an interpreted language (python, js, …). Raftt supports compiled languages just as well - [see our docs](https://docs.raftt.io/basics/onboard_project#compiling-your-code) for more info. We’ll start by mounting the code synced from the local repository, by adding to the `env.raftt` (after the `helm_local_chart`):

```python
resources.deployments["<service name>"].mount(repo_volume(), "/path/to/code")
```

To make this take effect, we simply run `raftt rebuild deployment/<service name>`. This should look something like this:

Since code syncs automatically, whenever we run `raftt restart <service name>` the service will start up with our new code. We can also configure hot reloading easily - [check out our documentation](https://docs.raftt.io/basics/onboard_project#file-watching-hooks).

Finally, we’d probably like to be able to debug our service as well. This is supported by Raftt OOTB, and is covered in detail (for all the popular programming languages) [here](https://docs.raftt.io/debugging). Just like the `env.raftt` file, the debug configuration can be committed to the repo, so once you have it working the whole team can use it.

### Concluding

We usually find that onboarding a project to Raftt takes very little time and configuration, and allows for easily orchestrating ephemeral environments. With Raftt, you get fast feedback cycles for deve environments, especially if they are running on remote kubenretes clusters. We’re happy to help out with the onboarding (even if you are just playing with the product!) - [just ping us](https://www.raftt.io/contact).