Local

Overview

info

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:

1. Set up network-level connectivity between the workstation and cluster
2. 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.