Local workloads in sandboxes allow running sandboxed workloads seamlessly on the user's workstation. It includes functionality to:
- Set up network-level connectivity between the workstation and cluster
- Set up sandbox routing to enable certain tagged traffic (based on routing key metadata) to flow from the cluster to the workstation
Local sandboxes require
v0.13.0+ of the Signadot Operator and
v0.5.0+ of the
To run a local workload in a sandbox, the Signadot CLI must be
configured to enable
connecting to the cluster associated with the sandbox. Once so configured, one
must connect to the cluster using
Once connected to the cluster, one simply applies the local sandboxes and launches the corresponding services on their workstation.
For further information:
- The local development guide provides an overview of usage with an example.
- The sandbox local specification details the local section of a sandbox spec.
- The CLI documentation covers usage information for connecting to a cluster.
- See sandbox-local.yaml for a full example of a local workload in a sandbox.
Managing Local Sandboxes
Local development with sandboxes is implicitly tied to the submitter of a sandbox spec. Sandbox request routing will involve only the submitter's machine. However, sandboxes with local workloads are still visible across the Signadot Organization.
In CI, one names a Sandbox according to the pull request or git SHA of a commit to guarantee the uniqueness of sandbox names. Similarly, submitters of sandboxes with local workloads should name their sandboxes in a way that avoids clashes with other submitters of sandboxes with local workloads in the same organization. For example, an organization could prefix sandbox names with local workloads with the user name of the submitter.