is it practical to replace pve's lxc totally with docker?

minlearn

it seems that docker is more lighter and simpler than lxc
it is more like a sandbox than a vm

so why not pve switch to it?

minlearn

omg
why i posted in provider cat?
please move it to general cat
thank you

lukast__

While LXC and Docker both use Linux namespaces and cgroups, they're quite different as LXC contains a complete distribution with a startup system and often sshd, but Docker (AFAIK) only has the daemons.
And the root filesystems are also different, IIRC Docker's root filesystems are readonly.
(If I'm wrong feel free to correct me, never used Docker and never will.)

minlearn

@lukast__ said:
While LXC and Docker both use Linux namespaces and cgroups, they're quite different as LXC contains a complete distribution with a startup system and often sshd, but Docker (AFAIK) only has the daemons.
And the root filesystems are also different, IIRC Docker's root filesystems are readonly.
(If I'm wrong feel free to correct me, never used Docker and never will.)

precisely

minlearn

@lukast__ said:
While LXC and Docker both use Linux namespaces and cgroups, they're quite different as LXC contains a complete distribution with a startup system and often sshd, but Docker (AFAIK) only has the daemons.
And the root filesystems are also different, IIRC Docker's root filesystems are readonly.
(If I'm wrong feel free to correct me, never used Docker and never will.)

you are quite right

just because lxc relies on emulating linux rootfs details , it turned out too heavy
docker however，just lit itself upper a bit beyond kernel, so it turned out light and to be fit for "sandbox runtime"

in fact, docker implement has wider applicable areas and domains than lxc

lukast__

@minlearn said: just because lxc relies on emulating linux rootfs details , it turned out too heavy

No? What about LXC is "too heavy"?

@minlearn said: docker however，just lit itself upper a bit beyond kernel, so it turned out light and to be fit for "sandbox runtime"

Docker is by no means "light". Just checked the source code:

$ find . -name \*.go -exec wc -l {} \; | sed 's/ .*//' | awk '{s+=$1} END {print s}'
1949259

Nearly 2M LoC!

emgh

I love Docker

darkimmortal

systemd-nspawn is where it’s at if you want a halfway sane container system

minlearn

@lukast__ said:

@minlearn said: just because lxc relies on emulating linux rootfs details , it turned out too heavy

No? What about LXC is "too heavy"?

@minlearn said: docker however，just lit itself upper a bit beyond kernel, so it turned out light and to be fit for "sandbox runtime"

Docker is by no means "light". Just checked the source code:

$ find . -name \*.go -exec wc -l {} \; | sed 's/ .*//' | awk '{s+=$1} END {print s}'
1949259

Nearly 2M LoC!

while sharing the same kernel and namespaces/cgroups basis:

docker requires no systemd, no init in rootfs, just a executable path as daemon

but lxc rootfs requires explict init mechanism and systemd/systemd alternatives just like normal linux rootfs，services rooted in systemd can be a very huge network

docker has 2M LoC codebase, mostly of them are transaction level api, not implement level logics, the basic parts are still thin as lxc.

lukast__

@minlearn said: but lxc rootfs requires explict init mechanism and systemd/systemd alternatives just like normal linux rootfs，services rooted in systemd can be a very huge network

From https://linuxcontainers.org/lxc/manpages/man5/lxc.container.conf.5.html:

lxc.init.cmd
   Absolute path from container rootfs to the binary to use as init. This mostly makes sense for lxc-start. Default is /sbin/init.