Adding docker submodule

[Trinketer22]

Hey!
I think this one might come in handy to temporary relief most of the pain that comes with binaries/toncli versions issues.
At least till the day when pip install toncli will just work with all the new features.
New tests are far better than the old ones s people using toncli, are going to need to switch to those ASAP.
Otherwise legacy code is going to continue to grow and cause pain to everyone.
Only way i see to quickly and reliably do it at this stage is moving towards containerized development.
What i'm proposing with this PR is to make some toncli approved container for people to work from.

I doesn't have to be my container, because it's not tested much yet at the moment, but it would be much easier to start if there was one.

Also there is probably better way to let people know about the existence of the new tests.
Not many people read docs/advanced till they feel completely lost.

I think it would be much better if there was at least a separate paragraph in quickstart more insistingly leading towards how tests work.
Or maybe even on the front README.md

Has at least to do with issue:#36

[tvorogme]

Wow! Awesome work!

Our team has been very busy with blockchain indexing, we literally wrote a lot of new code in monorepo for blockchain indexing. We are already at the finish line. Soon we will make important updates for toncli and updates will come out more often :)

I think the idea of running toncli in such an easy way from a container is very cool!

We will check docker. Maybe it's better to use docker-registry for easy to pull it?

[Trinketer22]

We will check docker. Maybe it's better to use docker-registry for easy to pull it?

For sure!

Idea is to publish it to the registry at some point, so people could just pull it as is without having to go through build process.

Glad that you liked the idea!
I think that's the most reliable way to do it that doesn't complicate things much for the newcomers.
It should even be WSL compatible (have not tested it in WSL docker) and the container usage is platform abstract.
I hope that would help a lot with all the platform specific issues people are facing.

[Trinketer22]

Maybe i should add tonlibjson to it?

[tvorogme]

@Trinketer22 will be great! Also, could you publish it to docker-hub, so we can provide short way of install?

[Trinketer22]

Also, could you publish it to docker-hub, so we can provide short way of install?

That's definitely the plan, but isn't it too soon to do it?
I'm thinking on adding args for Debug/Release builds.
Also maybe an arg for building from custom ton source tree.
It probably doesn't make much sense to have separate tags for with/without tonlibjson right?
@tvorogme See i don't use the tools that much myself yet. So it's a little bit confusing what makes sense and what not.

[tvorogme]

From dev-chat discussion: https://t.me/tondev/89471

I think that it's cool to have some slim docker image (around 80mb) and have bash script for fast usage

[Trinketer22]

I don't know if it even possible to get it that small, but maybe some android distro like alpine linux as a base could help.
Won't be WSL compatible in that case but yeah, could be helpfull for sure.
Currently Release build with Ubuntu base is around 400MB.
I'll release the binary image on dockerhub soon.
Going to have to figure out all of the github actions so that if any of the dependencies is updated,-image gets built and published.

[tvorogme]

@Trinketer22 we also will release docker-hub version of ton-k8s, maybe we need to cooperate?

Check out @TrueCarry work of optimization size: https://github.com/disintar/ton-k8s/pull/1/files#diff-458cb69809c9c61256fda581953e47fc00d34e6ea44cadbfd164577c0edfdcc3

Slim version is around 80mb :)

[TrueCarry]

I don't know if it even possible to get it that small, but maybe some android distro like alpine linux as a base could help. Won't be WSL compatible in that case but yeah, could be helpfull for sure. Currently Release build with Ubuntu base is around 400MB. I'll release the binary image on dockerhub soon. Going to have to figure out all of the github actions so that if any of the dependencies is updated,-image gets built and published.

python-slim is ~50mb, while python-bullseye 300+mb. Changing base really helps. Main problem is you need gcc to install some python requirements, but you can actually install and remove it in one step and it won't waste any space in resulting image.

[Trinketer22]

Ok challenge accepted

[Trinketer22]

python-slim is ~50mb

python:3.10-slim is actually 126MB.
python:3.10-alpine however is indeed 48.7MB.

Via using alpine base i've managed so far to get 136MB resulting image.
Main issue is that binaries are C++ runtime dependent.
In this particular image i'm using compiler-rt which is a stripped down c/c++ runtime version for RTOS.
Plus libatomic from g++ runtime.
Maybe there is a way to get rid of libatomic but it's only =<2MB.
Also maybe static build is the way to get rid of runtime but i don't see that happening without changing cmake build scripts.
Commits/reports welcome!

[Trinketer22]

Next steps are:

1. Publishing it on dockerhub
2. Setup github pipelines to automatically rebuild and publish on dependency git branches update.

[Trinketer22]

Here we go!
https://hub.docker.com/r/trinketer22/func_docker/tags
Compressed size turned out to be MUCH lower.

[tvorogme]

Thanks for work, added to installation.md in 353d8db