Déploiement en production - Docker & Cloud

Bienvenue ! Ici Darwin avec la dernière leçon du Module 6 - déployer FastAPI en production !

Sur ton ordinateur, la Safari API tourne parfaitement. Un collègue la lance chez lui et obtient une erreur, parce qu'il a une autre version de Python, et le serveur dans le cloud n'a pas encore PostgreSQL. Le fameux "ça marche chez moi" est le problème le plus courant lors d'un premier déploiement, et Docker le résout en emballant l'application avec tout son environnement.

Analogie safari : Le déploiement, c'est comme ouvrir un parc de safari au public - il faut garantir la sécurité, la scalabilité et une fiabilité 24h/24 et 7j/7 ! Un conteneur, lui, c'est un sac d'expédition bouclé : dans chaque camp, tu déballes exactement le même équipement.

Un Dockerfile pour FastAPI

Une image Docker est un paquet prêt à l'emploi avec le système, Python, les dépendances et le code, et un conteneur est une copie en cours d'exécution d'une image. On écrit la recette de l'image dans un fichier Dockerfile. La première partie choisit la base et installe les dépendances :

1# Dockerfile
2FROM python:3.11-slim
3
4WORKDIR /app
5
6COPY requirements.txt .
7RUN pip install --no-cache-dir -r requirements.txt

FROM désigne l'image de base - la variante slim est bien plus légère que la version complète. WORKDIR définit le répertoire de travail. Remarque qu'on copie d'abord uniquement requirements.txt : Docker mémorise chaque étape comme une couche, donc tant que la liste des dépendances ne change pas, l'installation des paquets vient du cache lors des constructions suivantes. --no-cache-dir empêche pip de laisser les archives téléchargées dans l'image.

La deuxième partie copie le code et indique comment lancer l'application :

1COPY . .
2
3CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

COPY . . apporte le reste du projet - ajoute un fichier .dockerignore pour que .venv, .git et les secrets n'y atterrissent pas. --host 0.0.0.0 est indispensable : la valeur par défaut 127.0.0.1 n'accepterait que les connexions venant de l'intérieur du conteneur. Écrire CMD sous forme de liste JSON (exec form) permet à uvicorn de recevoir directement le signal d'arrêt et de s'éteindre proprement.

Tu construis et lances l'image avec deux commandes :

1docker build -t safari-api .
2docker run -p 8000:8000 safari-api

-t donne un nom à l'image, et le point désigne le répertoire courant avec le Dockerfile. -p 8000:8000 relie le port de ton ordinateur à celui du conteneur, donc l'API répond sur http://localhost:8000.

docker-compose.yml

L'application a encore besoin d'une base de données. Docker Compose décrit dans un seul fichier plusieurs services qui démarrent ensemble. D'abord le service de l'API :

1version: '3.8'
2
3services:
4  api:
5    build: .
6    ports:
7      - "8000:8000"
8    environment:
9      - DATABASE_URL=postgresql+asyncpg://user:password@db/safari
10    depends_on:
11      - db

build: . construit l'image à partir de notre Dockerfile. On passe l'adresse de la base par une variable d'environnement, et le nom d'hôte db est tout simplement le nom du second service : Compose crée un réseau dans lequel les services se voient par leur nom. La ligne version est aujourd'hui obsolète : la spécification actuelle de Compose l'ignore et affiche un avertissement, tu peux donc l'omettre dans les nouveaux fichiers.

Voici maintenant la base et le volume :

1  db:
2    image: postgres:15
3    environment:
4      - POSTGRES_USER=user
5      - POSTGRES_PASSWORD=password
6      - POSTGRES_DB=safari
7    volumes:
8      - postgres_data:/var/lib/postgresql/data
9
10volumes:
11  postgres_data:

Le volume postgres_data conserve les fichiers de la base en dehors du conteneur, donc les données survivent à sa suppression. depends_on fixe seulement l'ordre de démarrage, il n'attend pas que PostgreSQL soit prêt à accepter des connexions : l'application doit savoir réessayer, ou tu peux ajouter un healthcheck.

Lance :

Tout démarre avec une seule commande, et -d lance l'ensemble en arrière-plan :

1docker-compose up -d

Dans les installations récentes de Docker, Compose est un plugin et tu tapes docker compose up -d, avec une espace au lieu d'un tiret. Je te recommande cette forme, car l'ancien programme autonome docker-compose n'est plus développé.

La checklist de production

• Variables d'environnement (DATABASE_URL, SECRET_KEY)
• Certificats HTTPS/TLS
• Configuration CORS
• Rate limiting (limitation du débit)
• Logging & monitoring
• Migrations de base de données (Alembic)
• Stratégie de sauvegarde
• Load balancer (répartiteur de charge)

Chaque point protège contre un problème différent : les secrets dans des variables d'environnement ne fuiront pas depuis le dépôt, et Alembic modifie la structure de la base sans SQL écrit à la main. Les mots de passe du fichier Compose ci-dessus ne conviennent qu'à l'apprentissage.

Déployer sur Render/Railway

Les plateformes PaaS construisent et lancent le conteneur à ta place. Il suffit de connecter le dépôt :

Render :

1. Pousse sur GitHub
2. Connecte le dépôt sur Render
3. Ajoute les variables d'environnement
4. Déploiement automatique !

Railway :

1. railway init
2. railway up
3. Terminé !

railway init et railway up sont des commandes de la ligne de commande Railway : la première crée un projet, la seconde envoie le code et le déploie. Vérifie les détails, comme les réglages de port requis, dans la documentation de la plateforme choisie.

Récapitulatif du Module 6

Félicitations ! Tu as terminé le Module 6 : FastAPI !

Tu as appris :

• Les fondamentaux d'async/await
• Les bases de FastAPI et les endpoints
• La validation Pydantic
• Les bases de données async (SQLAlchemy)
• L'authentification JWT
• Les tests avec pytest
• Le déploiement en production (Docker)

La Safari Database API a maintenant tout ce qu'il faut pour un premier déploiement : validation, base de données, authentification, tests et conteneur. Le nombre de requêtes par seconde qu'elle pourra gérer dépend du serveur et de la base, alors mesure-le toujours avant un gros trafic.

Darwin est fier de toi ! Le Module 7 approfondit le DevOps : tests, qualité du code, Docker, CI/CD, cloud et monitoring.

Retiens : un conteneur, c'est un sac d'expédition bouclé - ce qui a marché au camp d'entraînement marchera dans chaque savane.