It is currently Sat Nov 28, 2020 10:55 am
All times are UTC + 8 hours

(SOLVED) support for docker containers

Docker containers wrap a piece of software in a complete filesystem that contains everything needed to run: code, runtime, system tools, system libraries – anything that can be installed on a server. This guarantees that the software will always run the same, regardless of its environment.

(SOLVED) support for docker containers

Postby davesann » Sat Aug 02, 2014 3:42 pm

I would like to see support for docker. It would be very useful for simplified application deployment.

Is this on the roadmap?


Posts: 1
Joined: Sat Aug 02, 2014 3:36 pm

Re: support for docker containers

Postby mafredri » Sun Aug 03, 2014 4:17 am

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!
Hi, I'm new here. Looking to be active in the community and help with development :).
Storage: AS-604T with 3GB RAM (Kingston KVR1333D3S8S9/2G)
User avatar
Posts: 371
Joined: Sat Mar 22, 2014 8:41 am

Re: support for docker containers

Postby koodimonni » Sun Aug 03, 2014 7:12 am

This would be awesome :)!
Posts: 4
Joined: Sun Aug 03, 2014 6:49 am

Re: support for docker containers

Postby fabo » Fri Apr 15, 2016 8:49 pm


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).
Posts: 17
Joined: Wed Apr 13, 2016 1:15 pm

Re: support for docker containers

Postby father.mande » Fri Apr 15, 2016 10:26 pm


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/
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
FUSE (for use with lxcfs): enabled

--- Checkpoint/Restore ---
checkpoint restore: enabled
File capabilities: enabled

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


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 ...
AS5202T /AS5002T / AS202TE / AS1002T
My Blog specific to my APKG :
User avatar
Posts: 1047
Joined: Sat Sep 12, 2015 2:55 am

Re: support for docker containers

Postby fabo » Sun Apr 17, 2016 1:55 pm

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. :)
Posts: 17
Joined: Wed Apr 13, 2016 1:15 pm

Re: support for docker containers

Postby MikeG.6.5 » Sun Apr 17, 2016 2:15 pm

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.
Posts: 911
Joined: Fri May 15, 2015 1:56 am

Re: support for docker containers

Postby father.mande » Sun Apr 17, 2016 3:24 pm

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 ...
NB certainly you are NOT attach to Docker ... BUT me I am attached to ... "Open Source" and "Sharing" approach ... so automatically not impartial ...
AS5202T /AS5002T / AS202TE / AS1002T
My Blog specific to my APKG :
User avatar
Posts: 1047
Joined: Sat Sep 12, 2015 2:55 am

Re: support for docker containers

Postby fabo » Wed Apr 20, 2016 5:45 pm

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:// -H unix:///var/run/docker.sock --storage-driver=aufs --exec-opt native.cgroupdriver=cgroupfs --dns --dns -g /volume1/docker

## Run docker client
# docker version
 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

 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
 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
Docker Root Dir: /volume1/docker
Debug mode (client): false
Debug mode (server): false
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).
Posts: 17
Joined: Wed Apr 13, 2016 1:15 pm

Re: support for docker containers

Postby damien599901 » Mon Jul 25, 2016 12:28 am

in App Central - beta apps
Storage: AS7004T & AS5002T
Laptop: Apple MACBOOK Pro OS X El Capitan & Windows 10
Media Player: ASUSTOR NAS with Kodi 16 Beta & HD_Engine 1 (thanks Fathe_Mande)
Portable: iPhone 6S Plus, iPad Mini 2 & iPad Air
Posts: 558
Joined: Mon Dec 30, 2013 2:53 am

Return to Docker

  • You cannot post new topics in this forum
    You cannot reply to topics in this forum
    You cannot edit your posts in this forum
    You cannot delete your posts in this forum
    You cannot post attachments in this forum
  • Who is online

    Users browsing this forum: No registered users and 0 guests