Vérifier et nettoyer

Ce que vous saurez faire

Prouvez que l’API déployée fonctionne avec les mêmes vérifications que sur votre ordinateur. Envoyez une requête valide, une requête invalide et une requête dont une dépendance échoue de façon contrôlée. Ensuite, supprimez tout ce que vous avez créé. Ainsi, rien ne continue à fonctionner ou ne reste accessible à un usage abusif.

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

Ce que vous devez savoir

• Les valeurs locales et partagées dans Postman, dans Collections, variables et environnements : valeurs locales et valeurs partagées.
• Le paramètre CLASSIFIER_MODE, dans Configuration et journalisation : un seul endroit pour tous les paramètres, et l’identifiant de requête dans les journaux, dans Configuration et journalisation : un identifiant pour chaque requête.

Ce qu’il vous faut sur votre ordinateur

• L’API déployée, avec API_KEY comme secret, dans Publier en toute sécurité : étape 3 : déployer. Il vous faut son adresse, affichée par fastapi deploy.
• Sa clé, copiée dans Publier en toute sécurité : étape 2 : une nouvelle clé, stockée comme secret. Si vous l’avez perdue, définissez-en une nouvelle comme dans cette étape, mais sans --no-redeploy. L’application redémarrera ainsi avec la nouvelle clé.
• Le dossier du projet lié à l’application par .fastapicloud/cloud.json, dans Publier en toute sécurité : étape 1 : se connecter et créer l’application.
• La collection dans postman, avec la requête /ready, dans Publier en toute sécurité : exercice guidé : publier l’API.
• L’environnement Deployed (déployé) dans Postman, dans Collections, variables et environnements : exemple détaillé : deux environnements Postman.
• L’interface en ligne de commande (CLI) de Postman, dans Tests et exécutions reproductibles : exécuter depuis le terminal : Postman CLI.
• README.md dans le projet, dans Environnement et premier point de terminaison : étape 5 : un README pour le projet. Cette leçon y ajoute une section.
• Si votre projet manque ou ne fonctionne plus, copiez l’instantané end-of-m06, le projet à la fin du module 6, comme dans Utiliser un instantané. Refaites ensuite les exercices guidés de Premiers pas avec l’hébergement et de Publier en toute sécurité. Pour utiliser la collection dans l’application Postman, importez les fichiers de postman/ (Import, importer). Un instantané ne contient ni application déployée ni clé.

Les étapes suivent la documentation de FastAPI Cloud et l’aide de fastapi-cloud-cli 0.26. Les étapes de la CLI de Postman ont été testées avec la version 1.69.0.

Une vérification rapide

Une vérification rapide est un court ensemble de requêtes envoyées juste après un déploiement. Elle montre que les principaux parcours fonctionnent : la fumée signale un feu. Elle ne teste pas chaque détail. C’est le travail de pytest, avant le déploiement. Elle répond à une question : ce déploiement, sur ce serveur, avec ces paramètres, fonctionne-t-il?

Votre collection Postman constitue une bonne vérification rapide. Elle envoie un billet de soutien valide, des billets invalides et une requête sans clé, puis vérifie /health. Il vous faut seulement un environnement Postman qui pointe vers le serveur.

Exemple détaillé : l’environnement Deployed

Dans Postman, Amira ouvre l’environnement Deployed du module 5 :

1. Elle définit baseUrl avec l’adresse de son application, par exemple https://ticket-api.fastapicloud.dev (sans / à la fin).
2. Elle colle la clé déployée dans la local value (valeur locale) de apiKey. La valeur partagée reste vide.
3. Elle choisit Deployed dans le sélecteur d’environnement et envoie Check that the service runs (vérifier que le service fonctionne) : 200.
4. Elle exporte l’environnement dans postman/deployed.postman_environment.json et vérifie que apiKey est vide dans le fichier. L’adresse n’est pas un secret, elle peut donc rester.

Depuis le terminal, elle fournit la clé à la commande sans la saisir dans la ligne de commande :

macOS

read -s TICKET_API_KEY
curl -s https://ticket-api.fastapicloud.dev/health
postman collection run postman/ticket-api.postman_collection.json -e postman/deployed.postman_environment.json --env-var "apiKey=$TICKET_API_KEY"

Windows

$TICKET_API_KEY = Read-Host "API key"
curl.exe -s https://ticket-api.fastapicloud.dev/health
postman collection run postman/ticket-api.postman_collection.json -e postman/deployed.postman_environment.json --env-var "apiKey=$TICKET_API_KEY"

Linux

read -s TICKET_API_KEY
curl -s https://ticket-api.fastapicloud.dev/health
postman collection run postman/ticket-api.postman_collection.json -e postman/deployed.postman_environment.json --env-var "apiKey=$TICKET_API_KEY"

read -s attend qu’elle colle la clé, sans l’afficher (-s signifie « silencieux »). Read-Host fait la même chose dans PowerShell, mais affiche ce que vous collez. Aucune des deux commandes n’enregistre la clé dans l’historique du terminal. La clé est saisie comme entrée, pas comme partie d’une commande.

La commande curl vers /health réveille d’abord l’application. Avec le forfait Hobby, une application sans requêtes depuis un certain temps s’arrête (scale to zero, réduction à zéro). La première requête la redémarre, ce qui prend quelques secondes. Sans cette étape, le test « answers in under 500 ms » (répond en moins de 500 ms) peut échouer à la première requête. La cause n’est pas un bogue.

L’exécution se termine comme l’exécution locale : 8 requêtes, tous les tests réussis, code de sortie 0. La même collection, les mêmes tests, un environnement différent.

Une panne contrôlée sur le serveur

Dernière vérification du module : l’API déployée doit gérer une dépendance en panne aussi bien que l’API locale. Amira simule cette panne avec le paramètre du module 6. Définir une variable redéploie l’application avec cette variable :

Terminal

fastapi cloud env set CLASSIFIER_MODE unavailable

Quand le nouveau déploiement est prêt, elle appelle les deux points de terminaison de santé et envoie un billet avec sa clé :

Requête	Résultat attendu
GET /health	200 : le processus fonctionne
GET /ready	503 {"error":{"code":"classifier_unavailable",...}}
POST /v1/classify avec la clé	503, le même code, avec un identifiant de requête, sans détails internes

L’exécution de la collection échoue maintenant sur Classify a support ticket (classer un billet de soutien), avec le code de sortie 1. C’est le résultat attendu. Elle retire ensuite le paramètre, ce qui redéploie le classificateur normal, puis relance la collection : tous les tests réussissent.

Terminal

fastapi cloud env delete CLASSIFIER_MODE

Lire les journaux de la plateforme

L’application écrit les mêmes lignes de journal que sur votre ordinateur. La plateforme les conserve pendant 1 jour avec le forfait Hobby. Pour voir les lignes récentes :

Terminal

fastapi cloud logs --no-follow --since 10m

Sans --no-follow, la commande affiche les nouvelles lignes à mesure qu’elles arrivent, jusqu’à ce que vous appuyiez sur Ctrl+C. Chaque requête possède sa ligne provenant de votre intergiciel, par exemple :

A line from your app

INFO ticket_api: POST /v1/classify 503 2ms id=5d0b7e1c94aa

Pour examiner un problème, prenez le request_id du corps de l’erreur et cherchez-le dans les journaux. Sur macOS et Linux : fastapi cloud logs --no-follow --since 1h | grep 5d0b7e1c94aa. Dans PowerShell, utilisez Select-String 5d0b7e1c94aa au lieu de grep.

Documenter l’adresse

Une API déployée que personne ne peut trouver n’est pas terminée. Ajoutez une courte section au README du projet :

README.md (add)

## Deployed practice service

- Address: https://ticket-api.fastapicloud.dev (deleted after the course)
- Smoke check:

  ```sh
  postman collection run postman/ticket-api.postman_collection.json -e postman/deployed.postman_environment.json --env-var "apiKey=<the key>"
  ```

- The API key is not in this project. Ask the owner, or set a new one with
  `fastapi cloud env set API_KEY --secret --value-stdin`.

Nettoyer

Quand vous avez vos preuves, supprimez le service d’exercice. Le forfait Hobby ne vous facture rien, mais un service que personne ne surveille reste un risque. Une clé divulguée plus tard fonctionne encore, et le service utilise toujours une de vos 3 applications.

1. Ouvrez le tableau de bord de FastAPI Cloud et sélectionnez l’application. Trouvez l’option de suppression dans ses paramètres. Confirmez.
2. Dans le dossier du projet, retirez le lien vers l’application supprimée : fastapi cloud unlink. Cette commande supprime .fastapicloud/cloud.json.
3. Dans Postman, supprimez la valeur locale de apiKey dans l’environnement Deployed.
4. Vérifiez que le service a disparu : curl -i https://ticket-api.fastapicloud.dev/health ne renvoie plus 200.
5. Dans le README, indiquez que l’adresse a été supprimée.

La clé elle-même ne fonctionne plus, car le service qui la vérifiait a disparu. C’est la façon la plus sûre d’empêcher tout usage abusif d’une clé d’exercice.

Exercice guidé : vérifier et nettoyer

1. Configurez l’environnement Deployed dans Postman et exportez-le dans postman/, sans la clé.
2. Réveillez l’application avec /health, puis exécutez la collection depuis le terminal avec l’environnement Deployed. Tous les tests réussissent.
3. Définissez CLASSIFIER_MODE à unavailable. Vérifiez /health (200), /ready (503) et une requête de classification avec la clé (503). Exécutez la collection : elle échoue sur la requête de classification, avec le code de sortie 1.
4. Retrouvez cette requête de classification dans les journaux grâce à son identifiant de requête.
5. Supprimez CLASSIFIER_MODE et relancez la collection. Tous les tests réussissent.
6. Ajoutez la section sur le déploiement au README.
7. Supprimez l’application, dissociez le dossier et retirez la clé de Postman. Vérifiez que l’adresse ne répond plus.

À vous de jouer : une vérification rapide reproductible

Écrivez un court script, smoke-check.sh (macOS et Linux) ou smoke-check.ps1 (Windows). Il effectue dans l’ordre les étapes 2 et 3 d’une vérification de déploiement. Il réveille l’application avec /health, puis exécute la collection avec l’environnement Deployed. Il se termine avec le code de sortie de l’exécution de la collection. La clé provient d’une variable d’environnement que la personne définit avant l’exécution, jamais du fichier.

Que doit faire le script si TICKET_API_KEY n’est pas définie?

Afficher une réponse pour macOS et Linux

smoke-check.sh

#!/bin/sh
# Smoke check for the deployed ticket API. Set TICKET_API_KEY first.
set -e
if [ -z "$TICKET_API_KEY" ]; then
  echo "Set TICKET_API_KEY first (read -s TICKET_API_KEY)." >&2
  exit 2
fi
BASE_URL="https://ticket-api.fastapicloud.dev"
curl -s -o /dev/null "$BASE_URL/health"
postman collection run postman/ticket-api.postman_collection.json \
  -e postman/deployed.postman_environment.json \
  --env-var "apiKey=$TICKET_API_KEY"

Sans la clé, le script s’arrête immédiatement avec un message clair et le code de sortie 2 (commande incorrecte). Il n’exécute pas la collection pour ensuite signaler sept échecs 401 difficiles à comprendre. Exécutez-le avec sh smoke-check.sh. set -e arrête le script dès qu’une commande échoue. Le code de sortie de la dernière commande devient celui du script. Une vérification échouée fait donc échouer le script. Le cours CI/CD, tests et mises en production sûres exécute automatiquement une telle vérification après chaque déploiement.

Erreur courante

Seul le test du temps de réponse échoue, et seulement à la première exécution

Symptôme : l’exécution de la collection déployée échoue à un test, answers in under 500 ms (répond en moins de 500 ms), à la première requête. Relancez-la une minute plus tard : tout réussit.

Cause : scale to zero. L’application était arrêtée parce que personne ne l’utilisait. La première requête a dû attendre son démarrage. L’API n’est pas lente. Elle était inactive.

Solution :

1. Réveillez l’application avec une requête vers /health avant l’exécution, comme dans l’exemple détaillé.
2. Gardez une limite de temps stricte pour l’application déjà démarrée, car elle détecte les véritables lenteurs.
3. Pour que la première requête soit aussi rapide, un forfait payant peut garder au moins une copie de l’application active. C’est une décision de coût, pas une modification du code.

Vérifiez votre compréhension

Pourquoi la vérification rapide utilise-t-elle la collection Postman plutôt que pytest sur le serveur?

Afficher la réponse

Les tests de pytest utilisent TestClient, qui exécute l’application en mémoire sur votre ordinateur. Ils testent le code, pas le déploiement, et ne peuvent pas joindre un serveur. La collection envoie de vraies requêtes HTTPS à la véritable adresse, via la plateforme, avec les vrais paramètres et secret. Ce sont les éléments qui peuvent échouer dans un déploiement. C’est donc ce qu’une vérification rapide doit tester. Les deux sont nécessaires : pytest avant le déploiement, la collection après.

Vérifiez votre compréhension

Vérification du module : nommez les trois vérifications qui prouvent le déploiement, avec le code d'état attendu de chacune. Indiquez d'où chacune provient dans le cours.

Afficher la réponse

Une requête réussie : POST /v1/classify avec la clé et un billet valide renvoie 200 avec la classification (modules 2 et 6). Une requête invalide : un objet vide renvoie 422 avec invalid_request et "fields": ["subject"]. Une requête sans clé renvoie 401 (modules 3 et 6). Une panne contrôlée de dépendance : avec CLASSIFIER_MODE=unavailable, /ready et la classification renvoient 503 avec classifier_unavailable et un identifiant de requête. Pendant ce temps, /health reste à 200 (modules 6 et 7). La collection Postman avec l’environnement Deployed montre les deux premières vérifications. La troisième se démontre en définissant la variable sur le serveur.

Récapitulatif

• Une vérification rapide après chaque déploiement répond à la question : ce déploiement fonctionne-t-il? La collection Postman avec un environnement Deployed constitue cette vérification.
• Fournissez la clé à la CLI par une entrée (read -s, Read-Host), jamais dans une commande ou un fichier.
• Réveillez une application réduite à zéro avant un test chronométré.
• Montrez une panne contrôlée sur le serveur avec un paramètre, puis retirez ce paramètre.
• Retrouvez une requête dans les journaux de la plateforme grâce à son identifiant de requête.
• Documentez l’adresse. Supprimez les services d’exercice quand vous avez terminé et retirez leurs clés.

Vous avez créé une API, de la première requête à un service déployé, documenté, testé et protégé. Viennent ensuite deux études de cas : des projets complets sur des données réelles qui utilisent tout le cours. Terminez-en au moins une pour obtenir le certificat. Le travail final vous demande ensuite de modifier votre API comme le ferait une vraie équipe. Vous ajouterez un point de terminaison, du contrat au déploiement.

Leçon suivante : Servir un modèle de prix des maisons