To docker or not to docker

Jesko · 23. November 2022 um 16:14

Ich wüsste nicht, was simpler sein sollte, als eine Nextcloud im Docker…
ALLE Probleme, die durch die Verzahnung verschiedener Versionen verschiendener Komponenten (php, mysql, … was auch immer) entstehen können, sind durch die Docker-Geschichte erledigt… ich habe gerade mit NULL Aufwand die Komplette Instanz von server A nach server B übertragen… das wäre ohne Docker deutlich aufwändiger gewesen… so war es nur:
auf dem alten Server:
~# docker-compose down ; rsync -a cloudverzeichnis neuerserver:/srv/docker/
und auf dem neuen Server
~# docker-compose up -d

DAS ist für mich KISS in Reinform…

Ok… im Reverse-Proxy musste auch noch der neue Server rein… aber das wär ja so oder so so…

LG Jesko

crazy-to-bike · 23. November 2022 um 18:43

Hallo Jesko,

mein einziger Kontakt mit Docker beschränkt sich bislang auf BBB, und da hat dieser mangels (warum auch immer) Internetzugriff Neuinstallation von BBB gekostet, weil ich das nicht gelöst gekriegt habe.
Wenn es/er läuft, mag Docker einfacher sein, weil er alles in der richtigen Version mitbringt.
Wenn aber nicht, ist es halt eine Blackbox.
Ich mag keine Blackboxen und bin mit herkömmlicher Installation seit vielen Jahren auf allen Servern immer sehr gut gefahren.
Die von dir beschriebenen Probleme kommen doch eher, wenn man zu viel am Serversystem rumbastelt und nicht vorgesehene Versionen installiert.

Viele Grüße
Steffen

Tobias · 24. November 2022 um 09:49

Ist nur eine Blackbox bis du a.) das erste Mal einen Docker produktiv am Laufen hast, b.) live darin dich bewegt hast c.) hinbekommen hast, die live-änderung zu speichern, so dass bei einem Neustart des containers diese Änderung drin ist und dann übergegangen bist zu d.) verstehen, dass man am besten einen docker-container auf Grundlage eines anderen Containers selbst baut.

Dann hast du mehr als genug … und das ist keine Blackbox mehr für dich.

Für den letztendlichen Betrieb, wie ihn Jesko beschreibt (und ich privat aus Neugierde und dann Faulheit einfach mal für die NC in Betrieb habe) brauchst du dann nur noch a.)

Insofern: wenn es eine Fobi dazu gibt: einfach mitnehmen, dann ist gut.

VG, Tobias

crazy-to-bike · 24. November 2022 um 10:02

Hallo Tobias,

und bekommt man eine existierende NC dockerisiert (Datenbank)?

Sonst hat sich das eh komplett erledigt.

Viele Grüße
Steffen

sucher · 24. November 2022 um 12:35

Ich tue mir da auch schwer mit docker.
Man sollte dann ja alles so einrichten dass die personenbezogenen Daten alle ausserhalb des Containers gespeichert werden weil sonst kann man ja auch den container nicht einfach austauschen bei einem update oder so. Und dann verpuffen doch die adminstrativen vorteile beim Handling oder?

rettich · 24. November 2022 um 18:53

Hallo Steffen,
würde dir phpMyAdmin da weiter helfen?
Gruß,
Mathias

Jesko · 24. November 2022 um 18:56

Auf meinem Dockerhost brauch ich an gar nix rumbasteln … da läuft Docker, ein nginx als reverse-proxy (könnte auch woanders laufen…) und das wars im Grunde.
Ein Container „DNSroboCert“ holt mir regelmäßig die Wildcard-Zertifikate von letsencrypt. Stattdessen lief vorher dehydrated. Das hat dann irgendwann mal gestreikt und mein quickfix-Provisorium hat dann bis jetzt gehalten.
Ich bin super froh damit.
Allein dass da auf dem Server fünf Nextclouds laufen, die alle für sich selbst sind, find ich schon prima.
Update mach ich per
docker-compose pull; docker-compose down ; docker-compose up -d
und das wars dann auch in aller Regel (meistens muss ich noch ein occ für irgendwelche missing-indices hinterherschicken)
Wenns klappt ist super, wenn nicht, hab ich von dem Volume ein LVM-Snapshot gemacht und merge den zurück. Das musste ich aber noch nie (außer beim Test, ob das klappen würde)

Auch die Möglichkeit, die Nextcloud mal eben zu duplizieren, um Tests mit irgendwelchen Apps zu machen, ohne den Betrieb zu stören will ich nicht mehr missen.

Bei irgendwelchen Images, die irgendjemand fabriziert, bin ich auch vorsichtiger. Aber es gibt ja bei den meisten Dingen offizielle Docker-Images vom Hersteller. So auch bei Nextcloud.

LG Ich freu mich schon auf morgen

crazy-to-bike · 24. November 2022 um 19:19

Hallo Mathias,

das „Problem“ ist ja nicht der SQL-Dump, sodern dass die Datenbank, wenn man Docker nutzt, doch sicher im Docker läuft. Und vermutlich müsste auch data da rein

Aber wie spielt man den Datenbankdump in die Datenbank im Docker?

Einen Nginx habe ich auch nicht, weil alles auf demselben Server läuft oder einfach über die Index.php weitergeleitet wird.

Umstieg auf Docker wäre also ein ziemlicher Aufwand bei (für mich) wenig Vorteil.

Auch z.B. eine Kopie der NC erstellen, wie @Jesko argumenriert, ist ohne Docker doch auch kein Hexenwerk.
Verzeichnis und Datenbank klonen. Macht 2-3 Befehle auf der Konsole.

Ebenso sind mehrere NC auf demselben Server problemlos auch ohne Docker möglich.

Ich sehe da echt noch keinen wirklich entscheidenden Vorteil, die NC zu dockerisieren

Viele Grüße
Steffen

rettich · 24. November 2022 um 19:33

Hallo Steffen,
die Datenbank läuft bei mir tatsächlich im Docker-Container. Aber das ist kein Problem.
Mit dieser docker-compose.yml Datei:

version: '3'
services:
  db:
    container_name: myadmin
    restart: always
    image: phpmyadmin/phpmyadmin
    environment:
      PMA_HOST: database
    ports:
      - "81:80"

networks:
  default:
    external:
      name: nextcloud_backend

Startest du ein phpmyadmin im Netzwerk deiner Nextcloud. Dann kannst du deine Datenbank übertragen.

Wenn du lieber auf der Konsole arbeitest kannst du mit
docker exec -it docker_app_db_1 /bin/bash
auch direkt als root auf der db anmelden. (Hab ich nicht gemacht )

Wenn du dicht an die Anleitung in docs.linuxmuster.net hälst, gibt es das Unterverzeichnis nextcloud, in dem du vom Dockerhost vollen Zugriff auf deine Daten hast.

Gruß,
Mathias

Jesko · 24. November 2022 um 19:33

Hi Steffen
Datenbank zurückspielen:

cat backup.sql | docker exec -i CONTAINERNAME /usr/bin/mysql -u root --password=geheim DATENBANKNAME

Das ist also genau so einfach wie ohne
Aber ist ja am Ende egal… ich wollte dich überhaupt nicht drängen, da irgendwas zu ändern… nur ICH wollte darauf nicht mehr verzichten
LG

Jesko · 24. November 2022 um 19:43

Hi @sucher,
Ja klar, Daten, die bleiben sollen, müssen in ein „Volume“. Das kann man hinlegen wo man möchte.
Nur liegen dann alle Daten, die zu einem Projekt gehören gemeinsam mit der Beschreibung wer und was in einem Ordner.
Es ist kein so riesen Unterschied. Ich finde es aber grandios.

~~Ist aber irgendwie hier auch offtopic… mal schauen, ob ich das irgendwie rauslösen kann aus dem Thread…~~ Rausgelöst ist es… nicht alles dabei, was dazu gehört… aber so wichtig ist es ja nicht… wir werden den Faden schon nicht verlieren

Tobias · 25. November 2022 um 17:36

Hi Steffen,
schau mal das Dateiverzeichnis auf meinem Server, das sagt dir Vieles: ich habe alles aus dem Container gezogen:

root@nextcloud-server /srv/docker #  du -sch nextcloud/*
108K    nextcloud/config
18G     nextcloud/data
244M    nextcloud/db
229M    nextcloud/db.bak
1.3G    nextcloud/html
107M    nextcloud/log
960K    nextcloud/redis
20G     total

Konfiguration, Daten, Datenbank, html, log und redis … alles in eigenen Verzeichnissen außerhalb des Containers. „html“ ist sicher nicht nötig, hat aber den Vorteil, dass die Erweiterungen (bislang) immer drin blieben beim Update.

Dann meinen docker-compose.yml dazu:

##
## Nextcloud
##
  nextcloud-db:
    image: mariadb:10.6
    container_name: nextcloud-db
    restart: always
    command: --transaction-isolation=READ-COMMITTED --binlog-format=ROW
    volumes:
      - ./nextcloud/db:/var/lib/mysql
    environment:
      - MYSQL_ROOT_PASSWORD=asdfasdf
      - MYSQL_PASSWORD=asdfasdf
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud
      - MARIADB_AUTO_UPGRADE=true
  nextcloud-redis:
    image: redis:6-alpine
    container_name: nextcloud-redis
    restart: always
    volumes:
      - ./nextcloud/redis:/data
  ## nextcloud-cron, siehe /etc/cron.d/
  nextcloud:
    image: nextcloud:apache
    container_name: nextcloud
    restart: always
    links:
      - nextcloud-db
    depends_on:
      - nextcloud-db
      - nextcloud-redis
    volumes:
      - ./nextcloud/html:/var/www/html
      - ./nextcloud/config:/var/www/html/config
      - ./nextcloud/data:/var/www/html/data
      - ./nextcloud/log:/var/log/apache2
    environment:
      MYSQL_PASSWORD: asdfasdf
      MYSQL_DATABASE: nextcloud
      MYSQL_USER: nextcloud
      MYSQL_HOST: nextcloud-db
      REDIS_HOST: nextcloud-redis
      REDIS_HOST_PASSWORD:
      VIRTUAL_HOST: cloud.meinserver.de
      VIRTUAL_PORT: 80
      LETSENCRYPT_HOST: cloud.meinserver.de
      LETSENCRYPT_EMAIL: t.kuechel@meineemail.de

Das ganze ist noch eingerückt, weil es innerhalb von „services:“ läuft.

Den reverse-proxy, den man haben sollte, kann man (wie schon immer mal diskutiert), entweder auf dem Host (nicht im Container) konfigurieren, z.B. nginx + certbot/dehydrated oder - so hab ich es dort :

services:
##
## Proxy
##
  proxy:
    container_name: proxy
    restart: always
    image: jwilder/nginx-proxy:latest
    ports:
      - "80:80"
      - "443:443"
      - "1935:1935"
    volumes:
      - /var/run/docker.sock:/tmp/docker.sock:ro
      - ./proxy/certs:/etc/nginx/certs:ro
      - ./proxy/vhost.d:/etc/nginx/vhost.d
      - ./proxy/html:/usr/share/nginx/html
      - ./proxy/nginx.tmpl:/app/nginx.tmpl                           # if you need a custom (global) nginx template
    labels:
      - "com.github.jrcs.letsencrypt_nginx_proxy_companion.nginx_proxy"

##
## Letsencrypt
##
  proxy-le-companion:
    container_name: proxy-letsencrypt
    restart: always
    #    image: jrcs/letsencrypt-nginx-proxy-companion:latest
    image: nginxproxy/acme-companion
    volumes:
      - ./proxy/vhost.d:/etc/nginx/vhost.d
      - ./proxy/html:/usr/share/nginx/html
      - ./proxy/nginx.tmpl:/app/nginx.tmpl                           # if you need a custom (global) nginx template
      - ./proxy/certs:/etc/nginx/certs:rw
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - ./proxy/acme:/etc/acme.sh

Das Ganze ist jetzt noch in „version: 2“ von docker-compose. An anderer Stelle habe ich schon auf „version: 3“ upgedatet. Sorry, dass ich das hier jetzt nicht liefere. Sind nur minimale Stellen, wo man Änderungen diesbezüglich vornehmen muss.

Aber: wie gesagt, ich würde in meiner Aufzählung nicht einfach docker-compose.yml von jemand hernehmen, sondern mal a.) b.) c.) usw. ausprobieren, damit man einmalig ein Gefühl für docker-container hat.

Vielleicht in dem Zusammenhang: ich habe überall Ubuntu, außer auf meinem Laptop, dort habe ich arch. Der ist aber schwach auf der Brust, dort ein ungoogled-chromium zu kompilieren, wie es für archlinux typisch und nötig ist, dauert mehrere Tage.
Daher habe ich auf einem potenten Server einen docker-container mit „archlinux“ am Laufen, dort klinke ich mich ein und nehme den als build-umgebung statt meines Laptops. Klar wäre das auch mit einer VM gegangen, aber ich hab halt einen hetzner-server und nicht mehrere VMs dort… also nehme ich, was ich habe … und dafür ist docker cool.

VG, Tobias

Tobias · 25. November 2022 um 17:40

das hab ich damals, glaube ich, gemacht… wäre halt wichtig, dass die Datenbankversionen übereinstimmen, bevor man das macht und die nextcloud-version natürlich auch mindestens die gleiche…

VG, Tobias

crazy-to-bike · 25. November 2022 um 17:57

Hallo Tobias,

Liegen in HTML dann die NC-Dateien?
Dann würde im Container ja nur noch die Datenbank- und PHP-Installation in einer passenden Version liegen?

Viele Grüße
Steffen

Tobias · 26. November 2022 um 03:04

Ja, also „occ“ und so weiter.
Die Volumes sind ja auch im Container verfügbar. Da folgende: „html“, „log“, „db“ und „redis“ bei einem update des NExtcloud, SQL bzw. redis containers überschrieben werden, ist es vielleicht sinnvoller davon zu sprechen, dass das alles „im Container liegt“, durch die Volumes aber auch von außen zugänglich ist.
Außer aus Backupzwecken ist es ja überhaupt nicht sinnvoll, dass z.B. /var/lib/mysql aus dem Container auch außerhalb zugänglich ist.

Bei der NC-Installation „html“ selbst habe ich die Daten nur deshalb nach außen geführt, damit ich das Unterverzeichnis „apps“ persistent bei upgrades behalte. Vermutlich hätte auch gereicht dieses Unterverzeichnis nach außen zu führen.

VG, Tobias

Tobias · 22. August 2023 um 16:18

Hi Jesko,

ich komme zurück zur Frage: to docker or not to docker… im Fall der Nextcloud.

verwendest du das image nextcloud:27-fpm ? oder ein ähnliches? das „-fpm“ würde mich interessieren. Ich hatte das auf dem baremetal nötig. Das gab einen Performanzsprung. Allerdings habe ich auch an den Parametern frisiert… Jetzt müsste ich das im dockercontainer wieder machen, daher die Frage.
wie sieht denn deine „config/config.php“ aus? Diese Frage bezieht sich auf die Performanz wg. locking/caching/ttl, hatte ich hier ja schon mal mit @Bellm bequatscht
welche Verzeichnisse haben denn bei dir welchen Benutzer, wenn sie als Volume eingebunden werden: ich nutze das „html/“ als ein Volume und dort haben alle Verzeichnisse 755 und Benutzer ist 33:33 (also www-data), die Dateien alle 644 und ebenso 33:33. Ich hatte Berechtigungsprobleme, weil bei mir sowohl der nginx-container als auch der -fpm container auf „html“ zugreifen muss und in der Version „-fpm-alpine“ hat der User „www-data“ eine andere ID als im „normalen“ debian-basierten Image [sic!]
daneben hat bei mir „html/data“ ein eigenes Volume (für die Userdaten) und „html/config“ ein eigenes Volume (für die Konfig)

Ich habe heute erst Nextcloud Inc. angeschrieben, noch habe ich also keine Enterprise „Version“ und ich weiß daher nicht, ob sich etwas an meiner Konfig ändern muss.

Viele Grüße, Dank und schöne Ferien!
Tobias

Jesko · 22. August 2023 um 19:58

Hi Tobias

docker! aus meiner Sicht nach wie vor ganz klar … DOCKER

nein. Ich verwende das ganz normale image ohne Zusätze im Namen. Ich verwende das und bohre es mit libreoffice auf, damit ich automatisiert PDF-Dateien erstellen kann.
Dazu verwende ich das Image nicht direkt, sondern baue mein eigenes mit dem Dockerfile:

FROM nextcloud:27.0.1
RUN apt update && apt install -y libreoffice
COPY ./opcache-recommended.ini /usr/local/etc/php/conf.d/opcache-recommended.ini

in der Datei opcache-recommended.ini hab ich stehen

opcache.enable=1
opcache.interned_strings_buffer=32
opcache.max_accelerated_files=10000
opcache.memory_consumption=256
opcache.save_comments=1
opcache.revalidate_freq=60
opcache.jit=1255
opcache.jit_buffer_size=256M

das ist im Wesentlichen die originaldatei aus dem Image, aber einen Wert (weiß nicht mehr welcher) ist angepasst nach einem Vorschlag, den mir die Systemprüfung innerhalb der Administrationseinstellungen gegeben hat.

Warum kein -fpm:
Ich wollte das ursprünglich mit fpm machen, habe es aber nicht geblickt, weil ich zu dem Zeitpunkt noch gar nicht verstanden hatte, was das überhaupt ist. Und dann habe ich es anders gemacht und auch keine Not mehr gehabt, weil die Performance (spätestens seit redis) völlig ausreichend ist für meine 500 User (die irgendwie nie gleichzeitig Ressourcen belegen: Mein Performance-Monitoring sagt selten, dass in den letzten 5 min mehr als 60 User da waren. Das dürften dann größtenteils Lehrkräfte sein)

Ich habe da eigentlich nur die Default-Config:

<?php
if (getenv('REDIS_HOST')) {
  $CONFIG = array(
    'memcache.distributed' => '\\OC\\Memcache\\Redis',
    'memcache.locking' => '\\OC\\Memcache\\Redis',
    'redis' => array(
      'host' => getenv('REDIS_HOST'),
      'password' => (string) getenv('REDIS_HOST_PASSWORD'),
    ),
  );

  if (getenv('REDIS_HOST_PORT') !== false) {
    $CONFIG['redis']['port'] = (int) getenv('REDIS_HOST_PORT');
  } elseif (getenv('REDIS_HOST')[0] != '/') {
    $CONFIG['redis']['port'] = 6379;
  }
}

Da ich den Redis-Host und den Redis-Port als Environment-Variablen gesetzt habe, greift die Config.
TTL hab ich gar nicht gesetzt, ich gehe davon aus, dass 60*60 der Standard ist. Sicher bin ich aber nicht.
Den Redis-Server hab ich übrigens als Docker-Container nebendran laufen und das ganze ist orchestriert mit docker-compose

Alle haben www-data:www-data 755/644
Dass die User verschiedene IDs haben ist natürlich Käse. Ist mir allerdings nicht aufgefallen, weil ich ja den Einzelcontainer nutze.
Vermutlich nutzt du auch bind-mounts in deiner docker-compose Datei. (erkennbar daran, dass du die „Volumes“ (die keine sind) mit relativen Pfaden im Verzeichnis zusammen mit der docker-compose.yml lagerst.)
Ich hab mal gelesen, dass der Vorteil von echten Volumes (die, die dann unter /var/lib/docker/volumes/8/)(afs98uvdpoipsad9v87scaoihpsa98n7a9sc8pzhö landen sei, dass Docker sich dann um die Berechtigungen kümmert.
Vielleicht wäre das einen Versuch wert, bei deinem Stack.

Das kann man trennen oder auch sein lassen.
Ich habe nur html als Volume (genauer gesagt als bind-mount, ich steh nicht so auf Volumes, weil ich gern alles an einem Platz hab, was zusammen gehört.
Einige wenige Docker-Compose-Stacks laufen damit aber nicht (vermutlich aus den Gründen, die du oben auch merkst). Das sind: mailcow und zammad
Das sind die einzigen, die ich mit echten Volumes laufen lasse.

Ich hab außer der „Support-App“ und dem Eintragen des Schlüssels nichts geändert an meiner Config.
Ich installiere auch manchmal schon die nächste Version, auch wenn sie als Enterprise noch gar nicht angeboten wird. (Einfach Versionstag im Dockerfile erhöhen und dann - build - down - up)

Liebe Grüße und auch schöne Ferien.
Ich hab bis vor wenigen Tagen mein Arbeitszimmer aufgeräumt. SO SCHLIMM WARS NOCH NIE!

Jesko