Page 1 of 1

(SOLVED) support for docker containers

Posted: Sat Aug 02, 2014 3:42 pm
by davesann
I would like to see support for docker. It would be very useful for simplified application deployment.

Is this on the roadmap?

https://www.docker.com/

Thanks

Dave

Re: support for docker containers

Posted: Sun Aug 03, 2014 4:17 am
by mafredri
It would definitely be pretty neat to be able to run docker on the NAS. Although it might have a bit of a performance impact, the NAS is quite limited in power and memory, after all. For this to be feasible ASUSTOR would have to bump the kernel version they are using, Docker requires a minimum of 3.8 whereas even the newest one on AS-6 is 3.7.9.

There are even a couple of interesting web-ui's (DockerUI, Shipyard) for docker that would probably make container management quite simple.

+1 for this!

Re: support for docker containers

Posted: Sun Aug 03, 2014 7:12 am
by koodimonni
This would be awesome :)!

Re: support for docker containers

Posted: Fri Apr 15, 2016 8:49 pm
by fabo
Hi,

With ADM 2.6 beta, updated to linux 4.1 and glibc 2.22, it's a great opportunity to enable docker on Asustor NAS now.
I sent today a patch to Asustor to enable all the required kernel options and I hope it will be accepted.
In the meantime, I started to build go and docker for my NAS (AS5102T, x86 based).

Re: support for docker containers

Posted: Fri Apr 15, 2016 10:26 pm
by father.mande
Hi,

Docker is only a management tool (that hide lot of things) for reduce LXC Linux Containers
... so first step is to have IN the kernel ALL the namespace kernel modules available
... then integrate LXC
... then add Docker

Docker is a resource consumer plus a false security (marketing is the king) environment ... just to propose "packed" software but without real knowledge of what are inside ... So now lot of specialized site recommend to have a real knowledge of what is delivered before using ... it .
The marketing idea is essentially to sail new services to help you (due to the difficulty if you don't know exactly what is inside to debug ... )
The second point is the security ... in fact you are NOT in a V.M. and docker also limit the libraries use to the minimum ... so ANY hole in the security of the kernel, modules, hosts libraries, host network ... can be use to do ... something WITHOUT any visibility ...

But Docker is a real opportunity for "Professional" environment when you want to create your own "business application" and deploy it more easily (with a cost in performance (CPU, Memory and network (slowdown)) ... because if you use direct network to get better performances ... YOU MUST (and it's not do in lot of docker image) also manage the security (firewall, SSL, password, etc. ) if you use the "host network" (that also reduce the network overhead) ... you must open a door ... and redirect port to an unknown environment ... AND in this case ... any chroot or LXC using same network ... do the job with one intermediate software less ...

Docker is so confusing ... that LXC (Linux Container) group have add their own manager LXD ...

For a NAS to create "Linux distribution environment"
chroot is the more easy and accessible tool ... with the less impact on performance (ex. hx-engine is an Ubuntu chroot able to manage up to the graphic desktop interface ... )
LXC ... is a chroot with more separate resource ... so useful to limit the CPU, memory, etc. available for the "Linux Environment" ... but also imply to duplicate basic services and manage very carefully what is visible for the container ... but it's a clear way to have benefit for a reasonable cost ...
Docker is a LXC manager ... but hiding lot of things (include the chroot) in a big parse file ... but in fact you can break the container to enter in ... in a few minutes ...
... but can help if some specific case and for people wanting a service even if security is not assumed.

For Your Information :
I have already (even in double with Asustor) do a port of LXC 2.0 on Asustor NAS AS5002T under ADM 2.6 (kernel 4.1) ... and check for requirement (but based on 2.5 config file) ...
for the moment ONLY one (mandatory) directive seem to be missed in the kernel (T.B.C.) : Cgroup namespace: required

Code: Select all

root@AS5002TaPhil:/volume1/.@plugins/AppCentral/lxc/lxc-2.0/bin # CONFIG=/share/Public/GPL_Sources/linux-4.1.0-x86_64.co
nfig ./lxc-checkconfig
--- Namespaces ---
Namespaces: enabled
Utsname namespace: enabled
Ipc namespace: enabled
Pid namespace: enabled
User namespace: enabled
Network namespace: enabled
Multiple /dev/pts instances: enabled

--- Control groups ---
Cgroup: enabled
Cgroup namespace: required
Cgroup device: enabled
Cgroup sched: enabled
Cgroup cpu account: enabled
Cgroup memory controller: enabled
Cgroup cpuset: enabled

--- Misc ---
Veth pair device: enabled
Macvlan: enabled
Vlan: enabled
Bridges: enabled
Advanced netfilter: enabled
CONFIG_NF_NAT_IPV4: enabled
CONFIG_NF_NAT_IPV6: missing
CONFIG_IP_NF_TARGET_MASQUERADE: enabled
CONFIG_IP6_NF_TARGET_MASQUERADE: missing
CONFIG_NETFILTER_XT_TARGET_CHECKSUM: enabled
FUSE (for use with lxcfs): enabled

--- Checkpoint/Restore ---
checkpoint restore: enabled
CONFIG_FHANDLE: enabled
CONFIG_EVENTFD: enabled
CONFIG_EPOLL: enabled
CONFIG_UNIX_DIAG: enabled
CONFIG_INET_DIAG: enabled
CONFIG_PACKET_DIAG: enabled
CONFIG_NETLINK_DIAG: missing
File capabilities: enabled

Note : Before booting a new kernel, you can check its configuration
usage : CONFIG=/path/to/config ./lxc-checkconfig

root@AS5002TaPhil:/volume1/.@plugins/AppCentral/lxc/lxc-2.0/bin 
Philippe.
NB I have also for another NAS brand ... write a cookbook for LXC and Docker ... to get to potential users a better visibility ... so even if I am not a specialist ... I am a user of this kind of solution on NAS ... but really I will go back to LXC and use docker only for testing the new things ... and this don't change my opinion ...

Re: support for docker containers

Posted: Sun Apr 17, 2016 1:55 pm
by fabo
Hi Philippe,

Thanks for sharing your opinion. I don't want to enter in a battle of church. After all, everybody is free to work on anything they like.

Here's my personal thought on the topic:

Docker or LXC are using the same kernel features and are competing products. If we enable docker (and that's what I'm interested in), you'll get lxc kernel enablement for free. Up to the users to make their choice.

On using Docker, it isn't more complicated than LXC. Both are accessible containers technologies.

On security, well, Docker is backed up by a lot of vendors, have a lot of developers working on it, and is distro-agnostic. LXC is backed up by a single company (Canonical), well integrated into a single distribution (Ubuntu). LXC team is small and doesn't have that much contributions by 3rd parties. These aspects are important for an healthy open source project.
"so ANY hole in the security of the kernel, modules, hosts libraries, host network ... can be use to do ... something WITHOUT any visibility ...", that's true for any software ;) It isn't specific to Docker and it doesn't make LXC more secure. Any security issues that you'll have in the kernel may affect your user space application. So I'd say it's a moot point.
Main point of Docker detractors and its security is with regard to the images freely available on the internet as the users don't know necessarily how they have been built. They can contain malicious program. That's why it's highly recommended (if not mandatory) to create your own images that you control and know exactly what's inside. The competing projects (rkt, etc...) still relies on Docker but are trying to introduce a more secure images management with signing and other improvements.

Docker and LXC are competing. Both are lightweight from a resource point of view (LXC isn't more lightweight). Both rely on control groups namespaces and try to provide isolated containers.

I use Docker everyday in my job and I have no interest in LXC. Several tools provides Docker backends (Artifactory, Jenkins, etc..) while you won't have the integration with 3rd parties tooling with LXC. I'll skip the arguments about LXD, which isn't only technical but also political.

At the end of the day, I really think that users should make their choice based on unbiased information. If we can enable both on Asustor, it's a win for everybody. Do you see LXC enabled on Synology NAS? no. It's Docker.

Note: I don't work for Docker Inc. :)

Re: support for docker containers

Posted: Sun Apr 17, 2016 2:15 pm
by MikeG.6.5
I don't care either way, the work Philippe has done is leaps and bounds above what we had before.

Arguing over which is better seems silly, at this point... This gives us all a frame work, and if you want to build on it yourself to provide options, I'm sure no one is going to mind in the least.

Re: support for docker containers

Posted: Sun Apr 17, 2016 3:24 pm
by father.mande
Hi fabo,

No church .... here ... :lol: :lol:
Just a technical view ... enter in Docker (inside) ... and look at ... it's a LXC manager ... don't do a common mistake to get a "user visibility" for "the content itself" even if version after version ... they try to hide this ...

The ONLY interest for ALL company is :
sail services ... so it's ALWAYS more interesting that "Open Source free sharing project" ... and it's true not only for Docker ...
So company can offer partial or previous version in Docker ... to catch customer ... I have nothing against this ... just that people can things that it's a security approach when it's exactly against security. It's an Apple, Microsoft, IBM and others approach ... "trust me, trust me ... said the snake ... "

BUT you are free to promote, sail, applause, etc. Docker and it's 100% your right and respectable opinion ... Docker IS NOT A BAD product ... it's a good job but with a clear target announced on the Web site ... sailing services and hub
Syno ... and other (including certainly Asustor) ... want to sail box and bigger is the box better is the company result :lol: ... so docker is exactly a "fashion product" ... that target this point ... consuming ressources and customer (not consumer) infantilisation ...

I use Chroot, LXC, Docker and others tools like this, from the a long time ... (depend of arrival of each :roll: ) ... and I can have only a too personal point of view ...

BUT I encourage you and people liking Docker and other tools ... to be active as possible to get it, have it, port it ... I will be ready to be the first tester of any solution you provide for community ...

I can understand that at job ... you think it's not a political approach to don't know what is in a product but just as a consumer to use it ... But please don't consider that other are not, like you, in the "computing job" ... unfortunately or fortunately you are not alone to work everyday ... and I never said you have a "biased" view ... but using Docker without knowing risk ... if I follow your jugement ... are certainly biased no? :lol:

I am only, and no more than, a community member sharing his small work (really poor compare to ... professional like you) ... and YES I can look at others brand ... I have ... to play with ... Synology, QNAP, Asustor, WD NAS ... (I am a little stupid collector) and some other servers and desktop ... so it's NOT because a sailor said me, my software (or hardware) is a "horse" that I can not be able to see that inside it's "donkey" even if it's more interesting to present a "horse" ...

Don't be worry ... I stop anymore speaking about this ... if Asustor only get out Docker ... no problem at all ... because I can use LXC if I want (even by porting lxc tools myself) ...
If Asustor get out LXC, Docker and perhaps LXD or other ... I also applause and use it ...
and if a "professional" using every day solution ... said it's the best ... I said also yes you are true ... it's not a contest ... and I am sure that millions of peoples are better than me ... and for this community sure that lot of them don't like and never use what I try to share with us ... I work on this for my pleasure not for winning anything ... just game , play and smille ...

So even if Docker can be manipulate (for me) with caution ... I have write a (too long) document "a cookbook" for how to use it ... for the community of another NAS brand ... so I don't be against it ... :lol:

Have a nice day ...
Philippe.
NB certainly you are NOT attach to Docker ... BUT me I am attached to ... "Open Source" and "Sharing" approach ... so automatically not impartial ...

Re: support for docker containers

Posted: Wed Apr 20, 2016 5:45 pm
by fabo
Some progress (with ADM 2.6 beta kernel running on AS5102T):

Code: Select all

## Run docker daemon
# modprobe bridge
# modprobe nf_nat
# modprobe xt_conntrack
# modprobe aufs
# cgroupfs-mount
# docker daemon -H tcp://0.0.0.0:2375 -H unix:///var/run/docker.sock --storage-driver=aufs --exec-opt native.cgroupdriver=cgroupfs --dns 8.8.8.8 --dns 8.8.4.4 -g /volume1/docker

## Run docker client
# docker version
Client:
 Version:      1.11.0
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   4dc5990
 Built:        Wed Apr 13 19:36:04 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.11.0
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   4dc5990
 Built:        Wed Apr 13 19:36:04 2016
 OS/Arch:      linux/amd64
# docker info
Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 0
Server Version: 1.11.0
Storage Driver: aufs
 Root Dir: /volume1/docker/aufs
 Backing Filesystem: extfs
 Dirs: 0
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins: 
 Volume: local
 Network: bridge null host
Kernel Version: 4.1.0
Operating System: <unknown>
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 1.853 GiB
Name: AS5102T-ECC2
ID: LSXO:Q2J2:ARTW:VAP6:EWNG:BT43:2DFO:CAPZ:67NP:VFE2:UJ57:6LUE
Docker Root Dir: /volume1/docker
Debug mode (client): false
Debug mode (server): false
Registry: https://index.docker.io/v1/
WARNING: No cpu cfs quota support
WARNING: No cpu cfs period support
WARNING: bridge-nf-call-iptables is disabled
WARNING: bridge-nf-call-ip6tables is disabled
# docker run hello-world
Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
03f4658f8b78: Pull complete 
a3ed95caeb02: Pull complete 
Digest: sha256:8be990ef2aeb16dbcb9271ddfe2610fa6658d13f6dfb8bc72074cc1ca36966a7
Status: Downloaded newer image for hello-world:latest

docker: Error response from daemon: rpc error: code = 2 desc = "oci runtime error: could not synchronise with container process: pivot_root invalid argument".
In current state, we can run docker 1.11.0 and pull images from docker hub.
However, we can't run images yet and get the following error message when we try to run an image (docker run):
docker: Error response from daemon: rpc error: code = 2 desc = "oci runtime error: could not synchronise with container process: pivot_root invalid argument".

Since AUFS is the only storage driver enabled at the moment in the kernel, we also need aufs-tools package (some commands are needed by docker like auplink).

Re: support for docker containers

Posted: Mon Jul 25, 2016 12:28 am
by damien599901
solved
in App Central - beta apps