a. docker spannt eines (oder mehrere) interne Netzwerke auf. Gibt das mit VLAN Probleme?
b. Man kommt nicht so einfach von aussen an den container ran
c. evtl. kommt man vom container nicht so einfach auf Dienste des Servers (LDAP).
Darüber hatte ich mich auch schon gewundert. Und wenn ich mich richtig erinnere, kann man auch das mit portainer.io einstellen (ohne Gewähr). Von daher lohnt sich evtl ein Blick darauf…
(Ich hatte das damals aber alles auf default gelassen.)
Schönen Gruß,
Michael
Hier noch ein Nachtrag, wie das z.B. mit moodle läuft:
Habe ich mich auch gefragt und kann es nicht beantworten. Wie läuft der Autostart denn ohne portainer? Vor allem: wie kann man gewährleisten, dass man die „latest Version“ der gestoppten Container erwischt? Das wäre was für’s Video-Special, oder?
ich probiere hier gerade eine nextcloud mit angedocktem collabora/code und nach einem neustart des servers ist collabora wieder da.
das bewirkt wohl der schalter --restart always, der in der anleitung bei nextcloud schon drin war.
was mich noch interessiert ist, wie ich da andere fonts reinkriege. aber vielleicht finde ich da ja was passendes bei franks videos.
vg wolfgang
Auch hier neige ich fürs erste dem KISS Ansatz zu: Soweit ich das sehe habe ich keine Probleme, wenn der Docker Host in dem Netzwerk-Segment ist, in dem alle seine Containerdienste sein sollen, dann ist das völlig transparent, weil alle Container nach außen letztlich mit den Einstellungen des Hosts kommunizieren.
Wenn ich jetzt einen Container in einem anderen Segment haben will, nehme ich halt einen weiteren (virtuellen) Docker-Host.
Oder ich setze meinen Docker Host mit einer weiteren IP und Schnittstelle (Vlan oder nicht ist dabei eigentlich egal) zusätzlich in das andere Segment und tackere die Ports der Container auf die entsprechende IP Adresse fest.
Zu a) Das ist keine Bridge, eine Bridge würde die Container ja genau nach außen mit einer IP der umliegenden Infrastruktur versorgen. Ich habe es nicht nachgelesen, aber nach meinen Experimenten mit Docker ist das docker0 Interface ein Host-Only, das über den Docker Daemon für neue Container IP-Adressen verteilt. Dabei führt Docker auch Buch, somit kann man auf einem Host auch Container einfach mit --link verbinden.
docker run -name mydbserver -d mysql
docker run --link mydbserver:mysql debian bash
Und schon kann ich von dem debian-Container auf die DB zugreifen, alle Einstellungen werden dabei von Docker vorgenommen. Außerdem findet wohl noch ein Natting ins umgebende Netz statt (siehe zu c)).
Zu b) Daraus schließe ich auch: ich will auf gar keinen Fall dieses Netzwerk direkt nach außen führen, außer ich weiß sehr genau was ich tue oder habe Containerisierte Dienste auf mehrere Hosts verteilt - die ich trotzdem per Docker verlinken will/muss (und nicht „ganz normal“ über meine Segmente und Firewalls.
Es ist also nicht beabsichtigt, „von aussen an den container“ zu kommen, und das ist auch nicht nötig, denn ein Container ist keine VM, wenn der läuft macht der den Dienst, den er machen soll, ich kann da ja nicht z.B. per SSH noch drauf oder so. Ich muss die Container letztlich immer vom Docker Host steuern, und wenn ich Dienste anbierten will, kann ich die dafür nötigen Ports über die IP-Adressen und Schnittstellen des Hosts nach außen „exposen“.
Zu c) Das ist kein Problem, denn die Container „erben“ wesentliche Netzwerkeinestellungen und Verbindungen des Hosts, kommen also ins umgebende Netz und damit auch auf den LADP.
Nachdem ich jetzt nachgedacht habe, würde ich eher mehrere dockerhosts laufen lassen (z.B. einen mit dem mailserver in grün, einen mit nextcloud, webserver, moodle in orange), sonst muss ich meine Trennung in DMZ und „intern“ auf dem dockerhost sicherstellen.
Man kann sicher (wenn der als VM läuft) die entsprechenden IPs und ethXs (und die damit verbundenen docker-netzwerke) klar trennen, aber das vermieden wir bisher auch auf VM-Ebene soviel ich weiß.
Da bin ich vielleicht zu sehr in meinem eigenen Kopf gefangen, ich stelle mir eine Bridge halt immer eher so vor, dass die nach außen gebridget ist, man kann das aber sicher auch so verstehen, dass eben alle Container da miteinander gebridget sind. Namen sind Schall und Rauch, du hast jedenfalls recht, dass die Container nach außen erst mal nict erreichbar sind - aber eben untereinander. (Anmerkung: Am längsten hat bei mir ja gedauert, irgendwie zu realisieren, dass Container eben keine VMs sind, und wenn ich irgendwelche Sachen probiere, ecke ich da auch immer wieder mal an, wenn ich dann denke „wie soll denn ein python3 Container funktionieren ohne Shell?“)
Ich auch, wollte das nur der Vollständigkeit halber mit erwähnen - vor dem Hintergrund der Intel Panne fällt es uns vielleicht nicht mehr so leicht, einfach nochmal 3 Maschinen zu starten, die Patches gehen wohl sehr massiv auf die Performance (Pessimisten sprechen von 30%)
Ob der Netzbrief das erlaubt, wäre spannend, ich denke eigentlich schon, weil die Netze technisch auch mit zwei Schnittstellen getrennt sind, solange da kein Routing stattfindet. Der L3 Switch macht letztlich ja auch nix anderes. Du kommst erst ins andere Segment, wenn du den Host geowned hast (oder den Switch). Qualitativ sicherlich nicht vergleichbar, weil der Dockerhost natürlich eine 1000fach größere Angriffsfläche hat, also lieber zwei Hosts.
Wobei meine Konzeption derzeit eigentlich den Docker Host in Lila sieht (das ist das Router-Netz der Fritzbox) also je nach Betrachtungsweise in einer DMZ oder (für mich) in ROT. Weil fast alles, was ich containerisieren will ja letztlich von außen erreichbar sein soll.
vergleichbar, weil der Dockerhost natürlich eine 1000fach größere
Angriffsfläche hat, also lieber zwei Hosts.
… oh bitte nicht …
Wobei meine Konzeption derzeit eigentlich den Docker Host in Lila sieht
(das ist das Router-Netz der Fritzbox) also je nach Betrachtungsweise in
einer DMZ oder (für mich) in ROT. Weil fast alles, was ich
containerisieren will ja letztlich von außen erreichbar sein soll.
das ist eine gute Idee.
Da stehen alle meine Netzwerkdienste: Nextcloud, moodle, portfolio, mrbs
… da will ich einen Docker haben.
Und nicht einen in Grün und einen in Blau und einen in Rot …
Bitte bedenkt, dass es manche schon als sarkastisch ansehen, wenn ihr
von KISS (Keep It Simple, Stupid!) redet und es kommt am anderen Ende nur
… docker … reverseproxy…bridge…container…VLAN …
und weiteres Kauderwelsch an.
Ich kann euch auch nur folgen, wenn ich die ganzen Treads schön langsam
einen nach dem anderen lese…
… das soll heißen: wir werden etliche Leute am Ende haben, die das
einfach nur bedienen können: aber nicht verstehen: und das müssen wir an
der Hotline Supporten.
Keep it Simple: ein Dockerhost: Bitte.
Ein Mailserver sollte meiner Meinung nach sowiso nicht in grün
stehen…zumindest nicht, wenn er von außen erreichbar sein soll.
Hi,
klar, Holger, das geht sicher fast allen so (mir auch). Es ist „digitales Neuland für die meisten von uns“ (um die Kanzlerin auch gleich mit zu zitieren ).
Ich freue mich aber seit den letzten paar Threads zu Docker und den Tutorials von Frank sehr darüber, wie schnell man hier zu brauchbaren Ergebnisse kommt und wie effektiv dieses Forum hier wieder einmal zusammen denkt/tüftelt/ausprobiert/alles voran treibt! Das ist schon stark!
Ich glaube auch, dass wir zukünftig nicht um docker herum kommen werden. Da ist es sehr gut, wenn möglichst viele hier die Basics lernen und verstehen.
Die Idee von Frank einen oder mehrere fertige Container fix und fertig und genau passend für den lml-Server parat zu halten finde ich jedenfalls prima! Das dürfte vielen die Installationsarbeit enorm verkürzen oder sogar ganz abnehmen. Zudem sorgt es für einheitlichere Systeme.
Unter’m Strich also nochmal danke für die gute Zusammenarbeit!
Michael
).