Linux server-களை நிர்வகிக்க சிறந்த கருவிகள் எவை?

நீங்கள் உருவாக்குவது என்ன

இது ஒரே ஒரு கருவி அல்ல, ஒரு சிறிய stack. உங்களிடம் எத்தனை servers உள்ளன என்பதைப் பொறுத்தே இது தேர்ந்தெடுக்கப்படுகிறது. அந்த எண்ணிக்கை மட்டுமே முக்கியமான உள்ளீடு. ஆனால், "Linux server management tools" குறித்த பெரும்பாலான கட்டுரைகள் இதைப் புறக்கணிக்கின்றன. நான்கு VPS-களுக்கு 200 servers-க்கான தீர்வை ஏற்றுக்கொண்டு, servers-க்கு வேலை செய்வதற்குப் பதிலாக அந்த கருவிக்கே ஒரு மாதம் செலவிடுவது ஒரு பொதுவான தவறு. பதினெட்டு servers வைத்திருப்பவர் இன்னும் ஒவ்வொரு server-க்கும் தனித்தனியாக SSH செய்து, "ஒரே மாதிரியான" மாற்றத்தை பதினெட்டு வெவ்வேறு வழிகளில் செய்வது இரண்டாவது பொதுவான தவறு.

எனவே, இந்த வழிகாட்டி fleet அளவின் அடிப்படையில் பிரிக்கப்பட்டுள்ளது: 2 முதல் 5 servers, 5 முதல் 20, மற்றும் 20-க்கு மேல். இதனுடன், எந்த அளவிலும் பொருந்தக்கூடிய, ஆனால் யாரும் எழுதாத ஒரு பொதுவான அடுக்கு உள்ளது: ஒரு inventory, key hygiene, உள்ளே நுழைய ஒரே வழி, மற்றும் நீங்கள் உண்மையில் restore செய்து பார்த்த backups. ஒவ்வொரு கருவிக்கும் மூன்று விஷயங்கள் கொடுக்கப்பட்டுள்ளன: அது எதை மாற்றுகிறது, அதை அமைப்பதற்கான நேரம் (நிமிடங்களில்), மற்றும் உங்களை பாதிக்கும் ஒரு முக்கிய சிக்கல். நான் பதினைந்து ஆண்டுகளாக VPS host-ஐ இயக்கி வருகிறேன்; கீழே உள்ள பட்டியல், அதிகாலை 2 மணிக்கு ஏற்படும் outage-ன் போது கைகொடுக்கும் கருவிகளே தவிர, demo-வில் மட்டும் நன்றாகத் தெரியும் கருவிகள் அல்ல.

முன்நிபந்தனைகள் மற்றும் கவனிக்க வேண்டிய உண்மைகள்

ஒவ்வொரு server-க்கும் key-based SSH ஏற்கனவே செயல்படும் நிலையில் இருக்க வேண்டும் (நீங்கள் இன்னும் password-களைத் தட்டச்சு செய்கிறீர்கள் என்றால், முதலில் அதைச் சரிசெய்யவும்; இது பத்து நிமிட வேலை, கீழே உள்ள அனைத்தும் key-களை அடிப்படையாகக் கொண்டவை). root அல்லாத sudo user ஒருவரும், தற்போதைய நிலையில் இயங்கும் server-களும் அவசியம். இங்குள்ள கட்டளைகள் Ubuntu 24.04-ஐ அடிப்படையாகக் கொண்டவை, ஆனால் apt-ஐத் தவிர மற்றவை எந்தவொரு குறிப்பிட்ட OS-க்கும் உரியவை அல்ல.

கருவிகளைப் பயன்படுத்துவதற்கு முன்பு இரண்டு உண்மையான எச்சரிக்கைகள். முதலாவதாக, அதிகப்படியான கருவிகளைப் பயன்படுத்துவது நிர்வாகச் சிக்கலை உருவாக்கும்: நீங்கள் நிறுவும் ஒவ்வொரு agent-ம் ஒவ்வொரு server-லும் patch செய்யப்பட வேண்டிய ஒரு daemon ஆகும். எனவே, ஒரு கருவியைச் சேர்ப்பதற்கான அளவுகோல் "இது பயனுள்ளதாகத் தெரிகிறது" என்பதாக இருக்கக்கூடாது, "இது இந்த வாரம் நான் செய்த கைமுறை வேலையை மாற்றுகிறது" என்பதாக இருக்க வேண்டும். இரண்டாவதாக, இங்குள்ள அனைத்தும் free software ஆகும். இதன் உண்மையான செலவு அதை அமைப்பதற்கான நேரம் மட்டுமே. இதனால்தான் ஒவ்வொரு கருவிக்கும் நிமிடங்களில் ஒரு மதிப்பீடு வழங்கப்பட்டுள்ளது; ஒரு கருவிக்கு ஒரு மதியம் தேவைப்படும் என்று குறிப்பிடப்பட்டிருந்தால், அதை நம்புங்கள்.

2 முதல் 5 servers வரை: ~/.ssh/config என்பது உங்களிடம் ஏற்கனவே உள்ள மிகவும் குறைத்து மதிப்பிடப்பட்ட கருவி

இது எதை மாற்றுகிறது: IP முகவரிகள் அடங்கிய உரை கோப்பு, shell-history-ல் தேடுவது (ssh 203.0 பிறகு Ctrl-R அழுத்தி காத்திருப்பது), மற்றும் எப்போதும் -p 2222 -i ~/.ssh/other_key என தட்டச்சு செய்வது. அமைப்பு செலவு: ஒருமுறை, 15 நிமிடங்கள். சிக்கல்: காலாவதியான multiplexing sockets, இது கீழே விளக்கப்பட்டுள்ளது.

இந்த அளவில் உங்களுக்கு மென்பொருள் தேவையில்லை; உங்களிடம் ஏற்கனவே உள்ள client-ஐ சரியாக கட்டமைக்க வேண்டும். ~/.ssh/config ஒவ்வொரு server-க்கும் ஒரு சொல் கொண்ட பெயரை வழங்குகிறது மற்றும் routing-ஐ குறியீடாக்குகிறது, எனவே நீங்கள் அதை மீண்டும் நினைக்க வேண்டியதில்லை:

Host *
    ServerAliveInterval 30
    ControlMaster auto
    ControlPath ~/.ssh/cm-%r@%h-%p
    ControlPersist 10m

Host bastion
    HostName 10.0.0.10
    User matt

Host web1
    HostName 10.8.0.11
    User matt
    ProxyJump bastion

Host db1
    HostName 10.8.0.12
    User matt
    Port 2222
    ProxyJump bastion

மூன்று அமைப்புகள் இந்த வேலையைச் செய்கின்றன. ProxyJump இணைப்புகளை ஒரு bastion வழியாக ஒரே தாவலில் routing செய்கிறது, எனவே ஒரு café-விலிருந்து ssh db1 செய்யும் போது அது வெளிப்படையாக bastion வழியாக tunnel செய்கிறது. இதில் agent forwarding தேவையில்லை, ProxyCommand போன்ற சிக்கலான கட்டளைகள் தேவையில்லை, மேலும் private servers-க்கு public SSH ports தேவையில்லை (இது குறித்த கூடுதல் தகவல்கள் cross-cutting பகுதியில் உள்ளன). ControlMaster auto மற்றும் ControlPersist ஆகியவை இணைப்புகளை ஒரே TCP session-ல் multiplex செய்கின்றன, எனவே அதே host-க்கு செய்யப்படும் இரண்டாவது மற்றும் அதற்குப் பிந்தைய ssh, scp, அல்லது rsync இணைப்புகள் மீண்டும் பேச்சுவார்த்தை (renegotiate) நடத்தாமல் உடனடியாக இணைகின்றன. Ansible பயன்படுத்தும் போது இந்த வித்தியாசம் மிக முக்கியமானது. scp, rsync, மற்றும் Ansible ஆகிய அனைத்தும் இந்த கோப்பையே வாசிப்பதால், நீங்கள் இங்கே வரையறுக்கும் ஒவ்வொரு பெயரும் எல்லா இடங்களிலும் வேலை செய்யும்.

சிக்கல்: master connection அதன் பயனை இழக்கலாம், மேலும் இரண்டு தோல்வி நிலைகள் வெவ்வேறு விதமாகத் தோன்றும். Server reboot ஆகும்போதோ அல்லது Wi-Fi துண்டிக்கப்படும்போதோ, master process ஒரு செயலிழந்த TCP session-ஐ வைத்திருக்கும், அதை அது இன்னும் கவனிக்கவில்லை. அடுத்த ssh web1 எங்கும் செல்லாத ஒரு socket-ல் அமைதியாகத் தொங்கும். தனித்தனியாக, sshd ஒரு இணைப்பிற்கு 10 sessions வரை மட்டுமே அனுமதிக்கும் (sshd_config-ல் MaxSessions), எனவே ஒரு host-க்கு பதினொன்றாவது multiplexed session-ஐ உருவாக்கும்போது இது அச்சிடப்படும்:

mux_client_request_session: session request failed: Session open refused

இரண்டிற்கும் ஒரே தீர்வு: ssh -O exit web1 master-ஐ நிறுத்துகிறது, அடுத்த இணைப்பு புதியதாகத் தொடங்குகிறது. நீங்கள் எப்போதாவது ControlSocket ~/.ssh/cm-matt@web1-22 already exists, disabling multiplexing-ஐக் காணலாம், அது பாதிப்பில்லாதது: இரண்டு sessions ஒரே நேரத்தில் முயன்றன, இணைப்பு இன்னும் வேலை செய்கிறது, ஆனால் multiplexed செய்யப்படவில்லை.

இந்த அளவில் இரண்டு துணைக் கருவிகள் உள்ளன. ஒவ்வொரு server-லும் உள்ள tmux, nohup-க்கு மாற்றாக அமைகிறது. Wi-Fi துண்டிக்கப்படும்போது வேலை இழப்பு ஏற்படுவதையும், "migration நடப்பதால் என்னால் laptop-ஐ மூட முடியாது" என்ற நிலையையும் இது தவிர்க்கிறது. அமைப்பு செலவு: sudo apt install -y tmux, இரண்டு நிமிடங்கள், மற்றும் tmux new -s work, tmux attach -t work ஆகியவற்றின் தசை நினைவாற்றல் (muscle memory). சிக்கல்: nesting; tmux-க்குள் tmux உங்கள் prefix key-ஐ எடுத்துக்கொள்ளும், எனவே server-ல் அல்லது laptop-ல் ஏதேனும் ஒன்றில் மட்டும் இயக்கவும். நீங்கள் நீண்ட காலம் இயங்கும் agent sessions-ஐப் பயன்படுத்தினால் இது இரண்டு மடங்கு முக்கியமானது. இது running Claude Code in tmux on a VPS போன்றது, அங்கு session என்பது SSH இணைப்பை விட நீண்ட காலம் நீடிக்க வேண்டும்.

பகிரப்பட்ட alias கோப்பு ஒவ்வொரு பெட்டியிலும் உங்களுக்குப் பிடித்த பன்னிரண்டு ஒரு வரி கட்டளைகளை மீண்டும் தட்டச்சு செய்வதைத் தவிர்க்கிறது. ஒரு .bash_aliases-ஐ git repo-வில் வைத்து ஒவ்வொரு server-லும் pull செய்யவும். சிக்கல்: நீங்கள் அதை repo-வில் திருத்துவதற்குப் பதிலாக நேரடியாக ஒரு server-ல் திருத்தினால் அது மாறுபடும், இது அடுத்த கட்டம் ஏன் தேவைப்படுகிறது என்பதற்கான முதல் அனுபவமாகும்.

5 முதல் 20 servers வரை: config as code, அல்லது drift வெற்றி பெறும்

ஐந்து servers-க்கு மேல் சென்றவுடன், "ஒவ்வொரு பெட்டியிலும் நானே செய்து கொள்கிறேன்" என்பது ஒரு முறையாக இருக்காது, அது உங்களுக்கு நீங்களே சொல்லிக்கொள்ளும் பொய்யாக மாறிவிடும். இந்த நிலையில் உள்ள அனைத்து கருவிகளும் ஒரே எதிரியைத் தாக்குகின்றன: அதுதான் drift.

Ansible என்பது hostnames-ஐ வைத்து இயக்கும் shell loop-க்கும், மூன்று படிகள் பின்தங்கியுள்ள "புதிய server அமைப்பு" என்ற wiki பக்கத்திற்கும், web3-ல் fix சரியாகப் பதிவாகியுள்ளதா என்ற கவலைக்கும் மாற்றாக அமைகிறது. அமைப்பதற்கான செலவு: முதல் working playbook-ஐ உருவாக்க 30 நிமிடங்கள், உங்கள் laptop அல்லது management box-ல் sudo apt install -y ansible (apt மூலம் கிடைக்கும் பழைய Ansible release இதற்கெல்லாம் போதுமானது; இந்த tutorial-ன் pipx வழிமுறை தற்போதைய பதிப்புகளைத் தரும்), servers-ல் agents தேவையில்லை, நீங்கள் ஏற்கனவே உருவாக்கிய SSH config மூலமே அனைத்தும் இயங்கும். இது இந்தப் பக்கத்தில் உள்ள மிகப்பெரிய upgrade ஆகும், முழுமையான விளக்கம் Ansible first-playbook tutorial-ல் உள்ளது; இது செயல்படுவதற்கான inventory-ன் வடிவம் இதோ:

[web]
web1 ansible_host=10.8.0.11
web2 ansible_host=10.8.0.12

[db]
db1 ansible_host=10.8.0.21 ansible_port=2222

[all:vars]
ansible_user=matt
ansible_ssh_common_args='-o ProxyJump=bastion'

Ansible, OpenSSH binary-ஐப் பயன்படுத்துவதால், முந்தைய பகுதியில் நீங்கள் எழுதிய ~/.ssh/config ஏற்கனவே பொருந்தும், web1 போன்ற பெயர்களைக் கொண்ட inventory எந்த vars-ம் இல்லாமலேயே வேலை செய்யும். மேலே உள்ள vars, inventory-ஐத் தன்னிறைவு பெறச் செய்கிறது, இது உங்கள் laptop அல்லாத வேறொரு machine-லிருந்து இயக்கும்போது பயனுள்ளதாக இருக்கும்.

இதை ansible all -i inventory.ini -m ping மூலம் சோதிக்கவும்; சரியாக இருந்தால், ஒவ்வொரு host-க்கும் "ping": "pong" பச்சை நிறத்தில் அச்சிடப்படும். நீங்கள் முதலில் சந்திக்கும் தோல்வி இப்படி இருக்கும்:

web1 | UNREACHABLE! => {
    "changed": false,
    "msg": "Failed to connect to the host via ssh: matt@10.8.0.11: Permission denied (publickey).",
    "unreachable": true
}

இது Ansible பிரச்சினை அல்ல, சாதாரண ssh matt@10.8.0.11-ம் அதே வழியில் தோல்வியடையும். முதலில் SSH-ஐச் சரிசெய்யவும்; அதன் கீழ் உள்ள அடுக்கு சரியாக இருந்தால் மட்டுமே Ansible சரியாகச் செயல்படும். இதைத் தாண்டிய ஒரு சிக்கல்: Ansible-க்கு இரு முனைகளிலும் Python தேவை, எனவே மிகக் குறைந்த வசதி கொண்ட image-ல் /usr/bin/python3: not found என்று பதில் வரலாம், ஒரு apt install python3 கொடுத்தால் போதும், அது மீண்டும் உங்களைத் தொந்தரவு செய்யாது.

unattended-upgrades என்பது N servers-க்கு security patches-ஐ நீங்களே பதிவேற்றும் முறைக்கு மாற்றாக அமைகிறது. Stock Ubuntu Server 24.04-ல் இது முன்பே நிறுவப்பட்டு, பொதுவாக security updates-க்காக enabled நிலையிலேயே இருக்கும், எனவே இங்கே செய்ய வேண்டியது நிறுவுவது அல்ல, சரிபார்ப்பது மட்டுமே:

cat /etc/apt/apt.conf.d/20auto-upgrades

இரண்டு வரிகளும் "1" என்று முடிய வேண்டும். சில minimal மற்றும் cloud images-ல் இது அணைக்கப்பட்டிருக்கலாம், உங்கள் கணினியில் அப்படி இருந்தால் sudo dpkg-reconfigure -plow unattended-upgrades அந்த file-ஐ மீண்டும் எழுதும். அமைப்பதற்கான செலவு: ஒவ்வொரு server-க்கும் சரிபார்க்க இரண்டு நிமிடங்கள், அல்லது அனைத்திற்கும் சேர்த்து ஒரே ஒரு Ansible task. சிக்கல்: இது இயல்பாகவே reboot செய்யாது, எனவே kernel security updates நீங்கள் செய்யும் வரை பாதியிலேயே இருக்கும், unattended-upgrades guide தானியங்கி reboot, எதைப் patch செய்வது மற்றும் logs-ஐப் படிப்பது பற்றி விளக்குகிறது.

Centralized monitoring என்பது வாடிக்கையாளர் மூலம் ஒரு பிரச்சினை தெரிவதற்கு மாற்றாக அமைகிறது, அதுவே மிக விலையுயர்ந்த monitoring முறையாகும். இரண்டு கருவிகள், எப்போது பயன்படுத்த வேண்டும் என்பதற்கான விளக்கம்: Uptime Kuma "இது இயங்குகிறதா?" என்ற கேள்விக்கு பதில் அளிக்கும், HTTP, TCP, மற்றும் ping சோதனைகள் மூலம் எதற்கும் alerts அனுப்பும், Docker-ல் பத்து நிமிடங்களில் அமைக்கலாம்; Zabbix "இது செயலிழக்கப் போகிறதா?" என்ற கேள்விக்கு பதில் அளிக்கும், ஒவ்வொரு host-லும் உள்ள agent மூலம் disk, memory, மற்றும் CPU போக்குகளைக் கண்காணிக்கும், இதை அமைக்க ஒரு மதியம் தேவைப்படும். Kuma-வுடன் தொடங்கவும்; "இயங்குகிறது ஆனால் வேகம் குறைவு" என்பது உங்களுக்கு நஷ்டத்தை ஏற்படுத்தத் தொடங்கும்போது Zabbix-ஐச் சேர்க்கவும். இரண்டிற்கும் பொதுவான சிக்கல் அதன் இருப்பிடம் (placement), இது கீழே உள்ள தவறுகள் பகுதியில் முக்கியமாக விவாதிக்கப்பட்டுள்ளது.

Web panel, கட்டாயம் என்றால் மட்டும். Webmin என்பது Ubuntu எங்கே எதை வைத்திருக்கிறது என்பதை நினைவில் கொள்வதற்கு மாற்றாக அமைகிறது, பல்வேறு திறன் கொண்ட குழுவிற்கும் அல்லது வருடத்திற்கு இருமுறை மட்டும் தொடும் server-க்கும் இது பயனுள்ளது; அமைப்பதற்கு பத்து நிமிடங்கள் ஆகும். இதன் சிக்கல் என்னவென்றால், இது port 10000-ல் இயங்கும் root-க்கு இணையான web application, இணையம் இதைத் தொடர்ந்து தேடிக்கொண்டே இருக்கும். நீங்கள் இதைப் பயன்படுத்தினால், localhost அல்லது VPN address-ல் bind செய்யவும், பொதுவான interface-ல் 0.0.0.0-ல் ஒருபோதும் வைக்க வேண்டாம். SSH மெதுவாக இருப்பதாக உணர்ந்து panel-ஐத் தேடினால், முந்தைய பகுதியை மீண்டும் படிக்கவும்; ~/.ssh/config மற்றும் Ansible இணைந்தால் எந்த panel-ஐ விடவும் வேகமாகச் செயல்படும்.

20+ servers: இந்த வழிகாட்டி உண்மையாக முடிவடையும் இடம்

இருபதுக்கும் மேற்பட்ட servers-ஐ நீங்கள் நிர்வகிக்கும்போது, அது ஒரு fleet-ஆக மாறுகிறது. அப்போது toolchain-ன் வடிவம் மாறுகிறது: servers-ஐ மீண்டும் உருவாக்கக்கூடிய வகையில் மாற்ற Terraform அல்லது OpenTofu தேவைப்படும்; ஒரு server-ஐ பழுதுபார்ப்பதை விட அதை நீக்கிவிட்டு புதியதை உருவாக்க cloud-init அல்லது golden images பயன்படும்; உங்கள் laptop-லிருந்து Ansible-ஐ இயக்குவது scaling-க்கு ஒத்து வராது என்பதால், pull-based configuration அல்லது CI pipelines மூலம் அதை இயக்க வேண்டும்; மேலும் முறையான secrets management அவசியம். இருபது servers-க்கு மேல் Ansible-ஆல் இயங்க முடியாது என்று அர்த்தமல்ல, பல நிறுவனங்கள் நூற்றுக்கணக்கான nodes-க்கு அதைத்தான் பயன்படுத்துகின்றன. ஆனால், அதைச் சுற்றியுள்ள நடைமுறைகள் மிகவும் வலுவாக இருக்க வேண்டும். அது இந்தத் தளத்தின் நோக்கத்திற்கு அப்பாற்பட்டது. நீங்கள் அந்த அளவில் இருந்தால், கீழே உள்ள பகுதி உங்களுக்குப் பொருந்தும். ஏனெனில், inventory, keys மற்றும் access discipline ஆகியவையே fleet tooling-க்குத் தேவையான அடிப்படைத் தேவைகளாகும்.

எவரும் எழுதி வைக்காத அடுக்கு

எந்தவொரு fleet அளவிலும் நான்கு நடைமுறைகள் பொருந்தும். இவற்றைத் தவிர்ப்பதே server-களின் எண்ணிக்கையைத் தேவைக்கு அதிகமாகச் சுமையாக உணர வைக்கிறது.

ஒரு inventory file, அது ஒரு text file-ஆக இருந்தாலும் சரி. உங்களிடம் மூன்று server-கள் இருக்கும்போதே, அவற்றின் பெயர், IP, provider, அதில் இயங்கும் சேவைகள் மற்றும் அதன் நோக்கம் ஆகியவற்றை எழுதி வையுங்கள். git repo-வில் உள்ள ஒரு servers.md போதுமானது; மேலே உள்ள Ansible inventory இன்னும் சிறந்தது, ஏனெனில் அது இயங்கக்கூடிய ஆவணம் (executable documentation). இது எதை மாற்றுகிறது: "10.0.0.40 என்பது என்ன?" என்ற அதிகாலை 2 மணி நேரக் குழப்பத்தைத் தவிர்க்கிறது. அமைப்பதற்கான நேரம்: பத்து நிமிடங்கள். கவனிக்க வேண்டியது: ஒரு server-ஐ உருவாக்குவதும், அந்த வரியை inventory-ல் சேர்ப்பதும் ஒரே நேரத்தில் நடக்க வேண்டும்; தனித்தனியாகச் செய்யக்கூடாது.

Key hygiene: இப்போதே rotation செய்யுங்கள், சிக்கல் வரும்போது SSH CA-க்கு மாறுங்கள். உங்கள் keys எங்கே உள்ளன (உங்கள் பக்கத்தில் cat ~/.ssh/*.pub, ஒவ்வொரு server-ன் பக்கத்திலும் ~/.ssh/authorized_keys) என்பதைப் பட்டியலிடுங்கள். பழைய laptops மற்றும் முன்னாள் பணியாளர்களின் access-ஐ நீக்குங்கள். எங்கே பயன்படுத்தப்பட்டது என்று உறுதியாகத் தெரியாத அளவுக்குப் பழைய keys-ஐ மாற்றிவிடுங்கள் (rotate). SSH certificate authority, அதாவது நிலையான keys-க்கு பதிலாகக் குறுகிய கால signed certs-ஐப் பயன்படுத்துவது முதிர்ச்சியான அணுகுமுறை. ஆனால், பத்து server-களுக்குக் குறைவாக இருக்கும்போது, Ansible மூலம் ஒழுக்கமான authorized_keys மேலாண்மை செய்வது, 10% முயற்சியில் 90% பலனைத் தரும்.

உள்ளே வர ஒரு வழி, இருபது அல்ல. ஒவ்வொரு public SSH port-ம் attack surface-ஐ N மடங்கு அதிகரிக்கிறது. இதுவே சரியான முறை: ஒரு bastion host, அல்லது அதைவிடச் சிறந்தது, நீங்கள் கட்டுப்படுத்தும் ஒரு VPS-ல் WireGuard VPN, மற்றும் மற்ற அனைத்து server-களின் SSH-ஐயும் அவற்றின் private address-ல் மட்டும் பிணைப்பது (bind). மேலே உள்ள config-ல் உள்ள ProxyJump வரிகள் ஏற்கனவே இந்த அமைப்பைக் கொண்டுள்ளன. பொதுவெளியில் இருக்க வேண்டிய எதற்கும் fail2ban-ஐக் கட்டாயம் பயன்படுத்துங்கள். அமைப்பதற்கான நேரம்: ஒரு மணி நேரம், ஒருமுறை மட்டும். கவனிக்க வேண்டியது: port 22-ஐ மூடுவதற்கு முன்பே, உங்கள் fallback (provider-ன் console access) வேலை செய்கிறதா என்பதைச் சரிபார்க்கவும்.

மீட்டெடுப்பதன் (restoring) மூலம் சோதிக்கப்பட்ட backups. சோதிக்கப்படாத backup என்பது வெறும் ஊகம் மட்டுமே. நீங்கள் பயன்படுத்தும் முறை எதுவாக இருந்தாலும் (provider snapshots, restic, அல்லது மற்றொரு box-க்கு rsync), முக்கியமான கருவி உங்கள் calendar-ல் உள்ள நினைவூட்டல் மட்டுமே. ஒரு புதிய VPS-ல் server-ஐ மீட்டெடுத்து, அது boot ஆகிறதா மற்றும் சரியாகச் செயல்படுகிறதா என்பதை உறுதிப்படுத்துங்கள். பதினைந்து வருட hosting அனுபவத்தில் நான் கேட்ட ஒவ்வொரு backup தொடர்பான துயரக் கதையிலும் "எங்களிடம் backups இருந்தன" என்ற வாசகம் இடம்பெற்றிருந்தது.

தவறுகள்

பல server-களை நிர்வகிக்கும்போது ஏற்படும் தோல்விகள் கருவிகளால் வருவதில்லை; அவை பழக்கவழக்கங்களால் ஏற்படுகின்றன. அவற்றில் நான்கு காரணங்கள் பெரும்பாலான சிக்கல்களுக்கு அடிப்படையாக உள்ளன.

Snowflake servers. ஒவ்வொரு server-ம் கையால் கட்டமைக்கப்பட்டிருக்கும், ஒவ்வொன்றும் சிறிய அளவில் மாறுபடும், யாராலும் அதை மீண்டும் உருவாக்க முடியாது. disk failure ஏற்படும்போதுதான் இது தெரியவரும். இதற்கான தீர்வு சலிப்பூட்டும் ஒன்று: ஒவ்வொரு மாற்றமும் Ansible வழியாகவே நடக்க வேண்டும், அல்லது குறைந்தபட்சம் அந்த server-ன் inventory ஆவணத்தில் சேர்க்கப்பட வேண்டும். இன்று மதியம் உங்களால் மீண்டும் உருவாக்க முடியாத எந்தவொரு server-ம், காலக்கெடுவை நீங்களே தீர்மானிக்க முடியாத ஒரு technical debt ஆகும்.

"தற்காலிக" firewall ஓட்டைகள். ஏதோ ஒன்றைப் பிழைதிருத்தம் (debug) செய்ய ufw allow 5432-ஐப் பயன்படுத்துவீர்கள், ஆனால் பதினெட்டு மாதங்களுக்குப் பிறகும் Postgres இணையத்தில் வெளிப்படையாக இருக்கும். ஒவ்வொரு box-லும் sudo ufw status numbered மூலம் தணிக்கை செய்யுங்கள், அல்லது ஒரே முயற்சியில் ansible all -i inventory.ini -a "ufw status numbered" --become-ஐப் பயன்படுத்துங்கள். தற்போதைய தேவை என்னவென்று உங்களால் விளக்க முடியாத எந்தவொரு விதியையும் நீக்கிவிடுங்கள். ஒரு விதி உண்மையிலேயே தற்காலிகமானது என்றால், அதை நீக்குவதற்கான ufw delete கட்டளையை, அந்த tmux window-வை மூடுவதற்கு முன்பே அதே window-வில் பதிவிடுங்கள்.

கண்காணிக்கப்படும் box-லேயே கண்காணிப்பு மென்பொருளை வைத்தல். Uptime Kuma தான் கண்காணிக்கும் server-லேயே இயங்கினால், "எல்லாம் செயலிழந்துவிட்டது" என்ற எச்சரிக்கையும் செயலிழந்துவிடும். நீங்கள் உலகின் மிகத் திறமையற்ற datacenter-ன் ஒரு சிறிய மற்றும் வேடிக்கையான பதிப்பை உருவாக்கியுள்ளீர்கள் என்று அர்த்தம். கண்காணிப்பு என்பது வேறு ஒரு failure domain-ல் இருக்க வேண்டும்: வேறொரு provider-ல் உள்ள மலிவான VPS-ஐப் பயன்படுத்துவது இதற்குச் சிறந்த தீர்வாகும், அல்லது குறைந்தபட்சம் கண்காணிப்பாளரைக் கண்காணிக்கும் ஒரு external free-tier சேவையையாவது பயன்படுத்த வேண்டும்.

எங்கும் Root SSH. fleet முழுவதும் ஒரே root key-ஐப் பயன்படுத்துவது என்பது, ஒரு laptop திருடுபோனாலும் அனைத்தும் திருடுபோவதற்குச் சமம். மேலும், யார் என்ன செய்தார்கள் என்பதற்கான தணிக்கை தடயமும் இருக்காது. ஒவ்வொருவருக்கும் தனித்தனி user-கள், sudo பயன்பாடு, மற்றும் ஒவ்வொரு host-லும் /etc/ssh/sshd_config-ல் PermitRootLogin no ஆகியவற்றை அமல்படுத்துங்கள். இது ஒரு மாலை நேர வேலையல்ல, வெறும் மூன்று வரிகள் கொண்ட Ansible task மட்டுமே.

fleet-ன் எண்ணிக்கை ஒரு சிலவற்றைத் தாண்டும்போது, உங்கள் முதல் Ansible playbook மீண்டும் மீண்டும் செய்யப்படும் வேலைகளைத் தானியக்கமாக்கும்.

FAQ

பல Linux servers-ஐ நிர்வகிக்க சிறந்த இலவச கருவி எது?

2 முதல் 5 servers வரை நிர்வகிக்க, நன்கு எழுதப்பட்ட ~/.ssh/config மற்றும் tmux ஆகியவையே போதுமானவை; வேறு எதையும் நிறுவ வேண்டியதில்லை. சுமார் ஐந்து servers-க்கு மேல் இருந்தால், Ansible-ஐப் பயன்படுத்துவதே தரமான முறையாகும்: இது agentless, இலவசம், ஏற்கனவே உள்ள SSH மூலமாகவே இயங்கும், மேலும் server setup-ஐ git-ல் உள்ள கோப்புகளாக மாற்றும். server-ன் இயக்கம் (up/down) குறித்த எச்சரிக்கைகளுக்கு Uptime Kuma-வைப் பயன்படுத்தவும்; இந்த வழிகாட்டியில் குறிப்பிடப்பட்டுள்ள அனைத்து கருவிகளும் இலவச மென்பொருட்களே.

Ansible இல்லாமல் பல Linux servers-ஐ என்னால் நிர்வகிக்க முடியுமா?

ஆம், ஐந்து servers-க்கும் குறைவாக இருந்தால், சரியான SSH config, பகிரப்பட்ட alias கோப்பு மற்றும் ஒழுக்கம் இருந்தாலே போதுமானது; பலரும் பல ஆண்டுகளாக இந்த முறையிலேயே செயல்படுகிறார்கள். அதற்கு மேல் செல்லும்போது, Ansible-க்கு மாற்றாக "எதுவுமில்லை" என்று இருப்பது, ஆவணப்படுத்தப்படாத மாற்றங்களுக்கு (drift) வழிவகுக்கும்: அதாவது, பதினெட்டு servers-ம் ஒவ்வொன்றும் கையால் சற்று வித்தியாசமாக கட்டமைக்கப்பட்டிருக்கும். Ansible கடினமாகத் தோன்றினால், authorized_keys மற்றும் unattended-upgrades-ஐ மட்டும் நிர்வகிக்கும் ஒரு playbook-ஐ முதலில் தொடங்குங்கள்; இதுவே நீங்கள் கற்கும் முயற்சிக்கு நல்ல பலனைத் தரும்.

ஒரே நேரத்தில் பல Linux servers-ல் ஒரே கட்டளையை (command) எப்படி இயக்குவது?

ansible all -i inventory.ini -a "uptime" இதற்குச் சரியான தீர்வாகும்; இதற்கு playbook-கள் தேவையில்லை, inventory கோப்பு மட்டுமே போதுமானது. ஊடாடும் (interactive) முறையில் பக்கவாட்டில் வேலை செய்ய, tmux மூலம் setw synchronize-panes on கட்டளையைப் பயன்படுத்தி அனைத்து pane-களுக்கும் ஒரே நேரத்தில் keystrokes-ஐ அனுப்பலாம். ஆனால், இதை ஒரு தந்திரமாக மட்டுமே கருதுங்கள்; ஏனெனில், production servers-ல் ஊடாடும் கட்டளைகளைப் பகிரும்போது ஏற்படும் ஒரு சிறிய தட்டச்சுப் பிழை, பல servers-ல் செயலிழப்பை (outage) ஏற்படுத்தக்கூடும்.

Linux servers-ஐ நிர்வகிக்க Webmin போன்ற control panel எனக்குத் தேவையா?

தேவையில்லை. ஒரு panel செய்யும் அனைத்தையும் SSH மற்றும் Ansible மூலம் இன்னும் துல்லியமாகச் செய்ய முடியும். வெவ்வேறு திறன் கொண்டவர்கள் ஒரே server-ஐ நிர்வகிக்கும்போது அல்லது, நீங்கள் அரிதாகவே server-ஐப் பயன்படுத்தும் சூழலில் config பாதைகளை மீண்டும் தேடுவது நேரத்தை வீணடிக்கும்போது மட்டுமே Webmin பயனுள்ளதாக இருக்கும். நீங்கள் அதைப் பயன்படுத்தினால், அது root-க்கு இணையான அதிகாரத்தைக் கொண்ட web app என்பதை நினைவில் கொள்ளுங்கள்: அதை localhost அல்லது VPN முகவரியுடன் மட்டும் இணைக்கவும், பொதுவான (public) interface-ல் ஒருபோதும் இணைக்க வேண்டாம்.

ஒரு நபர் நடைமுறையில் எத்தனை Linux servers-ஐ நிர்வகிக்க முடியும்?

கையால் நிர்வகிக்கும்போது, பத்திற்கும் குறைவான servers-லேயே தரம் குறையத் தொடங்கும். config as code, தானியங்கி patching மற்றும் மையப்படுத்தப்பட்ட கண்காணிப்பு (centralized monitoring) இருந்தால், ஒரு கவனமான நபர் 20 முதல் 50 servers-ஐ பகுதிநேரப் பணியாக நிர்வகிக்க முடியும். இங்கு கட்டுப்பாடு என்பது வழக்கமான பராமரிப்பு அல்ல, மாறாக புதிய சிக்கல்கள் எவ்வளவு அடிக்கடி ஏற்படுகின்றன என்பதுதான். ஒரு நிர்வாகிக்கு எத்தனை servers என்பது முக்கியமல்ல, எத்தனை 'snowflakes' (தனித்துவமான, சீரற்ற கட்டமைப்புகள்) உள்ளன என்பதே முக்கியம்: அதை பூஜ்ஜியத்திற்கு அருகில் வைத்திருந்தால், நீங்கள் நிர்வகிக்கும் servers-ன் எண்ணிக்கை அதிகமாக இருக்கும்.