[FFA] Mapping von Freifunk-Knoten auf Docker?

[swuensch]

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> 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
> >> 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
> _______________________________________________
> freifunk-augsburg mailing list
> freifunk-augsburg at lists.subsignal.org
> https://lists.subsignal.org/mailman/listinfo/freifunk-augsburg
>
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.subsignal.org/pipermail/freifunk-augsburg/attachments/20200623/f31a0995/attachment.htm>