Read your GitHub and with the exciting news about 4.0 FTLDNS:
My target HW is S905X/W quadcore aarch64 v8 based Android Box (1GB RAM, 8 GB flash) running LibreElec-Kodi that fortunately can now add your Pi-hole Docker via its linuxserver.io addons from the Kodi AddOns menu !
Your Docker is Debian based 164 MB. Is there an Alpine aarch64 base (5MB) available? I am assuming it then will be really lightweight
Alpine 3.8 supports arm64v8. And Pi-hole itself is 9MB I believe?
Is there a way to add QoS priority and anti buffer bloat type packages common with OpenWrt to the Pi-hole Docker, or just to Docker Alpine base (5MB) via Dockerfile ADD command?
As you know Alpine too is OpenWrt like, just less known, and has own package manager: apk install package.
Is RAM requirement 500MB running? On a blog they claim 50 MB:
Will Pihole make use of multicore for S905?
LibreElec does support multicore for this SoC.
With above LibreElec as hostOS and Docker (s) , we will have a lightweight, highly efficient media player plus small router box that can form its own small home subnet.
I created an alpine version initially (along with a Debian version) and it required customizations to re-create the Pi-hole installer the 'alpine' way using slightly different packages and hacks to patch missing functionality. This lead to basically 2 different products with 2 different problems/bug sets and supporting 1 was hard enough so we simplified to the easier to maintain one. I saved a branch to snapshot the old code on the github repo before removing all reference to alpine earlier this year.
Can you elaborate on what these packages are? The Pi-hole docker image is fairly self contained, if you need kernel network changes or additional packages those changes should be made on the docker host server.
It'll vary depending on usage. I don't have a long running heavy usage container in front of me to look at but starting one and running docker stats <container> just now showed less than 40MB memory:
CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
3770874ec2d1 pihole 2.35% 33.11MiB / 7.826GiB 0.41% 1.86MB / 27.7kB 418kB / 14.9MB 0
The image it's self is in the 300MB of disk usage once extracted (164MB is the compressed download size)
I'm not familiar with LibElec boxes but I'd recommend for the best experience running my docker to make sure you have something the support the official docker installation process. Lots of issues arise from older versions of docker installed by plugins and or 3rd party packages (like dfn being used on that blog link).
I would only support re-opening the Alpine docker fork of the image if the rest of the team is willing to support Alpine as a native, non docker, OS installation too. This would open up the option for installs on other musl/busybox based OSs like *WRT router too.
Pi-hole installer was made for Debian based OSs and we've never supported Alpine/MUSL officially, that is where a lot of the difficulty creating and supporting the alpine image came from. Swapping apt packages for apk packages was the majority of the differences, but other small not to obvious things would crop up too.
I won't go into the full technical reasons but you can look at the last commits before alpine was removed here. The bash_functions.sh handled the majority of the alpine/debian differences. One note: I chose to swap lighttpd for nginx in the alpine image because of personal preference.
I dropped Alpine with a heavy heart, it was fun getting it to work w/customization in the beginning but I just got overwhelmed and chose to focus on the more stable and easier to update/maintain debian image. Disk space and Bandwidth are abundant these days so I favored a fat, stable image over a slim, unstable image.
The creation of docker images is a lot like installing natively on an OS, once created it becomes a highly portable image and gets Docker's full benefits. When issues arise with incompatibility between Alpine and the application you're trying to dockerize as I've outlined above, sometimes basing it on a larger image is the best answer.
Appreciate your details.
I have faced similar OpenWrt v Alpine issues, so Docker has ways to go before stabilizing its Alpine based thin containers...but Docker is focused not on open source but enterprise apps, for obvious reasons !
