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.ma). 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.ma { 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.
