Add Custom List via Docker Compose Environment?

[mcblum]

I have a small Docker Swarm (I know, I know) with three nodes, soon to be more. I'm trying to move almost all of my services to containers, and I'm wondering if it's possible to configure custom block lists via the Docker Compose file rather than in the web UI. My ideal situation would be as follows, though I'm not sure it's possible:

1. Host a custom block list on my Gitlab instance
2. Open a PR against the custom block list
3. When the PR is merged, a pipeline runs and executes a script to essentially re-deploy the pihole containers
4. The containers are set to run one per node, so if a node is offline there is guaranteed to always be two other (for now) instances of PiHole.
5. Pihole data and config is stored on GlusterFS so it's already shared, but I'm not sure if that will cause problems once I try to run multiple instances

Thanks for any insight you may have!
Matt

[Bucking_Horn]

@mcblum

• Host a custom block list on my Gitlab instance
• Open a PR against the custom block list
• When the PR is merged, a pipeline runs and executes a script to essentially re-deploy the pihole containers

Why would you want to redeploy containers for a change of blocklist content ?

Normally, just pointing your Pi-hole to a URL for the list should get you sorted, regardless where that list is hosted.
Pi-hole will update blocklists once a week automatically.
If you want to trigger a manual update, consider pihole -g.

Pi-hole itself isn't cluster-aware. It's assuming itself as the only Pi-hole instance accessing resources.
That said, there's little interference to be expected for DNS resolution itself, as DNS requests are essentially atomic and stateless.

The same may not be true for the DNS cache as well as statistics and network observed metrics that Pi-hole collects, and I guess it could be quite tricky to have Pi-hole's DHCP server function correctly in such a scenario (if that's possible at all).

As far as redundancy is concerned, DNS is already supplying some sort of client-side redundancy, lessening the need for server-side measures considerably: If you are already running two Pi-holes in your network, just tell your clients to use them. If one of them fails, your clients will use the other - no need to put up a cluster for DNS.

Most multi-host solutions discussed in this forum (that I am aware of) seem to be geared towards duplicating or syncing the config among a set of two separate Pi-hole instances.

Are you expecting such high volume DNS loads to consider a cluster for load-balancing? Is this for a company or a publically accessible setup?

[mcblum]

Why would you want to redeploy containers for a change of blocklist content ?

I'm not sure! I just assumed that in order to keep everything in sync that would be the best way. But honestly, if that's not necessary, then that's great.

Pi-hole will update blocklists once a week automatically.

Awesome.

Are you expecting such high volume DNS loads to consider a cluster for load-balancing? Is this for a company or a publically accessible setup?

No! Definitely not for the amount of requests but rather for the desire to have DNS be always available. I have a campus-style network with 6 physical locations and they all share DNS. I was worried that if I spun up a container and it lived on one node, and that node went offline, there would be a lag while the system spun up the same container on a different node. My hope was that I could just run one instance per node, but I hear what you're saying in regards to the stats and things being incorrect because there would essentially be 3 instances all hitting the same storage.

I might just start with 1 instance, point BIND to it and see what happens. I could leave the other PiHole VMs running until this solution has been online for a while and I see if it works.

Most multi-host solutions discussed in this forum (that I am aware of) seem to be geared towards duplicating or syncing the config among a set of two separate Pi-hole instances.

Totally -- that's exactly what I would do if I made enough changes to the current PiHole setup to warrant it. Right now I just do everything twice since they are separate VMs.

Thanks for the reply, going to give this a try and see what happens!