VPS-ல் Docker மூலம் ERPNext-ஐ நிறுவுவது எப்படி?

நீங்கள் இயக்கப்போகும் மென்பொருள் குறித்த விளக்கம்

VPS-ல் ERPNext-ஐ self-host செய்வது என்பது ஒரு செயல்பாட்டுப் பணி (operations job); இது ஒரே கட்டளையில் முடிந்துவிடும் நிறுவல் அல்ல. அதிகாரப்பூர்வ Docker Compose stack-ல் பதினொரு containers உள்ளன; இது உங்கள் பொதுப் பேரேடு (general ledger) மற்றும் வாடிக்கையாளர் தரவுகளைக் கையாள்கிறது. இது கீழே உள்ள அனைத்திற்கும் தரநிலையை உயர்த்துகிறது: நீங்கள் மீட்டெடுத்துப் பார்த்தால் ஒழிய ஒரு backup என்பது முழுமையானது அல்ல; மேலும், image tag-ஐ pin செய்யாமல் விடுவது என்பது எப்போது வேண்டுமானாலும் schema migration சிக்கலை உருவாக்கலாம்.

இந்த வழிகாட்டி முழுவதும் சில பெயர்கள் மீண்டும் மீண்டும் வரும். ERPNext என்பது வணிகப் பயன்பாட்டு மென்பொருள். Frappe என்பது அதன் அடிப்படையிலான Python framework. Bench என்பது sites-ஐ நிர்வகிக்கும் command line கருவி; இது ஏற்கனவே containers-க்குள் நிறுவப்பட்டிருக்கும். ஒரு site என்பது ஒரு tenant-ஐக் குறிக்கும்: ஒரு MariaDB database மற்றும் பதிவேற்றப்பட்ட கோப்புகளைக் கொண்ட ஒரு directory. இங்கே உள்ள பெரும்பாலான கட்டளைகள் bench-ஐப் பயன்படுத்தி backend container-க்குள் ஒரு குறிப்பிட்ட site-க்காக இயக்கப்படுகின்றன.

இந்த வழிகாட்டி frappe_docker repository-ஐப் பயன்படுத்துகிறது; இதுவே இந்தத் திட்டத்தால் பராமரிக்கப்படும் deployment ஆகும். கீழே உள்ள ஒவ்வொரு கட்டளையும் ஆகஸ்ட் 2026-ல் அந்த repository-ஐக் கொண்டு சரிபார்க்கப்பட்டது. Docker Compose உங்களுக்குப் புதியது என்றால், VPS-ல் Docker Compose-ஐ இயக்குவது குறித்த பகுதி இந்த வழிகாட்டிக்குத் தேவையான அடிப்படைத் தகவல்களை வழங்குகிறது.

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

[
  {
    "label": "Evaluation",
    "vcpu": 2,
    "ram_gb": 4,
    "disk_gb": 40
  },
  {
    "label": "Small production",
    "vcpu": 4,
    "ram_gb": 8,
    "disk_gb": 100
  },
  {
    "label": "Room to grow",
    "vcpu": 4,
    "ram_gb": 16,
    "disk_gb": 160
  }
]

வெளியிடப்பட்ட வழிகாட்டுதல்களின்படி, ஒரு பயனர் உள்நுழைவதற்கு முன்பே 2 vCPU மற்றும் 4 GB RAM தேவைப்படுகிறது. இது மதிப்பீட்டு நிலை (evaluation tier) ஆகும். இவை தொடக்கப்புள்ளிகள் மட்டுமே, இந்த வழிகாட்டியில் இருந்து பெறப்பட்ட அளவீடுகள் அல்ல. உங்கள் ஆவணங்களின் அளவே உண்மையான தேவையைத் தீர்மானிக்கும். கடைசி வரிசையில் குறிப்பிடப்பட்டுள்ள அளவு, குறைந்தபட்சத் தேவை அல்ல. அந்த அளவில் மெமரி பற்றாக்குறை குறித்த கவலைகள் பொதுவாகத் தவிர்க்கப்படும்.

குறைந்த திறன் கொண்ட திட்டங்களைப் (small plans) பயன்படுத்தும்போது கவனமாக இருக்கவும். 1 GB அல்லது 2 GB VPS-ல் stack தொடங்கும், ஆனால் முதல் தரவு இறக்குமதி (import) அல்லது நீண்ட அறிக்கை (report) உருவாக்கும்போது செயலிழந்துவிடும். ஏனெனில், ஒன்பது நீண்ட நேரம் இயங்கும் containers, MariaDB-ன் buffer pool மற்றும் அறிக்கை உருவாக்கும் Python worker ஆகிய அனைத்தும் அந்த மெமரிக்குள் அடங்காது. இந்தச் செயலிழப்பு சீராக இருக்காது. Kernel-ன் out of memory killer ஒரு container-ஐ நிறுத்திவிடும், அப்போது docker inspect-ல் பார்த்தால் "OOMKilled": true மற்றும் exit code 137 ஆகியவற்றைக் காட்டும். ஒரு பணி பாதியில் நிறுத்தப்படும்போது, சமர்ப்பிக்கப்பட்ட ஆவணத்தின் பின்னணி வேலைகள் பாதியிலேயே நின்றுவிடும்.

தினமும் ERPNext-ஐப் பயன்படுத்தும் ஒரு நிறுவனத்திற்கு, 8 GB RAM, 4 vCPU மற்றும் 100 GB SSD ஆகியவையே உண்மையான குறைந்தபட்சத் தேவையாகும். RAM முதலில் தீர்ந்துவிடும். ஒவ்வொரு இணைப்பும் (attachment) மற்றும் உள்ளூர் காப்புப்பிரதியும் (local backup) தரவுத்தளம் இருக்கும் அதே volume-ல் சேமிக்கப்படுவதால், வட்டு இடம் (disk space) எதிர்பார்ப்பதை விட வேகமாக நிரம்பும்.

பதினொரு containers மற்றும் ஒவ்வொன்றின் செயல்பாடுகள்

Stack இயங்கத் தொடங்கிய பிறகு ஒன்பது containers இயங்கிக்கொண்டிருக்கும்போது docker compose ps-ஐ இயக்கவும். மேலும் இரண்டு containers ஆன configurator மற்றும் create-site, தங்கள் பணியை ஒருமுறை முடித்துவிட்டு வெளியேறிவிடும்; இதனால்தான் மொத்தம் பதினொரு containers என கணக்கிடப்படுகிறது.

• backend, gunicorn-ன் கீழ் Frappe application-ஐ இயக்குகிறது. bench இதில் தான் இயங்குகிறது.
• frontend என்பது nginx ஆகும். இது static assets-ஐ வழங்கி, மற்ற கோரிக்கைகளை backend-க்கு அனுப்புகிறது.
• queue-short மற்றும் queue-long ஆகியவை RQ (Redis Queue) workers ஆகும். இவை மின்னஞ்சல் அனுப்புதல், தரவு இறக்குமதி மற்றும் அறிக்கை தயாரித்தல் போன்ற பின்னணிப் பணிகளைச் செய்கின்றன.
• scheduler, திட்டமிடப்பட்ட அறிக்கைகள் மற்றும் தானியங்கி ஆவணங்கள் போன்ற நேர அடிப்படையிலான பணிகளைச் செய்கிறது.
• websocket என்பது உலாவியில் நேரடி அறிவிப்புகளை (live updates) வழங்கும் socket.io செயல்முறை ஆகும்.
• db என்பது MariaDB ஆகும்.
• redis-cache மற்றும் redis-queue ஆகியவை இரண்டு தனித்தனி Redis instances ஆகும்; ஒன்று cache-க்கும் மற்றொன்று job queue-க்கும் பயன்படுத்தப்படுகிறது.

இந்தக் கட்டமைப்பைப் புரிந்துகொள்வது அவசியம், ஏனெனில் எந்த log-ஐப் பார்க்க வேண்டும் என்பதை இதுவே தீர்மானிக்கிறது. ஒரு மின்னஞ்சல் அனுப்பப்படாமல் தேங்கியிருந்தால், அது queue worker தொடர்பான சிக்கல், எனவே docker compose logs -f queue-short என்பதே சரியான கட்டளை. ஒரு பக்கம் சரியாகத் திறந்தும், அதில் அறிவிப்புகள் (notification badge) புதுப்பிக்கப்படவில்லை என்றால், அது websocket தொடர்பான சிக்கல். இத்தகைய சூழலில் backend logs-ஐப் படிப்பது நேரத்தை வீணடிக்கும் செயலாகும்.

Production compose கோப்புகளைப் பயன்படுத்தி நிறுவுதல், demo கோப்புகளைத் தவிர்க்கவும்

இந்த repository pwd.yml-ஐ வழங்குகிறது, மேலும் README கோப்பில் இதைப் பற்றி தெளிவாகக் குறிப்பிடப்பட்டுள்ளது: "இந்த அமைப்பு குறுகிய கால மதிப்பீட்டிற்காக மட்டுமே. இதில் நீங்கள் custom apps-களை நிறுவ முடியாது." ERPNext-ஐ ஒரு மதியம் மட்டும் சோதித்துப் பார்க்க இதைப் பயன்படுத்தவும். ஒரு நிறுவனத்தின் செயல்பாட்டிற்கு இதைப் பயன்படுத்த வேண்டாம்.

sudo apt update && sudo apt install -y git
curl -fsSL https://get.docker.com | bash
git clone https://github.com/frappe/frappe_docker
cd frappe_docker
mkdir -p ~/gitops
cp example.env ~/gitops/erpnext.env

~/gitops/erpnext.env கோப்பைத் திறந்து நான்கு மதிப்புகளை மாற்றவும். ERPNEXT_VERSION என்பது image tag-ஐ நிலைநிறுத்துகிறது. DB_PASSWORD என்பது உதாரணக் கோப்பில் 123 என வழங்கப்படுகிறது. SITES_RULE என்பது Traefik routing விதி, மற்றும் LETSENCRYPT_EMAIL என்பது certificate எச்சரிக்கைகளைப் பெறும் இடமாகும்.

ERPNEXT_VERSION=v16.32.1
DB_PASSWORD=<a long random password>
SITES_RULE=Host(`erp.example.com`)
LETSENCRYPT_EMAIL=ops@example.com

இப்போது ஒரு compose கோப்பை உருவாக்கி, அதைத் தொடங்கவும்.

docker compose --project-name erpnext \
  --env-file ~/gitops/erpnext.env \
  -f compose.yaml \
  -f overrides/compose.mariadb.yaml \
  -f overrides/compose.redis.yaml \
  -f overrides/compose.https.yaml \
  config > ~/gitops/erpnext.yaml

docker compose --project-name erpnext -f ~/gitops/erpnext.yaml up -d

config எதையும் தொடங்காது. இது base கோப்பையும் overrides கோப்புகளையும் இணைத்து, அனைத்து மாறிகளும் (variables) மாற்றப்பட்ட பிறகு முடிவை அச்சிடும். அதன் பிறகு நீங்கள் அந்த உருவாக்கப்பட்ட கோப்பை இயக்க வேண்டும். இந்த கூடுதல் படி பயனுள்ளது: இயங்கும் stack என்பது நீங்கள் படிக்கக்கூடிய மற்றும் commit செய்யக்கூடிய ஒரே கோப்பாக இருக்கும், எனவே env கோப்பை யாராவது மாற்றினாலோ அல்லது repository-ஐ நீங்கள் pull செய்தாலோ அது தானாக மாறாது. Docker Compose கோப்புகள் எவ்வாறு இணைகின்றன என்பது override விதிகளை விரிவாக விளக்குகிறது.

db தொடங்குவதற்கும், configurator முடிவடைவதற்கும் சில நொடிகள் காத்திருக்கவும், அதன் பிறகு site-ஐ உருவாக்கவும்.

docker compose --project-name erpnext exec backend \
  bench new-site --mariadb-user-host-login-scope=% \
  --db-root-password '<your DB_PASSWORD>' \
  --install-app erpnext \
  --admin-password '<a strong admin password>' \
  erp.example.com

இதைச் சரிபார்க்கவும்:

docker compose --project-name erpnext ps
docker compose --project-name erpnext exec backend bench --site erp.example.com list-apps

list-apps கட்டளை frappe மற்றும் erpnext ஆகியவற்றின் பதிப்புகளை அச்சிட வேண்டும். ஆரோக்கியமான ps நிலையில் ஒன்பது services running நிலையிலும், எதுவும் restarting நிலையிலும் இருக்கக்கூடாது.

இங்கு பெரும்பாலும் இரண்டு விஷயங்கள் தவறாக நடக்கலாம். Docker-ல் --mariadb-user-host-login-scope=% என்பது விருப்பத்தேர்வு அல்ல. App container ஆனது Docker network வழியாக MariaDB-ஐ அணுகுகிறது, எனவே அது ஒரு remote host-ஆகவே வரும், மேலும் localhost-க்கு மட்டும் வரையறுக்கப்பட்ட database user-ஆல் அங்கிருந்து login செய்ய முடியாது. அப்போது root user-க்கான MariaDB access denied பிழையுடன் site உருவாக்கம் தோல்வியடையும். % scope ஆனது, அந்த private network-ல் உள்ள எந்த host-லிருந்தும் புதிய site user-ஐ அணுக அனுமதிக்கிறது.

இரண்டாவது விஷயம் site-ன் பெயர். Frontend ஆனது HTTP Host header-ஐப் பொறுத்தே எந்த site-ஐ வழங்க வேண்டும் என்பதைத் தீர்மானிக்கிறது, எனவே erpnext என உருவாக்கப்பட்ட ஒரு site-ஐ erp.example.com முகவரியில் அணுக முடியாது. மேலே குறிப்பிட்டது போல site-க்கு domain பெயரை வைக்கவும், அல்லது env கோப்பில் FRAPPE_SITE_NAME_HEADER-ஐ site-ன் பெயருக்கு அமைத்து, compose கோப்பை மீண்டும் உருவாக்கவும்.

HTTPS மற்றும் அது செயல்படுவதற்கு முன்னால் இருக்க வேண்டிய நிபந்தனைகள்

compose.https.yaml override, Traefik-ஐ port 443-ல் இயக்குகிறது, port 80-ஐ அதற்குத் திருப்பி விடுகிறது (redirect), மேலும் Let's Encrypt-லிருந்து certificates-ஐக் கோருகிறது. ஒரு invoice மற்றும் session cookie-ஐ plain text வடிவில் network-ல் செல்லாமல் தடுப்பதே TLS (transport layer security) ஆகும்.

இரண்டு நிபந்தனைகள் பூர்த்தியாகவில்லை என்றால், எந்தச் சான்றிதழும் (certificate) வழங்கப்படாது. erp.example.com-க்கான DNS A record ஏற்கனவே அந்த VPS-ஐச் சுட்டிக்காட்ட வேண்டும். Port 80 மற்றும் 443 இணையத்திலிருந்து அணுகக்கூடியதாக இருக்க வேண்டும், ஏனெனில் Let's Encrypt, port 80-ல் HTTP-01 challenge மூலம் நீங்கள் அந்த domain-ஐக் கட்டுப்படுத்துகிறீர்கள் என்பதை உறுதிப்படுத்துகிறது. உங்கள் service provider-ன் network firewall மற்றும் server-ல் உள்ள firewall ஆகிய இரண்டையும் சரிபார்க்கவும். இவை தனித்தனி கட்டுப்பாடுகள்; பெரும்பாலும் மக்கள் panel firewall-ஐ மறந்துவிடுகிறார்கள்.

Certificates, cert-data volume-ல் /letsencrypt/acme.json என்ற இடத்தில் சேமிக்கப்படும். உங்கள் browser-ல் உங்களுடைய certificate-க்கு பதிலாக default certificate காட்டப்பட்டால், docker compose --project-name erpnext ps-ல் உள்ள proxy service-ன் பெயரைத் தேடி, அதன் logs-ல் உள்ள ACME (automatic certificate management environment) பிழையை வாசிக்கவும். அதே server-ல் பிற web apps-ஐ இயக்குகிறீர்களா? ஒரே Traefik instance-ஐ பல Docker Compose apps-க்கு முன்னால் பயன்படுத்துதல் என்ற பகுதி, port 443-க்காகப் போட்டியிடாமல் proxy-ஐ எவ்வாறு பகிர்ந்துகொள்வது என்பதை விளக்குகிறது.

வெளியேறும் மின்னஞ்சல், அல்லது invoices பெட்டியை விட்டு வெளியேறாத நிலை

ERPNext வழிகாட்டிகளில் தவிர்க்கப்படும் மிக முக்கியமான படி இதுவே; ஒரு system பயனுள்ளதா இல்லையா என்பதை இதுவே தீர்மானிக்கிறது. வெளியேறும் மின்னஞ்சல் சரியாகச் செயல்படவில்லை என்றால், எந்தவொரு invoice-ம் வாடிக்கையாளரைச் சென்றடையாது, கடவுச்சொல் மாற்றும் மின்னஞ்சல் வராது, மற்றும் திட்டமிடப்பட்ட அறிக்கைகளும் கிடைக்காது. இந்த stack-ல் மின்னஞ்சல் server எதுவும் இல்லை.

VPS-லிருந்து நேரடியாக port 25 மூலம் மின்னஞ்சல் அனுப்ப முயற்சிக்காதீர்கள். பெரும்பாலான சேவை வழங்குநர்கள் புதிய கணக்குகளில் port 25-ஐத் தடுத்துவிடுவார்கள். ஒருவேளை மின்னஞ்சல் வெளியேறினாலும், புதிய VPS முகவரிக்கு அனுப்பும் திறன் (sending reputation) இல்லாததால், அவை நிராகரிக்கப்படும் அல்லது spam என வகைப்படுத்தப்படும். எனவே, port 587-ல் authenticated relay-ஐப் பயன்படுத்துங்கள்.

ERPNext interface-ல் உள்ள Email Account திரைதான் இதற்கான அங்கீகரிக்கப்பட்ட வழி; இது கடவுச்சொல்லை குறியாக்கப்பட்டு (encrypted) சேமிக்கும். நீங்கள் keys-ஐ site config-லும் எழுதலாம்:

docker compose --project-name erpnext exec backend \
  bench --site erp.example.com set-config mail_server smtp.example.com

docker compose --project-name erpnext exec backend \
  bench --site erp.example.com set-config mail_port 587 --parse

docker compose --project-name erpnext exec backend \
  bench --site erp.example.com set-config use_tls 1 --parse

docker compose --project-name erpnext exec backend \
  bench --site erp.example.com set-config mail_login 'erp@example.com'

docker compose --project-name erpnext exec backend \
  bench --site erp.example.com set-config auto_email_id 'erp@example.com'

--parse என்பது "587" என்ற string-க்கு பதிலாக 587 என்ற எண்ணைச் சேமிக்கிறது. கோப்பை மீண்டும் படித்து, அந்த இரண்டு மதிப்புகளையும் சுற்றி மேற்கோள் குறிகள் (quotes) இல்லை என்பதை உறுதிப்படுத்தவும்:

docker compose --project-name erpnext exec backend \
  cat sites/erp.example.com/site_config.json

mail_password-ஐ command line-ல் அமைப்பதற்குப் பதிலாக Email Account திரை மூலம் அமைக்கவும். அப்போதுதான் அது குறியாக்கப்பட்டு சேமிக்கப்படும், மேலும் உங்கள் shell history-ல் இடம்பெறாது.

பிறகு, ஒரு உண்மையான செய்தியை அனுப்பிச் சோதிக்கவும். ஒரு Sales Invoice-ஐ உருவாக்கி, உங்கள் கட்டுப்பாட்டில் உள்ள மின்னஞ்சல் முகவரிக்கு அனுப்பி, அந்தச் செயல்பாட்டின் போது queue-ஐக் கவனிக்கவும்:

docker compose --project-name erpnext logs -f queue-short

வெளியேறும் மின்னஞ்சல் ஒரு background job என்பதால், வந்து சேராத செய்திகள் browser-ல் பிழையாகக் காட்டப்படாமல், அந்த log-ல் failed job-ஆகவே பெரும்பாலும் காட்டும். அனுப்பும் domain-க்கு SPF (sender policy framework) மற்றும் DKIM (domainkeys identified mail) பதிவுகளைப் பதிவேற்றவும், அதன்பின் DMARC policy-ஐச் சேர்க்கவும். இவை இல்லையென்றால், தொழில்நுட்ப ரீதியாகச் சரியாக இருந்தாலும், invoice வாடிக்கையாளரின் spam folder-க்குச் சென்றுவிடும். முழுப் பாதையையும் நீங்களே நிர்வகிக்க விரும்பினால், self-hosted Mailcow mail server மூலம் ERP-யிலிருந்து தனித்த ஒரு server-ல் உங்கள் கட்டுப்பாட்டில் உள்ள relay-ஐப் பெறலாம்.

மீட்டெடுக்கக்கூடிய காப்புப்பிரதிகள் (Backups)

ERPNext-ஐப் பொறுத்தவரை, database dump மட்டும் ஒரு முழுமையான காப்புப்பிரதி ஆகாது. இணைப்புகள் (attachments) மற்றும் தனிப்பட்ட கோப்புகள் (private files) MariaDB-ல் இல்லை, அவை sites கோப்பகத்தில் (directory) உள்ளன. database-ஐ மட்டும் மீட்டெடுத்தால், பதிவேற்றப்பட்ட அனைத்து கொள்முதல் ஆணைகளும் (purchase orders) உடைந்த இணைப்புகளாகவே (broken links) காட்டும்.

docker compose --project-name erpnext exec backend \
  bench --site erp.example.com backup --with-files

இது sites volume-க்குள் உள்ள sites/erp.example.com/private/backups கோப்பகத்தில் நான்கு கோப்புகளை உருவாக்குகிறது:

• ஒரு -database.sql.gz dump
• பொதுக் கோப்புகளின் (public files) ஒரு -files.tar காப்பகம்
• தனிப்பட்ட கோப்புகளின் (private files) ஒரு -private-files.tar காப்பகம்
• site config-ன் ஒரு -site_config_backup.json நகல்

நான்காவது கோப்பைத்தான் பலரும் கவனிக்காமல் விட்டுவிடுவார்கள், ஆனால் அதுவே மிக முக்கியமானது. அதில் encryption_key உள்ளது; இது சேமிக்கப்பட்ட கடவுச்சொற்களை (stored passwords) குறியாக்க (encrypt) Frappe பயன்படுத்தும் திறவுகோல் (key) ஆகும். மின்னஞ்சல் கணக்கு விவரங்கள், பேமெண்ட் கேட்வே திறவுகோல்கள் மற்றும் அனைத்து ஒருங்கிணைப்பு ரகசியங்களும் (integration secrets) இதில் அடங்கும். சரியான திறவுகோல் இல்லாமல் database-ஐ மீட்டெடுத்தால், தளம் சாதாரணமாக இயங்கும், ஆனால் மின்னஞ்சல் அனுப்பும்போது பின்வரும் பிழை ஏற்படும்:

frappe.exceptions.ValidationError: Encryption key is invalid! Please check site_config.json

இந்த நான்கு கோப்புகளையும் எப்போதும் ஒன்றாகவே வைத்திருக்கவும்.

பிறகு, அவற்றை server-லிருந்து வெளியேற்றவும். volume-க்குள் இருக்கும் காப்புப்பிரதி, server செயலிழந்தால் கிடைக்காது. மேலும், bench தானாகவே அவற்றை நீக்கிவிடும்: இயல்பாகவே, 24 மணிநேரத்திற்கு மேலான காப்புப்பிரதிகளை அந்த கோப்பகத்திலிருந்து அது நீக்கிவிடும்.

docker compose --project-name erpnext cp \
  backend:/home/frappe/frappe-bench/sites/erp.example.com/private/backups \
  ~/erpnext-backups

இதை cron மூலம் இயக்கவும், பிறகு அந்த கோப்பகத்தை நீங்கள் நிர்வகிக்காத வேறொரு இடத்திற்கு அனுப்பவும். encrypted restic backups to off-site storage இதற்கான சரியான கருவியாகும். ஏனெனில், இது பதிவேற்றுவதற்கு முன்பே கோப்புகளைக் குறியாக்கம் செய்கிறது, மேலும் restic check மூலம் அந்த repository இன்னும் படிக்கக்கூடிய நிலையில் உள்ளதா என்பதை உறுதிப்படுத்தலாம். ERP காப்புப்பிரதி என்பது உங்கள் முழு கணக்கு புத்தகத்தின் (ledger) நகல் என்பதால், அது இந்த server-ல் இல்லாத வேறொரு வன்பொருளில் (hardware) குறியாக்கம் செய்யப்பட்டு சேமிக்கப்பட வேண்டும்.

தேவைப்படுவதற்கு முன்பே restore-ஐச் சோதிக்கவும்

சோதிக்கப்படாத backup என்பது வெறும் ஊகம் மட்டுமே. அதை அதே server-ல் உள்ள மற்றொரு தளத்தில் சோதிக்கவும்; ஒருபோதும் நேரடி (live) தளத்தில் செய்ய வேண்டாம்.

docker compose --project-name erpnext exec backend \
  bench new-site --mariadb-user-host-login-scope=% \
  --db-root-password '<your DB_PASSWORD>' \
  --admin-password '<a strong admin password>' \
  restore-test.example.com

docker compose --project-name erpnext exec backend \
  bench --site restore-test.example.com --force restore \
  sites/erp.example.com/private/backups/<stamp>-erp.example.com-database.sql.gz \
  --with-public-files sites/erp.example.com/private/backups/<stamp>-erp.example.com-files.tar \
  --with-private-files sites/erp.example.com/private/backups/<stamp>-erp.example.com-private-files.tar \
  --db-root-password '<your DB_PASSWORD>'

Backup செய்யப்பட்ட configuration-லிருந்து encryption key-ஐ நகலெடுத்து, restore செய்யப்பட்ட தளத்தில் சேர்க்கவும். இல்லையெனில், அதன் integrations வேலை செய்யாது:

docker compose --project-name erpnext exec backend \
  bench --site restore-test.example.com set-config encryption_key '<value from site_config_backup.json>'

இப்போது ஒரு கணக்காளர் செய்வது போல restore-ஐச் சரிபார்க்கவும். Accounts Receivable அறிக்கையைத் திறந்து, அதன் closing balance-ஐ நேரடித் தளத்துடன் ஒப்பிடவும். சமீபத்திய purchase invoice ஒன்றைத் திறந்து, அதன் இணைப்பைப் (attachment) பதிவிறக்கம் செய்யவும். ஒரு தளத்தின் login பக்கம் மட்டும் தெரிவது எதையும் நிரூபிக்காது.

சோதனை முடிந்ததும் அந்தத் தளத்தை நீக்கவும்:

docker compose --project-name erpnext exec backend \
  bench drop-site restore-test.example.com

ERPNext-க்கு version pinning ஏன் முக்கியமானது

ஒரு static தளத்தில், pin செய்யப்படாத image tag என்பது எதிர்பாராத restart-ஐ மட்டுமே குறிக்கும். ஆனால் ERPNext-ல் இது ஒரு schema migration-ஐக் குறிக்கும். bench migrate database tables-ஐ மாற்றியமைக்கும், மேலும் இது document தரவுகளையும் மாற்றக்கூடும்; இதற்கு undo வசதி கிடையாது. எனவே, பழைய நிலைக்குத் திரும்புவது என்பது docker compose down மூலம் அல்ல, backup-லிருந்து restore செய்வதன் மூலமே சாத்தியம்.

எனவே, tag-ஐ pin செய்யவும். ERPNEXT_VERSION=v16.32.1 என்பது ஆகஸ்ட் 2026-ல் அந்த repository-ன் சொந்த pwd.yml-ல் pin செய்யப்பட்ட release ஆகும். அந்த எண்ணை சரிபார்க்காமல் அப்படியே பயன்படுத்த வேண்டாம். தற்போதைய releases frappe/erpnext releases page-ல் பட்டியலிடப்பட்டுள்ளன, மேலும் தற்போதுள்ள image tags Docker Hub-ல் உள்ளன. நீங்கள் மாறப்போகும் version-க்கான குறிப்புகளைப் படித்துவிட்டு, பின் தொடரவும்.

மேம்படுத்தல் (upgrade) செயல்முறை, backup மற்றும் maintenance mode-உடன் தொடங்குகிறது.

docker compose --project-name erpnext exec backend \
  bench --site erp.example.com backup --with-files

docker compose --project-name erpnext exec backend \
  bench --site erp.example.com set-maintenance-mode on

~/gitops/erpnext.env-ல் உள்ள ERPNEXT_VERSION-ஐத் திருத்தவும், பின் render, pull மற்றும் migrate செய்யவும்.

docker compose --project-name erpnext \
  --env-file ~/gitops/erpnext.env \
  -f compose.yaml \
  -f overrides/compose.mariadb.yaml \
  -f overrides/compose.redis.yaml \
  -f overrides/compose.https.yaml \
  config > ~/gitops/erpnext.yaml

docker compose --project-name erpnext -f ~/gitops/erpnext.yaml pull
docker compose --project-name erpnext -f ~/gitops/erpnext.yaml up -d

docker compose --project-name erpnext exec backend \
  bench --site erp.example.com migrate

docker compose --project-name erpnext exec backend \
  bench --site erp.example.com set-maintenance-mode off

Maintenance mode முக்கியமானது, ஏனெனில் migrate இயங்கும்போது schema-வை மாற்றியமைக்கும். முழுமையாக migrate ஆகாத ஒரு table-ல் பயனர் ஒரு document-ஐச் சமர்ப்பித்தால், நீங்கள் பதிவுகளைக் கையால் சரிசெய்ய வேண்டிய சூழல் ஏற்படும்.

ஒவ்வொரு major version-ஆக மேம்படுத்தவும், ஒவ்வொரு படிக்கும் இடையில் backup எடுக்கவும். ஒரு release-ல் உள்ள migration code, அதற்கு முந்தைய release-லிருந்து மேம்படுத்தும் வகையில் எழுதப்பட்டுள்ளது. எனவே, major versions-ஐத் தவிர்த்துவிட்டு நேரடியாக மேம்படுத்தினால், யாரும் சோதிக்காத ஒரு migration சூழல் உருவாகும்.

இந்த repository overrides/compose.migrator.yaml-ஐயும் வழங்குகிறது, இது ஒவ்வொரு தொடக்கத்திலும் bench --site all migrate-ஐ இயக்கும் ஒரு container-ஐச் சேர்க்கிறது. இது வசதியானதுதான். ஆனால், tag மாற்றப்பட்ட ஒரு docker compose up, உங்கள் கண்காணிப்பு இல்லாமலேயே production database-ஐ migrate செய்துவிடும். ஒரு வணிக அமைப்பில், அந்த நாளில் நீங்கள் எடுத்த முடிவின்படியே migrate கட்டளையை இயக்க வேண்டும்.

வாடிக்கையாளர் தரவுகளைக் கொண்ட server-ஐப் பாதுகாத்தல்

முதல்முறை login செய்யும்போது Administrator கடவுச்சொல்லை மாற்றவும். மதிப்பீட்டிற்கான compose file-ல் admin என்பது கடவுச்சொல்லாக வழங்கப்படுகிறது (ships), இந்த வழக்கம் பலரால் production சூழலிலும் தொடரப்படுகிறது.

example.env-ல் உள்ள 123-லிருந்து DB_PASSWORD-ஐ மாற்றவும். அந்த மதிப்பு, உருவாக்கப்படும் ~/gitops/erpnext.yaml-ல் plain text-ஆக அமையும், எனவே அந்த கோப்பை chmod 600 செய்து, எந்தவொரு git repository-யிலும் சேர்க்காமல் பாதுகாக்கவும். கூடுதல் பாதுகாப்பிற்கு, overrides/compose.mariadb-secrets.yaml என்பது environment variable-க்கு பதிலாக Docker secret கோப்பிலிருந்து கடவுச்சொல்லைப் படிக்கும். Docker Compose-ல் env கோப்புகள் மற்றும் secrets-ஐக் கையாளுதல் பகுதியில் இதற்கான சாதக பாதகங்கள் விளக்கப்பட்டுள்ளன.

தேவையானவற்றை மட்டும் public-ஆக வெளியிடவும். HTTPS override மூலம், 80 மற்றும் 443 ஆகிய ports மட்டுமே திறக்கப்படுகின்றன. database client இணைப்பை எளிதாக்க db service-க்கு ports mapping-ஐச் சேர்க்க வேண்டாம்: இது MariaDB-ஐ பொது இணையத்தில் (public internet) வெளிப்படுத்திவிடும். அதற்குப் பதிலாக docker compose --project-name erpnext exec backend bench mariadb-ஐப் பயன்படுத்தவும். Host-ல் 22, 80 மற்றும் 443 ஆகியவற்றை மட்டும் அனுமதித்து, மற்றவற்றைத் தடுக்கவும்; மேலும், உங்கள் service provider வழங்கும் தனிப்பட்ட network firewall-ஐயும் சரிபார்க்கவும்.

System Manager பொறுப்பைக் கொண்ட ஒவ்வொரு கணக்கிற்கும் System Settings-ல் two factor authentication-ஐச் செயல்படுத்தவும். அந்தப் பொறுப்பைக் கொண்டவர் ஒவ்வொரு ஆவணத்தையும் படிக்கவும், ஒவ்வொரு அட்டவணையையும் export செய்யவும் முடியும் என்பதால், அதை ஒரு வசதிக்கான கணக்காகக் கருதாமல், administrator கணக்காகவே கருதவும். நீங்கள் பல self-hosted application-களை இயக்கினால், ஒவ்வொரு app-க்கும் தனித்தனி கடவுச்சொல் வைப்பதை விட self-hosted single sign-on provider-ஆக Authentik சிறந்தது.

Host-ஐ patch செய்து, kernel updates-க்காக reboot செய்யவும். Stack மீண்டும் தானாகத் தொடங்கும் என்று நம்புவதற்கு முன், ஒவ்வொரு service-லும் restart policy உள்ளதா எனச் சரிபார்க்கவும், ஏனெனில் அது இல்லாத stack reboot-க்குப் பிறகு இயங்காது. reboot-க்குப் பிறகு Docker Compose stack-ஐ மீண்டும் தொடங்குதல் பகுதியில் systemd சார்ந்த விவரங்கள் உள்ளன.

ERPNext ஒரு VPS-ல் போதாத சூழல்

ஒரு சிறிய நிறுவனத்தின் தேவைகளை நீண்ட காலம் ஒரு VPS பூர்த்தி செய்யும். அது போதாது என்பதற்கான அறிகுறிகள்:

• Background jobs தேங்குவதால், மின்னஞ்சல்களும் இறக்குமதிகளும் பல நிமிடங்கள் அல்லது மணிநேரம் தாமதமாகின்றன.
• docker inspect containers "OOMKilled": true அல்லது exit code 137-ஐக் காட்டுகின்றன.
• இரண்டு வினாடிகளில் முடிந்த அறிக்கைகள் முப்பது வினாடிகள் ஆகின்றன; MariaDB செயல்முறை CPU-வை முழுமையாகப் பயன்படுத்துகிறது.
• Backups முடிவதற்குள் அடுத்த backup நேரம் வந்துவிடுகிறது.

முதலில் MariaDB-க்குத் தனிப்பட்ட வளங்களை (resources) ஒதுக்குங்கள். ஏனெனில் database-ம் Python workers-ம் ஒரே நினைவகத்தைப் பகிர்ந்து கொள்வதால், buffer pool-க்கு அதிக நினைவகம் தேவைப்படுகிறது. மக்கள் எதிர்பார்ப்பதை விட, application server-ஐப் பெரிதாக்குவது குறைவான பலனையே தரும். database-ஐ Docker-ல் அல்லது host-ல் இயக்குவது குறித்த முடிவை இது விளக்குகிறது. மேலும், Docker Compose-ல் memory limits அமைப்பது ஒரு container மற்றவற்றை முடக்காமல் தடுக்க உதவும்.

அதன்பிறகு, web capacity-ஐ அதிகரிப்பதை விட, queue workers-ஐச் சேர்க்கவும். ERPNext-ன் மெதுவான செயல்பாடுகள் பெரும்பாலும் background வேலைகளே: அறிக்கை தயாரித்தல் மற்றும் மொத்தமாகத் தரவுகளை இறக்குமதி செய்தல் போன்றவை. ஒரு பெரிய server-ஐ வாங்குவதை விட, கூடுதல் worker containers-ஐ இயக்குவது செலவு குறைவு; பயனர்கள் புகார் செய்யும் சிக்கல்களை இது சரிசெய்யும்.

FAQ

ERPNext-க்கு VPS-ல் எவ்வளவு RAM தேவை?

வெளியிடப்பட்ட வழிகாட்டுதல்களின்படி 4 GB RAM மற்றும் 2 vCPU குறைந்தபட்சத் தேவையாகும், ஆனால் இது மதிப்பீட்டிற்கு மட்டுமே. தினசரி பயன்பாட்டிற்கு, 8 GB RAM, 4 vCPU மற்றும் 100 GB SSD ஆகியவற்றைத் திட்டமிடுங்கள். இதற்கு குறைவாக இருந்தால், அதிக சுமையின் போது kernel-ன் out of memory killer containers-ஐ நிறுத்திவிடும். இது docker inspect-ல் "OOMKilled": true மற்றும் exit code 137 எனப் பதிவாகும். இவை ஆரம்ப அளவீடுகள் மட்டுமே என்பதால், முதல் மாதம் முழுவதும் உங்கள் memory பயன்பாட்டைக் கண்காணித்து வாருங்கள்.

pwd.yml-ஐ production-ல் பயன்படுத்தலாமா?

கூடாது. இந்தத் திட்டத்தின் README கோப்பு, இது குறுகிய கால மதிப்பீட்டிற்கு மட்டுமே என்று குறிப்பிடுகிறது. மேலும், இதில் custom apps-ஐ நிறுவ முடியாது. MariaDB, Redis மற்றும் HTTPS overrides-உடன் compose.yaml-ஐப் பயன்படுத்தவும். அவற்றை docker compose config மூலம் ஒரே கோப்பாக மாற்றி, அந்த கோப்பை இயக்கவும்.

ERPNext site-ஐ உருவாக்கியவுடன் ஏன் அதை அணுக முடியவில்லை?

Frontend, HTTP Host header-ஐ அடிப்படையாகக் கொண்டே எந்த site-ஐ வழங்க வேண்டும் என்பதைத் தீர்மானிக்கிறது. எனவே, browser-ல் உள்ள domain பெயரும் site பெயரும் ஒன்றாக இருக்க வேண்டும். erpnext என உருவாக்கப்பட்ட ஒரு site, erp.example.com முகவரியில் இயங்காது. site-ஐ domain பெயரிலேயே உருவாக்கவும் அல்லது env கோப்பில் FRAPPE_SITE_NAME_HEADER-ஐ site பெயருக்கு ஏற்ப மாற்றவும். அதன் பிறகு compose கோப்பை மீண்டும் render செய்து, stack-ஐ restart செய்யவும்.

ERPNext backup-ல் என்னென்ன இருக்க வேண்டும்?

நான்கு கோப்புகள் ஒன்றாக இருக்க வேண்டும்: -database.sql.gz dump, -files.tar மற்றும் -private-files.tar archives, மற்றும் -site_config_backup.json config நகல். bench --site erp.example.com backup --with-files-ஐ இயக்கினால் இந்த நான்கு கோப்புகளும் கிடைக்கும். config நகலில் encryption_key இருப்பதால், அதைத் தவிர்த்து restore செய்தால், சேமிக்கப்பட்ட integration கடவுச்சொற்களை decrypt செய்ய முடியாது. இது Encryption key is invalid! Please check site_config.json பிழையாக வெளிப்படும்.

தரவு சிதையாமல் ERPNext-ஐ எப்படி upgrade செய்வது?

--with-files மூலம் backup எடுக்கவும். maintenance mode-ஐ இயக்கவும். உங்கள் env கோப்பில் ERPNEXT_VERSION-ஐ மாற்றவும். compose கோப்பை மீண்டும் render செய்து, pull செய்யவும். stack-ஐ இயக்கி, bench --site erp.example.com migrate-ஐ ரன் செய்து, maintenance mode-ஐ அணைக்கவும். ஒரு நேரத்தில் ஒரு major version-ஆக மட்டும் upgrade செய்யவும். upgrade செய்வதற்கு முன் release notes-ஐப் படிக்கவும், ஏனெனில் migrate schema மற்றும் document தரவுகளை மாற்றியமைக்கும்; இதைத் திரும்பப் பெற முடியாது. பழைய நிலைக்குத் திரும்ப வேண்டுமெனில், தொடக்கத்தில் எடுத்த backup-ஐ மட்டுமே பயன்படுத்த முடியும்.