Jinsi ya kusimamia seva nyingi za Linux kwa ufanisi

Unachojenga

Hujengi zana moja, bali stack fupi, inayochaguliwa kulingana na idadi halisi ya seva ulizonazo. Nambari hiyo ndiyo ingizo pekee la maana, na ndilo jambo ambalo kila muhtasari wa "zana za usimamizi wa seva za Linux" hupuuza. Kosa la kawaida ni kutumia suluhisho la seva 200 kwa VPS nne na kutumia mwezi mzima kuhudumia zana hiyo badala ya seva zenyewe. Kosa la pili la kawaida ni mtu mwenye seva kumi na nane bado kuingia kwenye kila moja kupitia SSH kwa mikono, akitumia mabadiliko "yale yale" kwa njia kumi na nane tofauti kidogo.

Kwa hivyo, mwongozo huu umepangwa kulingana na ukubwa wa kundi la seva: seva 2 hadi 5, 5 hadi 20, na zaidi ya 20, pamoja na safu mtambuka inayotumika kwa kila ukubwa na ambayo hakuna anayeandika: orodha ya mali (inventory), usafi wa funguo (key hygiene), njia moja ya kuingia, na backups ambazo umewahi kuzirejesha kikweli. Kwa kila zana unapata mambo matatu: inachochukua nafasi yake, gharama ya usanidi kwa dakika, na changamoto moja inayoweza kukukwamisha. Nimeendesha host ya VPS kwa miaka kumi na mitano; orodha iliyo hapa chini ni ile inayoweza kuhimili hitilafu ya saa 8 usiku, si ile inayovutia kwenye maonyesho tu.

Mahitaji ya awali na tahadhari za kweli

Unahitaji SSH inayotumia funguo (key-based SSH) kufanya kazi kwenye kila seva (kama bado unaandika nywila, rekebisha hilo kwanza; inachukua dakika kumi na kila kitu hapa chini kinategemea funguo), mtumiaji mwenye sudo ambaye si root, na seva zinazoendesha mfumo wa kisasa. Amri hapa zinadhani unatumia Ubuntu 24.04, lakini hakuna kitu maalum kwa Ubuntu isipokuwa apt.

Maonyo mawili ya kweli kabla ya zana. Kwanza, kuongezeka kwa zana ni tatizo la usimamizi lenyewe: kila wakala (agent) unaosakinisha ni daemon nyingine ya kuifanyia patching kwenye kila mashine, kwa hivyo kigezo cha kuongeza moja kinapaswa kuwa "hii inachukua nafasi ya kazi ya mikono niliyofanya wiki hii," si "hii inaonekana kuwa muhimu." Pili, kila kitu hapa ni programu huru na gharama halisi ni muda wa usanidi, ndiyo maana kila zana ina makadirio ya muda katika dakika; makadirio yanaposema mchana mzima, yaamini.

Seva 2 hadi 5: ~/.ssh/config ni zana inayopuuzwa zaidi uliyonayo

Inachukua nafasi ya: faili ya maandishi ya anwani za IP, kutafuta historia ya shell (ssh 203.0 kisha Ctrl-R na kuomba iwe sawa), na kuandika -p 2222 -i ~/.ssh/other_key kila mara. Gharama ya usanidi: dakika 15, mara moja. Changamoto: soketi za multiplexing zilizopitwa na wakati, zilizoelezewa hapa chini.

Kwa ukubwa huu huhitaji programu nyingine; unahitaji mteja (client) uliyenaye tayari ambaye umemusanidi kwa umakini. ~/.ssh/config hubadilisha kila seva kuwa jina la neno moja na kusimba njia ya mawasiliano ili usiwahi kuifikiria tena:

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

Mipangilio mitatu hufanya kazi hiyo. ProxyJump huelekeza miunganisho kupitia bastion kwa hatua moja, kwa hivyo ssh db1 kutoka kwenye mkahawa hupita kwa uwazi kupitia bastion, bila agent forwarding, bila incantations za ProxyCommand, na seva za kibinafsi hazihitaji kamwe port za SSH za umma (zaidi kuhusu hili katika sehemu ya cross-cutting). ControlMaster auto pamoja na ControlPersist hufanya multiplexing ya miunganisho kupitia session moja ya TCP, kwa hivyo ya pili na kila ssh, scp, au rsync inayofuata kwa host hiyohiyo huunganisha papo hapo badala ya kufanya mazungumzo upya, tofauti inayokuwa kubwa wakati Ansible inapoingia. Na kwa sababu scp, rsync, na Ansible zote husoma faili hili hilohilo, kila jina unalofafanua hapa hufanya kazi kila mahali.

Changamoto: muunganisho mkuu (master connection) unaweza kudumu zaidi ya matumizi yake, na njia mbili za kufeli huonekana tofauti. Seva inapowaka upya au Wi-Fi yako inapokatika, mchakato mkuu hubaki umeshikilia session ya TCP iliyokufa ambayo haijaitambua bado, na ssh web1 inayofuata hukwama kimya kimya kwenye soketi isiyoelekea popote. Kando na hilo, sshd huweka kikomo cha session 10 kwa kila muunganisho (MaxSessions katika sshd_config), kwa hivyo session ya kumi na moja ya multiplexed kwa host moja huchapisha:

mux_client_request_session: session request failed: Session open refused

Zote zina suluhisho moja: ssh -O exit web1 huua master, na muunganisho unaofuata huanza mpya. Unaweza pia kuona ControlSocket ~/.ssh/cm-matt@web1-22 already exists, disabling multiplexing mara kwa mara, hiyo haina madhara: session mbili zilishindana, na muunganisho bado unafanya kazi, bila multiplexing tu.

Wenzake wawili kwa ukubwa huu. tmux kwenye kila seva huchukua nafasi ya nohup, kazi inayopotea Wi-Fi inapokatika, na "Siwezi kufunga laptop yangu, migration inaendelea." Gharama ya usanidi: sudo apt install -y tmux, dakika mbili, pamoja na mazoea ya misuli ya tmux new -s work na tmux attach -t work. Changamoto ni nesting: tmux ndani ya tmux humeza prefix key yako, kwa hivyo iendeshe kwenye seva au kwenye laptop, si zote mbili. Ikiwa unaendesha session za agent za muda mrefu hii ni muhimu mara mbili, ni muundo uleule kama kuendesha Claude Code kwenye tmux kwenye VPS, ambapo session lazima idumu zaidi ya muunganisho wa SSH.

Faili ya alias iliyoshirikiwa huchukua nafasi ya kuandika upya mistari yako kumi na mbili unayopenda kwenye kila kisanduku. Weka .bash_aliases kwenye git repo na uivute kwenye kila seva. Changamoto: hupoteza mwelekeo pale unapoihariri moja kwa moja kwenye seva moja badala ya kwenye repo, ambayo pia ni ladha yako ya kwanza ya kwa nini ngazi inayofuata ipo.

Seva 5 hadi 20: config as code, au drift itashinda

Ukivuka seva tano, mbinu ya "nitafanya kila kitu kwenye kila seva" inakuwa si mbinu tena, bali ni uongo unaojidanganya. Zana katika ngazi hii zote zinapambana na adui mmoja: drift.

Ansible inachukua nafasi ya shell loop juu ya hostnames, ukurasa wa wiki wenye kichwa "usanidi wa seva mpya" ambao umepitwa na wakati, na wasiwasi wa kutojua kama web3 ilipata marekebisho hayo. Gharama ya kuanzisha: dakika 30 hadi kupata playbook ya kwanza inayofanya kazi, sudo apt install -y ansible kwenye laptop yako au seva ya usimamizi (apt inakupa toleo la zamani la Ansible, ambalo linafaa kwa kila kitu hapa; njia ya pipx katika mafunzo haya inakupa matoleo ya sasa), hakuna agents kwenye seva, kila kitu kinafanya kazi juu ya SSH config uliyojenga tayari. Hii ndiyo upgrade kubwa zaidi kwenye ukurasa huu, na mwongozo kamili uko katika mafunzo ya Ansible first-playbook; hapa kuna muundo wa inventory unaoifanya ifanye kazi:

[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'

Kwa sababu Ansible inatumia binary ya OpenSSH, ~/.ssh/config uliyoandika katika sehemu iliyopita inatumika tayari, inventory ya majina matupu kama web1 ingefanya kazi bila vars yoyote. Vars zilizo hapo juu zinafanya inventory iweze kujitosheleza, jambo linalolipa siku utakapoiendesha kutoka kwenye mashine ambayo si laptop yako.

Ijaribu kwa ansible all -i inventory.ini -m ping; matokeo sahihi huchapisha "ping": "pong" kwa kila host, kwa rangi ya kijani. Hitilafu utakayokutana nayo kwanza inaonekana hivi:

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

Hiyo si tatizo la Ansible, ssh matt@10.8.0.11 pekee inafeli kwa njia hiyo hiyo. Rekebisha SSH kwanza, daima; Ansible ina afya sawa na safu iliyo chini yake. Jambo moja la kuzingatia zaidi ya hilo: Ansible inahitaji Python pande zote mbili, kwa hivyo image ndogo sana inaweza kujibu /usr/bin/python3: not found, moja apt install python3 na haitakusumbua tena.

unattended-upgrades inachukua nafasi yako kama mtu anayeweka security patches kwenye seva N. Ubuntu Server 24.04 ya kawaida inakuja ikiwa imesakinishwa na kwa kawaida imewezeshwa kwa ajili ya usalama, kwa hivyo kazi hapa ni kuthibitisha, si kusakinisha:

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

Mistari yote miwili inapaswa kuishia na "1". Baadhi ya images ndogo na za wingu huja zikiwa zimezimwa, na sudo dpkg-reconfigure -plow unattended-upgrades inabadilisha faili hiyo ikiwa yako ilikuwa hivyo. Gharama ya kuanzisha: dakika mbili za kukagua kwa kila seva, au task moja ya Ansible kwa zote. Jambo la kuzingatia: kwa default haifanyi reboot, kwa hivyo security updates za kernel hubaki nusu-zimesakinishwa hadi utakapofanya hivyo, mwongozo maalum wa unattended-upgrades unashughulikia automatic reboots, kuchagua kile kinachopaswa kupachikwa, na kusoma logs zake.

Centralized monitoring inachukua nafasi ya kugundua tatizo kutoka kwa mteja, ambayo ndiyo mfumo wa ufuatiliaji wa gharama kubwa zaidi uliowahi kubuniwa. Zana mbili, mstari mmoja kila moja kuhusu lini: Uptime Kuma inajibu "je, inafanya kazi?", HTTP, TCP, na ping checks zenye alerts kwa kila kitu, na inachukua dakika kumi kwenye Docker; Zabbix inajibu "je, inakaribia kuanguka?", mwenendo wa disk, memory, na CPU kupitia agent kwenye kila host, na kwa kweli inachukua mchana mzima. Anza na Kuma; ongeza Zabbix wakati "inafanya kazi lakini kwa shida" inapoanza kukugharimu pesa. Jambo la kuzingatia kwa zote mbili ni mahali pa kuiweka, na ni muhimu kiasi kwamba inaongoza sehemu ya makosa hapa chini.

Web panel, ikiwa ni lazima tu. Webmin inachukua nafasi ya kukumbuka mahali Ubuntu inapoweka vitu, na kwa timu yenye ujuzi mchanganyiko au seva unayoigusa mara mbili kwa mwaka ni muhimu kihalali; usanidi ni dakika kumi. Jambo la kuzingatia ni kwamba ni web application yenye mamlaka ya root inayofungua mlango 10000, na mtandao huichanganua kila mara. Ikiwa utaiendesha, ifunge kwenye localhost au anwani ya VPN, kamwe usiiweke kwenye 0.0.0.0 kwenye interface ya umma. Na ikiwa unatafuta panel kwa sababu SSH inahisi polepole, soma tena sehemu iliyopita kwanza; ~/.ssh/config pamoja na Ansible ni haraka kuliko panel yoyote ikishasanidiwa.

Seva 20+: mahali mwongozo huu unapofikia mwisho wake

Unapokuwa na seva zaidi ya ishirini, unaendesha kundi la seva (fleet), na mfumo wa zana hubadilika: unahitaji Terraform au OpenTofu ili seva zenyewe ziweze kuzalishwa upya, cloud-init au golden images ili seva iwe ya kutupwa badala ya kurekebishika, usanidi wa kuvuta (pull-based configuration) au CI pipelines zinazoendesha Ansible yako kwa sababu kusukuma usanidi kutoka kwenye laptop hakutoshelezi tena, na usimamizi halisi wa siri (secrets management). Ansible yenyewe haishindwi kufanya kazi kwenye seva ishirini; kampuni nyingi huiendesha kwenye mamia ya node, lakini mbinu zinazozunguka matumizi yake lazima ziimarishwe, na hilo ni somo tofauti na lile linaloandikwa kwenye tovuti hii. Ikiwa uko kwenye kiwango hicho cha ukubwa, sehemu iliyo hapa chini bado ni yako, kwa sababu hesabu ya seva (inventory), funguo (keys), na nidhamu ya ufikiaji ndiyo mambo ambayo zana za kusimamia kundi la seva huchukulia kuwa tayari unayo.

Safu ambayo hakuna anayeiandika

Kuna mbinu nne zinazotumika kwa kila ukubwa wa kundi la seva, na kuziruka ndiyo sababu inayofanya idadi ya seva ionekane nzito kuliko ilivyo.

Faili la orodha ya mali, hata kama ni faili la maandishi. Pale unapofikisha seva tatu, andika: jina, IP, mtoa huduma, kinachoendeshwa humo, na sababu ya kuwepo kwake. servers.md kwenye git repo inafaa; orodha ya Ansible iliyo hapo juu ni bora zaidi kwa sababu ni nyaraka inayoweza kutekelezwa. Inachokibadilisha: swali la saa 8 usiku "subiri, 10.0.0.40 ni nini?" Gharama ya usanidi: dakika kumi. Mtego: inafanya kazi tu ikiwa kuunda seva na kuongeza mstari huo ni tendo moja, kamwe si mawili.

Usafi wa funguo: zungusha sasa, tumia SSH CA wakati mambo yanapokuwa magumu. Orodhesha mahali funguo zako zilipo (cat ~/.ssh/*.pub upande wako, ~/.ssh/authorized_keys upande wa kila seva), ondoa laptop za zamani na wafanyakazi wa zamani, na zungusha (rotate) chochote kilicho na umri mrefu kiasi kwamba huwezi kusema kimekuwa wapi. Mamlaka ya vyeti vya SSH (SSH certificate authority), yaani vyeti vilivyotiwa saini vya muda mfupi badala ya funguo tuli, ndiyo jibu la kitaalamu, lakini ushauri wa kweli ni kwamba chini ya seva kumi, usimamizi wa nidhamu wa authorized_keys kupitia Ansible hukupa 90% ya faida kwa 10% ya juhudi.

Njia moja ya kuingia, si ishirini. Kila port ya SSH iliyo wazi kwa umma ni sehemu ya kushambuliwa iliyozidishwa kwa N. Mfumo unaokua: bastion host moja, au bora zaidi, WireGuard VPN kwenye VPS unayoimiliki, na SSH ya kila seva nyingine ifungwe kwenye anwani yake ya ndani pekee. Mistari ya ProxyJump katika usanidi hapo juu tayari inadhani mfumo huu. Chochote kinachopaswa kubaki wazi kwa umma lazima kiwe na fail2ban kama utaratibu wa kawaida. Gharama ya usanidi: saa moja, mara moja. Mtego: thibitisha kuwa njia yako ya dharura (console access ya mtoa huduma) inafanya kazi kabla ya kufunga port 22 kila mahali, si baada ya hapo.

Backup zilizojaribiwa kwa kurejesha data. Backup isiyojaribiwa ni nadharia tu. Mbinu yoyote unayotumia, snapshots za mtoa huduma, restic, rsync kwenda kwenye seva ya pili, zana muhimu zaidi ni ile ya kwenye kalenda ambapo unarejesha seva moja kwenye VPS mpya na kuthibitisha kuwa inawaka na kutoa huduma. Kila hadithi ya kutisha kuhusu backup niliyoisikia katika miaka kumi na mitano ya hosting ina maneno "tulikuwa na backup."

Makosa

Njia za kufeli katika kiwango cha seva nyingi si hitilafu za zana; ni mazoea. Makosa manne kati ya hayo husababisha karibu kila kitu.

Seva za Snowflake. Kila seva ilisanidiwa kwa mkono, ina tofauti ndogo, na hakuna anayeweza kuijenga upya. Unagundua hili wakati diski inapofeli. Dawa yake ni ya kawaida: kila mabadiliko lazima yapitie Ansible, au angalau yaongezwe kwenye sehemu ya hati ya orodha (inventory) ya seva hiyo, na seva yoyote ambayo huwezi kuijenga upya kutoka kwenye madokezo mchana huu ni deni la kiufundi (technical debt) ambalo una tarehe ya mwisho ya kulilipa ambayo huchagui wewe.

Matundu ya firewall ya "muda mfupi". ufw allow 5432 ili kutatua tatizo fulani, na miezi kumi na minane baadaye Postgres bado iko kwenye Internet. Fanya ukaguzi na sudo ufw status numbered kwenye kila seva, au kwa mara moja, ansible all -i inventory.ini -a "ufw status numbered" --become, na ufute chochote ambacho huwezi kutaja sababu yake ya sasa. Ikiwa sheria ni ya muda mfupi kweli, ufw delete inayolingana na hiyo lazima iingizwe kwenye dirisha lilelile la tmux kabla ya kulifunga.

Ufuatiliaji (monitoring) uliopangishwa kwenye seva inayofuatiliwa. Ikiwa Uptime Kuma inaendeshwa kwenye seva yenyewe inayoiangalia, tahadhari inayosema "kila kitu kimefeli" nayo pia itakuwa imefeli, na utakuwa umejenga toleo dogo na la kuchekesha la kituo cha data kisichofaa zaidi duniani. Ufuatiliaji lazima uwe katika kikoa kingine cha kufeli (failure domain): VPS ya bei nafuu kutoka kwa mtoa huduma mwingine ndiyo jibu la kawaida, au angalau ukaguzi wa nje wa kiwango cha bure unaoangalia mfuatiliaji.

Root SSH kila mahali. Ufunguo mmoja wa root unaoshirikiwa kwenye kundi zima la seva unamaanisha kuwa laptop moja iliyoibiwa inamiliki kila kitu, na hakuna kumbukumbu ya ukaguzi inayosema nani alifanya nini. Tumia watumiaji wa kila mtu, sudo, na PermitRootLogin no katika /etc/ssh/sshd_config kwenye kila seva, ambayo, kwa mara nyingine tena, ni kazi ya mistari mitatu ya Ansible badala ya kutumia jioni nzima kuandika.

Wakati kundi la seva linapozidi idadi ndogo, playbook yako ya kwanza ya Ansible hufanya sehemu za kurudiarudia kuwa za kiotomatiki.

FAQ

Ni zana gani bora ya bure ya kusimamia seva nyingi za Linux?

Kwa seva 2 hadi 5, ~/.ssh/config iliyoandikwa vizuri pamoja na tmux inashinda chochote unachoweza kusakinisha. Kuanzia seva tano na kuendelea, Ansible ndiyo jibu la kawaida: haina wakala, ni bure, inafanya kazi kupitia SSH uliyonayo tayari, na inageuza usanidi wa seva kuwa faili ndani ya git. Ongeza Uptime Kuma kwa ajili ya tahadhari za up/down; kila zana iliyotajwa katika mwongozo huu ni programu huru.

Je, ninaweza kusimamia seva nyingi za Linux bila Ansible?

Ndiyo, chini ya seva tano, usanidi mzuri wa SSH, faili ya alias iliyoshirikiwa, na nidhamu vinatosha, na watu wengi wamefanya kazi hivyo kwa miaka mingi. Zaidi ya hapo, mbadala wa Ansible si "kutotumia chochote," bali ni mtawanyiko usio na nyaraka: seva kumi na nane ambazo kila moja imesanidiwa kwa mikono kwa njia tofauti kidogo. Ikiwa Ansible inaonekana nzito, anza na playbook moja inayoshughulikia authorized_keys na unattended-upgrades pekee; hilo pekee litalipa gharama ya kujifunza.

Ninawezaje kuendesha amri ileile kwenye seva nyingi za Linux kwa wakati mmoja?

ansible all -i inventory.ini -a "uptime" ndiyo jibu safi na haihitaji playbooks, inahitaji tu faili ya inventory. Kwa kazi shirikishi za kando-kando, tmux inaweza kutangaza mibofyo ya vitufe kwa kila pane kwa kutumia setw synchronize-panes on, lakini ichukulie hiyo kama mbinu ya maonyesho tu, kwa sababu kutangaza amri shirikishi kwenye seva za uzalishaji ndiyo njia ambayo kosa moja la kuandika linageuka kuwa hitilafu mara N.

Je, ninahitaji jopo la kudhibiti kama Webmin ili kusimamia seva za Linux?

Hauhitaji, kila kitu kinachofanywa na jopo, SSH na Ansible hufanya kwa njia inayoweza kurudiwa zaidi. Webmin inafaa pale ambapo watu wenye viwango tofauti vya ujuzi wanasimamia seva zilezile, au unapogusa seva mara chache kiasi kwamba kukumbuka njia za usanidi kunapoteza muda mwingi. Ikiwa unatumia moja, ichukulie kama programu ya wavuti yenye mamlaka ya root: iunganishe kwenye localhost au anwani ya VPN, kamwe usiunganishe kwenye interface ya umma.

Mtu mmoja anaweza kusimamia seva ngapi za Linux kwa uhalisia?

Kwa usimamizi wa mikono, ubora hupungua chini ya kumi. Kwa usanidi kama msimbo (config as code), uwekaji viraka otomatiki, na ufuatiliaji wa kati, mtu mmoja makini anaweza kuendesha seva 20 hadi 50 kama kazi ya muda; kikwazo huwa ni mara ngapi kitu kipya kinaharibika, si utunzaji wa kawaida. Namba inayojalisha si seva kwa kila msimamizi bali ni seva za kipekee (snowflakes) kwa kila msimamizi: iweke hiyo karibu na sifuri na uwezo wa kusimamia utakuwa mkubwa.