Cara Urus Banyak Pelayan Linux Mengikut Bilangan

Apa yang anda sedang bina

Bukan satu alat, tetapi satu susunan teknologi (stack) ringkas yang dipilih berdasarkan bilangan pelayan sebenar yang anda miliki. Bilangan itu adalah satu-satunya input yang penting, dan ia merupakan perkara yang diabaikan oleh setiap ulasan "alat pengurusan pelayan Linux". Kesilapan klasik ialah menggunakan penyelesaian untuk 200 pelayan bagi empat VPS, lalu menghabiskan masa sebulan menyelenggara alat tersebut dan bukannya pelayan itu sendiri. Kesilapan klasik kedua ialah individu yang mempunyai lapan belas pelayan masih melakukan SSH ke setiap satu secara manual, dan melaksanakan "perubahan yang sama" dengan lapan belas cara yang sedikit berbeza.

Oleh itu, panduan ini disusun mengikut saiz armada: 2 hingga 5 pelayan, 5 hingga 20, dan melebihi 20, ditambah dengan lapisan merentas yang terpakai pada setiap saiz dan jarang ditulis oleh sesiapa: inventori, kebersihan kunci (key hygiene), satu laluan masuk, dan sandaran yang telah anda uji pemulihannya. Bagi setiap alat, anda akan mendapat tiga perkara: apa yang digantikannya, kos penyediaan dalam minit, dan satu masalah teknikal (gotcha) yang benar-benar memberi kesan. Saya telah mengendalikan hos VPS selama lima belas tahun; senarai di bawah adalah apa yang terbukti berkesan semasa gangguan pada pukul 2 pagi, bukan sekadar apa yang kelihatan bagus dalam demo.

Prasyarat dan peringatan jujur

Anda perlu memastikan akses SSH berasaskan kunci sudah berfungsi ke setiap pelayan (jika anda masih menaip kata laluan, selesaikan perkara itu dahulu; ia hanya mengambil masa sepuluh minit dan semua arahan di bawah mengandaikan penggunaan kunci), pengguna sudo yang bukan root, serta pelayan yang menjalankan sistem operasi terkini. Arahan di sini mengandaikan penggunaan Ubuntu 24.04, namun tiada apa-apa yang khusus untuk Ubuntu kecuali apt.

Dua peringatan jujur sebelum menggunakan alatan ini. Pertama, lambakan alatan merupakan satu masalah pengurusan: setiap ejen yang anda pasang adalah satu lagi daemon yang perlu ditampal (patch) pada setiap mesin, jadi syarat untuk menambah satu alatan baharu mestilah "ini menggantikan kerja manual yang saya lakukan minggu ini," bukan "ini kelihatan berguna." Kedua, semua alatan di sini adalah perisian percuma dan kos sebenar ialah masa penyediaan. Itulah sebabnya setiap alatan disertakan dengan anggaran masa dalam minit; jika anggaran menyatakan satu petang, percayalah.

2 hingga 5 pelayan: ~/.ssh/config ialah alat paling kurang dihargai yang sudah anda miliki

Apa yang digantikannya: fail teks alamat IP, pencarian sejarah shell (ssh 203.0 kemudian Ctrl-R dan berharap), dan menaip -p 2222 -i ~/.ssh/other_key berulang kali. Kos penyediaan: 15 minit, sekali sahaja. Perangkapnya: soket multipleks yang basi, diterangkan di bawah.

Pada skala ini, anda tidak memerlukan perisian tambahan; anda hanya perlu mengkonfigurasi klien yang sedia ada dengan betul. ~/.ssh/config menukar setiap pelayan kepada nama satu perkataan dan mengekodkan penghalaan supaya anda tidak perlu memikirkannya lagi:

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

Tiga tetapan melakukan kerja ini. ProxyJump menghalakan sambungan melalui bastion dalam satu hop, jadi ssh db1 dari kafe akan terowong secara telus melalui bastion, tanpa ejen forwarding, tanpa mantera ProxyCommand, dan pelayan peribadi tidak perlu membuka port SSH awam langsung (maklumat lanjut dalam bahagian rentas fungsi). ControlMaster auto dengan ControlPersist melakukan multipleks sambungan melalui satu sesi TCP, jadi sambungan kedua dan seterusnya menggunakan ssh, scp, atau rsync ke hos yang sama akan bersambung serta-merta tanpa perlu berunding semula, perbezaan yang menjadi ketara apabila Ansible digunakan. Dan kerana scp, rsync, dan Ansible semuanya membaca fail yang sama ini, setiap nama yang anda tentukan di sini akan berfungsi di mana-mana sahaja.

Perangkapnya: sambungan induk boleh bertahan lebih lama daripada kegunaannya, dan dua mod kegagalan kelihatan berbeza. Apabila pelayan but semula atau Wi-Fi anda terputus, proses induk tertinggal dengan sesi TCP mati yang belum disedarinya, dan ssh web1 seterusnya akan tergantung secara senyap pada soket yang tidak menuju ke mana-mana. Secara berasingan, sshd mengehadkan sesi setiap sambungan kepada 10 (MaxSessions dalam sshd_config), jadi sesi multipleks kesebelas ke satu hos akan memaparkan:

mux_client_request_session: session request failed: Session open refused

Kedua-duanya mempunyai penyelesaian yang sama: ssh -O exit web1 mematikan induk, dan sambungan seterusnya akan memulakan sesi baharu. Anda mungkin juga sekali-sekala melihat ControlSocket ~/.ssh/cm-matt@web1-22 already exists, disabling multiplexing, itu tidak berbahaya: dua sesi berlumba, dan sambungan masih berfungsi, cuma tidak dimultiplekskan.

Dua rakan pelengkap pada skala ini. tmux pada setiap pelayan menggantikan nohup, kerja yang hilang apabila Wi-Fi terputus, dan masalah "Saya tidak boleh menutup komputer riba, migrasi sedang berjalan." Kos penyediaan: sudo apt install -y tmux, dua minit, ditambah dengan memori otot tmux new -s work dan tmux attach -t work. Perangkapnya ialah penyarangan (nesting): tmux di dalam tmux akan menelan kekunci awalan anda, jadi jalankan ia sama ada pada pelayan atau komputer riba, bukan kedua-duanya. Jika anda menjalankan sesi ejen yang lama, ini lebih penting; ia adalah corak yang sama seperti menjalankan Claude Code dalam tmux pada VPS, di mana sesi perlu bertahan lebih lama daripada sambungan SSH.

Fail alias kongsi menggantikan kerja menaip semula dua belas baris arahan kegemaran anda pada setiap kotak. Simpan .bash_aliases dalam repositori git dan tarik ia ke setiap pelayan. Perangkapnya: ia akan terpesong sebaik sahaja anda mengeditnya secara terus pada satu pelayan dan bukannya dalam repositori, yang juga merupakan pengalaman pertama anda mengapa peringkat seterusnya wujud.

5 hingga 20 pelayan: konfigurasi sebagai kod, atau drift akan berlaku

Apabila jumlah pelayan melebihi lima, kaedah "saya buat sahaja pada setiap mesin" bukan lagi satu strategi, sebaliknya satu penipuan diri sendiri. Semua alatan pada peringkat ini menyasarkan musuh yang sama: drift (perubahan konfigurasi yang tidak selaras).

Ansible menggantikan gelung shell ke atas nama hos, halaman wiki bertajuk "persediaan pelayan baharu" yang sudah ketinggalan tiga langkah, dan kebimbangan sama ada web3 benar-benar menerima tampalan tersebut. Kos persediaan: 30 minit untuk playbook pertama yang berfungsi, sudo apt install -y ansible pada komputer riba atau pelayan pengurusan anda (apt memberikan versi Ansible yang lebih lama, yang memadai untuk semua perkara di sini; laluan pipx dalam tutorial ini memberikan versi terkini), tiada ejen pada pelayan, semuanya berjalan melalui konfigurasi SSH yang telah anda bina. Ini adalah peningkatan tunggal terbesar di halaman ini, dan panduan penuh ada di tutorial playbook pertama Ansible; berikut adalah bentuk inventori yang menjadikannya berfungsi:

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

Oleh kerana Ansible menggunakan binari OpenSSH, ~/.ssh/config yang anda tulis dalam bahagian lepas sudah terpakai, inventori nama ringkas seperti web1 akan berfungsi tanpa sebarang vars. Vars di atas menjadikan inventori itu lengkap dengan sendirinya, yang akan memberi manfaat apabila anda menjalankannya dari mesin selain komputer riba anda.

Uji dengan ansible all -i inventory.ini -m ping; hasil yang betul akan memaparkan "ping": "pong" untuk setiap hos, dalam warna hijau. Kegagalan yang akan anda temui dahulu kelihatan seperti ini:

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

Itu bukan masalah Ansible, ssh matt@10.8.0.11 biasa juga gagal dengan cara yang sama. Betulkan SSH dahulu, sentiasa; Ansible hanya berfungsi sebaik lapisan di bawahnya. Satu perkara yang perlu diingat: Ansible memerlukan Python pada kedua-dua hujung, jadi imej yang sangat minimal mungkin menjawab /usr/bin/python3: not found, satu apt install python3 dan ia tidak akan mengganggu anda lagi.

unattended-upgrades menggantikan anda sebagai individu yang memasang tampalan keselamatan pada N pelayan. Ubuntu Server 24.04 standard didatangkan dengan perisian ini diprapasang dan biasanya sudah diaktifkan untuk kemas kini keselamatan, jadi tugas di sini adalah untuk mengesahkan, bukan memasang:

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

Kedua-dua baris sepatutnya berakhir dengan "1". Sesetengah imej minimal dan awan menghantarnya dalam keadaan dimatikan, dan sudo dpkg-reconfigure -plow unattended-upgrades akan menulis semula fail tersebut jika milik anda begitu. Kos persediaan: dua minit untuk menyemak setiap pelayan, atau satu tugasan Ansible untuk kesemuanya. Perkara yang perlu diingat: secara lalai ia tidak pernah melakukan but semula (reboot), jadi kemas kini keselamatan kernel kekal separuh dipasang sehingga anda melakukannya, panduan khusus unattended-upgrades merangkumi but semula automatik, memilih apa yang perlu ditampal, dan membaca lognya.

Pemantauan berpusat menggantikan kaedah mengetahui masalah daripada pelanggan, yang merupakan sistem pemantauan paling mahal pernah dicipta. Dua alatan, satu baris setiap satu tentang bila untuk digunakan: Uptime Kuma menjawab "adakah ia hidup?", pemeriksaan HTTP, TCP, dan ping dengan makluman kepada apa sahaja, dan mengambil masa sepuluh minit dalam Docker; Zabbix menjawab "adakah ia hampir tumbang?", trend cakera, memori, dan CPU melalui ejen pada setiap hos, dan secara jujurnya mengambil masa satu petang. Mulakan dengan Kuma; tambah Zabbix apabila "hidup tetapi merosot" mula merugikan anda. Perkara yang perlu diingat untuk kedua-duanya adalah penempatan, dan ia cukup penting sehingga ia mendahului bahagian kesilapan di bawah.

Panel web, hanya jika perlu. Webmin menggantikan keperluan mengingati di mana Ubuntu menyimpan fail, dan bagi pasukan dengan kemahiran bercampur atau pelayan yang anda sentuh dua kali setahun, ia benar-benar berguna; persediaan mengambil masa sepuluh minit. Perkara yang perlu diingat ialah ia merupakan aplikasi web setara root yang mendengar pada port 10000, dan internet sentiasa mengimbasnya. Jika anda menjalankannya, ikat (bind) ia kepada localhost atau alamat VPN, jangan sekali-kali kepada 0.0.0.0 pada antara muka awam. Dan jika anda mencari panel kerana SSH terasa perlahan, baca semula bahagian sebelumnya dahulu; ~/.ssh/config ditambah Ansible adalah lebih pantas daripada mana-mana panel setelah dikonfigurasikan.

20+ pelayan: di mana panduan ini berakhir

Apabila mengurus lebih daripada dua puluh pelayan, anda sebenarnya mengendalikan satu flit dan rantaian alatan (toolchain) akan berubah: gunakan Terraform atau OpenTofu supaya pelayan boleh dihasilkan semula, cloud-init atau golden images supaya sesebuah mesin bersifat pakai buang dan bukannya perlu dibaiki, konfigurasi berasaskan tarikan (pull-based) atau pipeline CI yang menjalankan Ansible anda kerana kaedah tolak (push) daripada komputer riba tidak lagi berskala, serta pengurusan rahsia (secrets management) yang sebenar. Ansible sendiri tidak akan gagal pada skala dua puluh pelayan; banyak organisasi menjalankannya pada ratusan nod, tetapi amalan di sekelilingnya perlu diperketatkan, dan itu adalah topik yang berbeza daripada apa yang ditulis di laman ini. Jika anda berada pada skala tersebut, bahagian di bawah masih relevan untuk anda, kerana inventori, kunci, dan disiplin akses adalah perkara yang diandaikan oleh alatan pengurusan flit sebagai sesuatu yang sudah anda miliki.

Lapisan yang tidak didokumentasikan oleh sesiapa

Empat amalan ini terpakai untuk setiap saiz armada pelayan, dan mengabaikannya adalah punca mengapa mengurus bilangan pelayan terasa lebih berat daripada yang sepatutnya.

Fail inventori, walaupun sekadar fail teks. Sebaik sahaja anda mempunyai tiga pelayan, catatkan: nama, alamat IP, penyedia, perkara yang dijalankan di atasnya, dan sebab ia wujud. Fail servers.md dalam repositori git sudah memadai; inventori Ansible di atas adalah lebih baik kerana ia merupakan dokumentasi yang boleh dilaksanakan. Ia menggantikan soalan pada pukul 2 pagi: "tunggu, apakah 10.0.0.40 itu?" Kos penyediaan: sepuluh minit. Perangkapnya: ia hanya berkesan jika tindakan mencipta pelayan dan menambah baris tersebut dilakukan serentak, bukan secara berasingan.

Kebersihan kunci: lakukan penggiliran sekarang, gunakan SSH CA apabila keadaan menjadi sukar. Senaraikan lokasi kunci anda (cat ~/.ssh/*.pub pada pihak anda, ~/.ssh/authorized_keys pada pihak setiap pelayan), buang akses daripada komputer riba lama dan bekas rakan sekerja, serta lakukan penggiliran bagi mana-mana kunci yang terlalu lama sehingga anda tidak pasti di mana ia pernah digunakan. Pihak berkuasa sijil (SSH certificate authority) yang menggunakan sijil bertandatangan jangka hayat pendek dan bukannya kunci statik adalah penyelesaian profesional, namun nasihat jujur bagi pelayan yang kurang daripada sepuluh unit ialah pengurusan authorized_keys yang berdisiplin melalui Ansible sudah memberikan 90% manfaat dengan hanya 10% usaha.

Satu laluan masuk, bukan dua puluh. Setiap port SSH awam adalah permukaan serangan yang didarab dengan N. Corak yang berskala: satu bastion host, atau lebih baik lagi, WireGuard VPN pada VPS yang anda kawal, dan SSH bagi setiap pelayan lain hanya diikat pada alamat peribadi masing-masing. Baris ProxyJump dalam konfigurasi di atas sudah mengandaikan bentuk ini. Apa sahaja yang perlu kekal awam harus dipasang dengan fail2ban sebagai langkah standard. Kos penyediaan: satu jam, sekali sahaja. Perangkapnya: pastikan akses sandaran anda (akses konsol penyedia) berfungsi sebelum anda menutup port 22 di mana-mana, bukan selepasnya.

Sandaran yang diuji dengan pemulihan. Sandaran yang tidak diuji hanyalah satu hipotesis. Apa jua mekanisme yang anda gunakan, sama ada snapshot penyedia, restic, atau rsync ke pelayan kedua, alat yang sebenarnya penting ialah entri kalendar di mana anda memulihkan satu pelayan ke VPS baharu dan mengesahkan ia boleh but serta beroperasi. Setiap kisah ngeri tentang sandaran yang saya dengar dalam tempoh lima belas tahun mengurus pelayan mengandungi frasa "kami mempunyai sandaran."

Kesilapan-kesilapan

Mod kegagalan pada skala berbilang pelayan bukanlah kegagalan alatan; ia adalah tabiat. Empat daripadanya menyumbang kepada hampir semua masalah.

Pelayan snowflake. Setiap kotak dikonfigurasikan secara manual, mempunyai perbezaan kecil, dan tiada siapa yang mampu membina semulanya. Anda akan mengetahuinya semasa kegagalan cakera. Penawarnya membosankan: setiap perubahan mesti melalui Ansible, atau sekurang-kurangnya ditambah pada bahagian dokumentasi inventori pelayan tersebut, dan mana-mana pelayan yang tidak boleh anda bina semula daripada nota pada petang ini merupakan hutang teknikal dengan tarikh akhir yang anda tidak boleh pilih.

Lubang firewall "sementara". ufw allow 5432 untuk menyahpepijat sesuatu, dan lapan belas bulan kemudian Postgres masih berada di internet. Lakukan audit dengan sudo ufw status numbered pada setiap kotak, atau dalam satu langkah, ansible all -i inventory.ini -a "ufw status numbered" --become, dan padamkan apa sahaja yang anda tidak mempunyai alasan semasa untuknya. Jika sesuatu peraturan benar-benar bersifat sementara, ufw delete yang sepadan perlu dimasukkan ke dalam tetingkap tmux yang sama sebelum anda menutupnya.

Pemantauan yang dihoskan pada kotak yang dipantau. Jika Uptime Kuma berjalan pada pelayan yang dipantaunya, amaran yang menyatakan "semuanya tergendala" juga akan tergendala, anda telah membina versi yang lebih kecil dan melucukan bagi pusat data yang paling tidak cekap di dunia. Pemantauan perlu berada dalam domain kegagalan yang berbeza: VPS murah di penyedia berbeza adalah jawapan klasik, atau sekurang-kurangnya pemeriksaan peringkat percuma luaran yang memantau pemantau tersebut.

Root SSH di mana-mana. Satu kunci root yang dikongsi merentasi seluruh armada bermakna satu komputer riba yang bocor akan menguasai segala-galanya, dan tiada jejak audit yang menyatakan siapa melakukan apa. Gunakan pengguna bagi setiap individu, sudo, dan PermitRootLogin no dalam /etc/ssh/sshd_config pada setiap hos, yang mana, sekali lagi, merupakan tugasan Ansible tiga baris dan bukannya menghabiskan waktu malam dengan menaip.

Apabila armada berkembang melebihi segelintir, playbook Ansible pertama anda akan mengautomasikan bahagian yang berulang.

FAQ

Apakah alat percuma terbaik untuk menguruskan berbilang pelayan Linux?

Untuk 2 hingga 5 pelayan, ~/.ssh/config yang ditulis dengan baik berserta tmux adalah lebih baik daripada sebarang perisian yang anda pasang. Bermula daripada kira-kira lima pelayan ke atas, Ansible adalah standard industri: ia tidak memerlukan ejen, percuma, berjalan melalui SSH yang sedia ada, dan menukarkan penyediaan pelayan kepada fail dalam git. Tambahkan Uptime Kuma untuk makluman status hidup/mati; setiap alat yang dinamakan dalam panduan ini adalah perisian percuma.

Bolehkah saya menguruskan berbilang pelayan Linux tanpa Ansible?

Ya, untuk bawah lima pelayan, konfigurasi SSH yang baik, fail alias yang dikongsi, dan disiplin sudah memadai, dan ramai orang menguruskan pelayan dengan cara ini selama bertahun-tahun. Melebihi jumlah itu, alternatif kepada Ansible bukanlah "tiada apa-apa", sebaliknya ia membawa kepada konfigurasi yang tidak didokumentasikan: lapan belas pelayan yang setiap satunya dikonfigurasikan secara manual dengan sedikit perbezaan. Jika Ansible terasa berat, mulakan dengan satu playbook yang hanya menguruskan authorized_keys dan unattended-upgrades; usaha itu sahaja sudah berbaloi dengan keluk pembelajaran yang dilalui.

Bagaimanakah cara untuk menjalankan arahan yang sama pada berbilang pelayan Linux serentak?

ansible all -i inventory.ini -a "uptime" adalah jawapan yang kemas dan tidak memerlukan playbook, hanya fail inventori. Untuk kerja interaktif secara bersebelahan, tmux boleh menyiarkan ketukan kekunci ke setiap anak tetingkap dengan setw synchronize-panes on, tetapi anggap ia sebagai helah sahaja, kerana menyiarkan arahan interaktif ke pelayan pengeluaran adalah punca satu kesilapan taip menjadi gangguan perkhidmatan sebanyak N kali.

Adakah saya memerlukan panel kawalan seperti Webmin untuk menguruskan pelayan Linux?

Tidak perlu, segala yang dilakukan oleh panel boleh dilakukan oleh SSH dan Ansible dengan lebih konsisten. Webmin berguna apabila individu dengan tahap kemahiran berbeza mentadbir pelayan yang sama, atau apabila anda jarang menyentuh pelayan sehingga masa terbuang untuk mencari semula laluan konfigurasi. Jika anda menggunakannya, anggap ia sebagai aplikasi web yang setara dengan akses root: ikat ia kepada localhost atau alamat VPN, jangan sekali-kali kepada antara muka awam.

Berapa banyak pelayan Linux yang boleh diuruskan oleh seorang individu secara realistik?

Dengan pentadbiran manual, kualiti kerja akan merosot di bawah sepuluh pelayan. Dengan konfigurasi sebagai kod, penampalan automatik, dan pemantauan berpusat, seorang individu yang teliti boleh mengendalikan 20 hingga 50 pelayan sebagai kerja sampingan; kekangan sebenar adalah kekerapan kerosakan luar jangka, bukan penyelenggaraan rutin. Angka yang penting bukanlah bilangan pelayan bagi setiap pentadbir, tetapi bilangan konfigurasi unik (snowflakes) bagi setiap pentadbir: pastikan angka itu hampir sifar dan had keupayaan anda akan menjadi sangat tinggi.