Docker in Linux From Scratch

jr_bob_dobbs · 08-19-2017, 08:19 PM

Has anyone built Docker in their Linux From Scratch system?

jr_bob_dobbs · 08-26-2017, 12:37 PM

wow, I guess not.

I've found a slack-build for docker. The dependency tree (ascertained by reading the description on each slackbuild) flattens out to this (the idea is that I should compile in this order):

* google-go-lang
* libseccomp
* runc
* containerd
* tini
* docker-proxy
* docker

I am unclear if the gnu version of go can be used instead of google-go-lang. As I have that version already installed, I'm hoping it can. My gut feeling is that it cannot.

jr_bob_dobbs · 09-05-2017, 12:58 PM

So I've re-ordered the dependency tree and compiled libseccomp and tini first. No problems.

Planned: runc, containerd, docker-proxy and then docker itself. I have stopped, not because of compilation problems, but from a concern that perhaps docker is not necesarily a good idea. My original intent is to use it to run the few programs that I just can't compile within LFS. My concern is ... is this potentially messy, in a way that cannot be reverted? Part of what I like about building my own Linux is the feeling of control. Things only go in if I want them or if they are a needed dependency of something that I want. I have an uneasy feeling.

p.s. Googling mentions people putting an LFS into docker, not the other way around. So that was less than helpful.

jr_bob_dobbs · 09-15-2017, 06:01 PM

Got runc in. The slackbuild provided needed hints.

Near as I can tell from browsing the .md pages (don't ask why they are not man pages (really, don't ask)) runc may be enough to run several container formats. Something about taking an OS and tarring it up into a "bundle" (flashback to macintosh?) and then a json file (which seems to be a configuration file that describes the os in the image and sets the privileges, what it can access outside the container, that sort of thing) and then "runc create" and then another call of runc to have a specific program within the container run. This is all new territory to me.

jr_bob_dobbs · 09-16-2017, 07:15 AM

So after reading up on runc, I realized there were still gaps in my knowledge. Time to just try stuff. I've got a tar of a smallish Linux OS, previously made using the boot-root project. Said "image" worked in a VM once I added a kernel and modules. For a container, don't need those.

Code:

# mkdir /hsc/first_run/rootfs
# cd /hsc/first_run/rootfs

I then unzip .tar file to rootfs.
Then I run runc to auto-generate the config file

Code:

# runc spec

there is now a file "config.json"

Code:

# runc run
"container id cannot be empty"
# runc run foofy
 "rootfs (/hsc/first_run/rootfs/rootfs) does not exist"
# runc run .
 "rootfs (/hsc/first_run/rootfs/rootfs) does not exist"
# cd ..
# runc run rootfs
 "JSON specification file config.json not found"
# cp rootfs/config.json ./
# runc run rootfs
:0: starting container process caused ":0: applying cgroup configuration for process caused \"mountpoint for cgroup not found\""

So close. Arg.

mid-kid · 09-19-2017, 09:09 AM

@jr_bob_dobbs:

If you're concerned about running programs you want to try before "committing" them to your machine, you might be better out just installing debian or something in a chroot. It's fairly easy to set up with debootstrap, and a simple script for entering/leaving the chroot. Hell, LXC might even be a pretty good option for this.
Docker is fine, but it only adds in value that you can manage and create containers in a stateless way; one you're done with them, you remove them, and you can just make a new one from a debian base image whenever you need one again. You don't have to worry about messing up the container because if you do, you simply start over from your base image. You could emulate this yourself with overlayfs and some scripting, but it's simply not as handy as docker.

As for building Docker, I did this myself recently, mostly following the Arch PKGBUILD: https://git.archlinux.org/svntogit/c...ackages/docker
Why Arch, instead of SlackBuilds? Because the SlackBuilds for Docker are, frankly, a mess. Most of the dependencies of docker aren't stable yet, and need weird compilation instructions. This PKGBUILD includes everything docker needs, with the correct versions for everything.
I made my own packaging script, in which I tried to clean up Arch's build script: http://chunk.io/midkid/9c263adc34f244cc835f72c402030423
The only dependencies for this are go, libseccomp, and optionally, go-md2man.
The build process consists of simply setting up a correct GOPATH, and building, in order: Docker (engine, cli), runc, containerd, tini and proxy. Some of these are picky about where you run make from, such as runc, and how you call go build, such as gen-manpages.

EDIT: Oh, I forgot to mention, there's actually a quick&dirty way of installing Docker, but it involves a script that calls upon git, which is why it isn't really suitable for the packaging script standards a lot of distros try to uphold. This method is described in VoidLinux' script: https://github.com/voidlinux/void-pa...ocker/template
It consists of downloading docker-ce, and in the components/engine directory calling hack/make.sh with AUTO_GOPATH=1, along with hack/dockerfile/install-binaries.sh, which you'll have to modify using sed if you want to install to a prefix other than /usr/local.
Of course, this won't include manpages and as such is a far cry from a proper packaging method for Docker.

ChrootDoot · 10-01-2017, 11:08 PM

Successfully compiled on a LinuxFromScratch system, following the VoidLinux script, and compilation itself was relatively easy. Getting Docker to run, however, took some troubleshooting. Here are some tips for anyone else having difficulty, which worked on my end:

- Docker (Go) did not find ca-certs in its default location, it needed a symlink to one of the locations specified here: https://github.com/golang/go/blob/ma.../root_linux.go

- This script is useful for installing necessary kernel modules: https://github.com/moby/moby/blob/ma...heck-config.sh