Linux sunucu yönetimi için en iyi araçlar

Ne inşa ediyorsunuz

Tek bir araç değil; sahip olduğunuz sunucu sayısına göre seçilmiş kısa bir teknoloji yığını. Önemli olan tek girdi sunucu sayısıdır ve tüm "Linux sunucu yönetim araçları" listeleri bu faktörü göz ardı eder. Yaygın hata, dört adet VPS için 200 sunuculuk bir çözüm seçmek ve sunucular yerine araca veri girişi yapmak için bir ay harcamaktır. İkinci yaygın hata ise on sekiz sunucusu olan bir kişinin, her birine hala manuel olarak SSH ile bağlanması ve "aynı" değişikliği on sekiz farklı şekilde uygulamasıdır.

Bu kılavuz filo boyutuna göre düzenlenmiştir: 2 ile 5 sunucu arası, 5 ile 20 arası ve 20'den fazlası. Ayrıca her boyut için geçerli olan ancak kimsenin yazmadığı ortak katmanlar şunlardır: envanter, anahtar hijyeni, tek bir giriş yöntemi ve gerçekten geri yüklenmiş yedekler. Her araç için üç bilgi sağlanmaktadır: neyin yerini aldığı, kurulum süresi ve gerçekte sorun çıkaran kritik nokta. On beş yıldır bir VPS sağlayıcısı yönetiyorum; aşağıdaki liste, demolar için değil, saat 02:00'deki bir kesinti sırasında ayakta kalan yöntemlerden oluşmaktadır.

Ön Koşullar ve dikkat edilmesi gerekenler

Her sunucuya anahtar tabanlı SSH erişimi sağlanmış olmalıdır (eğer hâlâ şifre yazıyorsanız, önce bunu düzeltin; bu işlem 10 dakika sürer ve aşağıdaki tüm adımlar anahtar kullanımını varsayar). Root olmayan bir sudo kullanıcısına ve güncel bir işletim sistemi çalıştıran sunuculara ihtiyaç vardır. Buradaki komutlar Ubuntu 24.04 için hazırlanmıştır; ancak apt dışında Ubuntu'ya özgü bir durum yoktur.

Araçlara geçmeden önce iki önemli uyarı: Birincisi, araç çeşitliliği bir yönetim sorunudur; yüklenen her ajan, her makinede yamalanması gereken yeni bir daemon demektir. Bu nedenle, yeni bir araç ekleme kriteri "bu araç bu hafta yaptığım manuel işlerin yerini alıyor" olmalıdır, "bu araç kullanışlı görünüyor" değil. İkincisi, buradaki tüm araçlar ücretsiz yazılımdır ve asıl maliyet kurulum süresidir; bu nedenle her aracın yanında tahmini dakika bilgisi verilmiştir. Eğer tahmin bir öğleden sonra diyorsa, buna itibar edin.

2 ile 5 sunucu: ~/.ssh/config halihazırda sahip olduğunuz en az bilinen araçtır

Neyin yerini alır: IP adresleri listesini, shell-history üzerinden yapılan aramaları (ssh 203.0 ardından Ctrl-R ve umut etmek) ve sürekli -p 2222 -i ~/.ssh/other_key yazmayı. Kurulum maliyeti: Bir kez, 15 dakika. Dikkat edilmesi gereken nokta: aşağıda açıklanan güncelliğini yitirmiş multiplexing soketleri.

Bu ölçekte yazılıma ihtiyacınız yoktur; halihazırda yapılandırdığınız istemciye ihtiyacınız vardır. ~/.ssh/config her sunucuyu tek kelimelik bir isme dönüştürür ve yönlendirmeyi bir daha düşünmenize gerek kalmayacak şekilde kodlar:

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 işi halleder. ProxyJump bağlantıları tek bir adımda bir bastion üzerinden yönlendirir, böylece bir kafeden yapılan ssh db1 işlemi bastion üzerinden şeffaf bir şekilde tünellenir — agent forwarding gerekmez, ProxyCommand komutlarına ihtiyaç duyulmaz ve özel sunucuların genel SSH portlarına ihtiyacı yoktur (bu konu kesişen bölümlerde daha detaylı ele alınacaktır). ControlPersist ile birlikte kullanılan ControlMaster auto, bağlantıları tek bir TCP oturumu üzerinden multiplex eder; böylece aynı ana makineye yapılan ikinci ve sonraki tüm ssh, scp veya rsync işlemleri, yeniden müzakere etmek yerine anında bağlanır — bu fark, Ansible devreye girdiğinde belirginleşir. 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ı işlevini yitirdikten sonra açık kalabilir ve iki hata modu birbirinden farklı görünür. Sunucu yeniden başlatıldığında veya Wi-Fi bağlantısı koptuğunda, ana süreç henüz fark etmediği ölü bir TCP oturumunu tutmaya devam eder ve bir sonraki ssh web1, hiçbir yere çıkmayan bir sokette sessizce asılı kalır. Ayrı bir durum olarak, sshd bağlantı başına oturum sayısını 10 ile sınırlar (sshd_config içinde MaxSessions), bu nedenle bir ana makineye yapılan on birinci multiplex edilmiş oturum şu hatayı verir:

mux_client_request_session: session request failed: Session open refused

Her iki durumun çözümü aynıdır: ssh -O exit web1 ana süreci sonlandırır ve bir sonraki bağlantı yeni bir oturum başlatır. Ara sıra 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ışmaktadır, ancak multiplex edilmemiştir.

Bu ölçekte iki yardımcı araç vardır. Her sunucudaki tmux, nohup işleminin, Wi-Fi koptuğunda iş kaybının ve "Dizüstü bilgisayarımı kapatamam, bir taşıma işlemi sürüyor" durumunun yerini alır. Kurulum maliyeti: sudo apt install -y tmux, iki dakika, artı tmux new -s work ve tmux attach -t work kas hafızası. Dikkat edilmesi gereken nokta iç içe geçmedir: tmux içinde tmux kullanmak prefix tuşunuzu yutar; bu nedenle ya sunucuda ya da dizüstü bilgisayarda çalıştırın, her ikisinde birden değil. Uzun süreli agent oturumları çalıştırıyorsanız bu durum iki kat daha önemlidir — bu, oturumun SSH bağlantısından daha uzun sürmesi gereken bir VPS üzerinde tmux içinde Claude Code çalıştırma ile aynı desendir.

Paylaşılan bir alias dosyası, her makinede en sevdiğiniz on iki tek satırlık komutu tekrar yazmanın yerini alır. Bir .bash_aliases dosyasını git reposunda tutun ve her sunucuya çekin. Dikkat edilmesi gereken nokta: dosyayı repoda düzenlemek yerine doğrudan bir sunucuda düzenlediğiniz anda dosya senkronizasyonu bozulur — bu durum, bir sonraki aşamanın neden var olduğunu anlamanız için ilk deneyiminiz olacaktır.

5 ile 20 sunucu arası: kod olarak konfigürasyon veya drift galip gelir

Beş sunucunun ötesinde, "her makinede tek tek yaparım" yaklaşımı bir yöntem olmaktan çıkar ve kendinize söylediğiniz bir yalan haline gelir. Bu seviyedeki tüm araçlar aynı düşmana karşı savaşır: drift.

Ansible, hostname'ler üzerinde dönen shell döngülerinin, üç adım geride kalmış "yeni sunucu kurulumu" başlıklı wiki sayfalarının ve web3'e 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 — laptopunuzda veya bir yönetim makinesinde sudo apt install -y ansible (apt size eski bir Ansible sürümü verir, bu buradaki her şey için uygundur; tutorial'daki pipx yolu güncel sürümleri sağlar), sunucularda agent bulunmaz, her şey halihazırda oluşturduğunuz SSH konfigürasyonu üzerinden çalışır. Bu sayfadaki en büyük tekil yükseltmedir ve tam anlatım Ansible ilk playbook tutorial içeriğindedir; işlevsel hale getiren envanter 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ına komut gönderdiği için, bir önceki bölümde yazdığınız ~/.ssh/config zaten geçerlidir — web1 gibi sadece isimlerden oluşan bir envanter, hiçbir değişken olmadan çalışacaktır. Yukarıdaki değişkenler ise envanteri kendi kendine yeten hale getirir; bu, envanteri laptopunuz olmayan bir makineden çalıştırdığınız gün avantaj sağlar.

ansible all -i inventory.ini -m ping ile test edin; doğru sonuç her host için yeşil renkte "ping": "pong" yazdırır. Karşılaşacağınız ilk hata şu şekildedir:

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 hata verir. Her zaman önce SSH sorununu çözün; Ansible, altındaki katman kadar sağlıklıdır. Bunun dışındaki tek püf noktası: Ansible her iki uçta da Python gerektirir, bu nedenle gerçekten minimal bir imaj /usr/bin/python3: not found sorusuna yanıt verebilir — bir apt install python3 ile bir daha sizi rahatsız etmez.

unattended-upgrades, N sunucuya güvenlik yamalarını uygulayan kişi olarak sizin yerinizi alır. Standart Ubuntu Server 24.04 bunu önceden yüklü olarak sunar ve normalde güvenlik güncellemeleri için zaten etkinleştirilmiştir, bu nedenle buradaki görev 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 cloud imajları bunu kapalı olarak sunar ve eğer sizinkinde kapalıysa sudo dpkg-reconfigure -plow unattended-upgrades bu dosyayı yeniden yazar. Kurulum maliyeti: sunucu başına kontrol için iki dakika veya tüm sunucular için tek bir Ansible görevi. Püf noktası: varsayılan olarak asla yeniden başlatma yapmaz, bu nedenle çekirdek güvenlik güncellemeleri siz yapana kadar yarı uygulanmış halde bekler — özel unattended-upgrades kılavuzu otomatik yeniden başlatmaları, nelerin yamalanacağını seçmeyi ve logları okumayı kapsar.

Merkezi izleme, bir müşteriden öğrenmekten (ki bu şimdiye kadar icat edilmiş en pahalı izleme sistemidir) daha iyidir. Ne zaman kullanılacağına dair iki araç ve iki satır: Uptime Kuma "çalışıyor mu?" sorusuna yanıt verir — HTTP, TCP ve ping kontrolleri ile her şeye uyarı gönderir ve Docker üzerinde on dakika sürer; Zabbix "çökmek üzere mi?" sorusuna yanıt verir — her host üzerindeki bir agent aracılığıyla disk, bellek ve CPU trendlerini takip eder — ve dürüst olmak gerekirse bir öğleden sonra sürer. 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 püf noktası yerleşimdir ve bu o kadar önemlidir ki aşağıdaki hatalar bölümüne yol açar.

Bir web paneli, sadece mecbur kalırsanız. Webmin, Ubuntu'nun dosyaları nerede tuttuğunu hatırlama zorunluluğunu ortadan kaldırır ve karma yetenekli bir ekip veya yılda sadece iki kez dokunacağınız bir sunucu için gerçekten kullanışlıdır; kurulum on dakikadır. Püf noktası, port 10000 üzerinden dinleme yapan, root yetkisine eşdeğer bir web uygulaması olması ve internetin sürekli onu taramasıdır. Eğer çalıştıracaksanız, onu localhost'a veya bir VPN adresine bağlayın — asla halka açık bir arayüzde 0.0.0.0 adresine bağlamayın. Ve eğer SSH yavaş hissettirdiği için bir panele yöneliyorsanız, önce önceki bölümü tekrar okuyun; ~/.ssh/config artı Ansible, bir kez yapılandırıldıktan sonra her türlü panelden daha hızlıdır.

20+ sunucu: bu kılavuzun bittiği nokta

Yirmi sunucunun üzerine çıkıldığında bir filo yönetiliyor demektir ve araç zinciri değişir: sunucuların kendisi yeniden oluşturulabilir olsun diye Terraform veya OpenTofu; bir sunucu onarılmak yerine tek kullanımlık olsun diye cloud-init veya golden images; dizüstü bilgisayardan yapılan push işlemleri ölçeklenemediği için Ansible'ı çalıştıran pull-tabanlı konfigürasyon veya CI pipeline'ları ve gerçek bir secrets management gereklidir. Ansible tek başına yirmi sunucuda hata vermez; birçok işletme bunu yüzlerce düğüm üzerinde çalıştırır; ancak çevresindeki uygulamalar sağlamlaştırılmalıdır ve bu konu bu sitedeki içerikten farklı bir makaledir. 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 halihazırda sahip olduğunuzu varsaydığı unsurlardır.

Kaydedilmeyen katman

Her filo büyüklüğü için geçerli olan dört uygulama mevcuttur; bunların atlanması, sunucu sayılarının olduğundan daha ağır hissedilmesine neden olur.

Bir envanter dosyası — basit bir metin dosyası bile olsa. Üç sunucunuz olduğu anda şunları kaydedin: isim, IP, sağlayıcı, üzerinde ne çalıştığı ve neden var olduğu. Bir git reposundaki servers.md yeterlidir; yukarıdaki Ansible envanteri daha iyidir çünkü yürütülebilir bir dokümantasyondur. Yerine geçtiği durum: Saat 02:00'deki "bekle, 10.0.0.40 nedir?" sorusu. Kurulum maliyeti: on dakika. Kritik nokta: Bu yöntem, yalnızca sunucu oluşturma işlemi ile satır ekleme işlemi aynı anda yapıldığında işe yarar; bunlar asla iki ayrı adım olmamalıdır.

Temel hijyen: rotasyon hemen, SSH CA ise sorun çıktığında. Anahtarlarınızın nerede bulunduğunu 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 ve geçmişini takip edemeyeceğiniz kadar eski olan her şeyi rotasyona tabi tutun. Bir SSH sertifika otoritesi — statik anahtarlar yerine kısa ömürlü imzalı sertifikalar — profesyonel çözümdür; ancak dürüst tavsiye, on sunucunun altındayken Ansible aracılığıyla disiplinli authorized_keys yönetiminin, %90 faydayı %10 prosedürle sağlayacağıdır.

Yirmi değil, tek bir giriş yolu. Her açık SSH portu, saldırı yüzeyinin N ile çarpılmasıdır. Ölçeklenebilir model: tek bir bastion host — veya daha iyisi, kontrol ettiğiniz bir VPS üzerinde WireGuard VPN — ve diğer tüm sunucuların SSH servisinin yalnızca özel adrese (private address) bağlı olması. Yukarıdaki konfigürasyondaki ProxyJump satırları zaten bu yapıyı varsaymaktadır. Kamuya açık kalması gereken her şey için fail2ban kullanımı bir zorunluluktur. Kurulum maliyeti: bir kez, bir saat. Kritik nokta: Port 22'yi her yerde kapatmadan önce, yedek planınızın (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, sadece bir hipotezdir. Hangi mekanizmayı kullanırsanız kullanın — sağlayıcı snapshot'ları, restic veya ikinci bir kutuya rsync — asıl önemli olan araç, bir sunucuyu yeni bir VPS üzerine geri yüklediğiniz ve sistemin açılıp hizmet verdiğini onayladığınız takvim kaydıdır. On beş yıllık barındırma tecrübemde duyduğum her yedekleme felaket hikayesi, "yedeklerimiz vardı" ifadesini içerir.

Hatalar

Çoklu sunucu ölçeğindeki başarısızlık nedenları araç hataları değildir; bunlar alışkanlıklardır. Dört temel hata, neredeyse tüm sorunların kaynağını oluşturur.

Snowflake servers. Her sunucu manuel olarak yapılandırılmıştır, birbirinden farklıdır ve kimse sunucuyu yeniden kuramaz. Bu durum bir disk arızası sırasında fark edilir. Çözüm basittir: Her değişiklik Ansible üzerinden yürütülmelidir — veya en azından envanter dokümanındaki ilgili sunucu bölümüne eklenmelidir — bu öğleden sonra notlardan yeniden kurulamayan her sunucu, vadesi sizin tarafınızdan belirlenemeyen bir teknik borçtur.

"Geçici" firewall boşlukları. ufw allow 5432 ile bir hata ayıklama işlemi yapılır 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 nedeni olmayan tüm kuralları silin. Eğer bir kural gerçekten geçiciyse, ilgili ufw delete tmux oturumu kapatılmadan önce aynı pencereye kaydedilmelidir.

İzleme sisteminin izlenen sunucuda barındırılması. Eğer Uptime Kuma izlediği sunucu üzerinde çalışıyorsa, "her şey çöktü" uyarısı veren sistem de çökmüş demektir — dünyanın en verimsiz veri merkezi yapısının daha küçük ve komik bir versiyonunu inşa etmiş olursunuz. İzleme sistemi farklı bir hata alanında (failure domain) bulunmalıdır: farklı bir sağlayıcıdaki ucuz bir VPS klasik çözümdür veya en azından izleyiciyi izleyen harici bir ücretsiz servis kullanılmalıdır.

Her yerde Root SSH kullanımı. Tüm sistem genelinde paylaşılan tek bir root anahtarı, bir dizüstü bilgisayarın sızdırılması durumunda tüm sistemin ele geçirilmesi anlamına gelir ve kimin ne yaptığını gösteren bir denetim izi bulunmaz. Her host üzerinde kişiye özel kullanıcılar, sudo ve /etc/ssh/sshd_config içindeki PermitRootLogin no kullanılmalıdır — bu işlem, bir akşam boyunca komut yazmak yerine üç satırlık bir Ansible görevidir.

Sistem ölçeği birkaç sunucuyu geçtiğinde, ilk Ansible playbook'unuz tekrarlanan işleri otomatikleştirir.

FAQ

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

2 ile 5 sunucu için, iyi yazılmış bir ~/.ssh/config ve tmux kullanımı, kurulabilecek tüm araçlardan daha etkilidir. Yaklaşık beş sunucudan itibaren standart çözüm Ansible'dır: agentless yapısı, ücretsiz olması, mevcut SSH üzerinden çalışması ve sunucu kurulumunu git üzerindeki dosyalara dönüştürmesi ile öne çıkar. Durum bildirimleri için Uptime Kuma eklenebilir; bu kılavuzda adı geçen tüm araçlar ücretsiz yazılımdır.

Ansible olmadan birden fazla Linux sunucusunu yönetebilir miyim?

Evet — beş sunucunun altındaki yapılarda; iyi bir SSH config dosyası, paylaşılan bir alias dosyası ve disiplin yeterlidir; birçok kişi bu şekilde yıllarca çalışmaktadır. Bu sayının üzerine çıkıldığında, Ansible'ın alternatifi "hiçbir şey" değil, belgelenmemiş yapısal bozulmadır (drift): her biri elle hafif farklılıklarla yapılandırılmış on sekiz sunucu. Ansible karmaşık geliyorsa, sadece authorized_keys ve unattended-upgrades yöneten tek bir playbook ile başlayın; bu bile öğrenme sürecine değecektir.

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

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

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

Gerekli değildir — bir panelin yaptığı her şeyi SSH ve Ansible daha tekrarlanabilir şekilde yapar. Webmin, farklı yetenek seviyelerindeki kişilerin aynı makineleri yönettiği durumlarda veya bir sunucuya yapılandırma yollarını yeniden keşfetmenin zaman kaybı olacağı kadar nadir erişilen durumlarda tercih edilir. Eğer bir panel kullanıyorsanız, onu root yetkisine 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?

Manuel yönetimle, kalite on sunucunun altında düşer. Yapılandırmanın kod olarak kullanılması (config as code), otomatik yamalama ve merkezi izleme ile dikkatli bir kişi, yarı zamanlı bir iş olarak 20 ile 50 sunucuyu yönetebilir; burada kısıtlama rutin bakım değil, yeni bir şeylerin ne sıklıkla bozulduğüdür. Önemli olan sayı, yönetici başına düşen sunucu sayısı değil, yönetici başına düşen "snowflake" (benzersiz/farklılaşmış yapı) sayısıdır: bu sayıyı sıfıra yakın tutarsanız üst sınır oldukça yüksektir.