Installer Python et un environnement virtuel

Debian 13 fournit Python 3.13, mais son installation système est protégée : pip install global est bloqué pour éviter de casser les outils du système. La bonne pratique est un environnement virtuel par application, avec ses dépendances épinglées, puis un service systemd qui démarre l'application avec ce Python précis.

Installer Python et venv

sudo apt update
sudo apt install -y python3 python3-venv python3-pip
python3 --version

python3-venv est un paquet séparé : sans lui, python3 -m venv échoue avec ensurepip is not available. Debian applique PEP 668 et refuse les installations globales avec pip, d'où l'erreur externally-managed-environment si vous essayez. Ne contournez pas cette protection avec --break-system-packages sur un serveur de production.

Créer l'environnement

Passez sous l'utilisateur de déploiement avant de créer le venv :

sudo mkdir -p /srv/app
sudo chown deploy:www-data /srv/app
sudo -iu deploy
cd /srv/app
python3 -m venv venv
source venv/bin/activate
python -m pip install --upgrade pip
pip install -r requirements.txt
deactivate

Après activation, which python doit pointer vers /srv/app/venv/bin/python. Épinglez les versions dans requirements.txt (flask==3.1.0) pour rendre le déploiement reproductible. Le dossier venv n'entre pas dans Git : il se recrée à partir du fichier de dépendances.

Service systemd

Créez /etc/systemd/system/app.service :

[Unit]
Description=Application Python
After=network.target

[Service]
User=deploy
Group=www-data
WorkingDirectory=/srv/app
EnvironmentFile=/etc/app.env
ExecStart=/srv/app/venv/bin/python /srv/app/main.py
Restart=on-failure
RestartSec=3
NoNewPrivileges=true
PrivateTmp=true

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now app
sudo systemctl status app

ExecStart utilise le Python du venv, pas /usr/bin/python3, sinon les paquets installés seront introuvables. EnvironmentFile charge PORT, DATABASE_URL et les autres variables ; le fichier doit être lisible par deploy uniquement (chmod 600).

Écoute et reverse proxy

L'application lit son port dans l'environnement et écoute sur 0.0.0.0. Pour Flask ou FastAPI, ne lancez pas le serveur de développement en production : utilisez Gunicorn ou Uvicorn derrière Nginx. Le port applicatif reste local et fermé au pare-feu ; seuls 80 et 443 sont publics.

Vérifier et dépanner

journalctl -u app -n 100 --no-pager affiche les erreurs de démarrage. Les causes fréquentes : mauvais chemin dans ExecStart, module absent du venv, variable non chargée, port déjà utilisé (ss -ltnp). Testez avec curl http://127.0.0.1:PORT/ avant de conclure côté Nginx. Après pip install -r requirements.txt, redémarrez le service : un simple rechargement ne relit pas les nouveaux paquets.