Bölüm 2.6 - İki ASP.NET Core uygulamasını aynı anda çalıştırma

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

Bu makalede, iki ASP.NET Core uygulamasının yan yana çalışmasını, farklı bağlantı noktalarını dinlemesini ve gelen istekleri işlemesini sağlama adımları anlatılmaktadır.

Önkoşullar

Öğreticinin bu bölümünü tamamlamak için aşağıdaki öğelerin ayarlanmış olması gerekir:

• Hem .NET Core 3.1 hem de .NET 5.0 SDK'ları yüklü.
• Nginx otomatik olarak çalışır ve 80 numaralı bağlantı noktasında gönderilen istekleri dinler.
• Ters ara sunucu olarak yapılandırılan ve tüm istekleri ASP.NET Core uygulamasına yönlendiren Nginx (bağlantı noktası 5000'de dinleniyor.)
• Sunucu yeniden başlatıldıktan veya işlem durdurulduktan sonra otomatik olarak başlatacak şekilde yapılandırılmış bir ASP.NET Core uygulaması.
• SSH ve HTTP trafiğine izin verecek şekilde etkinleştirilmiş ve yapılandırılmış Linux yerel güvenlik duvarı.
• /var/buggyamb_v1.1 dizinine indirilen ve ayıklanan örnek buggy ASP.NET Core uygulaması.

Bu seride kullanılan ilk ASP.NET Core tanıtım uygulaması bir ASP.NET Core 5.0 uygulamasıdır. İkinci uygulama bir ASP.NET Core 3.1 uygulamasıdır. Hem .NET Core 3.1 hem de .NET 5.0 SDK'larınız yüklü değilse, devam etmeden önce eksik olanını yükleyin.

Not

komutunu çalıştırarak dotnet --info çalışma zamanlarının ve SDK'ların yüklü sürümünü de kontrol edebilirsiniz. .NET Core yüklemesi bu serinin önceki bölümlerinde ele alınmıştı.

Bu bölümün hedefi

Bu bölümün sonunda yan yana çalışan, farklı bağlantı noktalarını dinleyen ve gelen istekleri işleyen iki ASP.NET Core uygulamasına sahip olacaksınız.

Bu bölümde gerçekleştirdiğiniz eylemlerin çoğu benzer olacaktır: sunucu yeniden başlatıldığında veya işlem durdurulurken başlatılabilmesi için ikinci ASP.NET Core uygulaması için bir hizmet dosyası oluşturun.

İkinci uygulamayı çalıştırma

çalışan ilk uygulamaya benzer bir hizmet olarak ikinci bir uygulama çalıştırın. Hizmet dosyasını oluşturmadan önce doğru çalıştığından emin olun.

Önceki bölümlerde test hata ayıklama uygulamasını /var/buggyamb_v1.1/ dizinine kopyalamanız ve ardından komutunu kullanarak uygulamayı çalıştırmanız talimatının dotnet /var/buggyamb_v1.1/BuggyAmb.dll alındığını hatırlayın. Aşağıdaki hata iletisini alabilirsiniz:

System.IO.IOException: Adresi http://127.0.0.1:5000bağlanamadı: zaten kullanımda olan adres.

Bu iletiye göre, başka bir işlem zaten 5000 numaralı bağlantı noktasını kullanıyor. Bu çok açık. Ancak hangi işlemin bağlantı noktasını kullandığını nasıl öğrenebilirsiniz? komutunu çalıştırarak sudo netstat -tulpn | grep 5000 . Aşağıdaki ekran görüntüsünde PID, 12536 işlem adı ise şeklindedir dotnet. İşlem kimliğinizin büyük olasılıkla farklı olacağını görürsünüz:

Sonraki adım, bağlantı noktası 5000'de dinleyen dotnet işlemi tarafından hangi ASP.NET Core uygulamasının barındırıldığını anlamaktır. Aşağıdaki ekran görüntüsüne cat /proc/12536/cmdline benzer bir sonuç almak için komutunu çalıştırabilirsiniz.

Bu, bu seride yapılandırılan ilk ASP.NET Core uygulamasıdır. 5000 numaralı bağlantı noktasını dinliyor. Bu nedenle, yeni ASP.NET Core buggy uygulamamız aynı bağlantı noktasında dinleyemiyor.

Not

Burada yeni bir şey öğrendiniz. /proc adlı bir dizin var. Bu dizinin içeriğini listelerseniz, o anda çalışan her PID için adlandırılmış dizinler görürsünüz. Her alt klasörde, komut satırı ve bellek veya CPU bilgileri gibi her işlemin özelliklerini almak için kullanabileceğiniz birkaç dosya bulunur. Şimdilik buna odaklanmayın çünkü araçları ve süreçleri ele aldığımızda bunu tartışacağız.

Bağlantı noktası çakışması sorununun çözümü ilk uygulamayı çalıştırmayı durdurmak değildir. Amaç her iki uygulamanın da aynı anda çalışması olduğundan, çözüm aslında ikinci ASP.NET Core uygulamasını farklı bir bağlantı noktasında çalıştırmaktır.

İkinci ASP.NET Core uygulamasını farklı bir bağlantı noktasında dinleyecek şekilde yapılandırma

Bu hedefe ulaşmanın farklı yolları vardır:

• bağlantı noktasını Program.cs olarak ayarlamak için kullanınUseUrls(): Bu, bağlantı noktasının uygulamada sabit kodlandığı anlamına gelir. Bağlantı noktasını bir yapılandırma dosyasından okuyabiliyor olsak da, uygulamayı değiştirmek ve yeniden derlemek istemezsiniz. Bu nedenle, bu eğitim bu çözüme odaklanmayacak.
• Komut satırı bağımsız değişkenleri: Uygulamanızı çalıştırırken parametresini kullanın --urls .
• Ortam değişkenleri: Bir ortam değişkeninin kullanılmasını dinlemek için URL'yi ayarlayın. Bunu başarmak için veya ASPNETCORE_URLS ortam değişkeni adlarını kullanınDOTNET_URLS.

Hem ortam değişkenleri hem de komut satırı bağımsız değişkeni yaklaşımı dikkate alınması gereken seçeneklerdir. Aşağıdaki ekran görüntüsünde --urls gösterildiği gibi seçeneği test etmeyi deneyin.

Amacın uygulamayı hizmet olarak çalıştırmak olduğunu unutmayın. Bunun için ortam değişkenlerini ayarlayabileceğiniz bir hizmet dosyanız olması gerekir. Yürütülebilir komutu daha önce gösterildiği gibi ayarlayabilir veya ortam değişkenlerini ayarlayabilirsiniz. Aşağıdaki örnekler, uygulamayı alternatif bir bağlantı noktasında dinleyecek şekilde yapılandırmak için ortam değişkenlerini kullanır.

İkinci uygulama için hizmet birimi dosyası oluşturma

Hizmet birimi dosyanızda aşağıdaki hizmet tanımını kullanacaksınız. İkinci uygulamanın /var/buggyamb_v1.1 dizininde çalıştırılacağını unutmayın.

Not

Satırı adlı Environment=ASPNETCORE_URLS=http://localhost:5001 ASPNETCORE_URLS bir ortam değişkeni bildirir ve uygulamamıza 5001 numaralı bağlantı noktasını dinlemesini söyler:

[Unit]
Description=BuggyAmb is a really buggy application
 
[Service]
WorkingDirectory=/var/buggyamb_v1.1/
ExecStart=/usr/bin/dotnet /var/buggyamb_v1.1/BuggyAmb.dll
Restart=always
# Restart service after 10 seconds if the dotnet service crashes:
RestartSec=10
KillSignal=SIGINT
SyslogIdentifier=buggyamb-identifier
User=www-data
Environment=ASPNETCORE_ENVIRONMENT=Development
Environment=DOTNET_PRINT_TELEMETRY_MESSAGE=false
Environment=ASPNETCORE_URLS=http://localhost:5001
 
[Install]
WantedBy=multi-user.target

Hizmet dosyası adı buggyamb.service olur ve /etc/systemd/system/ dizininde oluşturulur. Daha önce yaptığınız gibi vi düzenleyicisini kullanın ve komutunu çalıştırarak sudo vi /etc/systemd/system/buggyamb.service hizmet tanımı dosyasını oluşturun. Bu yapılandırmayı kopyalayıp yapıştırın ve kaydedin. Ortam değişkenini nasıl ayarladığınıza ASPNETCORE_URLS tekrar dikkat edin:

Artık buggy ASP.NET Core web uygulamasını daemon olarak çalışacak şekilde yapılandırmış oldunuz. Bu, eğitimin başında belirttiğimiz hedefi karşılamak için yeterli mi? ve sudo systemctl start buggyamb.service komutlarını çalıştırarak sudo systemctl enable buggyamb.service hizmeti etkinleştirin ve başlatın. Ardından, aşağıdaki ekran görüntüsünde gösterildiği gibi komutunu çalıştırarak systemctl status buggyamb.servicehizmet durumunu denetleyin.

Artık BuggyAmb uygulamasının beklendiği gibi çalışıp çalışmadığını denetleyebileceğiniz noktadasınız. Aşağıdaki ekran görüntüsünde curl localhost:5001 gösterildiği gibi BuggyAmb HTML'nin Hoş Geldiniz sayfasının konsolda görüntülenmesini sağlamak için komutunu çalıştırın.

Uygulama, bağlantı noktası 5001'de dinlediğinden istemciden henüz test edilemiyor. Güvenlik duvarı ayarlarında bu bağlantı noktasına izin verilmez. Nginx bağlantı noktasını İnternet'te kullanıma sunmadığından, Nginx'i 80 numaralı bağlantı noktasında dinleyecek şekilde yapılandırabilir ve gelen HTTP istekleri belirli bir ana bilgisayar adı kullanılarak yapıldığında trafiği BuggyAmb'a yönlendirebilirsiniz. Örneğin, konak adlarını kullanabilirsiniz: http://buggyamb veya http://buggyweb. İstediğiniz başka bir ana bilgisayar adını da kullanabilirsiniz.

Şimdilik, ikinci ASP.NET Core uygulamasının ilk tanıtım uygulamasıyla yan yana çalışmasını sağlamak hedefleniyor. Sonraki bölümde, Nginx'i bu bölümde açıklandığı gibi yapılandırmaya devam edeceğiz.

Sonraki adımlar

Bölüm 2.7 - Nginx'te konak adıyla ikinci bir web sitesi yapılandırma