Explicitly binding certain ports to the container has a similar effect, no?

My problem with podman is the incompatibility with portainer :(

Any recommendations?

This is the way.

network: host gives the container basically full access to any port it wants. But even with other network modes you need to be careful, as any -p <external port>:<container port> creates the appropriate firewall rule automatically.

Actually I believe host networking would be the one case where this isn’t an issue. Docker isn’t adding iptables rules to do NAT masquerading because there is no IP forwarding being done.

When you tell docker to expose a port you can tell it to bind to loopback and this isn’t an issue.

To be fair, the largest problem here is that it presents itself as the kind of isolation that would respect firewall rules, not that they don’t respect them.

People wouldn’t make the same mistake in NixOS, despite it doing exactly the same.

This is why I hate Docker.

My impression from a recent crash course on Docker is that it got popular because it allows script kiddies to spin up services very fast without knowing how they work.

That’s only a side effect. It mainly got popular because it is very easy for developers to ship a single image that just works instead of packaging for various different operating systems with users reporting issues that cannot be reproduced.

That is definitely one of the crowds but there are also people like me that just are sick and tired of dealing with python, node, ruby depends. The install process for services has only continued to become increasingly more convoluted over the years. And then you show me an option where I can literally just slap down a compose.yml and hit “docker compose up - d” and be done? Fuck yeah I’m using that

Another take: Why should I care about dependency hell if I can just spin up the same service on the same machine without needing an additional VM and with minimal configuration changes.

eh, booting into single user mod should work fine, uninstall podman and init 5

Counterpoint

have a dedicated firewall

I mean, don’t router firewalls count in this regard? Isn’t that kinda part of their job?

Do you mean a hardware firewall?

ufw just manages iptables rules, if docker overrides those it’s on them IMO

Docker spesifically creates rules for itself which are by default open to everyone. UFW (and underlying eftables/iptables) just does as it’s told by the system root (via docker). I can’t really blame the system when it does what it’s told to do and it’s been administrators job to manage that in a reasonable way since forever.

And (not related to linux or docker in any way) there’s still big commercial software which highly paid consultants install and the very first thing they do is to turn the firewall off…

Or maybe it should be easy to configure correctly?

This is less of an issue with JS, but say you’re developing this C++ application. It relies on several dynamically linked libraries. So to run it, you need to install all of these libraries and make sure the versions are compatible and don’t cause weird issues that didn’t happen with the versions on the dev’s machine. These libraries aren’t available in your distro’s package manager (only as RPM) so you will have to clone them from git and install all of them manually. This quickly turns into hassle, and it’s much easier to just prepare one image and ship it, knowing the entire enviroment is the same as when it was tested.

However, the primary reason I use it is because I want to isolate software from the host system. It prevents clutter and allows me to just put all the data in designated structured folders. It also isolates the services when they get infected with malware.

have to make sure of is that the deployment environment has node and the angular CLI installed

I have spent so many fucking hours trying to coordinate the correct Node version to a given OS version, fucked around with all sorts of Node management tools, ran into so many glibc compat problems, and regularly found myself blowing away the packages cache before Yarn fixed their shit and even then there’s still a serious problem a few times a year.

No. Fuck no, you can pry Docker out of my cold dead hands, I’m not wasting literal man-weeks of time every year on that shit again.

(Sorry, that was an aggressive response and none of it was actually aimed at you, I just fucking hate managing Node.js manually at scale.)

Think of it more like pre-canned build scripts. I can just write a script (DockerFile), which tells docker how to prepare the environment for my app. Usually, this is just pulling the pre-canned image for the app, maybe with some extra dependencies pulled in.

This builds an image (a non-running snapshot of your environment), which can be used to run a container (the actual running app)

Then, i can write a config file (docker-compose.yaml) which tells docker how to configure everything about how the container talks to the host.

• shared folders (volumes)
• other containers it needs to talk to
• network isolation and exposed ports

The benefit of this, is that I don’t have to configure the host in any way to build / host the app (other than installing docker). Just push the project files and docker files, and docker takes care of everything else

This makes for a more reliable and dependable deploy

You can even develop the app locally without having any of the devtools installed on the host

As well, this makes your app platform agnostic. As long as it has docker, you don’t need to touch your build scripts to deploy to a new host, regardless of OS

A second benefit is process isolation. Should your app rely on an insecure library, or should your app get compromised, you have a buffer between the compromised process and the host (like a light weight VM)

You’re right. As an old-timey linux user I find it more confusing than running the services directly, too. It’s another abstraction layer that you need to manage and which has its own pitfalls.

Even when it seems like an app runs identically on every platform, you can easily run into issues down the road. If you have a well configured docker image, that issue is just solved ahead of time. Hell, I find it worth messing with just moving a node.js app between Linux boxes, which would experience the least issues I can think of.

I pretty much share the same experience. I avoid using docker or any other containerizing thing due to the amount of bloat and complexity that this shit brings. I always get out of my way to get Software running w/o docker, even if there is no documented way. If that fails then the Software just sucks.