Cara Self-host Planka dengan Docker Compose

Kelebihan self-hosting Planka

Self-hosting Planka memberikan pasukan anda papan Kanban dengan model kad, senarai dan label yang sudah biasa digunakan dalam Trello, berjalan pada VPS yang anda kawal. Tiada had bilangan pengguna dan tiada bil bagi setiap pengguna, kerana satu-satunya kos ialah pelayan itu sendiri. Panduan ini menggunakan Docker Compose untuk melancarkannya di belakang Traefik, menggunakan Postgres untuk data dan named volume bagi setiap fail yang dimuat naik oleh pengguna.

Panduan ini ditujukan kepada pasukan yang terdiri daripada dua hingga lima orang yang ingin beralih daripada pelan percuma Trello. Jika anda masih membuat keputusan tentang papan yang ingin digunakan, baca perbandingan alternatif Trello yang boleh di-self-host terlebih dahulu. Panduan ini mengandaikan pilihan telah dibuat dan hanya merangkumi proses pelancaran.

Anda memerlukan VPS yang menjalankan Docker Engine dengan pemalam Compose, serta DNS A record yang menghala ke pelayan tersebut. Anda juga memerlukan instans Traefik yang sudah mengendalikan TLS (transport layer security) pada pelayan tersebut. Jika Traefik belum tersedia, sediakan reverse proxy Traefik di hadapan beberapa aplikasi Compose terlebih dahulu, dan baca asas Docker Compose untuk VPS jika fail di bawah kelihatan asing bagi anda.

Berapakah keperluan VPS untuk Planka?

Projek ini tidak menerbitkan spesifikasi perkakasan minimum, jadi anggaplah sebarang angka yang anda baca sebagai titik permulaan dan bukannya ukuran mutlak. Angka 2 vCPU dan 4 GB yang sering diulang oleh laman pengehosan hanyalah tetapan lalai yang selesa bagi penyedia, bukannya keperluan yang diukur oleh pihak projek. Ia merupakan spesifikasi yang mewah untuk papan yang digunakan oleh lima orang.

Apa yang sebenarnya dijalankan adalah kecil: satu proses Node.js yang menyediakan API dan frontend yang telah dibina, serta satu proses Postgres yang menyimpan data. Proses proksi ketiga yang kecil berjalan di dalam kontena Planka untuk menapis permintaan keluar. Pelan 1 vCPU dan 2 GB mampu menampung papan untuk dua hingga lima orang, dan kebanyakan memori yang tidak digunakan akan berakhir sebagai cache Postgres.

Tentukan saiz cakera sebelum anda menentukan saiz memori, kerana lampiran adalah bahagian yang akan terus berkembang. Ukur instans anda sendiri dan jangan hanya bergantung pada perenggan ini:

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

Perintah pertama mencetak penggunaan memori dan CPU secara langsung bagi setiap kontena. Perintah kedua menunjukkan berapa banyak ruang yang digunakan oleh setiap volum. Ambil kedua-dua bacaan selepas satu minggu bekerja yang biasa, bukan pada hari pemasangan, kerana papan yang melahu tidak memberikan gambaran sebenar tentang pasukan anda.

Tulis fail Compose

Cipta direktori dan ambil pemilikan ke atasnya, supaya anda tidak perlu menyunting fail ini melalui sudo.

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

Jana rahsia ke dalam fail .env di sebelah fail Compose. Compose membaca fail tersebut secara automatik dan menggantikan nilai-nilainya.

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 adalah disengajakan. Rentetan heksadesimal hanya mengandungi digit dan huruf a hingga f, jadi ia tidak boleh merosakkan rentetan sambungan DATABASE_URL yang ia dimasukkan ke dalamnya. Kata laluan base64 yang mengandungi garis miring atau simbol at akan menghasilkan ralat sambungan yang kelihatan seperti nama hos yang salah, dan itu akan membuang masa anda selama satu jam. Corak yang lebih luas diliputi dalam menyimpan rahsia di luar fail Compose.

Sekarang docker-compose.yml. Gantikan kanban.example.com dengan nama hos anda sendiri di kedua-dua tempat ia muncul.

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:

Empat keputusan dalam fail itu perlu dijelaskan, kerana itulah perkara yang sering diubah oleh orang ramai dan kemudian mereka menyesalinya.

• Tiada blok ports: pada servis Planka. Traefik mencapai kontena merentasi rangkaian proxy, jadi port 1337 tidak pernah diterbitkan pada hos. Menerbitkannya akan memberi sesiapa sahaja cara untuk memintas proksi dan sijil anda.
• loadbalancer.server.port=1337 menamakan port di dalam kontena. Planka mendengar pada 1337, dan contoh huluan hanya mencapainya pada 3000 kerana ia memetakan port tersebut ke hos. Tiada pemetaan hos di sini, jadi Traefik perlu diberitahu tentang port kontena tersebut.
• condition: service_healthy berpasangan dengan pemeriksaan kesihatan Postgres. Tanpanya, Planka bermula sebelum pangkalan data menerima sambungan, gagal dalam pertanyaan pertamanya dan keluar, yang kelihatan seperti gelung ranap. Mekanismenya ada dalam pemeriksaan kesihatan dan aturan permulaan Compose.
• Servis pangkalan data dinamakan postgres dengan sengaja. Planka 2 menghalakan permintaan keluar sendiri melalui penapis dalaman yang senarai sekat lalainya ialah localhost,postgres. Namakan semula servis tersebut dan anda secara senyap mengeluarkan pangkalan data anda daripada senarai itu.

Semak sama ada Compose boleh melihat rahsia anda sebelum anda memulakan apa-apa:

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

Itu mencetak fail dengan nilai .env yang telah digantikan. Nilai kosong bermakna Compose tidak membaca fail .env, biasanya kerana anda menjalankan arahan daripada direktori yang berbeza.

Fungsi sebenar pemboleh ubah bootstrap pentadbir

Sejak Planka 1.13, tiada akaun pentadbir dicipta secara automatik untuk anda, jadi pangkalan data yang baharu tidak mempunyai pengguna yang boleh log masuk. Kumpulan DEFAULT_ADMIN_* merupakan salah satu daripada dua cara untuk menyelesaikan masalah ini.

Semasa permulaan, Planka akan mencari pengguna yang sepadan dengan DEFAULT_ADMIN_EMAIL. Jika tiada, ia akan mencipta satu akaun menggunakan kata laluan, nama paparan dan nama pengguna yang ditetapkan bersamanya. Perkara ini berlaku pada but pertama terhadap pangkalan data yang kosong, jadi pemboleh ubah ini berfungsi untuk memulakan akaun dan bukannya mengurusnya.

DEFAULT_ADMIN_EMAIL mempunyai fungsi kedua yang sering memerangkap pengguna. Selagi pemboleh ubah ini ditetapkan, akaun yang dinamakan tidak boleh disunting atau dipadamkan daripada antara muka oleh sesiapa pun. Ini adalah langkah perlindungan daripada terkunci keluar, dan itulah sebabnya anda tidak boleh menukar nama akaun atau alamat e-melnya dalam UI. Buang pemboleh ubah tersebut dan mulakan semula servis, maka akaun itu akan menjadi pentadbir biasa yang boleh disunting seperti akaun lain.

Baris kata laluan adalah bahagian yang perlu diberi perhatian. Sebarang maklumat di bawah environment: boleh dibaca oleh sesiapa sahaja yang boleh menjalankan docker inspect pada kontena, jadi DEFAULT_ADMIN_PASSWORD tidak seharusnya dibiarkan di situ secara kekal. Log masuk, tukar kata laluan anda dalam antara muka, padamkan baris tersebut, kemudian jalankan docker compose up -d sekali lagi.

Cara yang lebih bersih adalah dengan melangkau pemboleh ubah tersebut sepenuhnya. Komen keseluruhan kumpulan DEFAULT_ADMIN_*, kemudian cipta akaun secara interaktif:

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

Ia akan meminta e-mel, kata laluan, nama paparan dan nama pengguna pilihan, kemudian menulis data pengguna terus ke dalam pangkalan data. Kata laluan tidak akan menyentuh fail Compose atau persekitaran kontena. Gunakan cara ini jika lebih daripada seorang mempunyai akses shell ke VPS. Perintah ini memulakan Postgres terlebih dahulu disebabkan oleh depends_on, jadi ia berfungsi pada stack yang belum pernah dijalankan.

Kedua-dua cara ini memerlukan anda mengurus kata laluan Planka secara manual. Jika ini merupakan set kelayakan keempat yang dikumpulkan oleh pasukan anda, Planka boleh sebaliknya menyerahkan log masuk kepada pembekal OIDC seperti Authentik yang berjalan sebagai pelayan single sign-on anda sendiri, dengan pentadbir bootstrap disimpan sebagai akaun kecemasan sekiranya pembekal tersebut mengalami gangguan.

Mengapa BASE_URL menyebabkan kegagalan log masuk apabila ia tidak sepadan dengan nama hos

BASE_URL ialah alamat tepat yang ditaip oleh pengguna ke dalam pelayar, lengkap dengan skema dan tanpa garis miring di hujung. Bagi tindanan ini, nilainya ialah https://kanban.example.com. Planka membina pautan dan sambungan WebSocket miliknya sendiri berdasarkan nilai tersebut, yang bermaksud BASE_URL yang salah tidak akan memberikan ralat yang jelas. Sebaliknya, anda akan mendapat halaman yang dimuatkan tetapi tidak pernah selesai dimuatkan.

Versi yang biasa berlaku: anda menyalin contoh hulu (upstream), membiarkan BASE_URL=http://localhost:3000 seperti sedia ada, dan melayari tapak tersebut melalui HTTPS pada domain sebenar anda. Borang log masuk dihantar dan kelayakan anda diterima. Namun, papan (board) tidak pernah muncul. Buka konsol pembangun pelayar dan anda akan melihat permintaan ke /socket.io/ gagal, kerana klien diarahkan untuk membuka sambungan langsungnya ke localhost:3000, dan pada komputer riba anda, alamat tersebut tidak wujud sama sekali.

TRUST_PROXY=true ialah separuh lagi daripada masalah yang sama. Planka berada di belakang Traefik, jadi setiap permintaan sampai kepadanya daripada alamat proksi melalui HTTP biasa di dalam rangkaian Docker. Tanpa TRUST_PROXY, aplikasi mengabaikan pengepala X-Forwarded-Proto dan X-Forwarded-For yang ditetapkan oleh Traefik, jadi ia menganggap sambungan tersebut tidak selamat dan melayan setiap klien sebagai satu alamat IP yang dikongsi. Dengan menetapkannya, aplikasi membaca pengepala tersebut dan bersetuju dengan pelayar mengenai skema yang digunakan.

Traefik memproksi WebSocket tanpa konfigurasi tambahan, itulah sebabnya ia lebih diutamakan di sini. Pada nginx, socket.io memerlukan blok location sendiri yang membawa proxy_set_header Upgrade $http_upgrade dan proxy_set_header Connection "upgrade", jika tidak, anda akan mendapat masalah pemutar (spinner) yang tersangkut akibat punca yang berbeza.

Memindahkan papan ke nama hos baharu kemudiannya bermaksud menukar dua perkara serentak: nilai BASE_URL dan peraturan Host() Traefik. Jika anda menukar satu dan terlupa yang lain, anda akan kembali menghadapi masalah pemutar tersebut. Menghoskan Planka daripada sublaluan (subpath) seperti https://example.com/planka berfungsi bermula dari versi 2.1.0 ke atas, yang dikeluarkan pada Mac 2026. Bagi tag yang lebih lama, gunakan subdomain sendiri untuknya.

Lokasi Planka menyimpan lampiran dan avatar

Planka 2 menyimpan semua muat naik pengguna di bawah satu laluan di dalam kontena: /app/data. Lampiran, avatar pengguna, dan imej latar belakang papan semuanya berada di bawah laluan tersebut. Versi 1 menggunakan tiga direktori berasingan, jadi fail Compose yang disalin daripada panduan lama akan memautkan laluan yang tidak lagi wujud, dan direktori data sebenar tidak akan dipautkan (unmounted).

Satu pautan (mount) tersebut adalah perbezaan antara papan yang kekal selepas naik taraf dan masalah besar yang tidak dijangka. Jika /app/data tidak berada pada volume, muat naik akan disimpan dalam lapisan boleh tulis (writable layer) kontena. Lapisan itu akan dimusnahkan apabila kontena dicipta semula, dan kontena dicipta semula setiap kali anda menukar tag imej. Papan akan kelihatan seperti biasa, semua kad masih ada, tetapi setiap pautan lampiran akan mati kerana baris pangkalan data masih merujuk kepada fail yang tidak lagi wujud.

Volume bernama dalam fail Compose di atas menghalang perkara ini. Bind mount juga boleh digunakan dan menjadikan fail lebih mudah untuk disandarkan dengan alatan biasa, tetapi ia memerlukan satu langkah tambahan. Proses Node di dalam kontena berjalan sebagai UID 1000, jadi direktori hos yang dimiliki oleh root akan menyebabkan ralat kebenaran (permission error) pada muat naik pertama:

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

Pertimbangan antara kedua-duanya dibincangkan dalam bind mounts berbanding named volumes.

Jika saiz lampiran melebihi kapasiti cakera dalam pelan anda, Planka boleh menulisnya ke storan yang serasi dengan S3, melalui S3_ENDPOINT, S3_BUCKET dan pemboleh ubah kunci yang sepadan. Ia boleh merujuk kepada bucket yang dihoskan atau storan objek MinIO yang dihoskan sendiri pada mesin lain. Tentukan perkara ini sebelum pasukan anda mengisi papan tersebut, kerana tetapan ini hanya terpakai untuk muat naik baharu.

Mulakan stack dan pastikan ia berfungsi

docker compose pull
docker compose up -d
docker compose ps

docker compose ps sepatutnya menunjukkan postgres sebagai healthy dan planka sebagai running. Jika Planka memulakan semula dalam gelung, sambungan pangkalan data adalah perkara pertama yang perlu diperiksa, bukan aplikasinya.

docker compose logs -f planka

But pertama yang sihat akan menjalankan migrasi pangkalan data dan kemudian melaporkan pelayan sedang mendengar pada port 1337. Sahkan skema benar-benar telah dimuatkan dengan bertanya kepada Postgres secara terus dan bukannya mempercayai log:

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

Senarai jadual yang merangkumi board dan card bermakna migrasi telah dijalankan. "Did not find any relations" bermakna Planka tidak pernah bersambung, jadi bandingkan DATABASE_URL dengan nilai POSTGRES_USER dan POSTGRES_PASSWORD dalam .env anda.

Kemudian periksa laluan dari mesin anda sendiri, bukan dari VPS:

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

HTTP/2 200 bermakna Traefik memegang sijil dan sedang mencapai kontena tersebut. Ralat 404 yang dihidangkan oleh Traefik bermakna label penghala tidak sepadan, selalunya kerana kontena tidak disambungkan ke rangkaian proxy. Sekarang buka laman tersebut dan log masuk dengan akaun admin.

Lakukan pg_dump sebelum setiap peningkatan versi

Dua storan berasingan menyimpan papan anda, jadi sandaran perlu merangkumi kedua-duanya: pangkalan data Postgres dan volum planka-data. Lakukan dump pangkalan data semasa stack sedang berjalan.

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

Penggunaan -T adalah wajib. Tanpa parameter ini, Compose akan memperuntukkan pseudo-terminal, dan lapisan terminal akan menulis semula penamat baris dalam aliran data. Akibatnya, anda akan mendapat fail dump yang gagal semasa proses pemulihan. Kegagalan ini mungkin muncul beberapa minggu kemudian, iaitu waktu yang paling buruk untuk berlaku.

Seterusnya, bahagian muat naik. Cari nama volum sebenar terlebih dahulu, kerana Compose meletakkan awalan nama direktori projek pada nama volum tersebut.

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 .

Projek ini juga menyertakan docker-backup.sh dan docker-restore.sh dalam repositorinya, dan dokumentasi rasmi mencadangkan ia dijalankan melalui cron job setiap malam. Mana-mana pendekatan adalah memadai. Apa yang tidak memadai ialah sandaran yang tidak pernah anda pulihkan. Jadi, pulihkan satu sandaran ke dalam VPS percubaan sekali dan sahkan bahawa anda boleh log masuk serta membuka lampiran.

Jalankan dump serta-merta sebelum setiap perubahan versi. Sandaran dari malam tadi tidak sama dengan sandaran yang dibuat sebelum migrasi yang bakal anda jalankan.

Sematkan tag dan baca nota keluaran

Kedua-dua tag imej dalam fail tersebut disematkan dengan sengaja.

ghcr.io/plankanban/planka:2.1.1 ialah keluaran khusus yang terkini setakat Ogos 2026. latest berubah setiap kali pihak hulu menerbitkan versi baharu, jadi docker compose pull rutin boleh membawa migrasi skema pada masa yang tidak anda jangka. Baca nota keluaran sebelum anda menukar nombor tersebut, kerana di situlah perubahan yang memecahkan keserasian (breaking changes) dan pembaikan keselamatan diterangkan. Versi 2.0.3 diterbitkan sebagai keluaran keselamatan, iaitu perkara yang anda perlu baca dan fahami, bukannya diterima secara tidak sengaja.

postgres:16-alpine disematkan pada versi utama atas sebab yang lebih kritikal. Postgres menulis direktori datanya dalam format yang terikat dengan versi utama, dan pelayan akan menolak untuk membuka direktori yang ditulis oleh versi yang berbeza. Tulis postgres:latest, biarkan tag berubah ke 17, dan kontena tidak akan bermula:

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.

Tiada data yang hilang, dan tiada masalah yang selesai dengan memulakan semula (restart). Beralih ke versi utama Postgres yang baharu bermakna anda perlu melakukan dump daripada versi lama dan restore ke dalam direktori data yang baharu. Ini adalah tugas terancang yang dilakukan semasa stack dimatikan, bukannya kesan sampingan daripada tarikan imej (image pull).

Jika anda memindahkan pemasangan Planka 1.x yang sedia ada dan bukannya bermula dari awal, naik taraf tersebut mempunyai prosedur tersendiri yang didokumentasikan dalam dokumentasi projek, dan tiada cara untuk kembali ke versi 1 tanpa sandaran (backup) yang dibuat terlebih dahulu.

Mod kegagalan dan rentetan yang akan anda lihat

Planka bermula semula dalam gelung dan log menamakan pangkalan data. Kredensial dalam DATABASE_URL tidak sepadan dengan persekitaran Postgres. Ambil perhatian bahawa POSTGRES_PASSWORD hanya digunakan apabila direktori data dimulakan buat kali pertama, jadi membetulkan pemboleh ubah selepas but pertama yang gagal tidak akan mengubah apa-apa. Anda perlu memadamkan volum db-data dan bermula semula.

Log masuk berjaya tetapi papan tidak pernah dimuatkan. BASE_URL tidak sepadan dengan alamat dalam bar pelayar, atau TRUST_PROXY tiada. Konsol pelayar menunjukkan permintaan yang gagal ke /socket.io/.

Muat naik gagal walaupun segala-galanya berfungsi. Bind mount dimiliki oleh root. Jalankan sudo chown -R 1000:1000 pada direktori hos dan mulakan semula kontena.

Lampiran hilang selepas naik taraf. /app/data tidak berada pada volum, jadi fail tersebut berada dalam lapisan kontena yang digantikan oleh naik taraf tersebut. Pulihkan fail daripada sandaran, kemudian tambah volum sebelum anda menyentuh tag imej lagi.

Traefik mengembalikan 404. Kontena tidak berada pada rangkaian proxy, atau peraturan Host() tidak sepadan dengan rekod DNS anda. docker compose config menunjukkan label selepas penggantian, di mana kesilapan taip akan kelihatan.

Pemberitahuan atau webhook tidak pernah sampai. Planka 2 menghantar permintaan HTTP keluar melalui penapis dalaman, dan senarai sekat lalai meliputi localhost dan postgres. Webhook yang ditujukan kepada kontena lain pada hos yang sama boleh disekat secara reka bentuk. Laraskan OUTGOING_ALLOWED_HOSTS dan bukannya membuang penapis tersebut.

Apabila ia berjalan, beban operasi adalah kecil. Pantau nota keluaran, dan buat dump pangkalan data sebelum setiap naik taraf. But semula akan mengembalikan stack secara automatik kerana restart: unless-stopped, selagi perkhidmatan Docker itu sendiri didayakan semasa but, dan Stack Compose yang kembali selepas but semula merangkumi kes di mana ia tidak berlaku.

FAQ

Mengapa Planka terus memuat selepas saya log masuk?

Kredential telah diterima tetapi sambungan langsung gagal. Planka membina URL WebSocket daripada BASE_URL, jadi jika pemboleh ubah tersebut masih menyatakan http://localhost:3000 sedangkan anda melayari tapak tersebut di https://kanban.example.com, pelayar akan cuba membuka soket ke alamat yang tidak wujud pada mesin anda. Konsol pembangun akan menunjukkan permintaan yang gagal ke /socket.io/. Tetapkan BASE_URL kepada alamat awam yang tepat tanpa garis miring di hujung, tambah TRUST_PROXY=true supaya aplikasi mematuhi pengepala X-Forwarded-Proto daripada reverse proxy anda, kemudian jalankan docker compose up -d.

Bagaimanakah cara saya mencipta pengguna pentadbir Planka yang pertama?

Sejak versi 1.13, tiada pentadbir dicipta secara automatik. Sama ada tetapkan DEFAULT_ADMIN_EMAIL dengan pemboleh ubah kata laluan, nama dan nama pengguna yang sepadan kemudian mulakan stack, atau jalankan docker compose run --rm planka npm run db:create-admin-user dan jawab soalan yang diberikan. Perintah interaktif adalah lebih selamat pada pelayan kongsi, kerana kata laluan tidak akan dimasukkan ke dalam persekitaran kontena di mana docker inspect boleh membacanya. Mengekalkan DEFAULT_ADMIN_EMAIL yang ditetapkan selepas itu akan mengunci akaun tersebut daripada sebarang suntingan dan pemadaman melalui antara muka.

Di manakah Planka menyimpan lampiran dan avatar?

Semua fail yang dimuat naik berada di bawah /app/data di dalam kontena dalam Planka 2, termasuk lampiran, avatar pengguna dan latar belakang papan. Lekapkan laluan tersebut pada volume bernama. Jika ia tidak dilekapkan, fail-fail tersebut akan berada dalam lapisan boleh tulis kontena dan akan musnah apabila kontena dicipta semula, yang berlaku pada setiap naik taraf imej. Bind mount juga boleh digunakan, tetapi proses Node berjalan sebagai UID 1000, jadi jalankan sudo chown -R 1000:1000 pada direktori hos atau muat naik akan gagal dengan ralat kebenaran.

Berapakah RAM yang diperlukan oleh Planka yang dihoskan sendiri?

Projek ini tidak menerbitkan keperluan perkakasan minimum. Angka 2 vCPU dan 4 GB yang sering diulang pada halaman pengehosan adalah lalai pembekal dan bukannya ukuran sebenar, malah ia agak berlebihan untuk papan kecil. Satu proses Node dan satu proses Postgres adalah keseluruhan beban kerja, jadi pelan 1 vCPU dan 2 GB sudah memadai untuk pasukan seramai dua hingga lima orang. Jalankan docker stats --no-stream selepas seminggu penggunaan biasa dan tentukan saiz berdasarkan angka anda sendiri. Pantau cakera dengan lebih teliti berbanding memori, kerana lampiran adalah perkara yang akan terus berkembang.

Bagaimanakah cara saya menaik taraf Planka tanpa kehilangan data?

Buat dump pangkalan data dan arkibkan volume muat naik serta-merta sebelum naik taraf, bukan berdasarkan jadual malam tadi. Gunakan docker compose exec -T postgres pg_dump -U planka -d planka > planka-db.sql, dengan mengekalkan -T supaya pseudo-terminal tidak merosakkan output yang dihalakan. Baca nota keluaran bagi setiap versi yang anda langkau, tukar tag imej kepada keluaran tertentu dan bukannya latest, kemudian jalankan docker compose pull dan docker compose up -d serta pantau log untuk migrasi. Pastikan tag Postgres kekal pada versi majornya, kerana pelayan akan menolak untuk membuka direktori data yang ditulis oleh versi major yang berbeza.