Migration Nextcloud FPM Image zu LinuxServerIO

Vorbereitung

Zusätzlich empfiehlt es sich, Nextcloud auf die gleiche Version des LSIO-Images zu bringen. Ermitteln kann man die aktuelle Version mit Auslesen der version.php.

Beispiel:

grep OC_VersionString /srv/docker/nextcloud.old/html/version.php
$OC_VersionString = '28.0.2';

Passt die Version nicht, sollte vorher ein Update gemacht werden. Grundsätzlich unterstützt das LSIO Image ein Upgrade, aber weil es sich um eine “Neuinstallation” mit Migration handelt, kann es hier zu Problemen kommen…

Docker Compose

Aufgrund der vereinfachten Struktur des LinuxServer.IO Images kann das Docker Compose File leicht aufgebaut werden und die Daten hinein migriert werden.
Sollten eigene Pfade oder Anpassungen vorgenommen worden sein (zusätzliche Mounts, Konfigurationsdateien) müssen diese entweder hinein kopiert werden, oder wieder gemountet werden.
Das custom_apps Verzeichnis, welches für installierte Apps genutzt wird, dient uns hier als Vorlage…

version: '3'

services:
  nextcloud:
    image: lscr.io/linuxserver/nextcloud:28.0.2
    container_name: nextcloud_app
    environment:
      PUID: 1000
      PGID: 1000
      TZ: "Etc/UTC"
    volumes:
      - /srv/docker/nextcloud/config/:/config
      - /srv/docker/nextcloud/data:/data
      # zusätzlicher Mountpunkt für Apps die vom Standardset abweichen
      - /srv/docker/nextcloud/custom/custom_apps:/app/www/public/custom_apps
    restart: unless-stopped
    networks:
      default:
        ipv4_address: 10.11.12.254

networks:
  default:
    driver: bridge
    ipam:
      driver: default
      config:
        - subnet: 10.11.12.0/24
    driver_opts:
      com.docker.network.bridge.name: br_nextcloud

Danach kann der Container erstmalig gestartet werden, damit die Verzeichnisse angelegt werden.
Hierbei werden Einrichtungen erledigt wie:

• Log Ordner
• Nextcloud SSL Zertifikate (Container spricht HTTPS)
• Nextcloud Verzeichnisstruktur
• Config Files

Nachdem der Container gestartet wurde, kann dieser wieder gestoppt werden, damit wir die Daten migrieren können.

Migration

Config

cp /srv/docker/nextcloud.old/html/config/config.php /srv/docker/nextcloud/config/www/nextcloud/config/config.php

Danach müssen noch Anpassungen vorgenommen werden:

$CONFIG = array (
  'maintenance_window_start' => 1,
  array (
    0 =>
    // Standardpfad fuer Apps, readonly
    array (
      'path' => '/app/www/public/apps',
      'url' => '/apps',
      'writable' => false,
    ),
    // custom_apps vom Zusatzmountpoint, schreibbar
    1 =>
    array (
      'path' => '/app/www/public/custom_apps',
      'url' => '/custom_apps',
      'writable' => true,
    ),
  ),

Eventuell ist es auch nötig aus den anderen Configfiles Inhalte zu übernehmen, weil das Nextcloud Image zusätzliche Dateien anbietet und Werte aus dem Environment zieht:

• apcu.config.php
• apps.config.php
• autoconfig.php
• config.php
• redis.config.php
• reverse-proxy.config.php
• s3.config.php
• smtp.config.php
• swift.config.php
• test.config.php

Hier hängt es stark von deiner Konfiguration ab, ob zusätzliche Einstellungen in der config.php hinterlegt werden müssen.
Am besten im docker-compose.yml die Variablen mit den Dateien abgleichen, falls Environment-Variablen genutzt wurden…

Datenmigration

Hier werden die Dateien übernommen, es bietet sich an die original Cloud herunterzufahren, damit keine Änderungen geschrieben werden.
Auch hier gilt, sind weitere Ordner nötig, müssen diese auch synchronisiert werden.

rsync -aH /srv/docker/nextcloud.old/html/data/ /srv/docker/nextcloud/data/
rsync -aH /srv/docker/nextcloud.old/html/custom_apps/ /srv/docker/nextcloud/custom/custom_apps/
chown -R 1000:1000 /srv/docker/nextcloud/data/ /srv/docker/nextcloud/custom/custom_apps/

Nginx Config

Die Konfiguration eines Proxies gestaltet sich im Vergleich zum FPM Image nun deutlich einfacher

server {
  ...
  ...
  ...

  location / {
    # man beachte das https://, denn der Container spricht selbst HTTPS
    # nutzt man hier http://, wird die Cloud dies beim selfcheck bemängeln...
    proxy_pass https://10.11.12.254:443;
    proxy_http_version 1.1;

    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-Host $host;

    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "Upgrade";
  }

Gibt es beim Reload einen Fehler beim $http_upgrade, fehlt vermutlich die Map dafür.
Diese kann einfach in der nginx.conf hinterlegt werden:

  http {
    ...
    ...
    ...
      
    map $http_upgrade $connection_upgrade {
        default upgrade;
        ''      close;
    }

    ...
    ...
    ...
  }

Post Migration

• Eventuell konfigurierte Cronjobs können nun entfernt werden, weil der Docker Container einen eigenen Cronjob beinhaltet.
• Zertifikate der Cloud können migriert werden, sind aber kein muss, falls die Nextcloud sich selbst über den Reverse-Proxy (mit offiziellem Zertifikat) erreichen
• Indicies fixen

Zertifikate importieren

docker exec -ti -u 1000 -w /app/www/public nextcloud_app php occ security:certificates
docker exec -ti -u 1000 -w /app/www/public nextcloud_app php occ security:certificates:import /config/keys/cert.crt
docker exec -ti -u 1000 -w /app/www/public nextcloud_app php occ security:certificates

Indicies anlegen

docker exec -ti -u 1000 -w /app/www/public nextcloud_app php occ db:add-missing-indices

OCC Skript korrigieren

Solltest du ein occ Script als Wrapper für Nextcloud verwenden, können Anpassungen nötig sein, weil eine andere User-ID verwendet wird.
Einfach in die Datei /usr/local/sbin/occ packen:

#!/bin/bash
docker exec -ti -u 1000 -w /app/www/public nextcloud_app php occ $*

Danach die Berechtigung fixen

chmod 700 /usr/local/sbin/occ