Remove layers of abstraction on-top of docker-compose

[joe-p]

Problem

Right now the sandbox script is a layer of abstraction that exists on-top of docker-compose. If you look at the sandbox channel in discord, most of the issues people have are specific to the sandbox script and issues with docker itself is hard to debug due to it being all embedded within the sandbox script. Having this script offers an attractive ease-of-use, but when it doesn't work it can make things more complicated. Debugging a sandbox problem not only requires docker knowledge, but also sandbox-specific knowledge. In the end, the sandbox script is just another thing that requires maintenance and I'm not sure if it really adds much value.

Solution

I think it will be beneficial if we remove the abstraction layer that sandbox provides and instead rely on docker-compose for the management and configuration of sandbox services. At a high level, this means there is no more sandbox script that needs to be maintained and problems will be easier to debug. It also makes the experience a little easier to configure for those that are already familiar with docker.

For reference, I've created a fork of sandbox that does exactly this. I've also added some functionality in this repo that I think could be beneficial

• Two files for configuration. .env and docker-compose.yml, both of which are native to the docker environment
• Easier file management with bind mounts (copyFrom and copyTo can be confusing)
• Runs with specific UID:GID, making sharing files inside and outside of the container even easier
• Seemless VSCode devcontainer compatibility (simply clone directly as .devcontainer)
• Shell with more functionality (add git-prompt.sh and mount ~/.gitconfig) for in container development
• Option to install PyTeal

Most of this accomplished with docker-compose.yml and Dockerfile changes and is configurable with the docker-compose.yml and .env

Dependencies

Any work on this would require someone familiar with docker, docker-compose, and sandbox. Ideally I think some of the sandbox functionality could be implemented as in-container helper scripts.

Urgency

Low. Sandbox is still usable and support is easy enough to get on the discord, but making the sandbox simpler will be beneficial in the long run.

[robdmoore]

You might find this interesting: https://github.com/MakerXStudio/algorand-sandbox-dev

[winder]

@joe-p do you think supported docker images also solve this proablem? Eventually I'd like to use those in place of the custom docker build the sandbox script is currently using.

[joe-p]

@winder Yeah I think official images that have a high level of runtime configurability would be good. I think the important thing is that you have a reasonable amount of configuration in docker-compose.yml via ENV and then any further configuration can be done via mounting config files (ie. custom node configuration).

See https://github.com/joe-p/sandbox-v2 as an example. All configuration can be done via the docker-compose file. We could theoretically still have a layer of abstraction on top of it, but it isn't necessary.