Dayanıklı İşlevler için sıfır kapalı kalma süresi dağıtımı

Dayanıklı İşlevler güvenilir yürütme modeli, güncelleştirmeleri dağıtırken dikkate alınması gereken ek bir zorluk oluşturan düzenlemelerin belirleyici olmasını gerektirir. Bir dağıtım etkinlik işlevi imzalarında veya düzenleyici mantığında değişiklikler içerdiğinde, uygulama içi düzenleme örnekleri başarısız olur. Bu durum özellikle çalışma saatlerini veya günlerini temsil eden uzun süre çalışan düzenleme örnekleri için bir sorundur.

Bu hataların oluşmasını önlemek için iki seçeneğiniz vardır:

• Çalışan tüm düzenleme örnekleri tamamlanana kadar dağıtımınızı geciktirin.
• Çalışan tüm düzenleme örneklerinin işlevlerinizin mevcut sürümlerini kullandığından emin olun.

Aşağıdaki grafik, Dayanıklı İşlevler için sıfır kapalı kalma süresi dağıtımına ulaşmak için üç ana stratejiyi karşılaştırır:

Strateji	Kullanılması gereken durumlar	Avantajlar	Dezavantajlar
Sürüm Oluşturma	Sık sık hataya neden olan değişikliklerle karşılaşmayen uygulamalar.	Uygulanması basit.	Bellekte ve işlev sayısında artan işlev uygulaması boyutu. Kod yineleme.
Yuva ile durum denetimi	24 saatten uzun süren veya sık sık çakışan düzenleme işlemlerine sahip olmayan bir sistem.	Basit kod tabanı. Ek işlev uygulaması yönetimi gerektirmez.	Ek depolama hesabı veya görev hub'ı yönetimi gerektirir. Hiçbir düzenlemenin çalışmadığında belirli süreler gerektirir.
Uygulama yönlendirme	Düzenlemelerin çalışmadığı dönemlere sahip olmayan bir sistem; örneğin, 24 saatten uzun süren düzenleme dönemleri veya sık sık çakışan düzenlemelerle.	Sürekli ç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ı üst limitini aşabilir. Varsayılan değer 100'dür.

Bu belgenin geri kalanında bu stratejiler daha ayrıntılı olarak açıklanmaktadır.

Not

Bu sıfır kapalı kalma süresi dağıtım stratejilerinin açıklamalarında, Dayanıklı İşlevler için varsayılan Azure Depolama sağlayıcısını kullandığınız varsayılır. Varsayılan Azure Depolama sağlayıcısı dışında bir depolama sağlayıcısı kullanıyorsanız kılavuz uygun olmayabilir. Çeşitli depolama sağlayıcısı seçenekleri ve bunların karşılaştırması hakkında daha fazla bilgi için Dayanıklı İşlevler depolama sağlayıcıları belgelerine bakın.

Sürüm Oluşturma

İşlevlerinizin yeni sürümlerini tanımlayın ve eski sürümleri işlev uygulamanızda bırakın. Diyagramda görebileceğiniz gibi, işlevin sürümü adının bir parçası olur. İşlevlerin önceki sürümleri korunduğu için, uygulama içi düzenleme örnekleri bunlara başvurmaya devam edebilir. Bu arada, 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.

Bu stratejide, her işlev kopyalanmalıdır ve diğer işlevlere başvuruları güncelleştirilmelidir. Bir betik yazarak daha kolay hale getirebilirsiniz. Aşağıda geçiş betiği içeren örnek bir proje verilmiş.

Not

Bu strateji, dağıtım sırasında kapalı kalma süresini önlemek için dağıtım yuvalarını kullanır. Yeni dağıtım yuvaları oluşturma ve kullanma hakkında daha ayrıntılı bilgi için bkz. dağıtım yuvalarını Azure İşlevleri.

Yuva 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. Düzenlemeleriniz uzun süre çalışmadığında ve düzenleme yürütmeleriniz sık sık çakışmadığında en iyi yaklaşım budur.

İş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ı dizesi olarak ayarlayın. Bu depolama hesabı bağlantı dizesi, işlevlerin erişim anahtarlarını güvenli bir şekilde depolamak için Azure İşlevleri çalışma zamanı tarafından kullanılır.

3. Her yuva için , gibi DurableManagementStorageyeni bir uygulama ayarı oluşturun. 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.

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 azureStorageConnectionStringName (Dayanıklı 1.x) belirtin connectionStringName .

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

host.json örnekleri

Aşağıdaki JSON parçaları , host.json dosyasındaki bağlantı dizesi ayarına örneklerdir.

İşlevler 2.0

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

İşlevler 1.x

{
  "durableTask": {
    "azureStorageConnectionStringName": "DurableManagementStorage"
  }
}

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

CI/CD işlem hattınızı yalnızca işlev uygulamanızda bekleyen veya çalışan düzenleme örneği olmadığında dağıtılacak şekilde yapılandırın. Azure Pipelines'ı kullanırken, aşağıdaki örnekte olduğu gibi bu koşulları denetleyebilen bir işlev oluşturabilirsiniz:

[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 düzenlemenin çalışmamasını 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.

Şimdi 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ştirilir, bu nedenle sürüm 2 uygulaması depolama hesabı A'ya 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. Dayanıklı İşlevler görev hub'ları.

Uygulama yönlendirme

Bu strateji en karmaşık stratejidir. Ancak, düzenleme çalıştırma arasında zaman olmayan işlev uygulamaları için kullanılabilir.

Bu strateji için, Dayanıklı İşlevler önünde bir uygulama yönlendiricisi oluşturmanız gerekir. Bu yönlendirici Dayanıklı İşlevler ile uygulanabilir. Yönlendiricinin sorumluluğu:

• İşlev uygulamasını dağıtın.
• Dayanıklı İşlevler sürümünü yönetin.
• Düzenleme isteklerini işlev uygulamalarına yönlendirin.

İ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. Düzenleme isteğini yeni uygulamaya iletir.

Yönlendirici, uygulamanızın kodunun hangi sürümünün Azure'da 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. Düzeltme eki sürümünü yoksayar.

Hataya neden olan bir değişiklik olmadan uygulamanızın yeni bir sürümünü dağıttığınızda düzeltme eki sürümünü artırabilirsiniz. Yönlendirici mevcut işlev uygulamanıza dağıtılır ve kodun aynı işlev uygulamasına yönlendirilen eski ve yeni sürümleri için istekler gönderir.

Uygulamanızın yeni bir sürümünü hataya neden olan bir değişiklikle dağıttığınızda, birincil veya ikincil sürümü artırabilirsiniz. Ardından uygulama yönlendiricisi Azure'da 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 düzenleme çalıştırmaya devam edilir, ancak 1.1.0 sürümüne yönelik istekler yeni işlev 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.

Mağaza ayarlarını izleme

Her işlev uygulaması, muhtemelen ayrı depolama hesaplarında ayrı zamanlama kuyrukları kullanmalıdır. Uygulamanızın tüm sürümlerindeki tüm düzenleme örneklerini sorgulamak isterseniz işlev uygulamalarınızda örnek ve geçmiş tablolarını paylaşabilirsiniz. Host.json ayarlar dosyasındaki trackingStoreConnectionStringName ve trackingStoreNamePrefix ayarlarını, hepsinin aynı değerleri kullanması için yapılandırarak tabloları paylaşabilirsiniz.

Daha fazla bilgi için bkz. Azure'da Dayanıklı İşlevler örneklerini yönetme.

Sonraki adımlar

Sürüm oluşturma Dayanıklı İşlevler