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

VPS-இல் Nextcloud Docker Compose வழி இயக்கம்

Docker Compose, Postgres, Redis, Let's Encrypt TLS கொண்டு VPS-இல் Nextcloud-ஐ அமைக்க முழு வழிகாட்டி. SQLite-க்கு பதிலாக Postgres தேர்வு, consistent backup உருவாக்கம், upgrade படிகள்

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

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

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

திறன் மதிப்பீடு: எது உண்மையில் நினைவகத்தைப் பயன்படுத்துகிறது

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

PHP workers. -apache இமேஜ் ஒவ்வொரு ஒரே நேரத்து கோரிக்கையையும் ஒரு worker process மூலம் சேவையளிக்கிறது. அதில் ஒரு PHP interpreter இயங்குகிறது. PHP கோரிக்கையை முடிப்பதற்கு முன், ஒவ்வொரு worker-ம் PHP_MEMORY_LIMIT வரை வளரலாம். உங்கள் மோசமான நிலையிலான resident memory தோராயமாக ஒரே நேரத்து கோரிக்கைகள் × நினைவக வரம்பு ஆகும். ஒரு desktop sync client ஒவ்வொரு பயனருக்கும் பல இணை இணைப்புகளைத் திறக்கிறது. பயனர் எண்ணிக்கை அல்ல, ஒரே நேரத்து இயக்கமே உச்ச வரம்பைத் தீர்மானிக்கிறது.

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

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

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

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

SQLite ஏன் உடைகிறது

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

பின்னர் occ db:convert-type மூலம் மாற்றுவது சாத்தியம். ஆனால் இது live dataset-இல் நீண்ட, all-or-nothing migration ஆகும். ஆரம்பத்திலேயே Postgres அல்லது MariaDB உடன் தொடங்கவும்.

Compose கோப்பு

இதை /srv/nextcloud/compose.yaml-இல் வைக்கவும். ரகசியங்களை அதே அடைவில் உள்ள ஒரு சகோதர .env கோப்பில் 600 முறைமையில் வைக்கவும்.

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:

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

தரவு அடைவு ஒரு bind mount, named volume அல்ல. இது வேண்டுமென்றே செய்யப்பட்டது: ஒரு காப்பு கருவியை நேரடியாக சுட்டிக்காட்டக்கூடிய பாதை, ஒழுங்கான தோற்றத்தை விட மதிப்புமிக்கது. அதை படிமத்தின் www-data UID-உடனும் Nextcloud கோரும் அனுமதிகளுடனும் உருவாக்கவும்:

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

போர்ட் வெளியீட்டை கவனிக்கவும்: 127.0.0.1:8080:80. Docker போர்ட்களை DNAT விதிகளை எழுதி வெளியிடுகிறது. அந்த விதிகள் ufw-இன் INPUT சங்கிலி பேக்கெட்டை பார்ப்பதற்கு முன்பே மதிப்பிடப்படுகின்றன — ஒரு வெற்று 8080:80 எதுவாக இருந்தாலும், ufw என்ன சொல்கிறது என்பதை பொருட்படுத்தாமல் குறியாக்கப்படாத Nextcloud-ஐ பொது இணையத்தில் வைத்துவிடும். loopback-க்கு பிணைப்பது அதை பொது இடைமுகத்திலிருந்து விலக்கி வைக்கிறது. பிறகு ஃபயர்வால் ப்ராக்ஸியை மட்டுமே அனுமதிக்க வேண்டும் — SSH-ஐ முழு இணையத்திற்கும் திறந்து வைக்க விரும்பாவிட்டால், சுய-ஹோஸ்ட் செய்யப்பட்ட WireGuard VPN வழியாக VPS-ஐ அணுகுதல் போர்ட் 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-ஐ கவனிக்கவும். முதல் துவக்கம் முழு பயன்பாட்டு மரத்தையும் தொகுதிக்குள் நகலெடுத்து நிறுவியை இயக்குகிறது; அது முடியும் வரை கொள்கலன் எதற்கும் பதிலளிக்காது.

TLS மற்றும் ரிவர்ஸ் ப்ராக்ஸி

டிஸ்ட்ரோவிலிருந்து nginx மற்றும் certbot ஐ நிறுவவும். சரியான server_name உடன் ஒரு சாதாரண port-80 சர்வர் பிளாக்கை உருவாக்கவும். பின்னர் certbot அதை மாற்றியமைக்கட்டும். HTTP-01 சவாலின் இயங்குமுறை, புதுப்பிப்பு டைமர் மற்றும் தோல்வி நிலைகள் ஆகியவை Ubuntu 24.04 இல் certbot மற்றும் nginx உடன் Let's Encrypt சான்றிதழ்களை வழங்குதல் என்பதில் முழுமையாக விளக்கப்பட்டுள்ளன:

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

Certbot ஆனது ssl_certificate வரிகள் மற்றும் :80 → :443 திருப்பிவிடலைச் சேர்க்கிறது. மேலும் 90 நாள் சான்றிதழைப் புதுப்பிக்கும் systemd டைமரை நிறுவுகிறது. அது இருப்பதை systemctl list-timers | grep certbot உடன் உறுதிப்படுத்திக் கொள்ளுங்கள் — ஒருபோதும் இயக்கப்படாத புதுப்பிப்பு டைமர் என்பது 90 நாள் குண்டுச்சூடு ஆகும்.

ப்ராக்ஸி பிளாக்:

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 இல் பழைய பதிப்பு உள்ளது, அதற்கு சமமானது listen 443 ssl http2; ஆகும். உங்கள் பதிப்பு எதை ஏற்கிறது என்பதை nginx -t கூறும்.

client_max_body_size மற்றும் நீண்ட ரீட் நேரமுடைப்புகள் ஆகியவை பெரிய பதிவேற்றங்கள் பாதிவழியில் நின்றுவிடாமல் தடுக்கின்றன. proxy_request_buffering off ஆனது முழு கோப்பையும் முதலில் ப்ராக்ஸியின் வட்டில் சேமிக்காமல், பதிவேற்றத்தை நேரடியாகப் பாய்ச்சுகிறது.

ஒரு ஆப்பிற்கு செயல்படும் மிக எளிய வழி ஹோஸ்டில் உள்ள nginx ஆகும். Nextcloud மற்ற கொள்கலன்களுடன் VPS ஐப் பகிர்ந்து கொள்ள இருந்தால், பல ஆப்களுக்கு Docker Compose ரிவர்ஸ் ப்ராக்ஸியாக Traefik ஐ இயக்குதல் ரூட்டிங் மற்றும் சான்றிதழ் வழங்கலை கொள்கலன் லேபிள்களுக்கு மாற்றுகிறது. மேலும் அதே client_max_body_size மற்றும் நேரமுடிப்பு கவலைகள் அங்கே மிடில்வேர் மற்றும் டிரான்ஸ்போர்ட் அமைப்புகளாக மீண்டும் தோன்றும்.

trusted_proxies மற்றும் overwriteprotocol

பெரும்பாலான சுய-ஹோஸ்ட் செய்யப்பட்ட Nextcloud நிகழ்வுகள் இங்கே தான் தவறு செய்கின்றன. அதன் அறிகுறிகள் காரணத்துடன் தொடர்பில்லாமல் தோன்றும்.

X-Forwarded-Proto: https மரியாதை செய்யப்படுவது, கோரிக்கை trusted_proxies பட்டியலில் உள்ள முகவரியிலிருந்து வந்தால் மட்டுமே. மரியாதை செய்யப்படாதபோது, Nextcloud அந்தக் கோரிக்கை சாதாரண HTTP என நம்புகிறது. இது http:// URLகளை உருவாக்குகிறது. ப்ராக்ஸி அவற்றை HTTPS-க்கு திருப்பிவிடுகிறது. உலாவி அதைப் பின்தொடர்கிறது. Nextcloud மீண்டும் http:// ஐ உருவாக்குகிறது. இதுவே திருப்பிவிடுதல் சுழற்சி. OVERWRITEPROTOCOL: https திட்டத்தைப் பொருட்படுத்தாமல் நிர்ணயிக்கிறது.

TRUSTED_PROXIES இல் உள்ள வலை என்னவென்றால், Nextcloud பார்க்கும் முகவரி அல்ல 127.0.0.1. nginx ஹோஸ்டில் இயங்குகிறது. அது வெளியிடப்பட்ட போர்ட்டுடன் இணைகிறது. எனவே கன்டெய்னர் Docker பிரிட்ஜ் கேட்வேயைப் பார்க்கிறது — 172.x இல் ஏதோ ஒன்று. உண்மையான சப்நெட்டைக் கண்டுபிடிக்கவும்:

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

அந்த CIDR-ஐ (அல்லது அதை உள்ளடக்கிய 172.16.0.0/12) TRUSTED_PROXIES இல் சேர்க்கவும். இது மிக அகலமாக இருந்தால் எந்த கிளையன்டும் X-Forwarded-For ஐ போலியாக்கலாம். இது தவறாக அமைக்கப்பட்டால் ஒவ்வொரு லாகினும் கேட்வே முகவரியிலிருந்து வருவதாகத் தோன்றும். ப்ரூட்-ஃபோர்ஸ் பாதுகாப்பு உங்கள் முழு நிகழ்வையும் ஒரே நேரத்தில் தடுக்கிறது. நிர்வாகக் கண்ணோட்டம் காட்டுவது: "The reverse proxy header configuration is incorrect, or you are accessing Nextcloud from a trusted proxy."

OVERWRITECLIURL cron கன்டெய்னருக்கு முக்கியமானது. அதற்கு ஹோஸ்ட்பெயரை அனுமானிக்க உள்வரும் கோரிக்கை இல்லை. இது இல்லாவிட்டால், பின்னணி வேலைகள் localhost க்கான இணைப்புகளை உருவாக்குகின்றன. மின்னஞ்சல் அறிவிப்புகள் பயன்படுத்த முடியாத URLகளை அனுப்புகின்றன.

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

Nextcloud-இன் இயல்புநிலை வேலை இயக்கி AJAX ஆகும்: ஒருவர் பக்கத்தை ஏற்றுவதால் ஏற்படும் பக்க விளைவாக வேலைகள் இயங்குகின்றன. 04:00 மணிக்கு யாரும் உலாவ மாட்டார்கள். எனவே குப்பை காலாவதி, பதிப்புகள் துப்புரவு, முன்னோட்டங்கள் மற்றும் ஒருங்கிணைந்த மறுமுயற்சிகள் நின்றுபோகின்றன. முதல் அறிகுறி, தரவு அடைவு தொடர்ந்து வளர்ந்துகொண்டே இருப்பது ஆகும். மேலே உள்ள cron சேவை அதே தொகுதிகளுக்கு எதிராக அதிகாரப்பூர்வ /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) அமைப்பது பயனுள்ளதாக இருக்கும்.

காப்புப்பிரதிகள்: மூன்று உறுப்புகள், அல்லது ஒன்றுமே இல்லை

கோப்பு முறைமை மட்டுமே கொண்ட காப்புப்பிரதி செயலிழந்த நிகழ்வுக்கு மீட்டமைக்கப்படுகிறது. தரவு அடைவு பைட்டுகளைக் கொண்டுள்ளது; Postgres கோப்பு தற்காலிக சேமிப்பு, பகிர்வுகள், பயனர்கள் மற்றும் செயல் நிலையைக் கொண்டுள்ளது; config.php தரவுத்தள சான்றாணைகள், நிகழ்வு ID மற்றும் கடவுச்சொல் salt-ஐக் கொண்டுள்ளது. தரவுத்தளம் இல்லாமல் கோப்புகளை மீட்டமைத்தால் Nextcloud அவற்றைப் பார்க்க முடியாது. config.php இல்லாமல் தரவுத்தளத்தை மீட்டமைத்தால் அது தரவுத்தளத்தைத் திறக்க முடியாது. புதிய தரவு அடைவுடன் பழைய தரவுத்தளத்தை மீட்டமைத்தால், நகர்த்தப்பட்ட கோப்புகளைக் குறிக்கும் பகிர்வுகள் கிடைக்கும்.

மூன்றையும் நிறுத்தப்பட்ட நிகழ்விலிருந்து காப்புப் பிரதி எடுக்கவும்:

#!/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/

பராமரிப்பு பயன்முறைதான் dump மற்றும் கோப்பு நகலை ஒன்றுடன் ஒன்று ஒத்துப்போகச் செய்கிறது. இதைத் தவிர்த்தால், rsync இன்னும் அடையாத கோப்பைக் குறிப்பிடும் தரவுத்தளத்தை இறுதியில் நீங்கள் பிடிப்பீர்கள். ஸ்கிரிப்ட் நேரமுத்திரையிட்ட தரவுத்தள dump-களை வைத்திருக்கிறது ஆனால் தரவு அடைவின் ஒரே ஒரு உருளும் பிரதியை மட்டுமே வைத்திருக்கிறது — rsync --delete ஒவ்வொரு இயக்கத்திலும் அதை மேலெழுதுகிறது — எனவே புதிய dump மட்டுமே கோப்பு நகலுடன் இணைகிறது.

பிறகு அதை சேவையகத்திலிருந்து வெளியே எடுக்கவும். தான் காப்புப் பிரதி எடுக்கும் பொருளுடன் ஒரே VPS-இல் இருக்கும் காப்புப் பிரதி ஒரு நகல், காப்புப் பிரதி அல்ல. object storage அல்லது இரண்டாவது புரவலனுக்கு எதிராக restic வழக்கமான விடை, மேலும் அதன் deduplication தரவு அடைவை தினசரி tarball-ை விட மிகச் சிறப்பாகக் கையாள்கிறது. repository init-இலிருந்து இரவு நேர டைமர் மற்றும் மீட்டமைப்பு பயிற்சி வரை முழு அமைப்பும் restic உடன் சேவையகத்திற்கு வெளியே உள்ள VPS காப்புப்பிரதிகள்-இல் உள்ளன.

மீட்டமைப்பு வெறும் நேர்மாறு அல்ல. புதிதாகத் தொடங்கப்பட்ட ஸ்டாக் நிறுவியை இயக்கி புதிய config.php-ஐ எழுதுகிறது — புதிய நிகழ்வு ID மற்றும் கடவுச்சொல் salt — அந்தப் புதிய அடையாளத்தின் மேல் dump-ஐ இறக்குமதி செய்வது உடைந்த அமர்வுகள் மற்றும் பகிர்வு டோக்கன்களை விட்டுச்செல்கிறது. பழைய அடையாளத்தை முதலில், இந்த வரிசையில் மீண்டும் வைக்கவும்:

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 கோப்பு தற்காலிக சேமிப்பை வட்டில் உண்மையில் உள்ளதுடன் சரிசெய்கிறது. இதை ஒருமுறை, உங்களுக்குத் தேவைப்படுவதற்கு முன்பு, ஒரு உதிரி VPS-இல் பயிற்சி செய்யவும்.

மேம்படுத்தல்கள்: ஒரு தடவைக்கு ஒரு முக்கிய பதிப்பு

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

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

உங்களைக் காப்பாற்றும் இரண்டு விதிகள்: ஒரு முக்கிய பதிப்பை மேம்படுத்தவும், சரிபார்க்கவும், பிறகு அடுத்ததை மேம்படுத்தவும். மேலும் app சேவையில் tag ஐ திருத்தினால், cron ஐயும் பொருத்தமாக திருத்தாமல் விட வேண்டாம் — ஒரே தரவுத்தளத்திற்கு எதிராக இரண்டு வெவ்வேறு Nextcloud பதிப்புகள் என்பது ஊழலுக்கு வழிவகுக்கும்.

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

"Your data directory is readable by other users. Please change the permissions to 0770." bind-mount செய்யப்பட்ட கோப்பகத்தில் group அல்லது world read bits உள்ளன. 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." request-இல் உள்ள hostname ஆனது trusted_domains-ல் இல்லை. NEXTCLOUD_TRUSTED_DOMAINS முதல் நிறுவலின் போது மட்டுமே பொருந்தும்; அதன் பிறகு அதை live-ஆக அமைக்கவும்: 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-ல் எதையும் அடையவில்லை. கொள்கலன் இன்னும் துவக்கத்தில் இருக்கலாம் (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 database table-ல் இருக்கும்; write நடக்கும் போது கொல்லப்பட்ட request வரிசைகளை விட்டுச் செல்லும். Redis உண்மையில் பயன்பாட்டில் உள்ளதா என உறுதிப்படுத்தவும் — occ config:system:get memcache.locking ஆனது Redis class-ஐ திருப்பித் தர வேண்டும் — lock வரிசைகளை கைமுறையாக நீக்குவதற்கு முன்பு.

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

அளவு பெருகும்போது எது பழுதடைகிறது

முதல் தடை என்பது தரவு அடைவு வால்யூமை விட பெரியதாகி விடுவதாகும். ஒரு VPS-இல் வால்யூமை விரிவாக்குவது என்பது ஒரு resize செயல்பாடு மற்றும் filesystem grow செயல்பாடு ஆகியவற்றை உள்ளடக்கும். வட்டு 100% நிரம்பிய பிறகு இதைச் செய்வதை விட, முன்கூட்டியே திட்டமிட்டுச் செய்வது எளிதானது. எனவே, வட்டு பயன்பாட்டிற்கான எச்சரிக்கையை இப்போதே அமைக்கவும்; தாமதிக்க வேண்டாம்.

இரண்டாவது தடை oc_filecache. வரிசை எண்ணிக்கை அதிகரிக்க, கோப்பு பட்டியல்கள் மற்றும் sync ஸ்கேன்கள் மெதுவாகின்றன. இதற்கான தீர்வு தரவுத்தள வேலைதான்: Postgres-ஐ வேகமான சேமிப்பகத்தில் வைக்கவும், போதுமான shared memory பயன்படுத்த அனுமதிக்கவும், குப்பை மற்றும் பதிப்புகளை குவிய விடாமல் retention அமைப்புகள் மூலம் களையவும்.

மூன்றாவது தடை, preview உருவாக்கம் மற்ற அனைத்துடனும் போட்டியிடுவதாகும். ஒரு சிறிய சர்வரில், preview providers-ஐ குறைவாகவே வைத்திருக்கவும். வேலை நேரத்தில் occ preview:generate-all-ஐ ஒருபோதும் இயக்க வேண்டாம்.

இவற்றுக்கு அப்பால், நேர்மையான பதில் என்னவென்றால், கூடுதல் சேவைகளுக்கு தனியான ஒரு இயந்திரம் தேவை. Collabora மற்றும் full-text search ஆகியவை தனித்தனி நிரந்தர சேவைகள்; அவற்றுக்கு தனித்தனி memory profiles உள்ளன. உங்கள் கோப்புகளின் ஒரே பிரதியைக் கொண்டிருக்கும் சர்வரிலேயே இவற்றையும் இயக்கினால், எந்தப் பயனும் இல்லாமல் பழுதடையும் பகுதி விரிவடையும். வால்யூம் பொருத்தமற்றதாக மாறும்போது, கோப்பு சேமிப்பகத்தை S3-compatible primary storage-க்கு மாற்றவும். இது காப்புப்பிரதிகளை எளிதாக்காது; மாறாக, கடினமாக்கும் என்பதை அறிந்து கொள்ளவும்: தரவுத்தளம் இன்னும் metadata-ஐ கொண்டிருக்கும், மேலும் அது bucket-உடன் ஒத்திசைவாக dump செய்யப்பட வேண்டும்.

இந்த நிகழ்வு உண்மையான பயனர்களுக்குச் சேவை செய்யத் தொடங்கியதும், sync கிளையண்டுகள் அறிவதற்கு முன்பே நீங்கள் சேவை தடையை அறிந்து கொள்ள, அதன் முன் Uptime Kuma-ஐ அமைக்கவும். ஒரு தனியார் கிளவுட் உங்கள் சொந்த மின்னஞ்சல் சர்வர்-உடன் சிறப்பாக இணையும். சேவைகளை நீங்களாகவே கைமுறையாக இணைக்க விரும்பவில்லையென்றால், Cloudron, CasaOS மற்றும் Coolify அதை உங்களுக்காகத் தானாகச் செய்யும் தளங்களை ஒப்பிடுகிறது.

FAQ

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

இயக்கலாம். அதிகாரப்பூர்வ image-ம் அனுமதிக்கும். ஆனால் ஒரே ஒரு desktop sync client இணையான கோரிக்கைகளை அனுப்பினால் 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 உள்ளது. ஆனால் அது இயங்கும் தரவின் மீது நீண்ட, முழுமையான migration ஆகும்.

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

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

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 ஏன் தொடர்ச்சியாக redirect செய்கிறது அல்லது reverse proxy பற்றி எச்சரிக்கிறது?

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

Nextcloud-ஐ 29-ல் இருந்து நேரடியாக 31-க்கு மேம்படுத்தலாமா?

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

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