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

Yerine getirdikleri: IP adreslerinden oluşan metin dosyası, shell geçmişi arkeolojisi (ssh 203.0 yazıp Ctrl-R ile dua etmek) ve sonsuza kadar -p 2222 -i ~/.ssh/other_key yazmak. Kurulum maliyeti: Bir kez, 15 dakika. Dikkat edilmesi gereken nokta: Aşağıda açıklanan eski çoklu bağlantı (multiplexing) soketleri.

Bu ölçekte yazılıma ihtiyacınız yoktur; halihazırda sahip olduğunuz istemciyi ciddiyetle yapılandırmanız yeterlidir. ~/.ssh/config, her sunucuyu tek kelimelik bir isme dönüştürür ve yönlendirmeyi kodlar; böylece bir daha asla bunu düşünmek zorunda kalmazsınız:

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ı bir bastion üzerinden tek sekmede yönlendirir; böylece bir kafeden yapılan ssh db1, bastion üzerinden şeffaf bir şekilde tünellenir. Agent forwarding veya ProxyCommand büyüleri gerekmez; özel sunucuların hiçbir zaman genel SSH portlarına ihtiyacı kalmaz (bu konuya kesişen bölümlerde daha fazla değinilecektir). ControlPersist ile birlikte ControlMaster auto, bağlantıları tek bir TCP oturumu üzerinden çoklar (multiplex). Böylece aynı ana bilgisayara yapılan ikinci ve sonraki tüm ssh, scp veya rsync işlemleri, yeniden anlaşma yapmadan anında bağlanır. Bu fark, Ansible devreye girdiğinde dramatik hale gelir. scp, rsync ve Ansible 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 hata modu farklı görünür. Sunucu yeniden başlatıldığında veya Wi-Fi koptuğunda, ana süreç henüz fark etmediği ölü bir TCP oturumunu tutmaya devam eder. Bir sonraki ssh web1, 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 yüzden bir ana bilgisayara yapılan on birinci çoklu oturum şu çıktıyı verir:

mux_client_request_session: session request failed: Session open refused

Her ikisinin de çözümü aynıdır: ssh -O exit web1 ana süreci sonlandırır ve bir sonraki bağlantı yeni bir tane başlatır. Bazen ControlSocket ~/.ssh/cm-matt@web1-22 already exists, disabling multiplexing hatasını da görebilirsiniz; bu zararsızdır: iki oturum yarışmıştır ve bağlantı hala çalışır, sadece çoklanmamış durumdadır.

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

Paylaşılan bir alias dosyası, her kutuda 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: Doğrudan depoda değil de bir sunucuda düzenlediğiniz anda sapma yaşanır; 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 makinede tek tek yaparım" yaklaşımı bir yöntem olmaktan çıkar ve kendinize söylediğiniz bir yalana dönüşür. Bu ölçekteki araçların tamamı 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 sunucusunun yamayı alıp almadığı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 size daha eski bir Ansible sürümü verir, bu rehberdeki her şey için yeterlidir; öğ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 izlenecek yol Ansible ilk-playbook öğreticisi içindedir; işi ç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 ö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, envanteri kendi kendine yeterli hale getirir; bu da dizüstü bilgisayarınız dışındaki bir makineden çalıştırdığınız gün işinize yarar.

ansible all -i inventory.ini -m ping ile test edin; doğru sonuç, her host 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 dışındaki tek tuzak: Ansible her iki uçta da Python gerektirir, bu nedenle gerçekten minimal bir imaj /usr/bin/python3: not found hatası verebilir, bir apt install python3 ile sorun çözülür ve bir daha sizi rahatsız etmez.

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

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

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

Merkezi izleme, bir sorunu müşteriden öğrenmenin yerini alır; bu şimdiye kadar icat edilmiş en pahalı izleme sistemidir. İ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 şeye uyarı gönderir, Docker üzerinde on dakikada kurulur; Zabbix "çökme üzere mi?" sorusuna yanıt verir, her hosttaki bir ajan aracılığıyla disk, bellek ve CPU trendlerini izler, 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 o kadar önemlidir ki aşağıdaki hatalar bölümünün başında yer alır.

Bir web paneli, yalnızca mecbur kalırsanız. Webmin, Ubuntu'nun ayarları nerede tuttuğunu hatırlama zorunluluğunu ortadan kaldırır; karma becerilere sahip bir ekip veya yılda iki kez dokunduğunuz bir sunucu için gerçekten yararlıdır; kurulum 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ırıyorsanız, localhost veya bir VPN adresine bağlayın, asla genel bir arayüzdeki 0.0.0.0 adresine bağlamayın. Eğer SSH yavaş geldiği için bir panele yöneliyorsanız, önce ö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.