In our previous entry, we unleashed the awesome that is Pi-Hole inside a Docker container to make all the devices in our network ad-free when browsing the internet. Now while that is a good start, you want to keep your container running the latest and greatest version of Pi-Hole right? Now while the containerised version disables Pi-Holes built in upgrade mechanisms, you still can upgrade it in a way that containers are designed to…by phoenixing them!
Refresh the container script
First off, lets open up nano (or your favourite text editor) and create a script file:
nano refreshpihole.sh
Next, punch in the following code:
#!/bin/bash docker pull diginc/pi-hole-multiarch:debian_armhf docker rm -f pihole /path/to/pihole/launch/script.sh
If you have checked out any of my other Docker based posts, the above should be self explanatory.
docker pull diginc/pi-hole-multiarch:debian_armhf
This downloads the latest version of the container image. Remember to confirm which image:tag you require for your particular device.
docker rm -f pihole
The above then goes and trashes the currently running Pi-Hole container.
/path/to/pihole/launch/script.sh
Last but not least, we execute the previously created Pi-Hole script to launch it once more, albeit with a fresh and updated image.
Once you have saved and exited out of the script, don’t forget to make it executable with CHMOD.
Schedule the script with Cron
Cron, named after the Greek word for time, chronos, is a scheduling system across Linux distributions. Cron has various ways to schedule commands and scripts. One way is with the crontab -e command which will open the per user Cron schedule with a custom version of the text editor VIM. Alternatively, there are predefined folders under /etc/:
Simply copy your script file to refresh the Pi-Hole installation to the folder of your choice and it will be executed by Cron on that schedule:
sudo cp /path/to/script/refreshpihole.sh /etc/cron.monthly
With the above, Cron will execute our copied script (and any others in that folder) on a monthly basis.
Summary
The above gives us a small but important example in how Docker and container systems broadly are advantageous over running apps and services on a traditional virtual machine with (hopefully) a patching regime in place. Here we have a important component of our infrastructure that is being kept up to date, has a small footprint across our file-system and operating system, while keeping configuration and logs persistent with minimal downtime.
James,
Great details and best explanation with updates- was just browsing the Pihole Docker and Pi-hole.net page etc. !
I am looking to install Pihole Docker on my S905X/W Android Box 1G RAM, 8 G flash running LibreElec.tv with the kzsaq generic S905 3.14 kernel. Kodi runs great under this minimal OS distro.
S905X/W 4K @60/30 fps is Amlogic SoC with quadcore 1.5-2 GHz CPU, pentacore Mali 450 750 MHz GPU and a hardware accelerated VPU.
And I figured that besides using this Box with Pi-hole as media player, it could also be used as a secondary router serving DNS and adblocking for a few devices connected to it via WiFi AP ( the LibreElec WiFi tether setting in Kodi menu.)
1. While I read through the Pihole Docker pages, it talked about a 164MB Debian build requiring 500MB RAM (this RAM looks too high !)
So of course an Alpine 5MB base build instead of Debian will be much lighter, given the native 10MB Pihole install.
Are there any guides to building Pihole starting from available Alpine ARM64 base containers?
2. If I want to use the LE Box as mini router, would it make sense to have OpenWrt like QoS features (priority, anti buffer bloat- cake SQM)?
How would I install above packages on this LE Box with Pi-hole container?
LE has no package management, but Alpine base should behave much like OpenWrt “apt-get install package” with “apk install package” instead? Alpine is also a router based Linux distro like OpenWrt, just less known.
Or, could the available Debian based Pihole container install QoS/other packages on itself via Dockerfile ADD, or package manager?
3. So this continues from #2.
Could we use the available Alpine base container to add to it OpenWrt packages via ADD in Dockerfile or other method, then run these OpenWrt capabilities in this custom Docker container atop the LE OS, in addition to the Pi-hole Docker?
4. Many online references say that it is nice to change from port 53 to say, 54 on your router to thwart ISP dns hijacks.
Will port change port 53 internal to 54 external mapping be a problem on Docker ?
5. Any configuration suggestions for above Box compared with RPi?
Cheers !
Wooooo boy.
Firstly, thanks for stopping by Shippy, appreciate the comments.
Secondly, sounds like a great little project; I like where your head is at with regards to maximising the tin and getting much use of the IO on there as possible.
After a bit of quick research on LibreElec distro it looks like it has support for Docker. From what I can tell, your objectives are to run Pi Hole, OpenWRT (or a substitute with like features) on top of LibreElec with the help of Docker containers. With all that said, I think that is quite feasible.
1. Unfortunately Pi Hole installation script is quite picky about what distros it is being run on and the devs (as awesome as they are; shout out to WaLLy3K) don’t provide any guidance on getting it to work on other distros. I’ve attempted in the past do some so hackery to try and get Pi Hole working on Alpine with no success (though I was shooting for the ARM Alpine image so that added additional headache).
I totally get that having it run off a small footprint that Alpine gives is awesome but as a starting point, might be better to make-do with the Debian base.
In terms of concerns surrounding RAM usage; to give some perspective, I run Pi Hole in a container on my Raspberry Pi Zero which also is controlling 2 USB ASIC Bitcoin miners via the cgminer package (which is constantly chewing 10-15% CPU) and the Pi doesn’t break a sweat. I would doubt you would have any concerns with Pi Hole on your S905X/W with 1GB of RAM available (and a GPU not sharing that RAM?).
2. There are a couple of OpenWRT Docker images already (see: https://hub.docker.com/r/nmaas87/docker-openwrt/ as one fine example). I would give running the images a go before investigating other options. OpenWRT also provide instructions on rolling your own if you want to give that a try (see: https://openwrt.org/docs/guide-user/virtualization/docker_openwrt_image).
3. As above, if you want to roll your own, you could do so either via interactive shell or by building a Dockerfile with the necessary actions.
4. Not at all. If you want to do zero configuration to the container app itself (i.e. change what port it is listening on, you could append the run command for the container with -p HOSTPORT:APPPORT. In this example, it would look like something along the lines of ‘docker run -p 54:53 pi-hole’.
5. I would give running OpenWRT and PiHole a go using pre-prepared container images from the Docker registry first. Customise your setup for both apps and see if they place nice together. Then, when you are comfortable, try building your own containers from scratch using the Alpine image and adding pieces you need for OpenWRT (and if you want, PiHole in another although this will require reverse engineering their install script).
Good luck and would love to hear how you go.
[…] my follow up entry, I’ll expand on why using Pi-Hole in Docker is advantageous through some easy automation to […]
Great blog posts on Pihole! Have you found how to SSH into a Pihole Docker container?