Docker वापरून VPS वर Discourse कसे स्थापित करावे

VPS वर Discourse स्थापित करा: एक कंटेनर, एक configuration file

VPS वर Discourse स्थापित करण्यासाठी प्रकल्पाचे स्वतःचे installer चालवा, छोट्या wizard मधील प्रश्नांची उत्तरे द्या आणि build पूर्ण होईपर्यंत प्रतीक्षा करा. Discourse एकाच Docker container मध्ये Rails application, PostgreSQL, Redis आणि nginx देते. नंतर तुम्ही करणार असलेले सर्व बदल एका file मध्ये असतात, /var/discourse/containers/app.yml, आणि प्रत्येक बदल site वर लागू करण्यासाठी rebuild आवश्यक असतो.

अधिकृत install प्रक्रिया discourse_docker आहे: एक launcher shell script आणि YAML templates चा संच. तुम्ही स्वतः तयार केलेल्या Compose file ला Discourse support करत नाही. तसेच container हाताने वेगळ्या भागांत विभागण्यासाठी बनवलेले नाही. तुम्हाला Docker Compose वापरून VPS वर services चालवण्याची सवय असल्यास, येथे रचना वेगळी आहे अशी अपेक्षा ठेवा. येथे docker compose up -d नाही आणि ./launcher rebuild app हाच deploy आहे.

Discourse सुरू करण्यापूर्वी आवश्यक बाबी

चार आवश्यकता अनेकदा दुर्लक्षित राहतात. Login पृष्ठापर्यंत पोहोचण्यापूर्वीच त्यांपैकी प्रत्येकामुळे अडथळा येऊ शकतो.

• Memory. एका container मध्ये PostgreSQL, Redis, Sidekiq आणि Ruby web server चालतात. Build step मध्ये assets compile केले जातात आणि त्यासाठी चालू असलेल्या site पेक्षा अधिक memory आवश्यक असते.
• खरे domain name. वितरित sample config मध्ये हे स्पष्टपणे नमूद आहे: "Discourse bare IP number सह काम करणार नाही."
• Outbound mail path. Account activation, password resets, admin invites आणि digest mail हे सर्व SMTP (simple mail transfer protocol) द्वारे पाठवले जातात.
• Host वरील ports 80 आणि 443 मोकळे असणे आवश्यक आहे. तुम्ही Discourse आधीपासून चालू असलेल्या proxy मागे जाणीवपूर्वक ठेवत असाल, तर ही अट लागू होत नाही.

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

अधिकृत install document मध्ये swap सह 1 GB RAM आणि 10 GB disk ही किमान आवश्यकता दिली आहे. तसेच 2 GB RAM आणि 20 GB disk ची शिफारस केली आहे. पहिल्या ओळीतील आकडे installer पूर्ण होण्यासाठी आवश्यक असलेली क्षमता दर्शवतात; community चालवण्यासाठी अपेक्षित क्षमता नव्हे. हा फरक महत्त्वाचा आहे, कारण memory peak traffic मुळे नव्हे तर build मुळे निर्माण होतो.

स्थापना करण्यापूर्वी domain सर्व्हरकडे निर्देशित करा

तुम्ही वापरणार असलेल्या hostname साठी A record तयार करा आणि नंतर तो सर्व्हरवरूनच पडताळा.

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

दोन्ही commands ने समान address दाखवला पाहिजे. ते समान असणे आवश्यक आहे, कारण setup wizard तुमच्या hostname विरुद्ध connection test चालवतो. अजूनही दुसऱ्या ठिकाणी निर्देशित करणारा record ही चाचणी अयशस्वी करतो. दोन मिनिटांपूर्वी तयार केलेला record अजूनही cache मध्ये असू शकतो. त्यामुळे wizard वर उपाय शोधण्याऐवजी जुना TTL (time to live) संपेपर्यंत प्रतीक्षा करा.

Record CDN मार्फत proxied ठेवायचा की नाही, हे आता ठरवा. Proxied record तुमचा server address लपवतो. त्यामुळे container ची certificate request अयशस्वी होते, कारण ACME (automatic certificate management environment) challenge चे उत्तर Discourse ऐवजी proxy देतो. पहिल्या install साठी record unproxied ठेवा.

अधिकृत installer चालवा

एका command ने git install होते, Docker च्या स्वतःच्या install script द्वारे Docker install होते, discourse_docker हे /var/discourse मध्ये clone होते आणि setup wizard सुरू होतो.

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

सर्व्हरवर Docker आधीच install असल्यास आणि प्रत्येक पायरी पाहायची असल्यास, हेच काम manually करा.

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

हे root म्हणून चालवा. सामान्य user म्हणून सुरू केल्यास discourse-setup त्वरित This script must be run as root. Please sudo or log in as root first. सह थांबते. सर्व्हरवर Docker नसल्यास ते Docker is not installed. Please install Docker first. सह थांबते, कारण manual clone तुमच्यासाठी काहीही install करत नाही.

सेटअप विझार्ड काय विचारतो आणि काय लिहितो

August 2026 पर्यंत discourse-setup हा एक thin wrapper आहे. तो host network वापरून आणि Docker socket mount करून discourse/setup-wizard:release हे container म्हणून चालवतो. त्यामुळे विझार्ड ज्या मशीनचे configuration करत आहे तिची तपासणी करू शकतो. तो hostname आणि admin email addresses विचारतो. त्यानंतर तो तुमचा SMTP block विचारतो. तो containers/app.yml लिहितो आणि नंतर पुन्हा build करतो.

सुरू करण्यापूर्वी दोन बाबी जाणून घेणे उपयुक्त ठरेल. मशीनमध्ये memory कमी असेल आणि swap नसेल, तर विझार्ड थांबतो आणि swap तयार करण्याचा पर्याय देतो. त्यानंतर wrapper 2 GB आकाराची /swapfile तयार करतो, ती /etc/fstab मध्ये जोडतो, /etc/sysctl.d/30-discourse-swap.conf मध्ये vm.swappiness = 10 सेट करतो आणि विझार्ड पुन्हा सुरू करतो. विझार्ड पूर्ण झाल्यावर तो Rebuilding app in 5 seconds (Ctrl+C to cancel)... print करतो आणि host वर ./launcher rebuild app चालवतो. छोट्या VPS वर हा build पूर्ण होण्यासाठी काही मिनिटे लागतात. पहिला build सर्वात धीमा असतो, कारण प्रत्येक asset सुरुवातीपासून compile केला जातो.

काही समस्या आल्यास महत्त्वाचे flags ./discourse-setup --help मध्ये सूचीबद्ध केलेले आहेत. --skip-rebuild build न करता configuration लिहितो. --skip-connection-test DNS आणि port checks वगळतो. --skip-connection-test फक्त test का fail होत आहे हे आधीच माहीत असल्यास वापरा. उदाहरणार्थ, host तुमच्या नियंत्रणाखालील network firewall मागे असल्यास त्याचा वापर करता येतो.

पहिल्या 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 हा site ज्या address वर प्रतिसाद देतो तो address आहे. Discourse त्यावरून links तयार करतो. त्यामुळे चुकीची value दिल्यास site एकदा load होईल आणि नंतर तुम्हाला दुसऱ्या ठिकाणी पाठवेल. DISCOURSE_DEVELOPER_EMAILS ही comma-separated list आहे. First signup वेळी त्या addresses ना आपोआप admin अधिकार मिळतात. त्यात तुमचा स्वतःचा address ठेवा आणि त्याच्याने register करा. अशा प्रकारे पहिला admin account तयार होतो.

फाइलमध्ये तुमचा SMTP password plain text मध्ये साठवला जातो. त्यामुळे sudo chmod 700 /var/discourse/containers वापरून directory चे permissions मर्यादित करा. ही YAML फाइलही आहे. त्यामुळे whitespace हा configuration चाच भाग आहे. चुकीच्या indentation मुळे build parse error सह अपयशी ठरतो आणि site उपलब्ध होत नाही. Sample file मध्येच एक महत्त्वाचा trap नमूद आहे. Unquoted password मधील # पासून comment सुरू होतो. त्यामुळे # असलेला कोणताही password quotes मध्ये लिहा.

बहुतेक इंस्टॉलेशन थांबवणारे पाऊल म्हणजे ईमेल

August 2026 पर्यंत wizard मध्ये SMTP वगळून त्याऐवजी Discourse ID login वापरण्याची सुविधा आहे. app.yml मध्ये त्याला अनुरूप DISCOURSE_SKIP_EMAIL_SETUP switch देखील आहे. तेथे त्याचे वर्णन email setup validation वगळणे असे केले आहे. सॉफ्टवेअरची प्राथमिक पाहणी करण्यासाठी ईमेल setup वगळणे योग्य ठरू शकते. मात्र community साठी हा पर्याय योग्य नाही. Outbound mail नसल्यास कोणीही account activate किंवा password reset करू शकत नाही.

व्यवहारातील अडचण अशी आहे की बहुतेक VPS providers outbound port 25 block करतात. त्यामुळे त्या server वर चालणारा साधा mail server mail deliver करू शकत नाही. port 587 वर authenticated relay वापरा. पर्याय म्हणून implicit TLS (transport layer security) सह port 465 वापरा. port 465 साठी DISCOURSE_SMTP_FORCE_TLS: true सेट करा. नमुना configuration मध्ये त्या port साठी याची शिफारस केली आहे. Rebuild करण्यापूर्वी host वरून connectivity तपासा.

nc -vz smtp.example.com 587

योग्य निकाल म्हणजे succeeded! ने समाप्त होणारी एकच ओळ. एखादी command बराच वेळ थांबून नंतर timeout झाली, तर तुमच्या VPS मधून बाहेर जाणाऱ्या मार्गावर तो port block आहे. Discourse मधील कोणतीही setting हे दुरुस्त करू शकत नाही. Provider ने अनुमती दिलेल्या port वर जा किंवा provider कडे तो port open करण्याची विनंती करा.

Site सुरू झाल्यावर Admin मधील Email page वरून test message पाठवा. त्यानंतर त्याच page वरील Skipped आणि Bounced tabs तपासा. Discourse ने पाठवण्यास नकार दिलेले mail आणि relay ने reject केलेले mail यांची नोंद याच tabs मध्ये असते. त्यामध्ये कारणही दिलेले असते. त्यामुळे logs वाचण्यापेक्षा समस्या अधिक लवकर समजते.

TLS: कंटेनरला त्याचे स्वतःचे प्रमाणपत्र मिळू द्या

जर Discourse कडे 80 आणि 443 हे पोर्ट असतील, तर त्याची अंगभूत प्रमाणपत्र issuance वापरा. वर दाखवलेल्या दोन SSL template ओळींच्या सुरुवातीचे comment चिन्ह काढा आणि नंतर rebuild करा. Template acme.sh नियंत्रित करते, प्रमाणपत्रे shared volume मध्ये /shared/ssl अंतर्गत साठवते, कंटेनरमध्ये ठरावीक वेळापत्रकानुसार त्यांचे renewal करते आणि Discourse मध्ये HTTPS सक्तीचे करते.

हे कार्य करण्यासाठी port 80 इंटरनेटवरून पोहोचण्यायोग्य राहणे आवश्यक आहे, कारण HTTP challenge चे उत्तर तेथे दिले जाते. फक्त 443 ला परवानगी देणाऱ्या firewall मुळे build पूर्ण होईल, पण प्रमाणपत्र जारी होणार नाही. Rebuild झाल्यानंतर लगेच ./launcher logs app वापरून परिणाम तपासा.

nginx किंवा Caddy समोर ठेवावे का?

VPS वर Discourse ही एकमेव web सेवा असेल, तर तसे करू नका. कंटेनरमध्ये आधीच योग्य प्रकारे tune केलेला nginx चालतो. दुसरा proxy जोडल्यास आणखी एक hop, renewal करावे लागणारे दुसरे प्रमाणपत्र आणि header-संबंधित त्रुटींचा नवीन स्रोत निर्माण होतो.

त्याच VPS वर इतर sites दिल्या जात असतील, तेव्हा proxy समोर ठेवा. templates list मध्ये templates/web.socketed.template.yml जोडा, expose या दोन्ही lines comment out करा आणि दोन SSL templates देखील comment out ठेवाच. त्यानंतर कंटेनर /var/discourse/shared/standalone/nginx.http.sock येथे unix socket वर listen करेल आणि कोणतेही ports वापरणार नाही. त्यामुळे 80 आणि 443 तुमच्या proxy साठी मोकळे राहतील.

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 देखील optional नाही. Discourse absolute links लिहिते. त्यामुळे तो header नसल्यास HTTPS page वर http:// links तयार होतात आणि browsers त्यांना mixed content म्हणून block करतात. कंटेनर socket वर चालू केल्यानंतर TLS ची जबाबदारी तुमची राहते. त्यामुळे host वर Ubuntu 24.04 आणि nginx वर Certbot वापरून certificate issue करा. अद्याप proxy ठरवलेला नसेल, तर nginx, Caddy आणि Traefik ची तुलना या निवडीतील trade-offs स्पष्ट करते.

पुन्हा build करणे, upgrades आणि तुम्ही प्रत्यक्षात वापरणार असलेल्या commands

cd /var/discourse
./launcher rebuild app

rebuild चालू container नष्ट करतो, app.yml पासून नवीन container तयार करतो आणि तो सुरू करतो. संपूर्ण build प्रक्रियेदरम्यान site offline राहते. त्यामुळे प्रत्येक configuration बदल काही मिनिटांच्या नियोजित downtime प्रमाणे हाताळा.

फक्त env: अंतर्गत मूल्ये बदलण्यासाठी हे आवश्यक नाही. ./launcher destroy app && ./launcher start app तुम्ही आधीच build केलेल्या image मधून container पुन्हा तयार करतो. यासाठी काही सेकंद लागतात. templates: किंवा hooks: अंतर्गत कोणताही बदल image मध्ये बदल करतो. त्यामुळे पूर्ण rebuild आवश्यक असतो.

Upgrades दोन मार्गांनी येतात. /admin/upgrade येथे web interface मधून point releases लागू करता येतात. हे web interface build दरम्यान app.yml द्वारे clone केलेल्या docker_manager plugin कडून उपलब्ध होते. Base image किंवा templates मधील बदल git मधून येतात.

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

लहान servers वर rebuild दरम्यान अडचणी येतात, कारण asset compilation ही संपूर्ण system मधील memory वापराची कमाल पातळी असते. Build मध्येच थांबतो आणि dmesg मध्ये ruby process चे नाव देणारी Out of memory: Killed process सारखी ओळ दिसते, तर site आधी व्यवस्थित चालू असूनही build दरम्यान memory संपली आहे. Swap जोडा आणि rebuild पुन्हा चालवा.

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

logs container चे output दाखवतो, enter container मध्ये shell उघडतो आणि cleanup 24 तासांपेक्षा जास्त काळापासून थांबलेले containers काढून टाकतो. cleanup वेळोवेळी चालवा, कारण प्रत्येक rebuild नंतर जुना container शिल्लक राहतो आणि छोट्या VPS वरील disk space हळूहळू संपते.

बॅकअप आणि बॅकअपमध्ये नसलेली फाइल

Admin मधील Backups पृष्ठावरून बॅकअप घ्या. संग्रह होस्टवरील /var/discourse/shared/standalone/backups/default/ येथे तयार होतो. हेच काम shell मधूनही चालवता येते.

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

discourse restore <filename> ही प्रक्रिया उलटवते. discourse enable_restore चालवेपर्यंत restore नाकारले जातात. एखाद्या चुकीच्या command मुळे चालू forum overwrite होऊ नये, म्हणून हा सुरक्षा अडथळा आहे.

दोन त्रुटी तुम्हालाच दूर कराव्या लागतात. संग्रहात database असतो. Uploads समाविष्ट करणारी backup setting सुरू असेल, तेव्हाच त्यात uploaded files असतात. त्यामुळे त्यावर विश्वास ठेवण्यापूर्वी ही setting तपासा. त्यात app.yml कधीही नसते. म्हणून नवीन VPS वर restore करताना hostname आणि SMTP block पुन्हा आवश्यक असतात. ती फाइलसुद्धा सर्व्हरच्या बाहेर कॉपी करा.

संग्रह त्या साइटचे संरक्षण करत असलेल्या त्याच disk वरही असतो. तो backup नाही. ठरावीक वेळापत्रकानुसार तो दुसऱ्या ठिकाणी कॉपी करा.

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

RAM मध्ये व्यस्त फोरमची किंमत

Bootstrap ला आढळलेल्या memory आणि CPU च्या आधारे UNICORN_WORKERS आणि db_shared_buffers सेट करतो. नमुना configuration एकूण memory च्या एक-चतुर्थांशपर्यंत shared buffers मर्यादित करते. प्रत्येक unicorn worker ही स्वतंत्र पूर्ण Ruby process असते. Sidekiq त्यांच्यासोबत background jobs चालवतो. त्यामुळे memory वापर registered members च्या संख्येऐवजी concurrent requests नुसार बदलतो. काहीशे members असलेला शांत forum मोठा workload नसतो.

या लेखातील आकड्यासह कोणत्याही लेखातील आकड्यावरून server चा आकार ठरवू नका. स्वतःचे मोजमाप करा.

free -m
docker stats --no-stream

Swap सतत वापरात असणे आणि pages संथ असणे याचा अर्थ RAM अपुरी आहे. Memory स्थिर असून pages संथ असतील, तर कारण सहसा वेगळे असते. त्यामुळे मोठा plan खरेदी करण्यापूर्वी ./launcher logs app वाचा. बाहेरूनही एक check जोडा. 3am वाजता forum ची memory संपली, तर तो शांतपणे बंद पडू शकतो. स्वतंत्र host वर चालणारा self-hosted Uptime Kuma status monitor तुमच्या members ना कळण्यापूर्वी तुम्हाला माहिती देतो.

Discourse चुकीचा पर्याय कधी ठरतो

Discourse हे मोठे अॅप्लिकेशन आहे. त्याची installation प्रक्रिया जड आहे. app.yml मध्ये असलेल्या प्रत्येक setting साठी rebuild cycle चालवावी लागते. या खर्चाच्या बदल्यात प्रभावी moderation tooling आणि archive मोठा झाल्यावरही कार्यरत राहणारी search सुविधा मिळते. चर्चा करण्यासाठी जागा हवी असलेल्या तीस लोकांसाठी हे त्यांच्या गरजेपेक्षा अधिक मोठे machine आहे. आधी self-hosted forum software ची तुलना वाचा. Discourse निवडण्याचे कारण त्याची कार्ये असावीत, केवळ त्याचे नाव आधीपासून परिचित आहे म्हणून नव्हे.

FAQ

मी domain name शिवाय VPS वर Discourse install करू शकतो का?

नाही. उपलब्ध configuration मध्ये bare IP number वर Discourse काम करणार नाही, असे स्पष्ट केले आहे आणि DISCOURSE_HOSTNAME आवश्यक आहे. Discourse या hostname वरून absolute links तयार करते. त्यामुळे तिथे IP address दिल्यास links चुकीचे होतात आणि certificate issuance थांबते. सुरुवात करण्यापूर्वी A record तयार करा आणि तो तुमच्या server च्या address कडे resolve होतो का, हे dig +short forum.example.com ने तपासा.

Install पूर्ण करण्यासाठी SMTP configure करणे आवश्यक आहे का?

August 2026 पासून ते वगळता येते. Setup wizard त्याऐवजी Discourse ID logins देतो आणि app.yml मध्ये email setup validation वगळणारा switch आहे. मात्र केवळ प्राथमिक पाहणीपलीकडे वापरासाठी ते configure करा, कारण account activation आणि password resets दोन्ही email द्वारे पाठवले जातात. Port 587 किंवा 465 वर authenticated relay वापरा, कारण बहुतेक VPS providers outbound port 25 block करतात.

Discourse rebuild मध्ये मध्येच fail का झाले?

सामान्य कारण memory हे आहे. Build दरम्यान asset compilation साठी चालू site पेक्षा अधिक memory लागते. त्यामुळे forum व्यवस्थित serve करणारा box देखील rebuild करताना fail होऊ शकतो. dmesg मध्ये ruby process चे नाव असलेले Out of memory: Killed process दिसत असल्यास swap जोडा; wizard ची स्वतःची swapfile 2 GB असते. त्यानंतर ./launcher rebuild app पुन्हा चालवा. YAML error मुळे build थांबत असल्यास app.yml मधील indentation mistake हे कारण असते.

Discourse माझ्या nginx किंवा Caddy च्या मागे ठेवावे का?

VPS वर इतर sites देखील serve होत असतील तरच. Server वर Discourse एकटाच असल्यास container ला ports 80 आणि 443 ठेवू द्या आणि त्याला स्वतःचे certificate issue करू द्या. त्यामुळे व्यवस्थापित कराव्या लागणाऱ्या घटकांची संख्या कमी राहते. Machine share करण्यासाठी templates/web.socketed.template.yml जोडा, expose lines comment out करा आणि /var/discourse/shared/standalone/nginx.http.sock येथील unix socket कडे proxy करा. X-Forwarded-Proto पुढे पाठवा. अन्यथा HTTPS page वर Discourse http:// links तयार करेल.

Self-hosted Discourse चा backup कसा घ्यावा?

Admin मधील Backups page वापरा किंवा ./launcher enter app नंतर discourse backup चालवा. Archives host वर /var/discourse/shared/standalone/backups/default/ येथे ठेवले जातात. Uploads समाविष्ट करणारे setting enabled आहे, याची खात्री करा. /var/discourse/containers/app.yml archive सोबत copy करा आणि दोन्ही दुसऱ्या machine वर हलवा. Site ज्या disk वर आहे त्याच disk वरील backup त्या backup ची गरज निर्माण करणाऱ्या failure मधून सुरक्षित राहत नाही.