Application et déploiement dans Azure Spring Apps
Notes
Les plans Essentiel, Standard et Entreprise seront déconseillés à compter de la mi-mars 2025, avec une période de mise hors service de 3 ans. Nous vous recommandons de passer à Azure Container Apps. Pour plus d’informations, consultez l’annonce de mise hors service d’Azure Spring Apps.
Le plan de consommation standard et dédiée sera déconseillé à compter du 30 septembre 2024, avec un arrêt complet après six mois. Nous vous recommandons de passer à Azure Container Apps. Pour plus d’informations, consultez Migrer le plan de consommation standard et dédiée Azure Spring Apps vers Azure Container Apps.
Cet article s'applique à : ✅ Java ✅ C#
Cet article s'applique à : ✅ Basique/Standard ✅ Entreprise
L’application et le déploiement sont les deux concepts clés du modèle de ressources d’Azure Spring Apps. Dans Azure Spring Apps, une application est l’abstraction d’une application métier. Une version de code ou de binaire déployée comme application s’exécute dans un déploiement. Les applications s’exécutent dans une instance du service Azure Spring Apps ou simplement dans une instance de service, comme indiqué ci-dessous.
Vous pouvez avoir plusieurs instances de service au sein d’un seul abonnement Azure, mais le service Azure Spring Apps est plus facile à utiliser quand toutes les applications qui composent une application métier résident dans une instance de service unique. L’une des raisons est que les applications sont susceptibles de communiquer entre elles. Ils peuvent facilement le faire à l’aide du registre du service Eureka dans l’instance de service.
Le niveau Standard d’Azure Spring Apps permet à une application de disposer d’un déploiement de production et d’un déploiement de préproduction, ce qui vous permet d’y effectuer facilement un déploiement bleu-vert.
Les fonctionnalités/propriétés suivantes sont définies au niveau de l’application.
Fonctionnalités | Description |
---|---|
Point de terminaison public |
URL pour accéder à l’application. |
Domaine personnalisé |
L’enregistrement CNAME qui sécurise le domaine personnalisé. |
Liaison de service |
Connexion prête à l’emploi avec d’autres services Azure. |
Identité managée |
Une identité managée par Microsoft Entra ID permet à votre application d’accéder facilement à d’autres ressources protégées Microsoft Entra, comme Azure Key Vault. |
Stockage persistant |
Paramètre qui permet aux données d’être conservées au-delà du redémarrage de l’application. |
Les fonctionnalités/propriétés suivantes sont définies au niveau du déploiement et sont échangées lors du basculement entre un déploiement de production et un déploiement intermédiaire.
Fonctionnalités | Description |
---|---|
UC | Nombre de vCores par instance d’application. |
Mémoire | Go de mémoire par instance d’application. |
Nombre d’instances |
Nombre d’instances d’application, défini manuellement ou automatiquement. |
Mise à l’échelle automatique | Le nombre d'instances d'échelle est calculé automatiquement sur la base de règles et de planifications prédéfinies. |
Options JVM |
Options JVM à définir. |
Variables d’environnement |
Variables d’environnement à définir. |
Version du runtime |
Soit Java 8 ou Java 11. |
Azure Spring Apps monte certains fichiers YAML en lecture seule sur vos applications déployées. Ces fichiers contiennent le contexte Azure d’un déploiement. La liste suivante présente les chemins d’accès et le contenu de ces fichiers YAML :
/etc/azure-spring-cloud/context/azure-spring-apps.yml
AZURE_SPRING_APPS: SUBSCRIPTION_ID: <your-azure-subscription-id> RESOURCE_GROUP: <your-resource-group-name> NAME: <your-azure-spring-apps-name>
/etc/azure-spring-cloud/context/azure-spring-apps-deployment.yml
AZURE_SPRING_APPS: APP: NAME: <your-app-name> DEPLOYMENT: NAME: <your-deployment-name> ACTIVE: true # true if the deployment is in production, false if in staging
Si votre application est une application Spring Boot, ces deux chemins de fichier sont ajoutés à la variable d’environnement SPRING_CONFIG_ADDITIONAL_LOCATION
. De cette façon, votre application peut charger ces propriétés en tant que configurations et les utiliser dans votre code. Par exemple, vous pouvez utiliser l’annotation @ConfigurationProperties
pour lier les propriétés YAML à une classe Java. L’extrait de code suivant montre comment créer une @Configuration
classe qui représente le contexte Azure :
import lombok.Data;
import org.springframework.boot.context.properties.ConfigurationProperties;
import org.springframework.context.annotation.Configuration;
@Configuration
@ConfigurationProperties(prefix = "azure-spring-apps")
@Data
public class AzureSpringAppsContext {
private String subscriptionId;
private String resourceGroup;
private String name;
private AppContext app;
private DeploymentContext deployment;
@Data
public static class AppContext {
private String name;
}
@Data
public static class DeploymentContext {
private String name;
private boolean active;
}
}
Pour toutes les autres applications polyglottes, vous devrez peut-être lire et accéder aux propriétés correspondantes à l’aide des bibliothèques de lecture/écriture de fichiers correspondantes dans vos applications.
- Une application doit avoir un déploiement de production. L’API bloque la suppression d’un déploiement de production. Vous devez échanger un déploiement en préproduction avant de le supprimer.
- Une application peut avoir au maximum deux déploiements. L’API bloque la création de plus de deux déploiements. Déployez votre nouveau binaire dans le déploiement de production ou intermédiaire existant.
- La gestion du déploiement n’est pas disponible dans le plan de base. Utilisez le plan Standard ou Enterprise pour la fonctionnalité de déploiement bleu-vert.