Aracılığıyla paylaş


Bölüm 2.2 - Nginx'i yükleme ve ters ara sunucu olarak yapılandırma

Şunlar için geçerlidir: .NET Core 2.1, .NET Core 3.1, .NET 5

Bu makalede Nginx'in nasıl yükleneceği ve ters ara sunucu olarak nasıl yapılandırılması anlatılır.

Önkoşullar

Bu bölümdeki alıştırmaları takip etmek için bir ASP.NET Core web uygulaması oluşturmanız ve /var klasörüne dağıtmış olmanız gerekir.

Bu bölümün hedefi

Önceki bölümde .NET CLI aracını kullanarak bir ASP.NET Core web uygulaması oluşturdunuz ve uygulama /var klasörüne dağıtıldı. Uygulama ayrıca HTTP istekleri için 5000 numaralı bağlantı noktasında dinleyecek şekilde yapılandırıldı ve HTTPS yeniden yönlendirmesi kaldırıldı.

Bu noktada, uygulamaya bağlandığınızda istemcilerin bağlantı noktası numarasını sağlaması gerekir (örneğin, http://localhost:5000). Ancak, istenen davranış bu değildir.

Bu bölümdeki hedeflerimiz şunlardır:

  • İstemciler bağlantı noktası numarası sağlamak zorunda kalmadan gezinebilmelidir. Örneğin, istemcilerin kullanarak http://localhostbağlanması gerekir.
  • Web uygulaması bir nedenle veya bilgisayar yeniden başlatıldıktan sonra durursa otomatik olarak başlatılmalıdır.

Sonraki bölümde, 80 numaralı bağlantı noktasına yapılan HTTP isteklerini bunun yerine .NET uygulamamıza yönlendirmek için Nginx'i ara sunucu olarak kullanacaksınız. Ayrıca uygulamanızı otomatik olarak başlatacak şekilde yapılandıracaksınız.

Nginx nedir?

Nginx popüler, basit ve hızlı bir web sunucusudur. Hem Linux hem de Windows üzerinde çalıştırılabilir ve ters ara sunucu olarak yapılandırılabilir.

Daemon nedir?

Nginx bir daemon olarak çalışır. Daemon, arka planda çalışan bir hizmet için alternatif bir terimdir. Windows'da çalışan hizmetler gibi, daemon'lar da başlatma sırasında otomatik başlatılacak şekilde yapılandırılabilir. ASP.NET Core uygulamanızı daemon olarak çalışacak şekilde yapılandıracaksınız.

APT kullanarak Nginx yükleme

Nginx'i yüklemek basittir. sudo apt install nginx Ubuntu sanal makinesine programı yüklemek için komutunu çalıştırın.

sudo komutunun ekran görüntüsü.

Yükleme tamamlandıktan sonra, programın yüklendiği yeri bulmak için komutunu çalıştırın whereis nginx . Çıkışı inceleyerek Nginx yapılandırma dosyalarının nerede olduğunu görebilirsiniz. Aşağıdaki ekran görüntüsünde yapılandırma dosyalarının /etc/nginx klasöründe bulunduğu gösterilmektedir.

whereis komutunun ekran görüntüsü.

Not

Ubuntu veya Debian dışında bir dağıtım çalıştırıyorsanız, eşdeğer paket yöneticisi yükleme komutunu veya yönergeleri resmi Nginx yükleme belgelerinden bulabilirsiniz.

systemctl kullanarak hizmetleri yönetme

Nginx'in çalıştığını görmüyorsanız, komutunu çalıştırarak sudo systemctl start nginxaçıkça başlatabilirsiniz. Bu alıştırma Nginx komutlarını gösterse systemctl de, bu komutlar web uygulamasını otomatik olarak bir daemon olarak başlatılacak şekilde yapılandırmak için kullanılır.

Yükleme tamamlandıktan sonra, Nginx zaten otomatik olarak başlatacak şekilde yapılandırılmıştır. Nginx bir daemon olarak çalışır. Systemctl kullanarak daemon'un durumunu de kontrol edebilirsiniz.

komutu systemctl , hizmetin durumunu gösterme veya başlatma ve durdurma gibi görevler için "hizmetleri" yönetmek için kullanılır. Kullanılabilir parametrelerden bazıları başlangıç, durdurma, yeniden başlatma, etkinleştirme, devre dışı bırakma ve durumdur. Nginx'in durumunu denetlemek için komutunu çalıştırın systemctl status nginx.

systemctl komutunun ekran görüntüsü.

Bu komut bazı yararlı bilgiler oluşturur. Bu ekran görüntüsünde active (running) gösterildiği gibi, Nginx durumu ve Nginx örneğinin işlem kimliği 8539'dur. Ayrıca ve vendor preset: enabled deyimlerine de dikkat edinenabled. Enabled bu daemon'un makine yeniden başlatıldığında başlayacağı anlamına gelir ve vendor preset: enabled yüklendiğinde Nginx'in varsayılan olarak etkinleştirildiği anlamına gelir. Bu nedenle, sunucu başlatıldığında Nginx otomatik olarak başlatılır.

Nginx yüklemesini test edin

Varsayılan olarak, Nginx 80 numaralı bağlantı noktasını dinler. Çalıştığından, localhost'a göz atarken Nginx'in ana sayfasına erişebilmelisiniz. komutunu çalıştırarak curl localhostNginx'i test etmek için kullanıncurl. Aşağıdaki ekran görüntüsündeki sarı vurgulanmış metin, Nginx varsayılan web sayfasını gösterir. Bu nedenle, Nginx çalışıyor:

curl komutunun ekran görüntüsü.

systemctl komut seçenekleri

Hizmetler veya daemon'lar komutu kullanılarak systemctl yönetilebilir. Başlatma, durdurma veya değişiklik yapma, süper kullanıcı erişimi gerektirir. Bu nedenle, bu komutlara sudo ön ek eklemeniz gerekir.

Daemon'ları yeniden başlatma

Zaman zaman daemonları yeniden başlatmanız gerekebilir. Bir daemon'u yeniden başlatmak için komutunu çalıştırın sudo systemctl restart <daemon_name>. Nginx'i yeniden başlatmak için komutunu çalıştırın sudo systemctl restart nginx. İşlem kimliğindeki değişiklikleri izlemek için bu komutu çalıştırmadan önce ve çalıştırdıktan sonra Nginx'in durumunu denetlediğinizden emin olun.

Daemon'ları durdurma

Bir daemon'u durdurmak için komutunu çalıştırın sudo systemctl stop <daemon_name>. Nginx'i durdurmak için komutunu çalıştırın sudo systemctl stop nginxve yeniden çalıştırarak systemctl status nginx Nginx'in durumunu denetleyin. Bu kez hizmet etkin değil (ölü) olarak gösterilir ancak yine de etkindir. Bu, hizmet çalışmamasına rağmen sunucu yeniden başlatıldıktan sonra otomatik olarak başlatılacağı anlamına gelir.

Durdur komutunun ekran görüntüsü.

Not

Komut systemctl status ayrıca daemon için önceki günlük girdilerinin birkaç satırını görüntüler.

Nginx'i durdurduktan sonra yeniden çalıştırın curl localhost .

Not

Bağlantı noktası 80'de gelen trafiği dinleyen bir şey olmadığından bağlantı reddedildi.

BuggyAmb localhost'un ekran görüntüsü.

Daemon'ları devre dışı bırakma

Bir daemon'un devre dışı bırakılması, bir daemon'un durdurulmasından farklıdır. Devre dışı bırakılmış bir daemon çalışıyor olabilir, ancak sunucu yeniden başlatıldıktan sonra otomatik olarak başlatılmaz. Nginx daemon'unu devre dışı bırakmak için komutunu çalıştırın sudo systemctl disable nginxve Nginx'in durumunu denetleyin.

Disable komutunun ekran görüntüsü.

Bu ekran görüntüsü Nginx'in çalışmadığını ve devre dışı bırakıldığını gösterir. Bu, Nginx'in yeniden başlatmadan sonra otomatik olarak başlatılmayacağından emin olun.

Daemon'ları başlatma

Bir daemon başlatmak için komutunu çalıştırın sudo systemctl start <daemon_name>. Nginx'i başlatmak için komutunu çalıştırın sudo systemctl start nginxve hizmetin durumunu yeniden denetleyin.

Başlat komutunun ekran görüntüsü.

Bu ekran görüntüsü, Nginx'in başlatıldığını ancak hala devre dışı bırakıldığını gösterir. Hizmet çalışıyor olsa da, Nginx devre dışı bırakılmış bir hizmet olduğundan yeniden başlatmadan sonra otomatik olarak başlatılmaz.

Daemon'ları etkinleştirme

Bir hizmetin etkinleştirilmesi, hizmetin yeniden başlatıldıktan sonra otomatik olarak başlatılacağı anlamına gelir. Nginx'i etkinleştirmek için komutunu çalıştırın sudo systemctl enable nginxve Nginx'in durumunu yeniden denetleyin.

Enable komutunun ekran görüntüsü.

Bu ekran görüntüsü Nginx'in çalıştığını ve sunucu yeniden başlatıldıktan sonra başlatılacağını gösterir.

İstekleri ASP.NET Core uygulamanıza yönlendirmek için Nginx'i ters proxy olarak yapılandırın

Nginx hizmetini başlatmayı, durdurmayı ve yeniden başlatmayı öğrendiğinize göre, 80 numaralı bağlantı noktasında yapılan istekleri 5000 numaralı bağlantı noktasında dinleyen ASP.NET Core uygulamanıza yönlendirmek için Nginx'i ters proxy olarak yapılandıracaksınız.

Gerekli yapılandırma aşağıdadır. Bazı önemli parçalar vurgulanır.

http {
  map $http_connection $connection_upgrade {
    "~*Upgrade" $http_connection;
    default keep-alive;
  }

  server {
    listen        80;
    server_name _;
    location / {
        proxy_pass         http://localhost:5000;
        proxy_http_version 1.1;
        proxy_set_header   Upgrade $http_upgrade;
        proxy_set_header   Connection $connection_upgrade;
        proxy_set_header   Host $host;
        proxy_cache_bypass $http_upgrade;
        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Proto $scheme;
    }
  }
}

Bu yapılandırma aşağıdakileri gösterir:

  • Nginx, tüm istekler için bağlantı noktası 80'de dinler (yönerge: listen 80).
  • Nginx istekleri (yönerge: proxy_pass http://localhost:5000) adresine http://localhost:5000 yönlendirir

Not

server_name _ Koddaki satır. Bu, tümünü yakala yönergesi olarak kullanılır. server_name hakkında daha fazla bilgi edinmek istiyorsanız resmi belgelere bakın.

Yapılandırma değişiklikleri basit görünür. Yapılandırma dosyasındaki server yönerge bölümünü değiştirmek için bu kodu kullanacağız. Peki yapılandırma dosyası nerede?

Doğru Nginx yapılandırma dosyasını bulma

Birincil Nginx yapılandırma dosyasıdır /etc/nginx/nginx.conf. Yapılandırmayı incelemek için komutunu kullanın cat /etc/nginx/nginx.conf ve sunucu yönergesini arayın.

Cat komutunun ekran görüntüsü.

Sunucu yönergesini bulmak için yapılandırmayı kaydırın. Bulmayabileceğinizi bilmelisiniz. İstenen yapılandırma değişikliklerini yapılandırma dosyasının içinde bir yere yerleştirebiliriz. Ancak, ideal olarak, özgün yapılandırma dosyasını değiştirmek istemezsiniz. Bu, sunucunun düzgün başlatılmasını engelleyebilecek yapılandırma hatalarının oluşmasını önlemektir. Bölüm server ana yapılandırma dosyasında yer almıyor. Yapılandırma dosyasını kaydırmaya devam ederseniz bazı include yönergeler olduğunu keşfedeceksiniz.

include komutunun ekran görüntüsü.

Ekleme yönergeleri, yapılandırmayı ana yapılandırma dosyasına eklenecek öbeklere bölerek yönetmeyi kolaylaştırır. Ana yapılandırma dosyası basit tutulabilir ve bazı belirli yapılandırma bölümleri diğer dosyalara taşınabilir. Bu ekran görüntüsündeki vurgulanan satırlar aşağıdakileri gösterir:

  • Nginx, /etc/nginx/conf.d dizininde bulunan her .conf dosyasından yapılandırma yükler.
  • Nginx, /etc/nginx/sites-enabled dizininde bulunan her dosyadan yapılandırmaları yükler.

Bu dizinleri incelerseniz /etc/nginx/conf.d içinde yapılandırma dosyaları bulamazsınız. Ancak, /etc/nginx/sites-enabled içinde bir dosya vardır.

conf komutunun ekran görüntüsü.

Varsayılan yapılandırma dosyası, aradığımız yapılandırmayı barındırmak için birincil aday gibi görünür. kullanarak cat /etc/nginx/sites-enabled/default/etc/nginx/sites-enabled/default dosyasını incelerseniz, varsayılan sunucu yönergesinin aşağıdaki koda yerleştirildiğini görürsünüz.

Varsayılan bilgilerin ekran görüntüsü.

Bu nedenle, yapılandırmayı değiştirmek için /etc/nginx/sites-enabled/default dosyasının düzenlenmesi gerekir.

Vi kullanarak yapılandırma dosyasını düzenleme

ASP.NET işlem hattından HTTPS yeniden yönlendirmesini kaldırmak için Startup.cs dosyasını düzenlerken dosyaları düzenlemeyi öğrendiniz. Şimdi, nginx yapılandırma dosyasını değiştirmek için vi'yi yeniden kullanacaksınız.

İpucu

Değiştirdiğiniz dosyaları her zaman yedekleyin. Düzenlemeden sonra bir sorun olursa, dosyayı önceki durumuna geri yüklemek için bu kopyayı kullanabilirsiniz. Bu durumda, komutunu çalıştırarak cp /etc/nginx/sites-enabled/default ~/nginx-default-backup yapılandırma dosyasını giriş dizininize kopyalayın. Yedekleme dosyası adı olacaktır nginx-default-backup. Yedeklemenin özgün dosyayla aynı dizinde yapılmadığını fark edin. Bunun nedeni Nginx'in bu dizindeki tüm yapılandırma dosyalarını yüklemesi ve sunucu yönergesinin iki farklı sürümünü yükleyerek yapılandırmayı bozmak istemenizdir.

Aşağıdaki ekran görüntüsünde gösterildiği gibi yapılandırma dosyasını düzenlemek ve sunucu yönergesini değiştirmek için komutunu çalıştırın sudo vi /etc/nginx/sites-enabled/default .

vi komutunun ekran görüntüsü.

Vi kullanarak dosyaları düzenlemeye yönelik bazı ipuçları ve püf noktaları şunlardır:

  • Ok tuşlarını kullanarak yukarı ve aşağı kaydırabilirsiniz.
  • Düzenleme moduna geçmek için Ekle veya I tuşuna basın. Düzenleme modundayken sol alt köşede bir --INSERT-- iletisi olacaktır.
  • Düzenleme modunda, karakterleri teker teker silmek için klavyeyi kullanabilirsiniz.
  • Düzenleme modunda kopyalama ve yapıştırma işlemleri terminallerin çoğuyla birlikte çalışır. Bu nedenle, bu makaledeki içeriği kopyalayıp vi'ye yapıştırabilirsiniz.
  • Düzenleme modundan çıkmak için Esc tuşuna basın.
  • Normal modda satırları daha kolay silebilirsiniz. Normal modda, silmek istediğiniz satırın başına gidin ve dd girin. dd komutu satırın tamamını siler. Aynı anda beş satırı silmek için 5dd de yazabilirsiniz. Ancak bu seçenek, ek içeriğin silinmesini önlemek için dikkatli kullanılmalıdır.
  • Vim /Vi'de Satırları Silme makalesi iyi bir makaledir Vi'de birden çok satırı silmeyi öğrenmek için.
  • Vi'dan çıkmak ve değişiklikleri kaydetmek için :wq! yazın ve Enter tuşuna basın. Burada iki nokta üst üste (:), bir komut çalıştırdığınız, değişiklikleri yazdığınız, w q çıkabileceğiniz ve ! değişiklikleri geçersiz kılabileceğiniz anlamına gelir.
  • Değişiklikleri kaydetmeden çıkmak için :q! yazın ve Enter tuşuna basın.

Değişiklikler şimdi kaydedilir ve bu değişikliklerin etkili olması için Nginx hizmetini yeniden başlatmanız gerekir. Hizmeti yeniden başlatmadan önce komutunu çalıştırarak sudo nginx -t yapılandırma dosyasını test edebilirsiniz. Bu komut çalıştırıldığında, Nginx yapılandırma dosyasının söz dizimini denetler ve yapılandırma dosyasında başvurulan dosyaları açmaya çalışır.

t komutunun ekran görüntüsü.

Burada görebileceğiniz gibi, değiştirilen yapılandırma dosyası doğru görünüyor.

Değişikliklerin etkili olması için Nginx'i yeniden başlatmamız gerekir:

sudo systemctl restart nginx

Yeniden başlatmadan sonra, H'ye istektettp://localhost bulunurken ASP.NET Core uygulamasından bir yanıt görmeyi beklersiniz çünkü Nginx, 80 numaralı bağlantı noktasına yapılan istekler için ters ara sunucu olarak çalışmalıdır.

Değişikliklerin etkili olması için Nginx hizmetini yeniden başlatın ve komutunu çalıştırarak curl localhostlocalhost'a bir istekte bulunın. Ancak, bu komut başarısız olur. Sonraki adım komutunu çalıştırmak wget localhostve ardından sorunun kaynağıyla ilgili bazı ipuçları aramaktır.

wget komutunun ekran görüntüsü.

Nginx proxy sorununu giderme

Önceki ekran görüntüsünde şu bilgileri görürsünüz:

Resolving localhost (localhost)... 127.0.0.1  
Connecting to localhost (localhost)|127.0.0.1|:80... connected.  
HTTP request sent, awaiting response... 502 Bad Gateway  
2020-12-27 21:15:53 ERROR 502: Bad Gateway.

birinci ve ikinci satırlar localhost'u çözümleyebilmenizi ve yuvaya 127.0.0.1:80 bağlanabildiğinizi gösterir. Bu nedenle Nginx çalışıyor olmalıdır. Bunu doğrulamak için komutunu çalıştırabilirsiniz systemctl status nginx .

Üçüncü satır sorunun kaynağını gösterir. HTTP 502 Hatalı Ağ Geçidi hata iletisi alıyorsunuz. HTTP 502 Bad Gateway proxy'lerle ilgilidir. Bu, ters proxy'nin arka uç uygulamasına bağlanamadığı anlamına gelir. Bu durumda, istekler için 5000 numaralı bağlantı noktasında çalışması ve dinlemesi gereken ASP.NET Core web uygulamanızdır. Web uygulamasının da çalışıp çalışmadığını denetlememiz gerekir.

Sorun gidermeye başlamak için öncekiyle aynı netstat komutu çalıştırın. Bu kez grep'i kullanarak uygulamanızın 5000 numaralı bağlantı noktasını filtreleyin. Ardından komutunu çalıştırın netstat -tlp | grep 5000.

netstat komutunun ekran görüntüsü.

Bu örnek çıktı, 5000 numaralı bağlantı noktasında hiçbir şeyin dinlemediğini gösterir. Bu nedenle, Nginx'ten gelen HTTP 502 yanıtının nedeni budur çünkü 5000 numaralı bağlantı noktasında dinleyen bir işlemi bulamıyordur.

Çözüm, ASP.NET Core uygulamanızı başlatmaktır. Ancak, daha ileri gitmeden önce, bu sorunu gidermek için başka bir yaklaşımı gözden geçirebilirsiniz. Her sorunun düzeltilmesi, yalnızca birkaç günlük içeriği satırına bakmak ve kök nedeni bulmak kadar kolay değildir. Bazen diğer sistem ve uygulama günlüklerini ayrıntılı olarak incelemeniz gerekir.

Linux'ta ASP.NET Core uygulamaları ayarlarken Nginx ile yakın çalıştığınız için Nginx ve işletim sisteminin sorun giderme için sağladığı günlük türlerini öğrenmenizi öneririz.

Nginx günlüklerini denetleme

Yeniden çalıştırıp cat /etc/nginx/nginx.conf öğesini ararsanız logging settingsaşağıdakilere dikkat etmelisiniz.

Günlük bilgilerinin ekran görüntüsü.

Bu, Nginx'in iki tür günlük olduğunu gösterir: Erişim günlükleri ve Hata günlükleri. Bunlar /var/log/nginx/ dizininde depolanır.

Erişim günlükleri IIS günlük dosyalarına benzer. İçeriğin hızlı bir şekilde incelenmesi, aşağıdaki ekran görüntüsüne benzediklerini gösterir.

Access komutunun ekran görüntüsü.

Erişim günlükleri, zaten tanıdığınız HTTP 502 yanıt durumu dışında yeni bilgiler göstermez. komutunu çalıştırarak cat /var/log/nginx/error.loghata günlüklerini de inceleyebilirsiniz. Bunlar sorunun nedeni hakkında çok daha fazlasını ortaya koyuyor.

Hata bilgilerinin ekran görüntüsü.

Göstergeler açıktır: Nginx istemciden isteği alabilir, ancak bu bağlantı noktasında çalıştırılıp dinlemesi gereken ASP.NET Core uygulamasına ve sunucusuna http://127.0.0.1:5000 bağlanamazupstream.

Geçici çözüm

Bu sorunu geçici olarak çözmek için ASP.NET Core uygulamanızı el ile başlatın. İkinci bir terminal oturumu kullanarak sunucuya bağlanın ve daha önce olduğu gibi ASP.NET Core uygulamasını çalıştırın.

Aspnet bilgilerinin ekran görüntüsü.

ASP.NET Core uygulamanız çalışırken diğer terminal oturumuna geçin ve aynı curl localhost komutu çalıştırın. Artık Nginx'in arkasında çalışan ASP.NET Core uygulamanıza erişebilirsiniz. Aşağıdaki ekran görüntüsünde localhost'a istekte bulunduğunuz, isteğin Nginx tarafından işlendiği ve arka uç uygulamasına yönlendirildiği ve ASP.NET Core uygulamanızdan bir yanıt aldığınız gösterilmektedir.

curllocalhost komutunun ekran görüntüsü.

Şimdi Nginx'i Linux'ta çalışan ASP.NET Core uygulamanız için ters ara sunucu olarak davranacak şekilde yapılandırmış oldunuz.

Ancak, ASP.NET Core uygulaması yeniden başlatıldıktan sonra başlatılmazsa sonuç ne olur? Web uygulaması kilitlenirse ve çalışmadığını fark edene kadar başlatılmazsa ne olur? İşlem sonlandırmanın her yeniden başlatılmasından sonra ASP.NET Core uygulamanızı başlatmanız gerekir mi?

Sonraki adımlar

Bölüm 2.3 - ASP.NET Core uygulamasını otomatik olarak başlatacak şekilde yapılandırma

Üçüncü taraf bilgileri hakkında yasal uyarı

Bu makalede adı geçen üçüncü taraf ürünleri Microsoft'tan bağımsız şirketler tarafından üretilmektedir. Microsoft, bu ürünlerin performansı veya güvenilirliği ile ilgili örtük veya başka türlü hiçbir garanti vermez.