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

web uygulamanızı, Linux 'ta web uygulamanızı, mobil arka uca veya apı uygulamasını Azure App Serviceiçin dağıtırken, standart, Premium veya yalıtılmış App Service plan katmanında çalışırken varsayılan üretim yuvası yerine ayrı bir dağıtım yuvası kullanabilirsiniz. Dağıtım yuvaları, kendi ana bilgisayar adlarına sahip canlı uygulamalardır. Uygulama içeriği ve yapılandırma öğeleri, üretim yuvası dahil olmak üzere iki dağıtım yuvası arasında değiştirilebilir.

Uygulamanızı üretim dışı bir yuvaya dağıtmak aşağıdaki avantajlara sahiptir:

• Üretim yuvası ile takas etmeden önce hazırlama dağıtım yuvasındaki uygulama değişikliklerini doğrulayabilirsiniz.
• Bir uygulamayı önce bir yuvaya dağıtıp ardından üretim ortamına geçirmek, tüm yuva örneklerinin üretime alınmadan önce hazır olmasını sağlar. Bu da uygulamanızı kapalı kalma süresi olmadan dağıtmanıza imkan tanır. Trafik yeniden yönlendirmesi sorunsuz ve değiştirme işlemleri nedeniyle hiçbir istek atılamaz. Ön değiştirme doğrulaması gerekli olmadığında otomatik değiştirme 'yi yapılandırarak bu bütün iş akışını otomatikleştirebilirsiniz.
• Bir değiştirme işleminden sonra, önceden hazırlanmış uygulamaya sahip yuva artık önceki üretim uygulamasına sahiptir. Üretim yuvasında takas edilen değişiklikler beklenmediği sürece, "bilinen son iyi siteyi" geri almak için aynı değiştirmeyi hemen gerçekleştirebilirsiniz.

Her bir App Service plan katmanı farklı sayıda dağıtım yuvası 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ızda beşten fazla yuva varsa Standart katman yalnızca beş dağıtım yuvası desteklediğinden Standart katmana ölçeklendiremez.

Yuva ekleme

birden çok dağıtım yuvası etkinleştirebilmeniz için uygulamanın standart, Premium veya yalıtılmış katmanda çalışıyor olması gerekir.

1. Azure Portal, uygulama hizmetleri ' ni arayıp seçin ve uygulamanızı seçin.

   

2. Sol bölmede dağıtım yuvaları > yuva Ekle' yi seçin.

   

   Not

   uygulama zaten standart, Premium veya yalıtılmış katmanda değilse, hazırlanan yayımlamayı etkinleştirmek için desteklenen katmanları gösteren bir ileti alırsınız. Bu noktada, devam etmeden önce Yükselt ' i seçme ve uygulamanızın Ölçek sekmesine gitme seçeneğiniz vardır.

3. Yuva Ekle iletişim kutusunda yuvaya bir ad verin ve bir uygulama yapılandırmasını başka bir dağıtım yuvasından klonlamak isteyip istemediğinizi seçin. Devam etmek için Ekle ' yi seçin.

   

   Bir yapılandırmayı var olan herhangi bir yuvadan kopyalayabilirsiniz. klonlanacak Ayarlar, uygulama ayarları, bağlantı dizeleri, dil çerçevesi sürümleri, web yuvaları, HTTP sürümü ve platform bit kullanımı dahil olmak üzere.

4. Yuva eklendikten sonra, iletişim kutusunu kapatmak için Kapat ' ı seçin. Yeni yuva artık dağıtım yuvaları sayfasında gösteriliyor. Varsayılan olarak, % trafiği yeni yuva için, tüm müşteri trafiği üretim yuvasına yönlendirilirken 0 olarak ayarlanır.

5. Bu yuvanın kaynak sayfasını açmak için yeni dağıtım yuvasını seçin.

   

   Hazırlama yuvasında, tıpkı diğer App Service uygulamaları gibi bir yönetim sayfası vardır. Yuvanın yapılandırmasını değiştirebilirsiniz. Dağıtım yuvasını görüntülemekte olduğunuzu hatırlatmak için, uygulama adı olarak gösterilir <app-name>/<slot-name> ve uygulama türü App Service (yuva) olur. Ayrıca, yuvası aynı gösterimlerle aynı şekilde kaynak grubunuzda ayrı bir uygulama olarak da görebilirsiniz.

6. Yuvanın kaynak sayfasında Uygulama URL 'sini seçin. Dağıtım yuvası kendi ana bilgisayar adına sahiptir ve ayrıca canlı bir uygulamadır. Dağıtım yuvasına genel erişimi sınırlandırmak için bkz. IP kısıtlamaları Azure App Service.

Ayarları farklı bir yuvadan kopyalasanız bile, yeni dağıtım yuvasının içeriği yoktur. Örneğin, Bu yuvaya git ile yayımlayabilirsiniz. Yuvaya farklı bir depo dalından veya farklı bir depodan dağıtım yapabilirsiniz.

Yuvanın URL 'SI biçimde olacaktır http://sitename-slotname.azurewebsites.net . URL uzunluğunu gerekli DNS sınırları içinde tutmak için, site adı 40 karakterden kesilir, yuva adı 19 karakterden kesilir ve sonuçta elde edilen etki alanı adının benzersiz olduğundan emin olmak için ek 4 rastgele karakter eklenir.

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

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

İki yuva (genellikle bir hazırlama yuvasından üretim yuvasına) değiştirdiğinizde App Service, hedef yuvanın kapalı kalma süresi yaşamasını sağlamak için aşağıdakileri yapar:

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

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

   Bu durumların herhangi biri kaynak yuvadaki tüm örnekleri yeniden başlatılacak şekilde tetikler. Önizleme ile değiştirmesırasında, bu ilk aşamanın sonunu işaretler. Değiştirme işlemi duraklatılır ve kaynak yuvasının hedef yuvasının ayarlarıyla doğru şekilde çalışıp çalışmadığını doğrulayabilirsiniz.

2. Kaynak yuvadaki her örnek için yeniden başlatma işleminin tamamlanmasını bekleyin. Herhangi bir örnek yeniden başlatılamazsa, değiştirme işlemi kaynak yuvada tüm değişiklikleri geri alır ve işlemi sonlandırır.

3. Yerel önbellek etkinse, kaynak yuvasının her örneğindeki uygulama köküne ("/") bir http isteği getirerek 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. Otomatik takas özel ısınmaile etkinleştirilirse, kaynak yuvasının her örneğindeki uygulama köküne ("/") bir http isteği getirerek uygulama başlatma tetikleyin.

   applicationInitializationBelirtilmezse, her örnekteki kaynak yuvasının uygulama köküne BIR http isteği tetikleyin.

   Bir örnek herhangi bir HTTP yanıtı döndürürse, bu, çarpımış olarak kabul edilir.

5. Kaynak yuvasındaki tüm örnekler başarıyla çarpıtlarsa iki yuva için yönlendirme kurallarını değiştirerek iki yuvayı değiştirin. Bu adımdan sonra, hedef yuva (örneğin, üretim yuvası), kaynak yuvada daha önce çarpımış olan uygulamaya sahiptir.

6. Artık kaynak yuvasının hedef yuvada daha önce takas öncesi uygulamasına sahip olduğuna göre, tüm ayarları uygulayıp örnekleri yeniden başlatarak aynı işlemi gerçekleştirin.

Değiştirme işleminin herhangi bir noktasında, takas edilen uygulamaları başlatma işleminin hepsi kaynak yuvada gerçekleşir. Kaynak yuva hazırlanmakta olduğu veya başarısız olmasına bakılmaksızın, hedef yuva çevrimiçi kalır. Bir hazırlama yuvasını üretim yuvası ile 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ştirmiş?

Yapılandırmayı başka bir dağıtım yuvasından kopyaladığınızda, kopyalanmış yapılandırma düzenlenebilir olur. Bazı yapılandırma öğeleri bir takas (yuvaya özgü değil) içindeki içeriği izler, ancak diğer yapılandırma öğeleri bir değiştirme sonrasında aynı yuvada kalır (yuvaya özgü). Aşağıdaki listeler, yuvaları takas yaparken değişen ayarları gösterir.

takas edilen Ayarlar:

• Çerçeve sürümü, 32/64 bit, Web Yuvaları gibi genel ayarlar
• Uygulama ayarları (bir yuvayı kontrol etmek için yapılandırılabilir)
• Bağlantı dizeleri (bir yuvayı kontrol etmek için yapılandırılabilir)
• İşleyici eşlemeleri
• Ortak sertifikalar
• WebJobs içeriği
• Karma bağlantılar *
• Hizmet uç noktaları *
• Azure Content Delivery Network *
• Yol eşlemeleri

Yıldız işareti (*) ile işaretlenen özellikler, takas edilmemiş olarak planlanmaktadır.

takas olmayan Ayarlar:

• Yayımlama uç noktaları
• Özel etki alanı adları
• Genel olmayan sertifikalar ve TLS/SSL ayarları
• Ölçek ayarları
• WebJobs 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
• son ek ile biten Ayarlar _EXTENSION_VERSION

Bir uygulama ayarını veya bağlantı dizesini belirli bir yuvaya (takas değil) eklemek üzere yapılandırmak için, Bu yuvanın yapılandırma sayfasına gidin. Bir ayar ekleyin veya düzenleyin ve ardından dağıtım yuvası ayarı' nı seçin. Bu onay kutusunun belirlenmesi, ayarın değiştirilebilir olmadığını App Service söyler.

İki yuva değiştirme

Dağıtım yuvalarını uygulamanızın dağıtım yuvaları sayfasında ve genel bakış sayfasında takas edebilirsiniz. Yuva takası hakkında teknik ayrıntılar için bkz. değiştirme sırasında ne olur.

Dağıtım yuvalarını değiştirmek için:

1. Uygulamanızın dağıtım yuvaları sayfasına gidin ve takas' ı seçin.

   

   Takas iletişim kutusu, seçilen kaynak ve hedef yuvalarda değiştirilecek ayarları gösterir.

2. İstenen kaynak ve hedef yuvaları seçin. Genellikle hedef, üretim yuvadır. Ayrıca, kaynak değişiklikleri ve hedef değişiklikler sekmelerini seçip yapılandırma değişikliklerinin beklendiğini doğrulayın. İşiniz bittiğinde, Değiştir' i seçerek yuvaları hemen takas edebilirsiniz.

   

   Değiştirme işleminin gerçekten gerçekleşmeden önce hedef yuvalarınızın yeni ayarlarla nasıl çalışacağını görmek için değiştirme' yi seçmeyin, ancak Önizleme ile değiştirme' deki yönergeleri izleyin.

3. İşiniz bittiğinde, Kapat' ı seçerek iletişim kutusunu kapatın.

Herhangi bir sorununuz varsa bkz. değişiklikleri giderme.

Önizleme ile değiştirme (çok aşamalı takas)

Hedef yuva olarak üretime geçiş yapmadan önce, uygulamanın takas edilen ayarlarla çalıştığını doğrulayın. Kaynak yuva Ayrıca, değiştirme tamamlanmadan önce, görev açısından kritik uygulamalar için istenen şekilde daha da çarpmış olur.

Önizleme ile bir değiştirme 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ştirmeyi tamamlamadan önce hazırlama yuvasındaki sonucu doğrulayabilirsiniz.

Değiştirmeyi iptal ederseniz, App Service yapılandırma öğelerini kaynak yuvaya yeniden uygular.

Önizleme ile değiştirmek için:

1. Takas dağıtım yuvalarında bulunan adımları izleyin ancak Önizleme ile değiştirme gerçekleştir' i seçin.

   

   İletişim kutusunda kaynak yuvadaki yapılandırmanın 1. aşamada nasıl değiştiği ve kaynak ve hedef yuvanın aşama 2 ' de nasıl değiştirileceği gösterilir.

2. Değiştirmeyi başlatmaya hazırsanız değiştirmeyi Başlat' ı seçin.

   1. aşama tamamlandığında, iletişim kutusunda bilgilendirilirsiniz. Kaynak yuvadaki değiştirme 'yi öğesine giderek önizleyin https://<app_name>-<source-slot-name>.azurewebsites.net .

3. Bekleyen değiştirme işlemini tamamlamaya hazırsanız değiştirme eyleminde değiştirmeyi Tamam ' ı seçin ve değiştirmeyi Tamam' ı seçin.

   Bekleyen bir değişikliği iptal etmek için yerine değiştirmeyi Iptal et ' i seçin.

4. İşiniz bittiğinde, Kapat' ı seçerek iletişim kutusunu kapatın.

Herhangi bir sorununuz varsa bkz. değişiklikleri giderme.

Çok aşamalı bir değiştirme işlemini otomatikleştirmek için bkz. PowerShell Ile otomatikleştirin.

Değiştirme geri alma

Bir yuva takası sonrasında hedef yuvada (örneğin, üretim yuvası) herhangi bir hata oluşursa, aynı iki yuvayı hemen değiştirerek Yuvaları ön değiştirme durumlarına geri yükleyin.

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

otomatik takas, uygulamanızı sıfır soğuk başlar ve uygulamanın müşterileri için sıfır kapalı kalma süresiyle sürekli olarak dağıtmak istediğiniz Azure DevOps senaryoları kolaylaştırır. Otomatik takas bir yuvadan üretime etkin hale geldiğinde, kod değişikliklerinizi bu yuvaya her gönderdiğinizde, App Service, kaynak yuvada bir süre geçtikten sonra uygulamayı otomatik olarak üretime dönüştürür .

Otomatik değiştirmeyi yapılandırmak için:

1. Uygulamanızın kaynak sayfasına gidin. Dağıtım yuvaları > <desired source slot> > yapılandırma > genel ayarları' nı seçin.

2. Otomatik takas etkin için Açık seçeneğini belirleyin. Ardından, Otomatik takas dağıtım yuvası için istenen hedef yuvayı seçin ve komut çubuğunda Kaydet ' i seçin.

   

3. Kaynak yuvaya bir kod gönderimi yürütün. Otomatik değiştirme kısa bir süre sonra gerçekleşir ve güncelleştirme, hedef yuvaınızın URL 'sine yansıtılır.

Herhangi bir sorununuz varsa bkz. değişiklikleri giderme.

Özel ısınma belirtin

Bazı uygulamalar, değiştirme işleminden önce özel ısınma eylemleri gerektirebilir. applicationInitializationweb.config yapılandırma öğesi özel başlatma eylemleri belirtmenize olanak tanır. Takas işlemi , hedef yuva ile takas etmeden önce bu özel ısınma işleminin bitmesini bekler. Örnek bir web.config parçası aşağıda verilmiştir.

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

Öğesini özelleştirme hakkında daha fazla bilgi için applicationInitialization bkz. en yaygın dağıtım yuvası değiştirme hataları ve nasıl düzeltileceğini öğrenin.

Ayrıca, aşağıdaki uygulama ayarlarındanbiri veya her ikisiyle de ısınma davranışını özelleştirebilirsiniz:

• WEBSITE_SWAP_WARMUP_PING_PATH: Sitenizi ısınma için HTTP üzerinden ping yapılacak yol. 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ğerdir.
• WEBSITE_SWAP_WARMUP_PING_STATUSES: Isınma işlemi için geçerli HTTP yanıt kodları. Bu uygulama ayarını, virgülle ayrılmış bir HTTP kodları listesi ile ekleyin. Örnek olarak bir örnektir 200,202 . Döndürülen durum kodu listede yoksa, ısınma ve takas işlemleri durdurulur. Varsayılan olarak, tüm yanıt kodları geçerlidir.
• WEBSITE_WARMUP_PATH: Site her yeniden başlatıldığında (yalnızca yuva takas sırasında değil) ping yapılacak şekilde, sitedeki göreli bir yol. Örnek değerler /statuscheck , veya kök yolu içerir / .

Herhangi bir sorununuz varsa bkz. değişiklikleri giderme.

Değiştirme izleme

Değiştirme işleminin tamamlanmasını uzun sürerse, etkinlik günlüğündekideğiştirme işlemi hakkında bilgi edinebilirsiniz.

Portalın kaynak sayfasında, sol bölmede etkinlik günlüğü' nü seçin.

Günlük sorgusunda bir değiştirme işlemi görüntülenir Swap Web App Slots . Bu öğeyi genişletebilir ve ayrıntılarını görmek için alt perations veya hatalardan birini seçebilirsiniz.

Trafiği yönlendirme

Varsayılan olarak, uygulamanın üretim URL 'sine () yönelik tüm istemci istekleri http://<app_name>.azurewebsites.net Ü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 bildirimlerine ihtiyacınız varsa, ancak bunu üretime serbest bırakmaya hazırsanız faydalıdır.

Üretim trafiğini otomatik olarak yönlendir

Üretim trafiğini otomatik olarak yönlendirmek için:

1. Uygulamanızın kaynak sayfasına gidin ve dağıtım yuvaları' nı seçin.

2. Yönlendirmek istediğiniz yuvanın trafik% sütununda, yönlendirmek istediğiniz toplam trafik miktarını göstermek için bir yüzde (0 ile 100 arasında) belirtin. Kaydet’i seçin.

   

Ayar kaydedildikten sonra, belirtilen istemci yüzdesi, bir üretim dışı yuvaya rastgele yönlendirilir.

İstemci belirli bir yuvaya otomatik olarak yönlendirildikten sonra, o istemci oturumunun ömrü için bu yuvaya "sabitlenmiş" olur. İstemci tarayıcısında, x-ms-routing-name http başlıklarınızın tanımlama bilgisine bakarak oturumunuzun hangi yuvaya sabitlendiği hakkında bilgi alabilirsiniz. "Hazırlama" yuvasına yönlendirilen bir istek tanımlama bilgisine sahiptir x-ms-routing-name=staging . Üretim yuvasına yönlendirilen bir istek tanımlama bilgisine sahiptir x-ms-routing-name=self .

Üretim trafiğini el ile yönlendirin

Otomatik Trafik yönlendirmeye ek olarak, App Service istekleri belirli bir yuvaya yönlendirebilir. Bu, kullanıcılarınızın beta uygulamanızı kabul edebilir veya devre dışı bırakmak istediğinizde faydalıdır. Üretim trafiğini el ile yönlendirmek için x-ms-routing-name sorgu parametresini kullanırsınız.

Kullanıcıların beta uygulamanızı geri almasına izin vermek için, örneğ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 tüm istekler, x-ms-routing-name=self oturumu üretim yuvasına sabiteden tanımlama bilgisine sahiptir.

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

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

Varsayılan olarak, yeni yuvalara gri olarak gösterilen bir yönlendirme kuralı verilir 0% . Bu değeri açık olarak 0% (siyah metinde gösterildiği gibi) ayarlarsanız, kullanıcılarınız hazırlama yuvasına sorgu parametresini kullanarak el ile erişebilir x-ms-routing-name . Ancak, yönlendirme yüzdesi 0 olarak ayarlandığı için bunlar otomatik olarak yuvaya yönlendirilmez. Bu, iç ekiplerin yuvalarda değişiklikleri test kurmasına izin verirken, hazırlama yuvalarınızı genel olarak "gizleyebileceğiniz", gelişmiş bir senaryodur.

Yuva silme

Uygulamanızı arayın ve seçin. Dağıtım yuvalarına > <slot to delete> > Genel Bakış ' ı seçin. Uygulama türü, bir dağıtım yuvası görüntülemekte olduğunuzu hatırlatmak için App Service (yuva) olarak gösterilir. Komut çubuğunda Sil ' i seçin.

PowerShell ile otomatikleştirme

Azure PowerShell, Azure App Service dağıtım yuvalarını yönetme desteği de dahil olmak üzere Azure 'u Windows PowerShell aracılığıyla yönetmek için cmdlet 'leri sağlayan bir modüldür.

Azure PowerShell yükleme ve yapılandırma hakkında bilgi edinmek ve Azure aboneliğinizle Azure PowerShell kimlik doğrulaması yapmak için bkz. Microsoft Azure PowerShell yükleme ve yapılandırma.

Web uygulaması oluşturma

New-AzWebApp -ResourceGroupName [resource group name] -Name [app name] -Location [location] -AppServicePlan [app service plan name]

Yuva oluşturma

New-AzWebAppSlot -ResourceGroupName [resource group name] -Name [app name] -Slot [deployment slot name] -AppServicePlan [app service plan name]

Önizleme ile bir değiştirme başlatın (çok aşamalı takas) ve hedef yuva yapılandırmasını kaynak yuvaya uygulayın

$ParametersObject = @{targetSlot  = "[slot name – e.g. "production"]"}
Invoke-AzResourceAction -ResourceGroupName [resource group name] -ResourceType Microsoft.Web/sites/slots -ResourceName [app name]/[slot name] -Action applySlotConfig -Parameters $ParametersObject -ApiVersion 2015-07-01

Bekleyen bir değiştirmeyi iptal et (gözden geçireni değiştirme) ve kaynak yuva yapılandırmasını geri yükleme

Invoke-AzResourceAction -ResourceGroupName [resource group name] -ResourceType Microsoft.Web/sites/slots -ResourceName [app name]/[slot name] -Action resetSlotConfig -ApiVersion 2015-07-01

Dağıtım yuvalarını değiştirme

$ParametersObject = @{targetSlot  = "[slot name – e.g. "production"]"}
Invoke-AzResourceAction -ResourceGroupName [resource group name] -ResourceType Microsoft.Web/sites/slots -ResourceName [app name]/[slot name] -Action slotsswap -Parameters $ParametersObject -ApiVersion 2015-07-01

Etkinlik günlüğündeki değiştirme olaylarını izleme

Get-AzLog -ResourceGroup [resource group name] -StartTime 2018-03-07 -Caller SlotSwapJobProcessor  

Yuva silme

Remove-AzResource -ResourceGroupName [resource group name] -ResourceType Microsoft.Web/sites/slots –Name [app name]/[slot name] -ApiVersion 2015-07-01

Kaynak Yöneticisi şablonlarıyla otomatikleştirin

Azure Resource Manager şablonlar , Azure kaynaklarının dağıtımını ve yapılandırmasını otomatik hale getirmek için kullanılan BILDIRIM temelli JSON dosyalarıdır. Kaynak Yöneticisi şablonları kullanarak yuvaları takas etmek için, Microsoft. Web/Sites/yuvaları ve Microsoft. Web/Sites kaynaklarında iki özellik ayarlayacaksınız:

• buildVersion: Bu, yuvada dağıtılan uygulamanın geçerli sürümünü temsil eden bir String özelliğidir. Örneğin: "v1", "1.0.0.1" veya "2019-09-20T11:53:25.2887393-07:00".
• targetBuildVersion: Bu, yuvanın ne olması gerektiğini belirten bir String özelliğidir buildVersion . TargetBuildVersion geçerli değere eşit değilse buildVersion , bu, belirtilen yuvayı bularak değiştirme işlemini tetikler buildVersion .

Örnek Kaynak Yöneticisi şablonu

Aşağıdaki Kaynak Yöneticisi şablonu, buildVersion hazırlama yuvasının öğesini güncelleştirecek ve targetBuildVersion Üretim yuvasında ayarlayacaktır. Bu, iki yuvaları takas eder. Şablon zaten "hazırlama" adlı bir tepsisle oluşturulmuş bir WebApp olduğunu varsayar.

{
    "$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 Kaynak Yöneticisi şablonu, tekrar tekrar yürütülebileceğini ve yuvaların aynı durumunun ortaya çıkarıdempotent anlamına gelir. İlk yürütmeden sonra, targetBuildVersion geçerli olan ile eşleşir buildVersion , bu nedenle bir değiştirme tetiklenmeyecektir.

CLı ile otomatikleştirin

Dağıtım yuvaları için Azure CLI komutları için, bkz. az WebApp Deployment slot.

Takas sorunlarını giderme

Yuva değiştirmesırasında herhangi bir hata oluşursa, D:\home\LogFiles\eventlog.xml oturum açar. Ayrıca uygulamaya özgü hata günlüğüne kaydedilir.

Bazı yaygın değiştirme hataları aşağıda verilmiştir:

• Uygulama köküne yönelik bir HTTP isteği zaman aşımına uğradı. Değiştirme işlemi her HTTP isteği için 90 saniye bekler ve 5 kez yeniden dener. Tüm denemeler zaman aşımına uğradıysanız 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ış.

• Özel ısınmasırasında http istekleri dahili olarak yapılır (dış URL 'ye geçmeden). Web.config IÇINDEKI belirli URL yeniden yazma kurallarıyla başarısız olabilir. Örneğin, etki alanı adlarını yeniden yönlendirme veya HTTPS zorlama kuralları, uygulama koduna ulaşmasını önler. 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 engelliyor olabilir. 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ştirildikten sonra, uygulama beklenmeyen yeniden başlatmalar ile karşılaşabilir. Bunun nedeni, bir değiştirme işleminden sonra, ana bilgisayar adı bağlama yapılandırması eşitlemeden sonra yeniden başlatmalara neden olmaz. Ancak, bazı temel depolama olayları (örneğin, depolama birimi yük devretme işlemleri), bu tutarsızlıkları algılayabilir ve tüm çalışan süreçlerini yeniden başlamaya zorlayabilir. Bu tür yeniden başlatma türlerini en aza indirmek için Tüm yuvalarda WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG=1 uygulama ayarını ayarlayın. ancak, bu uygulama ayarı Windows Communication Foundation (WCF) uygulamalarıyla çalışmaz.

Sonraki adımlar

Üretim dışı yuvalara erişimi engelleyin