5 ms·

Rocket is tied to systemd, that will definitely spawn some interesting discussions. https://github.com/coreos/rocket/blob/9b79880d915f63e73891088fa3b7c32e98870

by darren0 12y ago

Rocket is tied to systemd, that will definitely spawn some interesting discussions. https://github.com/coreos/rocket/blob/9b79880d915f63e73891088fa3b7c32e98870914/stage1/init.go#L29 https://github.com/coreos/rocket/blob/9b79880d915f63e7389108...

robszumski 12y ago
The great part of having a spec separate from the runtime is that Rocket can use systemd, but other compatible tools won't have to.
- tknaup 12y ago
  This part is super important for Rocket support in Mesos and other things that run containers.
philips 12y ago
It isn't tied to systemd. The stage1 that is in the current prototype uses systemd to monitor and fork processes but we would love to see other stage1's that configure other process runners. For example configure and run a qemu-kvm filesystem as the container. Also, even though it is using systemd to monitor and fork processes a design goal is to run on all Linux's that have a modern Kernel.
- teacup50 12y ago
  What about non-Linux platforms (FreeBSD, Mac OS X with a kext)? One thing that I believe Docker has failed at is in taking a purely declarative approach to image definition; rather than specifying the packages that are assembled/inserted to create the container, Docker ships around non-portable Linux binaries.
  - tachion 12y ago
    I second that. At the begining Docker people were mentioning adding FreeBSD Jails support, what seemed to me an awesome thing, a platform independent containerization middleware, but recently they just seemt to forget about it and they're doing only linux-centric things - what a shame.
    - bcantrill 12y ago
      Yes, but the Docker Remote API allows for a great deal of implementation freedom -- including running on a different OS substrate. We're doing this with sdc-docker[1] to run Docker on top of SmartOS and in a SmartOS container, and the Docker folks have been incredibly supportive. Despite the rhetoric, Rocket appears to be much more bound to the OS platform than Docker -- and given @philips' comment that "part of the design difference is that rocket doesn't implement an API"[2], this binding appears to be deliberate. [1] https://github.com/joyent/sdc-docker https://github.com/joyent/sdc-docker [2] https://news.ycombinator.com/item?id=8682798 https://news.ycombinator.com/item?id=8682798
      - cbsmith 12y ago
        It depends on how you look at it. The Docker Remote API provides an abstraction on the OS substrate and definitely binds you a lot more to Docker and their model. The "rocket doesn't implement an API" means all that it isn't really doing much more than kicking off the container and using the existing OS substrate to manage everything else. I can see where for SmartOS & Windows the Docker approach is more flexible. If someone has already settled on Linux, but they have their own ideas about how to manage containers within Linux that have nothing to do with CoreOS, the Rocket model is going to leave them much more flexibility.
      - jacques_chester 12y ago
        Have you ever considered doing a Warden backend for SmartOS? It'd make Cloud Foundry run out of the box, as I understand it. Disclaimer: while I work on CF, I'm not that close to the Warden nitty-gritty.
- darren0 12y ago
  The app container specification has socket activation in it. This is going to essentially tie it to systemd. Otherwise you will need another daemon running to do the socket activation, but then that would seem to be a "fundamentally flawed" execution model.
  - cbsmith 12y ago
    You may be shocked to discover that socket activation is actually a pretty old idea, and can even be found on non-Linux platforms. systemd embraces it in a pretty big way, but I can't see a problem getting the app containers to work with one of the other socket activation models.
    - darren0 12y ago
      And you may be surprised that I ran socket activation well over 15 years ago, so yes I'm well aware of the approach. The comment is more around the fact that in CoreOS's post they seems to harp on the security of a daemon process running as root that is responsible for spawning containers. What I'm saying is that with socket activation you will essentially have that again. Rocket can only work around it today because they have systemd as PID 1 running as root doing the socket activation.
      - cbsmith 12y ago
        With capabilities there is no need to have privileges beyond port binding and (possibly) userid assignment, no?
  - philips 12y ago
    Socket activation isn't mandated and completely optional. If an application detects it didn't get its sockets it can certainly just start listening instead if it wishes.
  - lew21 12y ago
    Socket activation does not need systemd in any way. You can launch any socket-activated daemon with https://github.com/LEW21/sdlaunch https://github.com/LEW21/sdlaunch - without any dependence on systemd.

by darren0 12y ago

robszumski 12y ago

The great part of having a spec separate from the runtime is that Rocket can use systemd, but other compatible tools won't have to.

tknaup 12y ago
This part is super important for Rocket support in Mesos and other things that run containers.

philips 12y ago

It isn't tied to systemd. The stage1 that is in the current prototype uses systemd to monitor and fork processes but we would love to see other stage1's that configure other process runners. For example configure and run a qemu-kvm filesystem as the container. Also, even though it is using systemd to monitor and fork processes a design goal is to run on all Linux's that have a modern Kernel.

teacup50 12y ago
What about non-Linux platforms (FreeBSD, Mac OS X with a kext)? One thing that I believe Docker has failed at is in taking a purely declarative approach to image definition; rather than specifying the packages that are assembled/inserted to create the container, Docker ships around non-portable Linux binaries.
- tachion 12y ago
  I second that. At the begining Docker people were mentioning adding FreeBSD Jails support, what seemed to me an awesome thing, a platform independent containerization middleware, but recently they just seemt to forget about it and they're doing only linux-centric things - what a shame.
  - bcantrill 12y ago
    Yes, but the Docker Remote API allows for a great deal of implementation freedom -- including running on a different OS substrate. We're doing this with sdc-docker[1] to run Docker on top of SmartOS and in a SmartOS container, and the Docker folks have been incredibly supportive. Despite the rhetoric, Rocket appears to be much more bound to the OS platform than Docker -- and given @philips' comment that "part of the design difference is that rocket doesn't implement an API"[2], this binding appears to be deliberate. [1] https://github.com/joyent/sdc-docker https://github.com/joyent/sdc-docker [2] https://news.ycombinator.com/item?id=8682798 https://news.ycombinator.com/item?id=8682798
    - cbsmith 12y ago
      It depends on how you look at it. The Docker Remote API provides an abstraction on the OS substrate and definitely binds you a lot more to Docker and their model. The "rocket doesn't implement an API" means all that it isn't really doing much more than kicking off the container and using the existing OS substrate to manage everything else. I can see where for SmartOS & Windows the Docker approach is more flexible. If someone has already settled on Linux, but they have their own ideas about how to manage containers within Linux that have nothing to do with CoreOS, the Rocket model is going to leave them much more flexibility.
    - jacques_chester 12y ago
      Have you ever considered doing a Warden backend for SmartOS? It'd make Cloud Foundry run out of the box, as I understand it. Disclaimer: while I work on CF, I'm not that close to the Warden nitty-gritty.
darren0 12y ago
The app container specification has socket activation in it. This is going to essentially tie it to systemd. Otherwise you will need another daemon running to do the socket activation, but then that would seem to be a "fundamentally flawed" execution model.
- cbsmith 12y ago
  You may be shocked to discover that socket activation is actually a pretty old idea, and can even be found on non-Linux platforms. systemd embraces it in a pretty big way, but I can't see a problem getting the app containers to work with one of the other socket activation models.
  - darren0 12y ago
    And you may be surprised that I ran socket activation well over 15 years ago, so yes I'm well aware of the approach. The comment is more around the fact that in CoreOS's post they seems to harp on the security of a daemon process running as root that is responsible for spawning containers. What I'm saying is that with socket activation you will essentially have that again. Rocket can only work around it today because they have systemd as PID 1 running as root doing the socket activation.
    - cbsmith 12y ago
      With capabilities there is no need to have privileges beyond port binding and (possibly) userid assignment, no?
- philips 12y ago
  Socket activation isn't mandated and completely optional. If an application detects it didn't get its sockets it can certainly just start listening instead if it wishes.
- lew21 12y ago
  Socket activation does not need systemd in any way. You can launch any socket-activated daemon with https://github.com/LEW21/sdlaunch https://github.com/LEW21/sdlaunch - without any dependence on systemd.