ఒకటికన్నా ఎక్కువ Linux servers నిర్వహించడం: సరైన పరికరాలు

మీరు నిర్మించేది ఏమిటి

ఒక్క పరికరం కాదు — ఒక చిన్న స్టాక్. మీ వద్ద నిజంగా ఎన్ని సర్వర్‌లు ఉన్నాయో దాని ఆధారంగా దీన్ని ఎంచుకుంటారు. ఆ సంఖ్యే ప్రధానమైన ఏకైక ఇన్‌పుట్. ప్రతి "Linux server management tools" సమీక్ష దాన్ని విస్మరించే అంశం కూడా అదే. సాధారణ తప్పు ఏమిటంటే, నాలుగు VPSల కోసం 200 సర్వర్‌ల పరిష్కారాన్ని స్వీకరించడం. దాంతో సర్వర్‌లకు బదులుగా ఒక నెల రోజులు ఆ పరికరాన్నే పోషించాల్సి వస్తుంది. రెండవ సాధారణ తప్పు ఏమిటంటే, పద్దెనిమిది సర్వర్‌ు ఉన్న వ్యక్తి ఇప్పటికీ ప్రతి ఒక్కటి చేతులా SSH ద్వారా ప్రవేశించడం. "ఒకే" మార్పును పద్దెనిమిది స్వల్పంగా భిన్నమైన పద్ధతుల్లో వర్తింపజేయడం.

కాబట్టి ఈ గైడ్ ఫ్లీట్ పరిమాణం ప్రకారం వర్గీకరించబడింది: 2 నుండి 5 సర్వర్‌లు, 5 నుండి 20, మరియు 20 కంటే ఎక్కువ — అంతేకాకుండా ప్రతి పరిమాణం వద్ద వర్తించే క్రాస్-కట్టింగ్ పొర. దీన్ని ఎవరూ రాసి ఉండరు: ఒక ఇన్వెంటరీ, కీ హైజీన్, ప్రవేశించడానికి ఒకే మార్గం, మరియు మీరు వాస్తవంగా పునరుద్ధరించిన బ్యాకప్‌లు. ప్రతి పరికరం కోసం మీకు మూడు విషయాలు లభిస్తాయి: అది దేని స్థానంలో వస్తుంది, సెటప్‌కు ఎంత సమయం పడుతుంది, మరియు నిజంగా ఇబ్బంది పెట్టే ఒక్క లోపం. నేను పదునైదేళ్లుగా ఒక VPS హోస్ట్‌ను నడుపుతున్నాను; కింద ఉన్న జాబితా అర్ధరాత్రి 2 గంటల అవుటేజ్‌తో ఎదుర్కొన్నప్పుడు నిలబడేది, డెమో బాగా చూపించేది కాదు.

ముందస్తు అవసరాలు మరియు నిజాయితీ హెచ్చరికలు

ప్రతి సర్వర్‌కు కీ-ఆధారిత SSH ఇప్పటికే పని చేస్తూ ఉండాలి (మీరు ఇంకా పాస్‌వర్డ్‌లు టైప్ చేస్తుంటే, ముందుగా దాన్ని సరి చేయండి — అది పది నిమిషాల పని మరియు దిగువ ఉన్న ప్రతిదీ కీలను ఊహించుకుంటుంది), root కాని ఒక sudo వినియోగదారు, మరియు తాజా వెర్షన్ నడుస్తున్న సర్వర్‌లు అవసరం. ఇక్కడ ఉన్న ఆదేశాలు Ubuntu 24.04 ను ఊహించుకుంటాయి, అయితే apt తప్ప మరేదీ Ubuntu-ప్రత్యేకం కాదు.

పనిముట్ల గురించి చర్చించే ముందు రెండు నిజాయితీ హెచ్చరికలు. మొదటగా, పనిముట్ల విస్తరణ అనేది స్వయంగా ఒక నిర్వహణ సమస్యే: మీరు ఇన్‌స్టాల్ చేసే ప్రతి ఏజెంట్ అనేది ప్రతి సర్వర్‌లో ప్యాచ్ చేయాల్సిన మరొక డెమోన్. కాబట్టి దాన్ని జోడించడానికి ఉన్న ప్రామాణికం "ఇది ఈ వారం నేను చేసిన మాన్యువల్ పనిని భర్తీ చేస్తుంది" అని ఉండాలి, "ఇది ఉపయోగపడుతుంది" అని కాదు. రెండవది, ఇక్కడ ఉన్నదంతా ఉచిత సాఫ్ట్‌వేర్ మరియు నిజమైన ఖర్చు సెటప్ సమయం మాత్రమే. అందుకే ప్రతి పనిముట్టు నిమిషాల్లో అంచనాతో పాటు ఉంది — ఆ అంచనా ఒక మధ్యాహ్నం పడుతుంది అని చెప్పినప్పుడు, దాన్ని నమ్మండి.

2 నుండి 5 సర్వర్‌లు: ~/.ssh/config అనేది మీకు ఇప్పటికే ఉన్న అత్యంత విలువ తగ్గించబడిన సాధనం

దేని స్థానంలో వస్తుంది: IP చిరునామాలతో కూడిన టెక్స్ట్ ఫైల్, షెల్-హిస్టరీ అన్వేషణ (ssh 203.0 తర్వాత Ctrl-R నొక్కి ఆశపడటం), మరియు నిరంతరం -p 2222 -i ~/.ssh/other_key టైప్ చేయడం. సెటప్ ఖర్చు: 15 నిమిషాలు, ఒకేసారి. ఉన్న సమస్య: పాత మల్టీప్లెక్సింగ్ సాకెట్‌లు, దిగువన వివరించబడ్డాయి.

ఈ పరిమాణంలో మీకు సాఫ్ట్‌వేర్ అవసరం లేదు; మీకు ఇప్పటికే ఉన్న క్లయింట్ అవసరం, దాన్ని సరైన విధంగా కాన్ఫిగర్ చేయాలి. ~/.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 కనెక్షన్‌లను ఒకే హాప్‌లో బాస్టియన్ ద్వారా రూట్ చేస్తుంది, కాబట్టి కేఫే నుండి ssh db1 పారదర్శకంగా bastion ద్వారా టనెల్ అవుతుంది — ఏ ఏజెంట్ ఫార్వార్డింగ్ లేదు, ఏ ProxyCommand మంత్రాలు లేవు, మరియు ప్రైవేట్ సర్వర్‌లకు పబ్లిక్ SSH పోర్టులు అసలు అవసరం లేదు (క్రాస్-కటింగ్ విభాగంలో దీని గురించి మరింత). ControlMaster auto మరియు ControlPersist ఒకే TCP సెషన్‌లో కనెక్షన్‌లను మల్టీప్లెక్స్ చేస్తాయి, కాబట్టి రెండవది మరియు అదే హోస్ట్‌కు ప్రతి తదుపరి ssh, scp, లేదా rsync పునఃచర్చ చేయకుండా తక్షణమే కనెక్ట్ అవుతుంది — ఆన్సిబుల్ రంగంలోకి వచ్చినప్పుడు ఈ తేడా నాటకీయంగా మారుతుంది. మరియు scp, rsync, మరియు ఆన్సిబుల్ అన్నీ ఈ ఒకే ఫైల్‌ను చదువుతాయి కాబట్టి, మీరు ఇక్కడ నిర్వచించే ప్రతి పేరు అన్నిచోట్లా పనిచేస్తుంది.

ఉన్న సమస్య: మాస్టర్ కనెక్షన్ దాని ఉపయోగాన్ని దాటి జీవించగలదు, మరియు రెండు వైఫల్య రకాలు భిన్నంగా కనిపిస్తాయి. సర్వర్ రీబూట్ అయినప్పుడు లేదా మీ Wi-Fi డ్రాప్ అయినప్పుడు, మాస్టర్ ప్రాసెస్ ఇంకా గుర్తించని చనిపోయిన TCP సెషన్‌ను పట్టుకుని ఉండిపోతుంది, మరియు తదుపరి ssh web1 ఎక్కడికి చేరని సాకెట్‌పై నిశ్శబ్దంగా వేలాడుతుంది. వేరేగా, sshd ప్రతి కనెక్షన్‌కు సెషన్‌లను 10 వద్ద పరిమితం చేస్తుంది (sshd_configలో MaxSessions), కాబట్టి ఒక హోస్ట్‌కు పదకొండవ మల్టీప్లెక్స్డ్ సెషన్ ఇది ప్రింట్ చేస్తుంది:

mux_client_request_session: session request failed: Session open refused

రెండింటికీ ఒకే పరిష్కారం ఉంది: ssh -O exit web1 మాస్టర్‌ను కిల్ చేస్తుంది, మరియు తదుపరి కనెక్షన్ కొత్తదాన్ని ప్రారంభిస్తుంది. మీరు అప్పుడప్పుడు ControlSocket ~/.ssh/cm-matt@web1-22 already exists, disabling multiplexing కూడా చూడవచ్చు — అది హానికరం కాదు: రెండు సెషన్‌లు పోటీపడ్డాయి, మరియు కనెక్షన్ ఇప్పటికీ పనిచేస్తుంది, కేవలం మల్టీప్లెక్స్ కాకుండా.

ఈ పరిమాణంలో ఇద్దరు సహచరులు. ప్రతి సర్వర్‌లో tmux అనేది nohup, Wi-Fi డ్రాప్ అయినప్పుడు పోయిన పని, మరియు "నేను నా ల్యాప్‌టాప్‌ను మూసివేయలేను, ఒక మైగ్రేషన్ నడుస్తోంది" వాటి స్థానంలో వస్తుంది. సెటప్ ఖర్చు: sudo apt install -y tmux, రెండు నిమిషాలు, అంతేకాక tmux new -s work మరియు tmux attach -t work యొక్క మాంసపు స్మృతి కూడా. ఇక్కడ ఉన్న సమస్య నెస్టింగ్: tmux లోపల tmux మీ ప్రిఫిక్స్ కీని మింగేస్తుంది, కాబట్టి దాన్ని సర్వర్‌లో లేదా ల్యాప్‌టాప్‌లో నడపండి, రెండింటిలోనూ కాదు. మీరు సుదీర్ఘకాలిక ఏజెంట్ సెషన్‌లను నడిపితే ఇది రెట్టింపు ముఖ్యం — ఇది VPSలో tmuxలో క్లాడ్ కోడ్‌ను నడపడం వలె అదే ప్యాటర్న్, అక్కడ సెషన్ SSH కనెక్షన్‌ను దాటి జీవించాలి.

ఒక షేర్డ్ అలియాస్ ఫైల్ ప్రతి బాక్స్‌లో మీకు ఇష్టమైన పన్నెండు వన్-లైనర్‌లను మళ్లీ టైప్ చేయడం భర్తీ చేస్తుంది. ఒక git రెపోలో .bash_aliases ఉంచండి మరియు దాన్ని ప్రతి సర్వర్‌లోకి పుల్ చేయండి. ఉన్న సమస్య: మీరు రెపోలో కాకుండా ఒక సర్వర్‌లో నేరుగా దాన్ని సవరించిన క్షణంలోనే అది డ్రిఫ్ట్ అవుతుంది — తదుపరి టైర్ ఎందుకు ఉందో తెలియజేసే మీ మొదటి అనుభవం కూడా ఇదే.

5 నుండి 20 సర్వర్‌లు: కాన్ఫిగ్ కోడ్ వలె, లేదా డ్రిఫ్ట్ గెలుస్తుంది

ఐదు సర్వర్‌ల తర్వాత, "నేను ప్రతి బాక్స్‌లోనూ చేస్తాను" అనేది ఒక పద్ధతి కాదు. అది మీరు మీకంటూ చెప్పుకునే అబద్ధం. ఈ స్థాయిలోని సాధనాలన్నీ ఒకే శత్రువును ఎదుర్కొంటాయి: డ్రిఫ్ట్.

Ansible హోస్ట్‌పేర్లపై షెల్ లూప్‌ను భర్తీ చేస్తుంది. "new server setup" అనే వికీ పేజీ మూడు స్టెప్‌లు వెనుకబడి ఉంటుంది. web3 కి వాస్తవానికి ఫిక్స్ వచ్చిందో లేదో తెలియని ఆందోళి ఉంటుంది. సెటప్ ఖర్చు: మొదటి పనిచేసే ప్లేబుక్ వరకు 30 నిమిషాలు — మీ ల్యాప్‌టాప్‌పై లేదా మేనేజ్‌మెంట్ బాక్స్‌పై sudo apt install -y ansible (apt మీకు పాత Ansible వెర్షన్‌ను ఇస్తుంది, ఇది ఇక్కడ ఉన్న ప్రతిదానికీ సరిపోతుంది; ఈ ట్యుటోరియల్‌లోని pipx మార్గం మీకు ప్రస్తుత వెర్షన్‌లను ఇస్తుంది). సర్వర్‌లపై ఏ ఏజెంట్లు ఉండవు. మీరు ఇప్పటికే నిర్మించిన SSH కాన్ఫిగ్ ద్వారా ప్రతిదీ నడుస్తుంది. ఇది ఈ పేజీలో అతిపెద్ద సింగిల్ అప్‌గ్రేడ్. పూర్తి వాక్‌త్రూ the Ansible first-playbook tutorial లో ఉంది; దీన్ని పనిచేయించే ఇన్వెంటరీ ఆకారం ఇక్కడ ఉంది:

[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 వంటి బేర్ పేర్ల ఇన్వెంటరీ వేరే వార్స్ లేకుండానే పని చేస్తుంది. పైన ఉన్న వార్స్ ఇన్వెంటరీని స్వయం-సమగ్రంగా చేస్తాయి. మీరు దీన్ని మీ ల్యాప్‌టాప్ కాని ఇతర మెషిన్ నుండి రన్ చేసే రోజున ఇది మీకు ఉపయోగపడుతుంది.

దీన్ని ansible all -i inventory.ini -m ping తో టెస్ట్ చేయండి; సరైన ఫలితం ప్రతి హోస్ట్‌కూ "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 అవసరం, కాబట్టి నిజంగా మినిమల్ ఇమేజ్ /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 టాస్క్. ఇబ్బంది ఏమిటంటే: డిఫాల్ట్‌గా ఇది ఎప్పుడూ రీబూట్ అవ్వదు, కాబట్టి మీరు చేసే వరకు కెర్నల్ సెక్యూరిటీ అప్‌డేట్‌లు సగం వర్తించిన స్థితిలోనే ఉంటాయి — the dedicated unattended-upgrades guide ఆటోమేటిక్ రీబూట్‌లు, ఏవి ప్యాచ్ చేయబడతాయో ఎంచుకోవడం, మరియు దాని లాగ్‌లను చదవడం గురించి వివరిస్తుంది.

సెంట్రలైజ్డ్ మానిటరింగ్ కస్టమర్ ద్వారా తెలుసుకోవడాన్ని భర్తీ చేస్తుంది. అది ఇప్పటివరకు కనిపెట్టిన అత్యంత ఖరీదైన మానిటరింగ్ సిస్టమ్. రెండు సాధనాలు, ఎప్పుడు వాడాలో ఒక్కో లైన్: Uptime Kuma "అది అప్ లో ఉందా?" అనే ప్రశ్నకు సమాధానం ఇస్తుంది — HTTP, TCP, మరియు ping చెక్‌లు ఏదైనా ఒకదానికి అలర్ట్‌లతో — మరియు Docker లో పది నిమిషాలు పడుతుంది; Zabbix "అది కూలిపోవడానికి సిద్ధంగా ఉందా?" అనే ప్రశ్నకు సమాధానం ఇస్తుంది — ప్రతి హోస్ట్‌పై ఒక ఏజెంట్ ద్వారా డిస్క్, మెమరీ, మరియు CPU ట్రెండ్‌లు — మరియు నిజానికి ఒక మధ్యాహ్నం పడుతుంది. Kuma తో ప్రారంభించండి; "అప్ గా ఉంది కానీ డిగ్రేడెడ్ గా ఉంది" అనే పరిస్థితి మీకు నష్టం కలిగించడం మొదలైనప్పుడు Zabbix ని జోడించండి. రెండింటికీ ఉన్న ఇబ్బంది ప్లేస్‌మెంట్. అది చాలా ముఖ్యమైనది కాబట్టి, దిగువ తప్పుల విభాగాన్ని అది నడిపిస్తుంది.

వెబ్ ప్యానెల్, తప్పనిసరైతే మాత్రమే. Webmin Ubuntu విషయాలను ఎక్కడ ఉంచుతుందో గుర్తుంచుకోవడాన్ని భర్తీ చేస్తుంది. వివిధ నైపుణ్యాలు ఉన్న టీమ్ కోసం లేదా సంవత్సరానికి రెండుసార్లు మీరు తాకే సర్వర్ కోసం ఇది నిజంగా ఉపయోగకరం; సెటప్ పది నిమిషాలు. ఇబ్బంది ఏమిటంటే ఇది పోర్ట్ 10000 పై వింటినే ఉండే రూట్-ఎక్వివలెంట్ వెబ్ అప్లికేషన్. ఇంటర్నెట్ దీని కోసం నిరంతరం స్కాన్ చేస్తూ ఉంటుంది. మీరు దీన్ని రన్ చేస్తే, దాన్ని localhost కి లేదా VPN చిరునామాకు బైండ్ చేయండి — పబ్లిక్ ఇంటర్ఫేస్‌పై 0.0.0.0 కు ఎప్పుడూ వద్దు. మరియు SSH నెమ్మదిగా అనిపించడం వల్ల మీరు ప్యానెల్ కోసం చూస్తుంటే, ముందు మునుపటి విభాగాన్ని మళ్లీ చదవండి; ఒకసారి కాన్ఫిగర్ చేసిన తర్వాత ~/.ssh/config ప్లస్ Ansible ఏ ప్యానెల్ కంటే వేగవంతమైనది.

20+ సర్వర్లు: ఈ గైడ్ ఎక్కడ నిజంగా ముగుస్తుందో

ఇరవై సర్వర్ల తర్వాత మీరు ఒక ఫ్లీట్‌ను నడుపుతున్నట్లు అవుతుంది. దీనివల్ల టూల్‌చైన్ రూపం మారుతుంది. సర్వర్లు పునఃసృష్టించదగినవి కావడానికి Terraform లేదా OpenTofu వాడుతారు. ఒక బాక్స్‌ను రిపేర్ చేయడం కంటే పాత వాటిని పక్కన పెట్టడానికి cloud-init లేదా golden images వాడుతారు. ల్యాప్‌టాప్ నుండి పుష్ చేయడం స్కేల్ కానందున, పుల్-ఆధారిత కాన్ఫిగరేషన్ లేదా మీ Ansible ను నడిపే CI pipelines వాడుతారు. అంతేకాకుండా, సరైన సీక్రెట్స్ మేనేజ్‌మెంట్ అవసరం. ఇరవై సర్వర్ల వద్ద Ansible స్వయంగా విఫలం కాదు — చాలా సంస్థలు వందలాది నోడ్‌లపై దీన్ని నడుపుతున్నాయి. కానీ దాని చుట్టూ ఉన్న పద్ధతులు దృఢం కావాలి. అది ఈ సైట్ రాసే వ్యాసం కంటే భిన్నమైనది. మీరు ఆ స్థాయిలో ఉంటే, కింద ఉన్న విభాగం ఇంకా మీదే. ఎందుకంటే ఇన్వెంటరీ, కీలు, మరియు యాక్సెస్ విభాగం సరిగ్గా ఫ్లీట్ టూలింగ్ మీకు ముందే ఉన్నాయని ఊహించే అంశాలు.

ఎవరూ రాని పొర

నాలుగు పద్ధతులు ప్రతి సర్వర్ సంఖ్యకు వర్తిస్తాయి. వాటిని వదిలేయడమే సర్వర్ల సంఖ్య అనిపించినదానికంటే ఎక్కువ బరువుగా అనిపించడానికి కారణం.

ఒక ఇన్వెంటరీ ఫైల్ — ఒక టెక్స్ట్ ఫైల్ అయినా సరే. మీకు మూడు సర్వర్లు ఉన్నప్పుడు, ఇవి రాయండి: పేరు, IP, ప్రొవైడర్, దానిపై ఏమి నడుస్తుంది, మరియు అది ఎందుకు ఉంది. git రిపోజిటరీలో ఒక servers.md సరిపోతుంది; పైన పేర్కొన్న Ansible ఇన్వెంటరీ మెరుగైనది ఎందుకంటే అది నిర్వహించగలిగే డాక్యుమెంటేషన్. ఇది భర్తీ చేసేది: రాత్రి 2 గంటల ప్రశ్న "ఆగండి, 10.0.0.40 అంటే ఏమిటి?" సెటప్ ఖర్చు: పది నిమిషాలు. జాగ్రత్త: ఒక సర్వర్‌ను సృష్టించడం మరియు ఆ వరుసను జోడించడం ఒకే చర్య అయినప్పుడు ఇది పనిచేస్తుంది, రెండు వేర్వేరు చర్యలు కాదు.

కీ పరిశుద్ధత: ఇప్పుడు రొటేషన్, బాధించినప్పుడు SSH CA. మీ కీలు ఎక్కడ ఉన్నాయో లెక్కించండి (మీ వైపు cat ~/.ssh/*.pub, ప్రతి సర్వర్ వైపు ~/.ssh/authorized_keys), పాత ల్యాప్‌టాప్‌లు మరియు పాత సహచరులను తొలగించండి, మరియు అవి ఎక్కడున్నాయో మీరు చెప్పలేనంత పాతవి ఏవైనా ఉంటే వాటిని రొటేట్ చేయండి. ఒక SSH సర్టిఫికేట్ అథారిటీ — స్టాటిక్ కీల బదులు షార్ట్-లైవ్డ్ సైన్డ్ సర్ట్‌లు — అనుభవజ్ఞులైన సమాధానం, కానీ నిజాయితీ సలహా ఏమిటంటే పది సర్వర్ల కంటే తక్కువకు, Ansible ద్వారా క్రమబద్ధమైన authorized_keys నిర్వహణ 10% ఆచారంతో 90% ప్రయోజనాన్ని ఇస్తుంది.

ఒక మార్గం లోపల, ఇరవై కాదు. ప్రతి పబ్లిక్ SSH పోర్ట్ N తో గుణించబడిన దాడి ఉపరితలం. స్కేల్ అయ్యే ప్యాటర్న్: ఒక బాస్టియన్ హోస్ట్ — లేదా మెరుగైనది, మీరు నియంత్రించే VPSలో WireGuard VPN — మరియు ప్రతి ఇతర సర్వర్ SSH దాని ప్రైవేట్ చిరునామాకు మాత్రమే బంధించబడి ఉంటుంది. పైన కాన్ఫిగ్‌లోని ProxyJump వరుసలు ఇప్పటికే ఈ ఆకారాన్ని ఊహిస్తున్నాయి. పబ్లిక్‌గా ఉండాల్సింది ఏదైనా సరే, అది సహజంగా fail2ban పొందుతుంది. సెటప్ ఖర్చు: ఒక గంట, ఒకసారి. జాగ్రత్త: మీ ఫాల్‌బ్యాక్ (ప్రొవైడర్ కన్సోల్ యాక్సెస్) పనిచేస్తుందో లేదో మీరు పోర్ట్ 22 అన్నిచోట్లా మూసివేసే ముందు ధృవీకరించండి, తర్వాత కాదు.

రిస్టోర్ చేయడం ద్వారా పరీక్షించబడిన బ్యాకప్‌లు. పరీక్షించని బ్యాకప్ ఒక ఊహ. మీరు ఏ మెకానిజం ఉపయోగించినా — ప్రొవైడర్ స్నాప్‌షాట్‌లు, restic, రెండవ పెట్టెకు rsync — నిజంగా ముఖ్యమైన సాధనం క్యాలెండర్ ఎంట్రీ, దీనిలో మీరు ఒక సర్వర్‌ను కొత్త VPSపై రిస్టోర్ చేస్తారు మరియు అది బూట్ అవుతుందో సర్వ్ చేస్తుందో నిర్ధారిస్తారు. హోస్టింగ్‌లో పదిహేను సంవత్సరాలుగా నేను విన్న ప్రతి బ్యాకప్ భయంకరమైన కథ "మాకు బ్యాకప్‌లు ఉన్నాయి" అనే పదబంధాన్ని కలిగి ఉంటుంది.

తప్పులు

బహుళ-సర్వర్ స్థాయిలో వైఫల్య రకాలు సాధన వైఫల్యాలు కావు; అవి అలవాటులు. వాటిలో నాలుగు దాదాపు ప్రతిదీ వివరిస్తాయి.

స్నోఫ్లేక్ సర్వర్లు. ప్రతి పెట్టె చేతితో కాన్ఫిగర్ చేయబడింది, సూక్ష్మంగా భిన్నంగా ఉంటుంది, మరియు ఎవరూ దాన్ని పునర్నిర్మించలేరు. డిస్క్ వైఫల్యం సమయంలో మీకు తెలుస్తుంది. పరిష్కారం సాధారణంగా ఉంది: ప్రతి మార్పు Ansible ద్వారా వస్తుంది — లేదా కనీసం ఆ సర్వర్ యొక్క ఇన్వెంటరీ డాక్ విభాగానికి జతచేయబడుతుంది — మరియు ఈ మధ్యాహ్నం గమనికల నుండి మీరు పునర్నిర్మించలేని ఏ సర్వర్ అయినా సాంకేతిక రుణం, దాని గడువు తేదీని మీరు ఎంచుకోలేరు.

"తాత్కాలిక" ఫైర్‌వాల్ రంధ్రాలు. ఏదైనా డీబగ్ చేయడానికి ufw allow 5432, మరియు పద్దెనిమిది నెలల తర్వాత Postgres ఇంకా ఇంటర్నెట్‌లో ఉంది. ప్రతి పెట్టెపై sudo ufw status numbered తో ఆడిట్ చేయండి — లేదా ఒకేసారి, ansible all -i inventory.ini -a "ufw status numbered" --become — మరియు ప్రస్తుత కారణాన్ని మీరు పేర్కొనలేని ప్రతిదాన్ని తొలగించండి. ఒక నియమం నిజంగా తాత్కాలికమైతే, సరిపోలే ufw delete మీరు దాన్ని మూసే ముందు అదే tmux విండోలోకి వెళ్తుంది.

పర్యవేక్షించబడే పెట్టెపై హోస్ట్ చేయబడిన పర్యవేక్షణ. Uptime Kuma దాని పర్యవేక్షించే సర్వర్‌పై నడిస్తే, "ప్రతిదీ డౌన్" అని చెప్పే హెచ్చరిక కూడా డౌన్ అవుతుంది — మీరు ప్రపంచంలోని అత్యల్ప సామర్థ్య డేటాసెంటర్ యొక్క చిన్న, వినోదాత్మక వెర్షన్‌ను నిర్మించారు. పర్యవేక్షణ వేరే వైఫల్య డొమైన్‌లో ఉంటుంది: వేరే ప్రొవైడర్ వద్ద చౌకమైన VPS అనేది సాంప్రదాయ సమాధానం, లేదా కనీసం పర్యవేక్షకుడిని పర్యవేక్షించే బాహ్య ఉచిత-స్థాయి తనిఖీ.

అన్నిచోట్లా రూట్ SSH. మొత్తం ఫ్లీట్‌లో ఒకే భాగస్వామ్య రూట్ కీ అంటే ఒక లీక్ అయిన లాప్‌టాప్ ప్రతిదీ స్వంతం చేసుకుంటుంది, మరియు ఎవరు ఏమి చేశారో చెప్పే ఆడిట్ ట్రయల్ ఏదీ లేదు. వ్యక్తిగత వినియోగదారులు, sudo, మరియు ప్రతి హోస్ట్‌పై /etc/ssh/sshd_config లో PermitRootLogin no — ఇది మళ్ళీ, టైపింగ్ చేసే సాయంత్రం కాకుండా మూడు-లైన్ల Ansible టాస్క్.

ఫ్లీట్ కొన్ని సర్వర్ల దాటి పెరిగినప్పుడు, మీ మొదటి Ansible ప్లేబుక్ పునరావృత భాగాలను స్వయంచాలకం చేస్తుంది.

FAQ

బహుళ Linux సర్వర్‌లను నిర్వహించడానికి ఉత్తమ ఉచిత సాధనం ఏది?

2 నుండి 5 సర్వర్‌ల వరకు, బాగా రాసిన ~/.ssh/config మరియు tmux మీరు ఇన్‌స్టాల్ చేయగలిగే దేనికంటే మెరుగైనది. దాదాపు ఐదు సర్వర్‌ల నుండి పైన, Ansible అనేది ప్రామాణిక సమాధానం: ఏజెంట్‌లేనిది, ఉచితం, మీరు ఇప్పటికే కలిగి ఉన్న SSH పై నడుస్తుంది, మరియు సర్వర్ సెటప్‌ను git లోని ఫైళ్లుగా మారుస్తుంది. అప్/డౌన్ హెచ్చరిక కోసం Uptime Kuma ని జోడించండి; ఈ గైడ్‌లో పేర్కొన్న ప్రతి సాధనం ఉచిత సాఫ్ట్‌వేర్.

Ansible లేకుండా నేను బహుళ Linux సర్వర్‌లను నిర్వహించగలనా?

అవును — దాదాపు ఐదు సర్వర్‌ల కంటే తక్కువకు, మంచి SSH కాన్ఫిగ్, షేర్డ్ ఎలియాస్ ఫైల్, మరియు క్రమశిక్షణ సరిపోతాయి, చాలా మంది సంవత్సరాల తరబడి అలాగే నడుపుతున్నారు. అంతకంటే మించి, Ansible కు ప్రత్యామ్నాయం "ఏమీ లేదు" కాదు, అది డాక్యుమెంట్ చేయని డ్రిఫ్ట్: పద్దెనిమిది సర్వర్‌లు ఒక్కోదానికి చేతితో స్వల్పంగా భిన్నంగా కాన్ఫిగర్ చేయబడతాయి. Ansible భారీగా అనిపిస్తే, authorized_keys మరియు unattended-upgrades ని మాత్రమే నిర్వహించే ఒక ప్లేబుక్‌తో ప్రారంభించండి; అది ఒక్కటే లెర్నింగ్ కర్వ్‌కు ప్రతిఫలం ఇస్తుంది.

నేను బహుళ Linux సర్వర్‌లపై ఒకేసారి ఒకే కమాండ్‌ను ఎలా నడుపగలను?

ansible all -i inventory.ini -a "uptime" అనేది స్పష్టమైన సమాధానం మరియు దానికి ప్లేబుక్‌లు అవసరం లేదు, కేవలం ఇన్వెంటరీ ఫైల్ సరిపోతుంది. ఇంటరాక్టివ్ సైడ్-బై-సైడ్ పని కోసం, tmux అనేది setw synchronize-panes on తో ప్రతి పేన్‌కు కీస్ట్రోక్‌లను ప్రసారం చేయగలదు — కానీ దాన్ని ఒక పార్టీ ట్రిక్‌గా పరిగణించండి, ఎందుకంటే ప్రొడక్షన్ సర్వర్‌లకు ఇంటరాక్టివ్ కమాండ్‌లను ప్రసారం చేయడం వల్ల ఒక టైపో N రెట్లు అవుటేజ్‌గా మారుతుంది.

Linux సర్వర్‌లను నిర్వహించడానికి Webmin వంటి కంట్రోల్ ప్యానెల్ అవసరమా?

అవసరం లేదు — ప్యానెల్ చేసే ప్రతిదాన్ని, SSH మరియు Ansible మరింత పునరుత్పాదకంగా చేస్తాయి. వివిధ నైపుణ్య స్థాయిల వ్యక్తులు ఒకే సర్వర్‌లను నిర్వహించినప్పుడు, లేదా మీరు సర్వర్‌ను చాలా అరుదుగా తాకినప్పుడు కాన్ఫిగ్ పాత్‌లను తిరిగి కనుగొనడానికి నిజమైన సమయం పడినప్పుడు Webmin దాని స్థానాన్ని సంపాదిస్తుంది. మీరు ఒకదాన్ని నడిపితే, దాన్ని అది ఉన్న root-సమాన వెబ్ యాప్‌గా పరిగణించండి: దాన్ని localhost లేదా VPN చిరునామాకు బైండ్ చేయండి, పబ్లిక్ ఇంటర్‌ఫేస్‌కు ఎప్పుడూ కాదు.

ఒక వ్యక్తి వాస్తవంగా ఎన్ని Linux సర్వర్‌లను నిర్వహించగలడు?

చేతి నిర్వహణతో, నాణ్యత పది కంటే తక్కువ ఎక్కడో పడిపోతుంది. కాన్ఫిగ్ కోడ్‌గా, ఆటోమేటెడ్ ప్యాచింగ్, మరియు సెంట్రలైజ్డ్ మానిటరింగ్‌తో, ఒక జాగ్రత్తగా ఉన్న వ్యక్తి 20 నుండి 50 సర్వర్‌లను పార్ట్-టైమ్ ఉద్యోగంగా నడపగలడు — పరిమితి రొటీన్ కేర్ కాదు, కొత్తది ఎంత తరచుగా విరుస్తుందో అవుతుంది. ముఖ్యమైన సంఖ౾ ప్రతి అడ్మిన్‌కు సర్వర్‌లు కాదు ప్రతి అడ్మిన్‌కు స్నోఫ్లేక్‌లు: దాన్ని సున్నా దగ్గర ఉంచండి, పై సీలింగ్ ఎక్కువగా ఉంటుంది.