5 ms·

Sadly there is no new things to support FreeBSD Jails, a competitive (and much more matured) container technology than Docker's default LXC (despite earliers me

by tachion 12y ago

Sadly there is no new things to support FreeBSD Jails, a competitive (and much more matured) container technology than Docker's default LXC (despite earliers mentions of plans for supporting FreeBSD in version 1.0)...

nickstinemates 12y ago
Some of the core abstractions are there. Get started. We'll follow :)
yebyen 12y ago
I think that what you're asking for (a Jails execution driver) is really _not_ so far out of bounds, mostly given that FreeBSD has really good support for binary compatibility and Linux emulation, so FreeBSD is actually the _one_ good platform to try this with (one of the best candidate platforms?) but one thing, that people all keep repeating this about LXC makes me grumpy... The LXC driver is _not_ the default anymore as of ~0.9, Docker switched to pluggable execution and storage drivers at that time and shortly after, started using the new "native" driver for execution (which does not use LXC at all, but uses the underlying kernel services directly, like namespacing and cgroups, that are also used by LXC). The execution driver LXC provides the same experience from before the pluggable driver model happened, and it's still available but not the default anymore. Am I being pedantic, is my information wrong, or has this just not been heavily publicized before (maybe it's actually a very small distinction and I should stop repeating it?)
- justincormack 12y ago
  I don't think the binary compatibility and Linux emulation will be anything useful - there is no emulation of containers, and no one would want to run a Linux process in their container. But yes, some framework is there.
  - yebyen 12y ago
    I think the point would be not to use linux containers or any abstraction around the parts that fuel LXC, but to use BSD Jails on the idea that they are "battle tested" Just as you might not trust Docker's native driver more than LXC, if you most cynically regarded LXC as an "example of a failed marketing experiment" and then Docker as "the first notable consumer of cgroups and linux kernel namespacing, and certainly too new yet to trust with anything important" -- but there are plenty of high-profile consumers of the FreeBSD jails and it is trusted by many to keep processes separate. I mentioned emulation and binary compatibility, maybe because it's the thing that's missing in many other cases that wind up being responsible for alternative platform support getting back-burnered and second-classed in Docker community. Where there might be lots of people who want to use Docker on i386, it's not supported probably most of all because it would lead to a bad user experience and fragmentation. Binary images are all built for amd64 linux at this point. I bypassed the warnings, I use it, I'm not bothered that I have to rebuild for my specific architecture. The docker users at large can still use my images, and maybe I'm a bad citizen for pushing images compiled this way, but it works. Similarly there are probably a lot of people testing Docker on ARM, but they can't use any of the pre-built containers that are provided by the majority docker community, tested and supported. Their architecture is even farther out from being supported. They have the drawback that they can neither receive blood from "O" nor give to "AB" if you'll indulge the analogy of images to blood types, they have one of those weird blood types that doesn't even register in the statistics with a reasonably sized sample. Anemic, maybe. If you had a jails execution driver, you certainly don't have to use Linux processes or binary emulation, you can build your containers with a BSD base and BSD toolchain. The point is that in theory, you probably could skip that step and get working with existing binary images built from Linux distributions. It would quickly be a better "alternative platform" than any of the other existing contenders (different architectures) who you could already see in the docker ecosystem at this point; it could probably run many existing container images out of the box, on a FreeBSD host with amd64 architecture. The contained software really shouldn't care what execution driver keeps it isolated, at least in theory. In practice someone with more knowledge than me can probably say what a bad idea this is, maybe because either "congrats, you just invented Virtualization" or "wrong, jails won't keep those processes separated."
    - 12y ago

by tachion 12y ago

nickstinemates 12y ago

Some of the core abstractions are there. Get started. We'll follow :)

yebyen 12y ago

I think that what you're asking for (a Jails execution driver) is really _not_ so far out of bounds, mostly given that FreeBSD has really good support for binary compatibility and Linux emulation, so FreeBSD is actually the _one_ good platform to try this with (one of the best candidate platforms?) but one thing, that people all keep repeating this about LXC makes me grumpy... The LXC driver is _not_ the default anymore as of ~0.9, Docker switched to pluggable execution and storage drivers at that time and shortly after, started using the new "native" driver for execution (which does not use LXC at all, but uses the underlying kernel services directly, like namespacing and cgroups, that are also used by LXC). The execution driver LXC provides the same experience from before the pluggable driver model happened, and it's still available but not the default anymore. Am I being pedantic, is my information wrong, or has this just not been heavily publicized before (maybe it's actually a very small distinction and I should stop repeating it?)

justincormack 12y ago
I don't think the binary compatibility and Linux emulation will be anything useful - there is no emulation of containers, and no one would want to run a Linux process in their container. But yes, some framework is there.
- yebyen 12y ago
  I think the point would be not to use linux containers or any abstraction around the parts that fuel LXC, but to use BSD Jails on the idea that they are "battle tested" Just as you might not trust Docker's native driver more than LXC, if you most cynically regarded LXC as an "example of a failed marketing experiment" and then Docker as "the first notable consumer of cgroups and linux kernel namespacing, and certainly too new yet to trust with anything important" -- but there are plenty of high-profile consumers of the FreeBSD jails and it is trusted by many to keep processes separate. I mentioned emulation and binary compatibility, maybe because it's the thing that's missing in many other cases that wind up being responsible for alternative platform support getting back-burnered and second-classed in Docker community. Where there might be lots of people who want to use Docker on i386, it's not supported probably most of all because it would lead to a bad user experience and fragmentation. Binary images are all built for amd64 linux at this point. I bypassed the warnings, I use it, I'm not bothered that I have to rebuild for my specific architecture. The docker users at large can still use my images, and maybe I'm a bad citizen for pushing images compiled this way, but it works. Similarly there are probably a lot of people testing Docker on ARM, but they can't use any of the pre-built containers that are provided by the majority docker community, tested and supported. Their architecture is even farther out from being supported. They have the drawback that they can neither receive blood from "O" nor give to "AB" if you'll indulge the analogy of images to blood types, they have one of those weird blood types that doesn't even register in the statistics with a reasonably sized sample. Anemic, maybe. If you had a jails execution driver, you certainly don't have to use Linux processes or binary emulation, you can build your containers with a BSD base and BSD toolchain. The point is that in theory, you probably could skip that step and get working with existing binary images built from Linux distributions. It would quickly be a better "alternative platform" than any of the other existing contenders (different architectures) who you could already see in the docker ecosystem at this point; it could probably run many existing container images out of the box, on a FreeBSD host with amd64 architecture. The contained software really shouldn't care what execution driver keeps it isolated, at least in theory. In practice someone with more knowledge than me can probably say what a bad idea this is, maybe because either "congrats, you just invented Virtualization" or "wrong, jails won't keep those processes separated."
  - 12y ago