4 ms·

for the ignorant, why would I want to wrap docker inside docker?

y4mi 10y ago
they actually mention it in their readme. > it seemed logical and also it would really be bad if somebody did docker rm -f $(docker ps -qa) and deleted the entire OS or are you asking why anyone would want a 'docker-os', which has everything but the docker daemon as a container?
- KaiserPro 10y ago
  No no, I get the coreos idea, or providing libc, kernel docker service and nothing else. I saw that line, but since if you want to run docker at scale you'd have each execution node under the tight control of a scheduler, it seemed like a small edge case. As I said, for the ignorant such as myself why would I chose this over coreos?
magoon 10y ago
no, it's the OS services that are dockerized. so your containers won't be docker inside docked.
- ams6110 10y ago
  I still don't see any clear reason for doing this. I mean, "because we can" is interesting in a sort of academic way I guess.
  - magoon 10y ago
    Containers compartmentalize runtimes with their dependencies, eliminate library and version conflicts. That's just one benefit.
cookiecaper 10y ago
This is not Docker-in-Docker. This is an OS that acts like a "container hypervisor". It provides the bare minimum for hardware interfacing and hosting containers, just as conventional hypervisor provide the bare minimum for hardware interfacing and hosting virtual machines. The benefit is that more system resources are available for your clients (containers, in this case). I haven't used RancherOS but CoreOS works mostly-fine. However, I would avoid using these things altogether because containerization sucks.
- KaiserPro 10y ago
  I'd suggest that containerisation as a principle is fine, but its not what most people want. What people want is a mainframe where a lump of code is guaranteed to run the same everytime, regardless of the machine state, and if something goes wrong with the underlying layer is self heals(or automatically punts to a new machine, state intact). What we have currently is a guarantee that the container will run, and once running will be terminated at an unknown time. Mix in distributed systems(hard) atomic state handling (also hard) and scheduling(can be hard) its not all that fun to be productive for anything other than a basic website.
tiff_seattle 10y ago
for science
hobarrera 10y ago
To separate all the OS-service containers, from the user-service containers. I guess this is mostly so you don't accidentally delete OS-containers (like ntpd) when trying to delete all your containers.

y4mi 10y ago

they actually mention it in their readme. > it seemed logical and also it would really be bad if somebody did docker rm -f $(docker ps -qa) and deleted the entire OS or are you asking why anyone would want a 'docker-os', which has everything but the docker daemon as a container?

KaiserPro 10y ago
No no, I get the coreos idea, or providing libc, kernel docker service and nothing else. I saw that line, but since if you want to run docker at scale you'd have each execution node under the tight control of a scheduler, it seemed like a small edge case. As I said, for the ignorant such as myself why would I chose this over coreos?

magoon 10y ago

no, it's the OS services that are dockerized. so your containers won't be docker inside docked.

ams6110 10y ago
I still don't see any clear reason for doing this. I mean, "because we can" is interesting in a sort of academic way I guess.
- magoon 10y ago
  Containers compartmentalize runtimes with their dependencies, eliminate library and version conflicts. That's just one benefit.

cookiecaper 10y ago

This is not Docker-in-Docker. This is an OS that acts like a "container hypervisor". It provides the bare minimum for hardware interfacing and hosting containers, just as conventional hypervisor provide the bare minimum for hardware interfacing and hosting virtual machines. The benefit is that more system resources are available for your clients (containers, in this case). I haven't used RancherOS but CoreOS works mostly-fine. However, I would avoid using these things altogether because containerization sucks.

KaiserPro 10y ago
I'd suggest that containerisation as a principle is fine, but its not what most people want. What people want is a mainframe where a lump of code is guaranteed to run the same everytime, regardless of the machine state, and if something goes wrong with the underlying layer is self heals(or automatically punts to a new machine, state intact). What we have currently is a guarantee that the container will run, and once running will be terminated at an unknown time. Mix in distributed systems(hard) atomic state handling (also hard) and scheduling(can be hard) its not all that fun to be productive for anything other than a basic website.

tiff_seattle 10y ago

for science

hobarrera 10y ago

To separate all the OS-service containers, from the user-service containers. I guess this is mostly so you don't accidentally delete OS-containers (like ntpd) when trying to delete all your containers.