Azure App Service’ta hazırlık ortamları ayarlama

Web uygulamanızı, Linux'ta web uygulamasını, mobil arka ucu veya API uygulamasını Azure Uygulaması Hizmeti'ne dağıttığınızda, varsayılan üretim yuvası yerine ayrı bir dağıtım yuvası kullanabilirsiniz. Bu yaklaşım, Standart, Premium veya Yalıtılmış App Service plan katmanında çalışıyorsanız kullanılabilir. Dağıtım yuvaları, kendi konak adlarına sahip canlı uygulamalardır. Uygulama içeriği ve yapılandırmaları, üretim yuvası da dahil olmak üzere iki dağıtım yuvası arasında değişiklik yapılabilir.

Uygulamanızı üretim dışı bir yuvaya dağıtmanın aşağıdaki avantajları vardır:

• Hazırlama dağıtım yuvasındaki uygulama değişikliklerini üretim yuvasıyla değiştirmeden önce doğrulayabilirsiniz.
• Bir uygulamayı önce bir yuvaya dağıtmak ve üretime değiştirmek, yuvayı üretime geçirmeden önce yuvanın tüm örneklerinin ısınmasını sağlar. Bu yaklaşım, uygulamanızı dağıtırken kapalı kalma süresini ortadan kaldırır. Trafik yeniden yönlendirmesi sorunsuz. Değiştirme işlemleri nedeniyle hiçbir istek bırakılmaz. Değiştirme öncesi doğrulama gerekli olmadığında otomatik değiştirme yapılandırarak bu iş akışının tamamını otomatikleştirebilirsiniz.
• Değiştirme işleminden sonra, önceden hazırlanmış olan uygulamanın yuvasında artık önceki üretim uygulaması bulunur. Üretim yuvasında değiştirilen değişiklikler beklediğiniz gibi değilse, bilinen son iyi sitenizi geri almak için aynı değişimi hemen gerçekleştirebilirsiniz.

Her App Service planı katmanı farklı sayıda dağıtım yuvalarını destekler. Dağıtım yuvalarını kullanmak için ek ücret alınmaz. Uygulamanızın katmanının desteklediği yuva sayısını öğrenmek için bkz . App Service sınırları.

Uygulamanızı farklı bir katmana ölçeklendirmek için hedef katmanın uygulamanızın zaten kullandığı yuva sayısını desteklediğinden emin olun. Örneğin, uygulamanızın beşten fazla yuvası varsa ölçeği Standart katmana indiremezsiniz. Standart katman yalnızca beş dağıtım yuvasını destekler.

Bu videoda, Azure Uygulaması Hizmeti'nde hazırlama ortamlarının nasıl ayarlanacağı gösterilmektedir.

Videodaki adımlar aşağıdaki bölümlerde de açıklanmıştır.

Önkoşullar

• İstediğiniz yuva işlemini gerçekleştirmek için ihtiyacınız olan izinler hakkında bilgi için bkz . Kaynak sağlayıcısı işlemleri. Örneğin yuvayı arayın.

Yuva ekleme

Birden çok dağıtım yuvasını etkinleştirebilmeniz için uygulamanın Standart, Premium veya Yalıtılmış katmanında çalışıyor olması gerekir.

az webapp deployment slot create --name <app-name> --resource-group <group-name> --slot <slot-name>

New-AzWebAppSlot -ResourceGroupName <group-name> -Name <app-name> -Slot <slot-name> -AppServicePlan <plan-name>

Ayarları farklı bir yuvadan kopyalasanız bile yeni dağıtım yuvasında içerik yoktur. Örneğin, Git ile bu yuvaya yayımlayabilirsiniz. Yuvaya farklı bir depo dalından veya farklı bir depodan dağıtabilirsiniz. Azure Uygulaması Hizmetinden yayımlama profili alın, yuvaya dağıtmak için gerekli bilgileri sağlayabilir. Visual Studio, içeriği yuvaya dağıtmak için profili içeri aktarabilir.

Yuvanın URL'si biçimindedir http://sitename-slotname.azurewebsites.net. URL uzunluğunu gerekli DNS sınırları içinde tutmak için site adı 40 karakterde kesilir. Birleştirilmiş site adı ve yuva adı 59 karakterden az olmalıdır.

Değiştirme sırasında ne olur?

Değiştirme işlemi adımları

İki yuvayı değiştirdiğinizde App Service, hedef yuvanın kapalı kalma süresi yaşamadığından emin olmak için aşağıdakileri yapar:

1. Hedef yuvadan (örneğin, üretim yuvası) aşağıdaki ayarları kaynak yuvanın tüm örneklerine uygulayın:

   • Varsa yuvaya özgü uygulama ayarları ve bağlantı dizesi.
   • Etkinse sürekli dağıtım ayarları.
   • Etkinse App Service kimlik doğrulama ayarları.

   Kaynak yuvaya herhangi bir ayar uygulandığında, değişiklik kaynak yuvadaki tüm örneklerin yeniden başlatılmasını tetikler. Önizleme ile değiştirme sırasında, bu eylem ilk aşamanın sonunu işaretler. Değiştirme işlemi duraklatıldı. Kaynak yuvanın hedef yuva ayarlarıyla düzgün çalıştığını doğrulayabilirsiniz.

2. Kaynak yuvadaki her örneğin yeniden başlatılmasını bekleyin. Herhangi bir örnek yeniden başlatılamazsa, değiştirme işlemi kaynak yuvadaki tüm değişiklikleri geri döndürür ve işlemi durdurur.

3. Yerel önbellek etkinleştirildiyse, kaynak yuvanın her örneğinde uygulama köküne ("/") http isteğinde bulunarak yerel önbellek başlatmayı tetikleyin. Her örnek herhangi bir HTTP yanıtı döndürene kadar bekleyin. Yerel önbellek başlatma, her örnekte başka bir yeniden başlatmaya neden olur.

4. Özel ısınma ile otomatik değiştirme etkinleştirildiyse, kaynak yuvanın her örneğinde özel Uygulama Başlatma'yı tetikleyin.

   Belirtilmezse applicationInitialization , her örnekteki kaynak yuvanın uygulama köküne bir HTTP isteği tetikleyin.

   Bir örnek herhangi bir HTTP yanıtı döndürürse, bu yanıtın ısınmış olduğu kabul edilir.

5. Kaynak yuvadaki tüm örnekler başarıyla ısındıysa, iki yuva için yönlendirme kurallarını değiştirerek iki yuvayı değiştirin. Bu adımdan sonra hedef yuvada (örneğin, üretim yuvası) daha önce kaynak yuvada ısıtılmış olan uygulama bulunur.

6. Kaynak yuvada daha önce hedef yuvada önceden takas öncesi uygulama olduğuna göre, tüm ayarları uygulayarak ve örnekleri yeniden başlatarak aynı işlemi gerçekleştirin.

Değiştirme işleminin herhangi bir noktasında, değiştirilen uygulamaları başlatma işleminin tüm çalışmaları kaynak yuvada gerçekleşir. Değiştirme işleminin başarılı veya başarısız olmasına bakılmaksızın kaynak yuva hazırlanırken ve ısınırken hedef yuva çevrimiçi kalır. Hazırlama yuvasını üretim yuvasıyla değiştirmek için üretim yuvasının her zaman hedef yuva olduğundan emin olun. Bu şekilde, değiştirme işlemi üretim uygulamanızı etkilemez.

Hangi ayarlar değiştirilir?

Yapılandırmayı başka bir dağıtım yuvasından kopyaladığınızda, kopyalanan yapılandırma düzenlenebilir. Bazı yapılandırma öğeleri, içeriği bir değiştirme işlemi boyunca izler (yuvaya özgü değildir). Diğer yapılandırma öğeleri, değiştirme işleminden (yuvaya özgü) sonra aynı yuvada kalır. Aşağıdaki listelerde yuvaları değiştirdiğinizde değişen ayarlar gösterilir.

Değiştirilen ayarlar:

• Dil yığını ve sürüm, 32/64 bit
• Uygulama ayarları (yuvaya bağlı kalmak için yapılandırılabilir)
• Bağlantı dizeleri (yuvaya bağlı kalmak için yapılandırılabilir)
• Bağlı depolama hesapları (bir yuvaya bağlı kalmak için yapılandırılabilir)
• İşleyici eşlemeleri
• Ortak sertifikalar
• Web İşleri içeriği
• Karma bağlantılar *
• Hizmet uç noktaları *
• Azure Content Delivery Network *
• Yol eşlemeleri

Yıldız işareti (*) ile işaretlenmiş özelliklerin eşlenmemiş olması planlanıyor.

Değiştirilmeyen ayarlar:

• Değiştirilen Ayarlar'da belirtilmeyen genel ayarlar
• Yayımlama uç noktaları
• Özel etki alanı adları
• Abonelik dışı sertifikalar ve TLS/SSL ayarları
• Ölçek ayarları
• Web İşleri zamanlayıcıları
• IP kısıtlamaları
• Her Zaman Açık
• Tanılama ayarları
• Çıkış noktaları arası kaynak paylaşımı (CORS)
• Sanal ağ tümleştirmesi
• Yönetilen kimlikler ve ilgili ayarlar
• Sonek _EXTENSION_VERSION ile biten ayarlar
• Service Connector tarafından oluşturulan ayarlar

Bir uygulama ayarını yapılandırmak veya değiştirilmemiş belirli bir yuvaya bağlı kalmak için bağlantı dizesi ilgili yuvanın Ayarlar>Ortam Değişkeni sayfasına gidin. Bir ayar ekleyin veya düzenleyin ve ardından Dağıtım yuvası ayarı'nu seçin. Bu seçeneğin belirlenmesi App Service'e ayarın değiştirilemez olduğunu bildirir.

İki yuvayı değiştirme

Uygulamanızın Dağıtım yuvaları sayfasında ve Genel Bakış sayfasında dağıtım yuvalarını değiştirebilirsiniz. Yuva değiştirme hakkında daha fazla bilgi için bkz . Değiştirme sırasında ne olur?

az webapp deployment slot swap --resource-group <group-name> --name <app-name> --slot <source-slot-name> --target-slot production

Switch-AzWebAppSlot -SourceSlotName "<source-slot-name>" -DestinationSlotName "production" -ResourceGroupName "<group-name>" -Name "<app-name>"

Herhangi bir sorun yaşıyorsanız bkz . Değiştirme sorunlarını giderme.

Önizleme ile değiştirme (çok fazlı değiştirme)

Hedef yuva olarak üretime geçmeden önce, uygulamanın değiştirilen ayarlarla çalıştığını doğrulayın. Kaynak yuva, görev açısından kritik uygulamalar için tercih edilen değiştirme tamamlanmadan önce de ısıtılır.

Önizleme ile değiştirme işlemi gerçekleştirdiğinizde App Service aynı değiştirme işlemini gerçekleştirir ancak ilk adımdan sonra duraklatılır. Daha sonra değiştirme işlemini tamamlamadan önce hazırlama yuvasındaki sonucu doğrulayabilirsiniz.

Değiştirme işlemini iptal ederseniz App Service yapılandırma öğelerini kaynak yuvaya yeniden ekler.

az webapp deployment slot swap --resource-group <group-name> --name <app-name> --slot <source-slot-name> --target-slot production --action preview

az webapp deployment slot swap --resource-group <group-name> --name <app-name> --slot <source-slot-name> --target-slot production --action swap

az webapp deployment slot swap --resource-group <group-name> --name <app-name> --slot <source-slot-name> --target-slot production --action reset

Switch-AzWebAppSlot -SourceSlotName "<source-slot-name>" -DestinationSlotName "production" -ResourceGroupName "<group-name>" -Name "<app-name>" -SwapWithPreviewAction ApplySlotConfig

Switch-AzWebAppSlot -SourceSlotName "<source-slot-name>" -DestinationSlotName "production" -ResourceGroupName "<group-name>" -Name "<app-name>" -SwapWithPreviewAction CompleteSlotSwap

Switch-AzWebAppSlot -SourceSlotName "<source-slot-name>" -DestinationSlotName "production" -ResourceGroupName "<group-name>" -Name "<app-name>" -SwapWithPreviewAction ResetSlotSwap

Herhangi bir sorun yaşıyorsanız bkz . Değiştirme sorunlarını giderme.

Değiştirme işlemini geri alma

Yuva değiştirme işleminden sonra hedef yuvada (örneğin, üretim yuvası) herhangi bir hata oluşursa, aynı iki yuvayı hemen değiştirerek yuvaları önceden değiştirme durumlarına geri yükleyin.

Otomatik değiştirme yapılandırması

Otomatik değiştirme, uygulamanızı sıfır soğuk başlangıç ve uygulama müşterileri için sıfır kapalı kalma süresiyle sürekli dağıtmak istediğiniz Azure DevOps senaryolarını kolaylaştırır. Otomatik değiştirme bir yuvadan üretime etkinleştirildiğinde, kod değişikliklerinizi bu yuvaya her gönderdiğinizde App Service, kaynak yuvada ısındıktan sonra uygulamayı otomatik olarak üretime değiştirir.

az webapp deployment slot auto-swap --name <app-name> --resource-group <group-name> --slot <source-slot-name>

az webapp deployment slot auto-swap --name <app-name> --resource-group <group-name> --slot <source-slot-name> --disable

Set-AzWebAppSlot -ResourceGroupName "<group-name>" -Name "<app-name>" -Slot "<source-slot-name>" -AutoSwapSlotName "production"

Herhangi bir sorun yaşıyorsanız bkz . Değiştirme sorunlarını giderme.

Özel ısınmayı belirtme

Bazı uygulamalar, değiştirme işleminden önce özel ısınma eylemleri gerektirebilir. applicationInitialization web.config içindeki yapılandırma öğesi, özel başlatma eylemleri belirtmenize olanak tanır. Değiştirme işlemi , hedef yuvayla değiştirmeden önce bu özel ısınmanın bitmesini bekler. Aşağıda örnek bir web.config parçası verilmiş.

<system.webServer>
    <applicationInitialization>
        <add initializationPage="/" hostName="[app hostname]" />
        <add initializationPage="/Home/About" hostName="[app hostname]" />
    </applicationInitialization>
</system.webServer>

öğesini özelleştirme applicationInitialization hakkında daha fazla bilgi için bkz . En yaygın dağıtım yuvası değiştirme hataları ve bunların nasıl düzeltilmesi.

Ayrıca, aşağıdaki uygulama ayarlarıyla ısınma davranışını özelleştirebilirsiniz:

• WEBSITE_SWAP_WARMUP_PING_PATH: Sitenizi ısıtmak için HTTP üzerinden ping gönderme yolu. Değer olarak eğik çizgiyle başlayan özel bir yol belirterek bu uygulama ayarını ekleyin. /statuscheck bunun bir örneğidir. Varsayılan değer şudur: /.
• WEBSITE_SWAP_WARMUP_PING_STATUSES: Isınma işlemi için geçerli HTTP yanıt kodları. Http kodlarının virgülle ayrılmış listesiyle bu uygulama ayarını ekleyin. 200,202 bunun bir örneğidir. Döndürülen durum kodu listede yoksa, ısınma ve değiştirme işlemleri durdurulur. Varsayılan olarak, tüm yanıt kodları geçerlidir.
• WEBSITE_WARMUP_PATH: Site yeniden başlatıldığında (yalnızca yuva değiştirme işlemleri sırasında değil) ping atılması gereken, sitede göreli bir yol. Örnek değerler şunlardır/statuscheck: veya kök yolu. /

Herhangi bir sorun yaşıyorsanız bkz . Değiştirme sorunlarını giderme.

Değişimi izleme

Değiştirme işleminin tamamlanması uzun sürüyorsa, etkinlik günlüğünde değiştirme işlemi hakkında bilgi alabilirsiniz.

az monitor activity-log list --resource-group <group-name> --query "[?contains(operationName.value,'Microsoft.Web/sites/slots/slotsswap/action')]"

Get-AzLog -ResourceGroup <group-name> -StartTime 2025-01-01 | where{$_.OperationName -eq 'Swap Web App Slots'}

Üretim trafiğini otomatik olarak yönlendirme

Varsayılan olarak, uygulamanın üretim URL'sine (http://<app_name>.azurewebsites.net) yönelik tüm istemci istekleri üretim yuvasına yönlendirilir. Trafiğin bir bölümünü başka bir yuvaya yönlendirebilirsiniz. Bu özellik, yeni bir güncelleştirme için kullanıcı geri bildirimine ihtiyacınız varsa ancak bunu üretim ortamına yayınlamaya hazır değilseniz kullanışlıdır.

az webapp traffic-routing set --resource-group <group-name> --name <app-name> --distribution <slot-name>=15

Add-AzWebAppTrafficRouting -ResourceGroupName "<group-name>" -WebAppName "<app-name>" -RoutingRule @{ActionHostName='<app-name>-<slot-name>.azurewebsites.net';ReroutePercentage='15';Name='<slot-name>'}

bir istemci otomatik olarak belirli bir yuvaya yönlendirildikten sonra, bir saat boyunca veya tanımlama bilgileri silinene kadar bu yuvaya sabitlenir . İstemci tarayıcısında, HTTP üst bilgilerinizdeki tanımlama bilgisine bakarak oturumunuzun hangi yuvaya x-ms-routing-name sabitlendiğini görebilirsiniz. Hazırlama yuvasına yönlendirilen istekte tanımlama bilgisi x-ms-routing-name=stagingbulunur. Üretim yuvasına yönlendirilen bir istekte tanımlama bilgisi x-ms-routing-name=selfbulunur.

Üretim trafiğini el ile yönlendirme

App Service, otomatik trafik yönlendirmeye ek olarak istekleri belirli bir yuvaya yönlendirebilir. Bu seçenek, kullanıcılarınızın beta uygulamanızı kabul edebilmesini veya geri çevirebilmesini istediğinizde kullanışlıdır. Üretim trafiğini el ile yönlendirmek için sorgu parametresini x-ms-routing-name kullanırsınız.

Kullanıcıların beta uygulamanızdan vazgeçmesine izin vermek için bu bağlantıyı web sayfanıza yerleştirebilirsiniz:

<a href="<webappname>.azurewebsites.net/?x-ms-routing-name=self">Go back to production app</a>

Dize x-ms-routing-name=self , üretim yuvasını belirtir. İstemci tarayıcısı bağlantıya eriştiğinde üretim yuvasına yönlendirilir. Sonraki her istekte x-ms-routing-name=self oturumu üretim yuvasına sabitleyen tanımlama bilgisi bulunur.

Kullanıcıların beta uygulamanızı kabul etmesine izin vermek için aynı sorgu parametresini üretim dışı yuvanın adı olarak ayarlayın. Bir örnek aşağıda verilmiştir:

<webappname>.azurewebsites.net/?x-ms-routing-name=staging

Varsayılan olarak, yeni yuvalara gri renkte gösterilen yönlendirme kuralı 0%verilir. Bu değeri 0% açıkça olarak olarak ayarladığınızda (siyah metinle gösterilir), kullanıcılarınız sorgu parametresini kullanarak hazırlama yuvasına x-ms-routing-name el ile erişebilir. Yönlendirme yüzdesi 0 olarak ayarlandığından yuvaya otomatik olarak yönlendirilmeyeceklerdir. Bu yapılandırma, iç ekiplerin yuvadaki değişiklikleri test etmelerine izin verirken hazırlama yuvanızı genelden gizleyebileceğiniz gelişmiş bir senaryodur.

Yuva silme

az webapp deployment slot delete --name <app-name> --resource-group <group-name> --slot <slot-name>

Remove-AzWebAppSlot -ResourceGroupName "<group-name>" -Name "<app-name>" -Slot "<slot-name>"

Resource Manager şablonlarıyla otomatikleştirme

Azure Resource Manager şablonları , Azure kaynaklarının dağıtımını ve yapılandırmasını otomatikleştirmek için kullanılan bildirim temelli JSON dosyalarıdır. Resource Manager şablonlarını kullanarak yuvaları değiştirmek için Microsoft.Web/sites/slots ve Microsoft.Web/sites kaynaklarında iki özellik ayarlarsınız:

• buildVersion: Yuvada dağıtılan uygulamanın geçerli sürümünü temsil eden dize özelliği. Örneğin: v1, 1.0.0.1veya 2019-09-20T11:53:25.2887393-07:00.
• targetBuildVersion: Yuvanın sahip buildVersion olması gerekenleri belirten bir dize özelliği. targetBuildVersion değeri geçerli buildVersiondeğerine eşit değilse, belirtilen buildVersionile yuvayı bularak değiştirme işlemini tetikler.

Örnek Resource Manager şablonu

Aşağıdaki Resource Manager şablonu, yuvayı buildVersionstaging güncelleştirerek ve üretim yuvasında ayarını yaparak targetBuildVersion iki yuvayı değiştirir. adlı stagingbir yuvanız olmalıdır.

{
    "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "my_site_name": {
            "defaultValue": "SwapAPIDemo",
            "type": "String"
        },
        "sites_buildVersion": {
            "defaultValue": "v1",
            "type": "String"
        }
    },
    "resources": [
        {
            "type": "Microsoft.Web/sites/slots",
            "apiVersion": "2018-02-01",
            "name": "[concat(parameters('my_site_name'), '/staging')]",
            "location": "East US",
            "kind": "app",
            "properties": {
                "buildVersion": "[parameters('sites_buildVersion')]"
            }
        },
        {
            "type": "Microsoft.Web/sites",
            "apiVersion": "2018-02-01",
            "name": "[parameters('my_site_name')]",
            "location": "East US",
            "kind": "app",
            "dependsOn": [
                "[resourceId('Microsoft.Web/sites/slots', parameters('my_site_name'), 'staging')]"
            ],
            "properties": {
                "targetBuildVersion": "[parameters('sites_buildVersion')]"
            }
        }        
    ]
}

Bu Resource Manager şablonu bir kez etkili. Bunu tekrar tekrar çalıştırabilir ve yuvaların aynı durumunu oluşturabilirsiniz. Şablonda herhangi bir değişiklik yapılmadığında, yuvalar zaten istenen durumda olduğundan aynı şablonun sonraki çalıştırmaları yuva değişimini tetiklemez.

Değiştirme sorunlarını giderme

Yuva değiştirme sırasında herhangi bir hata oluşursa, hata D:\home\LogFiles\eventlog.xml içinde görüntülenir. Ayrıca uygulamaya özgü hata günlüğüne de kaydedilir.

Bazı yaygın takas hataları şunlardır:

• Uygulama köküne yönelik http isteği zamanlanmış. Değiştirme işlemi her HTTP isteği için 90 saniye bekler ve en fazla beş kez yeniden denenir. Tüm yeniden denemeler zaman aşımına uğradıysa değiştirme işlemi durdurulur.

• Uygulama içeriği yerel önbellek için belirtilen yerel disk kotasını aştığında yerel önbellek başlatma başarısız olabilir. Daha fazla bilgi için bkz . Yerel önbelleğe genel bakış.

• Site güncelleştirme işlemi sırasında aşağıdaki hata oluşabilir Yapılandırma ayarları takas için hazırlandığı için yuva değiştirilemez. Önizleme ile değiştirme (çok aşamalı değiştirme) 1. aşama tamamlandığında ancak 2. aşama henüz gerçekleştirilmezse bu hata oluşabilir. Değiştirme işlemi başarısız olursa da oluşabilir. Bu sorunu çözmenin iki yolu vardır:

  • Siteyi eski durumuna geri sıfırlayan değiştirme işlemini iptal etme
  • Siteyi istenen yeni duruma güncelleştiren değiştirme işlemini tamamlayın

  Değiştirme işlemini iptal etmeyi veya tamamlamayı öğrenmek için bkz . önizleme ile değiştirme (çok aşamalı değiştirme).

• Özel ısınma sırasında, HTTP istekleri dış URL'ye gitmeden dahili olarak yapılır. Web.config'de belirli URL yeniden yazma kurallarıyla başarısız olabilirler. Örneğin, etki alanı adlarını yeniden yönlendirme veya HTTPS'yi zorunlu tutma kuralları, ısınma isteklerinin uygulama koduna ulaşmasını engelleyebilir. Bu sorunu geçici olarak çözmek için, aşağıdaki iki koşulu ekleyerek yeniden yazma kurallarınızı değiştirin:

  <conditions>
    <add input="{WARMUP_REQUEST}" pattern="1" negate="true" />
    <add input="{REMOTE_ADDR}" pattern="^100?\." negate="true" />
    ...
  </conditions>
  

• Özel bir ısınma olmadan, URL yeniden yazma kuralları YINE DE HTTP isteklerini engelleyebilir. Bu sorunu geçici olarak çözmek için aşağıdaki koşulu ekleyerek yeniden yazma kurallarınızı değiştirin:

  <conditions>
    <add input="{REMOTE_ADDR}" pattern="^100?\." negate="true" />
    ...
  </conditions>
  

• Yuva değiştirme işleminden sonra uygulama beklenmeyen yeniden başlatmalarla karşılaşabilir. Bir değiştirme işleminden sonra ana bilgisayar adı bağlama yapılandırması eşitlenmediğinden yeniden başlatmalar gerçekleşir. Bu durum tek başına yeniden başlatmalara neden olmaz. Ancak, depolama birimi yük devretmeleri gibi bazı temel alınan depolama olayları bu tutarsızlıkları algılayabilir ve tüm çalışan işlemlerini yeniden başlatmaya zorlayabilir. Bu tür yeniden başlatmaları en aza indirmek için tüm yuvalarda uygulama ayarını ayarlayınWEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG=1. Ancak bu uygulama ayarı Windows Communication Foundation (WCF) uygulamalarıyla çalışmaz.

Sonraki adım