• This forum has a zero tolerance policy regarding spam. If you register here to publish advertising, your user account will be deleted without further questions.

Unbound als eigenen resolver

Domi

Member
Nabend Leute, ich hätte da mal eine Frage... dank neuerdings eingeführten DNS Sperren etc., haben ein Kumpel und ich über einen eigenen Resolver gesprochen. Er hat einen PiHole und ich einfach "nur" einen Ubuntu Server im Keller :) Kumpel probiert ein wenig mit seinem Pi herum, ich würde auf meinem Ubuntu wohl den 'unbound' einsetzen :)

Ich habe mir schon diverse Seiten angeschaut, mich hier und da belesen, doch das eine oder andere hängt irgendwie, oder ich hab ein Gedankenfehler. Einmal vorweg, mein DNS funktioniert! Aber vielleicht denke ich auch zu komplex und man sollte noch etwas anpassen.

Code:
/etc/unbound/unbound.conf.d/server.conf
server:
    verbosity: 1
    interface: 0.0.0.0
    port: 53
    do-ip4: yes
    do-ip6: yes
    do-udp: yes
    do-tcp: yes
    access-control: 127.0.0.0/8 allow
    access-control: 10.12.0.0/24 allow
    access-control: 10.12.1.0/24 allow
    root-hints: "/etc/unbound/root.hints"
    hide-identity: yes
    hide-version: yes
    harden-glue: yes
    harden-dnssec-stripped: yes
    use-caps-for-id: yes
    cache-min-ttl: 3600
    cache-max-ttl: 86400
    prefetch: yes
    num-threads: 4
    forward-zone:
        name: "."
        # definitely censor free & log free with DNSSEC Support:
        forward-addr: 9.9.9.9           # DNS Quad9
        forward-addr: 149.112.112.112   # DNS Quad9
Mein "forward" Eintrag hab ich mit Quad9 hinterlegt, damit (falls mal eine Domain nicht erreichbar ist) dennoch erreichbar ist. Ich hatte das forwarding schon mal raus kommentiert, doch dann konnte ich ads.google.com oder analytics.google.com nicht mehr öffnen, wo ich gestern mal eben rein musste um Daten für die Firma raus zu ziehen.

Nun wäre meine Frage, hab ich das Prinzip der "root-hints" falsch verstanden? An sich sind das ja die "Root DNS", die wissen wo die TLDs sind, die wiederum wissen wo die Domain registriert (oder gehostet) ist und dann so weiter. Somit sollte doch eigentlich alleine mit den root-hints alles funktionieren, oder nicht? Wie gesagt, ich hatte mir dann noch ein paar andere Webseiten angeschaut, bin aber immer zu dem gleichen Ergebnis gekommen. Wenn so etwas schon mal jemand für sich zuhause hinterlegt und eingerichtet hat, würde mich mal interessieren wo mein Fehler lag?!

An sich läuft die Anfrage hier bei mir aktuell wie folgt (hoffe ich kann das korrekt darstellen)...
- Client01 (IP: 10.12.0.21, DNS: 10.12.0.1)
-- Ubuntu Server (IP: 10.12.0.1, DNS: 10.12.0.254)
--- UDM Pro / Router (IP: 10.12.0.254)

Wobei der DNS des Router aufgrund der "root-hints" nicht angesprochen werden dürfte. Das einzige was ich jetzt noch im unbound hinterlegen müsste, wären lokale Namensauflösungen, falls ich mal vom Notebook meinen PC via Namen erreichen möchte... wäre aber ein sekundäres "Problem", daher wollte ich mal horchen ob und wie ihr dies so realisiert habt?!

Gruß, Domi

p.s. Ich habe mal meine "Quellen" oder Beispiele hier mit beigefügt... falls es von Interesse ist.
 
Zum Anfang eine kleine Ausschweifung da du scheinbar über unterschiedliche DNS-Verfahren stolperst; PiHole ist kein "echter" (aka rekursiver) DNS-Resolver, sondern ein DNS-Forwarder welcher die Anfrage an einen rekursiven DNS-Resolver weiterleitet (gerne genommen sind Google, OpenDNS oder Cloudflare) und dabei eine Liste bekannter Domains (blacklist) auf 127.0.0.1 "fälscht".
Deine Unbound-Konfiguration ist ebenfalls als Forwarder konfiguriert und verwendet Quad9. Du bist damit nicht dein eigener Resolver sondern unterliegst wieder der "Macht" eines externen Anbieters.

Prinzipiell reicht statt eines eigenen rekursiven DNS-Resolvers, ein jeder DNS-Server welcher nicht von der deutschen Medienindustrie kontrolliert wird, ich kann auch OpenDNS nur empfehlen. Zumindest für weniger "Geek" Haushalte ist es die einfachste Lösung; in der Fritzbox den DNS-Resolver für DHCP eintragen und fertig, ein eigener DNS-Server ist dazu schlicht nicht notwendig. Dazu sei aber gesagt dass die Medienindustrie (sorry, Verband der Telekomanbieter) aktuell nur eindrucksvoll belegt wieso man genau das vielleicht aus Datenschutz eher doch nicht will.

An sich läuft die Anfrage hier bei mir aktuell wie folgt (hoffe ich kann das korrekt darstellen)...
- Client01 (IP: 10.12.0.21, DNS: 10.12.0.1)
-- Ubuntu Server (IP: 10.12.0.1, DNS: 10.12.0.254)
--- UDM Pro / Router (IP: 10.12.0.254)
Deine Darstellung und Konfiguration widersprechen sich. Laut Darstellung leitest du die Anfragen vom Unbound DNS-Server an den Router weiter, welcher dann, abseits anderer Konfiguration, den DNS-Server deines Anbieters verwendet, womit das Problem nicht gelöst ist.

Mein "forward" Eintrag hab ich mit Quad9 hinterlegt, damit (falls mal eine Domain nicht erreichbar ist) dennoch erreichbar ist.
Falls eine Domain nicht erreichbar ist, ist sie nicht erreichbar. Quad9 kann auch das nicht magisch lösen. Du hast aber, ausser ich irre mich, eingestellt dass alle Anfragen an sie gehen, ergo meine obige Aussage dass dein DNS-Server in der aktuellen Konfig keinen Mehrwert bringt.

Nun wäre meine Frage, hab ich das Prinzip der "root-hints" falsch verstanden? An sich sind das ja die "Root DNS", die wissen wo die TLDs sind, die wiederum wissen wo die Domain registriert (oder gehostet) ist und dann so weiter. Somit sollte doch eigentlich alleine mit den root-hints alles funktionieren, oder nicht?
Root-Hints speichert die IP-Adresse der root-DNS Server. Prinzipbedingt braucht man DNS um bspw den DNS-Root "j.root-servers.net" auf zu lösen um zu fragen wer denn überhaupt ".net" sei, geschweige SLD und Thirdlevel. Also speichert man schlicht auf jedem DNS-Resolver eine Liste der zu fragenden Root-Server mit deren IP - in der Hoffnung dass sich diese nicht ändern müssen.

Auch wenn prinzipiell nichts gegen direkten DNS-Resolver spricht, ich würde empfehlen Pihole + Unbound zu verwenden statt ein purer Unbound, die Vorteile und Konfigurierbarkeit sind riesig. Beachte dass die Reaktionszeiten auf DNS-Anfragen deutlich langsamer als das Verwenden "guter" öffentlicher DNS-Server wie 8.8.8.8 oder 1.1.1.1 sein kann was sich durchaus in den Ladezeiten bemerkbar macht.
Pihole läuft übrigens wunderbar in Container (LXC bei mir), kann also ohne Weiteres auf deinem Ubuntu-Server laufen.

Beachte; falls deine Spielwiese abschmiert gibt es im ganzen Heimnetz "kein Internet" bis dass das Problem gelöst ist oder die DHCP-Konfiguration geändert wurde. Das mag nicht ganz tragisch auf den ersten Blick scheinen, wird aber durchaus relevant wenn man Familie oder Mitbewohner hat.
 
Moin, ich habe ja nun gestern meinen RPi abgeholt und dort mal separat einen PiHole drauf installiert. Es ist erstaunlich, wenn man sieht was alles eine DNS Anfrage stellt und nach hause funken möchte :D

Mein DHCP (die UDM Pro) übergibt als primären DNS die IP des PiHole (10.12.0.253) sowie die IPv6 (fe80::), was auch soweit klappt.

Auch mit unbound funktioniert jetzt meine ads.google.com, wobei ich mir dafür eine Gruppe und Whitelist hinterlegt habe, wenn ich für die Firma mal eben ads.google.com sowie analytics.google.com benötige, kann ich dieses entweder für meinen PC oder dem Notebook frei machen :) Eine Frage wäre allerdings noch und das ist ja so eine Geschmacksfrage...

Da ich im PiHole sowohl IPv4 als auch IPv6 aktiviert habe, sehe ich im Logfile beide varianten. Die IPv4 aller Geräte kenne ich bei mir im Netz, die IPv6 aber nicht. Sollte man daher auf die IPv6 Funktion am PiHole verzichten, oder gibt es dafür eine bessere / sinnigere Lösung?

Die Tage werde ich mir von meinem Ubuntu Server auch noch mal Unbound anschauen und gucken wieso das nicht so wollte mit den google.com Domains, aber das wird auch nur ein Layer 8 Problem gewesen sein :D

Deine Darstellung und Konfiguration widersprechen sich.
Ja, diese Auflistung und meine Config beißen sich, da hast du recht... aber ich war mir auch nicht sicher ob unbound doch noch irgendwie Anfragen an meine UDM-Pro weitergibt oder nicht. Aber gut, dann wäre das auch geklärt :)

Prinzipbedingt braucht man DNS um bspw den DNS-Root "j.root-servers.net" auf zu lösen um zu fragen wer denn überhaupt ".net" sei
Ja, an sich ist DNS ja (grob gesagt) ein dickes fettes Telefonbuch. Der Typ von SemperVideo hatte es schick dargestellt. Die Root DNS wissen wer für .de, .at, .com etc. zuständig ist. Danach kommen die TLD DNS, die wissen wo eine .de Domain registriert ist, und dann komme ja die DNS des Registrar / Provider etc., die einem sagen können auf welcher IP / Server dann die Domain verweist / liegt. Hoffe ich konnte das "laienhaft" gut erklären. Natürlich ist das technisch spezifisch wieder anders zu erklären, aber als IT'ler aufgrund des Kontakts mit 97% Laien, hab ich mir angewohnt es so einfach wie möglich zu machen :D

Wichtig ist aber schon mal, es funktioniert und tut was es soll.

Beachte; falls deine Spielwiese abschmiert gibt es im ganzen Heimnetz "kein Internet" bis dass das Problem gelöst ist
Das Thema hatten wir auch in der Ubiquiti Facebook Gruppe... ich hab irgendwo bei einem Kunden (oder bei uns in der Firma) zwei DNS hinterlegt und bei mir gestern (zum testen) auch zwei DNS hinterlegt (PiHole und Quad9), übergeben vom DHCP und als ich den PiHole deaktiviert hatte, ging noch alles. Kann aber auch Zufall sein, dank des Client Cache. Bin aber der Meinung, dass dies bei uns in der Firma so seit Jahren funktioniert.

Dort ist auch der primäre DNS der Windows PDC und der sekundäre DNS der Router / Gateway. Muss die Tage mal gucken ob das bei uns oder bei einem Kunden so hinterlegt war. Irgendwo hatte ich aber auch schon mal die Variante gewählt, primärer DNS ist Router / Gateway und es gibt ein DNS Forward zum Windows Server wegen der ActiveDirectory :)
 
Sollte man daher auf die IPv6 Funktion am PiHole verzichten, oder gibt es dafür eine bessere / sinnigere Lösung?
Es gibt zumindest keinen technischen Grund warum IPv6 aktiv sein müsste. IPv4 ist schlicht... simpler :p
Dazu reicht über DHCP nur die IPv4-IP für DNS mit zu teilen und alle Clients verwenden IP4v4 zur Auflösung während ausgehend von Pihole/Unbound weiterhin IPv6 verfügbar bleibt.

Die IPv4 aller Geräte kenne ich bei mir im Netz, die IPv6 aber nicht.
Aufgrund des RFC 4941 IPv6 Privacy Extension können die IPv6 Adresse zusätzlich noch konstant ändern. In einem switched Heimnetz kannst du über die MAC-Adresse gegebenfalls noch eine Relation aufbauen (Pihole unterstützt es aktuell nicht), aber eine wirkliche Lösung gibt es prinzipbedingt sonst nicht.

Moin, ich habe ja nun gestern meinen RPi abgeholt und dort mal separat einen PiHole drauf installiert
Technisch gesehen ist ein RPI nicht notwendig aber stabilitätsmässig vermutlich sinnvoll. Beachte dass Pihole standardmässig recht viel schreibt was eine MicroSD nicht so gerne mag, es lässt sich aber optimisieren.

Ja, an sich ist DNS ja (grob gesagt) ein dickes fettes Telefonbuch. Der Typ von SemperVideo hatte es schick dargestellt.
Von deiner Beschreibung hast du es richtig verstanden, von der Analogie aber leider falsch :cool: Ein "dickes Telefonbuch" wäre wenn die Root-Server alle IP Adressen kennen würden. Eigentlich ist es eine ganze Reihe Telefonbücher;
- zuerst das Telefonbuch welches Land welche Vorwahl hat (Root DNS ".")
- Dann das Telefonbuch welche Ortschaft welche Vorwahl hat (.de. Zone)
- Dann "das Örtliche" mit der Firma Max Mustermann AG (Zone domi.de.)
- Dann dort die Telefonnummer der Zentrale
- Die freundliche Dame findet dann im Telefonbuch der Firma die www.domi.de und gibt dir endlich die Durchwahl zu Max Mustermann.
Wichtig ist auch dass du nur das Root-Telefonbuch (root-hints) hast, alle anderen Einträge der Telefonbücher sind nur auf Auskunft vom Anbieter erhältlich. Wegen diesem Aufwand schätzt die Telefonzetrale wie lange die Nummer wohl mindestens noch gültig ist (TTL) und jeder hat ein kleines Büchlein bei sich wo er alle Telefonnnummern rein schreibt bis diese TTL abgelaufen ist.
----
Rekursiv: Du rufst die Auskunft an welche bereits kürzlich das Prozedere für einen anderen Anrufer für Herrn M. gemacht hat und sie kann dir seine Durchwahl direkt geben.

auch zwei DNS hinterlegt (PiHole und Quad9), übergeben vom DHCP
Achtung; meines Wissens ist das Verhalten bei Alt.DNS nicht standardisiert. Das Betriebssystem kann also auch schlicht round-robin an beide load-balancen oder nach sonstigem Verfahren entscheiden dass es Quad9 lieber hat, was dann deine Filterung unzuverlässig macht.


primärer DNS ist Router / Gateway und es gibt ein DNS Forward zum Windows Server wegen der ActiveDirectory :)
Hmm, ich bin mir nicht sicher ob das eine unterstützte Konfigurationsmöglichkeit ist, aber das können dir die Windows-Spezis vermutlich besser sagen. Aus dem Kopf muss man die DNS-Konfiguration eher auf dem AD-Server festlegen und diesen dann als DNS-Server auf den AD-Clients konfigurieren.

Es ist erstaunlich, wenn man sieht was alles eine DNS Anfrage stellt
Kleine aber wichtige Anmerkung hier; sowohl im privaten Umfeld (Mitbewohner) als auch Firmenumfeld aber insbesondere bei Gästen relevant ist dass die Standard-Loggingmethode von Pihole weit über DSGVO rausgeht. Sofern das Loggen nicht relevant ist, empfehle ich deutlich die Kurzzeit- und Langzeitlogs von Pihole (getrennte Optionen) zu anonymisieren oder deaktivieren. Klar gehen einem dann viele interessante Informationen verloren aber andere Leuten wollen vermutlich auch nicht dass zB die Visiten auf... der Bildzeitung.... langzeitarchiviert werden inklusive Gerät und Zeitstempel.
 
Aufgrund des RFC 4941 IPv6 Privacy Extension können die IPv6 Adresse zusätzlich noch konstant ändern.
Bezieht sich das nicht auf die Adressen die NICHT zu den "fe80::" gehören? Es gibt ja zwei Adressbereiche (fe80:: und noch einer) die ja nur Lokal möglich sind und diese sollten doch relativ kontant sein. Dann gibt es ja noch die anderen (Beispiel 2003::) die ja innerhalb eines 56er Subnetz (Telekom) rollieren sollen um ein wenig Privatsphäre zu erhalten. Aber zurück zu den "fe80" Adressen, theoretisch könnte man diese ja auch aufsteigend via DHCPv6 behandeln, denke ich mal. Aber du hast schon mit der ersten Aussage recht, IPv4 ist einfach und simple :D

Natürlich hab ich jetzt auch kein handelsüblichen Adressraum wie "192.168.0.0/24", aber selbst meine drei Räume (10.12.x.0/24, x ist je nach VLAN anders) kann ich gut und schnell zuordnen.

Dazu reicht über DHCP nur die IPv4-IP für DNS mit zu teilen und alle Clients verwenden IP4v4 zur Auflösung während ausgehend von Pihole/Unbound weiterhin IPv6 verfügbar bleibt.
Ich müsste mal in meiner UDM-Pro schauen, ob ich dieser sagen kann, dass die DHCPv6 machen kann / darf, aber nur den DNS IPv6 nicht verteilen soll / darf. Die Namenauflösung bekommen sie ja dann vom 'unbound', dieser kennt ja dann sowohl die IPv4 als auch IPv6 und dank des eingetragenen Gateway (IPv4 und IPv6) sollten die Clients dennoch alles erreichen können. Keine Ahnung, ob ich das den Geräten so vermitteln kann, muss ich aber nachher mal schauen.

Von deiner Beschreibung hast du es richtig verstanden, von der Analogie aber leider falsch
Ja, stimmt vollkommen... an sich ist das ein Telefonbuch welches auf andere Telefonbücher verweist, welches weiter verweist etc. Generell ist es nur einfacher den Leuten zu erklären, dass es wie ein Telefonbuch ist, denn da gibt es (wenn ich mich nicht irre) ja auch die grobe Variante bis hin zum örtlichen Telefonbuch.
a.) Ländervorwahl (+49, +43 etc.)
b.) Ortsvorwahlgebiete (030, 040, 060 etc.)

Zumindest bin ich mir relativ sicher, dass in einem Telefonbuch was wir vor X Jahren mal erhalten haben, keine Rufnummern aus Frankfurt oder München hatten, wenn wir in Hamburg oder Berlin wohnen :D

Kleine aber wichtige Anmerkung hier
Vollkommen verständlich... wenn ich das Teil in der Firma einbinden würde, würde Chef mich vermutlich verhauen :D Den Kolleginnen und Kollegen wäre das wohl egal, die gehen davon aus dass ich als IT Admin im Haus sowieso alles sehe (könnte ich ja theoretisch auch), aber Chef würde dann ausrasten, weil ich vermutlich im Query Log sehe wie oft er Facebook oder andere Gaming Plattformen aufruft, wobei ER dann der erste wäre der "hier" ruft, um selbst schauen zu können und das wollen die anderen gar nicht erst :D
 
Nicht genauer angesehen, aber genau Euer Vorhaben mit Unbound auf Pi-Hole: https://www.youtube.com/embed/tiMegG6nwvs

Nebenbei braucht man für Pi-Hole definitiv keinen Raspi, sondern kann das mit einem Befehl auch auf z.B. einer VM auf dem NAS, einem heimischen Virtualisierungshost (z.B. Proxmox oder auch Unraid als NAS System mit VM Möglichkeit) oder sonstwo installieren.

Eine nette Sache von Pi-Hole ist auch, dass man sich lokale DNS Records (im Netzwerk) setzen kann. Damit braucht man dafür keine hosts Files ändern und die Records gelten fürs gesamte Netzwerk.
 
Last edited by a moderator:
aber genau Euer Vorhaben mit Unbound auf Pi-Hole:
TLDR? :p Die offizielle war ja auch bereits verlinkt ^^

Nebenbei braucht man für Pi-Hole definitiv keinen Raspi, sondern kann das mit einem Befehl auch auf z.B. einer VM auf dem NAS, einem heimischen Virtualisierungshost (z.B. Proxmox oder auch Unraid als NAS System mit VM Möglichkeit) oder sonstwo installieren.
Absolut, ich betreibe meinen als LXC Container auf Proxmox. Wichtig ist aber dass Pihole sehr empfindlich auf hohe IO-Last des Hosts reagiert und mitunder extrem zäh auf DNS-Anfragen antwortet wenn seine Logs nicht geschrieben werden können. Durch Modifikation der Mountpoints kann man es etwas verbessern. Ich habe ihn aus diesem Grund von den Datenplatten auf die "local" Systemplatten migriert.

Bezieht sich das nicht auf die Adressen die NICHT zu den "fe80::" gehören? Es gibt ja zwei Adressbereiche (fe80:: und noch einer) die ja nur Lokal möglich sind und diese sollten doch relativ kontant sein.
Ich habe es nicht genauer in den RFCs überprüft, laut kurzer Recherche ist das aber durchaus erlaubt.

Natürlich hab ich jetzt auch kein handelsüblichen Adressraum wie "192.168.0.0/24", aber selbst meine drei Räume (10.12.x.0/24, x ist je nach VLAN anders) kann ich gut und schnell zuordnen.
10/8, 196.68.xx, 172.16-31.xx sind ja alle private Networks :) Persönlich finde ich nur die 172. etwas exotischer da es nicht eine volle Bitmaske ist die privat ist. Aus Kuriosität; betreibst du das ganze Heimnetz über managed-switches/managed-AP?
 
Aus Kuriosität; betreibst du
Hab Ubiquiti Hardware hier bei mir zuhause im Einsatz. Draytek Vigor als DSL Modem, dahinter meine UDM-Pro, dahinter ein Ubiquiti Switch und dahinter Ubiquiti Access Points sowie Kameras. Am Switch hängen dann die PCs, mein HP Gen 8 MicroServer (Link aggregation) und an der UDM direkt hängt meine FritzBox 7490 als "Telefonanlage" :) Falls ich deine Frage korrekt verstanden habe.

10/8, 196.68.xx, 172.16-31.xx sind ja alle private Networks
Ja, dass 172er Netz hab ich so auch noch nie benötigt... ich glaube dass ist eher ein "Fallback" Bereich, wenn mal eine FritzBox nicht so will, bin mir aber auch nicht 100% sicher.


aber genau Euer Vorhaben mit Unbound auf Pi-Hole
Jou, die Videos von Raspberry Pi Cloud hatte ich mir vorher angeschaut, bevor ich los legte :) Nachdem ich ja nun auch sah, wie simple sich der PiHole auf einem Linux System installieren lässt, könnte ich auch den PiHole auf meinem HP ProLiant installieren. Der hat ne 64 GB SSD als Systemplatte, dann sollte die hohen I/O Last kein Problem mehr sein und die SD Karte des Pi wäre wieder entspannter :) Vielleicht sollte es mal Gehäuse für den Raspberry mit SSD Fach geben, aber das ist dann ein anderes Thema :D

Ich war zwar nicht gemeint, musste aber echt einmal die Suchmaschine fragen was genau damit gemeint war :D Aber auf "too long; didn’t read" wäre ich wohl im Leben nicht gekommen... aber gut, man lernt ja nie aus und ich vergesse es bestimmt irgendwann wieder.
 
Pihole läuft übrigens wunderbar in Container (LXC bei mir), kann also ohne Weiteres auf deinem Ubuntu-Server laufen.
Was die Container angeht, hab sonst immer direkt mit VM und nicht mit Container gearbeitet... aber dazu mal eine Frage, die Vor- und Nachteile hatte ich schon gesehen, aber kann man den Containern (Docker oder LXC) auch eine separate IP verpassen?

Ich würde dann den PiHole auf meinen Ubuntu Server packen (IP: 10.12.0.1), aber ich würde gerne den Port 80 (den dieser LightHTTP verwendet), frei halten falls ich wieder einen Apache für irgend welche anderen "Spielereien" installiere. Oder gibt es da andere Szenarien wie man das mit Containern macht? Ich hab immer "Virtualisierung" im Kopf, aber das ist es ja nicht so richtig...

Nach Anwendungsbeispielen / Szenarien hatte ich schon mal geschaut, aber die Informationen dass man die Container schnell von Maschine zu Maschine oder in eine Cloud bringen kann, haben mir noch nicht das beantwortet was mich eigentlich interessiert.
 
Pi-Hole in einem Container geht, braucht aber einige Spezialitäten.

Ansonsten würde ich in einer containerisierten Umgebung den Port 80 und 443 des Hosts (und Portweiterleitung im Router) für den Nginx Proxy Manager freihalten, der Dir wiederum alle Webanwendungen (sub)domainbasiert proxied und dabei Let's Encrypt Zertifikate automatisiert erstellt und erneuert. Ich schau mich selbst gerade durch die Compose Files und Videos von https://www.the-digital-life.com/ und anderen. Er hat das gut zusammengeschrieben und die wichtigsten Container (Portainer, Nginx Proxy Manager, Watchtower, etc.) für einen vernünftige Basis schon vorexerziert.

Container sind für mich auch noch neu, eine Beschäftigung damit ist aber sehr lohnend, da hiermit ein komplexes Update oder eine schwierige Installation einer Anwendung einfach nur ein Starten bzw. Neuziehen eines Containers (oder eines Stacks von Containern) ist. Downtime: 3 Sekunden -> neue Version drauf. Für mich verschiebt sich aktuell die Komplexität vom Einrichten der Anwendung zur Schaffung der richtigen Umgebung für den Container / der richtigen Konfiguration des Containers (Run Befehl, docker-compose File).

Im Verglecih zu VMs sind Container auf der einen Seite deutlich ressourcensparender, da sie nur genau benötigen was sie wirklich gerade brauchen, auf der anderen Seite können Container aber auch auf ALLE Ressourcen (z.B. CPU Kerne) des Hosts zugreifen, wenn benötigt. Im Endeffekt bekommt man deutlich mehr Anwendungen auf einen Host. Prinzipiell sind die Container erst mal voneinander isoliert, man kann sie aber über (interne) Overlay Netzwerke miteinander koppeln, wenn sie miteinander reden können sollen (z.B. Webanwendungscontainer und Datenbank Container).

Wenn Du eh schon einen Virtualisierungshost hast, kannst Du ja mal mit einer Minimalinstallation von Debian oder Ubuntu Server anfangen und Dir einen Stack aufbauen.
 
Moin, ich hatte mich gestern mal mit Docker und dem PiHole befasst... an sich den PiHole dort hinein zu bringen und dann diesen anderen Ports (z.B. Port 8080:80) zu starten hatte auch schon geklappt. Selbst wenn ich 53:53 für DNS Anfragen einbringe, hatte es schon geklappt... ich muss dann nur mal schauen wie das mit einem weiteren Docker und "unbound" funktioniert, aber da habe ich dann gestern Abend aufgehört. Ich werde wohl die Tage mal Abends innerhalb einer VM ein minimales Debian installieren (irgendwas gefiel mir an dieser neuen Ubuntu 20.04 Live Server ISO nicht) und dann noch einmal herum experimentieren :)

Am Wochenende wollte ich sogar mal schauen, ob ich einen IPv6 Gateway vermitteln kann, aber den IPv6 DNS weg lassen kann, um im PiHole Log nur die IPv4 drin zu haben, aber das ist ein anderes Thema und jammern auf hohem Niveau :D

Was meinen ProLiant Gen 8 angeht, dieser läuft jetzt mit Debian 10 und nicht mehr mit Ubuntu (es sollte 20.04 LTS werden), aber das macht den Kohl jetzt nicht fett. An sich dachte ich nur an Docker (oder andere Lösungen), um mir die Optionen frei zu halten, sollte ich doch nochmal was installieren was selbst gerne den Port 80 belegt (z.B. Apache) :)
 
, aber kann man den Containern (Docker oder LXC) auch eine separate IP verpassen?
Docker und LXC haben funktional nicht sehr viel gemeinsam - Docker betreibt ephimerale Container auf Basis eines Templates, während LXC daraus ausgelegt ist, Gast-Betriebssysteme vollständig inklusive root aber ohne Kernel zu betreiben.
LXC hat also sehr ähnliche Funktionen zur VM-Attribution (RAM, CPU-Ressourcen, IP, ...) mit dem Vorteil dass ein Container nur die Ressourcen der Applikation belegt; Cache, Systemressourcen, ... werden nur 1x auf dem Host verwaltet.
Docker erlaubt keine dedizierte IP meines Wissens, außer er verwaltet ein eigenes IP-Netzwerk - ansonsten fährt man über Ports auf dem Host.

Anmerkung: "Docker" wird oft als Synonym für applikative Container benutzt, also Docker, Kubernetes, containerd, ...

Oder gibt es da andere Szenarien wie man das mit Containern macht? Ich hab immer "Virtualisierung" im Kopf, aber das ist es ja nicht so richtig...
Sowohl Virtualisieren als auch Systemcontainer sind kein Problem unter Ubuntu. Für LXC wäre die Installation ganz simpel "apt-get install lxc".

Nach Anwendungsbeispielen / Szenarien hatte ich schon mal geschaut, aber die Informationen dass man die Container schnell von Maschine zu Maschine oder in eine Cloud bringen kann
Der Hauptvorteil (imho) von Container ist, dass jede Applikation ihre getrennte und angepasste Umgebung hast. Kohabitation und die damit einhergehenden Kompatibilitätsprobleme sind schlicht kein Problem. Gut, das könnte man mit einer VM auch lösen, aber VMs haben sowohl für CPU als auch RAM signifikante Overheats. Bei mehreren VM's kann man gerne Gigabytes an RAM von Clients belegt sehen (Caches, Buffers, ...) welche dann für andere VM verloren sind - die Lösungen wie auto-ballooning machen oft Probleme mit Applikationen welche sich an der verfügbaren RAM orientieren. Container kosten keinen wirklichen Overhead in RAM oder CPU, haben aber funktionale Einschränkungen wenn man "besondere" Funktionen verwenden will (und sei es nur FUSE)


Pi-Hole in einem Container geht, braucht aber einige Spezialitäten.
Docker-Container, definitiv. LXC-Container, keinerlei Besonderheit.

da hiermit ein komplexes Update oder eine schwierige Installation einer Anwendung einfach nur ein Starten bzw. Neuziehen eines Containers (oder eines Stacks von Containern) ist. Downtime: 3 Sekunden -> neue Version drauf.
Sofern möglich erlaubt sowohl ein Docker-Stack als auch ein Kubernetes-Deployment zero-downtime. Docker startet dazu die neuen Container bevor die alten stoppen und übergibt die Kontrolle, während Kubernetes weitere Instanzen startet und dann die alte Instanz im Router drainen geht bevor sie gestoppt wird.

Container aber auch auf ALLE Ressourcen (z.B. CPU Kerne)
Standardmässig, ja. Das lässt sich aber throtteln. Entweder über hardthrottling oder über Schedule-Throttling (aka "burstable"). Letzteres hat den Vorteil dass Container die Ressourcen auslasten können wenn keine andere Instanz sie belegt.
 
Wichtig ist aber dass Pihole sehr empfindlich auf hohe IO-Last des Hosts reagiert und mitunder extrem zäh auf DNS-Anfragen antwortet wenn seine Logs nicht geschrieben werden können.
Moin, ich wollte mich auch nochmal zu Worte melden... also meinem RPi hab ich ein Gehäuse von barrybase organisiert. Die habe da so ein Gehäuse in das man den RPi 4 einbauen kann und diesen anschließend via M.2 SSD betreiben kann. Dazu kommt, dass da auch ein kleiner Lüfter drin verbaut ist. Mein RPi hatte nämlich immer so um die 60 - 65 Grad! Ich vermute mal, der kann das locker und auf Dauer ab, aber nun liegt er bei 43 - 47 Grad und das (finde ich) ist wesentlich charmanter. Dank der M.2 SSD, werde ich die Tage auch mal mit Docker genauer herum experimentieren und mir vielleicht den "Volkszähler" wieder installieren, da ich ein Lesegerät am Stromzähler habe :) Aber das sind andere Themen.

Der PiHole tut auf jeden Fall seinen Dienst, hier wird ein wenig was weg geblockt, auch mit eigenem resolver (unbound) funktioniert alles doch sehr gut. Als der PiHole auf meinem Server lief, musste ich die '/etc/hosts' nochmal anpassen, da dort der Eintrag 127.0.1.1 für "server" hinterlegt war und meine Clients die IP zum "server" nicht mehr korrekt auflösen konnten :D

Aber nachdem ich die Tage schon mal ein wenig mit Docker herum experimentiert hatte, hab ich wirklich ein paar Dinge im Hinterkopf gehabt die man dadurch ganz gut "abkapseln" kann. Bei mir sind das jetzt keine lebenswichtigen Dienste, aber in größeren Unternehmen oder Umfeldern, gibt es da mit Sicherheit auch andere Szenarien.

So, dass war erst einmal mein "Wort zum Samstag" ;)
 
Back
Top