IIS’ten Nginx veya Apache’ye Geçiş Rehberi

Yazar:komut.io ekibi IIS Web Sunucusu Kurulum ve Yönetimi
0 Yorum

Yıllarca IIS üzerinde çalıştıktan sonra bir gün patronunuz gelip “Bu sunucuları Linux’a taşıyoruz” dediğinde ne hissedersiniz? Ben bu geçişi birkaç kez yönettim ve her seferinde farklı dersler çıkardım. Bu yazıda o deneyimleri sizinle paylaşacağım; hem Nginx hem de Apache için pratik, saha testinden geçmiş bir geçiş rehberi hazırladım.

Geçişe Karar Vermeden Önce: Ne Bilmek Gerekiyor

IIS’ten ayrılmak kolay bir karar değil. Özellikle yıllarca üzerine yapılandırma biriktirmiş, onlarca sanal dizin açılmış, IIS Manager’dan tıklaya tıklaya yapılan ayarların altında ne olduğunu kimsenin tam bilmediği ortamlar gerçek bir mayın tarlasıdır. Geçişe başlamadan önce mevcut durumu belgeleyin.

IIS üzerinde hangi sitelerin çalıştığını, hangi uygulama havuzlarının kullanıldığını, SSL sertifikalarının durumunu ve yönlendirme kurallarını çıkarmanın en hızlı yolu PowerShell ile bir envanter almaktır:

# Mevcut IIS sitelerini ve bağlantı noktalarını listele
Import-Module WebAdministration
Get-Website | Select-Object Name, State, PhysicalPath, @{
    Name="Bindings"; 
    Expression={ ($_.Bindings.Collection | ForEach-Object { $_.protocol + "://" + $_.bindingInformation }) -join ", " }
} | Format-List

# Uygulama havuzlarını incele
Get-WebConfiguration "system.applicationHost/applicationPools/add" | 
    Select-Object name, managedRuntimeVersion, managedPipelineMode, processModel | 
    Export-Csv -Path "C:iis_apppool_inventory.csv" -NoTypeInformation

Bu çıktıyı dikkatli inceleyin. Hangi siteler .NET Framework kullanıyor, hangileri sadece statik içerik sunuyor? .NET uygulamalar için geçiş stratejisi çok farklı olacak; onlar doğrudan Nginx/Apache arkasına geçemez, .NET Core’a portlama ya da Mono gibi ek araçlar gerekir. Bu yazıda ağırlıklı olarak statik siteler, PHP uygulamaları ve reverse proxy senaryolarını ele alacağız.

Nginx Kurulumu ve Temel Yapılandırma

Ubuntu veya Debian tabanlı sistemlerde Nginx kurulumu oldukça doğrudan:

sudo apt update && sudo apt install nginx -y
sudo systemctl enable nginx
sudo systemctl start nginx

# Nginx'in çalıştığını doğrula
systemctl status nginx
nginx -v

CentOS/RHEL tabanlı sistemlerde ise:

sudo dnf install epel-release -y
sudo dnf install nginx -y
sudo systemctl enable --now nginx
# Firewall ayarı
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload

Nginx’in yapılandırma dosyaları /etc/nginx/ altında toplanır. IIS’ten gelen birinin ilk şaşırdığı şey bu hiyerarşidir: ana yapılandırma nginx.conf, site bazlı yapılandırmalar ise /etc/nginx/sites-available/ altında tutulur ve /etc/nginx/sites-enabled/ dizinine sembolik link oluşturularak aktif hale getirilir. Bu yaklaşım IIS’teki “site ekleme/kaldırma” mantığına aslında çok benzer, sadece araç grafik değil metin.

IIS Site Yapılandırmasını Nginx’e Çevirmek

Diyelim ki IIS’te şu yapılandırmanız var: www.orneksite.com.tr adresine gelen HTTP trafiği HTTPS’e yönleniyor, kök dizin C:inetpubwwwrootorneksite, custom 404 sayfası mevcut ve /api/ altındaki istekler başka bir sunucuya reverse proxy yapılıyor.

Nginx karşılığı:

# /etc/nginx/sites-available/orneksite.com.tr

server {
    listen 80;
    server_name orneksite.com.tr www.orneksite.com.tr;
    
    # HTTP'yi HTTPS'e yönlendir
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name orneksite.com.tr www.orneksite.com.tr;

    root /var/www/orneksite;
    index index.html index.htm index.php;

    ssl_certificate /etc/ssl/certs/orneksite.crt;
    ssl_certificate_key /etc/ssl/private/orneksite.key;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;

    # Custom 404 sayfası
    error_page 404 /404.html;
    location = /404.html {
        internal;
    }

    # API isteklerini arka sunucuya ilet
    location /api/ {
        proxy_pass http://127.0.0.1:8080/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    # Statik dosyalar için önbellekleme
    location ~* .(jpg|jpeg|png|gif|ico|css|js)$ {
        expires 30d;
        add_header Cache-Control "public, no-transform";
    }

    # Gzip sıkıştırma
    gzip on;
    gzip_types text/plain text/css application/json application/javascript;
}

Yapılandırmayı aktif hale getirip test edin:

sudo ln -s /etc/nginx/sites-available/orneksite.com.tr /etc/nginx/sites-enabled/
sudo nginx -t   # Sözdizimi kontrolü
sudo systemctl reload nginx

nginx -t komutu IIS’te bulunmayan ama hayat kurtaran bir özellik. Yapılandırmayı canlıya almadan önce hataları yakalar. Bunu her değişiklikten sonra çalıştırmayı alışkanlık haline getirin.

IIS URL Rewrite Kurallarını Nginx’e Taşımak

IIS’in en çok kullanılan özelliklerinden biri URL Rewrite modülüdür. Web.config içindeki rewrite kurallarını Nginx’e çevirmek bazen sinir bozucu olabilir ama mantık aynı.

Tipik bir WordPress permalinks ayarı veya MVC routing için IIS’te şöyle bir kural olur:

<!-- IIS web.config içindeki rewrite kuralı -->
<rewrite>
    <rules>
        <rule name="Main Rule" stopProcessing="true">
            <match url=".*" />
            <conditions logicalGrouping="MatchAll">
                <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
                <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
            </conditions>
            <action type="Rewrite" url="index.php?{REQUEST_URI}" />
        </rule>
    </rules>
</rewrite>

Nginx karşılığı çok daha temiz görünür:

location / {
    try_files $uri $uri/ /index.php?$args;
}

location ~ .php$ {
    fastcgi_pass unix:/run/php/php8.1-fpm.sock;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include fastcgi_params;
}

try_files direktifi önce fiziksel dosyayı arar, sonra dizini, bulamazsa son argümana düşer. Bu mekanizma IIS’teki “IsFile/IsDirectory negate” kombinasyonunun ta kendisi.

Apache ile Geçiş: .htaccess Avantajı

Apache, IIS’ten geçiş yapan ekipler için bazen daha az sürtüşme yaratır. Bunun en büyük nedeni .htaccess dosyalarıdır. Eğer uygulamanız zaten Apache’yi hedefleyerek yazılmışsa (WordPress, Drupal, birçok PHP framework buna dahil), büyük ihtimalle .htaccess dosyaları hazır gelir ve IIS’teki web.config kurallarını tekrar yazmak yerine bu dosyaları doğrudan kullanabilirsiniz.

Apache kurulumu:

# Ubuntu/Debian
sudo apt update && sudo apt install apache2 -y
sudo systemctl enable apache2

# Gerekli modülleri etkinleştir
sudo a2enmod rewrite
sudo a2enmod ssl
sudo a2enmod headers
sudo a2enmod proxy
sudo a2enmod proxy_http
sudo systemctl restart apache2

IIS’teki site yapılandırmasının Apache VirtualHost karşılığı:

# /etc/apache2/sites-available/orneksite.com.tr.conf

<VirtualHost *:80>
    ServerName orneksite.com.tr
    ServerAlias www.orneksite.com.tr
    Redirect permanent / https://orneksite.com.tr/
</VirtualHost>

<VirtualHost *:443>
    ServerName orneksite.com.tr
    ServerAlias www.orneksite.com.tr
    DocumentRoot /var/www/orneksite

    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/orneksite.crt
    SSLCertificateKeyFile /etc/ssl/private/orneksite.key

    # .htaccess dosyalarının çalışmasına izin ver
    <Directory /var/www/orneksite>
        AllowOverride All
        Require all granted
    </Directory>

    # API reverse proxy
    ProxyPreserveHost On
    ProxyPass /api/ http://127.0.0.1:8080/
    ProxyPassReverse /api/ http://127.0.0.1:8080/

    # Güvenlik header'ları
    Header always set X-Frame-Options "SAMEORIGIN"
    Header always set X-Content-Type-Options "nosniff"
    Header always set Strict-Transport-Security "max-age=31536000"

    ErrorLog ${APACHE_LOG_DIR}/orneksite_error.log
    CustomLog ${APACHE_LOG_DIR}/orneksite_access.log combined
</VirtualHost>

Siteyi aktif edin:

sudo a2ensite orneksite.com.tr.conf
sudo apache2ctl configtest   # nginx -t'nin Apache karşılığı
sudo systemctl reload apache2

SSL Sertifikası Geçişi

IIS’teki SSL sertifikalarını Linux’a taşımak sıklıkla atlanan bir adım. IIS sertifikaları .pfx formatında saklar. Bu dosyayı Nginx veya Apache’nin beklediği formata dönüştürmek gerekir:

# PFX'ten private key ve sertifika ayıkla
openssl pkcs12 -in windows_sertifika.pfx -nocerts -nodes -out orneksite.key
openssl pkcs12 -in windows_sertifika.pfx -nokeys -out orneksite.crt

# Dosyaları doğru konuma taşı
sudo cp orneksite.key /etc/ssl/private/
sudo cp orneksite.crt /etc/ssl/certs/
sudo chmod 600 /etc/ssl/private/orneksite.key
sudo chmod 644 /etc/ssl/certs/orneksite.crt

Eğer sertifikanız bir ara sertifika zinciri içeriyorsa (ki kurumsal ortamlarda genellikle içerir), Nginx için tüm zinciri tek dosyada birleştirmeniz gerekir:

# Sertifika zincirini oluştur
cat orneksite.crt intermediate.crt root.crt > orneksite_chain.crt

Ticari sertifika yerine Let’s Encrypt kullanmak isteyenler için certbot inanılmaz kolaylık sağlar:

sudo apt install certbot python3-certbot-nginx -y
sudo certbot --nginx -d orneksite.com.tr -d www.orneksite.com.tr
# Apache için:
sudo certbot --apache -d orneksite.com.tr -d www.orneksite.com.tr

IIS Log Formatını Nginx/Apache ile Eşleştirmek

Log analizi araçlarınız IIS formatına göre yapılandırılmışsa bu geçiş sizi zorlayabilir. SIEM sistemleri, Splunk veya ELK kurulumları log formatı değişikliğine hassastır.

Nginx’i IIS benzeri log formatıyla yapılandırmak mümkün. /etc/nginx/nginx.conf içindeki http bloğuna ekleyin:

# IIS'e benzer log formatı
log_format iis_style '$remote_addr - $remote_user [$time_local] '
                     '"$request" $status $body_bytes_sent '
                     '"$http_referer" "$http_user_agent" '
                     '$request_time $upstream_response_time';

access_log /var/log/nginx/access.log iis_style;

Bu sayede log analiz araçlarınızı hemen değiştirmenize gerek kalmaz; geçiş sürecinde her iki tarafı da aynı araçlarla izleyebilirsiniz.

Geçiş Sırasında Sık Karşılaşılan Sorunlar

Dosya sistemi büyük-küçük harf duyarlılığı: IIS Windows üzerinde çalıştığından Index.html ile index.html aynı şeydir. Linux’ta değil. Özellikle eski web sitelerinde CSS, JS veya resim referansları büyük-küçük harf uyumsuzluğu nedeniyle kırılabilir. Bu sorunu yakalamak için test ortamında tarayıcı geliştirici araçlarından 404 hatalarını inceleyin.

Windows yol ayraçları: Bazı PHP uygulamaları sabit kodlanmış Windows yolu (C:inetpub...) içerir. Bu değerleri tarama ve değiştirme işini ciddiye alın.

NTFS izinleri vs Linux izinleri: IIS’te IIS_IUSRS grubu dosyalara erişir. Linux’ta web sunucusu genellikle www-data (Nginx/Apache) kullanıcısıyla çalışır. Dosya izinlerini doğru ayarlamak şarttır:

# Web dosyalarının sahipliğini ve izinlerini ayarla
sudo chown -R www-data:www-data /var/www/orneksite
sudo find /var/www/orneksite -type d -exec chmod 755 {} ;
sudo find /var/www/orneksite -type f -exec chmod 644 {} ;

# PHP veya uygulama tarafından yazılması gereken dizinler için
sudo chmod 775 /var/www/orneksite/uploads
sudo chmod 775 /var/www/orneksite/cache

Session ve cache dosyaları: IIS uygulamalarında session’lar çoğunlukla uygulama havuzu bellekte yönetir ya da SQL Server’a yazar. Linux geçişinde session yönetimi mekanizmasını gözden geçirin; dosya tabanlı session kullanıyorsanız dizin izinlerini kontrol edin.

Performans Karşılaştırması ve İzleme

Geçiş sonrası performansı ölçmek için Apache Benchmark veya wrk kullanabilirsiniz. IIS’teki baseline değerlerinizi önceden alın:

# Basit yük testi
ab -n 10000 -c 100 https://orneksite.com.tr/

# Daha gerçekçi test için wrk
wrk -t12 -c400 -d30s https://orneksite.com.tr/

# Nginx durum sayfası (nginx_status modülü ile)
curl http://127.0.0.1/nginx_status

Nginx için hızlı bir durum modülü yapılandırması:

server {
    listen 127.0.0.1:8080;
    location /nginx_status {
        stub_status on;
        allow 127.0.0.1;
        deny all;
    }
}

Bu sayede aktif bağlantılar, toplam istekler ve mevcut worker durumunu anlık izleyebilirsiniz. Bunu Prometheus + Grafana stack’ine bağlamak için nginx-prometheus-exporter oldukça iyi çalışır; ama bu başlı başına ayrı bir yazı konusu.

Geçiş Stratejisi: Sıfır Downtime İçin

En kritik konu geçişi canlıya alırken yaşanan downtime’ı minimize etmektir. Öneririm:

  • Kademeli geçiş yapın: Tüm siteleri bir anda taşımayın. En az kritik siteden başlayın.
  • DNS TTL’i önceden düşürün: Geçişten 48 saat önce TTL değerini 300 saniyeye indirin. Bu şekilde geçiş sonrası sorun çıkarsa hızla geri dönebilirsiniz.
  • Paralel çalıştırın: IIS ve yeni sunucu aynı anda ayakta olsun. DNS’i değiştirdiğinizde birkaç saat her iki sunucuya trafik gelebilir; iki tarafı da izleyin.
  • Her zaman rollback planı hazırlayın: DNS’i eski sunucuya döndürmek 5 dakika sürer. Ama uygulama verilerini (veritabanı, dosya yüklemeleri) eski sunucuyla senkron tutmak daha dikkat ister.

Sonuç

IIS’ten Nginx veya Apache’ye geçiş, doğru hazırlıkla beklenenden çok daha az travmatik bir süreç. Benim tecrübelerime göre geçişlerin çoğunda asıl zaman harcanan nokta teknik yapılandırma değil; mevcut sistemin tam olarak ne yaptığını anlamak oluyor. O yüzden envanter adımını atlamamanızı özellikle vurgularım.

Nginx ve Apache arasındaki tercihe gelince: eğer yüksek trafikli bir ortam ve ince ayar performans optimizasyonu önemliyse Nginx, eğer büyük bir PHP ekosistemi ve .htaccess kolaylığı öncelikse Apache daha uygun olabilir. Birçok modern kurulum ikisini birlikte kullanır; Apache arka planda uygulama sunucusu olarak çalışırken Nginx önde reverse proxy ve statik içerik sunucusu olarak görev yapar.

Geçiş sonrası ilk birkaç gün log’ları düzenli takip edin. Beklenmedik 404’ler, SSL hataları veya yönlendirme döngüleri erken aşamada yakalanırsa çözümü çok kolaydır. Sonrasında Linux web sunucusu yönetiminin IIS’e kıyasla ne kadar şeffaf ve denetlenebilir olduğunu fark edeceksiniz; her şey bir metin dosyasında, versiyon kontrolüne alınabilir, diff’lenebilir ve otomatize edilebilir durumda. Bu özgürlüğe bir kez alıştıktan sonra IIS’e dönmek çok zorlaşıyor.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir