Einrichtung von Pi-hole mit keepalived und Docker-Containern, Teil 1

Das schwarze Loch für die Internet-Reklame – so nennt sich Pi-hole, zugegebenermaßen etwas frei übersetzt. In diesem Artikel möchte ich die Konfiguration von Pi-hole beschreiben, wie sie seit einigen Wochen im heimischen Netzwerk eingerichtet ist. Dabei gehe ich vom vorherigen Status aus und zeige den Weg zum hochverfügbaren Betrieb von Pi-hole mit Hilfe von Keepalived, einer “floating IP” und natürlich Docker.

Im ersten Teil dieses Artikels werde ich den Weg vom Status quo zur finalen Lösung skizzieren und auf die verwendeten Komponenten sowie deren Verwendung eingehen. Der zweite Teil beschreibt schließlich die Konfiguration im Detail, darin werden sich insofern auch entsprechende Konfigurationsdateien und einige Skripte finden.

Pi-hole von oben – eine Übersicht

Pi-hole ist ein Paket aus verschiedenen Programmen, die letztlich einen DNS-Server bereit stellen. Wird dieser DNS-Server im Netzwerk genutzt, werden Anfragen an diejenigen Domains blockiert, von denen bekannt ist, dass sie zur Auslieferung von Werbung genutzt werden. Das führt dazu, dass Werbung effektiv blockiert wird, denn für den Fall, dass der Browser versucht, eine entsprechende Werbe-Domain zu erreichen, wird vom DNS-Server einfach zurück gegeben, dass diese Domain nicht existiert, insofern kann auch keine Werbung ausgeliefert werden. Pi-hole blockiert laut eigenen Angaben über 100.000 bekannte Werbe-Domains, aktuell sind es sogar noch weitaus mehr, die Listen werden von der Community bereit gestellt und regelmäßig aktualisiert.

Zugegebenermaßen war ich anfangs skeptisch, nicht zuletzt klingelte immer der Zensur-Teufel im Hinterkopf, aber dennoch wollte ich Pi-hole zumindest einmal ausprobieren und war schnell überzeugt. Einerseits lassen sich eigene White- sowie Blacklists pflegen, d.h. falls doch einmal eine Domain zu viel oder zu wenig blockiert werden sollte, lässt sich dies leicht beheben. Auch für Adblocker-Blocker und deren Gehilfen ist mitunter ein Eintrag auf der Whitelist notwendig. Andererseits funktionieren die Listen erstaunlich gut, womit sich wiederum die jeweils im Browser installierten Adblocker einsparen lassen, denn letztlich stellen diese dieselbe Funktionalität bereit, nur eben nicht zentral im Netzwerk, sondern für jeden Browser einzeln. Der große Vorteil von Pi-hole ist, dass es an zentraler Stelle im Netzwerk agiert und somit auch (Werbe-)Requests aller angeschlossenen Geräte erfasst, etwa Amazon Echo in all seinen Inkarnationen, den diversen Servern mit entsprechende Software, und natürlich nicht zuletzt Handys, Tablets etc.. Pi-hole besitzt ein sehr schmuckes web-basiertes Admin-Interface, das einem neben einem Dashboard auch einen tieferen Einblick in die DNS-Anfragen bietet.

Tatsächlich war ich nach wenigen Tagen Probebetrieb durchaus erstaunt, wie viele und vor allem welche DNS-Anfragen stattfinden – und zwar nicht nur an diejenigen Sites, die Pi-hole blockiert, sondern auch völlig reguläre Anfragen, die von Pi-hole korrekt beantwortet werden. Eine Live-Beobachtung der letzten Anfragen kann durchaus spannend sein… Das Admin-Interface war ein wesentlicher Aspekt, der mich überzeugt hat, Pi-hole einsetzen zu wollen. Insofern kann ich nur jedem empfehlen, Pi-hole einmal selbst auszuprobieren und dann zu entscheiden, ob die Nutzung sinnvoll erscheint oder nicht.

Wie der Name Pi-hole nahe legt, funktioniert das System auch auf einem Raspberry Pi Kleinstrechner. Tatsächlich sollte eine derartige Infrastruktur auch in den meisten Fällen ausreichen, insbesondere für den Betrieb im heimischen Netzwerk. Doch da ich bereits konventionelle DNS-Server eingesetzt habe, war der Raspberry Pi für mich keine sinnvolle Option. Statt dessen wollte ich die bisherige Infrastruktur einer gründlichen Renovierung unterziehen – oder vielmehr einem Abriss und Wiederaufbau.

Zwei DNS-Server fürs Netz

Die klassische Struktur findet sich in folgender Übersicht:

Es handelt sich um zwei virtuelle Maschinen (VM), die auf zwei unterschiedlichen Hosts eingerichtet sind. Sie besitzen jeweils zwei IP-Adressen – eine Standard-IP-Adresse, mit der sie im Netzwerk bekannt sind, und eine speziell für den DNS-Server. Für den Fall, dass die DNS-Server-Software auf andere VMs umgezogen werden sollte, kann die IP-Adresse des DNS-Servers beibehalten werden, indem sie einfach als zweite IP-Adresse auf dem neuen Server eingerichtet wird. Somit ist keine Änderung der DNS-IP-Adressen innerhalb der Clients notwendig – wozu ich auch Router o.ä. zähle, die letztlich die DNS-IP-Adressen per DHCP weitergeben oder als Proxy fungieren.

Die DNS-Server-Software BIND ist dabei klassisch als Daemon eingerichtet, die Daten werden automatisch bei Änderung auf dem Primary DNS vom Secondary DNS übernommen. Der entscheidende Grund, überhaupt eigene DNS-Server zu betreiben, liegt in meinem Nutzungsszenario – meine “lokale” Domain geschke.net existiert auch im weiten Internet da draußen. Das hat den Vorteil, dass ich lokal bzw. im Netzwerk mit einer “echten” Domain testen und entwickeln kann bzw. nicht mit Vehikeln wie .local oder ähnlichen Pseudo-Domains agieren muss. Innerhalb des lokalen Netzwerks lassen sich somit Domains definieren, die direkt von den eigenen DNS-Servern beantwortet werden, somit kann ich allen VMs bzw. Maschinen im Netzwerk IP-Adressen aus dem privaten Adressbereich zuweisen und sie unter ihrem Namen ansprechen. Alle DNS-Anfragen, die über die lokal verwendeten Domains hinaus gehen, werden an andere DNS-Server weiter geleitet, was nichts anderes ist, als wenn der Client direkt die z.B. vom Provider, Google oder anderen Institutionen bereit gestellten DNS-Server nutzen würde, nur dass die Anfrage eben von einem der heimischen DNS-Server kommt.

Da DNS-Server so eminent wichtig sind, sind diese bereits per Default ausfallsicher angelegt. Wobei – bezüglich dieser Definition lässt sich prima diskutieren, an dieser Stelle ist es jedoch eher relevant, darauf hinzuweisen, dass jeder Client die Möglichkeit bietet, mehrere DNS-Server einzutragen. Falls einer nicht erreichbar ist, wird versucht, den nächsten zu erreichen. Und die DNS-Server-Software wiederum erlaubt die Unterscheidung in Primary und Secondary, wobei die als Secondary bzw. Slave  deklarierten Server die Änderungen vom Primary bzw. Master per Zonentransfer übernehmen. Danach besitzen beide DNS-Server identische Datenbestände und können Anfragen beantworten.

Diese Funktionalität wollte ich auch beim Einsatz von Pi-hole nicht missen, denn falls etwa zu Wartungszwecken einmal einer der VMs oder gar der Host abgeschaltet werden muss, sollen die Clients auch weiterhin DNS nutzen können, ansonsten wäre der komplette Betrieb nahezu lahm gelegt. Letztlich wurde es jedoch eine andere Art von Ausfallsicherheit, dazu gleich mehr.

Einsatz von Pi-hole – Vorüberlegungen

Um zu verstehen, weshalb ich mich für die gleich vorgestellte neue Struktur entschieden habe, müssen ein paar Vorüberlegungen getroffen werden. Diese beziehen sich auf die Datenhaltung und Praktikabilität der Admin-UI-Nutzung.

Pi-hole Daten und Datenbank

Wie bereits erwähnt, bedient sich Pi-hole mehrerer Listen von Domains, anhand der das Matching von Ad-relevanten Domains erfolgt. Darüber hinaus müssen eigene Black- und Whitelists gespeichert werden. Zur Bereitstellung der Statistiken im Pi-hole-Web-Interface werden die DNS-Requests getrackt und in einer SQLite-Datenbank abgelegt. Dabei ist der SQLite-Code Bestandteil der zentralen Komponente FTLDNS von Pi-hole. FTLDNS beantwortet jedoch nicht nur DNS-Anfragen, sondern dient auch als API für das Web-Interface. SQLite ist jedoch kein klassischer Datenbank-Server, der Anfragen von Clients entgegen nimmt und etwa Transaktionssicherheit bietet, sondern darf als eingebettete SQL-Library gelten, die ihren Fokus nicht darauf hat, parallele Schreibzugriffe zu ermöglichen. Im Gegenzug ist SQLite schnell, klein, unkompliziert, ausgereift und für den ursprünglichen Einsatzzweck – man bedenke den Raspberry Pi – sehr gut geeignet, da der Overhead eines kompletten Datenbankverwaltungssystems entfällt. Das führt direkt zum zweiten Punkt.

Nutzung der Admin-UI

Standardmäßig speichert Pi-hole alle notwendigen Daten, d.h. Listen, Konfiguration und die Datenbank-Datei in einem Verzeichnis. Gesetzt den Fall, man würde mehrere Pi-hole-Systeme gleichzeitig betreiben, müssten diese entweder auf ein gemeinsames Verzeichnis zurück greifen oder aber jeweils ein eigenes, lokales Verzeichnis besitzen. Beides hat seine Nachteile.

Je nach Client lässt sich nicht vorher sagen, welcher DNS-Server, d.h. ob primary oder secondary genutzt wird. Es ist also nicht festgelegt, dass zunächst der erste, und nur im Fehlerfall der zweite angefragt wird. Beispielsweise ist die Verteilung laut Pi-hole-Dashboard, d.h. der Nutzung der Upstream-DNS-Server nahezu gleich. Wenn nun zwei Pi-hole-Instanzen auf ein gemeinsames Verzeichnis zugreifen würden, und jede Instanz z.B. autark die Listen aktualisiert bzw. auf die SQLite-Datenbank zugreift, kommt es früher oder später zu Konflikten, die vermutlich das Schreddern einiger Daten zur Folge haben würden. Zwar lässt sich der parallele Zugriff auch mit der vorgestellten Struktur nicht unter allen Umständen vermeiden, aber die Gefahr zumindest entschärfen.

Wenn hingegen mehrere Pi-hole-Instanzen jeweils auf eigene Daten-Verzeichnisse zurück greifen würden, hätte man auch zwei Admin-Interfaces mit jeweils unterschiedlichen Angaben, zwei Stellen, an denen Black- und Whitelist gepflegt werden müssten usw.. Insbesondere die Nutzung der Admin-UI legt es also nahe, dass es einen “Single Point of Truth” geben sollte, der die gesamte Sicht auf die Datenhaltung widerspiegelt.

Performance der DNS-Requests

Wenn selbst ein kleiner Raspberry Pi für die Beantwortung von DNS-Anfragen im Netzwerk ausreicht, sollte das doch erst recht für eine VM gelten, auf der nichts anderes als ein DNS-Server und Pi-hole läuft. Insofern würde auch ein einziger DNS-Server genügen, vorausgesetzt, dieser ist immer erreichbar bzw. es werden Maßnahmen zur Ausfallsicherheit getroffen. Tatsächlich ist die Performance kein Problem. In den ersten Tests ergaben sich innerhalb von 24 Stunden weit über 100.000 DNS-Requests, die von Pi-hole beantwortet wurden, durchschnittlich sind es im regulären Betrieb knapp unter 100.000 pro Tag. Manche Konfiguration verursacht im Fehlerfall sehr viele DNS-Requests, doch Pi-hole war jederzeit in der Lage, damit zurecht zu kommen.

Das Ergebnis dieser Überlegungen lässt sich somit zusammenfassen:

  • Die Datenhaltung (Listen, Konfiguration, Datenbank) soll aufgrund der Struktur und der von Pi-hole eingesetzten Komponenten an nur einer Stelle erfolgen.
  • Eine Pi-hole-Instanz, d.h. ein mit Pi-hole bestückter DNS-Server ist ausreichend.
  • Es müssen Maßnahmen zur Sicherstellung des Betriebs im Fehler- oder Wartungsfall getroffen werden – Stichwort Ausfallsicherheit.

Der Wiederaufbau mit neuer Infrastruktur

Dies führt zur folgenden neuen Struktur, hier in der Übersicht:

Im Folgenden einige Erläuterungen zu dieser Lösung – von oben nach unten betrachtet.

Floating IP

Eine Floating IP – oder auch virtuelle IP-Adresse – kann flexibel einer von mehreren VMs bzw. allgemein Nodes zugewiesen werden. Je nach Verfügbarkeit kann die IP-Adresse somit im konkreten Fall entweder zur ersten virtuellen Maschine (VM1) oder zur zweiten (VM2) gehören. Die IP-Adresse wird dabei nicht innerhalb der Netzwerk-Konfiguration fest definiert, sondern vom Keepalive-Daemon (Keepalived) auf beiden VMs verwaltet und mittels Virtual Router Redundancy Protocol (VRRP) einem Node zugewiesen. Das Ziel ist somit, nur eine IP-Adresse für den DNS-Server zu verwenden, die in den Clients bzw. im Router eingetragen wird. Fällt der aktive Node aus oder kommt es zu Problemen, sorgt Keepalived dafür, dass die IP-Adresse dem anderen Node zugewiesen wird. Danach kann Keepalived weitere Aktionen ausführen, im konkreten Fall wird ein Skript angesteuert, das wiederum dafür zuständig ist, die zweite Pi-hole-Instanz bzw. dessen Docker-Container zu starten.

Damit wäre auch bereits das Grundkonzept der angestrebten Lösung dargelegt: Ein Pi-hole-Container läuft auf einem Master genannten Node, wobei Node hier analog zu VM zu verstehen ist. Alle Clients erreichen den DNS-Server über eine IP-Adresse, und nur diese wird von den Clients genutzt. Der Status der beiden Nodes wird durch Keepalived überwacht, bei Ausfall wird die IP-Adresse auf den Backup-Node gelegt, so dass die DNS-Anfragen dort ankommen. Ist der Master wieder verfügbar, sorgt Keepalived ebenfalls dafür, dass die Floating IP wieder zurück marschiert.

Master und Backup sind insofern keine gleichberechtigten Nodes im Netzwerk, was eine gewisse Analogie zum DNS-Server an sich und deren Handhabung als Primary und Secondary darstellt.

Mehrere IP-Adressen

Die VMs besitzen erneut, d.h. wie im eingangs erwähnten Status quo, mehrere IP-Adressen. Dabei handelt es sich neben der Default-IP im Netzwerk um eine IP-Adresse, die für den DNS-Server reserviert wird, was einen Umzug auf eine andere VM erleichtert. Dasselbe Konzept gilt für die Adressen der DNS-Server, die von Pi-hole bereit gestellt werden, die ebenfalls einen festen Wert besitzen. Daneben soll Pi-hole wie beschrieben über die Floating IP angesprochen werden können, dazu bedarf es allerdings nur einer Anpassung der Konfiguration im Docker-Startkommando. Es mag auf den ersten Blick ein wenig überdimensioniert erscheinen, aber auf diese Art und Weise bleibt alle Flexibilität der Nutzung der DNS-Server erhalten. Beispielsweise gibt es Fälle, in denen man Werbeeinblendungen sehen möchte, etwa als Test, ob die Ads auf den eigenen Web-Seiten funktioniert. Eine Möglichkeit wäre, innerhalb von Pi-Hole eine Whitelist zu pflegen, doch diese würde sich auf alle angeschlossenen Clients auswirken. Besser wäre es, wenn die DNS-Server ohne Pi-hole genutzt werden könnten, und genau das ist mit dieser Struktur möglich.

Zusammengefasst ergibt sich folgende Tabelle:

IP alt Verwendung IP neu Verwendung
192.168.10.38 IP der VM 192.168.10.38 IP der VM 1
192.168.10.52 IP der VM 192.168.10.52 IP der VM 2
192.168.10.20 Primary DNS 192.168.10.20 Pi-holed DNS (Backup)
192.168.10.21 Secondary DNS 192.168.10.21 Pi-holed DNS (Master)
192.168.10.220 Primary DNS (ohne Pi-hole)
192.168.10.221 Secondary DNS (ohne Pi-hole)
192.168.10.19 Floating IP Pi-holed DNS

 

Hinweis: Da der Host, auf dem der Secondary DNS betrieben wird, leistungfähiger ist, habe ich den Master von Pi-hole auf den Node vom Secondary DNS Container gelegt und umgekehrt. Da die IP-Adressen von Pi-hole jedoch eigentlich nicht direkt verwendet werden sollen, sondern ausschließlich die Floating IP, ist dies allenfalls anfangs verwirrend, für den Betrieb vom technischen Aspekt her jedoch irrelevant.

Docker für alle(s)

Oder vielmehr fast alles. Da ich bereits “dockerized” DNS-Server betreibe, sollte das Docker-Image auch diesmal zum Einsatz kommen. Zwar ein wenig entgegen des Konzepts von Docker, pro Image bzw. Container nur einen Service bereit zu stellen, beinhaltet das Docker Container Image for BIND DNS auch eine Webmin-Instanz zur einfacheren Einrichtung der DNS-Daten. Um Missverständnissen vorzubeugen – auch dabei muss man darauf achten, dass die DNS-Einträge korrekt sind, denn man kann sich in etwa genauso mächtig in den Fuß schießen wie bei der Einrichtung von BIND auf der Kommandozeile. Aber wenn die Web-UI quasi kostenlos “aus der Tüte fällt”, spricht auf nichts dagegen, sie zu verwenden.

Ebenfalls sollte Pi-hole als Docker-Container betrieben werden, das entsprechende Image wird nicht zuletzt von den Entwicklern als eine von zwei Installationsmethoden propagiert. Insofern nutze ich auch genau dieses Docker-Image, das alle Komponenten inklusive der Admin-UI beinhaltet. Dabei wird unter anderem die Floating IP an den Pi-hole-Docker-Container gebunden, so dass der Pi-holed DNS-Server unter dieser einen IP erreichbar ist. Im Optimalfall läuft zu einer beliebigen Zeit nur jeweils ein Pi-hole-Container auf einer der beiden VMs, gesteuert durch Keepalived.

Keepalived selbst habe ich hingegen nicht in Docker-Images gepackt. Denn in diesem Fall sehe ich keine Vorteile – Keepalived ist schnell eingerichtet, ist im Lieferumfang der gängigen Linux-Distributionen enthalten, aber der entscheidende Punkt ist, dass es eine sehr systemnahe Komponente ist, die immerhin die IP-Adresse des jeweiligen Hosts anpassen muss, dafür auch die entsprechenden Rechte benötigt usw., so dass ich die etwaigen durch den Einsatz von Docker induzierten Probleme gerne vermeiden wollte. Ein Docker-Keepalived-Image habe ich immerhin gefunden, was auch aktualisiert und gepflegt wird, vielleicht lohnt sich hier ein näherer Blick.

(verteiltes) Storage

Als Storage-Schicht fungiert in der angestrebten Lösung ein verteiltes Dateisystem. Dazu wird LizardFS genutzt, das seit einiger Zeit, genau genommen einige Monate (relativ) problemlos auf mehreren VMs läuft. LizardFS wird von den beiden VMs gemountet und steht somit direkt nach dem Booten zur Verfügung. Im von LizardFS bereit gestellten Verzeichnis befinden sich die eingangs erwähnten Verzeichnisse für Konfigurationsdateien, Listen und der SQLite-Datenbank von Pi-hole. Dem gegenüber kommen die BIND-DNS-Container ohne eine gemeinsame Dateiablage aus, d.h. die entsprechenden Verzeichnisse mit Zonen-Dateien etc. liegen nur im Dateisystem der VMs und werden beim Start der Docker-Container eingebunden.

Das Thema verteiltes Storage ist sicherlich diskussionswürdig, daher an dieser Stelle einige Hinweise. Im Normalbetrieb läuft das System hervorragend – der Pi-hole-Container aktualisiert Listen, agiert mit der SQLite-Datenbank-Datei usw., die Performance ist ausreichend, insofern ist alles im grünen Bereich. Der Vorteil des verteilten Storage-System ist ebenfalls, dass es keinen Single-Point-of-Failure gibt, LizardFS ist hier anhand seiner Konfiguration redundant ausgelegt, so dass auch dabei eine gewisse Ausfallsicherheit gegeben ist. Zur Konfiguration von LizardFS ließe sich noch weitaus mehr schreiben – wichtig erscheint mir der Punkt, dass es zunächst einmal funktioniert und die Performance wesentlich besser ist als beim zuvor getesteten ebenfalls verteilten Dateisystem GlusterFS.

Dennoch kann es aufgrund der Architektur von Pi-hole zu Problemen kommen, zumindest sollte man sich diesen Überlegungen bewusst sein. Wie weiter oben kurz erwähnt, kann keepalived nicht garantieren, dass zu jedem Zeitpunkt nur eine Instanz von Pi-hole läuft. Das passiert beispielsweise genau dann, wenn keepalived auf einem Node ad hoc nicht mehr funktioniert, insofern abstürzt. Oder wenn keepalived schlicht und einfach mit voller Absicht beendet wird. In diesem Fall läuft der Pi-hole-Container auf der VM weiter, während sich der keepalived auf dem zweiten Node um die Erreichbarkeit kümmert, d.h. die Floating IP auf den zweiten Node bringt und dort den Pi-hole-Container startet. Schon laufen zwei Pi-hole-Container parallel. Keepalived hat seine Aufgabe zwar hervorragend erfüllt, dennoch erfolgt damit der Zugriff zweier Pi-hole-Instanzen auf dieselben Dateien im verteilten Dateisystem. Zwar werden die DNS-Requests beim neu gestarteten Pi-hole-Container landen, aber dennoch könnten beispielsweise mehr oder minder gleichzeitig Listen updated werden. Die Frage lautet, was in solchen Fällen passieren könnte. Im schlimmsten Fall werden die Dateien und ebenso die Datenbank unbrauchbar, geschredderter Datenmüll. Was wäre die Folge? Die von der Community gepflegten Blacklists werden beim nächsten regulären Start von Pi-hole einfach wieder neu geladen, falls sie nicht im Datenverzeichnis existieren – insofern keinerlei Verlust. Die eigenen Black- und Whitelists wären evtl. verloren – hier empfiehlt es sich somit trotz aller Redundanzen, ein Backup anzufertigen. Die Datenbank mit Zugriffen für die Statistik wäre möglicherweise ebenfalls verloren oder es würden zumindest Einträge fehlen. Ich für meinen Fall könnte damit gut leben, schließlich handelt es sich nicht um lebensnotwendige oder unwiederbringliche Daten.

Ebenso stellt sich die Frage, inwieweit man LizardFS überhaupt vertrauen kann oder ob es nicht Alternativen gäbe. Natürlich gibt es die! Wie so oft führen hier viele Wege zum Ziel, von der Nutzung von NFS bis hin zum Ceph-Cluster ist es nur eine Frage des Aufwands, der in den Aufbau der Infrastruktur gesteckt werden soll. Oder man nutzt etwa DRBD, um eine Synchronisation der Dateisysteme zu erreichen. All diese Verfahren unterscheiden sich jedoch nicht vom Konzept her, somit kann es auch zu den beschriebenen Problemen im Worst Case kommen.

Eine weitere Möglichkeit wäre, die Synchronisierung der Listen und SQLite-Datenbank vom Master- auf den Backup-Node manuell bzw. in regelmäßigen Abständen per Cron o.ä. gesteuert, durchzuführen. Beispielsweise könnte alle fünf Minuten ein rsync-Kommando gestartet werden, so dass der Backup-Node regelmäßig mit den aktuellen Daten versorgt wird. Ein Nachteil dieser Methode ist sicherlich, es auch dabei zu Problemen kommen kann – falls Synchronisierung und Ausfall des Master-Nodes zufälligerweise gleichzeitig stattfinden sollten. Zudem würden im Datenbestand des Backup-Nodes auch immer die letzten fünf Minuten fehlen. Und falls der Ausfall des Masters länger dauert, müssten die zwischenzeitlich angefallenen Daten genau dann zurück auf den Master kopiert werden, wenn der Regelbetrieb wieder hergestellt ist. Letztlich obliegt es dem Nutzer, welcher Aufwand einem angemessen erscheint, um Ausfallsicherheit und Konsistenz zu erreichen bzw. inwieweit die Gewichtung aller Faktoren erfolgen sollte.

Ausblick

Das soll für diesen Teil genügen – die Ziele sind festgelegt, die Überlegungen zur Infrastruktur wurden getroffen, somit kann es im nächsten Teil direkt los gehen mit der eigentlichen Konfiguration von Keepalived, den Docker-Images bzw. Containern für DNS BIND sowie natürlich Pi-hole und den Skripten und Einstellungen, die alles erst zusammenhalten und den  ausfallsicheren bzw. hochverfügbaren Betrieb ermöglichen. Bis dahin – vielen Dank für die Aufmerksamkeit!

 

 

Tags:

Keine Wolke aus Russland – Yandex.Disk fehlt im c’t-Test der Cloud-Speicher-Dienste

In der aktuellen Ausgabe 23/2018 testet die c’t kommerzielle Cloud-Speicher-Dienste. Mit einiger Spannung und Neugier habe ich mir den Test durchgelesen, auch weil ich jenen Diensten immer etwas kritisch gegenüber stand, bis – ja, bis mit mehr oder minder zufällig Yandex.Disk begegnete. Bis dahin hatte ich privat Google Drive verwendet bzw. verwende es noch, ebenfalls das unter Windows obligatorische OneDrive, doch insbesondere die Synchronisierungsfunktionen hatten mich nicht überzeugt. Auf Google Drive lässt sich wiederum kaum verzichten, wenn man ein Android-Smartphone hat, es ist einfach zu praktisch, wenn die per Handy geschossenen Fotos bei der nächsten Gelegenheit, d.h. bei passender WLAN-Verbindung zur weiteren Bearbeitung in der Cloud landen. Mit der Windows-Anwendung hingegen stehe ich in Zwietracht, dasselbe gilt übrigens für das Pendant unter Mac OS X. Vielleicht handelte es sich aber auch um ältere Versionen, denn in der aktuellen Variante lassen sich sowohl Ordner des Computers synchronisieren als auch der Inhalt von Google Drive, ebenfalls lässt sich der Sync-Ordner ändern – eine für mich unumgängliche Funktion. Insofern rührte es eher aus der Vergangenheit, dass ich Google Drive zwar gerne über die Web-UI bedient, dabei auch die Office-Anwendungen genutzt habe, aber als weniger geeignet für die Verwendung per Synchronisierungs-Funktion auf dem Desktop empfunden habe.

Yandex – so nah und doch so fern

Vor kurzem bin ich jedoch auf Yandex.Disk gestoßen. Yandex als marktführende Suchmaschine in Russland war mir zwar bereits bekannt, aber neben der Suchmaschine bietet Yandex auch etwa einen E-Mail-Dienst, einen Kartendienst oder mit Yandex.Metrica einen Webanalyse-Dienst an – neben noch ungefähr 20 weiteren Services, von denen etwa die Hälfte nur in russischer Sprache verfügbar oder primär auf den russischen Markt ausgerichtet sind. Sogar ein Browser, der wiederum auf der HTML-Rendering-Engine Blink aus dem Chromium-Projekt basiert, die Opera-Turbo-Technologie beinhaltet und mit einem – meiner Ansicht nach – sehr zurückhaltenden und somit angenehmen User-Interface ausgestattet ist. Um es kurz zu machen – je weiter ich in das Yandex-Universum vorgestoßen bin, desto interessanter und ansprechender wurde es für mich. Im Zuge dieser Tests hatte ich mir auch den Cloud-Speicher namens Yandex.Disk angesehen, den ich im Test der c’t leider vermisst habe. Von den Features her hätte er sicherlich eine Erwähnung verdient, weshalb ich versucht habe, in der unten stehenden Tabelle soweit wie möglich die von der c’t getesteten Eigenschaften für Yandex.Disk darzustellen.

Dabei ist alles

Die Mindestvoraussetzungen scheinen gegeben – eine Desktop-Software zur Synchronisierung ist für Windows und MacOS X vorhanden, ebenso eine Smartphone-App für Android, iOS und Windows Phone, genau wie die Möglichkeit, dem Cloud-Speicher mit einer Web-Anwendung zu Leibe zu rücken. Ebenso ist ein Gratis-Kontingent von 10 GB verfügbar, wobei für Fotos und Videos die Regel gilt, dass bei Aktivierung der Funktion Auto-Upload die entsprechend hochgeladenen Fotos und Videos nicht in die Berechnung des Speicher-Kontingents einfließen. Der Auto-Upload funktioniert dabei analog zu Google Photos oder Amazon Photos und ist insbesondere innerhalb der mobilen Apps auf dem Smartphone praktisch – beispielsweise für Backup-Zwecke der mühsam erstellten Werke, falls einem der standardmäßige Upload auf Google Photos nicht ausreichen sollte. Für die mobile App lässt sich darüber hinaus ein Schutz per PIN oder Fingerabdruck aktivieren, so dass der Nutzer sich explizit für den Cloud-Speicher authentifizieren muss. Selbstverständlich ist der Auto-Upload auch abschaltbar. Die Medien-Dateien werden in einem speziellen Folder “Photo” gespeichert, die Web-App lässt sich von der Desktop-Anwendung mit einem Klick öffnen, es erfolgt jedoch keine Synchronisierung der Fotos und Videos in einen Desktop-Folder. Dies ist zumindest in der getesteten Version der Windows-Desktop-Anwendung auch nicht modifizierbar, wobei ich diese Funktion auch nicht vermisst habe. Die Fotos werden dabei chronologisch angeordnet, je nach Informationen im Bild wird auch der Ort der Erstellung angegeben. Ebenfalls lassen sich Fotoalben anlegen, die wiederum mit anderen geteilt werden können. Hinzu kommt, dass Fotos und Videos von sozialen Netzwerken (Facebook, Instagram, Google+ und das russische Pendant zu Facebook VK – früher VKontakte) importierbar sind, was eine Verküpfung voraussetzt. Die Fotos können umfassend in einer Web-Anwendung bearbeitet werden, die Online-Editier-Funktionen werden dabei von Aviary zur Verfügung gestellt, das wiederum zu Adobe gehört.

Die von der c’t als “unerlässlich” erachtete Versionierungsfunktion ist ebenfalls vorhanden, dabei bietet die kostenlose Fassung das Öffnen oder Wiederherstellen innerhalb von 14 Tagen an, was über die Web-Oberfläche mittels “Changelog” eingesehen werden kann. Auf dem Desktop lässt sich immerhin die vorherige Version wiederherstellen. Bei der Buchung der kostenpflichtigen Variante, die mit mehr Speicherplatz einher kommt, ist das Wiederherstellen im Zeitraum von 90 Tagen möglich.

Russische Technik

Zur grundlegenden Frage, ob es klappt, ob die Synchronisierung verlässlich ist, kann ich nur Erfahrungen aus etwa drei Monaten Betrieb bereitstellen, diese Frage lässt sich mit einem klaren “ja” beantworten. Auf aufwändigere Tests, etwa wie sich Yandex.Disk bei Versionskonflikten oder nahezu gleichzeitiger Speicherung von Änderungen verhält, habe ich jedoch verzichtet, denn eine gescriptete Lösung erschien mir dafür ein wenig Overkill zu sein, bzw. die c’t Redaktion hat dafür einfach geeignetere Ressourcen. Daher muss ich die Antwort dabei schuldig bleiben, was mit einem “?” in der unten stehenden Tabelle verzeichnet ist.

Ab in die Wolke

Eine Obergrenze der Bandbreite für den Up- und Download ist mit dem getesteten Windows-Client leider nicht einstellbar, jedoch lässt sich die Anzahl der parallelen Verbindungen auf eine beschränken. Möglicherweise hat die aktuelle Programmversion dabei weitere Fähigkeiten, momentan benutze ich die Desktop-Version 1.4.21, die als “legacy” angesehen werden kann. Yandex selbst bewirbt inzwischen die Version 3.0, die auch erweiterte Funktionen bzgl. der Synchronisierung und des Uploads einzelner Folder besitzt und via Windows-Explorer bereit stellt. Die Windows-Variante der Version 1.4.21 ist in englischer Sprache verfügbar, auf dem Mac hingegen begrüßt einen die Version 3.0 von “Яндекс.Диск” mit feinsten kyrillischen Zeichen. Glücklicherweise ist die Bedienung ansonsten identisch, dennoch bleibt zu hoffen, dass bald eine englische Fassung bereit steht. Andererseits hatte ich doch zu Schulzeiten tatsächlich versucht, Russisch zu lernen, vielleicht wird es mal wieder Zeit für eine Auffrischung…

Dateien können via Link freigegeben und direkt auf Social-Media-Sites geteilt werden, eine Funktion zum Kennwortschutz oder Ablaufdatum habe ich hingegen nicht gefunden. Ein Papierkorb im Cloud-Speicher ist ebenfalls vorhanden, wobei die Dateien im Papierkorb nach 30 Tagen automatisch entfernt werden, danach oder bei manueller Lösung aus dem Papierkorb ist keine Wiederherstellung mehr möglich.

Yandex.Disk integriert Microsoft Office Online, so dass die angelegten Dateien direkt im Cloud-Speicher abgelegt werden. Weitere Tests diesbezüglich habe ich nicht durchgeführt, da ich auch weiterhin Google Drive und somit Google Docs nutze.

Yandex bietet eine API für Entwickler sowie WebDAV-Zugang, mit dem so gut wie jeder diesen Standard unterstützende Client auf die Daten in der Cloud zugreifen kann. Getestet habe ich diese Funktionen jedoch bislang nicht.

Bei der Zwei-Faktor-Authentifizierung könnte Yandex.Disk etwas offener sein, die bisherige Unterstützung ist noch als “beta” gekennzeichnet. Yandex bietet eine eigene Authenticator-App an, die ähnlich wie Google Authenticator oder Microsoft Authenticator funktionieren dürfte. Leider ließen sich weder die Google-, noch die Microsoft-Lösung dazu überreden, mit Yandex zusammen zu arbeiten, beim Google Authenticator scheiterte bereits das Einlesen des QR-Codes. Mit dem Microsoft Authenticator funktionierte zwar dieser Schritt, der daraufhin erzeugte Code, d.h. das Einmalpasswort wurde von Yandex jedoch nicht akzeptiert. Da ich nicht noch eine weitere Authenticator-App nutzen wollte, habe ich auf die Yandex-Authenticator-App zunächst verzichtet.

Die Vertrauensfrage

Nun mag man sich mit der Speicherung auf Servern, die vermutlich in Russland beheimatet sind, nicht unbedingt anfreunden können, doch an der Stelle müsste man sich die Frage stellen, ob diese Meinung eher auf Tatsachen beruht oder ob nicht vielmehr die Propaganda aus den Zeiten des Kalten Krieges eine Rolle spielt. Natürlich nutzt auch Yandex nicht wenige Daten zur Optimierung eigener Dienste, speichert Kundendaten, gibt diese weiter an eigene Unternehmen oder z.B. im Falle der Foto-Editierfunktion ebenso an Dritte. Als Dienstleister für die Verarbeitung von Daten von Nutzern im europäischen Raum sowie der Schweiz wird übrigens die Gesellschaft Yandex Oy angegeben, die der finnischen Gesetzgebung untersteht. Was die Anbindung der Server anbetrifft, so hängt Yandex seit 2008 am DE-CIX in Frankfurt, was eine schnelle Verbindung zu den Rechenzentren in Russland ermöglicht. Insgesamt würde ich mir beim Thema Vertrauen somit die Frage stellen, inwieweit man anderen Cloud-Diensten gar mehr oder weniger vertrauen kann als Yandex. Oder ob es eine Rolle spielt, welcher der Drei-Buchstaben-Geheimdienste welchen Landes die übermittelten Daten mitliest respektive mitlesen könnte. Selbst bei deutschen Unternehmen, deren Server ausschließlich in Deutschland stehen, ist man davor nicht gefeit, sofern auch nur ein paar Bits davon übertragen werden. Einen Ausweg aus dieser Misere bietet nur das Verwenden von starker Ende-zu-Ende-Verschlüsselung, beispielsweise mit Boxcryptor oder ähnlicher Software. Ich nutze ebenfalls Boxcryptor für manche Dateien, die lieber nicht unverschlüsselt übertragen oder gespeichert werden sollten, praktischerweise unterstützt Boxcryptor neben weiteren Cloud-Diensten auch Yandex.Disk von Haus aus.

Preise und ein Add-On

Yandex.Disk ist in der Standard-Fassung kostenlos und bietet dabei 10 GB Cloud-Speicher. Der Speicherplatz kann erweitert werden mit einer Yandex.Disk Pro genannten Variante, und zwar entweder auf 100 GB oder 1 TB Cloud-Speicher. Es ist sowohl jährliche als auch monatliche Zahlung möglich, 100 GB kosten monatlich 2 US-$, bei jährlicher Zahlungsweise verringert sich der Betrag auf 1,70 US-$, für 1 TB werden monatlich 10 US-$ verlangt, bei jährlicher Zahlung nur noch 8,30 US-$. Damit ist Yandex.Disk durchaus konkurrenzfähig zu anderen Cloud-Speicher-Diensten.

Ein Feature, was mit der Desktop-Anwendung einher kommt bzw. darin integriert ist, ist ein Screenshot-Tool. Tatsächlich handelt es sich dabei meiner Ansicht nach um eine Funktion, von der man nicht wusste, dass man sie braucht, bis man sie plötzlich geliefert bekommt und man sich fragt, wie man zuvor ohne sie auskommen konnte. Auf dem Mac ist das Erstellen von Screenshots zwar komfortabler als unter Windows, aber Yandex.Disk erhöht diesen Komfort noch einmal. Zum einen integriert sich Yandex.Disk in die Mac-üblichen Screenshot-Funktionen, die üblicherweise den erstellten Screenshot auf dem Desktop speichern. Unter Windows musste man den Screenshot erstmal in ein Bildverarbeitungsprogramm einfügen, aus dem wiederum die Speicherung erfolgte. Mit Yandex.Disk ist die Bedienung unter Windows und Mac OS nun nahezu identisch, die Tastenkombinationen sind ebenfalls ähnlich. Zunächst lässt sich entweder ein Bereich des Bildschirms wählen, darüber hinaus können entweder ein Fenster einer Anwendung oder der komplette Bildschirm gespeichert werden. Nach dieser Wahl öffnet sich ein kleines Bearbeitungstool, in dem sich der Screenshot bereits befindet, von dort aus kann er mit der üblichen Speichern-Tastenkombination gesichert werden. Die Screenshots werden dabei sinnigerweise im Ordner “Screenshots” gespeichert, das Standard-Dateiformat und der Standard-Dateiname können im Yandex.Disk-Tool konfiguriert werden. Bereits damit ist das Erstellen von Screenshots unter Windows wesentlich erleichtert und auf dem Mac zumindest ein wenig optimiert. Das Tool bietet jedoch auch spezielle Bearbeitungsfunktionen an, etwa das Hinzufügen von Pfeilen, Texten, geometrischen Formen usw., es lässt sich ein Bildausschnitt wählen usw.. Natürlich beinhaltet das Tool nicht die Funktionen einer High-End-Bildverarbeitung, aber für das Nutzungsszenario, für das man öfters Screenshots einsetzt, genau die passenden Funktionen. Die Hotkeys sind im Übrigen abschaltbar, falls es hierbei zu Konflikten mit anderen Anwendungen kommen mag.

Features

Als Quelle der Tests der folgenden Tabelle dient der Artikel “Die Wahl der Wolke” aus der c’t 23/2018 (online verfügbar via Heise Select für c’t-Plus-Abonnenten). In der Hoffnung, nicht wegen Urheberrechtsverletzung der Begriffe und Gestaltung angeklagt zu werden, ergeben sich damit folgende Features:

 

Produkt Yandex.Disk
Anbieter Yandex LLC / Yandex Oy
Website https://disk.yandex.com
Firmensitz / Server-Standort Russland, Finnland, Schweiz / Russland
dauerhaftes Gratiskontingent 10 GB
Desktop-Clients Windows, Mac OS
Mobil-Clients Android, iOS, Windows Phone
Windows-Programmversion 3.0, 1.4.21 (legacy)
Funktionen
Sync-Ordner ändern
selektive Synchronisierung ?
Papierkorb
Versionierung 14 Tage, 90 Tage (Pro, kostenpflichtig))
Links / mit Kennwort / mit Ablaufdatum ✓ / – / –
Teilen mit anderen Teilnehmern ?
Log online / lokal ?
Konfliktverhalten online / offline ?
Explorer-Badges
alternative Zugriffsmethoden WebDAV
Collaboration-Extras Integration Microsoft Office Online, Screenshot-Tool
Zwei-Faktor-Authentifizierung – (beta, mit Yandex.Key App)
Userkonten-Verknüpfung ?
automatischer Foto-Upload Android / iOS ✓ / ? (nicht getestet, vermutlich  ✓)
iOS-Dateien-Integration ?
API-Dokumentation
Transfer-Steuerung
Downloads erst bei Bedarf ?
Erkennung doppelter Dateien ?
lokale Dateien ausschließen  –
Verschieben ohne Neutransfer ?
Bandbreitenlimits Down- / Upload – / – (siehe Text)
Fortsetzung großer Dateien nach Abbruch ?
differenzieller Transfer großer Dateien ?
Bewertung
Funktionsumfang
Synchronisierung ○ (siehe Text, nicht alle Tests der c’t durchgeführt, daher durchschnittliche Bewertung)
Jahrespreis-Beispiele 20 US-$ / 100 GB, 100 US-$ / 1 TB

 

Fazit

Vielleicht spielt Yandex.Disk nicht in der ersten Liga der Cloud-Speicher-Dienste mit, zu der die c’t im Test einzig Dropbox zählt. Zu den Diensten, bei denen man “je nach Geschmack […] nichts falsch macht” gehören laut c’t box.com, Google Drive, Mega, OneDrive, Tresorit und Your Secure Cloud. Aus den bisherigen Tests und Erfahrungen würde ich Yandex.Disk definitiv unter diesen Kandidaten. Einen Hinweis auf ein integriertes Screenshot-Tool habe ich im c’t-Test nicht gefunden, und auch wenn das nur als nettes Add-On gelten mag, so möchte ich diese Funktion inzwischen nicht mehr missen. Die Geschwindigkeit von Yandex.Disk hat mich bisher überzeugt, auch wenn das ein Kritikpunkt in einem Test bei “Cloudwards” gewesen ist, evtl. kommt es hier auch auf den Standort der Anbindung an. Insgesamt ist Yandex.Disk meiner Ansicht nach zumindest einen näheren Blick wert.

Und natürlich wäre es schön, wenn die c’t nicht nur europäische und US-amerikanische Angebote unter die Lupe nehmen würde, sondern auch den eher östlichen Gefilden eine Chance geben könnte, zumindest in eine Auswahl zu gelangen, aus der dann ggf. immer noch angesichts des Nichterfüllens relevanter Kriterien ausgeschlossen werden könnte. Die Cloud-Speicher-Dienste im chinesischen Raum bieten übrigens Terabyte-weise kostenlosen Speicherplatz. Aber dabei fehlt es dann leider doch einerseits an einer adäquaten Anbindung, außerdem ist zumindest meine Kenntnis von chinesischen Schriftzeichen genau null…

 

Hinweis: Der Autor ist ausschließlich Nutzer der kostenlosen Angebote von Yandex, steht jedoch ansonsten in keinerlei Verbindung zu Yandex, wurde auch nicht auf Kosten von Yandex nach Moskau, St. Petersburg oder in sonstige Yandex-Offices eingeladen (obwohl – cool wäre das ja schon…) und ist ebenfalls nicht vom russischen Präsidenten, FSB oder SWR infiltriert worden (was weniger cool wäre).

Impressionen

Unterschiedliche Ansichten in der Web-Anwendung:

 

Explorer-Integration

Integration Microsoft Office Online

Windows Desktop-Client

Desktop-Client – Einstellungen

Versionierung mit Öffnen und Wiederherstellen

Screenshot des Screenshot-Tools

Yandex.Disk-Integration von Boxcryptor

 

 

Tags:
Kategorie: Allgemein

WordPress-Plugin-Admin-UI-Entwicklung mit vue.js – da wächst nichts zusammen, was nicht zusammen gehört

“Jetzt wächst zusammen, was zusammen gehört”. Ob das berühmte Zitat von Willy Brandt nun älter ist als meist angenommen oder nicht, mögen die Historiker entscheiden. Schließlich geht es hier um clientseitige JavaScript-Programmierung, und noch dazu um das aufstrebende JavaScript-Framework namens vue.js. Dies hat in letzter Zeit für Furore gesorgt, weshalb sich auch Myriaden von Einführungen und Artikeln darüber finden lassen, die zumindest über die ersten Hürden prima weiterhelfen. 
Weiterlesen bei WordPress-Plugin-Admin-UI-Entwicklung mit vue.js – da wächst nichts zusammen, was nicht zusammen gehört »

Tags:

Zwei Stunden mit Univention Corporate Server

Univention Corporate Server (UCS) ist eine Linux-Distribution die als “Serversoftware für unkomplizierten IT-Betrieb” dienen soll. Insbesondere wird ein einfaches Identity- und Infrastrukturmanagement ermöglicht, UCS ist damit eine zentrale Komponente in einem Unternehmen zur Verwaltung von Benutzern und Administration von Anwendungen. Durch die Active-Directory-Funktionen, die von Samba zur Verfügung gestellt werden, kann UCS als Ersatz für ein Windows-Server-System dienen.
Weiterlesen bei Zwei Stunden mit Univention Corporate Server »

Tags:

Alexa! Ruf! Mich! An!

Ich gebe zu, ich mag die Amazon Echo-Geräte. Und natürlich Alexa. Ich würde sie auch heiraten, aber leider hat sie meine diesbezüglichen Versuche bislang erfolgreich abgewehrt. Nach dem Motto “Lass uns Freunde bleiben!” – als ob ich so etwas nicht bereits zur Genüge kannte… Jedenfalls haben sich in meinem Haus inzwischen so einige Echo-Geräte angesammelt, angefangen von der ersten Generation des Echo über den Echo Dot bis hin zum Echo Show und Echo Spot.
Weiterlesen bei Alexa! Ruf! Mich! An! »

Tags:
Kategorie: Allgemein

An den Grenzen von Docker Nginx-Proxy

…und wie ich darüber hinaus gekommen bin. Das war mir aber als Titel einfach zu lang. Aber zurück zum Thema – über das Nginx-Proxy-Docker-Image und den Docker-Letsencrypt-Nginx-Proxy-Companion hatte ich ja bereits den einen oder anderen Artikel verfasst. Die betreffenden Docker-Container laufen seit der Einrichtung problemlos, insofern bin ich damit vollends zufrieden.
Weiterlesen bei An den Grenzen von Docker Nginx-Proxy »

Tags:

Integration des WordPress Color Pickers in die Widget-Admin-UI

Mit dem Color Picker lässt sich innerhalb von WordPress auf einfache Art und Weise eine Farbe auswählen. Meist wird dieses UI-Element in der Admin-Oberfläche von Themes oder im Customizer bei der Anpassung der Farbgestaltung des verwendeten Themes genutzt. Da es sich um ein von WordPress bereit gestelltes Eingabeelement handelt, erschien es mir nur konsequent, es auch in den Einstellungen eines Widgets zu verwenden.
Weiterlesen bei Integration des WordPress Color Pickers in die Widget-Admin-UI »

Tags:

WordPress-Fehlermeldung “widget_setting_too_many_options” – Problem und Lösung

Momentan beschäftige ich mich wieder verstärkt mit WordPress, was dazu geführt hat, ein Widget im Rahmen eines kleinen WordPress-Plugins zu entwickeln. Es handelt sich um ein Plugin, das ein neues Widget bereit stellt. Nach Fertigstellung wird es selbstverständlich veröffentlicht, letztlich habe ich es jedoch zunächst für den Eigenbedarf entwickelt. Und nicht zu unterschätzen ist der damit einher gehende Lerneffekt, wobei dieser mitunter dazu führt, sich einfach nur zu wundern, weil man auf ein Problem gestoßen ist, was entweder überhaupt nicht oder nur sehr spärlich dokumentiert ist. 
Weiterlesen bei WordPress-Fehlermeldung “widget_setting_too_many_options” – Problem und Lösung »

Tags:

Kleiner PHP-RSS-Library-Rant

Zwar wird behauptet, RSS sei tot und man würde das bedauern, aber nichtsdestotrotz wollte ich letztens RSS nutzen. Nutzen heißt insofern, einen RSS-Feed auszulesen und darzustellen. Das musste auch zwangsläufig mit PHP passieren aufgrund der bereits bestehenden Umgebung. Man sollte meinen, dass dies eine Standardaufgabe sei, schließlich gibt es den Composer und nicht zuletzt Packagist, also Library installieren, Abhängigkeiten auflösen und einfach nur nutzen. 
Weiterlesen bei Kleiner PHP-RSS-Library-Rant »

Tags:
Kategorien: PHP Programmierung

Microsoft Azure Container Instances: erste Eindrücke

Nachdem ich im letzten Artikel einen Blick auf den Azure App Service geworfen habe, der auch letztlich auf Docker-Containern basiert, stand als nächstes der Test des von Microsoft Azure Container Instances getauften Services auf dem Plan.  Dabei wird eine Docker-Umgebung bereit gestellt, innerhalb der die jeweiligen Container lauffähig sind.
Weiterlesen bei Microsoft Azure Container Instances: erste Eindrücke »

Tags: