-
Notifications
You must be signed in to change notification settings - Fork 158
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use a single docker image for all sandbox components as an alternative to the current docker-compose structure #84
Comments
Yes, I pretty much support this. It would be great to have everything in a single docker container. 👍 |
It would be great for testing. |
Thanks for the feedback everyone. I can honestly say that this use case never occurred to us. I don't know if we'd support this in sandbox, but maybe it's worth supporting directly. Could I ask a follow-up question: |
Hi @winder , these are the answers:
We're using almost all endpoints on algod and
It would be useful to have algod and indexer preferably inside an extendible docker image (i.e. one based on Alpine with apk or Ubuntu with apt-get). We don't use kdm at the moment.
We would extend the docker to include the test environment. For example, in case of npm project, if the name of the unified image is sandbox, we would use:
Thank you! |
Having access to kmd so you can programmatically get hold of the default wallet is handy too. |
Problem
The problem with the current Docker Compose structure of the Sandbox occurs when there is necessity to execute the sandbox inside a Docker environment if DinD (Docker-in-Docker) is not available.
For example, Gitlab.com CI/CD allows executions of pipeline code inside a given Docker image, and doesn't allow Docker-in-Docker images. Using a single image that exposes all the components and can be uploaded to a repository, it would be possible to extend it (i.e. using apk if based on Alpine Linux) and prepare it for Test execution.
Solution
Prepare a single Dockerfile that merges all the components (postgres DB, indexer and algod) in one single image.
This image would be usable with standard
docker build
anddocker run <image_name>
command.The solution could be implemented without impacts on the current structure, just as a separate component and not as a substitution of the current one. Current working software that uses the current Sandbox structure would not be affected.
Dependencies
None
Urgency
Not urgent, but useful in an ongoing project.
The text was updated successfully, but these errors were encountered: