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 servers: మీ వద్ద ఇప్పటికే ఉన్న, అత్యంత తక్కువగా ఉపయోగించే సాధనం ~/.ssh/config

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

ఈ పరిమాణంలో మీకు ప్రత్యేక software అవసరం లేదు. మీ వద్ద ఇప్పటికే ఉన్న client ను సరైన విధంగా configure చేయాలి. ~/.ssh/config ప్రతి server ను ఒక పదంతో పిలవగల పేరుగా మార్చి, routing ను encode చేస్తుంది. అందువల్ల మళ్లీ దాని గురించి ఆలోచించాల్సిన అవసరం ఉండదు:

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

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

mux_client_request_session: session request failed: Session open refused

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

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

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

5 నుండి 20 సర్వర్లు: config as code, లేకపోతే drift గెలుస్తుంది

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

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

దీన్ని ansible all -i inventory.ini -m ping తో పరీక్షించండి. సరైన ఫలితంలో ప్రతి 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 కు రెండు చివరల్లోనూ Python అవసరం. అందువల్ల పూర్తిగా minimal image /usr/bin/python3: not found కు సమాధానం ఇవ్వవచ్చు. ఒకసారి apt install python3 చేస్తే, ఈ సమస్య మళ్లీ మీకు ఇబ్బంది కలిగించదు.

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 గా ఉంటుంది. అలా ఉంటే sudo dpkg-reconfigure -plow unattended-upgrades ఆ file ను మళ్లీ రాస్తుంది. Setup ఖర్చు: ప్రతి server కు రెండు నిమిషాల తనిఖీ, లేదా అన్నింటికీ ఒక Ansible task. ముఖ్యమైన విషయం: default గా ఇది ఎప్పుడూ reboot చేయదు. అందువల్ల kernel security updates మీరు reboot చేసే వరకు సగం వరకే వర్తిస్తాయి. unattended-upgrades ప్రత్యేక guide లో automatic reboots, ఏ updates వర్తించాలో ఎంచుకోవడం, దాని logs చదవడం గురించి వివరాలు ఉన్నాయి.

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

Web panel, అవసరమైతే మాత్రమే. Webmin Ubuntu లో settings ఎక్కడ ఉంచుతుందో గుర్తుంచుకోవాల్సిన అవసరాన్ని తొలగిస్తుంది. విభిన్న నైపుణ్యాలు ఉన్న team కు లేదా సంవత్సరానికి రెండుసార్లు మాత్రమే మీరు access చేసే server కు ఇది నిజంగా ఉపయోగకరం. Setup కు పది నిమిషాలు పడుతుంది. అయితే ఇది root కు సమానమైన web application. ఇది port 10000 పై listening చేస్తుంది. Internet నిరంతరం దీనిని scan చేస్తుంది. దీన్ని ఉపయోగిస్తే public interface పై 0.0.0.0 కు ఎప్పుడూ bind చేయవద్దు. localhost లేదా VPN address కు bind చేయండి. SSH నెమ్మదిగా అనిపిస్తున్నందుకు panel ను ఉపయోగించాలనుకుంటే, ముందు previous section ను మళ్లీ చదవండి. configure చేసిన తర్వాత ~/.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 లో పేర్కొన్న ప్రతి సాధనం free software.

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

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

ఒకేసారి అనేక Linux servers పై ఒకే command ఎలా అమలు చేయాలి?

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

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

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

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

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