Welche Installationsstrategie für moodle/NextCloud/$Webdienst?

Infrastruktur
1

Hi.
Nicht zum ersten Mal frage ich mich, welche Strategie man bei der Installation diverser Webdienste wie moodle/NextCloud/… zukünftig wählen sollte.

Da ja lml-V7.0 offenbar direkt mit einem Dockerhost daher kommt, ist die Frage evtl sofort beantwortet: Ist es demnächst so gedacht, dass man moodle usw einfach lokal als docker-Container mitlaufen lässt und somit das „unangenehme“ Upgrade auf aktuellere Versionen einfach docker überlässt?? Wird es damit möglich sein, das Data-Verzeichnis „außerhalb von docker“ automatisch einzubinden, so dass bei dist-Upgrades nicht mehr so viel Arbeit anfällt wie bisher? (Oder welche Rolle soll der Dockerhost sonst noch ab V7 übernehmen?)

Also, quo vadis, $webdienst?

Schönen Gruß,
Michael

2

Hallo Michael,

ja LMN 7 kommt mit optionalem Dockerserver. Für Mailfunktionalität super,
da man sich um keine Anpassungen bei Updates kümmern muss.

Für Moodle / Nextcloud sehe ich den Sinn nicht. Dort ist das Heikle ja das
Datenbankupgrade, das bei jedem Update nötig ist. Da nutzt Docker rein gar
nichts.

Viele Grüße
Steffen

3

Das sehe ich anders – wir hosten moodle auf einem vServer (kein BelWü möglich) … da läuft eine bestimme PHP/mySQL-Version. Ein Upgrade ist immer enorme Fummelei. Wenn man das mit Docker abwickelt und dort nur ein docker-Upgrade anstoßen muss, wäre man von allen Abhängigkeiten befreit – das DB-Upgrade machte hier bisher eigentlich nie Ärger, sondern war immer nur „lästige Pflicht“ …

4

Hi,

ich kenne Docker kaum und weiß daher nicht, inwieweit es einem die Update-Arbeit abnimmt. Ich habe mal versucht Nextcloud via Snap zu installieren. Das war super einfach, aber Anpassungen (z.B. Integration von LDAP) waren zu kompliziert bzw. hätte man da einen neuen Snap erstellen müssen.

Wir benutzen deshalb Linuxcontainer für (fast) alle unserer Webapps und Dienste.

vG Stephan

5

Hi Stephan.

Das liest sich sehr gut! Da Proxmox ebenfalls direkt mit LXD umgehen kann, wäre es imho möglich, dieses Vorgehen sofort umzusetzen. Ich habe bisher nur mit KVM auf dem Proxmox gearbeitet, doch habe ich schon öfter davon gelesen, dass LXD weitaus weniger ressourcenhungrig ist.

Aber mal ganz von der einfachen Umsetzbarkeit via LXD abgesehen, bleibt die Frage, ob es nicht zukünftig per docker-host noch einfacher wäre? Da gibt es vermutlich noch nicht so viele Erfahrungswerte??

Schönen Gruß,
Michael

6

Hi Michael und alle anderen,

ich beschäftige mich grade mit docker. Ich kann mir auch vorstellen, dass ich in die Richtung gehe. Wenn es ausgereift und nicht zu fehleranfällig wird, könnte es ja von linuxmuster.net “empfohlen” werden.

Wenig Vorteile sehe ich in der Wartbarkeit: ich habe bisher immer VMs geklont und entsprechend konfiguriert, gewartet habe ich sie vom server aus mit parallel-ssh aptitude -y full-upgrade, das ist bei docker auch nicht einfacher, ausser man sieht ein Webinterface als Vereinfachung.

Vorteile in docker oder lxd sehe ich in der Ressourcenschonung.

Nachteile sehe ich darin, dass man sich jetzt schon klar werden muss, was auf dem dockerhost laufen soll.

Was ich noch nicht zu Ende gedacht habe:

  • gibt es bei der nächsten Firewall eine so schön bunte Trennung der Netzwerke? Stelle ich dann den Dockerhost in die DMZ/Orange?
  • mache ich eine VM als dockerhost und darin die docker-container oder mache ich den Hypervisor/KVM/Proxmox-Host zum dockerhost? Der PLan der Entwickler von v7 ist einen Dockerhost als VM anzubieten.
  • Nach erstem Einlesen kann man die Dockergeschichte ganz schön skalieren mit load-balancing etc. das werden wir alles nicht brauchen an der Schle, oder?
  • WEnn ich das dann habe: setze ich alles in dockercontainer? z.B. moodle? oder nextcloud? für letzteres habe ich offizielle Anleitungen gesehen.
  • Wenn ich anderer Leute dockercontainer verwende muss ich jetzt einer anderen(?) Gruppe(?) von Leuten vertrauen: vorher war es das debian/ubuntu-security-team und evtl. den machern von Moodle und Nextcloud, jetzt muss ich demjenigen vertrauen, der die container managed.

im besten Fall gibt es eine kritische Masse von lmn.net-docker-usern, so dass wir in docker-hub etwas wie ein linuxmuster-docker-community Repository hinkriegen, wo wir nextcloud/moodle und ähnliche container selbst pflegen.

VG, Tobias

7

Hi Tobias,

Ich finde getrennte VMs wie sie mit LXD/LXC möglich sind, auch ganz ok. Ein Nachteil an Docker ist für mich die Unübersichtlichkeit. Es gibt natürlich GUIs wie https://portainer.io/ aber das macht es auch nicht sooo viel besser. Der Vorteil ist natürlich, dass es sehr ressourcenschonend ist und man einen Container in null-komma-nix auf den aktuellen Stand gebracht hat. Von daher sehe ich in Sache Wartbarkeit und Upgrades schon einen Vorteil! An diesem Beispiel habe ich das schon mal nachvollzogen:

https://kopfkrieg.org/2017/06/15/nextcloud-docker-nginx/ → Upgrades (unten)

Den Nachteil, den du ansprichst, verstehe ich nicht:

Warum? Wenn ich einen dockerhost habe, kann ich doch jederzeit beliebige container laufen lassen oder wieder anhalten?? Die Frage, wohin dieser DockerHost gehört (ehemals Orange – mit OPNSense weiterhin DMZ?!) ist aber interessant. Ich kenne OPNSense nicht gut genug, um es beantworten zu können. (Leider wurden die Gründe für den notwendigen Umstieg auf OPNSense bisher ja auch nicht hier im Discourse genannt?!)

Von Proxmox kommt jedenfalls der Hinweis, dass man die Docker-Container nicht direkt auf dem Host laufen lassen sollte, sondern lieber in eine VM packt. Unter Punkt 11 steht’s:
https://pve.proxmox.com/pve-docs/chapter-pve-faq.html
Man könnte also auf dem dockerhost bequem einen container für moodle und einen für NextCloud laufen lassen. Ich weiß leider auch nicht so genau, wie anfällig so ein System von docker-Containern ist. Bisher habe ich damit nur in einer VM etwas herumgespielt und einzelne Prozesse gestartet/gestoppt/auf den aktuellen Stand gebracht. Das lief meistens (aber nicht immer!) problemlos. In produktiven Umgebungen müsste man es schon genauer wissen :slight_smile:

Hier übrigens noch ein Howto, wie man es schnell unter Proxmox zum Laufen bekommt:

Die Diskussion, wohin die Reise geht und was von offizieller Seite angedacht/geraten oder im besten Fall supported wird, ist aber in jedem Fall wichtig, meine ich.

Schöne Grüße,
Michael

8

Hallo,

Docker ist im Prinzip ja LXC mit einem Union Filesystem (so hat das Projekt begonnen), inzwischen ist es natürlich ein „Container-Ökosystem“.

Aus meiner Sicht führt für uns kein Weg an Docker als „linuxmuster-Standard“ vorbei:

Mit Docker kann man einfach Images (die als Basis für die Container dienen) aus bereits vorhandenen Images „ableiten“, das passiert letztlich über das Overlay Filesystem um welches Docker die LXC Container ergänzt. Das bietet immenses Potenzial für den Austausch in der Community und für die Anpassung an die Bedürfnisse, die wir speziell haben.

Man kann z.B. ein Moodle Image nehmen, auf dessen Basis man ein eigenes Image erstellt, das z.B. LDAP genau für linuxmuster.net schon hat. (Erfundenes, eher schlechtes Beispiel, aber zu Demozwecken lass ich das mal so).

Aber vor allem in der Zusammenschau mit der damit zusammenhängenden weiteren „Eigenschaft“ von Docker wird das für uns unschlagbar: Die Images sind in „Registries“ und dort in „Repositorys“ online durchsuch- und direkt auf dem eigenen Host von dort installierbar: Man führe auf einer „leeren“ Maschine mit installiertem Docker den Befehl docker run -i -t ubuntu /bin/bash aus - das holt ein Ubuntu Image aus dem Netz und startet das mit einer Shell.

Die bekannteste Registry ist der „Docker Hub“, man kann aber auch eigene Registries haben, in denen dann Anwender ihre Images in benutzerbezogenen Repos zur Verfügung stellen und gemeinsam weiterentwickeln können - man kann die Idee erkennen, oder?

Diese Eigenschaften sind wohl die Hauptgründe, warum Docker so erfolgreich ist, obwohl es technisch sehr analog zu LXC und ähnlich zu vserver ist - und damit auf schon relativ lange vorhandenen Eigenschaften des Linux-Kernesl basiert.

Als Nachteil schlagen derzeit vor allem noch ein paar Probleme mit der Vertrauenswürdigkeit der den Containerinstanzen zugrundeliegenden Images zu Buche, aber da sind die Entwickler dran, das könnte sich bald ändern (signierte Images und ähnliches).

Wenn Interesse besteht, könnte ich für die Frühjahrstagung auch gerne einen kleinen Docker Workshop vorbereiten.

VG

Frank

1 „Gefällt mir“
9

Hallo @ironiemix,

danke für deine ausführliche Antwort. Ich denke, das Docker und LXD sehr ähnlich sind, aber einen unterschiedlichen Fokus haben. Docker → Apps, LXD → Linux-VMs. Man kann Docker vielleicht mehr mit Flatpack oder Snaps vergleichen, oder?

Je nachdem, was man braucht, kann man sich die entsprechende Technologie zu Hilfe nehmen.

Für linuxmuster.net sieht Docker sehr vielversprechend aus, auch wenn ich persönlich LXD bevorzuge :slight_smile: Liegt sicher zum großen Teil auch daran, dass ich Docker kaum kenne :slight_smile:

vG Stephan

10

Ein Beitrag wurde in ein neues Thema verschoben: Docker zum Kennenlernen

11

Hi Stephan.

Ich habe mir deine Seite bzgl LXD nochmal genauer angesehen – bzw gleich auf unserem Proxmox-Host umgesetzt. Die Installation eines Containers (Stimmt das: Unter Proxmox → LXC ohne LXD?) läuft dort relativ problemlos nach dieser Anleitung ab:
https://pve.proxmox.com/wiki/Linux_Container
(Es geht los bei „pveam update“, danach habe ich das meiste auf „default“ gelassen)

Danach kann man den neuen Container wirklich SEHR flott starten und hat Zugriff auf die Konsole. Mich wundert nur, dass jetzt so gut wie alles fehlt, was man zum Arbeiten braucht. Ich musste zuerst ein „dhclient eth0“ absetzen, um überhaupt Internetzugriff zu erhalten. Erst danach liefen die gewohnten Befehle „apt update“ usw. In diesen LXC-Containern ist ab jetzt also scheinbar jeder Schritt Handarbeit, und nichts unnötiges ist im Container installiert, richtig?

Schön an Proxmox ist, dass man sich mit dem Befehl „pct“ direkt auf die Konsole im Container einloggen kann, finde ich. Nun muss ich mich also entscheiden, ob ich in diesem Container deiner Anleitung weiter folge, indem dort HAProxy bzw nginx installiert wird – oder ich daraus doch lieber einen dockerhost mache und ich lieber docker, git und Co installiere … :interrobang::question:

Schöne Grüße,
Michael

12

Hi @Michael,

mit Proxmox habe ich noch nicht gearbeitet, aber ich schau dir mal LXD/LXC auf einem Ubuntu-Rechner an. Die beiden in Kombination finde ich unschlagbar. Sehr einfach zu bedienen und mächtig. Ich kann mir gut vorstellen, dass Proxmox und LXD verschiedene Standard-Images verwenden.

Ich kann dir folgende Blogreihe noch empfehlen: https://insights.ubuntu.com/2016/03/14/the-lxd-2-0-story-prologue/

Eine schöne Sache an LXD ist für mich noch, dass ich einen Container z.B. lokal auf meinem Rechner testen / einrichten kann und ihn dann später einfach auf den Schulserver schiebe.

Viel Spaß :slight_smile:

vG Stephan

PS: Docker kann man auch in einem Container laufen lassen: https://insights.ubuntu.com/2016/04/13/stephane-graber-lxd-2-0-docker-in-lxd-712/

13

… da Proxmox nur direkt LXC bietet, müsste ich doppelt virtualisieren, um das mit LXD & Ubuntu erreichen zu können. Das überlege ich mir nochmal…

14

Das machen wir auch so (XenServer → Ubuntu-Server → LXD/LXC). Bei Docker wäre es ja nicht so viel anders…

15

Hi Stephen.
Da hast du Recht … ich dachte nur: KISS bzw möglichst zunächst nur die Bordmittel nutzen, bevor man es doppelt und dreifach kompliziert macht.

Ich habe übrigens als LXC dieses Template gewählt:

system ubuntu-17.10-standard_17.10-1_amd64.tar.gz

Das ist 197 MB groß – daher kann es tatsächlich nicht viel mehr als den blanken Kernel und die aller notwendigsten Tools enthalten. Wie groß ist denn dein Ubuntu-LXD-Template bzw was beinhaltet das alles direkt?

Übrigens: Dass man einen Container zunächst zu Hause laufen läßt / ausprobiert / konfiguriert und erst später auf den Host schiebt, ist natürlich elegant, doch das wird vermutlich bei mir nicht allzu oft vorkommen, wenn ich die Container alle auch direkt in der Proxmox-GUI verwalten kann.

Schönen Gruß und einen guten Rutsch.
:two::zero::one::seven: :boom: :soon: :two::zero::one::eight:

16

Auf meinem Test-Server laufen drei Container (HAProxy, zwei Webserver). Die brauchen zusammen 1,27 GB.

Dadurch das die Container und der Host sich den Kernel teilen, verbraucht man Default Ubuntu Container folgendes:

$ lxc launch ubuntu:x test
Creating test
Starting test

$ lxc info test
Name: test
Remote: unix://
Architecture: x86_64
Created: 2018/01/01 05:10 UTC
Status: Running
Type: persistent
Profiles: default
Pid: 12204
Ips:
  eth0:	inet6	fde9:d763:6c02:c45f:216:3eff:fec2:a4ff	vethH0NBJG
  eth0:	inet6	fe80::216:3eff:fec2:a4ff	vethH0NBJG
  lo:	inet	127.0.0.1
  lo:	inet6	::1
Resources:
  Processes: 6
  Disk usage:
    root: 4.86MB
  CPU usage:
    CPU usage (in seconds): 3
  Memory usage:
    Memory (current): 27.11MB
    Memory (peak): 49.93MB
  Network usage:
    eth0:
      Bytes received: 3.52kB
      Bytes sent: 928B
      Packets received: 23
      Packets sent: 8
    lo:
      Bytes received: 0B
      Bytes sent: 0B
      Packets received: 0
      Packets sent: 0

5MB für das rootfs und 50MB in der Spitze :slight_smile:

Es sind die meisten Standardtools vorhanden (wget fehlt aber z.B.). apt ist mit dabei so dass man alles schnell installieren kann, was man noch braucht.

vG Stephan

PS: Ich habe noch einen weiteren Artikel geschrieben, der das HAProxy. LXD Setup noch um HTTPS / SSL erweitert.

1 „Gefällt mir“
17

Super!! Sehe ich das richtig: Wenn man es so macht hat man ein Setup, bei dem nur der HAProxy mit LetsEncrypt versorgt wird und alle anderen Services/Server können auf dieses Zertifikat zurückgreifen?

18

Ja, so ist es :slight_smile:

1 „Gefällt mir“
19

Hi Stephan,

willst du mich ärgern :smirk:, oder hast du das schon länger am Laufen? Irgendwie hat immer schon jemand (oft du) das Rad schon erfunden, wenn ich was hinkriegen will. Egal, hab viel gelernt.

Ich schau mir auf alle Fälle mal haproxy unter Docker mal an, letsencrypt machst du, wie ich sehe ja händisch. Ich hatte die traefik-Variante ja nur ausprobiert, weil sie scheinbar letsencrypt automatisch (in der gleichen Conf-Datei) verwaltet. Auf alle Fälle macht letsencrypt+reverseProxy in einer VM/Container einfach sinn, soviel hab ich selbst herausgefunden, egal ob mit haproxy,nginx, apache oder eben traefik.

VG, Tobias

20

Hi Tobias,

nein :wink:. Wir haben ein ähnliches Setup bei uns laufen, nur das HAProxy direkt auf der Firewall (pfSense bei uns) läuft. Dadurch sparen wir uns eine öffentliche IP. Der Nachteil ist, dass wir die Zertifikate einzeln auf den Webservern verwalten müssen. Da man das aber automatisieren kann, geht es aber :slight_smile:

vG Stephan