SSD Nodes Learn Hosting plans →
கல்வி வழிகாட்டிகள் Matt Connorஆல் Matt Connor · புதுப்பிக்கப்பட்டது 2026-10-07

VPS-ல் Docker மூலம் Nextcloud நிறுவுவது எப்படி?

Docker Compose, Postgres மற்றும் Redis பயன்படுத்தி உங்கள் VPS-ல் Nextcloud-ஐ நிறுவும் முறை. TLS reverse proxy அமைப்புடன், தரவு பாதுகாப்பு மற்றும் மேம்படுத்தல் வழிமுறைகள்.

நீங்கள் உண்மையில் உருவாக்குவது என்ன

இந்த அமைப்பில், நீங்கள் ஒரு reverse proxy-ஐ உங்கள் server-ன் நுழைவாயிலாக (gateway) நிறுவுகிறீர்கள். இது வெளிப்புறத்திலிருந்து வரும் அனைத்து HTTP/HTTPS traffic-ஐயும் பெற்று, அவற்றை உள்நாட்டில் இயங்கும் குறிப்பிட்ட application-களுக்கு வழிநடத்துகிறது (routing).

இதன் மூலம் நீங்கள் பின்வருவனவற்றைச் செய்கிறீர்கள்:

  • Centralized TLS Termination: SSL/TLS certificates-ஐ ஒவ்வொரு application-லும் தனித்தனியாக நிர்வகிப்பதற்குப் பதிலாக, proxy மட்டத்திலேயே கையாளுகிறீர்கள்.
  • Subdomain Routing: app1.example.com மற்றும் app2.example.com போன்ற கோரிக்கைகளை, அவற்றின் Host header-ஐப் பொறுத்து சரியான backend service-க்கு அனுப்புகிறீர்கள்.
  • Security Layer: உங்கள் application-களை நேரடியாக public internet-க்கு வெளிப்படுத்தாமல், proxy மூலம் பாதுகாப்பான முறையில் அணுக வழிவகை செய்கிறீர்கள்.
  • Simplified Management: Rate limiting, logging, மற்றும் authentication போன்ற பொதுவான பணிகளை ஒரே இடத்தில் ஒருங்கிணைக்கிறீர்கள்.

இது உங்கள் server-ன் கட்டமைப்பை modular-ஆக மாற்றுகிறது; இதனால் ஒரு application-ல் மாற்றம் செய்யும்போதோ அல்லது அதை restart செய்யும்போதோ மற்ற சேவைகள் பாதிக்கப்படுவதில்லை.

Nextcloud மற்றும் Docker Compose மூலம் VPS-ல் நிறுவுதல்

இந்த வழிகாட்டி Docker Compose மூலம் ஒரு VPS-ல் Nextcloud-ஐ இயக்குவது, அதன் முன்னால் Let's Encrypt TLS-ஐ அமைப்பது மற்றும் மீட்டெடுக்கக்கூடிய வகையில் backup எடுப்பது ஆகியவற்றை விளக்குகிறது. இதில் நான்கு containers மற்றும் ஒரு proxy உள்ளன: loopback-ல் இயங்கும் அதிகாரப்பூர்வ nextcloud image, கோப்பு மெட்டாடேட்டாவைச் சேமிக்கும் Postgres, கோப்பு பூட்டுகளை (file locks) பராமரிக்கும் Redis, cron loop-ஐ மட்டும் இயக்கும் இரண்டாவது Nextcloud image, மற்றும் இவை அனைத்திற்கும் முன்னால் TLS-ஐ முடிவுக்குக் கொண்டுவரும் (terminating) host-ல் உள்ள nginx. நிறுவல் பணி இருபது நிமிடங்களில் முடிந்துவிடும், ஆனால் அது முக்கியமல்ல. முதல் ஒரு மணி நேரத்தில் எடுக்கப்படும் இரண்டு முடிவுகளே, ஒரு வருடம் கழித்தும் உங்கள் கோப்புகள் பாதுகாப்பாக இருப்பதை உறுதி செய்யும்: SQLite-க்கு பதிலாக ஒரு உண்மையான database-ஐப் பயன்படுத்துவது மற்றும் data directory, database, மற்றும் config.php ஆகியவற்றை ஒரே சீரான தொகுப்பாகக் காக்கும் backup முறையை அமைப்பது.

கட்டமைப்பு மற்றும் தேவைகள்

இந்த அமைப்பில் உள்ள ஒவ்வொரு பகுதியும் ஒரு குறிப்பிட்ட நோக்கத்திற்காகச் செயல்படுகிறது.

  • nextcloud: முதன்மை application container.
  • Postgres: கோப்பு மெட்டாடேட்டாவிற்கான நம்பகமான database.
  • Redis: கோப்பு பூட்டுகளை நிர்வகிப்பதற்கான cache.
  • Cron container: பின்னணியில் இயங்கும் பணிகளை (background tasks) கையாளும்.
  • Nginx: TLS termination மற்றும் reverse proxy-ஆகச் செயல்படும்.

தரவு பாதுகாப்பு மற்றும் backup

தரவு இழப்பைத் தவிர்க்க, பின்வரும் மூன்று கூறுகளை ஒரே நேரத்தில் backup எடுப்பது அவசியம்:

  1. Data directory: உங்கள் கோப்புகள் சேமிக்கப்படும் இடம்.
  2. Database: கோப்புகளின் மெட்டாடேட்டா மற்றும் பயனர் தகவல்கள்.
  3. config.php: configuration கோப்புகள் மற்றும் முக்கிய அமைப்புகள்.

இவை மூன்றையும் ஒரே நேரத்தில் backup எடுத்தால் மட்டுமே, மீட்டெடுக்கும்போது (restore) தரவு முரண்பாடுகள் (inconsistencies) ஏற்படாது.

FAQ

SQLite-க்கு பதிலாக ஏன் Postgres-ஐப் பயன்படுத்த வேண்டும்?

SQLite சிறிய பயன்பாடுகளுக்கு மட்டுமே ஏற்றது. Nextcloud போன்ற அதிக கோப்புகளைக் கையாளும் சூழலில், Postgres அதிக செயல்திறனையும், தரவு ஒருமைப்பாட்டையும் (data integrity) வழங்குகிறது.

ஏன் தனித்தனி cron container தேவை?

Nextcloud-ன் பின்னணிப் பணிகளை (background jobs) திறம்படச் செய்ய, பிரத்யேகமான cron process தேவை. இது முதன்மை container-ன் சுமையைக் குறைத்து, பணிகளைச் சீராக இயங்க வைக்கிறது.

TLS termination-ஐ ஏன் nginx மூலம் செய்ய வேண்டும்?

Nginx மூலம் TLS-ஐக் கையாள்வது, அனைத்து சேவைகளுக்கும் ஒரே இடத்தில் சான்றிதழ்களை (certificates) நிர்வகிக்க உதவுகிறது. இது பாதுகாப்பு மற்றும் பராமரிப்பை எளிதாக்குகிறது.

###
முன்நிபந்தனைகள்

இந்த வழிகாட்டி Ubuntu 24.04 LTS அல்லது Debian 13 இயங்குதளங்களையும், Docker-ன் அதிகாரப்பூர்வ களஞ்சியத்திலிருந்து (repository) நிறுவப்பட்ட Docker Engine மற்றும் Compose v2 plugin-ஐயும் அடிப்படையாகக் கொண்டது. உங்கள் VPS-ன் IP முகவரிக்கு ஏற்கனவே ஒரு DNS A பதிவு (மற்றும் IPv6 வசதி இருந்தால் AAAA பதிவு) cloud.example.com எனச் சுட்டிக்காட்டப்பட்டிருக்க வேண்டும். இதற்கு நீங்கள் முழுமையான கட்டுப்பாட்டைக் கொண்ட ஒரு server தேவை; பிறரது SaaS தளங்களில் TLS termination மற்றும் database dump போன்ற பணிகளைச் செய்ய முடியாது.

அளவு நிர்ணயம்: நினைவகத்தை உண்மையில் பயன்படுத்துவது எது

Nextcloud-ன் நினைவகப் பயன்பாடு முக்கியமாக மூன்று விஷயங்களால் தீர்மானிக்கப்படுகிறது, இதில் எதுவுமே "Nextcloud" என்று நேரடியாகக் குறிப்பிட முடியாது.

PHP workers. -apache image, ஒவ்வொரு ஒரேநேர கோரிக்கையையும் (concurrent request) ஒரு PHP interpreter-ஐக் கொண்ட worker process மூலம் கையாளுகிறது. PHP கோரிக்கையை முடிப்பதற்கு முன்பு, ஒவ்வொரு worker-ம் PHP_MEMORY_LIMIT அளவு வரை வளரக்கூடும். உங்கள் worst-case resident memory என்பது தோராயமாக ஒரேநேர கோரிக்கைகள் × நினைவக வரம்பு ஆகும்; ஒரு desktop sync client ஒவ்வொரு பயனருக்கும் பல parallel connections-ஐத் திறக்கும். பயனர்களின் எண்ணிக்கை அல்ல, ஒரேநேர கோரிக்கைகளின் எண்ணிக்கையே (concurrency) நினைவக உச்ச வரம்பைத் தீர்மானிக்கிறது.

தரவுத்தளம் (Database). Postgres ஒவ்வொரு இணைப்புக்கும் ஒரு backend-ஐ உருவாக்கி, shared buffers-ஐ நினைவகத்தில் வைத்திருக்கும். இதன் working set, கோப்புகளின் அளவை விட கோப்புகளின் எண்ணிக்கையைப் பொறுத்தே அமையும்: oc_filecache ஒவ்வொரு பயனர் மற்றும் கோப்புக்கும் ஒரு row-ஐக் கொண்டிருக்கும். நூறாயிரம் சிறிய கோப்புகள், நூறு பெரிய கோப்புகளை விட அதிக தரவுத்தளச் சுமையை ஏற்படுத்தும்.

Preview generation. ஒரு thumbnail-ஐ உருவாக்கும்போது, மூலப் படத்தை முழுத் தெளிவுத்திறனில் (full resolution) நினைவகத்திற்கு decode செய்யும். Video previews-ஐ உருவாக்க ffmpeg பயன்படுத்தப்படுகிறது. occ preview:generate-all-ஐ இயக்குவது இந்தச் சுமையை மீண்டும் மீண்டும் ஏற்படுத்தும்; இதுவே ஒரு சிறிய VPS-ஐ OOM killer மூலம் செயலிழக்கச் செய்யும் பொதுவான வழியாகும்.

Redis ஒப்பீட்டளவில் குறைந்த நினைவகத்தையே பயன்படுத்தும். நீங்கள் பின்னர் சேர்க்கும் Collabora, full-text search, antivirus scanner போன்ற எவையும் தனித்தனி resident services ஆகும்; இவை ஒவ்வொன்றுக்கும் தனித்தனி நினைவகத் தேவை உண்டு. எனவே, இவற்றை இயக்குவதற்கு முன்பே உங்கள் அளவு நிர்ணயத் திட்டத்தில் சேர்த்துக்கொள்ள வேண்டும்.

உங்களிடம் RAM குறைவாக இருந்தால், இந்த மாற்றங்களைச் செய்யவும்: PHP_MEMORY_LIMIT-ஐக் குறைக்கவும், preview_max_x / preview_max_y / preview_max_filesize_image ஆகியவற்றிற்கு வரம்பு விதிக்கவும், enabledPreviewProviders-ஐ நீங்கள் உண்மையில் பயன்படுத்தும் வடிவங்களுக்கு மட்டும் சுருக்கவும், மேலும் trashbin_retention_obligation மற்றும் versions_retention_obligation ஆகியவற்றை அமைக்கவும், இதனால் தரவு அடைவு (data directory) உங்கள் கோப்புகளின் அளவை விட பல மடங்கு தானாக வளராது. ஒரு swap file-ஐச் சேர்க்கவும். Swap மெதுவானதுதான், ஆனால் upgrade செய்யும்போது OOM kill ஏற்படுவது அதைவிட மோசமானது.

SQLite ஏன் செயலிழக்கிறது

Nextcloud-ல் SQLite ஆதரவு உள்ளது, அதன் அதிகாரப்பூர்வ image-ம் அதை இயல்பாகவே பயன்படுத்தும். ஆனால், அதைத் தவிர்க்கவும். SQLite தரவுத்தளத்தில் எழுதும் பணிகளை (writes) ஒரு முழுமையான பூட்டு (database-wide lock) மூலம் வரிசைப்படுத்துகிறது: ஒரே நேரத்தில் ஒரு கோப்பில் ஒரு செயல்முறை மட்டுமே எழுத முடியும். Nextcloud தொடர்ந்து தரவுகளை எழுதிக்கொண்டே இருக்கும்; கோப்பு பூட்டுகள் (file locks), செயல்பாட்டு வரிசைகள் (activity rows), cache பதிவுகள், மற்றும் job நிலைகள் எனப் பல பணிகள் நடக்கும். ஒரு desktop client கோப்புத் தொகுப்பை ஒத்திசைக்கும்போது (syncing), அது ஒரே நேரத்தில் பல கோரிக்கைகளை (parallel requests) அனுப்பும். இந்தச் சூழலில் உங்களுக்கு SQLSTATE[HY000]: General error: 5 database is locked பிழையும் HTTP 500 பிழைகளும் ஏற்படும். உங்கள் instance பயனுள்ள நிலையை அடையும்போதுதான் இந்தத் தோல்வி துல்லியமாக நிகழும்.

பிற்காலத்தில் occ db:convert-type மூலம் தரவுத்தளத்தை மாற்ற முடியும், ஆனால் இது நேரலையில் உள்ள தரவுத்தொகுப்பில் (live dataset) செய்யப்படும் நீண்ட மற்றும் முழுமையான மாற்றமாகும். எனவே, தொடக்கத்திலிருந்தே Postgres அல்லது MariaDB-ஐப் பயன்படுத்தவும்.

Compose கோப்பு

இதை /srv/nextcloud/compose.yaml-ல் வைக்கவும், secrets-ஐ அதன் அருகிலுள்ள .env கோப்பில் 600 பயன்முறையில் (mode) சேமிக்கவும்.

services:
  db:
    image: postgres:16-alpine
    restart: unless-stopped
    volumes:
      - db:/var/lib/postgresql/data
    environment:
      POSTGRES_DB: nextcloud
      POSTGRES_USER: nextcloud
      POSTGRES_PASSWORD: ${DB_PASSWORD}

  redis:
    image: redis:7-alpine
    restart: unless-stopped
    command: redis-server --requirepass ${REDIS_PASSWORD}

  app:
    image: nextcloud:31-apache
    restart: unless-stopped
    depends_on: [db, redis]
    ports:
      - "127.0.0.1:8080:80"
    volumes:
      - html:/var/www/html
      - /srv/nextcloud/data:/var/www/html/data
    environment:
      POSTGRES_HOST: db
      POSTGRES_DB: nextcloud
      POSTGRES_USER: nextcloud
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      REDIS_HOST: redis
      REDIS_HOST_PASSWORD: ${REDIS_PASSWORD}
      NEXTCLOUD_ADMIN_USER: admin
      NEXTCLOUD_ADMIN_PASSWORD: ${ADMIN_PASSWORD}
      NEXTCLOUD_TRUSTED_DOMAINS: cloud.example.com
      TRUSTED_PROXIES: 172.16.0.0/12
      OVERWRITEPROTOCOL: https
      OVERWRITECLIURL: https://cloud.example.com
      APACHE_DISABLE_REWRITE_IP: "1"
      PHP_MEMORY_LIMIT: 512M
      PHP_UPLOAD_LIMIT: 10G

  cron:
    image: nextcloud:31-apache
    restart: unless-stopped
    entrypoint: /cron.sh
    depends_on: [db, redis]
    volumes:
      - html:/var/www/html
      - /srv/nextcloud/data:/var/www/html/data

volumes:
  db:
  html:

Major tag-ஐ pin செய்யவும். 31-ஐ அப்படியே நகலெடுக்கும் முன் Docker Hub-ல் தற்போதைய பதிப்பைச் சரிபார்க்கவும். latest எதிர்காலத்தில் ஏதேனும் ஒரு docker compose pull-ல் உங்களை major பதிப்பு எல்லைக்கு அப்பால் கொண்டு சென்றுவிடும், அதை Nextcloud ஆதரிக்காது.

தரவு அடைவு (data directory) ஒரு bind mount ஆகும், இது named volume அல்ல; இதற்குக் காரணம், ஒரு backup கருவியை நேரடியாகச் சுட்டிக்காட்டக்கூடிய ஒரு path, நேர்த்தியை விட முக்கியமானது. இதை image-ன் www-data UID மற்றும் Nextcloud கோரும் அனுமதிகளுடன் (permissions) உருவாக்கவும்:

sudo mkdir -p /srv/nextcloud/data
sudo chown -R 33:33 /srv/nextcloud/data
sudo chmod 0770 /srv/nextcloud/data

Port publish செய்வதைக் கவனிக்கவும்: 127.0.0.1:8080:80. Docker, DNAT விதிகளை எழுதுவதன் மூலம் ports-ஐ வெளியிடுகிறது; இவை ufw-ன் INPUT chain பாக்கெட்டைப் பார்ப்பதற்கு முன்பே மதிப்பீடு செய்யப்படுகின்றன. எனவே, வெறும் 8080:80 என்பது ufw என்ன சொன்னாலும், குறியாக்கம் செய்யப்படாத Nextcloud-ஐ பொது இணையத்தில் (public internet) விட்டுவிடும். Loopback-ல் bind செய்வதன் மூலம் அதை பொது இடைமுகத்திலிருந்து (public interface) விலக்கி வைக்கலாம். அதன் பிறகு, firewall proxy-ஐ மட்டும் அனுமதித்தால் போதும். ஒருவேளை நீங்கள் SSH-ஐ முழு இணையத்திற்கும் திறந்து வைக்க விரும்பவில்லை என்றால், சுயமாக ஹோஸ்ட் செய்யப்பட்ட WireGuard VPN மூலம் VPS-ஐ அணுகுவது, port 22-ஐ பொது விதிகளிலிருந்து முழுமையாக நீக்க உங்களை அனுமதிக்கும்:

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

docker compose up -d மூலம் அதைத் தொடங்கவும், பிறகு docker compose logs -f app-ஐக் கவனிக்கவும். முதல் boot-ன் போது முழு application tree-யும் volume-க்குள் நகலெடுக்கப்பட்டு installer இயங்கும்; அது முடியும் வரை container எந்தப் பதிலையும் தராது.

TLS மற்றும் reverse proxy

Distro-விலிருந்து nginx மற்றும் certbot ஆகியவற்றை நிறுவி, சரியான server_name உடன் ஒரு plain port-80 server block-ஐ உருவாக்கவும்; பின்னர் certbot-ஐக் கொண்டு அதை rewrite செய்யவும். HTTP-01 challenge-ன் செயல்பாடுகள், renewal timer மற்றும் தோல்விக்கான காரணங்கள் அனைத்தும் Ubuntu 24.04-ல் certbot மற்றும் nginx மூலம் Let's Encrypt certificates வழங்குதல் என்ற பகுதியில் முழுமையாக விளக்கப்பட்டுள்ளன:

sudo apt install nginx certbot python3-certbot-nginx
sudo certbot --nginx -d cloud.example.com

Certbot, ssl_certificate வரிகளையும் :80 → :443 redirect-ஐயும் சேர்க்கிறது. மேலும், 90 நாட்கள் செல்லுபடியாகும் certificate-ஐப் புதுப்பிக்கும் systemd timer-ஐயும் நிறுவுகிறது. இது இருப்பதை systemctl list-timers | grep certbot மூலம் உறுதிப்படுத்தவும்; ஒரு renewal timer-ஐ enable செய்யத் தவறினால், அது 90 நாட்களுக்குப் பிறகு காலாவதியாகும் ஒரு வெடிகுண்டாக மாறிவிடும்.

Proxy block-ன் அமைப்பு:

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name cloud.example.com;

    # certbot manages ssl_certificate / ssl_certificate_key here

    add_header Strict-Transport-Security "max-age=15552000; includeSubDomains" always;

    client_max_body_size 10G;
    client_body_timeout 300s;

    location = /.well-known/carddav { return 301 /remote.php/dav; }
    location = /.well-known/caldav  { return 301 /remote.php/dav; }

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_http_version 1.1;
        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;
        proxy_set_header X-Forwarded-Host  $host;
        proxy_request_buffering off;
        proxy_buffering off;
        proxy_read_timeout 3600s;
        proxy_send_timeout 3600s;
    }
}

Nginx 1.25 மற்றும் அதற்குப் பிந்தைய பதிப்புகளில், http2 on;-ஐச் சேர்க்கவும். Ubuntu 24.04-ல் உள்ள பழைய build-ல் இதற்கு இணையான கட்டளை listen 443 ssl http2; ஆகும். உங்கள் build எதை ஏற்கும் என்பதை nginx -t மூலம் கண்டறியலாம்.

client_max_body_size மற்றும் நீண்ட read timeouts ஆகியவை பெரிய கோப்புகளைப் பதிவேற்றும்போது அவை பாதியிலேயே துண்டிக்கப்படுவதைத் தடுக்கின்றன. proxy_request_buffering off, கோப்பு முழுவதையும் முதலில் proxy-ன் disk-ல் சேமிக்காமல், பதிவேற்றத்தை நேரடியாக stream செய்கிறது.

ஒரே ஒரு application-க்கு, host-ல் இயங்கும் nginx மிக எளிமையான தீர்வாகும். Nextcloud-ஐ மற்ற containers-உடன் சேர்த்து ஒரு VPS-ல் இயக்கப்போகிறீர்கள் என்றால், பல applications-க்கு Docker Compose reverse proxy-ஆக Traefik-ஐ இயக்குதல் என்ற முறை, routing மற்றும் certificate வழங்குதல் ஆகியவற்றை container labels-க்கு மாற்றும். அதே client_max_body_size மற்றும் timeout தொடர்பான கவலைகள் அங்கும் middleware மற்றும் transport அமைப்புகளாக மீண்டும் தோன்றும்.

trusted_proxies மற்றும் overwriteprotocol

பெரும்பாலான self-hosted Nextcloud instances-களில் தவறுகள் நடக்கும் இடம் இதுதான். இதன் அறிகுறிகள், உண்மையான காரணத்துடன் தொடர்பில்லாதது போலத் தோன்றும்.

X-Forwarded-Proto: https என்பது, trusted_proxies-ல் பட்டியலிடப்பட்டுள்ள முகவரியிலிருந்து கோரிக்கை (request) வரும்போது மட்டுமே ஏற்றுக்கொள்ளப்படும். இது ஏற்றுக்கொள்ளப்படாதபோது, அந்த கோரிக்கை plain HTTP என்று Nextcloud கருதி, http:// URL-களை வெளியிடும்; proxy அவற்றை HTTPS-க்கு திருப்பிவிடும் (redirect); browser அதைப் பின்பற்றும்; Nextcloud மீண்டும் http://-ஐ வெளியிடும். இதுவே redirect loop ஆகும். OVERWRITEPROTOCOL: https என்பது, எவ்வித சூழலிலும் scheme-ஐ அப்படியே நிலைநிறுத்தும்.

TRUSTED_PROXIES-ல் உள்ள சிக்கல் என்னவென்றால், Nextcloud பார்க்கும் முகவரி 127.0.0.1 அல்ல. nginx host-ல் இயங்கி, வெளியிடப்பட்ட port-உடன் இணைவதால், container-ஆனது Docker bridge gateway-ஐப் பார்க்கும், இது 172.x-ல் உள்ள ஒன்றாக இருக்கும். உண்மையான subnet-ஐக் கண்டறியவும்:

docker network inspect nextcloud_default \
  -f '{{range .IPAM.Config}}{{.Subnet}}{{end}}'

அந்த CIDR-ஐ (அல்லது அதை உள்ளடக்கிய 172.16.0.0/12-ஐ) TRUSTED_PROXIES-ல் உள்ளிடவும். இதை மிக விரிவாக அமைத்தால், எந்தவொரு client-ம் X-Forwarded-For-ஐ spoof செய்யக்கூடும்; தவறாக அமைத்தால், ஒவ்வொரு login-ம் gateway முகவரியிலிருந்து வருவது போலத் தோன்றும், brute-force protection உங்கள் முழு instance-ஐயும் ஒரே நேரத்தில் முடக்கிவிடும், மேலும் admin overview-ல் "The reverse proxy header configuration is incorrect, or you are accessing Nextcloud from a trusted proxy." என்ற எச்சரிக்கை தோன்றும்.

OVERWRITECLIURL என்பது cron container-க்கு முக்கியமானது, ஏனெனில் hostname-ஐ ஊகிப்பதற்கு அங்கு உள்வரும் கோரிக்கைகள் (incoming requests) எதுவும் இல்லை. இது இல்லையெனில், background jobs localhost-க்கான இணைப்புகளை உருவாக்கும் மற்றும் மின்னஞ்சல் அறிவிப்புகள் பயன்படுத்த முடியாத URL-களை அனுப்பும்.

பின்னணிப் பணிகள்: cron, AJAX அல்ல

Nextcloud-ன் இயல்புநிலை job runner என்பது AJAX ஆகும்: ஒரு பயனர் பக்கத்தை ஏற்றும்போது மட்டுமே பணிகள் பின்னணியில் இயங்கும். அதிகாலை 04:00 மணிக்கு யாரும் இணையதளத்தைப் பயன்படுத்துவதில்லை என்பதால், குப்பை நீக்கம் (trash expiry), கோப்புப் பதிப்பு நீக்கம் (versions cleanup), முன்னோட்டங்கள் (previews) மற்றும் federated retries போன்றவை தேங்கிவிடும். இதன் முதல் அறிகுறி, தரவு அடைவு (data directory) தொடர்ந்து வளர்ந்துகொண்டே இருப்பதுதான். மேலே உள்ள cron சேவை, அதே volumes-ல் அதிகாரப்பூர்வ /cron.sh சுழற்சியை இயக்குகிறது. இதை Nextcloud-க்குத் தெரிவிக்கவும்:

docker compose exec -u www-data app php occ background:cron

ஒவ்வொரு occ கட்டளையும் இந்த அமைப்பைப் பின்பற்றுகிறது: docker compose exec -u www-data app php occ <command>. இதற்கு alias அமைப்பது பயனுள்ளது.

காப்புப்பிரதிகள்: மூன்று விஷயங்கள், அல்லது எதுவுமில்லை

கோப்பு முறைமை (filesystem) சார்ந்த காப்புப்பிரதி மட்டுமே இருந்தால், அது பழுதடைந்த instance-ஐ மீட்டமைக்காது. தரவு அடைவு (data directory) பைட்டுகளைக் கொண்டுள்ளது; Postgres கோப்பு cache, பகிர்வுகள், பயனர்கள் மற்றும் app நிலையை வைத்திருக்கிறது; config.php தரவுத்தள நற்சான்றிதழ்கள் (credentials), instance ID மற்றும் password salt ஆகியவற்றை வைத்திருக்கிறது. தரவுத்தளத்தை மீட்டெடுக்காமல் கோப்புகளை மட்டும் மீட்டெடுத்தால், Nextcloud-ஆல் அவற்றை அணுக முடியாது. config.php இல்லாமல் தரவுத்தளத்தை மீட்டெடுத்தால், அதால் தரவுத்தளத்தைத் திறக்க முடியாது. புதிய தரவு அடைவுக்கு எதிராக பழைய தரவுத்தளத்தை மீட்டெடுத்தால், நகர்த்தப்பட்ட கோப்புகளைச் சுட்டிக்காட்டும் பகிர்வுகள் செயலிழந்துவிடும்.

ஒரு quiesced instance-லிருந்து இந்த மூன்றையும் காப்புப்பிரதி எடுக்கவும்:

#!/usr/bin/env bash
set -euo pipefail
cd /srv/nextcloud
DEST="/var/backups/nextcloud/$(date -u +%Y%m%dT%H%M%SZ)"
mkdir -p "$DEST"

occ() { docker compose exec -T -u www-data app php occ "$@"; }

occ maintenance:mode --on
trap 'occ maintenance:mode --off' EXIT

docker compose exec -T db \
  pg_dump -U nextcloud --clean --if-exists nextcloud | gzip > "$DEST/db.sql.gz"

docker compose exec -T app \
  tar -C /var/www/html -cf - config custom_apps themes > "$DEST/app.tar"

rsync -a --delete /srv/nextcloud/data/ /var/backups/nextcloud/data/

Maintenance mode-தான் dump மற்றும் கோப்பு நகல் ஆகியவற்றை ஒன்றிணைக்கிறது. இதைத் தவிர்த்தால், rsync இன்னும் சென்றடையாத ஒரு கோப்பைக் குறிப்பிடும் தரவுத்தளத்தை நீங்கள் காப்புப்பிரதி எடுக்க நேரிடும். இந்த script timestamp-உடன் கூடிய தரவுத்தள dump-களை வைத்திருக்கும், ஆனால் தரவு அடைவுக்கு ஒரே ஒரு rolling mirror மட்டுமே இருக்கும் என்பதை கவனிக்கவும். rsync --delete ஒவ்வொரு முறையும் அதை மேலெழுதும் (overwrite), எனவே புதிய dump மட்டுமே கோப்பு நகலுடன் இணையும்.

பிறகு அதை server-லிருந்து வெளியேற்றவும். காப்புப்பிரதி எடுக்கப்பட்ட அதே VPS-ல் இருக்கும் காப்புப்பிரதி என்பது ஒரு நகல் மட்டுமே, அது உண்மையான காப்புப்பிரதி அல்ல. restic-ஐ object storage அல்லது இரண்டாவது host-க்கு பயன்படுத்துவது வழக்கமான தீர்வாகும். அதன் deduplication வசதி, nightly tarball-ஐ விட தரவு அடைவை சிறப்பாகக் கையாளும். Repository init முதல் nightly timer மற்றும் restore drill வரையிலான முழுமையான அமைப்பு restic மூலம் off-box VPS காப்புப்பிரதிகள் பகுதியில் உள்ளது.

மீட்டெடுப்பு என்பது வெறும் தலைகீழ் செயல்முறை அல்ல. புதிதாகத் தொடங்கப்பட்ட stack, installer-ஐ இயக்கி ஒரு புதிய config.php, புதிய instance ID மற்றும் password salt ஆகியவற்றை உருவாக்கும். அந்த புதிய அடையாளத்தின் மேல் dump-ஐ இறக்குமதி செய்தால், அது செயலிழந்த sessions மற்றும் share tokens-ஐ உருவாக்கும். முதலில் பழைய அடையாளத்தை மீண்டும் வைக்கவும், இந்த வரிசையில்:

docker compose up -d && docker compose stop app cron    # create the volumes, then halt the app
sudo rsync -a --delete /var/backups/nextcloud/data/ /srv/nextcloud/data/
docker compose run --rm -T --entrypoint "" app \
  tar -C /var/www/html -xf - < app.tar                  # the original config.php returns
gunzip -c db.sql.gz | docker compose exec -T db psql -U nextcloud -d nextcloud
docker compose start app cron
docker compose exec -T -u www-data app php occ maintenance:mode --off
docker compose exec -T -u www-data app php occ files:scan --all

files:scan, வட்டில் உள்ள கோப்புகளுடன் கோப்பு cache-ஐ ஒத்திசைக்கிறது. உங்களுக்குத் தேவைப்படுவதற்கு முன்பே, ஒரு spare VPS-ல் இதை ஒருமுறை பயிற்சி செய்து பார்க்கவும். வட்டில் உள்ள பைட்டுகள் மற்றும் Postgres-ல் உள்ள மெட்டாடேட்டா ஆகியவற்றுக்கு இடையேயான இந்த பிரிவினை, இதே போன்ற அமைப்பைக் கொண்ட அனைத்து app-களுக்கும் பொருந்தும். இதனால்தான் library-ஐ மட்டும் காப்புப்பிரதி எடுத்து தரவுத்தளத்தை எடுக்காத Immich காப்புப்பிரதி, காலவரிசை இல்லாத வெற்றுத் தரவை மீட்டெடுக்கும்.

மேம்படுத்தல்கள்: ஒரு நேரத்தில் ஒரு முக்கிய பதிப்பு (major version)

Nextcloud ஒரு நேரத்தில் சரியாக ஒரு முக்கிய பதிப்பை மட்டுமே மேம்படுத்த அனுமதிக்கிறது. 29-லிருந்து 31-க்கு நேரடியாக மாறுவது சரியாகச் செயல்படாது; அது Exception: Updates between multiple major versions and downgrades are unsupported. பிழையைத் தந்து, உங்களை maintenance mode-ல் நிறுத்திவிடும்.

Docker மேம்படுத்தல் முறை இதுதான்: முதலில் backup எடுக்கவும், பிறகு app மற்றும் cron ஆகிய இரண்டு services-லும் உள்ள tag-ஐ 31-லிருந்து 32-க்கு மாற்றவும், அதன் பிறகு docker compose pull && docker compose up -d கட்டளையை இயக்கவும், இறுதியாக docker compose logs -f app கட்டளையை இயக்கவும். Image entrypoint, ஏற்கனவே உள்ள தரவுகளுடன் புதிய code-ஐ ஒப்பிட்டு, தானாகவே occ upgrade-ஐ இயக்கும். இந்தச் செயல்பாட்டை இடையில் நிறுத்த வேண்டாம். Logs அமைதியான பிறகு, docker compose exec -u www-data app php occ status-ஐ இயக்கி, versionstring-ஐச் சரிபார்க்கவும்; மேலும் அனைத்து apps-ம் மீண்டும் enabled நிலையில் உள்ளதா என்பதை உறுதிப்படுத்தவும்.

உங்களைக் காக்கும் இரண்டு விதிகள்: ஒரு முக்கிய பதிப்பை மேம்படுத்திச் சரிபார்க்கவும், அதன் பிறகு அடுத்த பதிப்பிற்குச் செல்லவும். மேலும், cron-ஐ மாற்றாமல் app service-ல் உள்ள tag-ஐ ஒருபோதும் மாற்ற வேண்டாம்; ஒரே database-ஐ இரண்டு வெவ்வேறு Nextcloud பதிப்புகள் அணுகுவது தரவுச் சிதைவிற்கு (corruption) வழிவகுக்கும்.

நீங்கள் உண்மையில் காணக்கூடிய பிழைகள்

"Your data directory is readable by other users. Please change the permissions to 0770." Bind-mount செய்யப்பட்ட கோப்பகத்தில் (directory) group அல்லது world read அனுமதிகள் உள்ளன. sudo chmod 0770 /srv/nextcloud/data மற்றும் sudo chown -R 33:33 /srv/nextcloud/data-ஐச் சரிபார்க்கவும்.

"Your data directory is invalid. Ensure there is a file called .ocdata in the root." Bind mount குறிப்பிடும் இடம் Nextcloud-ஆல் இன்னும் உருவாக்கப்படவில்லை, பாதையில் எழுத்துப் பிழை உள்ளது, அல்லது இயங்கிக்கொண்டிருந்த instance-க்கு பதிலாக புதிய காலி கோப்பகம் மாற்றப்பட்டுள்ளது. Host-ல் உள்ள பாதை volume வரியுடன் ஒத்துப்போகிறதா என்பதை உறுதிப்படுத்தவும்.

"Access through untrusted domain." கோரிக்கையில் உள்ள hostname trusted_domains-ல் இல்லை. NEXTCLOUD_TRUSTED_DOMAINS என்பது முதல்முறை நிறுவும் போது மட்டுமே பொருந்தும்; அதன் பிறகு இதை நேரடியாக அமைக்கவும்: occ config:system:set trusted_domains 1 --value=cloud.example.com.

502 Bad Gateway, /var/log/nginx/error.log-ல் connect() failed (111: Connection refused) while connecting to upstream பிழையுடன். Nginx-ஆல் 127.0.0.1:8080-ல் எதையும் அணுக முடியவில்லை. Container இன்னும் தொடங்கிக்கொண்டிருக்கலாம் (docker compose logs app-ஐச் சரிபார்க்கவும்), அது வெளியேறியிருக்கலாம் (docker compose ps), அல்லது publish வரி proxy_pass port-உடன் பொருந்தவில்லை. ss -ltnp | grep 8080 மூலம் இதை உறுதிப்படுத்தவும்.

Redirect loop, அல்லது admin overview-ல் "insecure" எச்சரிக்கைகள். OVERWRITEPROTOCOL: https விடுபட்டுள்ளது, அல்லது TRUSTED_PROXIES-ல் Docker gateway subnet இல்லை. மேலே உள்ள proxy பகுதியைச் பார்க்கவும்.

LockedException: "files/..." is locked. REDIS_HOST அமைக்கப்பட்டிருக்கும்போது, image ஆனது Redis-ஐ locking backend-ஆக உள்ளமைக்கும், இதனால் பழைய locks அரிதாகவே ஏற்படும். இது இல்லையெனில், locks தரவுத்தளத்தின் oc_file_locks அட்டவணையில் இருக்கும்; ஒரு கோரிக்கை பாதியிலேயே நிறுத்தப்பட்டால், அது வரிசைகளை (rows) அப்படியே விட்டுவிடும். கைமுறையாக lock வரிசைகளை நீக்கும் முன், Redis பயன்பாட்டில் உள்ளதா என்பதை உறுதிப்படுத்தவும்; occ config:system:get memcache.locking கட்டளை Redis class-ஐக் காட்ட வேண்டும்.

"The PHP memory limit is below the recommended value of 512MB." PHP_MEMORY_LIMIT-ஐ உயர்த்தி, container-ஐ மீண்டும் உருவாக்கவும். இது உங்கள் அதிகபட்ச நினைவகப் பயன்பாட்டில் (worst-case ceiling) என்ன மாற்றத்தை ஏற்படுத்தும் என்பதை நினைவில் கொள்ளவும்.

அளவீடு அதிகரிக்கும்போது ஏற்படும் சிக்கல்கள்

முதல் தடையாக இருப்பது, தரவு அடைவு (data directory) அதன் volume-ஐ விடப் பெரியதாக வளர்வதுதான். ஒரு VPS-ல் volume-ஐ அதிகரிப்பது என்பது, அதன் அளவை மாற்றிவிட்டு filesystem-ஐ விரிவுபடுத்துவதாகும். இது 100% நிறைந்த பிறகு செய்வதை விட, முன்னரே திட்டமிட்டுச் செய்வது எளிது. எனவே, disk பயன்பாடு குறித்த எச்சரிக்கைகளை இப்போதே அமைக்கவும்.

இரண்டாவது தடை oc_filecache ஆகும். கோப்புகளின் எண்ணிக்கை அதிகரிக்கும்போது, கோப்புப் பட்டியல் (file listings) மற்றும் sync scans மெதுவாகும். இதற்குத் தீர்வாக database-ஐ மேம்படுத்த வேண்டும்: Postgres-ஐ வேகமான storage-ல் வைக்கவும், அதற்குத் தேவையான shared memory-ஐ வழங்கவும், மேலும் குப்பைகளையும் பழைய பதிப்புகளையும் retention settings மூலம் அவ்வப்போது நீக்கவும்; அவற்றை நிரந்தரமாகச் சேமிக்க விடாதீர்கள்.

மூன்றாவது சிக்கல், preview generation மற்ற செயல்பாடுகளுடன் போட்டியிடுவது. சிறிய server-களில், preview providers-ஐக் குறைவாக வைத்திருங்கள். வேலை நேரத்தில் ஒருபோதும் occ preview:generate-all-ஐ இயக்க வேண்டாம். உங்கள் சேமிப்பில் பெரும்பகுதி கைபேசி புகைப்படங்களாக இருந்தால், அந்த thumbnail உருவாக்கும் பணிக்காகத் தனியாக ஒரு photo server-ஐப் பயன்படுத்துங்கள். PhotoPrism மற்றும் Immich ஆகியவற்றின் RAM பயன்பாடு, கைபேசி செயலிகள் மற்றும் backup கட்டளைகள் குறித்த ஒப்பீடு Nextcloud server-ஐ விட இவை ஒவ்வொன்றும் எவ்வளவு செலவாகும் என்பதை விளக்குகிறது.

இதைத் தாண்டிச் சொல்லப்போனால், கூடுதல் வசதிகளுக்குத் தனித்தனி machine-களைப் பயன்படுத்துவதே சிறந்தது. Collabora மற்றும் full-text search ஆகியவை தனித்தனி memory தேவைகளைக் கொண்ட resident services ஆகும். உங்கள் கோப்புகளின் ஒரே நகலை வைத்திருக்கும் அதே server-ல் இவற்றையும் வைப்பது, எவ்விதப் பயனும் இன்றி தோல்விக்கான வாய்ப்பை (failure domain) அதிகரிக்கிறது. browser-ல் ஆவணங்களைத் திருத்தும் வசதி உங்களுக்குத் தேவைப்பட்டால், OnlyOffice மற்றும் Collabora ஆகியவற்றின் RAM தேவை மற்றும் connection வரம்புகள் குறித்த கட்டுரை, 2 முதல் 4 GB RAM கொண்ட VPS-ல் எதை இயக்கலாம் என்பதைத் தீர்மானிக்க உதவும். volume-ன் அளவு சரியாக இல்லாதபோது, file storage-ஐ S3-compatible primary storage-க்கு மாற்றவும். ஆனால், இது backup எடுப்பதை எளிதாக்காது, மாறாகக் கடினமாக்கும் என்பதை நினைவில் கொள்க: metadata இன்னும் database-லேயே இருக்கும், எனவே அதை bucket-உடன் சேர்த்து dump செய்ய வேண்டும்.

instance உண்மையான பயனர்களுக்குச் சேவை செய்யத் தொடங்கியதும், Uptime Kuma-வை அதற்கு முன்னால் நிறுவுங்கள். அப்போதுதான் sync clients அறிவதற்கு முன்பே downtime குறித்து நீங்கள் தெரிந்துகொள்ள முடியும். ஒரு private cloud-ஐ உங்கள் சொந்த mail server-உடன் இணைப்பது சிறப்பாக இருக்கும். சேவைகளை நீங்களே கைகளால் இணைக்க விரும்பவில்லை என்றால், Cloudron, CasaOS மற்றும் Coolify போன்ற தளங்கள் உங்களுக்காக அதைச் செய்து தரும். ஒரு self-hosted search engine-ஐ அடுத்து நிறுவத் திட்டமிட்டால், மேலே குறிப்பிட்டவற்றிலிருந்து மாறுபட்ட சிக்கல்களை எதிர்பார்க்கலாம்: SearXNG-ன் 429 பிழைகள் அதன் சொந்த rate limiter-ஆல் அல்லது upstream engines உங்கள் VPS IP-ஐத் தடுப்பதாலோ ஏற்படலாம். log-ஐப் பார்த்தால் மட்டுமே இதற்கான காரணத்தைக் கண்டறிய முடியும்.

FAQ

Postgres-க்கு பதிலாக SQLite-ல் Nextcloud-ஐ இயக்க முடியுமா?

இயக்க முடியும், அதிகாரப்பூர்வ image-ம் அதற்கு அனுமதிக்கும். ஆனால், ஒரே ஒரு desktop sync client ஒரே நேரத்தில் பல கோரிக்கைகளை (parallel requests) அனுப்பும்போது SQLSTATE[HY000]: General error: 5 database is locked பிழையையும் HTTP 500 பிழைகளையும் சந்திக்கும். SQLite முழு தரவுத்தளத்திற்கும் ஒரு write lock-ஐ எடுக்கும்; Nextcloud தொடர்ந்து தரவுகளை எழுதுவதால், file locks, activity rows, மற்றும் job state ஆகியவற்றில் சிக்கல் ஏற்படும். எனவே, Postgres அல்லது MariaDB-ல் தொடங்குங்கள்; occ db:convert-type வசதி இருந்தாலும், அது நேரடித் தரவுகளில் (live data) செய்ய வேண்டிய நீண்ட மற்றும் முழுமையான இடம்பெயர்வு (all-or-nothing migration) ஆகும்.

Nextcloud VPS-க்கு உண்மையில் எவ்வளவு RAM தேவை?

பயனர்களின் எண்ணிக்கையை விட, ஒரே நேரத்தில் செயல்படும் கோரிக்கைகளின் (concurrency) அடிப்படையில் அளவிடவும். மிக மோசமான சூழலில், தேவைப்படும் நினைவகம் என்பது ஒரே நேரத்தில் வரும் கோரிக்கைகளின் எண்ணிக்கையை PHP_MEMORY_LIMIT-ஆல் பெருக்கி, அதனுடன் Postgres shared buffers, ஒவ்வொரு இணைப்பிற்கும் ஒரு backend, மற்றும் preview generation-ன் உச்சக்கட்டத் தேவை ஆகியவற்றைக் கூட்டி கணக்கிட வேண்டும். நீங்கள் preview-களைக் கட்டுப்படுத்தி swap சேர்த்தால், 2 GB RAM கொண்ட server ஒரு சிறிய குடும்பத்தின் பயன்பாட்டிற்குப் போதுமானது. ஆனால், Collabora அல்லது full-text search போன்றவற்றைச் சேர்த்தால், கூடுதல் சேவைகளுக்காக அதிக நினைவகம் தேவைப்படும்.

nginx reverse proxy-க்கு பின்னால் பெரிய கோப்புகளைப் பதிவேற்றும்போது ஏன் தோல்வியடைகிறது?

proxy-ல் உள்ள இரண்டு அமைப்புகள் இதற்கு முக்கியக் காரணம்: client_max_body_size-ன் இயல்புநிலை 1 MB-ஆக இருப்பதால் கோரிக்கை துண்டிக்கப்படுகிறது, மேலும் proxy_read_timeout / proxy_send_timeout ஆகியவற்றின் குறைந்த மதிப்புகள் நீண்ட நேரப் பரிமாற்றங்களை இடையில் நிறுத்திவிடுகின்றன. இரண்டையும் தாராளமாக அமைத்து, proxy_request_buffering off-ஐ spool செய்வதற்குப் பதிலாக stream செய்ய மாற்றி, app container-ல் உள்ள PHP_UPLOAD_LIMIT-ஐ அதற்கு இணையாக உயர்த்தவும்.

Nextcloud ஏன் loop-ல் redirect செய்கிறது அல்லது reverse proxy பற்றி எச்சரிக்கிறது?

Container-ஆனது 127.0.0.1-ல் உள்ள nginx-ஐப் பார்க்காது, அது 172.x-ல் உள்ள Docker bridge gateway-ஐ மட்டுமே பார்க்கும். அந்த முகவரி TRUSTED_PROXIES-ல் விடுபட்டிருந்தால், X-Forwarded-Proto: https header புறக்கணிக்கப்படும், Nextcloud http:// URL-களை உருவாக்கும், proxy அவற்றை மீண்டும் திருப்பி அனுப்பும். TRUSTED_PROXIES-ஐ உண்மையான bridge subnet-க்கு அமைத்து, OVERWRITEPROTOCOL: https-ஐ உறுதிப்படுத்தவும்.

Nextcloud-ஐ 29-லிருந்து நேரடியாக 31-க்கு upgrade செய்ய முடியுமா?

முடியாது. Nextcloud ஒருமுறைக்கு ஒரு major version-ஐ மட்டுமே ஆதரிக்கிறது. பதிப்புகளைத் தவிர்த்தால் Updates between multiple major versions and downgrades are unsupported. பிழையுடன் நின்றுவிடும், மேலும் அந்த instance maintenance mode-லேயே இருக்கும். தரவுகளை backup எடுத்து, app மற்றும் cron ஆகிய இரண்டு சேவைகளிலும் tag-ஐ ஒரு major version உயர்த்தி, docker compose pull && docker compose up -d செய்து, occ status மூலம் சரிபார்த்து, மீண்டும் அடுத்த பதிப்பிற்குச் செய்யவும்.

#nextcloud#docker#self-hosting#backups#reverse-proxy#postgres