Dockeriser votre blog Flask : Guide complet + deploiement Fly.io

Fred· Developer & Technical Writer8 min read

Derniere verification : Octobre 2025 | Docker : 24.x | Flask : 3.0.0 | PostgreSQL : 15 | Python : 3.11

Le deploiement est frustrant. Vous faites fonctionner parfaitement votre app Flask sur votre machine, puis passez des heures a vous battre avec la configuration du serveur, les versions de Python et les dependances manquantes quand vous essayez de la deployer. Docker resout ca en empaquetant tout ce dont votre app a besoin dans un conteneur qui fonctionne de la meme facon partout.

Ce guide vous montre comment containeriser un blog Flask et le deployer sur Fly.io. Le processus entier prend environ 15 minutes une fois que vous savez ce que vous faites. Pas de configuration de serveur, pas d'enfer des dependances, juste votre app qui tourne en production.

A qui s'adresse ce guide

Si vous avez une app Flask qui fonctionne localement et que vous voulez la deployer sans les maux de tete habituels, c'est pour vous. Peut-etre que vous en avez assez de deboguer pourquoi quelque chose fonctionne sur votre laptop mais casse en production. Peut-etre que vous voulez utiliser des pratiques de deploiement modernes sans passer des semaines a apprendre le DevOps.

Vous aurez besoin de connaissances basiques en Python et Flask. Si vous avez deja construit une app Flask, vous etes pret. Vous devriez etre a l'aise avec la ligne de commande, et vous aurez besoin de Docker Desktop installe. C'est tout.

A la fin, vous aurez un developpement local qui correspond exactement a la production, des deploiements qui prennent des minutes au lieu d'heures, et plus de conflits de version Python.

Pourquoi Docker aide

Docker a mauvaise reputation pour etre complexe, mais l'idee de base est simple : c'est une boite pour votre code. Votre app va dans la boite avec tout ce dont elle a besoin pour fonctionner. Cette boite fonctionne de la meme facon sur votre laptop, sur les serveurs CI et en production.

Cette coherence elimine des categories entieres de bugs. Plus de discussions "mais ca marche sur ma machine". Plus de decouvrir que la production a Python 3.8 quand vous avez developpe sur 3.11. Plus de bibliotheques systeme manquantes que vous avez oublie de documenter.

Le vrai gain c'est la vitesse de deploiement. Une fois que vous avez une configuration Docker fonctionnelle, deployer devient trivial. Poussez votre code, construisez l'image, deployez. Les rollbacks sont tout aussi faciles : redeployez l'image precedente et vous etes de retour en quelques secondes.

Ce que nous construisons

Nous allons prendre votre blog Flask existant et le containeriser correctement. Vous aurez le developpement local avec rechargement a chaud pour voir les changements instantanement. Nous utiliserons PostgreSQL parce que SQLite n'est pas fait pour la production, peu importe ce qu'on vous dit. Puis nous deploierons le tout sur Fly.io parce qu'ils ont un palier gratuit genereux et executent vos conteneurs Docker tels quels.

Preparer votre app Flask

D'abord, corrigeons votre requirements.txt. Si le votre dit juste "Flask" sans numero de version, vous cherchez les ennuis. Voici ce dont vous avez besoin pour la production :

Flask==3.0.0
Flask-SQLAlchemy==3.1.1
Flask-Migrate==4.0.5
psycopg2-binary==2.9.9
python-dotenv==1.0.0
gunicorn==21.2.0

Le serveur integre de Flask est uniquement pour le developpement. Gunicorn est un serveur WSGI pret pour la production qui peut gerer du vrai trafic. Le package psycopg2-binary vous permet de parler a PostgreSQL. Tout a des numeros de version parce que "Flask" sans version signifie que vous pourriez avoir differentes versions dans differents environnements, ce qui annule tout l'interet.

Creez un fichier wsgi.py comme point d'entree de votre application :

from app import create_app
import os

app = create_app()

if __name__ == "__main__":
    app.run(
        host="0.0.0.0",
        port=int(os.environ.get("PORT", 8080))
    )

Ce host="0.0.0.0" est important. Ca signifie "ecouter sur toutes les interfaces reseau". Le 127.0.0.1 par defaut n'ecoute que localement, ce qui ne fonctionne pas dans un conteneur. Ce petit detail a cause des heures de debogage pour beaucoup de developpeurs.

Votre config.py devrait utiliser des variables d'environnement pour tout ce qui est sensible :

import os
from dotenv import load_dotenv

basedir = os.path.abspath(os.path.dirname(__file__))
load_dotenv(os.path.join(basedir, '.env'))

class Config:
    SECRET_KEY = os.environ.get('SECRET_KEY') or 'dev-secret-key-change-in-production'

    SQLALCHEMY_DATABASE_URI = os.environ.get('DATABASE_URL') or \
        f'sqlite:///{os.path.join(basedir, "app.db")}'

    SQLALCHEMY_TRACK_MODIFICATIONS = False

    # Certains services utilisent postgres:// mais SQLAlchemy a besoin de postgresql://
    if SQLALCHEMY_DATABASE_URI.startswith("postgres://"):
        SQLALCHEMY_DATABASE_URI = SQLALCHEMY_DATABASE_URI.replace(
            "postgres://", "postgresql://", 1
        )

Ne jamais coder en dur les secrets. Utilisez les variables d'environnement. Votre futur vous vous remerciera quand vous ne committerez pas accidentellement votre mot de passe de base de donnees production sur GitHub.

Ecrire un Dockerfile qui fonctionne

Voici un Dockerfile qui fonctionne en production :

FROM python:3.11-slim as base

# Le buffering Python peut causer des problemes dans les conteneurs
ENV PYTHONUNBUFFERED=1 \
    PYTHONDONTWRITEBYTECODE=1 \
    PIP_NO_CACHE_DIR=1 \
    PIP_DISABLE_PIP_VERSION_CHECK=1

WORKDIR /app

# Installer les dependances systeme
RUN apt-get update && apt-get install -y \
    gcc \
    postgresql-client \
    && rm -rf /var/lib/apt/lists/*

# Copier requirements d'abord pour un meilleur caching
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY . .

# Creer un utilisateur non-root pour la securite
RUN useradd -m -u 1000 flaskuser && \
    chown -R flaskuser:flaskuser /app
USER flaskuser

EXPOSE 8080

CMD ["gunicorn", "--bind", "0.0.0.0:8080", "--workers", "2", "wsgi:app"]

L'ordre compte ici. Copier requirements.txt avant de copier votre code signifie que Docker peut mettre en cache la couche pip install. Quand vous changez votre code mais pas vos dependances, Docker reutilise la couche mise en cache avec tous vos packages deja installes. Ca transforme un rebuild de 5 minutes en un de 10 secondes.

Executer en tant qu'utilisateur non-root est une bonne pratique de securite. Si quelqu'un compromet votre app, il n'aura pas l'acces root au conteneur.

Docker Compose pour le developpement local

Docker Compose vous permet d'executer plusieurs conteneurs ensemble. Voici un docker-compose.yml qui configure votre app Flask avec PostgreSQL :

version: '3.8'

services:
  web:
    build: .
    ports:
      - "8080:8080"
    environment:
      - DATABASE_URL=postgresql://postgres:postgres@db:5432/flask_blog
      - SECRET_KEY=dev-secret-key
      - FLASK_ENV=development
    volumes:
      - .:/app  # Montez votre code pour le rechargement a chaud
    depends_on:
      - db
    command: flask run --host=0.0.0.0 --port=8080 --reload

  db:
    image: postgres:15-alpine
    environment:
      - POSTGRES_USER=postgres
      - POSTGRES_PASSWORD=postgres
      - POSTGRES_DB=flask_blog
    ports:
      - "5432:5432"
    volumes:
      - postgres_data:/var/lib/postgresql/data

volumes:
  postgres_data:

Le montage de volume (.:/app) signifie que les changements a votre code sont refletes immediatement sans reconstruire le conteneur. Le volume postgres_data garantit que votre base de donnees persiste meme quand vous arretez les conteneurs.

Tout executer

Construisez d'abord votre image :

docker-compose build

La premiere construction prend du temps car elle telecharge les images de base et installe les packages. Les constructions suivantes sont beaucoup plus rapides grace au caching de couches de Docker.

Demarrez la base de donnees :

docker-compose up -d db

Initialisez vos migrations de base de donnees si vous ne l'avez pas deja fait :

docker-compose run --rm web flask db init
docker-compose run --rm web flask db migrate -m "Initial migration"
docker-compose run --rm web flask db upgrade

Maintenant demarrez tout :

docker-compose up

Visitez localhost:8080 et votre blog devrait tourner. Si quelque chose ne va pas, les logs vous diront exactement quoi. Docker vous montre tout, ce qui est bien mieux que des echecs de production mysterieux sans messages d'erreur.

Deployer sur Fly.io

Fly.io execute votre veritable conteneur Docker, pas une version interpretee. Ils ont un palier gratuit qui ne necessite pas de carte de credit, ce qui est rafraichissant en 2025.

Installez d'abord leur CLI.

Sur Mac :

brew install flyctl

Sur Windows, telechargez l'installateur depuis leur site ou utilisez PowerShell :

pwsh -Command "iwr https://fly.io/install.ps1 -useb | iex"

Sur Linux :

curl -L https://fly.io/install.sh | sh

Lancez votre app avec flyctl launch. Quand on vous demande, donnez un nom a votre app (ou laissez-le generer un), choisissez une region proche de vous ou de vos utilisateurs, dites oui a PostgreSQL (choisissez development pour le palier gratuit), et dites non au deploiement immediatement parce que nous devons d'abord definir les secrets.

Definissez votre cle secrete :

flyctl secrets set SECRET_KEY=$(openssl rand -hex 32)

Deployez votre app :

flyctl deploy

Cela construit votre image Docker et la deploie. Prend environ 2 minutes. Quand c'est fait, executez vos migrations de base de donnees :

flyctl ssh console -C "flask db upgrade"

Ouvrez votre app deployee avec flyctl open. Vous avez maintenant une app Flask de production avec HTTPS, redemarrages automatiques et sauvegardes de base de donnees. Pas de configuration de serveur necessaire.

Construisez d'abord votre application Flask

Vous n'avez pas encore de blog Flask a dockeriser ? Commencez ici :

Chaque tutoriel inclut des prompts IA etape par etape pour vous guider dans la construction d'applications Flask prates pour la production. Une fois que vous avez construit votre app, revenez a ce guide pour la dockeriser et la deployer.

Maintenant allez construire quelque chose de cool.

Fred

Fred

AUTHOR

Full-stack developer with 10+ years building production applications. I've containerized dozens of production applications and learned these lessons the hard way.

Need a developer who gets it?

POC builds, vibe-coded fixes, and real engineering. Let's talk.

Hire Me →