4 ms·

That's horse-crap. There is no standard in this case. That we even have a first stab at a standard is a good thing.

by bmurphy1976 11y ago

falcolas 11y ago
Aside from Docker containers (which are broadly consumed by competing container engines), rkt containers, the systemd "Container Interface" specification, and the LXC containers, you're right. There's no standard. /s
- icebraining 11y ago
  From what I can tell, systemd's interface is not a container spec, but a way for Docker et all to launch systemd inside their own containers. And LXC doesn't define a container format either, it's more of a lower-level API, which is why Docker itself can use it to run their own containers.
  - nailer 11y ago
    > a way for Docker et all to launch systemd inside their own containers. Should that read: "a way for Docker et all to launch systemd units inside their own containers." ?
    - icebraining 11y ago
      No, from what I can tell, it's actually to launch systemd itself inside a container. For example, from the document: To allow systemd (and other code) to identify that it is executed within a container, please set the $container= environment variable for PID 1 in the container to a short lowercase string identifying your implementation. With this in place the ConditionVirtualization= setting in unit files will work properly. Example: "container=lxc-libvirt"
  - vezzy-fnord 11y ago
    systemd itself has its own system container tool called nspawn, though again like LXC it doesn't have any image format, serialization or anything of the sort. rkt originally used nspawn as its backend (still has it in, I think).
  - falcolas 11y ago
    LXC: http://man7.org/linux/man-pages/man5/lxc.container.conf.5.html http://man7.org/linux/man-pages/man5/lxc.container.conf.5.ht... A per-container configuration file, stored in the container directory. Similar to the "tarball with metadata" of Docker, but you'll have to roll your own layers (or do it the old fashioned way & hardlink common files between containers). Systemd: You're right on the container interface front, my apologies. However: http://www.freedesktop.org/software/systemd/man/systemd-nspawn.html#-i http://www.freedesktop.org/software/systemd/man/systemd-nspa... specifies an image format (basically a bootable ISO or some such). It's not as self-contained as a docker image (still need to specify a bunch of parameters), but it's available.
  - tobbyb 11y ago
    That's just wrong. Please have a look at the LXC or Systemd nspawn websites [1] or our guide to container technology [2] LXC is not 'low level' capabilities as Docker erroneously refers to it on its website or a 'low level api'. [3] The LXC project in development since 2009 on which Docker was based, and now Systemd-nspawn give you pretty advanced OS containers with mature management tools, full stack linux networking, multiple storage options including support for btrfs, zfs, LVM, Overlayfs, cloning, snapshotting and a wide choice of container OS templates. It also offers unprivileged containers that let's non root users run containers, which is a big step forward for container security, and is currently working on live migration of containers. Docker takes that as a base, limits the container OS template to a single app, builds the containers with layers of aufs and enforces storage separation. [4] It's not rocket science, you can do this yourself with overlayfs and LXC in minutes. [5] Docker is an opinionated way to use containers. You don't need to adopt Docker to get the benefits of containers. You adopt Docker to get the benefits of Docker. A lot of the messaging, hype and marketing conflates the 2 and it suits the docker ecosystem to do that but it does not benefit informed discussion. Nspawn is a systemd container project, which is similar to LXC in that it gives you OS containers, not layered single app containers. Rkt is based on Nspawn if I am not mistaken. It's curious that LXC project largely responsible for the development of most of the container technology available today is not part of this. I feel most folks who can move beyond the wild misconceptions floating around to try LXC will find it's significantly simpler to use. We provide a lightweight VM image with a complete LXC environment based on Alpine Linux for those who are interested. It's 80 MB and available for Virtualbox, VMWare and KVM at https://www.flockport.com/flockbox https://www.flockport.com/flockbox Disclosure I run flockport.com which provides an app store for servers based on LXC. [1] https://linuxcontainers.org https://linuxcontainers.org [2] https://www.flockport.com/a-new-users-guide-to-container-technology/ https://www.flockport.com/a-new-users-guide-to-container-tec... [3] https://www.flockport.com/guides https://www.flockport.com/guides [4] https://www.flockport.com/lxc-vs-docker https://www.flockport.com/lxc-vs-docker [5] https://www.flockport.com/experimenting-with-overlayfs-and-lxc/ https://www.flockport.com/experimenting-with-overlayfs-and-l...
    - deleted 11y ago
      [deleted]
    - 11y ago

That's horse-crap. There is no standard in this case. That we even have a first stab at a standard is a good thing.

Aside from Docker containers (which are broadly consumed by competing container engines), rkt containers, the systemd "Container Interface" specification, and the LXC containers, you're right. There's no standard. /s

icebraining 11y ago
From what I can tell, systemd's interface is not a container spec, but a way for Docker et all to launch systemd inside their own containers. And LXC doesn't define a container format either, it's more of a lower-level API, which is why Docker itself can use it to run their own containers.
- nailer 11y ago
  > a way for Docker et all to launch systemd inside their own containers. Should that read: "a way for Docker et all to launch systemd units inside their own containers." ?
  - icebraining 11y ago
    No, from what I can tell, it's actually to launch systemd itself inside a container. For example, from the document: To allow systemd (and other code) to identify that it is executed within a container, please set the $container= environment variable for PID 1 in the container to a short lowercase string identifying your implementation. With this in place the ConditionVirtualization= setting in unit files will work properly. Example: "container=lxc-libvirt"
- vezzy-fnord 11y ago
  systemd itself has its own system container tool called nspawn, though again like LXC it doesn't have any image format, serialization or anything of the sort. rkt originally used nspawn as its backend (still has it in, I think).
- falcolas 11y ago
  LXC: http://man7.org/linux/man-pages/man5/lxc.container.conf.5.html http://man7.org/linux/man-pages/man5/lxc.container.conf.5.ht... A per-container configuration file, stored in the container directory. Similar to the "tarball with metadata" of Docker, but you'll have to roll your own layers (or do it the old fashioned way & hardlink common files between containers). Systemd: You're right on the container interface front, my apologies. However: http://www.freedesktop.org/software/systemd/man/systemd-nspawn.html#-i http://www.freedesktop.org/software/systemd/man/systemd-nspa... specifies an image format (basically a bootable ISO or some such). It's not as self-contained as a docker image (still need to specify a bunch of parameters), but it's available.
- tobbyb 11y ago
  That's just wrong. Please have a look at the LXC or Systemd nspawn websites [1] or our guide to container technology [2] LXC is not 'low level' capabilities as Docker erroneously refers to it on its website or a 'low level api'. [3] The LXC project in development since 2009 on which Docker was based, and now Systemd-nspawn give you pretty advanced OS containers with mature management tools, full stack linux networking, multiple storage options including support for btrfs, zfs, LVM, Overlayfs, cloning, snapshotting and a wide choice of container OS templates. It also offers unprivileged containers that let's non root users run containers, which is a big step forward for container security, and is currently working on live migration of containers. Docker takes that as a base, limits the container OS template to a single app, builds the containers with layers of aufs and enforces storage separation. [4] It's not rocket science, you can do this yourself with overlayfs and LXC in minutes. [5] Docker is an opinionated way to use containers. You don't need to adopt Docker to get the benefits of containers. You adopt Docker to get the benefits of Docker. A lot of the messaging, hype and marketing conflates the 2 and it suits the docker ecosystem to do that but it does not benefit informed discussion. Nspawn is a systemd container project, which is similar to LXC in that it gives you OS containers, not layered single app containers. Rkt is based on Nspawn if I am not mistaken. It's curious that LXC project largely responsible for the development of most of the container technology available today is not part of this. I feel most folks who can move beyond the wild misconceptions floating around to try LXC will find it's significantly simpler to use. We provide a lightweight VM image with a complete LXC environment based on Alpine Linux for those who are interested. It's 80 MB and available for Virtualbox, VMWare and KVM at https://www.flockport.com/flockbox https://www.flockport.com/flockbox Disclosure I run flockport.com which provides an app store for servers based on LXC. [1] https://linuxcontainers.org https://linuxcontainers.org [2] https://www.flockport.com/a-new-users-guide-to-container-technology/ https://www.flockport.com/a-new-users-guide-to-container-tec... [3] https://www.flockport.com/guides https://www.flockport.com/guides [4] https://www.flockport.com/lxc-vs-docker https://www.flockport.com/lxc-vs-docker [5] https://www.flockport.com/experimenting-with-overlayfs-and-lxc/ https://www.flockport.com/experimenting-with-overlayfs-and-l...
  - deleted 11y ago
    [deleted]
  - 11y ago