பல Linux servers நிர்வாகம்: எந்த tools வேலை செய்கின்றன

நீங்கள் எதை உருவாக்கிக் கொண்டிருக்கிறீர்கள்

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

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

முன்தேவைகள் மற்றும் நேர்மையான எச்சரிக்கைகள்

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

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

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

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

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

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 ஊடாகச் செலுத்துகிறது. எனவே ஒரு கஃபேயிலிருந்து ssh db1 என்பது bastion ஊடாக வெளிப்படையாகச் சுரங்கம் அமைக்கிறது — agent forwarding இல்லை, ProxyCommand மந்திரங்கள் இல்லை, மேலும் தனியார் சர்வர்களுக்கு பொது SSH போர்ட்டுகள் தேவையே இல்லை (இது பற்றி cross-cutting பிரிவில் மேலும் காண்க). ControlMaster auto மற்றும் ControlPersist சேர்ந்து ஒரே ஒரு TCP அமர்வில் இணைப்புகளை multiplex செய்கின்றன. எனவே அதே host-க்கு இரண்டாவது மற்றும் அதற்குப் பிறகான ஒவ்வொரு ssh, scp, அல்லது rsync மறுபேச்சுவார்த்தை செய்யாமல் உடனடியாக இணைகின்றன — Ansible வரும்போது இந்த வித்தியாசம் குறிப்பிடத்தக்கதாக மாறுகிறது. மேலும் scp, rsync, மற்றும் Ansible மூன்றும் இதே கோப்பைப் படிக்கும் என்பதால், நீங்கள் இங்கே வரையறுக்கும் ஒவ்வொரு பெயரும் எல்லா இடங்களிலும் வேலை செய்யும்.

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

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 என்பதையும் காணலாம் — அது தீங்கற்றது: இரண்டு அமர்வுகள் போட்டியிட்டன, மேலும் இணைப்பு இன்னும் வேலை செய்கிறது, ஆனால் unmultiplexed ஆக.

இந்த அளவில் இரண்டு துணைக் கருவிகள். ஒவ்வொரு சர்வரிலும் tmux என்பது nohup, Wi-Fi துண்டிக்கப்படும்போது இழக்கப்பட்ட வேலை, மற்றும் "என்னால் என் மடிக்கணினியை மூட முடியவில்லை, ஒரு migration இயங்கிக் கொண்டிருக்கிறது" ஆகியவற்றை மாற்றுகிறது. அமைப்புச் செலவு: sudo apt install -y tmux, இரண்டு நிமிடங்கள், மேலும் tmux new -s work மற்றும் tmux attach -t work இன் தசை நினைவு. இங்கே சிக்கல் nesting ஆகும்: tmux-க்குள் tmux உங்கள் prefix விசையை விழுங்கும், எனவே அதை சர்வரிலோ மடிக்கணினியிலோ இயக்கவும், இரண்டிலும் அல்ல. நீண்ட கால agent அமர்வுகளை இயக்கினால் இது இரண்டு மடங்கு முக்கியம் — இது ஒரு VPS-ல் tmux-இல் Claude Code-ஐ இயக்குவது போன்றே அதே வடிவம், அங்கே அமர்வு SSH இணைப்பை விட நீண்ட காலம் நிலைத்திருக்க வேண்டும்.

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

5 முதல் 20 சேவையகங்கள் வரை: உள்ளமைவை குறியீடாக மாற்றுங்கள், இல்லையென்றால் வேறுபாடு வெல்லும்

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

Ansible பெயர்களுக்கு மேலான shell சுழற்சியை, "புதிய சேவையக அமைப்பு" என தலைப்பிடப்பட்டு மூன்று படிகள் காலாவதியான wiki பக்கத்தை, மற்றும் web3 சேவையகத்திற்கு திருத்தம் உண்மையில் பெறப்பட்டதா என்று தெரியாத கவலையை மாற்றியமைக்கிறது. அமைப்புச் செலவு: முதல் வேலை செய்யும் playbook உருவாக 30 நிமிடங்கள் — உங்கள் மடிக்கணினியில் அல்லது ஒரு நிர்வாகப் பெட்டியில் sudo apt install -y ansible (apt உங்களுக்கு பழைய Ansible வெளியீட்டைத் தருகிறது, இது இங்கே உள்ள அனைத்திற்கும் போதுமானது; பயிற்சியின் pipx வழி உங்களுக்கு தற்போதைய பதிப்புகளைத் தருகிறது), சேவையகங்களில் முகவர்கள் (agents) இல்லை, நீங்கள் ஏற்கனவே உருவாக்கிய SSH உள்ளமைவு வழியாக அனைத்தும் இயங்குகிறது. இது இந்தப் பக்கத்தில் உள்ள மிகப்பெரிய ஒற்றை மேம்பாடு, மேலும் முழு விளக்கம் Ansible முதல் playbook பயிற்சியில் உள்ளது; இதை வேலை செய்யச் செய்யும் 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 நிரலுக்கு வெளியே அனுப்புவதால், நீங்கள் கடந்த பகுதியில் எழுதிய ~/.ssh/config ஏற்கனவே பயன்படுத்தப்படுகிறது — web1 போன்ற வெறும் பெயர்களின் inventory எந்த மாறிகளும் இல்லாமலேயே வேலை செய்யும். மேலே உள்ள மாறிகள் inventory ஐ தன்னிறைவாக்குகின்றன, இது உங்கள் மடிக்கணினி அல்லாத வேறொரு கணினியில் இருந்து இயக்கும் நாளில் பலனளிக்கும்.

இதை 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 சேவையகங்களுக்கு பாதுகாப்பு திருத்தங்களைப் பயன்படுத்தும் நபராக இருந்து உங்களை மாற்றியமைக்கிறது. வழக்கமான Ubuntu Server 24.04 இதை முன்னரே நிறுவப்பட்டதாகவும் பொதுவாக பாதுகாப்பு புதுப்பிப்புகளுக்கு ஏற்கனவே இயக்கப்பட்டதாகவும் வழங்குகிறது, எனவே இங்கே உள்ள வேலை நிறுவுவது அல்ல, சரிபார்ப்பது:

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

இரண்டு வரிகளும் "1" உடன் முடிவடைய வேண்டும். சில குறைந்தபட்ச மற்றும் மேகக் கணினி படிமங்கள் இதை அணைத்த நிலையில் வழங்குகின்றன, மேலும் உங்களுடையது அப்படி இருந்தால் sudo dpkg-reconfigure -plow unattended-upgrades அந்தக் கோப்பை மீண்டும் எழுதுகிறது. அமைப்புச் செலவு: ஒரு சேவையகத்திற்கு சரிபார்க்க இரண்டு நிமிடங்கள், அல்லது அனைத்திற்கும் ஒரு Ansible பணி. சிக்கல்: இயல்பாக இது ஒருபோதும் மறுதொடக்கம் செய்யாது, எனவே kernel பாதுகாப்பு புதுப்பிப்புகள் நீங்கள் அதைச் செய்யும் வரை பாதி பயன்படுத்தப்பட்ட நிலையில் காத்திருக்கின்றன — பிரத்யேக unattended-upgrades வழிகாட்டி தானியங்கி மறுதொடக்கங்கள், எது திருத்தப்படுகிறது என்பதைத் தேர்ந்தெடுப்பது, மற்றும் அதன் பதிவுகளைப் படிப்பது ஆகியவற்றை உள்ளடக்கியது.

மையப்படுத்தப்பட்ட கண்காணிப்பு வாடிக்கையாளரிடம் இருந்து கண்டுபிடிப்பதை மாற்றியமைக்கிறது, இதுவரை கண்டுபிடிக்கப்பட்ட மிக விலை உயர்ந்த கண்காணிப்பு அமைப்பு இதுவாகும். இரண்டு கருவிகள், எப்போது என்பதற்கு ஒரு வரி தலா: Uptime Kuma "அது இயங்குகிறதா?" என்ற கேள்விக்கு பதிலளிக்கிறது — HTTP, TCP, மற்றும் ping சரிபார்ப்புகள் எதற்கும் எச்சரிக்கைகளுடன் — மேலும் Docker இல் பத்து நிமிடங்கள் ஆகும்; Zabbix "அது செயலிழக்க உள்ளதா?" என்ற கேள்விக்கு பதிலளிக்கிறது — ஒவ்வொரு host இலும் ஒரு முகவர் வழியாக வட்டு, நினைவகம், மற்றும் CPU போக்குகள் — மேலும் நேர்மையாகச் சொன்னால் ஒரு மதிய நேரம் ஆகும். Kuma உடன் தொடங்கவும்; "இயங்குகிறது ஆனால் செயல்திறன் குறைந்தது" என்பது உங்களுக்கு பணத்தை இழக்கத் தொடங்கும்போது Zabbix ஐச் சேர்க்கவும். இரண்டிற்குமான சிக்கல் அமைவிடம், மேலும் அது போதுமான அளவு முக்கியமானது, அதனால் அது கீழே உள்ள தவறுகள் பகுதிக்கு தலைமை தாங்குகிறது.

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

20+ சர்வர்கள்: இந்த வழிகாட்டி எப்படித் தவறுகிறது

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

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

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

ஒரு இன்வென்டரி கோப்பு — ஒரு டெக்ஸ்ட் கோப்பு கூட போதும். மூன்று சர்வர்கள் இருக்கும் போதே இவற்றை எழுதி வைக்கவும்: பெயர், IP, ப்ரொவைடர், அதில் என்ன இயங்குகிறது, மற்றும் அது ஏன் உள்ளது. git repo வில் ஒரு servers.md இருப்பது போதுமானது; மேலே உள்ள Ansible இன்வென்டரி சிறந்தது, ஏனெனில் அது இயங்கக்கூடிய ஆவணம். இது மாற்றுவது: இரவு 2 மணிக்கு எழும் கேள்வியான "இருங்க, 10.0.0.40 என்ன?" அமைப்புச் செலவு: பத்து நிமிடங்கள். சிக்கல்: ஒரு சர்வரை உருவாக்குவதும் அந்த வரியைச் சேர்ப்பதும் ஒரே செயலாக இருந்தால் மட்டுமே இது வேலை செய்யும்; இரண்டு தனித்தனி செயல்களாக இருக்கக் கூடாது.

கீ ஹைஜீன்: இப்போதே ரொடேஷன், வலிக்கும்போது ஒரு SSH CA. உங்கள் கீகள் எங்கே உள்ளன என்பதைப் பட்டியலிடுங்கள் (உங்கள் பக்கத்தில் cat ~/.ssh/*.pub, ஒவ்வொரு சர்வரின் பக்கத்திலும் ~/.ssh/authorized_keys), பழைய லேப்டாப்களையும் பழைய சக ஊழியர்களையும் நீக்கவும், எங்கே பயன்படுத்தப்பட்டது என்று கூற முடியாத அளவுக்குப் பழையவற்றை ரொடேட் செய்யவும். ஒரு SSH சர்டிபிகேட் அத்தாரிட்டி — ஸ்டேடிக் கீகளுக்குப் பதிலாக குறுகிய காலத்திற்குச் சைன் செய்யப்பட்ட சர்ட்கள் — முதிர்ந்த தீர்வு, ஆனால் நேர்மையான ஆலோசனை என்னவென்றால், பத்து சர்வர்களுக்குக் கீழே, Ansible மூலம் ஒழுங்கான authorized_keys மேனேஜ்மென்ட் 10% சிரமத்தில் 90% பலனைத் தரும்.

ஒரு வழி, இருபது அல்ல. ஒவ்வொரு பப்ளிக் SSH போர்ட்டும் N மடங்கு அட்டாக் சர்ஃபேஸ். ஸ்கேல் செய்யும் பேட்டர்ன்: ஒரு bastion ஹோஸ்ட் — அல்லது சிறந்தது, நீங்கள் கண்ட்ரோல் செய்யும் VPS இல் ஒரு WireGuard VPN — மற்றும் மற்ற எல்லா சர்வர்களின் SSH அவற்றின் ப்ரைவேட் முகவரியுடன் மட்டுமே பைண்ட் செய்யப்பட்டிருக்கும். மேலே உள்ள கன்ஃபிக்கில் ProxyJump வரிகள் ஏற்கனவே இந்த அமைப்பை வைத்துக்கொள்கின்றன. பப்ளிக்காகவே இருக்க வேண்டியவை கட்டாயம் fail2ban பெறும். அமைப்புச் செலவு: ஒரு மணி நேரம், ஒரு முறை. சிக்கல்: எல்லா இடங்களிலும் போர்ட் 22-ஐ மூடுவதற்கு முன்பு, உங்கள் ஃபால்பேக் (ப்ரொவைடரின் கன்சோல் அணுகல்) வேலை செய்கிறதா என்பதை சரிபார்க்கவும், அதற்குப் பிறகு அல்ல.

ரெஸ்டோர் செய்து டெஸ்ட் செய்யப்பட்ட பேக்கப்கள். டெஸ்ட் செய்யப்படாத பேக்கப் ஒரு ஊகம். நீங்கள் எந்த மெக்கானிசத்தைப் பயன்படுத்தினாலும் — ப்ரொவைடர் ஸ்னாப்ஷாட்கள், restic, இரண்டாவது பாக்ஸுக்கு rsync — உண்மையில் முக்கியமான கருவி கேலெண்டர் என்ட்ரிதான், அதில் நீங்கள் ஒரு சர்வரை புதிய VPS இல் ரெஸ்டோர் செய்து அது பூட் ஆகி சர்வ் செய்கிறதா என்பதை உறுதிப்படுத்துவீர்கள். ஹோஸ்டிங்கில் பதினைந்து ஆண்டுகளாக நான் கேட்ட ஒவ்வொரு பேக்கப் துயரக் கதையிலும் "எங்களிடம் பேக்கப்கள் இருந்தன" என்ற சொற்றொடர் இருக்கும்.

பிழைகள்

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

தனித்துவமான சேவையகங்கள். ஒவ்வொரு பெட்டியும் கைமுறையாக உள்ளமைக்கப்பட்டது, சுலபமாக வேறுபடுகிறது, மற்றும் யாராலும் மீண்டும் கட்ட முடியாது. வட்டுத் தோல்வியின்போது இது தெரியவரும். தீர்வு எளிதானது: ஒவ்வொரு மாற்றமும் Ansible வழியாகச் செல்கிறது — அல்லது குறைந்தபட்சம் அந்த சேவையகத்தின் inventory ஆவணப் பிரிவில் இணைக்கப்படுகிறது — மேலும் இன்று மாலை குறிப்புகளிலிருந்து மீண்டும் கட்ட முடியாத எந்த சேவையகமும் தொழில்நுட்பக் கடன் ஆகும், அதன் தேதியை நீங்கள் தேர்ந்தெடுக்க முடியாது.

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

கண்காணிக்கப்படும் பெட்டியில் நடத்தப்படும் கண்காணிப்பு. Uptime Kuma அது கவனிக்கும் சேவையகத்தில் இயங்கினால், "அனைத்தும் செயலிழந்தது" என்று கூறும் எச்சரிக்கையும் செயலிழந்திருக்கும் — நீங்கள் உலகின் மிகக் குறைவான திறனுள்ள datacenter இன் சிறிய, வேடிக்கையான பதிப்பை உருவாக்கியுள்ளீர்கள். கண்காணிப்பு வேறு ஒரு தோல்வி நிலையில் இருக்க வேண்டும்: வேறு ஒரு வழங்குநரிடம் உள்ள மலிவான VPS என்பது பாரம்பரியமான பதில், அல்லது குறைந்தபட்சம் கண்காணிப்பவரைக் கண்காணிக்கும் வெளிப்புற free-tier சரிபார்ப்பு.

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

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

FAQ

பல Linux சேவையகங்களை நிர்வகிக்க சிறந்த இலவச கருவி எது?

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

Ansible இல்லாமல் பல Linux சேவையகங்களை நிர்வகிக்க முடியுமா?

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

ஒரே கட்டளையை பல Linux சேவையகங்களில் ஒருங்கே எப்படி இயக்குவது?

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

Linux சேவையகங்களை நிர்வகிக்க Webmin போன்ற control panel தேவையா?

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

ஒரு நபர் யதார்த்தமாக எத்தனை Linux சேவையகங்களை நிர்வகிக்க முடியும்?

கைமுறை நிர்வாகத்தில், பத்திற்கும் குறைவான எண்ணிக்கையில் தரம் குறைகிறது. config as code, தானியங்கி patching, மற்றும் மையப்படுத்தப்பட்ட monitoring ஆகியவற்றுடன், ஒரு கவனமுள்ள நபர் 20 முதல் 50 சேவையகங்களை part-time வேலையாக இயக்க முடியும் — கட்டுப்பாடு வழக்கத்திற்கு மாறான ஏதாவது எவ்வளவு அடிக்கடி உடைகிறது என்பதாக மாறுகிறது, வழக்கமான பராமரிப்பு அல்ல. முக்கியமான எண் ஒரு admin-க்கு சேவையகங்கள் அல்ல, மாறாக ஒரு admin-க்கு snowflakes: அதை பூஜ்யத்திற்கு அருகில் வைத்தால் உச்ச எல்லை அதிகமாக இருக்கும்.