4 ms·

It's nothing like that at all. It's just a minimal operating system with a small install image. The only special thing it does is replace the init process with

It's nothing like that at all. It's just a minimal operating system with a small install image. The only special thing it does is replace the init process with a system-docker process to reduce the overhead of resources used by the operating system. The point isn't really to "run more Docker". It's to eliminate as much operating system overhead as possible, so that nearly every CPU cycle and byte of memory usage is dedicated to your containers.

dkarapetyan 9y ago
You realize how you're not making any sense. Docker is another abstraction so it can not be better in terms of resource usage than running whatever process you are now running inside docker. You literally have more overhead with the docker approach in terms of all resource utilization. You now have all the overhead of an OS and then you are layering docker on top of it. The OS has not gone away. It is still managing processes, memory, files, sockets, networking, etc.
- elcritch 9y ago
  Rather it's replacing systems like systemd and various other system daemons with the docker equivalents. For example why run a network supervision daemon if dockerd or equivalent handle all the important complex pieces of networking via container orchestration? Why have a local package manager, or system port mapper.
  - dkarapetyan 9y ago
    I'm pretty horrified by the argument you're making. The reason all those things are separate things is because they serve orthogonal functions. By bundling all of that into a single binary how have you improved things? You've increased the attack surface, reduced stability, increased complexity, and made things a lot harder to test and verify.
    - developer2 9y ago
      Have you ever used Rancher OS? Not trying to sound like a judgemental jerk, but the arguments you are making are clearly from someone who is commenting based on a preconceived notion of what it is, without knowing what it really is. Instead of combating others in comments because they can't succinctly describe it to you, go research it instead. If you don't care enough to look into it, you shouldn't be caring to argue in the comments.
      - dkarapetyan 9y ago
        Not to sound like a judgmental and experienced jerk back but how many container orchestration systems have you built and run in production? Since I have first hand experience in building, hacking, and working around all the limitation of a few such systems deployed into production environments I think I know all there is to know about RancherOS. By all means continue to run RancherOS and let me know how that goes when you're managing a few hundred to maybe upwards of a thousand VMs and then layering a container orchestration system with the underlying VMs coming and going on an on-demand basis. I remember thinking "I really wish I had more of this docker stuff in the OS itself. Because dealing with all the caching, volume mounting, and instability in userspace is so much fun". I'll await your report because clearly my experience with these systems and all the ways they fail is too combative for your taste. There are a few things they don't tell you on the brochure when you're drinking the kool-aid.
    - elcritch 9y ago
      Well can't speak to the horror of the design as I'm not a really proponent of that particular design. Just clarifying the parent's statement a little. Though the rancheros design is not particularly worse than what systemd does now, based on my recent experiences. It's all one giant (poorly?) implemented binary either way. From a pragmatic standpoint I don't see a difference. What's the difference between one opaque binary vs another, except possibly one's written in Go which I find easier to read if needed and is less likely to have buffer overruns. Really cutting out one crapshoot seems logical as at least there's only one system you'd need to learn. Still I'd like a non-either of those options approach. Personally I prefer running SmartOS and Triton containers. Their system seem much more stable than any of the Linux containers and/or systemd setups I've tried. It sticks a bit more to traditional unix design which makes sense to me. Items like the caching layer for containers build on ZFS snapshots, a well tested file system layer, rather than ad hoc userland tools. Triton also runs all of the orchestration layers in separate zones (containers) like RancherOS is trying to build. But each component is a simple(ish) service, it's easy to `zfs list` and check on a container's file system or fix it or backup, etc. Same with SVC or VM machine management which both have small simple tools that do one thing pretty well. To that note, docker has been moving towards breaking out and using smaller daemons haven't they? If that continues it might turn out more modular in the end wherein RancherOS would end up being more modular than systemd Linux setups. Imho, that'd be great.

dkarapetyan 9y ago

You realize how you're not making any sense. Docker is another abstraction so it can not be better in terms of resource usage than running whatever process you are now running inside docker. You literally have more overhead with the docker approach in terms of all resource utilization. You now have all the overhead of an OS and then you are layering docker on top of it. The OS has not gone away. It is still managing processes, memory, files, sockets, networking, etc.

elcritch 9y ago
Rather it's replacing systems like systemd and various other system daemons with the docker equivalents. For example why run a network supervision daemon if dockerd or equivalent handle all the important complex pieces of networking via container orchestration? Why have a local package manager, or system port mapper.
- dkarapetyan 9y ago
  I'm pretty horrified by the argument you're making. The reason all those things are separate things is because they serve orthogonal functions. By bundling all of that into a single binary how have you improved things? You've increased the attack surface, reduced stability, increased complexity, and made things a lot harder to test and verify.
  - developer2 9y ago
    Have you ever used Rancher OS? Not trying to sound like a judgemental jerk, but the arguments you are making are clearly from someone who is commenting based on a preconceived notion of what it is, without knowing what it really is. Instead of combating others in comments because they can't succinctly describe it to you, go research it instead. If you don't care enough to look into it, you shouldn't be caring to argue in the comments.
    - dkarapetyan 9y ago
      Not to sound like a judgmental and experienced jerk back but how many container orchestration systems have you built and run in production? Since I have first hand experience in building, hacking, and working around all the limitation of a few such systems deployed into production environments I think I know all there is to know about RancherOS. By all means continue to run RancherOS and let me know how that goes when you're managing a few hundred to maybe upwards of a thousand VMs and then layering a container orchestration system with the underlying VMs coming and going on an on-demand basis. I remember thinking "I really wish I had more of this docker stuff in the OS itself. Because dealing with all the caching, volume mounting, and instability in userspace is so much fun". I'll await your report because clearly my experience with these systems and all the ways they fail is too combative for your taste. There are a few things they don't tell you on the brochure when you're drinking the kool-aid.
  - elcritch 9y ago
    Well can't speak to the horror of the design as I'm not a really proponent of that particular design. Just clarifying the parent's statement a little. Though the rancheros design is not particularly worse than what systemd does now, based on my recent experiences. It's all one giant (poorly?) implemented binary either way. From a pragmatic standpoint I don't see a difference. What's the difference between one opaque binary vs another, except possibly one's written in Go which I find easier to read if needed and is less likely to have buffer overruns. Really cutting out one crapshoot seems logical as at least there's only one system you'd need to learn. Still I'd like a non-either of those options approach. Personally I prefer running SmartOS and Triton containers. Their system seem much more stable than any of the Linux containers and/or systemd setups I've tried. It sticks a bit more to traditional unix design which makes sense to me. Items like the caching layer for containers build on ZFS snapshots, a well tested file system layer, rather than ad hoc userland tools. Triton also runs all of the orchestration layers in separate zones (containers) like RancherOS is trying to build. But each component is a simple(ish) service, it's easy to `zfs list` and check on a container's file system or fix it or backup, etc. Same with SVC or VM machine management which both have small simple tools that do one thing pretty well. To that note, docker has been moving towards breaking out and using smaller daemons haven't they? If that continues it might turn out more modular in the end wherein RancherOS would end up being more modular than systemd Linux setups. Imho, that'd be great.