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

  • Makale

Web uygulamanızı, Linux üzerinde web uygulamanızı, mobil arka ucu veya API uygulamanızı Azure Uygulaması Service'e dağıttığınızda, 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 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ğı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 sorunsuzdur ve 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, Standart katmanı yalnızca beş dağıtım yuvasını desteklediğinden ölçeği Standart katmana indiremezsiniz.

Ön koş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, yuva arama).

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.

  1. Azure portalında uygulamanızın yönetim sayfasına gidin.

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

    Dekont

    Uygulama henüz Standart, Premium veya Yalıtılmış katmanında değilse Yükselt'iseçin ve devam etmeden önce uygulamanızın Ölçek sekmesine gidin.

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

    A screenshot that shows how to configure a new deployment slot called 'staging' in the portal.

    Bir yapılandırmayı var olan herhangi bir yuvadan kopyalayabilirsiniz. Kopyalanabilen Ayarlar uygulama ayarları, bağlantı dizesi, dil çerçevesi sürümleri, web yuvaları, HTTP sürümü ve platform bitliği dahildir.

    Dekont

    Şu anda özel uç nokta yuvalar arasında kopyalanmıyor.

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

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

    A screenshot that shows how to open deployment slot's management page in the portal.

    Hazırlama yuvası, diğer App Service uygulamaları gibi bir yönetim sayfasına sahiptir. Yuvanın yapılandırmasını değiştirebilirsiniz. Dağıtım yuvasını görüntülediğiniz anımsatmak için, uygulama adı uygulama adı/<yuva-adı>> olarak <gösterilir ve uygulama türü App Service (Yuva)'dır. Yuvayı kaynak grubunuzda aynı ifadelerle ayrı bir uygulama olarak da görebilirsiniz.

  6. Yuvanın kaynak sayfasında uygulama URL'sini seçin. Dağıtım yuvasının kendi ana bilgisayar adı vardır ve aynı zamanda canlı bir uygulamadır. Dağıtım yuvasına genel erişimi sınırlamak için bkz. hizmet IP kısıtlamaları Azure Uygulaması.

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. Profil, içeriği yuvaya dağıtmak için Visual Studio tarafından içeri aktarılabilir.

Yuvanın URL'si biçimindedir http://sitename-slotname.azurewebsites.net. URL uzunluğunu gerekli DNS sınırları içinde tutmak için, 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 (genellikle bir hazırlama yuvasından üretim yuvasına), Hedef yuvanın kapalı kalma süresi yaşamadığından emin olmak için App Service aşağıdakileri yapar:

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

    Bu durumlardan herhangi biri, yeniden başlatmak için hedef yuvadaki tüm örnekleri tetikler. Önizleme ile değiştirme sırasında bu, ilk aşamanın sonunu işaretler. Değiştirme işlemi duraklatılır ve 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 uygulama köküne ("/") http isteğinde bulunarak 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.

Dekont

Eski üretim örneklerinizdeki örnekler (bu değiştirme işleminden sonra hazırlamaya değiştirilecek örnekler) değiştirme işleminin son adımında hızla geri dönüştürülür. Uygulamanızda uzun süre çalışan işlemler varsa, çalışanlar geri dönüşüme geçtiğinde bunlar terk edilecek. Bu durum işlev uygulamaları için de geçerlidir. Bu nedenle uygulama kodunuz hataya dayanıklı bir şekilde yazılmalıdır.

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, bir değiştirme işleminden (yuvaya özgü değil) içeriği izlerken, diğer yapılandırma öğeleri değiştirme işleminden sonra (yuvaya özgü) aynı yuvada kalır. Aşağıdaki listelerde yuvaları değiştirdiğinizde değişen ayarlar gösterilir.

Ayarlar değiştirilir:

  • Çerçeve sürümü, 32/64 bit, web yuvaları gibi genel ayarlar
  • Uygulama ayarları (yuvaya bağlı kalmak için yapılandırılabilir)
  • Bağlan ion dizeleri (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ştirilmemiş Ayarlar:

  • Yayımlama uç noktaları
  • Özel etki alanı adları
  • Genel olmayan 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
  • oluşturan AyarlarHizmet Bağlan veya

Dekont

Yukarıda belirtilen ayarların değiştirilebilir olmasını sağlamak için, uygulamanın her yuvasına uygulama ayarını WEBSITE_OVERRIDE_PRESERVE_DEFAULT_STICKY_SLOT_SETTINGS ekleyin ve değerini veya falseolarak 0 ayarlayın. Bu ayarların tümü değiştirilebilir veya hiç değildir. Yalnızca bazı ayarları değiştirilebilir yapamazsınız, diğerlerini değiştiremezsiniz. Yönetilen kimlikler hiçbir zaman değiştirilmez ve bu geçersiz kılma uygulaması ayarından etkilenmez.

Eşlenmemiş ayarlara uygulanan bazı uygulama ayarları da değiştirilmez. Örneğin, tanılama ayarları değiştirilmediğinden ve gibi WEBSITE_HTTPLOGGING_RETENTION_DAYSDIAGNOSTICS_AZUREBLOBRETENTIONDAYS ilgili uygulama ayarları yuva ayarları olarak gösterilmese bile değiştirilmez.

Bir uygulama ayarını yapılandırmak veya belirli bir yuvaya (değiştirilmeden) bağlı kalmak için bağlantı dizesi ilgili 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 seçilmesi App Service'e ayarın değiştirilemez olduğunu bildirir.

A screenshot that shows how to configure an app setting as a slot setting in the Azure portal.

İ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şimiyle ilgili teknik ayrıntılar için bkz . Değiştirme sırasında ne olur?

Önemli

Bir uygulamayı dağıtım yuvasından üretime geçirmeden önce, üretimin hedef yuvanız olduğundan ve kaynak yuvadaki tüm ayarların tam olarak üretimde olmasını istediğiniz şekilde yapılandırıldığından emin olun.

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

  1. Uygulamanızın Dağıtım yuvaları sayfasına gidin ve Değiştir'i seçin.

    A screenshot that shows how to initiate a swap operation in the portal.

    Değiştir iletişim kutusu, değiştirilecek seçili kaynak ve hedef yuvalardaki ayarları gösterir.

  2. İstediğiniz Kaynak ve Hedef yuvalarını seçin. Hedef genellikle üretim yuvasıdır. Ayrıca, Kaynak Değişiklikleri ve Hedef Değişiklikler sekmelerini seçin ve yapılandırma değişikliklerinin beklendiğini doğrulayın. İşiniz bittiğinde Değiştir'i seçerek yuvaları hemen değiştirebilirsiniz.

    A screenshot that shows how to configure and complete a swap in the portal.

    Değiştirme işlemi gerçekleşmeden önce hedef yuvanızın yeni ayarlarla nasıl çalışacağını görmek için Değiştir'i seçmeyin, ancak Önizleme ile değiştirme başlığındaki yönergeleri izleyin.

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

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.

Dekont

Yuvalardan birinde site kimlik doğrulaması etkinleştirildiğinde önizleme ile değiştirme kullanılamaz.

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

  1. Dağıtım yuvalarını değiştirme'deki adımları izleyin, ancak Önizleme ile değiştirme gerçekleştir'i seçin.

    A screenshot that shows how to configure a swap with preview in the portal.

    İletişim kutusu, kaynak yuvadaki yapılandırmanın 1. aşamada nasıl değiştiğini ve 2. aşamada kaynak ve hedef yuvanın nasıl değiştiğini gösterir.

  2. Değişimi başlatmaya hazır olduğunuzda Değişimi Başlat'ı seçin.

    1. aşama tamamlandığında, iletişim kutusunda size bildirilir. adresine giderek kaynak yuvadaki değişimin önizlemesini görüntüleme https://<app_name>-<source-slot-name>.azurewebsites.net.

  3. Bekleyen değişimi tamamlamaya hazır olduğunuzda Değiştirme eyleminde Değişimi Tamamla'yı seçin ve Değiştirme işlemini Tamamla'yı seçin.

    Bekleyen değişimi iptal etmek için bunun yerine Değişimi İptal Et'i ve ardından alttaki Değişimi İptal Et'i seçin.

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

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ı

Dekont

Otomatik değiştirme, Linux'taki web uygulamalarında ve Kapsayıcılar için Web App'te desteklenmez.

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.

Dekont

Üretim yuvası için otomatik değişimi yapılandırmadan önce, üretim dışı bir hedef yuvada otomatik değişimi test etmeyi göz önünde bulundurun.

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

  1. Uygulamanızın kaynak sayfasına gidin. Dağıtım yuvaları<>istenen kaynak yuvası>>Yapılandırma>Genel ayarları'nı seçin.

  2. Otomatik değiştirme etkin için Açık'ı seçin. Ardından Otomatik değiştirme dağıtım yuvası için istediğiniz hedef yuvayı seçin ve komut çubuğunda Kaydet'i seçin.

    A screenshot that shows how to configure auto swap into the production slot in the portal.

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

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ından biriyle veya her ikisiyle de ı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ğerdir.
  • 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. Örnek olarak verilmiştir 200,202 . 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. /

Dekont

<applicationInitialization> Yapılandırma öğesi her uygulama başlatma işleminin bir parçasıdır, ancak iki ısınma davranışı uygulaması ayarı yalnızca yuva değiştirme işlemleri için geçerlidir.

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.

Uygulamanızın portaldaki kaynak sayfasında, sol bölmede Etkinlik günlüğü'nü seçin.

Günlük sorgusunda olarak Swap Web App Slotsbir değiştirme işlemi görüntülenir. Ayrıntıları görmek için bunu genişletebilir ve alt işlemlerden veya hatalardan birini seçebilirsiniz.

Ü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.

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

  1. Uygulamanızın kaynak sayfasına gidin ve Dağıtım yuvaları'na tıklayın.

  2. Yönlendirmek istediğiniz yuvanın Traffic % 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.

    A screenshot that shows how to route a percentage of request traffic to a deployment slot, in the portal.

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

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, 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. Ancak yönlendirme yüzdesi 0 olarak ayarlandığından yuvaya otomatik olarak yönlendirilmeyeceklerdir. Bu, iç ekiplerin yuvadaki değişiklikleri test etmelerine izin verirken hazırlama yuvanızı genelden "gizleyebileceğiniz" gelişmiş bir senaryodur.

Yuva silme

Uygulamanızı arayın ve seçin. Genel Bakış'ı silmek>>için Dağıtım yuvaları yuvasını<>seçin. Uygulama türü, bir dağıtım yuvasını görüntülediğiniz anımsatmak için App Service (Yuva) olarak gösterilir. Yuvayı silmeden önce yuvayı durdurup yuvadaki trafiği sıfır olarak ayarladığınızdan emin olun. Komut çubuğunda Sil'i seçin.

A screenshot that shows how to delete a deployment slot in the portal.

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: Bu, yuvada dağıtılan uygulamanın geçerli sürümünü temsil eden bir dize özelliğidir. Örneğin: "v1", "1.0.0.1" veya "2019-09-20T11:53:25.2887393-07:00".
  • targetBuildVersion: Bu, yuvanın sahip buildVersion olması gerekenleri belirten bir dize özelliğidir. 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 yuva oluşturduğunuz varsayılı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 olur, yani tekrar tekrar yürütülebilir ve yuvaların aynı durumunu üretebilir. Ş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, D:\home\LogFiles\eventlog.xml dizininde günlüğe kaydedilir. 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ış.

  • Özel ısınma sırasında HTTP istekleri dahili olarak (dış URL'ye gitmeden) 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. Bunun nedeni, bir değiştirme işleminden sonra ana bilgisayar adı bağlama yapılandırmasının eşitlenmemiş olmasıdır ve bu da yeniden başlatmalara neden olmaz. Ancak, bazı temel alınan depolama olayları (depolama birimi yük devretmeleri gibi) 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ımlar

Üretim dışı yuvalara erişimi engelleme