Docker-Compose Netzwerkeinstellungen des Hosts durchreichen

freak1051

Ensign
Registriert
Dez. 2012
Beiträge
198
Hallo Zusammen,

ich hab letzte vergangene Woche erstmals etwas mit Docker zu tun gehabt, deshalb seien etwaige dumme fragen bitte verziehen :)

Zuerst zu meinem Setup:
Ich habe ein Raspberry Pi mit Folgenden Image: Docker Pirate. Darauf habe ich mittels Docker-Compose folgendes Image gezogen:
Siehe unter Docker Compose.
Mein Pi-Grundsystem hat per DHCP eine IP-Adresse bekommen. Mein Host hat somit eine Internetverbindung. Dies konnte ich auch verifizieren durch Update und ping 8.8.8.8.
Nun wollte ich in das mittels Docker Compose erstellte Wiki ein Youtube-Video einbinden. Dies hat nicht geklappt (hab mir darum aber erst mal kein Kopf gemacht). Danach wollte ich einen SMTP-Server eingeben, damit ich Benachrichtigungen emfpfange... Zeitüberschreitung. Hier kam die Vermutung auf, ob der Container evtl. kein Internet hat.


Leider konnte ich das nicht ganz überprüfen, da ich für ein Ping "keine berechtigung" im container habe (Über docker exec ...bash im Terminal ping in Container abgesetzt). Sudo geht auch nicht.

Nun habe ich etwas gegoogelt, und folgenden zusatz im Docker-Compose file hinzugefügt: network_mode: host . Hier habe ich mir versprochen, dass ich "internet in den Container durchleite".

Leider ist der Container mir dann nicht hochgefahren. Er hatte kein Zugriff auf die Datenbank. So wie ich es sehe, sind es auch 2 Container (Bitte korrigieren, wenn ich falsch liege). Zum einen habe ich den Container db und den container wiki. Wiki bezieht sich auf db. So verstehe ich das zumindest.

Hinsichtlich dessen, dass die ganze Aktion ein Pilotprojekt für unsere Abteilung werden soll, darf ich das ganze auch irgendwann ins Firmen-Netzwerk bringen. Hier muss ich, damit ich zumindest im Host Internet habe, auch noch Proxyaddresse und Anmeldung hinterlegen.
Das sollte dann natürlich auch in die Container weiter geleitet werden.

Könnt ihr mir nen Tip geben, wie ich das Ganze verwirklichen kann?

vielen Dank schon mal im Vorraus.

Grüße
Daniel
 
Warum denn Docker Pirate? Was spricht dagegen einfach Debian oder Ubuntu zu nehmen?
Bastel distributionen sind daheim cool, aber nicht im Einsatz bei Firmen.

Was erhoffst du dir davon, dem Container eine eigene IP in eurem Netz zu geben?
Die Container sollen in der regel in ihren eigenen subnets sein, und du leitest relevante Ports nach außen, wie hier gezeigt: https://docs.docker.com/compose/networking/

Wenn viele dienste darauf sollen: Reverse Proxy vor die Container - aber hier wird ein raspi zu schwach sein.

Wenn wenige dienste darauf sollen (wie bei dir jetzt das Wiki): Warum überhaupt im Container?

Und Warum überhaupt selbst hosten? Für 2,5€/Monat eine VM mieten ist auf dauer vermutlich auh stressfreier, schneller und skalierbarer
 
  • Gefällt mir
Reaktionen: kamanu
freak1051 schrieb:
Leider konnte ich das nicht ganz überprüfen, da ich für ein Ping "keine berechtigung" im container habe (Über docker exec ...bash im Terminal ping in Container abgesetzt). Sudo geht auch nicht.
Möglicherweise sind sowohl die ping als auch die sudo Pakete gar nicht im Container installiert.

Warum nimmst du überhaupt Docker ? Willst du wirklich eine DB im Container betreiben ? Ein Container hat seine Stärken bei stateless Applikationen. Eine DB ist meist das Gegenteil von stateless ;)

Das Frontend kann man ruhig als Docker laufen lassen, aber die DB ? Das Geschreie wird groß in der Firma, wenn dann mal der DB container weg ist samt allen Daten...
 
Zuletzt bearbeitet:
freak1051 schrieb:
Leider konnte ich das nicht ganz überprüfen, da ich für ein Ping "keine berechtigung" im container habe
Code:
❯ docker exec --help

Usage:  docker exec [OPTIONS] CONTAINER COMMAND [ARG...]

Run a command in a running container

Options:
  -d, --detach               Detached mode: run command in the background
      --detach-keys string   Override the key sequence for detaching a container
  -e, --env list             Set environment variables
  -i, --interactive          Keep STDIN open even if not attached
      --privileged           Give extended privileges to the command
  -t, --tty                  Allocate a pseudo-TTY
  -u, --user string          Username or UID (format: <name|uid>[:<group|gid>]) <-------
  -w, --workdir string       Working directory inside the container

Bevor du das aber produktiv nimmst, probier wenigstens ein paar Szenarien durch, wie ein komplettes Neuaufsetzen des Deployments. Einfach mal Container deployen und auf magische Weise "funktioniert einfach" ist nicht.

Was sagt die Firewall? Was sagen die Default Policies? Was sagt deine docker-compose.yml?
Groug schrieb:
Dann wird der ganze Spass auch gleich ggf. mit upgedatet.
Mach ich in nem Container mittels pull + up. Absolut keinen Grund heutzutage nichts in nem Container laufen zu lassen, zumal man sich viel zu gern mit den Dependencies auf dem Host verrennt und schnell nicht mehr updaten kann, ohne dass es irgendwas zerschießt.
Cokocool schrieb:
Willst du wirklich eine DB im Container betreiben ? Ein Container hat seine stärken bei stateless Applikationen.
Welchen Grund gibt es nicht?
Cokocool schrieb:
Das Geschreie wird groß in der Firma, wenn dann mal der DB container weg ist samt allen Daten...
Dafür nimmt man Volumes, das ist absolutes Basiswissen. Da ist nichts "mal weg". Den Ordner des Deployments backuppen inkl. der darin enthaltenen DB ist absolut kein Hexenwerk.

Man kann auch nen Hammer zum Umrühren der Suppe verwenden...
 
madmax2010 schrieb:
---Vollzitat entfernt---
Bitte Zitierhinweise beachten.
Grundsätzlich isses nachher mir wurst, wie die des machen :) Die bekommen von mir ein Backup, was sie einspielen, und dann is gut :)

Eigentlich sollen keine Dienste mehr drauf. Es ging mir hier nur drum Schnell das teil ans laufen zu bekommen. Ich habe versucht, alles einzeln zu installieren, bin aber leider, mangels Linux-Wissen daran gescheitert. Ich hab schon die DB nicht aufgesetzt bekommen.

In der Firma soll es irgendwann dann mehrere Wikis geben, von unterschiedlichen Abteilungen, die sich aber nicht mischen.

VM mieten wäre auch kein ding, allerdings wer zahlt es... okay 2,50 aber nachher komm ich nicht mal auf die Seite aus der Firma raus... und wenn es Öffentlich ist, hab ich das problem mit Sicherheit.. Man will ja nicht alles ins WWW legen.

Ich erhoff mir aus den IP´s nicht viel. ich brauch halt iwie im Container Internet :)

Groug schrieb:
Also wenn es nur um ein Wiki + DB geht würde ich es native auf dem PI aus den Repositorys installieren.
Dann wird der ganze Spass auch gleich ggf. mit upgedatet.
Wie schon oben gesagt, ich bin daran kläglich gescheitert :) Bin kein Linux-Experte. In der Wiki.js doku steht quasi nur "installier Postgre". WIE...?? kp.. also nächste "Anleitung" suchen, was nicht gescheit geklappt hat.


Cokocool schrieb:
Möglicherweise sind sowohl die ping als auch die sudo Pakete gar nicht im Container installiert.

Warum nimmst du überhaupt Docker ? Willst du wirklich eine DB im Container betreiben ? Ein Container hat seine Stärken bei stateless Applikationen. Eine DB ist meist das Gegenteil von stateless ;)

Das Frontend kann man ruhig als Docker laufen lassen, aber die DB ?

Wie auch schon oben beschrieben. Ich war zum einen mal froh, dass es geklappt hat. Ich selbst arbeite nicht in unserer IT. Und die lesen sich wahrscheinlich auch nicht ein...
Für mich war es die einfachste möglichkeit. Da fehlt mir einfach jemand, der mich an der Hand nimmt und sagt: jetzt machst des so.

Hab noch n anderes Wiki aufgesetzt zum vergleichen (Dokuwiki). ich hab glaub 3 Tage gebraucht, bis ich wenn ich die IP des Pi´s im Browser eingeb, dass er nicht die Apache (oder auch als versuch nginx) test-seite anzeigt, sondern tatsächlich das Wiki :)
 
Zuletzt bearbeitet von einem Moderator:
Aus meiner Sicht spricht erstmal nix gegen Docker auf einem Pi. Auch nicht mit App+DB+Reverseproxy.

Ob man im Firmennetz eine Indie-Distro haben will ist nochmal eine andere Frage.

Auf die "was machst du wenn xxx mal komplett weg ist" kann man nur sagen: Backup ist ja hoffentlich mit eingeplant. Mir persönlich sind mit Containern noch nie Daten abhanden gekommen.

Allerdings ist hier scheinbar gar kein Wissen vorhanden. Wenn man hier mal von einem Azubi ausgeht, sollte man sich mMn mal ne Woche Zeit nehmen und entsprechend in die Technologie eintauchen, damit man ungefähr weiß, was man tut.
 
Yuuri schrieb:
Dafür nimmt man Volumes, das ist absolutes Basiswissen. Da ist nichts "mal weg". Den Ordner des Deployments backuppen inkl. der darin enthaltenen DB ist absolut kein Hexenwerk.

Man kann auch nen Hammer zum Umrühren der Suppe verwenden...
Uh ein "Experte". Von Docker Volumes habe ich noch nie gehört /s

Der TE ist bereits jetzt überfordert und du kommst mit Docker Volumes. Dazu gibt es auch 10x bessere Wege als Docker Volumes für DBs...

Er braucht managed Services, damit er so wenig wie möglich technisch selber machen muss. Wer eine Datenbank in Docker empfiehlt, hat keinerlei Basiswissen. Das geht auf der Entwicklungsumgebung, aber das wars dann auch. Der TE arbeitet nicht einmal in der IT. Da kauft man am besten direkt einfach Confluence hostet ein und gut ist....

Jede halbwegs normale und moderne Firma nutzt managed DB services wie AWS RDS. Hier kümmert sich AWS um Backups/Snapshots, OS und DB-Patches, Read-Replikas, Multi-region-Replikation, ... du kannst da gerne mit deinem DB Container rumspielen...
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: madmax2010
Postgres installierst du beispielsweise so: https://www.digitalocean.com/community/tutorials/how-to-install-and-use-postgresql-on-ubuntu-18-04

oder du nimmst dir einen Postgres Container, legst ein persistent volume da rein und richtest dir die datenbank ein wie benötigt.


freak1051 schrieb:
Grundsätzlich isses nachher mir wurst, wie die des machen :) Die bekommen von mir ein Backup, was sie einspielen, und dann is gut :)
Meinst du damit ein Docker image oder wirklich ein statisches Backup?!

Das wäre OKish, wenn du garantieren kannst, dass das ursprungsbackup danachgelöscht wird.. Sonst wird nur bad practice vertieft.

Nach 2 Wochen ist das backup veraltet und nutzloch -> Wiki.js reproduzierbar deployen geht beispielsweise so: https://github.com/supertarto/ansible-wikijs


Aber warum machst du das eigentlich?
Wenn du was lernen willst: Nimm dir nicht alles auf einmal vor. Step bey Step.

Wenn es etwas ist was eine Firma nutzen soll, dann soll sie auch ein Budget von 2-3 PT und für den Betrieb bereitstellen. Sowas stellt man nicht hin und es läuft einfach für immer weiter. Das muss geupdated und gewarteet werden. Backups müssen laufen und auch hier gibts wartungsaufwand.


Entweder die interne IT tut das, oder man nimmt sich einen Dienstleister.
 
freak1051 schrieb:
In der Firma soll es irgendwann dann mehrere Wikis geben, von unterschiedlichen Abteilungen, die sich aber nicht mischen.


Wie auch schon oben beschrieben. Ich war zum einen mal froh, dass es geklappt hat. Ich selbst arbeite nicht in unserer IT. Und die lesen sich wahrscheinlich auch nicht ein...
Für mich war es die einfachste möglichkeit. Da fehlt mir einfach jemand, der mich an der Hand nimmt und sagt: jetzt machst des so.
Hier sollten alle Alarmglocken klingeln. Kauft euch Confluence hosted ein und gut ist. Ein nicht IT-ler soll für alle Abteilungen Wiki-Server in einer Firma bereit stellen. Was soll nur schief gehen ?

Wenn keiner das technische Knowhow hat, dann kaufe ich einen fertigen Wiki-Service ein. Dann kümmern sich andere um Backups, Verfügbarkeit, etc..
 
@Cokocool Ich habe ein paar Kunden die ähnliche Dinge versucht haben. Alles ging schief und auf einmal konnten firmen nicht mehr arbeiten weil ihr wiki | nextcloud | redmine | odoo .... nicht mehr erreichbar war und die Panik wurde groß.
Lieber auslagern und ordentlichen Betrieb gewährleisten, als frickeln

@freak1051 Das heißt nicht, das es nicht cool ist das du dich da rein arbeitest. Wir helfen gern, aber 1 Schritt nach dem anderen.
 
  • Gefällt mir
Reaktionen: Cokocool
Yuuri schrieb:
Code:
❯ docker exec --help

Usage:  docker exec [OPTIONS] CONTAINER COMMAND [ARG...]

Run a command in a running container

Options:
  -d, --detach               Detached mode: run command in the background
      --detach-keys string   Override the key sequence for detaching a container
  -e, --env list             Set environment variables
  -i, --interactive          Keep STDIN open even if not attached
      --privileged           Give extended privileges to the command
  -t, --tty                  Allocate a pseudo-TTY
  -u, --user string          Username or UID (format: <name|uid>[:<group|gid>]) <-------
  -w, --workdir string       Working directory inside the container
Die doku sagt mir was :) Aber was willst du mir damit sagen :)

ich hab mit docker ps die ID rausgefunden und dann damit über ienen ebfehel (daheim aufgeschrieben) in den Container geschaut. Also das Terminal war dann IM container.
Yuuri schrieb:
Bevor du das aber produktiv nimmst, probier wenigstens ein paar Szenarien durch, wie ein komplettes Neuaufsetzen des Deployments. Einfach mal Container deployen und auf magische Weise "funktioniert einfach" ist nicht.
Genau das ist der Plan.
Ich hab auch schon versucht (aber gescheitert) ein Volume einzuhängen, welches dann auch vom Host erreichbar ist. Darein hätte ich dann die Daily-Backups gepackt. Dann hab ich wenigstens die, auch wenn ich nen Container zerballer. Wie gesagt, wäre aber mal noch nen extra Beitrag geworden :)
Yuuri schrieb:
Was sagt die Firewall? Was sagen die Default Policies? Was sagt deine docker-compose.yml?
Was meinst du damit :) ^^


Kyze schrieb:
Aus meiner Sicht spricht erstmal nix gegen Docker auf einem Pi. Auch nicht mit App+DB+Reverseproxy.

Ob man im Firmennetz eine Indie-Distro haben will ist nochmal eine andere Frage.
Das ist mir ja dann "eigentlich" wurst, was die für nen Grundsystem fahren. Ich habs nur mal der einfachheithalber genommen, da ich wie eben gesagt noch nie was damit gemacht hab
Kyze schrieb:
Allerdings ist hier scheinbar gar kein Wissen vorhanden. Wenn man hier mal von einem Azubi ausgeht, sollte man sich mMn mal ne Woche Zeit nehmen und entsprechend in die Technologie eintauchen, damit man ungefähr weiß, was man tut.
Da hast du Recht.. Nein Azubi nicht... nicht mehr...(oh gott is des lange her) :)
Nur andere Abteilung. Ich bin in der Elektrokonstruktion als SPS-Programmierer tätig. Da mein Chef aber weiß, dass ich nen RPI (als Printserver am 3D-Drucker) zuhause hab, meinte er es sei ne super idee, Dass ich mir das (nebenher) mal anschau :)
 
freak1051 schrieb:
Da mein Chef aber weiß, dass ich nen RPI (als Printserver am 3D-Drucker) zuhause hab, meinte er es sei ne super idee, Dass ich mir das (nebenher) mal anschau :)
Du und dein Chef kriegen später auf den Sack, wenn das Wiki nach ein paar Jahren kaputt geht und alles weg ist. Die Idee ist einfach dumm. Das kann man zu Hause machen, aber nicht in einer Firma.

https://www.atlassian.com/de/software/confluence/pricing
 
@Cokocool @madmax2010

Sicherlich habt ich absolut recht. Nur leider haben wir, was das anbelangt, eine sehr "altomodische" IT.

Und selbst wenn.. Confluence kommt nicht in Frage. Warum, weil isso.

Es muss etwas sein, wo für uns einfach zu pflegen ist. WIR müssen uns eine Struktur überelgen, mit der WIR zurecht kommen. Das wird nichts, wenn es unsere IT macht. Das haben sie mit MS TEAMS versucht, und sind kläglich gescheitert.

Als beispiel: In unserer Mechanik ist die bisherige Wissensdatenbank eine PowerPoint-Datei mit 1.4 Gb.
in der Ekonst haben wir eine Ordnerstruktur, in der sich aber auch keiner mehr zurecht findet, und vorallem z.T. Anleitungen vorhanden sind von vor 25 Jahren auf Windows 98...

UND es darf kein geld kosten.
Das wir aber stunden verbringen um uns in unserm Wissens-Müll zurech zu finden, rechnet man nicht.. "Eh-Da-Kosten"
 
freak1051 schrieb:
@Cokocool @madmax2010

Sicherlich habt ich absolut recht. Nur leider haben wir, was das anbelangt, eine sehr "altomodische" IT.

Es muss etwas sein, wo für uns einfach zu pflegen ist.
Dann baut Druck zur IT auf. Die IT Abteilung ist dazu da euch z.B. eine Wiki-Lösung zu hosten. Diese könnt ihr dann ja selber inhaltlich administrieren, aber fürs Hosting muss sich die IT kümmern oder ihr kauft es eben Extern ein.

Weiterer Anstoß: Wenn ihr das auf eigene Faust macht, dann baut ihr Schatten-IT auf. https://de.wikipedia.org/wiki/Schatten-IT#:~:text=Der Begriff Schatten-IT beschreibt,des IT-Bereichs angesiedelt sind.

In vielen Firmen hagelt es direkt eine Abmahnung oder zu mindestens einen Anschiss, wenn du einfach nen Raspberry-Pi an der IT vorbei ins Firmennetz hängst...
 
Das mag gut sein. Aber wenn wir nichts gescheites vorlegen, wird nichts angestoßen.

Administriert wird alles durch die IT. Die sicherungen werden durch diese gemacht. Es geht nur akuell um eine Plattform, welche für uns am geschicktesten ist
Ergänzung ()

@Cokocool Haha, das haben wir theoretisch bereits. Wir arbeiten voll in VM´s. Für einen IT´ler ist es nicht immer leicht zu verstehen, das ich am Tag mehrere male mein Netzwerk ändere.. Und ein Lokales Admin-Passwort haben wir, allerdings das jedes mal eingeben...

Und zum Thema Hosten. Das wird so kommen.

Es it auch alls mit der IT abgeklärt. Ich hoste (und darf es auch) aktuell auf einem Pi. Dieser ist nur lokal ansprechbar und hängt in keinem Firmennetz. Wir in der Abteilung schauen uns das nun 4 Wochen an und jeder darf mal suchen und einen Eintrag machen.

WENN das innerhalb der Abteilung passt, dann setzte ich mich mit der IT zusammen, und hänge das teil (noch als RPI) ins Firmennetz.
Grund Hierfür: nun können LESEND auch andere Abteilungen sich alles mal anschauen, und sagen ob sie potentiell Interesse an einem/soeinem Wiki haben.

Ist das gelaufen können wir innerhalb der Abteilung unsere Daten schon mal stück vor stück auf den Pi laden.

Sobald die IT dann in der Firma Das wiki Hostet gebe ich denen mein backup, damit wir auf dem weiter machen können, was wir angefangen haben.

Was die IT mit den anderen Abteilungen macht, ist mir dann wurst. Es geht nur darum:

erstmal im kleinen vortellen. Dann kommt Faktor "was der Bauer nicht kennt" ins spiel. Also muss man erst die leute spielen lassen - Drum lokal auf pups hardware - Entweder es kommt an und wird genutzt, oder es wird eingestampt. Dennoch weiß unserer IT schon was geplant ist, und hat den Plan auch so abgesegnet.
 
Zuletzt bearbeitet:
Hast du wenigstens eine ordentliche SD-Karte im PI ? Die sterben auch ganz gerne mal...
 
  • Gefällt mir
Reaktionen: freak1051
Wirst lachen aus de Vergangenheit heraus hab ich nur den bootloader auf der sd karte und den rest auf ner usb-ssd. Hab mich da vor Jahren mal durch gekämpft weil ich auch angegangen bin, seither mach ich des immer so bei "wichtigen" sachen
 
Hab mal n kleines Deployment angehangen. Beachten müsstest du, dass du das Verzeichnis des Volumes vorher erstellst und die Rechte für den postgres User (regulär User ID 70) richtig setzt - das ist da ein bisschen zickig (ich hab allerdings auch User Namespaces aktiviert).
Bash:
$ mkdir ./devops/data/db--data
$ chown -R 70:70 ./devops/data/db--data
Ich hab es jetzt einfach mal in ein eigenes Subnetz gepackt, was du aber ggf. nicht brauchst. Schaden tut es jedenfalls nicht.

Nach obigen Befehlen, kannst du dann einfach mittels
Bash:
$ make
die Hilfe dafür aufrufen und mit dessen Targets die Container steuern.
  • make up startet die Container
  • make down stoppt sie
  • make reup startet sie neu
usw. Es wäre gut, wenn du dich da selbst einliest, was das alles genau bedeutet.

Die Datenbank liegt dann im Ordner ./devops/data/db--data. Heißt für ein Backup einfach den gesamten Projektordner ziehen und du bist fertig. Beim Wiederherstellen entsprechend die Daten wieder dort ablegen, aber darauf achten, dass beim Backup die Dateisystemrechte wiederhergestellt werden.

Nichtsdestotrotz musst du natürlich schaun, ob du immer noch keine Verbindung nach außen hast. Da kannst du einfach mal
Bash:
$ docker run alpine ping 8.8.8.8
ausführen. Dann siehst du, ob du ne Verbindung ins Internet bekommst. Ggf. müsstest du die Default Policy der Firewall ändern. Ubuntu blockt(e?) standardmäßig bspw. jeglichen routed Traffic, wodurch in den Containern ggf. keine Pakete ankommen. Da musst du aber bei deiner Distribution schauen, inwiefern man das ändern kann. Testweise sonst einfach deaktivieren und gegenprüfen ob es daran liegt.

edit: Achso, die .env.dist müsstest du nach .env kopieren und die Zugangsdaten anpassen.
 

Anhänge

Zurück
Oben