VPS-ல் Discourse நிறுவுவது எப்படி? முழுமையான வழிகாட்டி

VPS-ல் Discourse நிறுவுதல்: ஒரு container, ஒரு config file

VPS-ல் Discourse-ஐ நிறுவ, அந்தத் திட்டத்தின் சொந்த installer-ஐ இயக்க வேண்டும், ஒரு சிறிய wizard-ன் கேள்விகளுக்குப் பதிலளிக்க வேண்டும், பின்னர் build முடியும் வரை காத்திருக்க வேண்டும். Discourse என்பது Rails application, PostgreSQL, Redis மற்றும் nginx ஆகியவற்றை உள்ளடக்கிய ஒரே ஒரு Docker container-ஆகவே வெளிவருகிறது. நீங்கள் பின்னர் மாற்றும் அனைத்தும் /var/discourse/containers/app.yml என்ற ஒரே கோப்பில் இருக்கும், மேலும் ஒவ்வொரு மாற்றமும் ஒரு rebuild மூலமே தளத்திற்குச் சென்றடையும்.

இதன் அதிகாரப்பூர்வ நிறுவல் முறை discourse_docker ஆகும்: இது ஒரு launcher shell script மற்றும் சில YAML templates-களைக் கொண்டது. நீங்களாக எழுதும் Compose file-ஐ Discourse ஆதரிக்காது, மேலும் இந்த container-ஐ கைமுறையாகப் பிரித்து அமைக்கக் கூடாது. நீங்கள் Docker Compose மூலம் VPS-ல் services-ஐ இயக்குவதற்கு பழகியவர் என்றால், இது மாறுபட்ட அமைப்பைக் கொண்டிருக்கும் என்பதை எதிர்பார்க்கவும். இங்கே docker compose up -d கிடையாது, மேலும் ./launcher rebuild app என்பதே deploy செய்யும் முறையாகும்.

நீங்கள் தொடங்குவதற்கு முன் Discourse-க்குத் தேவையானவை

நான்கு முக்கியமான தேவைகள் பயனர்களைச் சிக்கலில் ஆழ்த்துகின்றன. லாகின் பக்கத்தை அடைவதற்கு முன்பே இவை ஒவ்வொன்றும் பாதிப்பை ஏற்படுத்தும்.

• Memory. ஒரு container-ல் PostgreSQL, Redis, Sidekiq மற்றும் ஒரு Ruby web server ஆகியவை இயங்குகின்றன. Build செய்யும் நிலையில் assets compile செய்யப்படுவதால், இயங்கும் தளத்தை விட அதிக memory தேவைப்படும்.
• ஒரு உண்மையான domain name. வழங்கப்பட்ட sample config-ல் இது தெளிவாகக் குறிப்பிடப்பட்டுள்ளது: "Discourse வெறும் IP முகவரியுடன் இயங்காது."
• ஒரு outbound mail path. கணக்குச் சரிபார்ப்பு (account activation), கடவுச்சொல் மாற்றம் (password resets), நிர்வாகி அழைப்புகள் (admin invites) மற்றும் சுருக்க மின்னஞ்சல்கள் (digest mail) அனைத்தும் SMTP (simple mail transfer protocol) வழியாகவே அனுப்பப்படுகின்றன.
• host-ல் 80 மற்றும் 443 ஆகிய ports காலியாக இருக்க வேண்டும். நீங்கள் ஏற்கனவே இயக்கும் ஒரு proxy-க்கு பின்னால் Discourse-ஐ வைத்தால் ஒழிய, இந்த ports தேவைப்படும்.

[
  {
    "label": "Documented minimum",
    "ram_gb": 1,
    "storage_gb": 10
  },
  {
    "label": "Documented recommended",
    "ram_gb": 2,
    "storage_gb": 20
  }
]

அதிகாரப்பூர்வ நிறுவல் ஆவணம், swap-உடன் குறைந்தபட்சம் 1 GB RAM மற்றும் 10 GB disk இடவசதியைக் குறிப்பிடுகிறது. மேலும், 2 GB RAM மற்றும் 20 GB disk இடவசதியைப் பரிந்துரைக்கிறது. முதல் வரிசையை நிறுவல் முடிவடைவதற்கான குறைந்தபட்ச அளவாகக் கருதவும்; ஒரு சமூகத்தை (community) இயக்குவதற்குத் தேவையான அளவாக இதைக் கருத வேண்டாம். இந்த இடைவெளி முக்கியமானது, ஏனெனில் memory பயன்பாடு உச்சத்தை அடைவது traffic-ல் அல்ல, build செய்யும் போதுதான்.

நிறுவுவதற்கு முன் domain-ஐ server-ஐ நோக்கிச் சுட்டிக்காட்டவும்

நீங்கள் பயன்படுத்தப்போகும் hostname-க்கு ஒரு A record-ஐ உருவாக்கவும், பின் அதை server-லிருந்தே உறுதிப்படுத்தவும்.

dig +short forum.example.com
curl -4 -s https://ifconfig.co

இரண்டு கட்டளைகளும் ஒரே முகவரியையே காட்ட வேண்டும். இவை ஒத்துப்போக வேண்டியது அவசியம், ஏனெனில் setup wizard உங்கள் hostname-ஐ வைத்து ஒரு connection test-ஐச் செய்யும். பழைய முகவரியைக் காட்டும் record அந்தத் தேர்வில் தோல்வியடையும். இரண்டு நிமிடங்களுக்கு முன் உருவாக்கிய record இன்னும் cache-ல் இருக்கலாம், எனவே wizard-உடன் போராடுவதை விட, பழைய TTL (time to live) முடியும் வரை காத்திருக்கவும்.

இந்த record ஒரு CDN மூலம் proxied செய்யப்படுமா என்பதை இப்போதே முடிவு செய்யவும். Proxied செய்யப்பட்ட record உங்கள் server முகவரியை மறைத்துவிடும். இதனால் container-ன் certificate கோரிக்கை தோல்வியடையும், ஏனெனில் ACME (automatic certificate management environment) challenge-க்கு Discourse-க்கு பதிலாக proxy பதிலளிக்கும். முதல்முறை நிறுவும் போது record-ஐ unproxied நிலையில் வைத்திருக்கவும்.

அதிகாரப்பூர்வ installer-ஐ இயக்குதல்

ஒரே கட்டளை git-ஐ நிறுவுகிறது, Docker-ன் சொந்த install script மூலம் Docker-ஐ நிறுவுகிறது, discourse_docker-ஐ /var/discourse-க்கு clone செய்கிறது, மற்றும் setup wizard-ஐத் தொடங்குகிறது.

wget -qO- https://raw.githubusercontent.com/discourse/discourse_docker/main/install-discourse | sudo bash

ஏற்கனவே server-ல் Docker இருந்தால் மற்றும் ஒவ்வொரு படியையும் நீங்களே செய்ய விரும்பினால், அதே வேலையை கைமுறையாகச் செய்யவும்.

sudo -s
git clone https://github.com/discourse/discourse_docker.git /var/discourse
cd /var/discourse
./discourse-setup

இதை root பயனராக இயக்கவும். சாதாரண பயனராகத் தொடங்கினால், discourse-setup உடனடியாக This script must be run as root. Please sudo or log in as root first. பிழையுடன் நின்றுவிடும். server-ல் Docker இல்லை என்றால், அது Docker is not installed. Please install Docker first. பிழையுடன் நின்றுவிடும், ஏனெனில் manual clone எதையும் தானாக நிறுவாது.

setup wizard எதைக் கேட்கிறது மற்றும் எதை எழுதுகிறது

ஆகஸ்ட் 2026 நிலவரப்படி, discourse-setup என்பது ஒரு மெல்லிய wrapper ஆகும். இது discourse/setup-wizard:release-ஐ host network மற்றும் Docker socket ஆகியவற்றுடன் இணைக்கப்பட்ட container-ஆக இயக்குகிறது. இதன் மூலம், wizard தான் கட்டமைக்கும் machine-ஐ ஆய்வு செய்ய முடியும். இது hostname மற்றும் admin email முகவரிகளைக் கேட்கும், பின்னர் உங்கள் SMTP விவரங்களைக் கேட்கும். இது containers/app.yml-ஐ எழுதிவிட்டு, மீண்டும் build செய்கிறது.

நீங்கள் தொடங்குவதற்கு முன் இரண்டு செயல்பாடுகளைத் தெரிந்துகொள்வது அவசியம். machine-ல் memory குறைவாக இருந்து swap இல்லையென்றால், wizard நின்று அதை உருவாக்கப் பரிந்துரைக்கும்: wrapper பின்னர் 2 GB /swapfile-ஐ உருவாக்கி, அதை /etc/fstab-ல் சேர்த்து, /etc/sysctl.d/30-discourse-swap.conf-ல் vm.swappiness = 10-ஐ அமைத்து, wizard-ஐ மீண்டும் தொடங்கும். wizard முடிவடையும் போது, அது Rebuilding app in 5 seconds (Ctrl+C to cancel)...-ஐ அச்சிட்டு, host-ல் ./launcher rebuild app-ஐ இயக்கும். சிறிய VPS-ல் அந்த build பல நிமிடங்கள் எடுக்கும். முதல் build-ல் அனைத்து asset-களும் புதிதாக compile செய்யப்படுவதால், அதுவே மிக மெதுவானதாக இருக்கும்.

ஏதாவது தவறு நடக்கும்போது கவனிக்க வேண்டிய flags-களை ./discourse-setup --help பட்டியலிடுகிறது. --skip-rebuild என்பது build செய்யாமல் configuration-ஐ மட்டும் எழுதும், --skip-connection-test என்பது DNS மற்றும் port சோதனைகளைத் தவிர்க்கும். சோதனை ஏன் தோல்வியடைகிறது என்பது உங்களுக்கு ஏற்கனவே தெரிந்தால் மட்டுமே --skip-connection-test-ஐப் பயன்படுத்தவும்; உதாரணமாக, நீங்கள் கட்டுப்படுத்தும் network firewall-க்கு பின்னால் host இருக்கும்போது இதைப் பயன்படுத்தலாம்.

முதல் rebuild-க்கு முன் app.yml கோப்பை வாசிக்கவும்

இந்த wizard ஒரு கோப்பை உருவாக்குகிறது, அதை இனி நீங்கள் தான் பராமரிக்க வேண்டும். அதை sudo nano /var/discourse/containers/app.yml மூலம் திறக்கவும். இவைதான் அனைத்தையும் தீர்மானிக்கும் முக்கிய பகுதிகள்.

templates:
  - "templates/postgres.template.yml"
  - "templates/redis.template.yml"
  - "templates/web.template.yml"
  - "templates/web.ratelimited.template.yml"
  ## Uncomment these two lines if you wish to add Lets Encrypt (https)
  #- "templates/web.ssl.template.yml"
  #- "templates/web.letsencrypt.ssl.template.yml"

expose:
  - "80:80"   # http
  - "443:443" # https

env:
  DISCOURSE_HOSTNAME: "forum.example.com"
  DISCOURSE_DEVELOPER_EMAILS: "you@example.com"
  DISCOURSE_SMTP_ADDRESS: smtp.example.com
  DISCOURSE_SMTP_PORT: 587
  DISCOURSE_SMTP_USER_NAME: user@example.com
  DISCOURSE_SMTP_PASSWORD: "your-smtp-password"

DISCOURSE_HOSTNAME என்பது தளம் பதிலளிக்கும் முகவரி ஆகும், இதிலிருந்தே Discourse தனது இணைப்புகளை உருவாக்குகிறது. இதில் தவறான மதிப்பு இருந்தால், தளம் ஒருமுறை மட்டுமே லோட் ஆகும், அதன் பிறகு உங்களை வேறு இடத்திற்கு திருப்பிவிடும். DISCOURSE_DEVELOPER_EMAILS என்பது கமாவால் பிரிக்கப்பட்ட பட்டியல் ஆகும். இதில் உள்ள முகவரிகள் முதல்முறை signup செய்யும்போது தானாகவே admin உரிமையைப் பெறும். உங்கள் சொந்த முகவரியை அதில் உள்ளிடவும், அதன் மூலம் பதிவு செய்யவும்; ஏனெனில் இதுவே முதல் admin கணக்கை உருவாக்கும் வழியாகும்.

இந்தக் கோப்பு உங்கள் SMTP கடவுச்சொல்லை plain text வடிவில் சேமிக்கிறது, எனவே sudo chmod 700 /var/discourse/containers மூலம் அந்த directory-க்கு கட்டுப்பாடுகளை விதிக்கவும். இது YAML வடிவில் இருப்பதால், whitespace-க்கு முக்கியத்துவம் உண்டு: ஒரு key தவறாக align செய்யப்பட்டிருந்தால், parse error ஏற்பட்டு build தோல்வியடையும், தளம் இயங்காது. இதில் ஒரு சிக்கல் sample கோப்பிலேயே குறிப்பிடப்பட்டுள்ளது. ஒரு password-க்குள் # இருந்தால், அது comment-ஆகக் கருதப்படும். எனவே, அத்தகைய குறியீடு கொண்ட கடவுச்சொற்களை quote செய்யவும்.

மின்னஞ்சல் அமைப்பே பெரும்பாலான நிறுவல்களைத் தடுக்கும் படியாகும்

ஆகஸ்ட் 2026 நிலவரப்படி, இந்த wizard-ஐப் பயன்படுத்தி நீங்கள் SMTP-ஐத் தவிர்த்துவிட்டு, அதற்குப் பதிலாக Discourse ID login-களைப் பயன்படுத்தலாம். மேலும், app.yml ஒரு பொருத்தமான DISCOURSE_SKIP_EMAIL_SETUP switch-ஐக் கொண்டுள்ளது; இது மின்னஞ்சல் அமைப்பு சரிபார்ப்பைத் தவிர்ப்பதாக விவரிக்கப்பட்டுள்ளது. மென்பொருளை முதன்முதலில் சோதித்துப் பார்க்கும்போது மின்னஞ்சலைத் தவிர்ப்பது நியாயமானது. ஆனால், ஒரு சமூகத்திற்கு இது தவறான தேர்வாகும், ஏனெனில் வெளிச்செல்லும் மின்னஞ்சல் இல்லையென்றால், யாராலும் கணக்கைச் செயல்படுத்தவோ அல்லது கடவுச்சொல்லை மாற்றவோ முடியாது.

நடைமுறைச் சிக்கல் என்னவென்றால், பெரும்பாலான VPS வழங்குநர்கள் வெளிச்செல்லும் port 25-ஐத் தடுக்கிறார்கள், எனவே அந்த server-ல் உள்ள சாதாரண மின்னஞ்சல் server-ஆல் மின்னஞ்சல்களை அனுப்ப முடியாது. port 587-ல் அல்லது implicit TLS (transport layer security) உடன் port 465-ல் அங்கீகரிக்கப்பட்ட relay-ஐப் பயன்படுத்தவும். port 465-க்கு, DISCOURSE_SMTP_FORCE_TLS: true-ஐ அமைக்கவும்; இது அந்த port-க்கு மாதிரி அமைப்பில் (sample config) பரிந்துரைக்கப்படுகிறது. நீங்கள் rebuild செய்வதற்கு முன்பு, host-லிருந்து மின்னஞ்சல் சேவையை அடைய முடியுமா என்பதைச் சோதிக்கவும்.

nc -vz smtp.example.com 587

வெற்றிகரமான முடிவானது succeeded!-ல் முடியும் ஒரு வரியைக் கொண்டிருக்கும். ஒரு கட்டளை (command) நீண்ட நேரம் இயங்கி, பின் காலாவதியானால் (timeout), உங்கள் VPS-லிருந்து வெளியேறும் பாதையில் அந்த port தடுக்கப்பட்டுள்ளது என்று அர்த்தம். இதை எந்த Discourse அமைப்பாலும் சரிசெய்ய முடியாது. உங்கள் வழங்குநர் அனுமதிக்கும் வேறொரு port-க்கு மாறவும் அல்லது அந்த port-ஐத் திறந்து தருமாறு வழங்குநரிடம் கேட்கவும்.

தளம் இயங்கத் தொடங்கியதும், Admin பக்கத்தில் உள்ள Email பகுதியிலிருந்து ஒரு சோதனைச் செய்தியை அனுப்பவும். பின்னர், அதே பக்கத்தில் உள்ள Skipped மற்றும் Bounced தாவல்களைப் பார்க்கவும். Discourse அனுப்ப மறுத்த மின்னஞ்சல்கள் மற்றும் relay நிராகரித்த மின்னஞ்சல்கள் இந்தத் தாவல்களில் பதிவு செய்யப்படும். அவை அதற்கான காரணத்தையும் குறிப்பிடும், இது logs-ஐப் படிப்பதை விட வேகமான வழியாகும்.

TLS: container-ஐ அதன் சொந்த certificate-ஐப் பெற அனுமதித்தல்

Discourse 80 மற்றும் 443 ஆகிய ports-ஐக் கையாள்கிறது என்றால், அதன் உள்ளமைக்கப்பட்ட (built-in) சான்றிதழ் வழங்கும் முறையைப் பயன்படுத்தலாம். மேலே காட்டப்பட்டுள்ள இரண்டு SSL template வரிகளின் comment-ஐ நீக்கிவிட்டு, rebuild செய்யவும். இந்த template acme.sh-ஐ இயக்குகிறது, /shared/ssl-ன் கீழ் உள்ள shared volume-ல் certificates-ஐச் சேமிக்கிறது, container-க்குள் குறிப்பிட்ட கால இடைவெளியில் அவற்றை renew செய்கிறது, மேலும் Discourse-ஐ HTTPS-க்குக் கட்டாயப்படுத்துகிறது.

இந்தச் செயல்முறை வேலை செய்ய, இணையத்திலிருந்து 80-வது port-ஐ அணுகக்கூடியதாக இருக்க வேண்டும், ஏனெனில் HTTP challenge அங்கேயே பதிலளிக்கப்படுகிறது. 443-வது port-ஐ மட்டும் அனுமதிக்கும் firewall-ஐப் பயன்படுத்தினால், build செயல்முறை முடிவடையும், ஆனால் certificate ஒருபோதும் வழங்கப்படாது. rebuild செய்த உடனேயே ./launcher logs app மூலம் அதன் முடிவைச் சரிபார்க்கவும்.

Nginx அல்லது Caddy-ஐ முன்னால் வைக்க வேண்டுமா?

Discourse மட்டுமே அந்த VPS-ல் இயங்கும் ஒரே web service என்றால், அவ்வாறு செய்ய வேண்டாம். அதன் container ஏற்கனவே மேம்படுத்தப்பட்ட nginx-ஐ இயக்குகிறது; இரண்டாவது proxy-ஐச் சேர்ப்பது ஒரு கூடுதல் hop-ஐ உருவாக்குவதுடன், புதுப்பிக்க வேண்டிய மற்றொரு certificate மற்றும் header பிழைகளுக்கான புதிய வாய்ப்பையும் ஏற்படுத்துகிறது.

அதே VPS-ல் பிற தளங்களும் இயங்கினால், இதை முன்னால் வைக்கலாம். templates பட்டியலில் templates/web.socketed.template.yml-ஐச் சேர்க்கவும், இரண்டு expose வரிகளையும் comment செய்யவும், மேலும் இரண்டு SSL template-களையும் comment செய்யப்பட்ட நிலையிலேயே விடவும். அப்போது அந்த container /var/discourse/shared/standalone/nginx.http.sock-ல் உள்ள unix socket-ல் இயங்கும் மற்றும் எந்த port-ஐயும் பயன்படுத்தாது; இது உங்கள் சொந்த proxy-க்காக 80 மற்றும் 443 ஆகிய port-களை விடுவிக்கும்.

server {
  listen 443 ssl;
  server_name forum.example.com;

  location / {
    proxy_pass http://unix:/var/discourse/shared/standalone/nginx.http.sock:;
    proxy_set_header Host $http_host;
    proxy_http_version 1.1;
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Real-IP $remote_addr;
  }
}

.sock-க்கு பின்னால் உள்ள colon, nginx-ன் unix socket syntax-ன் ஒரு பகுதியாகும்; அது இல்லையெனில் sudo nginx -t அந்த configuration-ஐ ஏற்காது. X-Forwarded-Proto என்பதும் கட்டாயமானது. Discourse absolute links-ஐ உருவாக்குவதால், அந்த header இல்லையெனில் அது HTTPS பக்கத்தில் http:// இணைப்புகளை வெளியிடும்; இதனால் browsers அவற்றை mixed content எனக் கருதி தடுக்கும். Container socket முறையில் இயங்கும்போது, TLS-ஐ நிர்வகிக்கும் பொறுப்பு உங்களுடையது; எனவே Certbot on Ubuntu 24.04 and nginx மூலம் host-ல் certificate-ஐப் பெறவும். நீங்கள் இன்னும் எந்த proxy-ஐப் பயன்படுத்தலாம் என முடிவு செய்யவில்லை எனில், the nginx, Caddy and Traefik comparison நீங்கள் மேற்கொள்ளும் மாற்றங்களை விளக்குகிறது.

மறுநிர்மாணம் (Rebuilds), மேம்படுத்தல்கள் மற்றும் நீங்கள் பயன்படுத்தும் கட்டளைகள்

cd /var/discourse
./launcher rebuild app

rebuild இயங்கிக்கொண்டிருக்கும் container-ஐ அழித்து, app.yml-லிருந்து புதிய ஒன்றை உருவாக்கி, அதைத் தொடங்கும். இந்த முழு கட்டுமானச் செயல்பாட்டின் போதும் தளம் (site) இயங்காது, எனவே ஒவ்வொரு configuration மாற்றத்தையும் சில நிமிட திட்டமிடப்பட்ட செயலிழப்பாக (scheduled downtime) கருதவும்.

env:-க்குக் கீழ் உள்ள மதிப்புகளை மட்டும் மாற்றினால் இதற்குத் தேவையில்லை. ./launcher destroy app && ./launcher start app ஏற்கனவே நீங்கள் உருவாக்கிய image-லிருந்து container-ஐ மீண்டும் உருவாக்கும், இதற்குச் சில நொடிகள் மட்டுமே ஆகும். templates: அல்லது hooks:-க்குக் கீழ் உள்ள எதை மாற்றினாலும் அது image-ஐயே மாற்றும் என்பதால், முழுமையான மறுநிர்மாணம் தேவைப்படும்.

மேம்படுத்தல்கள் இரண்டு வழிகளில் வரும். app.yml கட்டுமானத்தின் போது clone செய்யும் docker_manager plugin மூலம், /admin/upgrade-ல் உள்ள web interface வழியாக point releases-ஐப் பயன்படுத்தலாம். அடிப்படை image அல்லது templates-ல் செய்யப்படும் மாற்றங்கள் git மூலம் வரும்.

cd /var/discourse
git pull
./launcher rebuild app

சிறிய server-களில் மறுநிர்மாணம் தோல்வியடைவதற்கு முக்கிய காரணம், asset compilation-ன் போது ஏற்படும் அதிகப்படியான memory பயன்பாடுதான். கட்டுமானத்தின் போது dmesg-ல் Out of memory: Killed process போன்ற வரியுடன், ruby process-ஐக் காட்டி பாதியில் நின்றால், கட்டுமானத்தின் போது memory பற்றாக்குறை ஏற்பட்டுள்ளது என்று அர்த்தம்; தளம் அதற்கு முன்பு சரியாக இயங்கிக்கொண்டிருந்தாலும் இது நிகழலாம். Swap-ஐச் சேர்த்துவிட்டு மறுநிர்மாணத்தை மீண்டும் இயக்கவும்.

./launcher logs app
./launcher enter app
./launcher cleanup

logs என்பது container-ன் வெளியீட்டைத் திரையில் காட்டும், enter அதற்குள் ஒரு shell-ஐத் திறக்கும், மேலும் cleanup என்பது 24 மணி நேரத்திற்கு மேலாக நிறுத்தப்பட்டிருக்கும் container-களை நீக்கும். அவ்வப்போது cleanup-ஐ இயக்கவும், ஏனெனில் ஒவ்வொரு மறுநிர்மாணமும் ஒரு பழைய container-ஐ விட்டுச் செல்லும், இதனால் சிறிய VPS-ல் disk இடம் மெதுவாகத் தீர்ந்துவிடும்.

காப்புப்பிரதிகள் (Backups) மற்றும் காப்புப்பிரதியில் இல்லாத கோப்புகள்

Admin-ல் உள்ள Backups பக்கத்திலிருந்து காப்புப்பிரதிகளை எடுக்கலாம். இந்த ஆவணக் கோப்பு (archive) host-ல் /var/discourse/shared/standalone/backups/default/ என்ற பாதையில் சேமிக்கப்படும். இதே பணியை shell மூலமாகவும் இயக்கலாம்.

cd /var/discourse
./launcher enter app
discourse backup

discourse restore <filename> கட்டளை இதைத் தலைகீழாகச் செய்யும். நீங்கள் discourse enable_restore கட்டளையை இயக்கும் வரை restore செய்ய அனுமதி மறுக்கப்படும். தவறுதலாக ஏதேனும் ஒரு கட்டளை இயங்கி, நேரலையில் உள்ள forum-ஐ அழிப்பதைத் தவிர்க்கவே இந்த பாதுகாப்பு அம்சம் உள்ளது.

நீங்கள் கவனிக்க வேண்டிய இரண்டு இடைவெளிகள் உள்ளன. இந்த ஆவணக் கோப்பில் database இருக்கும். uploads-ஐ உள்ளடக்கிய backup setting ஆன் செய்யப்பட்டிருந்தால் மட்டுமே, பதிவேற்றப்பட்ட கோப்புகளும் (uploaded files) அதில் இருக்கும். எனவே, காப்புப்பிரதியை நம்புவதற்கு முன் அந்த setting-ஐ சரிபார்க்கவும். இதில் app.yml கோப்பு ஒருபோதும் இருக்காது. எனவே, புதிய VPS-ல் restore செய்யும்போது உங்கள் hostname மற்றும் SMTP விவரங்கள் தேவைப்படும். இதற்காக அந்த கோப்பையும் தனியாக நகலெடுத்து வைத்துக்கொள்ள வேண்டும்.

மேலும், இந்த ஆவணக் கோப்பு எந்த தளத்தைப் பாதுகாக்கிறதோ, அதே disk-ல் தான் சேமிக்கப்படுகிறது. இது முறையான காப்புப்பிரதி ஆகாது. எனவே, அட்டவணைப்படி (schedule) இதை வேறொரு இடத்திற்கு நகர்த்தவும்.

rsync -avz root@forum.example.com:/var/discourse/shared/standalone/backups/default/ ~/discourse-backups/

செயல்பாட்டில் உள்ள ஒரு forum-க்குத் தேவைப்படும் RAM அளவு

Bootstrap செயல்முறையானது, கண்டறியப்பட்ட memory மற்றும் CPU அளவைக் கொண்டு UNICORN_WORKERS மற்றும் db_shared_buffers ஆகியவற்றை அமைக்கிறது. மாதிரி உள்ளமைப்பில் (sample config), shared buffers-ன் அளவு மொத்த memory-ல் கால் பங்காகக் கட்டுப்படுத்தப்பட்டுள்ளது. ஒவ்வொரு unicorn worker-ம் ஒரு முழுமையான Ruby process ஆகும்; அவற்றுடன் Sidekiq பின்னணி வேலைகளை (background jobs) இயக்குகிறது. எனவே, memory பயன்பாடு என்பது பதிவு செய்யப்பட்ட உறுப்பினர்களின் எண்ணிக்கையை விட, ஒரே நேரத்தில் நடக்கும் கோரிக்கைகளின் (concurrent requests) எண்ணிக்கையையே சார்ந்துள்ளது. சில நூறு உறுப்பினர்களைக் கொண்ட ஒரு அமைதியான forum அதிக பணிச்சுமை கொண்டதல்ல. அந்த server-ல் வேறு என்னென்ன இயங்குகின்றன என்பதே முக்கியமானது. அது ஒரு photo library-ஆக இருந்தால், PhotoPrism மற்றும் Immich ஒப்பீட்டில் உள்ள அளவிடப்பட்ட RAM பயன்பாட்டுத் தரவுகள், Discourse rebuild-ஐ முடிப்பதற்கான போதிய வசதி (headroom) உள்ளதா என்பதை உங்களுக்குத் தெரிவிக்கும்.

ஒரு கட்டுரையில் உள்ள எண்ணைக் கொண்டு server-ன் அளவைத் தீர்மானிக்காதீர்கள்; இதையும் சேர்த்துதான் சொல்கிறேன். உங்கள் தேவையை நீங்களே அளவிடுங்கள்.

free -m
docker stats --no-stream

Swap பயன்பாடு தொடர்ந்து நீடிப்பதும், பக்கங்கள் மெதுவாகத் திறப்பதும் உங்களுக்கு RAM பற்றாக்குறை இருப்பதைக் குறிக்கிறது. Memory பயன்பாடு சீராக இருந்து, பக்கங்கள் மெதுவாகத் திறந்தால், அதற்கு வேறு ஏதோ காரணம் இருக்கலாம். எனவே, பெரிய plan-க்கு மாறுவதற்கு முன் ./launcher logs app-ஐப் படியுங்கள். Server-க்கு வெளியிலிருந்தும் ஒரு கண்காணிப்பைச் சேர்க்கவும். ஏனெனில், அதிகாலை 3 மணிக்கு memory தீர்ந்து ஒரு forum செயலிழந்தால், அது அமைதியாகவே நின்றுவிடும்: தனி host-ல் இயங்கும் Uptime Kuma status monitor, உங்கள் உறுப்பினர்கள் அறிவதற்கு முன்பே உங்களுக்குத் தெரிவித்துவிடும்.

Discourse தவறான தேர்வாக இருக்கும் சூழல்

Discourse என்பது ஒரு பெரிய application ஆகும். இதன் நிறுவல் முறை சிக்கலானது, மேலும் app.yml-ல் உள்ள எந்தவொரு அமைப்பை மாற்றினாலும் முழு application-ஐயும் மீண்டும் கட்டமைக்க (rebuild) வேண்டியிருக்கும். இந்தச் செலவிற்கு ஈடாக, இதில் சிறந்த moderation கருவிகளும், பெரிய அளவிலான தரவுகளைக் கொண்டாலும் சிறப்பாகச் செயல்படும் தேடல் வசதியும் கிடைக்கின்றன. முப்பது பேர் கொண்ட ஒரு குழுவிற்கு உரையாடுவதற்கு ஒரு தளம் தேவை என்றால், அவர்களின் தேவைக்கு இது மிக அதிகமான வளங்களை (machine resources) கோரும் ஒரு மென்பொருளாகும். முதலில் self-hosted forum மென்பொருட்களின் ஒப்பீட்டை வாசிக்கவும். Discourse-ஐ அதன் பெயருக்காகத் தேர்ந்தெடுக்காமல், அது வழங்கும் வசதிகள் உங்கள் தேவைக்கு அவசியமானவை என்பதால் மட்டுமே தேர்ந்தெடுக்கவும்.

FAQ

டொமைன் பெயர் இல்லாமல் VPS-ல் Discourse-ஐ நிறுவ முடியுமா?

முடியாது. Discourse-ன் தற்போதைய கட்டமைப்பு, வெறும் IP முகவரியுடன் இயங்காது என்று குறிப்பிடுகிறது, மேலும் அதற்கு DISCOURSE_HOSTNAME அவசியம். Discourse அந்த hostname-ஐக் கொண்டு முழுமையான இணைப்புகளை (absolute links) உருவாக்குகிறது; எனவே IP முகவரியைப் பயன்படுத்தினால் இணைப்புகள் வேலை செய்யாது மற்றும் certificate வழங்குவதில் சிக்கல் ஏற்படும். தொடங்குவதற்கு முன் ஒரு A record-ஐ உருவாக்கி, அது உங்கள் server முகவரிக்குத் தான் செல்கிறது என்பதை dig +short forum.example.com மூலம் உறுதிப்படுத்தவும்.

நிறுவலை முடிக்க SMTP-ஐ configure செய்ய வேண்டுமா?

ஆகஸ்ட் 2026 நிலவரப்படி, நீங்கள் இதைத் தவிர்க்கலாம். Setup wizard-ல் Discourse ID மூலம் உள்நுழையும் வசதி உள்ளது, மேலும் app.yml கட்டளையில் மின்னஞ்சல் சரிபார்ப்பைத் தவிர்க்கும் வசதி (switch) உள்ளது. ஆரம்பக்கட்ட சோதனைக்கு அப்பால் பயன்படுத்த, SMTP-ஐ configure செய்வது அவசியம்; ஏனெனில் கணக்கு உறுதிப்படுத்தல் (account activation) மற்றும் கடவுச்சொல் மீட்டமைப்பு (password reset) போன்றவை மின்னஞ்சல் மூலமே நடைபெறும். பெரும்பாலான VPS நிறுவனங்கள் outbound port 25-ஐத் தடுப்பதால், port 587 அல்லது 465-ல் authenticated relay-ஐப் பயன்படுத்தவும்.

எனது Discourse rebuild பாதியிலேயே தோல்வியடைந்தது ஏன்?

இதற்கு பெரும்பாலும் நினைவகப் பற்றாக்குறையே (memory) காரணமாகும். Build செய்யும்போது asset compilation-க்கு, இயங்கும் தளத்தை விட அதிக நினைவகம் தேவைப்படும். எனவே, forum-ஐச் சிறப்பாக இயக்கும் ஒரு server-ல் கூட rebuild தோல்வியடையலாம். dmesg கட்டளையில் ruby process தொடர்பான Out of memory: Killed process பிழை தெரிந்தால், swap-ஐச் சேர்க்கவும் (wizard-ன் swapfile 2 GB அளவு கொண்டது) மற்றும் ./launcher rebuild app கட்டளையை மீண்டும் இயக்கவும். ஒருவேளை build YAML பிழையில் நின்றால், அது app.yml கோப்பில் உள்ள indentation பிழையைக் குறிக்கிறது.

Discourse-ஐ எனது சொந்த nginx அல்லது Caddy-க்கு பின்னால் வைக்க வேண்டுமா?

VPS-ல் பிற தளங்களும் இயங்கினால் மட்டுமே இதைச் செய்ய வேண்டும். ஒரு server-ல் Discourse மட்டும் இருந்தால், container-ஐயே port 80 மற்றும் 443-ஐக் கையாள அனுமதிக்கவும்; அதுவே சொந்தமாக certificate-ஐப் பெற்றுக்கொள்ளும், இதனால் சிக்கல்கள் குறையும். பிற தளங்களுடன் பகிரும் பட்சத்தில், templates/web.socketed.template.yml-ஐச் சேர்த்து, expose வரிகளை comment செய்துவிட்டு, /var/discourse/shared/standalone/nginx.http.sock-ல் உள்ள unix socket-க்கு proxy செய்யவும். X-Forwarded-Proto-ஐ அனுப்பவும், இல்லையெனில் HTTPS பக்கத்தில் Discourse http:// இணைப்புகளை உருவாக்கும்.

self-hosted Discourse-ஐ எவ்வாறு backup எடுப்பது?

Admin பகுதியில் உள்ள Backups பக்கத்தைப் பயன்படுத்தவும் அல்லது ./launcher enter app-க்கு பிறகு discourse backup கட்டளையை இயக்கவும். கோப்புகள் host-ல் /var/discourse/shared/standalone/backups/default/ என்ற இடத்தில் சேமிக்கப்படும். பதிவேற்றங்களையும் (uploads) உள்ளடக்கும் அமைப்பை உறுதிப்படுத்தவும், /var/discourse/containers/app.yml கோப்பை அந்த archive-உடன் சேர்த்து நகலெடுத்து, வேறொரு machine-க்கு மாற்றவும். ஏனெனில், தளத்தின் அதே disk-ல் இருக்கும் backup, அந்த disk செயலிழக்கும்போது பயனளிக்காது.