5 ms·

Sounds like a chroot with extra steps

• detaro 5y ago
  That's a way to describe pretty much all container things in a superficial way.
  • scatters 5y ago
    It's not even superficial. A chroot is a limiting case of a container that only rebinds the filesystem; or, equally, a container is a chroot that also rebinds the user namespace, process namespace, networking, etc.
    • yakubin 5y ago
      Can you escape from a mount namespace? You can escape from a chroot.
      • majewsky 5y ago
        You can change into an existing mount namespace, which is what commands like "docker exec" or "machinectl shell" do to execute a command within the mount namespace of an existing container. The container can do the same to escape its mount namespace, but it needs privileges to execute the respective namespace-changing syscall, and it needs to know which namespace to change into. I have an application in a Kubernetes-managed container which needs to do exactly this to access the host system (to open LUKS containers and mount their contents), so I have it run in privileged mode (i.e. with access to all syscalls) and give it the full host filesystem as a bind mount, so it can do: nsenter -m /host/proc/1/ns/mnt mount $DEV $PATH (The actual nsenter invocation is slightly more complicated, but that's the basic gist.) Side-note: Since there will inevitably be a comment along the lines of "but then what do you even need isolation for", I'm very explicitly using Kubernetes as a deployment mechanism only. Other pods within the same Kubernetes are strictly isolated, but this one deliberately runs with practically no isolation. But I still get the consistent environment that Kubernetes provides (rolling upgrades, log shipping, liveness probes, etc.).
• silisili 5y ago
  I know this was made tongue in cheek, but that was my first thought as well. Seems it would be more valuable for one to explain how and why it's better than a chroot, instead of redescribing how a chroot works but adding the word container.
  • cpach 5y ago
    Some pointers if anyone is curious about chroot vs other isolation techniques: https://fly.io/blog/sandboxing-and-workload-isolation/ https://fly.io/blog/sandboxing-and-workload-isolation/ https://devops.stackexchange.com/questions/2826/difference-between-chroot-and-docker https://devops.stackexchange.com/questions/2826/difference-b... For further reading, searching for ⟬docker vs chroot⟭ yields a bunch of interesting articles.
  • bjt 5y ago
    chroot just isolates the file system. A "container" (whether Docker or LXC or Podman) is a bundle of isolations that includes the filesystem as well as processes and users, and constraints on memory, CPU, networking, and kernel calls.
    • chriswarbo 5y ago
      AFAIK Docker, LXC, Podman, etc. are actually all the same underneath: they use 'runc', which chroots into a directory (along with extra restriction/config via cgroups, bind mounts, etc.). The differences between Docker, LXC, Podman, etc. are the config, management, etc. of containers; e.g. Docker abstracts over the chroot directories, using a set of content-addressed tarballs (called "images"), and provides commands for starting/stopping/listing/etc. the containers that are running.
      • bjt 5y ago
        Dating myself a little, but LXC came along well before runc. It predates Docker, and was actually wrapped by the first versions of Docker. I learned about LXC, and used it, after doing some research on how to build my own PaaS at work (pre-Docker) and reading that Heroku was using LXC for their platform. It worked decently for me, but required more in-depth knowledge of all the knobs for disk mounts and networking than Docker typically requires. You may be right that LXC has switched over to runc since then. I haven't kept up. I would be surprised though.