Is there a guide around that teaches you to build a container from scratch with chroot, namespaces and cgroups?
The What, Why and How of Containers
41–50 of 132 posts
Re: The What, Why and How of Containers
#42If you use chroot to run something, it's interesting how the dynamic libs you need to get in place grows until you are mirroring a whole linux in a subtree. It gives you a sense for how you end up with containers. One thing that is wild to me is how nix solves this problem, of things needing to be linked together. It doesn't solve it with containers, but by rewriting the location of the links in the executable to be…
Funny - it looks like you’re being downvoted for asking what I think is a very natural question. It’s one I’ve asked before; have we just created a more elaborate statically-linked executable via containerization? In the end, Docker/OCI seems like the universal Linux package manager. I’m sure I don’t have the full picture since I’m far more ops than dev though.
For me as a mere user, wanting to run some homelab services, the main advantages to containers are that they make updates easier (don't need to wait for distro), and it makes it much clearer where configuration and data lives, easing backup and rollback by orders of magnitude.
Static vs dynamic linking is an implementation detail as far as I'm concerned. If all the dynamic libs needed were in a well-defined location it wouldn't matter that much.
Re: The What, Why and How of Containers
#43Earlier quoted context omitted.
[flagged]
Grab a developer off the street and ask them how Docker works. Most of them will have no idea.
Considering my peers, same for system administrators/SRE/Operations people
I'm the resident expert because I bothered to piece together "containers" = "applied namespaces"
Re: The What, Why and How of Containers
#44Computing is an endless cycle of inventing ways to isolate code in a private machine, followed by inventing ways to make it easier for those machines to interoperate.
> inventing ways to isolate code in a private machine
Reminds me of how Alan Kay described OOP as communicating objects, where each object is a kind of computer.
"I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages."
Re: The What, Why and How of Containers
#45Earlier quoted context omitted.
Funny - it looks like you’re being downvoted for asking what I think is a very natural question. It’s one I’ve asked before; have we just created a more elaborate statically-linked executable via containerization? In the end, Docker/OCI seems like the universal Linux package manager. I’m sure I don’t have the full picture since I’m far more ops than dev though.
I don't think so. Instead we created an artifact which can live inside an OS, but cannot see and touch to the rest of the OS. CGroups is a deceptively powerful mechanism. You can isolate a process resource wise (X cores, Y amount of memory, Z amount of swap), network wise (a different virtual network adapter with its own IP, bandwidth limits, etc.) and FS wise (running in its own filesystem with devices it can see).…
You can put any given process is a cgroup. It doesn't have to be a container.
If you have a statically linked executable, setup the cgroup for it as you will. No containers needed. You can namespace is as well.
No `FROM X` `RUN Y` dockerfile stuff needed.
Re: The What, Why and How of Containers
#46Is there a guide around that teaches you to build a container from scratch with chroot, namespaces and cgroups?
It's not a tutorial, but "Docker implemented in around 100 lines of Bash" might help: https://news.ycombinator.com/item?id=33218094
Re: The What, Why and How of Containers
#47Is there a guide around that teaches you to build a container from scratch with chroot, namespaces and cgroups?
I did one with just the chroot part:
https://earthly.dev/blog/chroot/
Liz Rice has a good talk about the cgroups and namespaces.
Re: The What, Why and How of Containers
#48If you use chroot to run something, it's interesting how the dynamic libs you need to get in place grows until you are mirroring a whole linux in a subtree. It gives you a sense for how you end up with containers. One thing that is wild to me is how nix solves this problem, of things needing to be linked together. It doesn't solve it with containers, but by rewriting the location of the links in the executable to be…
One issue with static linking is that your dependencies will likely have critical CVEs over time. If you keep all your libraries separate on the filesystem, you can just do a "apt update; apt upgrade", and you will have all the latest patches. This will patch security issues in e.g. libssl or libc for all your applications that are dynamically linked against this shared libraries, which can be quite a few. In static binaries, the version of the libraries is not obvious from the outside. If you have, for example, 100 fully static binaries, these can come in 100 different major/minor/patch level versions of their dependencies. You now have to patch each binary separately by upgrading and recompilation 100 times to patch all your static binaries, that requires much more time and energy.
Re: The What, Why and How of Containers
#49Earlier quoted context omitted.
I don't think so. Instead we created an artifact which can live inside an OS, but cannot see and touch to the rest of the OS. CGroups is a deceptively powerful mechanism. You can isolate a process resource wise (X cores, Y amount of memory, Z amount of swap), network wise (a different virtual network adapter with its own IP, bandwidth limits, etc.) and FS wise (running in its own filesystem with devices it can see).…
You can put any given process is a cgroup. It doesn't have to be a container. If you have a statically linked executable, setup the cgroup for it as you will. No containers needed. You can namespace is as well. No `FROM X` `RUN Y` dockerfile stuff needed.
> You can put any given process is a cgroup. It doesn't have to be a container.
Yes, I run many programs inside cgroups, but not in containers.
> If you have a statically linked executable, setup the cgroup for it as you will. No containers needed. You can namespace is as well.
Yes.
> No `FROM X` `RUN Y` dockerfile stuff needed.
Yes. dockerfile only sets up the chroot in an overlayfs and fires up the "container" using mechanisms present in the kernel already.
As I said on another comment, quoting myself:
> Docker just made the interface more practical, and built the ecosystem around it.
Re: The What, Why and How of Containers
#50Earlier quoted context omitted.
Disclaimer: I'm not a strong containerization proponent. The good part of containers is you isolating the thing you're running. I'm very against resource waste, but if I can spend 90MB on a container image instead of installing a complete software stack to run a task which is executed weekly and runs for 10 minutes, I'd prefer that. Plus, I can create a virtual network and storage stack around the container(s) if I n…
>>> To me, all that points at containers being in some way a solution to Dynamic linking. And maybe an over the top solution. ... Should we be doing more static linking? Not even depending on libc? What are the challenges with that? >> but it's a ruby application and I need to install the whole stack of things, plus the gems. Instead I containerize it, and keep my system clean. There was a bit of drama recently with…
> Bottles devs saying "we only want the appimage as a distribution method".
Good for them having wishes, yet free software doesn't work that way in most cases. :)
> I see containers as a means of distributing software
That's OK. Docker is a tool, and tools can be held and used in many ways.