Linux servers నిర్వహణకు సరైన tools ఏవి?

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

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

అందుకే ఈ guide fleet size ఆధారంగా రూపొందించబడింది: 2 నుంచి 5 servers, 5 నుంచి 20 servers, 20 దాటిన fleetలు. ప్రతి పరిమాణానికి వర్తించే, కానీ ఎవరూ రాయనిది అయిన common layer కూడా ఇందులో ఉంది: inventory, key hygiene, లోపలికి ప్రవేశించే ఒకే విధానం, మరియు మీరు వాస్తవంగా restore చేసి పరీక్షించిన backups. ప్రతి tool కోసం మూడు విషయాలు అందిస్తాం: అది ఏదిని భర్తీ చేస్తుంది, setupకు ఎన్ని నిమిషాలు పడతాయి, మరియు వాస్తవ సమస్య సమయంలో ఇబ్బంది కలిగించే ఒక ప్రధాన విషయం. నేను పదిహేను సంవత్సరాలుగా VPS host నిర్వహిస్తున్నాను. కాబట్టి క్రింది జాబితా 2 a.m. outage సమయంలోనూ ఉపయోగపడే వాటిని మాత్రమే కలిగి ఉంది; demoలో బాగా కనిపించే వాటిని కాదు.

అవసరాలు మరియు వాస్తవంగా గుర్తుంచుకోవాల్సిన విషయాలు

ప్రతి server కు key-based SSH ఇప్పటికే పనిచేస్తూ ఉండాలి. మీరు ఇంకా passwords టైప్ చేస్తుంటే, ముందుగా దాన్ని సరిచేయండి. దీనికి పది నిమిషాలు పడుతుంది. దిగువన ఉన్న ప్రతిదీ keys పై ఆధారపడి ఉంటుంది. root కాని sudo user కూడా ఉండాలి. Servers లో ప్రస్తుతకాలపు software నడుస్తూ ఉండాలి. ఇక్కడి commands Ubuntu 24.04 ను అనుసరిస్తాయి. అయితే apt తప్ప మరేదీ Ubuntu-specific కాదు.

Tools ఉపయోగించే ముందు రెండు వాస్తవ హెచ్చరికలు. మొదటిది, tools ను అధికంగా చేర్చడం కూడా management సమస్యే. మీరు install చేసే ప్రతి agent ప్రతి box లో patch చేయాల్సిన మరో daemon అవుతుంది. కాబట్టి కొత్త tool చేర్చడానికి ప్రమాణం “ఈ వారం నేను మాన్యువల్‌గా చేసిన పనిని ఇది భర్తీ చేస్తుంది” అయి ఉండాలి; “ఇది ఉపయోగకరంగా కనిపిస్తోంది” కాదు. రెండవది, ఇక్కడ ఉన్న ప్రతిదీ free software. అసలు ఖర్చు setup సమయం. అందుకే ప్రతి tool కు నిమిషాల్లో ఒక అంచనాను ఇచ్చాం. ఆ అంచనా ఒక afternoon అని చెబితే, దాన్ని అక్షరాలా నమ్మండి.

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

ఇది భర్తీ చేసేది: IP చిరునామాల text file, shell history లో వెతుకులాట (ssh 203.0 తరువాత Ctrl-R నొక్కి ఫలితం కోసం ఎదురుచూడటం), అలాగే ఎప్పటికీ -p 2222 -i ~/.ssh/other_key టైప్ చేయడం. అమలు చేయడానికి పట్టే సమయం: ఒక్కసారి 15 నిమిషాలు. గమనించాల్సిన సమస్య: stale multiplexing sockets; దీని గురించి దిగువన ఉంది.

ఈ స్థాయిలో మీకు ప్రత్యేక software అవసరం లేదు. మీ వద్ద ఇప్పటికే ఉన్న client ను ఉద్దేశించిన విధంగా configure చేయాలి. ~/.ssh/config ప్రతి సర్వర్‌కు ఒక పదంతో ఉపయోగించగల పేరు ఇస్తుంది. 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

ఈ పని మూడు settings తో పూర్తవుతుంది. ProxyJump ఒకే hop లో bastion ద్వారా connections ను route చేస్తుంది. అందువల్ల café నుంచి ssh db1 చేసినప్పుడు అది పారదర్శకంగా bastion ద్వారా tunnel అవుతుంది. Agent forwarding అవసరం లేదు. ProxyCommand వంటి incantations అవసరం లేదు. Private servers కు public SSH ports కూడా అవసరం ఉండదు. దీనిపై cross-cutting section లో మరింత వివరాలు ఉన్నాయి. ControlMaster auto ను ControlPersist తో ఉపయోగిస్తే connections ఒకే TCP session మీద multiplex అవుతాయి. అందువల్ల అదే host కు రెండవ మరియు తరువాతి ప్రతి ssh, scp లేదా rsync వెంటనే connect అవుతుంది. ప్రతిసారి మళ్లీ negotiation చేయాల్సిన అవసరం ఉండదు. Ansible ఉపయోగించినప్పుడు ఈ తేడా స్పష్టంగా కనిపిస్తుంది. scp, rsync మరియు Ansible అన్నీ ఇదే file ను చదువుతాయి. కాబట్టి ఇక్కడ నిర్వచించిన ప్రతి పేరు అన్ని చోట్లా పనిచేస్తుంది.

గమనించాల్సిన సమస్య ఏమిటంటే, master connection అవసరం ముగిసిన తర్వాత కూడా కొనసాగవచ్చు. దీని వల్ల రెండు రకాల వైఫల్యాలు కనిపిస్తాయి. Server reboot అయినప్పుడు లేదా మీ Wi-Fi disconnect అయినప్పుడు, master process తాను గుర్తించని dead TCP session ను పట్టుకుని ఉంటుంది. తరువాతి ssh web1 ఎక్కడికీ దారి లేని socket పై నిశ్శబ్దంగా hang అవుతుంది. మరోవైపు, sshd ప్రతి connection కు sessions సంఖ్యను 10కి పరిమితం చేస్తుంది (MaxSessions లో sshd_config). అందువల్ల ఒక host కు multiplex చేసిన పదకొండవ session ఈ సందేశాన్ని చూపిస్తుంది:

mux_client_request_session: session request failed: Session open refused by peer

రెండింటికీ ఒకే పరిష్కారం ఉంది: ssh -O exit web1 master ను terminate చేస్తుంది. తరువాతి connection కొత్త master ను ప్రారంభిస్తుంది. కొన్నిసార్లు ControlSocket /home/matt/.ssh/cm-matt@10.8.0.11-22 already exists, disabling multiplexing కూడా కనిపించవచ్చు. అది ప్రమాదకరం కాదు. రెండు sessions ఒకేసారి ప్రారంభించడానికి ప్రయత్నించాయి. Connection మాత్రం పనిచేస్తుంది, కానీ multiplexing లేకుండా.

ఈ స్థాయిలో ఉపయోగపడే మరో రెండు సాధనాలు ఉన్నాయి. ప్రతి server పై tmux ఉపయోగిస్తే nohup భర్తీ అవుతుంది. Wi-Fi disconnect అయినప్పుడు పని కోల్పోకుండా ఉంటుంది. “నేను laptop మూసివేయలేను; migration నడుస్తోంది” అనే పరిస్థితి కూడా ఉండదు. అమలు ఖర్చు sudo apt install -y tmux, రెండు నిమిషాలు. అదనంగా tmux new -s work మరియు tmux attach -t work ఉపయోగించే అలవాటు రావాలి. సమస్య nesting. tmux లోపల మరో tmux నడిపితే మీ prefix key పనిచేయకుండా పోతుంది. కాబట్టి tmux ను server పై లేదా laptop పై మాత్రమే నడపాలి; రెండింటిపైనా కాదు. ఎక్కువసేపు నడిచే agent sessions ను ఉపయోగిస్తే ఇది మరింత ముఖ్యమైనది. VPS పై tmux లో Claude Code నడపడంలో ఉన్న విధానమే ఇక్కడ కూడా ఉంటుంది. Session, SSH connection కంటే ఎక్కువ కాలం కొనసాగాలి.

Shared alias file ప్రతి box పై మీకు ఇష్టమైన పన్నెండు one-liners ను మళ్లీ టైప్ చేయాల్సిన అవసరాన్ని తొలగిస్తుంది. ఒక .bash_aliases ను git repo లో ఉంచి ప్రతి server పైకి pull చేయండి. సమస్య ఏమిటంటే, repo లో కాకుండా ఒక server పై నేరుగా edit చేసిన వెంటనే అది ఇతర చోట్ల నుంచి వేరుపడుతుంది. తదుపరి tier ఎందుకు అవసరమో మీరు మొదటిసారి గ్రహించేది కూడా ఇక్కడే.

5 నుంచి 20 servers: configuration as code, లేకపోతే drift గెలుస్తుంది

ఐదు servers దాటిన తర్వాత, “ప్రతి box పై విడిగా చేస్తాను” అనేది పద్ధతి కాదు; మీరే మీకు చెప్పుకునే అబద్ధంగా మారుతుంది. ఈ స్థాయి tools అన్నీ ఒకే సమస్యను ఎదుర్కొంటాయి: drift.

Ansible hostnameలపై shell loop ను, మూడు దశలు పాతబడిన “new server setup” అనే wiki పేజీని, web3 కి fix చేరిందో లేదో తెలియకపోవడం వల్ల కలిగే ఆందోళనను భర్తీ చేస్తుంది. Setup cost: మొదట పనిచేసే playbook సిద్ధం చేయడానికి 30 minutes, మీ laptop లేదా management box పై sudo apt install -y ansible (apt మీకు పాత Ansible release ను ఇస్తుంది; ఇక్కడి అవసరాలన్నింటికీ అది సరిపోతుంది. Tutorialలోని pipx విధానం ప్రస్తుత versions ను ఇస్తుంది), servers పై agents అవసరం లేదు, మీరు ఇప్పటికే సిద్ధం చేసిన SSH config ద్వారా అన్నీ నడుస్తాయి. ఈ పేజీలో ఇది ఒక్కటే అతిపెద్ద మెరుగుదల. పూర్తి విధానం Ansible మొదటి 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 ను ఉపయోగిస్తుంది కాబట్టి, గత section లో మీరు రాసిన ~/.ssh/config ఇప్పటికే వర్తిస్తుంది. web1 వంటి bare names తో inventory రాస్తే vars ఏవీ లేకుండానే పనిచేస్తుంది. పై vars inventory ని self-contained గా మారుస్తాయి. మీరు దాన్ని మీ laptop కాని machine నుంచి నడిపే రోజున ఇది ఉపయోగపడుతుంది.

దీన్ని ansible all -i inventory.ini -m ping తో test చేయండి. సరైన ఫలితంలో ప్రతి host కోసం "ping": "pong" ఆకుపచ్చ రంగులో ముద్రించబడుతుంది. మీరు మొదట ఎదుర్కొనే failure ఇలా ఉంటుంది:

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 ను సరిచేయండి. దాని కింద ఉన్న layer ఎంత ఆరోగ్యంగా ఉంటే Ansible కూడా అంతే ఆరోగ్యంగా ఉంటుంది. మరో ముఖ్యమైన విషయం: Ansible కు మీ machine పై Python అవసరం. ping సహా దాదాపు ప్రతి module కు server పై కూడా Python అవసరం. అందువల్ల నిజంగా minimal image /usr/bin/python3: not found కు సమాధానం ఇవ్వవచ్చు. ఒక apt install python3 చేస్తే ఆ సమస్య మళ్లీ ఎదురుకాదు. మొత్తం fleet లోని bare images కోసం, remote పై Python అవసరం లేని కొద్దిమంది modules లో ఒకటైన raw module ఆ installation ను మీ తరఫున చేయగలదు.

unattended-upgrades N servers కు security patches వర్తింపజేసే వ్యక్తిగా మీ స్థానాన్ని భర్తీ చేస్తుంది. Stock Ubuntu Server 24.04 లో ఇది ముందుగానే install అయి ఉంటుంది. సాధారణంగా security updates కోసం ఇప్పటికే enable అయి ఉంటుంది. కాబట్టి ఇక్కడ చేయాల్సింది install చేయడం కాదు, verify చేయడం:

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

రెండు lines కూడా "1" తో ముగియాలి. కొన్ని minimal మరియు cloud images లో ఇది off అయి ఉంటుంది. మీ image లో అలా ఉంటే sudo dpkg-reconfigure -plow unattended-upgrades ఆ file ను మళ్లీ రాస్తుంది. Setup cost: ప్రతి server కు check చేయడానికి రెండు minutes, లేదా అన్నింటికీ ఒక Ansible task. ముఖ్యమైన విషయం: default గా ఇది ఎప్పుడూ reboot చేయదు. అందువల్ల kernel security updates మీరు reboot చేసే వరకు పూర్తిగా అమలుకావు. Automatic reboots, ఏ updates apply చేయాలో ఎంచుకోవడం, logs చదవడం గురించి ప్రత్యేక unattended-upgrades guide లో వివరాలు ఉన్నాయి.

Centralized monitoring గురించి customer ద్వారా తెలుసుకునే పరిస్థితిని భర్తీ చేస్తుంది. అది ఇప్పటివరకు రూపొందించిన అత్యంత ఖరీదైన monitoring system. రెండు tools కు ఒక్కొక్కటి ఉపయోగించే సందర్భం ఇలా ఉంటుంది: Uptime Kuma “ఇది పనిచేస్తుందా?” అనే ప్రశ్నకు సమాధానం ఇస్తుంది. HTTP, TCP, ping checks చేసి ఏదైనా alert destination కు alerts పంపుతుంది. Docker లో దీనిని పది minutes లో అమర్చవచ్చు. Zabbix “ఇది త్వరలో విఫలమవుతుందా?” అనే ప్రశ్నకు సమాధానం ఇస్తుంది. ప్రతి host పై agent ద్వారా disk, memory, CPU trends ను చూపిస్తుంది. దీన్ని సరిగ్గా అమర్చడానికి ఒక మధ్యాహ్నం పడుతుంది. Kuma తో ప్రారంభించండి. “up but degraded” పరిస్థితి మీకు ఖర్చు కలిగించడం ప్రారంభించినప్పుడు Zabbix ను జోడించండి. రెండింటికీ ముఖ్యమైన సమస్య placement. అది కింద ఉన్న mistakes section కు దారితీసేంత ముఖ్యమైనది.

అవసరమైతే మాత్రమే web panel. Webmin Ubuntu లో settings ఎక్కడ ఉంటాయో గుర్తుంచుకోవాల్సిన అవసరాన్ని భర్తీ చేస్తుంది. విభిన్న నైపుణ్యాలున్న team కు లేదా సంవత్సరానికి రెండుసార్లు మాత్రమే మీరు ఉపయోగించే server కు ఇది నిజంగా ఉపయోగకరం. Setup కు పది minutes పడుతుంది. అయితే ఇది root-equivalent web application. ఇది port 10000 పై listen చేస్తుంది. Internet దీనిని నిరంతరం scan చేస్తుంది. దీన్ని ఉపయోగిస్తే localhost లేదా VPN address కు bind చేయండి. Public interface పై 0.0.0.0 కు ఎప్పుడూ bind చేయవద్దు. SSH నెమ్మదిగా అనిపిస్తుందని panel ను ఉపయోగించాలనిపిస్తే, ముందరి section ను మళ్లీ చదవండి. Configured ~/.ssh/config మరియు Ansible కలిపి ఏ panel కంటే వేగంగా ఉంటాయి.

20+ సర్వర్లు: ఈ గైడ్ నిజాయితీగా ముగిసే స్థానం

20 కంటే ఎక్కువ సర్వర్ల వద్ద మీరు ఒక fleet ను నిర్వహిస్తున్నారు. ఈ దశలో toolchain రూపం మారుతుంది: సర్వర్లను reproducible గా ఉంచడానికి Terraform లేదా OpenTofu, సర్వర్‌ను మరమ్మతు చేయదగినదిగా కాకుండా అవసరమైతే తొలగించి మళ్లీ సృష్టించదగినదిగా చేయడానికి cloud-init లేదా golden images, laptop నుంచి push చేయడం scale కాకపోవడంతో మీ Ansible ను అమలు చేయడానికి pull-based configuration లేదా CI pipelines, అలాగే సరైన secrets management అవసరం. Ansible 20 సర్వర్ల వద్దనే విఫలం కాదు; అనేక సంస్థలు దీన్ని వందలాది nodes పై అమలు చేస్తున్నాయి. అయితే దాని చుట్టూ ఉన్న విధానాలు మరింత కఠినంగా ఉండాలి. అది ఈ సైట్ రాసే ఈ వ్యాసానికి భిన్నమైన విషయం. మీరు ఆ స్థాయిలో ఉంటే, కింది విభాగం మీకూ వర్తిస్తుంది. ఎందుకంటే inventory, keys, access discipline వంటివి fleet tooling మీ వద్ద ముందుగానే ఉన్నాయని భావించే ప్రాథమిక అంశాలు.

ఎవరూ రాయనిది అయిన పొర

నాలుగు పద్ధతులు ఏ పరిమాణంలోని fleet‌కైనా వర్తిస్తాయి. వీటిని వదిలేయడం వల్ల server‌ల సంఖ్య వాస్తవానికి మించిన భారంగా అనిపిస్తుంది.

ఒక inventory file, text file అయినా సరే. మీ వద్ద మూడు server‌లు ఉన్న వెంటనే వాటి name, IP, provider, వాటిపై ఏమి నడుస్తోంది, అవి ఎందుకు ఉన్నాయి అనే వివరాలను రాయండి. git repoలోని ఒక servers.md సరిపోతుంది; పైభాగంలోని Ansible inventory మరింత మంచిది, ఎందుకంటే అది executable documentation. ఇది భర్తీ చేసేది: తెల్లవారుజామున 2 గంటలకు వచ్చే “ఒక్క నిమిషం, 10.0.0.40 అంటే ఏమిటి?” అనే ప్రశ్న. Setup cost: పది నిమిషాలు. జాగ్రత్త: server సృష్టించడం మరియు ఆ line‌ను జోడించడం ఒకేసారి జరగాలి. వాటిని ఎప్పుడూ రెండు వేర్వేరు పనులుగా చేయకపోతేనే ఇది పనిచేస్తుంది.

Key hygiene: ఇప్పుడే rotation చేయండి; అవసరం వచ్చినప్పుడు SSH CA వాడండి. మీ keys ఎక్కడ ఉన్నాయో జాబితా చేయండి (మీ వైపు cat ~/.ssh/*.pub, ప్రతి server వైపు ~/.ssh/authorized_keys). పాత laptops మరియు మాజీ సహచరుల keys తొలగించండి. ఒక key ఎంతకాలం పాతదో, అది ఎక్కడ ఉపయోగించబడిందో మీకు చెప్పలేని స్థితిలో ఉంటే దాన్ని rotate చేయండి. Static keys బదులుగా తక్కువ కాలం చెల్లే signed certificates ఇచ్చే SSH certificate authority అనేది పరిపక్వమైన పరిష్కారం. అయితే పది server‌ల కంటే తక్కువ ఉన్నప్పుడు, Ansible ద్వారా క్రమబద్ధమైన authorized_keys management అమలు చేస్తే, ఆ ప్రక్రియలోని 10% క్రమబద్ధతతో 90% ప్రయోజనం పొందవచ్చనేది నిజాయితీగల సలహా.

లోపలికి ఒకే మార్గం ఉండాలి, ఇరవై కాదు. ప్రతి public SSH port attack surface‌ను N రెట్లు పెంచుతుంది. పెద్ద స్థాయిలో కూడా పనిచేసే విధానం: ఒక bastion host, లేదా ఇంకా మంచిది, మీరు నియంత్రించే VPSలో WireGuard VPN, మరియు మిగిలిన ప్రతి server‌కి SSH‌ను దాని private address‌కు మాత్రమే bind చేయడం. పై configలోని ProxyJump lines ఇప్పటికే ఈ నిర్మాణాన్ని ఆధారంగా తీసుకుంటున్నాయి. తప్పనిసరిగా publicగా ఉండాల్సిన వాటికి సాధారణంగా fail2ban అమలు చేయండి. Setup cost: ఒక్కసారి ఒక గంట. జాగ్రత్త: port 22ను ప్రతిచోటా మూసే ముందు fallback పనిచేస్తుందో నిర్ధారించండి. అంటే provider console access‌ను పరీక్షించండి. మూసిన తర్వాత పరీక్షించకండి.

Restore చేసి పరీక్షించిన backups. పరీక్షించని backup ఒక ఊహ మాత్రమే. మీరు ఏ mechanism వాడినా, provider snapshots, restic, రెండో boxకు rsync, నిజంగా ముఖ్యమైనది calendar entry. ఆ entryలో ఒక server‌ను కొత్త VPSపై restore చేసి, అది boot అవుతూ సేవ అందిస్తోందో నిర్ధారించాలి. పదిహేను సంవత్సరాల hosting అనుభవంలో నేను విన్న ప్రతి backup విషాదకథలో “మా వద్ద backups ఉన్నాయి” అనే వాక్యం ఉంటుంది.

పొరపాట్లు

అనేక సర్వర్ల స్థాయిలో కనిపించే వైఫల్యాలు సాధనాల వల్ల రావు; అవి అలవాట్ల వల్ల వస్తాయి. దాదాపు అన్నింటికీ నాలుగు అలవాట్లు కారణమవుతాయి.

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

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

పర్యవేక్షిస్తున్న సర్వర్‌పైనే monitoring నిర్వహించడం. Uptime Kuma అది పర్యవేక్షించే సర్వర్‌పైనే నడిస్తే, "అన్నీ down అయ్యాయి" అని చెప్పే alert కూడా down అవుతుంది. అప్పుడు మీరు ప్రపంచంలోని అత్యంత అసమర్థమైన datacenter యొక్క మరింత చిన్న, వినోదాత్మక రూపాన్ని నిర్మించినట్లే. Monitoring వేరు failure domainలో ఉండాలి. వేరే provider వద్ద ఉన్న చవకైన VPS సాధారణ పరిష్కారం. కనీసం, monitoring వ్యవస్థను పర్యవేక్షించే external free-tier check ఉండాలి.

ప్రతిచోటా Root SSH. మొత్తం fleetకు ఒకే shared root key ఉంటే, ఒక laptop లీక్ అయినప్పుడు అన్నింటిపైనా నియంత్రణ లభిస్తుంది. ఎవరు ఏమి చేశారో చూపించే audit trail కూడా ఉండదు. ప్రతి వ్యక్తికి ప్రత్యేక users, sudo, మరియు ప్రతి hostలో /etc/ssh/sshd_config లో PermitRootLogin no ఉండాలి. మళ్లీ చెప్పాలంటే, ఇది ఒక సాయంత్రం చేతితో టైప్ చేయాల్సిన పని కాదు; మూడు పంక్తుల Ansible task చాలు.

Fleet కొద్దిమంది సర్వర్లను దాటినప్పుడు, మీ మొదటి Ansible playbook పునరావృత పనులను స్వయంచాలకంగా నిర్వహిస్తుంది.

FAQ

అనేక Linux servers నిర్వహించడానికి ఉత్తమ ఉచిత సాధనం ఏది?

2 నుంచి 5 servers వరకు, చక్కగా రాసిన ~/.ssh/config మరియు tmux మీరు install చేయగల ఇతర సాధనాలన్నింటికంటే మెరుగ్గా పనిచేస్తాయి. సుమారు 5 servers నుంచి పైకి Ansible ప్రామాణిక ఎంపిక: దీనికి agent అవసరం లేదు, ఇది ఉచితం, మీ వద్ద ఇప్పటికే ఉన్న SSH ద్వారా పనిచేస్తుంది, server setup ను git లోని files గా మార్చుతుంది. up/down alerting కోసం Uptime Kuma ను జోడించండి; ఈ guide లో పేర్కొన్న ప్రతి tool free software.

Ansible లేకుండా అనేక Linux servers నిర్వహించవచ్చా?

అవును, సుమారు 5 servers లోపు ఉంటే మంచి SSH config, shared alias file, మరియు క్రమశిక్షణ సరిపోతాయి. చాలామంది సంవత్సరాల పాటు ఈ విధంగానే నిర్వహిస్తారు. ఆ పరిమితిని దాటిన తర్వాత Ansible కు ప్రత్యామ్నాయం "ఏమీ కాదు" అనేది కాదు; documentation లేని drift అవుతుంది: 18 servers ను ఒక్కొక్కటిగా చేతితో, స్వల్ప తేడాలతో configure చేయడం. Ansible భారంగా అనిపిస్తే, authorized_keys మరియు unattended-upgrades ను మాత్రమే నిర్వహించే ఒక playbook తో ప్రారంభించండి; అది ఒక్కటే నేర్చుకోవడానికి పెట్టిన సమయానికి తగిన ప్రయోజనం ఇస్తుంది.

అనేక Linux servers పై ఒకేసారి అదే command ఎలా నడపాలి?

ansible all -i inventory.ini -a "uptime" స్పష్టమైన పరిష్కారం. దీనికి playbooks అవసరం లేదు; inventory file మాత్రమే అవసరం. పక్కపక్కన interactive పని కోసం, tmux setw synchronize-panes on తో ప్రతి pane కు keystrokes ను broadcast చేయగలదు. అయితే దాన్ని ఒక party trick గానే పరిగణించండి. Production servers కు interactive commands ను broadcast చేయడం వల్ల ఒక typo, N రెట్లు పెద్ద outage గా మారవచ్చు.

Linux servers నిర్వహించడానికి Webmin వంటి control panel అవసరమా?

అవసరం లేదు. ఒక panel చేసే ప్రతిదాన్ని SSH మరియు Ansible మరింత పునరుత్పాదకంగా చేయగలవు. ఒకే boxes ను భిన్న నైపుణ్య స్థాయులు ఉన్న వ్యక్తులు administer చేసినప్పుడు, లేదా server ను చాలా అరుదుగా తాకడం వల్ల config paths ను మళ్లీ గుర్తించడానికి నిజమైన సమయం ఖర్చవుతున్నప్పుడు Webmin ఉపయోగకరంగా ఉంటుంది. దాన్ని నడిపితే, అది root-equivalent web app అన్నట్లుగా నిర్వహించండి: దాన్ని localhost లేదా VPN address కు bind చేయండి; public interface కు ఎప్పుడూ bind చేయవద్దు.

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

చేతితో administration చేస్తే, 10 కంటే తక్కువ వద్దే నాణ్యత తగ్గుతుంది. config as code, automated patching, మరియు centralized monitoring ఉంటే, జాగ్రత్తగా పనిచేసే ఒక వ్యక్తి part-time job గా 20 నుంచి 50 servers నిర్వహించగలరు. పరిమితి routine care కాదు; కొత్తగా ఏదైనా విఫలమయ్యే తరచుదనం. ముఖ్యమైన సంఖ్య ప్రతి admin కు ఉన్న servers సంఖ్య కాదు; ప్రతి admin కు ఉన్న snowflakes సంఖ్య. దాన్ని దాదాపు సున్నాకు దగ్గరగా ఉంచితే పరిమితి ఎక్కువగా ఉంటుంది.