eben nicht … wenn NC direkt im docker-container daher kommt, reicht doch ein docker-compose up und die Kiste rennt.
Und wenn aus einem Server der alles unter einer Haube hat, nun „plötzlich“ drei werden (was ja offenbar nicht zwingend notwendig ist, wie Holger und „ch“ schreiben), dann hat man anstelle von einem Server drei Server zu pflegen. Ich will damit nur sagen, dass es dann eben kein KISS mehr ist – nicht, dass es unmöglich wäre.
Hallo Michael,
ja, in der Standard-Config, aber wenn du z.B. die DB auf einen anderen Server legen willst (Aufspaltung von Ressourcen), dann musst du doch an die Docker Config genauso Hand anlegen wie an eine Nicht-Container Installation.
Ich würde da sogar bei Docker mehr Nachteile als Vorteile sehen, denn mySQL läuft dann ja immer noch im Docker, obwohl die DB auf einem anderen Server liegt.
Viele Grüße
Steffen
… wir drehen uns im Kreis. Meine Frage lautet ja auch: Wie installiert man es so, dass es einfach ist UND performant läuft.
Hi,
wir haben die Cloud vor Kurzem auf einen deziderten Server umgezogen, da die alte Cloud an einem T@school-Anschluss mit 16Mb down und 2Mbit up hing. da ging natürlich schnell nix mehr. Beim Umzug haben wir einfach mal docker ausprobiert und abgesehen davon, dass die Migration von nc 16 auf 18 ein bissl gezwickt hat, hat das ganz gut funktioniert,
Wenn du deine docker.compose.yml zusammengebastelt hast, die Datenbank in den mariadb-container importiert hast und die Daten auch zur Hand hast, ist eigentlich nicht viel mehr zu machen (reverseproxy und zertifikate noch). Auf jeden Fall einfacher und am Ende auch schneller als eine NC z.B. in einer VM aufzusetzen, wie ich das beim letzten Mal gemacht habe. Und die Performance stimmt auch, denke ich.
Einen nacken Stack mit nc,mariadb, redis hast du in 5 Minuten laufen.
Ich würde wieder Docker nehmen für die NC
Viele Grüße
christian
Hallo Christian.
na ja – ich dachte da an fertige yml-Files; wie beispielsweise hier angeboten (in der Hoffnung, dass da viele Settings schon optimiert wurden??).
Andere hier berichteten schon mal davon, dass der docker-Container (aus Gründen, die imho nie ganz geklärt wurden) gefühlt oder tatsächlich messbar langsamer war als eine direkte Installation. Aber wenn du sagst, dass es flüssig läuft, wäre das ja nochmal eine Überlegung wert …
Schöne Grüße,
Michael
Hallo Michael,
ja, klar. So hab ich das auch gemacht und angepasst an meine Bedürfnisse.
Ich hab das nicht nachgemessen.
Man kann da sicher ne Menge optimieren (Wahl des docker-storage-Treiber usw), wenn man Zeit und Lust dazu hat. Ich habe beides nicht.
Die NC läuft hier wie oben beschrieben problemlos, sauber und flüssig. Das reicht mir!
Viele Grüße
christian
Hi,
zur Frage, wie performant die eigene Nextcloud läuft, habe ich gerade (zufällig) etwas gefunden. Wenn man den redis-Cache im Hintergrund verwendet, kann man einen Benchmarktest durchführen. Ich habe das gerade mal gemacht:
redis-benchmark -h 127.0.0.1 -p 6379 -n 100000 -d 1000000 -c 200und erhalte dabei die Größenordnung: 40.000 requests per second
Ob das jetzt „brauchbar/mittel/schlecht“ ist, kann ich so aber nicht beurteilen. Welche Werte spucken Eure Nextclouds denn so aus?
Viele Grüße,
Michael
Hi,
Ich glaube, der eigentliche Flaschenhals ist die Internetanbindung. Genauer gesagt die Uploadrate.
Bei mir zuhause läuft auf einem Raspberry pi 4 mit 4 GB und einer ssd eine Nextcloud ( wie hier beschrieben). Das geht echt gut. Allerdings habe ich eine Uploadrate von 25 MBit/s.
Gruß,
Mathias
Hi. Die Schule ist neuerdings mit 1GBit angebunden, das sollte vorerst ausreichen.
Falls du eh einen RPi verwendest – kennst du auch das hier? Damit ist es wirklich extrem einfach:
Viele Grüße
Michael
Hallo Michael,
ich habe Deinen Befehl ausgeführt, s.u. Der Host ist ein Ryzen 9 3900X. Die Festplatten sind sehr schnelle NVMEs. Die NC ist für die ganze Schule offen (~900), wird aber (noch? es gibt sie schon seit Owncloud 6…) nicht exzessiv genutzt.
Bei den ersten beiden PING-Ausgaben habe ich ~130k per second.
Dann kommt:
100000 requests completed in 36.03 seconds
200 parallel clients
1000000 bytes payload
keep alive: 1
100000 requests completed in 42.70 seconds
200 parallel clients
1000000 bytes payload
keep alive: 1
====== INCR ======
100000 requests completed in 0.85 seconds
200 parallel clients
1000000 bytes payload
keep alive: 1
99.27% <= 1 milliseconds
100.00% <= 1 milliseconds
118063.76 requests per second
Error: Connection reset by peer
Die NC ist eine eigene VM (12 GB RAM), auf der habe ich aber auch ein Collabora-Docker drauf laufen. Der frisst deutlich an CPU-Performance, Ich würde sagen mind. 0.5 Cores und 500MB RAM pro Verbindung. Wenn Du Performance-Sorgen hast, würde ich den auf jeden Fall auslagern, ist aber sicherlich das einfachste am ganzen Setting.
Hoffe, das hilft Dir.
LG
Max
ach, und „Talk“ habe ich bei Coronabeginn abgeschaltet, da es schlecht lief und viel Ressourcen gefressen hat. BBB war besser.
Hi Max. Das ist schon ein erheblicher Unterschied 
Ich stelle Talk auch wieder ab…
Hast du denn auch Quota für die User eingetragen (s. Parallelthread)
Viele Grüße
Michael
Du kannst ja auch BBB in die Nextcloud einbinden.
Gruß
Roland
Genau, haben wir gemacht, in Moodle auch. Deshalb tat es wirklicn nicht weh…
LG
Max
Hi Michael,
bei mir sind in der NC automatisch (und schon immer) Begrenzungen des Speicherplatzes aktiv (200 MB Schüler, das reicht eigentlich).
Ich kann mich nicht erinnern, dafür etwas installiert zu haben. Default Group Quota und Group Quota sind jedenfalls nicht aktiv. Über den LDAP mache ich das auch nicht.
LG
Max
Wie meinst du das? Als Link oben in der Menu-Leiste oder gibt’s da noch etwas anderes?
Meinst du das hier??
(Kannte ich bis gerade noch nicht …)
Genau an die habe ich gedacht.
LG
Roland
Hi Roland,
hab’s installiert (was aber kein Selbstläufer war).
Die Integration in die Cloud macht sich aber sehr gut! Danke für den Tipp!
Viele Grüße,
Michael
Servus Michael ( man sieht: ich bin Bayer 
)
es freut mich, dass es läuft.
Viele Grüße
Roland