SSD Nodes Learn Hosting plans →
கல்வி வழிகாட்டிகள் Matt Connorஆல் Matt Connor · புதுப்பிக்கப்பட்டது 2026-08-30

Docker Compose மூலம் Planka-வை நிறுவுவது எப்படி?

Docker Compose மற்றும் Traefik பயன்படுத்தி Planka-வை உங்கள் VPS-ல் நிறுவுங்கள். Postgres அமைப்பு, admin bootstrap மற்றும் லாகின் சிக்கலைத் தீர்க்கும் BASE_URL குறித்த முழுமையான

Planka-வை self-host செய்வதன் மூலம் நீங்கள் பெறுபவை

Planka-வை self-host செய்வதன் மூலம், உங்கள் குழுவிற்கு Trello-வில் ஏற்கனவே பழக்கமான card, list மற்றும் label மாதிரியைக் கொண்ட Kanban board கிடைக்கிறது. இது நீங்கள் கட்டுப்படுத்தும் VPS-ல் இயங்குகிறது. இதில் seat limits அல்லது பயனர் வாரியான கட்டணங்கள் இல்லை, ஏனெனில் server-க்கான செலவு மட்டுமே ஒரே செலவாகும். இந்த வழிகாட்டி, Traefik-க்கு பின்னால் Docker Compose மூலம் இதை நிறுவுகிறது. தரவுகளுக்கு Postgres-ஐயும், பயனர்கள் பதிவேற்றும் கோப்புகளுக்கு named volume-ஐயும் பயன்படுத்துகிறது.

Trello-வின் இலவசத் திட்டத்திலிருந்து வெளியேறும் இரண்டு முதல் ஐந்து பேர் கொண்ட குழுக்களுக்காக இந்த வழிகாட்டி எழுதப்பட்டுள்ளது. எந்த board-ஐப் பயன்படுத்தலாம் என்று இன்னும் முடிவெடுக்கவில்லை என்றால், முதலில் self-hosted Trello மாற்றுகளின் ஒப்பீட்டை படிக்கவும். இந்த வழிகாட்டி, நீங்கள் ஏற்கனவே முடிவெடுத்துவிட்டதாகக் கருதி, நிறுவல் முறையை மட்டும் விளக்குகிறது.

உங்களுக்கு Docker Engine மற்றும் Compose plugin இயங்கும் ஒரு VPS-ம், அதைச் சுட்டிக்காட்டும் DNS A record-ம் தேவை. மேலும், அந்த server-ல் ஏற்கனவே TLS (transport layer security) termination செய்யும் Traefik instance இருக்க வேண்டும். Traefik இன்னும் அமைக்கப்படவில்லை என்றால், முதலில் பல Compose apps-க்கு முன்னால் ஒரு Traefik reverse proxy-ஐ அமைக்கவும். கீழே உள்ள கோப்பு உங்களுக்குப் புரியவில்லை என்றால், VPS-க்கான Docker Compose அடிப்படைகளை படிக்கவும்.

Planka-க்கு எவ்வளவு VPS தேவை?

இந்தத் திட்டம் வன்பொருள் தேவைகளுக்கான குறைந்தபட்ச அளவை வெளியிடவில்லை, எனவே நீங்கள் படிக்கும் எந்தவொரு எண்ணையும் ஒரு அளவீடாகக் கருதாமல், தொடக்கப் புள்ளியாகக் கருதுங்கள். ஹோஸ்டிங் பக்கங்களில் மீண்டும் மீண்டும் கூறப்படும் 2 vCPU மற்றும் 4 GB என்பது சேவை வழங்குநரின் வசதிக்கான இயல்புநிலை அளவே தவிர, திட்டத்தால் கணக்கிடப்பட்ட கட்டாயத் தேவை அல்ல. ஐந்து பேர் பயன்படுத்தும் ஒரு போர்டுக்கு இது தாராளமான அளவாகும்.

உண்மையில் இயங்குவது சிறிய அளவிலானவை: API மற்றும் கட்டமைக்கப்பட்ட frontend-ஐ வழங்கும் ஒரு Node.js process, மற்றும் தரவைச் சேமிக்கும் ஒரு Postgres process. Planka container-க்குள் அதன் வெளிச்செல்லும் கோரிக்கைகளை வடிகட்ட மூன்றாவது சிறிய proxy process இயங்குகிறது. 1 vCPU மற்றும் 2 GB திட்டம் இரண்டு முதல் ஐந்து பேர் கொண்ட போர்டைத் தாங்கும், மேலும் மீதமுள்ள நினைவகத்தில் பெரும்பகுதி Postgres cache-ஆகப் பயன்படும். ஒரு போர்டு என்பது இலகுவான ஒரு அண்டை சேவை, எனவே அதே VPS-ல் உங்கள் குழுவின் ஆவணங்களையும் சேமிக்கத் திட்டமிட்டால், அந்த application-க்கு முதலில் அளவு நிர்ணயம் செய்யுங்கள்: Notion போன்ற workspace-ஆக AFFiNE-ஐ இயக்குதல் என்பதற்கு Planka-வின் தேவைக்கு முன்பே சில GB நினைவகம் தேவைப்படும்.

நினைவகத்தை அளவிடும் முன் வட்டை (disk) அளவிடுங்கள், ஏனெனில் இணைப்புகள் (attachments) தான் காலப்போக்கில் வளரக்கூடியவை. இந்தப் பத்தியை நம்புவதை விட, உங்கள் instance-ஐ நீங்களே அளவிடுங்கள்:

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

முதல் கட்டளை ஒவ்வொரு container-ன் நேரடி நினைவகம் மற்றும் CPU பயன்பாட்டைக் காட்டுகிறது. இரண்டாவது கட்டளை ஒவ்வொரு volume-ம் எவ்வளவு இடத்தைப் பிடித்துள்ளது என்பதைக் காட்டுகிறது. இந்த அளவீடுகளை நிறுவிய நாளில் எடுக்காமல், ஒரு சாதாரண வேலை வாரத்திற்குப் பிறகு எடுங்கள், ஏனெனில் பயன்பாடற்ற ஒரு போர்டு உங்கள் குழுவின் தேவையைப் பற்றி எதையும் உணர்த்தாது.

Compose file-ஐ எழுதுதல்

கோப்பகத்தை உருவாக்கி, அதன் உரிமையைப் பெற்றுக்கொள்ளுங்கள். இதன் மூலம் நீங்கள் sudo வழியாக இந்த கோப்புகளைத் திருத்த வேண்டிய அவசியம் இருக்காது.

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

Compose கோப்பிற்கு அருகிலேயே .env கோப்பில் ரகசியங்களை (secrets) உருவாக்குங்கள். Compose தானாகவே அந்த கோப்பைப் படித்து மதிப்புகளைப் பதிலீடு செய்யும்.

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 என்பது வேண்டுமென்றே செய்யப்பட்டது. ஒரு hex string-ல் எண்கள் மற்றும் a முதல் f வரையிலான எழுத்துக்கள் மட்டுமே இருக்கும். எனவே, அது இணைக்கப்படும் DATABASE_URL connection string-ஐப் பாதிக்காது. ஒரு base64 கடவுச்சொல்லில் உள்ள slash அல்லது at sign, தவறான hostname போன்ற பிழையை ஏற்படுத்தும். இது உங்கள் நேரத்தை வீணடிக்கும். இதைப் பற்றிய விரிவான விளக்கம் Compose கோப்பில் ரகசியங்களை வைக்காமல் இருப்பது பகுதியில் உள்ளது.

இப்போது docker-compose.yml. kanban.example.com என்று உள்ள இடங்களில் உங்கள் சொந்த hostname-ஐப் பதிவிடுங்கள்.

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:

அந்தக் கோப்பில் எடுக்கப்பட்ட நான்கு முடிவுகள் விளக்கத்திற்குரியவை. ஏனெனில், மக்கள் அவற்றை மாற்றிய பிறகு வருத்தப்படுவார்கள்.

  • Planka service-ல் ports: பகுதி இல்லை. Traefik, proxy network வழியாக container-ஐ அடைகிறது. எனவே, port 1337 host-ல் வெளியிடப்படவில்லை (publish). அதை வெளியிட்டால், உங்கள் proxy மற்றும் certificate-ஐத் தவிர்த்துவிட்டு எவரும் உள்ளே நுழைய வழிவகை செய்ததாகிவிடும்.
  • loadbalancer.server.port=1337 என்பது container-க்குள் இருக்கும் port-ஐக் குறிக்கிறது. Planka 1337-ல் இயங்குகிறது. உதாரணங்களில் 3000-ல் அணுகப்படுவது, அது host-க்கு port-ஐ map செய்வதால் மட்டுமே. இங்கே host mapping இல்லாததால், Traefik-க்கு container port-ஐத் தெரிவிக்க வேண்டும்.
  • condition: service_healthy என்பது Postgres healthcheck-உடன் இணைகிறது. இது இல்லையென்றால், database இணைப்புகளை ஏற்கும் முன்பே Planka தொடங்க முயற்சிக்கும். முதல் query தோல்வியடைந்து, அது crash loop போலத் தோன்றும். இதன் நுட்பங்கள் Compose healthchecks மற்றும் startup ordering பகுதியில் உள்ளன.
  • Database service-க்கு postgres என்று பெயரிடப்பட்டுள்ளது. Planka 2 தனது வெளிச்செல்லும் கோரிக்கைகளை ஒரு internal filter வழியாக அனுப்புகிறது. அதன் default block list localhost,postgres ஆகும். service-ன் பெயரை மாற்றினால், உங்கள் database அந்தப் பட்டியலிலிருந்து நீக்கப்படும்.

எதையும் தொடங்கும் முன், Compose உங்கள் ரகசியங்களைப் பார்க்கிறதா என்பதைச் சரிபார்க்கவும்:

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

இது .env மதிப்புகள் ஏற்கனவே பதிலீடு செய்யப்பட்ட கோப்பை அச்சிடும். மதிப்பு காலியாக இருந்தால், Compose .env கோப்பைப் படிக்கவில்லை என்று அர்த்தம். பெரும்பாலும் நீங்கள் வேறு கோப்பகத்திலிருந்து கட்டளையை இயக்குவதால் இது நிகழும்.

நிர்வாகி bootstrap மாறிகள் உண்மையில் என்ன செய்கின்றன

Planka 1.13 பதிப்பிற்குப் பிறகு, உங்களுக்காக நிர்வாகி கணக்கு தானாக உருவாக்கப்படுவதில்லை. எனவே, புதிய database-ல் உள்நுழைய யாருக்கும் அனுமதி இருக்காது. DEFAULT_ADMIN_* தொகுதி இதைச் சரிசெய்யும் இரண்டு வழிகளில் ஒன்றாகும்.

தொடக்கத்தின்போது, DEFAULT_ADMIN_EMAIL-க்கு இணையான பயனர் யாராவது இருக்கிறார்களா என்று Planka சரிபார்க்கும். யாரும் இல்லை என்றால், அதனுடன் குறிப்பிடப்பட்டுள்ள கடவுச்சொல், காட்சிப் பெயர் மற்றும் பயனர் பெயரைப் பயன்படுத்தி ஒரு கணக்கை உருவாக்கும். இது காலியான database-ல் முதல்முறை boot செய்யும்போது மட்டுமே நடக்கும்; எனவே, இந்த மாறிகள் கணக்கை நிர்வகிக்க அல்ல, அதைத் தொடங்குவதற்கு (bootstrap) மட்டுமே பயன்படுகின்றன.

DEFAULT_ADMIN_EMAIL ஒரு கூடுதல் வேலையைச் செய்கிறது, இது பலரைச் சிக்கலில் தள்ளும். இந்த மாறி அமைக்கப்பட்டிருக்கும் வரை, அந்தப் பயனர் கணக்கை interface மூலம் யாராலும் திருத்தவோ அல்லது நீக்கவோ முடியாது. இது ஒரு பாதுகாப்பு பூட்டு (lock-out guard) ஆகும்; இதனால்தான் UI மூலம் அந்தப் பயனர் பெயரை மாற்றவோ அல்லது மின்னஞ்சல் முகவரியை மாற்றவோ முடியாது. இந்த மாறியை நீக்கிவிட்டு restart செய்தால், அந்தக் கணக்கு மற்ற சாதாரண நிர்வாகிக் கணக்குகளைப் போலவே திருத்தக்கூடியதாக மாறிவிடும்.

கடவுச்சொல் வரியைக் கையாளும்போது கவனமாக இருக்க வேண்டும். environment:-ன் கீழ் உள்ள எதையும், container-ல் docker inspect-ஐ இயக்கக்கூடிய எவரும் படிக்க முடியும். எனவே, DEFAULT_ADMIN_PASSWORD-ஐ நிரந்தரமாக அங்கே வைத்திருக்கக்கூடாது. உள்நுழைந்து, interface-ல் உங்கள் கடவுச்சொல்லை மாற்றிய பிறகு, அந்த வரியை நீக்கிவிட்டு, மீண்டும் docker compose up -d-ஐ இயக்கவும்.

மாறிகளைத் தவிர்ப்பதே தூய்மையான வழி. DEFAULT_ADMIN_* தொகுதியை முழுமையாக comment செய்துவிட்டு, கணக்கை நேரடியாக உருவாக்கவும்:

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

இது மின்னஞ்சல், கடவுச்சொல், காட்சிப் பெயர் மற்றும் விருப்பத்தேர்வான பயனர் பெயரைப் கேட்கும், மேலும் பயனரை நேரடியாக database-ல் பதிவு செய்யும். கடவுச்சொல் ஒருபோதும் Compose கோப்பையோ அல்லது container சூழலையோ சென்றடையாது. VPS-க்கு ஒன்றுக்கும் மேற்பட்டவர்களுக்கு shell access இருந்தால், இந்த முறையைப் பயன்படுத்தவும். depends_on காரணமாக, இந்த command முதலில் Postgres-ஐத் தொடங்கும், எனவே இது இதுவரை இயங்காத stack-லும் வேலை செய்யும்.

எந்த முறையைப் பயன்படுத்தினாலும், Planka கடவுச்சொற்களை நீங்களே நிர்வகிக்க வேண்டியிருக்கும். உங்கள் குழுவிடம் ஏற்கனவே நான்கு வகையான நற்சான்றிதழ்கள் (credentials) இருந்தால், Planka-வின் உள்நுழைவை OIDC provider-க்கு மாற்றலாம். உதாரணமாக, உங்கள் சொந்த single sign-on server-ஆக இயங்கும் Authentik-ஐப் பயன்படுத்தலாம். bootstrap நிர்வாகிக் கணக்கை, provider செயலிழக்கும் நாட்களுக்காக ஒரு அவசரக்கால கணக்காக (break-glass account) வைத்துக்கொள்ளலாம்.

BASE_URL hostname-உடன் பொருந்தாதபோது ஏன் login தோல்வியடைகிறது

BASE_URL என்பது பயனர்கள் browser-ல் உள்ளீடு செய்யும் சரியான முகவரியாகும்; இதில் scheme இருக்க வேண்டும், இறுதியில் slash இருக்கக்கூடாது. இந்த stack-க்கு அது https://kanban.example.com ஆகும். Planka தனது சொந்த இணைப்புகளையும் WebSocket இணைப்பையும் அந்த மதிப்பைக் கொண்டே உருவாக்குகிறது. எனவே, தவறான BASE_URL இருந்தால், அது தெளிவான பிழைச் செய்தியைக் காட்டாது. மாறாக, பக்கம் லோட் ஆகும், ஆனால் முழுமையாக லோட் ஆகி முடிவடையாது.

பொதுவான தவறு இதுதான்: நீங்கள் upstream உதாரணத்தை நகலெடுத்து, BASE_URL=http://localhost:3000-ஐ அப்படியே விட்டுவிட்டு, உங்கள் உண்மையான domain-ல் HTTPS மூலம் தளத்தை அணுகுகிறீர்கள். Login form-ல் விவரங்களை உள்ளிட்டு சமர்ப்பித்ததும், உங்கள் credentials ஏற்கப்படும். ஆனால், board திரையில் தோன்றாது. Browser developer console-ஐத் திறந்து பார்த்தால், /socket.io/-க்கான கோரிக்கைகள் தோல்வியடைவதைக் காணலாம். ஏனெனில், client தனது live இணைப்பை localhost:3000-க்கு ஏற்படுத்தும்படி அறிவுறுத்தப்பட்டுள்ளது, ஆனால் உங்கள் கணினியில் அந்த முகவரி எதுவுமே இல்லை.

TRUST_PROXY=true என்பது இதே பிரச்சினையின் மற்றொரு பகுதியாகும். Planka, Traefik-க்கு பின்னால் இயங்குகிறது. எனவே, ஒவ்வொரு கோரிக்கையும் Docker network-க்குள் plain HTTP வழியாக proxy முகவரியிலிருந்து வருகிறது. TRUST_PROXY இல்லையென்றால், Traefik அமைக்கும் X-Forwarded-Proto மற்றும் X-Forwarded-For headers-ஐ அந்த application புறக்கணித்துவிடும். இதனால், இணைப்பு பாதுகாப்பற்றது என்று கருதி, அனைத்து client-களையும் ஒரே IP முகவரியாக அது கையாளும். இதை அமைப்பதன் மூலம், அந்த headers-ஐ வாசித்து, browser-ன் scheme-உடன் application ஒத்துப்போகும்.

Traefik எந்த கூடுதல் அமைப்பும் இன்றி WebSockets-ஐ proxy செய்கிறது, இதனால்தான் இங்கு Traefik-ஐப் பயன்படுத்துவது சிறந்தது. Nginx-ல், socket.io-க்கு proxy_set_header Upgrade $http_upgrade மற்றும் proxy_set_header Connection "upgrade" ஆகியவற்றை உள்ளடக்கிய தனி location block தேவைப்படுகிறது. இல்லையெனில், அதே போன்ற spinner சிக்கல் வேறு காரணத்தால் ஏற்படும்.

Board-ஐப் பிற்காலத்தில் புதிய hostname-க்கு மாற்றும்போது, இரண்டு விஷயங்களைச் சேர்த்து மாற்ற வேண்டும்: BASE_URL மதிப்பு மற்றும் Traefik Host() விதி. ஒன்றை மாற்றிவிட்டு மற்றொன்றை மறந்துவிட்டால், மீண்டும் spinner சிக்கலே ஏற்படும். மார்ச் 2026-ல் வெளியான 2.1.0 பதிப்பிலிருந்து, https://example.com/planka போன்ற subpath-ல் Planka-வை இயக்குவது சாத்தியம். பழைய பதிப்புகளில், அதற்குத் தனி subdomain-ஐப் பயன்படுத்தவும்.

Planka இணைப்புகள் மற்றும் அவதாரங்களை எங்கு சேமிக்கிறது

Planka 2, பயனர் பதிவேற்றும் அனைத்தையும் container-க்குள் ஒரே பாதையில் சேமிக்கிறது: /app/data. இணைப்புகள் (attachments), பயனர் அவதாரங்கள் மற்றும் board பின்னணி படங்கள் அனைத்தும் இதற்குக் கீழேதான் அமையும். பதிப்பு 1-ல் மூன்று தனித்தனி கோப்பகங்கள் (directories) பயன்படுத்தப்பட்டன. எனவே, பழைய கட்டுரைகளிலிருந்து நகலெடுக்கப்பட்ட Compose கோப்பு தற்போது இல்லாத பாதைகளை mount செய்யக்கூடும், இதனால் உண்மையான தரவு கோப்பகம் mount செய்யப்படாமல் போகும்.

அந்த ஒற்றை mount-தான், ஒரு upgrade-க்குப் பிறகும் board அப்படியே இருப்பதற்கும், ஒரு மோசமான மதியத்திற்கும் இடையிலான வித்தியாசம். /app/data ஒரு volume-ல் இல்லை என்றால், பதிவேற்றங்கள் container-ன் writable layer-ல் சேமிக்கப்படும். நீங்கள் image tag-ஐ மாற்றும்போதெல்லாம் container மீண்டும் உருவாக்கப்படும், அப்போது அந்த layer அழிக்கப்படும். Board பார்ப்பதற்குச் சரியாகத் தெரியும், cards அனைத்தும் இருக்கும், ஆனால் ஒவ்வொரு இணைப்பு இணைப்பும் (attachment link) வேலை செய்யாது. ஏனெனில், database வரிசைகள் இப்போது இல்லாத கோப்புகளைச் சுட்டிக்காட்டும்.

மேலே உள்ள Compose கோப்பில் உள்ள named volume இதைத் தடுக்கிறது. Bind mount-ம் வேலை செய்யும், மேலும் சாதாரண கருவிகளைக் கொண்டு கோப்புகளை backup எடுப்பதை இது எளிதாக்குகிறது. ஆனால், இதற்கு ஒரு கூடுதல் படி தேவை. Container-க்குள் இருக்கும் Node process, UID 1000-ஆக இயங்குகிறது. எனவே, root-க்குச் சொந்தமான host கோப்பகத்தில் முதல் பதிவேற்றத்தின்போது அனுமதிப் பிழை (permission error) ஏற்படும்:

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

இவ்விரண்டிற்கும் இடையிலான சாதக பாதகங்கள் bind mounts against named volumes பகுதியில் விளக்கப்பட்டுள்ளன.

உங்கள் திட்டத்தில் இணைப்புகள் disk கொள்ளளவை விட அதிகரித்தால், S3_ENDPOINT, S3_BUCKET மற்றும் அதனுடன் தொடர்புடைய key variables மூலம் Planka அவற்றை S3-compatible சேமிப்பகத்தில் எழுத முடியும். இது ஒரு hosted bucket-ஐ அல்லது மற்றொரு பெட்டியில் உள்ள a self-hosted MinIO object store-ஐச் சுட்டிக்காட்டலாம். குழுவினர் board-ஐப் பயன்படுத்துவதற்கு முன்பே இதை முடிவு செய்யுங்கள், ஏனெனில் இந்த அமைப்பு புதிய பதிவேற்றங்களுக்கு மட்டுமே பொருந்தும்.

Stack-ஐத் தொடங்கி அது சரியாக வேலை செய்கிறதா எனச் சரிபார்த்தல்

docker compose pull
docker compose up -d
docker compose ps

docker compose ps கட்டளை postgres-ஐ healthy ஆகவும், planka-ஐ running ஆகவும் காட்ட வேண்டும். Planka தொடர்ந்து restart ஆகிக்கொண்டிருந்தால், application-ஐ விட முதலில் database இணைப்பைச் சரிபார்க்க வேண்டும்.

docker compose logs -f planka

சரியான முதல் boot-ன் போது database migrations இயங்கி, server 1337 port-ல் listening நிலையில் இருப்பதாகத் தெரிவிக்கும். Log-ஐ மட்டும் நம்பாமல், Postgres-ஐ நேரடியாகக் கேட்டு schema சரியாகப் பதிவாகியுள்ளதா என்பதை உறுதிப்படுத்தவும்:

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

board மற்றும் card ஆகியவற்றை உள்ளடக்கிய table பட்டியல் இருந்தால், migrations சரியாக இயங்கியுள்ளன என்று பொருள். "Did not find any relations" என்று வந்தால், Planka இணைப்பை ஏற்படுத்தவில்லை என்று பொருள்; எனவே DATABASE_URL-ஐ உங்கள் .env-ல் உள்ள POSTGRES_USER மற்றும் POSTGRES_PASSWORD மதிப்புகளுடன் ஒப்பிட்டுச் சரிபார்க்கவும்.

பிறகு, VPS-லிருந்து அல்லாமல், உங்கள் சொந்த கணினியிலிருந்து route-ஐச் சரிபார்க்கவும்:

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

HTTP/2 200 என்பது Traefik ஒரு certificate-ஐக் கொண்டுள்ளதையும், container-ஐ அடைவதையும் குறிக்கிறது. Traefik மூலம் 404 பிழை கிடைத்தால், router labels பொருந்தவில்லை என்று பொருள்; பெரும்பாலும் container proxy network-உடன் இணைக்கப்படாததே இதற்குக் காரணமாக இருக்கும். இப்போது தளத்தைத் திறந்து, admin கணக்கைப் பயன்படுத்தி உள்நுழையவும்.

ஒவ்வொரு version மாற்றத்திற்கு முன்பும் pg_dump எடுக்கவும்

உங்கள் board-ன் தரவுகள் இரண்டு தனித்தனி இடங்களில் சேமிக்கப்படுகின்றன. எனவே, Postgres database மற்றும் planka-data volume ஆகிய இரண்டையும் உள்ளடக்கியே backup எடுக்க வேண்டும். stack இயங்கிக்கொண்டிருக்கும்போதே database-ஐ dump செய்யவும்.

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

-T கட்டாயம் தேவை. இது இல்லையென்றால், Compose ஒரு pseudo-terminal-ஐ ஒதுக்கும். அந்த terminal layer stream-ல் உள்ள line endings-ஐ மாற்றிவிடும். இதனால், restore செய்யும்போது பாதியிலேயே தோல்வியடையும் ஒரு dump file உங்களுக்குக் கிடைக்கும். இந்தத் தோல்வி பல வாரங்களுக்குப் பிறகுதான் தெரியவரும், இதுவே மிக மோசமான சூழலாகும்.

அடுத்து, uploads. முதலில் சரியான volume பெயரைத் தேடிக் கண்டறியவும், ஏனெனில் Compose உங்கள் project directory பெயரை அதனுடன் முன்னொட்டாக (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 .

இந்த project-ன் repository-ல் docker-backup.sh மற்றும் docker-restore.sh ஆகியவையும் உள்ளன. அதிகாரப்பூர்வ ஆவணங்கள் இவற்றை nightly cron job-ல் சேர்க்கப் பரிந்துரைக்கின்றன. இதில் எந்த முறையைப் பின்பற்றினாலும் சரிதான். ஆனால், ஒருபோதும் restore செய்து பார்க்காத backup-ஐ நம்பக்கூடாது. எனவே, ஒருமுறை scratch VPS-ல் restore செய்து, உங்களால் login செய்ய முடிகிறதா மற்றும் attachment-ஐத் திறக்க முடிகிறதா என்பதை உறுதிப்படுத்திக் கொள்ளுங்கள். uploads-ஐ ஏற்கும் ஒவ்வொரு Compose app-லும் இதே போன்ற இரண்டு சேமிப்பிடங்கள் இருக்கும். எனவே, பிற்காலத்தில் நீங்கள் Chatwoot-ஐ உங்கள் support desk இருக்கும் அதே server-ல் நிறுவினால், இங்கே நீங்கள் உருவாக்கும் நடைமுறையை volume பெயர்களை மட்டும் மாற்றி அப்படியே பயன்படுத்திக்கொள்ளலாம்.

ஒவ்வொரு version மாற்றத்திற்கு முன்பும் உடனடியாக dump எடுக்கவும். நேற்று எடுக்கப்பட்ட backup-க்கும், நீங்கள் செய்யப்போகும் migration-க்கு முன்பு எடுக்கப்படும் backup-க்கும் பெரிய வித்தியாசம் உள்ளது.

Tags-ஐ Pin செய்து release notes-ஐ வாசிக்கவும்

அந்தக் கோப்பில் உள்ள இரண்டு image tags-ம் வேண்டுமென்றே pin செய்யப்பட்டுள்ளன.

ghcr.io/plankanban/planka:2.1.1 என்பது ஒரு குறிப்பிட்ட release ஆகும், இது ஆகஸ்ட் 2026 நிலவரப்படி தற்போதைய பதிப்பாகும். latest என்பது upstream வெளியிடும் போதெல்லாம் மாறும், எனவே ஒரு வழக்கமான docker compose pull நீங்கள் எதிர்பாராத நேரத்தில் schema migration-ஐ ஏற்படுத்தலாம். அந்த எண்ணை மாற்றுவதற்கு முன் release notes-ஐ வாசிக்கவும், ஏனெனில் அங்குதான் breaking changes மற்றும் security fixes விவரிக்கப்பட்டிருக்கும். Version 2.0.3 ஒரு security release-ஆக வெளியிடப்பட்டது; இது போன்ற தகவல்களைத் தற்செயலாகப் பெறுவதை விட, முன்கூட்டியே வாசிப்பதே சிறந்தது. Upstream-ல் images கிடைப்பதால் இங்கே pinning செய்வது எளிது; ஒரு project எதையும் வெளியிடவில்லை என்றால், checked-out git tag-லிருந்து box-ல் build செய்யப்பட்ட openGym போன்ற கூடுதல் முயற்சியுடன் அதே ஒழுக்கத்தைப் பின்பற்ற வேண்டும்.

postgres:16-alpine ஒரு major version-க்கு pin செய்யப்பட்டுள்ளது, இதற்கு ஒரு முக்கியமான காரணம் உள்ளது. Postgres தனது data directory-ஐ அந்த major version-க்கு உரிய format-ல் எழுதும்; வேறு ஒரு version-ல் எழுதப்பட்ட directory-ஐத் திறக்க server மறுத்துவிடும். நீங்கள் postgres:latest என்று எழுதி, tag-ஐ 17-க்கு மாற அனுமதித்தால், container தொடங்காது:

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.

எதுவும் இழக்கப்படாது, restart செய்வதால் எதுவும் சரியாகாது. புதிய Postgres major version-க்கு மாறுவது என்பது பழைய version-லிருந்து dump எடுத்து, புதிய version-ல் உள்ள புதிய data directory-ல் restore செய்வதாகும். இது stack-ஐ நிறுத்திவிட்டுத் திட்டமிட்டுச் செய்ய வேண்டிய வேலை; image pull செய்வதால் ஏற்படும் பக்கவிளைவு அல்ல.

நீங்கள் புதிதாகத் தொடங்காமல் ஏற்கனவே உள்ள Planka 1.x install-ஐ மாற்றுகிறீர்கள் என்றால், அந்த upgrade-க்கு project documentation-ல் தனிப்பட்ட நடைமுறை உள்ளது. முன்னதாக backup எடுக்காமல் version 1-க்குத் திரும்ப வழி இல்லை.

தோல்வி முறைகள் மற்றும் நீங்கள் காணும் செய்திகள்

Planka தொடர்ச்சியாக restart ஆகிறது மற்றும் log-ல் database பற்றிய பிழை உள்ளது. DATABASE_URL-ல் உள்ள நற்சான்றிதழ்கள் (credentials) Postgres சூழலுடன் பொருந்தவில்லை. POSTGRES_PASSWORD என்பது தரவு அடைவு (data directory) முதன்முதலில் உருவாக்கப்படும்போது மட்டுமே பயன்படுத்தப்படும் என்பதை கவனத்தில் கொள்க. எனவே, தவறான முதல் boot-க்கு பிறகு இந்த variable-ஐ மாற்றினாலும் எந்த மாற்றமும் இருக்காது. நீங்கள் db-data volume-ஐ நீக்கிவிட்டு மீண்டும் தொடங்க வேண்டும்.

Login வெற்றிகரமாக முடிகிறது, ஆனால் board ஏற்றப்படவில்லை. BASE_URL என்பது browser முகவரிப் பட்டியில் உள்ள முகவரியுடன் பொருந்தவில்லை, அல்லது TRUST_PROXY விடுபட்டுள்ளது. Browser console-ல் /socket.io/-க்கு செல்லும் கோரிக்கைகள் தோல்வியடைவதைக் காணலாம்.

மற்ற அனைத்தும் சரியாக இயங்கினாலும், கோப்புகளைப் பதிவேற்ற (uploads) முடியவில்லை. Bind mount-ன் உரிமையாளர் root ஆக இருக்கலாம். Host அடைவில் sudo chown -R 1000:1000 கட்டளையை இயக்கி, container-ஐ restart செய்யவும்.

Upgrade செய்த பிறகு இணைப்புகள் (attachments) காணவில்லை. /app/data ஒரு volume-ல் இல்லை, எனவே கோப்புகள் container layer-ல் இருந்தன; upgrade-ன் போது அவை நீக்கப்பட்டுவிட்டன. Backup-லிருந்து கோப்புகளை மீட்டெடுக்கவும், பின்னர் image tag-ஐ மாற்றும் முன் volume-ஐச் சேர்க்கவும்.

Traefik 404 பிழையைக் காட்டுகிறது. Container proxy network-ல் இல்லை, அல்லது Host() விதி உங்கள் DNS பதிவோடு பொருந்தவில்லை. docker compose config கட்டளை labels-ஐ மாற்றியமைத்த பிறகு காட்டும், அங்குதான் தட்டச்சுப் பிழைகளை (typos) கண்டறிய முடியும்.

அறிவிப்புகள் (notifications) அல்லது webhooks வரவில்லை. Planka 2 தனது வெளிச்செல்லும் HTTP கோப்புகளை ஒரு internal filter வழியாக அனுப்புகிறது, மேலும் இயல்புநிலை தடுப்புப் பட்டியலில் (block list) localhost மற்றும் postgres உள்ளன. ஒரே host-ல் உள்ள மற்றொரு container-க்கு அனுப்பப்படும் webhook, வடிவமைப்பின்படி தடுக்கப்படலாம். Filter-ஐ நீக்குவதற்குப் பதிலாக OUTGOING_ALLOWED_HOSTS-ஐ மாற்றியமைக்கவும்.

ஒருமுறை இயங்கத் தொடங்கிய பிறகு, செயல்பாட்டுச் சுமை குறைவாகவே இருக்கும். Release notes-ஐக் கவனிக்கவும், ஒவ்வொரு upgrade-க்கு முன்பும் database-ஐ dump செய்யவும். restart: unless-stopped காரணமாக, Docker service boot-ன் போது enabled நிலையில் இருந்தால், reboot-க்கு பிறகு stack தானாகவே மீண்டும் இயங்கும். reboot-க்கு பிறகு மீண்டும் தொடங்கும் Compose stacks என்ற பகுதியில், அவ்வாறு இயங்காத சூழல்கள் விளக்கப்பட்டுள்ளன.

FAQ

நான் உள்நுழைந்த பிறகு Planka ஏன் தொடர்ந்து லோட் ஆகிக்கொண்டே இருக்கிறது?

உங்கள் நற்சான்றிதழ்கள் (credentials) ஏற்றுக்கொள்ளப்பட்டன, ஆனால் நேரடி இணைப்பு (live connection) ஏற்படவில்லை. Planka அதன் WebSocket URL-ஐ BASE_URL-லிருந்து உருவாக்குகிறது. எனவே, நீங்கள் https://kanban.example.com முகவரியில் தளத்தை அணுகும்போது, அந்த variable இன்னும் http://localhost:3000 என்று இருந்தால், உங்கள் கணினியில் இல்லாத ஒரு முகவரிக்கு socket-ஐத் திறக்க browser முயலும். Developer console-ல் /socket.io/-க்குச் செல்லும் கோரிக்கைகள் தோல்வியடைவதைக் காணலாம். BASE_URL-ல் இறுதியில் slash இல்லாமல் சரியான பொது முகவரியை (public address) அமைக்கவும். உங்கள் reverse proxy-யிலிருந்து வரும் X-Forwarded-Proto header-ஐ app ஏற்றுக்கொள்வதற்காக TRUST_PROXY=true-ஐச் சேர்க்கவும். பிறகு docker compose up -d கட்டளையை இயக்கவும்.

முதல் Planka admin பயனர் கணக்கை எவ்வாறு உருவாக்குவது?

பதிப்பு 1.13 முதல், நிர்வாகி கணக்கு தானாக உருவாக்கப்படுவதில்லை. DEFAULT_ADMIN_EMAIL-ல் அதற்கான கடவுச்சொல், பெயர் மற்றும் பயனர் பெயரை அமைத்து stack-ஐத் தொடங்கலாம், அல்லது docker compose run --rm planka npm run db:create-admin-user-ஐ இயக்கி கேட்கப்படும் கேள்விகளுக்குப் பதிலளிக்கலாம். பகிரப்பட்ட server-ல் இந்த interactive கட்டளையே பாதுகாப்பானது, ஏனெனில் கடவுச்சொல் container சூழலுக்குள் செல்லாது, அங்கு docker inspect-ஆல் அதைப் படிக்க முடியாது. அதன் பிறகு DEFAULT_ADMIN_EMAIL-ஐ அமைத்து வைத்திருப்பது, அந்த கணக்கை interface மூலம் திருத்துவதிலிருந்தோ அல்லது நீக்குவதிலிருந்தோ பாதுகாக்கும்.

Planka கோப்புகளை (attachments) மற்றும் அவதாரங்களை (avatars) எங்கே சேமிக்கிறது?

Planka 2-ல், பதிவேற்றப்பட்ட அனைத்து கோப்புகளும், attachments, பயனர் அவதாரங்கள் மற்றும் board பின்னணிகள் உட்பட, container-க்குள் /app/data என்ற பாதையில் சேமிக்கப்படுகின்றன. அந்தப் பாதையை ஒரு named volume-ஆக mount செய்யவும். அது mount செய்யப்படவில்லை என்றால், கோப்புகள் container-ன் writable layer-ல் தங்கிவிடும். அடுத்த முறை container மீண்டும் உருவாக்கப்படும்போது (ஒவ்வொரு image upgrade-ன் போதும் இது நடக்கும்) அவை அழிந்துவிடும். Bind mount-ம் வேலை செய்யும், ஆனால் Node process UID 1000-ஆக இயங்குவதால், host directory-ல் sudo chown -R 1000:1000 கட்டளையை இயக்கவும், இல்லையெனில் அனுமதி மறுப்பு (permission error) காரணமாக பதிவேற்றங்கள் தோல்வியடையும்.

சுய-ஹோஸ்ட் செய்யப்பட்ட (self-hosted) Planka-விற்கு எவ்வளவு RAM தேவை?

இந்தத் திட்டம் குறைந்தபட்ச வன்பொருள் தேவையை (hardware floor) நிர்ணயிக்கவில்லை. ஹோஸ்டிங் பக்கங்களில் குறிப்பிடப்படும் 2 vCPU மற்றும் 4 GB என்பது ஒரு வழங்குநரின் பொதுவான பரிந்துரையே தவிர, அளவீடு அல்ல; சிறிய board-களுக்கு இது தாராளமானது. ஒரு Node process மற்றும் ஒரு Postgres process மட்டுமே மொத்த பணிச்சுமை என்பதால், 1 vCPU மற்றும் 2 GB திட்டம் இரண்டு முதல் ஐந்து பேர் கொண்ட குழுவிற்குப் போதுமானது. ஒரு வாரம் இயங்கிய பிறகு docker stats --no-stream கட்டளையை இயக்கி, உங்கள் பயன்பாட்டுத் தரவுகளின் அடிப்படையில் அளவை முடிவு செய்யுங்கள். நினைவகத்தை விட வட்டு (disk) பயன்பாட்டைக் கவனமாகக் கண்காணியுங்கள், ஏனெனில் attachments-தான் காலப்போக்கில் வளரும்.

தரவு இழப்பின்றி Planka-வை எவ்வாறு upgrade செய்வது?

Upgrade செய்வதற்கு முன்னதாகவே, தரவுத்தளத்தை dump செய்து, uploads volume-ஐ archive செய்யவும்; முந்தைய நாள் இரவு எடுத்த backup-ஐ நம்ப வேண்டாம். docker compose exec -T postgres pg_dump -U planka -d planka > planka-db.sql-ஐப் பயன்படுத்தவும், அப்போது -T-ஐ அப்படியே வைத்திருக்கவும், இது pseudo-terminal-ஆல் output சிதைவதைத் தடுக்கும். நீங்கள் தவிர்க்கும் ஒவ்வொரு பதிப்பிற்கான release notes-ஐயும் படிக்கவும். Image tag-ஐ latest என்பதற்குப் பதிலாக ஒரு குறிப்பிட்ட பதிப்பிற்கு மாற்றவும். பிறகு docker compose pull மற்றும் docker compose up -d கட்டளைகளை இயக்கி, migration நடப்பதைக் கண்காணிக்கவும். Postgres tag-ஐ அதன் major பதிப்பிலேயே வைத்திருக்கவும், ஏனெனில் வெவ்வேறு major பதிப்புகளில் எழுதப்பட்ட தரவு அடைவை (data directory) server திறக்க மறுத்துவிடும்.

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