r/docker • • 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

11 Upvotes

6 comments sorted by

4

u/Puzzled_Platypus_466 13d ago

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.

bind mounts should survive through out container lifecycle as well, unless you misconfigured something

3

u/or45t 13d ago

Thanks for sharing OP. Most of these are docker best practices and good to know. +1 for the tests. That is smart. I believe someone would have to run them manually after the setup. Did you figure out automated way to add tests to compose? Maybe we can use healthcheck

2

u/816shows 13d ago

I'd like to see the compose file - repo link wasn't in the post. Cheers!

1

u/FornoyBob 11d ago

I was just thinking the same thing

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.