Hallo,
darum stelle ich mir auch eher vor, dass ich vieles, was ich bislang als Paket gebaut habe eben künftig (für linuxmuster) als Container mache - ich denke, dass so ein MRBS Container oder ein OSP Container da mal ein guter Start sind.
VG
Frank
Hallo,
hier Teil 4: Daten teilen und dauerhaft speichern mit Volumes
Wir lernen Volumes beim Imagebau bereits im Dockerfile festzulegen, finden raus, wie lange Volumes und die darin enthaltenen Daten leben. Wie kann man vorhandene Volumes in neuen Containern nutzen und wie kann man auf diese Weise mit “Datencontainern” eine persistente Datenhaltung über den Start neuer Containerinstanzen hinaus erreichen? Und außerdem wichtig: Wie kann man Verzeichnisse des Hosts in einen Container hineinreichen, um Daten persistent zu speichern (und welche Nachteile hat dieses Verfahren…)?
Wiki:
http://www.linuxmuster.net/wiki/anwenderwiki:webapps:docker:grundlagen:docker04:start
Viel Spaß,
VG Frank
3 „Gefällt mir“
Lieber Frank,
ich habe mit GROSSEM Vergnügen und Interesse zwei Deiner vier docker-Videos angeschaut. (Demnächst sehe ich mir den Rest an). Danke für den Spaß und die interessanten Informationen, die Du - in einer für mich sehr fasslichen, entspannten Art - hier 'rüberbringst. Hätte ich mal früher solche Lehrer gehabt !
Merci -
Christoph Gü.
1 „Gefällt mir“
Hallo,
heute wirds wohl nix mehr mit dem docker-compose Video, aber ich habe mal begonnen, mich dem von @morpweb im anderen Diskussionfaden formulierten komplexitätsproblem zu nähern.
Das hängt eng mit dem Problem zusammen, dass wir „anwenden“ und lernen „vermischen“. Die Entscheidung für Docker ist tatsächlich weitgehend gefallen, weil das Mailsystem in Version 7 höchstwahrscheinlich als Docker Container daherkommt - aber dort derzeit auch eher unmodular - hatten wir in Essen drüber diskutiert.
Wir müssen es aber eben schaffen, den Einsatz von (unseren Standard-)Containern in linuxmuster gut und klar zu strukturieren - es kann IMHO am Ende nicht sein, dass jeder Container mit irgendeinem Shell/Python whatever Skript auf schwer durchschaubare Weise konfiguriert und gestartet wird.
Darum habe ich mal ein (derzeit extremn rudimentäres Skript gemacht, das aus einem nackten Ubuntu 16.04 + apt-get install git einen "linuxmuster-docker-Host macht:
Das macht derzeit im Prinzip folgendes.
- Installiert die neueste Version von docker-ce aus den docker.io Repos
- Installiert das dazu passende docker-compose
- Legt einen Benutzer „dockeruser“ an, der in der Gruppe „docker“ ist. Dieser Benutzer steuert nachher die Container, damit man das nicht als root machen muss - das ist nämlich mit wenig Nachdenken offensichtlich keine gute Idee.
- Individualisiert die ssh-host-keys.
Nun kann man z.B. im Home des dockeruser systematisch Informationen und compose-Dateien für Container ablegen, die man auf diesem Docker-Host laufen lassen will. Wie die Konventionen da genau aussehen sollten, muss man sicher erst mal ausprobieren.
Ein erster Container sollte dabei wohl sicherlich der Reverse Proxy sein.
Alle (offiziellen) Container sollten vom Dockerhub aus dem Repo linuxmuster/XYZ kommen und nicht direkt vom Upstream. Der Zwischenschritt macht zwar ein wenig Arbeit, aber so können wir immer erst mal testen, ob Upstream Updates tun, bevor das an die linuxmuster-Benutzer geht.
Beispiel: Ich nehme (als Entwickler/Betreuer eines Images) eben das nextcloud Image und baue daraus ein linuxmuster/nextcloud Image, im einfachsten Fall durch bloßes „kopieren“ im FROM des Dockerfiles.
Wenn es ein Nextcloud Update gibt, baue ich das linuxmuster/nextcloud als Entwickler neu und teste das - und erst wenn ich sehe, dass das wirklich tut, pushe ich das ins linuxmuster-Repo in den Dockerhub, von wo aus es über die offizielle Updatefunktion von linuxmuster.net an die Anwender geht.
Zusammenfassend: Klare Struktur zur Informationshaltung auf unserem linuxmuster Dockerhost, Updates für offizielle Container nur von uns.
Das Video hier zeigt, wie man den Demo Host auf das linuxmuster-dockerhost Skript umstellt:
VG
Frank
2 „Gefällt mir“
Hi Frank.
Auf diese Weise ist für alle ein sehr gut beschreitbarer Weg gefunden, meine ich! Sehr gut! 
Ich werde den linuxmuster-dockerhost bei mir unter Proxmox als LXC-Container (Tautologie 
) installieren, da der ziemlich flott startet und kaum Ressourcen benötigt. Wir hatten eine ähnliche Diskussion neulich im Parallel-Thread – es macht ja scheinbar für die Installation und den produktiven Betrieb von docker keinen großen Unterschied, ob man ein “vollewertiges” Ubuntu als VM oder ein schlankes Ubuntu als Container laufen läßt?!?
Schönen Gruß – ich komme mit den Videos kaum hinterher.
Michael
Hej,
Lass dir Zeit - wenn die Schule wieder anfängt nimmt die Frequenz ab 
VG
Frank
alleine schon deswegen sinnvoll, weil sich docker-images z.B: beim Neustart des systems automatisch aktualisieren (in der standard-ubuntuvariante von docker+docker-compose) wie ich heute herausfand: ich hatte testweise gitlab-ce im container installiert und den host rebootet - inzwischen war ein neues Image draußen und damit wurde „:latest“ eben beim neuen start geholt.
Wenn linuxmuster/reverseproxy:latest und ähnliche kuratiert werden wäre der updatemechanismus auch als standard wünschenswert und komfortabel.
VG, Tobias
1 „Gefällt mir“
Moin,
vielen Dank für die informativen Videos.
Das ist ganz großes Kino!
Gruß ch
1 „Gefällt mir“
Hi Frank.
Ich habe es gerade installiert und erhalte diese Meldung, nachdem docker geholt wurde:
Installing docker-compose version 1.18.0 …
Setting up docker-ce (17.12.0~ce-0~ubuntu) …
Job for docker.service failed because the control process exited with error code.
See „systemctl status docker.service“ and „journalctl -xe“ for details.
invoke-rc.d: initscript docker, action „start“ failed.
docker.service - Docker Application Container Engine
Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
Active: activating (auto-restart) (Result: exit-code) since Sat 2018-01-06 11:24:49 UTC; 7ms ago Docs: https://docs.docker.com
Process: 3934 ExecStart=/usr/bin/dockerd -H fd:// (code=exited, status=1/FAILURE)
Main PID: 3934 (code=exited, status=1/FAILURE)
CPU: 44ms
dpkg: error processing package docker-ce (–configure):
subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
docker-ce
E: Sub-process /usr/bin/dpkg returned an error code (1)
Hast du eine Idee?
Hab’s unter Ubuntu 17.10 versucht – kann es das schon gewesen sein?
[etwas später]
Ok, ich verwende unter Proxmox lieber doch kein LXC für docker sondern nehme eine „vollwertige VM“ (KVM, qemu2). Das scheint doch der bessere Weg zu sein – dann dürfte es zwar auch mit 17.10 laufen, aber ich kann auch bei 16.04 LTS bleiben!
Übrigens: Darauf gekommen bin ich erst, als ich mir „dockerd -D“ angesehen habe. Da stand dann:
„Could not check if docker-default AppArmor profile was loaded: open /sys/kernel/security/apparmor/profiles: permission denied“ – also ein AppArmor-Problem vom Proxmox-Host!? Jaaa, ich kann Bertram bestätigen: docker macht die ganze Sache komplexer! Aber dabei nicht uninteressanter 
https://www.reddit.com/r/docker/comments/5pyd2i/installing_docker_on_proxmox_lxc_issue/
Michael
Hallo Frank,
ich denke, dass so ein MRBS Container oder ein OSP Container da mal ein
guter Start sind.
+1
Viele Grüße
Steffen
1 „Gefällt mir“
Hai,
Teil 5: Einführung in docker-compose und ein funktionaler OSP Container
Wiki:
https://www.linuxmuster.net/wiki/anwenderwiki:webapps:docker:grundlagen:docker05:start
Viele Grüße,
Frank
1 „Gefällt mir“
Hi.
So, ich habe jetzt auch die Videos 3, 4 und 4a angeschaut. Erneut super gemacht!
Ein paar Rückfragen dazu:
-
Der Platzverbrauch von docker muss ja gigantisch sein, wenn volumes bei jedem Start neu angelegt werden bzw wenn man nicht dafür sorgt, dass alte volumes mit -v gelöscht werden. Das muss man bei später produktiv laufenden Systemen tatsächlich im Hinterkopf behalten?!
-
Wenn man persistente Volumes nutzt, kann man ja das Problem, das ich neulich mal angesprochen hatte (“NextCloud & moodle verheiraten?”) in einem Streich lösen, oder?
-
Wenn ich das richtig sehe, ist die Autostart-Frage von docker-Containern noch nicht geklärt, oder? (Die Option wurde aber irgendwo hier im discourse bereits genannt, meine ich…). Also wenn der Host startet, sollen auch automatisch die entsprechenden docker-container “proxy, moodle, nextcloud …” in der richtigen Reihenfolge gestartet werden.
-
Nur nochmal zur Unterscheidung: Du hast anfänglich “docker run …” mit den Optionen gestartet, doch später einfach “docker start < name>” neu gestartet, was dann dennoch die Ports, die exposed waren, kannte. Das Verhalten ist wahrscheinlich so gewollt, nehme ich an? (In Video 4 bei 6:30 min)
-
Zuletzt noch ein kleiner Typo im Script linuxmuster-dockerhost: “just to be sure” – da war ein “h” zuviel.
Ansonsten kann ich nur sagen: Ich habe 'ne Menge gelernt und glaube immer mehr, dass das der richtige Weg sein wird!
… und kaum schreibe ich das hier zu Ende, ist auch schon Teil 5 da! Wahnsinn.
Schönen Gruß,
Michael
Hallo Michael!
Nein, eher nicht - das kommt durch das Overlay Dateisystem, das immer nur die Änderungen eines Containers zum zugrundeliegenden Image speichert. wenn du natürlich Anwemdung verwendest, die von Haus aus schon große Datenmengen mitbringen, die dann in Volumes kopiert werden und von denen viele Container (mit den entsprechenden Volumes) erzeugst und die nicht mehr löschst, dann eher ja.
Beispiel: Das OSP Image erzeugt bei jedem Start mit „automatischen“ Volumes wahrscheinlich ca. 20MB. Wenn ich natürlich das Wiki jetzt mit 1GB Daten in /var/www/html/data bereits im Image „vorbefülle“, erzeugt jede Containerinstanz halt 1GB. Wenn ich das aber produktiv einsetze, werde ich die Volumes eher zielgerichtet aus dem Host durchschieben, dann ist das eh egal (siehe Video 5).
Kann ich so nicht sagen, weil ich grade nimmer genau vor Augen habe, was du genau erreichen wolltest. wenn du Moodle innerhalb der Cloud haben willst muss man wahrscheinlich mit entsprechenden NC Erweiterungen experimentieren.
Sieh Video 5: Dieses Problem wird von docker-compose umfassend adressiert, wenn ich zu Video 6 komme (das kann etwas dauern, weil ab nächste Woche wieder Schule ist), werde ich zeigen, wie man damit eine ganze Containerlandschaft ans laufen bringen kann.
Wenn ich einen gestoppten Container wieder starte, dann hat der alle Einstellungen vom ursprünglichen Start immer noch, also z.B. die exponierten Ports. An dieser Stelle hatte ich ja den Container gestartet und ohne eine neue Instanz zu erzeugen denselben Container wieder gestartet.
Danke, das ist vielleicht schon gefixt- der Dank dafür geht an @Sven, der auf jeden Fall einen Haufen andere Typos im Repo gefixt hat.
VG
Frank
Hallo Frank.
Hier steht es nochmal im Nachbarforum - ist aber eher ein kleines Feature („nice to have“)
https://moodle.org/mod/forum/discuss.php?d=362843#p1463564
Ach ja – natürlich! Wäre ja auch seltsam, wenn’s anders wäre. Trotzdem gut, dass auch das jetzt geklärt ist
Teil 5 schaue ich mir evtl morgen an. Damit wären dann ja alle Voraussetzungen geschaffen, dass man moodle 3.4 und NextCloud 12 in einen Container verschieben könnte, oder? Die alte Frage aus dem anderen Thread klingt in deinem Video bei dem php-Container („official“) ja auch nochmal an: Sollte man sich „irgendwelche“ Quellen von Containern an Bord holen oder sollte man lieber nur bei den offiziellen Quellen bleiben? (Das ist ein ähnliches Problem wie bei Ubuntu-Repositories von Fremdanbietern, würde ich sagen…)
Von moodle-, NextCloud-Containern gibt es ja gleich mehrere (?) Anbieter … oder soll es zukünftig doch eher so sein, dass alle linuxmuster-User den kuratierten Container, der speziell auf den lml-Server zugeschnitten ist, benutzen sollten? (Wird das erst mit Version 7 zusammen sein oder völlig getrennt davon auch schon vorher?)
Ich hatte es übrigens vor einer Weile auf eigene Faust mit dem Collabora Online Office versucht … nach deinen Videos versteht man jetzt auch, was da geschieht – und siehe da: Dort taucht auch die Autostart-Option wieder auf → „Getting started in 3 steps“
Also dann – einen schönen Abend und einen guten Start in die erste Schulwoche,
Michael
Hi.
Eine kleine Ergänzung zum Thema “persistent volumes”, über das ich heute zufällig gestolpert bin:
Ich habe den docker-Container von bitnami/moodle:latest hier installiert. Den starte ich per docker-compose, wie von Frank erläutert. Die entsprechende yaml-Datei lag bisher in ~/moodle-docker, doch weil ich mich ständig vertan habe, habe ich das Verzeichnis in ~/docker-moodle umbenannt. Ergebnis: der Container startete nicht mehr richtig!
Als ich nach den Volumes geschaut habe, stellte ich fest, dass es plötzlich 4 anstatt 2 Volumes mit folgenden Namen gab:
docker volume ls
DRIVER VOLUME NAME
local dockermoodle_mariadb_data
local dockermoodle_moodle_data
local moodledocker_mariadb_data
local moodledocker_moodle_data
Muss man also darauf achten, dass man das Verzeichnis, aus dem man den Container startet (bzw wo die yaml-Datei liegt) nicht einfach umbenennt? Das ist für die Verwaltung ja nicht ganz unerheblich?! Vielleicht gibt es aber auch hier eine weitere Option, die die Volumes eindeutig identifizierbar macht?
Schöne Grüße,
Michael
Container images klein halten
zwei Strategien sollte man bedenken:
- erstens: jeder RUN Befehl erzeugt ein neues Layer, wenn ich etwas installiere, damit etwas mache und dann wieder deinstalliere, dann stecken in den vorherigen Layern weiterhin die installierten Dateien. Es bringt also nichts, am Ende ein “apt clean” aufzurufen, um Platz zu sparen. siehe hier: https://www.ianlewis.org/en/creating-smaller-docker-images
- zweitens multi-stage docker images: siehe hier: https://learnk8s.io/blog/smaller-docker-images/
VG, Tobias
wenn man sich ein alpine-abgleitetes Image zieht, zieht man sich dann automatisch auch ein leeres root-PW ? Kriegt man mit docker history oder inspect raus, ob man betroffen ist
?
(in dem Fall schaut man am besten die /etc/shadow an).
VG, Tobias
Hallo,
Ja.
VG
Frank
Hi,
gut, dann wie? Beispiel:
# docker history --format "{{.ID}}: {{.CreatedBy}}" jrcs/letsencrypt-nginx-proxy-companion:latest
7c68d6368c57: /bin/sh -c #(nop) CMD ["/bin/bash" "/app/st…
<missing>: /bin/sh -c #(nop) ENTRYPOINT ["/bin/bash" "…
<missing>: /bin/sh -c #(nop) WORKDIR /app
<missing>: /bin/sh -c #(nop) COPY dir:3eabc3e59bbd8afe8…
<missing>: /bin/sh -c chmod +rx /app/install_simp_le.sh…
<missing>: /bin/sh -c #(nop) COPY file:c956374558b1053c…
<missing>: /bin/sh -c #(nop) COPY file:88ce64f68cd9c1bf…
<missing>: /bin/sh -c apk add --update bash …
<missing>: /bin/sh -c #(nop) ENV DEBUG=false DOCKER_HO…
<missing>: /bin/sh -c #(nop) LABEL maintainer=Yves Blu…
<missing>: /bin/sh -c #(nop) CMD ["/bin/sh"]
<missing>: /bin/sh -c #(nop) ADD file:91fb97ea3549e52e7…daran kann ich echt nix erkennen. docker inspect bringt auch nichts. Wenn ich nach github gehe und das Dockerfile anschaue, sehe ich es ja, zumindest wer der direkte Vorgänger ist.
FROM golang:1.11-alpine AS go-builder
...
FROM alpine:3.8und tatsächlich zum vergleich mit mariadb:latest
# docker run --rm -it jrcs/letsencrypt-nginx-proxy-companion head -n 1 /etc/shadow
root:::0:::::
# docker run --rm -it mariadb:latest head -n 1 /etc/shadow
root:*:18010:0:99999:7:::Da muss man schon drauf vertrauen, dass Herr JRCS sein upstream-image verfolgt und andersherum: wenn man selbst docker-bauer ist, dann nimmt man besser ein offizielles Image als Baseimage und hofft dass dessen Vewalter zügig reagiert und selbst zügig reagieren…
VG, Tobias