Déployez Flask sur Nodion

Déployez Flask étape par étape

1. Ajoutez Gunicorn à vos dépendances Nodion démarre Gunicorn mais ne l'installe pas : listez-le à côté de Flask. Fixez la version de Python dans .python-version, car une plage dans pyproject.toml sélectionne la version la plus récente. requirements.txt

   flask
   gunicorn

2. Placez l'objet app dans app.py Nodion prend le premier fichier parmi app.py, application.py et wsgi.py qui contient Flask et exécute gunicorn <fichier>:app avec 3 workers sur le PORT qu'il définit. L'objet doit s'appeler app. app.py

   from flask import Flask
   
   app = Flask(__name__)
   
   
   @app.get("/")
   def index():
       return "Hello from Frankfurt"

3. Vous utilisez une app factory ? Ajoutez une ligne web Avec create_app(), il n'y a pas d'objet app au niveau du module : indiquez donc à Gunicorn, dans un Procfile, d'appeler la factory. Cette ligne remplace la commande de démarrage par défaut. Procfile

   web: gunicorn "myapp:create_app()" --bind 0.0.0.0:$PORT --workers 3

4. Exécutez les migrations à chaque déploiement Avec Flask-Migrate, une ligne release: exécute flask db upgrade une fois par build, après le build et avant le démarrage de la nouvelle version. Si elle échoue, le déploiement s'arrête et la version en cours reste en ligne. Procfile

   release: flask --app myapp db upgrade

5. Créez l'app et la base de données Créez une application depuis votre dépôt dans la région EU Central, puis une base de données PostgreSQL dans la même région, et rattachez-la dans l'onglet Environment : elle arrive sous la forme DATABASE_URL au déploiement suivant. Définissez votre SECRET_KEY comme variable secrète, lisez-la avec os.environ, puis faites un push.

Bon à savoir

• DATABASE_URL et SQLAlchemyLa DATABASE_URL de Nodion commence par postgres://, que SQLAlchemy 1.4 et les versions suivantes n'acceptent pas. Remplacez le schéma avant de la transmettre : postgresql:// pour psycopg2, postgresql+psycopg:// pour psycopg 3.
• Health checkLe trafic bascule dès que / renvoie un code 2xx ou 3xx : une redirection vers une page de connexion convient donc. Si / renvoie 401 ou 404, ajoutez une route comme /healthz et indiquez-la comme chemin du health check dans les paramètres de l'app.
• Workers Celery et RQAjoutez worker: celery -A myapp worker au Procfile avec une ligne explicite web: gunicorn app:app --bind 0.0.0.0:$PORT --workers 3 ; sans ligne web:, la première entrée du Procfile autre que release: devient la commande par défaut. Ajoutez ensuite, dans l'onglet Processes, un processus nommé worker sans port. Valkey dans la même région vous fournit REDIS_URL.

Ce que Nodion gère pour vous

• Déploiements sans interruption Faites un push sur votre branche : Nodion construit une nouvelle release. Le trafic bascule lorsque les nouvelles instances réussissent leur health check ; si la release échoue, celle en cours reste active. Les apps avec un volume local redémarrent, car le disque appartient à une seule instance.
• Bases de données à côté de l'app PostgreSQL, pgvector, MySQL, Valkey et ClickHouse managés, dans la même région. Les bases de données rattachées arrivent sous forme de DATABASE_URL, REDIS_URL ou CLICKHOUSE_URL.
• Previews par pull request Activez les previews, et les pull requests de votre dépôt obtiennent leur propre app, avec sa propre URL et des bases de données neuves et vides, créées automatiquement ou à la main. Les pull requests issues de forks ou de bots sont ignorées.
• Workers, cron jobs et mise à l'échelle Exécutez les workers comme processus supplémentaires de la même app, planifiez des tâches dans l'onglet Cron et mettez chaque processus à l'échelle jusqu'à 16 instances.
• Étape de release Avec les buildpacks, une ligne release: du Procfile s'exécute à chaque nouveau build. Les apps Dockerfile, ainsi que les redéploiements ou les rollbacks vers une image antérieure, utilisent une commande de release définie sur l'app elle-même, qui prime aussi sur la ligne du Procfile. Sur les sites statiques, l'étape de release s'exécute dans une image qui ne contient que les fichiers générés par le build.
• Logs et métriques Logs de build, de release et d'exécution, ainsi que les métriques CPU, mémoire, disque et réseau de chaque instance, dans le dashboard.
• Domaines et HTTPS Un nom d'hôte par défaut avec HTTPS dès le premier déploiement, et des certificats automatiques pour vos propres domaines.

Pour aller plus loin

• Alternatives à Heroku avec hébergement dans l'UE : 5 options Une plateforme allemande et des clouds américains avec des régions dans l'UE, comparés par siège, régions et bases de données managées.
• Environnements de preview : une app par pull request Une copie de votre app en fonctionnement pour chaque pull request : à quoi servent les environnements de preview, où ils se compliquent et comment Nodion les gère.

Flask sur Nodion : questions et réponses