[Sammelthread] Container unter Linux - Laberthread: von Docker über LXC bis Podman und K8

[Prankst3r]

Servus allerseits,

nachdems in einem Thread um Docker ging und festgestellt wurde, dass es keinen Quasselthread dafür gibt. Eröffne ich hiermit einen.

Hauptthema sind Container unter Linux.
Egal ob es um Docker, Podman, LXC oder deren Verwaltung oder Benutzung mit Kubernetes/K8 oder Distrobox/Toolbox geht. Auch devcontainer können hier besprochen werden. Falls es um größere Probleme geht, wäre ggfl ein eigener Thread von Vorteil. Das kann man aber auch anfangs hier besprechen.

Nützliche Infos werde ich hier immer mal wieder reineditieren. Wer schon was hat, gerne posten!

Viel Spaß beim Austauschen

Grüße

 

[Shihatsu]

Zones > Rest. Change my Mind.

 

[Prankst3r]

Zones > Rest. Change my Mind.

Ist halt Solaris und co, kein Linux :P
Da müsste man dich erstmal zu Linux konvertieren

 

[Shihatsu]

Ändert nichts daran das es den anderen Lösungen einfach inherent überlegen ist. Verstehe nicht warum die OCI (die ein guter Anfang ist) nicht noch viel mehr in diese Richtung geht. Docker skaliert schlecht, LXC ist einfach zu unflexibel, Kubernetes wird einfach immer komplexer und brauch mitlerweile in großen Geschichten noch was zusätzliches (Rancher *würg*), und Podman ist eher ein Spielzeug.
Klar, im Homelab ists mir egal, da nutze ich LXC weils völlig ausreicht und Docker einfach kackkack ist, aber für den Einsatz im großen via OCI wären Zones@Linux einfach geil - am besten per Default mit ZFS drunter, so wie für Solaris vorgesehen. Gott wie ich Oracle verachte.

 

[Prankst3r]

Es mag überlegen sein, aber ists auch weiter verbreitet und findet man dazu auch als Ottonormal-PC-User genug Infos und auch Leute, die da einem gut helfen können?
Ich war schon mehr mals kurz davor u.A. FreeBSD (wegen den Jails) oder auch Solaris Konsorten ausgiebiger zu testen, aber am Ende, war es für mich doch am einfachsten bei Linux zu bleiben. (da waren aber auch Container nicht so im Vordergrund gestanden ehrlich gesagt).

Wenn ich jetzt z.B. von Desktop Systemen ausgehe, finde ich halt Podman (mit Distrobox ) richtig gut. Einfach zu bedienen, die systemd Integration ist auch stellenweise sehr geil. (ich weiß systemd :P aber es macht was es soll bei mir und ich finde mich da gut zurecht).

Es kommt aber auch drauf an, für was man es eben nutzt, will man stark skalieren, ist Docker echt nicht toll. Für nen Heimserver aber wiederum imo/e genau das richtige. Wobei ich da auch mittlererweile eher zu Podman tendiere. Gut ich bin auch ein (RHEL/damals auch CentOS und) vor allem Fedora Fanboy (das hat sich einfach irgendwann mal so ergeben).

Wenn ich z.B. ans Programmieren denke, will ich devcontainer auch nicht mehr missen. Alles schön aufgeräumt.

[Noch ein Beispiel wäre NBDE mit Tang und Clevis, super geil! Afaik kann das Solaris nicht (Aber braucht auch nicht jeder, ist n edge case wieder und wahrscheinlich wird da Solaris auch was in die Richtung haben, aber kP ehrlich gesagt)]

 

[toscdesign]

Docker skaliert schlecht

Ist zumindest im Selfhost Umfeld eher irrelevant.
Ist hat "recht" einfach zu konfigurieren und es gibt allerhand Anleitungen, Lösungen und vorgefertige Beispiele.

LXC ist einfach zu unflexibel

Als schlanker VM Ersatz für eine bestimmte Applikation ist es optimal., wenn man keine Flexibelität braucht.

Kubernetes wird einfach immer komplexer

Ist komplex, selbst auf TrueNAS Scale war es ein Kraus.

Podman ist eher ein Spielzeug.

Das stimmt, vieles funktioniert halt auch nicht wie gewohnt. Ich hab noch nie was damit stabil und dauerhaft was zum Laufen bekommen.
Dokumentation und Untersützung im Netz ist auch eher so meh.

Beitrag automatisch zusammengeführt: 08.05.2026

Ich war schon mehr mals kurz davor u.A. FreeBSD (wegen den Jails) oder auch Solaris Konsorten ausgiebiger zu testen, aber am Ende, war es für mich doch am einfachsten bei Linux zu bleiben.

Bei Linux bekommt man eben mehr unterstüzung bzw. findet schneller eine Lösung. Gerade im Homelab will man ja das es einfach läuft.

Es kommt aber auch drauf an, für was man es eben nutzt, will man stark skalieren, ist Docker echt nicht toll. Für nen Heimserver aber wiederum imo/e genau das richtige.

Exakt!

Wobei ich da auch mittlererweile eher zu Podman tendiere.

Ne, bleib mir weg damit. Zu unfertig.

 

[Tundor]

Bezieht ihr euch dabei auf euer professionelles Umfeld oder warum ist das relevant, dass Docker schlecht skaliert bzw. nicht ausreicht? Bei mir auf der Arbeit nutzen wir auch K8s das sind ja ganz andere Dimensionen und Komplexitäten. Ich hab auf meiner Truenas Kiste 40 Container am Laufen, von schlecht skalieren merke ich da nix, das läuft alles prima.

 

[Shihatsu]

Ich redete von sowohl als auch, aber im Homelab spielt Skalierung keine Rolle. Kubernetes wird immer komplexer, und anstatt dagegen etwas zu tun wirft man halt die nächste API-Schicht drauf.

 

[Prankst3r]

Bezieht ihr euch dabei auf euer professionelles Umfeld oder warum ist das relevant, dass Docker schlecht skaliert bzw. nicht ausreicht? Bei mir auf der Arbeit nutzen wir auch K8s das sind ja ganz andere Dimensionen und Komplexitäten. Ich hab auf meiner Truenas Kiste 40 Container am Laufen, von schlecht skalieren merke ich da nix, das läuft alles prima.

Die schlechte Skalierbarkeit stammt bei mir eher aus Kontakt zu Kollegen die tausende Server mit hunderten von Containern betreut haben. Selbst bei mir oder Kundenprojekten gabs da bisher keine Probleme. Mein Maximum war da aber auch bisher ~60 Container auf einem Host (ging da u.A. um sehr viele kleinere Webseiten bzw Webapps, der Kunde wollte das alles schön getrennt haben ). Ist aber auch schon wieder ne Zeit lang her.

Auf meinen Servern (ne handvoll VPSe und Heimserver + arm Mini-PCs) läufts auch ohne Probleme mit 20-40 Containern. K8 hatte ich dafür mal getestet, aber hat keinen Sinn gemacht. Docker reicht da vollkommen aus, bzw wie ich es nutze. Liegt aber alles auch daran, dass ich im Windows Env gelernt habe und alles was Linux anbelangt mir über die Jahre nebenher selbst beigebracht habe. Hatte da nie wen, der sagt, so gehts richtig oder besser oder es passt wie ich es gemacht habe. Kunden/Bekannte/Freunde und ich selbst sind/waren damit aber immer vollkommen zufrieden. Lese halt viele Dokumentationen und hol mir auch Infos und Anregungen von anderen öffentlichen Projekten.

Ich redete von sowohl als auch, aber im Homelab spielt Skalierung keine Rolle. Kubernetes wird immer komplexer, und anstatt dagegen etwas zu tun wirft man halt die nächste API-Schicht drauf.

Aber wo hat man das denn nicht? Was halt generell in der IT auffällt, es wird immer komplexer, auf einen Layer kommt der nächste. Ich muss nur in ein aktuelles UEFI/Bios schauen und da weiß ich ehrlich gesagt nur noch die Hälfte vllt sogar weniger, was welche Einstellung denn genau macht. Das war mal anders
Mit Fortschritt kommt halt auch wieder Neues dazu, was man sich bestenfalls aneignen sollte... ob man will oder nicht

Ne, bleib mir weg damit. Zu unfertig.

Unfertig ists nicht, die meisten Container die man so findet sind halt dafür nicht wirklich ausgelegt incl der Dokumentation dafür. Größter Vorteil ist imo, dass systemd im Container unter Podman einfach läuft. Hab immer wieder systemd als dep für Docker gehabt und das ist so ein extrem beschissenens Gefrickel das zum laufen zu bekommen... Möglich, dass das vllt auch an mir liegt, Layer 8 und so

 

[toscdesign]

Unfertig ists nicht, die meisten Container die man so findet sind halt dafür nicht wirklich ausgelegt incl der Dokumentation dafür.

Angeblich soll es ja kompatibel mit den Docker Containersn sein, dann müssen die halt auch einfach laufen.
Das es keine Doku gibt, ist der nächte negative Punkt.

Größter Vorteil ist imo, dass systemd im Container unter Podman einfach läuft. Hab immer wieder systemd als dep für Docker gehabt und das ist so ein extrem beschissenens Gefrickel das zum laufen zu bekommen... Möglich, dass das vllt auch an mir liegt, Layer 8 und so

Ich hab noch nie systemd bei irgend einem Container gebraucht. Hast du mal ein Beispiel?

Beitrag automatisch zusammengeführt: 08.05.2026

Andere Frage nutzt jemand von euch Watchtower oder WhatsUpDocker für Autoupdates der Dockercontainer?

 

[Tundor]

Frage ich mich auch, wozu braucht man den systemd unbedingt im Container? Hab gerade mal nachgeschaut, unter Docker muss man den Container dafür mit privileged flag laufen lassen damit er auf PID1 vom Host Zugriff hat, das will man ja nun mal sowas von überhaupt gar nicht

 

[Prankst3r]

Ich hab noch nie systemd bei irgend einem Container gebraucht. Hast du mal ein Beispiel?

Das letzte wo ich mir die Zähne ausgebissen habe, war Mysterium-VPN. Weil das paar Freunde und ich gerne nutzen. Tausende IPs für Lau ist schon nice (gut z.B. für geo-blocking ohne dämliche blacklisted IPs von VPN Anbietern zu haben, wo Cloudflare z.B. dann direkt blockiert).
Aber auch so, wenn man z.B. nen Container mit Desktop und Web-VNC möchte, gibts immer wieder Anwendungen die das brauchen. Betrifft aber wieder eher sehr wenige use-cases. Mit Docker eben nur mit der priviledged flag, mit Podman läuft das so ohne Probleme.

 

[toscdesign]

ah ok, sowas hatte ich noch nicht.

Was sagst du zu Tools wie Watchtower oder WhatsUpDocker für Autoupdates der Dockercontainer?
Möchte vermeiden, das wie bei TrueNAS Scale die Conainer so weit veralten, das ich nicht mehr migrieren kann.

 

[Prankst3r]

Watchtower ist mitlererweile unmaintained. WhatsUpDocker kenne ich nicht. Werde ich mir aber mal anschauen.

Selbst nutze ich cronjobs mit Scripten oder einfach den docker-compose commands, stellenweise auch systemd services. Mir ist da vor allem wichtig, dass ich das einmal eingerichtet nie wieder anfassen muss, daher habe ich bisher extra Tools dafür nicht getestet. Das läuft seit Jahren ohne Probleme.

 

[Tundor]

@toscdesign Schau dir mal https://getarcane.app/ an. Das kann Autoupdates und du kannst dir auch notifications z.B. via Pushover einrichten. Container können gelabelt werden, dass du z.B. nur ne notification über neue updates bekommst, aber nicht automatisch aktualisiert wird wenn man das für bestimmte stacks so möchte.

 

[Kreis]

Womit verwaltet ihr eure Container? Alles über die cli?

Ich nutze portainer weil mit Agent auch andere Server in denen docker Instanzen laufen überwachen oder installieren kann.
Ehrlich gesagt ist mir das Programm zu groß docker Instanzen installiere ich eh meist Manuel damit ich weiß wo das ist und nicht im Server Nirvana verschwindet.
Und nur reine Überwachung starten Updates etc. ist das Zuviel was es bietet.

Was gibt es da noch so?

 

[toscdesign]

Also ich nutze auch Portainer für die Verwaltung, weil es vieles komfortabler macht.
So kann ich z.B. von unterwegs aus mal nen Container neustarten falls nötig.
Ich finde es jetzt nicht zu groß.


Welche Container habt ihr eigentlich laufen?
Bei mir sieht es aktuell so aus (auf dem NAS):

• Portainer
• jellyfin
• rackpeek
• syncthing
• vaultwarden
• nextcloud

Meine Probleme mit der CalDav und CardDav Sync von Nextcloud hat mir wieder gezeigt, das ich NExtcloud besser meide.
Werde daher wieder auf radicale v3 für CalDav und CardDav umsteigen. Dieses Tool habe ich Jahre lang vor Nextcloud verwendet und es lief einfach immer stabil.
Das tolle ist einfach, das es alles in normalen Datein und Ordnern ablegt und keien Datenbank benötigt. Ich komme immer super easy an meine Daten, falls es mal über dne Jordan gehen sollte.

Da es jetzt auch einen Joplin Server für Docker gibt, brauche ich auch dafür die Nextcloud nicht mehr.
Im Grunde wechsle ich also zu einem KISS System, jedes Tool macht nur eine Sache und diese dafür richtig gut.

 

[Tundor]

Was gibt es da noch so?

Als UI nutze ich das von mir oben verlinkte getarcaneapp, hat alles was man braucht und ist dabei immer noch recht lean.
Da ich inzwischen einige Stacks habe und immer wieder gerne mal was ausprobiere hab ich für mich inzwischen ne andere Lösung die ich am meisten nutze. Hab nen Git Repo auf Forgejo (läuft auch als Container), da liegt der komplette stack drin mit allen compose files. Änderungen kann ich dann bequem lokal in vscode auf meinem Linux Desktop machen und wenn ich eine änderung pushe, hab ich einen forgejo worker auf truenas der ein deploy script ausführt, das dann entsprechen auf truenas den stack aus git aktualisiert und automatisch alle stacks die sich geändert haben neu deployed.

Welche Container habt ihr eigentlich laufen?

 

[Shihatsu]

Bei mir siehts privat so aus:

Beruflich halt so an die 100k... Erwähnte ich schondas Docker, Kubernetes und Rancher SCHEISSE skalieren? Nein? K, das Zeug skaliert scheisse

 

[toscdesign]

Hab aktuell das hier laufen:

Proxmox Host:

+ AdGuard LXC

NAS:



Nextcloud habe ich eben erfolgreich außer Betrieb genommen 💪

 

[toscdesign]

So, anstatt den Joplin Server einzurichten, denn der braucht wieder ne Datenbank
Habe ich jetzt kurzerhand rclone als webdav Server eingerichtet und synce Joplin damit.
Super klein, kompakt und ohne Datenbank. KISS Prinzip eben.

Ach schneller als das Webdav von Nextcloud ist es auch noch, sehr viel schneller.
So schnell hat Joplin noch nie synchronisiert, kompletter Sync in 10 Sekunden was bei nextcloud mehrere Minuten gedauert hat.

Spoiler: Compose

services:
  rclone-webdav:
    image: rclone/rclone:latest
    container_name: rclone-webdav
    user: "1000:1000"
    restart: unless-stopped
    ports:
      - "8181:8080"
    volumes:
      - /pfad/config:/config/rclone:ro    # Pfad zu Ihrer rclone.conf
      - /pfad/data:/data                  # Lokale Daten zum Freigeben
      - /pfad/cache:/temp/cache
    command:
      - "serve"
      - "webdav"
      - "remote:/"                    # Ersetzen Sie 'remote:' durch Ihren Namen in rclone.conf
      - "--addr=:8080"
      - "--user=benutzer"             # Ihr WebDAV-Benutzername
      - "--pass=passwort"             # Ihr WebDAV-Passwort
      - "--vfs-cache-mode=writes"     # Verbessert die Kompatibilität beim Schreiben
      - "--config=/config/rclone/rclone.conf" # Expliziter Pfad zur Config
      - "--cache-dir=/temp/cache"       # Pfad muss zum Volume-Mount passen
      - "--vfs-cache-max-age=24h"       # Räumt alte Cache-Dateien auf

Spoiler: rclone.conf

[remote]
type = alias
remote = /data

Hängt natürlich hinter meinem NPM Proxy und ist nur aus Heimnetz + VPN erreichbar

 

[Tundor]

Was findest du an einer DB so schlimm? Weil man die dann getrennt sichern muss? Joplin hatte ich auch mal getestet, die App fand ich furchtbar.

NPM Proxy und ist nur aus Heimnetz + VPN erreichbar

Zumindest im Heimnetzwerk ist dein Webdav aber nicht exklusiv hinter NPM, zumindest lt. deiner Config. Oder war das nur das Template.

ports:
- "8181:8080"

 

[toscdesign]

Was findest du an einer DB so schlimm?

In dem Fall unnötiger Bloat, da Joplin alles in Markdown Files speichert.

Joplin hatte ich auch mal getestet, die App fand ich furchtbar.

Finde die App klasse, nutze die schon lange.
Weiter Vorteil es wird in Markdown gespeichert, also kein proprietäres Format wie z.B. DSnote (Synology).

Zumindest im Heimnetzwerk ist dein Webdav aber nicht exklusiv hinter NPM, zumindest lt. deiner Config. Oder war das nur das Template.

Was meinst du damit?
Ich habe im NPM noch folgendes eingetragen:

location / {
    set $destination $http_destination;
    if ($destination ~* ^https(.+)$) {
         set $destination http$1;
    }
    proxy_set_header Destination $destination;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_pass http://XXX.XXX.XXX.XXX:8181;
    }

Edit:
Auch ganz interesant schon alleine der Größenunterschied der Docker Images, vom alten zum neuen Setup.
Vom RAM Verbrauch ganz zu schweigen.

Alt:


Neu:

 

[Tundor]

Was meinst du damit?

Wenn du

ports:
- "8181:8080"

einträgst heißt das, dass port 8080 via port 8181 von extern (also außerhalb vom Docker Netzwerk) erreichbar ist, d.h. NPM kann umgangen werden.

Wenn du in der compose nichts angibst, erstellt docker pro stack (also das ist ein compose file, wo ja mehrere services drin sein können) ein default netzwerk über das alle container/services intern sprechen können. Um von extern auf einen Port zuzugreifen, musst du dann mit ports mit dem Eintrag in der exposen.

D.h. wenn du z.B. jetzt rsync-webdav in einem stack hast und npm in nem anderen, brauchst du die Portfreigabe weiterhin so wie du sie angegeben hast, es kann dann aber nicht nur NPM drauf zugreifen, sondern auch jeder andere Client in deinem Netzwerk der auf den Host Zugriff hat indem er direkt den Port anspricht.

Lösen kann man das, indem man auf docker z.B. ein Netzwerk anlegt das sich npm und alle services die via NPM erreichbar sein sollen teilen und dann exposed du nur Port 443 für npm und npm hat dann intern zugriff auf 8080 von rsync. Dann kannst du alle anderen exposed Ports rausnehmen und dann ist wirklich nur noch NPM erreichbar. Wenn dich das interessiert, kann ich dir ein paar Beispiele hier posten wie du das machen kannst in der config, aber spar ich mir jetzt erstmal bevor ich mir hier die Finger wund tippe

Kannst auf jeden Fall mal mit

docker network list

checken welche Netzwerke dir Docker angelegt hat, da wirst du vermutlich sowas wie default_npm, default_rsync-webdav etc. sehen die er dir automatisch angelegt hat.

 

[toscdesign]

D.h. wenn du z.B. jetzt rsync-webdav in einem stack hast und npm in nem anderen, brauchst du die Portfreigabe weiterhin so wie du sie angegeben hast, es kann dann aber nicht nur NPM drauf zugreifen, sondern auch jeder andere Client in deinem Netzwerk der auf den Host Zugriff hat indem er direkt den Port anspricht.

NPM läuft auf einem anderen System.
Das die anderen Geräte (PC und Notebook) auf die IP direkt Zugriff haben ist gewollt.

Alle anderen Geräte sind durch eine Firewall davon getrennt und können nur den NPM erreichen.
Auch der VPN kann nur den NPM erreichen, auch hier durch Firewallregeln getrennt.

 

[Tundor]

NPM läuft auf einem anderen System.

Aber was macht das für einen Sinn? Du willst ja mit NPM eigentlich, dass der Netzwerktraffic verschlüsselt ist und wenn der auf einem anderen System ist ja nur der Teil von NPM zu deinem Client verschlüsselt während NPM zu deinem Docker Service offen ist 😅 Zumindest wenn es da um ne Anwendung geht die dann auf http oder anderen unverschlüsselten Kanälen läuft.
In jedem Fall ist dann in deinem Heimnetzwerk alles auf Docker direkt erreichbar, da ja dann jeweils die Ports exposed sind.

*edit*
Es sei denn natürlich es juckt dich nicht, dass das im Heimnetz unverschlüsselt ist, dann ist es egal. So hätte ich dich jetzt nur nicht eingeschätzt

 

[toscdesign]

Aber was macht das für einen Sinn?

Das ich mir keine IP Adressen mehr merken muss und von den Programmen/Apps kein gemecker "Verbindung nicht sicher" bekomme

In jedem Fall ist dann in deinem Heimnetzwerk alles auf Docker direkt erreichbar, da ja dann jeweils die Ports exposed sind.

Wie schon gesagt, der Rest vom Netz kommt da nicht ran, da hinter einer Firewall.

 

[Prankst3r]

Kurz zu NC und CalDAV, da muss man zwingend in Nnginx oder co die passenden Einträge machen, sonst geht das nicht

Spoiler: partial nginx für nc-aio

    ## nextcloud aio to cloud.hostname.tld
    server {
        listen 443 ssl;
        http2 on;
        ssl_certificate /etc/nginx/fullchain.pem;
        ssl_certificate_key /etc/nginx/privkey.pem;
        server_name cloud.sh3.kiwi;
        server_tokens off;
        resolver 127.0.0.11 valid=10s;
        resolver_timeout 5s;


        add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;" always;
        fastcgi_buffers 64 4K;
        client_body_buffer_size 512k;

        gzip on;
        gzip_vary on;
        gzip_comp_level 4;
        gzip_min_length 256;
        gzip_proxied expired no-cache no-store private no_last_modified no_etag auth;
        gzip_types application/atom+xml text/javascript application/javascript application/json application/ld+json application/manifest+json application/rss+xml application/vnd.geo+json application/vnd.ms-fontobject application/wasm application/x-font-ttf application/x-web-app-manifest+json application/xhtml+xml application/xml font/opentype image/bmp image/svg+xml image/x-icon text/cache-manifest text/css text/plain text/vcard text/vnd.rim.location.xloc text/vtt text/x-component text/x-cross-domain-policy;

        add_header Referrer-Policy "no-referrer" always;
        add_header X-Content-Type-Options "nosniff" always;
        add_header X-Frame-Options "SAMEORIGIN" always;
        add_header X-Permitted-Cross-Domain-Policies "none" always;
        add_header X-Robots-Tag "noindex, nofollow" always;
        add_header X-XSS-Protection "1; mode=block" always;

        fastcgi_hide_header X-Powered-By;
        proxy_read_timeout 86400s;
        client_max_body_size 0;
        client_body_timeout 86400s;

        include mime.types;
        types {
            text/javascript mjs;
        }

        location / {
        set $nc_aio_apache_hn nextcloud-aio-apache;
            proxy_pass http://$nc_aio_apache_hn:11000;
            proxy_redirect off;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Host $server_name;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection $http_connection;
            proxy_http_version 1.1;

            rewrite ^/\.well-known/carddav https://$server_name/remote.php/dav/ redirect;
            rewrite ^/\.well-known/caldav https://$server_name/remote.php/dav/ redirect;
            rewrite ^/\.well-known/webfinger https://$server_name/index.php/.well-known/webfinger redirect;
            rewrite ^/\.well-known/nodeinfo https://$server_name/index.php/.well-known/nodeinfo redirect;
                # Websocket
#            proxy_http_version 1.1;
#            proxy_set_header Upgrade $http_upgrade;
#            proxy_set_header Connection $connection_upgrade;
        }
    }

    ### nc_aio_admin
    server {
        listen 443 ssl;
        server_name nc-admin.sh3.kiwi;

        ssl_certificate /etc/nginx/fullchain.pem;
        ssl_certificate_key /etc/nginx/privkey.pem;

        location / {
            proxy_pass https://nextcloud-aio-mastercontainer:8080;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
        }
    }

also die rewrite Rules werden dir fehlen, afaik zeigt das aber auch deine NC Logdatei an, dass das fehlt, wenn ich mich richtig erinnere.
in NPM, was gut und auch bescheiden ist. Gut weil man einfach nginx einrichten kann, bescheiden, weil gerade sowas wie oben schwer wird. Zum rumspielen ists aber ne feine Sache, hab das auch ne Zeit lang benutzt bzw nutze ich es auch noch bei Leuten, die nicht viel mit Linux am Hut haben, genauso wie Portainer.
Bei dem Setup nutze ich auch self-signed Certs mit nem eigenen CA, da hinterlege ich auf allen Geräten dann das CA cert.

Aber radicale ist auch gut, habe ich vor NC dafür benutzt.

 

[toscdesign]

Kurz zu NC und CalDAV, da muss man zwingend in Nnginx oder co die passenden Einträge machen, sonst geht das nicht

Ich nutze kein NC mehr, alle Einträge waren aber drin wie von Nextcloud vorgegeben.
Hat ja auch funktioniert.

Bei dem Setup nutze ich auch self-signed Certs mit nem eigenen CA, da hinterlege ich auf allen Geräten dann das CA cert.

Ich habe ne .de Domain über Netcup.de (Aktion 0,18€ im Jahr) und das Zertifikat kommt per Lets Encrypt und DNS Challange als Wildcard Zertifikat *.domain.de

Aber radicale ist auch gut, habe ich vor NC dafür benutzt.

Hatte es vor NC, musste dann auf NC umsteigen, da es bei TrueNAS Scale rausgeflogen war. Bin jetzt dank Debian mit ZNAS wieder bei radicale.

 

[spyfly]

Womit verwaltet ihr eure Container? Alles über die cli?

docker compose und autoupdates via watchtower: https://watchtower.nickfedor.com

In den ganzen GUI Tools wie Portainer, Dockploy und wie sie alle heißen sehe ich keinen Mehrwert.

Erwähnte ich schondas Docker, Kubernetes und Rancher SCHEISSE skalieren? Nein? K, das Zeug skaliert scheisse

Wenn man nicht weiß wie es geht skaliert es auch nicht. Natürlich kann man seine Services auch in LXC Containern laufen lassen, aber was ist da mit Anwendungs und System-Updates? Und viele Anwendungen laufen in LXC erfahrungsgemäß ziemlich bescheiden.

Ich hab im Homelab so ziemlich alles in Docker Containern am laufen, je nach Anforderung auf CoreOS oder Ubuntu VMs (bei GPU Passthrough), bis auf den Proxmox VE Hypervisor muss ich nichts mehr manuell updaten.