Best practice for accessing lots of Docker containers? (re: macvlan vs reverse proxy)

Reverse proxy absolutely. Assigning IPs to every single container will just get really messy and you also loose out on all the advantages of routing everything through a proxy (SSL, SSO, etc.)

I've been using Docker with macvlan and assigning each container a dedicated ip address on my network. Each container is then accessible from my other computers using their ip address and I also configure each container's web interface to use port 80.

That is so much extra work, why do any of this? Youre making things so much harder on yourself without any real gain.

You do not need a IP in your network for every single container. Do not treat containers as VMs, they are not.

Switch to using a reverse proxy with DNS names, can be something like a local Pihole.

Then you can turn your nightmare of IPs into basic domains for each service, like portainer.example.home or portainer.home.

If you also want to use valid (trusted) SSL certs, you can do that too with most reverse proxies, but the domains you use must be valid public ones (doesnt mean you need to open any ports tho). So portainer.example.home wouldnt work, but portainer.example.duckdns.org would work.

Tons of threads here exist about this already, simply search.

Macvlan is plain unnecessary. You are wasting IP addresses in your subnet and people must remember the correct IP address per service.

Furthermore, you likely expose many network services that must not be exposed such as database ports etc.

The recommended way would be to use Docker bridge networks (a unique one per container stack) and then joining a reverse proxy to the networks. The reverse proxy will expose TCP/80 and TCP/443 and proxy to your docker containers. You won't even map any container ports to your docker host server anymore. Only 80 and 443 of the reverse proxy. Everything else happens within Docker networks.

So the reverse proxy can directly talk to your other container services as they both remain in the same docker bridge networks. Docker also handles name resolution, so you can just tell the reverse proxy to proxy to 'nginx', which may be the name of your nginx container. No need to define internal Docker IPs or remember those.

If you have a valid domain name, you can even opt for obtaining valid SSL certificates for all your services. Even when you do not plan to expose anything, you can use dns challenge and obtain valid lets encrypt certificates. Then just use subdomain names for your services like plesk.example.com, cloud.example.com, which all point to the IP address of your reverse proxy (in this case the IP address of your server). May use an internal DNS server to resolve your domain properly (split brain dns).

I would say your approach using macvlans is a bit overkill. Nice if you want to absolutely isolate each container from each other, but I don't see that paying off. With a reverse proxy you can still give them different names, all you need to worry about is they don't have a conflicting port on the same host. The proxy configuration is easy to maintain and can be trivially reloaded anytime with zero downtime to the underlying services.

The only drawback I can thing off is your proxy needs to have access to all your containers, so generally they will all share the same network, not a biggie at all to me.

One advantage of Macvlans is with Tailscale. With Tailscale you get to choose only the host name. Your domain name is always host.net name.ts.net or else use /application or very limited ports. So with a Macvlan you can assign each container a separate name. With Cloudflare or without tunnels then reverse proxy makes more sense.

imho, most people using macvlans are trying to treat containers like VMs. macvlans, again imho.. should rarely, if ever be used, and only for very specific reason.

you are using macvlans wrong... it is intended for special cases where you absolutely need the container to appear physically connected to your nic, like they need to monitor traffic or such. IT IS not designed to be anything more secure than the default bridge driver...

what exactly is your concern of security? are you trying to isolate each container so that they can't communicate with each other? then just put each container in its own bridge network. are you trying to hide insecure endpoints from the public, so that it is only accessible through secure connections like tls? then use a reverse proxy. in any of those cases, macvlan does not play a role.