71–80 of 87 posts
Earlier quoted context omitted.
I don't know, I find "Linux Containers" to be sufficiently generic as Linux has native support for them. LXD/LXC, Docker, etc, are simply tools built upon that.
I agree. Most people who read "Linux Containers" are going to think of Docker, not LXD.
A little bit of education about container systems in linux[1]. A container system is typically made up a number of components: isolation layer : the piece that limits privileges and resource usage. (On linux, this is usually handled by cgroups and the kernel, but could also be handled by something like kvm for vm-based containers) raw container configuration : Given an image and some metadata (like cpu limits), launc…
I feel like podman is proving that you don't really need the api daemon and a porcelain over runc with a one-off process supervisor is sufficient for a good number of workloads. Being able to run containers like any other process and leave the lifecycle management to systemd is actually really nice.
A little bit of education about container systems in linux[1]. A container system is typically made up a number of components: isolation layer : the piece that limits privileges and resource usage. (On linux, this is usually handled by cgroups and the kernel, but could also be handled by something like kvm for vm-based containers) raw container configuration : Given an image and some metadata (like cpu limits), launc…
Earlier quoted context omitted.
Given certain initial conditions, this statement moves the current process (and any process it subsequently creates) into a control group, which meets minimal definitions of containerization.
It really doesn't. I would say that "unshare -mpf ; pivot_root" matches the most minimal definition of a container more accurately than joining a cgroup (it's an isolated system which can't directly interact with the host). Otherwise you'd have to argue that configuring rlimits actually makes your shell a container, which is too much of a stretch (for me at least).
rlimit is sort of a thing but it's not actually effective so to me it's not part of the picture. If unix limits worked, Google would not have needed to contribute cgroups before deploying Borg. Indeed, in this LWN article which is actually about control groups, they call control groups "containers". Just shows there is not a universal meaning of the term.
The earliest control groups patch I can find says "We use the term container to indicate a structure against which we track and charge utilization of system resources like memory, tasks etc for a workload." It doesn't say anything about isolation, namespaces, or security, but it uses the term container to describe resource control.
Earlier quoted context omitted.
Are you saying because of bugs or are you saying it's by design? I explicitly said ignore OS bugs.
Yes you did, but that’s as useless as a discussion based on ignoring the laws of thermodynamics.
Earlier quoted context omitted.
I didn't notice that, thanks! Although I imagine they can't do much with /dev etc. unless they get sudo.
Unless you're using user namespaces (which this doesn't) then root inside a container is equal to root outside the container. You don't even need access to /dev, because the container process could just mknod(2) any device and access it with full permissions. This is only possible in this example because the container has the full capability set (including CAP_MKNOD) and the devices cgroup hasn't been configured to r…
A little bit of education about container systems in linux[1]. A container system is typically made up a number of components: isolation layer : the piece that limits privileges and resource usage. (On linux, this is usually handled by cgroups and the kernel, but could also be handled by something like kvm for vm-based containers) raw container configuration : Given an image and some metadata (like cpu limits), launc…
> Container systems seem to have a relatively complex abstraction over what is a relatively simple architecture Yep, it's really not rocket science. I find that very useful and usable resource isolation (i.e. most of what I actually use containers for) can be achieved with processes + cgroups + chroot. Unfortunately networking complicates things since DNS doesn't return ports, only IP addresses. A local DNS service t…
DNS can return IP:Port pairs, using SRV records instead of A/AAAA records, but for some reason it never took off :( I guess because these days everything uses HTTP as the transport layer, and HTTP doesn’t support it?
Earlier quoted context omitted.
It really doesn't. I would say that "unshare -mpf ; pivot_root" matches the most minimal definition of a container more accurately than joining a cgroup (it's an isolated system which can't directly interact with the host). Otherwise you'd have to argue that configuring rlimits actually makes your shell a container, which is too much of a stretch (for me at least).
I think that just underscores my point, which is that containment means different things to different people. To me, it means only the resource limiting features from cgroups. I have no use for namespaces, bind mounts, virtual network interfaces, or any of that stuff. In my application all that stuff is either pointless or harmful. But to you, container means at least PID and mount namespaces. rlimit is sort of a thi…
> Just shows there is not a universal meaning of the term.
Yes, there is. That meaning has just evolved since 2007.