Birden Fazla Linux Sunucusu Yönetimi İçin En İyi Araçlar

Ne inşa ediyorsunuz

Tek bir araç değil, sahip olduğunuz gerçek sunucu sayısına göre seçilmiş kısa bir yığın. Önemli olan tek girdi bu sayıdır ve "Linux sunucu yönetim araçları" incelemelerinin tamamının göz ardı ettiği nokta da budur. Klasik hata, dört adet VPS için 200 sunuculuk bir çözüm benimsemek ve sunucular yerine aracı beslemek için bir ay harcamaktır. İkinci klasik hata ise, on sekiz sunucusu olmasına rağmen hala her birine manuel olarak SSH ile bağlanan ve "aynı" değişikliği on sekiz farklı şekilde uygulayan kişidir.

Bu rehber, filo boyutuna göre düzenlenmiştir: 2 ila 5 sunucu, 5 ila 20 sunucu ve 20 sunucu üzeri. Ayrıca, her boyutta geçerli olan ve kimsenin yazmadığı çapraz katmanlar da mevcuttur: bir envanter, anahtar hijyeni, tek bir giriş noktası ve gerçekten geri yüklemesini yaptığınız yedekler. Her araç için üç şey elde edeceksiniz: neyin yerini aldığı, kurulumun dakika cinsinden maliyeti ve sizi gerçekten zorlayacak olan tek bir tuzak. On beş yıldır bir VPS barındırma hizmeti yönetiyorum; aşağıdaki liste, demosu iyi görünenleri değil, gece saat 02:00'deki bir kesinti anında hayatta kalanları içermektedir.

Ön koşullar ve dürüst uyarılar

Her sunucuda anahtar tabanlı SSH erişiminin halihazırda çalışıyor olması gerekir (eğer hala parola giriyorsanız, bunu öncelikle düzeltin; on dakikalık bir işlemdir ve aşağıdaki her şey anahtarların varlığını varsayar). Ayrıca root olmayan bir sudo kullanıcısına ve güncel bir işletim sistemi çalıştıran sunuculara ihtiyacınız vardır. Buradaki komutlar Ubuntu 24.04 sürümünü temel alır, ancak apt dışında hiçbir şey Ubuntu'ya özgü değildir.

Araçlara geçmeden önce iki dürüst uyarı: Birincisi, araç çeşitliliğinin kendisi bir yönetim sorunudur; yüklediğiniz her aracı (agent) her sunucuda yamamanız gerekir. Bu nedenle yeni bir araç ekleme kriteriniz "bu araç, bu hafta manuel olarak yaptığım işin yerini alıyor" olmalı, "bu kullanışlı görünüyor" olmamalıdır. İkincisi, buradaki her şey özgür yazılımdır ve asıl maliyet kurulum süresidir. Bu yüzden her aracın yanında dakika cinsinden bir tahmin yer alır; bir araç için "bir öğleden sonra" deniliyorsa, buna inanın.

2 ila 5 sunucu: ~/.ssh/config halihazırda sahip olduğunuz en az değer verilen araçtır

Neyin yerini alır: IP adreslerinin tutulduğu metin dosyalarının, shell geçmişinde yapılan arkeolojik kazıların (ssh 203.0 yazıp Ctrl-R ile dua etmenin) ve sonsuza kadar -p 2222 -i ~/.ssh/other_key yazmanın yerini alır. Kurulum maliyeti: Bir kez, 15 dakika. Dikkat edilmesi gereken nokta: Aşağıda açıklanan eski çoklu bağlantı (multiplexing) soketleri.

Bu ölçekte ek bir yazılıma ihtiyacınız yoktur; yalnızca halihazırda sahip olduğunuz istemciyi doğru şekilde yapılandırmanız yeterlidir. ~/.ssh/config, her sunucuyu tek kelimelik bir isme dönüştürür ve yönlendirmeyi kodlayarak bir daha bu konuda düşünmenize gerek kalmamasını sağlar:

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

Üç ayar tüm işi yapar. ProxyJump, bağlantıları tek bir atlamada bir bastion sunucusu üzerinden yönlendirir; böylece bir kafeden yapılan ssh db1, bastion üzerinden şeffaf bir şekilde tünellenir. Agent forwarding veya ProxyCommand komutlarına gerek kalmaz ve özel sunucuların hiçbir zaman genel SSH portlarına ihtiyacı olmaz (bununla ilgili daha fazla bilgi çapraz kesit bölümündedir). ControlMaster auto ve ControlPersist ile bağlantılar tek bir TCP oturumu üzerinden çoklanır; böylece aynı ana bilgisayara yapılan ikinci ve sonraki tüm ssh, scp veya rsync bağlantıları, yeniden görüşme yapmadan anında gerçekleşir. Bu fark, Ansible devreye girdiğinde oldukça belirginleşir. scp, rsync ve Ansible'ın tümü aynı dosyayı okuduğu için burada tanımladığınız her isim her yerde çalışır.

Dikkat edilmesi gereken nokta: Ana bağlantı (master connection) ömrünü tamamlayabilir ve iki farklı hata modu ortaya çıkabilir. Sunucu yeniden başlatıldığında veya Wi-Fi bağlantınız koptuğunda, ana süreç henüz fark etmediği ölü bir TCP oturumunu tutmaya devam eder ve bir sonraki ssh web1 komutu, hiçbir yere çıkmayan bir soket üzerinde sessizce asılı kalır. Ayrıca, sshd bağlantı başına oturum sayısını 10 ile sınırlar (sshd_config içindeki MaxSessions), bu nedenle aynı ana bilgisayara yapılan on birinci çoklu oturum şu çıktıyı verir:

mux_client_request_session: session request failed: Session open refused by peer

Her ikisinin de çözümü aynıdır: ssh -O exit web1 ana bağlantıyı sonlandırır ve bir sonraki bağlantı yeni bir tane başlatır. Bazen ControlSocket /home/matt/.ssh/cm-matt@10.8.0.11-22 already exists, disabling multiplexing hatasını da görebilirsiniz; bu zararsızdır: iki oturum çakışmıştır ve bağlantı yine de çalışır, sadece çoklu bağlantı (multiplexing) kullanılmaz.

Bu ölçekte iki yardımcı araç vardır. Her sunucudaki tmux, nohup komutunun, Wi-Fi koptuğunda kaybedilen işlerin ve "Bir taşıma işlemi çalışırken dizüstü bilgisayarımı kapatamam" sorununun yerini alır. Kurulum maliyeti: sudo apt install -y tmux, iki dakika ve tmux new -s work ile tmux attach -t work tuş kombinasyonlarının kas hafızasına yerleşmesi. Dikkat edilmesi gereken nokta iç içe geçmedir: tmux içinde tmux, ön ek (prefix) tuşunuzu yutar, bu yüzden ya sunucuda ya da dizüstü bilgisayarda çalıştırın, ikisinde birden değil. Uzun süreli agent oturumları çalıştırıyorsanız bu durum iki kat önemlidir; bu, oturumun SSH bağlantısından daha uzun yaşaması gereken Claude Code'u bir VPS üzerinde tmux içinde çalıştırmak ile aynı desendir.

Paylaşılan bir alias dosyası, her sunucuda en sevdiğiniz on iki tek satırlık komutu tekrar yazmanın yerini alır. Bir .bash_aliases dosyasını git deposunda tutun ve her sunucuya çekin. Dikkat edilmesi gereken nokta: Dosyayı depoda düzenlemek yerine doğrudan bir sunucuda düzenlediğiniz anda yapılandırma sapması (drift) başlar; bu da bir sonraki aşamanın neden var olduğuna dair ilk deneyiminizdir.

5 ila 20 sunucu: kod olarak yapılandırma veya sapma kazanır

Beş sunucudan sonra, "her birini tek tek hallederim" yaklaşımı bir yöntem olmaktan çıkar ve kendinize söylediğiniz bir yalana dönüşür. Bu ölçekteki tüm araçlar aynı düşmanla savaşır: yapılandırma sapması (drift).

Ansible, sunucu adları üzerinde dönen shell döngülerinin, üç adım geriden gelen "yeni sunucu kurulumu" başlıklı wiki sayfalarının ve web3 sunucusuna düzeltmenin gerçekten uygulanıp uygulanmadığını bilmemenin yarattığı kaygının yerini alır. Kurulum maliyeti: ilk çalışan playbook için 30 dakika, dizüstü bilgisayarınızda veya bir yönetim sunucusunda sudo apt install -y ansible (apt, burada anlatılan her şey için yeterli olan eski bir Ansible sürümü sunar; öğreticideki pipx yolu ise güncel sürümleri sağlar), sunucularda ajan gerektirmez, her şey halihazırda oluşturduğunuz SSH yapılandırması üzerinden çalışır. Bu sayfadaki en büyük tekil yükseltmedir ve tam kılavuzu Ansible ilk-playbook öğreticisi içindedir; sistemi çalıştıran envanterin yapısı şöyledir:

[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 dosyasını kullandığı için, bir önceki bölümde yazdığınız ~/.ssh/config zaten geçerlidir; web1 gibi yalın isimlerden oluşan bir envanter, hiçbir değişken olmadan çalışacaktır. Yukarıdaki değişkenler ise envanteri kendi kendine yeterli kılar; bu da onu dizüstü bilgisayarınızdan farklı bir makinede çalıştırdığınız gün işinize yarar.

ansible all -i inventory.ini -m ping ile test edin; doğru bir sonuç, her sunucu için yeşil renkte "ping": "pong" çıktısı verir. İlk karşılaşacağınız hata şuna benzer:

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

Bu bir Ansible sorunu değildir, düz ssh matt@10.8.0.11 de aynı şekilde başarısız olur. Her zaman önce SSH bağlantısını düzeltin; Ansible, altındaki katman kadar sağlıklıdır. Bunun ötesindeki tek tuzak şudur: Ansible, makinenizde ve ping dahil neredeyse tüm modüller için sunucuda da Python gerektirir; bu nedenle çok minimal bir imaj /usr/bin/python3: not found yanıtını verebilir. Bir apt install python3 ile bu sorun çözülür; çok sayıda yalın imaj için, uzak sunucuda Python gerektirmeyen nadir modüllerden biri olan raw, bu kurulumu sizin yerinize yapabilir.

unattended-upgrades, N sayıda sunucuya güvenlik yamalarını uygulama görevinde sizin yerinizi alır. Standart Ubuntu Server 24.04, bu aracı önceden yüklenmiş ve genellikle güvenlik güncellemeleri için etkinleştirilmiş olarak sunar; bu yüzden buradaki iş kurulum değil, doğrulamadır:

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

Her iki satır da "1" ile bitmelidir. Bazı minimal ve bulut imajları bu özelliği kapalı olarak sunar; sudo dpkg-reconfigure -plow unattended-upgrades, sizinki kapalıysa dosyayı yeniden yazar. Kurulum maliyeti: sunucu başına iki dakika kontrol veya hepsi için tek bir Ansible görevi. Tuzak: varsayılan olarak asla yeniden başlatma yapmaz, bu yüzden çekirdek güvenlik güncellemeleri siz yapana kadar yarım kalır; özel unattended-upgrades kılavuzu otomatik yeniden başlatmaları, nelerin yamalanacağını seçmeyi ve logları okumayı kapsar.

Merkezi izleme, en pahalı izleme sistemi olan "müşteriden öğrenme" yönteminin yerini alır. İki araç, ne zaman kullanılacaklarına dair birer satır: Uptime Kuma "çalışıyor mu?" sorusuna yanıt verir; HTTP, TCP ve ping kontrolleri ile her yere uyarı gönderir ve Docker üzerinde on dakikada kurulur; Zabbix "çökmek üzere mi?" sorusuna yanıt verir; her sunucudaki ajan aracılığıyla disk, bellek ve CPU trendlerini izler ve dürüst olmak gerekirse bir öğleden sonranızı alır. Kuma ile başlayın; "çalışıyor ama performans düşük" durumu size para kaybettirmeye başladığında Zabbix ekleyin. Her ikisi için de tuzak konumlandırmadır ve bu, aşağıdaki hatalar bölümünde yer alacak kadar önemlidir.

Bir web paneli, sadece zorunluysa. Webmin, Ubuntu'nun ayarları nerede tuttuğunu hatırlama zorunluluğunu ortadan kaldırır; farklı yeteneklere sahip bir ekip veya yılda iki kez dokunduğunuz bir sunucu için gerçekten yararlıdır; kurulumu on dakikadır. Tuzak, 10000 numaralı portta dinleme yapan ve internetin sürekli taradığı, root yetkilerine eşdeğer bir web uygulaması olmasıdır. Eğer çalıştıracaksanız, herkese açık bir arayüzdeki 0.0.0.0 yerine localhost veya bir VPN adresine bağlayın. Eğer SSH yavaş geldiği için bir panele yöneliyorsanız, önce bir önceki bölümü tekrar okuyun; ~/.ssh/config ve Ansible yapılandırıldığında herhangi bir panelden daha hızlıdır.

20+ sunucu: bu rehberin gerçek anlamda bittiği nokta

Yirmi sunucunun üzerine çıktığınızda artık bir filo yönetiyorsunuz demektir ve araç zincirinizin yapısı değişir: Sunucuların yeniden üretilebilir olması için Terraform veya OpenTofu, bir makinenin onarılabilir değil atılabilir olması için cloud-init veya golden image, dizüstü bilgisayardan push yöntemi ölçeklenemediği için pull tabanlı yapılandırma veya Ansible çalıştıran CI pipeline'ları ve gerçek bir sır yönetimi (secrets management) gerekir. Ansible'ın kendisi yirmi sunucuda çökmez; birçok işletme bunu yüzlerce düğüm üzerinde kullanır ancak etrafındaki uygulamaların sertleşmesi gerekir ve bu, bu sitenin yazdığı makaleden farklı bir konudur. Eğer bu ölçekteyseniz, aşağıdaki bölüm hala sizin için geçerlidir; çünkü envanter, anahtarlar ve erişim disiplini, filo araçlarının zaten sahip olduğunuzu varsaydığı temel unsurlardır.

Kimsenin yazmadığı katman

Sunucu sayısı ne olursa olsun dört uygulama geçerlidir; bunları atlamak, sunucu yönetiminin olduğundan daha ağır hissedilmesine neden olur.

Bir envanter dosyası, bir metin dosyası bile olsa. Üç sunucunuz olduğu anda şunları not edin: isim, IP, sağlayıcı, üzerinde ne çalıştığı ve neden var olduğu. Bir git deposundaki servers.md yeterlidir; yukarıdaki Ansible envanteri, çalıştırılabilir dokümantasyon olduğu için daha iyidir. Yerine geçtiği şey: gece saat 02.00'de sorulan "bir dakika, 10.0.0.40 nedir?" sorusudur. Kurulum maliyeti: on dakika. Dikkat edilmesi gereken nokta: sadece sunucuyu oluşturmak ve satırı eklemek aynı anda yapıldığında işe yarar, asla iki ayrı işlem olmamalıdır.

Anahtar hijyeni: hemen rotasyon, zorlandığınızda bir SSH CA. Anahtarlarınızın nerede yaşadığını listeleyin (sizin tarafınızda cat ~/.ssh/*.pub, her sunucunun tarafında ~/.ssh/authorized_keys), eski dizüstü bilgisayarları ve eski iş arkadaşlarını kaldırın, nerede olduğunu söyleyemeyeceğiniz kadar eski olan her şeyi döndürün. Bir SSH sertifika yetkilisi (CA), statik anahtarlar yerine kısa ömürlü imzalı sertifikalar, yetişkin çözümüdür; ancak dürüst tavsiye şudur: on sunucunun altında, Ansible aracılığıyla disiplinli bir authorized_keys yönetimi, size işin %10'luk zahmetiyle %90'lık faydasını sağlar.

Yirmi tane değil, tek bir giriş yolu. Herkese açık her SSH portu, N ile çarpılan bir saldırı yüzeyidir. Ölçeklenen model şudur: bir bastion host veya daha iyisi, kontrol ettiğiniz bir VPS üzerinde WireGuard VPN ve diğer tüm sunucuların SSH'ının yalnızca özel adreslerine bağlanması. Yukarıdaki yapılandırmadaki ProxyJump satırları zaten bu şekli varsayar. Herkese açık kalması gereken her şey için doğal bir süreç olarak fail2ban kurulmalıdır. Kurulum maliyeti: bir saat, bir defaya mahsus. Dikkat edilmesi gereken nokta: 22 numaralı portu her yerde kapatmadan önce, yedekleme yönteminizin (sağlayıcının konsol erişimi) çalıştığını doğrulayın, kapattıktan sonra değil.

Geri yükleme ile test edilmiş yedekler. Test edilmemiş bir yedek bir hipotezdir. Hangi mekanizmayı kullanırsanız kullanın; sağlayıcı snapshot'ları, restic, ikinci bir kutuya rsync, aslında önemli olan tek araç, bir sunucuyu yeni bir VPS'e geri yüklediğiniz, açıldığını ve hizmet verdiğini doğruladığınız takvim kaydınızdır. On beş yıllık barındırma deneyimimde duyduğum her yedekleme korku hikayesi "yedeklerimiz vardı" cümlesini içerir.

Hatalar

Çoklu sunucu ölçeğinde karşılaşılan hata modları araçlardan değil, alışkanlıklardan kaynaklanır. Neredeyse tüm sorunların temelinde dört ana alışkanlık yatar.

Snowflake sunucular. Her sunucu elle yapılandırılmıştır, birbirinden küçük farklar içerir ve kimse onu baştan kuramaz. Bu durum ancak bir disk arızası sırasında fark edilir. Çözümü basittir: Her değişiklik Ansible üzerinden yapılmalı veya en azından o sunucunun envanter belgesindeki ilgili bölüme eklenmelidir. Bugün notlarınıza bakarak yeniden kuramadığınız her sunucu, vadesini sizin belirlemediğiniz bir teknik borçtur.

"Geçici" güvenlik duvarı delikleri. Bir sorunu ayıklamak için ufw allow 5432 komutunu kullanırsınız ve on sekiz ay sonra Postgres hala internete açıktır. Her sunucuda sudo ufw status numbered ile veya tek seferde ansible all -i inventory.ini -a "ufw status numbered" --become ile denetim yapın ve güncel bir gerekçesini açıklayamadığınız tüm kuralları silin. Eğer bir kural gerçekten geçiciyse, onu kapatmadan önce ilgili ufw delete komutunu aynı tmux penceresine yazın.

İzlenen sunucuda barındırılan izleme araçları. Eğer Uptime Kuma, izlediği sunucu üzerinde çalışıyorsa, "her şey çöktü" uyarısı da çökmüş demektir; böylece dünyanın en verimsiz veri merkezinin daha küçük ve komik bir versiyonunu oluşturmuş olursunuz. İzleme araçları farklı bir hata alanında barındırılmalıdır: Farklı bir sağlayıcıdan alınan ucuz bir VPS klasik çözümdür; en azından izleyiciyi izleyen ücretsiz bir dış servis katmanı kullanılmalıdır.

Her yerde root SSH erişimi. Tüm filoda paylaşılan tek bir root anahtarı, çalınan bir dizüstü bilgisayarın her şeyi ele geçirmesi ve kimin ne yaptığını gösteren bir denetim izinin olmaması anlamına gelir. Her sunucuda kişisel kullanıcılar, sudo yetkisi ve /etc/ssh/sshd_config dosyasında PermitRootLogin no ayarı kullanılmalıdır; bu da bir akşamınızı yazarak geçirmek yerine üç satırlık bir Ansible görevi ile halledilebilir.

Filo birkaç sunucunun üzerine çıktığında, ilk Ansible playbook'unuz tekrarlayan işleri otomatize edecektir.

FAQ

Birden fazla Linux sunucusunu yönetmek için en iyi ücretsiz araç nedir?

2 ila 5 sunucu için, iyi yazılmış bir ~/.ssh/config ve tmux kombinasyonu, kurabileceğiniz her türlü araçtan daha verimlidir. Yaklaşık beş sunucudan itibaren Ansible standart çözümdür: ajansızdır, ücretsizdir, halihazırda sahip olduğunuz SSH üzerinden çalışır ve sunucu kurulumunu git içindeki dosyalara dönüştürür. Çalışma durumu uyarıları için Uptime Kuma ekleyin; bu kılavuzda adı geçen her araç özgür yazılımdır.

Birden fazla Linux sunucusunu Ansible olmadan yönetebilir miyim?

Evet, yaklaşık beş sunucuya kadar iyi bir SSH yapılandırması, paylaşılan bir alias dosyası ve disiplin yeterlidir; birçok kişi yıllarca bu şekilde çalışır. Bu sayıdan sonra Ansible'a alternatif "hiçbir şey" değil, belgelenmemiş sapmadır: her biri elle biraz farklı yapılandırılmış on sekiz sunucu. Ansible ağır geliyorsa, yalnızca authorized_keys ve unattended-upgrades yöneten tek bir playbook ile başlayın; bu bile öğrenme sürecine değecektir.

Aynı komutu birden fazla Linux sunucusunda aynı anda nasıl çalıştırırım?

ansible all -i inventory.ini -a "uptime" temiz bir çözümdür ve playbook gerektirmez, sadece envanter dosyası yeterlidir. Etkileşimli ve yan yana çalışma için tmux, tuş vuruşlarını setw synchronize-panes on ile her bölmeye yayınlayabilir; ancak bunu bir gösteri numarası olarak görün, çünkü üretim sunucularına etkileşimli komutlar yayınlamak, tek bir yazım hatasının N katı kesintiye dönüşmesine neden olur.

Linux sunucularını yönetmek için Webmin gibi bir kontrol paneline ihtiyacım var mı?

İhtiyaç duymazsınız; bir panelin yaptığı her şeyi SSH ve Ansible daha tekrarlanabilir şekilde yapar. Webmin, farklı yetenek seviyelerine sahip kişiler aynı sunucuları yönettiğinde veya bir sunucuya yapılandırma yollarını hatırlayamayacak kadar nadir eriştiğinizde yerini bulur. Eğer bir tane çalıştırıyorsanız, onu root yetkilerine sahip bir web uygulaması olarak değerlendirin: asla genel bir arayüze değil, localhost veya bir VPN adresine bağlayın.

Bir kişi gerçekçi olarak kaç Linux sunucusunu yönetebilir?

Elle yönetimde kalite on sunucunun altında düşmeye başlar. Kod olarak yapılandırma, otomatik yama yönetimi ve merkezi izleme ile dikkatli bir kişi 20 ila 50 sunucuyu yarı zamanlı bir iş olarak yürütebilir; kısıtlayıcı faktör rutin bakım değil, yeni bir sorunun ne sıklıkla ortaya çıktığıdır. Önemli olan sayı yönetici başına sunucu sayısı değil, yönetici başına benzersiz (snowflake) sunucu sayısıdır: bunu sıfıra yakın tutun, böylece kapasite tavanı yüksek kalacaktır.