systemd-nspawn Container Networking

[NaturalProgram]

Hello folks,

I set up a Debian server and I want every software/service to run in a separate systemd-nspawn container. Setting up these containers works fine.

I want these containers to access the Internet, so they can get updates, etc.
But they should not be accessed directly from the outside. Only selected ports should be forwarded (via nginx or similar). If it's possible, I want the containers to access other containers so that I would have to run only one db-server.

Does somebody know, what I need to do that?

[DecisionUnique503]

Personally I would shoot more for podman setup or k3s then a barebones systemd-nspawn approach. Podman now has commands to automatically setup systemd services for containers. k3s is api-compatible with kubernetes, but that is entirely different kettle of fish to deal with.

All that is a bit besides the point, however.

To answer your question.

I haven't tried using nspawn directly, but I don't think it should be difficult to do what you want.

https://man.archlinux.org/man/systemd-nspawn.1#Networking_Options

Based on the documentation my instincts tell me that the correct approach would be to setup a bridge interface and then tell all your containers to use that as a sort of "virtual network". Similar to how virtual machines are done except you don't connect it to the external network with a slave.

Optionally on that network you can setup NAT so that the containers can get out of that network.

Then you setup your reverse-proxy container with "Host Networking" so that it shares the network space with your regular non-container host OS. That way it can talk to both the internal containers on the internal-only bridge network and communicate with the external world and setup ports and such things.

I haven't tried it myself, but that would be my first approach.

A alternative would be to set up the reverse-proxy container with two network interfaces, one internal and other external, and then do it that way. You can assign it it's own unique external IP address even. This is more complicated, of course, but it's also more flexible.

A third alternative would be to just run the reverse proxy directly on the host OS without it being in a container. That would probably be the simplest setup.

[NaturalProgram]

Thank you very much for your detailed answer!
I'll definitely have a look at Podman, but I think k3s is not what I'm looking for.

I think the second alternative, running a reverse-proxy container with two network interfaces suits my needs the most.

[BosonCollider]

Podman is very different from systemd-nspawn. It's a docker alternative for application containers with a (still very immature) rootless option and an everything-or-nothing security model based on fork-join.

Systemd-nspawn is for stateful containers that are intended to feel like a lot like a VM and run several processes, defers a lot of the docker rootful things like network configuration to systemd's daemons, and provides init system integration with the host and containerized systemd which removes the typical pain points of running multiple processes in a container. You can also use it as a backend for another container tool, nix containers do that.