Aller au contenu

Azure App Service : héberger et gérer une application Web

1. Présentation

Azure App Service (service d'exploitation) est un service Cloud de type PaaS (Platform as a Service) permettant d’héberger des applications web pouvant contenir une application ASP .NET MVC, une application Blazor, des services Web API ou gRPC. En plus de la plateforme .NET, il prend en charge les environnements Java, Node.js, Python, Ruby et PHP, ainsi que le déploiement de conteneurs (Docker) personnalisés.

Microsoft Azure prend en charge l’infrastructure d’hébergement et la gestion de la plateforme selon le mode choisi. Le développeur se concentre sur le code, la configuration, le déploiement et l'utilisation de l'application. App Service propose des environnements Windows et Linux ; les possibilités dépendent de la technologie et du mode d’hébergement retenus.

2. L’application et son plan App Service

La création d’une application implique de choisir ou de créer un plan App Service. Ce plan définit les ressources de calcul sur lesquelles elle s’exécute.

Élément Rôle
Application App Service Héberger le code ou le conteneur et porter sa configuration.
Plan App Service Définir la région, le système d’exploitation, la capacité de calcul, le nombre d’instances et le niveau tarifaire.
Services externes Fournir, par exemple, une base de données, du stockage ou une gestion des secrets.

Plusieurs applications peuvent partager un même plan. Elles partagent alors ses ressources de calcul : une application très consommatrice peut affecter les performances des autres. Les emplacements de déploiement utilisent également les ressources du plan.

3. La répartition des responsabilités

Le modèle PaaS réduit les tâches d’administration, mais l’entreprise reste responsable de son application.

Dans le mode classique utilisant un environnement d’exécution intégré, Microsoft gère notamment les serveurs et les mises à jour de la plateforme. L’équipe applicative reste responsable du code, des dépendances, des données, des droits d’accès et de la configuration. Avec un conteneur personnalisé, elle doit aussi entretenir son image et les composants qu’elle contient.

Cette section permettrait de souligner un principe : un hébergement managé ne dispense pas de concevoir, sécuriser et superviser le logiciel.

4. Le déploiement d’une application

App Service permet de publier une application depuis des outils de développement ou une chaîne d’intégration et de déploiement continus, notamment avec GitHub Actions ou Azure Pipelines.

Pour ton exemple, tu pourrais présenter une API ASP.NET Core, puis expliquer comment une modification validée dans Git déclenche sa compilation et son déploiement.

5. Les emplacements de déploiement

Les deployment slots, ou emplacements de déploiement, permettent de déployer une version dans un emplacement distinct de la production. L’équipe peut la vérifier avant de procéder à une permutation avec l’emplacement de production.

Cette fonctionnalité dépend du niveau tarifaire. Les emplacements partagent les ressources du plan : ils ne constituent donc pas des infrastructures entièrement indépendantes. La permutation doit aussi tenir compte de la configuration et de la compatibilité des changements de base de données.

6. La mise à l’échelle

Deux approches peuvent être présentées :

  • Mise à l’échelle verticale (scale up) : augmenter la capacité des instances, notamment en processeur et en mémoire.
  • Mise à l’échelle horizontale (scale out) : augmenter le nombre d’instances exécutant les applications.

Les possibilités d’automatisation dépendent du plan choisi. Par défaut, la mise à l’échelle du plan concerne les applications qu’il héberge.

Tu peux ensuite expliquer les conséquences pour le logiciel : éviter de conserver des informations indispensables uniquement dans la mémoire d’une instance et prévoir un stockage partagé lorsque plusieurs instances doivent accéder aux mêmes données.

7. La sécurité et les accès réseau

Cette section peut aborder HTTPS, l’authentification, les autorisations et l’accès aux services utilisés par l’application.

Une distinction mérite d’être expliquée : l’intégration à un réseau virtuel concerne les connexions sortantes de l’application vers les ressources du réseau. Elle ne rend pas, à elle seule, l’accès entrant à l’application privé.

8. Un exemple concret avec ASP.NET Core

Pour donner un fil conducteur à l’article, je te propose une application de gestion de commandes :

  1. Une API ASP.NET Core est hébergée dans App Service.
  2. Un plan App Service fournit ses ressources de calcul.
  3. Une base de données Azure SQL conserve les commandes.
  4. La configuration distingue les environnements.
  5. Une chaîne de déploiement publie les nouvelles versions.
  6. La supervision permet de suivre les erreurs, les performances et la consommation des ressources.

Cet exemple peut ensuite devenir un tutoriel distinct. L’article de présentation resterait ainsi centré sur les concepts, avec une idée directrice : App Service simplifie l’hébergement d’une application web, tandis que son bon fonctionnement repose toujours sur les choix de conception, de configuration et d’exploitation.