Régions et types de services

Ce que vous saurez faire

Avant de louer quoi que ce soit dans le nuage, déterminez les besoins de votre service. Déterminez aussi quel type de service infonuagique y répond. Vous pourrez ensuite choisir la conception la plus simple qui fonctionne et la placer au bon endroit. Vous saurez aussi quelles parties restent votre responsabilité.

Avant de commencerCe qu’il faut savoir et avoir sous la mainEnviron 40 minutes

Ce que vous devez savoir

• Les cinq tâches d’une plateforme d’hébergement (construire, démarrer, écouter, configurer, maintenir en marche), dans Premiers pas avec l’hébergement : ce que fait une plateforme d’hébergement.
• Une image avec des paramètres différents pour chaque environnement, dans Configuration à l’exécution : une image, plusieurs environnements.
• Où placer les données (un volume, une base de données, un stockage d’objets), dans Données persistantes : où stocker les données.
• Pourquoi les fichiers d’un conteneur sont jetables, dans Données persistantes : les fichiers d’un conteneur sont jetables.

Ce qu’il vous faut sur votre ordinateur

• Le dossier du projet ~/projects/ticket-api à la fin du module 3, avec compose.yaml et le tableau des paramètres dans README.md. Ils viennent de Données persistantes : écrire compose.yaml et de Exercice guidé : l’API et sa base de données. Vous lisez ces fichiers dans cette leçon. Vous ne les modifiez pas.
• Si votre projet manque ou ne fonctionne plus, copiez l’instantané end-of-m03, comme dans Utiliser un instantané.
• Vous n’avez pas besoin d’un compte Azure pour ce module. Le module 4 ne crée rien dans le nuage et ne coûte rien. Ses sorties Azure sont des sorties réelles, enregistrées lors d’une véritable exécution. Une commande facultative nécessite un compte Azure.

Les étapes Azure ont été exécutées avec Azure CLI 2.88.0 et l’extension containerapp 1.3.0b5, dans la région canadacentral. Les faits sur Azure, AWS et Google Cloud viennent de leur documentation.

Ce dont l’API a besoin

Commencez par le service, pas par le nuage. Sur son ordinateur, Amira exécute ticket-api avec docker compose up -d. Elle dresse la liste de ce que l’API y utilise :

Ce dont l’API a besoin	Sur l’ordinateur d’Amira (module 3)
Un ordinateur qui exécute le conteneur à partir de l’image	Docker Desktop exécute ticket-api:1.1.0
Une adresse que les clients peuvent joindre	-p 127.0.0.1:8000:8000 : seulement son ordinateur
Des paramètres	REQUIRE_API_KEY, SHOW_DOCS, DATABASE_URL dans compose.yaml et .env
Un secret	La clé d’API dans secrets/api_key.txt, montée comme fichier
Un endroit pour les enregistrements	PostgreSQL dans le conteneur db, avec le volume ticket-api_pgdata
Des journaux (logs)	docker compose logs api

Un fournisseur infonuagique, comme Azure, AWS ou Google Cloud, vous loue chacun de ces éléments sous forme de service. Vous payez ce que vous utilisez et vous pouvez le supprimer à la fin. Chaque fournisseur offre les mêmes types de services de base, sous des noms différents. Ce module prend Azure comme exemple, parce que le module 5 y déploie l’application. Les idées s’appliquent aussi aux autres nuages.

Régions

Une région est un endroit du monde où un fournisseur infonuagique possède des centres de données. Par exemple, canadacentral (Toronto) ou westeurope (Pays-Bas). Quand vous créez une ressource, vous choisissez sa région. La ressource y fonctionne et y conserve ses données.

La région compte pour quatre raisons :

• Distance (latence). Chaque requête fait l’aller-retour jusqu’à la région. Une région proche de vos utilisateurs répond plus vite.
• Lieu de conservation des données (résidence des données). Certaines lois et certains contrats exigent que les données restent dans un pays ou dans l’Union européenne. Azure regroupe ses régions en zones géographiques, comme le Canada ou l’Europe. Une zone géographique délimite la résidence des données.
• Prix. Le même service peut coûter un montant différent dans une autre région.
• Services disponibles. Les services ne sont pas tous disponibles dans chaque région.

De nombreuses régions ont aussi des zones de disponibilité : des groupes distincts de centres de données dans la même région. Chacune possède sa propre alimentation électrique, son propre refroidissement et son propre réseau. Un service qui utilise plusieurs zones continue de fonctionner quand une zone tombe en panne. L’exercice de ce cours utilise une région et ne configure aucune zone.

Si vous avez un compte Azure, vous pouvez afficher la liste des régions avec Azure CLI. Cette commande ne fait que lire et ne crée rien :

Terminal (optional)

az account list-locations --query "[?name=='canadacentral' || name=='westeurope'].{Name:name, DisplayName:displayName, Geography:metadata.geographyGroup}" -o table

La sortie (réelle) :

Name           DisplayName     Geography
-------------  --------------  -----------
westeurope     West Europe     Europe
canadacentral  Canada Central  Canada

Le champ Name (nom) indique ce que vous tapez dans les commandes, par exemple --location canadacentral. Ce jour-là, dans l’abonnement du cours, les machines virtuelles étaient disponibles dans 49 régions, et Azure Container Apps dans 46. Par exemple, Israel Central et Qatar Central offraient des machines virtuelles, mais pas Container Apps. Vérifiez que chaque service de votre conception est disponible dans la région choisie.

Le cours a utilisé canadacentral. Choisissez une région près de vous qui offre Azure Container Apps. Utilisez-la dans chaque commande où le cours indique canadacentral. Utilisez la même région pour toutes les ressources d’un service. Ainsi, ses parties n’envoient pas de données entre les régions.

Types de services

Chaque élément de base est un type de service. Les voici, avec leurs noms généraux en premier. Les autres nuages servent seulement de repères : ce cours ne les utilise pas.

Type	Ce qu’il vous fournit	Azure	AWS	Google Cloud	Sur votre ordinateur
Calcul : une machine virtuelle	Un serveur complet. Vous gérez son système d’exploitation.	Virtual Machines	Amazon EC2	Compute Engine	Votre ordinateur
Calcul : des conteneurs sans serveur	Exécute votre image. Démarre et arrête des copies selon le trafic.	Azure Container Apps	Amazon ECS on AWS Fargate	Cloud Run	docker run, Compose
Calcul : un orchestrateur de conteneurs	De nombreux conteneurs sur une grappe de serveurs, avec un contrôle complet	Azure Kubernetes Service	Amazon EKS	Google Kubernetes Engine	Compose (une petite version)
Calcul : des fonctions	Exécute une fonction pour chaque événement ou requête	Azure Functions	AWS Lambda	Cloud Run functions	Aucun
Stockage : le stockage d’objets	Des fichiers accessibles par leur nom, comme les fichiers téléversés et les fichiers de modèles	Blob Storage	Amazon S3	Cloud Storage	Un dossier, un montage lié
Base de données : PostgreSQL géré	Un serveur PostgreSQL dont le fournisseur applique les correctifs et fait les sauvegardes	Azure Database for PostgreSQL flexible server	Amazon RDS for PostgreSQL	Cloud SQL for PostgreSQL	postgres:18.6-trixie avec un volume
Réseau : une entrée HTTPS	Une adresse HTTPS publique qui envoie les requêtes à votre application	Container Apps ingress	Application Load Balancer	Intégrée à Cloud Run	-p 127.0.0.1:8000:8000, sans HTTPS
Réseau : un réseau privé	Des parties qui communiquent entre elles, mais pas avec Internet	Virtual Network	Amazon VPC	VPC network	Un réseau Compose
Service géré : un registre de conteneurs	Conserve vos images	Azure Container Registry	Amazon ECR	Artifact Registry	docker image ls
Service géré : un magasin de secrets	Conserve les secrets et les fournit aux identités autorisées	Key Vault	AWS Secrets Manager	Secret Manager	secrets/api_key.txt
Service géré : des journaux	Recueille les journaux et permet d’y chercher	Log Analytics workspace	Amazon CloudWatch Logs	Cloud Logging	docker logs

Un service géré est un logiciel que le fournisseur exécute pour vous. Vous utilisez la base de données, le registre ou le magasin de journaux. Le fournisseur assure son fonctionnement, applique les correctifs et fait les sauvegardes. Vous choisissez toujours ses paramètres et vous continuez de payer pour ce service.

Sur AWS, App Runner était la façon la plus simple d’exécuter une image de conteneur avec une adresse HTTPS publique. AWS a fermé App Runner aux nouveaux clients le 30 avril 2026. Il suggère Amazon ECS Express Mode, qui fonctionne sur Fargate. Les noms changent. Les types de services ne changent pas.

Qui gère quoi

Les types de services de calcul diffèrent sur un point important : qui gère chaque couche. Sur votre ordinateur, vous gérez tout. Une machine virtuelle louée est de l’IaaS (infrastructure en tant que service). Le fournisseur gère le matériel. Vous gérez le système d’exploitation et tout ce qui se trouve au-dessus. Dans un service sans serveur, le fournisseur gère aussi les serveurs, leur système d’exploitation et le certificat HTTPS. Il gère aussi le démarrage et l’arrêt des copies de votre application. Vous ne voyez ni ne gérez aucun serveur. Vous payez ce qui s’exécute.

La limite des responsabilités. Le sans serveur confie les serveurs et leur entretien au fournisseur. Votre image, vos paramètres, vos identités et votre nettoyage restent votre responsabilité sur chaque plateforme.

Description textuelle du diagramme

La grille compare trois endroits où exécuter l’API de billets. Chaque ligne représente une tâche, et chaque cellule indique qui la fait. Sur votre ordinateur avec Docker, vous faites les huit tâches. Sur une machine virtuelle, le fournisseur n’en fait qu’une : les serveurs, le réseau et le centre de données. Vous appliquez toujours les correctifs au système d’exploitation, configurez HTTPS et redémarrez l’application quand elle s’arrête. Avec les conteneurs sans serveur, le fournisseur gère aussi le système d’exploitation hôte, le certificat HTTPS et l’adresse publique. Pour la mise à l’échelle et les redémarrages, vous fixez les limites (par exemple, de 0 à 2 copies). Le fournisseur les respecte. Quatre lignes restent votre responsabilité sur chaque plateforme. Ce sont votre code et l’image, les paquets du système d’exploitation dans l’image, puis les paramètres, secrets et identités. La quatrième est la décision de ce qui existe et du moment où le supprimer.

Regardez la deuxième ligne. L’image contient Debian 13 et Python 3.14.8 (module 2). En mode sans serveur, le fournisseur applique les correctifs à ses serveurs, mais pas aux paquets de votre image. Quand l’image de base reçoit un correctif de sécurité, vous reconstruisez votre image et la déployez de nouveau. Personne d’autre ne le fait pour vous.

Groupes de ressources, abonnements et locataires

Chaque élément que vous créez dans Azure, comme un registre ou une application conteneurisée, est une ressource. Les ressources sont rangées dans des conteneurs à trois niveaux :

• Un groupe de ressources est un dossier pour des ressources qui ont le même cycle de vie. Vous les créez ensemble et les supprimez ensemble. Quand vous supprimez un groupe de ressources, Azure supprime toutes les ressources qu’il contient. Chaque ressource appartient à un seul groupe de ressources. L’exercice utilise un groupe, rg-ticket-api-practice, pour qu’une seule commande puisse tout supprimer.
• Un abonnement est une entente avec Azure, avec un mode de paiement et ses propres limites. Chaque groupe de ressources appartient à un abonnement. Les coûts de ses ressources figurent sur la facture de cet abonnement. Une entreprise a souvent des abonnements distincts pour la production et les tests.
• Un locataire est le répertoire des utilisateurs et des identités de votre organisation, dans Microsoft Entra ID. Quand vous exécutez az login, vous vous connectez comme utilisateur d’un locataire. Un locataire peut avoir plusieurs abonnements.

AWS et Google Cloud ont les mêmes concepts sous d’autres noms (un compte ou un projet, avec des étiquettes ou dossiers). La règle est la même partout : placez un déploiement d’exercice dans un seul conteneur que vous pouvez supprimer d’un coup.

Voici la première commande de l’exécution réelle du module 5. Elle crée le groupe dans une région, avec deux étiquettes. Vous choisissez ces étiquettes sous forme de paires name=value (nom=valeur); la leçon 3 les utilise :

Terminal (Module 5, do not run it now)

az group create --name rg-ticket-api-practice --location canadacentral --tags purpose=practice course=C18 -o table

La sortie (réelle) :

Location       Name
-------------  ----------------------
canadacentral  rg-ticket-api-practice

Exemple détaillé : la conception minimale d’Amira

Amira associe chaque besoin de sa liste au plus petit service de base qui y répond. Elle note la raison de chaque choix :

Besoin	Service de base	Ressource Azure dans l’exercice	Pourquoi ce choix
Exécuter le conteneur à partir de l’image	Conteneurs sans serveur	Application conteneurisée ticket-api dans l’environnement cae-ticket-api	Elle exécute la même image. Elle peut descendre à zéro copie et ne coûte donc rien quand personne ne l’utilise.
Un endroit pour l’image	Registre de conteneurs	ticketapi4821 (Basic)	Le nuage ne peut pas lire les images sur son ordinateur. Le nom du registre doit être unique dans tout Azure.
Une adresse HTTPS publique	Entrée HTTPS	L’entrée de l’application, externe, avec le port cible 8000	La plateforme fournit HTTPS sans qu’Amira ait son propre certificat.
Les paramètres	Configuration de l’application	Variables d’environnement de l’application	La même image, d’autres paramètres (module 3).
La clé d’API	Un secret	Un secret Container Apps, api-key (Key Vault est facultatif)	La clé ne doit jamais être dans l’image ni dans un paramètre ordinaire. Leçon 2.
L’autorisation de récupérer l’image	Une identité	Identité gérée id-ticket-api avec le rôle AcrPull	Aucun mot de passe à stocker. Leçon 2.
Les journaux	Un magasin de journaux	L’espace de travail Log Analytics	L’environnement en crée un automatiquement. La leçon 3 explique pourquoi cela compte pour les coûts.
Les enregistrements de l’historique	PostgreSQL géré	Aucun pour l’exercice	Un serveur de base de données coûte de l’argent pour chaque heure où il existe. Sans DATABASE_URL, l’API fonctionne avec l’historique désactivé.

La dernière ligne est une décision, pas un oubli. L’API a été conçue pour cela dans le module 3. Sans base de données, la classification fonctionne toujours, et /v1/history répond 503 avec history_unavailable (historique indisponible). Un vrai service ajouterait un serveur PostgreSQL géré et fournirait son DATABASE_URL à l’application comme secret.

La conception Azure minimale pour l'API de billets. Tout se trouve dans un seul groupe de ressources. Les lignes et contours bleus représentent ce que vous configurez et gérez; Azure gère l'environnement et l'entrée en gris.

Description textuelle du diagramme

Deux éléments sont à l’extérieur d’Azure : votre ordinateur et les clients. Votre ordinateur construit l’image et envoie ticket-api:1.1.0 au registre ticketapi4821. Les clients, comme le système du service de soutien ou curl, envoient des requêtes HTTPS avec l’en-tête X-API-Key. Tout le reste se trouve dans le groupe de ressources rg-ticket-api-practice, dans la région canadacentral. Les requêtes passent par l’entrée HTTPS, que l’environnement Container Apps cae-ticket-api gère. L’entrée accepte HTTPS sur le port 443 et transmet les requêtes au port 8000 de l’application conteneurisée ticket-api. L’application exécute de 0 à 2 copies du conteneur et possède un secret, api-key. Pour obtenir son image, l’application utilise l’identité gérée id-ticket-api. Cette identité possède une autorisation, AcrPull, sur ce registre seulement. Facultativement, la même identité peut lire le secret dans le Key Vault kv-ticket-api-4821. L’environnement envoie les journaux de l’application à un espace de travail Log Analytics, qu’il a créé automatiquement. Vous gérez l’image et ses paquets, les paramètres, le secret, l’identité et son rôle, les limites de mise à l’échelle et le nettoyage. Azure gère les serveurs et leur système d’exploitation, le certificat HTTPS, le démarrage et l’arrêt des copies. Il gère aussi le stockage des images et des journaux.

Lors de l’exécution réelle, après la création du registre, de l’identité et de l’environnement, le groupe contenait ces ressources. Voici la sortie de az resource list -g rg-ticket-api-practice -o table (réelle, avant la création de l’application conteneurisée) :

Name                               ResourceGroup           Location       Type                                              Status
---------------------------------  ----------------------  -------------  ------------------------------------------------  ---------
ticketapi4821                      rg-ticket-api-practice  canadacentral  Microsoft.ContainerRegistry/registries            Succeeded
id-ticket-api                      rg-ticket-api-practice  canadacentral  Microsoft.ManagedIdentity/userAssignedIdentities  Succeeded
workspace-rgticketapipracticeXXXX  rg-ticket-api-practice  canadacentral  Microsoft.OperationalInsights/workspaces          Succeeded
cae-ticket-api                     rg-ticket-api-practice  canadacentral  Microsoft.App/managedEnvironments                 Succeeded

Prédisez : quelle ligne représente une ressource qu’Amira n’a pas demandée? L’espace de travail. az containerapp env create a affiché No Log Analytics workspace provided. (aucun espace de travail Log Analytics fourni) et en a créé un. Avec l’application conteneurisée, le groupe possède cinq ressources, ou six avec le Key Vault facultatif.

Exercice guidé : associer les besoins aux services

Vous préparez la conception que le module 5 met en œuvre. Écrivez vos réponses dans un fichier texte ou sur papier. Vous les mettrez dans docs/cloud-design.md à la leçon 3.

1. Ouvrez compose.yaml et le tableau des paramètres dans README.md, dans ~/projects/ticket-api.
2. Listez tout ce que l’API utilise pendant son exécution : le conteneur, le port, chaque paramètre, le secret, la base de données et les journaux.
3. Pour chaque élément, écrivez le type général de service de base tiré du tableau dans Types de services.
4. Indiquez pour chacun « nécessaire pour l’exercice » ou « non nécessaire pour l’exercice », avec une raison.
5. Écrivez la région que vous utiliseriez et une raison de la choisir. Vérifiez qu’Azure Container Apps est offert dans cette région.
6. Écrivez le nom du groupe de ressources qui contient tout.

Afficher un exemple de réponse

Ce que l’API utilise	Type de service de base	Pour l’exercice?
Le conteneur provenant de ticket-api:1.1.0	Conteneurs sans serveur et registre de conteneurs pour l’image	Nécessaire
Port 8000	Entrée HTTPS vers le port cible 8000	Nécessaire : les clients doivent pouvoir y accéder
REQUIRE_API_KEY=true, SHOW_DOCS=false	Paramètres dans la configuration de l’application	Nécessaires
API_KEY	Un secret	Nécessaire : REQUIRE_API_KEY=true empêche l’application de fonctionner sans lui
DATABASE_URL et PostgreSQL	PostgreSQL géré	Non nécessaires : l’historique est désactivé, et un serveur de base de données est facturé à l’heure
ALLOWED_ORIGINS	Un paramètre	Non nécessaire : le système de soutien ne fait pas d’appels depuis un navigateur
Journaux	Un stockage de journaux	Nécessaire pour vérifier le déploiement (module 5)

Région : canadacentral pour le cours, ou la région la plus proche de vous qui offre Container Apps, par exemple westeurope en Europe. Groupe de ressources : rg-ticket-api-practice.

À vous de jouer : des données qui doivent rester en Europe

Le service de soutien déménage en Allemagne. Ses billets contiennent les noms des clients, et l’entreprise exige que les données des billets restent dans l’UE. Modifiez votre conception pour respecter cette condition. Quelle région choisissez-vous? Quelles ressources doivent s’y trouver?

Afficher une réponse

Choisissez une région dans la zone géographique Europe, par exemple germanywestcentral ou westeurope, et vérifiez que Container Apps y est offert. Chaque ressource qui conserve ou traite les données des billets doit se trouver dans cette région. Cela comprend l’application conteneurisée et sa base de données, si vous en ajoutez une. Les journaux comptent aussi. L’espace de travail conserve tout ce que l’application écrit. L’API de billets consigne la méthode, le chemin, le statut et un identifiant de requête, mais pas le texte du billet. Ce choix de conception vient du cours Créer et déployer votre première API et du module 3, et il aide ici. Placez tout le groupe de ressources, avec son registre et son espace de travail, dans la même région. Vous n’avez alors pas besoin de vérifier chaque ressource.

Erreur courante

La conception conserve l'historique dans le conteneur

Symptôme : Lors d’une révision de conception, un collègue propose d’éviter la base de données. Il veut écrire l’historique dans un fichier du conteneur. « L’application fonctionne tout le temps de toute façon. »

Cause : Les fichiers d’un conteneur sont temporaires. Vous l’avez démontré au module 3 : après docker compose up -d --force-recreate api, le fichier avait disparu (cat: /tmp/note.txt: No such file or directory, soit « aucun fichier ou dossier de ce nom »). Dans le nuage, cela arrive plus souvent. Chaque nouvelle révision lance de nouveaux conteneurs à partir de l’image. L’application passe à zéro instance, puis redémarre. Avec 2 réplicas, chacun possède ses propres fichiers. Deux requêtes peuvent donc voir deux historiques différents.

Solution :

1. Conservez les enregistrements dans une base de données gérée, par exemple un serveur flexible Azure Database for PostgreSQL. Donnez son adresse à l’application dans DATABASE_URL, sous forme de secret.
2. Conservez les fichiers, comme les fichiers téléversés ou les fichiers de modèles, dans un stockage d’objets (Blob Storage).
3. Utilisez les fichiers du conteneur uniquement pour ce qui peut être perdu, comme un cache.

Pour un vrai service d’IA, la même règle protège les données coûteuses. Les prédictions, les commentaires des utilisateurs et les fichiers de modèles doivent survivre à tous les conteneurs.

Vérifiez votre compréhension

Nommez quatre raisons de bien choisir une région et donnez un exemple pour chacune.

Afficher la réponse

Distance : une région près des utilisateurs répond plus vite, car chaque requête fait l’aller-retour. Résidence des données : une loi ou un contrat peut exiger que les données des clients restent dans un pays ou dans l’UE. Vous choisissez alors une région dans cette zone géographique. Prix : le même service peut coûter un montant différent dans une autre région. Disponibilité : tous les services ne sont pas offerts dans toutes les régions. Par exemple, l’abonnement du cours pouvait utiliser des machines virtuelles dans Israel Central, mais pas Container Apps.

Vérifiez votre compréhension

L'API de billets fonctionne dans des conteneurs sans serveur. Un correctif de sécurité paraît pour une bibliothèque de Debian 13. Qui l'installe, et comment?

Afficher la réponse

Vous l’installez. Le fournisseur applique les correctifs à ses propres serveurs, mais les paquets Debian sont dans votre image. Cette image reste la vôtre sur toutes les plateformes. Vous reconstruisez l’image à partir de l’image de base mise à jour, exécutez les tests, poussez la nouvelle étiquette et la déployez. Sans serveur ne signifie pas que personne n’a rien à entretenir. Cela signifie que vous n’entretenez plus les serveurs.

Vérifiez votre compréhension

Pourquoi l'exercice place-t-il toutes les ressources dans un seul groupe de ressources?

Afficher la réponse

Un groupe de ressources est un dossier pour des ressources qui ont le même cycle de vie. Quand vous supprimez le groupe, Azure supprime toutes les ressources qu’il contient. Cela inclut celles que vous n’avez pas créées vous-même, comme l’espace de travail Log Analytics créé par l’environnement. Un seul groupe donne un inventaire clair et une seule commande pour tout supprimer. La leçon 3 et le module 5 montrent la seule exception : un Key Vault supprimé conserve son nom pendant 90 jours.

Récapitulatif

• Partez des besoins du service : exécuter une image, avoir une adresse publique, des paramètres, un secret, des journaux et peut-être une base de données. Chaque nuage offre un service de base pour chacun.
• Une région est l’endroit où les ressources s’exécutent et conservent leurs données. Choisissez-la selon la distance, la résidence des données, le prix et les services offerts.
• Sans serveur signifie que le fournisseur gère les serveurs et démarre et arrête votre application. Votre image, ses paquets, vos paramètres, vos identités et votre nettoyage restent votre responsabilité.
• Un groupe de ressources contient des ressources qui ont le même cycle de vie. Supprimez le groupe, et tout son contenu disparaît.
• La conception de l’exercice comprend cinq ressources : un registre, une identité, un environnement avec son espace de travail de journaux automatique et l’application conteneurisée. Un Key Vault est facultatif. La base de données est volontairement exclue.

Ensuite, vous donnez une identité à l’application plutôt qu’un mot de passe, et vous décidez où conserver son secret.

Leçon suivante : Identité et secrets