SSD Nodes Learn 🎉 VPS kutoka $5.50/mwezi
Mwongozo Matt ConnorNa Matt Connor · Imeboreshwa 2026-08-13

Jinsi ya kujiendeshea Planka kwenye VPS na Docker

Jifunze kusakinisha Planka kwa Docker Compose pamoja na Postgres na Traefik. Mwongozo huu unaelezea jinsi ya kusanidi BASE_URL ili kuepuka hitilafu ya login inayozuia watumiaji.

Unachopata kwa kujiendeshea Planka mwenyewe

Kujiendeshea Planka mwenyewe kunakupa timu yako ubao wa Kanban wenye mfumo wa kadi, orodha na lebo ambao watu tayari wanaufahamu kutoka Trello, ukifanya kazi kwenye VPS unayoimiliki. Hakuna mipaka ya idadi ya watumiaji na hakuna malipo kwa kila mtumiaji, kwa sababu gharama pekee ni seva. Mwongozo huu unaiweka kwa kutumia Docker Compose nyuma ya Traefik, huku ukitumia Postgres kwa ajili ya data na volume iliyotajwa kwa kila faili wanayopakia watumiaji.

Msomaji niliyemlenga ni timu ya watu wawili hadi watano wanaohama kutoka mpango wa bure wa Trello. Ikiwa bado unaamua ni ubao upi wa kutumia, soma ulinganisho wa njia mbadala za Trello zinazojiendesha. Mwongozo huu unachukulia kuwa uamuzi umeshafanyika na unashughulikia uwekaji pekee.

Unahitaji VPS inayoendesha Docker Engine na Compose plugin, na DNS A record inayoelekeza kwenye seva hiyo. Pia unahitaji mfano wa Traefik ambao tayari unashughulikia TLS (transport layer security) kwenye seva hiyo. Ikiwa Traefik haipo bado, sanidi reverse proxy ya Traefik mbele ya programu kadhaa za Compose kwanza, na usome misingi ya Docker Compose kwa VPS ikiwa faili iliyo hapa chini inaonekana ngeni.

Planka inahitaji VPS ya ukubwa gani?

Mradi huu haujatoa kiwango cha chini cha maunzi, kwa hivyo chukulia namba yoyote unayosoma kama kianzio badala ya kipimo kamili. Takwimu ya 2 vCPU na 4 GB inayorudiwarudiwa kwenye kurasa za hosting ni chaguo la kawaida la watoa huduma ili kuleta utulivu, si hitaji lililopimwa na mradi wenyewe. Hiyo ni nafasi kubwa kwa ubao unaotumiwa na watu watano.

Kinachoendesha programu ni kidogo: mchakato mmoja wa Node.js unaohudumia API na frontend iliyojengwa, na mchakato mmoja wa Postgres unaohifadhi data. Mchakato wa tatu mdogo wa proxy huendesha ndani ya container ya Planka ili kuchuja maombi yake ya nje. Mpango wa 1 vCPU na 2 GB unatosha kwa ubao wa watu wawili hadi watano, na sehemu kubwa ya kumbukumbu iliyobaki hutumika kama cache ya Postgres.

Pima ukubwa wa diski kabla ya kupima kumbukumbu, kwa sababu viambatisho ndivyo vinavyoongezeka. Pima mfano wako mwenyewe badala ya kuamini aya hii:

docker stats --no-stream
docker system df -v

Amri ya kwanza inaonyesha kumbukumbu na CPU inayotumika kwa kila container. Ya pili inaonyesha nafasi inayotumiwa na kila volume. Chukua vipimo vyote viwili baada ya wiki ya kawaida ya kazi, si siku ya usakinishaji, kwa sababu ubao usiotumika haukupi taarifa zozote kuhusu timu yako.

Andika faili la Compose

Tengeneza saraka na uichukue umiliki wake, ili usilazimike kuhariri faili hizi kupitia sudo.

sudo mkdir -p /opt/planka
sudo chown "$USER":"$USER" /opt/planka
cd /opt/planka

Tengeneza siri (secrets) kwenye faili la .env kando ya faili la Compose. Compose husoma faili hilo kiotomatiki na kuingiza thamani zake.

umask 077
{
  printf 'SECRET_KEY=%s\n' "$(openssl rand -hex 64)"
  printf 'POSTGRES_PASSWORD=%s\n' "$(openssl rand -hex 24)"
  printf 'ADMIN_PASSWORD=%s\n' "$(openssl rand -hex 12)"
} > .env
chmod 600 .env

openssl rand -hex imekusudiwa. Mfuatano wa hex una tarakimu na herufi a hadi f pekee, kwa hivyo hauwezi kuvunja mfuatano wa muunganisho wa DATABASE_URL unaowekwa ndani yake. Nenosiri la base64 lenye alama ya mkwaju au "at sign" husababisha hitilafu ya muunganisho inayoonekana kama hostname isiyo sahihi, na hilo hukupotezea saa nzima. Mfumo mpana zaidi umeelezwa katika kuepuka kuweka siri kwenye faili la Compose.

Sasa docker-compose.yml. Badilisha kanban.example.com na hostname yako mwenyewe katika sehemu zote mbili inapoonekana.

services:
  planka:
    image: ghcr.io/plankanban/planka:2.1.1
    restart: unless-stopped
    volumes:
      - planka-data:/app/data
    environment:
      - BASE_URL=https://kanban.example.com
      - DATABASE_URL=postgresql://planka:${POSTGRES_PASSWORD}@postgres/planka
      - SECRET_KEY=${SECRET_KEY}
      - TRUST_PROXY=true
      - DEFAULT_ADMIN_EMAIL=you@example.com
      - DEFAULT_ADMIN_PASSWORD=${ADMIN_PASSWORD}
      - DEFAULT_ADMIN_NAME=Your Name
      - DEFAULT_ADMIN_USERNAME=admin
    networks:
      - proxy
      - internal
    labels:
      - "traefik.enable=true"
      - "traefik.docker.network=proxy"
      - "traefik.http.routers.planka.rule=Host(`kanban.example.com`)"
      - "traefik.http.routers.planka.entrypoints=websecure"
      - "traefik.http.routers.planka.tls.certresolver=default"
      - "traefik.http.services.planka.loadbalancer.server.port=1337"
    depends_on:
      postgres:
        condition: service_healthy

  postgres:
    image: postgres:16-alpine
    restart: unless-stopped
    volumes:
      - db-data:/var/lib/postgresql/data
    environment:
      - POSTGRES_DB=planka
      - POSTGRES_USER=planka
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
    networks:
      - internal
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U planka -d planka"]
      interval: 10s
      timeout: 5s
      retries: 5

volumes:
  planka-data:
  db-data:

networks:
  proxy:
    external: true
  internal:

Maamuzi manne katika faili hilo yanastahili maelezo, kwa sababu ndiyo watu hubadilisha na kisha kujuta.

  • Hakuna kizuizi cha ports: kwenye huduma ya Planka. Traefik hufikia kontena kupitia mtandao wa proxy, kwa hivyo port 1337 haichapishwi kamwe kwenye host. Kuichapisha kungepa mtu yeyote njia ya kukwepa proxy yako na cheti chako.
  • loadbalancer.server.port=1337 hutaja port iliyo ndani ya kontena. Planka husikiliza kwenye 1337, na mfano wa upstream huifikia kwenye 3000 kwa sababu huweka ramani ya port hiyo kwenye host. Hakuna ramani ya host hapa, kwa hivyo Traefik lazima iambiwe port ya kontena.
  • condition: service_healthy huambatana na healthcheck ya Postgres. Bila hiyo, Planka huanza kabla ya database kukubali miunganisho, hushindwa kwenye swali lake la kwanza na kujifunga, jambo linaloonekana kama crash loop. Mbinu zake ziko katika healthchecks za Compose na mpangilio wa kuanza.
  • Huduma ya database imeitwa postgres kwa makusudi. Planka 2 huelekeza maombi yake ya kutoka kupitia kichujio cha ndani ambacho orodha yake ya kuzuia ya awali ni localhost,postgres. Badilisha jina la huduma hiyo na utaondoa database yako kimyakimya kwenye orodha hiyo.

Thibitisha kuwa Compose inaweza kuona siri zako kabla ya kuanza chochote:

docker compose config | grep -E 'image:|BASE_URL|POSTGRES_USER'

Hiyo huchapisha faili lenye thamani za .env zilizokwisha kuingizwa. Thamani tupu inamaanisha kuwa Compose haisomi faili la .env, kwa kawaida kwa sababu unaendesha amri hiyo kutoka saraka tofauti.

Kazi halisi ya vigezo vya bootstrap vya admin

Tangu Planka 1.13, hakuna msimamizi anayeundwa kiotomatiki, kwa hivyo database mpya haina mtumiaji yeyote anayeweza kuingia. Kundi la DEFAULT_ADMIN_* ni mojawapo ya njia mbili za kutatua tatizo hilo.

Wakati wa kuanza, Planka hutafuta mtumiaji anayelingana na DEFAULT_ADMIN_EMAIL. Ikiwa hayupo, huunda mmoja kwa kutumia nenosiri, jina la kuonyesha, na jina la mtumiaji lililowekwa sambamba nalo. Hii hutokea wakati wa boot ya kwanza kwenye database tupu, kwa hivyo vigezo hivi huanzisha akaunti badala ya kuimudu.

DEFAULT_ADMIN_EMAIL hufanya kazi ya pili ambayo huwachanganya watu wengi. Wakati kigezo hiki kikiwa kimewekwa, akaunti inayotajwa haiwezi kuhaririwa au kufutwa kutoka kwenye interface na mtu yeyote. Hii ni hatua ya kuzuia kufungiwa nje, na ndiyo sababu huwezi kubadilisha jina la akaunti hiyo au kubadilisha barua pepe yake kwenye UI. Ondoa kigezo hicho na uanzishe upya huduma, na akaunti hiyo itakuwa admin wa kawaida unayoweza kuhariri kama nyingine yoyote.

Mstari wa nenosiri ni ule unaopaswa kuwa mwangalifu nao. Kitu chochote chini ya environment: kinaweza kusomwa na mtu yeyote anayeweza kuendesha docker inspect kwenye container, kwa hivyo DEFAULT_ADMIN_PASSWORD haipaswi kuwepo hapo kwa kudumu. Ingia kwenye mfumo, badilisha nenosiri lako kwenye interface, futa mstari huo, kisha uendeshe docker compose up -d tena.

Njia safi zaidi ni kuruka vigezo hivi kabisa. Toa maoni (comment out) kwenye kundi zima la DEFAULT_ADMIN_*, kisha uunde akaunti kwa njia ya maingiliano (interactive):

docker compose run --rm planka npm run db:create-admin-user

Inakuuliza barua pepe, nenosiri, jina la kuonyesha, na jina la mtumiaji la hiari, kisha inaandika mtumiaji moja kwa moja kwenye database. Nenosiri haligusi kamwe faili ya Compose au mazingira ya container. Tumia njia hii ikiwa zaidi ya mtu mmoja ana uwezo wa kufikia shell ya VPS. Amri hii huanzisha Postgres kwanza kwa sababu ya depends_on, kwa hivyo inafanya kazi kwenye stack ambayo haijawahi kuwashwa.

Njia yoyote kati ya hizi inakuacha ukisimamia nywila za Planka kwa mkono, na ikiwa huo ni mkusanyiko wa nne wa vitambulisho ambavyo timu yako imekusanya, Planka inaweza badala yake kukabidhi maingizo kwa mtoa huduma wa OIDC kama vile Authentik inayofanya kazi kama seva yako ya single sign-on, huku admin wa bootstrap akihifadhiwa kama akaunti ya dharura kwa siku ambayo mtoa huduma huyo atakuwa chini.

Kwa nini BASE_URL huvunja uwezo wa kuingia kwenye mfumo (login) wakati hailingani na hostname

BASE_URL ni anwani kamili wanayoiandika watu kwenye kivinjari, ikiwa na scheme na bila slash ya mwisho. Kwa stack hii, hiyo ni https://kanban.example.com. Planka hutengeneza viungo vyake na muunganisho wake wa WebSocket kutokana na thamani hiyo, jambo linalomaanisha kuwa BASE_URL isiyo sahihi haikupi kosa lililo wazi. Badala yake, unapata ukurasa unaopakia na kisha haumalizi kupakia.

Toleo la kawaida: unanakili mfano wa upstream, unaacha BASE_URL=http://localhost:3000 kama ilivyo, na unafikia tovuti hiyo kupitia HTTPS kwenye domain yako halisi. Fomu ya kuingia inatuma data na vitambulisho vyako vinakubaliwa. Ubao (board) haujitokezi kamwe. Fungua konsole ya msanidi programu kwenye kivinjari na utaona maombi kwenda /socket.io/ yakifeli, kwa sababu mteja aliambiwa afungue muunganisho wake wa moja kwa moja kwenda localhost:3000, na kwenye kompyuta yako anwani hiyo haipo kabisa.

TRUST_PROXY=true ni nusu nyingine ya tatizo hilo hilo. Planka hukaa nyuma ya Traefik, kwa hivyo kila ombi hufika kutoka kwenye anwani ya proxy kupitia HTTP ya kawaida ndani ya mtandao wa Docker. Bila TRUST_PROXY, programu hupuuza headers za X-Forwarded-Proto na X-Forwarded-For ambazo Traefik huweka, kwa hivyo huamini kuwa muunganisho si salama na humchukulia kila mteja kama anayetumia anwani moja ya IP iliyoshirikiwa. Ikiwa imewekwa, programu husoma headers hizo na kukubaliana na kivinjari kuhusu scheme inayotumika.

Traefik hufanya proxy ya WebSockets bila usanidi wa ziada, ambayo ni sababu moja ya kuipendelea hapa. Kwenye nginx, socket.io inahitaji block yake ya location inayobeba proxy_set_header Upgrade $http_upgrade na proxy_set_header Connection "upgrade", la sivyo utapata kizuizi hicho hicho cha spinner inayozunguka bila kuacha kwa sababu tofauti.

Kuhamisha ubao kwenda kwenye hostname mpya baadaye kunamaanisha kubadilisha vitu viwili kwa pamoja: thamani ya BASE_URL na sheria ya Host() ya Traefik. Badilisha kimoja na usahau kingine, na utarudi kwenye tatizo la spinner. Kuhudumia Planka kutoka subpath kama https://example.com/planka hufanya kazi kuanzia toleo la 2.1.0 na kuendelea, lililotolewa Machi 2026. Kwenye tags za zamani, ipe subdomain yake yenyewe.

Mahali ambapo Planka huhifadhi viambatisho na avatar

Planka 2 huhifadhi kila kitu kinachopakiwa na mtumiaji chini ya njia moja ndani ya kontena: /app/data. Viambatisho, avatar za watumiaji, na picha za mandharinyuma ya ubao vyote hukaa ndani ya njia hiyo. Toleo la 1 lilitumia saraka tatu tofauti, kwa hivyo faili ya Compose iliyonakiliwa kutoka kwa mwongozo wa zamani huweka njia ambazo hazipo tena, na saraka halisi ya data huachwa bila kuwekwa (unmounted).

Kuweka njia hiyo moja (mount) ndiko kunakotofautisha ubao unaosalia baada ya uboreshaji na ule unaopotea. Ikiwa /app/data haijawekwa kwenye volume, faili zilizopakiwa huishia kwenye safu ya kontena inayoweza kuandikwa (writable layer). Safu hiyo huharibiwa wakati kontena linapoundwa upya, na kontena huundwa upya kila unapobadilisha image tag. Ubao utarudi ukiwa unaonekana sawa, kadi zote zitakuwepo, lakini kila kiungo cha kiambatisho kitakuwa kimevunjika, kwa sababu safu za hifadhidata bado zinaelekeza kwenye faili ambazo hazipo tena.

Named volume iliyo kwenye faili ya Compose hapo juu huzuia hili. Bind mount pia hufanya kazi na hurahisisha kuhifadhi faili hizo kwa kutumia zana za kawaida, lakini inahitaji hatua moja ya ziada. Mchakato wa Node ndani ya kontena huendeshwa kama UID 1000, kwa hivyo saraka ya mwenyeji (host) inayomilikiwa na root italeta hitilafu ya ruhusa (permission error) wakati wa upakiaji wa kwanza:

sudo chown -R 1000:1000 /opt/planka/data

Ulinganisho kati ya njia hizi mbili umeelezwa katika bind mounts dhidi ya named volumes.

Ikiwa viambatisho vitazidi nafasi ya diski kwenye mpango wako, Planka inaweza kuviandika kwenye hifadhi inayooana na S3 badala yake, kupitia S3_ENDPOINT, S3_BUCKET na vigezo (variables) vya funguo vinavyolingana. Hiyo inaweza kuelekeza kwenye bucket iliyopangishwa au kwenye hifadhi ya vitu ya MinIO inayojiendesha kwenye seva nyingine. Amua hili kabla ya timu kujaza ubao, kwa sababu mpangilio huu unahusu upakiaji mpya pekee.

Anzisha stack na uhakikishe kuwa imefanya kazi

docker compose pull
docker compose up -d
docker compose ps

docker compose ps inapaswa kuonyesha postgres kama healthy na planka kama running. Ikiwa Planka inajianzisha upya mara kwa mara, muunganisho wa database ndilo jambo la kwanza la kukagua, si programu yenyewe.

docker compose logs -f planka

Boot ya kwanza yenye afya huendesha migrations za database na kisha kuripoti seva ikisikiliza kwenye port 1337. Thibitisha kuwa schema imeingia kweli kwa kuuliza Postgres moja kwa moja badala ya kuamini log:

docker compose exec postgres psql -U planka -d planka -c '\dt'

Orodha ya majedwali inayojumuisha board na card inamaanisha kuwa migrations zimefanya kazi. "Did not find any relations" inamaanisha Planka haikuwahi kuunganishwa, kwa hivyo linganisha DATABASE_URL dhidi ya thamani za POSTGRES_USER na POSTGRES_PASSWORD katika .env yako.

Kisha kagua njia (route) kutoka kwenye mashine yako mwenyewe, si kutoka kwenye VPS:

curl -I https://kanban.example.com

HTTP/2 200 inamaanisha Traefik inashikilia cheti na inafikia container. 404 inayotolewa na Traefik inamaanisha lebo za router hazikulingana, mara nyingi kwa sababu container haijaunganishwa kwenye mtandao wa proxy. Sasa fungua tovuti na uingie kwa kutumia akaunti ya admin.

Fanya pg_dump kabla ya kila toleo jipya

Hifadhi mbili tofauti zinashikilia bodi yako, kwa hivyo backup lazima ihusishe zote mbili: database ya Postgres na volume ya planka-data. Fanya dump ya database wakati stack inaendelea kufanya kazi.

docker compose exec -T postgres pg_dump -U planka -d planka > "planka-db-$(date +%F).sql"

Flag ya -T si ya hiari. Bila hiyo, Compose hutenga pseudo-terminal, na safu ya terminal hubadilisha mwisho wa mistari kwenye mtiririko, hivyo utapata faili ya dump inayofeli katikati ya restore. Hitilafu hiyo huonekana wiki kadhaa baadaye, wakati ambao ni mbaya zaidi.

Kisha uploads. Tafuta jina halisi la volume kwanza, kwa sababu Compose huongeza jina la saraka ya mradi (project directory) kama prefix.

docker volume ls | grep planka
docker run --rm -v planka_planka-data:/data -v "$PWD":/backup alpine \
  tar czf /backup/planka-files-$(date +%F).tgz -C /data .

Mradi huu pia unakuja na docker-backup.sh na docker-restore.sh kwenye repository yake, na nyaraka rasmi huweka hizi kwenye cron job ya kila usiku. Njia yoyote kati ya hizi ni sawa. Kinachokosea ni backup ambayo hujawahi kuifanyia restore, kwa hivyo fanya restore kwenye VPS ya majaribio mara moja na uhakikishe unaweza kuingia (log in) na kufungua kiambatisho.

Endesha dump mara moja kabla ya kila mabadiliko ya toleo. Backup ya jana usiku si sawa na backup ya kabla ya migration unayotaka kufanya.

Bandika tagi na usome maelezo ya toleo

Tagi zote mbili za image kwenye faili hilo zimebandikwa kwa makusudi.

ghcr.io/plankanban/planka:2.1.1 ni toleo mahususi, ambalo ni la sasa kufikia Agosti 2026. latest hubadilika wakati wowote mtoa huduma anapotoa toleo jipya, kwa hivyo docker compose pull ya kawaida inaweza kuleta mabadiliko ya schema wakati usiotarajiwa. Soma maelezo ya toleo kabla ya kubadilisha namba hiyo, kwa sababu hapo ndipo mabadiliko makubwa na marekebisho ya usalama yanapoelezewa. Toleo la 2.0.3 lilichapishwa kama toleo la usalama, ambalo ndilo hasa unalotaka kulisoma badala ya kulipata kwa bahati mbaya.

postgres:16-alpine imebandikwa kwenye toleo kuu kwa sababu nzito zaidi. Postgres huandika saraka yake ya data katika umbizo linalofungamana na toleo kuu, na seva hukataa kufungua saraka iliyoandikwa na toleo tofauti. Andika postgres:latest, ruhusu tagi ibadilike kwenda 17, na container haitaanza:

FATAL:  database files are incompatible with server
DETAIL:  The data directory was initialized by PostgreSQL version 16, which is not compatible with this version 17.

Hakuna kinachopotea, na hakuna kinachorekebishwa kwa kuanzisha upya (restart). Kuhamia toleo kuu jipya la Postgres kunamaanisha kutoa dump kutoka toleo la zamani na kuirejesha kwenye saraka mpya ya data katika toleo jipya. Hiyo ni kazi iliyopangwa huku stack ikiwa imezimwa, si matokeo ya bahati mbaya ya kuvuta (pull) image.

Ikiwa unahamisha usakinishaji wa sasa wa Planka 1.x badala ya kuanza upya, uboreshaji huo una utaratibu wake uliowekwa kwenye nyaraka za mradi, na hakuna njia ya kurudi kwenye toleo la 1 bila backup iliyochukuliwa mapema.

Njia za hitilafu na ujumbe utakaouona

Planka inajianzisha upya mara kwa mara na logi inataja database. Vitambulisho vilivyopo kwenye DATABASE_URL havilingani na mazingira ya Postgres. Kumbuka kuwa POSTGRES_PASSWORD hutumika tu wakati saraka ya data inapoanzishwa kwa mara ya kwanza, kwa hivyo kurekebisha variable hiyo baada ya boot ya kwanza iliyofeli hakutabadilisha chochote. Lazima ufute volume ya db-data na uanze upya.

Kuingia kwenye mfumo kunafanikiwa lakini ubao (board) haupakii. BASE_URL hailingani na anwani iliyo kwenye bar ya kivinjari, au TRUST_PROXY haipo. Dashibodi ya kivinjari inaonyesha maombi yanayofeli kuelekea /socket.io/.

Upakiaji wa faili (uploads) unafeli wakati kila kitu kingine kinafanya kazi. Bind mount inamilikiwa na root. Tekeleza sudo chown -R 1000:1000 kwenye saraka ya mwenyeji (host) na uanzishe upya container.

Viambatisho vimetoweka baada ya kuboresha (upgrade). /app/data haikuwa kwenye volume, kwa hivyo faili zilikuwa kwenye safu ya container ambayo ilibadilishwa wakati wa upgrade. Rejesha faili kutoka kwenye backup, kisha ongeza volume kabla ya kugusa image tag tena.

Traefik inarudisha 404. Container haipo kwenye mtandao wa proxy, au sheria ya Host() hailingani na rekodi yako ya DNS. docker compose config inaonyesha lebo baada ya mabadiliko, ambapo makosa ya uchapaji huwa dhahiri.

Arifa au webhooks hazifiki. Planka 2 hutuma maombi yake ya nje ya HTTP kupitia kichujio cha ndani, na orodha ya kuzuia ya awali inahusu localhost na postgres. Webhook inayoelekezwa kwenye container nyingine kwenye mwenyeji mmoja inaweza kuzuiwa kwa makusudi. Rekebisha OUTGOING_ALLOWED_HOSTS badala ya kuondoa kichujio hicho.

Mara tu inapofanya kazi, mzigo wa uendeshaji ni mdogo. Fuatilia maelezo ya toleo (release notes), na fanya dump ya database kabla ya kila upgrade. Reboot huleta stack yenyewe kwa sababu ya restart: unless-stopped, mradi huduma ya Docker yenyewe imewezeshwa wakati wa boot, na Compose stacks zinazorudi baada ya reboot inashughulikia hali ambapo haifanyi hivyo.

FAQ

Kwa nini Planka inapakia milele baada ya kuingia?

Kitambulisho kimekubaliwa lakini muunganisho wa moja kwa moja (live connection) haukukubaliwa. Planka hutengeneza URL ya WebSocket kutoka BASE_URL, kwa hivyo ikiwa variable hiyo bado inasema http://localhost:3000 wakati unafikia tovuti hiyo kupitia https://kanban.example.com, kivinjari kinajaribu kufungua socket kwenye anwani ambayo haipo kwenye mashine yako. Dashibodi ya msanidi programu inaonyesha maombi yanayofeli kwenda /socket.io/. Weka BASE_URL kwenye anwani kamili ya umma bila alama ya mkwaju (slash) mwishoni, ongeza TRUST_PROXY=true ili programu iheshimu header ya X-Forwarded-Proto kutoka kwa reverse proxy yako, kisha endesha docker compose up -d.

Ninawezaje kuunda mtumiaji wa kwanza wa admin wa Planka?

Tangu toleo la 1.13, hakuna msimamizi anayeundwa kiotomatiki. Aidha weka DEFAULT_ADMIN_EMAIL pamoja na variable zake za nenosiri, jina, na jina la mtumiaji linalolingana kisha uanzishe stack, au endesha docker compose run --rm planka npm run db:create-admin-user na ujibu maelekezo yanayojitokeza. Amri ya maingiliano (interactive command) ni salama zaidi kwenye seva inayoshirikiwa, kwa sababu nenosiri haliingii kwenye mazingira ya container ambapo docker inspect inaweza kulisoma. Kuacha DEFAULT_ADMIN_EMAIL kikiwa kimewekwa baada ya hapo hufunga akaunti hiyo dhidi ya kuhaririwa au kufutwa kutoka kwenye interface.

Planka huhifadhi wapi viambatisho na avatars?

Faili zote zilizopakiwa hukaa chini ya /app/data ndani ya container katika Planka 2, ikijumuisha viambatisho, avatars za watumiaji, na asili za mbao (board backgrounds). Mount njia hiyo kwenye named volume. Ikiwa haijawekwa (unmounted), faili hukaa kwenye safu inayoweza kuandikwa ya container na huharibiwa wakati container inapoundwa upya, jambo linalotokea kila unapoboresha image. Bind mount pia hufanya kazi, lakini mchakato wa Node huendeshwa kama UID 1000, kwa hivyo endesha sudo chown -R 1000:1000 kwenye saraka ya host au upakiaji utafeli kwa hitilafu ya ruhusa (permission error).

Planka inayojiendesha yenyewe inahitaji RAM kiasi gani?

Mradi huu hauchapishi kiwango cha chini cha maunzi. Takwimu ya 2 vCPU na 4 GB inayorudiwarudiwa kwenye kurasa za hosting ni chaguo-msingi la mtoa huduma badala ya kipimo, na ni kubwa mno kwa mbao ndogo. Mchakato mmoja wa Node na mchakato mmoja wa Postgres ndio mzigo mzima wa kazi, kwa hivyo mpango wa 1 vCPU na 2 GB unatosheleza timu ya watu wawili hadi watano. Endesha docker stats --no-stream baada ya wiki ya kawaida na upime ukubwa kulingana na namba zako mwenyewe. Fuatilia diski kwa karibu zaidi kuliko kumbukumbu, kwa sababu viambatisho ndivyo vinavyokua.

Ninawezaje kuboresha Planka bila kupoteza data?

Hifadhi database na uweke kwenye kumbukumbu (archive) volume ya upakiaji mara moja kabla ya uboreshaji, si kwa ratiba ya jana usiku. Tumia docker compose exec -T postgres pg_dump -U planka -d planka > planka-db.sql, huku ukihifadhi -T ili pseudo-terminal isiharibu matokeo yaliyoelekezwa (redirected output). Soma maelezo ya toleo (release notes) kwa kila toleo unaloruka, badilisha tag ya image iwe toleo mahususi badala ya latest, kisha endesha docker compose pull na docker compose up -d na ufuatilie log kwa ajili ya uhamiaji (migration). Acha tag ya Postgres ikiwa imefungwa kwenye toleo lake kuu (major version), kwa sababu seva hukataa kufungua saraka ya data iliyoandikwa na toleo tofauti kuu.

#planka#self-hosting#docker-compose#postgres#traefik