Managing multiple containers
Eventually, you’re going to find your server lacking ports.
Pihole, for example, really needs to take control of port 80, because your HTTP traffic is routed through it — but what if another container also needs to use port 80? It’s possible, as we’ve seen, to remap those ports in your docker-compose.yml, piping port 80 from the container to any other free port on the host, but that’s much more awkward than it needs to be when you’re connecting to your server from elsewhere. Combining a little DNS management with a reverse proxy (we’re partial to nginx-proxy) means all requests to your server are collected and rerouted to the appropriate container based on the hostname used; plex.apc.local, for example, might take you to your Plex server without the need to remember which port it’s living on. Nginx can also take charge of load balancing and traffic management between your server containers — check out github.com/jwilder/nginxproxy for information on getting it running, and look at installing dnsmasq ( hub. docker.com/r/strm/dnsmasq) within a container to deal with local DNS remapping.
Although Nginx (pronounced “Engine X” as we were told after saying “Nn gincks” a few too many times) can deal with load balancing, and our containerised server should theoretically be able to dole out its resources sensibly, a little monitoring layer is a great choice to see just where that load is going. Grab the image titpetric/netdata and get that running. Netdata provides not only insight into the movements of your various containers, but offers up an absolutely live and extremely well-explained look at the deeper aspects of your server hardware. If something’s not working as it should — or even if you have a minor driver issue — you’ll know about it first.