Flask auf Nodion deployen

Flask Schritt für Schritt deployen

1. Gunicorn zu den Dependencies hinzufügen Nodion startet Gunicorn, installiert es aber nicht, es gehört also neben Flask in deine Dependencies. Pinne die Python-Version in .python-version, denn ein Bereich in der pyproject.toml nimmt das neueste Release. requirements.txt

   flask
   gunicorn

2. Das App-Objekt in app.py anlegen Nodion nimmt die erste Datei aus app.py, application.py und wsgi.py, die Flask enthält, und startet gunicorn <datei>:app mit 3 Workern auf dem PORT, den Nodion setzt. Das Objekt muss app heißen. app.py

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

3. App Factory? Eine web-Zeile ergänzen Mit create_app() gibt es kein app auf Modulebene, also sagst du Gunicorn in einer Procfile, dass es die Factory aufrufen soll. Die Zeile ersetzt den Standard-Startbefehl. Procfile

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

4. Migrationen bei jedem Deploy ausführen Mit Flask-Migrate führt eine release:-Zeile bei jedem Build einmal flask db upgrade aus, nach dem Build und bevor die neue Version startet. Scheitert sie, stoppt der Deploy und die laufende Version bleibt live. Procfile

   release: flask --app myapp db upgrade

5. App und Datenbank anlegen Lege eine Application aus deinem Repository in der Region EU Central an, dann eine PostgreSQL-Datenbank in derselben Region, und hänge sie auf dem Tab Environment an: Sie kommt beim nächsten Deploy als DATABASE_URL an. Setz deinen SECRET_KEY als Secret, lies ihn mit os.environ, dann pushen.

Gut zu wissen

• DATABASE_URL und SQLAlchemyDie DATABASE_URL von Nodion beginnt mit postgres://, und das akzeptiert SQLAlchemy ab 1.4 nicht. Tausch das Schema aus, bevor du die URL weitergibst: postgresql:// für psycopg2, postgresql+psycopg:// für psycopg 3.
• Health CheckDer Traffic wechselt, sobald / mit 2xx oder 3xx antwortet; eine Weiterleitung auf eine Login-Seite reicht also. Liefert / 401 oder 404, leg eine Route wie /healthz an und trag sie in den App-Einstellungen als Health-Check-Pfad ein.
• Celery- und RQ-WorkerErgänz die Procfile um worker: celery -A myapp worker und eine ausdrückliche Zeile web: gunicorn app:app --bind 0.0.0.0:$PORT --workers 3; ohne web:-Zeile wird der erste Procfile-Eintrag außer release: zum Standardbefehl. Dann legst du auf dem Tab Processes einen Prozess worker ohne Port an. Valkey in derselben Region liefert dir REDIS_URL.

Was Nodion für dich betreibt

• Deploys ohne Downtime Push auf deinen Branch und Nodion baut ein neues Release. Der Traffic wechselt erst, wenn die neuen Instanzen ihren Health Check bestehen; ein fehlgeschlagenes Release lässt das laufende stehen. Apps mit lokalem Volume starten stattdessen neu, weil die Disk zu einer Instanz gehört.
• Datenbanken neben der App Managed PostgreSQL, pgvector, MySQL, Valkey und ClickHouse in derselben Region. Angehängte Datenbanken kommen als DATABASE_URL, REDIS_URL oder CLICKHOUSE_URL in die App.
• Previews pro Pull Request Schalte Previews ein, und Pull Requests aus deinem Repository bekommen eine eigene App mit eigener URL und frischen, leeren Datenbanken, automatisch oder per Hand angelegt. Forks und Bot-Pull-Requests werden übersprungen.
• Worker, Cron Jobs und Skalierung Worker laufen als weitere Prozesse derselben App, Jobs planst du auf dem Tab Cron, und jeden Prozess skalierst du auf bis zu 16 Instanzen.
• Release-Schritt Mit Buildpacks läuft eine release:-Zeile in der Procfile bei jedem neuen Build. Dockerfile-Apps sowie Redeploys und Rollbacks auf ein früheres Image nutzen einen Release Command, der an der App selbst gesetzt ist; er hat auch Vorrang vor der Procfile-Zeile. Bei statischen Sites läuft ein Release-Schritt in einem Image, das nur die gebauten Dateien enthält.
• Logs und Metriken Build-, Release- und Laufzeit-Logs sowie CPU-, Speicher-, Disk- und Netzwerk-Metriken für jede Instanz im Dashboard.
• Domains und HTTPS Ein Default-Hostname mit HTTPS ab dem ersten Deploy; deine eigenen Domains bekommen automatisch Zertifikate.

Weiterlesen

• Heroku-Alternativen mit EU-Hosting: 5 Optionen im Vergleich Eine deutsche Plattform und US-Clouds mit EU-Regionen, verglichen nach Sitz, Regionen und Managed Databases.
• Preview-Environments erklärt: eine App pro Pull Request Eine laufende Kopie deiner App für jeden Pull Request: wofür Preview-Environments gut sind, wo es knifflig wird und wie Nodion sie handhabt.

Flask auf Nodion: Fragen und Antworten