Flatpaks are similar, but more aimed at desktop applications. Docker containers are made for services and give more isolation on the network.

Docker containers get their own IP addresses, they can discover each other internally, you get port forwarding, etc. Additionally you get volume mounts for persistent storage and other features.

Docker compose allows you to bring up multiple dependent containers as a group and manage connections between them, with persistent volumes. It'll handle lifecycle issues (restarting crashed containers) and health checks.

An example - say you want a Nextcloud service and an immich service running on the same host. You can create two docker-compose files that launch both of them, each with its own supporting database, and give each db and application persistent volumes for storage. Your applications can be exposed to the network and the databases only internally to other containers. You don't need to worry about port conflicts internally since each container is getting its own IP address. So those two MySQL DBs won't conflict with each other. All you need to do is ensure that publicly available services have a unique port forwarded to them. So less to keep track of.

Docker will let you run as many database containers as you want and route things such that each service only sees its own database and none of the others, plus even processes on your host machine can't connect unless you've configured ports for that.

@non_burglar@lemmy.world is correct, but is perhaps not explaining it perfectly for the practical questions you seem to be asking.

If you have, say, two Docker containers for two different web servers (maybe one's for your Wiki, and the other is for your portfolio site), you can have both listening on ports 80 and 443 of their container, but a third Docker container running a reverse proxy which has access to your machine's ports 80 and 443. It then looks at the incoming request and decides which container to route the request to (e.g., http://192.168.1.2/wiki/%s requests go to the Wiki container, and all other requests go to portfolio site).

Now, reverse proxies can be run without Docker, but the isolation Docker adds makes it all a lot easier to manage, in part because you don't need to configure loads of different ports.

Sorry, that was presumptuous of me. 'TCP stack' just means each container can have its own IP and services. Each docker, and in fact each Linux host can have as many interfaces as you like.

I imagine you would get a conflict when you try to go to 192.168.1.2:8000 or even localhost:8000.

You're free to run a service on port 8000 on one IP and still run the same port 8000 on another ip on the same subnet. However, two services can't listen on the port at the same ip address.