Sandbox Local
Overview
Local Workloads in Sandboxes is in Beta. Please leave feedback via our community GitHub or join our Slack.
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
Signadot CLI.
Usage Overview
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 signadot local
connect.
Once connected to the cluster, one simply applies the local sandboxes and launches the corresponding services on their workstation.
For further information:
- The local testing 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.