Sandbox Endpoints

Introduction

In order to access a Sandbox Environment manually, or from your test, Endpoints should be used. Endpoints are entities that provide an authenticated URL that points to a service accessible from your Kubernetes cluster.

Endpoints automatically set the routing-key header context on every request made through them, so they will automatically exercise the services within the sandbox as long as header propagation is implemented. They are authenticated and require a Signadot API Key or cookie-based authentication to access.

Specifying Endpoints

In the below example, the fork endpoint is specified under spec.defaultRouteGroup. Note that once created, all endpoint URLs will assume a similar form, https://endpoint-name--sandbox-name.preview.signadot.com.

name: sandbox-better-route
spec:
  description: sandbox env to test a new route service change
  cluster: demo
  forks:
  - forkOf:
      kind: Deployment
      name: route
      namespace: hotrod
    customizations:
      images:
      - image: signadot/hotrod:cace2c797082481ac0238cc1310b7816980e3244
  defaultRouteGroup: # CLI v0.3.7+ required (see sandbox specification for details)
    endpoints:
    - name: endpoint-name      
      target: http://my-app.example.svc:8080

Endpoints Response

Given a specification of endpoints such as above, a sandbox GET or PUT response from the Signadot API will contain a set of endpoints in json (or yaml via the cli) such as below.

endpoints:
- host: frontend.hotrod.svc
  name: frontend-hotrod-svc
  port: 8080
  protocol: http
  routeType: host
  url: https://frontend-hotrod-svc--test-apply.preview.staging.signadot.com

The URL under the field url accesses a service which may or may not have a backing forked workload. In any event, requests to this URL inject a sandbox context propagation header.

More information regarding context propagation is available here.