Öne Çıkanlar
- Canlı sunucuda tek komutla yerinde yükseltme risklidir; en güvenli yol temiz bir CentOS 8/AlmaLinux sunucu kurup migration yapmaktır.
- Geçiş öncesi kapsamlı kaynak ve log izlemesi (CPU, RAM, I/O, network) yap; plansız geçişler en büyük hatadır.
- Firewall, SSH sertleştirmesi ve repo uyumluluğu gibi altyapı detayları yükseltme sonrası erişim ve stabilite için kritik önemdedir.
- PHP ve veritabanı sürümlerinde “destek süresi devam eden” ve uygulamanın resmi olarak desteklediği seviyeleri tercih et; önce staging ortamında test et.
- Tam yedek, test ortamı ve kontrollü cutover planı olmadan geçiş yapma; rollback imkanı her zaman hazır olmalı.
CentOS 7’den 8’e Yükseltme Hakkında Bilmeniz Gerekenler
Önce şu soruyu netleştirelim: Neden CentOS 7’den 8’e yükseltme derdine girelim? Çünkü eski bir Linux sürümünü çalıştırmaya devam etmek, kapısı kilitlenmeyen bir ofiste kasa saklamaya benziyor. Çalışır mı? Çalışır. Güvenli mi? Çok tartışılır.
CentOS 7 artık ana akım destek sürecinin dışına çıkıyor; paketler güncellenmiyor, güvenlik yamaları gecikiyor veya hiç gelmiyor. Özellikle internete açık bir VDS veya fiziksel sunucu kullanıyorsan, bu ciddi bir risk. CentOS 8 (veya artık çoğu kullanıcının tercih ettiği AlmaLinux / Rocky Linux gibi RHEL tabanlı klonlar) daha güncel bir kernel, modern kütüphaneler, yeni nesil PHP ve veritabanı desteği sağlıyor.
Burada önemli bir efsaneyi de kırmak gerekiyor: “In-place upgrade yaparsam (7’den 8’e yerinde yükseltme), her şey eskisi gibi ama daha güncel çalışır.” Hayır, iş öyle yürümüyor. Evet, bazı araçlarla yerinde yükseltme yapmak mümkün, ancak:
- Paket bağımlılıkları çatışabilir.
- cPanel/DirectAdmin/Plesk gibi paneller bozulabilir.
- Özel derlenmiş servisler (custom Nginx, custom PHP, kernel modülleri) patlayabilir.
Aslında durum tam olarak şöyle: Üretim ortamında, “tek tıkla yükseltme” genelde kağıt üzerinde güzel görünen ama pratikte riskli bir hayal. En sağlıklı yaklaşım, yeni bir CentOS 8 / AlmaLinux sunucu hazırlayıp, servisleri ve veriyi oraya taşımak (migration). Bu sinir bozucu gelebilir ama uzun vadede hem daha temiz hem daha tahmin edilebilir.
Bu arada, performansınızı artırmak için Sunucu sayfamızdaki diğer çözümlere de bakabilirsiniz.
Kaynak Yönetimi – Limitleri Zorlamayin
CentOS 7’den 8’e yükseltme planı yaparken herkes “versiyon” konuşuyor ama işi patlatan çoğu zaman kaynak yönetimi oluyor. Şöyle düşünün: Aynı donanım üzerinde daha yeni bir OS ve daha yeni yazılımlar çalıştıracaksın. Bunların bir kısmı daha verimli, ama bir kısmı da daha aç gözlü olabiliyor.
İşin püf noktası şurada: Geçiş öncesinde mevcut sunucunun yük profilini çok iyi okuman lazım. En az 24 saatlik top, htop, iostat, vmstat gözlemi, hatta mümkünse netdata veya benzeri bir izleme aracı kullanmak hayat kurtarır. CPU spike’ları nerede oluyor? RAM tavan yapıyor mu? Disk I/O kuyrukları ne durumda? Bunları bilmeden yükseltme yapmak, gözleri bağlı arabayı uzun yola çıkarmaya benzer.
“Aşırı kaynak kullanımı” uyarısı geldiğinde panik yapmadan önce bakacağın ilk yer çoğu zaman log dosyaları olmalı. Özellikle:
/var/log/messages/var/log/dmesg- Web sunucusu logları:
/var/log/httpd/veya/var/log/nginx/ - Veritabanı logları:
/var/log/mysqld.logveya/var/log/mariadb/mariadb.log
Genelde kullanıcılarımızdan duyduğumuz en büyük şikayet şu oluyor: “CPU %100, sunucu çakılı, kesin DDoS yiyorum.” Sonra bakıyoruz, tek bir bozuk sorgu tüm MySQL’i kilitlemiş. Yani her yüksek kaynak tüketimi saldırı değildir; bazen kendi kodun seni sabaha kadar uğraştırır.
Geçiş planında şunu da unutma: Eğer daha modern bir PHP-FPM yapılandırmasına geçeceksen, pm.max_children, pm.max_requests gibi ayarları körü körüne artırma. RAM’e göre hesaplamak gerek. Örneğin 2 GB RAM’li bir makinede her PHP süreci ortalama 40-60 MB tüketiyorsa, 50-60 process açmak zaten sunucuyu göçertir. Limitleri deneyerek, küçük küçük artırarak git.
Guvenlik Duvari ve Port Ayarlari
CentOS 7’den 8’e yükseltme sonrası en çok kafaları karıştıran kısım genelde firewall oluyor. firewalld ile iptables geçişleri, varsayılan zone ayarları, SELinux politikaları derken “Sunucu çalışıyor ama dışarıdan hiçbir şey erişemiyor” senaryosuyla çok karşılaşıyoruz.
Şöyle düşünün: Dış dünyaya açık her port, sunucuda açık bir pencere. Önemli olan, gerçekten nefes alman gereken pencereleri açık bırakmak, gereksiz olanları kapatmak. Temel mantık:
- SSH (22 veya custom port): Mecbursun, ama mutlaka:
- Port değiştir (root brute force saldırılarının %80’i default 22’yedir).
- Şifreli giriş yerine mümkünse sadece SSH key ile girişe izin ver.
- Fail2ban veya benzeri bir araçla brute force denemelerini engelle.
- FTP: Dürüst olayım, klasik FTP mümkünse hiç kullanma. SFTP veya FTPS tercih et. Passive port aralıklarını ve firewall izinlerini net tanımla.
- Panel portları (2083, 2087, 8443 vb.): Sadece belirli IP’lere açmayı düşün. Herkese açık bir cPanel/WHM portu, saldırganlar için davetiye gibi.
- Veritabanı portları (3306, 5432, vb.): Uygulama ile aynı sunucudaysan, dış dünyaya hiç açma. Sadece localhost.
CentOS 8 tarafında firewalld ile çalışıyorsan, mümkün olduğunca “service” bazlı tanımlar kullanmak işleri temiz tutar. Örneğin:
firewall-cmd --permanent --add-service=httpfirewall-cmd --permanent --add-service=https
Sonrasında firewall-cmd --reload ile uygulayıp test et. Panel, SSH ve veritabanı bağlantılarını her değişiklikten sonra tek tek denemek, ileride çıkacak garip “Bağlantı Zaman Aşımı” sorunlarını daha erken yakalamanı sağlar.
Yazilim Uyumlulugu ve PHP/Veritabani Secimi
CentOS 7’den 8’e yükseltme denilince çoğu kişinin aklına hemen şu soru geliyor: “Madem yükseltiyoruz, her şeyin en son sürümünü kuralım mı?” Cevap: Her zaman değil.
En güncel sürüm her zaman en iyisi değil; özellikle de üretim ortamında. Şöyle düşünün: Uygulaman WordPress, yanında bir iki eklenti, belki bir de özel yazılmış bir entegrasyon var. PHP 7.4 ile sorunsuz çalışıyor. Sen bir anda “PHP 8.2 çıkmış, ona geçelim” dersen, bazı eski eklentiler patlayabilir. Aynı şey MySQL/MariaDB için de geçerli.
İşin dengesi şu:
- Güvenlik açısından destek süresi devam eden bir sürüm kullan.
- Uygulamalarının resmi olarak desteklediği en yüksek sürüme çık ama daha yukarıya atlama.
- Önce staging/test ortamında dene, sonra canlıya al.
Veritabanı tarafında sana küçük ama altın değerinde bir kural: “Önce indeks, sonra donanım.” Site yavaşladığında herkes önce CPU, RAM, NVMe konuşuyor. Evet, bunlar önemli ama düzgün indexlenmemiş bir tabloyu dünyanın en güçlü sunucusuna da koysan, karmaşık sorgularda yine bekleyeceksin. Özellikle:
- Sıklıkla WHERE veya JOIN yapılan kolonların index durumunu kontrol et.
- Gereksiz
SELECT *kullanma; gerçekten ihtiyacın olan alanları seç. - Uzun süren sorguları
slow_query_logile tespit et, iyileştir.
PHP için de aynı mantık geçerli. PHP-FPM + OPcache + doğru bir cache (Redis/Memcached veya uygulama cache’i) üçlüsü, donanımı büyütmekten önce masaya gelmeli.
Yapilandirma ve Yonetim: Adim Adim
| Özellik | Detay |
|---|---|
| Hizmet Türü | VDS / Cloud Sunucu |
| Hedef Kitle | Geliştiriciler, DevOps, Orta-Ölçekli Projeler |
| Zorluk Seviyesi | İleri |
| Öne Çıkan Özellik | Güvenlik ve Uzun Vadeli Stabilite |
Uygulama: Kurulum ve Yayina Alma
Şimdi gelelim işin pratiğine. Terminali açın, şu komutu girin demiyorum ama mantık şu sırayla ilerlemeli:
- Yedek al: Tam yedek olmadan bu işe girme. Dosyalar + veritabanları + eğer panel kullanıyorsan panelin kendi backup sistemi. Mümkünse harici bir sunucuya veya storage alanına at.
- Yeni ortamı hazırla: Ya doğrudan CentOS 8, ya da güncel ve RHEL uyumlu bir dağıtım (örneğin AlmaLinux 8). Temiz bir kurulum yap. Eğer yönetimli bir çözüm istiyorsan, hazır optimize edilmiş Cloud Sunucu paketlerine bakmak işi çok hızlandırır.
- Temel yapılandırma:
- Hostname, timezone, locale ayarları.
- SSH güvenliği (port, key, fail2ban).
- Güncelleme kanalları (yum/dnf repo’ları).
- Servisleri kur: Web sunucusu (Apache/Nginx/LiteSpeed), PHP-FPM, veritabanı (MariaDB/MySQL/PostgreSQL), cache sistemi (Redis vb.). Burada eski sunucudaki versiyonlara yakın ama desteklenen sürümleri seç.
- Config dosyalarını taşı ve uyumlandır: Eski sunucudaki
httpd.conf,nginx.conf,php.ini,my.cnfgibi dosyaları birebir kopyalamak yerine, yenide oluşturulan dosyalarla karşılaştır ve sadece gerekli ayarları taşı. Çünkü CentOS 8 tarafında bazı default yollar ve modüller farklı olabilir. - DNS ve SSL tarafını planla: Domainlerin hangi IP’yi göstereceği, hangi sitenin hangi sertifikayı kullanacağı belli olmalı. Gerekirse yeni bir SSL sertifikası planla veya Let’s Encrypt entegrasyonunu test et.
- Test ortamı: Canlı DNS’leri çevirmeden önce, hosts dosyası ile yalnızca kendi bilgisayarından yeni sunucuya erişerek test et. Tüm sayfalar, formlar, admin panelleri düzgün çalışıyor mu bak.
- Canlı geçiş (cutover): Trafiğin yoğun olmadığı bir zaman seç, DNS’i yeni IP’ye çevir. Eski sunucuyu bir süre daha “read-only” yönergelerle beklet (en azından hızlı rollback için).
Genelde bu mantıkla hazırlanmış bir geçiş, tahmin edildiği kadar sancılı olmuyor. Çünkü bir kere planı oturttuktan sonra, komutlar sadece detay oluyor.
Sik Karsilasilan Sorunlar ve Pratik Cozumler
| Sorun | Muhtemel Neden | Çözüm |
|---|---|---|
| Site Yavaş Açılıyor | Zayıf önbellekleme veya yüksek sorgu sayısı | Redis/Litespeed Cache kurulumu yapın |
| Bağlantı Zaman Aşımı | Firewall engeli veya hatalı DNS | Port izinlerini kontrol edin |
| Mail Servisi Çalışmıyor | SMTP portu kapalı veya reverse DNS eksik | 25/587 portlarını açın, rDNS ve SPF kayıtlarını yapılandırın |
| Panel Açılmıyor | Panel portu firewall tarafından engellenmiş veya servis başlatılmamış | İlgili panel servisini kontrol edin, portu firewalld’da açın |
Ek olarak, CentOS 7’den 8’e yükseltme sırasında sıkça gördüğümüz problemlerden biri de repo uyumsuzlukları. Eski üçüncü parti repo’lar (EPEL, Remi vb.) yeni sürümde farklı URL’lere taşınmış olabiliyor. Bu durumda:
- Önce eski repo dosyalarını geçici olarak devre dışı bırak.
- Yeni CentOS 8’e uygun repo paketlerini resmi kaynaktan kur.
- Ardından
dnf clean allve tam bir update çalıştır.
Sikca Sorulan Sorular
CentOS 7’den 8’e yükseltme güvenli mi?
Doğru yaparsan, evet. Ama “doğru yapmak”tan kasıt, canlı sunucuda tek komutla yerinde yükseltme değil. Yeni bir sunucu kurup, test edip, sonra kontrollü migration yapmak. Yedeksiz, testsiz geçiş güvenli değil; bunu net söyleyebilirim. Ayrıca sunucu internete açık çalışıyorsa, mutlaka güvenlik güncellemeleri, firewall ve SSH sertleştirmesi yapılmış olmalı.
Fiyat/Performans dengesini nasıl kurarım?
Tıpkı bir araba motoru gibi, sunucular da yüksek devirde (trafikte) doğru soğutmaya (kaynağa) ihtiyaç duyar. En pahalı sunucu her zaman en iyi çözüm değil. Genelde şöyle bir yol izliyoruz:
- Önce mevcut sitenin profilini çıkart (trafik, CPU/RAM kullanımı, disk I/O).
- Önce yazılım optimizasyonu yap (cache, PHP-FPM, veritabanı indexleri).
- Buna rağmen sınırda kalıyorsan, o zaman bir üst seviyeye geç (daha güçlü hosting yerine VDS, VDS yerine gerekirse cloud sunucu).
Yani önce yazılım, sonra donanım. Sırayı tersine çevirenler genelde boş yere daha çok para ödüyor.
Taşıma (Migration) işlemi zor mu?
Tek başına, hiç dokümantasyon okumadan ve test etmeden yapmaya kalkarsan zor. Ama planlı gidersen, iş ciddi anlamda kolaylaşıyor. Bizim tarafta, Bilhost’ta şunu çok yaşıyoruz: Kullanıcı “CentOS 7’den 8’e yükseltme yapmak istiyorum ama sunucuyu çökertmekten korkuyorum” diyor, beraber bir plan yapıyoruz, biz migration sürecini yönetiyoruz, kullanıcı sadece test ediyor.
Özellikle panel tabanlı ortamlarda (cPanel, Plesk, DirectAdmin), çoğu zaman panelin kendi transfer araçları ve bizim tarafımızdaki otomasyonlar sayesinde, siteleri ve mail hesaplarını yeni sunucuya taşımak sandığından daha kolay oluyor. İstersen yeni bir VDS veya cloud sunucu üzerinde, yapılandırma ve taşıma konusunda da yanındayız.
Sonuc
İşin özü şu: CentOS 7’den 8’e yükseltme, “geç mi kalsam, hiç mi dokunmasam?” diye erteledikçe büyüyen bir iş gibi görünür. Ama adımlarını doğru kurguladığında, aslında sadece altyapını geleceğe taşımış oluyorsun. Güvenlik yamaları, daha güncel yazılımlar, daha sağlıklı bir performans tabanı… Hepsi bu aşamada kazanılıyor.
Teknoloji ne kadar karmaşık görünürse görünsün, doğru yapılandırma hayat kurtarır. Yedeksiz iş yapma, test ortamını ihmal etme, firewall ve kaynak yönetimini de “sonra bakarım” diye erteleme. Eğer bir yerde takılırsan biz buradayız, yorumlarda sorularını bekliyorum.
