[silverquiet]

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.

[bayindirh]

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).

It can keep your system tidy by encapsulating elaborate stacks which makes system management painful, allows deterministic operation and image generation if you tag everything with version.

Downside is you can do bad things with it like terminating HTTPS with a gateway container and talk HTTP among your backend instead of configuring tools, or writing shoddy software, and getting away with it because it works, or gets automatically restarted when it crashes 6 times a day.

I don't run every service as a container, because some services suffocate when they are in a container, but for short running things which needs system-wide changes to function, or test-driving small services before fully committing, it's a good tool to have.

However, it's abused with no end, and their popular use leaves a bad taste in your mouth.

[adamgordonbell]

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.

[bayindirh]

> 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.

[zer00eyz]

If you have a go/rust/zig binary as your application do you need a container to run it?

Maybe, but it makes less sense at that point. If your doing Node/Ruby/Python/PHP then yes the container makes sense to drag your runtime to the server...

Do containers (docker) make sense for dev. Sure, to a point. Because our dev (win/Mac) might not look like our deploy (linux).... If we move to a standardized remote dev model then docker makes less and less sense.

>> It’s one I’ve asked before; have we just created a more elaborate statically-linked executable via containerization?

The bottles project only supports their app image, as they no longer want to be responsible for supporting the disttro maintained packaged version of their product.

Yes containers are becoming a way of dealing with linking, and dependency management. Its a blunt instrument for dealing with software packaging and distribution.

[ianburrell]

The huge advantage of containers is that can use the same mechanism to run anything. Don't care if it is a single Go binary, dynamically linked binary, or Ruby interpreter and thousand files.

You might start off writing Go programs, but then need to run Postgres database for development. Or discover that need special library in some other language and easier to make its own service. Or need to run third-party service. With Docker, you run the image and don't care what's inside, and the isolation gives some assurance that won't escape.

[magicalhippo]

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.

[forgotmyinfo]

The benefit of waiting for maintainers to update your software is that you have a stronger guarantee that it won't break your system, or otherwise fubar something. Maintainers are the adults in the room saying "no, fix your shit" when sloppy developers release crap, which seems to be happening more and more frequently lately.

As for where configuration and data live, that's always available in the docs, and Linux convention puts stuff in /etc, so I'm not sure how containers help. And dynamic libraries are in a well-defined location, with environment variables and other tools that allow you to specify where they live. It's not like dynamic linking is an unsolved problem.

[EraYaN]

Maintainers are also the ones breaking software so, realistically the difference is basically moot. And for a containers to fubar the system you have to really mess up. At worst that specific container fubars itself and you rollback a tag.

There are just fewer things that can go wrong when you get to a sufficient number of services. And lastly moving to a new host is infinitely easier too, export the volume, import of new host and off you go. And stuff like Kubernetes will just handle this for you (and more).

And as for those linux conventions, they vary a lot from distro to distro, you can never be quite sure where that specific version of that specific distro puts its files. So having them just not be able to touch the host ever is a good thing.

[c-hendricks]

Right, but a piece of software having a distribution maintainer doesn't mean it will never have bugs, and if it's a container there's already much less risk of it breaking my system.

As for your second paragraph, that's very idealistic. Config can live in /var, /usr, /home, /usr/local, literally anywhere. I find it much nicer when all data / configuration for a piece of software is all self contained.

[silverquiet]

I think of myself as a mere user as well, though I manage the container system/orchestration for a small SaaS company as well (we're weirdos who use Swarm instead of Kubernetes) and agree with you regarding the management benefits.