Azure Uygulaması Hizmeti'nde işletim sistemi işlevselliği

Bu makalede, Azure Uygulaması Hizmeti'nde çalışan tüm Windows uygulamalarının kullanabileceği temel işletim sistemi işlevselliği açıklanmaktadır. Bu işlevsellik dosya, ağ ve kayıt defteri erişiminin yanı sıra tanılama günlüklerini ve olaylarını içerir.

Dekont

App Service'teki Linux uygulamaları kendi kapsayıcılarında çalışır. Kapsayıcıya kök erişiminiz var ancak konak işletim sistemine erişiminiz yok. Benzer şekilde, Windows kapsayıcılarında çalışan uygulamalar için kapsayıcıya yönetici erişiminiz vardır ancak konak işletim sistemine erişiminiz yoktur.

App Service plan katmanları

App Service, müşteri uygulamalarını çok kiracılı bir barındırma ortamında çalıştırır. Ücretsiz ve Paylaşılan katmanlarda dağıtılan uygulamalar, paylaşılan sanal makinelerde (VM) çalışan işlemlerinde çalıştırılır. Standart ve Premium katmanlarında dağıtılan uygulamalar, tek bir müşteriyle ilişkilendirilmiş uygulamalar için özel olarak ayrılmış VM'lerde çalışır.

Dekont

App Service Ücretsiz ve Paylaşılan (önizleme) hizmet planları, diğer App Service uygulamalarıyla aynı Azure sanal makinelerinde çalışan temel katmanlardır. Bazı uygulamalar diğer müşterilere ait olabilir. Bu katmanlar yalnızca geliştirme ve test amacıyla tasarlanmıştır.

App Service katmanlar arasında sorunsuz bir ölçeklendirme deneyimini desteklediğinden, App Service uygulamaları için uygulanan güvenlik yapılandırması aynı kalır. Bu yapılandırma, bir App Service planı bir katmandan diğerine geçtiğinde uygulamaların aniden farklı davranmamasını ve beklenmedik şekilde başarısız olmasını sağlar.

Geliştirme çerçeveleri

App Service fiyatlandırma katmanları, uygulamalarda kullanılabilen işlem kaynaklarının (CPU, disk depolama, bellek ve ağ çıkışı) miktarını denetler. Ancak, ölçeklendirme katmanlarından bağımsız olarak uygulamalar için kullanılabilen çerçeve işlevselliğinin genişliği aynı kalır.

App Service, ASP.NET, klasik ASP, Node.js, PHP ve Python gibi çeşitli geliştirme çerçevelerini destekler. App Service uygulamaları, güvenlik yapılandırmasını basitleştirmek ve normalleştirmek için genellikle geliştirme çerçevelerini varsayılan ayarlarıyla çalıştırır. Platformun sağladığı çerçeveler ve çalışma zamanı bileşenleri, güvenlik ve uyumluluk gereksinimlerini karşılamak için düzenli olarak güncelleştirilir. Bu nedenle belirli ikincil/yama sürümlerini garanti etmeyiz. Müşterilerin gerektiğinde ana sürümleri hedeflemesini öneririz.

Aşağıdaki bölümlerde, App Service uygulamalarında kullanılabilen genel işletim sistemi işlevselliği türleri özetlenmektedir.

Dosya erişimi

App Service içinde yerel sürücüler ve ağ sürücüleri gibi çeşitli sürücüler vardır.

Yerel sürücüler

App Service, temel olarak Azure hizmet olarak platform (PaaS) altyapısının üzerinde çalışan bir hizmettir. Sonuç olarak, bir sanal makineyle ilişkili yerel sürücüler, Azure'da çalışan tüm çalışan rollerinde kullanılabilen sürücü türleriyle aynıdır. Bu ölçümler şunlardır:

• Boyutu VM'nin boyutuna bağlı olan bir işletim sistemi sürücüsü (%SystemDrive%).
• App Service'in dahili olarak kullandığı bir kaynak sürücüsü (%ResourceDrive%).

En iyi yöntem, sabit kodlanmış dosya yolları yerine her zaman ortam değişkenlerini %SystemDrive%%ResourceDrive% kullanmaktır. Bu iki ortam değişkeninden döndürülen kök yol, zaman içinde yerine d:\c:\kaydırıldı. Ancak, App Service işaret etmek için d:\ otomatik olarak yeniden eşlediğinden, dosya yolu başvuruları ile sabit kodlanmış eski uygulamalar çalışmaya devam etmek için başvurur d:\c:\. Daha önce de belirtildiği gibi, dosya yolları oluştururken her zaman ortam değişkenlerini kullanmanızı ve platform değişikliklerinin varsayılan kök dosya yolundaki karışıklığı önlemenizi kesinlikle öneririz.

Uygulamanız büyüdükçe disk kullanımınızı izlemek önemlidir. Disk kotalarına ulaşmanın uygulamanızda olumsuz etkileri olabilir. Örneğin:

• Uygulama diskte yeterli alan olmadığını belirten bir hata verebilir.
• Kudu konsoluna göz atarken disk hataları görebilirsiniz.
• Azure DevOps veya Visual Studio'dan dağıtım ile ERROR_NOT_ENOUGH_DISK_SPACE: Web deployment task failed. (Web Deploy detected insufficient space on disk)başarısız olabilir.
• Uygulamanızın performansı düşük olabilir.

Ağ sürücüleri (UNC paylaşımları)

App Service'in uygulama dağıtımını ve bakımını basit hale getiren benzersiz yönlerinden biri, tüm içerik paylaşımlarının bir DIZI UNC paylaşımında depolanmasıdır. Bu model, birden çok yük dengeli sunucuya sahip şirket içi web barındırma ortamları tarafından kullanılan ortak içerik depolama düzenine uygundur.

App Service'te, her veri merkezinde UNC paylaşımları oluşturulur. Her veri merkezinde yer alan tüm müşteriler için kullanıcı içeriğinin yüzdesi her UNC paylaşımına ayrılır. Her müşterinin aboneliği, bir veri merkezinde belirli bir UNC paylaşımında ayrılmış bir dizin yapısına sahiptir. Bir müşterinin belirli bir veri merkezinde birden çok uygulaması oluşturulmuş olabilir, bu nedenle tek bir müşteri aboneliğine ait tüm dizinler aynı UNC paylaşımında oluşturulur.

Azure hizmetlerinin çalışma şekli nedeniyle unc paylaşımını barındırmakla sorumlu olan sanal makine zaman içinde değişir. UNC paylaşımları, Azure işlemlerinin normal seyri sırasında açılan ve kapanan farklı sanal makineler tarafından bağlanır. Bu nedenle, uygulamalar bir UNC dosya yolundaki makine bilgilerinin zaman içinde kararlı kalacağına ilişkin sabit kodlanmış varsayımlarda bulunmamalıdır. Bunun yerine, App Service'in sağladığı uygun sahte mutlak yolu %HOME%\site kullanmalıdır.

Sahte mutlak yol, kendi uygulamanıza başvurmak için taşınabilir bir yöntemdir. Herhangi bir uygulama veya kullanıcıya özgü değildir. kullanarak %HOME%\site, her aktarım için yeni bir mutlak yol yapılandırmak zorunda kalmadan paylaşılan dosyaları uygulamadan uygulamaya aktarabilirsiniz.

Bir uygulamaya verilen dosya erişimi türleri

Bir uygulamadaki dizin, %HOME% azure Depolama ilgili uygulama için ayrılmış bir içerik paylaşımıyla eşler. Fiyatlandırma katmanınız boyutunu tanımlar. İçerik, hata ve tanılama günlükleri gibi dizinleri ve kaynak denetiminin oluşturduğu uygulamanın önceki sürümlerini içerebilir. Bu dizinler, okuma ve yazma erişimi için çalışma zamanında uygulamanın uygulama kodu tarafından kullanılabilir. Dosyalar yerel olarak depolanmadığından, uygulama yeniden başlatmalarında kalıcıdır.

Sistem sürücüsünde App Service %SystemDrive%\local , uygulamaya özgü geçici yerel depolama alanı ayırır. Bu dizindeki dosyalarda yapılan değişiklikler uygulama yeniden başlatmalarında kalıcı değildir . Bir uygulamanın kendi geçici yerel depolama alanına tam okuma ve yazma erişimi olsa da, bu depolama alanı uygulama kodu tarafından doğrudan kullanıma yönelik değildir. Bunun yerine, amaç IIS ve web uygulaması çerçeveleri için geçici dosya depolama alanı sağlamaktır.

App Service, tek tek uygulamaların aşırı miktarda yerel dosya depolama alanı kullanmasını önlemek için her uygulama için içindeki %SystemDrive%\local depolama miktarını sınırlar. Ücretsiz, Paylaşılan ve Tüketim (Azure İşlevleri) katmanları için sınır 500 MB'tır. Aşağıdaki tabloda diğer katmanlar listelemektedir:

Katman	Yerel dosya depolama
B1/S1/P1	11 GB
B2/S2/P2	15 GB
B3/S3/P3	58 GB
P0v3	11 GB
P1v2/P1v3/P1mv3/Isolated1/Isolated1v2	21 GB
P2v2/P2v3/P2mv3/Isolated2/Isolated2v2	61 GB
P3v2/P3v3/P3mv3/Isolated3/Isolated3v2	140 GB
Isolated4v2	276 GB
P4mv3	280 GB
Isolated5v2	552 GB
P5mv3	560 GB
Isolated6v2	1.104 GB

App Service'in geçici yerel depolamayı nasıl kullandığını gösteren iki örnek, geçici ASP.NET dosyalarının dizini ve IIS sıkıştırılmış dosyalarının dizinidir. ASP.NET derleme sistemi, dizini geçici bir derleme önbellek konumu olarak kullanır %SystemDrive%\local\Temporary ASP.NET Files . IIS, sıkıştırılmış yanıt çıkışını %SystemDrive%\local\IIS Temporary Compressed Files depolamak için dizinini kullanır. Bu dosya kullanımı türlerinin her ikisi de (diğerleriyle birlikte) App Service'te uygulama başına geçici yerel depolama alanına yeniden eşlenir. Bu yeniden eşleme, işlevselliğin beklendiği gibi devam etmesini sağlamaya yardımcı olur.

App Service'teki her uygulama, uygulama havuzu kimliği olarak adlandırılan rastgele, benzersiz, düşük ayrıcalıklı bir çalışan işlemi kimliği olarak çalışır. Uygulama kodu, işletim sistemi sürücüsüne temel salt okunur erişim için bu kimliği kullanır. Bu erişim, uygulama kodunun ortak dizin yapılarını listeleyip işletim sistemi sürücüsündeki ortak dosyaları okuyabileceği anlamına gelir. Bu erişim düzeyi geniş gibi görünse de, Azure tarafından barındırılan bir hizmette çalışan rolü sağladığınızda ve sürücü içeriğini okuduğunuzda aynı dizinlere ve dosyalara erişilebilir.

Birden çok örnek arasında dosya erişimi

İçerik paylaşımı (%HOME%) dizini bir uygulamanın içeriğini içerir ve uygulama kodu buna yazabilir. Bir uygulama birden çok örnekte çalışıyorsa, tüm örneklerin %HOME% aynı dizini görmesi için dizin tüm örnekler arasında paylaşılır. Örneğin, bir uygulama karşıya yüklenen dosyaları dizine %HOME% kaydederse, bu dosyalar tüm örnekler tarafından hemen kullanılabilir.

Geçici yerel depolama (%SystemDrive%\local) dizini örnekler arasında paylaşılmaz. Ayrıca uygulama ile Kudu uygulaması arasında paylaşılmaz.

Ağ erişimi

Uygulama kodu, dış hizmetleri kullanıma sunan İnternet'te erişilebilir uç noktalara giden ağ bağlantıları oluşturmak için TCP/IP ve UDP tabanlı protokoller kullanabilir. Uygulamalar, azure içindeki hizmetlere bağlanmak için aynı protokolleri kullanabilir; örneğin, Azure SQL Veritabanı için HTTPS bağlantıları kurarak.

Ayrıca, uygulamaların tek bir yerel geri döngü bağlantısı kurması ve bu yerel geri döngü yuvasında bir uygulamanın dinlemesini sağlamak için sınırlı bir özellik vardır. Bu özellik, işlevlerinin bir parçası olarak yerel geri döngü yuvalarını dinleyen uygulamalara olanak tanır. Her uygulamanın özel bir geri döngü bağlantısı vardır. Bir uygulama, başka bir uygulamanın oluşturduğu yerel bir geri döngü yuvasını dinleyemez.

Adlandırılmış kanallar, bir uygulamayı toplu olarak çalıştıran işlemler arasında işlemler arası iletişim mekanizması olarak da desteklenir. Örneğin IIS FastCGI modülü, PHP sayfalarını çalıştıran tek tek işlemleri koordine etmek için adlandırılmış kanallara dayanır.

Kod yürütme, işlemler ve bellek

Daha önce belirtildiği gibi, uygulamalar rastgele bir uygulama havuzu kimliği kullanarak düşük ayrıcalıklı çalışan işlemleri içinde çalışır. Uygulama kodu, çalışan işlemiyle ilişkili bellek alanına ve CGI işlemlerinin veya diğer uygulamaların oluşturabileceği alt işlemlere erişebilir. Ancak, bir uygulama aynı sanal makinede olsa bile başka bir uygulamanın belleğine veya verilerine erişemez.

Uygulamalar desteklenen web geliştirme çerçeveleriyle yazılmış betikler veya sayfalar çalıştırabilir. App Service herhangi bir web çerçevesi ayarlarını daha kısıtlı modlar için yapılandırmaz. Örneğin, App Service'te çalışan ASP.NET uygulamalar, daha kısıtlı bir güven modu yerine tam güven içinde çalışır. Hem klasik ASP hem de ASP.NET de dahil olmak üzere web çerçeveleri, Windows işletim sisteminde varsayılan olarak kaydedilen işlem içi COM bileşenlerini (ActiveX Veri Nesneleri gibi) çağırabilir. Web çerçeveleri işlem dışı COM bileşenlerini çağıramaz.

Bir uygulama rastgele kod oluşturup çalıştırabilir, komut kabuğu açabilir veya bir PowerShell betiği çalıştırabilir. Ancak yürütülebilir programlar ve betikler yine de üst uygulama havuzuna verilen ayrıcalıklarla sınırlıdır. Örneğin, bir uygulama giden HTTP çağrısı yapan yürütülebilir bir program oluşturabilir, ancak bu yürütülebilir program sanal makinenin IP adresini ağ bağdaştırıcısından ayırmayı deneyemez. Düşük ayrıcalıklı kod için giden ağ çağrısına izin verilir, ancak sanal makinede ağ ayarlarını yeniden yapılandırmaya çalışmak yönetici ayrıcalıkları gerektirir.

Tanılama günlükleri ve olayları

Günlük bilgileri, bazı uygulamaların erişmeye çalıştığı başka bir veri kümesidir. App Service'te çalıştırılan kodun kullanabileceği günlük bilgisi türleri, bir uygulamanın oluşturduğu ve kolayca erişebildiği tanılama ve günlük bilgilerini içerir.

Örneğin, uygulama tarafından oluşturulan W3C HTTP günlükleri şunlardan biri kullanılabilir:

• Uygulama için oluşturduğunuz ağ paylaşımı konumundaki bir günlük dizininde
• Depolamada W3C günlüğünü ayarladıysanız blob depolamada

İkinci seçenek, uygulamaların ağ paylaşımıyla ilişkili dosya depolama sınırlarını aşmadan büyük miktarda günlük toplamasına olanak tanır.

Benzer şekilde, .NET uygulamalarından gerçek zamanlı tanılama bilgileri .NET izleme ve tanılama altyapısı aracılığıyla günlüğe kaydedilebilir. Ardından izleme bilgilerini uygulamanın ağ paylaşımına veya blob depolama konumuna yazabilirsiniz.

Tanılama günlüğü ve izlemenin uygulamalar tarafından kullanılamayabilecek alanları Windows için Windows Olay İzleme (ETW) olayları ve yaygın Windows olay günlükleridir (örneğin, sistem, uygulama ve güvenlik olay günlükleri). ETW izleme bilgileri bir makinede görüntülenebilir olabileceğinden (doğru erişim denetim listeleriyle), ETW olaylarına okuma erişimi ve yazma erişimi engellenir. ETW olaylarını ve yaygın Windows olay günlüklerini okumak ve yazmak için API çağrıları çalışıyor gibi görünebilir, ancak gerçekte uygulama kodunun bu olay verilerine erişimi yoktur.

Kayıt defteri erişimi

Uygulamalar, üzerinde çalıştıkları sanal makinenin kayıt defterinin çoğuna (ancak tümüne değil) salt okunur erişime sahiptir. Bu erişim, uygulamaların Yerel Kullanıcılar grubuna salt okunur erişim sağlayan kayıt defteri anahtarlarına erişebileceği anlamına gelir. Kayıt defterinin şu anda okuma veya yazma erişimi için desteklenmeyen bir alanı kovandır HKEY\_CURRENT\_USER .

Kullanıcı başına kayıt defteri anahtarlarına erişim de dahil olmak üzere kayıt defterine yazma erişimi engellenir. Uygulama açısından bakıldığında, uygulamalar sanal makineler arasında geçirilebildiği için Azure ortamında kayıt defterine yazma erişimine güvenemez. Bir uygulamanın bağımlı olabileceği tek kalıcı yazılabilir depolama, App Service UNC paylaşımlarında depolanan uygulama başına içerik dizin yapısıdır.

Uzak masaüstü erişimi

App Service, VM örneklerine uzak masaüstü erişimi sağlamaz.

Daha fazla bilgi

App Service'in yürütme ortamı hakkında en güncel bilgiler için bkz. Azure Uygulaması Hizmeti korumalı alanı. App Service geliştirme ekibi bu sayfayı korur.