How to run sandbox on docker

How we can run the sandbox on docker container?


We provide a docker container containing an SDK installation Note that this is only intended for development, for a production usecase you are better off building a smaller docker containing containing just the JSON API or DAML on SQL but given that Sandbox is only a development tool anyway this shouldn’t be an issue here. Here’s an example of how you can use it:

docker run -p 6865:6865 digitalasset/daml-sdk:1.7.0 daml sandbox

@cocreature I’m thinking of using this image as a base image and just creating a new image since I want some other binaries running in the container too. (I’ve actual already build a inhouse DAML container, but I’m considering using yours depending on which one offers persistence the best.)

If I were to wrap this in a K8s deployment, do you have any idea how I could persist the data of the Sandbox with Postgres? I’ve tried this What's the difference between Daml Driver for Postgres and Daml Sandbox w/ Postgres? - #8 by perbergman, but no luck.

2021-04-15 08:26:04.986 UTC [85] FATAL:  password authentication failed for user "sanbox-participant"
2021-04-15 08:26:04.986 UTC [85] DETAIL:  Role "sanbox-participant" does not exist.
	Connection matched pg_hba.conf line 99: "host all all all md5"

I suppose I’d have to configure the container? Not sure. However, I get the deprecated method working, but when I restart the runtime the ledgerId changes and then can’t access the Postgres container I’ve got going.

I’m basically just looking for a development environment to run the DAML contact, use the JSON HTTP API, and to persist the data, so that on a restart it restores its state. of the Sandbox. Any advice?

Kind regards,

You can pass a --ledgerid option to the sandbox. If it has the same ledgerid as the one in the database it will pick up from where it left.

1 Like

@Gary_Verhaegen Thank you for your reply. I’ll test it right away.

Not sure if that’s the issue here but there is also a typo in your example: sanbox-participant instead of sandbox-participant.

I think it’s also worth pointing out that neither the docker container here nor the persistence in Sandbox are intended or supported for production usage. For that, either use the docker container for Daml on SQL if you have a license for that or build your own based on the JAR available on github releases.

@Gary_Verhaegen Thank you so much. Works great. Everything persisted.

@cocreature Yes, I’m well aware. This is just to demo. But I’d like to keep the data for a few days since we would like to query the data from the contract for the next few days. And thank you for the reply.

Could someone expand on this topic? I’m trying to run the SDK sandbox on docker in order to achieve a highly repeatable integration test on developer workstations and in CI/CD. I’ve tried a number of different image versions, but I’m always getting errors. My environment is Mac OS with Docker Desktop v4.30.0 and Rosetta amd64 emulation on Apple Silicon enabled.

$ docker run --platform linux/amd64 --rm -it -p 6865:6865  digitalasset/daml-sdk:2.8.7 daml sandbox

Starting Canton sandbox.
# A fatal error has been detected by the Java Runtime Environment:
#  SIGSEGV (0xb) at pc=0x00007ffffee30049, pid=27, tid=62
# JRE version: OpenJDK Runtime Environment (11.0.22+7) (build 11.0.22+7-post-Ubuntu-0ubuntu222.04.1)
# Java VM: OpenJDK 64-Bit Server VM (11.0.22+7-post-Ubuntu-0ubuntu222.04.1, mixed mode, sharing, tiered, compressed oops, g1 gc, linux-amd64)
# Problematic frame:
# V  []  BasicMatcher::match(methodHandle const&)+0x69
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
# An error report file with more information is saved as:
# /home/daml/hs_err_pid27.log
# If you would like to submit a bug report, please visit:
Port file was not written to '/tmp/extra-dir-83839128165597/canton-portfile.json' before process exit with ExitFailure (-6)

My apologies, it looks like my issue is a more widely spread Rosetta problem on the Sonoma 14.5 Mac OS. That said, an arm64-compatible SDK image would be greatly appreciated by those of us on newer Macs.