Cara urus pelbagai Linux server dengan berkesan

Apa yang anda bina

Bukan satu alatan — tetapi satu set alatan ringkas, dipilih berdasarkan jumlah pelayan yang anda miliki. Jumlah tersebut adalah satu-satunya input yang penting, dan ia adalah perkara yang sering diabaikan oleh setiap senarai "Linux server management tools". Kesilapan klasik adalah menggunakan penyelesaian untuk 200 pelayan bagi empat VPS, lalu menghabiskan masa sebulan untuk mengurus alatan tersebut berbanding mengurus pelayan. Kesilapan klasik kedua ialah individu dengan lapan belas pelayan masih menggunakan SSH secara manual ke setiap pelayan, 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 saiz yang terpakai pada setiap tahap tetapi jarang ditulis: inventori, kebersihan kunci, satu cara akses, dan sandaran (backups) yang telah berjaya dipulihkan. Bagi setiap alatan, anda akan mendapat tiga perkara: apa yang digantikan, kos penyediaan dalam minit, dan satu masalah teknikal (gotcha) yang benar-benar menyusahkan. Saya telah mengendalikan hos VPS selama lima belas tahun; senarai di bawah adalah apa yang terbukti berkesan semasa gangguan pada jam 2 a.m., bukan apa yang kelihatan bagus semasa demonstrasi.

Prasyarat dan cabaran sebenar

Anda memerlukan akses SSH berasaskan kunci yang berfungsi pada setiap pelayan (jika anda masih menaip kata laluan, selesaikan perkara itu dahulu — ia hanya mengambil masa sepuluh minit dan semua langkah di bawah mengandaikan penggunaan kunci), pengguna sudo yang bukan root, dan pelayan yang menjalankan versi terkini. Arahan di sini mengandaikan Ubuntu 24.04, tetapi tiada yang khusus untuk Ubuntu kecuali apt.

Dua amaran sebelum menggunakan alatan ini. Pertama, penggunaan alatan yang terlalu banyak adalah masalah pengurusan: setiap ejen yang anda pasang adalah satu lagi daemon yang perlu dikemas kini pada setiap mesin, jadi syarat untuk menambah alatan baharu adalah "ini menggantikan kerja manual yang saya lakukan minggu ini," bukan "ini kelihatan berguna." Kedua, semua perkara di sini adalah perisian bebas dan kos sebenar adalah masa penyediaan, sebab itulah setiap alatan disertakan anggaran dalam minit — jika anggaran menyatakan satu petang, percayalah.

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

Apa yang digantikan: fail teks alamat IP, pencarian sejarah shell (ssh 203.0 kemudian Ctrl-R dan berharap), dan menaip -p 2222 -i ~/.ssh/other_key selamanya. Kos tetapan: 15 minit, sekali sahaja. Masalah utama: soket multiplexing yang sudah tamat tempoh, dibincangkan di bawah.

Pada saiz ini anda tidak memerlukan perisian; anda memerlukan klien yang sudah anda konfigurasi dengan betul. ~/.ssh/config menukarkan setiap pelayan menjadi nama satu perkataan dan menetapkan laluan 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 tugas ini. ProxyJump melalukan sambungan melalui bastion dalam satu lompatan, jadi ssh db1 dari kafe akan melalui terowong bastion secara telus — tanpa agent forwarding, tanpa mantera ProxyCommand, dan pelayan peribadi tidak memerlukan port SSH awam langsung (maklumat lanjut ada dalam bahagian berkaitan). ControlMaster auto dengan ControlPersist melakukan multiplexing sambungan melalui satu sesi TCP, jadi ssh, scp, atau rsync kedua dan seterusnya ke hos yang sama bersambung secara serta-merta berbanding rundingan semula — perbezaan ini menjadi sangat ketara apabila Ansible digunakan. Dan kerana scp, rsync, dan Ansible semuanya membaca fail yang sama ini, setiap nama yang anda takrifkan di sini berfungsi di mana-mana sahaja.

Masalah utama: sambungan utama boleh melebihi tempoh kegunaannya, dan dua mod kegagalan kelihatan berbeza. Apabila pelayan but semula atau Wi-Fi anda terputus, proses utama akan memegang sesi TCP yang sudah mati tanpa menyedarinya, dan ssh web1 seterusnya akan tergantung secara senyap pada soket yang tidak menuju ke mana-mana. Secara berasingan, sshd mengehadkan sesi bagi setiap sambungan kepada 10 (MaxSessions dalam sshd_config), jadi sesi multiplexed yang 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 proses utama, dan sambungan seterusnya akan memulakan sesi baharu. Anda mungkin juga kadangkala melihat ControlSocket ~/.ssh/cm-matt@web1-22 already exists, disabling multiplexing — itu tidak berbahaya: dua sesi bersaing, dan sambungan masih berfungsi, cuma tanpa multiplexing.

Dua teman tambahan pada saiz ini. tmux pada setiap pelayan menggantikan nohup, kehilangan kerja apabila Wi-Fi terputus, dan "Saya tidak boleh menutup komputer riba saya, migrasi sedang berjalan." Kos tetapan: sudo apt install -y tmux, dua minit, ditambah dengan memori otot tmux new -s work dan tmux attach -t work. Masalah utamanya ialah nesting: tmux di dalam tmux akan menelan kunci prefix anda, jadi jalankannya pada pelayan atau komputer riba, bukan kedua-duanya. Jika anda menjalankan sesi agent jangka panjang, perkara ini menjadi dua kali ganda penting — ia adalah corak yang sama seperti menjalankan Claude Code dalam tmux pada VPS, di mana sesi tersebut mesti melebihi jangka hayat sambungan SSH.

Fail alias kongsi menggantikan penaipan semula dua belas baris arahan kegemaran anda pada setiap kotak. Simpan .bash_aliases dalam repo git dan tarik ia ke setiap pelayan. Masalah utama: ia akan lari sebaik sahaja anda mengeditnya secara terus pada satu pelayan dan bukannya di dalam repo — yang juga merupakan pengenalan pertama anda mengapa tahap seterusnya wujud.

5 hingga 20 pelayan: konfigurasi sebagai kod, atau drift menang

Apabila melebihi lima pelayan, kaedah "saya akan buat pada setiap kotak" bukan lagi satu kaedah tetapi menjadi satu penipuan kepada diri sendiri. Alat pada tahap ini semuanya melawan musuh yang sama: drift.

Ansible menggantikan gelung shell pada nama hos, halaman wiki bertajuk "setup server baru" yang sudah ketinggalan tiga langkah, dan kegelisahan kerana tidak tahu sama ada web3 benar-benar telah menerima pembetulan. Kos tetapan: 30 minit untuk playbook pertama yang berfungsi — sudo apt install -y ansible pada komputer riba atau mesin 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. Ia adalah peningkatan tunggal terbesar pada halaman ini, dan panduan lengkap ada dalam tutorial playbook pertama Ansible; berikut adalah struktur 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'

Kerana Ansible memanggil binari OpenSSH, ~/.ssh/config yang anda tulis dalam seksyen sebelum ini sudah boleh digunakan — inventori dengan nama kosong seperti web1 akan berfungsi tanpa sebarang vars. Vars di atas menjadikan inventori tersebut bersifat kendiri, yang sangat berguna apabila anda menjalankannya dari mesin yang bukan komputer riba anda.

Uji dengan ansible all -i inventory.ini -m ping; keputusan yang betul akan mencetak "ping": "pong" untuk setiap hos, dalam warna hijau. Kegagalan yang akan anda hadapi terlebih dahulu adalah 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 akan gagal dengan cara yang sama. Baiki SSH terlebih dahulu, sentiasa; Ansible hanya akan berfungsi dengan baik jika lapisan di bawahnya juga stabil. Satu perkara penting yang lain: Ansible memerlukan Python pada kedua-dua hujung, jadi imej yang benar-benar minimal boleh 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 asal disertakan dengan ia yang telah dipasang dan biasanya sudah diaktifkan untuk kemas kini keselamatan, jadi tugas di sini adalah untuk mengesahkan, bukan untuk memasang:

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

Kedua-dua baris harus berakhir dengan "1". Sesetengah imej minimal dan awan membekalkannya dalam keadaan tutup, dan sudo dpkg-reconfigure -plow unattended-upgrades menulis semula fail tersebut jika fail anda dalam keadaan tutup. Kos tetapan: dua minit untuk menyemak setiap pelayan, atau satu tugasan Ansible untuk kesemuanya. Perkara penting: secara lalai ia tidak akan melakukan reboot, jadi kemas kini keselamatan kernel akan kekal separa dipasang sehingga anda melakukannya — panduan khusus unattended-upgrades merangkumi reboot automatik, memilih apa yang perlu ditampal, dan membaca lognya.

Pemantauan berpusat menggantikan cara mengetahui masalah daripada pelanggan, yang merupakan sistem pemantauan paling mahal pernah dicipta. Dua alat, satu baris untuk setiap kegunaan: Uptime Kuma menjawab "adakah ia sedang berjalan?" — semakan HTTP, TCP, dan ping dengan amaran kepada apa-apa sahaja — dan mengambil masa sepuluh minit dalam Docker; Zabbix menjawab "adakah ia bakal tumbang?" — trend cakera, memori, dan CPU melalui ejen pada setiap hos — dan secara jujurnya mengambil masa satu petang. Mulakan dengan Kuma; tambah Zabbix apabila keadaan "berjalan tetapi merosot" mula menyebabkan kerugian wang. Perkara penting bagi kedua-duanya adalah penempatan, dan ia cukup penting sehingga ia disenaraikan dalam seksyen kesilapan di bawah.

Panel web, hanya jika perlu. Webmin menggantikan keperluan untuk mengingati di mana Ubuntu menyimpan fail, dan untuk pasukan dengan kemahiran bercampur atau pelayan yang hanya anda sentuh dua kali setahun, ia sangat berguna; tetapan mengambil masa sepuluh minit. Perkara penting ialah ia adalah aplikasi web setaraf root yang mendengar pada port 10000, dan internet sentiasa mengimbasnya. Jika anda menjalankannya, ikat ia pada localhost atau alamat VPN — jangan sekali-kali pada 0.0.0.0 pada antara muka awam. Dan jika anda mencari panel kerana SSH terasa lambat, baca semula seksyen sebelum ini; ~/.ssh/config ditambah Ansible adalah lebih pantas daripada mana-mana panel setelah dikonfigurasikan.

20+ server: di mana panduan ini berakhir

Selepas dua puluh server, anda sedang mengendalikan satu armada, dan rantaian alatan akan berubah: Terraform atau OpenTofu supaya server itu sendiri boleh dihasilkan semula, cloud-init atau golden images supaya sesebuah unit boleh dibuang dan bukannya dibaiki, konfigurasi berasaskan pull atau saluran paip CI yang menjalankan Ansible anda kerana kaedah push-from-a-laptop tidak lagi boleh diskalakan, dan pengurusan rahsia yang sebenar. Ansible sendiri tidak akan gagal pada jumlah dua puluh — banyak syarikat menggunakannya terhadap ratusan nod — tetapi amalan di sekelilingnya mesti diperkukuh, dan itu adalah artikel yang berbeza daripada apa yang ditulis laman ini. Jika anda berada pada skala tersebut, bahagian di bawah masih relevan untuk anda, kerana inventori, kunci, dan disiplin akses adalah perkara yang dianggap sudah anda miliki oleh alatan armada.

Lapisan yang tidak pernah dicatat

Empat amalan ini terpakai untuk setiap saiz armada, dan kegagalan melaksanakannya menyebabkan jumlah pelayan terasa lebih berat daripada yang sepatutnya.

Fail inventori — walaupun sekadar fail teks. Sebaik sahaja anda mempunyai tiga pelayan, catatkan: nama, IP, pembekal, aplikasi yang berjalan, dan tujuan ia wujud. Fail servers.md dalam repo git sudah memadai; inventori Ansible di atas adalah lebih baik kerana ia merupakan dokumentasi yang boleh dilaksanakan. Ia menggantikan: persoalan pada jam 2 pagi seperti "tunggu, apa itu 10.0.0.40?". Kos tetapan: sepuluh minit. Perkara penting: ia hanya berkesan jika proses mencipta pelayan dan menambah baris kod dilakukan sebagai satu tindakan yang sama, bukan dua tindakan berasingan.

Kebersihan kunci: pusingan kunci sekarang, gunakan SSH CA apabila keadaan menjadi sukar. Senaraikan di mana kunci anda disimpan (cat ~/.ssh/*.pub di pihak anda, ~/.ssh/authorized_keys di setiap pihak pelayan), buang kunci daripada komputer riba lama atau bekas rakan sekerja, dan pusingkan (rotate) apa-apa kunci lama yang anda tidak lagi tahu sejarah penggunaannya. SSH certificate authority — menggunakan sijil bertandatangan jangka pendek berbanding kunci statik — adalah penyelesaian yang matang, tetapi nasihat jujur saya ialah untuk kurang daripada sepuluh pelayan, pengurusan authorized_keys yang berdisiplin melalui Ansible memberikan 90% manfaat dengan hanya 10% kerumitan.

Satu pintu masuk, bukan dua puluh. Setiap port SSH awam adalah permukaan serangan yang didarabkan dengan N. Corak yang boleh diskalakan: satu bastion host — atau lebih baik, WireGuard VPN pada VPS yang anda kawal — dan SSH bagi setiap pelayan lain hanya terikat pada alamat peribadinya sahaja. Baris ProxyJump dalam konfigurasi di atas sudah mengandaikan struktur ini. Apa-apa yang mesti kekal awam wajib menggunakan fail2ban. Kos tetapan: satu jam, sekali sahaja. Perkara penting: sahkan akses konsol pembekal (fallback) berfungsi sebelum anda menutup port 22 di semua tempat, bukan selepas itu.

Sandaran (backup) diuji dengan pemulihan (restore). Sandaran yang tidak diuji hanyalah satu hipotesis. Apa jua mekanisme yang anda gunakan — snapshot pembekal, restic, rsync ke kotak kedua — alat yang benar-benar penting ialah catatan kalendar di mana anda memulihkan satu pelayan ke VPS baharu dan mengesahkan ia boleh but (boot) dan berfungsi. Setiap kisah ngeri sandaran yang saya dengar dalam lima belas tahun penghosan mengandungi frasa "kami ada sandaran."

Kesilapan

Kegagalan pada skala pelbagai pelayan bukan disebabkan oleh kegagalan alatan; ia adalah disebabkan oleh tabiat. Empat perkara ini merangkumi hampir semua masalah.

Pelayan Snowflake. Setiap mesin dikonfigurasi secara manual, mempunyai perbezaan halus, dan tiada sesiapa yang boleh membina semula pelayan tersebut. Anda hanya akan menyedarinya semasa kegagalan cakera berlaku. Penyelesaiannya mudah: setiap perubahan mesti melalui Ansible — atau sekurang-kurangnya ditambah ke bahagian inventori dokumen pelayan tersebut — dan mana-mana pelayan yang tidak boleh dibina semula daripada nota petang ini adalah hutang teknikal dengan tarikh tamat tempoh yang tidak boleh anda pilih.

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

Pemantauan dihoskan pada mesin yang dipantau. Jika Uptime Kuma berjalan pada pelayan yang dipantau, amaran yang menyatakan "semuanya terhenti" juga akan terhenti — anda telah membina versi yang lebih kecil dan lebih lucu bagi pusat data yang paling tidak cekap di dunia. Pemantauan mesti berada dalam domain kegagalan yang berbeza: VPS murah pada penyedia lain adalah jawapan klasik, atau sekurang-kurangnya semakan percuma luaran yang memantau pemantau tersebut.

Root SSH di mana-mana. Satu kunci root yang dikongsi merentasi seluruh rangkaian bermakna satu komputer riba yang bocor akan menguasai segalanya, dan tiada jejak audit yang menyatakan siapa melakukan apa. Gunakan pengguna per individu, sudo, dan PermitRootLogin no dalam /etc/ssh/sshd_config pada setiap hos — yang mana, sekali lagi, hanyalah tugas Ansible tiga baris berbanding menghabiskan masa satu malam untuk menaip.

Apabila rangkaian berkembang melebihi beberapa unit, playbook Ansible pertama anda akan mengautomasikan bahagian yang berulang.

FAQ

Apakah alat percuma terbaik untuk mengurus pelbagai pelayan Linux?

Untuk 2 hingga 5 pelayan, penggunaan ~/.ssh/config yang ditulis dengan baik bersama tmux adalah lebih baik daripada mana-mana alat lain. Bermula daripada kira-kira lima pelayan, Ansible adalah jawapan standard: tanpa ejen, percuma, berjalan melalui SSH sedia ada, dan menukar tetapan pelayan kepada fail dalam git. Tambah Uptime Kuma untuk amaran status aktif/tidak aktif; setiap alat yang dinamakan dalam panduan ini adalah perisian percuma.

Bolehkah saya mengurus pelbagai pelayan Linux tanpa Ansible?

Boleh — untuk kurang daripada lima pelayan, konfigurasi SSH yang baik, fail alias kongsi, dan disiplin sudah mencukupi, dan ramai orang menggunakannya sedemikian selama bertahun-tahun. Selepas jumlah itu, alternatif kepada Ansible bukanlah "tiada apa-apa", tetapi ia adalah "undocumented drift": lapan belas pelayan yang setiap satunya dikonfigurasi secara manual dengan sedikit perbezaan. Jika Ansible terasa terlalu berat, mulakan dengan satu playbook yang hanya mengurus authorized_keys dan unattended-upgrades; itu sahaja sudah berbaloi dengan proses pembelajaran tersebut.

Bagaimanakah cara untuk menjalankan arahan yang sama pada pelbagai pelayan Linux secara 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 kekunci ke setiap pane dengan setw synchronize-panes on — tetapi anggap itu sebagai sekadar teknik sampingan, kerana menyiarkan arahan interaktif ke pelayan produksi adalah cara bagaimana satu kesilapan taip menjadi gangguan sebanyak N kali.

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

Tidak perlu — semua 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 mencari semula laluan konfigurasi memakan masa yang lama. Jika anda menggunakannya, anggap ia sebagai aplikasi web setaraf root: sambungkan ke localhost atau alamat VPN, jangan sesekali sambungkan ke antara muka awam.

Berapakah jumlah pelayan Linux yang boleh diurus secara realistik oleh seorang individu?

Dengan pentadbiran manual, kualiti akan merosot apabila mencapai kurang daripada sepuluh pelayan. Dengan konfigurasi sebagai kod, pemutihan automatik, dan pemantauan berpusat, seorang individu yang teliti boleh mengurus 20 hingga 50 pelayan sebagai kerja sambilan — kekangan utama adalah kekerapan berlaku kerosakan luar jangka, bukan penjagaan rutin. Jumlah yang penting bukanlah pelayan bagi setiap admin tetapi "snowflake" (konfigurasi unik) bagi setiap admin: kekalkan jumlah itu hampir sifar dan had pengurusan anda adalah tinggi.