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

Planka-வை self-host செய்வதன் நன்மைகள்

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

Trello-வின் இலவசத் திட்டத்திலிருந்து வெளியேறும் 2 முதல் 5 பேர் கொண்ட குழுக்களுக்காக இந்த வழிகாட்டி எழுதப்பட்டுள்ளது. எந்த 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-ஆகப் பயன்படுத்தப்படும்.

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

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

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

Compose கோப்பை எழுதுதல்

கோப்பகத்தை உருவாக்கி, அதன் உரிமையை மாற்றிக்கொள்ளுங்கள். இதன் மூலம் நீங்கள் 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) சரத்தில் எண்களும் a முதல் f வரையிலான எழுத்துகளும் மட்டுமே இருக்கும். எனவே, அது ஒட்டப்படும் DATABASE_URL இணைப்புச் சரத்தை (connection string) அது சிதைக்காது. ஒரு base64 கடவுச்சொல்லில் ஸ்லாஷ் (/) அல்லது அட் (@) குறியீடு இருந்தால், அது தவறான ஹோஸ்ட் பெயர் (hostname) போன்ற பிழையை ஏற்படுத்தும். அதைச் சரிசெய்ய ஒரு மணிநேரம் வீணாகும். இது குறித்த விரிவான விளக்கம் Compose கோப்பில் ரகசியங்களை வைக்காமல் இருத்தல் பகுதியில் உள்ளது.

இப்போது docker-compose.yml. kanban.example.com என்று குறிப்பிடப்பட்டுள்ள இரண்டு இடங்களிலும் உங்கள் சொந்த ஹோஸ்ட் பெயரைப் பதிவிடுங்கள்.

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 சேவையில் ports: தொகுதி இல்லை. Traefik ஆனது proxy நெட்வொர்க் வழியாக கன்டெய்னரை அடைகிறது, எனவே 1337 போர்ட் ஹோஸ்டில் வெளியிடப்படுவதில்லை (published). அதை வெளியிட்டால், எவரும் உங்கள் ப்ராக்ஸி மற்றும் சான்றிதழைத் தவிர்த்துவிட்டு உள்ளே வர வழிவகுக்கும்.
• loadbalancer.server.port=1337 கன்டெய்னருக்குள் இருக்கும் போர்ட்டைக் குறிக்கிறது. Planka 1337-ல் இயங்குகிறது. அப்ஸ்ட்ரீம் உதாரணங்கள் 3000-ல் அதை அடைகின்றன, ஏனெனில் அவை போர்ட்டை ஹோஸ்டுடன் மேப் செய்கின்றன. இங்கே ஹோஸ்ட் மேப்பிங் இல்லை, எனவே Traefik-க்கு கன்டெய்னர் போர்ட் எது என்று தெரிவிக்க வேண்டும்.
• condition: service_healthy ஆனது Postgres ஹெல்த்செக்குடன் (healthcheck) இணைகிறது. இது இல்லையென்றால், தரவுத்தளம் இணைப்புகளை ஏற்கும் முன்பே Planka தொடங்க முயற்சிக்கும், முதல் குவரியிலேயே தோல்வியடைந்து வெளியேறும். இது ஒரு கிராஷ் லூப் (crash loop) போலத் தோன்றும். இதன் நுட்பங்கள் Compose ஹெல்த்செக்குகள் மற்றும் தொடக்க வரிசைமுறை பகுதியில் உள்ளன.
• தரவுத்தள சேவைக்கு postgres என்று பெயரிடப்பட்டுள்ளது. Planka 2 தனது வெளிச்செல்லும் கோரிக்கைகளை ஒரு உள் வடிகட்டி (internal filter) வழியாக அனுப்புகிறது. அதன் இயல்புநிலை தடுப்புப் பட்டியலில் localhost,postgres உள்ளது. சேவையின் பெயரை மாற்றினால், உங்கள் தரவுத்தளம் அந்தப் பட்டியலிலிருந்து நீக்கப்படும்.

எதையும் தொடங்கும் முன், உங்கள் ரகசியங்களை 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-ல் முதல்முறை தொடங்கும் போது மட்டுமே நடக்கும். எனவே, இந்த மாறிகள் கணக்கை நிர்வகிக்காமல், பூட்ஸ்டார்ப் (bootstrap) செய்ய மட்டுமே பயன்படுகின்றன.

DEFAULT_ADMIN_EMAIL ஒரு கூடுதல் பணியைச் செய்கிறது, இது பலரை குழப்பமடையச் செய்யும். இந்த மாறி அமைக்கப்பட்டிருக்கும் வரை, அந்தப் பயனர் கணக்கை interface மூலம் யாராலும் திருத்தவோ அல்லது நீக்கவோ முடியாது. இது ஒரு பாதுகாப்பு பூட்டு (lock-out guard) ஆகும். இதனால்தான் அந்தப் பயனர் கணக்கின் பெயரை மாற்றவோ அல்லது மின்னஞ்சல் முகவரியை UI-ல் மாற்றவோ முடியாது. அந்த மாறியை நீக்கிவிட்டு, service-ஐ 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-ஐப் பயன்படுத்தலாம். பூட்ஸ்டார்ப் செய்யப்பட்ட நிர்வாகி கணக்கை, provider செயலிழக்கும் காலங்களுக்காக ஒரு 'break-glass' கணக்காக மட்டும் வைத்திருக்கலாம்.

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 சமர்ப்பிக்கப்பட்டு, உங்கள் விவரங்கள் ஏற்றுக்கொள்ளப்படும். ஆனால், board திரையில் தோன்றாது. Browser developer console-ஐத் திறந்து பார்த்தால், /socket.io/-க்கான கோரிக்கைகள் தோல்வியடைவதைக் காணலாம். ஏனெனில், client தனது நேரடி இணைப்பை localhost:3000-க்குத் திறக்க வேண்டும் என்று அறிவுறுத்தப்பட்டுள்ளது, ஆனால் உங்கள் கணினியில் அந்த முகவரி எதுவுமே இல்லை.

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

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

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

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

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

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

மேலே உள்ள 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 space) மேல் அதிகரித்தால், S3_ENDPOINT, S3_BUCKET மற்றும் அதனுடன் தொடர்புடைய key variables மூலம் Planka அவற்றை S3-compatible சேமிப்பகத்தில் எழுத முடியும். இது ஒரு hosted bucket-ஐ அல்லது மற்றொரு பெட்டியில் உள்ள self-hosted MinIO object store-ஐச் சுட்டிக்காட்டலாம். குழுவினர் போர்டில் தகவல்களை நிரப்புவதற்கு முன்பே இதை முடிவு செய்யுங்கள், ஏனெனில் இந்த அமைப்பு புதிய பதிவேற்றங்களுக்கு மட்டுமே பொருந்தும்.

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

docker compose pull
docker compose up -d
docker compose ps

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

docker compose logs -f planka

சரியாகத் தொடங்கும் ஒரு system, database migrations-ஐ முடித்துவிட்டு, server 1337 port-ல் இயங்குவதாகத் தெரிவிக்கும். 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-உடன் இணைய முடியவில்லை என்று பொருள். எனவே, 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 account மூலம் login செய்யவும்.

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

உங்கள் board-ன் தரவுகள் இரண்டு தனித்தனி இடங்களில் சேமிக்கப்படுகின்றன. எனவே, backup எடுக்கும்போது Postgres database மற்றும் planka-data volume ஆகிய இரண்டையும் உள்ளடக்கியிருக்க வேண்டும். 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-ஐத் திறக்க முடிகிறதா என்பதை உறுதிப்படுத்திக் கொள்ளுங்கள்.

ஒவ்வொரு version மாற்றத்திற்கு முன்பும் உடனடியாக dump எடுக்கவும். நீங்கள் செய்யப்போகும் migration-க்கு முந்தைய backup-ம், நேற்று எடுக்கப்பட்ட 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-ஆக வெளியிடப்பட்டது; இது போன்ற தகவல்களைத் தற்செயலாகப் பெறுவதை விட, முன்கூட்டியே வாசிப்பதே சிறந்தது.

postgres:16-alpine ஒரு major version-க்கு pin செய்யப்படுவதற்கு இன்னும் முக்கியமான காரணம் உள்ளது. Postgres தனது data directory-ஐ ஒரு குறிப்பிட்ட major version-க்கு ஏற்ற வடிவத்தில் எழுதுகிறது; வேறொரு 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-ல் உள்ள விவரங்கள் Postgres environment-உடன் பொருந்தவில்லை. POSTGRES_PASSWORD என்பது தரவு அடைவு (data directory) முதன்முதலில் உருவாக்கப்படும்போது மட்டுமே பயன்படுத்தப்படும் என்பதை கவனத்தில் கொள்க. எனவே, தவறான முதல் boot-க்கு பிறகு இந்த மாறியை (variable) மாற்றினாலும் எந்தப் பயனும் இல்லை. நீங்கள் db-data volume-ஐ நீக்கிவிட்டு மீண்டும் தொடங்க வேண்டும்.

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

மற்ற அனைத்தும் சரியாக இயங்குகிறது, ஆனால் கோப்புகளை upload செய்ய முடியவில்லை. Bind mount-ன் உரிமையாளர் root ஆக உள்ளார். Host directory-ல் 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 record-உடன் பொருந்தவில்லை. docker compose config கட்டளை மாற்றீடுகளுக்குப் பிறகுள்ள labels-ஐக் காட்டும், அதில் எழுத்துப் பிழைகளை எளிதாகக் கண்டறியலாம்.

அறிவிப்புகள் (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 காரணமாக, reboot செய்த பிறகு stack தானாகவே மீண்டும் இயங்கும்; Docker service boot-ன் போது enabled நிலையில் இருப்பதை உறுதி செய்யவும். reboot-க்கு பிறகு இயங்காத Compose stacks என்ற பகுதியில், அவ்வாறு இயங்காத சூழல்கள் குறித்து விளக்கப்பட்டுள்ளது.

FAQ

Planka-வில் உள்நுழைந்த பிறகு ஏன் தொடர்ந்து லோடிங் ஆகிறது?

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

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

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

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

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

சுய-வழங்கி (self-hosted) Planka-விற்கு எவ்வளவு RAM தேவை?

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

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

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