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

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

VPS-ல் Discourse-ஐ நிறுவ, நீங்கள் அந்த project-ன் சொந்த installer-ஐ இயக்க வேண்டும், ஒரு சிறிய wizard-ன் கேள்விகளுக்குப் பதிலளிக்க வேண்டும், பின்னர் build முடியும் வரை காத்திருக்க வேண்டும். Discourse என்பது Rails application, PostgreSQL, Redis மற்றும் nginx ஆகியவற்றை உள்ளடக்கிய ஒரே ஒரு Docker container-ஆகவே வழங்கப்படுகிறது (ships). நீங்கள் பிற்காலத்தில் மாற்றும் அனைத்தும் /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 தொகுக்கப்படுவதால், இயங்கும் தளத்தை விட அதிக memory தேவைப்படும்.
• ஒரு உண்மையான domain name. வழங்கப்பட்ட sample config-ல் இது தெளிவாகக் குறிப்பிடப்பட்டுள்ளது: "Discourse வெறும் IP எண்ணுடன் இயங்காது."
• ஒரு outbound mail path. கணக்குச் சரிபார்ப்பு, கடவுச்சொல் மாற்றம், நிர்வாகி அழைப்புகள் மற்றும் digest மின்னஞ்சல்கள் அனைத்தும் SMTP (simple mail transfer protocol) வழியாகவே அனுப்பப்படுகின்றன.
• host-ல் 80 மற்றும் 443 ஆகிய ports காலியாக இருக்க வேண்டும். நீங்கள் ஏற்கனவே இயக்கும் ஒரு proxy-க்கு பின்னால் Discourse-ஐ வேண்டுமென்றே நகர்த்தினால் ஒழிய, இது கட்டாயம்.

[
  {
    "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-ஐப் பயன்படுத்தப் பரிந்துரைக்கப்படுகிறது. முதல் வரிசையில் உள்ள அளவை நிறுவல் முடிவடைவதற்கான குறைந்தபட்சத் தேவையாகக் கருதவும்; ஒரு சமூகத் தளத்தை இயக்குவதற்குத் தேவையான அளவாக இதைக் கருத வேண்டாம். இந்த இடைவெளி முக்கியமானது, ஏனெனில் 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) சவாலுக்கு 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-ஐ எழுதிவிட்டு, மறுசீரமைப்பை (rebuild) செய்யும்.

நீங்கள் தொடங்குவதற்கு முன் இரண்டு செயல்பாடுகளைத் தெரிந்துகொள்வது அவசியம். 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 செயல்முறை பல நிமிடங்கள் எடுக்கும். முதல் முறை அனைத்து 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 தவறான இடத்தில் இருந்தால், parse error ஏற்பட்டு build தோல்வியடையும், தளம் இயங்காது. இதில் ஒரு சிக்கல் sample கோப்பிலேயே குறிப்பிடப்பட்டுள்ளது. ஒரு password-ஐ quote செய்யாமல் உள்ளே # குறியீட்டைப் பயன்படுத்தினால், அது 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 பக்கத்திலிருந்து ஒரு சோதனைச் செய்தியை (test message) அனுப்பவும். அதே பக்கத்தில் உள்ள Skipped மற்றும் Bounced தாவல்களைச் சரிபார்க்கவும். Discourse அனுப்ப மறுத்த மின்னஞ்சல்கள் மற்றும் relay நிராகரித்த மின்னஞ்சல்கள் அங்குதான் பதிவாகும். மேலும், அவை அதற்கான காரணத்தையும் குறிப்பிடும்; இது logs-ஐப் படிப்பதைக் காட்டிலும் விரைவானது.

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

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

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

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

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

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

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) இணைப்புகளை உருவாக்குவதால், அந்த header இல்லையென்றால் அது HTTPS பக்கத்தில் http:// இணைப்புகளை வழங்கும்; இதனால் browsers அவற்றை mixed content எனக் கருதி தடுக்கும். Container socket முறையில் இயங்கும்போது, TLS-ஐ நிர்வகிக்கும் பொறுப்பு உங்களுடையது. எனவே, Ubuntu 24.04 மற்றும் nginx-ல் Certbot மூலம் certificate-ஐப் பெறவும். நீங்கள் இன்னும் எந்த proxy-ஐப் பயன்படுத்துவது என்று முடிவு செய்யவில்லை என்றால், nginx, Caddy மற்றும் Traefik ஒப்பீடு நீங்கள் மேற்கொள்ளும் மாற்றங்களை விளக்குகிறது.

Rebuilds, upgrades மற்றும் நீங்கள் பயன்படுத்தும் கட்டளைகள்

cd /var/discourse
./launcher rebuild app

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

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

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

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

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

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

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

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

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

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

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

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

மேலும், இந்த archive அது பாதுகாக்கும் தளத்தின் அதே வட்டில் (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 பணிகளைச் செய்கிறது. எனவே, memory பயன்பாடு என்பது பதிவு செய்யப்பட்ட உறுப்பினர்களின் எண்ணிக்கையை விட, ஒரே நேரத்தில் வரும் கோரிக்கைகளின் (concurrent requests) எண்ணிக்கையையே சார்ந்துள்ளது. சில நூறு உறுப்பினர்களைக் கொண்ட ஒரு அமைதியான forum அதிக பணிச்சுமை கொண்டதல்ல.

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

free -m
docker stats --no-stream

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

Discourse பொருத்தமற்றதாக இருக்கும் சூழல்கள்

Discourse என்பது ஒரு பெரிய application ஆகும். இதன் நிறுவல் முறை சிக்கலானது, மேலும் app.yml-ல் உள்ள எந்தவொரு அமைப்பை மாற்றினாலும் முழுமையாக rebuild செய்ய வேண்டியிருக்கும். இந்த கூடுதல் உழைப்பிற்கு ஈடாக, இதில் சிறந்த moderation கருவிகளும், பெரிய அளவிலான தரவுகளைக் கொண்டிருந்தாலும் சிறப்பாகச் செயல்படும் தேடல் வசதியும் கிடைக்கின்றன. முப்பது பேர் கொண்ட ஒரு குழுவிற்கு உரையாடுவதற்கு ஒரு தளம் தேவை என்றால், அந்த உரையாடலின் தேவைக்கு இது மிக அதிகமான வளங்களை (machine resources) கோரும் ஒரு மென்பொருளாகும். முதலில் சுயமாக ஹோஸ்ட் செய்யப்படும் 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 செய்வது அவசியம், ஏனெனில் கணக்குச் சரிபார்ப்பு மற்றும் கடவுச்சொல் மாற்றங்கள் மின்னஞ்சல் மூலமே நடைபெறும். பெரும்பாலான VPS நிறுவனங்கள் outbound port 25-ஐத் தடுப்பதால், port 587 அல்லது 465-ல் authenticated relay-ஐப் பயன்படுத்தவும்.

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

இதற்கு பெரும்பாலும் நினைவகப் பற்றாக்குறையே (memory) காரணமாக இருக்கும். Build செய்யும்போது asset compilation-க்கு, இயங்கும் தளத்தை விட அதிக நினைவகம் தேவைப்படும். எனவே, forum-ஐச் சிறப்பாக இயக்கும் ஒரு server-ல் கூட rebuild தோல்வியடையலாம். dmesg கட்டளையில் Out of memory: Killed process ஒரு ruby 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-க்கு நகர்த்தவும். ஏனெனில், தளத்தின் அதே வட்டில் இருக்கும் backup, வட்டு செயலிழக்கும்போது பயனளிக்காது.