Zum Inhalt springen
PAASBOXPAASBOXPAASBOX

Beispiel: eine Django-SaaS

Eine typische Django-SaaS, etwa das quelloffene SaaS-Pegasus-Boilerplate, besteht aus einem Web-Prozess, einem Hintergrund-Worker, einem Migrationsschritt, einer PostgreSQL-Datenbank und einem Redis-kompatiblen Broker für Celery. Diese Seite zeigt diese Form als paas.paasbox.com-Objekte. Es ist ein durchgerechnetes Beispiel, kein veröffentlichtes Starter-Repository — es gibt noch keinen fertigen Manifest-Satz zum Klonen.

apiVersion: paas.paasbox.com/v1alpha1
kind: ManagedPostgres
metadata: { name: db, namespace: shop }
spec:
  plan: s
  storage: 20Gi
  backup: { retention: 7d, objectStoreSecretRef: { name: s3-backups } }
---
apiVersion: paas.paasbox.com/v1alpha1
kind: ManagedValkey
metadata: { name: broker, namespace: shop }
spec:
  plan: xs
  persistence: true
---
apiVersion: paas.paasbox.com/v1alpha1
kind: App
metadata: { name: shop, namespace: shop }
spec:
  image: registry.example.com/acme/shop:1.4.2
  port: 8000
  envFrom: [{ secretRef: { name: shop-env } }]      # DJANGO_SETTINGS_MODULE, SECRET_KEY, …
  uses:
    - { name: db, kind: ManagedPostgres, prefix: DB_ }
    - { name: broker, kind: ManagedValkey, prefix: REDIS_ }
  scale: { min: 0, max: 5 }
  release:
    command: [python, manage.py]
    args: [migrate, --noinput]
    timeoutSeconds: 300
---
apiVersion: paas.paasbox.com/v1alpha1
kind: App
metadata: { name: shop-worker, namespace: shop }
spec:
  type: worker
  image: registry.example.com/acme/shop:1.4.2
  command: [celery]
  args: [-A, project, worker, -l, INFO]
  envFrom: [{ secretRef: { name: shop-env } }]
  uses:
    - { name: db, kind: ManagedPostgres, prefix: DB_ }
    - { name: broker, kind: ManagedValkey, prefix: REDIS_ }
  scale: { min: 2 }
Terminal-Fenster
kubectl apply -f shop.yaml
pb status

Was das bringt, mit den Teilen, die schon auf ihren eigenen Seiten stehen:

  • Die Web-App wartet, bis db und broker Ready sind, führt den Release-Job (migrate --noinput) gegen das neue Image aus, und rollt die neue Revision erst dann aus — Release-Schritt.
  • Beide Apps lesen dieselbe Datenbank und denselben Broker über DB_*- und REDIS_*-Umgebungsvariablen, die Referenzen auf die Credentials-Secrets sind, nie Kopien — Datenbanken, Caches.
  • shop-worker läuft mit fest zwei Replicas, ohne Port, ohne URL, ohne Skalierung auf null — Web und Worker.
  • envFrom lädt die eigenen Settings der App, SECRET_KEY inklusive, aus einem Secret, das du separat verwaltest.
  • pb preview up shop --ref <branch> --from-prod gibt einem Pull Request seine eigene Web-App, seinen eigenen Worker, seine eigene Datenbank (aus der Produktion wiederhergestellt) und seinen eigenen Broker — Preview-Umgebungen.

Was noch nicht gebaut ist: ein veröffentlichtes, klon-und-los-Repository für diese Form, und das Image aus Quellcode zu bauen statt aus deiner eigenen CI — siehe was als Nächstes kommt auf der Überblicksseite.