Helm and K8s Manifest Support

Raftt is a managed dev environment as a service (EaaS) that allows developers to create unlimited, fully dynamic, and debuggable developer environments in the cloud based on existing infrastructure definitions. Following some amazing work by our R&D team, we now support creating environments based on Kubernetes manifests or helm charts - no need to re-write any configurations! Read on for more info.

The first infrastructure definition language we supported was docker-compose, which is already in wide use for developer environments. Companies using docker-compose often are able to consistently bring up a local env with all the required services, but encounter problems with debugging, working with multiple environments and collaborating.

As the company’s product becomes more complex, the IaC definition that deploys it grows as well, and at some point maintaining both a docker-compose for development and additional definitions (Kubernetes manifests or equivalent, Terraform, …) for production / staging no longer makes sense. Do we choose to maintain multiple definitions, and deal with the extra work and inconsistencies? Or do we no longer expect developers to run the product as part of the day-to-day flow, and shift to limited, testing-based development?

By supporting Kubernetes manifests and helm charts natively, Raftt allows teams to minimize their maintenance, while keeping the same optimal dev experience.

There are quite a few pitfalls to supporting the more production IaC definition languages - they don’t include everything you need for a dev environment. In a Kubernetes manifest you can’t define how to build the image, or which ports to forward, or how to seed the database. And sometimes the yaml defining the production services is different from the one we want for development - for example, it may define replicas, harden security or interact directly with production cloud services.

In order to give teams the maximum definition reuse while allowing full flexibility, we are proud to introduce the `.raftt` file and language, with built-in primitives for importing existing definitions, and a familiar syntax (based on starlark) for making changes and enriching definitions. This results in clear and simple configuration, no matter what we have as input. The choice to create a Domain Specific Language (DSL) was not an easy one, but it was the only option that gave the engineers onboarding onto Raftt the power they needed.

See the following on how to configure `.raftt` to load resources of various types:

### Docker Compose

```python
compose_resources = docker_compose("./path/to/compose.yml")
deploy(compose_resources)
```

### Kubernetes Manifests

```python
resources = k8s_manifests("./manifests") # can be a folder or a file
deploy(resources)
```

### Local Helm Charts

```python
resources = helm_local_chart("release-name", "./path/to/helm/chart", values_files="./helm/values.dev.yml", values={"override_value": true}, version="3.10.1")
deploy(resources)
```

Of course, these can be used together if needed.

For more information, see [https://docs.raftt.io/docs/config/rafttfile](https://docs.raftt.io/config/rafttfile#import-kubernetes-manifests). If this has piqued your interest and you’d like to see a demo, [contact us](https://www.raftt.io/contact).