ubuntuusers.de

Hallo, ich möchte gerne ein Shellskript zur Konfiguration der Umgebung des Containers vor dem Containerstart per docker-compose auf dem Docker-Host ausführen, um ein benötigtes Verzeichnis zu mounten. Bisher konnte ich keine Möglichkeit finden die mir konsistent erscheint. Kann mir jemand raten?

Von was für einem Host reden wir? Eine 0815 Linux Kiste, oder was spezielles wie Kubernetes, CoreOS oder sonstwas? Wie wird der Container gestartet?

Standard, zumindest im Server Umfeld, ist das die entsprechenden Mountpoints durch ansible, puppet oder ähnliches am Host vorhanden sind und damit nicht Teil von der Containerspielerei sind. Der Ansatz von Docker ist ja das es möglichst Portabel sein soll, spezifische Host Anpassungen wären da kontraproduktiv (meiner Ansicht nach).

mfg Stefan

Hallo encbladexp, danke für deine schnelle Antwort. Es geht um einen dezidierten Server in der Schule mit Debian auf dem Docker läuft. Nachdem ich die Dockerbefehle zunächst in Shellskripten aufgerufen habe, bin ich auf docker-compose umgestiegen, um die Übersicht über jetzt 4 Dienste mit 14 Containern zu behalten. Die Container jeder Gruppe werden über docker-compose up -d gestartet.

Wenn ich z.B. das Verzeichnis mit den HTML-Dateien für einen startenden Webserver-Container benötige, welches auf einem anderen Server bereitgestellt wird, muss ich es vor dem Containerstart mounten. Dafür möchte ich tatsächlich keine Bastelei, sondern möglichst einen Aufruf wie preexec: in der docker-compose.yml. Bei Cron habe ich schon von außen mit exec-Aufrufen gewurstelt, aber mehr davon muss es nicht sein. Gemountet soll nur werden, wenn die Container laufen.

Von den von dir genannten Dingen habe ich bisher nicht gehört. Nach erster Sichtung erscheint mir das aber eher als oversized - oder liege ich damit daneben?

bbs-lehrer schrieb:

Wenn ich z.B. das Verzeichnis mit den HTML-Dateien für einen startenden Webserver-Container benötige, welches auf einem anderen Server bereitgestellt wird, muss ich es vor dem Containerstart mounten.

Das ist richtig, das ist dein Job als Systemadministrator. Die Idee von Docker Compose ist es ja, wie du schon gemerkt hast, Container gut zusammenarbeiten zu lassen. Die Aufgabe davon ist es aber nicht deinen Host entsprechend zu konfigurieren. Mir ist auch unklar was dagegen spricht das Remote Verzeichnis einfach permanent gemounted zu haben 😉

Von den von dir genannten Dingen habe ich bisher nicht gehört. Nach erster Sichtung erscheint mir das aber eher als oversized - oder liege ich damit daneben?

In größeren Installationen (oder weil man es kann) nimmt man Tools welche die Systemkonfiguration in einen bestimmten Stand bringen, dazu gehörten Ansible, Chef, Puppet und noch einige andere.

mfg Stefan

bbs-lehrer schrieb:

Wenn ich z.B. das Verzeichnis mit den HTML-Dateien für einen startenden Webserver-Container benötige,

Das gehört in deinen Container-Build rein.

Kann man da Befehle auf dem Docker-Host ausführen? Ich hab das so verstanden, dass die Befehle im Container laufen. Kannst du ein Bespiel geben?

bbs-lehrer schrieb:

Wenn ich z.B. das Verzeichnis mit den HTML-Dateien für einen startenden Webserver-Container benötige, welches auf einem anderen Server bereitgestellt wird

Was meinst du mit "anderen Server"? Wie werden die Daten dort bereit gestellt? NFS oder sowas?

Dann gibt es mehrere Varianten, das zu lösen:

1. permanenten Mount auf dem Host, am besten irgendwie logisch sortiert wie /mnt/docker/<SERVICE>/data/html + mount via bind-mount von dort in den Container via docker-compose

2. mount via docker-Volume mit dem entsprechenden Plugin (z.B. für NFS)

3. Images bauen, die die HTML-Daten beinhalten und diese jeweils verwenden (Variante von TheDarkRose)

Vor- und Nachteile:

1. Sinnvoll, für mehrere Projekte auf dem gleichen Host. Unabhängige docker-compose.yml (Docker-Prinzip, siehe auch die Anmerkung von encbladexp.

2. Eher unabhängig von der Host-configuration. Wird nur eingehängt wenn die Container starten. Der NFS-Client muss aber trotzdem am Host installiert werden.

3. Vorteil: Daten im Container. Keine Mounts benötigt. Nachteil: Image-Verteilung muss gewährleistet werden, bspw. lokale Docker-Registry, das ist dann etwas kniffliger.

Ich würde mal mit 1. beginnen und als Variante ggf. 2. probieren. Dann bekommt man ein Gefühl dafür. Spätestens für den SwarmMode muss man sich dann eh mit den unterschiedlichen Varianten beschäftigen.

Ich hatte noch andere Varianten im Kopf, die fallen mir aber gerade nicht mehr ein. ☺

Alles in allem ist das eine Design-Frage der Infrastruktur. Wichtig ist, dass man die Varianten kennt - nur dann kann man entscheiden, was für den eigenen Anwendungsfall/Infrastruktur passt.

Bei Fragen einfach nochmal melden.

Gruß BillMaier

Ps: 1b) Man kann natürlich das ganze (also das docker-compose up)auch in eine systemd-Unit packen und diese abhängig vom Mountpoint machen.

Pps. config für 2 (ich musste lange suchen)

volumes:
  nfs-data:
    driver: local
    driver_opts:
      device: :/
      o: addr=<IP>
      type: nfs4

ok ☺ 1b. und 2. sehen gut aus. Danke. Probiere ich aus.

bbs-lehrer schrieb:

ok ☺ 1b. und 2. sehen gut aus. Danke. Probiere ich aus.

1b) ist ja nur die Erweiterung von 1)

Ich frage mich tatsächlich auch (wie encbladexp) , warum die mounts nicht immer da liegen sollen. Aber ich kenne ja das Design nicht.

gelöst?