LinuxQuestions.org - [SOLVED] Getting started with Docker

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - Getting started with Docker (https://www.linuxquestions.org/questions/slackware-14/getting-started-with-docker-4175528172/)

Getting started with Docker

First question: is Docker incompatible with i386? If so, why SBo doesn't say a thing about it?

Anyways, I want to see what this "Linux containers" thing is about and decided to give Docker a try.

I've built it from SBo, created a docker group, assigned my user to it with:

Code:

# groupadd -r -g 281 docker

# usermod -a -G docker pedro

Started docker with:

Code:

/etc/rc.d/docker start

Went to start its daemon with:

Code:

docker -d

Which returns me:

Code:

2014/12/13 14:29:44 docker daemon: 1.3.1 4e9bbfa; execdriver: native; graphdriver:

[4f935441] +job serveapi(unix:///var/run/docker.sock)

2014/12/13 14:29:44 The Docker runtime currently only supports amd64 (not 386). This

will change in the future. Aborting.

Quote:

Originally Posted by moisespedro (Post 5284066)

First question: is Docker incompatible with i386?

Code:

2014/12/13 14:29:44 The Docker runtime currently only supports amd64 (not 386). This will change in the future. Aborting.

In what way didn't you just answer your own question I wonder?..

Quote:

Originally Posted by moisespedro (Post 5284066)

My bad. I'll make a note to update the SBo. Docker has been linux-x86_64 only, for essentially silly reasons. Hopefully that will loosen up soon. In the meantime the SBo should note that it is only for x86_64 presently.

Quote:

Originally Posted by unSpawn (Post 5284370)

In what way didn't you just answer your own question I wonder?..

I just wanted to be sure because there was nothing in SBo and it compiled fine.

EDIT: @vbatts, any good alternatives?

If you are wanting to use docker, alternatives include waiting. It is not for lack of attention that i386 is not supported yet. Lots of eyes are on it. I suspect it will start opening up after the new year.
The issue is largely around the docker-registry support. The patch to allow the local docker daemon to use different arches (arm too) is a one liner. and if you are not pushing to the hub, perhaps that is an okay use-case.

Otherwise, you can look into the lxc toolchain, and not use docker for the time being, if ix86 is a current requirement.

Code:

commit aeb3113f2a1e6096f240bb9bb4b3de8d31e5ef73

Author: Vincent Batts <vbatts@hashbangbash.com>

Date:  Mon Dec 15 06:38:01 2014 +0700



    system/docker: Add note about requirement.

    

    Signed-off-by: Willy Sudiarto Raharjo <willysr@slackbuilds.org>



diff --git a/system/docker/README b/system/docker/README

index 7afec75..d9c5e78 100644

--- a/system/docker/README

+++ b/system/docker/README

@@ -28,3 +28,5 @@ well, then append "swapaccount=1" to your kernel's parameters. This is often in

 /etc/lilo.conf, on the "append" variable.

 

 NOTE: google-go-lang is only needed at compile time - not needed for runtime.

+

+Docker doesn't support x86, only x86_64

diff --git a/system/docker/docker.info b/system/docker/docker.info

index fdcd39f..9039305 100644

--- a/system/docker/docker.info

+++ b/system/docker/docker.info

@@ -1,10 +1,10 @@

 PRGNAM="docker"

 VERSION="1.3.1"

 HOMEPAGE="https://docker.io/"

-DOWNLOAD="https://github.com/docker/docker/archive/v1.3.1.tar.gz"

-MD5SUM="098c366f9c8eb82ba537b93eec66303e"

-DOWNLOAD_x86_64=""

-MD5SUM_x86_64=""

+DOWNLOAD="UNSUPPORTED"

+MD5SUM=""

+DOWNLOAD_x86_64="https://github.com/docker/docker/archive/v1.3.1.tar.gz"

+MD5SUM_x86_64="098c366f9c8eb82ba537b93eec66303e"

 REQUIRES="google-go-lang"

 MAINTAINER="Vincent Batts"

 EMAIL="vbatts@hashbangbash.com"

You can approximate around 80% of what a Docker container can give you (that is, lacking isolated networking,) via other tools. I remember using things like schroot on Debian back in the day; looking for Slackware port, it seems that vbatts already got that covered too in http://www.slackware.com/~vbatts/schroot/ .

To cover the remaining 20%, you might want to play around with OpenVZ Virtual Ethernet devices and/or Virtual Distributed Ethernet...

true, but chroot and schroot do not handle the cgroups and namespaces. You could wrap some things up with unshare(1) and other tools, but there is a good deal more than just a change root. I do like schroot, and have since made the same workflow for myself using docker images instead. Having a way to distribute the image is much nicer now.