Dayanıklı İşlevler için kesintisiz dağıtım

Dayanıklı İşlevler güvenilir yürütme modeli düzenlemelerin belirleyici olmasını gerektirir ve bu da güncelleştirmeleri dağıttığınızda bir zorluk oluşturur. Dağıtım, değiştirilmiş etkinlik işlevi imzaları veya değiştirilmiş düzenleyici mantığı gibi hataya neden olan değişiklikler içerdiğinde, uçuş içi düzenleme örnekleri başarısız olur. Bu durum, saatlerce veya günlerce süren çalışmayı temsil eden uzun süreli orkestrasyonlarda özellikle bir sorundur.

Note

Bu makaledeki stratejilerde, Dayanıklı İşlevler için varsayılan Azure Depolama sağlayıcısını kullandığınız varsayılır. Farklı bir depolama sağlayıcısı kullanıyorsanız kılavuz geçerli olmayabilir. Orkestrasyon sürümleme stratejisi istisnadır; herhangi bir depolama arka uçla çalışır. Depolama sağlayıcısı seçenekleri hakkında daha fazla bilgi için bkz. Dayanıklı İşlevler depolama sağlayıcıları.

Aşağıdaki tablo, kesintisiz dağıtım gerçekleştirme için dört stratejiyi karşılaştırır. İş yükünüzle en iyi eşleşen stratejiyi seçin:

Strateji	Ne zaman kullanılır?	Pros	Cons
Orchestrasyon sürümleme (önerilir)	Birden çok düzenleme sürümünün eşzamanlı olarak çalışmasını gerektiren bozucu değişiklikler içeren uygulamalar.	Bozulmaya neden olan değişikliklerle sıfır kapalı kalma süresine sahip dağıtımları etkinleştirir. En az yapılandırma gerektiren yerleşik özellik. Herhangi bir depolama arka planı teknolojisiyle çalışır.	Sürüm uyumluluğu için dikkatli düzenleyici kod değişiklikleri gerektirir.
Ad tabanlı sürüm oluşturma		Uygulanması basit.	Bellekte ve işlev sayısında artan işlev uygulaması boyutu. Kod yineleme.
Slot ile durum kontrolü	Kısa süreli düzenlemelere (24 saatten az) ve yürütmeler arasında tahmin edilebilir boşluklara sahip sistemler.	Basit kod tabanı. Ek işlev uygulaması yönetimi gerektirmez.	Ek depolama hesabı veya görev hub'ı yönetimi gerektirir. Hiçbir orkestrasyonun çalışmadığı belli zaman dilimleri gerektirir.
Uygulama yönlendirme	Sürekli olarak çalışan orkestrasyonlara (24 saatten uzun süre) veya boşta zaman aralığı bulunmadan sık sık çakışan yürütmelere sahip sistemler.	Sürekli olarak çalışan ve hataya neden olan değişiklikler içeren düzenlemelerle sistemlerin yeni sürümlerini işler.	Akıllı bir uygulama yönlendiricisi gerektirir. Aboneliğinizin izin verdiği işlev uygulaması sayısını en üst değere çıkarabilirsiniz (varsayılan değer 100'dür).

Orkestrasyon versiyonlama

Orkestrasyon sürümleme özelliği, uyumsuz değişikliklerle kesintisiz dağıtımlar için önerilen stratejidir. Farklı düzenleme sürümlerinin çakışma olmadan eşzamanlı olarak birlikte var olmasını ve yürütülmesini sağlar.

Orkestrasyon sürümlendirme ile:

• Her orkestrasyon örneği, oluşturulduğunda kalıcı olarak kendisiyle ilişkilendirilmiş bir sürüm alır.
• Daha yeni düzenleyici sürümleri çalıştıran çalışanlar eski sürüm örneklerini yürütmeye devam edebilir.
• Eski düzenleme sürümlerini çalıştıran çalışanlar daha yeni sürüm örnekleri yürütemez .
• Orchestrator işlevleri, versiyonlarını ve dal yürütmelerini buna göre inceleyebilir.

Bu yaklaşım, uygulamanızın farklı sürümlerini çalıştıran çalışanların birlikte güvenle var olabileceği sıralı yükseltmeleri kolaylaştırır. Bu makaledeki diğer stratejilerden farklı olarak, düzenleme sürümü oluşturma arka uç bağımsızdır ve herhangi bir depolama sağlayıcısıyla çalışır.

Tam uygulama adımları — sürüm oluşturmanın yapılandırılması, düzenleyici kodunda sürüm dallanmasının işlenmesi ve sıralı yükseltmelerin yönetilmesi dahil — için bkz. Orkestra sürüm oluşturma.

Kalan stratejiler, orkestrasyon sürümlemenin uygun olmadığı senaryolar için birer alternatiftir.

Ad tabanlı sürüm oluşturma

Bu stratejiyle, işlevlerinizin yeni sürümlerini aynı işlev uygulamasındaki eski sürümlerin yanı sıra oluşturursunuz. Her işlevin sürümü adının bir parçası olur (örneğin, , MyOrchestrator_v1MyOrchestrator_v2). Önceki sürümler korunduğu için, uçuş içi düzenleme örnekleri bunlara başvurmaya devam edebilir. Yeni düzenleme örneklerine yönelik istekler, düzenleme istemci işlevinizin bir uygulama ayarından başvurabileceği en son sürümü çağırır. Aşağıdaki diyagramda bu yaklaşım gösterilmektedir.

Bu stratejide, her işlev kopyalanmalıdır ve diğer işlevlere başvuruları güncelleştirilmelidir. Bir komut dosyası yazarak bunu kolaylaştırabilirsiniz. Aşağıda bir geçiş betiği içeren örnek bir proje verilmiştir.

Note

Bu strateji, dağıtım sırasında çalışma kesintisini önlemek için dağıtım yuvalarından yararlanır. Yeni dağıtım yuvaları oluşturma ve kullanma hakkında daha ayrıntılı bilgi için bkz. Azure İşlevleri dağıtım yuvaları.

Slot ile durum denetimi

İşlev uygulamanızın geçerli sürümü üretim yuvanızda çalışırken işlev uygulamanızın yeni sürümünü hazırlama yuvanıza dağıtın. Üretim ve hazırlama yuvalarınızı değiştirmeden önce çalışan düzenleme örnekleri olup olmadığını denetleyin. Tüm düzenleme örnekleri tamamlandıktan sonra değiştirme işlemini gerçekleştirebilirsiniz. Bu strateji, hiçbir düzenleme örneğinin uçuşta olmadığı öngörülebilir dönemleriniz olduğunda çalışır. Orkestrasyonlarınız uzun süreli çalışmadığında ve orkestrasyon yürütmeleriniz sık sık çakışmadığında bu en iyi yaklaşımdır.

İşlev uygulaması yapılandırması

Bu senaryoyu ayarlamak için aşağıdaki yordamı kullanın.

1. Hazırlama ve üretim için işlev uygulamanıza dağıtım yuvaları ekleyin.

2. Her yuva için, AzureWebJobsStorage uygulama ayarını, paylaşılan depolama hesabının bağlantısına ayarlayın. Bu depolama hesabı bağlantısı, Azure İşlevleri çalışma zamanı tarafından functions erişim anahtarlarını güvenli bir şekilde depolamak için kullanılır. En yüksek güvenlik düzeyi için depolama hesabınızla yönetilen kimlik bağlantısı kullanmanız gerekir.

3. Her slot için yeni bir uygulama ayarı oluşturun, örneğin DurableManagementStorage. Değerini farklı depolama hesaplarının bağlantı dizesi olarak ayarlayın. Bu depolama hesapları, güvenilir yürütme için Dayanıklı İşlevler uzantısı tarafından kullanılır. Her yuva için ayrı bir depolama hesabı kullanın. Bu ayarı dağıtım yuvası ayarı olarak işaretlemeyin. Yönetilen kimlik tabanlı bağlantılar da en güvenli bağlantılardır.

4. İşlev uygulamanızın host.json dosyasının durableTask bölümünde, 3. adımda oluşturduğunuz uygulama ayarının adı olarak (Dayanıklı 2.x) veya connectionStringName (Dayanıklı 1.x) belirtin azureStorageConnectionStringName .

Aşağıdaki diyagramda dağıtım yuvalarının ve depolama hesaplarının açıklanmış yapılandırması gösterilmektedir. Bu olası dağıtım öncesi senaryoda, bir işlev uygulamasının 2. sürümü üretim yuvasında, sürüm 1 ise hazırlama yuvasında kalır.

host.json örnek

Aşağıdaki JSON parçası, host.json dosyasındaki bağlantı dizesi ayarını gösterir.

{
  "version": 2.0,
  "extensions": {
    "durableTask": {
      "hubName": "MyTaskHub",
      "storageProvider": {
        "connectionStringName": "DurableManagementStorage"
      }
    }
  }
}

Note

Eski İşlevler 1.x uygulamaları için azureStorageConnectionStringName özelliğini doğrudan durableTask bölümünde, storageProvider.connectionStringName yerine kullanın.

CI/CD işlem hattı yapılandırması

CI/CD işlem hattınızı yalnızca fonksiyon uygulamanızın bekleyen veya çalışan orkestrasyon örnekleri olmadığında dağıtım yapacak şekilde yapılandırın. Azure Pipelines kullanırken, aşağıdaki C# örneğinde olduğu gibi bu koşulları denetleyebilen bir işlev oluşturabilirsiniz. Aynı desen diğer diller için de geçerlidir; Pending veya Running durumunda olan düzenleme örneklerini sorgulayın ve bunların var olup olmadığını belirleyin.

[FunctionName("StatusCheck")]
public static async Task<IActionResult> StatusCheck(
    [HttpTrigger(AuthorizationLevel.Function, "get", "post")] HttpRequestMessage req,
    [DurableClient] IDurableOrchestrationClient client,
    ILogger log)
{
    var runtimeStatus = new List<OrchestrationRuntimeStatus>();

    runtimeStatus.Add(OrchestrationRuntimeStatus.Pending);
    runtimeStatus.Add(OrchestrationRuntimeStatus.Running);

    var result = await client.ListInstancesAsync(new OrchestrationStatusQueryCondition() { RuntimeStatus = runtimeStatus }, CancellationToken.None);
    return (ActionResult)new OkObjectResult(new { HasRunning = result.DurableOrchestrationState.Any() });
}

Ardından, hazırlama geçidini hiç bir orkestrasyon çalışmıyor olana kadar bekleyecek şekilde yapılandırın. Daha fazla bilgi için bkz. Geçitleri kullanarak dağıtım denetimini serbest bırakma

Azure Pipelines dağıtımınız başlamadan önce işlev uygulamanızın düzenleme örneklerini çalıştırmasını denetler.

Artık işlev uygulamanızın yeni sürümü hazırlama yuvasına dağıtılmalıdır.

Son olarak yuvaları değiştirin.

Dağıtım yuvası ayarları olarak işaretlenmeyen uygulama ayarları da değiştirildiğinden, sürüm 2 uygulaması A depolama hesabına başvurusunu korur. Düzenleme durumu depolama hesabında izlendiğinden, sürüm 2 uygulamasında çalışan tüm düzenleme işlemleri kesinti olmadan yeni yuvada çalışmaya devam eder.

Her iki yuva için de aynı depolama hesabını kullanmak için görev hub'larınızın adlarını değiştirebilirsiniz. Bu durumda yuvalarınızın durumunu ve uygulamanızın HubName ayarlarını yönetmeniz gerekir. Daha fazla bilgi edinmek için bkz. Task hubs in Dayanıklı İşlevler.

Başvuru rotası

Bu strateji en karmaşık stratejidir, ancak yuva değiştirme işlemleri için boşta penceresi olmayan sürekli çalışan düzenlemelere sahip sistemler için tek seçenektir.

Bu strateji için, Dayanıklı İşlevler'in önünde bir uygulama yönlendiricisi oluşturursunuz — örneğin, HTTP tetikleyicileri içeren bir Azure İşlevi veya sürüm üst bilgilerine göre yönlendiren bir API Yönetimi örneği. Yönlendirici aşağıdakiler için sorumludur:

• İşlev uygulaması dağıtılıyor.
• Uygulamanın hangi sürümünün etkin olduğunu yönetme.
• Orkestrasyon isteklerini sürüme göre doğru işlev uygulamasına yönlendirme.

İlk kez bir düzenleme isteği alındığında yönlendirici aşağıdaki görevleri yapar:

1. Azure'da yeni bir işlev uygulaması oluşturur.
2. İşlev uygulamanızın kodunu Azure'daki yeni işlev uygulamasına dağıtır.
3. Orkestrasyon isteğini yeni uygulamaya iletir.

Yönlendirici, uygulamanızın kodunun hangi sürümünün Azure hangi işlev uygulamasına dağıtıldığı durumunu yönetir.

Yönlendirici, dağıtım ve düzenleme isteklerini, istekle gönderilen sürüme göre uygun işlev uygulamasına yönlendirir. Yama sürümünü yoksayar.

Uygulamanızın uyumsuz değişiklik içermeyen yeni bir sürümünü dağıttığınızda yama sürümünü artırabilirsiniz. Yönlendirici, mevcut işlev uygulamanıza entegre edilir ve kodun eski ve yeni sürümlerine yönelik istekleri, aynı işlev uygulamasına yönlendirir.

Uygulamanızın yeni bir sürümünü uyumsuzluk oluşturan bir değişiklikle dağıttığınızda, ana veya küçük sürümü artırabilirsiniz. Ardından uygulama yönlendiricisi Azure'de yeni bir işlev uygulaması oluşturur, uygulamaya dağıtır ve uygulamanızın yeni sürümüne yönelik istekleri buna yönlendirir. Aşağıdaki diyagramda, uygulamanın 1.0.1 sürümünde orkestrasyon çalışmaya devam eder, ancak 1.1.0 sürümüne yönelik istekler yeni function uygulamasına yönlendirilir.

Yönlendirici, 1.0.1 sürümündeki düzenlemelerin durumunu izler ve tüm düzenleme işlemleri tamamlandıktan sonra uygulamaları kaldırır.

İzleme deposu ayarları

Her işlev uygulaması, büyük olasılıkla ayrı depolama hesaplarında ayrı zamanlama kuyrukları kullanmalıdır. Uygulamanızın tüm sürümlerindeki tüm düzenleme örneklerini sorgulamak istiyorsanız, işlev uygulamalarınızda örnek ve geçmiş tablolarını paylaşabilirsiniz. trackingStoreConnectionStringName ve trackingStoreNamePrefix ayarlarını host.json ayarları dosyasında yapılandırarak tabloları paylaşabilirsiniz, böylece hepsi aynı değerleri kullanır.

Daha fazla bilgi için Azure'da Dayanıklı İşlevler'taki örnekleri yönetme konusuna bakın.

Sonraki Adımlar

Dayanıklı Fonksiyonların Versiyonlanması