Hallo liebe Computerbase-Community,
ich bin madnuttah und würde euch gerne mein Unbound-Docker-Projekt auf GitHub vorstellen.
Dies ist ein rein privates Projekt, nach wie vor ohne finanzielle Interessen. Auch NLnet Labs, der Hersteller der Software die im Image Verwendung findet, hat keinen Einfluss und keinerlei Mitwirkung an der Entwicklung dieses Projekts.
Es handelt sich um einen „distroless“ Alpine Linux basierten, DNSSEC validierenden, rekursiven DNS-Resolver mit Pi-hole im Fokus und bietet folgende Features:
Nun, ich war seinerzeit mit der Pflege und mir wichtigen, fehlenden Komponenten diverser, populärer Unbound Docker Images unzufrieden und hatte daher ohne große Ahnung von Docker und seinen Containern mein eigenes auf Basis von Alpine Linux gebaut. Als ich soweit zufrieden war, habe ich es am Weihnachtstag 2021 herausgebracht.
Tja. Ich glaubte, ein Eintrag in einer Konfigurationsdatei würde genügen um eine sichere "chroot" Umgebung bereitzustellen. Ein aufmerksamer GitHub-User wies mich darauf hin, dass dem leider nicht der Fall war. Das Image war bei weitem nicht so sicher wie ich dachte. Nach wenigen Versuchen, das Image zu korrigieren, gab ich mich geschlagen und begann ein „distroless“ Image mit meinen Alpine-Kompilaten zu gestalten, also eigentlich komplett von vorne zu beginnen. Wie sich gezeigt hat, war der Aufwand geringer, als das Image komplett umzubauen. Ein super Nebeneffekt war, dass eigentlich nur Kleinigkeiten in der unbound.conf anzupassen waren, damit es auch wieder bei den bereits bestehenden Installationen „meiner“ Nutzer ohne viel Aufwand weitergehen konnte. Nach ein paar mehr commits war dann auch der letzte Fehler, der mir mitgeteilt wurde, behoben.
Neuerdings habe ich meine Workflows auf CD (Continuous Delivery) umgestellt, also sobald ein Unbound Update vom Hersteller herausgebracht wird, läuft über einen Pipeline-Prozess um 19:00 UTC ein Versionsabgleich und anschließend ein automatischer Build von Unbound, danach folgt das automatische Pushen, Taggen und Releasen auf GitHub.
Ich bin nach wie vor in der Lage, das Image auch manuell zu aktualisieren, sobald Schwachstellen der Komponenten des Images gestopft wurden.
Wirklich nett ist unter vielem anderen die Möglichkeit eure eigene UID/GID in der Compose-Datei oder beim Start aus der Shell heraus zu definieren, sowie die funktionierende Redis-Anbindung via Unix Socket, was einen enormen Schub in Sachen Geschwindigkeit bietet.
Falls ihr Zabbix nutzt und Graphen mögt, lassen sich Statistiken mittels eines modifizierten und injizierten (ich nenne es "Frankensteined") Healthcheck-Skriptes ausgeben. Der Link befindet sich recht prominent auf meiner GitHub-Seite.
Ich habe versucht alles so gut und detailliert wie möglich mit vielen Beispieldateien zu dokumentieren.
Hier findet ihr mein Projekt, ich hoffe euch gefällt was ich so mache und bin offen für jegliche konstruktive Kritik.
Viele Grüße,
madnuttah
ich bin madnuttah und würde euch gerne mein Unbound-Docker-Projekt auf GitHub vorstellen.
Dies ist ein rein privates Projekt, nach wie vor ohne finanzielle Interessen. Auch NLnet Labs, der Hersteller der Software die im Image Verwendung findet, hat keinen Einfluss und keinerlei Mitwirkung an der Entwicklung dieses Projekts.
Es handelt sich um einen „distroless“ Alpine Linux basierten, DNSSEC validierenden, rekursiven DNS-Resolver mit Pi-hole im Fokus und bietet folgende Features:
- Unprivilegierter Benutzer
- Unprivilegierter Port
- DNSSEC
- DNSCrypt
- DNSTap
- DNS64
- DNS over HTTPS
- DNS over TLS
- Redis
- Libevent
- Optional: Healthcheck
- Optional: Statistiken
Nun, ich war seinerzeit mit der Pflege und mir wichtigen, fehlenden Komponenten diverser, populärer Unbound Docker Images unzufrieden und hatte daher ohne große Ahnung von Docker und seinen Containern mein eigenes auf Basis von Alpine Linux gebaut. Als ich soweit zufrieden war, habe ich es am Weihnachtstag 2021 herausgebracht.
Tja. Ich glaubte, ein Eintrag in einer Konfigurationsdatei würde genügen um eine sichere "chroot" Umgebung bereitzustellen. Ein aufmerksamer GitHub-User wies mich darauf hin, dass dem leider nicht der Fall war. Das Image war bei weitem nicht so sicher wie ich dachte. Nach wenigen Versuchen, das Image zu korrigieren, gab ich mich geschlagen und begann ein „distroless“ Image mit meinen Alpine-Kompilaten zu gestalten, also eigentlich komplett von vorne zu beginnen. Wie sich gezeigt hat, war der Aufwand geringer, als das Image komplett umzubauen. Ein super Nebeneffekt war, dass eigentlich nur Kleinigkeiten in der unbound.conf anzupassen waren, damit es auch wieder bei den bereits bestehenden Installationen „meiner“ Nutzer ohne viel Aufwand weitergehen konnte. Nach ein paar mehr commits war dann auch der letzte Fehler, der mir mitgeteilt wurde, behoben.
Neuerdings habe ich meine Workflows auf CD (Continuous Delivery) umgestellt, also sobald ein Unbound Update vom Hersteller herausgebracht wird, läuft über einen Pipeline-Prozess um 19:00 UTC ein Versionsabgleich und anschließend ein automatischer Build von Unbound, danach folgt das automatische Pushen, Taggen und Releasen auf GitHub.
Ich bin nach wie vor in der Lage, das Image auch manuell zu aktualisieren, sobald Schwachstellen der Komponenten des Images gestopft wurden.
Wirklich nett ist unter vielem anderen die Möglichkeit eure eigene UID/GID in der Compose-Datei oder beim Start aus der Shell heraus zu definieren, sowie die funktionierende Redis-Anbindung via Unix Socket, was einen enormen Schub in Sachen Geschwindigkeit bietet.
Falls ihr Zabbix nutzt und Graphen mögt, lassen sich Statistiken mittels eines modifizierten und injizierten (ich nenne es "Frankensteined") Healthcheck-Skriptes ausgeben. Der Link befindet sich recht prominent auf meiner GitHub-Seite.
Ich habe versucht alles so gut und detailliert wie möglich mit vielen Beispieldateien zu dokumentieren.
Hier findet ihr mein Projekt, ich hoffe euch gefällt was ich so mache und bin offen für jegliche konstruktive Kritik.
Viele Grüße,
madnuttah
Zuletzt bearbeitet:
