This page is only relevant if you use Raftt for improving the developer experience of dev envs created by other tools, and not for orchestrating dev envs.
When used in connect mode, Raftt is used for adding a development features layer on top of existing envs created and managed by other tools.
To make resources, especially workloads, easy to use for development, they need to change. Some of these changes are performed automatically by Raftt without any config from the user, and some are configured for the specific resource. When these changes are applied to a resource, we say it's moved into dev-mode, or devified, and when it returns to it's original state, we say it's moving out of dev-mode, or undevified.
Dev envs should be as similar as possible to production, while keeping them easy to develop. To handle this tradeoff, Raftt only transforms the specific resources the users want, while keeping the other just like in production.
When starting to work with Raftt in an env, the first thing you need to is run the
raftt connect command from the directory of the repo that's deployed in the env. The command works add Raftt's infra to the specified namespace and makes it ready for getting resources into dev-mode. The command does the following -
- Raftt's env controller is added to your namespace (a deployment named sandcastle).
- Your repo is mirrored to the cluster and live syncing is started.
- You can start using
raftt logscommands to inspect all your workloads.
As explained before, to convert resources into their dev-mode configuration, you must run
raftt dev for the specific resources. All resources can be converted dev-mode, but it's usually most usefull for workloads. For that reason, if there are multiple resources with the same name and the kind isn't specified, the
dev command assumes you intended to devify the workload. To specify a non-workload resource, use the
When entering dev-mode, the following actions occur -
- The dev-mode definitions of the specified resources are read from the .raftt file.
- The specified resource taken down (scaled down to 0 replicas in case of deployments) and new resources are spawned according to the new definitions.
- If the specified resources are workloads, they differ from the old ones in the following characteristics -
- Their name has the suffix
-raftt. This isn't relevant for pods who are treated like a non-workload deployment in this context.
- The lifecycle of the container is split from the lifecycle of its main process. You can restart the process without respawning the container, and the main process crashing doesn't result in the termination of the container, allowing much better inspection. See here for more information.
- Any changes defined in the
.rafttfile for the specified resources are applied. This usually includes -
- Code is now continuously synced to the container, allowing you to write code in you favorite local IDE and see the changes affect the cluster.
- Port are mapped from the workloads to localhost, allowing easy access.
- Any other change that makes it better for development.
- You can now run all raftt commands that are relevant to workloads, e.g.
- Their name has the suffix
- All the rest of the namespace resources (those not specified in the
rebuildcommand) remain unchanged.
raftt dev -u
-u, short for
--undev, reverts any changes performed to a specified resource during and following its devification. When devifying a resource, Raftt saves the current state and returns to it when undevifying.
raftt dev -u reverts all changes to the resource, even those not performed by Raftt commands. It means that if any external tool modified devified resources, running
raftt dev -u is expected to revert the changes.
dev -u can be run on a specific workloads or without specifying anything, which results in undevifying every devified resource.
This command removes everything that raftt added/modified in the env. It first undevs all resources and then cleans all the infra added in
raftt connect. If undevifying any resource failed, or that Raftt CLI isn't connected to the specified namespace, the infra isn't removed, unless the
--force flag is specified. If this flag is specified, all resources left raftt failed to undev are forcibly removed along with all of Raftt's infra.