Partager via

Déplacer votre application de fonction vers une autre région Azure

  • Article

Cet article explique comment déplacer une application de fonction hébergée par Azure Functions vers une autre région Azure.

Il existe différentes raisons pour lesquelles vous pouvez avoir besoin de déplacer vos ressources Azure existantes d’une région à une autre. Vous pouvez :

  • Tirer parti d’une nouvelle région Azure.
  • Déployer des fonctionnalités ou des services disponibles uniquement dans des régions spécifiques.
  • Respecter les exigences de gouvernance et de stratégie internes.
  • Être en phase avec les fusions et acquisitions de l’entreprise
  • Répondez aux exigences de planification de la capacité.

Les ressources Azure qui hébergent votre application de fonction sont spécifiques à la région et ne peuvent pas être déplacées entre régions. Au lieu de cela, vous devez créer une copie de vos ressources d’application de fonction existantes dans la région cible, puis redéployer votre code de fonctions sur la nouvelle application.

Prérequis

  • S’assurer que la région cible prend en charge Azure Functions et tout service associé dont vous souhaitez déplacer les ressources.
  • Assurez-vous que vous disposez de privilèges pour créer les ressources nécessaires dans la nouvelle région.

Préparer

Identifiez toutes les ressources de l’application de fonction utilisées sur la région source, ce qui peut inclure :

Lorsque vous préparez le déplacement de votre application vers une nouvelle région, quelques parties de l’architecture nécessitent une considération et une planification particulières.

Nom de la Function App

Les noms des applications de fonction doivent être globalement uniques dans l’ensemble des applications Azure. Cela signifie que votre nouvelle application de fonction ne peut pas avoir le même nom et la même URL que celle d’origine. Cela est même vrai lors de l’utilisation d’un DNS personnalisé, car le <APP_NAME>.azurewebsites.net sous-jacent doit toujours être unique. Vous devrez peut-être mettre à jour tous les clients qui se connectent aux points de terminaison HTTP sur votre application de fonction. Ces clients doivent utiliser la nouvelle URL lorsque vous effectuez des requêtes.

Code source

Dans l’idéal, vous conservez votre code source dans un référentiel de code d’un type quelconque, ou dans un référentiel de conteneurs en cas d’exécution dans un conteneur Linux. Si vous utilisez un déploiement continu, envisagez de basculer la connexion de déploiement de référentiel ou de conteneur à la nouvelle adresse de l’application de fonction. Si, pour une raison quelconque, vous n’avez plus le code source, vous pouvez télécharger le package en cours d’exécution à partir de l’application de fonction d’origine. Nous vous recommandons de stocker vos fichiers sources dans un référentiel de code et d’utiliser un déploiement continu pour les mises à jour.

Compte de stockage par défaut

L’hôte Functions nécessite un compte de stockage Azure. Pour plus d'informations, consultez Exigences relatives au compte de stockage. Pour des performances optimales, votre application de fonction doit utiliser un compte de stockage dans la même région. Lorsque vous créez une application avec un nouveau compte de stockage dans votre nouvelle région, votre application obtient un nouvel ensemble de clés d’accès de fonction et l’état de tous les déclencheurs (tels que les déclencheurs de minuteur) est réinitialisé.

Stockage local persistant

Les exécutions de fonctions sont destinées à être sans état. Toutefois, nous ne vous empêchez pas d’écrire des données dans le système de fichiers local. Il est possible de stocker les données générées et utilisées par votre application sur le lecteur virtuel %HOME%\site, mais elles ne doivent pas être liées à l’état. Si votre scénario vous oblige à maintenir l’état entre les exécutions de fonction, envisagez plutôt d’utiliser Durable Functions.

Si votre application conserve les données sur le chemin de stockage partagé de l’application, veillez à planifier la façon dont vous allez gérer cet état pendant un déplacement de ressources. N’oubliez pas que pour les applications de plan Dedicated (App Service), le partage fait partie du site. Pour les plans Consommation et Premium, le partage est, par défaut, un partage Azure Files dans le compte de stockage par défaut. Les applications s’exécutant sur Linux peuvent utiliser un partage monté explicitement pour le stockage persistant.

Services connectés

Vos fonctions peuvent se connecter à Azure Services et à d’autres ressources à l’aide d’un Kit de développement logiciel (SDK) de service ou de déclencheurs et de liaisons. Tout service connecté peut être affecté négativement lorsque l’application passe à une nouvelle région. En cas de latence ou d’autres problèmes, envisagez de déplacer également n’importe quel service connecté vers la nouvelle région. Pour savoir comment déplacer ces ressources d’une région à l’autre, consultez la documentation des services respectifs. Lorsque vous déplacez une application avec des services connectés, vous pouvez envisager une stratégie de récupération d'urgence et de continuité d’activité inter-régions pendant le déplacement.

Les modifications apportées aux services connectés peuvent nécessiter la mise à jour des valeurs stockées dans les paramètres de votre application, qui sont utilisées pour se connecter à ces services.

Configuration

  • Vous pouvez capturer un instantané des paramètres d’application existants et des chaînes de connexion à partir du Portail Azure. Développez Paramètres>Variables d’environnement, sélectionnez Modification avancée sous Paramètres de l’application ou Chaînes de connexion et enregistrez la sortie JSON contenant les paramètres ou connexions existants. Vous devez recréer ces paramètres dans la nouvelle région, mais les valeurs elles-mêmes sont susceptibles de changer en raison des modifications de région suivantes dans les services connectés.

  • Les références Key Vault existantes ne peuvent pas être exportées au-delà d’une limite géographique Azure. Vous devez recréer toutes les références requises dans la nouvelle région.

  • Votre configuration d’application peut être gérée par Azure App Configuration ou à partir d’une autre dépendance de base de données centrale (en aval). Passez en revue les magasins App Configuration ou les magasins similaires pour les paramètres spécifiques à l’environnement et à la région susceptibles de nécessiter des modifications.

Domaines personnalisés

Si votre application de fonction utilise un domaine personnalisé, liez-la à l’application cible de manière préventive. Vérifiez et activez le domaine dans l’application cible. Après le déplacement, vous devez remappper le nom de domaine.

Réseaux virtuels

Azure Functions vous permet d’intégrer vos applications à des ressources de réseau virtuel, et même de les exécuter dans un réseau virtuel. Pour plus d’informations, consultez la section Options de mise en réseau Azure Functions. Lors du déplacement vers une nouvelle région, vous devez d’abord déplacer ou recréer toutes les ressources de réseau virtuel et de sous-réseau nécessaires avant de déployer votre application. Cela inclut le déplacement ou la recréation de points de terminaison privés et de points de terminaison de service.

Identités

  • Vous devez recréer toutes les identités managées affectées par le système, ainsi que votre application dans la nouvelle région cible. En règle générale, une application Microsoft Entra ID créée automatiquement (utilisée par EasyAuth) utilise par défaut le nom de la ressource d’application.

  • Les identités managées affectées par l’utilisateur ne peuvent pas non plus être déplacées entre les régions. Pour conserver les identités managées affectées par l’utilisateur dans le même groupe de ressources que votre application, vous devez les recréer dans la nouvelle région. Pour plus d’informations, consultez Relocaliser des identités managées pour les ressources Azure vers une autre région.

  • Accordez aux identités managées les mêmes autorisations dans vos services déplacés que les identités d’origine qu’elles remplacent, y compris les appartenances au groupe.

Certificats

Les ressources App Service Certificate peuvent être déplacées vers un nouveau groupe de ressources ou un nouvel abonnement, mais pas entre différentes régions. Les certificats exportables peuvent également être importés dans l’application ou dans Key Vault dans la nouvelle région. Ce processus d’exportation et d’importation équivaut à un déplacement entre les régions.

Il existe différents types de certificats qui doivent être pris en considération lorsque vous planifiez le déplacement de votre service :

Type de certificat Exportable Commentaires
Géré par App Service Non Recréez ces certificats dans la nouvelle région.
Géré par Azure Key Vault Oui Ces certificats peuvent être exportés à partir de Key Vault, puis importés dans Key Vault dans la nouvelle région.
Clé privée (auto-gérée) Oui Les certificats que vous avez acquis en dehors d’Azure peuvent être exportés à partir d’App Service, puis importés dans la nouvelle application ou dans Key Vault dans la nouvelle région.
Clé publique Non Votre application peut avoir des certificats avec uniquement une clé publique et aucun secret, qui sont utilisés pour accéder à d’autres points de terminaison sécurisés. Obtenez les fichiers de certificat de clé publique requis et importez-les dans l’application dans la nouvelle région.

Clés d’accès

Functions utilise des clés d’accès pour rendre plus difficile l’accès aux points de terminaison HTTP dans votre application de fonction. Ces clés sont chiffrées dans le compte de stockage par défaut. Lorsque vous créez une application dans la nouvelle région, un ensemble de clés est créé. Vous devez mettre à jour tous les clients existants qui utilisent des clés d’accès afin d’utiliser les nouvelles clés dans la nouvelle région. Bien que vous deviez utiliser les nouvelles clés, il est possible de recréer les anciennes clés dans la nouvelle application. Pour plus d’informations, consultez Utiliser des clés d’accès dans Azure Functions.

Temps d’arrêt

Si un temps d’arrêt minimal est requis, envisagez d’exécuter votre application de fonction dans les deux régions, comme recommandé, pour implémenter une architecture de récupération d’urgence. L’architecture spécifique que vous implémentez dépend des types de déclencheurs dans votre application de fonction. Pour plus d’informations, consultez Fiabilité dans Azure Functions.

Fonctions durables

L’extension Durable Functions vous permet de définir des orchestrations, où l’état est conservé dans vos exécutions de fonction à l’aide d’entités avec état. Dans l’idéal, vous devez autoriser l’exécution des orchestrations avant de migrer votre application Durable Functions, en particulier lorsque vous envisagez de basculer vers un nouveau compte de stockage dans la nouvelle région. Lors de la migration de vos applications Durable Functions, envisagez d’utiliser l’une de ces stratégies de récupération d’urgence et de géo-distribution.

Relocaliser

La recréation de votre application de fonction dans une nouvelle région vous oblige à recréer d’abord l’infrastructure Azure d’un plan App Service, une instance d’application de fonction et des ressources associées, telles que les réseaux virtuels, les identités et les emplacements. Vous devez également vous reconnecter ou, dans la nouvelle région, recréer les ressources Azure requises par l’application. Ces ressources peuvent inclure le compte de stockage Azure par défaut et l’instance Application Insights.

Vous pouvez ensuite empaqueter et redéployer le code source ou le conteneur de l’application de fonction en cours d’exécution dans la nouvelle région.

Recréer votre infrastructure Azure

Il existe plusieurs façons de créer une application de fonction et des ressources associées dans Azure dans la région cible :

  • Modèles de déploiement : si vous avez initialement déployé votre application de fonction à l’aide de fichiers IaC (Infrastructure-as-code) (Bicep, modèles ARM ou Terraform), vous pouvez mettre à jour ces déploiements précédents pour cibler la nouvelle région et les utiliser pour recréer des ressources dans la nouvelle région. Si vous n’avez plus ces fichiers de déploiement, vous pouvez toujours télécharger un modèle ARM pour votre groupe de ressources existant à partir du Portail Azure.
  • Scripts Azure CLI/PowerShell : si vous avez déployé initialement votre application de fonction à l’aide d’Azure CLI ou de scripts Azure PowerShell, vous pouvez mettre à jour ces scripts pour cibler la nouvelle région et les réexécuter. Si vous ne disposez plus de ces scripts, vous pouvez également télécharger un modèle ARM pour votre groupe de ressources existant à partir du Portail Azure.
  • Portail Azure : si vous avez créé votre application de fonction dans le portail à l’origine ou que vous ne vous sentez pas à l’aise pour utiliser des scripts ou des fichiers IaC, vous pouvez simplement recréer tout ce qui se trouve dans le portail. Veillez à utiliser le même plan d’hébergement, le même runtime de langage et la même version de langue que votre application d’origine.

Examiner les ressources configurées

Examinez et configurez les ressources identifiées à l’étape Préparation ci-dessus dans la région cible si elles n’ont pas été configurées pendant le déploiement. Si vous utilisez un déploiement continu avec l’authentification d’identité managée, vérifiez que les identités et mappages de rôles requis existent dans la nouvelle application de fonction.

Redéployer votre code source

Maintenant que vous disposez de l’infrastructure en place, vous pouvez repackager et redéployer le code source dans l’application de fonction. Il est judicieux de déplacer votre code source ou votre image conteneur vers un référentiel et d’activer le déploiement continu à partir de ce référentiel.

Vous pouvez également utiliser n’importe quelle autre méthode de publication prise en charge par Functions. La plupart des publications basées sur des outils vous obligent à activer l’authentification de base sur le point de terminaison scm, ce qui n’est pas recommandé pour les applications de production.

Considérations relatives au déplacement

  • N’oubliez pas de vérifier votre configuration et de tester vos fonctions dans la région cible.
  • Si vous avez configuré un domaine personnalisé, remappez le nom de domaine.
  • Pour une application de fonction s’exécutant dans un plan Dedicated (App Service), passez également en revue le plan de migration App Service lorsqu’il est partagé avec une ou plusieurs applications web.

Nettoyage

Une fois le déplacement terminé, supprimez l’application de fonction et le plan d’hébergement de la région source. Vous payez pour des applications de fonction dans des plans Premium ou Dedicated, même quand l’application elle-même n’est pas en cours d’exécution. Si vous avez recréé d’autres services dans la nouvelle région, vous devez également supprimer les anciens services une fois que vous êtes certain qu’ils ne sont plus nécessaires.

Consultez le Centre des architectures Azure pour obtenir des exemples d’applications de fonction s’exécutant dans plusieurs régions dans le cadre d’architectures de solutions plus avancées et géoredondantes.