This page talks about how to let components in the sandbox communicate with each other and how to access services running in the sandbox from outside via
- How services communicate with each other within sandbox
- How to expose services running in the sandbox for external access
As mentioned before, in each Crafting sandbox, there is an overlay network Crafting sets up for services to communicate with each other. There are multiple ways for one service to reach another within a sandbox.
containers can address each other by their
names as the network
hostname, and use the
ports they define in the configuration.
For example, in the workspace defined above, other service can reach it by
spring:8080 using HTTP protocol. For all the built-in dependencies, they open the default ports, and details can be found at https://sandboxes.cloud/dependencies
Note that the port defined in
containers will NOT be directly exposed to Internet for security reasons, so you can't access them directly from your local machine. See below for how to access that.
Based on our practice for local development, sometimes we configure our services in dev mode to hit a port on localhost for reaching a dependency, e.g. hitting
localhost:6379 to reach the
redis local server. Crafting makes it easy to replicate the same practice by allowing workspace port forwarding.
For example, as shown above, the this workspace sets up two port forwardings for port 3306 and port 6379, to
redis, respectively. That way, the service running on the workspace can just hit
localhost:3306, which will be equivalent as hitting
Setting up port forwardings on a workspace is also helpful for hybrid development by providing information on outbound connections. See Port-forwarding for hybrid development for details.
For security reasons, the port defined in
containers will NOT be directly exposed to Internet. To access the services running in the sandbox from external, e.g. local laptop, there are following ways.
We can define
endpoints in the sandbox to manage access from external. Each endpoint is corresponding to an external facing URL, which can be addressed from Internet. To add an endpoint, from the editing view of a Standalone sandbox, click
Add Component as shown below and choose
An endpoint can map traffic hitting the external URL to internal ports by a set of pre-defined rules. From web console, we can define a direct mapping for a TCP endpoint or a set of routing rules for an HTTP endpoint.
In the above examples, the Internet facing URL
tcp://mysql--mysandbox-myorg.sandboxes.run:443 goes to the
mysql service's default port (3306), and
https://app--mysandbox-myorg.sandboxes.run/ goes to the
app port (defined as 3000).
For security reasons, all
endpoints exposed by Crafting sandbox need to have TLS layer, e.g. https for HTTP protocol and tcp+tls for TCP protocol.
As shown above, for HTTP endpoints, we can add authentication to make sure only users in the same organization can access the endpoint. For APIs, sometimes it might be unnecessary if the API itself has an app level authentication mechanism already there.
An HTTP endpoint can support routing different paths to different backend services, (i.e.,
dependencies). It also supports more advanced routing rules. Please see Sandbox Definition for details.
There are other special ways to access services in the sandbox, which is using CLI
cs. Using the same mechanism of how
cs ssh works. We can set up SSH tunnel from a local machine.
In addition, after
cs portforward, the local port on the local machine, e.g.
localhost:6379 will be mapped to the target port defined in the workspace's
port forwardings, you can use your debugging tools to easily access the in-sandbox service that way from your local machine. See Port-forwarding for hybrid development.
We recommend define
endpoints properly as shown above, which supports generic use cases such as mobile testing, end-to-end testing, and demoing.
Updated 10 months ago