Jinsi ya kusakinisha Discourse kwenye VPS na Docker

Kusakinisha Discourse kwenye VPS: kontena moja, faili moja la usanidi

Ili kusakinisha Discourse kwenye VPS, unaendesha kisakinishi cha mradi wenyewe, unajibu maswali machache ya mchawi wa usanidi, na unasubiri ujenzi ukamilike. Discourse inatolewa kama kontena moja la Docker linalobeba programu ya Rails, PostgreSQL, Redis na nginx. Kila kitu utakachobadilisha baadaye kinapatikana katika faili moja, /var/discourse/containers/app.yml, na kila mabadiliko hufika kwenye tovuti kupitia ujenzi upya (rebuild).

Usakinishaji rasmi ni discourse_docker: hati ya shell ya launcher pamoja na seti ya templeti za YAML. Discourse haitumii faili ya Compose unayoiandika wewe mwenyewe, na kontena hilo halijakusudiwa kutenganishwa kwa mikono. Ikiwa umezoea kuendesha huduma kwenye VPS kwa kutumia Docker Compose, tarajia muundo tofauti. Hakuna docker compose up -d hapa, na ./launcher rebuild app ndiyo njia ya kupeleka (deploy) mabadiliko.

Mahitaji ya Discourse kabla ya kuanza

Kuna mahitaji manne ambayo huwasumbua watu wengi, na kila moja hujitokeza kabla hata hujafika kwenye ukurasa wa kuingia (login).

• Kumbukumbu (RAM). Kontena moja huendesha PostgreSQL, Redis, Sidekiq na seva ya wavuti ya Ruby. Hatua ya ujenzi (build) hukusanya (compile) faili za programu na inahitaji kumbukumbu nyingi zaidi kuliko tovuti inayoendelea kufanya kazi.
• Jina halisi la kikoa (domain name). Usanidi wa mfano uliotolewa unasema wazi: "Discourse haitafanya kazi kwa kutumia namba ya IP pekee."
• Njia ya kutuma barua pepe (outbound mail). Uamilishaji wa akaunti, uwekaji upya wa nywila, mialiko ya admin na barua pepe za muhtasari (digest) zote hutumwa kupitia SMTP (simple mail transfer protocol).
• Port 80 na 443 lazima ziwe wazi kwenye seva, isipokuwa kama utaamua kwa makusudi kuweka Discourse nyuma ya proxy unayoitumia tayari.

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

Hati rasmi ya usakinishaji inaweka kiwango cha chini cha 1 GB ya RAM pamoja na swap na 10 GB ya diski, na inapendekeza 2 GB ya RAM pamoja na 20 GB ya diski. Soma mstari wa kwanza kama namba itakayokamilisha usakinishaji, si namba unayotaka ili kuendesha jamii ya watumiaji. Tofauti hii ni muhimu kwa sababu kilele cha matumizi ya kumbukumbu hutokea wakati wa ujenzi (build), si wakati wa trafiki ya watumiaji.

Elekeza domain kwenye seva kabla ya kusakinisha

Tengeneza A record kwa ajili ya hostname utakayotumia, kisha ithibitishe kutoka kwenye seva yenyewe.

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

Amri zote mbili lazima zionyeshe anwani ileile. Ni lazima zikubaliane kwa sababu wizard ya usanidi hufanya jaribio la muunganisho dhidi ya hostname yako, na record inayoelekeza kwingine itafanya jaribio hilo kufeli. Record uliyotengeneza dakika mbili zilizopita inaweza kuwa bado imehifadhiwa kwenye cache, kwa hivyo subiri TTL (time to live) ya zamani ipite badala ya kupambana na wizard.

Amua sasa kama record hiyo itapitia CDN. Record inayopitia proxy huficha anwani ya seva yako, na ombi la cheti cha container litafeli, kwa sababu changamoto ya ACME (automatic certificate management environment) hujibiwa na proxy badala ya Discourse. Acha record hiyo bila proxy kwa ajili ya usakinishaji wa kwanza.

Endesha kisakinishi rasmi

Amri moja husakinisha git, husakinisha Docker kwa kutumia script rasmi ya usakinishaji ya Docker, hufanya clone ya discourse_docker kwenye /var/discourse, na kuanzisha wizard ya usanidi.

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

Ikiwa Docker tayari ipo kwenye seva na ungependa kuona kila hatua, fanya kazi hiyo hiyo kwa mikono.

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

Endesha kama root. Ikianzishwa kama mtumiaji wa kawaida, discourse-setup husimama mara moja ikiwa na This script must be run as root. Please sudo or log in as root first.. Bila Docker kwenye seva, husimama ikiwa na Docker is not installed. Please install Docker first., kwa sababu clone ya mikono haikusakinishi chochote.

Mambo yanayoulizwa na mchawi wa usanidi, na anayoyaandika

Kufikia Agosti 2026 discourse-setup ni kanga nyepesi tu. Inaendesha discourse/setup-wizard:release kama kontena kwa kutumia mtandao wa seva (host network) na Docker socket iliyopachikwa, ili mchawi aweze kukagua mashine anayoisanidi. Inaomba jina la mwenyeji (hostname) na anwani za barua pepe za msimamizi, kisha inakuomba maelezo ya SMTP. Inaandika containers/app.yml, kisha inajenga upya.

Tabia mbili zinafaa kujulikana kabla ya kuanza. Ikiwa mashine haina kumbukumbu ya kutosha na haina swap, mchawi husimama na kutoa ofa ya kuitengeneza: kanga hiyo hutengeneza /swapfile ya 2 GB, inaiongeza kwenye /etc/fstab, inaweka vm.swappiness = 10 ndani ya /etc/sysctl.d/30-discourse-swap.conf, na kuanzisha mchawi tena. Mchawi anapomaliza, huchapisha Rebuilding app in 5 seconds (Ctrl+C to cancel)... na kuendesha ./launcher rebuild app kwenye seva. Ujenzi huo huchukua dakika kadhaa kwenye VPS ndogo, na ujenzi wa kwanza ndio wa polepole zaidi kwa sababu kila rasilimali hukusanywa (compile) kuanzia mwanzo.

./discourse-setup --help inaorodhesha bendera (flags) muhimu wakati kitu kinapoharibika. --skip-rebuild huandika usanidi bila kujenga, na --skip-connection-test huruka ukaguzi wa DNS na port. Tumia --skip-connection-test tu wakati tayari unajua kwa nini jaribio linashindwa, kwa mfano wakati seva iko nyuma ya firewall ya mtandao unayoimiliki.

Soma app.yml kabla ya ujenzi wa kwanza

Mchawi (wizard) huandika faili ambalo sasa ni jukumu lako kulisimamia. Lifungue kwa kutumia sudo nano /var/discourse/containers/app.yml. Hizi ndizo sehemu zinazoamua karibu kila kitu.

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 ni anwani ambayo tovuti hujibu kupitia hiyo, na Discourse hujenga viungo vyake kulingana na anwani hiyo, kwa hivyo thamani isiyo sahihi itakupa tovuti inayopakia mara moja kisha kukupeleka mahali pengine. DISCOURSE_DEVELOPER_EMAILS ni orodha iliyotenganishwa kwa koma, na anwani hizo huwa admin moja kwa moja wakati wa usajili wa kwanza. Weka anwani yako mwenyewe hapo na ujisajili nayo, kwa sababu ndivyo akaunti ya kwanza ya admin inavyoundwa.

Faili hili huhifadhi nenosiri lako la SMTP katika maandishi wazi (plain text), kwa hivyo zuia saraka hiyo kwa kutumia sudo chmod 700 /var/discourse/containers. Pia ni YAML, ambayo inamaanisha nafasi nyeupe (whitespace) ni usanidi: ufunguo uliopangwa vibaya husababisha ujenzi kufeli na hitilafu ya uchanganuzi (parse error) na kukuacha bila tovuti. Mtego mmoja umeandikwa katika faili la sampuli lenyewe. # ndani ya nenosiri lisilowekwa kwenye alama za kunukuu huanzisha maoni (comment), kwa hivyo weka kwenye alama za kunukuu nenosiri lolote lenye alama hiyo.

Baruapepe ndiyo hatua inayokwamisha usakinishaji mwingi

Kufikia Agosti 2026, mchawi wa usakinishaji hukuruhusu kuruka SMTP na kutumia kuingia kwa Discourse ID badala yake, na app.yml ina swichi inayolingana ya DISCOURSE_SKIP_EMAIL_SETUP, inayoelezewa hapo kama kuruka uthibitishaji wa usanidi wa baruapepe. Kuruka hatua hii ni sawa kwa ajili ya kuangalia programu kwa mara ya kwanza. Ni chaguo mbaya kwa jumuiya, kwa sababu bila baruapepe ya kutoka, hakuna mtu anayeweza kuamilisha akaunti au kuweka upya nenosiri.

Tatizo la kivitendo ni kwamba watoa huduma wengi wa VPS huzuia port 25 ya kutoka, kwa hivyo seva ya kawaida ya baruapepe kwenye mashine hiyo haitaleta ujumbe. Tumia relay iliyothibitishwa kwenye port 587, au kwenye 465 yenye TLS (transport layer security) ya moja kwa moja. Kwa 465, weka DISCOURSE_SMTP_FORCE_TLS: true, ambayo usanidi wa mfano unapendekeza kwa port hiyo. Jaribu uwezo wa kufikia (reachability) kutoka kwa host kabla ya kujenga upya.

nc -vz smtp.example.com 587

Matokeo mazuri ni mstari mmoja unaoishia na succeeded!. Amri inayokwama na kisha kuisha muda (times out) inamaanisha kuwa port imezuiwa kwenye njia ya kutoka ya VPS yako, na hakuna mpangilio wa Discourse unaoweza kurekebisha hilo. Hamia kwenye port ambayo mtoa huduma wako anaruhusu, au mwombe mtoa huduma aifungue.

Tovuti inapokuwa hewani, tuma ujumbe wa majaribio kutoka ukurasa wa Email katika Admin, kisha soma vichupo vya Skipped na Bounced kwenye ukurasa huo huo. Vichupo hivyo ndipo Discourse hurekodi baruapepe iliyokataa kutuma na baruapepe iliyokataliwa na relay, na huonyesha sababu, jambo ambalo ni la haraka zaidi kuliko kusoma logi.

TLS: acha container ipate cheti chake yenyewe

Ikiwa Discourse inamiliki port 80 na 443, tumia utaratibu wake wa ndani wa kutoa vyeti. Ondoa alama ya maoni kwenye mistari miwili ya template ya SSL iliyoonyeshwa hapo juu, kisha fanya rebuild. Template hiyo inaendesha acme.sh, inahifadhi vyeti kwenye shared volume chini ya /shared/ssl, inavihuisha kwa ratiba ndani ya container, na inaweka Discourse kulazimisha HTTPS.

Port 80 lazima ibaki inafikika kutoka kwenye Internet ili hili lifanikiwe, kwa sababu HTTP challenge hujibiwa hapo. Firewall inayoruhusu 443 pekee itakupa build inayokamilika lakini cheti hakitawahi kutolewa. Angalia matokeo kwa kutumia ./launcher logs app mara tu baada ya rebuild.

Je, unapaswa kuweka nginx au Caddy mbele?

Ikiwa Discourse ndiyo huduma pekee ya wavuti kwenye VPS, usifanye hivyo. Kontena hilo tayari linaendesha nginx iliyosanidiwa vyema, na proksi ya pili huongeza hatua ya ziada, cheti kingine cha kuhuisha, na chanzo kipya cha hitilafu za header.

Iweke mbele ikiwa VPS hiyo hiyo inahudumia tovuti nyingine. Ongeza templates/web.socketed.template.yml kwenye orodha ya templates, toa maoni (comment out) kwenye mistari yote miwili ya expose, na uache templates mbili za SSL zikiwa zimefungwa kwa maoni. Kontena hilo kisha litasikiliza kwenye unix socket katika /var/discourse/shared/standalone/nginx.http.sock na halitashikilia port yoyote, jambo linaloacha port 80 na 443 wazi kwa proksi yako mwenyewe.

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;
  }
}

Koloni la mwisho baada ya .sock ni sehemu ya sintaksia ya unix socket ya nginx, na sudo nginx -t hukataa usanidi huo bila koloni hilo. X-Forwarded-Proto si ya hiari pia. Discourse huandika viungo kamili (absolute links), kwa hivyo bila header hiyo hutoa viungo vya http:// kwenye ukurasa wa HTTPS, na vivinjari huvizuia kama maudhui mchanganyiko (mixed content). Kontena likiwa kwenye socket, TLS inakuwa jukumu lako, kwa hivyo toa cheti kwenye host kwa kutumia Certbot kwenye Ubuntu 24.04 na nginx. Ikiwa bado hujaamua proksi ya kutumia, ulinganisho wa nginx, Caddy na Traefik unaelezea mabadilishano unayofanya.

Ujenzi upya, maboresho na amri utakazozitumia kwa vitendo

cd /var/discourse
./launcher rebuild app

rebuild huharibu container inayofanya kazi, huandaa mpya kutoka app.yml, na kuianzisha. Tovuti huwa nje ya mtandao wakati wote wa ujenzi, kwa hivyo chukulia kila mabadiliko ya usanidi kama muda wa matengenezo uliopangwa wa dakika chache.

Kubadilisha thamani pekee zilizo chini ya env: hakuhitaji hatua hiyo. ./launcher destroy app && ./launcher start app huunda upya container kutoka kwenye image uliyokwisha ijenga, jambo ambalo huchukua sekunde chache. Kitu chochote kilicho chini ya templates: au hooks: hubadilisha image yenyewe, kwa hivyo inahitaji ujenzi kamili.

Maboresho hufika kwa njia mbili. Point releases hutumika kutoka kwenye kiolesura cha wavuti katika /admin/upgrade, zinazotolewa na plugin ya docker_manager ambayo app.yml huiga (clone) wakati wa ujenzi. Mabadiliko kwenye base image au templates hutoka kwenye git.

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

Ujenzi upya ndipo seva ndogo hushindwa, kwa sababu mkusanyiko wa rasilimali (asset compilation) ndio kilele cha matumizi ya kumbukumbu kwa mfumo mzima. Ujenzi unaokwama katikati, huku dmesg ikionyesha mstari kama Out of memory: Killed process unaotaja mchakato wa ruby, ulikosa kumbukumbu wakati wa ujenzi ingawa tovuti yenyewe ilikuwa ikifanya kazi vizuri kabla ya hapo. Ongeza swap na uendeshe ujenzi upya.

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

logs huchapisha matokeo ya container, enter hufungua shell ndani yake, na cleanup huondoa container zilizosimamishwa kwa zaidi ya saa 24. Endesha cleanup mara kwa mara, kwa sababu kila ujenzi upya huacha container ya zamani nyuma na diski kwenye VPS ndogo hujaa kimya kimya.

Hifadhi rudufu, na faili ambalo hifadhi hiyo haijumuishi

Chukua hifadhi rudufu kutoka kwenye ukurasa wa Backups katika Admin. Kumbukumbu hiyo huwekwa kwenye seva katika /var/discourse/shared/standalone/backups/default/. Kazi hiyo hiyo inaweza kuendeshwa kutoka kwenye shell.

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

discourse restore <filename> huirejesha, na urejeshaji hukataliwa hadi utakapoiendesha discourse enable_restore. Kinga hiyo ipo ili amri ya bahati mbaya isije ikafuta jukwaa linalofanya kazi.

Kuna mapengo mawili unayopaswa kuziba mwenyewe. Kumbukumbu hiyo huhifadhi database, na huhifadhi faili zilizopakiwa (uploads) pale tu mpangilio wa hifadhi rudufu unaojumuisha uploads unapokuwa umewashwa, kwa hiyo hakiki mpangilio huo kabla ya kuutegemea. Hifadhi hiyo haijumuishi kamwe app.yml, kwa hiyo urejeshaji kwenye VPS mpya bado utahitaji hostname yako na block ya SMTP, jambo linalomaanisha kuwa lazima unakili faili hiyo nje ya seva hiyo pia.

Pia, kumbukumbu hiyo hukaa kwenye diski ileile ya tovuti inayolindwa, jambo ambalo si hifadhi rudufu ya kweli. Ihamishe kwenda mahali pengine kwa ratiba maalum.

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

Gharama ya RAM kwa jukwaa lenye shughuli nyingi

Bootstrap huweka UNICORN_WORKERS na db_shared_buffers kulingana na kumbukumbu na CPU inazotambua, na usanidi wa sampuli hupunguza shared buffers hadi robo ya kumbukumbu yote. Kila mfanyakazi wa unicorn ni mchakato kamili wa Ruby, na Sidekiq huendesha kazi za usuli kando yao, kwa hivyo matumizi ya kumbukumbu hufuata maombi yanayotokea kwa wakati mmoja badala ya idadi ya wanachama waliosajiliwa. Jukwaa tulivu lenye wanachama mia chache si mzigo mzito wa kazi.

Usikadirie ukubwa wa seva kulingana na namba iliyo kwenye makala, ikiwemo hii. Pima yako mwenyewe.

free -m
docker stats --no-stream

Swap inayotumika kila mara pamoja na kurasa za polepole inamaanisha kuwa huna RAM ya kutosha. Kumbukumbu thabiti yenye kurasa za polepole kwa kawaida inamaanisha kitu kingine, kwa hivyo soma ./launcher logs app kabla ya kununua mpango mkubwa zaidi. Ongeza ukaguzi kutoka nje ya seva pia, kwa sababu jukwaa linalokosa kumbukumbu saa 9 usiku hushindwa kimya kimya: kifuatiliaji cha hali cha Uptime Kuma kinachojiendesha kwenye seva tofauti kitakujulisha kabla ya wanachama wako.

Wakati Discourse si chaguo sahihi

Discourse ni programu kubwa yenye usakinishaji mzito na mzunguko wa ujenzi upya (rebuild cycle) kwa kila mpangilio unaopatikana ndani ya app.yml. Gharama hiyo inakupa zana halisi za usimamizi wa maudhui na mfumo wa utafutaji unaofanya kazi hata wakati kumbukumbu za mazungumzo ni kubwa. Kwa watu thelathini wanaotaka mahali pa kuzungumzia mambo, hii ni mashine kubwa kuliko mahitaji ya mazungumzo hayo. Soma ulinganisho wa programu za majukwaa ya kujihostia kwanza, na uchague Discourse kwa sababu unataka utendaji wake, si kwa sababu ni jina unalolijua tayari.

FAQ

Je, ninaweza kusakinisha Discourse kwenye VPS bila jina la kikoa (domain name)?

Hapana. Usanidi uliotolewa unaeleza kuwa Discourse haitafanya kazi na anwani ya IP pekee, na DISCOURSE_HOSTNAME inahitajika. Discourse hutengeneza viungo kamili (absolute links) kutoka kwa hostname hiyo, kwa hivyo anwani ya IP hapo itavunja viungo na kuzuia utoaji wa cheti. Unda A record kabla ya kuanza, na uthibitishe kwa dig +short forum.example.com kuwa inaelekeza kwenye anwani ya seva yako.

Je, lazima nisanidi SMTP ili kukamilisha usakinishaji?

Kufikia Agosti 2026 unaweza kuruka hatua hiyo. Mchawi wa usanidi (setup wizard) hutoa chaguo la kuingia kwa kutumia Discourse ID badala yake, na app.yml ina swichi inayoruka uthibitishaji wa usanidi wa barua pepe. Kwa matumizi yoyote zaidi ya kuangalia mara ya kwanza, isanidi, kwa sababu uanzishaji wa akaunti na uwekaji upya wa nenosiri vyote hutumwa kupitia barua pepe. Tumia relay iliyothibitishwa (authenticated relay) kwenye port 587 au 465, kwa kuwa watoa huduma wengi wa VPS huzuia trafiki ya kutoka kwenye port 25.

Kwa nini ujenzi (rebuild) wa Discourse yangu umefeli katikati?

Kumbukumbu (memory) ndiyo sababu ya kawaida. Uundaji wa rasilimali (asset compilation) wakati wa ujenzi unahitaji kumbukumbu zaidi kuliko tovuti inayofanya kazi, kwa hivyo seva inayohudumia jukwaa vizuri inaweza kushindwa kulijenga upya. Ikiwa dmesg inaonyesha Out of memory: Killed process ikitaja mchakato wa ruby, ongeza swap (swapfile ya mchawi wa usanidi ni 2 GB) na uendeshe ./launcher rebuild app tena. Ujenzi unaokwama kwenye kosa la YAML unaashiria kosa la mpangilio (indentation) katika app.yml.

Je, Discourse inapaswa kukaa nyuma ya nginx au Caddy yangu mwenyewe?

Ni pale tu VPS inapohudumia tovuti nyingine pia. Ikiwa peke yake kwenye seva, acha kontena (container) itumie port 80 na 443 na itoe cheti chake yenyewe, jambo linalopunguza vipengele vingi vya kusimamia. Ili kushiriki mashine, ongeza templates/web.socketed.template.yml, toa maoni (comment out) kwenye mistari ya expose, na uelekeze trafiki (proxy) kwenye unix socket iliyo katika /var/discourse/shared/standalone/nginx.http.sock. Pitisha X-Forwarded-Proto, vinginevyo Discourse itatoa viungo vya http:// kwenye ukurasa wa HTTPS.

Ninawezaje kuhifadhi nakala (backup) ya Discourse inayojiendesha yenyewe?

Tumia ukurasa wa Backups katika Admin, au endesha discourse backup baada ya ./launcher enter app. Kumbukumbu (archives) huhifadhiwa kwenye seva mwenyeji katika /var/discourse/shared/standalone/backups/default/. Thibitisha kuwa mpangilio unaojumuisha upakiaji (uploads) umewashwa, nakili /var/discourse/containers/app.yml pamoja na kumbukumbu hiyo, na uihamishe yote kwenye mashine nyingine, kwa sababu nakala iliyo kwenye diski moja na tovuti haitapona hitilafu ya diski hiyo ambayo ndiyo sababu ya kuwepo kwa nakala hiyo.