Nginx nedir sorusuna kısa cevap şudur: İstemciden gelen HTTP isteklerini karşılayan, statik dosyaları doğrudan sunabilen, başka bir sunucuya yönlendirme yapabilen ve FastCGI ile çalışan bir uygulamaya bağlantı kurabilen bir web sunucusudur. Bir site açıldığında tarayıcı ile uygulama kodu arasında durabilir, isteğin nerede karşılanacağına karar verir ve cevabı istemciye iletir.
Bu yazı, Nginx'i bir kurulum kılavuzu gibi değil, karar verme mantığı üzerinden anlatır. Hangi isteğin Nginx katmanında biteceğini, hangisinin uygulamaya geçeceğini ve yapılandırma dosyasındaki blokların bu kararı nasıl yönlendirdiğini göreceksiniz.
Nginx nedir ve hangi ihtiyacı karşılar?
Bir web projesinde her istek aynı türde değildir. Kimi istek bir görsel, CSS dosyası ya da indirilebilir bir belge ister. Kimi istek bir giriş formunun işlenmesini, bir sorgunun çalıştırılmasını ya da dinamik bir sayfanın üretilmesini gerektirir. Nginx, bu ayrımı yönetmek için kullanılan katmanlardan biridir.
Resmi başlangıç kılavuzuna göre Nginx; statik içeriği sunabilir, proxy sunucusu olarak çalışabilir ve FastCGI ile çalışan bir uygulamaya bağlanabilir. Yani üç farklı görev aynı Nginx kurulumunun farklı bölümlerinde tanımlanabilir. Önemli ayrım şudur: Nginx, uygulama kodunu kendisi çalıştırmaz. Dinamik işlem gerektiğinde isteği ilgili uygulamaya iletir ve uygulamadan aldığı cevabı istemciye döndürür.
İstek Nginx'e geldiğinde ne olur?
Süreç, basitleştirilmiş bir akışla şöyle düşünülebilir. Tarayıcı bir adres ister. Nginx önce bu isteğin hangi siteye ve hangi yola ait olduğunu bulur. Ardından ilgili kurala bakar: istenen içerik kendi sunduğu bir dosyaysa dosyayı döndürür, başka bir adrese yönlendirilmesi gerekiyorsa proxy davranışını kullanır, uygulama tarafından üretilmesi gerekiyorsa FastCGI bağlantısı üzerinden uygulamaya sorar.
Burada ters vekil sunucu kavramını doğru anlamak gerekir. Ters vekil sunucu, istemcinin doğrudan uygulama sunucusuyla konuşması yerine araya giren katmandır. İstemci Nginx'i görür; uygulamanın adresi, dili veya iç düzeni istemci tarafında görünmek zorunda değildir. Bu yapı, istekleri tek bir girişte toplamak, farklı hedeflere dağıtmak ve uygulama katmanını sade tutmak için kullanılır.
Somut bir istek örneği
Örnek bir akışı temsilî olarak düşünelim. Aynı site üzerinde üç farklı istek olsun: bir logo görseli, bir yönetim paneli sayfası ve bir form gönderimi. Yapılandırma, logo isteğini dosya sistemindeki ilgili konumdan karşılayacak biçimde yazılabilir. Yönetim paneli ve form gönderimi ise uygulama tarafına iletilebilir. Böylece her istek, niteliğine uygun katmanda sonuçlanır. Bu örnek belirli bir siteye ait değildir; yalnızca karar mantığını göstermek içindir. Bu tür bir kurguyu planlarken web tasarım ve site kurulumu hizmetinden yararlanılabilir.
Ana süreç ve worker süreçleri nasıl çalışır?
Resmi kılavuz, Nginx'in ana süreç ve worker süreçleri ile çalıştığını açıklar. Ana süreç yapılandırmayı değerlendirir ve worker süreçlerini yönetir. İstemci isteklerini asıl işleyen taraf worker süreçleridir. Olay temelli çalışma modeli bu noktada devreye girer.
Olay temelli model, her bağlantı için ayrı ve uzun süre bekleyen ağır bir işlem düzeni kurmak yerine, bekleyen işlemlerin olaylar üzerinden izlenmesi olarak özetlenebilir. Bir worker, bir isteği beklerken tamamen durmak yerine başka olaylarla ilgilenebilir. Bu yaklaşım, çok sayıda eşzamanlı bağlantının daha düzenli biçimde ele alınmasına yardımcı olur. Bu açıklama bir performans sıralaması değildir; yalnızca mimarinin nasıl organize edildiğini anlatır.
Yapılandırma dosyasındaki blok düzeni
Nginx yapılandırması, direktif adı verilen ayarlardan ve bu ayarları gruplayan bloklardan oluşur. Bloklar iç içe geçebilir. Resmi kılavuzda vurgulanan üç bağlam, birbirini kapsayan bir hiyerarşi kurar: `http`, `server` ve `location`.
| Bağlam | Ne için kullanılır? | Temsili karar |
|---|---|---|
| http | Nginx üzerinde çalışan web trafiğine ait genel ayarlar | Bu ayarlar ilgili kapsamdaki trafiğe uygulanır |
| server | Belirli bir site veya alan adı için ayrım | Bu istek hangi siteye ait? |
| location | Site içindeki yol veya istek türü için ayrım | Bu yol dosyadan mı, uygulamadan mı karşılanacak? |
Bu tabloyu yukarıdan aşağıya okumak gerekir. Önce genel web ayarları ele alınır, sonra isteğin hangi siteye geldiği bulunur, en sonda sitenin içindeki yol değerlendirilir. Yanlış anlamanın önüne geçmek için şunu belirtelim: Yukarıdaki üçüncü sütun gerçek bir yapılandırma satırı değildir; kararın yönünü açıklayan sadeleştirilmiş ifadedir. Yollar kuruluma göre değişebilir.
Değişiklikten sonra reload ve restart ayrımı
Yapılandırma değiştirildiğinde yeni ayarların uygulanması için servisin yeniden yüklenmesi veya yeniden başlatılması gerekir. Resmi kılavuz, ana sürecin yapılandırmayı doğrulayabilen bir denetim mekanizmasıyla çalıştığını belirtir. Doğrulama başarısız olursa eski yapılandırmanın korunması mümkündür. Bu nedenle her değişiklikten önce dosyanın hangi kurulumda nerede tutulduğunu ve ilgili komutun o sisteme ait karşılığını doğrulamak gerekir.
- Değiştirilecek dosyanın yedeğini alın.
- Yalnızca ilgili bağlamı düzenleyin; ilgisiz bloklara dokunmayın.
- Kullandığınız kurulumun doğrulama ve yeniden yükleme adımını resmi belgedeki sırayla uygulayın.
- Site adresini, statik bir dosyayı ve uygulamaya giden bir isteği ayrı ayrı deneyin.
- Hata durumunda değiştirdiğiniz bölümü geri alarak eski dosyayı kullanın.
Nginx ile Apache farkını nasıl okumalı?
Bu iki yazılımın karşılaştırılması çoğu zaman tek bir hız yargısına indirgenir. Oysa resmi başlangıç kılavuzunun verdiği bilgiler, doğrudan bir üstünlük iddiası kurmak için yeterli değildir. Daha sağlıklı yaklaşım, görev dağılımındaki farkı anlamaktır.
Apache, dinamik içerik üretiminde uygulama bileşenleriyle daha iç içe bir çalışma düzeniyle bilinir. Nginx anlatısında ise istek karşılama, yönlendirme ve uygulama katmanına bağlantı kurma işlevleri daha belirgin şekilde ayrışır. Hangi yazılımın seçileceği; projenin mevcut altyapısına, ekip bilgisine, uygulama diline, barındırma ortamına ve bakım düzenine göre değişir. Tek bir proje türü için evrensel bir seçim kuralı bu kaynaklardan çıkarılamaz.
Yapılandırmayı öğrenmeden önce bilinmesi gerekenler
Nginx yapılandırması ilk bakışta sade görünür. Blok yapısı okunabilir olduğu için temel mantık kısa sürede anlaşılabilir. Zorluk, sözdiziminden çok kararların sonuçlarını öngörmekte ortaya çıkar. Yanlış yazılmış bir `location` eşleşmesi, isteğin dosyaya mı yoksa uygulamaya mı gideceğini değiştirebilir. Proxy hedefi yanlış yazılırsa istek beklenen uygulamaya ulaşmayabilir.
- Alan adı, site kök dizini ve uygulama adresini önceden netleştirin.
- Statik dosya, yönlendirilecek istek ve uygulamaya gidecek isteği ayrı başlıklar halinde listeleyin.
- Üretim ortamında deneme yapmadan önce ayrı bir test ortamı kullanın.
- Dosya izinleri, güvenlik sertifikası ve ağ erişimi gibi ortam koşullarını yapılandırma dışında da kontrol edin.
- Tam bir üretim yapılandırmasını, ortam doğrulanmadan kopyalayıp kullanmayın.
Kaynaklar
Bu yazıda yararlanılan resmi kaynak: Nginx başlangıç kılavuzu.
