Pourquoi self-héberger Apache Airflow sur un VPS
Airflow est l'outil que choisissent les équipes data quand elles veulent décrire leurs pipelines en Python pur : chaque DAG est un fichier .py qui définit des tâches, leurs dépendances et leur planification. L'écosystème de providers est immense (bases SQL, S3, BigQuery, dbt, Spark…), et la communauté gigantesque. Les services managés (Cloud Composer, MWAA) facturent cher l'environnement à l'heure ; en self-hébergeant Airflow sur un VPS, vous obtenez le même moteur pour le coût d'un serveur, et vos DAG s'exécutent au plus près de vos sources de données internes. C'est aussi une question de contrôle : versions des providers, dépendances Python custom, variables et connexions, tout reste sous votre main. Le déploiement Docker Compose officiel (CeleryExecutor) reproduit fidèlement une architecture de production : webserver, scheduler, workers, Redis et PostgreSQL.
Bénéfices concrets du self-hosting
- DAG en Python pur, versionnés dans Git, avec dépendances et providers maîtrisés.
- Énorme écosystème d'opérateurs : SQL, cloud, dbt, Spark, HTTP, et plus.
- Scheduler robuste : cron, dépendances entre tâches, backfill et catchup.
- Workers Celery scalables pour absorber des centaines de tâches en parallèle.
- Exécution proche de vos bases internes, sans transit par un cloud tiers.
- Coût d'un VPS au lieu d'un environnement managé facturé à l'heure.
Prérequis techniques
Airflow est l'outil le plus gourmand de cette série en configuration CeleryExecutor, car il fait tourner simultanément webserver, scheduler, worker(s), triggerer, Redis et PostgreSQL. La documentation officielle recommande au moins 4 Go de RAM, mais pour une production confortable visez 4 vCPU et 8 Go de RAM ; 16 Go si vos DAG chargent pandas ou de gros volumes. Prévoyez 40 Go de disque, Docker et Docker Compose, et un domaine (airflow.votredomaine.com). Le mode LocalExecutor allège la stack (sans Celery ni Redis) et peut tourner sur 4 Go si vos besoins restent modestes.
Déployer Apache Airflow avec Docker Compose
Récupérer le compose officiel
Créez /opt/airflow, puis téléchargez le fichier de référence : curl -LfO https://airflow.apache.org/docs/apache-airflow/stable/docker-compose.yaml. Créez les sous-dossiers attendus : mkdir -p ./dags ./logs ./plugins ./config.
Régler les permissions et l'UID
Airflow exige un UID cohérent pour les volumes montés. Générez le fichier d'environnement : echo -e "AIRFLOW_UID=$(id -u)" > .env. Sans cela, le scheduler ne pourra pas écrire ses logs et plantera au démarrage.
Initialiser la base de données
Lancez la migration et la création du compte admin : docker compose up airflow-init. Cette commande prépare PostgreSQL, applique les migrations et crée l'utilisateur par défaut airflow / airflow, à changer ensuite.
Démarrer la stack complète
Lancez tous les services : docker compose up -d. Vérifiez que webserver, scheduler, worker et triggerer sont healthy avec docker compose ps. Le webserver écoute sur le port 8080.
Reverse proxy et HTTPS
Mettez Caddy devant le webserver : airflow.votredomaine.com { reverse_proxy localhost:8080 }. Le HTTPS protège l'accès à l'UI Airflow, qui expose connexions, variables et logs potentiellement sensibles.
Déposer un DAG et l'exécuter
Placez un fichier hello.py minimal dans ./dags (un DAG avec une BashOperator ou PythonOperator). Le scheduler le détecte en quelques secondes. Activez-le dans l'UI, déclenchez une exécution manuelle et inspectez les logs de la tâche.
Ne mettez jamais de logique lourde directement dans le fichier DAG : le scheduler parse tous les .py à intervalle régulier (min_file_process_interval), et un import coûteux au niveau module ralentit tout l'ordonnanceur. Gardez le code de parsing léger et déportez le travail dans les tâches. Pour gérer les dépendances Python custom, construisez votre propre image dérivée de apache/airflow avec un requirements.txt plutôt que d'installer des paquets au runtime : vos workers démarrent plus vite et restent reproductibles. Enfin, surveillez la croissance du dossier ./logs et purgez régulièrement.
CVE-2026-58076 : vulnérabilité critique et mise à jour vers Airflow 2.10.4
CVE-2026-58076 (CVSS 9.1) est une vulnérabilité d'exécution de code à distance dans le composant DAG serialization d'Apache Airflow, affectant les versions antérieures à 2.10.4. Un attaquant authentifié peut déclencher l'exécution d'un objet arbitraire lors de la désérialisation en injectant un payload dans les métadonnées d'un DAG. La correction est disponible dans Airflow 2.10.4. Pour mettre à jour votre instance Docker Compose : modifiez le tag dans votre docker-compose.yml en apache/airflow:2.10.4, puis docker compose pull && docker compose up -d. Vérifiez la version avec docker compose exec airflow-webserver airflow version. Les tables de migration se mettent à jour automatiquement au premier démarrage. Si l'accès web au DAG serialization doit être désactivé en attendant la mise à jour, définissez AIRFLOW__CORE__DAG_SERIALIZATION=True (activé par défaut depuis 2.1.0) et bloquez l'accès au worker depuis l'extérieur du réseau Docker.
Dépannage : trois erreurs fréquentes
Port 8080 déjà utilisé : si docker compose up -d échoue avec port is already allocated, changez le port dans docker-compose.yml ou stoppez le service qui l'occupe (lsof -i :8080). Scheduler en état running sans exécuter de DAG : vérifier que le répertoire ./dags est bien monté (docker compose config | grep dags) et que les fichiers .py des DAGs sont syntaxiquement valides (python3 -c "import dag_file"). DAG non visible dans l'interface après ajout : l'intervalle de scan du dossier DAGs est de 30 secondes par défaut ; forcer le rechargement avec docker compose restart airflow-scheduler. Pour les fichiers modifiés après le démarrage, le Scheduler les récupère automatiquement dans son prochain cycle.
