How Raftt Works?

Raftt supports two basic modes of operation - "connect" and "orchestration". In "connect" mode, the environment is already deployed by other infrastructure, and Raftt is used to enable development on top. In orchestration mode, Raftt also orchestrates the environment. Beyond that difference, the modes are remarkably similar.

We'll go through the mechanics of the raftt connect operation, and note where raftt up behaves a bit differently.

This is a concise explanation, more info is available under Key Concepts.

Connecting to an Environment

When a user runs raftt connect <namespace>, the following actions happen:

1. Raftt's CLI brings up Raftt's daemon, which handles all access to the remote environment controller, including file syncing and traffic handling.
2. The daemon uses the user's KubeConfig to deploy Raftt's environment controller in the specified namespace.
3. The daemon initializes the controller with the current user and repository.
4. The contents of the current repo, including untracked files, are synced to the environment controller.
5. A persistent connection is created between the daemon and the environment controller.
6. Over the connection, a continuous low-latency file sync is set up.
7. A "deploy" request is sent to the environment controller, which leads to...
8. An evaluation in the environment controller of the .raftt file - Raftt's primary configuration file, defining the behavior of the Kubernetes resources during development.
9. Deployment of resources passed to deploy_on_connect - usually configurations or auxiliary workloads that are needed for development but not present in the "clean" environment.

At this point, the flow is complete, and the user can start working with their environment - converting workloads to dev mode and iterating on them.

How is Spawning an Environment Using Raftt Different?

When using raft up there are some slight differences:

1. The daemon contacts Raftt's Environment Manager, which provisions a new Kubernetes namespace, deploys the environment controller in it, and initializes it.
2. The deploy request causes, along with evaluation of the .raftt file, as before, the deployment of all Kubernetes resources passed to the deploy method - generally, the entire environment.
   1. In this mode, this step can also include things like mounting the synced source from the local machine, seeding databases, building images or running scripts.
3. When using raftt up all workloads are always in dev mode.

Under the Hood of a Running Environment

Even after the environment has spawned, our job is not yet done. We make sure that your work is as easy and seamless as possible. We keep the remote environment synced with whatever you do locally by syncing file changes from the repo folder. The port mapping between your machine's localhost and the containers in the remote environment allows accessing the env using any tool you are used to working with locally. We even enhance the containers to allow easier access and debugging.