Nginx, internetteki en büyük sitelerin bazılarının yükünü ele almaktan sorumlu yüksek performanslı bir web sunucusudur. Birçok eşzamanlı bağlantıyı idare etmede özellikle iyidir ve statik içerik sunmada mükemmeldir.
Pek çok kullanıcı Nginx’in yeteneklerinin farkında olsa da, yeni kullanıcılar genellikle Nginx yapılandırma dosyalarında buldukları bazı kurallarla karıştırılır.
Yapılandırma dosyası yapısı
directive
Bir seçenek veya parametre değeriyle dolu bir seçenek veya parametre adından oluşur.
context
Aynı zamanda bir directive, ancak bloğunda diğer yönergeleri kapsar, bu yönergeler küme ayraçları içine alınır.
Directive
server_name domain.com www.domain.com; option option or or parameter parameter value
Context
events {
worker_connections 768;
# multi_accept on;
}
directivelerin içerisinde yanlış yazılmış context değerleri olduğunda sistemimiz hata alır. Nginx, yapılandırmayı test ederken bir hata üretecektir. Yazılan directive ve contextlerden sonra ngnxin -t komutunu kullanarak konfigurasyonumuzu kontrol edebiliriz.
sudo nginx -t
Herhangi bir sorun sıkıntı görülmezse servis yeniden başlatılabilir.
sudo systemctl reload nginx
Nginx Yapılandırma Contextleri Anlama
Nginx yapılandırma dosyasında bulunan temel yapıyı kapsayacaktır. Bu dosyanın konumu, yazılımı makinenize nasıl yüklediğinize bağlı olarak değişecektir. Çoğu dağıtım için dosya /etc/nginx/nginx.conf adresinde bulunacaktır. Orada yoksa, /usr/local/nginx/conf/nginx.conf veya /usr/local/etc/nginx/nginx.conf adresinde de olabilir.
Ana yapılandırma dosyasına bakarken dikkat etmeniz gereken ilk şeylerden biri, parantez dizileriyle ({ve} gibi görünen) ağaç benzeri bir yapıda organize edilmiş görünmesidir. Nginx sözlüğünde, bu parantezlerin tanımladığı alanlar, ilgi alanlarına göre ayrılmış konfigürasyon ayrıntılarını içerdikleri için “context” olarak adlandırılır. Temel olarak, bu bölümler, içindeki konfigürasyonların uygulanıp uygulanmayacağına karar vermek için bazı koşullu mantıkla birlikte bir organizasyon yapısı sağlar.
Contextler birbiri içinde katmanlanabildiğinden, Nginx bir düzeyde yönerge mirası sağlar. Genel bir kural olarak, bir yönerge birden çok iç içe geçmiş kapsamda geçerliyse, daha geniş bir bağlamdaki bir bildirim, varsayılan değerler olarak tüm alt bağlamlara aktarılacaktır. Child bağlamları bu değerleri isteğe göre geçersiz kılabilir. Herhangi bir dizi tipi yönergeye yapılan bir geçersiz kılma işleminin, önceki değerin sonuna değil, önceki değerin yerine geçeceğini belirtmek gerekir.
Directives yalnızca tasarlandıkları contextlerde kullanılabilir. Nginx, yanlış context bildirilmiş directive sahip bir yapılandırma dosyasını okurken hata verecektir. Nginx belgeleri, her direktifin hangi bağlamlarda geçerli olduğu hakkında bilgi içerir, bu nedenle emin değilseniz harika bir referanstır.
http://nginx.org/en/docs/dirindex.html
Aşağıda, Nginx ile çalışırken karşılaşmanız muhtemel en yaygın contextleri ele alalım.
Temel Contextler
Ele alacağımız ilk context grubu, Nginx’in hiyerarşik bir ağaç oluşturmak ve ayrık konfigürasyon bloklarının endişelerini ayırmak için kullandığı temel bağlamlardır. Bunlar, bir Nginx konfigürasyonunun ana yapısını oluşturan bağlamlardır.
Ana Context
En genel bağlam, “main” veya “global” bağlamdır. Aşağıdaki gibi görünen tipik bağlam blokları içinde bulunmayan tek bağlam budur:
# The main context is here, outside any other contexts
. . .
context {
. . .
}
Tamamen bu blokların dışında bulunan herhangi bir direktifin “main” bağlamda yer aldığı söylenir. Nginx yapılandırmanız modüler bir şekilde ayarlanmışsa, bazı dosyaların köşeli parantezli bağlamın dışında var gibi görünen, ancak yapılandırma birbirine birleştirildiğinde böyle bir bağlama dahil edilecek talimatlar içereceğini unutmayın.
Main context, Nginx yapılandırması için en geniş ortamı temsil eder. Tüm uygulamayı temel düzeyde etkileyen ayrıntıları yapılandırmak için kullanılır. Bu bölümdeki yönergeler alt bağlamları etkilese de, bunların çoğu miras alınmaz çünkü alt düzeylerde geçersiz kılınamazlar.
Ana bağlamda yapılandırılan bazı genel ayrıntılar, çalışan işlemleri çalıştıracak kullanıcı ve grup, çalışan sayısı ve ana işlemin PID’sini kaydedecek dosyadır. Çalışan CPU benzeşimi ve çalışan işlemlerin “niceness” gibi şeyleri bile tanımlayabilirsiniz. Tüm uygulama için varsayılan hata dosyası bu seviyede ayarlanabilir (bu daha özel bağlamlarda geçersiz kılınabilir).
Event Context
“Event” bağlamı, “main” bağlam içinde yer alır. Nginx’in bağlantıları genel düzeyde nasıl ele aldığını etkileyen genel seçenekleri ayarlamak için kullanılır. Nginx yapılandırmasında tanımlanan yalnızca tek bir olay içeriği olabilir.
Bu context, diğer köşeli parantezli bağlamların dışında, yapılandırma dosyasında şöyle görünecektir:
# main context
events {
# events context
. . .
}
Nginx olay tabanlı bir bağlantı işleme modeli kullanır, bu nedenle bu bağlamda tanımlanan yönergeler çalışan işlemlerin bağlantıları nasıl ele alması gerektiğini belirler. Esas olarak, burada bulunan yönergeler, kullanılacak bağlantı işleme tekniğini seçmek veya bu yöntemlerin uygulanma şeklini değiştirmek için kullanılır.
Genellikle bağlantı işleme yöntemi, platformun sahip olduğu en verimli seçime göre otomatik olarak seçilir. Linux sistemleri için epoll yöntemi genellikle en iyi seçimdir.
Yapılandırılabilen diğer öğeler, bir çalışanın bir seferde yalnızca tek bir bağlantıyı alması veya bekleyen bir bağlantı hakkında bilgilendirildikten sonra bekleyen tüm bağlantıları alması ve çalışanların olaylara sırayla yanıt verip vermeyeceği, her çalışanın başa çıkabileceği bağlantı sayısıdır.
HTTP Context
Nginx’i bir web sunucusu veya ters proxy olarak yapılandırırken, “http” bağlamı yapılandırmanın çoğunu tutacaktır. Bu bağlam, programın HTTP veya HTTPS bağlantılarını nasıl işleyeceğini tanımlamak için gerekli tüm yönergeleri ve diğer bağlamları içerecektir.
Http bağlamı, olaylar bağlamının bir kardeşidir, bu nedenle iç içe değil yan yana listelenmelidirler. İkisi de ana bağlamın dalları:
# main context
events {
# events context
. . .
}
http {
# http context
. . .
}
Daha düşük bağlamlar, isteklerin nasıl ele alınacağı konusunda daha spesifik hale gelirken, bu seviyedeki yönergeler, içinde tanımlanan her sanal sunucu için varsayılanları kontrol eder. Devralmanın nasıl çalışmasını istediğinize bağlı olarak, bu bağlamda ve aşağıda çok sayıda yönerge yapılandırılabilir.
Karşılaşabileceğiniz bazı yönergeler access ve error günlükleri için varsayılan konumları (access_log ve error_log) kontrol eder, dosya işlemleri için eşzamansız I/O yapılandırır (aio, sendfile ve directio) ve hata oluştuğunda sunucunun durumlarını yapılandırır. (error_page). Diğer yönergeler sıkıştırmayı yapılandırır (gzip ve gzip_disable), TCP’nin canlı tutma ayarlarına ince ayar yapar (keepalive_disable, keepalive_requests ve keepalive_timeout) ve Nginx’in paketleri ve sistem çağrılarını (sendfile, tcp_nodelay ve tcp_nopush) optimize etmeye çalışmak için izleyeceği kurallar . Ek yönergeler, uygulama düzeyinde bir belge kök ve dizin dosyalarını (kök ve dizin) yapılandırır ve farklı veri türlerini depolamak için kullanılan çeşitli karma tabloları (* _hash_bucket_size ve * _hash_max_size for server_names, türler ve değişkenler) ayarlar.
Server Context
“Server” bağlamı, “http” bağlamı içinde bildirilir. Bu iç içe geçmiş, köşeli parantezli bağlamlara ilişkin ilk örneğimizdir. Aynı zamanda birden fazla bildirime izin veren ilk bağlamdır.
Sunucu bağlamının genel biçimi şuna benzer olabilir. Bunların http bağlamında yer aldığını unutmayın:
# main context
http {
# http context
server {
# first server context
}
server {
# second server context
}
}
Sunucu bağlamının birden çok bildirimine izin vermenin nedeni, her bir örneğin istemci isteklerini işlemek için belirli bir sanal sunucuyu tanımlamasıdır. İhtiyaç duyduğunuz kadar sunucu bloğuna sahip olabilirsiniz ve bunların her biri belirli bir bağlantı alt kümesini yönetebilir.
Birden fazla sunucu bloğunun olasılığı ve olasılığı nedeniyle, bu bağlam türü, Nginx’in kararlar almak için bir seçim algoritması kullanması gereken ilk içeriktir. Her istemci isteği, tek bir sunucu bağlamında tanımlanan yapılandırmaya göre ele alınacaktır, bu nedenle Nginx, isteğin ayrıntılarına bağlı olarak hangi sunucu bağlamının en uygun olduğuna karar vermelidir. Bir isteği yanıtlamak için bir sunucu bloğunun kullanılıp kullanılmayacağına karar veren yönergeler şunlardır:
- listen: Bu sunucu bloğunun yanıt vermek üzere tasarlandığı ip adresi / bağlantı noktası birleşimi. Bir istemci tarafından bu değerlerle eşleşen bir talep yapılırsa, bu blok potansiyel olarak bağlantıyı idare etmek için seçilecektir.
- server_name: Bu yönerge, işlenmek üzere bir sunucu bloğu seçmek için kullanılan diğer bileşendir. İsteği işleyebilecek aynı özgüllükte dinleme yönergelerine sahip birden fazla sunucu bloğu varsa, Nginx isteğin “Host” başlığını ayrıştıracak ve bu yönergeye göre eşleştirecektir.
Bu bağlamdaki yönergeler, http bağlamında tanımlanabilen, günlük kaydı, belge kökü, sıkıştırma vb. Dahil birçok yönergeyi geçersiz kılabilir. Http bağlamından alınan yönergelere ek olarak, dosyaları şu şekilde yapılandırabiliriz: isteklere yanıt vermeyi deneyin (try_files), yeniden yönlendirmeler ve yeniden yazmalar yayınlayın (return ve rewrite) ve rastgele değişkenler ayarlayın (set).
Location Context
Düzenli olarak ilgileneceğiniz bir sonraki bağlam, konum bağlamıdır. Konum bağlamları, sunucu bağlamlarıyla birçok ilişkisel niteliği paylaşır. Örneğin, birden çok konum bağlamı tanımlanabilir, her konum belirli bir müşteri talebini işlemek için kullanılır ve her konum, bir seçim algoritması aracılığıyla konum tanımını müşteri talebiyle eşleştirerek seçilir.
Bir sunucu bloğunun seçilip seçilmeyeceğini belirleyen yönergeler sunucu bağlamında tanımlanırken, bir konumun bir isteği işleme yeteneğine karar veren bileşen konum tanımında (konum bloğunu açan satır) bulunur.
Genel sözdizimi şuna benzer:
location match_modifier location_match {
. . .
}
location blokları, sunucu bağlamları içinde bulunur ve sunucu bloklarının aksine, birbirinin içine yerleştirilebilir. Bu, belirli bir trafik alt kümesini yakalamak için daha genel bir konum bağlamı oluşturmak ve daha sonra, içinde ek bağlamlar bulunan daha özel kriterlere göre daha fazla işlemek için yararlı olabilir:
# main context
server {
# server context
location /match/criteria {
# first location context
}
location /other/criteria {
# second location context
location nested_match {
# first nested location
}
location other_nested {
# second nested location
}
}
}
Sunucu bağlamları, istenen IP adresi / bağlantı noktası kombinasyonuna ve “Ana Bilgisayar” başlığındaki ana bilgisayar adına göre seçilirken, konum blokları, istek URI’sına bakarak bir sunucu bloğu içindeki istek işlemeyi daha da böler. İstek URI’si, isteğin alan adı veya IP adresi / bağlantı noktası kombinasyonundan sonra gelen kısmıdır.
Dolayısıyla, bir istemci 80 numaralı bağlantı noktasında http://www.example.com/blog isterse, http, www.example.com ve bağlantı noktası 80’in tümü hangi sunucu bloğunun seçileceğini belirlemek için kullanılır. Bir sunucu seçildikten sonra, / blog kısmı (istek URI’si), isteğe yanıt vermek için hangi başka içeriğin kullanılması gerektiğini belirlemek için tanımlanan konumlara göre değerlendirilir.
Bir konum bağlamında göreceğiniz direktiflerin çoğu, üst düzeylerde de mevcuttur. Bu seviyedeki yeni direktifler, belge kökü dışındaki yerlere (takma ad) erişmenize, konumu yalnızca dahili olarak erişilebilir (dahili) olarak işaretlemenize ve diğer sunuculara veya konumlara proxy (http, fastcgi, scgi ve uwsgi proxy kullanarak) izin verir.
Diğer Contextler
Yukarıdaki örnekler Nginx ile karşılaşacağınız temel bağlamları temsil ederken, başka bağlamlar da mevcuttur. Aşağıdaki bağlamlar, ya daha isteğe bağlı modüllere bağlı olduklarından, yalnızca belirli koşullarda kullanıldıklarından ya da çoğu insanın kullanmayacağı işlevler için kullanıldığından ayrılmıştır.
Yine de mevcut bağlamların her birini tartışmayacağız. Aşağıdaki bağlamlar hiçbir derinlikte tartışılmayacaktır:
- split_clients: Bu bağlam, sunucunun aldığı istemcileri bir yüzdeye dayalı değişkenlerle etiketleyerek kategorilere ayırmak için yapılandırılır. Bunlar daha sonra farklı ana bilgisayarlara farklı içerik sağlayarak A / B testi yapmak için kullanılabilir.
- perl / perl_set: Bu bağlamlar, Perl işleyicileri içinde göründükleri konum için yapılandırır. Bu yalnızca Perl ile işlem yapmak için kullanılacaktır.
- map: Bu bağlam, başka bir değişkenin değerine bağlı olarak bir değişkenin değerini ayarlamak için kullanılır. İkinci değişkenin neye ayarlanması gerektiğini belirlemek için bir değişkenin değerlerinin eşlenmesini sağlar.
- geo: Yukarıdaki bağlam gibi, bu bağlam da bir eşlemeyi belirtmek için kullanılır. Ancak, bu eşleme özellikle istemci IP adreslerini kategorilere ayırmak için kullanılır. Bağlanan IP adresine bağlı olarak bir değişkenin değerini ayarlar.
- types: Bu bağlam yine eşleme için kullanılır. Bu bağlam, MIME türlerini kendileriyle ilişkilendirilmesi gereken dosya uzantılarıyla eşlemek için kullanılır. Bu genellikle Nginx ile birlikte ana nginx.conf yapılandırma dosyasına sağlanan bir dosya aracılığıyla sağlanır.
- charset_map: Bu, bir eşleme bağlamının başka bir örneğidir. Bu bağlam, bir dönüştürme tablosunu bir karakter kümesinden diğerine eşlemek için kullanılır. Bağlam başlığında her iki küme de listelenir ve gövde içinde eşleme gerçekleşir.
Aşağıdaki bağlamlar şimdiye kadar tartıştıklarımız kadar yaygın değildir, ancak yine de bilinmesi çok yararlıdır.
Upstream Context
Upstream bağlamı, “upstream” sunucuları tanımlamak ve yapılandırmak için kullanılır. Temel olarak, bu bağlam, Nginx’in daha sonra proxy isteklerinde bulunabileceği adlandırılmış bir sunucu havuzunu tanımlar. Bu bağlam, çeşitli türlerdeki proxy’leri yapılandırırken büyük olasılıkla kullanılacaktır.
Upstream bağlamı, herhangi bir belirli sunucu bağlamının dışında, http bağlamına yerleştirilmelidir. Genel form şuna benzer:
# main context
http {
# http context
upstream upstream_name {
# upstream context
server proxy_server1;
server proxy_server2;
. . .
}
server {
# server context
}
}
Daha sonra upstream bağlamı, belirli bir türdeki istekleri tanımlanmış sunucular havuzuna geçirmek için sunucu veya konum blokları içindeki adla referans alınabilir. Daha sonra, yukarı akış, isteği hangi belirli sunucuya vereceğini belirlemek için bir algoritma (varsayılan olarak round-robin) kullanır. Bu bağlam, Nginx’imize isteklere proxy uygularken bazı yük dengeleme yapma yeteneği verir.
Mail Context
Nginx çoğunlukla bir web veya ters proxy sunucusu olarak kullanılsa da, yüksek performanslı bir posta proxy sunucusu olarak da işlev görebilir. Bu tür direktifler için kullanılan bağlam, uygun şekilde “mail” olarak adlandırılır. Posta bağlamı, “main” veya “global” bağlam içinde (http bağlamının dışında) tanımlanır.
Posta bağlamının ana işlevi, sunucuda bir posta proxy çözümünü yapılandırmak için bir alan sağlamaktır. Nginx, kimlik doğrulama isteklerini harici bir kimlik doğrulama sunucusuna yönlendirme yeteneğine sahiptir. Daha sonra gerçek posta verilerini sunmak için POP3 ve IMAP posta sunucularına erişim sağlayabilir. Posta içeriği, istenirse bir SMTP Relay host bağlanmak için de yapılandırılabilir.
Genel olarak, bir posta bağlamı şuna benzer:
# main context
events {
# events context
}
mail {
# mail context
}
If Context
“If” bağlamı, içinde tanımlanan direktiflerin koşullu işlenmesini sağlamak için oluşturulabilir. Geleneksel programlamadaki if deyimi gibi, Nginx’teki if yönergesi, belirli bir test “true” döndürürse içerilen talimatları yürütür.
Nginx’teki if bağlamı, yeniden yazma modülü tarafından sağlanır ve bu, bu bağlamın birincil kullanım amacıdır. Nginx, bir talebin koşullarını diğer birçok amaca yönelik direktifle test edeceğinden, çoğu koşullu yürütme biçimi için kullanılmaması gerekir. Bu o kadar önemli bir not ki Nginx topluluğu if is evil adında bir sayfa oluşturdu. https://www.nginx.com/resources/wiki/start/topics/depth/ifisevil/
Temelde sorun, Nginx işleme sırasının çoğu zaman bir if bloğunun anlamını altüst eden beklenmedik sonuçlara yol açabilmesidir. Bu bağlamlar içinde güvenilir şekilde güvenli kabul edilen direktifler, dönüş ve yeniden yazma direktifleridir (bu bağlam için oluşturulmuş olanlar). Bir if bağlamı kullanırken akılda tutulması gereken bir diğer husus, aynı bağlamda bir try_files yönergesini işe yaramaz hale getirmesidir.
Çoğu zaman, rewrite veya return gerekip gerekmediğini belirlemek için bir if kullanılır. Bunlar genellikle konum bloklarında bulunur, bu nedenle ortak biçim şuna benzer:
# main context
http {
# http context
server {
# server context
location location_match {
# location context
if (test_condition) {
# if context
}
}
}
}
Limit_except Context
Limit_except bağlamı, bir konum bağlamı içinde belirli HTTP yöntemlerinin kullanımını kısıtlamak için kullanılır. Örneğin, yalnızca belirli istemcilerin POST içeriğine erişimi olması gerekiyorsa, ancak herkesin içeriği okuyabilmesi gerekiyorsa, bu gereksinimi tanımlamak için bir limit_except bloğu kullanabilirsiniz.
Yukarıdaki örnek şuna benzer:
. . .
# server or location context
location /restricted-write {
# location context
limit_except GET HEAD {
# limit_except context
allow 192.168.1.1/24;
deny all;
}
}
Bu, bağlam başlığında listelenenler dışında herhangi bir HTTP yöntemiyle karşılaşıldığında bağlam içindeki yönergeleri (erişimi kısıtlamak içindir) uygular. Yukarıdaki örneğin sonucu, herhangi bir istemcinin GET ve HEAD fiillerini kullanabilmesidir, ancak yalnızca 192.168.1.1/24 alt ağından gelen istemcilerin diğer yöntemleri kullanmasına izin verilir.
Bağlamlara İlişkin Uyulması Gereken Genel Kurallar
Artık Nginx konfigürasyonlarını keşfederken karşılaşacağınız yaygın bağlamlar hakkında bir fikriniz olduğuna göre, Nginx bağlamlarıyla uğraşırken kullanabileceğiniz bazı en iyi uygulamaları tartışabiliriz.
Direktifleri Mevcut En Yüksek Bağlamda Uygulayın
Birçok yönerge birden fazla bağlamda geçerlidir. Örneğin, http, sunucu veya konum bağlamına yerleştirilebilecek epeyce yönerge vardır. Bu bize bu direktifleri belirlemede esneklik sağlar.
Bununla birlikte, genel bir kural olarak, genellikle en iyisi, direktifleri uygulanabilir oldukları en yüksek bağlamda ilan etmek ve gerektiğinde daha düşük bağlamlarda geçersiz kılmaktır. Bu, Nginx’in uyguladığı kalıtım modeli nedeniyle mümkündür. Bu stratejiyi kullanmanın birçok nedeni var.
Her şeyden önce, yüksek düzeyde beyan etmek, kardeş bağlamlar arasında gereksiz tekrarları önlemenizi sağlar. Örneğin, aşağıdaki örnekte, konumların her biri aynı belge kökünü bildiriyor:
http {
server {
location / {
root /var/www/html;
. . .
}
location /another {
root /var/www/html;
. . .
}
}
}
root sunucu bloğuna veya hatta http bloğuna şu şekilde taşıyabilirsiniz:
http {
root /var/www/html;
server {
location / {
. . .
}
location /another {
. . .
}
}
}
Çoğu zaman, sunucu seviyesi en uygun olanıdır, ancak daha yüksek seviyede beyan etmenin avantajları vardır. Bu yalnızca yönergeyi daha az yerde ayarlamanıza izin vermekle kalmaz, aynı zamanda varsayılan değeri tüm alt öğelere kademelendirmenize olanak tanır ve daha düşük bir düzeydeki bir yönergeyi unutarak bir hatayla karşılaştığınız durumları önler. Bu, uzun konfigürasyonlarda önemli bir sorun olabilir. Daha yüksek seviyelerde beyan etmek size mantıklı bir varsayılan sağlar.
Bu noktada, Nginx’in en yaygın bağlamlarını ve onları tanımlayan blokları oluşturan yönergeyi iyi bir şekilde kavramış olduk sayılır.
http://nginx.org/en/docs/dirindex.html
Bir direktifin hangi bağlamlara yerleştirilebileceği hakkında bilgi almak ve en etkili konumu değerlendirmek için her zaman Nginx’in belgelerine bakın. Konfigürasyonlarınızı oluştururken dikkatli olmak yalnızca sürdürülebilirliği artırmakla kalmaz, aynı zamanda performansı da sıklıkla artırır.