Add docker package

[FreddieOliveira]

Another package from docker suite.

---

Edit: the whole docker suite. Includes:

1. Binary docker. This is the docker client provided by docker-cli
2. Binary dockerd. This is the server daemon provided by moby
3. Binary docker-proxy provided by Libnetwork

[FreddieOliveira]

@xeffyr Finally done. Please, check the files.

[ghost]

@FreddieOliveira Don't put wrapped binaries to $PREFIX/bin, unless they are needed for specific use-cases. We have $PREFIX/libexec for that.

And where the Docker client (utility docker) ? It usually comes with the daemon package. Here is a list of binaries on Ubuntu:

/usr/bin/docker
/usr/bin/docker-init
/usr/bin/docker-proxy
/usr/bin/dockerd

[FreddieOliveira]

Don't put wrapped binaries to $PREFIX/bin, unless they are needed for specific use-cases. We have $PREFIX/libexec for that.

Hmm, didn't know that. But $PREFIX/libexec isn't in the $PATH, how to proceed? I wanted a script that mounts the cgroups and calls the dockerd binary.

---

Edit: nevermind, just saw that the 8086tiny does exactly that. Now I get it.

---

Here is a list of binaries on Ubuntu:

/usr/bin/docker
/usr/bin/docker-init
/usr/bin/docker-proxy
/usr/bin/dockerd

Oh yes, now we must make some organizational decisions. containerd package was already added, there's still 4 packages to go:

1. Tini (which provides the docker-init binary)
2. Docker-cli (which provides the docker binary)
3. Dockerd (which provides the dockerd binary)
4. Libnetwork (which provides the docker-proxy binary)

So, we can make a separated package for each and then create a metapackage called docker that will install all 4 of them as dependencies. Or, make a single package docker that will compile all 4 of them in the build.sh script.

Which choice do you prefer?

[ghost]

What about relationship between these components? I guess at least some of them, like dockerd and docker-cli, should be of same/specific version.

[FreddieOliveira]

Dockerd daemon and docker-cli indeed share the same version. But, despite walking togheter, they have to be downloaded from differents repositories. If it's ok downloading two packages inside the same build.sh we may build them together and forget about the metapackage.

Tini can be considered a separated package. It doesn't depend on any other docker and can be installed separately, just like containerd. Here's the Ubuntu package of tini: https://packages.ubuntu.com/focal/tini. Just one observation here: tini has to be compiled statically to work with docker. Building statically on device can be accomplished by installing ndk-multilib. I tested the static binary and it worked well. Is it possible to cross compile static binaries as well? Is it safe? Is it portable?

Libnetwork is actually a bigger project than the simple docker-proxy binary. It's also a library that can be imported and used in go language. The docker-proxy binary is just a small part of the whole. But, since we only need this small binary and not the whole package, it can be compiled together with the dockerd daemon (inside the build.sh) instead of having a separated package for it.

[ghost]

Packaging software built from multiple repos is ok, see libllvm package.

[ghost]

I tested the static binary and it worked well. Is it possible to cross compile static binaries as well? Is it safe? Is it portable?

Static binaries are safe but not portable.

Why: because provided static libc is for specific Android OS version and some functionality may not work for others. That is for example DNS resolver. Its interface has been changed multiple times between OS versions and that cause errors when binary using such functionality is being executed on OS which doesn't match libc Android API level.

Non-portability is one of reasons why programs should be linked dynamically and CGO should be enabled for Golang.

[FreddieOliveira]

Packaging software built from multiple repos is ok

Cool, just finished rewriting the build.sh script. Now it builds the

• docker client binary from the docker-cli
• dockerd daemon from moby
• docker-proxy binary from libnetwork

Please, check the files again.

Static binaries are safe but not portable

Hmm, so now we have a little problem: the --init flag when creating a container with docker-cli won't work, because it requires a static tini binary called docker-init. What this flag does is to make the init process be the first process of the container being ran. Having init as the parent of all other proccess ensures that a proper clean up inside the container is made regarding zombie process. But, I call it a "little problem" because this is not always needed and in practice it's kind of rare to see anyone using this. Here's the words from the tini creator:

Obviously, it's not always needed (e.g. I run http://apt-browse.org/ in a dozen Docker containers, and only one of them uses Tini)

Taken from here.

But in anycase, do you see any solution for this?

[Grimler91]

@FreddieOliveira Is this okay to merge in your opinion? Non-critical problems can always be fixed later.

I will have a look at removing the need to override termux_step_get_source, but very nice work packaging all of this!

[ghost]

Hmm, so now we have a little problem: the --init flag when creating a container with docker-cli won't work, because it requires a static tini binary called docker-init.

docker-init can be compiled with GOOS=linux. That's seems to be the only suitable fix, considering that it is being executed inside container.

[FreddieOliveira]

@Grimler91

Is this okay to merge in your opinion?

I believe so. These are the same steps I used to build the docker I'm running right now on my phone. Everything is working fine and in my opinion the build script is nicely organized now.

I will have a look at removing the need to override termux_step_get_source

I had to overwrite it because some tarballs have the same name. Both dockerd and docker-cli are called v20.10.2.tar.gz. My version of termux_step_get_source downloads and extracts a package before moving to the next one, while the default termux_step_get_source downloads everything first and then extracts everything. So, if some tarballs have the same name they get overwritten.

nice work packaging all of this!

Thanks!

@xeffyr

docker-init can be compiled with GOOS=linux. That's seems to be the only suitable fix, considering that it is being executed inside container.

That sounds a valid idea. Tini will have its own package, since it doesn't depend on docker, so we can try that when porting it.

[Grimler91]

had to overwrite it because some tarballs have the same name

Right, that would require some improvements to the termux_step_get_source scripts and cannot be easily fixed here

[FreddieOliveira]

Cool. I will pkg install and test it.

[FreddieOliveira]

I pkg install docker and tested it for the past couple of days. Everything seems to be working correctly. #60 can finally be closed. I'll work on Tini now.

@xeffyr @Grimler91 were you able to test it?

[ghost]

@FreddieOliveira Sorry, I won't be able to test it as none of my devices is rooted.