Relocaliser Azure Static Web Apps dans une autre région

Cet article explique comment relocaliser les ressources Azure Static Web Apps dans 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é.

Prérequis

Passez en revue les prérequis suivants avant de vous préparer pour la relocalisation.

• Vérifiez qu’Azure Static Web Apps est disponible dans la région cible.

• Vérifiez que vous avez l’autorisation de créer des ressources Static Web Apps dans la région cible.

• Vérifiez si des restrictions de région Azure Policy s’appliquent à votre organisation.

• Si vous utilisez la prise en charge d’API intégrée fournie par Azure Functions :

  • Déterminez la disponibilité d’Azure Functions dans la région cible.
  • Déterminez si les clés API de fonction sont actuellement utilisées. Par exemple, est-ce que vous utilisez Key Vault ou est-ce que vous les déployez dans le cadre de vos fichiers de configuration d’application ?
  • Déterminez le modèle de déploiement pour la prise en charge des API dans la région cible : Apportez vos propres fonctions. Comprenez les différences entre les deux modèles.

• Vérifiez que le plan d’hébergement Standard est utilisé pour héberger l’application web statique. Pour plus d’informations sur les plans d’hébergement, consultez Plans d’hébergement Azure Static Web Apps.

• Déterminez le temps d’arrêt autorisé pour le transfert.

• Selon votre déploiement d’Azure Static Web Apps, les ressources dépendantes suivantes peuvent être déployées et configurées dans la région cible avant la relocalisation :

  • Azure Functions.
  • Réseau virtuel Azure
  • Azure Front Door
  • Groupe de sécurité réseau
  • Service Azure Private Link
  • Azure Key Vault
  • Compte Stockage Azure
  • Application Gateway Azure

Temps d’arrêt

La relocalisation d’un site web statique Azure implique un temps d’arrêt pour votre application. Le temps d’arrêt est affecté par le modèle de haute disponibilité que vous avez implémenté pour votre site web statique Azure. Les modèles généraux sont les suivants :

• Reprise progressive (cold standby) : Les données de charge de travail sont sauvegardées régulièrement en fonction des besoins. En cas de sinistre, la charge de travail est redéployée dans une nouvelle région Azure et les données sont restaurées.
• Reprise immédiate (warm standby) : La charge de travail est déployée dans la région de continuité d’activité et reprise d’activité (BCDR), et les données sont répliquées de manière asynchrone ou synchrone. En cas de sinistre, le déploiement dans la région de reprise d’activité (DR) fait l’objet d’un scale-up et d’un scale-out.
• Multirégion : La charge de travail est déployée dans les deux régions et les données sont répliquées de manière synchrone. Les deux régions ont une copie accessible en écriture des données. L’implémentation peut être active/passive ou active/active.

Préparer

Déploiements avec des points de terminaison privés

Si vos ressources Static Web Apps sont déployées avec des points de terminaison privés, veillez à :

• Mettre à jour le nom d’hôte pour le point de terminaison de connexion.
• Mettre à jour le nom d’hôte sur la zone privée DNS ou le serveur DNS personnalisé (applicable uniquement à Private Link).

Pour plus d’informations, consultez Configurer un point de terminaison privé dans Azure Static Web Apps.

Tous les autres déploiements

Pour tous les autres types de déploiement, veillez à :

• Le cas échéant, récupérez les nouvelles clés API de fonction d’Azure Functions dans la nouvelle région.

• Si la fonction Azure a une dépendance à une base de données, vérifiez que DATABASE_CONNECTION_STRING est mis à jour. Il est possible que cette base de données n’entre pas dans le cadre de la migration régionale.

• Mettez à jour le domaine personnalisé pour qu’il pointe vers le nouveau nom d’hôte de l’application web statique.

• Si vous utilisez Key Vault, approvisionnez un nouveau coffre de clés dans la région cible. Mettez à jour les clés API de fonction dans Key Vault le cas échéant. Toutes les autres données sensibles à ne pas stocker dans du code ou des fichiers de configuration doivent être stockées dans ce coffre de clés

Exporter le modèle

Pour exporter le modèle Resource Manager contenant les paramètres qui décrivent votre application web statique :

1. Connectez-vous au portail Azure.

2. Accédez à votre application web statique.

3. Dans le menu de gauche, sous Automatisation, sélectionnez Exporter le modèle.

   La génération du modèle peut prendre un certain temps.

4. Sélectionnez Télécharger.

5. Recherchez le fichier .zip téléchargé et ouvrez-le dans un dossier de votre choix.

   Ce fichier contient les fichiers .json qui incluent le modèle et les scripts pour le déployer.

6. Apportez les modifications nécessaires au modèle, telles que la mise à jour de la localisation avec la région cible.

Relocaliser

Suivez ces étapes pour relocaliser votre application web statique dans une autre région.

1. Si vous relocalisez avec un point de terminaison privé, suivez les instructions dans Relocaliser le service Azure Private Link dans une autre région.

2. Si vous avez fourni une instance Azure Functions existante à votre application web statique, suivez la procédure de relocalisation pour Azure Functions.

3. Redéployez votre application web statique à l’aide du modèle que vous avez exporté et configuré dans la section précédente.

   Important

   Si vous n’utilisez pas de domaine personnalisé, l’URL de votre application change dans la région cible. Dans ce scénario, assurez-vous que les utilisateurs ont pris connaissance du changement d’URL.

4. Si vous utilisez une API intégrée, créez une nouvelle API intégrée prise en charge par Azure Functions.

5. Reconfigurez votre dépôt (GitHub ou Azure DevOps) à déployer dans l’application web statique nouvellement déployée dans la région cible. Lancez le déploiement de l’application en utilisant GitHub Actions ou Azure Pipelines.

6. Avec un déploiement dereprise progressive, assurez-vous d’informer les clients de la nouvelle URL. Si vous utilisez un domaine DNS personnalisé, changez simplement l’entrée DNS pour qu’elle pointe vers la région cible. Avec un déploiement de reprise immédiate, un équilibreur de charge, tel que Front Door ou Traffic Manager, gère la migration de l’application web statique de la région source vers la région cible.