İşlev uygulamanızı başka bir Azure bölgesine taşıma

Bu makalede, Azure İşlevleri barındırılan bir işlev uygulamasının başka bir Azure bölgesine nasıl taşındığı açıklanır.

Mevcut Azure kaynaklarınızı bir bölgeden diğerine taşımak istemenizin çeşitli nedenleri vardır. Şunu yapmak isteyebilirsiniz:

  • Yeni bir Azure bölgesinden yararlanın.
  • Yalnızca belirli bölgelerde kullanılabilen özellikleri veya hizmetleri dağıtın.
  • İç ilke ve idare gereksinimlerini karşılayın.
  • Şirket birleşmeleri ve alımlarıyla uyumlu hale getirme
  • Kapasite planlama gereksinimlerini karşılayın.

İşlev uygulamanızı barındıran Azure kaynakları bölgeye özgü olup bölgeler arasında taşınamaz. Bunun yerine, hedef bölgede mevcut işlev uygulaması kaynaklarınızın bir kopyasını oluşturmanız ve ardından işlev kodunuzu yeni uygulamaya yeniden dağıtmanız gerekir.

Aynı bölgede kaldıkları sürece bu kaynakları başka bir kaynak grubuna veya aboneliğe taşıyabilirsiniz. Daha fazla bilgi için bkz . App Service kaynaklarını yeni bir kaynak grubuna veya aboneliğe taşıma.

Önkoşullar

  • Hedef bölgenin Azure İşlevleri ve kaynaklarını taşımak istediğiniz ilgili hizmetleri desteklediğinden emin olun.
  • Yeni bölgede gerekli kaynakları oluşturma ayrıcalıklarına sahip olduğunuzdan emin olun.

Hazırlamak

Kaynak bölgede kullanılan ve şunları içerebilen tüm işlev uygulaması kaynaklarını belirleyin:

Uygulamanızı yeni bir bölgeye taşımaya hazırlanırken, mimarinin özel olarak dikkate alınması ve planlanması gereken birkaç bölümü vardır.

İşlev uygulamasının adı

İşlev uygulaması adları tüm Azure uygulamalarında genel olarak benzersiz olmalıdır. Bu, yeni işlev uygulamanızın, orijinal uygulamayla aynı ada ve URL'ye sahip olamayacağı anlamına gelir. Bu, özel DNS kullanırken bile geçerlidir, çünkü temel alınan <APP_NAME>.azurewebsites.net dns hala benzersiz olmalıdır. İşlev uygulamanızda HTTP uç noktalarına bağlanan tüm istemcileri güncelleştirmeniz gerekebilir. Bu istemcilerin istekte bulunurken yeni URL'yi kullanması gerekir.

Kaynak kodu

İdeal olarak, kaynak kodunuzu bir tür kod deposunda veya Linux kapsayıcısında çalışıyorsanız bir kapsayıcı deposunda tutarsınız. Sürekli dağıtım kullanıyorsanız depo veya kapsayıcı dağıtım bağlantısını yeni işlev uygulaması adresine değiştirmeyi planlayın. Herhangi bir nedenle kaynak kodunuz artık yoksa, o anda çalışan paketi özgün işlev uygulamasından indirebilirsiniz. Kaynak dosyalarınızı bir kod deposunda depolamanızı ve güncelleştirmeler için sürekli dağıtım kullanmanızı öneririz.

Varsayılan depolama hesabı

İşlev barındırıcı bir Azure Depolama hesabı gerektirir. Daha fazla bilgi için bkz . Depolama hesabı gereksinimleri. En iyi performans için işlev uygulamanızın aynı bölgede bir depolama hesabı kullanması gerekir. Yeni bölgenizde yeni bir depolama hesabıyla yeni bir uygulama oluşturduğunuzda, uygulamanız yeni bir işlev erişim anahtarları kümesi alır ve tüm tetikleyicilerin (zamanlayıcı tetikleyicileri gibi) durumu sıfırlanır.

Kalıcı yerel depolama

İşlev yürütmelerinin durum bilgisi olmayan olması amaçlanmıştır. Ancak yerel dosya sistemine veri yazmanızı engellemeyiz. Uygulamanız tarafından oluşturulan ve kullanılan verileri sanal sürücüde %HOME%\site depolamak mümkündür, ancak bu veriler durumla ilgili olmamalıdır. Senaryonuz işlev yürütmeleri arasında durumu korumanızı gerektiriyorsa bunun yerine Dayanıklı İşlevler kullanmayı göz önünde bulundurun.

Uygulamanız verileri uygulamanın paylaşılan depolama yolunda kalıcı hale getirirse, kaynak taşıma sırasında bu durumu nasıl yönetebileceğinizi planladığınızdan emin olun. Ayrılmış (App Service) planı uygulamaları için paylaşımın sitenin bir parçası olduğunu unutmayın. Tüketim ve Premium planları için paylaşım varsayılan olarak varsayılan depolama hesabında bir Azure Dosyalar paylaşımıdır. Linux üzerinde çalışan uygulamalar, kalıcı depolama için açıkça monte edilmiş bir paylaşımı kullanıyor olabilir.

Bağlı hizmetler

İşlevleriniz hizmet SDK'sı veya tetikleyiciler ve bağlamalar kullanarak Azure Hizmetleri'ne ve diğer kaynaklara bağlanabilir. Uygulama yeni bir bölgeye geçtiğinde bağlı tüm hizmetler olumsuz etkilenebilir. Gecikme süresi veya veri işleme kapasitesi sorun yaratıyorsa, bağlı olan herhangi bir hizmeti de yeni bölgeye taşımayı göz önünde bulundurun. Bu kaynakları bölgeler arasında taşımayı öğrenmek için ilgili hizmetlerin belgelerine bakın. Bağlı hizmetler içeren bir uygulamayı taşırken, taşıma sırasında bölgeler arası olağanüstü durum kurtarma ve iş sürekliliği stratejisini göz önünde bulundurmak isteyebilirsiniz.

Bağlı hizmetlerde yapılan değişiklikler, bu hizmetlere bağlanmak için kullanılan uygulama ayarlarınızda depolanan değerleri güncelleştirmenizi gerektirebilir.

Konfigürasyon

  • Azure portalından mevcut uygulama ayarlarının ve bağlantı dizesi anlık görüntüsünü yakalayabilirsiniz. Ayarlar> genişletin, Uygulama ayarları veya Bağlantılar dizeleri altında Gelişmiş düzenleme'yi seçin ve mevcut ayarları veya bağlantıları içeren JSON çıkışını kaydedin. Bu ayarları yeni bölgede yeniden oluşturmanız gerekir, ancak bağlı hizmetlerde sonraki bölge değişikliklerinin sonucu olarak değerlerin değişme olasılığı yüksektir.

  • Mevcut Key Vault başvuruları Bir Azure coğrafi sınırı boyunca dışarı aktarılamaz. Yeni bölgede gerekli referansları yeniden oluşturmanız gerekir.

  • Uygulama yapılandırmanız Azure Uygulaması Yapılandırması tarafından veya başka bir merkezi (aşağı akış) veritabanı bağımlılığından yönetilebilir. Değişiklik gerektirebilecek ortama ve bölgeye özgü ayarlar için Uygulama Yapılandırması depolarını veya benzer depoları gözden geçirin.

Özel alan adları

İşlev uygulamanız özel bir etki alanı kullanıyorsa, bunu hedef uygulamaya önceden bağlayın. Hedef uygulamada etki alanını doğrulayın ve etkinleştirin. Taşımadan sonra alan adını yeniden eşlemeniz gerekir.

Sanal ağlar

Azure İşlevleri, uygulamalarınızı sanal ağ kaynaklarıyla tümleştirmenize ve hatta bir sanal ağda çalıştırmanıza olanak tanır. Daha fazla bilgi için bkz. Azure İşlevleri ağ seçenekleri. Yeni bir bölgeye geçerken, uygulamanızı dağıtmadan önce gerekli tüm sanal ağ ve alt ağ kaynaklarını taşımanız veya yeniden oluşturmanız gerekir. Bu, özel uç noktaları ve hizmet uç noktalarını taşımayı veya yeniden oluşturmayı içerir.

Kimlik

  • Yeni hedef bölgede uygulamanızla birlikte sistem tarafından atanan yönetilen kimlikleri yeniden oluşturmanız gerekir. Genellikle, EasyAuth tarafından kullanılan, otomatik olarak oluşturulan bir Microsoft Entra ID uygulaması varsayılan olarak uygulama kaynağı adını kullanır.

  • Kullanıcı tarafından atanan yönetilen kimlikler de bölgeler arasında taşınamaz. Kullanıcı tarafından atanan yönetilen kimlikleri uygulamanızla aynı kaynak grubunda tutmak için bunları yeni bölgede yeniden oluşturmanız gerekir. Daha fazla bilgi için bkz . Azure kaynakları için yönetilen kimlikleri başka bir bölgeye taşıma.

  • Hizmetlerdeki yönetilen kimliklere, grup üyelikleri dahil olmak üzere, taşınan hizmetlerinizde değiştirdikleri özgün kimliklerle aynı izinleri verin.

Sertifikalar

App Service sertifika kaynakları yeni bir kaynak grubuna veya aboneliğe taşınabilir ancak bölgeler arasında taşınamayabilir. Dışarı aktarılabilir sertifikalar, uygulamaya veya yeni bölgedeki Key Vault'a da aktarılabilir. Bu dışarı aktarma ve içeri aktarma işlemi, bölgeler arasındaki taşıma işlemine eşdeğerdir.

Hizmetinizi yeniden konumlandırmayı planladığınızda dikkate alınması gereken farklı sertifika türleri vardır:

Sertifika türü Dışarı aktarılabilir Yorumlar
App Service tarafından yönetilen Hayı Bu sertifikaları yeni bölgede yeniden oluşturun.
Azure Key Vault Yönetimi Evet Bu sertifikalar Key Vault'tan dışarı aktarılabilir ve ardından yeni bölgedeki Key Vault'a aktarılabilir.
Özel anahtar (kendi kendine yönetilen) Evet Azure dışından aldığınız sertifikalar App Service'ten dışarı aktarılabilir ve ardından yeni uygulamaya veya yeni bölgedeki Key Vault'a aktarılabilir.
Ortak anahtar Hayı Uygulamanızın, diğer güvenli uç noktalara erişmek için kullanılan ve yalnızca ortak anahtar içeren, ancak gizli anahtar içermeyen sertifikaları olabilir. Gerekli ortak anahtar sertifika dosyalarını alın ve yeni bölgedeki uygulamaya aktarın.

Erişim anahtarları

İşlevler, işlev uygulamanızda HTTP uç noktalarına erişmeyi zorlaştırmak için erişim anahtarlarını kullanır. Bu anahtarlar varsayılan depolama hesabında şifrelenmiş olarak tutulur. Yeni bölgede yeni bir uygulama oluşturduğunuzda, yeni bir anahtar kümesi oluşturulur. Yeni bölgedeki yeni anahtarları kullanmak için erişim anahtarlarını kullanan mevcut istemcileri güncelleştirmeniz gerekir. Yeni anahtarları kullanmanız gerekirken, yeni uygulamada eski anahtarları yeniden oluşturmak mümkündür. Daha fazla bilgi için bkz. Azure İşlevleri'da erişim anahtarlarıyla çalışma.

Kesinti süresi

Minimum kapalı kalma süresi gerekliyse, olağanüstü durum kurtarma mimarisi uygulamak için önerilen şekilde işlev uygulamanızı her iki bölgede de çalıştırmayı göz önünde bulundurun. Uyguladığınız belirli mimari, işlev uygulamanızdaki tetikleyici türlerine bağlıdır. Daha fazla bilgi için bkz. Azure İşlevleri'de güvenilirlik.

Dayanıklı İşlevler

Dayanıklı İşlevler uzantısı, durum bilgisine sahip varlıklar kullanılarak işlev yürütmelerinizde durumun korunduğu orkestrasyonları tanımlamanıza olanak tanır. İdeal olarak, özellikle yeni bölgede yeni bir depolama hesabına geçmeyi planlıyorsanız, Dayanıklı İşlevler uygulamanızı geçirmeden önce çalıştırma düzenlemelerinin tamamlanmasına izin vermelisiniz. Dayanıklı İşlevler uygulamalarınızı geçirirken bu olağanüstü durum kurtarma ve coğrafi dağıtım stratejilerinden birini kullanmayı göz önünde bulundurun.

Taşımak

İşlev uygulamanızı yeni bir bölgede yeniden oluşturmak için önce App Service planının, işlev uygulaması örneğinin ve sanal ağlar, kimlikler ve yuvalar gibi ilgili kaynakların Azure altyapısını yeniden oluşturmanız gerekir. Ayrıca yeniden bağlanmanız veya yeni bölgede uygulamanın gerektirdiği Azure kaynaklarını yeniden oluşturmanız gerekir. Bu kaynaklar varsayılan Azure Depolama hesabını ve Application Insights örneğini içerebilir.

Ardından gerçek uygulama kaynak kodunu veya kapsayıcısını paketleyebilir ve yeni bölgede çalışan işlev uygulamasına dağıtabilirsiniz.

Azure altyapınızı yeniden oluşturma

Azure'da hedef bölgede işlev uygulaması ve ilgili kaynaklar oluşturmanın birkaç yolu vardır:

  • Dağıtım şablonları: İşlev uygulamanızı ilk olarak kod olarak altyapı (IaC) dosyalarını (Bicep, ARM şablonları veya Terraform) kullanarak dağıttıysanız, önceki dağıtımları yeni bölgeyi hedef alacak şekilde güncelleştirebilir ve bunları kullanarak yeni bölgedeki kaynakları yeniden oluşturabilirsiniz. Bu dağıtım dosyalarına artık sahip değilseniz, azure portalından mevcut kaynak grubunuz için istediğiniz zaman bir ARM şablonu indirebilirsiniz.
  • Azure CLI/PowerShell betikleri: İşlev uygulamanızı başlangıçta Azure CLI veya Azure PowerShell betikleri kullanarak dağıttıysanız, bu betikleri yeni bölgeyi hedefleyip yeniden çalıştıracak şekilde güncelleştirebilirsiniz. Artık bu betiklere sahip değilseniz Azure portalından mevcut kaynak grubunuz için bir ARM şablonu da indirebilirsiniz.
  • Azure portalı: İşlev uygulamanızı başlangıçta portalda oluşturduysanız veya betikleri veya IaC dosyalarını kullanmaktan memnun değilseniz portaldaki her şeyi yeniden oluşturabilirsiniz. Özgün uygulamanızla aynı barındırma planını, dil çalışma zamanını ve dil sürümünü kullandığınızdan emin olun.

Yapılandırılmış kaynakları gözden geçirme

Dağıtım sırasında yapılandırılmadıysa, hedef bölgede yukarıdaki Hazırlama adımında tanımlanan kaynakları gözden geçirin ve yapılandırın. Yönetilen kimlik kimlik doğrulaması ile sürekli dağıtım kullanıyorsanız, yeni işlev uygulamasında gerekli kimliklerin ve rol eşlemelerinin mevcut olduğundan emin olun.

Kaynak kodunuzu yeniden dağıtma

Artık altyapıyı oluşturduğunuza göre kaynak kodu yeniden paketleyebilir ve işlev uygulamasına yeniden dağıtabilirsiniz. Kaynak kodunuzu veya kapsayıcı görüntünüzü bir depoya taşımak ve bu depodan sürekli dağıtımı etkinleştirmek için uygun bir zamandır.

İşlevler tarafından desteklenen diğer yayımlama yöntemlerini de kullanabilirsiniz. Çoğu araç tabanlı yayımlama, üretim uygulamaları için önerilmez, uç noktada temel kimlik doğrulamasını scm etkinleştirmenizi gerektirir.

Yeniden konumlandırma ile ilgili dikkat edilmesi gerekenler

  • Yapılandırmanızı doğrulamayı ve işlevlerinizi hedef bölgede test edin.
  • Özel etki alanı yapılandırdıysanız, etki alanı adını yeniden yönlendirin.
  • Ayrılmış (App Service) planında çalışan bir işlev uygulaması için, plan bir veya daha fazla web uygulamasıyla paylaşıldığında App Service Geçiş Planı'nı da gözden geçirin.

Temizleme

Taşıma işlemi tamamlandıktan sonra işlev uygulamasını ve barındırma planını kaynak bölgeden silin. Uygulamanın kendisi çalışmasa bile Premium veya Ayrılmış planlarda işlev uygulamaları için ödeme yapabilirsiniz. Yeni bölgede başka hizmetleri yeniden oluşturdıysanız, artık gerekli olmadığından emin olduktan sonra eski hizmetleri de silmeniz gerekir.

Daha gelişmiş ve coğrafi olarak yedekli çözüm mimarilerinin bir parçası olarak birden çok bölgede çalışan işlev uygulamaları örnekleri için Azure Mimari Merkezi'ni gözden geçirin.

  • Last updated on