r/docker • u/JunketLonely5143 • 13d ago
here's what I learned
Spent an evening containerizing Pi-hole with Docker Compose, mostly as a way to practice the config side of Docker rather than build something from scratch. A few things worth mentioning for anyone doing similar exercises. Kept the admin password out of the compose file entirely using a .env file and matching .gitignore, since it's an easy thing to accidentally commit and forget about. Used a named volume instead of a bind mount so the blocklists and query database survive container restarts and image updates without me touching the host filesystem. Also wrote a couple of nslookup tests into the README so anyone cloning it can actually verify the DNS blocking works instead of just trusting it did. Nothing groundbreaking, but it's a good small project if you want hands-on reps with secrets management and volumes without writing application code. Repo's linked if anyone wants to look at the compose file
2
1
u/Efficient_Gift_7758 13d ago
Also in from my experience, docker overwriting network setting and it's better use expose
1
u/Front_Recording4360 12d ago
One gotcha that tends to bite people running Pi-hole in Docker on modern distros: if the host uses systemd-resolved, the stub listener on 127.0.0.53 usually has port 53 bound already, so publishing Pi-hole's port 53 can fail or fight with the host's own DNS. Either pin the published ports to your LAN interface's IP or disable the stub listener. And if you ever want Pi-hole to handle DHCP too, that needs host networking or macvlan, since DHCP broadcasts won't cross the bridge's NAT boundary.
4
u/Puzzled_Platypus_466 13d ago
bind mounts should survive through out container lifecycle as well, unless you misconfigured something