[FFA] Mapping von Freifunk-Knoten auf Docker?

[Markus Rudy]

Hi Severin, hi Steini,

docker-compose ist tatsächlich noch ein guter Mittelweg, mit dem man 
deklarative Orchestrierung auf einem Host ohne viel overhead machen kann.

Eine Sache, die ich über Container gelernt habe, sowohl im 
professionellen als auch im privaten Bereich: man kommt in der Regel 
nicht darum herum, sich mit den Anwendungen im Container und ihrer 
Konfiguration zu beschäftigen. Nur die allerwenigsten images kommen als 
one-size-fits-all, und ein falsch konfigurierter docker container ist 
auch nur marginal weniger problematisch als eine falsch konfigurierte 
Anwendung auf dem host.

Die Alleinstellungsmerkmale von einem containerisierten System würde ich 
eher, wie Severin, in den Isolationsmechanismen sehen.

+ Das rootfs-packaging erübrigt die Integration in das Hostsystem 
(shared libraries, system daemons, ...)
- Wenn nicht statisch kompiliert wird, oder die images ohne die nötige 
Sorgfalt gebaut werden, tendieren docker images zur Ansammlung von Ballast.
+ Container können separat (unabhängig vom Betriebssystem) gepatcht werden.
- Man muss seinen image upstream beobachten (und hoffen, dass der 
patches rausbringt).
+ Netzwerkisolation macht eine sichere Konfiguration einfacher und die 
Abhängigkeiten zwischen Komponenten leichter verständlich.
- Netzwerkisolation bestärkt die Annahme, interner traffic wäre 
vertrauenswürdig, und vereinfacht damit laterale Bewegung bei einem Angriff.

Ein sicheres und stabiles System aus Containern zusammenzustellen ist 
meines Erachtens nicht wesentlich einfacher oder schwieriger, als das 
aus Hostkomponenten zu bauen. Ich glaube, Container glänzen am ehesten 
in sehr kleinen Prototypen, weil schnell aufgesetzt und wieder 
verworfen, und in Systemen, die stark von Automatisierung profitieren 
oder die Komponenten mit sehr unterschiedlichen Ansprüchen an die 
Infrastruktur beinhalten (z.B. der gruselige legacy-Monolith, der auf 
ein RHEL5 userland angewiesen ist).

Grüße, Markus

On 6/23/20 10:56 PM, swuensch wrote:
> Hallo Steini,
> 
> ich verwende im Arbeitsumfeld docker um ganze Webseiten mit mehreren 
> Services zu Hosten. Wir verwenden dazu docker-comopse.yml files.
> Da konfigurieren wir alles nötige über Umgebungsvariablen. Volumes 
> werden zum teil direkt eingebunden damit sie persistent sind wenn eine 
> neuerer version gepulled wird.
> Das funktioniert sehr gut, wir haben jedoch auch nur minimale 
> configurations unterschiede zwischen den einzelnen Servern.
> 
> Vorteil ist halt das man echt unabhängig ist von was auf den servern 
> läuft so lange es ein linux ist und docker installiert hat und gerade 
> mit mehreren containern sehr ressourcen arm ist.
> Desweiteren dient das ja auch als Schutz so das etwa zugang zu 
> Datenbanken Container etwa nur aus anderen docker containern auf dem 
> selben system möglich ist (docker bridge networks 
> <https://docs.docker.com/network/bridge/>).
> 
> Der vorteil ist ja gerade wenn man nicht so ahnung hat das man explizit 
> in docker mitteilen muss welche ports offen sind. Was wir nicht 
> verwenden aber je nach einsatzfeld ggf sinnvoll sein kann ist
> docker auch no resource limits zu geben: 
> https://docs.docker.com/compose/compose-file/#resources
> 
> Grüße Severin
> 
> On Sat, 20 Jun 2020 at 11:07, Steini <freifunk at total-connection.net 
> <mailto:freifunk at total-connection.net>> wrote:
> 
>     Hallo Markus,
> 
>     vielen Dank für deine Antwort, das is mal nen Einblick von jemandem der
>     Docker privat nutzt.
>     Bei mir schwirrt nicht so ganz die Frage rum "Orchestrierung Ja/Nein",
>     eher plag ich mich mit der Grundsatzfrage "Docker Ja/Nein".
> 
>     Um die 4-5 Docker-Images für den Mapping-Service zu betreiben würde ich
>     mir jetzt auch kein Kubernets anlachen, aber die Frage is bei mir eher:
>     Soll oder will ich das überhaupt mit Docker-Images machen oder nicht
>     lieber eine Art "Mapping-VM" in der die Dienste Hopglas, Hopglas-Server,
>     Prometheus und Grafana nebeneinander laufen oder soll ich den
>     Mapping-Dienst aus vier nebeneinander laufenden Docker-Images laufen
>     lassen?
> 
>     Ich hab bei den Docker-Images mangels Erfahrung etwas die Sorge, dass
>     ich da was Wichtiges übersehe: Mach hier nen Backup von $x, Pass auf,
>     dass das hier nicht vollläuft, achte drauf dass bei $y die
>     default-config noch geändert wird weil's sonst unsicher ist usw.
>     Aus meinem Blickwinkel raus, is für mich das Betreiben von mehreren
>     Docker-Images intransparenter, als wenn ich jeden Dienst nacheinander
>     hochziehe und mich dabei eingehend mit beschäftigen muss wie man den
>     Dienst sicher konfiguriert, was man backupen muss usw.
> 
>     Des grad bissl so meine "Konflikt" wo ich am Überlegen bin, was ich
>     sinnvollerweise machen soll.
>     Aber gerne her mit Euren Erfahrungen, mit Euren Tips, mit Euren
>     Meinungen.
> 
>     Ciao
> 
>     Steini
> 
>     Am 17.06.20 um 20:07 schrieb Markus Rudy:
>      > Hi Steini,
>      >
>      > ich manage privat ein Kleingehege von Docker images, um meinen
>      > Mailserver zu betreiben, bestehend aus 3 images für
>     Kernkomponenten, 1
>      > image mit Spezifika für mich und 2 Infrastrukturkomponenten. Die
>      > Konfiguration bewegt sich im 10kB-Bereich und der Funktionsumfang
>     deckt
>      > process supervision und health checks ab, und läuft auf runc mit
>     einem
>      > simplen one-host network plugin. Dieses deployment ist an meiner
>      > persönlichen Schmerzgrenze, was die Überschaubarkeit angeht.
>      >
>      > Der einzige Grund, warum ich *keinen* Container Orchestrator benutze
>      > ist, dass dessen Fußabdruck den meiner Anwendungen um ein vielfaches
>      > übersteigen würde. k3s zum Beispiel, eine "lightweight"
>      > Kubernetes-Variante "für die edge", belegt mal locker 500MB RAM.
>     Hätte
>      > ich allerdings mehr container zu managen, wäre Kubernetes die einzige
>      > für mich in Frage kommende Lösung. In einem kleinen,
>     möglicherweise nur
>      > einen Rechner umfassenden Setup hat man nachdem man Container
>     einführt
>      > zwei Probleme, wo vorher nur eins war.
>      >
>      > Auf der anderen Seite hat Kubernetes viele Vorteile, angefangen mit
>      > eingebauter Funktionalität wie health checks oder Replikation über
>      > Automatisierung von updates bis zu deklarativem
>      > Konfigurationsmanagement. Vieles davon macht nur für power user
>     wirklich
>      > Sinn, zugegeben, aber wenn man schon mit einem mittelgroßen Projekt
>      > anfängt und das dann im Zweifel noch wachsen soll, ist das meines
>      > Erachtens eine Überlegung wert.
>      >
>      > Ich bin auch immer noch an dem containerisierten FF-Projekt
>      > interessiert, aber die Lage der Welt macht das gerade auch nicht
>      > einfacher -.-
>      >
>      > Grüße, Markus
>      >
>      > On 6/1/20 12:10 PM, Steini wrote:
>      >> Hallo zusammen,
>      >>
>      >> weil ja kürzlich im Chat die Frage kam, wie machen andere Communitys
>      >> eigentlich immer diese schicken Karten: Da hat sich so scheins ein
>      >> defacto-Standard um Hopglass etabliert.
>      >> Hier die Projekt-URL: https://github.com/hopglass/hopglass
>      >>
>      >> Ich hab dann gedacht "Ah, easy!" und dann mal geschaut wie das
>     Ganze so
>      >> zusammenspielt und das is schon nen Brocken an Software inkl.
>      >> Dependancy-hell: Prometheus, Grafana, Hopglass und Hopglass-Server.
>      >> So, da gibt's für's Allermeiste auch so schicke
>     Docker-Container, aber
>      >> ich hab da bissle die Befürchtungen, da allein für das Thema
>     Mapping nen
>      >> ganzen Zoo an Docker-Images laufen lassen und mir das unbehagt,
>     Software
>      >> in so großen Monolithen wie Container zu betreiben, da für mich
>     dadurch
>      >> die Übersicht verlorengeht in welcher Version welcher Container
>     läuft,
>      >> welche Konfigurationsoptionen gesetzt sind, bekomm ich
>     rechtzetig mit
>      >> Ressourcen knapp werden oder welche Daten man sinnvollerweise
>     backuppt...
>      >> Also ich muss dazu sagen, dass ich Docker-Anfänger bin und ich
>     deshalb
>      >> noch nicht so ganz die Sicherheit um Umgang mit der Technologie
>     habe.
>      >> Ich scheue mich noch Infrastruktur, also in unserem Fall
>     Gateways und
>      >> Mappingserver (okay Mapping kann man jetzt auch aus der
>     Infrastruktur
>      >> rausrechnen, das is nicht essentiell) als Container laufen zu
>     lassen.
>      >>
>      >> Wie seht'n Ihr das: Kann man die Dockerisierung von
>     Infrastruktur Eurer
>      >> Erfahrung nach machen? Macht Ihr das schon z.B. im
>     Arbeitskontext? Würde
>      >> mich Eure Meinung zu interessieren.
>      >>
>      >> Ciao
>      >>
>      >> Steini
>      >> _______________________________________________
>      >> freifunk-augsburg mailing list
>      >> freifunk-augsburg at lists.subsignal.org
>     <mailto:freifunk-augsburg at lists.subsignal.org>
>      >> https://lists.subsignal.org/mailman/listinfo/freifunk-augsburg
>      >>
>      > _______________________________________________
>      > freifunk-augsburg mailing list
>      > freifunk-augsburg at lists.subsignal.org
>     <mailto:freifunk-augsburg at lists.subsignal.org>
>      > https://lists.subsignal.org/mailman/listinfo/freifunk-augsburg
>     _______________________________________________
>     freifunk-augsburg mailing list
>     freifunk-augsburg at lists.subsignal.org
>     <mailto:freifunk-augsburg at lists.subsignal.org>
>     https://lists.subsignal.org/mailman/listinfo/freifunk-augsburg
> 
> 
> _______________________________________________
> freifunk-augsburg mailing list
> freifunk-augsburg at lists.subsignal.org
> https://lists.subsignal.org/mailman/listinfo/freifunk-augsburg
>