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

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

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

இந்த வழிகாட்டி முழுவதும் சில பெயர்கள் மீண்டும் மீண்டும் வரும். ERPNext என்பது வணிகப் பயன்பாட்டு மென்பொருள் (business application). 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 மற்றும் report-ஐ உருவாக்கும் Python worker ஆகிய அனைத்தும் அந்த மெமரிக்குள் அடங்காது. இந்தச் செயலிழப்பு சீராக இருக்காது. Kernel-ன் out of memory killer ஒரு container-ஐ நிறுத்திவிடும்; அப்போது docker inspect-ஐப் பார்த்தால், அது exit code 137 உடன் "OOMKilled": true-ஐக் காட்டும். ஒரு பணி பாதியில் இருக்கும்போது worker நிறுத்தப்பட்டால், அந்த ஆவணம் முழுமையடையாமல் நின்றுவிடும்.

தினமும் ERPNext-ஐப் பயன்படுத்தும் ஒரு நிறுவனத்திற்கு, 8 GB RAM, 4 vCPU மற்றும் 100 GB SSD என்பதே உண்மையான குறைந்தபட்சத் தேவையாகும். RAM தான் முதலில் தீர்ந்துவிடும். ஒவ்வொரு கோப்பு இணைப்பும் (attachment) மற்றும் உள்ளூர் backup-களும் database இருக்கும் அதே 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 என்பது browser-ல் நேரடி அறிவிப்புகளை (live updates) வழங்கும் socket.io process ஆகும்.
• 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-ஐ நிலைநிறுத்துகிறது (pin). 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 கோப்பை render செய்து, பின் அதைத் தொடங்கவும்.

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-உடன் இணைத்து, அனைத்து variable-களும் மாற்றப்பட்ட பிறகு முடிவை அச்சிடும். அந்த render செய்யப்பட்ட கோப்பை நீங்கள் இயக்க வேண்டும். இந்த கூடுதல் படி பயனுள்ளது: இயங்கும் 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 ஆகியவற்றின் version-களை அச்சிட வேண்டும். ஆரோக்கியமான ps, ஒன்பது services-களை running நிலையிலும், எதையும் restarting நிலையிலும் காட்டாது.

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

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

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

இரண்டு விஷயங்கள் சரியாக இருந்தால் மட்டுமே 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-ஐ எவ்வாறு பகிர்ந்துகொள்வது என்பதைக் காட்டுகிறது. இது போன்ற ஒரு server-ல் இரண்டாவது app பெரும்பாலும் வாடிக்கையாளர் சேவைக்காகப் பயன்படுத்தப்படுகிறது, மேலும் self-hosted Chatwoot support desk அதே proxy-க்கு பின்னால் இயங்குகிறது. இதனால் invoice கையாளும் பணியாளர்கள், வாடிக்கையாளர் மின்னஞ்சல் மற்றும் chat-களுக்கும் ஒரே இடத்தில் பதிலளிக்க முடியும்.

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

பெரும்பாலான ERPNext வழிகாட்டிகள் தவிர்க்கும் இந்த படிநிலைதான், இந்த system பயனுள்ளதா என்பதைத் தீர்மானிக்கிறது. வெளியேறும் மின்னஞ்சல் சரியாகச் செயல்படவில்லை என்றால், எந்த invoice-ம் வாடிக்கையாளரைச் சென்றடையாது, password reset மின்னஞ்சல்கள் வராது, மற்றும் திட்டமிடப்பட்ட அறிக்கைகள் (scheduled reports) அனுப்பப்படாது. இந்த stack-ல் mail server எதுவும் இல்லை.

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

ERPNext interface-ல் உள்ள Email Account திரைதான் இதற்கான அங்கீகரிக்கப்பட்ட வழி; இது password-ஐ 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-ஆக இல்லாமல் எண்ணாக (number) சேமிக்கிறது, அதாவது "587". கோப்பை மீண்டும் படித்து, அந்த இரண்டு மதிப்புகளையும் சுற்றி quotes இல்லை என்பதை உறுதிப்படுத்தவும்:

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

mail_password-ஐ command line-ல் அமைப்பதற்குப் பதிலாக Email Account திரை வழியாக அமைக்கவும். அப்போதுதான் அது encrypted முறையில் சேமிக்கப்படும் மற்றும் உங்கள் 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 உங்களுக்குக் கட்டுப்பாட்டில் உள்ள relay-ஐ வழங்குகிறது, இது ERP இருக்கும் server-லிருந்து தனித்திருக்கும்.

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

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

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
• பொதுக் கோப்புகளின் -files.tar காப்பகம்
• தனிப்பட்ட கோப்புகளின் -private-files.tar காப்பகம்
• site config-ன் -site_config_backup.json நகல்

நான்காவது கோப்பைத்தான் பலரும் கவனிக்காமல் விட்டுவிடுவார்கள், அதுவே மிக முக்கியமானது. அதில் encryption_key உள்ளது; இது சேமிக்கப்பட்ட கடவுச்சொற்களை (மின்னஞ்சல் கணக்கு விவரங்கள், payment gateway keys, அனைத்து integration secrets) குறியாக்க (encrypt) Frappe பயன்படுத்தும் திறவுகோல் (key) ஆகும். பொருத்தமான திறவுகோல் இல்லாமல் 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 காப்புப்பிரதி என்பது உங்கள் முழு கணக்கு விவரங்களின் நகல் என்பதால், அது இந்த வன்பொருளில் (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 site-ல், pinned செய்யப்படாத image tag என்பது எதிர்பாராத restart-ஐ மட்டுமே ஏற்படுத்தும். ஆனால் ERPNext-ல், அது ஒரு schema migration-ஐக் குறிக்கும். bench migrate database tables-ஐ மாற்றியமைக்கும், மேலும் document data-வையும் மாற்றக்கூடும்; இதற்கு undo வசதி கிடையாது. எனவே, rollback செய்வது என்பது backup-லிருந்து restore செய்வதே தவிர, docker compose down செய்வது அல்ல.

ஆகவே, tag-ஐ pin செய்யவும். ஆகஸ்ட் 2026-ல், repository-ன் சொந்த pwd.yml-ல் ERPNEXT_VERSION=v16.32.1 என்பது pinned செய்யப்பட்ட 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-ஐ edit செய்யவும், பிறகு 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-லிருந்து upgrade செய்யவே எழுதப்பட்டுள்ளது; எனவே, 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 என்பது கடவுச்சொல்லாக வழங்கப்படுகிறது, இந்த வழக்கத்தை பயனர்கள் 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 applications-ஐ இயக்கினால், ஒவ்வொரு செயலிக்கும் தனித்தனி கடவுச்சொல் பயன்படுத்துவதை விட self-hosted single sign-on provider-ஆக Authentik-ஐப் பயன்படுத்துதல் சிறந்தது.

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

ERPNext ஒரு VPS-ல் போதாமல் போகும்போது

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

• Background jobs தேங்குவதால், மின்னஞ்சல்களும் இறக்குமதிகளும் பல நிமிடங்கள் அல்லது மணிநேரம் தாமதமாகச் சென்றடையும்.
• docker inspect containers-ல் "OOMKilled": true அல்லது exit code 137 பிழையைக் காட்டும்.
• இரண்டு வினாடிகளில் முடிந்த அறிக்கைகள் முப்பது வினாடிகள் எடுக்கும், மேலும் CPU பயன்பாட்டில் MariaDB முதன்மையாக இருக்கும்.
• 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

VPS-ல் ERPNext இயங்க எவ்வளவு 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 பயன்பாட்டைக் கண்காணித்து வாருங்கள்.

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

கூடாது. இந்த project-ன் 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 செய்யுங்கள். முதலில் release notes-ஐப் படியுங்கள், ஏனெனில் migrate, schema மற்றும் document தரவுகளை மாற்றியமைக்கும்; இதைத் திரும்பப் பெற முடியாது. பழைய நிலைக்குத் திரும்புவது என்றால், நீங்கள் முதலில் எடுத்த backup-ஐ மீண்டும் restore செய்ய வேண்டும்.