{.object-cover .max-w-full .mb-5}

:::GlobalTitle{:size="lg" .mb-5} Agiler Projektstart: Weg mit der Starrheit, her mit der Flexibilität ::: :::GlobalParagraph Der Start eines Softwareprojekts ist immer eine aufregende Phase: Ideen sprudeln, Visionen entstehen – und genau hier entscheidet sich oft schon, ob ein Projekt ein Erfolg wird. Viele Teams halten sich zu lange an veralteten Methoden fest, wie dem klassischen Anforderungskatalog, der zwar Struktur vorgaukelt, aber oft zum Bremser der Agilität wird. :::

:::GlobalParagraph Wir bei BLUESHOE haben gelernt: Flexibilität von Anfang an ist der Schlüssel. Deshalb setzen wir auf den agilen Produkt-Backlog, der den starren Anforderungskatalog ersetzt. Wie das funktioniert? Lies weiter – und entdecke am Ende, wie unser RAPID-System{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} deine Projekte noch effizienter macht. :::

:::GlobalButton{:url="/leistungen/anforderungsanalyse/" :label="Erfahre mehr über unsere Anforderungsanalyse" :color="blue" .mb-6} :::

:::GlobalTitle{:size="lg" .mb-5} Der Anforderungskatalog: Ein Relikt aus der Wasserfall-Ära ::: :::GlobalParagraph Der klassische Anforderungskatalog listet jede Funktion bis ins kleinste Detail auf. Klingt erstmal sinnvoll, oder? Schließlich sorgt er für klare Vorgaben und scheinbare Planungssicherheit. Doch hier lauern die Probleme: :::

:::GlobalBlock{.ul-disk .mb-4}

• Unflexibel: Änderungen sind aufwendig, teuer und oft nicht vorgesehen.
• Keine Dynamik: Neue Erkenntnisse lassen sich nur schwer integrieren.
• Risiko von Fehlentwicklungen: Was zu Beginn geplant wurde, passt selten noch zum Ziel am Ende. :::

:::GlobalParagraph Kurz gesagt: Der Anforderungskatalog plant für eine Welt, die es nicht mehr gibt. :::

:::GlobalTitle{:size="lg" .mb-5} Der Produkt-Backlog: Agil, flexibel, dynamisch ::: :::GlobalParagraph Der Produkt-Backlog ist das Herzstück agiler Projekte. Er ist kein starres Dokument, sondern eine lebendige Liste von Aufgaben, die kontinuierlich angepasst wird. So bleibt dein Projekt dynamisch und reaktionsfähig. :::

{.object-cover .max-w-full .mb-5}

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Doch wie werden Anforderungen im Backlog definiert? :: :::GlobalParagraph Hier kommen die User Stories{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} ins Spiel. Sie sind kurze, prägnante Beschreibungen von Anforderungen aus der Perspektive des Endnutzers. Eine typische User Story folgt dieser einfachen Struktur: :::

:::GlobalParagraph Struktur: "Als Nutzerrolle möchte ich Ziel/Wunsch, damit Nutzen." :::

:::GlobalParagraph Beispiel: "Als Online-Shop-Kunde möchte ich meine Bestellungen verfolgen können, damit ich immer weiß, wann mein Paket ankommt." :::

:::GlobalParagraph Die Vorteile von User Stories: :::

:::GlobalBlock{.ul-disk .mb-4}

• Fokus auf den Nutzer: Sie sorgen dafür, dass jede Anforderung echten Mehrwert liefert.
• Flexibilität: Leicht anpassbar, wenn sich Anforderungen ändern.
• Klarheit: Alle im Team – vom Entwickler bis zum Projektmanager – verstehen sofort, worum es geht. :::

:::GlobalParagraph Durch regelmäßiges Backlog-Refinement verfeinern und priorisieren wir diese User Stories, sodass dein Projekt immer auf das Wesentliche fokussiert bleibt. :::

:::GlobalParagraph Die Vorteile im Überblick: :::

:::GlobalBlock{.ul-disk .mb-4}

• Flexibilität: Änderungen sind jederzeit möglich.
• Kundenorientierung: Fokus auf den tatsächlichen Mehrwert.
• Schnelle Ergebnisse: Iterative Entwicklung mit sichtbarem Fortschritt.
• Transparenz: Alle Beteiligten sind immer im Bilde. :::

:::GlobalParagraph{.mb-5} Klingt spannend? Dann wird dich unser RAPID-System{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} noch mehr begeistern – es macht deine Prozesse bis zu 35 % schneller. :::

:::GlobalTitle{:size="lg" .mb-5} So gelingt der Wechsel vom Katalog zum Backlog ::: :::GlobalParagraph Der Übergang zum agilen Arbeiten muss nicht kompliziert sein. Bei BLUESHOE setzen wir auf einen strukturierten, aber flexiblen Ansatz: :::

:::GlobalBlock{.ol-decimal .mb-4}

1. Anforderungen in User Stories umwandeln: Statt starrer Vorgaben definieren wir User Stories, die sich an den Bedürfnissen der Nutzer orientieren. Das schafft Klarheit und Fokus.
2. Prioritäten setzen: Nicht alles ist gleich wichtig. In Workshops priorisieren wir gemeinsam, was den größten Nutzen bringt – und was warten kann.
3. Regelmäßiges Backlog-Refinement: Der Backlog ist kein „Set-and-Forget“-Dokument. Wir passen ihn kontinuierlich an neue Erkenntnisse an, um immer auf Kurs zu bleiben.
4. Transparenz schaffen: Dank digitaler Tools und offener Kommunikation hast du jederzeit Einblick in den Projektstatus. Keine Überraschungen, keine Blackboxes. :::

:::GlobalTitle{:size="lg" .mb-5} Warum der agile Backlog den Projekterfolg steigert :::

:::GlobalParagraph Ein agiler Backlog macht den Unterschied: :::

:::GlobalBlock{.ul-disk .mb-4}

• Anpassungsfähig: Veränderungen? Kein Problem – der Backlog wächst mit.
• Fokus auf das Wesentliche: Klare Prioritäten halten das Team auf Kurs.
• Schnelle Ergebnisse: Iterative Schritte liefern frühzeitig sichtbaren Mehrwert.
• Bessere Abstimmung: Ein gemeinsames Verständnis durch klare Anforderungen. :::

:::GlobalTitle{:size="lg" .mb-5} Fazit: Dynamik von Anfang an ::: :::GlobalParagraph Agil zu starten bedeutet, flexibel zu bleiben. Mit BLUESHOE schaffst du den Sprung vom starren Plan zur dynamischen Umsetzung. Wir helfen dir, Anforderungen sinnvoll zu strukturieren und den Backlog lebendig zu halten. Wenn du dein Projekt agil starten möchtest, lass uns zusammen loslegen – kontaktiere uns und wir machen den ersten Schritt gemeinsam! :::

:::GlobalTitle{:size="lg" .mb-5 .mt-8} Häufige Fragen :::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 1. Was ist der Unterschied zwischen Anforderungskatalog und Produkt-Backlog? ::

::GlobalParagraph Der Anforderungskatalog ist eine starre Liste von Vorgaben. Der Produkt-Backlog ist flexibel und wird regelmäßig an neue Erkenntnisse angepasst. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 2. Warum ist agiles Projektmanagement effizienter? ::

::GlobalParagraph Weil es Veränderungen als Chance sieht. Statt starrer Pläne setzt es auf iterative Verbesserungen und schnellen Kunden-Feedback. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 3. Braucht jedes Projekt einen Produkt-Backlog? ::

::GlobalParagraph Für agile Projekte: Ja! Der Backlog ist das zentrale Steuerungsinstrument. Er hält das Team fokussiert und sorgt für Transparenz. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 4. Wie oft sollte der Backlog aktualisiert werden? ::

::GlobalParagraph Regelmäßig! Idealerweise nach jedem Sprint oder wenn es wichtige neue Erkenntnisse gibt. So bleibt das Projekt immer auf Kurs. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 5. Wie hilft der Produkt-Backlog, den Projekterfolg zu sichern? ::

::GlobalParagraph{.mb-4} Der Produkt-Backlog sorgt für klare Prioritäten, flexible Anpassungsmöglichkeiten und kontinuierliche Transparenz im Projekt. So können Teams schneller auf Veränderungen reagieren, den Fokus auf den größten Mehrwert legen und effizienter zusammenarbeiten. ::

Celery ist mächtig, aber manchmal zu schwergewichtig für einfache Setups. In diesem Artikel schauen wir auf Alternativen wie Django RQ, Dramatiq und Huey, erklären, warum KEDA eine Schlüsselrolle beim Autoscaling spielt und geben dir Mini-YAML-Beispiele für sauberes Deployment mit Probes und Graceful Shutdown.

Die vier Optionen im Kurzprofil

(Mit Links zu Projekten und Repos, damit du weiter eintauchen kannst.)

Celery

Der Klassiker mit großem Ökosystem. Unterstützt Worker und den separaten Scheduler Beat. In großen Setups mit Chains und vielen Integrationen bleibt Celery der Referenzpunkt.

Django RQ

Django-freundliche Integration von RQ auf Redis Basis. Worker starten im Django Kontext. In vielen Fällen genügt das Setzen von DJANGO_SETTINGS_MODULE. Monitoring ist leicht über RQ Dashboard oder Admin-Integrationen.

Dramatiq

Moderne Defaults mit Fokus auf Zuverlässigkeit. Läuft mit Redis oder RabbitMQ. Die Django Integration django_dramatiq bringt das Management Kommando rundramatiq.

Huey

Leichtgewichtig mit eingebautem Scheduler. Saubere Django Integration über das Management Kommando run_huey inklusive Auto-Discovery von tasks.py.

KEDA in 60 Sekunden

KEDA ist der Kubernetes Event Driven Autoscaler.
Er skaliert Deployments und Jobs abhängig von Ereignissen wie Queue-Längen und kann bei Leerlauf bis auf null skalieren. KEDA ergänzt den Horizontal Pod Autoscaler und arbeitet mit ihm zusammen.

Warum ist KEDA so wichtig?

• Du brauchst kein Polling im Worker.
• Pods skalieren dynamisch, wenn Jobs in der Queue liegen.
• Bei Leerlauf kannst du die Worker auf 0 reduzieren und Ressourcen sparen.

Typische Trigger für Django Worker sind Redis Lists sowie RabbitMQ Queues. Beide sind als Scaler verfügbar.

Vergleich speziell für Kubernetes

| Tool | Broker | KEDA Trigger | Vorteile | Nachteile | Beste Wahl wenn | |---|---|---|---|---|---| | Celery | Redis, RabbitMQ | Redis List oder RabbitMQ Queue | Sehr ausgereift, viele Integrationen, Worker plus Beat, breite Community. K8s Plus: viele Beispiele für Queue-basiertes Autoscaling. | Mehr Betriebsaufwand, zusätzliche Komponenten wie Beat, sorgfältiges Shutdown Handling nötig. | Hohe Last, komplexe Chains, vorhandene Celery Erfahrung. | | Django RQ | Redis | Redis List | Sehr leichter Start, Admin Integration, wenige bewegliche Teile. K8s Plus: Listenlänge als simpler KEDA Trigger. | Geringere Feature Tiefe, Redis Pflicht. | Web Projekte mit klaren Jobs und schnellem Go Live. | | Dramatiq | Redis, RabbitMQ | Redis List oder RabbitMQ Queue | Moderne Defaults, robuste Retries, saubere Django Integration über rundramatiq. K8s Plus: gut kombinierbar mit KEDA je nach Broker. | Weniger fertige Django UIs, Einarbeitung ins Actor Modell. | Anspruchsvoll aber schlank, Fokus auf Zuverlässigkeit. | | Huey | Redis | Redis List | Leichtgewichtig, Scheduler enthalten, Consumer als Management Kommando. K8s Plus: simpler Prozess und KEDA Kopplung. | Kleineres Ökosystem, Monitoring eher minimal. | Wenige Worker, viele periodische Aufgaben. |

Mini YAML Beispiele

Beispiel A: Celery Worker mit RabbitMQ und KEDA

# Deployment für Celery Worker
apiVersion: apps/v1
kind: Deployment
metadata:
  name: celery-worker
spec:
  selector: { matchLabels: { app: celery } }
  template:
    metadata: { labels: { app: celery } }
    spec:
      terminationGracePeriodSeconds: 60
      containers:
        - name: worker
          image: your-registry/app:latest
          command: ["celery","-A","proj","worker","--loglevel=info"]
          env:
            - name: RABBITMQ_HOST
              valueFrom:
                secretKeyRef: { name: rmq, key: amqp_uri }
---
# ScaledObject für RabbitMQ Queue
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: celery-rabbit
spec:
  scaleTargetRef: { name: celery-worker }
  minReplicaCount: 0
  maxReplicaCount: 20
  triggers:
    - type: rabbitmq
      metadata:
        hostFromEnv: RABBITMQ_HOST
        queueName: celery
        protocol: amqp
        mode: QueueLength
        value: "20"
      authenticationRef:
        name: rmq-auth

Beispiel B: Django RQ Worker plus KEDA Redis List Scaler

# Deployment für RQ Worker
apiVersion: apps/v1
kind: Deployment
metadata:
  name: rq-worker
spec:
  selector: { matchLabels: { app: rq } }
  template:
    metadata: { labels: { app: rq } }
    spec:
      terminationGracePeriodSeconds: 60
      containers:
        - name: worker
          image: your-registry/app:latest
          command: ["bash","-lc","DJANGO_SETTINGS_MODULE=config.settings rq worker default"]
          env:
            - name: REDIS_HOST
              value: "redis:6379"
---
# KEDA ScaledObject mit Redis List Trigger
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: rq-scale
spec:
  scaleTargetRef: { name: rq-worker }
  minReplicaCount: 0
  maxReplicaCount: 10
  triggers:
    - type: redis
      metadata:
        addressFromEnv: REDIS_HOST
        listName: default
        listLength: "20"  # Skalierung ab 20 Jobs

Beispiel C: Dramatiq unter Django mit Redis

apiVersion: apps/v1
kind: Deployment
metadata:
  name: dramatiq-worker
spec:
  selector: { matchLabels: { app: dramatiq } }
  template:
    metadata: { labels: { app: dramatiq } }
    spec:
      terminationGracePeriodSeconds: 60
      containers:
        - name: worker
          image: your-registry/app:latest
          command: ["python","manage.py","rundramatiq","--processes","2","--threads","8"]
          env:
            - name: REDIS_HOST
              value: "redis:6379"
---
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: dramatiq-scale
spec:
  scaleTargetRef: { name: dramatiq-worker }
  minReplicaCount: 0
  maxReplicaCount: 10
  triggers:
    - type: redis
      metadata:
        addressFromEnv: REDIS_HOST
        listName: default
        listLength: "10"

Beispiel D: Huey Worker mit Redis

apiVersion: apps/v1
kind: Deployment
metadata:
  name: huey-worker
spec:
  selector: { matchLabels: { app: huey } }
  template:
    metadata: { labels: { app: huey } }
    spec:
      terminationGracePeriodSeconds: 60
      containers:
        - name: worker
          image: your-registry/app:latest
          command: ["python","manage.py","run_huey"]
          env:
            - name: REDIS_HOST
              value: "redis:6379"
---
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: huey-scale
spec:
  scaleTargetRef: { name: huey-worker }
  minReplicaCount: 0
  maxReplicaCount: 5
  triggers:
    - type: redis
      metadata:
        addressFromEnv: REDIS_HOST
        listName: default
        listLength: "5"

Kubernetes Betriebsaspekte, die zählen

Broker deployen

Redis und RabbitMQ bekommst du stabil per Helm Chart oder Operator. Für RabbitMQ gibt es zusätzlich einen offiziellen Cluster Operator.

Probes konfigurieren

Setze Readiness, Liveness und bei längeren Starts eine Startup Probe. Beispiel:

livenessProbe:
  exec: { command: ["pgrep", "rq"] }
  initialDelaySeconds: 20
  periodSeconds: 10

So verhinderst du Deadlocks und Traffic an nicht bereite Pods.

Graceful Shutdown

Nutze terminationGracePeriodSeconds und bei Bedarf einen preStop Hook, damit laufende Tasks sauber zu Ende laufen:

lifecycle:
  preStop:
    exec:
      command: ["bash","-c","kill -TERM 1 && sleep 30"]

Kubernetes beendet Container nach Ablauf der Grace Period in jedem Fall – plane also Puffer.

KEDA Installation

KEDA lässt sich per Helm Chart oder YAML installieren. Danach definierst du ScaledObjects oder ScaledJobs pro Worker.

Code Beispiele für Tasks

Damit du den Unterschied auch im Django Code siehst:

Celery

from celery import shared_task

@shared_task
def send_email(user_id):
    # klassische Celery Task
    ...

Django RQ

import django_rq

def send_email(user_id):
    ...

# Task in die Queue legen
queue = django_rq.get_queue('default')
queue.enqueue(send_email, user.id)

Dramatiq

import dramatiq

@dramatiq.actor
def send_email(user_id):
    ...

# Task dispatchen
send_email.send(user.id)

Huey

from huey.contrib.djhuey import task

@task()
def send_email(user_id):
    ...

# Task aufrufen
send_email(user.id)

Ausfallhandling in Kubernetes Clustern

Früher oder später passiert’s: Ein Worker geht down oder der Broker fällt aus. Damit deine Tasks trotzdem sauber weiterlaufen, brauchst du etwas Absicherung. So kannst du vorgehen:

Wenn ein Worker abstürzt

Kubernetes stellt deine Pods automatisch mit restartPolicy: Always wieder her. Wichtig ist jedoch, dass Jobs erst dann aus der Queue entfernt werden, wenn sie wirklich verarbeitet sind. Andernfalls gehen Tasks verloren.

Alle vier Tools (Celery, RQ, Dramatiq, Huey) unterstützen eingebaute Retries. Diese solltest du aktiv einsetzen.

Ein Beispiel für ein RQ‑Worker‑Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: rq‑worker
spec:
  replicas: 2
  selector: { matchLabels: { app: rq } }
  template:
    metadata: { labels: { app: rq } }
    spec:
      restartPolicy: Always
      containers:
        - name: worker
          image: your‑registry/app:latest
          command: ["rq","worker","default"]

Wenn ein Pod abstürzt, startet Kubernetes ihn einfach neu. Die offenen Jobs bleiben in Redis liegen und werden vom nächsten Worker übernommen.

Wenn der Broker ausfällt

Ohne Redis oder RabbitMQ läuft nichts. Deshalb solltest du diese Komponenten hochverfügbar betreiben.

Redis als StatefulSet

Ein Deployment allein reicht nicht aus, wenn Daten dauerhaft gespeichert werden müssen. Ein StatefulSet sorgt dafür, dass Redis‑Pods stabile Namen und ein eigenes Volume haben. Damit bleibt die Queue auch nach Neustarts bestehen.

Kurz gesagt: StatefulSets geben Pods eine feste Identität und persistenten Speicher.

RabbitMQ mit replizierten Queues

RabbitMQ‑Queues sind normalerweise an einen Node gebunden. Fällt dieser Node oder Pod aus, ist die Queue verschwunden. Mit Quorum Queues, also replizierten und ausfallsicheren Queues auf Basis des Raft‑Protokolls, bist du sicherer aufgestellt. Der RabbitMQ Kubernetes Operator erleichtert dir den Aufbau eines hochverfügbaren Clusters.

Der Vorteil ist klar: Wenn ein Pod ausfällt, übernimmt ein anderer, ohne dass deine Worker davon viel mitbekommen.

Kubernetes‑Tools, die du nicht vergessen solltest

• PodDisruptionBudget (PDB): sorgt dafür, dass bei Updates nicht zu viele Pods gleichzeitig ausfallen.
• Readiness Probes: stellen sicher, dass nur gesunde Pods Jobs bearbeiten.
• Graceful Shutdown: gibt deinen Workern Zeit, um Tasks bei SIGTERM zu Ende zu bringen.
• Backoff und Retries: ermöglichen es Workern, automatisch wieder zu verbinden, wenn der Broker kurzzeitig nicht erreichbar ist.

Mit diesem Setup bist du für die häufigsten Fehlerquellen im Cluster gut vorbereitet, egal ob Worker oder Broker einmal ausfallen.

Entscheidungsleitfaden

• Einfach und schnell mit Redis: Django RQ oder Huey. Kopple über den KEDA Redis List Scaler.
• Robust mit flexibler Broker Wahl: Dramatiq. Nimm Redis oder RabbitMQ und binde KEDA entsprechend an.
• Großes Setup mit vorhandenem Know-how: Celery mit ScaledObjects je Queue und optional Beat oder django-celery-beat für Periodics.

Migrationen sind möglich: Viele Task-Definitionen lassen sich mit geringem Aufwand portieren, auch wenn Retry/ACK-Mechanismen unterschiedlich umgesetzt sind.

FAQ

1. Was ist KEDA und wofür nutze ich es?

KEDA skaliert Workloads anhand externer Ereignisse wie Queue Länge und ermöglicht Scale to Zero. Es ergänzt den Horizontal Pod Autoscaler.

2. Kann ich alle vier Tools mit KEDA autoscalen?

Ja. Über den Redis Lists Scaler oder den RabbitMQ Queue Scaler, je nach Broker.

3. Wie wähle ich den passenden Broker?

Redis ist schnell bereitgestellt und genügt oft für Web Projekte. RabbitMQ lohnt sich bei komplexem Routing oder bestehender AMQP Erfahrung.

4. Brauche ich für Celery einen separaten Scheduler?

Für periodische Aufgaben nutzt Celery den Scheduler Beat. Mit django-celery-beat kannst du Zeitpläne im Django Admin pflegen.

5. Wie starte ich Dramatiq in Django sauber?

Über python manage.py rundramatiq aus django_dramatiq. Das Kommando ist für die Django Integration gedacht.

6. Gibt es Dashboards für Django RQ?

Ja. Es gibt rq-dashboard als Standalone sowie Integrationen für den Django Admin.

{.object-cover .max-w-full .mb-5}

:::globalParagraph Die Aufnahme der Kundenwünsche, die Anforderungsanalyse und -erhebung, wird im Arbeitsalltag oft stiefmütterlich behandelt. Denn das alles kostet bereits vor der Auftragserteilung meist Zeit – und Zeit ist Geld. Das rächt sich dann aber meist in der Umsetzungsphase und auch vermeintlich „leichte” Projekte können ungeahnte Ausmaße annehmen. In diesem Artikel wollen wir deshalb einen genaueren Blick auf diesen Aspekt der Projektimplementierung werfen. :::

:::globalTitle{:size="lg" .mb-5} DAS „MAGISCHE DREIECK” ::: :::globalParagraph Das magische Dreieck ist im theoretischen Projektmanagement weit verbreitet. Nur, wenn die Aspekte „Kosten”, „Zeit” und „Qualität” ein gleichseitiges Dreieck bilden, ist die Projektumsetzung ausgewogen. Wir plädieren dafür, den Begriff der Qualität durch den Begriff des „Scopes”, also des Umfangs, zu ersetzen. Denn der Umfang der Leistungserbringung ist viel klarer definierbar als die Qualität der Leistungserbringung. Damit kann der Scope auch viel effektiver an die Aspekte der Kosten und der Zeit gekoppelt werden, wobei die Qualität dann einen Aspekt des Scopes darstellt. :::

{.object-cover .max-w-full .mb-5}

:::globalTitle{:size="md" .mb-5} DEN KUNDENWÜNSCHEN AUF DER SPUR ::: :::globalParagraph Die daraus resultierende Frage ist: Wie kann der Scope am genauesten erhoben werden? Dabei fällt meist der Begriff der Anforderungsanalyse. Also zu analysieren, was der Kunde möchte und welche der Kundenwünsche im konkreten Auftrag umgesetzt werden sollen. Dieser Prozess, der oft als „Anforderungsanalyse” bezeichnet wird, besteht allerdings aus zwei separaten Schritten: Zuerst kommt die Anforderungserhebung und erst im zweiten Schritt folgt die eigentliche Analyse. :::

:::globalTitle{:size="md" .mb-5} DIE ANFORDERUNGSERHEBUNG ::: :::globalParagraph Bei der Anforderungserhebung geht es darum, herauszufinden was der Kunde „wirklich will”. Die Anforderungen, die der Kunde an sein künftiges Produkt hat, sind in der Regel in der Sprache und mit dem Vokabular des Kunden formuliert. Es lohnt sich hier eine extra Abstimmungsschleife zu drehen, um sicherzustellen, dass Kunde und Auftragnehmer eine möglichst deckungsgleiche Vorstellung des späteren Produktes haben. :::

:::globalTitle{:size="lg" .mb-5} FUNKTIONALE UND NICHT-FUNKTIONALE ANFORDERUNGEN ::: :::globalParagraph Funktionale Anforderungen beschreiben dabei, WAS ein System leisten soll. Nicht-funktionale Anforderungen beschreiben, WIE ein System funktionieren soll. ::: :::globalParagraph Beide Aspekte sind im Kundengespräch dabei nicht immer klar voneinander zu trennen. Die Herausforderung für den Auftragnehmer ist es, diese Aspekte zu trennen – gegebenenfalls auch erst nach dem Gespräch mit dem Kunden. Denn für den Kunden sind beide Aspekte oft „ein und dasselbe”. Für die Definition des Scopes ist die Trennung aber immens wichtig: Die funktionalen Anforderungen, also das WAS, müssen den Kern der Anforderungserhebung bilden. Herrscht darüber zwischen Kunde und Auftragnehmer keine Einigkeit, kann das Projekt nicht erfolgreich umgesetzt werden. :::

:::globalTitle{:size="sm" :tag="h4" .mb-5} PRAXISBEISPIELE :::

{.object-cover .max-w-full .mb-5}

:::globalParagraph Nehmen wir als Beispiel einen Gastronomen, der ein Reservierungssystem benötigt. Dieser beschreibt die funktionale Anforderung als: “Das System soll anzeigen, wie viele freie Plätze im Restaurant noch verfügbar sind”. Diese Formulierung birgt ein hohes Risiko für Missverständnisse: Bezieht sich die Anforderung rein auf freie Plätze, also wie viele potentielle Gäste das Restaurant aufnehmen kann? Oder muss die Verteilung der Plätze auf die Tische mitberücksichtigt werden? ::: :::globalParagraph Ein anderes Beispiel: Für einen Kunden soll eine Suchabfrage aus einer Datenbank realisiert werden. Die funktionale Anforderung ist erfasst und so geklärt, dass Kunde und Auftragnehmer ein gemeinsames Verständnis teilen. Eine nicht-funktionale Anforderung ist die spätere Darstellung der Suchergebnisse. Zum Beispiel, ob die Suchergebnisse paginiert oder nicht-paginiert dargestellt werden sollen, oder wie viele Suchergebnisse überhaupt angezeigt werden sollen. Aber auch, auf welche Zielgruppe der Suchdienst abzielt und in welcher Form die Suchergebnisse dargestellt werden sollen (sollen z. B. nur der Titel oder auch weitere Details angezeigt werden?). ::: :::globalParagraph Die beiden Beispiele zeigen, dass die funktionalen Anforderungen zwar den Kern des Scopes bilden, aber die nicht-funktionalen Aspekte trotzdem nicht vernachlässigt werden dürfen und ebenso gewissenhaft erhoben werden müssen. Denn, auch wenn in einem Projekt alle funktionalen Anforderungen abgebildet werden, ist es möglich, dass das Ergebnis trotzdem nicht dem entspricht, was der Kunde sich vorstellt, da die nicht-funktionalen Anforderungen nicht ausreichend abgeklärt wurden. :::

:::globalTitle{:size="lg" .mb-5} ANFORDERUNGSERHEBUNG = DER DIENSTLEISTER ALS DETEKTIV ::: :::globalParagraph Der Fokus der Anforderungserhebung sollte darauf liegen, alle möglichen Eventualitäten in den Kundenanforderungen aufzudecken. Dabei kann der Softwaredienstleister sich als Detektiv verstehen, um den Fokus nicht aus den Augen zu verlieren und sich folgende zwei Fragen stellen: ::: :::GlobalBlock{.ol-decimal .mb-5}

1. Wer profitiert davon wirklich? Für wen soll das spätere Produkt nützlich sein? Wer ist die eigentliche Zielgruppe: der Kunde selbst oder der Kunde des Kunden? Die Zielgruppe beeinflusst maßgeblich die funktionalen und nicht-funktionalen Anforderungen. Diese Frage erscheint einfach, oft verstecken sich hier aber essentielle Aspekte für eine umfassende Anforderungserhebung. What doesn’t fit in?
2. Was passt nicht ins Bild? Oft verstecken sich hinter anscheinend banalen Funktionalitäten weitere Funktionen, die für die Umsetzung unabdingbar sind. Die Frage zielt auf Edge-Cases (also Ausnahmefälle) ab. Ausnahmefälle müssen dabei richtiggehend „aufgespürt” werden. Vielen Kunden sind Ausnahmefälle, die bei der Projektimplementierung berücksichtigt werden müssen, oft gar nicht bewusst. In der späteren Implementierung können diese aber dazu führen, dass eine zuvor erstellte Konzeption durch das Auftreten von Edge-Cases komplett neu aufgesetzt werden muss. ::: :::globalParagraph Um im Bild eines ermittelnden Kommissars zu bleiben, dient die Anforderungserhebung also dazu, die „wahren Motive” des Kunden zu erkennen. :::

:::globalTitle{:size="lg" .mb-5} ANFORDERUNGSANALYSE ALS ZWEITER SCHRITT :::

{.object-cover .max-w-full .mb-5}

:::globalParagraph Die eigentliche Analyse der Anforderungen erfolgt erst nach der Anforderungserhebung. Nachdem die Kundenanforderungen aufgenommen wurden, muss – im besten Falle gemeinsam mit dem Kunden – geprüft werden, ob diese überhaupt umsetzbar sind. ::: :::globalParagraph Hier gilt es zu klären, ob die notwendigen technischen Voraussetzungen gegeben sind, um die Anforderungen umzusetzen. Außerdem muss geklärt werden, ob Anforderungen im vorgegebenen Zeit- und Kostenrahmen realisierbar sind. ::: :::globalParagraph Ist das nicht der Fall, muss geprüft werden, ob es sinnvoll ist, in einer ersten Umsetzungsphase nur einen Teil der Anforderungen umzusetzen. Ist das möglich, ist sowohl aus Kunden- als auch aus Auftragnehmersicht eine Anforderungspriorisierung hilfreich: Es gilt zu klären, welche Elemente für den Kunden am wichtigsten sind, und ob diese auch realisierbar sind. :::

:::globalTitle{:size="md" .mb-5} ABGLEICH MIT DER REALITÄT ::: :::globalParagraph Was in Büchern zum erfolgreichen Projektmanagement oft fehlt, ist ein Abgleich mit der Realität. In einer idealtypischen Welt haben sowohl Kunde als auch Auftragnehmer genügend Zeit und Muße, die Anforderungen zu erheben und die Anforderungen gemeinsam zu analysieren und zu priorisieren, damit der Auftragnehmer im Anschluss daran ein gut kalkuliertes Angebot erstellen kann. ::: :::globalParagraph Als Auftragnehmer haben wir aber die Erfahrung gemacht, dass dies in der Realität so oft nicht abzubilden ist. In anderen Worten: Zeit ist Geld und Geld muss zuerst einmal verdient werden. Der Kunde ist darauf angewiesen, so schnell wie möglich ein Angebot zu erhalten, das er beauftragen kann, damit das gewünschte Produkt so schnell wie möglich umgesetzt wird. Der Auftragnehmer ist ebenfalls an einer schnellen Auftragserteilung interessiert, um Planungssicherheit zu haben. Eine umfassende Anforderungserhebung und -analyse findet manchmal sogar erst nach der Beauftragung statt. :::

:::globalTitle{:size="lg" .mb-5} VIER ERKENNTNISSE FÜR EINE ERFOLGREICHE ANFORDERUNGSPHASE :::

{.object-cover .max-w-full .mb-5}

:::globalParagraph Im Folgenden stellen wir vier Erkenntnisse aus unserer Erfahrung dar, die zeigen, wie man die Anforderungserhebung und -analyse in Auftragskalkulationen abbilden und die Risiken für Kunde und Auftragnehmer verringern kann. :::

:::globalTitle{:size="md" .mb-5} ZEITTRACKING SCHON VOR PROJEKTBEGINN ::: :::globalParagraph Als Auftragnehmer sollte man kontinuierlich monitoren, wie viel Zeit für die Auftragsklärung benötigt wird. Nur dann kann man Erfahrungswerte sammeln, und weiß später, wie aufwändig sich der Prozess gestaltet, und kann die Kosten besser einpreisen. :::

:::globalTitle{:size="md" .mb-5} KONZEPTIONSPHASEN EINPLANEN ::: :::globalParagraph Im Angebot sollte eine zusätzliche Konzeptionsphase dargestellt werden – je nach Umfang von einigen Stunden bis hin zu ganzen Tagen. Darin sollte dann nicht nur die notwendige Zeit für die Softwarearchitektur, sondern auch Zeit für grundsätzliche Absprachen mit dem Kunden berücksichtigt werden. Vor allem, wenn eine Ausschreibung nicht klar formuliert ist, sollte diese Angebotsposition besonders berücksichtigt werden. :::

:::globalTitle{:size="md" .mb-5} GRENZEN DEFINIEREN ::: :::globalParagraph Das Angebot sollte klare Grenzen definieren. Vor allem für Kunden ist oft nicht ganz eindeutig, was sich hinter einzelnen Angebotspunkten versteckt. Ggf. ist es sinnvoll, das eigentliche Angebot um ein Dokument zu ergänzen, das die einzelnen Punkte genauer erläutert. :::

:::globalTitle{:size="md" .mb-5} PROJEKTMANAGEMENTKOSTEN BESSER AUFTEILEN ::: :::globalParagraph Projektmanagement wird oft als “unproduktiver” Overhead gesehen. Je höher die Projektmanagementkosten, desto schwieriger wird es, die Notwendigkeit dieser Position dem Kunden gegenüber zu erläutern. ::: :::globalParagraph Wir schlagen deshalb vor, in der Kalkulation die einzelnen technischen Angebotspositionen um einen gewissen Anteil an PM-Zeit zu erhöhen. Das Angebot an den Kunden enthält dann trotzdem den finalen Zeit- und Kostenaufwand. Damit wird der extra ausgewiesene PM-Anteil im Angebot nicht zu hoch. Der zusätzliche PM-Anteil kann für Absprachen mit dem Kunden genutzt werden und sollte im Projektcontrolling auch immer getrennt von der technischen Umsetzung gemonitort werden. ::: :::globalParagraph Eine fünfte Erkenntnis für die erfolgreiche Umsetzung von Projekten ist auch die Definition von Abnahmekriterien. :::

:::globalTitle{:size="lg" .mb-5} FAZIT: DER ANFORDERUNGSPROZESS BEI BLUESHOE ::: :::globalParagraph Zu Beginn unserer Unternehmensgeschichte haben sich die Entwickler noch stark in den Anforderungsprozess eingebracht und sehr viel persönlich mit den Kunden kommuniziert. Manchmal wurde Anforderungen sogar „on the fly” erhoben und gleichzeitig umgesetzt. Aufgrund der steigenden Anzahl an Kunden und Projekt haben wir erkannt, dass dieses Vorgehen ab einer gewissen Größe nicht mehr möglich ist. Seither nimmt der Anforderungsprozess in unserem Projektmanagement eine zentrale Stelle ein und wird von unseren Projektmanagern durchgeführt. ::: :::globalParagraph Uns ist es dabei besonders wichtig, dass wir immer flexibel auf Änderungen in den Anforderungen reagieren können, die sich während der Projektimplementierung ergeben. Die konsequente Anforderungserhebung gibt aber nicht nur uns, sondern vor allem auch unseren Kunden eine wesentlich höhere Planungssicherheit hinsichtlich des Umsetzungszeitraums eines Projektes. :::

{.object-cover .max-w-full .mb-5}

:::GlobalTitle{:size="lg" .mb-5} Ausgangslage ::: :::GlobalParagraph Das Projekt wird vollständig in der Azure Cloud betrieben und nutzt zwei AKS Kubernetes Cluster: ein Staging- und ein Produktiv-System. Diese generieren Cloud-Ressourcen wie virtuelle Maschinen, Festplatten, Load Balancer und IP-Adressen. ::: :::GlobalParagraph Zusätzlich kommen diverse Azure-Services zum Einsatz, darunter eine Managed Database, Storage für Media-Daten und eine Redis-Instanz. Vor der Optimierung lagen die Kosten bei ca. 100 € pro Tag. :::

{.object-cover .max-w-full .mb-5}

::GlobalTitle{:size="lg" .mb-4} Analyse mit Azure Cost Management :: ::GlobalParagraph Der erste Schritt zur Kubernetes Cluster Kostenmanagement war eine Analyse mit Azure Cost Management für Kubernetes. Das Tool bietet detaillierte Einblicke, welche Services wie viel kosten - ein sehr guten Anhaltspunkt, bei welchen Services es lohnend sein kann genauer hinzuschauen. ::

::GlobalParagraph Direkt fiel uns eine abgeschaltete, aber noch existierende VM auf. Diese hat zwar wenig Kosten verursacht, war aber dennoch unnötig und konnte entfernt werden. ::

::GlobalParagraph Die größten Kostentreiber waren jedoch die virtuellen Maschinen – insbesondere die Node Pools der beiden AKS Cluster. Ein detaillierter Blick auf die Kubernetes Ressourcenoptimierung zeigte, dass die Anzahl der Nodes nicht optimal auf den tatsächlichen Bedarf abgestimmt war. Auch hier unterstützt Azure – nämlich mit einem Monitoring der CPU- und der Memory-Auslastung. ::

::GlobalParagraph Auch Azure Log Analytics erwies sich als unerwartet hoher Kostenpunkt. Dieser war für den Production Cluster konfiguriert. Sämtliche Logs der Kubernetes-Ressourcen wurden langfristig gespeichert, ohne aktiv genutzt zu werden. ::

::GlobalTitle{:size="lg" .mb-4} Getroffene Maßnahmen :: ::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Node Pools optimieren ::

::GlobalParagraph Basierend auf diesen Erkenntnissen haben wir eine Reihe gezielter Optimierungsmaßnahmen umgesetzt. :: ::GlobalBlock{.ul-disk .mb-4}

• Der Staging-Cluster wurde von 3 auf 1-3 Nodes umgestellt – mit Auto-Scaling. Damit laufen in der Regel nur noch 2 Nodes.
• Der Production-Cluster nutzt zwei Nodepools: System-Mode (fix auf 2 Nodes) und User-Mode (Auto-Scaling auf 1-6 Nodes). Das spart Ressourcen und passt sich dynamisch der Last an. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Virtuelle Maschinen anpassen :: ::GlobalParagraph Eine zu groß dimensionierte VM für die Managed Database wurde verkleinert. Dank Azure Cost Management für Kubernetes war klar, dass die vorhandene Rechenleistung überdimensioniert war. Die Umstellung erfolgte reibungslos und kann jederzeit rückgängig gemacht werden, falls der Bedarf steigt. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Log Analytics deaktivieren :: ::GlobalParagraph Die hohen Kosten von Azure Log Analytics standen in keinem Verhältnis zur tatsächlichen Nutzung. Die Deaktivierung führte zu einer erheblichen Einsparung, die sich erst nach einigen Wochen vollständig bemerkbar machte, da Logs bis zu 90 Tage gespeichert wurden. ::

{.object-cover .max-w-full .mb-5}

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Unnötige Ressourcen entfernen :: ::GlobalParagraph Eine ungenutzte VM eines alten GitLab Runners wurde gelöscht. Zwar verursachte sie nur ca. 10 € pro Monat, aber solche "vergessenen" Ressourcen summieren sich über die Zeit. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Betriebszeiten mit KEDA optimieren :: ::GlobalParagraph Beide AKS Cluster werden nur werktags während der Arbeitszeiten benötigt. Mittels KEDA Auto-Scaling{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} wurden Betriebszeiten definiert, sodass Anwendungen außerhalb dieser Zeiten automatisch herunterskaliert werden. Dies senkt die AKS Kosten zusätzlich, da weniger Nodes aktiv sind. ::

::GlobalTitle{:size="lg" .mb-4} Ergebnis: Über 50% Kostenreduktion :: ::GlobalParagraph Es hat eine gewisse Zeit gedauert, bis das volle Ausmaß der Kostenersparnis ersichtlich war. Aber die Optimierungsmaßnahmen haben sich gelohnt. Die Betriebskosten sanken von ca. 100 € auf 45 € pro Tag – eine Einsparung von mehr als 50%! ::

::GlobalParagraph Einige Maßnahmen, wie der Node-Autoscaler, hätten früher umgesetzt werden können. Andere, wie das Kubernetes Cluster Kostenmanagement durch Betriebszeiten-Optimierung, erforderten mehr Planung, zahlen sich aber langfristig aus. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Lessons Learned :: ::GlobalBlock{.mb-4} ✔ Regelmäßige Kostenanalyse lohnt sich – ohne sie hätten wir unnötige Ressourcen nicht entdeckt.
✔ Auto-Scaling konsequent nutzen – feste Node-Größen ist oft ineffizient.
✔ Logging hinterfragen – nicht jeder Log-Service ist notwendig oder wirtschaftlich.
::

::GlobalParagraph Mehr über Kubernetes & Kostenoptimierung erfahren? :: :::GlobalButton{:url="/technologien/docker-kubernetes/" :label="Erfahre mehr über unsere Kubernetes-Entwicklungsdienste" :color="blue" .mb-6} :::

:::GlobalTitle{:size="lg" .mb-5 .mt-8} Häufige Fragen :::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 1. Wie kann ich die Kosten meines Azure Kubernetes Clusters senken? :: ::GlobalParagraph Du kannst die AKS Kosten reduzieren, indem du Auto-Scaling aktivierst, ungenutzte Ressourcen entfernst, Log-Services optimierst und Betriebszeiten mit KEDA{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} anpasst. :: ::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 2. Welche Tools helfen bei der Azure Kubernetes Kostenoptimierung? :: ::GlobalParagraph Das Azure Cost Management für Kubernetes bietet detaillierte Analysen. Zusätzlich helfen der Kubernetes Autoscaler und KEDA beim dynamischen Skalieren der Nodes. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 3. Warum ist Auto-Scaling wichtig für die Kostenoptimierung in AKS? :: ::GlobalParagraph Auto-Scaling passt die Anzahl der Nodes an den tatsächlichen Bedarf an und verhindert Überprovisionierung – eine effektive Maßnahme zur Kubernetes Ressourcenoptimierung. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 4. Wie wirkt sich die Deaktivierung von Azure Log Analytics auf die Kosten aus? :: ::GlobalParagraph Log Analytics kann hohe laufende Kosten verursachen. Falls du die Logs nicht aktiv nutzt, kann die Deaktivierung zu einer deutlichen Einsparung führen. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 5. Gibt es eine Möglichkeit, Kubernetes Cluster außerhalb der Arbeitszeiten zu reduzieren? :: ::GlobalParagraph Ja! Mit KEDA Auto-Scaling{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} kannst du deine Cluster außerhalb der Geschäftszeiten automatisch herunterskalieren und so Kosten sparen. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 6. Wie oft sollte ich mein Azure Kubernetes Kostenmanagement überprüfen? :: ::GlobalParagraph Eine monatliche Analyse mit Azure Cost Management hilft, ineffiziente Ressourcen frühzeitig zu erkennen und Kosten langfristig zu senken. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 7. Welche Node-Pool-Strategie ist am kosteneffizientesten für AKS? :: ::GlobalParagraph Eine Kombination aus System-Mode- und User-Mode-Pools mit Auto-Scaling ist ideal. System-Mode sollte stabil bleiben, während User-Mode dynamisch skaliert. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 8. Wann lohnt sich die Nutzung von Spot-Instances in AKS? :: ::GlobalParagraph Spot-Instances sind günstiger, aber nicht immer verfügbar. Sie eignen sich für nicht-kritische Workloads mit flexiblem Ausführungszeitpunkt. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 9. Kann ich Kosten sparen, indem ich auf einen anderen Cloud-Anbieter wechsle? :: ::GlobalParagraph Ja, Azure ist nicht immer die günstigste Option. Es lohnt sich, Alternativen wie Linode oder Hetzner zu prüfen, falls deine Anforderungen es erlauben. ::

{.object-cover .max-w-full .mb-5}

:::globalTitle{:size="lg" :tag="h2" .mb-5} BARRIEREFRE WEBSITES UND INKLUSION – FÜR WEN? ::: :::globalParagraph Die erste Frage, welche sich stellt ist doch – für wen lassen sich eigentlich barrierefreie Websites erstellen? Was könnten Schwierigkeiten bei der Bedienung einer Website sein? Bevor wir zu den Tools und Lösungen kommen, gilt es potentielle Nutzer und deren Barrieren zu identifizieren. ::: :::globalParagraph Barrieren durch Einschränkung des Sehvermögens - Das Web ist ein sehr visuelles Medium zum Konsum von Inhalten. Einschränkungen im Sehvermögen – sei es beispielsweise eine Farbblindheit oder schwache bis nicht vorhandene Sehkraft schränken die Nutzung und Bedienung von Websites ein. ::: :::globalParagraph Barrieren durch Bewegungseinschränkungen - Oftmals kann der gesamte Inhalt einer Seite im Netz nicht auf einem Bildschirm dargestellt werden – also scrollen wir einfach weiter. Verlinkungen sind an unterschiedlichen Stellen zu finden – also klicken wir diese mit dem Cursor an. Die gute alte Maus sowie Touchpads sind als primäres Eingabemedium zur Navigation auf Websites etabliert. Für Nutzer mit Bewegungseinschränkungen, bspw. Arthrose in der Hand, lassen sich diese Interaktionen nur schwer bis gar nicht durchführen. ::: :::globalParagraph Barrieren durch Taubheit - Video- und Audio-Streams finden sich nahezu überall im Web. Menschen mit einer gestörten auditiven Wahrnehmung ist es praktisch unmöglich diese zu konsumieren. ::: :::globalParagraph Barrieren durch Lernschwierigkeiten - Oftmals werden komplexe Zusammenhänge, Probleme oder gar Lösungen als Inhalte auf Websites dargestellt. Menschen mit Lernschwierigkeiten ist es quasi nicht möglich diese zu verstehen und sich somit zu informieren. ::: :::globalParagraph Die Auflistung dieser Behinderungen hat keinen Anspruch auf Vollständigkeit, sondern dient zur Veranschaulichung der bestehenden Probleme und den folgenden potentiellen Lösungen. :::

:::globalTitle{:size="lg" :tag="h2" .mb-5} BARRIEREFREIE KONZEPTION EINER WEBSITE ::: :::globalParagraph Am Beginn jedes Projekts in der Softwareentwicklung steht natürlich ihre Konzeption. Typischerweise ist hier der erste Schritt die Inhalte zu bestimmen, welche dem Besucher vermittelt und zur Verfügung gestellt werden sollen. Je nachdem, wen man erreichen möchte und auch wie, ist es sehr hilfreich bereits an dieser Stelle zu wissen, ob und wie stark Barrierefreiheit und Inklusion eine Rolle spielen. Dies gibt allen Projektbeteiligten ein besseres Verständnis bzgl. der Zielsetzungen hinsichtlich Barrierefreiheit und resultiert somit einem besseren Ergebnis. ::: :::globalParagraph Entsprechend ist es wichtig, bereits bei der Anforderungsanalyse abzuklopfen – ::: :::GlobalBlock{.ul-disk .mb-5}

• „Wie viel“ Barrierefreiheit brauchen wir?
• Was bedeutet dies für das Projekt?
• Steht dies im Einklang mit der Strategie des Unternehmens und der Website selbst?
• Ist der Aufwand wirtschaftlich vertretbar? ::: :::globalParagraph Nicht zuletzt ist Inklusion und Barrierefreiheit noch ein Premium-Service, welcher von Webseiten-Betreibern zusätzlich bezahlt werden muss. Natürlich bringt dieser nicht nur Pluspunkte im Karma und des Images, sondern auch potenzielle neue User/Besucher/Kunden. :::

:::globalTitle{:size="lg" :tag="h2" .mb-5} BARRIEREFREIHEIT UND INKLUSION IN DESIGN, PROGRAMMIERUNG UND REDAKTION ::: :::globalParagraph Ein barrierefreier und inklusiver Webauftritt ist nicht die Aufgabe einer dedizierten Person. Vielmehr müssen die verschiedenen Bereiche Design, Programmierung und Redaktion zusammen für einen barrierefreien Auftritt arbeiten. Nur so, kann wirklich vollumfänglich für einen barrierefreien und inklusiven Webauftritt gesorgt werden. :::

:::globalTitle{:size="lg" :tag="h2" .mb-5} BARRIEREFREIHEIT IM DESIGN ::: :::globalParagraph Hier spielen vor allem visuelle Aspekte wie Kontrastverhältnisse oder Schriftgrößen eine Rolle aber auch der Einsatz der richtigen Bedienelemente wie z.B. Audio- und Videostreams oder auch ein Button zum Umschalten von „normaler“ auf „einfache“ Sprache. :::

{.object-cover .max-w-full .mb-5}

:::globalParagraph Um den Kontrast von Schrift und Hintergrund einer Website zu überprüfen gibt es bereits Websites wie http://accessible-colors.com/{.bs-link-blue :target="_blank"}. :::

:::globalTitle{:size="lg" :tag="h2" .mb-5} BARRIEREFREIHEIT IN DER ENTWICKLUNG ::: :::globalParagraph Um Websites barrierefrei zu machen ist vor allem eine Initiative bekannt: ARIA (Accessible Rich Internet Application). Diese ist seit 2014 der vom World Wide Web Consortium empfohlene Standard für die Implementierung barrierefreier Webseiten. Hierbei wird der Quelltext einer Webseite mit speziellen Attributen versehen um diese für assistive Technologien wie Screenreader konsumierbar zu machen. Aber auch einfach Änderungen wie alt-Attribute für Bilder helfen Nutzern mit Screenreader ein Bild zu interpretieren und gleichzeitig gibt es noch Pluspunkte hinsichtlich der SEO der Webseite. :::

{.object-cover .max-w-full .mb-5}

:::globalParagraph Durch die semantisch korrekte Benutzung von HTML5 in Kombination mit den Empfehlungen der ARIA-Initiative können assistive Technologien Webseiten für Nutzer mit Behinderungen zugänglich machen. Source: https://www.w3.org/WAI/intro/aria{.bs-link-blue :target="_blank"} :::

:::globalTitle{:size="lg" :tag="h2" .mb-5} BARRIEREFREIHEIT IN DER REDAKTION ::: :::globalParagraph Auch redaktionelle Inhalte können barrierefrei gestaltet werden. Dies fängt bei einfachen Dingen wie Untertitel für Videoinhalte an. Weiterhin ist es möglich eine „einfache“ Sprachversion von einem Text zu hinterlegen, sodass Nutzer mit Lernschwierigkeiten auch Zugriff auf das Wissen der Webseite haben. Videoinhalte mit Gebärdensprache können taube Nutzer beim Konsumieren einer Webseite unterstützen. :::

:::globalTitle{:size="lg" :tag="h2" .mb-5} BARRIEREFREIHEIT FÜR WEBSITES IST NICHT NUR EIN TREND ::: :::globalParagraph Wir haben aufgezeigt, dass Barrierefreiheit und Inklusion für einen Webauftritt keine Dinge sind, welche man sich einfach aus dem Ärmel schüttelt. Neben den hier genannten Maßnahmen zur Steigerung der Barrierefreiheit stehen noch viele weitere, welche es zu beachten gibt. Inklusion und Accessibility sind Themen, welche wir in jüngster Zeit immer wieder in den Anfragen unserer Kunden finden. :::

{.object-cover .max-w-full .mb-5}

:::globalParagraph Wir denken, dass Barrierefreiheit und Inklusion kein rein wirtschaftlich getriebener Gedanke sein darf, sondern dies auch als menschliche und gesellschaftliche Aufgabe angesehen werden muss. ::: :::globalParagraph Beispiele für barrierefreie Webseiten: ::: :::globalParagraph http://www.polizei-nrw.de/im/index.html{.bs-link-blue :target="_blank"} ::: :::globalParagraph http://www.bundestag.de/{.bs-link-blue :target="_blank"} ::: :::globalParagraph https://www.virginatlantic.com/{.bs-link-blue :target="_blank"} :::

Stichtag für die Umstellung ist der 29. September 2025. Dieser Schritt, der unter der neuen Eigentümerschaft von Broadcom erfolgt, zwingt tausende Entwickler, DevOps-Teams und Unternehmen zum Handeln. In diesem Beitrag analysieren wir die Hintergründe, zeigen die Konsequenzen auf und geben dir einen klaren Fahrplan für die anstehende Migration.

{.object-cover .max-w-full .mb-5}

1. Einleitung: Der Paukenschlag in der DevOps-Welt

Bitnami war jahrelang die Abkürzung zu produktionsreifen Stacks: ein riesiges Portfolio an Images für populäre Anwendungen wie WordPress, PostgreSQL, Redis, NGINX, Keycloak oder Kafka - vorkonfiguriert, gut dokumentiert und bis dato in großem Umfang kostenlos. Diese Mischung aus einfacher Installation, großer Auswahl und null Einstiegskosten machte Bitnami zum De-facto-Standard in vielen Teams.

Mit der Ankündigung der Umstellung zum 29. September 2025 ist nun klar: „Bitnami nicht mehr kostenlos“ ist mehr als eine Schlagzeile - es ist ein Paradigmenwechsel. Unter Broadcoms Regie richtet sich die Produktstrategie stärker auf zahlende Unternehmenskunden und das neue Angebot „Bitnami Secure Images“ aus. Für den Großteil der bisherigen, versionierten Images bedeutet dies das Ende regelmäßiger, frei zugänglicher Updates.

2. Analyse der Umstellung: Was „nicht mehr kostenlos“ konkret bedeutet

Das „Legacy“-Repository

• Versionierte Images werden in ein Legacy- bzw. Archiv-Repository verschoben und nicht mehr aktualisiert.
• Betroffen ist praktisch die gesamte Bandbreite an Tags - mit Ausnahme einer stark begrenzten Auswahl an :latest-Images.
• Sicherheitsrisiko: Ohne Patches häufen sich Schwachstellen (CVEs), Compliance-Anforderungen werden verletzt und Audits erschwert.

Das neue „Bitnami Secure Images“-Abonnement

• Leistungsversprechen: kontinuierliche Sicherheits-Updates, Kompatibilitäts-Tests, SLA-getriebener Support.
• Preisliche Einordnung: Öffentlich genannte Richtwerte bewegen sich - je nach Paket - im Bereich von ca. 50.000 - 72.000 USD pro Jahr. Für viele Startups, kleinere Unternehmen oder Non-Profit-Teams ist das kaum stemmbar.

Was bleibt kostenlos?

• Eine stark eingeschränkte Auswahl an :latest-Images.
• Warum :latest in Produktion problematisch ist: kein Version Pinning, fehlende Reproduzierbarkeit, schwer nachvollziehbares Drift-Verhalten - ein No-Go für stabile CI/CD und deterministische Releases.

3. Die Konsequenzen für Nutzer: Von brüchigen Pipelines bis zu Sicherheitslücken

• Broken Builds: CI/CD-Pipelines, die feste Versionen referenzieren, schlagen fehl, wenn Images verschwinden oder nicht mehr aktualisiert werden. Build-Caching, SBOM-Erzeugung und Vulnerability-Scans werden unzuverlässig.
• Sicherheits-Albtraum: Ungepatchte Schwachstellen in produktiven Systemen erhöhen das Risiko von Incidents, Datenabflüssen und Compliance-Verstößen (z. B. ISO 27001, SOC 2).
• Verlust der Stabilität: Ohne Version Pinning sind Rollbacks, reproduzierbare Deployments und deterministische Tests kaum möglich. Drift zwischen Staging und Produktion nimmt zu.

Fallbeispiel: Das unvorbereitete Team

Ein mittelständisches SaaS-Unternehmen nutzt bitnami/postgresql:15.6 und bitnami/redis:7.2 in dutzenden Pipelines. Nach der Umstellung sind die versionierten Tags nicht mehr verfügbar bzw. erhalten keine Patches. Builds brechen, SRE-Teams müssen Security-Exceptions dokumentieren, und Kundenaudits stellen kritische Fragen zur Patch-Policy. Das Team improvisiert mit :latest - was kurzfristig hilft, jedoch neue Instabilitäten und schwer reproduzierbare Fehler einführt. Die Kosten: Wochen an Engineering-Zeit und ein erhöhtes Sicherheitsrisiko.

4. Handlungsbedarf: Dein Fahrplan für die Migration

Schritt 1: Analyse der eigenen Infrastruktur

• Bestandsaufnahme aller Bitnami-Images in Nutzung (Container Registry, SBOMs, Deployment-Manifeste).
• Suche in Dockerfile, docker-compose.yml, Helm-Charts und Kustomize-Overlays nach bitnami/*-Referenzen.
• Erstelle eine priorisierte Liste nach Kritikalität (Produktion > Staging > Entwicklung) und Exposition.

Schritt 2: Kurzfristige Übergangslösungen (Notfallplan)

• Umstellung auf das bitnamilegacy-Repository kann Builds kurzfristig retten - ist aber nur eine temporäre Brücke, da Sicherheits-Updates fehlen.
• Parallel: Security-Gates schärfen (Scanner, Policy as Code), klare Ausnahmeregeln mit Ablaufdatum etablieren.

Schritt 3: Langfristige Strategien und Alternativen

• Zielbild definieren: Offizielle Images, verifizierte Anbieter oder eigene Hardening-Pipeline?
• Infrastruktur-As-Code (IaC) und CI/CD so anpassen, dass Version Pinning, SBOM-Erzeugung, Signaturen (Sigstore/Cosign) und regelmäßige Rebuilds Standard werden.

5. Die besten Alternativen zu Bitnami

Offizielle Docker-Images (empfohlen, wo verfügbar)

• Vorteile: Nähe zum Upstream, schnelle Sicherheits-Updates, klare Roadmaps, große Community.
• Beispiele: Docker Hub - Official Images, PostgreSQL, NGINX, Redis.

Verifizierte Anbieter

• Chainguard: Fokus auf „Wolfi“-basierten, minimalistischen , signierten und häufig aktualisierten Images. Link: https://www.chainguard.dev/
• Iron Bank (DoD/Platform One): Härtete, geprüfte Images mit Compliance-Fokus. Link: https://repo1.dso.mil/
• Weitere Enterprise-Angebote je nach Technologie-Stack und Compliance-Anforderungen evaluieren.

Der „Do-It-Yourself“-Ansatz: Eigene Images bauen

• Vorteile: Volle Kontrolle, reproduzierbare Builds, maximale Transparenz (SBOM, Signaturen), abgestimmtes Patch-Management.
• Nachteile: Höherer initialer Aufwand, laufende Wartung und Security-Backporting.
• Praxis-Tipps:
  • Multi-Stage-Builds, Minimierung der Base-Images (Distroless, Wolfi, Alpine mit Bedacht), Rootless-Container.
  • Automatisierte Security-Scans (Trivy, Grype), Signieren mit Cosign, Policy Enforcement (OPA/Gatekeeper, Kyverno).

Community-Helm-Charts und Initiativen

• Beobachte Community-Projekte, die als Reaktion auf die Bitnami-Änderungen entstehen (Forks, Maintained Charts, Operatoren).
• Prüfe Maintainer-Aktivität, Security-Policy, Update-Frequenz und Migrationspfade.

6. Fazit: Eine Chance für mehr Resilienz

Die Botschaft „Bitnami nicht mehr kostenlos“ ist ein Weckruf. Wer sich zu stark auf einen Anbieter verlässt, riskiert Abhängigkeiten mit Sicherheits- und Stabilitätsfolgen. Nutze die Umstellung, um deine Container-Strategie zu modernisieren: Offizielle Images bevorzugen, Security-by-Default etablieren, Version Pinning und Signaturen konsequent durchsetzen und eigene Build-Pipelines stärken.

Beginne jetzt mit der Umstellung, priorisiere kritische Workloads und dokumentiere deine Sicherheitsmaßnahmen. So erhöhst du die Resilienz deiner Plattform - unabhängig von kurzfristigen Marktänderungen.

Häufig gestellte Fragen (FAQs)

1. Was kostet Bitnami jetzt?

Bitnami orientiert sich mit „Bitnami Secure Images“ an Enterprise-Kunden. Genannte Preisbereiche liegen je nach Paket grob bei 50.000 - 72.000 USD jährlich. Konkrete Konditionen variieren nach Umfang, Support-Level und Vertragsdauer.

2. Welche Alternativen zu Bitnami gibt es?

• Offizielle Docker-Images, wo verfügbar.
• Verifizierte Anbieter wie Chainguard oder Iron Bank.
• Eigene, gehärtete Images mit automatisierten Pipelines, Signaturen und SBOMs.

3. Kann ich Bitnami-Images nach August 2025 weiterhin verwenden?

Kurzfristig ja - häufig über Legacy-Repositories oder :latest. Für Produktion ist dies wegen fehlender Patches und mangelnder Reproduzierbarkeit nicht empfehlenswert. Plane eine Migration auf alternative, gepflegte Images.

Welche Erfahrungen machst du mit der Umstellung von Bitnami? Welche Bitnami Alternativen empfiehlst du, und wie adressierst du die Bitnami Preise in deinem Budget? Teile deine Ansätze, Lessons Learned und Tool-Empfehlungen in den Kommentaren.

{.object-cover .max-w-full .mb-5}

:::globalTitle{:size="lg" :tag="h2" .mb-5} Tag 1: Anreise und Welcome Evening ::: :::globalParagraph Da unser Blueshoe Team über Europa verteilt ist, begann unsere Teamweek mit einer spannenden Anreise, die aber für alle Mitarbeiter reibungslos verlief. Die Flüge waren gut organisiert, und der Shuttleservice ins Hotel "You and the Sea" war komfortabel und pünktlich. Bereits bei der Ankunft spürten wir die entspannte Atmosphäre dieser malerischen Küstenstadt. ::: {.max-w-full .mb-5} {.max-w-full .mb-5}

:::globalParagraph Der Abend begann mit einem herzlichen Empfang an der Strandbar. Bei Finger Food und Cocktails konnten wir den Blick auf das Meer genießen und ersten Eindrücke austauschen. Der "Welcome Evening" war ein gelungener Start, um die Kollegen in einem entspannten Umfeld besser kennenzulernen, neue Kollegen zu begrüßen und sich auf die kommenden Tage einzustimmen. :::

:::globalTitle{:size="lg" :tag="h2" .mb-5} Tag 2: Arbeit und Erkundungstour ::: :::globalParagraph Der zweite Tag war als Arbeitstag geplant. Im Hotel "You and the Sea" fanden wir optimale Bedingungen vor, um produktiv zu sein. Die Konferenzräume waren modern ausgestattet, und die Verpflegung ließ keinerlei Wünsche offen. Vom Frühstück über das Mittagessen bis hin zu kleinen Snacks zwischendurch – wir wurden rundum versorgt. ::: :::globalParagraph Am Abend stand eine Stadtführung durch Ericeira auf dem Programm. Ein Guide, der aus Ericeira stammte, zeigte uns die schönsten Ecken der Stadt und brachte uns die Geschichte und Kultur der Region auf kurzweilige Weise nah. Der anschließende Pubcrawl bot eine wunderbare Gelegenheit, das Nachtleben von Ericeira kennenzulernen. In verschiedenen Bars und Pubs konnten wir ins nächtliche Ericeira eintauchen und den Tag bei guter Musik und Getränken ausklingen lassen. ::: {.max-w-full .mb-5}

:::globalTitle{:size="lg" :tag="h2" .mb-5} Tag 3: Arbeit und Game Evening ::: :::globalParagraph Auch am dritten Tag gab es Zeit zum Arbeiten. Einige nutzten die Gelegenheit, um sich in Ruhe mit Kollegen auszutauschen, Ideen zu entwickeln oder Projekte voranzutreiben. Die Umgebung und das gute Wetter sorgten dafür, dass die Arbeitstage keineswegs anstrengend waren, sondern im Gegenteil, sehr inspirierend wirkten. ::: :::globalParagraph Der Abend stand ganz im Zeichen von Spaß und Unterhaltung. Beim "Game Evening" kamen wir alle noch einmal zusammen, um bei Live-Musik und verschiedenen Spielen den Zusammenhalt im Team zu stärken. Es wurde viel gelacht, gesungen und gespielt. Dieser Abend wird uns allen noch lange in Erinnerung bleiben, denn er zeigte, wie wichtig Teamgeist und gemeinsame Erlebnisse für den Erfolg unseres Unternehmens sind. :::

:::globalTitle{:size="lg" :tag="h2" .mb-5} Tag 4: Arbeit und Dinner auswärts ::: :::globalParagraph Auch der vierte Tag begann mit produktiver Arbeitszeit. Danach freuten wir uns auf ein gemeinsames Dinner in einem gemütlichen Restaurant außerhalb des Hotels. Mit Blick auf das Meer bot sich die wunderbare Gelegenheit, die Erlebnisse der vergangenen Tage Revue passieren zu lassen und die Teamdynamik weiter zu stärken. ::: {.max-w-full .mb-5}

:::globalTitle{:size="lg" :tag="h2" .mb-5} Fazit ::: :::globalParagraph Unser Blueshoe Team offsite in Ericeira war ein voller Erfolg. Die perfekte Mischung aus Arbeit und Freizeitaktivitäten hat uns nicht nur als Team enger zusammengeschweißt, sondern auch dazu beigetragen, neue Energie und Inspiration für die kommenden Aufgaben zu tanken. Ericeira hat sich als hervorragender Ort erwiesen, um Arbeit und Erholung zu verbinden, und wir sind alle dankbar für diese unvergesslichen Tage. ::: :::globalParagraph Ericeira, wir kommen bestimmt wieder! ::: {.max-w-full .mb-5}

{.object-cover .max-w-full .mb-6}

:::GlobalTitle{:size="lg" .mb-5} Einführung in Cilium und seine Verwendung in Kubernetes ::: :::GlobalParagraph Cilium ist eine Netzwerklösung für Kubernetes, die fortschrittliche Netzwerk- und Sicherheitsfunktionen bietet. Sie verwendet eBPF, um leistungsstarke Netzwerkaufgaben, Sicherheit und Beobachtbarkeit in Kubernetes durchzuführen. ::: :::GlobalParagraph In diesem Artikel werden wir untersuchen, wie man Cilium für das Kubernetes-Netzwerk verwendet. Wir werden die Grundlagen der Einrichtung von Cilium in einem Cluster, die Konfiguration von Netzwerkrichtlinien und die Verwendung von Hubble zur Beobachtbarkeit behandeln. Wir werden auch bewährte Verfahren für die Verwendung von Cilium in Produktionsumgebungen und die Behebung häufiger Probleme besprechen. Fangen wir an, indem wir Cilium in unseren Kubernetes-Cluster installieren! ::: :::GlobalParagraph Hinweis: Wir empfehlen dir die Verwendung von kind, um dies auf deinem lokalen Rechner auszuprobieren. K3d (das unter der Haube k3s verwendet) enthält in seinen Knoten-Images kein Bash, was dazu führt, dass die Cilium-Installation fehlschlägt. :::

:::GlobalTitle{:size="lg" .mb-5} Cilium installieren ::: :::GlobalParagraph Zunächst müssen wir das Cilium CLI gemäß der Dokumentation installieren. ::: :::GlobalParagraph Sobald die CLI-Installation abgeschlossen ist, können wir Cilium in unseren Cluster installieren, indem wir Folgendes ausführen: :::

:::BlogCode{.mb-5}

$ cilium install

:::

:::GlobalParagraph Dies installiert Cilium in den Cluster, auf den unser aktueller kubectl-Kontext zeigt. Um eine funktionierende Installation zu überprüfen, verwenden wir: :::

:::BlogCode{.mb-5}

$ cilium status --wait

:::

:::GlobalParagraph Die Ausgabe sollte ungefähr so aussehen: :::

:::BlogCode{.mb-5}

    /¯¯\
 /¯¯\__/¯¯\    Cilium:         OK
 \__/¯¯\__/    Operator:       OK
 /¯¯\__/¯¯\    Hubble:         disabled
 \__/¯¯\__/    ClusterMesh:    disabled
    \__/

DaemonSet         cilium             Desired: 1, Ready: 1/1, Available: 1/1
Deployment        cilium-operator    Desired: 1, Ready: 1/1, Available: 1/1
Containers:       cilium             Running: 1
                  cilium-operator    Running: 1
Cluster Pods:     0/3 managed by Cilium
Image versions    cilium             quay.io/cilium/cilium:v1.12.5@sha256:06ce2b0a0a472e73334a7504ee5c5d8b2e2d7b72ef728ad94e564740dd505be5: 1
                  cilium-operator    quay.io/cilium/operator-generic:v1.12.5@sha256:b296eb7f0f7656a5cc19724f40a8a7121b7fd725278b7d61dc91fe0b7ffd7c0e: 1

:::

:::GlobalParagraph Wenn alles gut aussieht, können wir die ordnungsgemäße Netzwerkverbindung überprüfen, indem wir Folgendes ausführen: :::

:::BlogCode{.mb-5}

$ cilium connectivity test

:::

:::GlobalParagraph Dies erstellt einen dedizierten Namespace und führt einige Tests auf vordefinierten Workloads aus, um die Netzwerkverbindung des Clusters zu testen. ::: :::GlobalParagraph Die erfolgreiche Ausgabe sieht wie folgt aus: :::

:::BlogCode{.mb-5}

All 31 tests (151 actions) successful, 0 tests skipped, 1 scenarios skipped.

:::

:::GlobalParagraph Wenn alle Tests erfolgreich durchgeführt wurden, herzlichen Glückwunsch! Wir haben Cilium erfolgreich in unseren Kubernetes-Cluster installiert! :::

:::GlobalPodcastSection{:videoId="5wNTUUSk1jA" :videoPosition="left" .mb-6} ::::GlobalPreTitle{:color="text-bs-green" .mb-3} UNSER PODCAST: TOOLS FOR THE CRAFT :::: ::::GlobalTitle{:tag="h3" .mb-6} E3: Deep dive into Getdeck :::: ::::globalParagraph{:font-size="lg" .mb-4} Michael und Robert stellen Getdeck vor und demonstrieren es. Außerdem vergleichen sie lokale und entfernte Kubernetes- und Pre-Production-Cluster. :::: ::::globalParagraph{:font-size="lg" } Weitere Ausgaben unseres Podcasts findest du hier: :::: ::::GlobalButton{:url="/kubernetes-podcast/" :label="Show more" :color="green"} :::: :::

:::GlobalTitle{:size="lg" .mb-5} Konfigurieren von Netzwerkrichtlinien mit Cilium ::: :::GlobalParagraph Netzwerkrichtlinien in Kubernetes werden zur Kontrolle und Filterung des Datenverkehrs verwendet. Standardmäßig kann jeder Pod, der in einem Cluster läuft, mit jedem anderen Pod kommunizieren, was je nach Einrichtung unsicher sein kann. Mithilfe von Netzwerkrichtlinien können wir Regeln implementieren, die nur den Verkehr zulassen, den wir explizit zulassen wollen. Cilium ermöglicht es uns, Regeln auf der HTTP-Ebene festzulegen, wodurch die Netzwerkregeln von unserem Anwendungscode entkoppelt werden. ::: :::GlobalParagraph Nun, da Cilium in unserem Cluster läuft, wollen wir es testen, indem wir einige Netzwerkrichtlinien anwenden, um festzulegen, welcher Datenverkehr innerhalb des Clusters sowie nach innen und außen erlaubt ist. ::: :::GlobalParagraph Die häufig verwendete Richtlinie "default-deny-ingress" kann mit Cilium wie folgt implementiert werden: :::

:::BlogCode{.mb-5}

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "deny-all-ingress"
spec:
  endpointSelector:
    matchLabels:
  ingress:
  - {}

:::

:::GlobalParagraph Da der matchLabels-Schlüssel leer ist, wird dies auf jeden Endpunkt angewendet und sperrt effektiv den gesamten eingehenden Datenverkehr innerhalb des Clusters. ::: :::GlobalParagraph Da wir möchten, dass unsere Dienste miteinander kommunizieren, fügen wir eine Richtlinie hinzu, die explizit den eingehenden Datenverkehr zwischen zwei Diensten erlaubt. ::: :::GlobalParagraph Eine einfache "ingress-allow" Richtlinie könnte wie folgt aussehen: :::

:::BlogCode{.mb-5}

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "ingress-allow"
spec:
  endpointSelector:
    matchLabels:
      role: backend-api
  ingress:
  - fromEndpoints:
    - matchLabels:
        role: client

:::

:::GlobalParagraph Diese Netzwerkrichtlinie erlaubt allen eingehenden Datenverkehr von Endpunkten mit dem Label role: client, die sich mit Endpunkten mit dem Label role: backend-api. ::: :::GlobalParagraph Bewegen wir uns auf den OSI-Modellschichten nach oben, können wir auch HTTP-Methoden und Pfade wie folgt einschränken: :::

:::BlogCode{.mb-5}

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "rule1"
spec:
  description: "Allow HTTP GET /api from app=client to app=api"
  endpointSelector:
    matchLabels:
      app: api
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: client
    toPorts:
    - ports:
      - port: "80"
        protocol: TCP
      rules:
        http:
        - method: "GET"
          path: "/api"

:::

:::GlobalParagraph Dies erlaubt eingehenden HTTP-Verkehr von Endpunkten mit dem Label app: client zu Endpunkten mit dem Label app: api, solange die HTTP-Methode GET ist und der Pfad "/public" ist. Anfragen an andere Ports als 80 werden abgelehnt, während andere HTTP-Verben und andere Pfade abgelehnt werden. :::

:::GlobalTitle{:size="lg" .mb-5} Cilium für Observability verwenden ::: :::GlobalParagraph Cilium Hubble ist ein leistungsstarkes Observability-Tool, das tiefe Einblicke in den Netzwerkverkehr und die Sicherheit eines Kubernetes-Clusters bietet. In diesem Abschnitt werden wir erkunden, wie man Hubble für Observability einrichtet und verwendet. :::

:::GlobalTitle{:size="md" :tag="h3" .mb-5} Einrichten von Hubble ::: :::GlobalParagraph Um Hubble zu verwenden, müssen wir es, wie folgt, in unserem Kubernetes-Cluster bereitstellen: :::

:::BlogCode{.mb-5}

$ cilium hubble enable --ui

:::

:::GlobalParagraph Wenn wir "cilium status" erneut ausführen, sehen wir, dass Hubble aktiviert und ausgeführt wird. ::: :::GlobalParagraph Um die gesammelten Daten zu nutzen, installieren wir das Hubble CLI wie in der Dokumentation beschrieben. Sobald die Installation abgeschlossen ist, können wir den Hubble-API-Zugriff überprüfen, indem wir zuerst ein Port-Forwarding für Hubble erstellen und dann die Hubble CLI verwenden, um den Hubble-Status zu überprüfen und die API{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} abzufragen. Dies geschieht wie folgt: :::

:::BlogCode{.mb-5}

$ cilium hubble port-forward&
$ hubble status
$ hubble observe
Apr  4 07:14:29.119: 10.244.0.166:37906 (host) -> cilium-test/echo-same-node-9f8754876-ns7tx:8181 (ID:2357) to-endpoint FORWARDED (TCP Flags: ACK)
Apr  4 07:14:29.120: 10.244.0.166:41980 (host) <- cilium-test/echo-same-node-9f8754876-ns7tx:8080 (ID:2357) to-stack FORWARDED (TCP Flags: ACK, PSH)
Apr  4 07:14:29.121: 10.244.0.166:41980 (host) -> cilium-test/echo-same-node-9f8754876-ns7tx:8080 (ID:2357) to-endpoint FORWARDED (TCP Flags: ACK, FIN)
Apr  4 07:14:29.121: 10.244.0.166:41980 (host) <- cilium-test/echo-same-node-9f8754876-ns7tx:8080 (ID:2357) to-stack FORWARDED (TCP Flags: ACK, FIN)
Apr  4 07:14:29.121: 10.244.0.166:41980 (host) -> cilium-test/echo-same-node-9f8754876-ns7tx:8080 (ID:2357) to-endpoint FORWARDED (TCP Flags: ACK)
Apr  4 07:14:30.119: 10.244.0.166:41986 (host) -> cilium-test/echo-same-node-9f8754876-ns7tx:8080 (ID:2357) to-endpoint FORWARDED (TCP Flags: SYN)
Apr  4 07:14:30.119: 10.244.0.166:41986 (host) <- cilium-test/echo-same-node-9f8754876-ns7tx:8080 (ID:2357) to-stack FORWARDED (TCP Flags: SYN, ACK)
Apr  4 07:14:30.119: 10.244.0.166:41986 (host) -> cilium-test/echo-same-node-9f8754876-ns7tx:8080 (ID:2357) to-endpoint FORWARDED (TCP Flags: ACK)
Apr  4 07:14:30.119: 10.244.0.166:37912 (host) -> cilium-test/echo-same-node-9f8754876-ns7tx:8181 (ID:2357) to-endpoint FORWARDED (TCP Flags: SYN)
Apr  4 07:14:30.119: 10.244.0.166:37912 (host) <- cilium-test/echo-same-node-9f8754876-ns7tx:8181 (ID:2357) to-stack FORWARDED (TCP Flags: SYN, ACK)
Apr  4 07:14:30.119: 10.244.0.166:37912 (host) -> cilium-test/echo-same-node-9f8754876-ns7tx:8181 (ID:2357) to-endpoint FORWARDED (TCP Flags: ACK)
Apr  4 07:14:30.119: 10.244.0.166:37912 (host) -> cilium-test/echo-same-node-9f8754876-ns7tx:8181 (ID:2357) to-endpoint FORWARDED (TCP Flags: ACK, PSH)
Apr  4 07:14:30.119: 10.244.0.166:41986 (host) -> cilium-test/echo-same-node-9f8754876-ns7tx:8080 (ID:2357) to-endpoint FORWARDED (TCP Flags: ACK, PSH)
Apr  4 07:14:30.120: 10.244.0.166:37912 (host) <- cilium-test/echo-same-node-9f8754876-ns7tx:8181 (ID:2357) to-stack FORWARDED (TCP Flags: ACK, PSH)
Apr  4 07:14:30.120: 10.244.0.166:37912 (host) <- cilium-test/echo-same-node-9f8754876-ns7tx:8181 (ID:2357) to-stack FORWARDED (TCP Flags: ACK, FIN)
Apr  4 07:14:30.120: 10.244.0.166:37912 (host) -> cilium-test/echo-same-node-9f8754876-ns7tx:8181 (ID:2357) to-endpoint FORWARDED (TCP Flags: ACK, FIN)
Apr  4 07:14:30.120: 10.244.0.166:37912 (host) -> cilium-test/echo-same-node-9f8754876-ns7tx:8181 (ID:2357) to-endpoint FORWARDED (TCP Flags: ACK)
Apr  4 07:14:30.121: 10.244.0.166:41986 (host) <- cilium-test/echo-same-node-9f8754876-ns7tx:8080 (ID:2357) to-stack FORWARDED (TCP Flags: ACK, PSH)
Apr  4 07:14:30.121: 10.244.0.166:41986 (host) -> cilium-test/echo-same-node-9f8754876-ns7tx:8080 (ID:2357) to-endpoint FORWARDED (TCP Flags: ACK, FIN)
Apr  4 07:14:30.121: 10.244.0.166:41986 (host) <- cilium-test/echo-same-node-9f8754876-ns7tx:8080 (ID:2357) to-stack FORWARDED (TCP Flags: ACK, FIN)

:::

:::GlobalParagraph Wenn du grafische Benutzeroberflächen bevorzugst, kannst du auch Hubble UI in deinem Cluster bereitstellen. Hubble UI bietet dir Zugriff auf eine grafische Servicemap, die zur visuellen Überprüfung des Datenverkehrs im Cluster verwendet werden kann. Für unser Beispiel-Setup sieht Hubble UI folgendermaßen aus: :::

{.object-cover .max-w-full .mb-6}

:::GlobalTitle{:size="lg" .mb-5} Fazit ::: :::GlobalParagraph Zusammenfassend bietet Cilium eine robuste Netzwerklösung für Kubernetes, die es Benutzern ermöglicht, präzise Netzwerkrichtlinien durchzusetzen und Netzwerkaktivitäten in Echtzeit zu verfolgen. Durch sein cloud-natives Design und seine auf eBPF basierende Architektur ist Cilium die erste Wahl für Benutzer, die erweiterte Netzwerkfunktionen in ihren Kubernetes-Setups suchen. :::

:::GlobalTitle{:size="lg" .mb-5} Weitere Schritte ::: :::GlobalParagraph Cilium bietet noch viele weitere Funktionen, die wir in diesem Beitrag nicht behandeln können. Hier ist eine kurze Zusammenfassung dessen, wozu Cilium noch fähig ist. :::

:::GlobalTitle{:size="md" .mb-5} Cluster Mesh ::: :::GlobalParagraph Mit Cluster Mesh können wir Netzwerkpfade über mehrere Kubernetes-Cluster hinweg erweitern, sodass Endpunkte in verbundenen Clustern miteinander kommunizieren können, während gleichzeitig Netzwerkrichtlinien durchgesetzt werden. :::

:::GlobalTitle{:size="md" .mb-5} Service Mesh ::: :::GlobalParagraph Cilium Service Mesh zielt darauf ab, traditionelle Service-Mesh-Lösungen wie Linkerd zu ersetzen. Es gibt jedoch einen entscheidenden Unterschied: Während Linkerd auf Sidecar-Proxies zur Verwaltung des Datenverkehrs zwischen Pods angewiesen ist, verwendet Cilium Service Mesh auf der Knotenebene eBPF, um den Datenverkehr zu verwalten. Dies verbessert die Leistung, reduziert die Last und entkoppelt den Service Mesh weiter von den tatsächlichen Workloads. :::

{.object-cover .max-w-full .mb-5}

:::GlobalTitle{:size="lg" .mb-5} Einleitung ::: :::GlobalParagraph In der heutigen Webentwicklung ist die Sicherstellung der Qualität einer Anwendung entscheidend für den Erfolg. Um eine reibungslose Benutzererfahrung zu garantieren, hat sich das automatisierte End-to-End-Testing (E2E) als unverzichtbarer Bestandteil des Entwicklungsprozesses etabliert. Eines der leistungsfähigsten Tools für automatisiertes Testing ist Cypress{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid}, das wir in diesem Artikel näher beleuchten möchten. ::: :::GlobalParagraph Cypress ermöglicht es Entwicklern, Tests direkt im Browser durchzuführen und so die Benutzererfahrung realitätsnah nachzubilden. Mit seinem Fokus auf Geschwindigkeit, Benutzerfreundlichkeit und Stabilität ist Cypress ideal, um Webanwendungen umfassend zu testen und potenzielle Fehler frühzeitig zu erkennen. In diesem Artikel erfährst du, warum Cypress in modernen Webprojekten eine wichtige Rolle spielt und wie du es erfolgreich einsetzen kannst. :::

:::GlobalButton{:url="/technologien/cypress/" :label="Erfahre mehr über unsere Cypress-Entwicklungsdienste" :color="blue" .mb-6} :::

::GlobalTitle{:size="lg" .mb-4} Was ist Cypress? :: ::GlobalParagraph Cypress ist ein modernes End-to-End-Testing-Framework, das speziell für Webanwendungen entwickelt wurde. Es basiert auf JavaScript und ist tief in den Browser integriert. Das bedeutet, dass Tests in der gleichen Umgebung ausgeführt werden, in der die Benutzer mit der Anwendung interagieren – nämlich direkt im Browser. Dies sorgt für besonders realitätsnahe Ergebnisse. Lerne mehr über Cypress. Zur offiziellen Cypress-Seite.{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} ::

::GlobalTitle{:size="lg" .mb-4} Warum ist Cypress so besonders? :: ::GlobalParagraph Cypress hebt sich durch seine enge Integration in den Browser und seine Benutzerfreundlichkeit ab. Hier sind einige seiner herausragenden Eigenschaften{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid}: :: ::GlobalBlock{.ul-disk .mb-4}

• Einfache Einrichtung: Kein komplexes Setup – installiere Cypress mit einem Befehl, und du kannst direkt loslegen.
• Tests im Browser: Deine Tests laufen in der gleichen Umgebung wie die Anwendung, was die Ergebnisse besonders realistisch macht.
• Schnelles Debugging: Mit Screenshots, Videos und interaktiven Laufzeiten siehst du sofort, wo es hakt. :: ::GlobalParagraph Im Vergleich zu anderen Testing-Frameworks wie Selenium bietet Cypress eine einfachere Benutzererfahrung. Die Integration in den Browser und die schnellere Testausführung machen es zur optimalen Wahl für automatisiertes Testen moderner Webanwendungen. ::

{.mx-auto .h-48 .max-w-full .my-4}

::GlobalTitle{:size="lg" .mb-4} Vorteile von Cypress :: ::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Performance und Geschwindigkeit :: ::GlobalParagraph Cypress bietet Echtzeit-Feedback, sodass Entwickler Fehler sofort erkennen und beheben können. Dadurch wird der gesamte Entwicklungsprozess effizienter. Du kannst Tests schnell schreiben und ausführen, was besonders bei umfangreichen Projekten ein großer Vorteil ist. :: ::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Realitätsnahe Tests :: ::GlobalParagraph Da Cypress-Tests direkt im Browser ausgeführt werden, spiegeln sie die tatsächliche Benutzererfahrung wider. Dies stellt sicher, dass Anwendungen unter realen Bedingungen fehlerfrei funktionieren. :: ::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Benutzerfreundlichkeit und einfache Integration :: ::GlobalParagraph Cypress verwendet eine intuitive Syntax, die eine schnelle Einarbeitung ermöglicht. Zudem lässt sich Cypress problemlos in bestehende Entwicklungs-Workflows integrieren, inklusive Continuous Integration (CI) und Continuous Deployment (CD). :: ::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Flexibilität und Anpassbarkeit :: ::GlobalParagraph Cypress bietet eine Vielzahl von APIs und Konfigurationsmöglichkeiten, die es ermöglichen, Tests an die spezifischen Anforderungen eines Projekts anzupassen. Neben der Möglichkeit, Benutzeroberflächen zu testen, unterstützt Cypress auch API-Tests und lässt sich nahtlos in CI/CD-Pipelines integrieren. ::

:::GlobalButton{:url="/technologien/cypress/" :label="Möchtest du deine Teststrategie verbessern? Sieh dir unsere Cypress-Entwicklungslösungen an." :color="blue" .mb-6} :::

::GlobalTitle{:size="lg" .mb-4} Cypress in der Praxis :: ::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Beispiel 1: Cypress im E-Commerce :: ::GlobalParagraph Ein führendes E-Commerce-Unternehmen implementierte Cypress, um den gesamten Checkout-Prozess automatisiert zu testen. Dadurch lassen sich Probleme in Zahlungs- und Versandprozessen frühzeitig erkennen, was die Benutzererfahrung verbessert und Kaufabbrüche reduziert. :: ::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Beispiel 2: Cypress für SaaS-Plattformen :: ::GlobalParagraph Ein Anbieter einer Projektmanagement-Plattform nutzt Cypress, um kritische Funktionen wie Benutzerregistrierung und Team-Kollaboration zu testen. So konnten Entwicklungszyklen verkürzt und die Stabilität der Anwendung verbessert werden. :: ::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Beispiel 3: Finanzplattform mit Continuous Integration :: ::GlobalParagraph Eine Finanzplattform mit hohen Sicherheitsanforderungen setzt Cypress für automatisiertes End-to-End-Testing in der Continuous Integration ein. Fehler in Transaktionsprozessen werden so frühzeitig erkannt und behoben. :: ::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Integration in bestehende Systeme :: ::GlobalParagraph Dank umfassender Dokumentation und Unterstützung für gängige CI/CD-Tools{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} lässt sich Cypress nahtlos in bestehende Entwicklungsumgebungen integrieren. ::

::GlobalTitle{:size="lg" .mb-4} Implementierung von Cypress: Schritt-für-Schritt-Anleitung :: ::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Schritt 1: Installation von Cypress :: ::GlobalParagraph Die Installation von Cypress ist der erste Schritt, um automatisierte Tests in deinem Projekt zu integrieren. Cypress wird als npm-Paket installiert, was bedeutet, dass du Node.js und npm (Node Package Manager) in deinem Projekt eingerichtet haben musst. :: ::GlobalParagraph Befehl zur Installation: :: ::GlobalBlock{.ol-decimal .mb-4}

1. Öffne dein Terminal oder deine Befehlszeile und navigiere zum Root-Verzeichnis deines Projekts.
2. Führe den folgenden Befehl aus, um Cypress als Entwicklungsabhängigkeit in deinem Projekt zu installieren: ::

::BlogCode{.mb-4}

$ npm install cypress --save-dev

::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Schritt 2: Cypress starten :: ::GlobalParagraph Nach der Installation kannst du Cypress zum ersten Mal starten und die interaktive Testumgebung erkunden. Verwende dazu den folgenden Befehl: :: ::BlogCode{.mb-4}

$ npx cypress open

::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Schritt 3: Erstellen und Strukturieren der ersten Tests :: ::GlobalParagraph Cypress erwartet, dass deine Tests in einem speziellen Verzeichnis gespeichert werden, das sich unter cypress/integration befindet. Wenn du Cypress zum ersten Mal öffnest, wird dieses Verzeichnis automatisch erstellt. :: ::GlobalBlock{.ol-decimal .mb-4}

1. Erstelle eine neue Testdatei in diesem Verzeichnis, z. B. example.spec.js.
2. Schreibe einen einfachen Test, um sicherzustellen, dass Cypress funktioniert. Hier ist ein Beispiel für einen Basis-Test, der überprüft, ob deine Website ordnungsgemäß geladen wird: ::

::BlogCode{.mb-4}

describe('Meine erste Cypress-Testreihe', () => {
  it('Besucht die Startseite', () => {
    cy.visit('https://deine-website.com')
    cy.contains('Willkommen')
  })
})

::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Schritt 4: Testausführung :: ::GlobalParagraph Nachdem du deinen ersten Test erstellt hast, kannst du ihn in der Cypress Test Runner-Oberfläche ausführen. Wähle einfach die erstellte example.spec.js-Datei im Cypress-Fenster aus, und der Test wird automatisch im Browser ausgeführt. Du kannst dabei die Testschritte in Echtzeit beobachten. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Schritt 5: Cypress in CI/CD-Pipelines integrieren :: ::GlobalParagraph Ein wichtiger Vorteil von Cypress ist die einfache Integration in CI/CD-Pipelines, damit deine Tests bei jeder Änderung am Code automatisch ausgeführt werden können. Hier ist ein allgemeiner Ablauf, wie du Cypress in eine CI-Umgebung wie GitLab CI, Jenkins oder GitHub Actions integrieren kannst: :: ::GlobalBlock{.ol-decimal .mb-4}

1. Erstelle eine CI-Konfigurationsdatei in deinem Projekt (z. B. .gitlab-ci.yml oder .github/workflows/test.yml).
2. Füge die Cypress-Befehle in die Pipeline-Konfiguration ein. Hier ist ein einfaches Beispiel für GitLab CI: :: ::BlogCode{.mb-4}

stages:
  - test

cypress-test:
  image: cypress/base:14
  stage: test
  script:
    - npm ci
    - npx cypress run

::

::GlobalBlock{.ol-decimal .mb-4} 3. Führe die Pipeline aus, um sicherzustellen, dass Cypress-Tests automatisch bei jedem neuen Commit oder Merge-Request ausgeführt werden. ::

:::GlobalCallAnExpert{:bg="bg-bs-blue"} #buttonBlockTitle Wir können auch deine Anwendung mit Cypress Tests fehlerfrei machen. :::

::GlobalTitle{:size="lg" .mb-4} Best Practices für das Schreiben von Cypress-Tests :: ::GlobalParagraph Um das Beste aus Cypress herauszuholen und deine Tests effizient und wartbar zu gestalten, gibt es einige Best Practices, die du beachten solltest: :: ::GlobalBlock{.ul-disk .mb-4}

• Vermeide direkte Abhängigkeiten zwischen Tests: Jeder Test sollte unabhängig von anderen Tests sein. Dies erleichtert das Debuggen und macht deine Tests robuster.
• Nutze Mocks und Stubs, um API-Abhängigkeiten zu reduzieren: Verwende Cypress' cy.intercept()-Funktion, um API-Aufrufe zu simulieren und unnötige Abhängigkeiten zu vermeiden.
• Verwende Selektoren gezielt: Verwende gezielte Datenattribute wie data-cy="element-name", um deine Tests stabiler zu gestalten, selbst wenn sich das Layout ändert.
• Vermeide zu viele "wait"-Befehle: Nutze die eingebauten Funktionen von Cypress, um auf das Laden von Inhalten zu warten, z. B. cy.get(), anstatt willkürliche cy.wait()-Befehle hinzuzufügen.
• Nutze die Cypress-Dashboard-Option: Für größere Test-Suiten bietet das Dashboard detaillierte Berichte, Screenshots und Videos über fehlgeschlagene Tests. ::

::GlobalTitle{:size="lg" .mb-4} Fehlerbehebung und Debugging mit Cypress :: ::GlobalParagraph Cypress bietet leistungsstarke Debugging-Tools, die dir helfen, Probleme schnell zu finden und zu beheben: :: ::GlobalBlock{.ul-disk .mb-4}

• Interaktive Laufzeit: Wenn ein Test fehlschlägt, kannst du in der Test Runner-Oberfläche sehen, welcher Schritt fehlschlug und warum.
• Screenshots und Videos: Cypress nimmt automatisch Screenshots und Videos von jedem fehlgeschlagenen Test auf, damit du den genauen Moment des Fehlers nachvollziehen kannst.
• Chrome DevTools Integration: Cypress erlaubt dir, die Chrome DevTools zu verwenden, während deine Tests laufen, um detaillierte Netzwerk- und Konsolenfehler zu untersuchen. ::

::GlobalTitle{:size="lg" .mb-4} Warum Blueshoe für Cypress-Implementierungen? :: ::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Unsere Expertise :: ::GlobalParagraph Blueshoe hat umfassende Erfahrung mit Cypress Testing und konnte es bereits in zahlreichen Projekten erfolgreich implementieren. Unsere Entwicklerteams optimieren Teststrategien für End-to-End Testing in verschiedensten Webanwendungen. :: ::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Maßgeschneiderte Lösungen :: ::GlobalParagraph Jedes Projekt hat individuelle Anforderungen. Ob automatisiertes End-to-End-Testing für Benutzeroberflächen, komplexe Workflows oder CI/CD-Integration – Blueshoe bietet Lösungen, die genau auf dein Projekt zugeschnitten sind. ::

::GlobalTitle{:size="lg" .mb-4} Cypress für effizientes Testing: Jetzt die Qualität deiner Webanwendung steigern :: ::GlobalParagraph Cypress bietet eine leistungsstarke und benutzerfreundliche Lösung für automatisiertes End-to-End-Testing. Durch die schnelle Testausführung, die einfache Integration in bestehende Workflows und die realitätsnahen Tests im Browser ist es ein unverzichtbares Werkzeug für die Qualitätssicherung in der Webentwicklung. :: ::GlobalParagraph Möchtest du die Qualität deiner Webanwendungen verbessern? Lass uns gemeinsam automatisierte Tests implementieren, die deine Entwicklungsprozesse beschleunigen und die Fehlerquote minimieren. Kontaktiere uns{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} für ein unverbindliches Beratungsgespräch und erfahre, wie wir dein Projekt unterstützen können. ::

:::GlobalTitle{:size="lg" .mb-5 .mt-8} Häufige Fragen :::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 1. Was ist Cypress und wofür wird es verwendet? :: ::GlobalParagraph Cypress ist ein End-to-End-Testing-Framework für Webanwendungen. Es ermöglicht Entwicklern, automatisierte Tests direkt im Browser auszuführen, um sicherzustellen, dass eine Anwendung wie erwartet funktioniert. :: ::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 2. Welche Vorteile bietet Cypress gegenüber Selenium? :: ::GlobalParagraph Cypress unterscheidet sich von Selenium durch: :: ::GlobalBlock{.ul-disk .mb-4}

• Schnellere Testausführung, da es direkt im Browser läuft.
• Einfachere Einrichtung, ohne zusätzliche WebDriver oder Plugins.
• Bessere Debugging-Möglichkeiten, inklusive Screenshots und Videos von fehlgeschlagenen Tests. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 3. Wie kann Cypress in CI/CD-Pipelines integriert werden? :: ::GlobalParagraph Cypress lässt sich nahtlos in Continuous Integration/Deployment (CI/CD) integrieren. Dazu wird es in der CI-Konfiguration (z. B. GitLab CI, GitHub Actions) als Testschritt definiert. So werden Tests automatisch bei jeder Codeänderung ausgeführt. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 4. Welche Best Practices gibt es für Cypress-Tests? :: ::GlobalBlock{.ul-disk .mb-4}

• Unabhängige Tests: Jeder Test sollte für sich allein lauffähig sein.
• Gezielte Selektoren: Verwendung von data-cy-Attributen für stabile Tests.
• API-Interception nutzen: Anstatt auf feste Wartezeiten (cy.wait()) zu setzen, lieber API-Responses mit cy.intercept() überwachen.
• Tests modular aufbauen: Wiederkehrende Testlogik in Custom Commands oder Helper-Funktionen auslagern. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 5. Für welche Anwendungen ist Cypress nicht geeignet? :: ::GlobalParagraph Cypress unterstützt nur moderne Webanwendungen. Einschränkungen bestehen bei: :: ::GlobalBlock{.ul-disk .mb-4}

• Tests in mehreren Browser-Tabs oder verschiedenen Domains gleichzeitig (workarounds notwendig).
• Mobile App Testing, da Cypress nicht für native Apps gedacht ist.
• Tests für Internet Explorer oder ältere Browser, da Cypress nur moderne Browser unterstützt. ::

{.object-cover .max-w-full .mb-5}

:::globalTitle{:size="lg" :tag="h2" .mb-5} RELEVANZ VON SOCIAL MEDIA ::: :::globalParagraph Prinzipiell gilt, dass Social-Media-Posts nicht nur eine weitere Möglichkeit zur Außendarstellung eines Unternehmens sind, sondern eben auch dabei helfen können wertvolle Inhalte, die im Zuge einer Inbound-Marketing-Strategie entwickelt wurden, weiter zu verbreiten. Auch wenn Social Media Posts sich nicht die überdimensionierte SEO-Relevanz entwickelt haben, wie man vor einigen Jahren noch dachte, so sind die Interaktionen auf Verlinkungen Sozialen Netzwerken dennoch ein Ranking-Faktor den auch Google in seiner Bewertung für Inhalte mit einbezieht. Eben auch aus diesen Gründen ist es natürlich hilfreich was man tun muss, um den perfekten Facebook oder Instagram-Post zu veröffentlichen. :::

:::globalTitle{:size="lg" :tag="h2" .mb-5} DER PERFEKTE FACEBOOK POST – SO KLAPPT ES ::: :::globalParagraph Bei Facebook gibt es generell drei unterschiedliche Typen von Postings: Bilder, Videos und Links. Dazu kommen noch reine Text-Postings, die allerdings einen eher geringeren Werbeeffekt haben. Am meisten werden Links bei Facebook gepostet, die von den zu verbreitenden Medien noch den geringsten Erfolg versprechen. Videos sind am besten geeignet und bieten eine doppelt so hohe Erfolgsquote wie Bilder. Links erreichen hingegen nur rund ein Viertel der Performance von Video-Beiträgen. :::

{.object-cover .max-w-full .mb-5}

:::globalParagraph Die erfolgreichsten Facebook Posts werden in der Woche platziert – 80 Prozent der Postings erfolge generell in der Woche, lediglich 20 Prozent erfolgen am Wochenende. Am Wochenende ist dabei die Rate der Interaktionen ein wenig besser. Für den perfekten Post auf Facebook sollte man dabei auch die Länge der Zeichen berücksichtigen. Um die 50 Zeichen bieten bei der Performance das größte Potential. Ganz ohne Text erreicht ein Post die schlechteste Performance. Heißt: Kurz und bündig auf den Inhalt hinweisen, das reicht. :::

:::globalTitle{:size="lg" :tag="h2" .mb-5} WELCHE ROLLE SPIELEN EMOJIS? ::: :::globalParagraph Immer noch wird in rund 80 Prozent der Facebook Posts auf Emojis verzichtet – dabei performen solche Postings deutlich schlechter. Ein bis drei Smileys sorgen zumeist für mehr Interaktionen und solche Beiträge können somit mehr Reichweite bringen. ::: :::globalParagraph Bei Hashtags verhält es sich bei Facebook anders. Meist wird darauf verzichtet, was allerdings nicht nachteilig ist. Ohne Hashtags funktionieren Facebook Posts oftmals besser – der Unterschied ist aber nur gering. :::

:::globalTitle{:size="lg" :tag="h2" .mb-5} AUF EINEN BLICK: DER PERFEKTE FACEBOOK POST ::: :::GlobalBlock{.ul-disk .mb-5}

• Emojis sollten in Maßen genutzt werden
• Mindestens ein, maximal 50 Zeichen sind optimal
• Videos bieten die beste Performance
• Beste Posting Zeit: das Wochenende :::

:::globalTitle{:size="lg" :tag="h2" .mb-5} SO VERÖFFENTLICHT MAN DEN PERFEKTEN INSTAGRAM POST ::: :::globalParagraph Bei Instagram bieten Bilder die meiste Präsenz – kein Wunder, sind doch rund drei Viertel hier Bildbeiträge. Videos und andere Inhalte – wie Karussell-Posts – machen den Rest aus. Videos bieten trotz der Bildermacht die bessere Instagram Performance. Bilder liegen sogar noch hinter den Karussell Postings. :::

{.object-cover .max-w-full .mb-5}

:::globalParagraph Für den optimalen Post bei Instagram ist das Wochenende ebenso gut geeignet – hier erscheinen nur rund 20 Prozent der Beiträge im Netzwerk. Die Rate an Interaktionen ist hier allerdings am größten, sodass sich dieser Zeitraum bezahlt machen kann. Zwischen einem und 50 Zeichen sind bei Instagram ebenfalls eine gute Idee und bieten eine ideale Performance. Aber auch gänzlich ohne Zeichen kann man eine optimale Reichweite erzielen. Auffällig ist weiterhin, dass Emojis keine große Rolle spielen müssen – eine hohe Interaktion bieten aber Postings mit rund zehn Emojis bei Instagram. :::

:::globalTitle{:size="lg" :tag="h2" .mb-5} HASHTAGS HABEN EINE GRÖSSERE RELEVANZ ::: :::globalParagraph Bei Instagram sind Hashtags deutlich wichtiger als bei Facebook. Sind sie bei Facebook in aller Regel überflüssig, gehören ein bis drei Hashtags bei Instagram zu einer optimalen Performance dazu. Ebenso sind aber auch Posts ganz ohne Hashtags oftmals erfolgreich, sie folgen direkt dahinter. Dies funktioniert meist aber nur bei Posts von erfolgreichen Stars, die bereits als Marke auftreten oder bei Accounts von Firmen und Influencern, die ohnehin eine große Reichweite haben. :::

:::globalTitle{:size="lg" :tag="h2" .mb-5} ZUSAMMENGEFASST: SO GELINGT DER PERFEKTE INSTAGRAM POST ::: :::GlobalBlock{.ul-disk .mb-5}

• Videos bieten die beste Performance
• Wochenendepostings sorgen für viele Interaktionen
• Hashtags sollten gezielt genutzt werden
• Text mit bis zu 50 Zeichen ist optimal :::

{.object-cover .max-w-full .mb-5}

::globalParagraph Nachdem die Schulen in Deutschland aufgrund des Corona-Virus für einige Wochen geschlossen sind, muss der Unterricht plötzlich von Zuhause aus weitergehen. Diese Entwicklung stellt viele Lehrkräfte vor eine Herausforderung. Ende 2019 bestätigten die Ergebnisse der ICLIS-Studie (International Computer and Information Literacy Study), welche die Medienkompetenz von Achtklässlerinnen und Achtklässlern untersucht, dass Deutschland viel mehr für digitale Bildung tun muss. ::

::globalTitle{:size="lg" .mb-5} CORONA ALS CHANCE FÜR DIGITALES LERNEN ::

::globalParagraph So verrückt es klingt, aber Corona könnte eine Chance sein - in Bezug auf die Digitalisierung der deutschen Schulen. 5.200 bayerische Schulen sind bereits Teil der digitalen Lernplattform des Landesmedienzentrums Bayern (mebis), die seit 2017 existiert. :: ::globalParagraph Und auch andere Länder ziehen nach: Für die Technische Hochschule Hamburg (TUHH) haben wir bei Blueshoe vor einiger Zeit die Website des Digital Learning Labs gebaut. Das Konzept für die digitale Lernplattform hat die Hochschule in Zusammenarbeit mit dem ebenfalls in Hamburg ansässigen Institut für Technische Bildung und Hochschuldidaktik (ITBH) erarbeitet. ::

{.object-cover .w-full .mb-5}

::globalTitle{:size="lg" .mb-5} WAS IST DAS DIGITAL LEARNING LAB? :: ::globalParagraph Das Digital Learning Lab ist eine Art digitales Kompetenzzentrum für die Unterrichtsgestaltung - von der Grundschule bis zum Abitur. Lehrkräfte finden hier Trends, Tools und Tutorials, um ihren Unterricht für eine digitalisierte Welt weiterzuentwickeln. Sie können selbst Unterrichtsbausteine hochladen oder sich von den Bausteinen der Kollegen inspirieren lassen. Mitmachen kann jede Lehrkraft, deutschlandweit und das komplett kostenlos. Die Schüler sollen durch die Einbeziehung der Plattform in den Unterricht verschiedene Kompetenzen erlernen bzw. weiterentwickeln. Diese sind: :: ::GlobalBlock{.ul-disk .mb-5}

• Suchen, Verarbeiten & Aufbewahren
• Analysieren & Reflektieren
• Problemlösen & Handeln
• Schützen & sicher Agieren
• Produzieren & Präsentieren
• Kommunizieren & Kooperieren :: ::globalParagraph Die drei inhaltlichen Elemente des Digital Learning Labs der Technischen Hochschule Hamburg sind: digitale Unterrichtsbausteine, eine umfangreiche Toolbox sowie Trendbeobachtungen durch relevante Forschungsergebnisse, Fortbildungen und inspirierende Praxisbeispiele. Im Folgenden stellen wir kurz die unterschiedlichen Elemente bzw. Funktionen vor: ::

::globalTitle{:size="lg" .mb-5} UNTERRICHTSBAUSTEINE :: ::globalParagraph Alle Themenbausteine können nach Unterrichtsfach oder Kompetenz gefiltert werden. Von “Quellen im Sachunterricht” über “Mobile Reporting - Videobeiträge mit dem Smartphone produzieren” bis hin zu “Eine Learning-App zum Thema gegensätzliche Adjektive erstellen” findet man auf der digitalen Lernplattform zahlreiche inspirierende Unterrichtsmodule. ::

{.object-cover .w-full .mb-5}

::globalTitle{:size="lg" .mb-5} TOOLS :: ::globalParagraph Um einen modernen Unterricht zu unterstützen, können verschiedene digitale Tools genutzt werden. Hierzu zählen neben Desktop-Programmen auch mobile Apps, Webseiten und Online-Plattformen. Zu den Tools, die verwendet werden können zählen u. a. Trello (Aufgaben- und Projektkooridnation), Draw.io (Diagramme und Visualisierungen) oder Wordpress (Blog-Erstellung). ::

{.object-cover .w-full .mb-5}

::globalTitle{:size="lg" .mb-5} TRENDS :: ::globalParagraph Die Welt der Schülerinnen und Schüler verändert sich rasend schnell, deshalb ist es das Ziel von Digital Learning Lab, Lehrkräften die Chance zu geben, sich schneller über wissenschaftliche Studien, Kooperationsprojekte und Forschungstrends zu informieren. Das Thema Fake News ist und war in letzter Zeit beispielsweise immer wieder ein wichtiger Diskussionsgegenstand in den Schulen. ::

{.object-cover .w-full .mb-5}

::globalTitle{:size="lg" .mb-5} FAZIT :: ::globalParagraph In Zeiten von Corona ist es wichtiger als je zuvor, dass Schülerinnen und Schüler von Zuhause aus lernen können. Die digitale Lernplattform Digital Learning Lab , für die wir bei Blueshoe die technische Entwicklung übernommen{.bs-link-blue} haben, bietet allen Lehrerinnen und Lehrern die Möglichkeit, ihren Unterrichtsstoff schneller und effizienter digital aufzubereiten. :: ::globalParagraph Eine wirklich gute und hilfreiche Sache - nicht nur aufgrund der Corona-Krise, sondern auch im Hinblick auf die noch fehlende Digitalisierung des deutschen Bildungssystems. ::

{.object-cover .max-w-full .mb-5}

:::globalParagraph „Wir beantworten unsere Kundenanfragen auch schon per E-Mail.“ Ist das Digitalisierung? Vielleicht. Ein wenig. Allerdings so wenig, dass es nicht einmal an der Oberfläche der Möglichkeiten kratzt, welche uns in der heutigen Zeit offen- und zur Verfügung stehen. ::: :::globalParagraph „Auf unserer Webseite sind alle Informationen zu finden, die unsere Kunden benötigen, um sich über unsere Produkte zu informieren.“ Das ist gut. Aber finden diese Kunden diese Informationen auch? Finden diese Kunden die Webseite selbst? Welche Informationen können über die Besucher der Webseite gesammelt werden? Fragen dieser Art lassen sich beliebig ausbauen und fortführen – und werden leider zu häufig von den Unternehmen selbst nicht gestellt. :::

:::globalTitle{:size="lg" .mb-5} DIGITALISIERUNG FÜR DEN SELBSTZWECK ::: :::globalParagraph Man hat eine Webseite, „weil sich das ja heute so gehört“. „Die Konkurrenz hat auch eine neue Webseite.“ Dies sollten nicht die Gründe sein, die eigene Webseite neu in Auftrag zu geben oder auch seine Prozesse zu digitalisieren. Die digitale Transformation eines Prozesses sollte immer als Investment in einen schlankeren und effektiveren Ablauf im Unternehmen gesehen werden, und nicht, um sich selbst, den Vorstand oder das Gewissen zu beruhigen. Doch was kann die Digitalisierung wirklich? Wie können wir die Industrie 4.0 erreichen und für uns nutzen? Die grundsätzlichen Fragen, die sich Unternehmen stellen müssen, werden oftmals nicht ausführlich und erschöpfend genug beantwortet: Was will ich mit meiner Digitalstrategie eigentlich erreichen und was muss ich dafür tun? :::

:::globalTitle{:size="lg" .mb-5} INDUSTRIE 4.0 UND DIGITALISIERUNG – EINE BEGRIFFSKLÄRUNG ::: :::globalParagraph Industrie 4.0 – eine Hightech-Strategie der Bundesregierung, welche darauf abzielt, die industrielle Produktion mit moderner Informations- und Kommunikationstechnik zu verknüpfen. Alle in der Produktion verankerten Systeme werden vernetzt und durch „intelligente Algorithmen“ angetrieben.[1] ::: :::globalParagraph Digitalisierung – die Umstrukturierung manueller Prozesse hin zu digitalen Prozessen, welche mittels Informations- und Kommunikationstechnologien abgebildet werden. Oftmals nennt man diese Veränderung auch „Digitale Transformation“.[2] ::: :::globalParagraph Beide Begriffe haben einen gemeinsamen Kern: ein oder mehrere Teile des Wertschöpfungsprozesses eines Unternehmens wird bzw. werden zunehmend technologisch abgebildet. Dadurch können in der Regel Kosten reduziert werden. Beispielsweise kann physischer Platz (z. B. im Lager) gewonnen oder die Kosten für Personal (durch das Einsetzen intelligenter Algorithmen) eingespart werden. ::: :::globalParagraph Diese Einsparungen steigern also direkt den Gewinn, der wiederum weitere Investitionen ermöglicht. Gibt es mehr Platz, so kann ein Unternehmen auch mehr lagern. Ist das Personal entlastet, so kann es eventuell andere Aufgaben übernehmen, welche nicht einfach durch Software abgebildet werden können. Je nach Situation kann sich eine Reinvestition der ersparten Ressourcen schnell bezahlt machen. ::: :::globalParagraph Doch solange ein Entscheider die Möglichkeiten nicht kennt, welche durch die Digitalisierung von Prozessen geboten werden können, ist auch keine sinnvolle Investition in die Optimierung von Prozessen möglich. :::

:::globalTitle{:size="lg" .mb-5} BEISPIELE FÜR DIGITALE TRANSFORMATION VON PROZESSEN ::: :::globalParagraph Täglich werden neue Möglichkeiten und Technologien angepriesen, die man nutzen kann, um seine Prozesse zu optimieren. Hier den Überblick zu behalten, ist extrem schwierig. Blueshoe hat hier immer das Ohr auf der Schiene, um entsprechend mit Rat und Tat zur Seite stehen zu können. Es folgt ein Auszug unserer Erfahrungen: :::

:::globalTitle{:size="lg" .mb-5} DIGITALE KUNDENGEWINNUNG ::: :::globalParagraph Muss die Neugewinnung von Kunden immer ein manueller Prozess sein? Definitiv nicht. Eine gute Webseite kann eine gute Möglichkeit zur Kundenakquise bieten. Allerdings reicht eine Webseite allein dafür nicht. Sie muss gepflegt werden, die Nutzer stets mit neuen Inhalten bereichert und begeistert werden und vor allem ist es wichtig, mit ihnen in Kontakt zu treten. Die Website ist schlussendlich nur das Vehikel, das ein Unternehmen einsetzen kann, um die gesetzten Ziele zu erreichen. Es geht in den meisten Fällen darum, Neu- und Mehrgeschäfte zu generieren. Dies kann nur erreicht werden, wenn ein Webauftritt auch in eine entsprechende Kommunikationsstrategie integriert ist. Achtung, ein weiteres Buzzword: Inbound Marketing. ::: :::globalParagraph Die Tools des Inbound Marketing sind dabei so vielfältig wie die Ansprüche von Kunden. Newsletter, Live-Chats, Landing Pages, E-Books, White Paper, Blogging, Social Media, Smart Content, Formulare, um nur einige zu nennen, können alles Möglichkeiten sein, den Vertrieb mittels einer Webseite zu unterstützen. Im Idealfall greifen all diese Teildisziplinen ineinander und unterstützen sich gegenseitig. Das heißt, der Nutzer wird durch die komplette Kette dieser Tools begleitet, so kann ein Unternehmen möglichst viel über ihn erfahren und ihn genau im richtigen Moment mit der passenden Ansprache abholen. :::

{.object-cover .max-w-full .mb-5}

:::globalParagraph Tools wie Zendesk und Intercom können dabei helfen, mit den Kunden direkt in Kontakt zu treten. Hiermit ist der entsprechende Mitarbeiter schneller im unmittelbaren Kontakt mit dem Kunden und kann diesem beratend zur Seite stehen oder gar Supportanfragen beantworten. ::: :::globalParagraph Ein weiteres nützliches Tool ist Hubspot. Es ermöglicht dem Nutzer, eine strukturierte Sales-Pipeline aufzusetzen und effektives Inbound-Marketing zu betreiben. Artikel, Newsletter, Formulare oder Landing Pages helfen dabei, einen unbekannten zu einem regelmäßigen Besucher oder gar zu einem Kunden konvertieren zu lassen. Es versetzt den Betreiber einer Webseite in die Lage, maßgeschneiderte Inhalte an den User auszuspielen. Ein Beispiel: Ein Besucher deiner Webseite liest sich die komplette Seite zu deinem Produkt A durch. Er schaut auch auf die Seite von Produkt B, aber nur flüchtig. Im Suchfeld deiner Webseite sucht der Nutzer nun nach weiteren Informationen zu Produkt A. Egal, ob er diese findet oder nicht, du weißt nun, dass dieser Nutzer anscheinend ein gewisses Interesse an Produkt A hat. Schaffe es jetzt, dass der Nutzer seine E-Mail-Adresse hinterlässt, sei es für einen Newsletter, ein Gewinnspiel oder im Live-Chat, paart Hubspot diese Daten mit dem zuvor gewonnenen Wissen. Dieses Wissen lässt sich nun in eine zielgenaue Kundenansprache umwandeln. ::: :::globalParagraph Die grundsätzliche Methodik dieses Vorgehens sieht dabei so aus: ::: :::globalParagraph Anziehen - Blogs, SEO, Kampagnen, Social Media ::: :::globalParagraph Konvertieren - Formulare, Landing Pages, Call-to-Action, E-Books, White Paper ::: :::globalParagraph Abschließen - CRM, Triggerketten, aktive Ansprache, Smart Content ::: :::globalParagraph Begeistern - Kundenservice, Umfragen, Prämienprogramme, Kunden werben Kunden, Bewertungen ::: :::globalParagraph Es gilt, diesen Prozess bis zur letzten Stufe perfekt durchzuführen. Ein begeisterter Kunde ist der perfekte Marken-Botschafter. Wer begeistert ist, empfiehlt weiter. :::

:::globalTitle{:size="lg" .mb-5} BESTELLEINGÄNGE OPTIMIEREN ::: :::globalParagraph OCR - Bot scannt BilddateienEin Bestandteil der Kommunikation mit dem Kunden ist beispielsweise das Aufnehmen von Bestellungen. Die folgende Statistik (2015) [3] beschäftigt sich mit den Kontaktkanälen der deutschen Customer Service Center. Dort werden sowohl Kundenanfragen beantwortet als auch Bestellungen entgegengenommen. Lediglich für zwei Medien scheinen die befragten Unternehmen zukünftig weder ein Wachstum noch einen Rückgang zu prognostizieren: Briefe/Postkarten und Fax. :::

{.object-cover .max-w-full .mb-5}

:::globalParagraph Es schreibt doch heute jeder E-Mails, oder? Nein. Offenbar nicht. Dies deckt sich mit den Erfahrungen, die Blueshoe gemacht hat. Ein großer Teil der Bestellungen, vor allem im B2B-Sektor, werden heute noch per Fax getätigt. Ist es möglich, einen so analogen Prozess zu digitalisieren? Natürlich! ::: :::globalParagraph Es ist möglich, ein Fax in Form einer PDF-Datei zu empfangen, beispielsweise per E-Mail. Der Text aus dieser PDF-Datei kann nun mithilfe von OCR-Software extrahiert werden. Dieser Text wird dann in ein strukturiertes Format gebracht und kann nun maschinell verarbeitet werden. Hierdurch liegen dann beispielsweise der Name des Bestellenden, die Bestellnummer, die bestellten Artikel und deren Anzahl sowie die Versandadresse vor, was es wiederum möglich macht, die Bestellung direkt ins Warenwirtschaftssystem zu übertragen. Ganz ohne den Aufwand, das Fax abtippen zu müssen. :::

:::globalTitle{:size="lg" .mb-5} FIRST-LEVEL-SUPPORT ::: :::globalParagraph Guter und schneller Support ist ein wichtiger Bestandteil der Kommunikation mit dem Kunden. So umfangreich die FAQs oder Hilfetexte eines Produktes auch sein mögen, der direkte Kontakt mit dem Kundensupport via Telefon oder Chat bleibt nicht aus. :::

{.object-cover .max-w-full .mb-5}

:::globalParagraph Dazu kommt die Tatsache, dass sich Anfragen von Kunden ähneln oder gar komplett gleichen. Bandansagen oder der Versuch, den Kunden dazu zu bringen, sich mithilfe von Nummerneingabe durch akustische Menüs zu navigieren, senken die Qualität einer Supportanfrage und nerven den Kunden nur. Doch gibt es Möglichkeiten, sich wiederholende Supportanfragen schon zu beantworten, bevor diese tatsächlich beim Support ankommen? ::: :::globalParagraph Chatbots sind mittlerweile in der Realität angekommen. Sie sind nicht mehr nur statische Antwortgeneratoren. Sie können auf unterschiedliche Formulierungen für denselben Sachverhalt gleichermaßen kompetent antworten. Weiterhin bieten sie die Möglichkeit, häufig gestellte Fragen automatisch zu beantworten. Mit einem guten Design der „Persönlichkeit“ des Chatbots wirkt der Chat nicht einmal künstlich. Ein Chatbot beantwortet häufige Fragen, berät oder verweist direkt an den richtigen Ansprechpartner. Wie könnte so etwas aussehen? ::: :::globalParagraph „Gibt es Produkt X in der Größe L?“ – „Ja, wir haben noch 3 Stück auf Lager. Du findest das Produkt hier.“ ::: :::globalParagraph „Wie lange dauert es, bis Produkt X wieder auf Lager ist?“ -‒ „Das kann ich dir leider nicht sagen, aber ich habe deine Anfrage an einen Mitarbeiter weitergeleitet.“ ::: :::globalParagraph Je nach Wissensstand des Chatbots kann dieser dem Kunden weiterhelfen, diesen an einen Mitarbeiter aus dem Support weiterleiten oder gar auf die richtige Telefonnummer verweisen. :::

:::globalTitle{:size="lg" .mb-5} OHNE DIGITALISIERUNG KEIN ÜBERLEBEN – DER MITTELSTAND MUSS ANGREIFEN ::: :::globalParagraph Auch wenn die zuvor genannten Schritte nicht auf jede Unternehmung mit ihren individuellen Prozessen anwendbar sind, ist die digitale Transformation ein wichtiger Schritt zum Fortbestand und zur Weiterentwicklung unserer Wirtschaft. Es lassen sich garantiert in jedem Unternehmen Möglichkeiten finden, Prozesse zu optimieren und zu digitalisieren. Tun wir das nicht, bleiben wir stehen oder werden gar von der Konkurrenz überholt. Die großen Dax-Unternehmen haben das längst begriffen und eine Digitalisierungsagenda aufgesetzt. Dennoch werden sie es schwer haben, denn eine radikale Transformation ist in Dickschiff-Unternehmen mit mehreren Tausend Mitarbeitern ein zäher Prozess, der von vielen Widrigkeiten geprägt sein kann. Der Vorteil vieler kleiner Start-ups ist hierbei, dass diese ihre Probleme oftmals sehr digital lösen und dadurch auch ihren Kunden schnellere Antwort- oder Lieferzeiten bieten können. Mittelständische Unternehmungen haben wiederum den Vorteil, durch ihre Vertriebsstruktur, ihre Bestandskunden, ihre Mitarbeiter und ihr Kapital ihre Prozesse mithilfe der Digitalisierung auszubauen und somit ihre Position am Markt zu sichern. ::: :::globalParagraph Es ist wichtig, heute aktiv die Digitalisierung der eigenen Prozesse anzugehen, damit morgen ein Fortbestand der freien Marktwirtschaft möglich ist. ::: :::globalParagraph Der Mittelstand wirkt diesbezüglich noch oftmals viel zu behäbig, obwohl er eigentlich im Vorteil ist. Der klassische Mittelständler hat das Potential, schneller Entscheidungen zu treffen und umzusetzen als ein Dax-Konzern. Auf die gleiche Geschwindigkeit wie ein Start-up wird er nicht kommen, kann aber dafür Vorteile in anderen Teilbereichen ausspielen: ::: :::globalParagraph Markenbekanntheit, Budget oder Markterfahrung sind weitere Beispiele. Konzentrieren sich die Mittelständler aktiv darauf, eine digitale Agenda zu entwickeln und diese stringent und mit Unterstützung kompetenter Partner umzusetzen, so ist die digitale Transformation eher eine „Möglichkeit“ als eine „Gefahr“. Einzig das Mindset muss stimmen. ::: :::globalParagraph Also, liebe Mittelständler: in die Hände gespuckt und los geht’s! ::: :::globalParagraph Gern beraten wir dich unverbindlich zu Themen der digitalen Transformation. :::

:::globalParagraph [1] https://de.wikipedia.org/wiki/Industrie_4.0{.bs-link-blue :target="_blank"}

[2] https://de.wikipedia.org/wiki/Digitalisierung{.bs-link-blue :target="_blank"}

[3] https://de.statista.com/statistik/daten/studie/499494/umfrage/umfrage-zu-kundenkanaelen-im-deutschen-customer-service/{.bs-link-blue :target="_blank"} :::

{.object-cover .max-w-full .mb-5}

In diesem Guide führen wir dich durch die Welt des Django Cachings. Wir stellen dir den "magischen" Helfer Django Cachalot{target="_blank"} vor, der dir viel Arbeit abnimmt, und vergleichen ihn mit den mächtigen Bordmitteln von Django – vom Template-Caching bis zur granularen Low-Level API. Am Ende wirst du genau wissen, welche Technik für deinen Anwendungsfall die richtige ist.

1. Warum ist Caching in Django unverzichtbar? Die Jagd nach Millisekunden

Wenn eine Django-App langsam wird, liegt das fast immer an denselben Verdächtigen:

• Zu viele oder zu teure Datenbankabfragen
• Komplexes Template-Rendering
• Rechenintensive Logik in den Views

Diese Probleme summieren sich zu langen Ladezeiten, ungeduldigen Usern und schlechteren SEO-Rankings.

Caching ist hier der Gamechanger. Es speichert häufig genutzte Ergebnisse zwischen und liefert sie blitzschnell aus, ohne dass Django alles neu berechnen muss. Das spart Serverlast, senkt den Datenbank-Load und verbessert die User Experience enorm.

2. Django Cachalot: Der Autopilot für dein ORM

Django Cachalot ist ein Open-Source-Paket (https://django-cachalot.readthedocs.io/en/latest/{target="_blank"}), das automatisch alle ORM-Abfragen cached. Du musst dafür keine einzige Zeile Cache-Logik schreiben.

Wie funktioniert es?

Cachalot merkt sich die Ergebnisse deiner ORM-Queries und löscht sie automatisch, sobald du Daten veränderst, also bei INSERT, UPDATE oder DELETE.
Die Auto-Invalidierung sorgt dafür, dass dein Cache immer aktuell bleibt, ohne dass du dich aktiv darum kümmern musst.

Der große Vorteil: Auto-Invalidierung

Wenn also z.b. ein neuer Post gespeichert wird:

post.title = "Neuer Titel"
post.save()

Dann invalidert Cachalot automatisch:

• alle gecachten Querysets des Post-Models
• Querysets, die über ForeignKeys auf Post zugreifen
• Querysets, die Joins enthalten, die durch Post beeinflusst werden

Setup in 3 Schritten:

pip install django-cachalot

Füge anschließend in deiner settings.py hinzu:

INSTALLED_APPS = [
    # ...
    "cachalot",
]

Wähle dein Cache-Backend, zum Beispiel Redis:

CACHES = {
    "default": {
        "BACKEND": "django.core.cache.backends.redis.RedisCache",
        "LOCATION": "redis://127.0.0.1:6379/1",
    }
}

Vorteile von Django Cachalot

• Enorme Zeitersparnis bei der Entwicklung
• Keine manuelle Cache-Logik im Code nötig
• Besonders effektiv für leseintensive Anwendungen

Nachteile und Grenzen von Django Cachalot

• Weniger granulare Kontrolle
• Mögliche Fallstricke bei sehr komplexen Abfragen oder Raw-SQL
• Manchmal werden veraltete Ergebnisse ausgeliefert, wenn die automatische Invalidierung nicht greift

3. Das Standard-Repertoire: Djangos eingebaute Caching-Werkzeuge

Manchmal brauchst du mehr Kontrolle, als Cachalot dir bieten kann. In diesen Fällen lohnen sich die eingebauten Caching-Tools von Django.

3a) Template-Fragment-Caching: Die statischen Inseln

Template-Fragment-Caching eignet sich, wenn du nur bestimmte Bereiche einer Seite cachen möchtest, zum Beispiel Navigationen, Teaserboxen oder Sidebar-Komponenten mit vielen Datenbankabfragen.

{% raw %}{% load cache %}{% endraw %}
{% raw %}{% cache 600 sidebar %}{% endraw %}
  <div class="sidebar">
    {% raw %}{% for post in popular_posts %}{% endraw %}
      <a href="{{ post.get_absolute_url }}">{{ post.title }}</a>
    {% raw %}{% endfor %}{% endraw %}
  </div>
{% raw %}{% endcache %}{% endraw %}

3b) View-Level-Caching: Die ganze Seite auf einmal

Wenn eine Seite für alle Besucher gleich aussieht, zum Beispiel eine Blog-Übersicht oder eine Landingpage, kannst du die komplette View cachen.

from django.views.decorators.cache import cache_page
from django.shortcuts import render
from .models import Post

@cache_page(60 * 15)  # 15 Minuten
def blog_list(request):
    posts = Post.objects.all()
    return render(request, "blog/list.html", {"posts": posts})

3c) Die Low-Level Cache API: Maximale Kontrolle für Profis

Mit der Low-Level API steuerst du selbst, welche Daten in den Cache gelangen, wie lange sie dort bleiben und wann sie erneuert werden sollen. Perfekt für komplexe Objekte, externe API-Calls oder spezifische QuerySets.

from django.core.cache import cache

def get_weather_data(city):
    cache_key = f"weather_{city}"
    data = cache.get(cache_key)

    if not data:
        # Externer API Call, zum Beispiel OpenWeather
        data = fetch_weather_from_api(city)
        cache.set(cache_key, data, timeout=3600)  # 1 Stunde

    return data

Super! Du kennst jetzt die Grundlagen von Django Cachalot und den eingebauten Caching-Mechanismen. Aber wann setzt du was ein? Der nächste Abschnitt hilft dir bei der Entscheidung.

4. Head-to-Head: Cachalot vs. Low-Level API, wann nehme ich was

In vielen Projekten stellt sich die Frage: Reicht mir ein automatisches Tool wie Django Cachalot oder brauche ich die volle Kontrolle der Low-Level API. Die folgende Tabelle hilft dir bei der Einordnung.

| Kriterium | Django Cachalot | Low-Level API | | :---------------- | :------------------------------- | :------------------------------------------- | | Kontrolle | Gering, da automatisch | Maximal, da vollständig manuell | | Einrichtungsaufwand | Sehr gering | Eher hoch | | Anwendungsbereich | ORM-Abfragen | Beliebige Objekte und Datenquellen | | Ideal für | Schnelle Erfolge, leseintensive Seiten | Komplexe Logik und feines Performance Tuning |

5. Praxis-Guide: Die richtige Strategie für dein Projekt

Die Theorie ist schön, aber wie sieht das in echten Projekten aus. Schau dir diese drei typische Szenarien an.

Szenario 1: Ein Blog oder ein News-Portal

Viele Lesezugriffe, vergleichsweise wenig Schreibzugriffe, dafür viele wiederkehrende Besucher.

Empfehlung:

• Nutze Django Cachalot für die Artikellisten, zum Beispiel für die Startseite und Kategorien.
• Nutze View-Level-Caching für die Detailseiten, also einzelne Artikel, die sich nicht bei jedem Seitenaufruf ändern.

Szenario 2: Ein E-Commerce-Shop

Im Shop werden Produktdaten eher selten geändert, aber Warenkörbe und personalisierte Empfehlungen sind sehr dynamisch.

Empfehlung:

• Setze Template-Fragment-Caching für Produktlisten und Kategorieseiten ein.
• Verwende die Low-Level API für Warenkorb, Checkout und personalisierte Empfehlungen, da hier stark nutzerabhängige Daten im Spiel sind.

Szenario 3: Eine komplexe B2B-Anwendung mit vielen Daten

In B2B-Anwendungen werden oft viele Daten aggregiert, gefiltert und berechnet. Die Business Logik ist meist deutlich komplexer.

Empfehlung:

• Nutze die Low-Level API, um berechnete Kennzahlen, Reports oder Dashboards gezielt zu cachen.
• Nutze Django Cachalot für Standard-Listenansichten, also dort, wo einfach nur viele Datensätze angezeigt werden.

6. Fazit: Der Mix machts

Caching ist kein Alles-oder-nichts-Feature, sondern ein Baukasten. Mit den richtigen Bausteinen sorgst du dafür, dass deine Django-App sich schnell anfühlt, selbst wenn im Hintergrund komplexe Dinge passieren.

Eine sinnvolle Herangehensweise ist:

• Starte einfach, zum Beispiel mit Django Cachalot oder View-Level-Caching.
• Miss die Wirkung mit Werkzeugen wie der Django Debug Toolbar{target="_blank"}.
• Optimiere gezielt dort nach, wo du die größten Performance Probleme siehst, zum Beispiel mit der Low-Level API.

Die Faustregel lautet:

Beginne so einfach wie möglich und füge Komplexität nur dort hinzu, wo sie sich wirklich lohnt.

Welche Caching-Technik ist dein Favorit für Django-Projekte. Hast du noch einen Geheimtipp. Teile deine Erfahrungen in den Kommentaren und hilf anderen Entwicklern dabei, ihre Django Performance zu verbessern.

7. Häufig gestellte Fragen (FAQ)

Kann ich Django Cachalot mit Redis verwenden.

Ja, das ist sogar eine sehr gängige Kombination. Redis ist extrem schnell und als Cache-Backend sehr zuverlässig. Du musst lediglich dein CACHES Setting entsprechend konfigurieren.

Wie messe ich, ob mein Caching funktioniert.

Du kannst die Django Debug Toolbar nutzen, um zu sehen, wie viele Datenbankabfragen pro Request durchgeführt werden und ob sich diese Zahl nach dem Einbau von Caching verringert. Zusätzlich helfen Monitoring Tools wie Sentry Performance oder APM Lösungen, um Antwortzeiten im Blick zu behalten.

Veraltet der Cache mit Django Cachalot niemals.

Doch, Django Cachalot invalidiert automatisch alle gecachten Ergebnisse, sobald sich Daten ändern, zum Beispiel durch Speichern im Admin oder durch eine API. Dadurch stellst du sicher, dass Nutzer keine veralteten Daten sehen.

Wann sollte man den Django Low-Level Cache verwenden.

Die Low-Level Cache API lohnt sich immer dann, wenn du selbst bestimmen möchtest, welche Daten gecached werden und wie lange. Typische Beispiele sind:

• Externe API Requests
• Teure Berechnungen
• Komplexe zusammengesetzte Objekte, die aus mehreren Quellen stammen

Kann Caching Fehler verursachen.

Caching kann dann Probleme machen, wenn veraltete Daten zurückgegeben werden oder wenn sich Business Logik ändert, aber der Cache noch alte Ergebnisse enthält. Wichtig ist deshalb eine durchdachte Invalidierungsstrategie. Bei Django Cachalot wird dieser Teil bereits stark vereinfacht, da Änderungen an Modellen automatisch zum Löschen der betroffenen Cache-Einträge führen.

Kennst du das? Eine Bestellung geht ein – und plötzlich hängt deine Django-App, weil gerade E-Mails verschickt oder PDFs generiert werden? Hier kommt Django Celery{target="_blank"} ins Spiel. Die Integration in deine Django-Anwendung ermöglicht leistungsstarke, asynchrone Aufgabenverarbeitung. Erfahre, wie du Django-Celery effektiv einrichtest und für Produktionsumgebungen optimierst, um deine Anwendung stabil und performant zu machen.

Warum Django-Celery?

Viele Aufgaben in Webanwendungen müssen nicht synchron abgearbeitet werden. Dazu zählen z. B. das Versenden von E-Mails, das Generieren von PDFs oder das Verarbeiten großer Datenmengen. Genau hier kommt Celery ins Spiel: Es ermöglicht dir, diese Aufgaben im Hintergrund (asynchron) zu erledigen.

Typische Anwendungsfälle für Celery in Django:

• E-Mail-Versand
• Bildverarbeitung
• Externe API-Aufrufe
• Datenbankbereinigung oder -analyse
• Wiederkehrende Aufgaben (z. B. Reportgenerierung mit celery beat)

So richtest du Celery ein

1. Installation der notwendigen Pakete

pip install celery redis

Falls du periodische Tasks brauchst:

pip install django-celery-beat

2. Projektstruktur vorbereiten

Erstelle eine Datei celery.py in deinem Projektordner:

# myproject/celery.py
import os
from celery import Celery

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "myproject.settings")

app = Celery("myproject")
app.config_from_object("django.conf:settings", namespace="CELERY")
app.autodiscover_tasks()

In __init__.py:

from .celery import app as celery_app
__all__ = ["celery_app"]

3. Beispielkonfiguration in settings.py

CELERY_BROKER_URL = "redis://localhost:6379/0"
CELERY_RESULT_BACKEND = "redis://localhost:6379/0"
CELERY_ACCEPT_CONTENT = ["json"]
CELERY_TASK_SERIALIZER = "json"

Teste dein Setup mit einem simplen Task.

So sehen Celery-Tasks in Django aus

1. Einfacher Task

@shared_task
def send_email_to_user(user_id):
    print(f"E-Mail an User {user_id} gesendet")

Aufgerufen wird dieser jetzt mit:

send_email_to_user.delay(user.id)

.delay() vs. .apply_async()

• .delay() ist ein Shortcut für .apply_async() mit Standardparametern.
• Mit .apply_async() kannst du z. B. countdown, eta oder retry nutzen.

2. Komplexere Aufgaben mit Transaktionen und Logging

@shared_task
def run_customer_basket_groups_processing(basket_id):
    from shop.order.processing import BasketProcessor
    from shop.models import Basket
    from shop.exceptions import ReachedAdvertisingMediumQuotaWarning
    from django.db import transaction
    import logging

    logger = logging.getLogger(__name__)

    basket = Basket.objects.get(pk=basket_id)

    try:
        if basket.user.groups.exists():
            with transaction.atomic():
                for cbg in basket.customerbasketgroups.all():
                    user = cbg.consignee.user
                    customer_basket = Basket.objects.create(
                        user=user,
                        field_staff=basket.user,
                        discount=basket.discount,
                        discount_code=basket.discount_code,
                        shipment_options=basket.shipment_options
                    )
                    customer_basket.add_basket_lines_to_basket(
                        cbg.basket_lines, as_stock_order=True, check_quotas=False
                    )
                    basket_processor = BasketProcessor(basket=customer_basket)
                    basket_processor.process_basket()
    except Exception as e:
        logger.error(f"Fehler beim Verarbeiten von Basket {basket_id}: {e}")

transaction.atomic() sorgt dafür, dass bei einem Fehler keine halbfertige Bestellung angelegt wird.

Periodische Aufgaben mit django-celery-beat

Migrationen:

python manage.py migrate

App aktivieren:

INSTALLED_APPS += ["django_celery_beat"]

Beispieltask anlegen:

from django_celery_beat.models import PeriodicTask, IntervalSchedule

schedule, _ = IntervalSchedule.objects.get_or_create(every=10, period=IntervalSchedule.SECONDS)
PeriodicTask.objects.create(interval=schedule, name="Beispiel Task", task="myapp.tasks.send_email_to_user")

Fertig! Deine erste periodische Aufgabe ist erstellt. Das bedeutet: Celery ruft in diesem Intervall die Task auf – etwa um regelmäßig eine Benachrichtigung oder Erinnerungs-E-Mail zu versenden. Diese Konfiguration ist besonders nützlich für wiederkehrende Aufgaben, die zeitgesteuert ausgelöst werden sollen.

Die Admin-Oberfläche zeigt dir dann alle eingerichteten Tasks mit Status und Zeitplan – ideal für Monitoring und Management im Live-Betrieb.

Celery in der Produktion

1. Worker starten

celery -A myproject worker -l info

2. Beat starten

celery -A myproject beat -l info

3. Deployment-Tools nutzen

• Verwende Supervisor oder systemd zum Prozessmanagement.
• Logge Fehler z. B. mit Sentry oder externen Tools.
• Implementiere Retries bei temporären Fehlern.

Häufige Stolpersteine

• Redis nicht gestartet → ConnectionRefusedError
• .autodiscover_tasks() vergessen → Tasks werden nicht gefunden
• Task hängt → Worker nicht gestartet oder Deadlock in Datenbank

Best Practices für saubere Tasks

• Halte Tasks klein, schnell und wiederholbar
• Nutze Logging (z. B. logger.info(), logger.error())
• Plane Timeouts und Retry-Logik ein
• Verwende transaction.atomic() bei Datenbank-Aktionen
• Verwende .apply_async(countdown=...) für geplante Ausführung

Fazit

Celery ist ein kraftvolles Werkzeug, das deine Django-App flexibler, schneller und robuster machen kann. Ob einfache E-Mail-Tasks oder komplexe Bestellverarbeitung - mit dem richtigen Setup und ein paar Best Practices bist du dann auf der sicheren Seite.

Lege jetzt los - und bringe Django-Celery in deine App!

{.object-cover .max-w-full .mb-5}

:::globalTitle{:size="lg" .mb-5} Django CMS: Das großartige Content-Management-System ::: :::globalParagraph Es zeichnet sich durch eine hervorragende Usability, gute Wartbarkeit und leichte Erweiterbarkeit aus. Wie gut es letztendlich auf den Redakteur/Benutzer angepasst ist liegt letztendlich, in den meisten Fällen, am Entwickler selbst. Da uns stets die Usability unserer Lösungen am Herzen liegt, haben wir früh angefangen eine Lösung zum Erstellen des Layouts von Seiten im CMS gesucht. Bei dieser Suche stößt man schnell auf djangocms-column und aldryn-bootstrap3. Im Folgenden möchte ich diese 2 Plugins analysieren und gegenüberstellen. Daraufhin folgt eine Vorstellung unserer eigenen Lösung: djangocms-layouter. :::

:::globalTitle{:size="lg" .mb-5} Djangocms-column ::: :::globalParagraph Djangocms-column ist ein simples Plugin zum Strukturieren der Seiteninhalte. Fügt man ein „Mehrspalten“-Plugin im Struktur-Modus hinzu, so In erscheint folgender Dialog. :::

{.object-cover .max-w-full .mb-5}

:::globalParagraph Hier kann der Nutzer nun einstellen wie viele Spalten mit welcher Breite erstellt werden sollen. Die Breite der Spalten verhält sich auf allen Bildschirmgrößen gleich. Spalten können im Nachhinein noch in ihrer Breite angepasst werden, sodass auch Spalten mit unterschiedlichen Breiten innerhalb eines Mehrspalten-Plugins möglich sind: :::

{.object-cover .max-w-full .mb-5}

:::globalParagraph In jede der Spalten können nun nach Belieben weitere Plugins hinzugefügt werden. :::

{.object-cover .max-w-full .mb-5}

:::globalParagraph Bei der oben dargestellten Variante, stellt sich schnell heraus, dass die erste Spalte (mit 50%) nicht dargestellt wird, solange diese keinen Inhalt hat. Man kann also keine Inhalte vom linken Rand wegschieben. :::

:::globalTitle{:size="lg" .mb-5} BOOTSTRAP IN DJANGO CMS: ALDRYN-BOOTSTRAP3 ::: :::globalParagraph Das Bootstrap3 Plugin von Aldryn/Divio ist definitiv komplexer als djangocms-columns. Hier wird die Grid Logik, welche sonst Frontend-Entwickler implementieren, dem User als Werkzeug in die Hand gegeben. Fügt der Nutzer eine Zeile (Row) hinzu, so erscheint folgender Dialog: :::

{.object-cover .max-w-full .mb-5}

:::globalParagraph Hier kann der Nutzer nun entscheiden, wie viele Spalten (Columns) er erstellen möchte, und wie diese sich auf verschiedenen Bildschirmgrößen verhalten. ::: :::globalParagraph Hierzu ein kurzer Exkurs zu Bootstrap3. Das populäre Frontend-Framework sieht vor, dass man seine Inhalte in Zeilen gliedert, welche wiederrum in Spalten unterteilt sind. Insgesamt ist der Platz von 12 Spalten zu vergeben. Dabei kann eine Spalte verschiedene Breiten einnehmen und zwar 1 bis 12. Entsprechend kann man in einer Zeile beispielsweise 12 Spalten der Breite 1 einordnen oder auch 6 Spalten der Breite 2. Die Breite der Spalten kann man basierend auf der Breite des Endgerätes auf dem die Website angeschaut wird definieren. Daraus ergibt sich, dass eine Zeile auf dem Desktop 6 Spalten der Breite 2 hat, auf dem Tablet werden in der Darstellung dann aber 2 Zeilen mit jeweils 3 Zeilen der Breite 4. Lange Rede, kurzer Sinn auf http://getbootstrap.com/css/#grid-example-mixed lässt sich sehr gut beobachten, wie sich entsprechende Spalten verhalten. ::: :::globalParagraph Hat man nun seine Zeile mit ihren Spalten erstellt, kann man Inhalte in die Spalten ziehen. :::

{.object-cover .max-w-full .mb-5}

:::globalParagraph Somit gibt das Aldryn-Bootstrap 3 Plugin dem Nutzer quasi die Freiheit des Frontend-Entwicklers bei der Strukturierung der Inhalte. Weiterhin können noch Klassen ergänzt, sowie der Tag für die Spalte gesetzt werden. :::

:::globalTitle{:size="lg" .mb-5} AUSWERTUNG VON DJANGOCMS-COLUMN UND ALDRYNS BOOTSTRAP3 PLUGIN ::: :::globalParagraph Ein Fazit zu djangocms-column lässt sich schnell ziehen: Das Plugin bietet wenig Flexibilität, funktioniert nicht responsive und bietet auch keine visuelle Unterstützung beim Anlegen der Seitenstruktur. Vielleicht war es auch gar nicht die Absicht des Entwicklers responsive Funktionalität in dem Plugin zu verankern. Es eignet sich lediglich in solchen Fällen, in denen die Anordnung der Inhalte auf Endgeräten verschiedener Größe gleich sein sollte. Dies ist aber eher untypisch. ::: :::globalParagraph Da das Aldryn Bootstrap3 Plugin wesentlich komplexer ist, muss man hier beim Ziehen eines Fazits auch tiefer einsteigen. Es ist vorrangig sehr gut geeignet Inhalte für verschiedene Bildschirmgrößen anzuordnen. Durch die Möglichkeit die Tags zu bestimmen, kann eine saubere Strukturierung der Seite gewährleistet werden. Weiterhin können durch das Feld „Classes“ CSS-Klassen ergänzt werden, wodurch der Nutzer auch Zugriff auf das Styling der Inhalte bekommt. ::: :::globalParagraph Bei all der Flexibilität, die das Bootstrap3 Plugin bietet, die Bedienung ist für einen durchschnittlichen Autor oder Editor durchaus nicht leicht, da meistens das Wissen über das Grid-System und seine Funktionsweise nicht bekannt ist. :::

:::globalTitle{:size="lg" .mb-5} Django CMS LAYOUTER AUF BOOTSTRAP BASIS ::: :::globalParagraph Die Strukturierung/Anordnung der Inhalte, ohne komplizierte Bedienung oder Spezialwissen. Dies ist das hauptsächliche Ziel, welches der Django CMS{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} Layouter erreichen sollte. Der Nutzer sollte intuitiv wählen können, wie Inhalte auf seinem Bildschirm angeordnet sein sollten, sich jedoch nicht um die Optimierung auf anderen Auflösungen kümmern müssen. Somit haben wir die Entscheidung getroffen, vorerst, auf gewisse Flexibilität zu verzichten, zugunsten von einer einfacheren Bedienung. Der Nutzer sollte das Grid nicht nur in der Strukturansicht sehen können, sondern auch in der Inhaltsansicht. Dies würde das Verständnis für den Aufbau und die Strukturierung von Seiten maßgeblich vereinfachen. Die Baumstruktur in der Strukturansicht von Django CMS{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} sollte nicht unnötig tief sein; diese führt sonst auch zur einer Erschwerung der Bearbeitung der Inhalte. Fehler sollten dem Nutzer kenntlich gemacht werden und das Layout der Seite möglichst wenig beeinflussen. ::: :::globalParagraph Aus diesen Gedanken heraus haben wir Django CMS Layouter gestartet. ::: :::globalParagraph Ergebnis ist eine schlanke Administration zur Strukturierung der eignen Plugins: :::

{.object-cover .max-w-full .mb-5}

:::globalParagraph Man wählt die Struktur und den Abstand nach außen, welche/n man für seine Plugins vorsehen möchte. Wird ein spezielles Styling benötigt, so kann man dies einfach per CSS Klassen, getrennt durch Leerzeichen hinzufügen. ::: :::globalParagraph Django-CMS Layouter basiert auf dem populären Frontend-Framework Bootstrap. Dadurch, dass Zeilen und Spalten gleichzeitig angelegt werden, hat man eine flache Baustruktur in der Strukturansicht. ::: :::globalParagraph Fügt man zu viele Kind-Plugins in das Django CMS{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} Layouter Plugin ein, so wird man durch einen roten Warntext darauf aufmerksam gemacht: :::

{.object-cover .max-w-full .mb-5}

:::globalParagraph Nutzer haben nun die Möglichkeit, ihre Plugins einfach in einen Container zu ziehen, welcher sich um die Anordnung kümmert. Die Anordnung auf kleineren Bildschirmen, wie Tablets und Smartphones wird ebenfalls automatisch über das Plugin gesteuert und erleichtert somit auch den Umgang für den Nutzer. ::: :::globalParagraph Um die Anordnung der Plugins in der Inhaltsansicht besser zu verstehen wurde die Toolbar um einen Button ergänzt: Toggle Grid. :::

{.object-cover .max-w-full .mb-5}

:::globalParagraph Dieser Button ermöglicht es das Grid, welches die Inhalte umschließt anzuzeigen. Hierdurch bekommt der Nutzer nun einen besseren Eindruck, warum seine Inhalte entsprechend angeordnet sind. :::

{.object-cover .max-w-full .mb-5}

:::globalParagraph Mit der erleichterten Bedienung kommt, wie so oft, auch ein Verlust an Flexibilität. Im Gegensatz zum Aldryn Bootstrap 3 Plugin ist es mit dem Django CMS{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} Layouter nicht möglich die Darstellung der Spalten auf den verschiedenen Auflösungen granular zu steuern. Weiterhin sind die Spalten im Django CMS Layouter immer zentriert, sobald man Ihnen einen Rand zuweist, in Aldryn’s Bootstrap 3 Plugin, kann man den Spalten auch einzeln Offsets zuweisen und somit die Einrückung im Detail steuern. Um Spalten im Grid zu überspringen ist ein „Spacer-Plugin“ angedacht, aber noch nicht verfügbar. ::: :::globalParagraph Welches Plugin sollte man nun wann verwenden? Wir empfehlen bei erfahrenen Nutzern, die bestenfalls sogar mit dem Bootstrap 3 Framework vertraut sind, auf Aldryn Bootstrap 3 zu setzen. Dieses bietet eine großartige Flexibilität, wird aktiv gepflegt und eignet sich sehr gut um Inhalte zu strukturieren. ::: :::globalParagraph Für Autoren und Editoren, welche nicht entsprechende Erfahrungen in der Gestaltung von Webseiten haben, empfehlen wir unseren Django CMS{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} Layouter. ::: :::globalParagraph Als Nachtrag noch ein kleines GIF zum Django CMS{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} Layouter: :::

{.object-cover .max-w-full .mb-5}

:::globalParagraph Der Django CMS Layouter ist Open-Source und kann hier gefunden werden: ::: :::globalParagraph https://github.com/Blueshoe/djangocms-layouter{.bs-link-blue :target="_blank"} ::: :::globalParagraph Und hier geht's zu Projekten{.bs-link-blue} die wir mit Django CMS{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} umgesetzt haben . :::

{.object-cover .max-w-full .mb-5}

:::globalTitle{:size="lg" :tag="h2" .mb-5} DJANGO CMS PLUGINS - LAYOUTING UND GROSSE FREIHEITE ::: :::globalParagraph Bei der Entwicklung von Templates in Django CMS{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} werden sogenannte Platzhalter in diesen eingesetzt. Die Platzhalter können dann später von den Nutzern des CMS mit Plugins befüllt werden. ::: :::globalParagraph Plugins erlauben dem Nutzer Seiteninhalte zu erstellen und zu strukturieren. Vom einfachen Darstellen eines Bildes, über Tabellen, Videos, Kacheln ist wirklich alles möglich. Viele Plugins gibt es bereits für DjangoCMS{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid}, die Entwicklung von maßgeschneiderten Plugins ist sehr gut dokumentiert. Plugins werden immer innerhalb der Platzhalter eingesetzt. In der Strukturansicht kann man ihre Reihenfolge einfach per Drag’n’Drop manipulieren. In der Inhaltsansicht lassen sich ihre Inhalte einfach per Doppelklick bearbeiten. :::

{.object-cover .max-w-full .mb-5}

:::globalParagraph Plugins sind verschachtelbar. Beispielsweise kann ein Textplugin auch Bilder enthalten. ::: :::globalParagraph Alle Plugins unterliegen dem Entwurf- und Veröffentlichen-Status einer Seite. Änderungen an Plugins werden also erst veröffentlicht, wenn der blaue Button „Änderungen Veröffentlichen“ oben rechts in der Toolbar betätigt wird. :::

:::globalTitle{:size="lg" :tag="h2" .mb-5} DJANGO CMS PLUGINS - WAS SIND DIE STANDARDS? ::: :::globalParagraph Welche Plugins sind bei Django CMS{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} vorinstalliert? Die Dokumentation von django CMS bietet eine Liste der django CMS Core Addons, welche mit der Installation des CMS bereits vorinstalliert sind. Diese umfasst die folgenden Plugins: ::: :::GlobalBlock{.ul-disk .mb-5}

• Django Filer – Management von Dateien und Bildern
• django CMS Text CKEditor – der „standard“ WYSIWYG Editor für Benutzer von Django CMS
• django CMS Link – zum Verlinken von Inhalten
• django CMS Picture – zum Hinzufügen von Bildern
• django CMS File – zum Einbinden von Dateien
• django CMS Style - für Nutzer, welche manuelle Anpassungen am Styling vornehmen wollen
• django CMS Snippet – zum Einfügen von HTML Code
• django CMS Audio – zum Einfügen von Audio Dateien
• django CMS Video – zum Einfügen von Videos (intern und extern z.B. Youtube)
• django CMS GoogleMap – Darstellung von Google Maps, basierend auf Adressen oder Koordinaten :::

:::globalParagraph Natürlich ist dies nicht das Ende der Fahnenstange. Es gibt zahlreiche weitere Plugins, welche von der Community entwickelt, betreut und konstant verbessert werden. ::: :::globalParagraph Weiterhin besteht natürlich immer die Möglichkeit Individual- oder Neuentwicklung für Plugins zu betreiben. Später in diesem Artikel ist ein Absatz zur Entwicklung von Plugins zu finden – und es ist gar nicht so schwer, wie man denken könnte. Indem Blueshoe Github Repository sind eine unserer eigenen Entwicklungen zu finden. :::

:::globalTitle{:size="lg" :tag="h2" .mb-5} KOMPLEXE ANSICHTEN UND ANWENDUNGEN IN DJANGO CMS ::: :::globalParagraph Django-CMS-Apps werden auf Seitenebene eingebunden. Sie können komplexe Zusammenhänge abbilden und erzeugen festgelegte Ansichten automatisch. Ihr Layout ist entsprechend oft statisch, jedoch ist die Verwendung von Plugins innerhalb von Apps nicht ausgeschlossen. Während sich die Funktionalität von Plugins auf ihre jeweilige Seite beschränken lässt, können Apps selbstständig Ansichten erzeugen. Ein typisches Beispiel für eine App ist ein Blog. Man aktiviert die App für eine Seite im CMS, z.B. /blog. Werden nun Artikel geschrieben, generiert die Blog-App selbstständig durchsuchbare Listen, Kategorie-Ansichten sowie die Detail-Ansichten der Blogeinträge. Ein weiteres Beispiel für eine App könnte ein Fragenbogen sein, welche vom Redakteur erstellt wird. Je nach Beantwortung der Fragen wird der Nutzer nach Abschluss auf eine speziell zugeschnittene Ergebnisseite weitergeleitet. :::

:::globalTitle{:size="lg" :tag="h2" .mb-5} STANDARD-APPS IN DJANGO CMS ::: :::globalParagraph Mit der Installation von Django CMS{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} werden keine Apps im Sinne eine Django CMS App installiert. Das hat den einfachen Grund, dass Apps immer spezielle Anforderungen abbilden, welche nicht auf alle Benutzer abgebildet werden können (im Gegensatz zu z.B. Text und Bild Plugin). Nicht jeder braucht zwangsweise einen Blog, oder eine Verwaltung und Darstellung für Events. Dahingehend verfolgt Django CMS{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} das Prinzip den Kern der Software schlank zu halten und zusätzlich benötigte Komponenten nachträglich zu installieren. Dieses Github Repository bietet eine, leider nicht ganz aktuelle, aber umfangreiche Sammlung von guten Django CMS Add-ons (Plugins und Apps). :::

:::globalTitle{:size="lg" :tag="h2" .mb-5} DER UNTERSCHIED ZWISCHEN APPS UND PLUGINS ::: :::globalParagraph Plugins dienen als Bausteine zur Gestaltung einer einzelnen Seite. Sie erlauben es dem Redakteur oder Editor auf den Seiten in Django CMS{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} Inhalte einzupflegen und auf verschiedene Art und Weise darzustellen. Alle Einstellungen, welche für ein Plugin getroffen werden, gelten nur für die einzelne Instanz und nicht übergreifend. Plugins werden i.d.R. mehrmals im CMS verwendet. Ihre Inhalte können direkt aus dem Input der Benutzer des Systems kommen, aber auch über Schnittstellen und vom CMS generierte Daten (z.B. Listen von Artikeln). ::: :::globalParagraph Apps definieren die gesamte Funktion einer Seite im CMS. Sie haben die Möglichkeit über eine Seite hinaus weitere Ansichten (Unterseiten) zu erzeugen. Auch Apps haben sind über Einstellungen individualisierbar und können selber über Platzhalter verfügen, in welche wiederum Plugins eingesetzt werden können. :::

:::globalTitle{:size="lg" :tag="h2" .mb-5} WIE ENTWICKELT MAN EIN DJANGO CMS PLUGIN? ::: :::globalParagraph Jedes Django CMS{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} Plugin besteht aus drei Basiskomponenten: eine Konfiguration, einem Publisher und einem Template. Die Konfiguration entspricht leitet sich von der Klasse cms.models.pluginmodel.CMSPlugin ab, wobei diese selbst von der bekannten Django Model Klasse ableitet. Sie enthält alle wichtigen Einstellungen, welche benötigt werden um die jeweilige Instanz darzustellen: ::: :::BlogCode{.mb-5}

class ImageWithCaptionModel(CMSPlugin):
    image = models.Imagefield(...)
    caption = models.TextField(...)

::: :::globalParagraph In dieser konkreten Klasse werden also die Daten gehalten, welche eine Instanz der Plugins dann später zur Darstellung von einem Bild mit Unterschrift verwenden kann. ::: :::globalParagraph Der Publisher ist im Django-Jargon die „Admin-Oberfläche“ zum jeweiligen Model. Die Klasse CMSPluginBase, welcher zur Erstellung dieser Publisher verwendet wird, leitet selbst auch die ModelAdmin Klasse ab. Publisher kontrollieren, wie die Daten ins Template gelangen, welches Template zum rendern verwendet werden soll, ob Caching beim rendern verwendet werden sollte, welche Felder der Konfiguration der Redakteur bearbeiten kann und einiges mehr. ::: :::BlogCode{.mb-5}

class ImageWithCaptionPlugin(CMSPluginBase):
    model = ImageWithCaptionModel

::: :::globalParagraph Dies ist eine simple Version eines Publishers, welche es erlaubt neue ImageWithCaption Instanzen im CMS zu erzeugen, diese zu bearbeiten und zu löschen. ::: :::globalParagraph Zu guter Letzt benötigt man ein Template, welches vorgibt wie das Plugin auf einer Seite dargestellt wird. Es enthält alle Variablen, welche vom Publisher in den Kontext gegeben werden. Standardmäßig ist das die Instanz des Models. ::: :::BlogCode{.mb-5}

<img src=“{% thumbnail instance.image 200x200 %}“>
<div>{{ instance.caption }}</div>

::: :::globalParagraph Die Entwicklung von Django CMS{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} Plugins ist weitestgehend in der Dokumentation beschrieben. :::

:::globalTitle{:size="lg" :tag="h2" .mb-5} WIE ENTWICKELT MAN EINE DJANGO CMS APP? ::: :::globalParagraph Eine Django CMS{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} App ist im Grunde genommen eine normale Django App – mit ein paar Anpassungen. Wie bereits zuvor erwähnt werden Apps auf Seitenebene angelegt und zwar mit sogenannten Apphooks. Diese ermöglichen es dem CMS eine App, welche gegebenenfalls eine eigene Seitenstruktur mitbringt, einzubinden. ::: :::BlogCode{.mb-5}

class ShowRoomApphook(CMSApp):
    name = _("Showroom")
    app_name = "showroom"

    def get_urls(self, page=None, language=None, **kwargs):
        return ["showroom.urls"]

apphook_pool.register(ShowRoomApphook)

::: :::globalParagraph In diesem Beispiel bauen wir eine Showroom-App – sie dient zur Darstellung der Kunstwerke eines Malers, welche die Webseite betreibt. Nachdem wir unsere URLs nun auch noch in die urls.py unseres Projektes eingetragen haben, ist prinzipiell der Django CMS{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} spezifische Teil um: ::: :::BlogCode{.mb-5}

url(r'^showroom/', include('showroom.urls', namespace='showroom', app_name='showroom')),

::: :::globalParagraph Die urls.py für die App selbst muss auch angelegt werden: ::: :::BlogCode{.mb-5}

urlpatterns = patterns('showroom.views',
    url(r'^$', CategoryListView.as_view(), name='category_list'),
    url(r'^artpiece/(?P<cat_id>\d+)/$',
        ArtPieceListView.as_view(), name='artpiece_list'),
)

::: :::globalParagraph Nun erstellen wir 2 Models, damit wir die Werke in der Datenbank repräsentieren können: ::: :::BlogCode{.mb-5}

class Category(models.Model):
    name = models.Charfield(...)
    slug = models.Charfield(...)

::: :::BlogCode{.mb-5}

class ArtPiece(models.Model):
    name = models.Charfield(...)
    image = models.ImageField(...)
    category = models.Foreignkey('Category', ...)

::: :::globalParagraph Weiterhin benötigen wir nun Views, zur Darstellung der Kunstwerke im Browser: ::: :::BlogCode{.mb-5}

class CategoryListView(ListView):
    model = Category
    template = 'category_list.html'

class ArtPieceListView(ListView):
    model = ArtPiece
    template = 'art_piece_list.html'

  def get_queryset(self):
        qs = super(...)
        cat_id = kwargs.get('cat_id', None)
        if cat_id:
            qs = qs.filter(category__id=cat_id)
        return qs

::: :::globalParagraph Diese benutzen wiederum 2 Templates zur Darstellung der jeweiligen Listen. Der CategoryListView gibt eine Liste alle Kategorien der Kunstwerke aus, der ArtPieceListView gibt eine gefilterte Liste der Kunstwerke (gefiltert nach Kategorie). Diese beiden Views werden nun den URLs im Apphook hinzugefügt und schon können wir unsere neue App verwenden. Natürlich müssen wir die Models vorher Migrationen durchgeführt werden. ::: :::globalParagraph Eine detailierte Dokumentation zum Erstellen von Apps in Django CMS{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} ist hier zu finden: http://docs.django-cms.org/en/release-3.4.x/how_to/apphooks.html{.bs-link-blue :target="_blank"}. :::

:::globalTitle{:size="lg" :tag="h2" .mb-5} UNTERSCHIED UND GLEICHHEIT – DJANGO CMS APPS UND PLUGINS ::: :::globalParagraph Nachdem wir nun herausgestellt haben, wie sich die Unterschiede zwischen Apps und Plugins sowohl für Benutzer als auch für Entwickler darstellen sollte hier auch nochmal gesagt werden: Bei entsprechender Implementierung, kann man dieselbe Darstellung von bestimmten Problemen sowohl mit Apps als auch mit Plugins erreichen. Es gibt auch Problemstellungen, bei denen es nun nicht offensichtlich ist, ob man eine App braucht, oder ein Plugin. Dazu sollte man sich immer genau den Verwendungszweck anschauen, für welchen die Komponente erstellt wird. Sollen viele Informationen automatisiert dargestellt werden, werden Unterseiten gebraucht, bzw. Logiken und Workflows, welche sicher immer wieder wiederholen? Dann ist wohl in der Regel eine App die richtige Lösung. Wird viel Flexibilität in der Darstellung gebraucht und lässt sich kein Muster in der Verwendung erkennen, so sollte man eher dazu tendieren ein Plugin als Problemlösung herzunehmen. ::: :::globalParagraph Die Implementierung der Django CMS{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} App ist auch auf Github zu finden: https://github.com/Blueshoe/django_cms_example{.bs-link-blue :target="_blank"}. :::

{.object-cover .max-w-full .mb-5}

::GlobalTitle{:size="lg" .mb-4} Optimierte CORS-Konfiguration für moderne Webanwendungen ::

::GlobalParagraph Django-CORS ist ein unverzichtbares Werkzeug für die sichere Kommunikation zwischen Diensten in einer Cross-Origin-Umgebung. Besonders in verteilten Architekturen und Container-Umgebungen spielt eine flexible und gut konfigurierte CORS-Strategie eine Schlüsselrolle. Erfahre, welche Pakete du benötigst, wie du sie installierst und konfigurierst und welche Best Practices es gibt. ::

:::GlobalButton{:url="/technologien/python-django-agentur/" :label="Erfahre mehr über unsere Django-Entwicklungsdienste" :color="blue" .mb-6} :::

::GlobalTitle{:size="lg" .mb-5} Einführung in Django-CORS ::

::GlobalParagraph CORS (Cross-Origin Resource Sharing) definiert, welche Domains Zugriff auf Ressourcen deiner Anwendung haben. Browser blockieren standardmäßig solche Anfragen, wenn sie von einer anderen Domain stammen. Mit django-cors-headers{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} kannst du diese Beschränkung gezielt aufzuheben und API{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid}-Zugriffe sicher und kontrolliert gestalten. ::

::GlobalTitle{:size="lg" .mb-5} Pakete und Installation ::

::GlobalParagraph Für die CORS-Konfiguration in Django wird das Paket django-cors-headers{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} verwendet. Dieses Paket ist speziell für Django entwickelt und integriert sich nahtlos in die bestehende Middleware. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 1. Installiere das Paket mit pip ::

::BlogCode

pip install django-cors-headers

::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 2. Füge das Paket in deinen Django-Einstellungen hinzu ::

::BlogCode

INSTALLED_APPS += [
    'corsheaders',
]

::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 3. Registriere die Middleware – sie muss ganz oben in der Liste stehen ::

::BlogCode

MIDDLEWARE = [
    'corsheaders.middleware.CorsMiddleware',
    *MIDDLEWARE,
]

::

::GlobalTitle{:size="lg" .mb-5} Beispiel: Webanwendung mit CORS ::

::GlobalParagraph Für eine typische Webanwendung, bei der Frontend und Backend auf unterschiedlichen Domains laufen, kannst du CORS_ALLOWED_ORIGINS so konfigurieren: ::

::BlogCode

CORS_ALLOWED_ORIGINS = [
    "https://frontend.example.com",
    "https://partner.example.com",
]

::

::GlobalParagraph Möchtest du zusätzliche Header erlauben, z. B. für Authentifizierung, kannst du dies erweitern: ::

::BlogCode

from corsheaders.defaults import default_headers
CORS_ALLOW_HEADERS = list(default_headers) + [
    "Authorization",
    "X-Custom-Header",
]

::

:::GlobalCallAnExpert{:bg="bg-bs-blue"} #buttonBlockTitle Wir können CORS auch für deine Django Apps einrichten. :::

::GlobalTitle{:size="lg" .mb-5} CORS in Container-Umgebungen ::

::GlobalParagraph In Container- und verteilten Systemen wird Django häufig als Backend verwendet, das von verschiedenen Diensten (Frontend, API-Gateways, Authentifizierungsserver) angesprochen wird. Hier ist es entscheidend, die CORS-Regeln auch für interne Container-Kommunikation korrekt zu setzen. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Herausforderungen: ::

::GlobalBlock{.ol-decimal .my-4}

1. Dynamische Ursprünge: Dienste können in Containern unterschiedliche IP-Adressen oder dynamische Subdomains verwenden.
2. Preflight-Anfragen: Optionen-Anfragen (OPTIONS) können von Proxies oder Load-Balancern blockiert werden, was zu Problemen führt. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Lösung: ::

::GlobalParagraph Mit regex-basierten Whitelists und flexiblen Methoden: :

::BlogCode

CORS_ORIGIN_REGEX_WHITELIST = [
    r"^https://.*\.example\.com$",
]
CORS_ALLOW_METHODS = [
    "GET",
    "POST",
    "PUT",
    "DELETE",
    "OPTIONS",
]

::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Häufige Stolpersteine ::

::GlobalBlock{.ol-decimal .my-4}

1. Wildcard-Konfiguration: Vermeide CORS_ALLOW_ALL_ORIGINS=True in der Produktion - das ist ein Sicherheitsrisiko.
2. Preflight-Anfragen in Containern: Stelle sicher, dass API-Gateways oder Proxies die OPTIONS-Anfragen korrekt durchleiten.
3. Logs und Debugging: Überwache fehlerhafte CORS-Anfragen mithilfe von Django-Logs, um Fehlkonfigurationen schnell zu erkennen. ::

::GlobalTitle{:size="lg" .mb-5} Best Practices für Django-CORS ::

::GlobalBlock{.ol-decimal .my-4}

1. Nutze Umgebungsvariablen, um Konfigurationen zwischen Entwicklungs- und Produktionsumgebung zu trennen.
2. Teste regelmäßig deine CORS-Konfiguration, z. B. mit Tools wie Postman{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} oder Browser-Developer-Tools.
3. Reduziere die Anzahl erlaubter Ursprünge und Header auf das absolut Notwendige. ::

::GlobalTitle{:size="lg" .mb-5} Fazit ::

::GlobalParagraph Mit django-cors-headers kannst du sicherstellen, dass Cross-Origin-Anfragen kontrolliert und sicher abgewickelt werden – unabhängig davon, ob du lokal entwickelst oder in einer skalierbaren Container-Umgebung arbeitest. Besonders in verteilten Systemen ist die richtige CORS-Konfiguration entscheidend, um eine reibungslose Kommunikation zwischen Diensten zu gewährleisten. ::

:::GlobalButton{:url="/technologien/python-django-agentur/" :label="Lust auf mehr Django-Insights?" :color="blue" .mb-6} :::

::GlobalParagraph Hast du Fragen oder möchtest du Unterstützung bei der Umsetzung? Kontaktiere uns{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} – wir helfen dir, deine Djangp Apps erfolgreich umzusetzen! ::

:::GlobalTitle{:size="lg" .mb-5 .mt-8} Häufige Fragen :::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 1. Was ist Django-CORS und warum ist es wichtig? ::

::GlobalParagraph Django-CORS (Cross-Origin Resource Sharing) ermöglicht es, gezielt zu definieren, welche Domains auf Ressourcen einer Django-Anwendung zugreifen dürfen. Das ist besonders in modernen, verteilten Systemen relevant, um APIs sicher und flexibel zu gestalten. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 2. Wie konfiguriere ich CORS in Django? ::

::GlobalParagraph Die Konfiguration erfolgt mit dem Paket django-cors-headers. Dieses wird per pip installiert und in den INSTALLED_APPS sowie der MIDDLEWARE eingetragen. Domains, die zugreifen dürfen, werden in den Einstellungen wie CORS_ALLOWED_ORIGINS definiert. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 3. Welche Herausforderungen gibt es bei CORS in Container-Umgebungen? ::

::GlobalParagraph In Container-Architekturen treten oft dynamische Ursprünge und blockierte Preflight-Anfragen auf. Diese können durch regex-basierte Whitelists (CORS_ORIGIN_REGEX_WHITELIST) und die richtige Proxy-Konfiguration gelöst werden. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 4. Was sind Best Practices für eine sichere Django-CORS-Konfiguration? ::

::GlobalParagraph

• Vermeide die Verwendung von CORS_ALLOW_ALL_ORIGINS=True in der Produktion.
• Reduziere erlaubte Ursprünge und Header auf das Nötigste.
• Nutze Umgebungsvariablen, um Konfigurationen zwischen Entwicklungs- und Produktionsumgebungen zu trennen. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 5. Wie teste ich meine Django-CORS-Konfiguration? ::

::GlobalParagraph{.mb-4} Die CORS-Einstellungen können mit Tools wie Postman oder den Developer-Tools des Browsers überprüft werden. Preflight-Anfragen sollten korrekt durchgeleitet und Logs auf Fehler analysiert werden. ::

{.object-cover .max-w-full .mb-5}

:::globalParagraph Wir bei Blueshoe sind schon immer Fans von Open Source. In sehr vielen unserer Projekten kommen Open Source-Komponenten zum Einsatz, wir nutzen ja auch u. a. sehr stark das Django Framework und wir bemühen uns auch, Open Source-Projekte bei der Maintenance und Weiterentwicklung zu unterstützen. Seit einiger Zeit hat nun auch Kubernetes bei uns Einzug erhalten, wodurch wir uns mehr und mehr der Herausforderung stellen, wie wir möglichst Cloud Native entwickeln können. Dazu haben wir auch schon Blog-Posts geschrieben, z. B.: Cloud Native Kubernetes development{.bs-link-blue}. ::: :::globalParagraph Heute möchten wir euch unser neues Open Source-Projekt Django-Hurricane vorstellen. :::

:::globalTitle{:size="lg" .mb-5} “Klassisches” Deployment ::: :::globalParagraph Zunächst wollen wir kurz betrachten, wie Django oftmals auf einem Server, bzw. einer VM ausgeführt wird. Üblicherweise verwenden wir dazu einen Stack mit nginx als Web Server, sowie uwsgi als Application Server, welcher den Django-Code ausführt. Appserver wie uwsgi haben ein hochgradig optimiertes Prozessmodell für diese Art von Deployments mit vielen CPUs, mehreren Threads, usw. Mit genügend Wissen über die Anwendung und genügend Erfahrung im Betrieb von Django-Anwendungen, lässt sich der Application Server nun möglichst optimal konfigurieren, wofür i. d. R. genügend Optionen zur Verfügung stehen. :::

:::globalTitle{:size="lg" .mb-5} Kubernetes Deployment von Django-Anwendungen ::: {.object-cover .max-w-full .mb-5}

:::globalParagraph In Kubernetes sieht das nun etwas anders aus. Auch dort lässt sich unsere Django-Anwendung in einem Container mittels uwsgi ausführen. Allerdings ist eine auf die Hardware abgestimmte Optimierung des Application Servers im Container eher fehl am Platze. Schon allein, da sich ja nicht direkt beeinflussen lässt, auf welcher Node im Cluster der Container nun tatsächlich ausgeführt wird. In Kubernetes kann weiterhin mit dem Replication-Wert die horizontale Skalierung der Anwendung konfiguriert werden. Zusätzlich kann mit dem Horizontal Pod Autoscaler eine Mindest- und Maximalanzahl an Pods spezifiziert werden. Kommt die App beispielsweise mit den Requests nicht mehr zurecht, kann Kubernetes einfach einen neuen Container parallel starten. ::: :::globalParagraph Es gibt noch weitere Punkte, die wir in unserer Django-Anwendung beachten müssen, wenn sie mit Kubernetes ausgeführt wird. Hier sind z. B. die Liveness-, Readiness- und Startup-Probes genannt. Unsere Anwendung muss Endpunkte für die Probes zur Verfügung stellen, die regelmäßig von Kubernetes abgefragt werden, um zu beurteilen, ob ein Container z. B. neu gestartet werden muss, oder ob er gerade Traffic empfangen kann. Das kann dann doch zu etwas Boilerplate-Code führen, oder auch dazu, dass die Django-Anwendung u. U. Funktionalität einfach nur für das Hosting bereitstellen muss. ::: :::globalParagraph All das wollen wir eigentlich nicht: Wir wollen einen Application Server, der direkter mit Kubernetes verzahnt ist. :::

:::globalTitle{:size="lg" .mb-5} Django-Hurricane ::: {.object-cover .max-w-full .mb-5}

:::globalParagraph Aus diesem Grund haben wir Django Hurricane entwickelt. Dabei bauen wir auf dem Tornado web server auf. Hurricane lässt sich als einfacher Django-Management-Command ausführen und mittels Flags auch konfigurieren. Es sind keine weiteren Konfigurationsdateien nötig. ::: :::globalParagraph Die Installation kann einfach mittels pip erfolgen: ::: :::BlogCode{.mb-5}

pip install hurricane

:::

:::globalParagraph Hurricane muss daraufhin in die INSTALLED_APPS des Django-Projekts hinzugefügt werden. Weiterhin sollte auch ein Logger konfiguriert werden, damit Log-Nachrichten angezeigt werden: ::: :::BlogCode{.mb-5}

INSTALLED_APPS += (
  'hurricane',
)

LOGGING = {
    # [...]
    “loggers”: {
        # [...]
        “hurricane:”: {
          "handlers": ["console"],
          "level": os.getenv("HURRICANE_LOG_LEVEL", "INFO"),
          "propagate": False,
        },
    },
    # [...]
}

:::

:::globalParagraph Starten lässt sich Django-Hurricane mit dem Management-Command: ::: :::BlogCode{.mb-5}

python manage.py serve

:::

:::globalParagraph Auch die Konfiguration findet komplett mit Optionen des Management-Commands statt. Hier ist eine Auflistung der momentan vorhandenen Optionen: ::: :::GlobalBlock{.ul-disk .mb-5}

• static: Ausliefern von Static-Files
• media: Ausliefern von Media-Files
• auto-reload: Code-Änderungen dynamisch laden
• debug: Debug Flag von Tornado setzen (nicht mit djangos DEBUG=True zu verwechseln)
• port: Der Port auf dem Tornado laufen soll (default: 8000)
• probe: Der Pfad für die Liveness- und Readiness-Probes (default: /alive)
• probe-port: Der Port unter welchem die Probes zu erreichen sind (default: ein Port nach --port)
• no-probe: Probe-Endpunkt deaktivieren :::

:::globalParagraph Mit diesen grundlegenden Konfigurationsmöglichkeiten lassen sich bereits einige Szenarien abdecken und wir können Django-Hurricane damit bereits auf Produktivsystemen einsetzen. ::: :::globalParagraph Damit die Probes auch ihren Sinn erfüllen können, muss gewährleistet sein, dass sie tatsächlich eine Aussage über die Erreichbarkeit und Verfügbarkeit der Anwendung treffen und es nicht einfach nur ein Endpunkt ist, der eher unabhängig von der Anwendung zu erreichen ist. Bei Hurricane werden der Django-Code und der Probe-Endpunkt zwar auf zwei verschiedenen Ports ausgeliefert, da die komplette Code-Basis in der gleichen asyncio-Loop ausgeführt wird, lässt sich aber implizit ein Rückschluss auf die Erreichbarkeit und Verfügbarkeit der Anwendung treffen. ::: :::globalParagraph Es kann durchaus nötig sein, dass es mehr Logik benötigt, um die Liveness oder Readiness einer Anwendung zu ermitteln, als einfach nur einen Endpunkt, der eine 200 zurückliefert. Hurricanes Probe-Endpunkt ruft Djangos Check Framework auf. Dadurch ist es möglich, die benötigte zusätzliche Logik für die Anwendung in Django-Checks abzubilden. :::

:::globalTitle{:size="md" .mb-5} Roadmap und weitere Entwicklungen ::: {.object-cover .max-w-full .mb-5}

:::globalParagraph Auch wenn Hurricane bereits für Produktivsysteme verwendet werden kann, steht die Entwicklung erst ganz am Anfang. Uns schweben noch einige weitere Features vor, die To-do-Liste im GitHub Repository bietet noch einige freie Checkboxen an. Unterstützung bei der Weiterentwicklung ist natürlich wie bei allen Open Source-Projekten immer willkommen. Wir bleiben auf jeden Fall weiter am Ball, es wird künftig sicherlich auch noch den ein oder anderen Blogpost, z. B. über neue Django-Hurricane-Features{.bs-link-blue}, oder auch Anwendungsszenarien geben. :::

Wer Django{target="_blank"} liebt, weiß seine Stärken zu schätzen: schnelle Entwicklung, ein robustes ORM und eine riesige Community. Doch wenn es um den Einsatz in modernen, cloud-nativen Umgebungen wie Kubernetes geht, stößt das traditionelle Django-Setup an seine Grenzen. Hier kommt Django Hurricane ins Spiel – ein Projekt, das deine Django-Anwendung fit für die Orchestrierung macht.

{.object-cover .max-w-full .mb-5}

::GlobalBlogLevelInfo

• Kubernetes Basics
• Das Projekt Django Hurricane{target="_blank"}
• Kubernetes Probes{:target="_blank"}
• Kubernetes Horizontal Pod Autoscaler{:target="_blank"}
• Optional Google Kubernetes Engine{:target="_blank"}

Solltest du Fragen haben, oder dir etwas unklar sein, kannst du die Kommentarfunktion unter dem Artikel nutzen. ::

Django Hurricane{target="_blank"} integriert Konzepte wie Liveness- und Readiness-Probes direkt in den Django-Management-Kontext. Das bedeutet, Kubernetes kann jederzeit den Zustand deiner Anwendung verstehen und intelligent darauf reagieren – zum Beispiel, indem es Traffic erst dann an einen neuen Pod sendet, wenn dieser wirklich bereit ist.

Doch das ist nur der Anfang. Die letzten Updates (Version 1.5.0 und 1.6.0) haben eine Reihe mächtiger neuer Funktionen mitgebracht, die das Entwicklerleben noch einfacher machen. Schauen wir uns die Highlights genauer an.

Neue Superkräfte: Monitoring, Ressourcen-Kontrolle und feines Tuning

Die jüngsten Versionen von Hurricane haben sich darauf konzentriert, dir mehr Kontrolle und bessere Einblicke in deine Anwendung zu geben – genau das, was man in einer dynamischen Kubernetes-Umgebung braucht.

Besseres Monitoring und Logging mit structlog & Prometheus (v1.5.0)

Gute Observability ist das A und O für stabile Systeme. Hurricane macht hier einen großen Schritt nach vorne.

Prometheus-Metriken out-of-the-box

Mit dem Start des Servers via $ python manage.py serve wird standardmäßig ein Metrik-Endpunkt unter /metrics auf dem internen Port bereitgestellt. Diese Metriken sind im Prometheus-Format und können von deinem Monitoring-System einfach ausgelesen werden. Das ist die Grundlage für Alarme und Dashboards. Falls du das nicht benötigst, kannst du es einfach mit der Option --no-metrics deaktivieren. 📈

Strukturiertes Logging

Sobald du structlog zu deinem Projekt hinzufügst, integriert sich Hurricane automatisch. Strukturiertes Logging ist ein Game-Changer, weil Logs nicht mehr nur Textwüsten, sondern maschinenlesbare Daten sind. Das erleichtert die Analyse und Fehlersuche ungemein. Tipp: Für Nutzer der Google Kubernetes Engine (GKE) empfiehlt sich zusätzlich structlog-gcp, um die Logs perfekt für das Google Cloud Logging aufzubereiten.

Intelligentes Ressourcenmanagement (v1.5.0)

In einer Container-Welt sind Ressourcen wie Speicher kostbar und müssen gut verwaltet werden.

Speicherlimit setzen

Speicherlimit setzen: Mit --max-memory kannst du eine Obergrenze für den Arbeitsspeicher festlegen (z. B. --max-memory 512M). Überschreitet deine Anwendung dieses Limit, wird sie kontrolliert neu gestartet. Das verhindert unkontrollierte Abstürze durch "Out of Memory"-Fehler und überlässt Kubernetes die Steuerung über den Neustart des Pods.

Worker-Threads anpassen

Die Option --workers gibt dir die Kontrolle über die Anzahl der Threads im ThreadPoolExecutor. Damit kannst du die Performance für I/O-intensive Aufgaben gezielt optimieren.

Mehr Flexibilität und Kontrolle (v1.6.0)

Version 1.6.0 legt den Fokus auf Konfiguration und die Handhabung spezieller Anwendungsfälle.

Umgang mit großen Datenmengen

Deine App verarbeitet große Datei-Uploads oder riesige JSON-Payloads? Mit --max-body-size und --max-buffer-size kannst du das Verhalten des zugrundeliegenden Tornado-Servers präzise steuern. Damit verhinderst du Pufferüberläufe und sorgst auch bei hohem Datenaufkommen für Stabilität.

Konfiguration auf deine Art

Flexibilität ist Trumpf. Hurricane lässt sich nun über drei Wege konfigurieren: klassische CLI-Argumente, Einträge in den Django Settings oder – und das ist besonders für Kubernetes-Deployments ideal - über Umgebungsvariablen. Dies folgt dem bewährten "12-Factor App"-Prinzip{target="_blank"} und ermöglicht saubere, umgebungsspezifische Konfigurationen ohne Code-Änderungen.

Deep Dive: API-Skalierung mit HPA und Prometheus-Metriken

Eine der größten Stärken von Kubernetes ist die Fähigkeit zur automatischen Skalierung. Aber die Standardskalierung nach CPU- oder Speicherauslastung ist für I/O-intensive Anwendungen wie Django-APIs oft nicht ideal. Eine API kann unter Volllast stehen (z.B. durch viele langsame Datenbankabfragen), ohne dass die CPU-Last signifikant ansteigt.

Eine viel bessere Metrik ist der request backlog – also die Anzahl der Anfragen, die gerade aktiv von einem Pod bearbeitet werden. Wenn diese Zahl steigt, bedeutet das, dass die Anwendung an ihre Belastungsgrenze kommt und wir mehr Instanzen benötigen.

Im Folgenden zeige ich dir, wie man genau das mit Django Hurricane auf der Google Kubernetes Engine (GKE) umsetzt.

Schritt 1: Die richtige Metrik identifizieren

Django Hurricane stellt über seinen Prometheus-Endpunkt /metrics eine Vielzahl von Messwerten bereit. Für unseren Anwendungsfall ist eine Metrik wie request_queue_length ideal. Sie zeigt uns die Anzahl der gleichzeitig verarbeiteten Anfragen pro Pod. Unser Ziel ist es, zu sagen: "Wenn im Durchschnitt mehr als 5 Anfragen pro Pod aktiv sind, starte einen neuen Pod."

{.mx-auto .w-1/2}

Schritt 2: Prometheus-Metriken in GKE sammeln

Der einfachste Weg, Prometheus-Metriken in GKE zu nutzen, ist der Google Cloud Managed Service for Prometheus{target="_blank"}. Wenn dieser in deinem Cluster aktiviert ist, musst du Kubernetes nur noch sagen, wo es die Metriken deiner Anwendung finden kann.

Wir weisen Kubernetes an, den Port 8081 (den internen Port von Django Hurricane) nach Metriken abzusuchen. Hier ein Beispiel für ein Deployment-Manifest:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-django-api
spec:
  replicas: 2
  selector:
    matchLabels:
      app: my-django-api
  template:
    metadata:
      labels:
        app: my-django-api
    spec:
      containers:
      - args:
        - python /app/manage.py serve --req-queue-len 100 --command "collectstatic
          --no-input" --port 8080 --static --max-memory 950
        name: django-hurricane
        image: your-django-app-image:latest
        ports:
        - containerPort: 8080
          name: http
          protocol: TCP
        - containerPort: 8081
          name: metrics
          protocol: TCP

Dann brauchen wir noch ein PodMonitoring:

apiVersion: monitoring.googleapis.com/v1
kind: PodMonitoring
metadata:
  name: my-django-api
spec:
  endpoints:
  - interval: 5s  # Interval um den Metrics-Endpunkt abzufragen
    metricRelabeling:
    - action: keep
      regex: request_queue_.+  # Wir exportieren nur diese eine Metrik
      sourceLabels:
      - __name__
    port: metrics  # Das ist der Name des Ports (siehe oben am Deployment)
  selector:
    matchLabels:
      name: my-django-api  # Der Pod Selector
  targetLabels:
    metadata:
    - pod
    - container

Damit landen die Daten auch schon in der Google Cloud Console.

Schritt 3: Den Horizontal Pod Autoscaler (HPA) anlegen

Jetzt kommt der spannendste Teil. Wir definieren einen Horizontal Pod Autoscaler (HPA){target="_blank"}, der die Metrik aus dem Managed Prometheus Service ausliest und darauf reagiert.

Die von Google Cloud Managed Prometheus gesammelten Metriken erhalten ein spezielles Präfix. Unsere Metrik request_queue_length wird in Google Cloud Monitoring als prometheus.googleapis.com|request_queue_length|gauge verfügbar sein.

Das HPA-Manifest sieht dann so aus:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-django-api-hpa
spec:
  # Beschreibung des Scaling-Verhaltens
  behavior:
    scaleDown:
      policies:
      - periodSeconds: 15
        type: Percent
        value: 100
      selectPolicy: Max
      stabilizationWindowSeconds: 300
    scaleUp:
      policies:
      - periodSeconds: 15
        type: Pods
        value: 4
      - periodSeconds: 15
        type: Percent
        value: 100
      selectPolicy: Max
      stabilizationWindowSeconds: 0
  # Ziel-Deployment, das skaliert werden soll
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-django-api
  
  # Skalierungsgrenzen
  minReplicas: 2
  maxReplicas: 20
  
  # Metriken, die zur Skalierung verwendet werden
  metrics:
  - type: Pods # Wir messen einen Wert pro Pod
    pods:
      metric:
        # Der vollständige Name der Metrik in Google Cloud Monitoring
        name: "prometheus.googleapis.com|request_queue_length|gauge"
      target:
        type: AverageValue # Wir zielen auf einen Durchschnittswert
        averageValue: "5" # Skaliere hoch, wenn der Durchschnitt über 5 liegt

Was passiert hier genau?

1. Django Hurricane liefert's: Jeder Pod deiner Django-Anwendung stellt unter :8081/metrics die Anzahl der aktiven Anfragen bereit.
2. Prometheus sammelt's: Der Managed Prometheus Collector in GKE sieht die Annotationen, liest die Metriken regelmäßig aus und speichert sie.
3. HPA beobachtet's: Der HPA fragt kontinuierlich den Wert für prometheus.googleapis.com|request_queue_length|gauge ab.
4. HPA reagiert: Er berechnet den Durchschnittswert über alle laufenden Pods. Liegt dieser Wert über unserem Ziel von 5, weist der HPA das Deployment an, die Anzahl der Replicas zu erhöhen (bis zum Maximum von 20). Fällt der Wert wieder, werden Pods elegant heruntergefahren (bis zum Minimum von 2).

Mit diesem Setup schaffst du eine hocheffiziente und reaktionsschnelle API, die sich perfekt an die tatsächliche Last anpasst – und das alles mit Bordmitteln von Django Hurricane, Kubernetes und GKE.

Fazit: Django und Kubernetes – Ein echtes Dream-Team

Django Hurricane schließt die Lücke zwischen der Entwicklungsfreundlichkeit von Django und den betrieblichen Anforderungen von Kubernetes. Die neuen Features für Monitoring, Ressourcenmanagement und flexible Konfiguration machen es zu einem unverzichtbaren Werkzeug für alle, die skalierbare und robuste Webanwendungen in der Cloud betreiben wollen.

Wenn du deine Django-Projekte auf das nächste Level heben möchtest, gib Django Hurricane eine Chance. Deine Anwendung – und dein DevOps-Team – werden es dir danken.

Während FastAPI mit seiner modernen, asynchronen Architektur und maximaler Flexibilität punktet, bringt Django Ninja die elegante API-Syntax von FastAPI in das bewährte Django-Ökosystem. In diesem umfassenden Vergleich erfährst du nicht nur die technischen Unterschiede bei Setup, Schema-Definitionen und Middleware-Konzepten, sondern erhältst auch eine fundierte Entscheidungshilfe: Wann ist die radikale Freiheit von FastAPI der richtige Weg, und wann profitierst du mehr von Django Ninjas nahtloser Integration in die Django-Welt?

{.object-cover .max-w-full .mb-5}

::GlobalBlogLevelInfo

• REST API{target="_blank"}
• Django{target="_blank"} Basics, ORM{target="_blank"}, Middlewares{target="_blank"}
• FastAPI{target="_blank"}
• Optional JSON Web Token{:target="_blank"}

Solltest du Fragen haben, oder dir etwas unklar sein, kannst du die Kommentarfunktion unter dem Artikel nutzen. ::

Django Ninja vs FastAPI: Ein detaillierter Vergleich zweier moderner Python Web-Frameworks

Wenn du moderne REST APIs in Python entwickeln möchtest, stößt du unweigerlich auf FastAPI{target="_blank"} - das Framework, das die Python-Web-Entwicklung in den letzten Jahren revolutioniert hat. Aber kennst du auch Django Ninja{target="_blank"}? Diese elegante Alternative bringt die Geschwindigkeit und Type-Safety von FastAPI in die Django-Welt. Lass uns gemeinsam erkunden, wie sich diese beiden Frameworks unterscheiden und wann du welches einsetzen solltest.

Schnellübersicht: Django Ninja vs. FastAPI auf einen Blick

| Feature | Django Ninja | FastAPI | |----------------|--------------------------------------------|----------------------------------------------| | Grundlage | Auf Django aufgebaut | Eigenständiges Framework (basiert auf Starlette) | | Performance | Sehr gut, aber synchron | Exzellent, primär asynchron (ASGI) | | Datenbank | Django ORM (integriert) | Jedes ORM (z.B. SQLAlchemy, Tortoise ORM) | | Admin-Panel | Django Admin (out-of-the-box) | Muss selbst gebaut/integriert werden | | Authentifizierung | Django Auth (integriert) | Muss selbst implementiert werden | | Lernkurve | Sehr flach für Django-Entwickler | Flach für Python-Entwickler | | Flexibilität | Weniger flexibel, aber "batteries-included" | Maximale Flexibilität, aber mehr Setup-Aufwand | | Ideal für | Bestehende Django-Projekte, schnelle CRUD-APIs | Hochperformante Microservices, neue Projekte |

Die Grundidee hinter beiden Frameworks

Bevor wir in die technischen Details eintauchen, lasst mich kurz erklären, was beide Frameworks besonders macht. FastAPI ist ein eigenständiges, asynchrones Web-Framework, das von Grund auf für moderne API-Entwicklung konzipiert wurde. Django Ninja hingegen ist eine Erweiterung für Django, die es erlaubt, APIs mit einer FastAPI-ähnlichen Syntax zu schreiben, während du weiterhin das gesamte Django-Ökosystem nutzen kannst.

Setup-Vergleich: Der erste Eindruck zählt

FastAPI Setup

Bei FastAPI beginnst du praktisch bei null. Das hat Vor- und Nachteile. Der Vorteil ist die absolute Freiheit - du entscheidest über jeden Aspekt deiner Anwendung. Ein minimales FastAPI-Projekt sieht so aus:

# main.py
from fastapi import FastAPI

app = FastAPI()

@app.get("/")
def read_root():
    return {"Hello": "World"}

# Starten mit: fastapi dev main.py

Das war's! Mit nur wenigen Zeilen hast du eine funktionierende API. Aber sobald du Datenbanken, Authentifizierung oder andere Features brauchst, musst du alles selbst konfigurieren:

# Ein realistischeres FastAPI Setup
from fastapi import FastAPI
from sqlalchemy import create_engine
from sqlalchemy.orm import sessionmaker
import uvicorn

# Datenbank Setup
SQLALCHEMY_DATABASE_URL = "postgresql://user:password@localhost/dbname"
engine = create_engine(SQLALCHEMY_DATABASE_URL)
SessionLocal = sessionmaker(autocommit=False, autoflush=False, bind=engine)

app = FastAPI(title="Meine API", version="1.0.0")

# Dependency für Datenbank-Sessions
def get_db():
    db = SessionLocal()
    try:
        yield db
    finally:
        db.close()

Django Ninja Setup

Bei Django Ninja hast du bereits ein vollständiges Django-Projekt als Grundlage. Das bedeutet, dass Datenbank-Konfiguration, Migrationen, Admin-Interface und vieles mehr bereits vorhanden sind:

# Nach django-admin startproject und pip install django-ninja

# views.py
from ninja import NinjaAPI

api = NinjaAPI()

@api.get("/hello")
def hello(request):
    return {"message": "Hello from Django Ninja"}

# urls.py
from django.urls import path
from my_app.views import api

urlpatterns = [
    path("api/", api.urls),
]

Der große Unterschied? Mit Django Ninja bekommst du das Beste aus beiden Welten: Die intuitive API-Syntax von FastAPI und die bewährte Infrastruktur von Django. Du musst nicht bei null anfangen, sondern baust auf einem soliden Fundament auf.

Model Schemas: Der größte Unterschied

Hier wird es richtig interessant! Beide Frameworks nutzen Python Type Hints für die Validierung, aber die Implementierung unterscheidet sich fundamental.

FastAPI mit Pydantic

FastAPI setzt vollständig auf Pydantic für die Datenvalidierung. Pydantic-Modelle sind eigenständige Klassen, die deine Datenstrukturen definieren:

from pydantic import BaseModel, Field, validator
from datetime import datetime

class UserBase(BaseModel):
    # es gibt auch eine E-Mail Klasse in Pydantic!
    email: str = Field(..., description="Die E-Mail-Adresse des Benutzers")
    username: str = Field(..., min_length=3, max_length=20)
    
    @validator('email')
    def email_must_be_valid(cls, v):
        if '@' not in v:
            raise ValueError('Keine gültige E-Mail-Adresse')
        return v

class UserCreate(UserBase):
    password: str = Field(..., min_length=8)

class UserResponse(UserBase):
    id: int
    created_at: datetime
    is_active: bool = True
    
    class Config:
        # Erlaubt die Verwendung von ORM-Objekten
        orm_mode = True

Die Stärke von Pydantic liegt in seiner Flexibilität und den umfangreichen Validierungsmöglichkeiten. Du kannst komplexe Validierungslogik implementieren, automatische Konvertierungen durchführen und sogar verschachtelte Modelle erstellen.

Django Ninja's Schema-System

Django Ninja bietet dir zwei Möglichkeiten: Du kannst entweder Pydantic verwenden oder Ninja's eigenes Schema-System. Das Schema-System von Ninja ist speziell für die Integration mit Django ORM optimiert:

from ninja import Schema, ModelSchema
from django.contrib.auth.models import User
from typing import Optional

# Option 1: Manuelles Schema
class UserSchema(Schema):
    id: int
    username: str
    email: str
    first_name: Optional[str] = None
    last_name: Optional[str] = None

# Option 2: ModelSchema - Automatisch aus Django Model
class UserModelSchema(ModelSchema):
    class Config:
        model = User
        model_fields = ['id', 'username', 'email', 'first_name', 'last_name']

# Option 3: Erweiterte ModelSchema mit zusätzlichen Feldern
class UserDetailSchema(ModelSchema):
    full_name: str
    post_count: int = 0
    
    class Config:
        model = User
        model_fields = '__all__'
    
    @staticmethod
    def resolve_full_name(obj):
        return f"{obj.first_name} {obj.last_name}"

Der entscheidende Vorteil von Django Ninja's Schema-System ist die nahtlose Integration mit Django Models. Du musst nicht ständig zwischen ORM-Objekten und Pydantic-Modellen konvertieren. Die ModelSchema Klasse generiert automatisch Schemas basierend auf deinen Django Models, was Duplikation vermeidet.

Der tiefere Vergleich: Pydantic vs Ninja Schema

Lass uns die "philosophischen" Unterschiede verstehen:

Pydantic in FastAPI:

• Vollständig entkoppelt von der Datenbank
• Explizite Konvertierung zwischen ORM und Pydantic nötig
• Mehr Kontrolle, aber auch mehr Boilerplate
• Perfekt für komplexe Validierungen und Transformationen

# FastAPI mit SQLAlchemy
@app.post("/users/", response_model=UserResponse)
def create_user(user: UserCreate, db: Session = Depends(get_db)):
    # Manuelle Konvertierung nötig
    db_user = UserModel(
        email=user.email,
        username=user.username,
        hashed_password=hash_password(user.password)
    )
    db.add(db_user)
    db.commit()
    db.refresh(db_user)
    # Pydantic konvertiert automatisch dank orm_mode
    return db_user

Ninja Schema:

• Eng mit Django ORM verzahnt
• Automatische Konvertierung zwischen Django Models und Schemas
• Weniger Code, aber auch weniger Flexibilität bei Bedarf
• Ideal für CRUD-Operationen mit Django Models

# Django Ninja
@api.post("/users/", response=UserModelSchema)
def create_user(request, user_data: UserCreateSchema):
    # Direkte Arbeit mit Django ORM
    user = User.objects.create_user(
        username=user_data.username,
        email=user_data.email,
        password=user_data.password
    )
    # Automatische Konvertierung zum Response Schema
    return user

Endpoint-Definition: Subtile aber wichtige Unterschiede

Auf den ersten Blick sehen die Endpoint-Definitionen sehr ähnlich aus, aber der Teufel steckt im Detail.

FastAPI Endpoints

from fastapi import FastAPI, Path, Query, Body, Header, Depends
from typing import Optional, List

app = FastAPI()

@app.get("/items/{item_id}")
async def read_item(
    item_id: int = Path(..., title="Die ID des Items", ge=1),
    q: Optional[str] = Query(None, max_length=50),
    x_token: str = Header(...),
    current_user: User = Depends(get_current_user)
):
    # Async ist optional aber empfohlen
    return {"item_id": item_id, "q": q}

@app.post("/items/")
async def create_item(
    item: Item = Body(..., embed=True),
    importance: int = Body(...)
):
    return {"item": item, "importance": importance}

Django Ninja Endpoints

from ninja import Router, Path, Query, Body, Header
from django.shortcuts import get_object_or_404

router = Router()

@router.get("/items/{item_id}")
def read_item(
    request,  # Django Request Objekt ist immer der erste Parameter
    item_id: int = Path(..., title="Die ID des Items", ge=1),
    q: Optional[str] = Query(None, max_length=50),
    x_token: str = Header(...)
):
    # Nutze Django's ORM direkt
    item = get_object_or_404(Item, id=item_id)
    return {"item_id": item.id, "q": q}

@router.post("/items/", response=ItemSchema)
def create_item(request, item_data: ItemCreateSchema):
    # Django's Authentifizierung ist direkt verfügbar
    if not request.user.is_authenticated:
        return 401, {"detail": "Not authenticated"}
    
    item = Item.objects.create(**item_data.dict(), owner=request.user)
    return item

Die wichtigsten Unterschiede:

1. Request-Objekt: Django Ninja übergibt immer das Django Request-Objekt als ersten Parameter. Das gibt dir Zugriff auf Sessions, User-Objekt und andere Django-Features.

2. Async-Support: FastAPI ist von Grund auf async, während Django Ninja primär synchron arbeitet (async Support ist experimentell).

3. Response-Handling: Django Ninja erlaubt es dir, direkt Django Model-Instanzen zurückzugeben, während FastAPI explizite Konvertierung benötigt.

Middlewares und Lifecycles: Verschiedene Philosophien

FastAPI Middleware und Lifecycle

FastAPI bietet ein minimalistisches aber mächtiges Middleware-System:

from fastapi import FastAPI, Request
from fastapi.middleware.cors import CORSMiddleware
import time

app = FastAPI()

# CORS Middleware
app.add_middleware(
    CORSMiddleware,
    # ! ACHTUNG: never ever in Production !
    allow_origins=["*"],
    allow_methods=["*"],
    allow_headers=["*"],
)

# Custom Middleware
@app.middleware("http")
async def add_process_time_header(request: Request, call_next):
    start_time = time.time()
    response = await call_next(request)
    process_time = time.time() - start_time
    response.headers["X-Process-Time"] = str(process_time)
    return response

# Lifecycle Events
@app.on_event("startup")
async def startup_event():
    # Initialisierung, z.B. Datenbankverbindung
    print("Starting up...")

@app.on_event("shutdown")
async def shutdown_event():
    # Aufräumen
    print("Shutting down...")

Django Ninja Middleware

Django Ninja nutzt das bewährte Django Middleware-System:

# Django Middleware (in middleware.py)
class ProcessTimeMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        start_time = time.time()
        response = self.get_response(request)
        process_time = time.time() - start_time
        response['X-Process-Time'] = str(process_time)
        return response

# In settings.py
MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    'myapp.middleware.ProcessTimeMiddleware',
    # ... andere Middlewares
]

# Django Ninja spezifische Features
from ninja import NinjaAPI

api = NinjaAPI()

# API-Level Middleware/Hooks
@api.exception_handler(ValidationError)
def validation_error_handler(request, exc):
    return api.create_response(
        request,
        {"detail": exc.errors()},
        status=422
    )

Der Hauptunterschied liegt in der Philosophie: FastAPI gibt dir ein leeres Blatt und du baust deine Middleware-Pipeline selbst auf. Django hingegen kommt mit einer umfangreichen Middleware-Sammlung (Security, Session, CSRF, etc.), die du bei Django Ninja automatisch nutzen kannst.

Automatische Dokumentationsgenerierung: Beide glänzen

Sowohl FastAPI als auch Django Ninja generieren automatisch interaktive API-Dokumentation. Aber es gibt feine Unterschiede.

FastAPI Dokumentation

from fastapi import FastAPI
from pydantic import BaseModel, Field

app = FastAPI(
    title="Meine tolle API",
    description="Das ist eine ausführliche Beschreibung meiner API",
    version="2.5.0",
    terms_of_service="https://blueshoe.de/terms/",
    contact={
        "name": "API Support",
        "email": "support@blueshoe.de"
    }
)

class Item(BaseModel):
    """Ein Item in unserem System"""
    name: str = Field(..., example="Beispiel Item", description="Der Name des Items")
    price: float = Field(..., gt=0, example=29.99, description="Preis in EUR")
    tax: Optional[float] = Field(None, example=2.5)

@app.post(
    "/items/",
    response_model=Item,
    summary="Erstelle ein neues Item",
    description="Erstelle ein neues Item mit allen Details",
    response_description="Das erstellte Item",
    tags=["items"]
)
async def create_item(item: Item):
    """
    Erstelle ein Item mit allen Informationen:
    
    - **name**: Eindeutiger Name des Items
    - **price**: Preis muss größer als 0 sein
    - **tax**: Optionale Steuerangabe
    """
    # Tatsächlicher Code ....
    return item

FastAPI generiert sowohl Swagger UI (unter /docs) als auch ReDoc (unter /redoc). Die Dokumentation ist hochgradig anpassbar und nutzt die Pydantic-Modelle für Beispiele.

Django Ninja Dokumentation

from ninja import NinjaAPI, Schema
from typing import Optional

api = NinjaAPI(
    title="Django Ninja API",
    version="1.0.0",
    description="Meine Django-basierte API"
)

class ItemSchema(Schema):
    """Schema für Items"""
    name: str = Field(..., example="Beispiel Item")
    price: float = Field(..., gt=0, example=29.99)
    tax: Optional[float] = None
    
    class Config:
        schema_extra = {
            "example": {
                "name": "Tolles Produkt",
                "price": 49.99,
                "tax": 3.5
            }
        }

@api.post(
    "/items/",
    response=ItemSchema,
    summary="Erstelle ein neues Item",
    tags=["items"],
    operation_id="create_item"
)
def create_item(request, item: ItemSchema):
    """
    Erstelle ein neues Item.
    
    Diese Funktion speichert das Item in der Django-Datenbank.
    """
    # Tatsächlicher Code ....
    return item

Django Ninja generiert ebenfalls eine Swagger UI (standardmäßig unter /api/docs). Ein Vorteil ist die Integration mit Django's Authentifizierung - die Dokumentation kann automatisch die verfügbaren Authentifizierungsmethoden anzeigen.

Authentifizierung & Sicherheit in der Praxis

Die Sicherheit von APIs ist entscheidend für den Schutz sensibler Daten. Lassen Sie uns die Authentifizierungsmöglichkeiten in beiden Frameworks vergleichen.

Token-Authentifizierung

FastAPI mit JWT:

from fastapi import Depends, FastAPI, HTTPException, status
from fastapi.security import OAuth2PasswordBearer, OAuth2PasswordRequestForm
from jose import JWTError, jwt
from passlib.context import CryptContext

app = FastAPI()

# Konfiguration
SECRET_KEY = "dein_geheimes_token"
ALGORITHM = "HS256"
oauth2_scheme = OAuth2PasswordBearer(tokenUrl="token")

@app.post("/token")
async def login(form_data: OAuth2PasswordRequestForm = Depends()):
    # Hier würde die Benutzerüberprüfung stehen
    user_dict = {"username": form_data.username}
    access_token = jwt.encode(user_dict, SECRET_KEY, algorithm=ALGORITHM)
    return {"access_token": access_token, "token_type": "bearer"}

Django Ninja mit JWT:

from ninja.security import HttpBearer
from ninja import NinjaAPI
import jwt

class AuthBearer(HttpBearer):
    def authenticate(self, request, token):
        try:
            return jwt.decode(token, "dein_geheimes_token", algorithms=["HS256"])
        except:
            return None

api = NinjaAPI(auth=AuthBearer())

@api.post("/token")
def login(request, username: str, password: str):
    # Benutzerüberprüfung hier
    return {"token": jwt.encode({"username": username}, "dein_geheimes_token")}

Berechtigungen (Permissions)

FastAPI:

from fastapi import Depends, HTTPException, status

def get_current_user(token: str = Depends(oauth2_scheme)):
    credentials_exception = HTTPException(
        status_code=status.HTTP_401_UNAUTHORIZED,
        detail="Could not validate credentials",
        headers={"WWW-Authenticate": "Bearer"},
    )
    try:
        payload = jwt.decode(token, SECRET_KEY, algorithms=[ALGORITHM])
        username: str = payload.get("sub")
        if username is None:
            raise credentials_exception
        return username
    except JWTError:
        raise credentials_exception

@app.get("/secure/")
async def read_secure(current_user: str = Depends(get_current_user)):
    return {"message": f"Hallo {current_user}"}

Django Ninja:

from ninja.security import django_auth
from django.contrib.auth.models import User

@api.get("/secure/", auth=django_auth)
def secure_route(request):
    return f"Hallo {request.user.username}"

Sicherheits-Middleware

FastAPI Sicherheits-Header:

from fastapi import FastAPI
from fastapi.middleware.httpsredirect import HTTPSRedirectMiddleware
from fastapi.middleware.trustedhost import TrustedHostMiddleware

app = FastAPI()

# Erzwinge HTTPS
app.add_middleware(HTTPSRedirectMiddleware)

# Erlaube nur bestimmte Hosts
app.add_middleware(
    TrustedHostMiddleware,
    allowed_hosts=["example.com", "*.example.com"],
)

Django Ninja (erbt von Django):

# settings.py
MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    # ...
]

# Sicherheitseinstellungen
SECURE_HSTS_SECONDS = 31536000  # 1 Jahr
SECURE_HSTS_INCLUDE_SUBDOMAINS = True
SECURE_SSL_REDIRECT = True
SESSION_COOKIE_SECURE = True
CSRF_COOKIE_SECURE = True

Zusammenfassung der Sicherheitsfeatures

• FastAPI: Bietet maximale Flexibilität, erfordert aber manuelle Konfiguration vieler Sicherheitsaspekte. Ideal für Entwickler, die volle Kontrolle benötigen.

• Django Ninja: Nutzt Djangos bewährte Sicherheitsfeatures wie CSRF-Schutz, Clickjacking-Schutz und sichere Cookies. Bietet eine höhere Sicherheit durch Voreinstellungen, ist aber weniger flexibel in der Anpassung.

Projektstruktur und Deployment

Eine klare Projektstruktur und ein reibungsloses Deployment sind entscheidend für den Erfolg Ihrer API. Hier sind die Best Practices für beide Frameworks.

Projektstruktur

FastAPI empfohlene Struktur:

fastapi_project/
├── app/
│   ├── __init__.py
│   ├── main.py              # Hauptanwendung
│   ├── config.py            # Konfiguration
│   ├── database.py          # Datenbankverbindung
│   ├── models/              # Pydantic Modelle
│   │   └── schemas.py
│   ├── api/                 # API-Endpunkte
│   │   ├── __init__.py
│   │   ├── v1/              # API Version 1
│   │   │   ├── __init__.py
│   │   │   ├── endpoints/   # Endpunkt-Module
│   │   │   └── deps.py      # Abhängigkeiten
│   ├── core/                # Kernlogik
│   └── tests/               # Tests
├── alembic/                 # Datenbank-Migrationen
├── static/                  # Statische Dateien
├── requirements.txt
└── .env                    # Umgebungsvariablen

Django Ninja empfohlene Struktur:

django_project/
├── manage.py
├── requirements.txt
├── .env
├── config/
│   ├── __init__.py
│   ├── settings.py
│   ├── urls.py
│   └── asgi.py
├── apps/
│   ├── __init__.py
│   └── api/
│       ├── __init__.py
│       ├── schemas.py      # Pydantic-Schemas
│       ├── routers.py      # API-Router
│       └── tests/
└── static/

Deployment mit Docker

FastAPI Dockerfile:

# Basis-Image mit Python 3.9
FROM python:3.9-slim

# Arbeitsverzeichnis setzen
WORKDIR /app

# Abhängigkeiten installieren
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# Anwendung kopieren
COPY . .

# Port freigeben
EXPOSE 8000

# Startbefehl
CMD ["uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "8000"]

Docker Compose für FastAPI:

version: '3.8'

services:
  web:
    build: .
    ports:
      - "8000:8000"
    env_file: .env
    depends_on:
      - db
    restart: unless-stopped

  db:
    image: postgres:13
    environment:
      POSTGRES_USER: ${DB_USER}
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      POSTGRES_DB: ${DB_NAME}
    volumes:
      - postgres_data:/var/lib/postgresql/data/
    ports:
      - "5432:5432"

volumes:
  postgres_data:

Django Ninja Dockerfile:

# Basis-Image mit Python 3.9
FROM python:3.9-slim

# Arbeitsverzeichnis setzen
WORKDIR /app

# System-Abhängigkeiten installieren
RUN apt-get update && apt-get install -y --no-install-recommends \
    build-essential \
    libpq-dev \
    && rm -rf /var/lib/apt/lists/*

# Python-Abhängigkeiten installieren
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# Anwendung kopieren
COPY . .

# Statische Dateien sammeln
RUN python manage.py collectstatic --noinput

# Port freigeben
EXPOSE 8000

# Startbefehl
CMD ["gunicorn", "config.wsgi:application", "--bind", "0.0.0.0:8000"]

Deployment-Optionen

FastAPI:

• Uvicorn/ASGI-Server: Für Produktionseinsatz hinter einem Reverse-Proxy
• Gunicorn mit Uvicorn Workern: Für bessere Auslastung
• Cloud-Anbieter: AWS (ECS, EKS), Google Cloud Run, Azure App Service
• Serverless: AWS Lambda mit Mangum

Django Ninja:

• Gunicorn/Uvicorn: Für synchrone/asynchrone Endpunkte
• Daphne: ASGI-Server für volle asynchrone Unterstützung
• Cloud-Anbieter: Wie FastAPI, plus spezielle Django-Hosting-Anbieter
• PaaS: Heroku, PythonAnywhere, Railway

CI/CD Integration

Beide Frameworks können problemlos in CI/CD-Pipelines integriert werden. Hier ein Beispiel für GitHub Actions:

name: Django CI

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    services:
      postgres:
        image: postgres:13
        env:
          POSTGRES_USER: test
          POSTGRES_PASSWORD: test
          POSTGRES_DB: test
        ports:
          - 5432:5432
        options: >-
          --health-cmd pg_isready
          --health-interval 10s
          --health-timeout 5s
          --health-retries 5

    steps:
    - uses: actions/checkout@v3
    - name: Set up Python
      uses: actions/setup-python@v4
      with:
        python-version: '3.9'
    - name: Install dependencies
      run: |
        python -m pip install --upgrade pip
        pip install -r requirements.txt
    - name: Run tests
      env:
        DATABASE_URL: postgresql://test:test@localhost:5432/test
      run: |
        python manage.py test

Praktische Pro-Tipps

1. HTTP-Status-Codes richtig nutzen

Problem: Django Ninja hat standardmäßig keine integrierte HTTP-Status-Code-Enumeration.

Lösung: Erstelle eine wiederverwendbare http_status.py Datei:

# http_status.py
from http import HTTPStatus
from typing import Any, Dict, Optional
from ninja import Response

def json_response(
    data: Any = None,
    status: int = HTTPStatus.OK,
    headers: Optional[Dict[str, str]] = None,
) -> Response:
    """Erstellt eine JSON-Response mit korrektem Status-Code."""
    return Response(
        content=data,
        status=status.value,
        headers=headers or {},
        content_type="application/json",
    )

# Verwendung:
# return json_response({"message": "Erfolg!"}, status=HTTPStatus.CREATED)

2. Performance-Optimierung für Django Ninja

# 1. Verwende select_related und prefetch_related
@api.get("/users/{user_id}")
def get_user(request, user_id: int):
    user = get_object_or_404(User.objects.select_related('profile'), id=user_id)
    return {"name": user.name, "email": user.email}

# 2. Paginierung für bessere Performance
from ninja.pagination import paginate, PageNumberPagination

@api.get("/articles/", response=List[ArticleSchema])
@paginate(PageNumberPagination, page_size=20)
def list_articles(request):
    return Article.objects.all()

3. FastAPI Performance-Tuning

# 1. Verwende Pydantic's orm_mode für bessere Performance
class UserResponse(BaseModel):
    id: int
    username: str
    email: str
    
    class Config:
        orm_mode = True

# 2. Caching für häufig abgerufene Endpunkte
from fastapi_cache import FastAPICache
from fastapi_cache.backends.redis import RedisBackend
from fastapi_cache.decorator import cache

@router.get("/expensive-query/")
@cache(expire=300)  # Cache für 5 Minuten
async def expensive_query():
    # Langsame Abfrage hier
    return {"result": "Daten aus dem Cache oder berechnet"}

4. Fehlerbehandlung

Django Ninja:

from ninja import NinjaAPI
from ninja.errors import HttpError

api = NinjaAPI()

@api.exception_handler(ValueError)
def handle_validation_error(request, exc):
    return api.create_response(
        request,
        {"detail": str(exc)},
        status=400,
    )

FastAPI:

from fastapi import FastAPI, HTTPException, Request
from fastapi.responses import JSONResponse

app = FastAPI()

@app.exception_handler(ValueError)
async def validation_exception_handler(request: Request, exc: ValueError):
    return JSONResponse(
        status_code=400,
        content={"detail": str(exc)},
    )

5. Dokumentation verbessern

FastAPI:

@app.get(
    "/items/{item_id}",
    response_model=Item,
    summary="Hole ein Item",
    description="""
    Diese Route gibt ein einzelnes Item zurück.
    - **item_id**: Die eindeutige ID des Items
    """,
    responses={
        200: {"model": Item, "description": "Das angeforderte Item"},
        404: {"description": "Item nicht gefunden"},
    },
)
async def read_item(item_id: int):
    return {"id": item_id, "name": "Beispiel"}

Django Ninja:

@api.get(
    "/items/{item_id}",
    response=ItemSchema,
    summary="Hole ein Item",
    description="""
    Diese Route gibt ein einzelnes Item zurück.
    - **item_id**: Die eindeutige ID des Items
    """,
    tags=["Items"],
    operation_id="get_item",
)
def get_item(request, item_id: int):
    return {"id": item_id, "name": "Beispiel"}

6. Umgebungsvariablen verwalten

Erstelle eine config.py für beide Frameworks:

# config.py
import os
from pydantic import BaseSettings, PostgresDsn

class Settings(BaseSettings):
    # Datenbank
    DATABASE_URL: str = "postgresql://user:password@localhost/dbname"
    
    # Sicherheit
    SECRET_KEY: str = "your-secret-key"
    ALGORITHM: str = "HS256"
    ACCESS_TOKEN_EXPIRE_MINUTES: int = 30
    
    class Config:
        env_file = ".env"
        case_sensitive = True

settings = Settings()

7. Logging einrichten

Für beide Frameworks:

import logging
from pathlib import Path

# Logger konfigurieren
log_dir = Path("logs")
log_dir.mkdir(exist_ok=True)

logging.basicConfig(
    level=logging.INFO,
    format="%(asctime)s - %(name)s - %(levelname)s - %(message)s",
    handlers=[
        logging.FileHandler(log_dir / "api.log"),
        logging.StreamHandler(),
    ],
)

logger = logging.getLogger(__name__)

# Verwendung:
# logger.info("API gestartet")
# logger.error("Ein Fehler ist aufgetreten", exc_info=True)

Fazit: Wann solltest du welches Framework wählen?

Nach diesem tiefen Einblick fragst du dich sicher: "Welches Framework ist das richtige für mich?" Die Antwort hängt von deinen Anforderungen ab.

Wähle FastAPI wenn:

• Du eine neue API von Grund auf entwickelst
• Maximale Performance und async-Support kritisch sind
• Du volle Kontrolle über jeden Aspekt deiner Anwendung willst
• Dein Team bereits Erfahrung mit modernen Python-Patterns hat
• Du primär APIs entwickelst (keine traditionellen Web-Views)

Wähle Django Ninja wenn:

• Du bereits ein Django-Projekt hast oder planst
• Du Django's Utilities (ORM, Admin, Auth, etc.) nutzen möchtest
• Dein Team Django-Erfahrung hat
• Du eine Mischung aus API und traditionellen Django-Views brauchst
• Schnelle Entwicklung wichtiger ist als maximale Performance

Beide Frameworks sind hervorragend und die Entscheidung ist keine Entweder-Oder-Frage. In der Praxis kannst du sogar beide in verschiedenen Projekten oder Microservices einsetzen. Das Wichtigste ist, dass du die Stärken und Schwächen verstehst und das richtige Werkzeug für deine spezifische Aufgabe wählst.

Die Entscheidung zwischen FastAPI und Django Ninja ist keine reine Technologiefrage – es geht darum, das richtige Werkzeug für deine spezifischen Anforderungen zu finden. Beide Frameworks ermöglichen es dir, moderne, performante APIs zu entwickeln, die den höchsten Standards entsprechen. Die Kunst liegt darin, die Stärken des gewählten Frameworks optimal zu nutzen und eine Architektur zu entwickeln, die nicht nur heute funktioniert, sondern auch morgen noch erweiterbar ist.

Stehst du vor der Entscheidung, welches Framework für dein nächstes Projekt das richtige ist? Oder planst du eine Migration deiner bestehenden API? Bei Blueshoe haben umfangreiche Erfahrung mit beiden Frameworks und unterstützen dich gerne dabei, die optimale Lösung für deine Anforderungen zu finden. Von der Architekturberatung über die Implementierung bis hin zur Performance-Optimierung – lass uns gemeinsam deine API-Vision Wirklichkeit werden lassen. Kontaktiere uns für ein unverbindliches Beratungsgespräch und profitiere von unserer Expertise in der modernen Python-Webentwicklung!

Häufig gestellte Fragen (FAQs)

1. Kann ich von FastAPI zu Django Ninja (oder umgekehrt) migrieren?

Die Migration ist definitiv möglich, aber der Aufwand hängt stark von deiner Codebasis ab. Von FastAPI zu Django Ninja ist oft einfacher, da du "nur" ein Django-Projekt drumherum bauen musst. Die API-Syntax ist so ähnlich, dass viele Endpoints mit minimalen Anpassungen übernommen werden können. Der größte Aufwand entsteht bei der Migration der Datenbank-Layer - von SQLAlchemy zu Django ORM.

Die umgekehrte Richtung (Django Ninja zu FastAPI) erfordert mehr Arbeit, da du die gesamte Django-Infrastruktur ersetzen musst. Du musst Authentifizierung, Datenbankzugriff, Middleware und andere Django-Features neu implementieren. Mein Tipp: Plane eine schrittweise Migration über mehrere Sprints und nutze die Übergangszeit, um beide APIs parallel zu betreiben.

2. Welches Framework ist schneller in der Performance?

FastAPI hat in reinen Benchmarks meist die Nase vorn, besonders bei asynchronen Operationen. Die Zahlen können beeindruckend sein - FastAPI kann teilweise doppelt so viele Requests pro Sekunde verarbeiten. Aber Vorsicht: Diese synthetischen Benchmarks spiegeln selten die Realität wider!

In der Praxis ist der Flaschenhals fast nie das Web-Framework selbst, sondern Datenbankzugriffe, externe API-Calls oder komplexe Business-Logik. Django Ninja's Performance ist für die allermeisten Anwendungen mehr als ausreichend. Wenn du wirklich jede Millisekunde brauchst, ist FastAPI mit async/await die bessere Wahl. Aber bedenke: Premature optimization is the root of all evil. Optimiere erst, wenn du echte Performance-Probleme identifiziert hast.

3. Wie sieht es mit Testing aus?

Beide Frameworks bieten exzellente Testing-Unterstützung, aber mit unterschiedlichen Ansätzen.

Bei FastAPI nutzt du typischerweise TestClient von Starlette:

from fastapi.testclient import TestClient
client = TestClient(app)
response = client.get("/items/1")
assert response.status_code == 200

Django Ninja profitiert vom ausgereiften Django-Test-Framework mit all seinen Features wie Fixtures, Transactional Tests und der Test-Datenbank. Du kannst sowohl Django's TestCase als auch Ninja's eigenen Test-Client verwenden. Der große Vorteil: Du kannst deine API-Tests nahtlos mit anderen Django-Tests kombinieren und hast Zugriff auf Dinge wie Factory Boy oder Model Mommy für Test-Daten.

4. Kann ich beide Frameworks im selben Projekt verwenden?

Technisch gesehen ja, aber ich rate davon ab! Du könntest theoretisch FastAPI für hochperformante Endpoints und Django (mit Ninja) für den Rest verwenden. In der Praxis führt das aber zu unnötiger Komplexität: zwei verschiedene Routing-Systeme, zwei Arten von Middlewares, potenzielle Konflikte bei Dependencies.

Eine bessere Strategie wäre eine Microservice-Architektur, wo verschiedene Services unterschiedliche Frameworks nutzen. Zum Beispiel: Django Ninja für deine Haupt-API mit Nutzerverwaltung und Business-Logik, FastAPI für einen spezialisierten Service, der Echtzeit-Datenverarbeitung macht.

5. Welches Framework hat die steilere Lernkurve?

Das hängt stark von deinem Hintergrund ab! Wenn du bereits Django kennst, wirst du dich bei Django Ninja sofort zuhause fühlen. Die API-Syntax ist intuitiv und du kannst dein Django-Wissen direkt anwenden.

FastAPI hat initial eine flachere Lernkurve, wenn du bei null startest. Die Konzepte sind modern und klar strukturiert. Aber sobald du über "Hello World" hinausgehst, musst du viele Entscheidungen treffen und Dinge selbst implementieren. Das kann überwältigend sein, wenn du nicht genau weißt, was du brauchst.

Mein Rat: Wenn du Python-Webentwicklung lernen willst, starte mit FastAPI für das Verständnis moderner API-Konzepte. Wenn du produktiv werden willst und bereits etwas Erfahrung hast, könnte Django Ninja der schnellere Weg sein.

6. Wie steht es um die Zukunftssicherheit beider Frameworks?

FastAPI hat enormen Momentum gewonnen und wird von einer sehr aktiven Community unterstützt. Große Unternehmen wie Microsoft, Netflix und Uber setzen es ein. Die Entwicklung ist sehr aktiv und das Framework wird ständig verbessert.

Django Ninja ist jünger und hat eine kleinere Community, profitiert aber von der Stabilität des Django-Ökosystems. Solange Django relevant bleibt (und dafür spricht alles), wird auch Django Ninja eine solide Wahl sein. Der Vorteil: Selbst wenn Django Ninja die Entwicklung einstellen würde, könntest du relativ einfach auf Django REST Framework oder pure Django-Views migrieren.

7. Gibt es Situationen, wo keines der beiden Frameworks passt?

Absolut! Wenn du eine GraphQL-API bauen willst, schau dir Strawberry oder Graphene an. Für WebSocket-heavy Anwendungen könnte Starlette oder Django Channels besser passen.

Für sehr einfache APIs oder Prototypen könnte auch Flask mit Flask-RESTX ausreichen. Und wenn du in der Data Science Welt unterwegs bist, könnte Streamlit oder Gradio für API-ähnliche Interfaces interessant sein. Das Schöne am Python-Ökosystem ist die Vielfalt - es gibt für jeden Use Case das passende Tool!

{.object-cover .max-w-full .mb-5}

Moderne E-Mail-Authentifizierung für Django-Anwendungen

E-Mails sind ein zentraler Bestandteil vieler Webanwendungen – und genau deshalb besonders kritisch, wenn sie nicht zuverlässig funktionieren. Viele Unternehmen setzen dabei auf Microsoft 365 und Exchange Online, während klassische SMTP-Authentifizierung zunehmend eingeschränkt oder ganz abgeschaltet wird. OAuth 2.0 ist inzwischen der empfohlene Standard.

Mit django-o365{target="_blank"} haben wir ein Mailbackend für Django{target="_blank"} entwickelt, das den Versand von E-Mails über Exchange Online mit OAuth-2.0-Authentifizierung ermöglicht und sich nahtlos in den bestehenden Django-Mail-Workflow integriert. In diesem Beitrag zeigen wir, auf welchen Bausteinen es aufsetzt und wie du es in deinem eigenen Projekt einsetzen kannst.

Ausgangslage: Mailversand mit django-exchange

In einem Bestandsprojekt eines unserer Kunden wurde der Mailversand bisher mit einem lokalen Postfach via Microsoft Exchange realisiert. Zu diesem Zweck haben wir damals das Paket django-exchange{target="_blank"} entwickelt. Das Postfach wurde nun zu Exchange Online mit OAuth 2.0 Authentifizierung migriert. Da es für Django noch kein geeignetes Paket gab, haben wir django-o365 entwickelt. Unsere größte Motivation dafür war eine saubere Django-Integration, sodass wir in unserem Projekt lediglich das Email-Backend austauschen müssen.

Technisches Fundament: python-o365

Als technisches Fundament setzt django-o365 auf das etablierte Python-Paket python-o365{target="_blank"}. Dieses stellt eine vollständige Abstraktion der Microsoft-Graph-API bereit und übernimmt unter anderem die Authentifizierung via OAuth 2.0 sowie den eigentlichen Versand der E-Mails über Exchange Online.

django-o365 nutzt python-o365 gezielt als Transport-Schicht, kapselt dessen Funktionalität jedoch vollständig hinter dem bekannten Django-Mail-Interface. So profitieren wir von einer stabilen und aktiv gepflegten Basis, ohne diese direkt im Anwendungscode verwenden zu müssen.

Auf eine eigene Implementierung der Microsoft-Graph-API haben wir bewusst verzichtet: python-o365 deckt den benötigten Funktionsumfang bereits zuverlässig ab und erlaubt es uns, den Fokus auf eine saubere Django-Integration, Wartbarkeit und einfache Nutzung zu legen.

Architektur & Funktionsweise

django-o365 ist bewusst schlank aufgebaut und folgt dem Prinzip, sich nahtlos in bestehende Django-Strukturen einzufügen. Kern des Pakets ist ein eigenes Django-Mailbackend, das die standardisierte Django-Mail-API implementiert. Sobald Django eine E-Mail versendet, übernimmt django-o365 die Übergabe an python-o365, welches wiederum den Versand über die Microsoft Graph API abwickelt.

Die Authentifizierung erfolgt vollständig über OAuth 2.0. Access- und Refresh-Tokens werden dabei von python-o365 verwaltet und erneuert, ohne dass der Anwendungscode davon etwas mitbekommt. django-o365 fungiert somit als Bindeglied zwischen Django und Exchange Online: Es übersetzt Djangos Mailversand in Graph-API-Aufrufe, ohne zusätzliche Logik in der Anwendung zu erzwingen.

Diese klare Trennung hat zwei Vorteile: Zum einen bleibt der Django-Code unverändert und unabhängig von Microsoft-spezifischen Details, zum anderen können wir auf eine bewährte Bibliothek für die komplexe OAuth- und API-Logik zurückgreifen.

Verwendung in Django

Da django-o365 aktuell noch nicht auf PyPI veröffentlicht ist, wird es direkt aus dem Git-Repository eingebunden, z.B. über die requirements.txt. Weitere Abhängigkeiten, insbesondere python-o365, werden automatisch mitinstalliert.

Auf Microsoft-Seite ist eine App-Registrierung in Microsoft Entra ID (ehemals Azure AD) erforderlich. Dort wird eine Anwendung angelegt, die die Berechtigung zum Versand von E-Mails über Microsoft Graph erhält (z.B. Mail.Send). Für die OAuth-Authentifizierung werden eine Client-ID, ein Client-Secret sowie der Tenant benötigt. Zusätzlich muss festgelegt werden, ob der Versand über ein Benutzerkonto oder ein Shared Mailbox Postfach erfolgen soll.

In Django beschränkt sich die Konfiguration auf die Settings. Dort wird lediglich das Mailbackend auf django-o365 umgestellt und die benötigten Zugangsdaten hinterlegt:

EMAIL_O365_TENANT_ID = 'my-tenant-id'
EMAIL_O365_CLIENT_ID = 'my-client-id'
EMAIL_O365_CLIENT_SECRET = 'my-super-secret'
EMAIL_O365_SENDER = 'mysender@example.com'

# set backend
EMAIL_BACKEND = 'django_o365.backend.O365EmailBackend'

Am eigentlichen Anwendungscode muss nichts geändert werden. Bestehende Aufrufe von send_mail, EmailMessage oder EmailMultiAlternatives funktionieren weiterhin unverändert. Der Wechsel auf Exchange Online mit OAuth 2.0 erfolgt ausschließlich über Konfiguration – genau das war eines der zentralen Ziele bei der Entwicklung von django-o365.

Open Source & Ausblick

Wir bei Blueshoe sind überzeugt vom Open Source Ansatz. Somit ist django-o365 selbstverständlich als Open-Source-Projekt konzipiert und wird offen auf GitHub entwickelt. Der aktuelle Fokus liegt bewusst auf einem klaren, stabilen Kern: dem zuverlässigen Mailversand über Exchange Online mit OAuth-2.0-Authentifizierung im Credentials-Workflow. Der Versand von E-Mails inklusive Anhängen wird bereits vollständig unterstützt und deckt damit die gängigen Anwendungsfälle in Webprojekten ab.

Für die Zukunft sind weitere Authentifizierungs-Workflows denkbar, etwa stärker benutzerbezogene Szenarien. Der Anspruch bleibt dabei derselbe: eine saubere Django-Integration ohne unnötige Komplexität im Anwendungscode. Feedback, Anregungen und Beiträge aus der Community sind ausdrücklich willkommen – sie helfen dabei, das Paket gezielt weiterzuentwickeln und praxisnah zu halten.

{.object-cover .max-w-full .mb-5}

:::globalTitle{:size="lg" .mb-5 .mt-8} Installation ::: :::globalParagraph Die Installation von Docker Desktop ist für alle gängigen Plattformen recht einfach. Es gibt auch Installationskandidaten für Apples neue Silicon- und Intel-basierte Chipsätze. Das ist praktisch und erleichtert den Einstieg für Entwickler, die mit der Container-basierten Entwicklung beginnen möchten. ::: :::globalParagraph Als jemand, der mit Linux (speziell mit Ubuntu) arbeitet, stört es mich jedoch ein wenig, ein >500 MiB Installationspaket aus dem Browser auf meinen Rechner herunterzuladen. Normalerweise möchte ich ein Software-Repository hinzufügen und damit automatisch Update-Strategien konfigurieren. Wenn ich Docker Desktop aktualisieren möchte (ja, Docker Desktop sagt mir in der Benutzeroberfläche Bescheid), muss ich ein weiteres Installationspaket von der Website herunterladen und den Updater entsprechend ausführen. ::: :::globalParagraph Im Kern ist die Idee einfach: Führe einen logischen oder "virtuellen" Kubernetes-Cluster innerhalb eines physischen oder "Host"-Kubernetes-Clusters aus. Dieses Konzept bringt eine neue Ebene der Flexibilität, da es Entwicklern ermöglicht, schnell isolierte Umgebungen zu erstellen, ohne den Aufwand, mehrere physische Cluster zu verwalten. Mit diesem Ansatz können Entwickler Produktionsumgebungen replizieren, sicher experimentieren und Anwendungen für das Kubernetes-Ökosystem optimieren. :::

:::globalTitle{:size="lg" .mb-5 .mt-8} VM-Backend auf allen Plattformen erforderlich ::: :::globalParagraph Docker Desktop benötigt ein virtuelles Maschinen (VM)-Backend auf allen Plattformen, einschließlich Linux. Das ist erforderlich, da Software-Container eine Linux-native Technologie sind und daher auf Windows und Mac nicht direkt unterstützt werden. Auf Windows kannst du entweder das WSL2-Subsystem verwenden (eine leichte VM mit einem begrenzten Hyper-V-Toolset, um den Linux-Kernel auszuführen) oder ein Hyper-V-Backend. Je nach Windows-Edition wird die erste oder zweite Option empfohlen. Auf macOS läuft Docker Desktop mit HyperKit, einem Toolkit zur Einbettung von Hypervisor-Funktionen in eine Anwendung. Auf Linux wird QEMU verwendet. ::: :::globalParagraph Die Frage, warum Docker Desktop auf Linux genau eine VM benötigt, wird hier beantwortet. Ich finde die aufgeworfenen Punkte nachvollziehbar, auch wenn es bedeutet, dass ich Leistungseinbußen hinnehmen muss. ::: :::globalParagraph Zumindest unter Linux besteht die Alternative darin, nur den Docker-Daemon (auch als Docker-Engine bezeichnet) auszuführen. Dadurch kann ich Container mit systemweiter Leistung ausführen und verwalten. Das ist ein großer Vorteil gegenüber anderen Plattformen. Es scheint jedoch nicht möglich zu sein, Docker Desktop mit einem nativen Docker-Daemon zu verwenden. Das wäre das Beste aus beiden Welten: die Funktionen und Bequemlichkeit von Docker Desktop und die Leistung einer nativen Docker-Engine. Nun, diese Option wird wahrscheinlich nie eintreten. :::

:::globalTitle{:size="lg" .mb-5 .mt-8} Leistung & Bequemlichkeit ::: :::globalParagraph Wenn wir über Bequemlichkeit sprechen: Worum geht es genau bei der Entwicklererfahrung mit Docker Desktop? Lass mich mit dem wichtigsten Nachteil im Jahr 2023 beginnen. ::: :::globalParagraph Da ich täglich mit der Docker CLI (zusammen mit der Docker-Engine) in Linux arbeite, bin ich sehr daran gewöhnt. Bisher war der Docker-Daemon (prominent) auf Windows oder macOS nicht verfügbar und konnte nur über die Docker Desktop-VM auf diesen Plattformen installiert werden. In der Vergangenheit habt mein Team bei Blueshoe erhebliche Unterschiede in der Geschwindigkeit der Containerausführung und dem Ressourcenverbrauch des VM-basierten Workarounds von Docker Desktop festgestellt. Wir haben beispielsweise lokale Kubernetes-Cluster{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} mit k3d auf Basis von Docker-Containern ausgeführt, was für Linux-Benutzer in Ordnung war, aber für Mac-Benutzer selbst mit vergleichbaren oder besseren Hardware-Spezifikationen (d.h. CPU, Speicher usw.) nahezu unmöglich war. :::

:::globalTitle{:size="lg" .mb-5 .mt-8} Echte Rechenleistung erforderlich ::: :::globalParagraph Die Startzeit von Docker Desktop, insbesondere auf macOS, ist sehr lang und die Containerleistung ist ehrlich gesagt ziemlich schlecht. Da du die Systemressourcen nur für die gesamte VM anpassen kannst, musst du viel verfügbare Kapazität deines Host-Systems zugunsten der Docker-VM abzweigen. Der Nachteil ist, dass du eine sehr unflexible Ressourcenzuweisung erhältst. Wenn du viel Kapazität in die Docker-VM steckst, wirst du sie wahrscheinlich auf deinem Host-System vermissen und umgekehrt. Nur eine sehr leistungsstarke Maschine (mit mehr als 8 Kernen und mehr als 16 GiB Speicher) wird für ernsthafte containerbasierte Entwicklungsaufgaben ausreichen. In der Realität betreibst du auch eine ressourcenintensive IDE, einen Webbrowser mit vielen geöffneten StackOverflow-Tabs, einige Instant-Messenger und mehr auf deiner Entwicklungsmaschine. Das frisst auch viel Kapazität. Das Ausführen von Docker Desktop erfordert eine weitere enorme Anforderung, die einen gewöhnlichen Entwicklungsscomputer wahrscheinlich in die Knie zwingen wird. Das mindert die Bequemlichkeit und die Entwicklererfahrung von Docker Desktop erheblich. ::: :::globalParagraph Das Starten der integrierten Kubernetes-Distribution dauert ebenfalls sehr lange. Dies hat sich mit der WSL2-Integration unter Windows deutlich verbessert. Ich vermute, dass die Ressourcenzuweisung von WSL2 flexibler ist als bei Hyper-V-basierten VMs. Auf macOS ist dies immer noch sehr zeitaufwändig und frustrierend, wenn es mehrmals am Tag durchgeführt wird. :::

:::globalTitle{:size="lg" .mb-5 .mt-8} Viel besser als nur eine CLI ::: :::globalParagraph Aber abgesehen von der Leistung bietet Docker Desktop eine sehr saubere und intuitive grafische Benutzeroberfläche.Meiner Meinung nach ist es sehr einfach, wenn du bereits zuvor mit Containern gearbeitet hast. Zum Beispiel ist es ein großer Vorteil, mit einem Klick von Logs zu interaktiven Terminals zu Umgebungsvariablen zu wechseln. Das ist ein großer Vorteil gegenüber der reinen CLI (auch wenn du damit sehr schnell bist) und fühlt sich eher wie ein Entwicklungstool an, das nicht nur zum "Ausführen eines Software-Containers" entwickelt wurde. Möchtest du mit Kubernetes arbeiten? - Kein Problem. Aktiviere einfach das Kontrollkästchen in den Einstellungen und warte, bis Kubernetes verfügbar ist. ::: :::globalParagraph Alles, was du zusätzlich benötigst, ist kubectl, die primäre Schnittstelle zu jedem Kubernetes-Cluster. Die kubeconfig wird automatisch mit dem richtigen Kontext vorbereitet, sodass kubectl sofort einsatzbereit ist. :::

{.object-cover .w-full .mb-5}

:::globalTitle{:size="lg" .mb-5 .mt-8} Einrichten von Docker Desktop Kubernetes ::: :::globalParagraph Die Arbeit mit Kubernetes in Docker Desktop erfordert eine ziemlich leistungsstarke Entwicklungsmaschine. Abgesehen von dieser Anforderung kannst du auf die Einschränkung stoßen, dass nur eine Kubernetes-Version verfügbar ist: diejenige, die mit der installierten Docker Desktop-Version geliefert wird. Das kann ein Problem sein, wenn du die spezifische Kubernetes-Version deines Produktionssystems abstimmen möchtest (im Hinblick auf die Übereinstimmung von Entwicklung und Produktion). ::: :::globalParagraph Wenn du eine bestimmte Kubernetes-Version installieren möchtest, schaue dir diesen Artikel an{.bs-link-blue}. Du könntest minikube mit dem --kubernetes-version-Flag und dem Docker-Treiber verwenden, um jede verfügbare Kubernetes-Version auf Docker Desktop zu installieren. Das könnte sogar hinsichtlich der Startzeit schneller sein. ::: :::globalParagraph Die mit Docker Desktop gelieferte Kubernetes-Distribution ist neutral. Das ist ein Vorteil, wenn du mit einer produktionsnahen Umgebung arbeiten möchtest. Der Nachteil ist jedoch, dass Entwickler alle Bausteine selbst bereitstellen müssen. Zum Beispiel ist standardmäßig kein Ingress-Controller verfügbar. Im Vergleich zu k3d sind einige zusätzliche Schritte erforderlich, um ihn verfügbar zu machen: :::

:::globalTitle{:size="lg" .mb-5 .mt-8} Welcher Ingress-Controller sollte verwendet werden? ::: :::globalParagraph Du kannst aus einer Reihe verschiedener Ingress-Controller für Kubernetes wählen. Die Plattform "learnk8s" pflegt eine sehr umfassende Tabelle, die praktisch alle Kubernetes Ingress-Controller vergleicht: :::

{.object-cover .w-full .mb-5}

:::globalParagraph Diese Entscheidung sollte für Entwickler jedoch nicht sehr relevant sein. Wenn du immer noch nicht weißt, welchen Ingress-Controller du mit Docker Desktop verwenden sollst, kannst du wahrscheinlich jeden von ihnen wählen. Ich persönlich empfehle den Ingress-Nginx-Controller, der auch ein offizielles Kubernetes-Projekt ist. :::

:::globalTitle{:size="lg" .mb-5 .mt-8} Installiere Ingress-Nginx auf deinem Docker Desktop Kubernetes ::: :::globalParagraph Um es zu installieren, musst du zunächst sicherstellen, dass dein kubeconfig-Kontext auf docker-desktop festgelegt ist. In einem Terminal kannst du den folgenden Befehl ausführen: :::

:::BlogCode{.mb-5}

> kubectl config current-context

docker-desktop

:::

:::globalParagraph Wenn dieser Befehl etwas anderes sagt, setze den Kontext auf docker-desktop mit: ::: :::BlogCode{.mb-5}

> kubectl config use-context docker-desktop

Switched to context "docker-desktop".

:::

:::globalParagraph Wende dann einfach die Ingress-Controller-Konfigurationen für Kubernetes an, etwa so: ::: :::BlogCode{.mb-5}

> kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.6.4/deploy/static/provider/cloud/deploy.yaml

:::

:::globalParagraph Du kannst den ingress-controller mit diesem Befehl überprüfen und er sollte folgendes anzeigen: ::: :::BlogCode{.mb-5}

> kubectl -n ingress-nginx get pod

  NAME                                        READY   STATUS      RESTARTS   AGE
  ingress-nginx-admission-create-szn97        0/1     Completed   0          70s
  ingress-nginx-admission-patch-plpcx         0/1     Completed   0          70s
  ingress-nginx-controller-6b94c75599-vpjjd   1/1     Running     0          70s

:::

:::globalParagraph Et voilà, dein lokaler Kubernetes-Cluster ist bereit, echten HTTP-Verkehr zu bedienen. ::: :::globalParagraph Wichtig: Das Kubernetes von Docker Desktop bindet direkt an die Ports deines lokalen Computers. Das bedeutet, dass der gerade installierte Ingress-Controller auf Port 80 gestartet wird, der auf deinem Computer frei sein muss. :::

:::globalTitle{:size="lg" .mb-5 .mt-8} Testen des Ingress-Controllers mit einer kleinen Demo-Anwendung ::: :::globalParagraph Bestätigen wir, dass es funktioniert, indem wir eine Test-Workload anwenden und sie mit einem Ingress-Objekt freigeben: ::: :::BlogCode{.mb-5}

> kubectl apply -f https://raw.githubusercontent.com/gefyrahq/gefyra/main/testing/workloads/hello_dd.yaml

:::

:::globalParagraph Dies ist die "hello-nginx" Anwendung, von unserem Kubernetes-Entwicklungstool Gefyra ::: :::globalParagraph Wenn du die Ingress-Objekte überprüfen möchtest, verwende: ::: :::BlogCode{.mb-5}

> kubectl get ingress

NAME            CLASS    HOSTS                    ADDRESS   PORTS   AGE
hello-ingress   <none>   hello.127.0.0.1.nip.io             80      7s

::: :::globalParagraph Du erreichst das hello-ingress-Objekt unter http://hello.127.0.0.1.nip.io (dafür müssen nip.io-Domains in deinem aktuellen Netzwerk funktionieren; falls nicht, suche nach "DNS rebind protection"). Sobald du deinen Browser auf diese Adresse richtest, wirst du mit dem Hello Nginx-Bildschirm begrüßt. :::

{.object-cover .max-w-full .mb-5}

:::globalParagraph Es gibt einige Informationen über deinen Cluster preis: den Namen des Pods, der diesen einfachen Prozess ausführt, und die IP-Adresse des Pods. :::

:::globalTitle{:size="lg" .mb-5 .mt-8} Wie sieht die Docker Desktop GUI aus? ::: :::globalParagraph Wenn du zu Docker Desktop zurückkehrst, findest du alle Container, die wir gerade in Kubernetes installiert haben, auch im Abschnitt "Container". :::

{.object-cover .w-full .mb-5}

:::globalParagraph Durch Klicken auf die Schaltfläche "Details anzeigen" des Containers "k8s_hello-nginx_hellp-nginxdemo" erhältst du Protokolle und viele andere nützliche Informationen. Du kannst sogar über den Tab "Terminal" eine interaktive Shell starten. :::

{.object-cover .w-full .mb-5}

:::globalParagraph Das ist sehr praktisch, wenn du den Zustand des Containers überprüfen oder einen einmaligen Verwaltungsbefehl deiner Anwendung ausführen möchtest. :::

:::GlobalPodcastSection{:videoId="tyvE9VlSWkE" :videoPosition="left" .mb-6} ::::GlobalPreTitle{:color="text-bs-green" .mb-3} UNSER PODCAST: TOOLS FOR THE CRAFT :::: ::::GlobalTitle{:tag="h3" .mb-6} E3: Tiefere Einblicke in Getdeck :::: ::::globalParagraph{:font-size="lg" .mb-4} Michael und Robert stellen Getdeck vor, demonstrieren es und vergleichen lokale und entfernte Kubernetes- und Vorproduktionscluster. :::: ::::globalParagraph{:font-size="lg" } Weitere Ausgaben unseres Podcasts findest du hier: :::: ::::GlobalButton{:url="/kubernetes-podcast/" :label="Mehr anzeigen" :color="green"} :::: :::

:::globalTitle{:size="lg" .mb-5 .mt-8} Code schreiben mit Docker Desktop Kubernetes ::: :::globalParagraph Als Entwickler ist es nur natürlich, dass ich Code schreiben und schnell iterieren möchte. In vielen modernen Umgebungen findet man Kubernetes-basierte Produktionsumgebungen. Daher ist es konsequent, dass auch Kubernetes-basierte Entwicklungsumgebungen im Trend liegen. ::: :::globalParagraph Wenn DevOps viel Aufwand betreiben, um gute Kubernetes-Konfigurationen für alle erforderlichen Ressourcen zu schreiben, die die Anwendung ausmachen, warum stellen wir diese Ressourcen dann nicht auch unseren Entwicklern zur Verfügung? ::: :::globalParagraph Angenommen, du möchtest eine Kubernetes-basierte Entwicklungsumgebung erstellen. Hier ist, was du brauchst: :::

:::GlobalBlock{.ol-decimal .mb-5}

1. Sammele alle Ressourcen zur Bereitstellung eines Kubernetes-Clusters (z.B. brauchst du Helm-Charts, Kustomize-Ressourcen oder einfache YAML-Dateien). Wenn du unsicher bist, frage deinen DevOps, dir Anleitungen zur Verfügung zu stellen.
2. Installiere alle Komponenten, die die Anwendung ausmachen, in deinem lokalen Kubernetes-Cluster (z.B. erforderliche Datenbanken, Caches, Indizes, APIs{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} und andere Anwendungen). Alternativ kannst du nur die Komponenten installieren, die wirklich für deine spezielle Anwendung erforderlich sind, um Rechenkapazität zu sparen.
3. Stelle sicher, dass alles läuft. ::: :::globalParagraph Von hier aus hast du im Grunde genommen einige Optionen, um die Entwicklungswerkzeuge einzurichten. :::

:::globalTitle{:size="lg" .mb-5 .mt-8} Lokale Container-Images in Kubernetes ausführen ::: :::globalParagraph Kubernetes ruft normalerweise Images aus einem Container-Register ab, was bedeutet, dass du das von uns erstellte Image nach jeder Änderung hochladen und herunterladen musst. Docker Desktop erleichtert dies, indem es dockershim verwendet, um den Image-Cache zwischen dem Docker-Engine und Kubernetes gemeinsam zu nutzen. ::: :::globalParagraph Das dockershim ist eine Komponente, die mit Docker Desktop Kubernetes geliefert wird und zwischen dem Kubernetes kubelet und der Docker-Engine übersetzt. ::: :::globalParagraph Das ist ein großer Vorteil für Entwickler, da sie ihre Container-Images nicht hochladen und herunterladen müssen, bevor sie sie in Docker Desktop Kubernetes ausführen können. Diese Funktion ist in gewisser Weise ähnlich zu dem, was du mit k3d, minikube und kind erreichen kannst, indem du das Container-Image auf deine Cluster-Knoten importierst. Mit Docker Desktop musst du jedoch das Container-Image wie gewohnt erstellen und es nicht in einen Kubernetes-Knoten importieren. Das ist sogar schneller als bei anderen lokalen Kubernetes-Lösungen. ::: :::globalParagraph Wenn du die Ausgabe der oben genannten "hello-nginx"-Anwendung ändern möchtest, wirf zuerst einen Blick auf die Workload-Spezifikation: :::

:::BlogCode{.mb-5}

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-nginxdemo
spec:
  selector:
    matchLabels:
      app: hello-nginx
  replicas: 1
  template:
    metadata:
      labels:
        app: hello-nginx
      spec:
        containers:
            - name: hello-nginx
            image: nginxdemos/hello
            ports:
            - containerPort: 80

:::

:::globalParagraph Es sagt, dass das ausgeführte Container-Image "nginxdemos/hello" ist, das vom Dockerhub abgerufen wurde. Du kannst diese Informationen auch mit Docker Desktop im Abschnitt "Container" finden (siehe Screenshot von oben). ::: :::globalParagraph Jetzt kannst du entweder eine neue Version dieses Container-Images mit docker build . -t nginxdemos/hello erstellen und den Kubernetes-Pod löschen: :::

:::BlogCode{.mb-5}

> kubectl get pod

NAME                               READY   STATUS    RESTARTS   AGE
hello-nginxdemo-6c4f96b577-2rkcp   1/1     Running   0          51m

> kubectl delete pod hello-nginxdemo-6c4f96b577-2rkcp

pod "hello-nginxdemo-6c4f96b577-2rkcp" deleted

:::

:::globalParagraph Du erhältst fast sofort einen neuen Pod, der jedoch diesmal dein benutzerdefiniertes Container-Image ausführt, das du gerade erstellt hast. ::: :::globalParagraph Anstatt das ursprüngliche Container-Image, das mit der Kubernetes-Ressource geliefert wird, wiederzuverwenden, kannst du auch ein benutzerdefiniertes Container-Image erstellen und es beliebig benennen. Anschließend kannst du die Bereitstellung einfach ändern und dieses Image ausführen: :::

:::BlogCode{.mb-5}

> kubectl patch deployment hello-nginxdemo -p '{"spec":{"template":{"spec":{"containers":[{"name":"hello-nginx","image":"my-custom-image"}]}}}}'

:::

:::globalParagraph Dies führt zum gleichen Ergebnis: Der Pod wird mit dem neuen Image neu gestartet, das du gerade erstellt habst. Kubernetes wird sich nicht die Mühe machen, das Image abzurufen, da der Docker-Engine, den du zum Erstellen des Container-Images verwendest, genau derselbe ist wie der von Docker Desktop Kubernetes verwendete. Sie teilen sich den gleichen Image-Cache, was es sehr bequem macht, ein beliebiges Image im lokalen Cluster auszuführen. ::: :::globalParagraph Übrigens werden dem Container alle Kubernetes-Ressourcen und -Konfigurationen zur Verfügung stehen. Dies macht ihn der Produktionsumgebung sehr nahe. :::

:::globalTitle{:size="lg" .mb-5 .mt-8} Verwendung zusätzlicher Tools für noch schnellere Interaktion ::: :::globalParagraph Wenn du das Container-Image nicht jedes Mal neu erstellen möchtest, wenn du eine Code-Änderung vornimmst, brauchst du zusätzliche Tools. Wenn du einen Debugger an den Container-Prozess anhängen möchtest, kannst du dies nicht einfach mit dem lokalen Kubernetes{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} tun. Darüber hinaus musst du deine Kubernetes-Konfigurationen im Cluster ändern, wenn du Umgebungsvariablen überschreiben musst (sagen wir, du möchtest einen DEBUG-Flag setzen). ::: :::globalParagraph Blueshoe hat Gefyra{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} genau für diesen Anwendungsfall entwickelt. Damit kannst du einfach docker run ... – pardon, ich meinte gefyra run ... (es ist fast dasselbe) – dein Container-Image ausführen, ohne einen Kubernetes-Pod neu laden zu müssen. Auf diese Weise kannst du dein aktuelles Arbeitsverzeichnis in den Container einbinden und das Hot-Reloading-Flag in deinem Prozess aktivieren (falls verfügbar). Du kannst ganz einfach Umgebungsvariablen setzen und das Beste daran ist, dass du diesen Container auf einem dedizierten lokalen Port exponieren kannst, um noch schneller iterieren zu können. Der Container verhält sich wie in einem Kubernetes-Pod (einschließlich Netzwerksemantik) und erreicht daher alle auf Kubernetes basierenden Ressourcen wie Datenbanken oder andere Anwendungen. ::: :::globalParagraph Dies funktioniert mit der Befehlszeilenanwendung gefyra oder alternativ können Entwickler von der Gefyra Docker Desktop-Erweiterung aus dem Marketplace profitieren. ::: :::globalParagraph Schaue dir Gefyra und unseren Getting Started Guide zur Verwendung mit Docker Desktop Kubernetes oder der Docker Desktop-Erweiterung an. :::

:::globalTitle{:size="lg" .mb-5 .mt-8} Abschließende Bemerkungen ::: :::globalParagraph Obwohl Docker Desktop die Entwicklung mit Kubernetes vereinfacht, gibt es immer noch einige Herausforderungen. Die Ressourcenanforderungen sind überwältigend und der Aufbau eines Clusters, der der Produktion nahe kommt, erfordert Zeit und Wissen. Ich habe eine Diskussion im Docker-Ideenboard auf GitHub erstellt, um diesen Prozess in Zukunft einfacher zu gestalten. Vielleicht wird es aufgegriffen und umgesetzt. ::: :::globalParagraph Es gibt bereits einige interessante Docker Desktop-Erweiterungen im Marketplace, die das Entwicklungserlebnis noch weiter verbessern können. Bleib dran für einen weiteren Artikel, in dem wir bestehende Kubernetes-basierte Entwicklungserweiterungen vorstellen möchten. ::: :::globalParagraph Langfristig betrachtet sehe ich die lokale Kubernetes-Entwicklung jedoch nicht als nachhaltige Option. Remote-Entwicklungsumgebungen sind die Zukunft! Getdeck Beiboot wird alle auf Kubernetes basierenden Ressourcen ausführen, und mit Tools{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} wie Gefyra ermöglichen wir Entwicklern, in einer echten Kubernetes-basierten Entwicklungsumgebung mit nur wenigen lokal ausgeführten Containern zu arbeiten. ::: :::globalParagraph Wenn du mehr über die Kubernetes-basierte Entwicklung erfahren möchtest, folge mir auf LinkedIn oder schreibe uns bei Blueshoe. :::

{.object-cover .max-w-full .mb-5}

:::globalTitle{:size="lg" .mb-5} Was ist Docker im Jahr 2023? ::: :::globalParagraph Docker ist ein langjähriger Akteur in der Container-Welt und existiert seit 2013. Wenn du die Branche schon eine Weile verfolgst, hast du sicherlich schon von Docker gehört oder es sogar selbst verwendet! ::: :::globalParagraph In den letzten Jahren hat sich das Unternehmen darauf konzentriert, die Entwicklererfahrung zu verbessern und sicherzustellen, dass Container in allen Phasen des Anwendungslebenszyklus effektiv von Entwicklern genutzt werden können. Es bietet auch eine umfangreiche Funktionssammlung für den Betrieb von Containern in der Produktion. Das Unternehmen hinter der Technologie, Docker Inc., hat auch einen fantastischen geschäftlichen Schwenk vollzogen und ist nun mit seinem abonnementbasierten Modell sehr profitabel. Sich auf Docker als kommerziell unterstütztes Produkt zu verlassen, könnte eine solide Entscheidung für die Zukunft sein. ::: :::globalParagraph Da Docker schon lange auf dem Markt ist, unterstützt es auch viele Funktionen, wie den Rootless-Modus (dazu später mehr). Dadurch ist es nicht mehr erforderlich, den Docker-Daemon mit Root-Rechten auf den Servern auszuführen. Das macht es für alle einfacher, da du Container verwenden kannst, ohne dich um privilegierten Zugriff oder die Sicherheitsprobleme kümmern zu müssen, die du als Root-Benutzer sonst hättest. ::: :::globalParagraph Docker bietet eine sehr umfassende Dokumentation zu nahezu jedem Thema, das bei der Arbeit mit Containern aufkommt. :::

:::globalTitle{:size="lg" .mb-5} Was ist das Besondere an Podman? ::: :::globalParagraph Podman ist eine relativ neue Container-Laufzeitumgebung, hat aber bereits Einzug in viele Standard-Software-Repositories für Linux erhalten. Du musst keine externen Quellen hinzufügen, um es auf deinem Host zu installieren. Es ist manchmal bereits bei einer frischen Installation verfügbar. ::: :::globalParagraph Podman läuft ohne Daemon und bietet eine Entwicklungserfahrung, die der von Docker sehr nahe kommt, d.h., die meisten Befehle in der Podman-CLI sind identisch mit denen der Docker-CLI. Podman Desktop, eine grafische Benutzeroberfläche für Podman, sieht ebenfalls fast genauso wie Docker Desktop aus. ::: :::globalParagraph Die Dokumentation von Podman ist ehrlich gesagt nicht so gut und lässt bestimmte Themen vollständig aus. ::: :::globalParagraph Die folgende Abbildung zeigt einen Graphen von Google Trends, der das wachsende Interesse an Podman in den letzten Jahren deutlich zeigt. ::: {.object-cover .max-w-full .mb-5} :::globalParagraph Podman ist ein von Red Hat gesponsertes Community-Projekt. :::

:::globalTitle{:size="lg" .mb-5} Was unterscheidet Podman von Docker? ::: :::globalParagraph Podman und Docker haben viele ähnliche Eigenschaften. Beide sind Tools zur Verwaltung von Containern unter Linux, die auf den gleichen Kernel-Funktionen (wie Namespaces und cgroups) aufbauen, die es ihnen ermöglichen, Prozesse voneinander isoliert auszuführen ('Sandboxing'). Die Benutzeroberfläche ist nahezu identisch, was einen einfachen und praktischen Wechsel zwischen den beiden ermöglicht. Du kannst sogar die meisten Container-Images, die du bereits hast, weiterhin verwenden (sofern sie mit dem OCI-Container-Image-Format kompatibel sind). ::: :::globalParagraph Lass uns einen genaueren Blick auf die Unterschiede zwischen Podman und Docker werfen. :::

:::globalTitle{:size="lg" .mb-5} Daemon – oder kein Daemon ::: :::globalParagraph Docker führt einen Daemon-Prozess ('docked') auf dem Host-System aus, der in der Regel mit Root-Rechten ausgestattet ist. Was macht der Daemon-Prozess in den Tiefen des Systems? Nun, im Grunde alles, was zur Verwaltung von Containern auf dem Host benötigt wird: Überwachung laufender Container-Instanzen, Verwaltung der Container-Images, Bereitstellung von Speichervolumes und vieles mehr. Er erstellt Container-Netzwerke auf Anfrage und kümmert sich um alle niedrigstufigen Container-Dinge, insbesondere containerd und runc. Der Daemon-Prozess erstellt eine API-Schnittstelle mit einem HTTP-Protokoll, um seine Funktionalität für alle Arten von Benutzeroberflächen zugänglich zu machen, einschließlich der Docker-Befehlszeile. Je nach Plattform wird die Docker-Schnittstelle über einen Unix-Socket, eine benannte Pipe oder einen TCP-Port (mit vielen Optionen, um sie sicher zu machen) realisiert. Der Docker-Daemon läuft mit sehr geringem Ressourcenverbrauch. :::

:::globalTitle{:size="sm" :tag="h3" .mb-5} Kein Daemon mit Podman ::: :::globalParagraph Podman verzichtet dagegen auf den Daemon-Prozess ('daemonlose Container-Engine'). Das Container-Management erfolgt direkt vom Client aus. Daher erlaubt das Aufrufen von Podman mit einem anderen Benutzer als root nur die Operationen, die dieser Benutzer ausführen darf. Dies beschränkt natürlich die Möglichkeiten des Benutzers – aber auch die von Eindringlingen, die einen Container von innen übernehmen könnten. ::: :::globalParagraph Aus Sicherheitssicht ist das 'rootless'-Phänomen also eine ziemlich gute Idee. Und doch könnte es irgendwann schnell zu Ende gehen. Darauf werden wir im nächsten Abschnitt genauer eingehen. :::

:::globalTitle{:size="sm" :tag="h3" .mb-5} Podman für die Produktion - etwas komplizierter ::: :::globalParagraph Ein entscheidenderer Nachteil des Verzichts auf einen Daemon-Prozess wird deutlich, wenn versucht wird, Podman für Produktions-Workloads zu verwenden. Mit Docker kannst du beispielsweise einfach eine 'Restart-Policy' für Container angeben und sicherstellen, dass sie im Falle eines Absturzes neu gestartet werden. Podman führt keinen Prozessmonitor aus und muss diese Aufgabe daher an eine andere Stelle delegieren: Hier kommt unser guter alter Freund systemd ins Spiel. Obwohl systemd sehr verbreitet ist und wahrscheinlich von den meisten Systemadministratoren gut verstanden wird, handelt es sich dennoch um eine sehr komplexe zusätzliche Lösung, die mit eigenen Kosten verbunden ist. Podman unterstützt den Benutzer, indem es die systemd-Einheiten generiert (die Konfiguration, um systemd mitzuteilen, wie ein Prozess überwacht und verwaltet werden soll), aber dies ist ein völlig anderes Ökosystem. Wenn du von Docker kommst, kann dies eine gewisse Einarbeitungszeit erfordern, um alles mit dem gewünschten Verhalten zum Laufen zu bringen. Ein weiterer Pluspunkt für systemd ist jedoch, dass eine Einheit genauso gut mit verringerten Benutzerrechten ausgeführt werden kann. ::: :::globalParagraph Ob Docker oder Podman - wenn die Produktionsbereitstellungen ernst genommen werden sollen, muss letztendlich irgendwo ein Daemon-Prozess involviert sein. Und natürlich gibt es einen Dienstprozess (Daemon), wenn du die Podman REST API verwenden möchtest.. :::

:::GlobalPodcastSection{:videoId="tyvE9VlSWkE" :videoPosition="left" .mb-6} ::::GlobalTitle{:tag="h3" .mb-6} Tools for the craft - Ausgabe 1: Kubernetes-Entwicklungsumgebungen :::: ::::globalParagraph{:font-size="lg" .mb-4} Hier findest du die erste Ausgabe unseres Kubernetes-Podcasts "Tools für das Handwerk: Die Navigation im Kubernetes-Ökosystem". Michael und Robert sprechen ausführlich über die Feinheiten der lokalen Kubernetes-Entwicklung und geben auch einige echte Codierungsbeispiele. :::: ::::globalParagraph{:font-size="lg" } Weitere Ausgaben unseres Podcasts findest du hier: :::: ::::GlobalButton{:url="/kubernetes-podcast/" :label="Weitere Podcast-Ausgaben anzeigen" :color="green"} :::: :::

:::globalTitle{:size="lg" .mb-5} Rootful und rootless ::: :::globalParagraph Eine sehr nützliche (und manchmal unterschätzte) Funktion von Docker sind Overlay-Netzwerke. Diese ähneln 'echten' (virtuellen) Netzwerken auf einer Host-Maschine. Docker-Netzwerke ermöglichen alle Arten von komplexen Verbindungstopologien mit Routen, NATs und IP-Pools usw. Das ist besonders nützlich in Situationen, in denen eine bestimmte Produktionsumgebung erreicht und verschiedene Dienste, die eine Anwendung ausmachen, lose gekoppelt werden sollen. Tatsächlich läuft jeder Container in seinem eigenen Namespace im Linux-Kernel, sodass es möglich ist, Ressourcenbeschränkungen für jeden Container, Netzwerkeinstellungen usw. festzulegen. Einer der grundlegenden Gedanken bei der Aufteilung des Linux-Kernels in mehrere Räume war die Prozesssicherheit. Im Moment ist dies größtenteils nur mit Root-Rechten möglich. Dennoch ist Sandboxing mit Namespaces auch mit nicht privilegierten Benutzern möglich. :::

:::globalTitle{:size="sm" :tag="h3" .mb-5} Wie es in der Realität aussieht ::: :::globalParagraph Wichtige Funktionen verschwinden, wenn Docker im Rootless-Modus ausgeführt wird, und das gilt auch für Podman. Ich habe herausgefunden, dass es eine Option gibt, Podman rootful auszuführen, um diese Fähigkeiten, insbesondere ein ordentliches Netzwerk, zu erhalten. ::: :::globalParagraph In der Praxis hat das Podman-Entwicklungsteam eine meiner bescheidenen Meinung nach fragwürdige Lösung für das fehlende Networking geschaffen, indem es das Konzept des „Pods" als Alternative eingeführt hat. ::: :::globalParagraph Mit Podman kannst du mehrere Container in einem Pod kompilieren. „Pod" ist der Name für eine höherstufige Organisation von Kernel-Namespaces. Alle Container, die denselben Pod teilen, befinden sich tatsächlich im selben Kernel-Namespace(s). Am wichtigsten ist, dass sie denselben Netzwerk-Namespace teilen. Dadurch können die Container-Prozesse über TCP-Sockets miteinander kommunizieren. Du kannst beispielsweise einen Prozess auf Port localhost:8000 und einen anderen Prozess auf localhost:8001 ausführen. Beide Prozesse können über den TCP-Socket auf localhost miteinander kommunizieren. Dies wäre nicht möglich für zwei separate „podman run ..." (oder mit „docker run ..."), da sie standardmäßig voneinander getrennt sind. Die Verwendung des Pod-Konzepts beseitigt letztendlich die Notwendigkeit für Networking vollständig und somit auch die Notwendigkeit für eine rootful-Betrieb. :::

:::globalTitle{:size="md" :tag="h3" .mb-5} Der Podman "Infra Container" ::: :::globalParagraph Übrigens: Jedes Podman-Pod erhält einen speziellen Container namens "Infra-Container". Er tut nichts weiter, als einzuschlafen, sobald das Pod erstellt ist. Alle Attribute, die das Pod definieren, werden tatsächlich diesem speziellen Container zugewiesen, einschließlich Port-Bindungen, Kernel-Namespaces, Ressourcenbeschränkungen usw. Sobald das Pod erstellt ist, können diese Attribute nie wieder geändert werden. Angenommen, du erstellst ein neues Pod und fügst später einen Container hinzu, der einen neuen Port mit dem Host bindet - Podman wird dazu nicht in der Lage sein. Du musst das gesamte Pod mit der neuen Port-Bindung (oder anderen Attributen) neu erstellen. :::

:::globalTitle{:size="md" :tag="h3" .mb-5} Privilegien vs. Fähigkeiten ::: :::globalParagraph Jeden Prozess mit herabgesetzten Rechten auszuführen, bringt erhebliche Einschränkungen mit sich. Das macht Sinn, besonders um zu verhindern, dass ausgenutzte Containerprozesse Systemänderungen vornehmen oder auf andere Prozesse zugreifen können. Das Herabsetzen der Ausführungsrechte ist generell vorzuziehen, und ich nehme dieses Thema sehr ernst. Allerdings führt der Tausch des Sandbox-Mechanismus zugunsten fehlender Netzwerkfähigkeiten eine weitere Klasse von Systemanfälligkeiten ein. :::

:::globalTitle{:size="lg" .mb-5} Podman-Pods und Kubernetes ::: :::globalParagraph Das Podman-Team behauptet, dass die Arbeit mit Podman-Pods den Übergang zu Kubernetes viel einfacher macht. Tatsächlich kannst du mit Podman ein Pod erstellen (alle Container, die du benötigst, hinzufügen; bestimmte Attribute festlegen) und automatisch eine gültige Kubernetes YAML-Datei daraus generieren. Und ja, die technische Grundlage ist die gleiche. Aber trotzdem, wer hat nach diesem Feature gefragt? :::

:::globalTitle{:size="sm" :tag="h3" .mb-5} Der monolithische Pod ::: :::globalParagraph Ich habe dieses Tutorial gefunden, das vorschlägt, einen Webserver, einen Anwendungsserver und die Datenbank in einen Podman-Pod zu packen. Das wäre praktisch, wenn ich dies mit Podman auf einem Serverhost betreiben wollte. Aber hier ist der Punkt. Wer mit Erfahrung in Kubernetes würde jemals eine solche Pod-Definition in einer Kubernetes-Umgebung anwenden? Ich erhalte einen monolithischen Pod, der alles enthält, was eine Anwendung ausmacht. Was ist mit Skalierbarkeit, Ausfallsicherheit und natürlich Sicherheit? Eine ernsthafte Kubernetes-Bereitstellung verwendet abstrakte Arbeitslastdefinitionen, die in "Deployments", "StatefulSets" und anderen höheren Kubernetes-Objekten deklariert sind. Ich habe dieses Muster noch nie in der realen Welt gesehen (was nicht bedeutet, dass es nicht existiert). Die Verwendung von nackten Pods scheint für Kubernetes überhaupt kein praktischer Ansatz zu sein. Wenn es jedoch verwendet wird, um echte Kubernetes-Strukturbereitstellungsmuster wie Sidecars oder Adapter zu konstruieren, wäre ich sehr glücklich. :::

:::globalTitle{:size="sm" :tag="h3" .mb-5} Ungerechtfertigte Versprechungen ::: :::globalParagraph Daher finde ich dieses Feature irreführend, insbesondere in Bezug auf die Kommunikation und Dokumentation von Podman. Nein, ich kann keinen Podman-Pod auf einem lokalen Rechner definieren und ihn so einfach in die Produktionsumgebung von Kubernetes migrieren. In Kubernetes verwenden wir starke Netzwerkmechanismen wie Lastenausgleicher, IP-Routing, Netzwerkrichtlinien und damit lose Kopplung. :::

:::globalTitle{:size="md" .mb-5} Fazit ::: :::globalParagraph Ich hoffe, dieser Artikel hat dir ein besseres Verständnis für die Unterschiede zwischen Podman und Docker gegeben. Wie du sehen kannst, gibt es viele Ähnlichkeiten zwischen den beiden Tools, aber sie haben auch einige wesentliche Unterschiede, die je nach Anwendungsfall die eine Option geeigneter machen könnten als die andere. Obwohl Podman sich noch in einem frühen Entwicklungsstadium befindet, hat es bereits Anzeichen dafür gezeigt, eine würdige Alternative zu Docker zu sein, indem es eine einfachere Benutzererfahrung bietet und gleichzeitig die Kompatibilität mit vorhandenen Images aus anderen Registern wie Docker Hub oder Google Container Registry (GCR) beibehält. Ich bin gespannt, wie sich diese Tools im Laufe der Zeit weiterentwickeln, während sie beide neue Funktionen hinzufügen. Schau dir auch Podman Desktop an. Ich bin mir nicht sicher, ob Podman auch den Weg der Entwicklererfahrung („DX“) wie Docker geht oder ob sie versuchen, Produktionsserver zu betreiben. Lass mich wissen, was du denkst. ::: :::globalParagraph Fühle dich frei, folge mir auf LinkedIn oder trete unserem Discord bei. :::

{.object-cover .max-w-full .mb-5}

Online-Shopping ist aus unserem Alltag nicht mehr wegzudenken. Vom kleinen Händler hin zu den Dickschiffen wie Zalando, Amazon, Otto - im B2C-Sektor hat sich längst rumgesprochen, dass man ohne einen Online-Shop mindestens Geld auf der Straße liegen lässt, wenn nicht sogar sein Schicksal besiegelt.

Im B2B fangen wir gerade erst so richtig an dieses Verständnis zu wecken. Es wirkt aktuell vieles wie der B2C E-Commerce vor 10 Jahren. Viele Marktteilnehmer setzen erstmal irgendetwas auf. Oftmals halbherzig. Immer das Budget im Blick, entscheidet man sich dann für Standardlösungen aus dem B2C-Umfeld um „erstmal zu schauen wie das läuft". Das ihr Sektor dabei völlig andere Voraussetzungen hat, dass vergessen die B2B-Unternehmen ganz schnell und wundern sich dann, dass der Webshop nicht so läuft wie gedacht.

Aber was sind denn nun diese unterschiedlichen Voraussetzungen?

GRUNDSÄTZLICHE UNTERSCHIEDE IM B2B / B2C E-COMMERCE

Zunächst einmal haben selbst große B2B-Händler meist einen viel kleineren Kundenstamm als ein breit aufgestellter B2C-Händler. Logisch, ein Fachhändler für Dachdeckerbedarf hat natürlich eine kleinere Zielgruppe als ein Online-Schuhhändler. Die Umsätze die der Händler für Dachdeckerbedarf aber an einem Kunden erwirtschaften kann, sind natürlich weitaus höher als bei unserem Schuhshop-Beispiel. Ein Dachdecker der mal eben 2000 Dachziegel bestellt, hat natürlich einen üppigeren Warenkorbwert.

Heißt also, der ARPU (Average Revenue per User) ist bei B2B > B2C. Und im Umkehrschluss lassen sich damit folgende simple Thesen aufstellen:

• Der Wert einer einzelnen Kundenakquise (CLV) im B2B ist deutlich höher als im B2C
• Der Verlust (Churn) eines Kunden wiegt im B2B deutlich schwerer als im B2C

Aber in die Marketing Economics dieses Themas steigen wir an dieser Stelle nicht tiefer ein und heben uns das für ein anderes Mal auf. Schauen wir uns lieber an welche Unterschiede tatsächlich in den Online-Shops eine Rolle spielen.

SPEZIELLE KONDITIONEN FÜR BESTELLER

Im B2B ist es gang und gäbe das Händler mit deinen Kunden viele Bedingungen der Geschäftsbeziehungen einzeln aushandeln. Je größer der potentielle Kunde, desto größer sein Verhandlungshebel. Im Einzelnen heißt das, dass Kunden individuelle Preislisten haben, einzeln verhandelte Zahlungsziele und Modalitäten, unterschiedliche Regelungen für Skonto oder Rabatte, spezielle Lieferbedingungen oder gar Verpackungsbedingungen. Im B2C gibt es diese Unterschiede auf Kundenebene nicht. Im B2B bedeutet das, dass im Prinzip jeder Kunde seinen eigenen Shop haben müsste, in dem seine eigenen verhandelten Konditionen abgebildet würden.

Eine Thematik die in einem B2B-Online-Shop über den Login des Kunden abgebildet würde. In einer Kundenstammdatenbank sind alle spezifischen Konditionen des Kunden hinterlegt und der Webshop ist smart genug um nun alle dieser Logiken für den einzelnen Kunden abbilden zu können.

KUNDEN BESTELLEN FÜR KUNDEN

Beispiel: Ein Hersteller beliefert ein Netzwerk an Händlern die seine und die Produkte anderer Hersteller vertreiben. Die Produkte des Herstellers sind individualisierbar und werden vom Endkunden beim Händler nach einer ausgiebigen Beratung bestellt. Der Händler bestellt nun also beim Hersteller ein spezifisch konfiguriertes Produkt für einen spezifischen Kunden. Der Händler möchte also schon im Bestellprozess angeben für welchen Kunden das entsprechende Produkt ist, damit später die Zuordnung leichter fällt sowie eventuelle Retourenprozesse.

Der Händler macht dies ggf. äußerst regelmäßig und möchte im Onlineshop einen Überblick über seine unterschiedlichen Bestellungen für seine Kunden haben. Im Prinzip hat der Händler im Onlineshop seine eigene Kundenkartei und Bestellverwaltung und er hat den Anspruch die Produkte die dann bei Ihm im Laden eintreffen problemlos zuordnen zu können, weil der Hersteller vom Händler gewünschte Merkmale bei der Lieferung mit aufgreift und abbildet. Dies könnten z.B. die Daten des Endkunden sein oder eine händlerspezifische Bestellnummer.

Je einfacher ein E-Commerce-System solche Prozesse für einen B2B-Kunden abbilden kann, desto besser. In einem Standard-Shopsystem gehören solche Funktionalitäten eher nicht zum regulären Funktionsumfang.

KOMPLEXE SCHNITTSTELLEN UND ANBINDUNG AN BESTANDSPROZESSE

Gerade im B2B-Sektor sind die Bestandsunternehmen oft schon seit Jahrzehnten am Markt. Dabei sind die Geschäftsprozesse sowie die verwendeten Software-Systeme nicht so schnell mitgewachsen wie man das hoffen würde. Gibt es ein funktionierendes System, gibt es oft wenig Grund dieses zu wechseln, denn Systemwechsel sind bekanntlich immer sehr teuer.

Nun, dies bedeutet, dass B2B E-Commerce-Systeme oft auf Systemlandschaften aufsetzen müssen, die bspw. noch aus den 2000er Jahren stammen. Der B2B-Händler passt seine ERP-Software, seine Produktinformationsverwaltung, sein CRM, seine Produktionsschnittstellen eher nicht an ein E-Commerce-System an, sondern erwartet, dass das E-Commerce-System mit seiner bestehenden Systemlandschaft reibungslos funktioniert. Hier steckt der Teufel im Detail und die Systemintegration ist absolute Expertenarbeit. Versuche das mal mit einem Woo Commerce umzusetzen ;) .

ANBINDUNG IN PRODUKTIONSPROZESSE

Wie schon im letzten Absatz angedeutet, sind Integrationen in Bestandslandschaften ein besonders heikles Thema. Dies wird nochmal expliziter, wenn der Online-Shop automatisiert in Produktionsabläufe eingreift. Im B2B-Sektor ist On-Demand Produktion keine Seltenheit. Hier dürfen bei der Produktkonfiguration und Datenübergabe in Produktionssoftware keine Fehler passieren. Ggf. müssen hier Logiktests abgebildet werden oder der Webshop muss mit Rückfragen aus der Produktion umgehen können.

Der Kunde soll möglicherweise auch darüber informiert in welchem Produktionsschritt sich seine Bestellung gerade befindet und wann er mit dem Produkt rechnen kann. Eine solche Integration sollte man entsprechend von Experten begleiten lassen.

KONFIGURATOREN

Hier gibt es zur Abwechslung mal eine klare Gemeinsamkeit von B2C- und B2B-Sektor. In beiden Sektoren erfreuen sich Produktkonfiguratoren großer Beliebtheit. Das macht natürlich auch Sinn. Je visueller und flexibler, desto besser. Das Problem: Konfiguratoren sind immer individuelle Entwicklungen. Ein Thema das klassische E-Commerce-Shopsysteme also grundsätzlich schon nicht out-of-the-box anbieten können.

SCHNELLBESTELLUNGEN

B2B-Kunden haben deutlich öfter gleiche bzw. sich wiederholende Warenkörbe als B2C-Kunden. Ein Fachhändler bestellt möglicherweise wöchentlich oder monatlich das gleiche oder ein nahezu gleiches Kontingent an Produkten für sein Lager. Diesem Fakt sollten B2C E-Commerce-Systeme Rechnung tragen indem sie solche wiederkehrenden Bestellungen dem Kunden so einfach wie möglich machen. Eine solche Monatsbestellung sollte im Kundenkonto also mit möglichst wenigen Klicks abbildbar sein. Es ist auch denkbar, automatische Bestellungen für den Kunden auszuführen, wenn bspw. dessen eigene Warenwirtschaft mit dem Online-Shop verknüpft ist.

Auch direkte Bestellungen über Artikelnummern, die eigene oder sogar die des Kunden, sowie Bestellungen über einen EAN-Scanner können zu den Features gehören, die Anspruchsvolle B2B-Kunden erwarten.

SERVICE

Zugegeben, Anspruch auf guten Service haben B2C- als auch B2B-Kunden. Der B2B-Kunde bedarf hier aber sicherlich einer etwas intensiveren Betreuung. Retourenmanagement, Rechnungen, Lieferscheine, Kommissionsnummern, Kundenstammverwaltung, etc. es gibt wahnsinnig viele unterschiedliche Themen, zu denen ein B2B-Kunde Hilfe benötigen könnte. Wünschenswert ist dafür, dass dem Kunden möglichst viele unterschiedliche Kontaktkanäle zur Verfügung gestellt werden. Nur E-Mail ist dabei eigentlich etwas zu wenig. Telefon, E-Mail, Live-Chat gehören zum Standard-Repertoire. Das Backend des B2B E-Commerce-Systems sollte dabei so aufgestellt sein, dass Service-Mitarbeiter schnell und unkompliziert unterschiedliche Anfragen von Kunden beantworten und bearbeiten können. Die Komplexität des B2B-Kunden sollte sich daher auch in diesem Service-Backend widerspiegeln.

KUNDENBINDUNG

Wie schon eingangs des Artikels erwähnt, hat ein einzelner B2B-Kunde einen erheblichen Wert für den Hersteller bzw. Händler. Dementsprechend ist es wichtig, Kunden möglichst lange und nachhaltig an das Unternehmen zu binden. Kundenbindungsprogramme sind im B2C bereits weit verbreitet. Punkte sammeln, Gutscheine bekommen, Freunde einladen, etc. das ist alles kein Neuland mehr. Im B2B hingegen werden auch diese Themen recht stiefmütterlich behandelt. Klar, dass der Händler für Dachdeckerbedarf plötzlich im Payback-Programm auftaucht ist natürlich unwahrscheinlich und wohl auch nicht zielführend. Dennoch können B2B-Händler mit individuellen Kundenbindungs- bzw. Incentiveprogrammen auch bei ihren Kunden punkten und langfristige Geschäftsbeziehungen fördern. Aber auch hier gilt, man sollte sich im Einzelfall anschauen, was Sinn ergibt, was man erreichen möchte und was für den Kunden attraktiv ist.

Zu unsere vergangenen Projekte hier entlang!

{.object-cover .max-w-full .mb-5}

::GlobalTitle{:size="lg" .mb-5} Einführung ::

::GlobalParagraph In der heutigen datengetriebenen Welt ist die Fähigkeit, Informationen schnell und effizient zu finden, von entscheidender Bedeutung. Elasticsearch bietet eine leistungsstarke Lösung, die es Unternehmen ermöglicht, ihre Daten zu indexieren und in Echtzeit abzufragen. Doch was genau ist Elasticsearch, und warum solltest du es in deinem Unternehmen oder Projekt einsetzen? ::

:GlobalButton{:url="/technologien/elasticsearch/" :label="Erfahre mehr über unsere Elasticsearch-Entwicklungsdienste" :color="blue" .mb-6}

::GlobalTitle{:size="lg" .mb-5} Was ist Elasticsearch? ::

::GlobalParagraph Elasticsearch ist eine verteilte, RESTful Such- und Analyse-Engine, die für ihre Geschwindigkeit und Skalierbarkeit bekannt ist. Sie ermöglicht es, Daten in nahezu Echtzeit zu speichern, zu suchen und zu analysieren. Mit Funktionen wie Volltextsuche, facettierter Suche und Aggregationen ist Elasticsearch eine ideale Lösung für Anwendungen, die große Datenmengen verarbeiten müssen. ::

::GlobalTitle{:size="lg" .mt-4 .mb-5} Vorteile von Elasticsearch ::

::GlobalParagraph Elasticsearch bietet zahlreiche Vorteile, sowohl für Entwickler als auch für Unternehmen: ::

::GlobalBlock{.ul-disk .mb-5}

• Echtzeit-Suche: Benutzer können Daten in Echtzeit durchsuchen, was die Benutzererfahrung erheblich verbessert.
• Skalierbarkeit: Elasticsearch kann horizontal skaliert werden, um mit wachsenden Datenmengen umzugehen.
• Flexibilität: Dank der Unterstützung für verschiedene Datentypen und Abfragesprachen kann Elasticsearch in einer Vielzahl von Anwendungen eingesetzt werden.
• Integration: Elasticsearch lässt sich leicht in bestehende Systeme integrieren und kann mit anderen Tools wie Kibana und Logstash kombiniert werden. ::

::GlobalTitle{:size="lg" .mt-4 .mb-5} Technische Grundlagen und Funktionsweise ::

::GlobalParagraph Im Kern basiert Elasticsearch auf Apache Lucene, einer leistungsstarken Such-Engine-Bibliothek. Während Lucene die grundlegende Suchfunktionalität bereitstellt, macht Elasticsearch diese durch eine REST-API und verteilte Architektur wesentlich zugänglicher. Die Anfragesprache von Elasticsearch ist JSON-basiert und ermöglicht sowohl einfache Volltextsuchen als auch komplexe analytische Abfragen. Mit der Query DSL (Domain Specific Language) können Entwickler präzise Suchanfragen formulieren, die von exakten Matches bis hin zu Fuzzy-Suchen reichen. ::

::GlobalParagraph Hier ein paar Query Beispiele:

:::BlogCode

// 1. Einfache Volltextsuche
// Sucht nach Dokumenten, die das Wort "elasticsearch" im Feld "description" enthalten
{
  "query": {
    "match": {
      "description": "elasticsearch"
    }
  }
}

// 2. Fuzzy-Suche mit mehreren Bedingungen
// Findet auch Dokumente mit Tippfehlern und kombiniert mehrere Suchkriterien
{
  "query": {
    "bool": {
      "must": [
        {
          "fuzzy": {
            "title": {
              "value": "elastcsearch",
              "fuzziness": "AUTO"
            }
          }
        },
        {
          "range": {
            "price": {
              "gte": 10,
              "lte": 100
            }
          }
        }
      ]
    }
  }
}
// 3. Komplexe Volltextsuche mit Highlighting
// Sucht nach Phrasen und hebt die gefundenen Stellen hervor
{
  "query": {
    "multi_match": {
      "query": "cloud computing",
      "fields": ["title^2", "description"],
      "type": "phrase"
    }
  },
  "highlight": {
    "fields": {
      "title": {},
      "description": {
        "number_of_fragments": 2,
        "fragment_size": 150
      }
    }
  }
}

::: ::

::GlobalParagraph Um diese Queries zu nutzen, können sie über die Elasticsearch REST API gesendet werden, zum Beispiel: curl -X GET "localhost:9200/my-index/_search" -H "Content-Type: application/json" -d' {query hier einfügen}' ::

::GlobalParagraph Ein weiteres cooles Feature von Elasticsearch is die Validate API. Mit dieser können Queries vor "richtiger" Ausführung überprüft werden. Genutzt werden kann sie mittels: curl -X GET "localhost:9200/my-index/_validate" -H "Content-Type: application/json" -d' {query hier einfügen}' ::

::GlobalParagraph Besonders hervorzuheben sind Features wie Autocomplete und Suggestions, die durch spezielle Analyzer und Token-Filter realisiert werden. Die NGram- und Edge-NGram-Token-Filter ermöglichen es, Texte in kleinere Einheiten zu zerlegen, was für Autovervollständigung und Teilwortsuche essentiell ist. Darüber hinaus bietet Elasticsearch fortgeschrittene Funktionen wie Geo-Spatial-Suche, Aggregationen für analytische Zwecke und ein ausgefeiltes Scoring-System zur Bewertung der Suchergebnisse. ::

::GlobalTitle{:size="lg" .mt-4 .mb-5} Deployment und Konfiguration ::

::GlobalParagraph Elasticsearch lässt sich in verschiedenen Szenarien deployen, von einzelnen Entwicklungsinstanzen bis hin zu großen Produktivclustern. In Kubernetes-Umgebungen erfolgt das Deployment typischerweise über den Elastic Cloud on Kubernetes (ECK) Operator oder durch managed Services wie Elastic Cloud. Die Konfiguration erfolgt über YAML-Dateien, wobei wichtige Aspekte wie Speicherallokation, Netzwerkeinstellungen und Sicherheitsfeatures definiert werden. ::

::GlobalParagraph Ein typisches Produktions-Setup umfasst mehrere Nodes mit unterschiedlichen Rollen (Master, Data, Ingest) und redundanter Datenhaltung durch Repliken. Für die Entwicklung eignet sich auch ein lokales Setup mit Docker Compose, das schnell aufgesetzt werden kann und die wichtigsten Features für Entwicklung und Tests bereitstellt. ::

::GlobalTitle{:size="lg" .mt-4 .mb-5} Integration und Ökosystem ::

::GlobalParagraph Das Elasticsearch-Ökosystem ist besonders umfangreich. Für Python-Entwickler steht der offizielle elasticsearch-py Client{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} zur Verfügung, der eine intuitive API für alle Elasticsearch-Operationen bietet. Content Management Systeme wie Wagtail integrieren Elasticsearch für leistungsfähige Suchfunktionen in Websites. Die Integration erfolgt dabei meist über den Python-Client und ermöglicht Features wie automatische Indizierung von Inhalten und facettierte Suche. ::

::GlobalParagraph Für das Monitoring und die Verwaltung stehen verschiedene Tools zur Verfügung. Kibana bietet umfangreiche Visualisierungs- und Management-Funktionen, während Grafana sich besonders für das Monitoring von Performance-Metriken eignet. Beats und Logstash ergänzen das Ökosystem um Datenaggregation und -transformation. ::

:::GlobalCallAnExpert{:bg="bg-bs-blue"} #buttonBlockTitle Wir können auch deine Daten mit Elasticsearch durchsuchbar machen. :::

::GlobalTitle{:size="lg" .mt-4 .mb-5} Vergleich mit Alternativen ::

::GlobalParagraph Im Vergleich zu Apache Solr, dem anderen großen Player im Bereich Suchengines, zeichnet sich Elasticsearch durch seine einfachere Handhabung und bessere Unterstützung für verteilte Systeme aus. Während Solr traditionell in Enterprise-Umgebungen stark ist, punktet Elasticsearch besonders bei modernen, Cloud-nativen Anwendungen. OpenSearch, ein Fork von Elasticsearch, bietet eine vollständig Open-Source-Alternative mit ähnlichen Funktionen. ::

::GlobalParagraph PostgreSQL mit seiner Volltext-Suchfunktionalität kann für kleinere Anwendungen ausreichend sein, bietet aber nicht die Skalierbarkeit und spezialisierten Suchfeatures von Elasticsearch. Meilisearch und Typesense sind neuere Alternativen, die sich auf Benutzerfreundlichkeit und schnelle Integration fokussieren, aber nicht die gleiche Funktionstiefe bieten. ::

::GlobalTitle{:size="lg" .mt-4 .mb-5} Lizenzen und Kosten ::

::GlobalParagraph Seit 2021 verwendet Elasticsearch eine duale Lizenzierung: Die grundlegende Version ist unter der Server Side Public License (SSPL) verfügbar, während zusätzliche Features unter der Elastic License stehen. Diese Lizenzänderung hat zur Entstehung von OpenSearch geführt, das unter der Apache 2.0 Lizenz steht. Die Kosten für Elasticsearch variieren je nach Nutzungsszenario: Die Self-Hosted-Version verursacht hauptsächlich Infrastrukturkosten, während die Elastic Cloud als managed Service nach Ressourcenverbrauch abgerechnet wird. Enterprise-Funktionen wie maschinelles Lernen oder erweiterte Sicherheitsfunktionen sind kostenpflichtig. ::

::GlobalTitle{:size="lg" .my-5} Praxisbeispiel - Mayan EDMS in Kubernetes ::

::GlobalParagraph Als Beispiel für die Verwendung von Elasticsearch möchte ich die Verschmelzung mit dem bekannten Mayan EDMS heranziehen. Hier haben wir das EDMS in einem Kubernetes Cluster eingerichtet. Mayan basiert per Standart auf einem lokalen Such-Index, welcher nicht verwendet werden kann wenn verschiedene Pods ins Spiel gebracht werden. Da jeder Pod seinen eigenen Such-Index bekommt funktioniert die Globale Suche im verteilten Kubernetes Mayan nicht mehr. Hier schafft Elasticsearch Abhilfe. Als globaler Index ermöglicht es die Suche nach Dokumenten, auch wenn diese von unterschiedlichen Pods indiziert werden. ::

::GlobalParagraph Die größte Herausforderung hierbei war die richtige Konfiguration des Elasticsearch Stacks. Da es nur noch veraltete Helm-Charts für Elasticsearch selbst gibt und das Deployment des kompletten ECK-Stacks{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} außer Frage stand, mussten wir den unkonventionelleren Weg gehen. Dieser sieht vor, dass man Elasticsearch als einzelne Node deployed. Der Elasticsearch-Operator wird dann automatisch mit deployed. Diese Methode ist die "unkonventionelle", da man sich selbst um richtiges Resourcen-Management sowie Volume Konfiguration kümmern muss. Nach dem Elasticsearch Setup kann man dann einfach die Mayan Instanz mittels der generierten Zugangsdaten zur Elasticsearch Node verbinden und die Dokumente werden indiziert. Wer sich für die Einrichtung von Elasticsearch als einzelne Node interessiert sollte unbedingt diese Anleitung{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} auschecken. ::

::div{.mb-8 .mt-8 .relative } :::GlobalSliderSection{:numberCards=2 data-title="Successful projects" :bg="bg-bs-gray"} ::::GlobalTitle{.mb-6 :size="lg" :tag="h3"} Beispielprojekte, bei denen wir Elasticsearch eingesetzt haben. ::::

::::GlobalParagraph
Schnellere Suchen, Autocomplete (die Vervollständigung von Suchwörtern) und clevere Vorschläge: in diesen Projekten haben wir Elasticsearch eingesetzt.
::::

#card1 :GlobalPartial{content=slides/luma-3-blog}

#card2 :GlobalPartial{content=slides/wuc-1-blog} ::: ::

::GlobalTitle{:size="lg" .mb-5} Fazit ::

::GlobalParagraph Elasticsearch ist ein unverzichtbares Werkzeug für Unternehmen, die mit großen Datenmengen arbeiten. Es bietet nicht nur eine leistungsstarke Such- und Analyse-Engine, sondern auch eine Vielzahl von Funktionen, die die Datenverarbeitung erheblich erleichtern. Wenn du nach einer effektiven Lösung für die Suche und Analyse deiner Daten suchst, ist Elasticsearch die richtige Wahl. ::

::GlobalParagraph Wenn du mehr über die Implementierung von Elasticsearch in deinem Projekt erfahren möchtest, kontaktiere uns! Wir helfen dir dabei, Elasticsearch in dein System zu integrieren und maßgeschneiderte Lösungen zu entwickeln, um deine Daten optimal zu nutzen. ::

::GlobalTitle{:size="lg" .mb-5 .mt-8} Häufige Fragen ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 1. Wie skaliert man Elasticsearch? ::

::GlobalParagraph Elasticsearch ist horizontal skalierbar. Du kannst: ::

::GlobalBlock{.ul-disk}

• Knoten hinzufügen: Neue Server in den Cluster integrieren.
• Sharding verwenden: Indizes in kleinere Shards aufteilen, um die Last zu verteilen.
• Replikate konfigurieren: Replikationen erhöhen, um Leseanfragen besser zu bewältigen und die Ausfallsicherheit zu verbessern. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 2. Was ist ein Index in Elasticsearch? ::

::GlobalParagraph Ein Index ist eine Sammlung von Dokumenten mit ähnlichen Eigenschaften. Er ist vergleichbar mit einer Datenbank in einer relationalen Datenbank. Jeder Index hat einen Namen und kann in mehrere Shards (Datenblöcke) aufgeteilt werden, um die Skalierbarkeit zu erhöhen. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 3. Was sind Shards und Replikate? ::

::GlobalBlock{.ul-disk .mb-5}

• Shards: Elasticsearch teilt große Indizes in kleinere Teile, sogenannte Shards, um die Verarbeitung auf mehrere Server zu verteilen.
• Replikate: Kopien von Shards, die zur Verbesserung der Verfügbarkeit und Ausfallsicherheit dienen. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .my-5} 4. Welche Arten von Abfragen gibt es in Elasticsearch? ::

::GlobalParagraph Elasticsearch unterstützt mehrere Abfragetypen, darunter: ::

::GlobalBlock{.ul-disk .mb-4}

• Match Query: Für Volltextsuche.
• Term Query: Für genaue Übereinstimmungen.
• Range Query: Zum Suchen nach Werten innerhalb eines Bereichs.
• Bool Query: Kombiniert mehrere Abfragen mithilfe von must, should und must_not. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 5. Was ist der Unterschied zwischen Elasticsearch, Logstash und Kibana (ELK-Stack)? ::

::GlobalBlock{.ul-disk .mb-4}

• Elasticsearch: Die zentrale Such- und Analyse-Engine, die Daten speichert und verarbeitet.
• Logstash: Ein Tool zur Datenverarbeitung, das Daten aus verschiedenen Quellen sammelt, transformiert und an Elasticsearch sendet.
• Kibana: Eine Visualisierungsplattform, die Daten aus Elasticsearch in Dashboards und Diagrammen darstellt. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 6. Warum sollten man Elasticsearch wählen? ::

::GlobalParagraph Elasticsearch hat sich als eine der führenden Suchlösungen etabliert und bietet eine Vielzahl von Funktionen, die es Entwicklern ermöglichen, leistungsstarke Suchanwendungen zu erstellen. Mit der Möglichkeit, große Datenmengen schnell zu verarbeiten und zu analysieren, ist Elasticsearch eine hervorragende Wahl für Unternehmen, die ihre Daten effektiv nutzen möchten. ::

{.object-cover .max-w-full .mb-5}

:::globalTitle{:size="lg" .mb-5} Phase 1: Normalisierung ::: :::GlobalBlock{.ul-disk .mb-5}

• Teams für die Anwendungsentwicklung verwenden Versionsverwaltung.
• Teams für die Anwendungsentwicklung verwenden die üblichen Entwicklungsverfahren. ::: :::globalParagraph Dies geschieht zum Beispiel, wenn Git oder SVN verwendet werden. Es gibt dabei die Hauptversionen sowie zusätzliche Features, die es einfacher machen, die Kontrolle über den Anwendungscode zu behalten. Zudem gibt es Versionierungen für Release-Prozesse. ::: :::globalParagraph Falls dein Unternehmen noch nicht in dieser Phase angekommen ist, habt ihr in den letzten 20 Jahren wohl in einer Höhle gelebt. Setze die Versionsverwaltung umgehend durch. Jetzt sofort. :::

:::globalTitle{:size="lg" .mb-5} Phase 2: Standardisierung ::: :::GlobalBlock{.ul-disk .mb-5}

• Teams entwickeln mit einer Reihe Standardtechnologien.
• Teams deployen an eine Standard-Betriebsplattform. ::: :::globalParagraph Standardisierung kann die Effizienz deines Unternehmens drastisch erhöhen. Das bezieht sich zwar nicht nur auf dein Tech-Team, aber speziell für die heißt das, dass sie mit Container-Technologie wie Docker{.bs-link-blue}, Docker-Compose oder Kubernetes{.bs-link-blue} arbeiten werden. ::: :::globalParagraph Diese Phase ist das Fundament für das Unterfangen, ein Unternehmen cloud-native zu machen. :::

{.object-cover .w-full .mb-5}

:::globalTitle{:size="lg" .mb-5} Phase 3: Expansion ::: :::GlobalBlock{.ul-disk .mb-5}

• Anwendungen bestehen aus mehreren kleineren, beweglichen Elementen und lose gekoppelten Services.
• Anwendungen sind auf den Umfang, die Widerstandfähigkeit und die Geschwindigkeit von Veränderungen ausgerichtet. ::: :::globalParagraph Dein Unternehmen verwendet serviceorientierte Architektur, Message-Brokering, Event-Streams und lose gekoppelte Interfaces (REST-, GraphQL- etc.). Ganz nach dem Motto „Divide et impera“, also „Teile und herrsche“, können dadurch spezialisierte Teams kreiert und schnellere Entwicklung sowie eine bessere Handhabung komplexer Anwendungen umgesetzt werden. ::: :::globalParagraph Um in dieser Phase anzukommen, ist es wichtig, für deine Anwendung bereits von Anfang an eine Struktur aus individuell entwickelten Services einzuplanen. Es ist nämlich wirklich anstrengend, eine monolithische Anwendung zu einem späteren Zeitpunkt aufzuteilen. :::

:::globalTitle{:size="lg" .mb-5} Phase 4: Automatisierte Bereitstellung der Anwendung ::: :::GlobalBlock{.ul-disk .mb-5}

• Teams verwenden existierende Deployment-Muster erneut.
• Versionsverwaltung für Deployment-Muster und Konfigurationen.
• Automatische Provisionierung der Entwicklungsumgebung.
• Teams verwenden einen Standardsatz an Build- und Testsystemen.
• Service-Discovery wird in Anwendungen verwendet.
• Security-Teams sind am Design und Deployment beteiligt.
• Automatisiertes Security-Profiling von Code und Config-Manifesten. ::: :::globalParagraph Zu den Technologien und Ansätzen, die möglicherweise während der 4. Phase eingesetzt wurden, gehören Helm, Quay, GitHub Actions, Continuous Integration, ArgoCD, Service Mesh, Network Policies und Pod Disruption Budget. ::: :::globalParagraph Anwendungen (oder besser gesagt: kleine, robuste Services) haben eine hohe Release-Häufigkeit. Umfassende automatisierte Deployment-Muster (z. B. bei der Verwendung von Helm in allen Bereichen) mit GitOps sind vorhanden. Ein „Anstoß“ des Source-Management-Systems löst nachvollziehbare Änderungen an der Infrastruktur und den Anwendungen aus. Alle Teammitglieder (mit besonderem Schwerpunkt auf die Entwickler) kennen die Schlüsselelemente der kontinuierlichen Integrationspipeline und lösen aufkommende Probleme ganz selbstständig. Zudem sind auch Mitglieder eines spezialisierten Security-Teams an der Entwicklung von Architekturen und Services beteiligt. Sobald Sicherheitslücken auftreten, werden Security-Updates umgehend erstellt. :::

:::globalTitle{:size="lg" .mb-5} Phase 5: Automatisiertes Application-Management ::: :::GlobalBlock{.ul-disk .mb-5}

• Entwicklerteams können auf alle Services für die Entwicklung zugreifen.
• Produktion kann für das Deployment nachgebildet werden.
• Anwendungen verwenden Muster von fortgeschrittenen Betriebsplattformen.
• Anwendungen verwalten sich selbst sowie die Betriebsplattform. ::: :::globalParagraph Beispiele: Operators, CRD (Custom Resource Definitions), Auto Scaling und Probes. :::

:::globalParagraph Dein Entwicklungsteam jagt einen komplexen Bug, der peinlicherweise alle deine Service beeinflusst? Kein Problem – in Phase 5 können deine Teams die Komplexität deiner Produktionsentwicklung nämlich im Handumdrehen provisionieren. Und obendrauf managen alle Service ihre eigenen Lifecycles, ohne dass manuell eingegriffen werden muss. ::: :::globalParagraph Ein neues Update benötigt eine Datenmigration? Auch kein Problem, denn deine Kubernetes-Operators ermitteln das verfügbare Update in deinem Registry und wenden die nötigen Scripts automatisch an, um die Daten deiner Anwendung konstant zu halten. Anwendungen informieren Kubernetes dabei selbst über ihren Zustand – sind sie bereit, neue Anfragen zu bearbeiten oder wird mehr Kapazität benötigt? Können wir es ein bisschen zurückschrauben, um etwas Geld zu sparen? In Phase 5 muss sich dein Team um solche Fragen glücklicherweise keine Sorgen mehr machen. ::: :::globalParagraph Bist du bereits bei Phase 5 angekommen? Wenn ja – Glückwunsch! Falls nicht, mach dir aber keine Sorgen. Soweit wir es beurteilen können, sind bisher sehr wenige Unternehmen wirklich in Phase 5 angekommen. Wir empfehlen, dass jedes Unternehmen möglichst schnell bei Phase 3 ankommen sollte und daraufhin sofort versuchen sollte, Phase 4 als mittelfristiges Ziel zu verfolgen. Falls das deine Strategie ist, dann bist du schonmal auf einem guten Weg zum zukünftigen Erfolg. ::: :::globalParagraph Wenn du mehr Einblicke in das Kubernetes-Ökosystem erhalten möchtest, folge einfach Michael Schilonka auf LinkedIn. :::

{.object-cover .max-w-full .mb-5}

:::GlobalTitle{:size="lg" .mb-5} Einführung ::: :::GlobalParagraph In der heutigen digitalen Welt ist die Implementierung von FastAPI-Anwendungen in der Produktion ein wichtiger Schritt für Unternehmen und Entwickler. FastAPI bietet eine schnelle, moderne und flexible Möglichkeit, APIs zu entwickeln und zu betreiben. Doch wie bringst du deine FastAPI-Anwendung erfolgreich in die Produktion? Erfahre, welche Best Practices und Tools dir dabei helfen, deine FastAPI-Anwendung performant und sicher zu betreiben. Wir starten zuerst mit ein paar grundlegenden Begrifflichkeiten und Konzepten bevor wir uns die Optimierung der Produktionsumgebung ansehen. :::

:::GlobalButton{:url="/loesungen/api-entwicklung/" :label="Erfahre mehr über unsere API-Entwicklungsdienste" :color="blue" .mb-6} :::

:::GlobalTitle{:size="lg" .mb-5} Was ist FastAPI überhaupt? ::: :::GlobalParagraph FastAPI ist ein modernes, schnelles (High-Performance), Web-Framework für Python, das auf Starlette und Pydantic basiert. Es wurde von Sebastián Ramírez a.k.a tiangolo{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} geschrieben und ist eine der am schnellsten wachsenden Python-Web-Frameworks. Es ist auch sehr effizient APIs in FastAPI zu schreiben, da es die Vorteile von Python Typ-Überprüfungen und asynchronen Programmiermodellen nutzt. Darüber hinaus generiert FastAPI automatisch interaktive API-Dokumentationen mit Swagger UI und ReDoc, was den Entwicklungsaufwand erheblich reduziert. :::

:::GlobalTitle{:size="lg" .mb-5} The 12 Factor App - Was eine gute Applikation ausmacht ::: :::GlobalParagraph Blueshoe ist starker Vertreter des 12 Factor App Ansatzes. Die 12 Factor App ist eine Methode um Software-As-A-Service Apps zu bauen, welche (laut Zitat) folgende Anforderungen erfüllen sollen: ::: :::GlobalBlock{.ul-disk .mb-4}

• deklarative Formate benutzen für die Automatisierung der Konfiguration, um Zeit und Kosten für neue Entwickler im Projekt zu minimieren
• einen sauberen Vertrag mit dem zugrundeliegenden Betriebssystem haben, maximale Portierbarkeit zwischen Ausführungsumgebungen bieten
• sich für das Deployment auf modernen Cloud-Plattformen eignen, die Notwendigkeit von Servern und Serveradministration vermeiden
• die Abweichung minimieren zwischen Entwicklung und Produktion, um Continuous Deployment für maximale Agilität ermöglichen
• und skalieren können ohne wesentliche Änderungen im Tooling, in der Architektur oder in den Entwicklungsverfahren :::

:::GlobalParagraph So beinhaltet der Ansatz Konzepte wie die gute Umsetzung der Konfiguration einer Applikation oder parität der Dev und Produktions Umgebung. Nachzulesen sind alle Faktoren auf der 12 Factor App Website{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid}. Mit FastAPI lässt sich dieser Ansatz gut umsetzen. Dank der leichtgewichtigkeit des Frameworks kann zum Beispiel Faktor IX. recht simpel erfüllt werden und eine schnelle Startzeit der Applikation garantiert werden. :::

:::GlobalParagraph Nachdem nun alle Konzepte und Grundlegenden Begriffe für die SaaS-App geklärt sind folgt nun das perfekte FastAPI Produktions Setup. :::

:::GlobalTitle{:size="lg" .mb-5} Server Runner - Wer lässt deine App laufen? :::

:::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Gunicorn + Uvicorn - Der alte Weg :::

{.object-contain .w-128}

:::GlobalParagraph Vor einigen Monaten war die Kombination von Gunicorn mit Uvicorn-Workern die bevorzugte Wahl, um eine FastAPI-API zu serven. Gunicorn wurde verwendet, weil es die Fähigkeit hat, eine große Anzahl von Prozessen zu verwalten, während die Leistung konstant bleibt. Dies ermöglichte es, die Last auf mehrere Prozesse zu verteilen und die Verfügbarkeit der API zu erhöhen. Uvicorn wurde als Worker-Prozess verwendet, um die Anfragen zu bearbeiten, da es eine effiziente Implementierung des ASGI-Standards bietet. Allerdings unterstützte Uvicorn bis vor kurzen das Management und Neustarten von Workern nicht direkt, was die Verwendung von Gunicorn als Prozessmanager erforderlich machte. Durch die Kombination von Gunicorn und Uvicorn konnten Entwickler die Vorteile beider Tools nutzen, um eine skalierbare und zuverlässige API-Infrastruktur aufzubauen. :::

:::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Die FastAPI CLI - der neue Weg :::

:::GlobalParagraph Inzwischen wird diese Kombination von Gunicorn und Uvicorn nicht mehr benötigt, da Uvicorn das Management von Workern nun auch selbst hin bekommt. Man kann nun also Uvicorn allein benutzen, oder man benutzt die neue FastAPI CLI. Diese basiert auf Uvicorn, erleichtert das Entwickler leben aber ungemein indem sie mit Management Kommandos für FastAPI daher kommt. Auch kann sie als entrypoint Kommando benutzt werden um Produktions APIs zu serven. :::

:::GlobalParagraph Um nun die maximale Performance, in einer Multiprozessor Umgebung, herauszuholen kann dem FastAPI CLI run Kommando eine Flag mitgegeben werden um die Anzahl an Service Workern festzulegen. Der resultierende Kommando sieht so aus: ::: :::BlogCode{.mb-5}

fastapi run --workers 4 <Pfad zur main Datei>

:::

:::GlobalParagraph Dies führt Uvicorn mit Optimierungen für Produktion aus und erzeugt 4 Worker welche nun Nebenläufig Anfragen abarbeiten. Wenn du deine Applikation aber in Kubernetes hosten möchtest ist es empfohlen die Replikation über den Cluster laufen zu lassen und nicht in jedem einzelnen Container. Das heißt, du braucht dann die workers Flag nicht, sondern solltest in deine Deployment Konfiguration schauen.

:::

:::GlobalTitle{:size="lg" .mb-5} Reverse Proxies :::

:::GloablParagraph Ein "Reverse Proxy" ist ein Server, der zwischen den Clients (z. B. Browsern oder anderen Anwendungen) und den Backend-Servern einer Anwendung sitzt und als Vermittler fungiert. Statt dass die Clients direkt mit dem Backend kommunizieren, leitet der Reverse Proxy die Anfragen weiter und gibt die Antworten des Backends zurück an die Clients. Dadurch verbirgt er die tatsächlichen Backend-Server vor den Clients und fungiert als zentraler Zugangspunkt zur Anwendung. :::

:::GlobalParagraph Reverse Proxies wie Nginx oder Traefik sind also ein unverzichtbares Werkzeug für das Deployment moderner API-Anwendungen, da sie zahlreiche Vorteile bieten, die sowohl die Performance als auch die Sicherheit und Skalierbarkeit verbessern. Durch die Übernahme von Aufgaben wie SSL/TLS-Terminierung sorgt ein Reverse Proxy dafür, dass die API sicher über HTTPS erreichbar ist, ohne die Backend-Anwendung selbst zu belasten. Gleichzeitig ermöglicht er Load Balancing, indem eingehende Anfragen effizient auf mehrere Backend-Instanzen verteilt werden, was die Stabilität und Verfügbarkeit der Anwendung erhöht. Darüber hinaus kann ein Reverse Proxy statische Inhalte wie Bilder oder CSS-Dateien direkt ausliefern, was die Performance weiter steigert, indem es die API-Server entlastet. Nicht zuletzt bietet ein Reverse Proxy zusätzliche Sicherheitsfunktionen wie Rate Limiting oder IP-Blocking, um APIs vor bösartigen Angriffen zu schützen. Diese Kombination aus Performance-Optimierung, Sicherheit und Flexibilität macht Nginx, Traefik und ähnliche Tools zu einem unverzichtbaren Bestandteil jeder professionellen API-Deployment-Strategie. :::

::GlobalCallAnExpert{:bg="bg-bs-blue"} #buttonBlockTitle Wir können auch Deine FastAPI-App betreiben. ::

:::GlobalTitle{:size="lg" .mb-5} Und zuletzt die Sicherheit :::

:::GlobalParagraph Sicherheit ist ein zentraler Aspekt beim Deployment von APIs, und es gibt bewährte Maßnahmen, die helfen, deine Anwendung vor Angriffen zu schützen. HTTPS sollte stets verwendet werden, um die Kommunikation zwischen Client und Server zu verschlüsseln. Ein SSL-Zertifikat kann einfach und kostenlos über Dienste wie Let’s Encrypt bereitgestellt werden. Weiterhin erhöhen Sicherheitsheader den Schutz vor häufigen Angriffen wie Cross-Site-Scripting (XSS). Dies lässt sich in FastAPI einfach mit der SecurityMiddleware von Starlette umsetzen. Zusätzlich schützt der Einsatz von TrustedHostMiddleware vor Host-Header-Angriffen, indem nur definierte Domains erlaubt werden:

:::BlogCode{.mb-5}

from starlette.middleware.trustedhost import TrustedHostMiddleware
from starlette.middleware import Middleware

app = FastAPI(
  middleware=[
    Middleware(
      TrustedHostMiddleware,
      allowed_hosts=["yourdomain.com", "*.yourdomain.com"]
    ),
  ]
)

:::

:::GlobalParagraph Wenn deine API mit externen Clients interagiert, ist eine korrekte Konfiguration von CORS (Cross-Origin Resource Sharing) entscheidend, um nur vertrauenswürdige Ursprünge zuzulassen: :::

:::BlogCode{.mb-5}

from fastapi.middleware.cors import CORSMiddleware

app.add_middleware(
    CORSMiddleware,
    allow_origins=["https://trusteddomain.com"],
    allow_methods=["GET", "POST"],
    allow_headers=["*"],
)

::: :::GlobalParagraph Für den Schutz von Datenbankzugängen sollten sensible Informationen wie Zugangsdaten niemals im Code hartcodiert werden. Stattdessen können Umgebungsvariablen oder Secrets-Management-Tools genutzt werden. Um SQL-Injection zu verhindern, sollten Sie ORM-Tools wie SQLAlchemy oder Tortoise ORM verwenden, die Abfragen sicher parameterisieren. Hier kommt wieder das 12 Factor App Konzept ins Spiel. ::: :::GlobalParagraph Zusätzlich können Sie durch Rate Limiting die Häufigkeit eingehender Anfragen begrenzen und damit sowohl Missbrauch als auch Überlastungen vorbeugen. Reverse Proxies wie Nginx oder Traefik eignen sich hervorragend, um dies effizient zu implementieren. Mit diesen Maßnahmen können Sie die Sicherheit Ihrer API signifikant erhöhen. :::

:::GlobalTitle{:size="lg" .mb-5} Beispiel Dockerfile :::

:::GlobalParagraph Hier noch ein Beispiel eines Dockerfiles für eine Produktionsumgebung in Kubernetes (der Cluster übernimmt die Replikation):

:::BlogCode{.mb-5}

FROM python:3.12-slim

# Set environment variables
ENV PYTHONDONTWRITEBYTECODE 1
ENV PYTHONUNBUFFERED 1

# Set the working directory
WORKDIR /app

# Install dependencies
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# Copy the application code
COPY src/ .

# Expose the port the app runs on
EXPOSE 8000

# Command to run the FastAPI application using the FastAPI CLI -> no workers flag as Kubernetes handles replication
CMD ["fastapi", "run", "main:app", "--host", "0.0.0.0", "--port", "8000"]

:::

:::GlobalTitle{:size="lg" .mb-5} Honorable Mentions :::

:::GlobalBlock{.ul-disk}

• Mit Caching kann auch viel für die Performance einer API getan werden. Bei Blueshoe benutzen wir vor allem Varnish{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid}.
• I/O und Ressourcen intensive Tasks sollten in FastAPIs BackgroundTasks{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} ausgeführt werden :::

:::GlobalTitle{:size="lg" .mb-5 .mt-8} Fazit :::

:::GlobalParagraph FastAPI ist nicht nur schnell und flexibel, sondern bietet durch seine Integration mit modernen Deployment- und Sicherheitsstandards eine ideale Grundlage für produktionsreife APIs. Mit den vorgestellten Best Practices und Tools lassen sich Anwendungen performant, sicher und skalierbar betreiben. Entwickler profitieren von der schnellen Startzeit, asynchronen Verarbeitung und integrierten Werkzeugen zur Optimierung. Der Einsatz von Reverse Proxies, Sicherheitsmaßnahmen und modernen Deployment-Strategien machen FastAPI zur idealen Wahl für zukunftsorientierte API-Entwicklung. :::

{.object-cover .max-w-full .mb-5}

:::GlobalTitle{:size="lg" .mb-5} Dokumentation via OpenAPI ::: :::GlobalParagraph Zuallererst die Grundlagen - FastAPI{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} ist eines der Frameworks, welche wir verwenden, um APIs zu schreiben. Es basiert auf Python und wirbt mit sehr guter Performance. FastAPI ist stark typisiert, was bedeutet, dass die Typen Eingabe- und Ausgabewerte im Programm weitestgehend bekannt sind (in dem Rahmen, in dem das in Python möglich ist). :::

:::GlobalButton{:url="/loesungen/api-entwicklung/" :label="Erfahre mehr über unsere API-Entwicklungsdienste" :color="blue" .mb-6} :::

:::GlobalParagraph

Durch die bekannten Typen lässt sich ein Schema der API generieren. Dieses Schema beinhaltet alle notwendigen Informationen zu den verfügbaren Endpunkten. Als Standardformat wird hierfür OpenAPI hergenommen. Beispiel für ein OpenAPI Endpunkt: :::

:::BlogCode{.mb-5}

openapi: 3.1.0
info:
  title: Redocly Museum API
  description: An imaginary, but delightful Museum API for interacting with museum services and information. Built with love by Redocly.
  version: 1.0.0
  contact:
    email: team@redocly.com
    url: 'https://redocly.com/docs/cli/'
  x-logo:
    url: 'https://redocly.github.io/redoc/museum-logo.png'
    altText: Museum logo
  license:
    name: MIT
    url: 'https://opensource.org/license/mit/'
servers:
  - url: 'https://api.fake-museum-example.com/v1'
paths:
  /museum-hours:
    get:
      summary: Get museum hours
      description: Get upcoming museum operating hours
      operationId: getMuseumHours
      x-badges:
        - name: 'Beta'
          position: before
          color: purple
      tags:
        - Operations
      parameters:
        - $ref: '#/components/parameters/StartDate'
        - $ref: '#/components/parameters/PaginationPage'
        - $ref: '#/components/parameters/PaginationLimit'
      responses:
        '200':
          description: Success
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/GetMuseumHoursResponse'
              examples:
                default:
                  summary: Museum opening hours
                  value:
                    - date: 2023-09-11
                      timeOpen: '09:00'
                      timeClose: '18:00'
                    - date: 2023-09-12
                      timeOpen: '09:00'
                      timeClose: '18:00'
                    - date: 2023-09-13
                      timeOpen: '09:00'
                      timeClose: '18:00'
                    - date: 2023-09-17
                      timeOpen: '09:00'
                      timeClose: '18:00'
                closed:
                  summary: The museum is closed
                  value: []

        '400':
          description: Bad request
        '404':
          description: Not found

:::

:::GlobalParagraph Die erzeugte Spezifikation enthält Beispiele, mögliche Antworten, sowie Beschreibung der Parameter des Endpunktes. ::: :::GlobalParagraph Programme wie Swagger oder Redoc greifen dieses Schema auf und erzeugen eine für Menschen lesbare Ansicht im Browser{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid}: :::

{.mx-auto .w-1/2}

:::GlobalParagraph Hier werden Informationen wie Authentifizierung, Pagination und Filter für den Endpunkt dargestellt. :::

:::GlobalTitle{:size="lg" .mb-5} Beispiele in API Dokumentation :::

:::GlobalParagraph Ein großer Mehrwert des OpenAPI Standards ist, dass aus den strukturierten Daten auch noch Beispiele erzeugt werden können. Dies sieht in Redoc dann beispielsweise folgendermaßen aus: :::

{.mx-auto .w-1/2}

:::GlobalParagraph Die Beispiele können explizit bei der Entwicklung angegeben werden oder sie werden mit einfachen Daten (wie 0 für Integer, "string" für Zeichenketten) automatisch erzeugt. Diese Beispieldaten für einen HTTP Post Request zu unserer FastAPI zeigen allerdings nur den Payloads. Zur Unterstützung der Entwickler, die unsere API benutzen, wollen wir konkrete Programmierbeispiele einbetten. Dies lässt sich mit Redoc via dem x-codeSamples{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} Tag einfach realisieren. Doch woher bekommen wir die Beispiele, ohne jede Programmiersprache selbst zu lernen? :::

:::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Erzeugung von Codebeispielen - Pakete ::: :::GlobalParagraph Auf Github sind wir auf 2 Pakete gestoßen, welche zur Generierung von API Code Beispielen geeignet scheinen: postman-code-generators{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} und httpsnippet{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid}. postman-code-generators stammt von Postman{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid}, einer Firma welche sich rund um Entwickler-Tooling für APIs beschäftigt. Es hat seine eigene Datenstruktur, um für HTTP Anfragen abzubilden. ::: :::GlobalParagraph httpsnippet stammt von Kong, einer Firma, welche vornehmlich ein API-Gateway entwickelt. Es arbeitet mit dem Standard von HTTP Archives. Beide Pakete sind gut gewartet und wir entscheiden uns an dieser Stelle aus pragmatischen Gründen für postman-code-generators. Die Daten, die wir in unserem OpenAPI Schema vorhanden haben, lassen sich recht leicht in die Strukturen von Postman überführen :::

:::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Umwandlung der OpenAPI in Postman Strukturen ::: :::GlobalParagraph Zuerst zur Struktur des Postman SDKs. Um mit postman-code-generators zu arbeiten, wird zusätzlich das SDK postman-collection benötigt. :::

:::BlogCode{.mb-5}

const codegen = require('postman-code-generators')
const sdk = require('postman-collection')

const baseUrl = 'https://unsere-api.de'
const openapiJSON = getOpenApiJSON()
const supportedCodegens = codegen.getLanguageList()

:::

:::GlobalParagraph postman-code-generators kommt mit einer Liste von Sprachen, über die wir einfach iterieren, um Codebeispiele zu erzeugen. :::

:::BlogCode{.mb-5}

for (const codegen of supportedCodegens) {
  language = codegen.key
  languageLabel = codegen.label
  for (const variation of codegen.variants) {
    variant = variation.key
    generateSamples()
  }
}

:::

:::GlobalParagraph Jede Sprache hat verschiedene Varianten, welche i.d.R. einfach verschiedene Möglichkeiten abbilden, HTTP Anfragen zu stellen - z.B. http und requests für Python. Unsere generateSamples Funktion erzeugt nun einfach für jeden Endpunkt (hier nur POST Endpunkte) ein Codebeispiel in der aktuellen Sprache: :::

:::BlogCode{.mb-5}

function generateSamples() {
  // generate samples for open api endpoint paths
  const paths = openapiJSON.paths
  for (const [path, operation] of Object.entries(paths)) {
    currentPath = path
    const data = generateExamplePayload(operation.post, openapiJSON)
    convertEndpoint(path, 'POST', data, addEntry)
  }
}

:::

:::GlobalParagraph Im Rahmen der Erzeugung des Payloads (generateExamplePayload) wird dann das Postman Request Objekt erzeugt: :::

:::BlogCode{.mb-5}

function buildRequest(url, method, data) {
  // build postman request
  return new sdk.Request({
    url: `${baseUrl}${url}`,
    method,
    body: buildBody(data),
    header: {
      ...header,
    }
  })
}

:::

:::GlobalParagraph Da wir in unserer openapi.json Datei mit Schemata arbeiten, nutzen wir ein weiteres Paket, welches uns hilft Beispiel-Payloads für diese Schemata zu erzeugen: :::

:::BlogCode{.mb-5}

const OpenAPISampler = require('openapi-sampler')
const schema = spec.components.schemas[name]
// Generate sample data
return OpenAPISampler.sample(
  schema,
  {},
  spec
)

:::

:::GlobalParagraph Zum Schluss stecken wir unsere Schleife und die Code Generierung zusammen: :::

:::BlogCode{.mb-5}

function convertEndpoint(path, method, data, cb) {
  const request = buildRequest(path, method, data)
  codegen.convert(language, variant, request, sampleFormattingOptions, cb)
}

:::

:::GlobalParagraph Als letzten Schritt fügen wir die erzeugten Beispiele in unsere openapi.json Datei ein: :::

:::BlogCode{.mb-5}

function addEntry(error, snippet) {
  if (error) {
    console.log(error, language, variant)
    return
  }
  const xCodeSample = {
    lang: languageLabel,
    label: `${languageLabel} (${variant})`,
    source: snippet
  }
  if (openapiJSON.paths[currentPath].post['x-codeSamples']) {
    openapiJSON.paths[currentPath].post['x-codeSamples'].push(xCodeSample)
  }
  else {
    openapiJSON.paths[currentPath].post['x-codeSamples'] = [xCodeSample]
  }
}

:::

:::GlobalParagraph Und schon beinhaltet unsere openapi.json Datei Codebeispiele aus allen möglichen Sprachen. :::

{.mx-auto .w-1/2}

:::GlobalTitle{:size="lg" .mb-5 .mt-8} Fazit :::

:::GlobalParagraph{.mb-8} Die Entwicklung einer API und das Schreiben einer Dokumentation dient nicht nur dem Selbstzweck. Es gilt, die Benutzer / Entwickler in Betracht zu ziehen, welche beispielsweise unsere REST API konsumieren. Die API Konsumenten dort abzuholen wo sie stehen, sodass die Verwendung der API weiter erleichtert wird, sollte insbesondere das Ziel für öffentliche Schnittstellen sein. :::

{.object-cover .max-w-full .mb-5}

Einführung

Die Wahl des richtigen API-Frameworks ist entscheidend für den Erfolg eines Projekts. Während FastAPI{target="_blank"} bereits seit einigen Jahren etabliert ist, gewinnt Robyn{target="_blank"} als neuerer Player zunehmend an Popularität. Beide Frameworks versprechen hohe Performance und moderne Entwicklungsansätze, aber sie unterscheiden sich in ihrer Implementierung und ihren Stärken. In diesem Artikel werden wir die wichtigsten Aspekte beider Frameworks vergleichen und dir helfen, die richtige Wahl für dein Projekt zu treffen.

Gemeinsamkeiten

FastAPI und Robyn teilen einige grundlegende Eigenschaften, die sie zu modernen und effizienten API-Frameworks machen:

• Beide sind moderne, asynchrone Web-Frameworks
• Sie bieten eine hohe Performance durch asynchrone Verarbeitung
• Beide unterstützen OpenAPI/Swagger-Dokumentation
• Sie nutzen moderne Python-Features wie Type Hints
• Beide sind leichtgewichtig und modular aufgebaut

Unterschiede

Runtime

FastAPI basiert auf Starlette und Uvicorn als ASGI-Server, während Robyn seine eigene Runtime in Rust implementiert hat. Dies führt zu interessanten Unterschieden: FastAPI profitiert von der reifen Python-Ökosystem-Integration und der breiten Community-Unterstützung, während Robyn durch seine Rust-Implementierung potenziell bessere Performance bei bestimmten Workloads bieten kann. Allerdings bedeutet die Rust-Implementierung auch, dass Robyn weniger flexibel bei der Integration von Python-Bibliotheken ist und möglicherweise mehr Wartungsaufwand erfordert.

Endpoint-Handhabung

Während beide Frameworks ähnliche Ziele verfolgen, unterscheiden sie sich in ihrer Implementierung von Endpoints:

FastAPI nutzt einen dekoratorbasierten Ansatz mit starkem Fokus auf Typisierung und Validierung, sowie request Destrukturierung und Injektion:

from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI()

class Item(BaseModel):
    id: str
    name: str
    price: float

@app.post("/items/")
async def create_item(item: Item):
    # create item in db
    # ...
    return item

@app.put("/items/{item_id}")
async def update_item(item_id: str, item: Item):
    """
    A client would call me like: PUT {base_url}/items/0485fd43-1345-4336-877c-4b47758102ea

    And `item_id` is automatically made available to this endpoint!
    """
    # update item in db
    # ...
    return item

@app.put("/items/{item_id}/move")
async def move_item(item_id: str, item: Item, directory: str | None = None):
    """
    A client would call me like: PUT {base_url}/items/0485fd43-1345-4336-877c-4b47758102ea/move?directory=new-n-shiny

    And `directory` is automatically made available to this endpoint!
    """
    # move item
    # ...
    return item

Robyn hingegen bietet einen etwas flexibleren, aber meiner Meinung nach umständlicheren, Ansatz der Injektion von Pfad- und Queryparametern:

# Why import types from three different modules?
from robyn import Robyn, Request
from robyn.types import PathParams
from robyn.robyn import QueryParams

app = Robyn(__file__)

@app.post("/items/")
async def create_item(request: Request):
    data = await request.json()
    return data

@app.put("/items/:item_id")
async def update_item(
    request: Request,
    path_parameters: PathParams,  # NOTE: variable name has to be `path_parameters` for injection to work
):
    item_id: str = str(path_parameters["item_id"])
    # update item in db
    # ...
    return item

@app.put("/items/:item_id")
async def move_item(
    request: Request,
    path_parameters: PathParams,
    query_parameters: QueryParams,  # NOTE: variable name has to be `query_parameters` for injection to work
):
    item_id: str = str(path_parameters["item_id"])
    directory: str = query_parameters.get("directory", None)
    # move item
    # ...
    return item

Übrigens sind alle Pfad- und Queryparameter auch im Request Model verfügbar. Man kann sich also die Injektion theoretisch sparen.

ORM-Unterstützung

Die Unterstützung von Datenbankoperationen ist ein wichtiger Aspekt bei der Framework-Auswahl:

FastAPI:

• Ermöglicht einfache Integration mit ORMs wie SQLAlchemy - dank Pydantic
• Unterstützt asynchrone ORMs wie Tortoise ORM
• Verfügt über eine aktive Community mit zahlreichen Beispielen und Best Practices für ORM-Nutzung
• Generiert automatisch OpenAPI-Dokumentation auf Basis der Datenbankmodelle
• Bietet mit SQLModel{target="_blank"} eine eigene ORM-Option auf Basis von SQLAlchemy und Pydantic

Robyn:

• Flexibler in der Wahl der Datenbank-Lösung (auch Rust ORMs!)
• Weniger vordefinierte Patterns für Datenbankoperationen

Serialisierung und Validierung

Die Art und Weise, wie Daten validiert und serialisiert werden, unterscheidet sich deutlich:

FastAPI:

• Nutzt Pydantic{target="_blank"} für Validierung und Serialisierung
• Strikte Typisierung und Validierung
• Automatische Generierung von OpenAPI-Schemas
• Umfangreiche Validierungsmöglichkeiten (durch Pydantic)

Robyn:

• Flexiblere Validierungsmöglichkeiten
• Weniger strikte Typisierung
• Manuelle Serialisierung/Deserialisierung (zum Beispiel über jsonify) Auch wenn dies nicht unbedingt notwendig ist. Die Dokumentation von Robyn ist hier nicht 100% eindeutig: (jsonify wird zwar importiert aber nicht verwendet; Im Test musste man jsonify auch gar nicht importieren, ein Dict als Response reicht völlig aus)

FFIs

Zumindest wenn man CPython verwendet steht es einem schon immer frei gewisse Teile seines Python Codes in C / C++ umzusetzen (falls nicht schon passiert; stdlib, etc.) und damit zu beschleunigen. Da Robyn über eine Rust Runtime verfügt, ermöglicht dieses Framework allerdings eine Kinderleichte Integration von Rust Code!

Für unseren kleinen Performance-Vergleich lasse ich Fibonacci Zahlen bis zur (maximal) 30er Größe generieren. Hierbei werden keine Tricks wie Memoization verwendet, um die rohe Python Performance zu zeigen:

def py_fib(n: int):
    if n < 2:
        return n
    return py_fib(n - 1) + py_fib(n - 2)

Diesen "Generator" habe ich auch (krude, und ohne Rekursion) in Rust implementiert:

// rustimport:pyo3

//:
//: [dependencies]
//: num-bigint = "0.4"
//: num-traits = "0.2"

use pyo3::prelude::*;
use num_bigint::BigUint;
use num_traits::{Zero, One};

#[pyfunction]
fn fibonacci(term: u64) -> PyResult<String> {
    if term == 0 {
        return Ok("0".to_string());
    }
    
    let (mut a, mut b): (BigUint, BigUint) = (Zero::zero(), One::one());
    for i in 1..=term {
        let temp = b.clone();
        b = a + b;
        a = temp;
    }
    
    Ok(b.to_string())
}

Kinderleicht war das ganze, da ich mich nur um die Implementierung kümmern musste. Dependencies können über Kommentare definiert werden und werden automatisch von der Robyn CLI aufgelöst.

Nachdem man also seinen Rust Code geschrieben hat reicht folgender Befehl:

robyn --compile-rust-path "my-robyn-rust-dir"

Und schon wird wie durch Magie (PyO3) der Rust Code compiliert und in eine Plattformabhängige Library gepackt!

Diese kann dann wie ein normales Python Module importiert werden (meine Rust Datei heißt native_fib.rs und liegt im gleichen Verzeichnis wie die Robyn main.py):

from native_fib import fibonacci as rs_fibonnacci

Performance-Vergleich

Wie schon erwähnt wird zum Vergleich der Performance die Generierung von Fibonacci Zahlen sowie folgendes Setup benutzt:

1. Ein Endpoint / welcher ein einfaches JSON zurück gibt:

   # fastapi implementation
   @app.get("/")
   async def root():
       return {"response": "success"}
   
   # robyn implementation
   @app.get("/")
   async def root(request: Request):
       return {"response": "success"}
   

2. Eine locust{target="_blank"} Konfigurationsdatei mit einem Task:
   1. Ruft / auf mit 10, 1000 und 10.000 Usern
3. Ein Endpoint /fibonacci/:size mit optionalen Queryparameter use_native
4. Eine locust{target="_blank"} Konfigurationsdatei mit drei Tasks:
   1. Ruft /fibonacci/10 auf; mit Gewichtung 3
   2. Ruft /fibonacci/20 auf; mit Gewichtung 2
   3. Ruft /fibonacci/30 auf; ohne Gewichtung
   4. Verteilt über 100 User mit 1 Ramp User pro Sekunde
5. Eine locust{target="_blank"} Konfigurationsdatei mit drei Tasks (für die Rust Implementierung):
   1. Ruft /fibonacci/10?use_native=true auf; mit Gewichtung 3
   2. Ruft /fibonacci/20?use_native=true auf; mit Gewichtung 2
   3. Ruft /fibonacci/30?use_native=true auf; ohne Gewichtung
   4. Verteilt über 100 User mit 1 Ramp User pro Sekunde

Allgemein wurde mit 1 Prozess und 1 Worker getestet.

Test-Machine

Lenovo ThinkPad P14s Gen 2i

• Prozessor: 11th Gen Intel® Core™ i7-1165G7
• RAM Größe: 32GiB

Dann schauen wir uns doch mal die Ergebnisse an!

Simple

Dieser Load-Test ruft den sehr einfachen JSON Response Endpoint auf und erhöht die User Zahlen stetig, bis zu einem Maximum von 10.000 Usern.

Wie zu erkennen ist, geht FastAPI (zumindest auf meinem Laptop) bereits mit 246.4 Requests pro Sekunde an seine Grenzen. So treten vermehrt Fehler auf bei denen die locust Requests nicht mehr (oder zu spät) verarbeitet wurden.

Ein ConnectionResetError ist ein Netzwerkfehler, der auftritt, wenn die Gegenstelle (in diesem Fall der Server) eine bestehende TCP-Verbindung abrupt beendet, typischerweise durch Senden eines RST-Pakets (Reset). Dies ist keine ordnungsgemäße Beendigung (wie ein FIN-Paket) und signalisiert oft, dass etwas Unerwartetes passiert ist oder der Server die Verbindung nicht mehr verarbeiten kann.

Unter hoher Last kann ein Server überfordert sein. Dies kann verschiedene Ursachen haben: Erschöpfung von Systemressourcen (wie CPU, Speicher, Dateideskriptoren) oder eine Überlastung der Event-Loop, die für die Verarbeitung der asynchronen Operationen zuständig ist. Wenn die Event-Loop nicht schnell genug neue Verbindungen annehmen oder Daten auf bestehenden Sockets verarbeiten kann, können Timeouts auftreten oder der Server muss Verbindungen zwangsweise schließen, um Ressourcen freizugeben oder eine Überlastung zu verhindern.

Im Kontext von Python und ASGI-Servern wie Uvicorn (der von FastAPI genutzt wird) spielt die Art und Weise, wie Python Netzwerk-I/O handhabt, eine Rolle. Obwohl Python mit asyncio und ASGI asynchrone Operationen ermöglicht und theoretisch viele Verbindungen gleichzeitig verwalten kann, während auf I/O gewartet wird, gibt es Grenzen. Die Ausführung von Python-Code selbst unterliegt dem Global Interpreter Lock (GIL), der verhindert, dass mehrere native Threads gleichzeitig Python-Bytecode auf mehreren CPU-Kernen ausführen. Bei sehr hoher Last, selbst wenn die Endpoints I/O-gebunden sind (wie das einfache JSON-Response), kann die schiere Menge an Kontextwechseln, das Scheduling der Coroutinen und die kurze Zeit, die jede Anfrage im Python-Code verbringt (auch wenn es nur das Serialisieren des JSONs ist), dazu führen, dass die Event-Loop überlastet wird. Der Serverprozess verbringt zu viel Zeit mit der Ausführung von Python-Code (auch wenn er asynchron ist), um schnell genug auf neue oder bestehende Socket-Ereignisse zu reagieren.

Die ConnectionResetErrors in diesem Test zeigen, dass FastAPI (bzw. die zugrundeliegende Python/Uvicorn-Schicht) schon recht früh an seine Grenzen stößt. Die Event-Loop kann die eingehenden Anfragen nicht schnell genug verarbeiten, was dazu führt, dass der Server die Verbindungen zurücksetzt, anstatt sie ordnungsgemäß zu bedienen. Dies ist ein Indikator dafür, dass die Python-Runtime unter dieser spezifischen extremen Last zum Engpass wird. Während Robyn, das eine Rust-Runtime ohne GIL nutzt, diese Art von Engpass bei der Verarbeitung von Netzwerkverbindungen besser umschiffen können sollte.

Das Load Test Ergebnis für Robyn sieht dagegen deutlich performanter aus:

Was sehen wir? Nicht nur keine Failures (da alle Requests verarbeitet werden konnten) sondern auch durch die Bank schnellere Antwortzeiten! Spannend, aber nun zu den Load-Tests die eine Größere Herausforderung darstellen.

Fibonacci

Hier direkt die Ergebnisse (links FastAPI, rechts Robyn):

{.object-cover .max-w-full .mb-5}

Wie wir sehen können, ist Robyn in den Antwortzeiten um ein paar Millisekunden besser als FastAPI. Auch trat hier unter FastAPI ein einziger Request Fail auf:

{.object-cover .max-w-full .mb-5}

Interessanterweise trat dieser zwischen 25 und 27 Requests per Second (RPS) auf und kam dann nie wieder vor. Dies kann also durchaus ein Ausreißer gewesen und auf meine nicht für API Hosting ausgelegte Hardware zurückzuführen sein.

Aber: Robyn unterstützt ja auch noch Rust nativen Code. Wie sieht es denn hier aus?

{.object-cover .max-w-full .mb-5}

Das Ergebnis? Drastisch.

Spaß bei Seite, wie wir sehen können sind die Antwortzeiten in der (lange nicht optimierten) Rust Implementierung fast verschwindend gering. Hier die locust Zusammenfassung:

{.object-cover .max-w-full .mb-5}

Hier fällt auf: Eine größere Fibonacci Zahl anzufordern scheint im Mittel und Maximum weniger Zeit als kleinere zu brauchen? Eine mögliche Erklärung hierfür könnte sein, dass der "Handover" von Python an Rust (und zurück von Rust an Python) die meiste Zeit in Anspruch nimmt.

Zusammenfassung

Wir haben FastAPI und Robyn mit einem simplen JSON-Endpoint sowie einem komplexeren Fibonacci-Endpoint unter Last getestet.

• FastAPI erreicht auf meinem Laptop etwa 246 RPS, dann treten vermehrt Fehler auf.
• Robyn bleibt auch bei 10.000 Usern stabil – schneller und ohne Fehler.
• Bei der Fibonacci-Berechnung (Python) ist Robyn um ein paar Millisekunden flotter, während FastAPI bei 25–27 RPS einen Ausreißer zeigt.
• Mit Rust-nativem Code in Robyn sehen wir eine drastische Verbesserung der Antwortzeiten – und sogar weniger Zeit bei größeren Fibonacci-Zahlen!

Fazit: Robyn skaliert besser als FastAPI, besonders bei hoher Last. Und Rust zeigt eindrucksvoll, wie viel mehr Performance möglich ist, wenn wir Python-Bottlenecks auslagern.

Projektstruktur und Entwickler-Workflow

Wie organisiert man ein Projekt mit FastAPI im Vergleich zu Robyn?

• FastAPI-Projektstruktur:

  • Typischerweise modular aufgebaut, oft nach Features oder Domänen getrennt (z.B. routers/, models/, services/).
  • Verlässt sich stark auf das Python-Ökosystem für Tooling: black für Formatierung, pytest für Tests, alembic für Datenbank-Migrationen.
  • Die main.py ist oft nur der Einstiegspunkt, der die verschiedenen Router und Konfigurationen zusammenführt.

• Robyn-Projektstruktur:

  • Oft monolithischer, da das Framework weniger "opinionated" ist. Viele Entwickler beginnen mit einer einzigen app.py.
  • Die Rust-Integration erfordert eine klare Trennung zwischen Python- und Rust-Code (z.B. in einem native/ Verzeichnis).
  • Robyn bringt eine eigene CLI mit, die für das Kompilieren von Rust-Code und das Starten der Anwendung verwendet wird, was den Workflow leicht verändert.

• Entwicklungs-Server:

  • FastAPI: Nutzt fastapi dev main.py für einen schnellen Hot-Reload-Entwicklungsserver.
  • Robyn: Bietet mit robyn --dev einen eingebauten Hot-Reload-Server, der auch Änderungen am Rust-Code erkennen und neu kompilieren kann.

Deployment in der Praxis: Von Lokal zu Live

• Containerisierung (Docker):

  • FastAPI: Das Dockerfile ist unkompliziert. Es basiert auf einem Python-Image und startet die Anwendung mit fastapi-cli (was intern uvicorn verwendet).

    FROM python:3.11-slim
    WORKDIR /app
    COPY requirements.txt .
    RUN pip install --no-cache-dir -r requirements.txt
    COPY . .
    CMD ["fastapi", "run", "main.py", "--host", "0.0.0.0", "--port", "80"]
    

  • Robyn: Das Dockerfile ist komplexer, wenn Rust-Code involviert ist. Es erfordert oft einen Multi-Stage-Build: eine Stage, um die Rust-Toolchain zu installieren und den Code zu kompilieren, und eine zweite, um die kompilierte Bibliothek in ein schlankes Python-Image zu kopieren.

    # Stage 1: Build Rust
    FROM rust:latest as builder
    WORKDIR /app
    COPY native/ .
    # Hier würde der Compile-Schritt für Rust stehen
    
    # Stage 2: Final Image
    FROM python:3.11-slim
    WORKDIR /app
    COPY --from=builder /app/target/release/libnative_fib.so .
    # ... Rest des Setups
    

• Produktions-Server:

  • FastAPI: Läuft auf jedem ASGI-kompatiblen Server (Uvicorn, Hypercorn, Daphne).
  • Robyn: Bringt seine eigene Rust-basierte Server-Runtime mit und benötigt keinen separaten ASGI-Server.

Fehlerbehandlung und Debugging

• FastAPI:

  • Bietet ein robustes System für Exception-Handler. Du kannst globale Handler für HTTPException oder benutzerdefinierte Exceptions definieren.
  • Die Validierungsfehler von Pydantic sind extrem detailliert und geben genau an, welches Feld im Request-Body fehlerhaft ist.
  • Das Debugging ist Standard-Python-Debugging.

• Robyn:

  • Bietet ebenfalls Exception-Handler, die jedoch weniger strukturiert sind als in FastAPI.
  • Das Debugging kann komplexer sein, wenn Fehler in der Rust-Runtime oder an der Schnittstelle zwischen Python und Rust auftreten. Dies erfordert möglicherweise Kenntnisse in beiden Sprachen.

Wann nun welches Framework?

Die Wahl zwischen FastAPI und Robyn hängt von den spezifischen Anforderungen deines Projekts ab:

FastAPI ist ideal für:

• Projekte mit komplexen Data Klassen
• Teams, die strikte Typisierung bevorzugen
• Anwendungen mit umfangreichen API-Dokumentationsanforderungen
• Projekte, die eine etablierte Community und viele Ressourcen benötigen

Robyn eignet sich besser für:

• Einfachere API-Projekte
• Teams, die sich mehr Flexibilität bei der Implementierung wünschen
• Projekte mit spezifischen Performance-Anforderungen, welche mit nativer Rust Integration und Runtime "heraus gequetscht" werden kann

Fazit

Sowohl FastAPI als auch Robyn sind moderne, leistungsstarke API-Frameworks, die unterschiedliche Stärken haben. FastAPI bietet eine umfassendere Lösung mit starker Typisierung und Validierung, während Robyn mehr Flexibilität und einen minimalistischen Ansatz bietet. Die endgültige Wahl sollte von den spezifischen Anforderungen deines Projekts abhängen.

FAQ – Häufige Fragen zur richtigen Framework Wahl

Welches Framework bietet bessere Performance?

Robyn zeigt in den Performance-Tests bessere Ergebnisse, besonders bei einfachen Endpoints und hoher Last. Allerdings bietet FastAPI eine ausgereiftere Ökosystem-Integration und Community-Unterstützung.

Kann ich Rust-Code in beiden Frameworks verwenden?

Robyn bietet eine native Integration von Rust-Code durch seine Rust-Runtime, während FastAPI dies nicht direkt unterstützt. Bei FastAPI müsste man auf traditionelle CPython-FFIs zurückgreifen.

Welches Framework ist besser für komplexe Datenmodelle geeignet?

FastAPI ist besser für komplexe Datenmodelle geeignet, da es Pydantic für Validierung und Serialisierung nutzt und eine strikte Typisierung bietet. Robyn bietet hier mehr Flexibilität, aber weniger vordefinierte Strukturen.

Wie unterscheiden sich die ORM-Möglichkeiten?

FastAPI bietet native Integration mit SQLAlchemy, Tortoise ORM und SQLModel. Robyn hat keine native ORM-Integration, erlaubt aber die Verwendung von Rust ORMs und bietet mehr Flexibilität bei der Datenbankwahl.

Für welche Art von Projekten ist welches Framework besser geeignet?

FastAPI eignet sich besser für komplexe Projekte mit umfangreichen API-Dokumentationsanforderungen und strikter Typisierung. Robyn ist ideal für einfachere API-Projekte und Teams, die mehr Flexibilität und native Rust-Integration wünschen.

Warum du Sentry unbedingt brauchst

Fehler in Live-Umgebungen können teuer werden. Wenn du dich auf E-Mails deiner Nutzer:innen verlässt, ist es oft schon zu spät. Sentry{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid}) bringt dir Echtzeit-Fehlermeldungen direkt ins Dashboard – inkl. User, Stacktrace und sogar Umgebung (Staging, Prod etc.).

:::GlobalButton{:url="/technologien/python-django-agentur/" :label="Entdecke, wie wir mit Django Software entwickeln" :target="_blank" :color="blue" .mb-6} :::

Schnellstart: So integrierst du Sentry in Django

1. SDK installieren

pip install --upgrade sentry-sdk

2. Projekt bei Sentry.io erstellen

Melde dich auf sentry.io an oder logge dich ein. Erstelle dort ein neues Projekt und wähle „Django“ als Plattform. Sentry generiert dir daraufhin automatisch einen DSN, das ist eine eindeutige URL, über die deine Anwendung Fehler an das richtige Projekt bei Sentry sendet.

Beispiel-DSN:

https://examplePublicKey@o0.ingest.sentry.io/0

Diesen DSN kopierst du und bindest ihn im nächsten Schritt in deine Django-App ein.

3. In settings.py integrieren

Integriere den DSN und die grundlegenden Einstellungen für Sentry in dein Projekt. Wichtig dabei sind drei Parameter:

• dsn: Verbindet deine App mit deinem Projekt bei Sentry.
• traces_sample_rate: Gibt an, wie viel Prozent der Performance-Daten (z. B. Langsamkeit von Views) gesammelt werden sollen. Bei 1.0 werden alle Daten erfasst. Für produktive Systeme sind Werte wie 0.2 üblich, um Datenmenge und Kosten zu reduzieren.
• send_default_pii: Aktiviert das Mitsenden personenbezogener Daten (z. B. eingeloggte User), damit du besser nachvollziehen kannst, wen ein Fehler betrifft.

import sentry_sdk
from sentry_sdk.integrations.django import DjangoIntegration

sentry_sdk.init(
    dsn=SENTRY_DSN,
    traces_sample_rate=0.1,
    profiles_sample_rate=0.1,
    environment=SENTRY_ENV,
    default_integrations=False,
    release=VERSION,
    integrations=[
        DjangoIntegration()
    ],
    send_default_pii=True
)

Environments trennen

Gerade bei größeren Projekten willst du unterscheiden können, ob ein Fehler in deiner Entwicklungs-, Staging- oder Produktionsumgebung auftritt. Sonst besteht die Gefahr, dass du bei Tests generierte Fehlermeldungen für Live-Probleme hältst.

Die environment-Angabe im Sentry-Setup hilft dir dabei, das sauber zu trennen:

ENVIRONMENT = os.getenv("ENVIRONMENT", "development")

Du kannst diesen Wert z.B. über Umgebungsvariablen pro Server setzen. Im Sentry-Dashboard kannst du später nach Environment filtern oder gezielte Alerts nur für Production-Fehler anlegen.

Manuelles Logging

Um deinen ersten Fehler zu testen, kannst du Sentry auch manuell ansprechen. Das ist besonders hilfreich, wenn du einen Fehler in einem bestimmten Kontext erfassen willst. Zum Beispiel, wenn du einen Fehler in einer bestimmten Funktion oder bei einem bestimmten Nutzer erfassen möchtest.

try:
    ...
except Exception as e:
    sentry_sdk.capture_exception(e)

Damit wäre die Einrichtung von Sentry in Django abgeschlossen. Du kannst jetzt Fehler in deiner App überwachen und bekommst sofort eine Benachrichtigung, wenn etwas schiefgeht. Super! Nun noch ein paar Tipps, wie du Sentry optimal nutzen kannst.

:::GlobalCallAnExpert{:bg="bg-bs-blue"} #buttonBlockTitle Wir können das Error-Tracking auch in Deiner Django App verbessern :::

Best Practices für eine saubere Fehlerüberwachung

Einmal eingerichtet, kannst du mit ein paar Tipps das Beste aus Sentry herausholen:

1. Konsequent Environments nutzen

Ordne alle Fehler sauber nach production, staging oder development. So kannst du gezielt nach Problemen im Live-System suchen – und behältst bei Tests die Übersicht.

2. Release-Tags verwenden

Wenn du regelmäßig neue Versionen deployst, solltest du release="myapp@1.2.3" setzen. Damit kannst du erkennen, ob ein Fehler erst seit einer bestimmten Version auftritt. Praktisch bei Regressions oder Hotfixes.

3. Nutzerkontext aktivieren

Sentry kann dir sagen, welcher eingeloggte Nutzer betroffen war. Das hilft enorm beim Nachvollziehen und Debuggen.

set_user({"email": user.email})

4. Fehler gezielt ignorieren

Nicht jede Exception ist kritisch. Du kannst Regeln in Sentry anlegen, um z.B. 404-Fehler oder bestimmte Warnungen auszublenden. So bleibt dein Alert-Feed übersichtlich.

5. Alert-Regeln definieren

Setze Alerts z. B. bei mehr als 10 Fehlern in 5 Minuten oder wenn eine bestimmte Umgebung betroffen ist. Diese Regeln kannst du per Slack, E-Mail oder Webhook triggern lassen.

Das Sentry-Dashboard verstehen

• Das Dashboard ist dein zentraler Einstiegspunkt. Es zeigt dir sofort:
• Neue und häufige Fehler
• Welche Releases und Environments betroffen sind
• Den Zeitverlauf und Trends von Fehlern

Hier erhältst du eine Übersicht über alle Fehler, die in deiner App aufgetreten sind. Du kannst sie nach Schweregrad, Häufigkeit und Umgebung filtern.

Fehler und Issues im Detail

Klickst du im Dashboard auf einen Fehler, bekommst du eine detaillierte Übersicht:

• Stacktrace mit Codezeilen
• Kontext der Anfrage (Header, URL, etc.)
• User-Daten (falls aktiviert)
• Link zum betroffenen Release

Sentry gruppiert identische Fehler automatisch, sodass du nicht jeden einzelnen Vorfall manuell prüfen musst. Hier siehst du auf einen Blick: Was ist kritisch? Was wurde zuletzt gesehen? Wie viele Nutzer:innen sind betroffen?

Fazit

Mit Sentry bist du im Fehlerfall immer sofort informiert – und kannst handeln, bevor es eskaliert. Einrichten lohnt sich, nicht nur in der Produktion, sondern auch in Staging & Dev.

{.object-cover .max-w-full .mb-6}

:::GlobalTitle{:size="lg" .mb-5} Function-as-a-Service (FaaS) vs Kubernetes in der Welt des Cloud Computing ::: :::GlobalParagraph Die Welt der modernen Computertechnologie ist eine umfangreiche und sich ständig weiterentwickelnde Landschaft, die eine Vielzahl von Plattformen und Frameworks zur Auswahl bietet. In diesem Blogbeitrag möchten wir zwei prominente Paradigmen erkunden und vergleichen: Function-as-a-Service (FaaS)/Serverless und Kubernetes. Diese Plattformen haben erhebliche Aufmerksamkeit erregt und die Art und Weise, wie Anwendungen entwickelt, bereitgestellt und verwaltet werden, revolutioniert. ::: :::GlobalParagraph Mit dem Fortschreiten der Technologie suchen Organisationen nach Möglichkeiten, ihre Infrastruktur zu optimieren, die Skalierbarkeit zu verbessern und die Entwicklungsworkflows zu optimieren. FaaS, mit seinem Versprechen von Skalierbarkeit und ereignisgesteuerter Ausführung, hat sich als eine überzeugende Option für Entwickler etabliert. Auf der anderen Seite bietet Kubernetes, der Branchenstandard für die Container-Orchestrierung, eine robuste und flexible Plattform, die es Organisationen ermöglicht, Anwendungen in großem Maßstab zu entwickeln, bereitzustellen und zu verwalten. ::: :::GlobalParagraph In diesem Vergleich gehen wir auf die grundlegenden Prinzipien und Eigenschaften von FaaS und Kubernetes ein und möchten damit ihre einzigartigen Stärken und Schwächen beleuchten. Durch die Untersuchung ihrer architektonischen Unterschiede, Ressourcenverwaltungsmöglichkeiten, Entwicklererfahrungen, betrieblichen Komplexitäten und Kostenüberlegungen möchten wir dich mit dem nötigen Wissen ausstatten, um fundierte Entscheidungen bei der Auswahl der optimalen Plattform für deine spezifischen Anwendungsfälle zu treffen. ::: :::GlobalParagraph Bitte beachte, dass der folgende Inhalt einen umfassenden Überblick und Vergleich von FaaS/Serverless und Kubernetes bieten soll, ohne in detaillierte Informationen einzutauchen. Der Fokus liegt auf den einzigartigen Merkmalen und Überlegungen jeder Plattform, um dir die Möglichkeit zu geben, fundierte Entscheidungen basierend auf deinen Anforderungen zu treffen. Lassen wir uns auf diese spannende Reise in die Welt von FaaS und Kubernetes ein! :::

:::GlobalTitle{:size="lg" .mb-5} Serverless Computing mit Function as a Service (FaaS) ::: :::GlobalParagraph Function as a Service (FaaS) ist ein relativ neuer Ansatz für das Computing, der die Art und Weise verändert, wie Unternehmen Anwendungen entwickeln und bereitstellen. Mit FaaS schreiben und implementieren Entwickler kleine, zustandslose Funktionen, die durch Ereignisse wie HTTP-Anfragen, Datenbankänderungen und Nachrichten von anderen Diensten ausgelöst werden. Dieser Ansatz beseitigt die Notwendigkeit, Server und Infrastruktur zu verwalten, und ermöglicht es Entwicklern, sich auf das Schreiben von Code und die Bereitstellung von Mehrwert für ihre Kunden zu konzentrieren. :::

:::GlobalTitle{:size="md" :color="text-bs-blue" :tag="h3" .mb-5} Vorteile von FaaS ::: :::GlobalParagraph FaaS bietet mehrere Vorteile gegenüber traditionellen serverbasierten Architekturen: ::: :::GlobalBlock{.ul-disk .mb-5}

• Verringerte Verwaltungskosten für die Infrastruktur: Mit serverlosem Computing müssen Entwickler die zugrunde liegende Infrastruktur nicht verwalten, was die Infrastrukturkosten erheblich reduzieren kann.
• Schnellere Time-to-Market: Serverloses Computing vereinfacht die Bereitstellung und beschleunigt das Schreiben und Bereitstellen von Code, sodass Unternehmen Produkte und Dienstleistungen schneller auf den Markt bringen können.
• Hohe Skalierbarkeit: FaaS skaliert Ressourcen automatisch nach Bedarf, was sicherstellt, dass Anwendungen plötzliche Spitzen im Datenverkehr ohne Ausfallzeiten bewältigen können.
• Erhöhte Ausfallsicherheit: Serverlose Plattformen bieten in der Regel eine integrierte Fehlertoleranz und können Fehler automatisch behandeln, was sicherstellt, dass Anwendungen hoch ausfallsicher sind und unerwartete Fehler ohne Ausfallzeiten bewältigen können.
• Kostenflexibilität: Mit FaaS zahlst du nur für die tatsächlich genutzte Rechenzeit deines Codes, was eine genauere Kostenkontrolle und potenziell niedrigere Gesamtkosten im Vergleich zu traditionellen serverbasierten Architekturen ermöglicht, bei denen du für den gesamten Server oder eine feste Menge an Rechenressourcen bezahlen musst, unabhängig von der tatsächlichen Nutzung.
• Nahtlose Integration in die Cloud: AWS Lambda integriert sich nahtlos in andere AWS-Cloud-Services wie DynamoDB und SQS, was es Entwicklern ermöglicht, komplexe und skalierbare Anwendungen zu erstellen, die mehrere Services nutzen. Dies ermöglicht Unternehmen die Erstellung maßgeschneiderter Lösungen, die ihren spezifischen Anforderungen entsprechen und sich problemlos in bestehende Workflows integrieren lassen. :::

:::GlobalTitle{:size="md" :color="text-bs-blue" :tag="h3" .mb-5} Potenzielle Nachteile von FaaS ::: :::GlobalParagraph Trotz der Vorteile von FaaS gibt es auch einige Einschränkungen zu beachten. Funktionen sind in Bezug auf Speicher und Ausführungszeit begrenzt, und die Startlatenz (die anfängliche Startzeit der Laufzeit deiner Funktion) kann sich auf die Leistung der Anwendung auswirken, wenn Funktionen selten aufgerufen werden. Es ist jedoch möglich, die Infrastruktur im Voraus bereitzustellen, um die Startlatenz zu minimieren. Es ist auch wichtig zu beachten, dass serverlose Funktionen häufig auf einer proprietären Plattform ausgeführt werden, was bedeutet, dass sie möglicherweise nicht mit anderen Cloud-Plattformen oder On-Premise-Infrastrukturen kompatibel sind. ::: :::GlobalParagraph Darüber hinaus sind Funktionen von Natur aus zustandslos, d.h. sie haben keine Erinnerung an vorherige Aufrufe oder Interaktionen. Diese Einschränkung kann jedoch durch die Nutzung von serverlosen Datenbanken oder anderen zustandsbehafteten Diensten überwunden werden. Durch die Verwendung dieser Dienste können Funktionen Daten erstellen und abrufen, die über Aufrufe hinweg bestehen bleiben, was eine zustandsbehaftetes Verhalten in einer ansonsten zustandslosen Umgebung ermöglicht. :::

:::GlobalTitle{:size="md" :color="text-bs-blue" :tag="h3" .mb-5} Anwendungsfälle für FaaS ::: :::GlobalParagraph Function as a Service wurde von Unternehmen jeder Größe genutzt, um innovative und spannende Lösungen zu entwickeln. Hier sind einige Beispiele: ::: :::GlobalBlock{.ul-disk .mb-5}

• Ereignisgesteuerte Verarbeitung: FaaS ist eine ideale Lösung für ereignisgesteuerte Verarbeitung, bei der Code nur in Reaktion auf bestimmte Ereignisse ausgeführt werden muss. Dies kann die Verarbeitung von Daten aus Sensoren, die Reaktion auf Benutzeraktionen in einer Webanwendung oder die Automatisierung von Geschäftsprozessen umfassen.
• Serverlose APIs: FaaS ist eine gute Option für den Aufbau serverloser APIs{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid}, bei denen du nur für die genutzten Rechenressourcen bezahlst. Dies kann nützlich sein, um kleine, fokussierte Microservices{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} zu erstellen, die ohne komplexe Infrastrukturverwaltung einfach bereitgestellt und skaliert werden können.
• Leichtgewichtige Anwendungen: FaaS ist eine gute Option für leichtgewichtige Anwendungen, bei denen du Anwendungen schnell bereitstellen und skalieren musst, ohne umfangreiche Infrastrukturverwaltung zu benötigen. Dies kann insbesondere für kleine Startups oder einzelne Entwickler nützlich sein, die sich auf den Aufbau ihrer Anwendungen konzentrieren müssen, anstatt die Infrastruktur zu verwalten. ::: :::GlobalParagraph AWS Lambda ist eine der beliebtesten FaaS-Lösungen, die heute verfügbar sind. Wenn du das volle Potenzial des serverlosen Computings nutzen möchtest, sind superluminar die Experten, die du an deiner Seite brauchst. Als AWS Advanced Consulting Partner haben sie sich auf die Entwicklung innovativer und kosteneffizienter Lösungen spezialisiert, insbesondere mit serverlosem Computing, einschließlich AWS Lambda als Kernkomponente. :::

:::GlobalTitle{:size="lg" .mb-5} Kubernetes Verstehen ::: :::GlobalParagraph Kubernetes{.bs-link-blue} ist eine Open-Source-Container-Orchestrierungsplattform, die die Art und Weise, wie Anwendungen verwaltet und bereitgestellt werden, revolutioniert hat. Es bietet eine umfassende Lösung zur Automatisierung der Bereitstellung, Skalierung und Verwaltung von containerisierten Anwendungen. Mit seinen leistungsstarken Funktionen und Komponenten bietet Kubernetes eine skalierbare und flexible Plattform für die moderne Anwendungsentwicklung. :::

:::GlobalTitle{:size="md" :color="text-bs-blue" :tag="h3" .mb-5} Vorteile der Verwendung von Kubernetes ::: :::GlobalParagraph Einer der Hauptvorteile von Kubernetes besteht darin, dass es die Verwaltung von Anwendungen automatisiert und vereinfacht. Kubernetes ermöglicht es Entwicklern, den gewünschten Zustand ihrer Anwendung zu definieren und zu deklarieren, und die Plattform kümmert sich um die Orchestrierung der Bereitstellung und Skalierung von Containern entsprechend. Diese Automatisierung reduziert die Komplexität und den manuellen Aufwand, der für die Verwaltung von containerisierten Umgebungen in großem Maßstab erforderlich ist. ::: :::GlobalParagraph Kubernetes bietet auch integrierte Unterstützung für Autoscaling, Lastenausgleich und Service Discovery, um sicherzustellen, dass der Datenverkehr effizient auf die Anwendungsinstanzen verteilt wird. Es bietet fortschrittliche Netzwerkfunktionen, die es Containern ermöglichen, nahtlos miteinander zu kommunizieren. Dies erleichtert die Entwicklung von verteilten und auf Microservices basierenden Architekturen{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid}. ::: :::GlobalParagraph Ein weiterer bedeutender Vorteil von Kubernetes sind seine Fehlertoleranz und Selbstheilungsfähigkeiten. Kubernetes überwacht kontinuierlich den Zustand der Anwendungsinstanzen und startet oder ersetzt automatisch fehlgeschlagene Container. Dies gewährleistet hohe Verfügbarkeit und Widerstandsfähigkeit, minimiert Ausfallzeiten und verbessert die Gesamtzuverlässigkeit der Anwendung. :::

:::GlobalTitle{:size="md" :color="text-bs-blue" :tag="h3" .mb-5} Potenzielle Nachteile von Kubernetes ::: :::GlobalParagraph Obwohl Kubernetes als robustes Container-Orchestrierungssystem an Beliebtheit gewonnen hat, hat es bestimmte Nachteile, darunter höhere Verwaltungskosten und Komplexität. Die Implementierung und Wartung von Kubernetes-Clustern erfordert spezialisierte Fähigkeiten, was zu erhöhten Betriebskosten führen kann. Darüber hinaus ist die Lernkurve von Kubernetes steil und erfordert umfangreiche Schulungen und kontinuierliche Weiterbildung für Teams. Die kontinuierliche Überwachung, Skalierung und Fehlerbehebung erhöhen die Verwaltungslast. Darüber hinaus kann die Bereitstellung und Konfiguration von Anwendungen auf Kubernetes komplex sein, insbesondere für kleinere Projekte oder Teams ohne dedizierte Ressourcen. Diese Faktoren tragen gemeinsam zu den potenziellen Nachteilen von Kubernetes bei. :::

:::GlobalTitle{:size="md" :color="text-bs-blue" :tag="h3" .mb-5} Anwendungsfälle für Kubernetes ::: :::GlobalParagraph Kubernetes eignet sich besonders gut für die Verwaltung komplexer und skalierbarer Anwendungen. Seine flexible Architektur und seine Ressourcenverwaltungsfähigkeiten machen es zu einer idealen Wahl für Microservices-Architekturen{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid}, bei denen Anwendungen aus mehreren kleinen, unabhängigen Services bestehen. Kubernetes ermöglicht eine effiziente Bereitstellung, Skalierung und Überwachung (unter Verwendung zusätzlicher Tools wie prometheus) dieser Services und ermöglicht es Unternehmen, hochresiliente und anpassungsfähige Systeme aufzubauen. ::: :::GlobalParagraph Datenintensive Anwendungen, wie beispielsweise solche, die Big Data-Verarbeitung oder maschinelles Lernen beinhalten, können von Kubernetes stark profitieren. Es ermöglicht Organisationen, die Leistung verteilten Rechnens zu nutzen, indem Workloads effizient über einen Cluster von Maschinen verteilt werden. Kubernetes bietet die erforderlichen Tools und Abstraktionen zur Verwaltung von datenintensiven Verarbeitungspipelines und ist daher eine attraktive Option für datengetriebene Anwendungen. ::: :::GlobalParagraph Darüber hinaus ist es auch möglich, die elegante FaaS-Architektur auf Kubernetes mithilfe von Software wie OpenFaaS zu nutzen. :::

:::GlobalTitle{:size="lg" .mb-5} Vergleich von FaaS und Kubernetes ::: :::GlobalTitle{:size="md" :color="text-bs-blue" :tag="h3" .mb-5} Architektur und Skalierbarkeit ::: :::GlobalParagraph Bei einem Vergleich von Functions as a Service (FaaS) und Kubernetes ist einer der wichtigsten Aspekte ihre architektonischen Unterschiede. FaaS-Plattformen wie AWS Lambda oder Azure Functions sind für ereignisgesteuertes, serverloses Computing konzipiert. Sie führen einzelne Funktionen als Reaktion auf Ereignisse aus und ermöglichen eine hohe Skalierbarkeit und Ressourceneffizienz. Kubernetes hingegen folgt einer containerbasierten Architektur, bei der Anwendungen in kleinere, isolierte Anwendungen (Container) aufgeteilt werden, die unabhängig voneinander skaliert werden können. Kubernetes bietet robuste Skalierungsfähigkeiten, mit denen Organisationen ihre Anwendungen sowohl horizontal als auch vertikal je nach Bedarf skalieren können. :::

:::GlobalTitle{:size="md" :color="text-bs-blue" :tag="h3" .mb-5} Entwicklungserfahrung und Bereitstellungsworkflow ::: :::GlobalParagraph Die Entwicklungserfahrung und der Bereitstellungsworkflow unterscheiden sich ebenfalls zwischen FaaS und Kubernetes. Bei FaaS konzentrieren sich Entwickler hauptsächlich auf das Schreiben und Bereitstellen einzelner Funktionen. FaaS-Plattformen kümmern sich um die zugrunde liegende Infrastruktur und skalieren Funktionen automatisch basierend auf eingehenden Ereignissen. Dieses vereinfachte Entwicklungsmodell reduziert die Betriebslast für Entwickler. Im Gegensatz dazu erfordert Kubernetes, dass Entwickler ihre Anwendungen in Container verpacken und den gewünschten Zustand des Systems mithilfe von YAML- oder Konfigurationsdateien definieren. Entwickler haben mehr Kontrolle über die Infrastruktur und können komplexe, mehrere Container umfassende Anwendungen bereitstellen. Dies erfordert jedoch mehr anfängliche Konfiguration und Verwaltungsaufwand. :::

:::GlobalTitle{:size="md" :color="text-bs-blue" :tag="h3" .mb-5} Komplexität des Betriebs und Wartung ::: :::GlobalParagraph Die operationale Komplexität und Wartungsüberlegungen unterscheiden sich zwischen FaaS und Kubernetes. FaaS-Plattformen abstrahieren einen Großteil der zugrunde liegenden Infrastruktur und ermöglichen es Entwicklern, sich ausschließlich auf den Code zu konzentrieren. Dies vereinfacht den Betrieb, da die Plattform Skalierbarkeit, Fehlertoleranz und Infrastrukturwartung übernimmt. Im Gegensatz dazu erfordert Kubernetes von Organisationen, die gesamte Container-Orchestrierungsinfrastruktur zu verwalten und zu warten, einschließlich der Verwaltung des Clusters, Überwachung, Skalierung und Gewährleistung hoher Verfügbarkeit. Während Kubernetes mehr Kontrolle bietet, erfordert es auch mehr operationelles Fachwissen und Aufwand. :::

:::GlobalTitle{:size="md" :color="text-bs-blue" :tag="h3" .mb-5} Kostenüberlegungen ::: :::GlobalParagraph Kostenüberlegungen spielen eine wichtige Rolle bei einem Vergleich von FaaS und Kubernetes. FaaS-Plattformen arbeiten nach dem Pay-per-Use-Modell, bei dem Organisationen basierend auf der Anzahl der Funktionsaufrufe und deren Ressourcenverbrauch in Rechnung gestellt werden. Dies kann kostengünstig für Anwendungen mit sporadischem oder unvorhersehbarem Traffic sein. Kubernetes hingegen erfordert von Organisationen, ihre eigene Infrastruktur bereitzustellen und zu verwalten, was möglicherweise anfängliche Kosten für Hardware oder Cloud-Ressourcen mit sich bringt. Kubernetes-Anwendungen müssen kontinuierlich betrieben werden, um die Serviceverfügbarkeit sicherzustellen, unabhängig davon, ob eingehende Anfragen vorliegen oder nicht. Sobald eingerichtet, bietet Kubernetes jedoch mehr Kostenkontrolle und -vorhersagbarkeit für lang laufende oder kontinuierlich aktive Anwendungen. :::

:::GlobalTitle{:size="lg" :tag="h3" .mb-5} Überlegungen zu Function-as-a-Service (FaaS) und Kubernetes ::: :::GlobalParagraph Zusammenfassend lässt sich sagen, dass sowohl Functions as a Service (FaaS)/Serverless als auch Kubernetes einzigartige Stärken und Möglichkeiten für die Entwicklung und Bereitstellung moderner Anwendungen bieten. Das Verständnis der Nuancen und Kompromisse der einzelnen Plattformen ist entscheidend, um fundierte Entscheidungen für deine spezifischen Anwendungsfälle zu treffen. ::: :::GlobalParagraph FaaS-Plattformen zeichnen sich durch ihre ereignisgesteuerte, serverlose Architektur aus, die es Entwicklern ermöglicht, sich ausschließlich auf das Schreiben von Funktionen zu konzentrieren, ohne sich um die Verwaltung der Infrastruktur zu kümmern. Sie bieten nahtlose Skalierbarkeit und Ressourceneffizienz, was sie zu einer attraktiven Wahl für Anwendungen mit sporadischen oder unvorhersehbaren Verkehrsmustern macht. ::: :::GlobalParagraph Auf der anderen Seite bietet Kubernetes eine robuste Plattform für die Container-Orchestrierung, die es Unternehmen ermöglicht, komplexe Anwendungen in großem Umfang zu erstellen, bereitzustellen und zu verwalten. Sie bietet Flexibilität, Kontrolle und erweiterte Funktionen für die Verwaltung verteilter Systeme und eignet sich daher für Microservices-Architekturen{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} und datenintensive Anwendungen. ::: :::GlobalParagraph Letztlich gibt es keine Einheitslösung für alle. Die Wahl zwischen FaaS und Kubernetes hängt von der Art deiner Anwendung, den Skalierungsanforderungen, den Entwicklungspräferenzen und den Budgetbeschränkungen ab. In einigen Fällen könnte ein hybrider Ansatz oder die Kombination beider Plattformen die beste Strategie sein. ::: :::GlobalParagraph Im Zuge der technologischen Entwicklung werden neue Fortschritte und Plattformen auftauchen, die die Möglichkeiten für Entwickler und Unternehmen noch erweitern. Durch das Verfolgen von Branchentrends und die kontinuierliche Bewertung der Eignung von Plattformen stellst du sicher, dass du an der Spitze der Innovation bleibst und optimale Lösungen für deine Anwendungen liefern kannst. :::

{.object-cover .max-w-full .mb-5}

::GlobalTitle{:size="lg" .mb-5} Gefyra für Kubernetes-Entwicklung: Das kommt 2025 :: ::GlobalParagraph Du entwickelst in Kubernetes und willst endlich schneller testen, ohne Deploy-Schleifen? Dann wirst du Gefyra lieben – und das kommende Jahr noch mehr. Denn 2025 bringt fette Features, die deine Dev-Experience auf ein neues Level heben. Hier liest du, was die Gefyra Roadmap bereithält – inklusive Performance-Boost, neuer Config-Datei, CI-Integration und der Game-Changer: User Bridges. ::

:::GlobalButton{:url="https://gefyra.dev/" :label="Entdecke, wie Gefyra dein Dev-Setup verändert" :target="_blank" :color="blue" .mb-6} :::

::GlobalTitle{:size="lg" .mb-5} Was ist Gefyra? :: ::GlobalParagraph Falls du neu bist: Gefyra{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} ist ein Open-Source-Tool, das deinen lokalen Code direkt im Kubernetes-Cluster ausführt – ohne Build- und Push-Zyklus. Das spart dir jede Menge Zeit und Nerven beim Entwickeln und Debuggen. ::

::GlobalParagraph Seit der Version 2.0 Ende 2023 hat sich einiges getan. Zeit also für eine klare Roadmap für 2025, mit allem, was kommt. ::

::GlobalTitle{:size="lg" .mb-5} 1. Quartal 2025: Das ist schon da :: ::GlobalParagraph Da das erste Quartal 2025 bereits fast um ist, hier eine kurze Zusammenfassung was sich bisher getan hat: :: ::GlobalBlock{.ul-disk .mb-4}

• Neuer cli Parameter --registry: Dieser erlaubt es eine custom Docker Registry, von welcher die Gefyra Images gepulled werden sollen, anzugeben. Dies ist besonders hilfreich in “Air-Gapped Environments”.
• Neuer cli Parameter --mtu: Dieser Parameter erlaubt es, den standard Wert der Wireguard MTU (1340) zu verändern. Dies ist hilfreich wenn man bereits durch einen VPN auf seinen Kubernetes Cluster zugreift und nun eine Gefyra Verbindung aufbauen möchte. ::

{.mx-auto .max-w-full}

::GlobalParagraph Hier eine kurze Demonstration der neuen Parameter und wie sich diese auf das Client File auswirken. ::

::GlobalTitle{:size="lg" .mb-5} Was 2025 noch bringt ::

::GlobalParagraph Aber auch für den Rest von 2025 ist Großes geplant! ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 1. Copy & Copy Sync :: ::GlobalParagraph Fangen wir mit dem Copy & Copy Sync Feature an: Dieses soll es ermöglichen, lokale Dateien mit Dateien im Cluster, und andersherum, zu synchronisieren. Wie bestimmt schnell zu erkennen ist, hilft dies vor allem bei Konfigurationsdateien, welche man in einem Feature einführt und die noch nicht im Cluster verfügbar sind. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 2. UDP-over-TCP-Support :: ::GlobalParagraph Seit April 2024 (und auch schon ein bisschen davor) existiert ein GitHub Issue{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid}, dass zur Zeit die Gefyra Verbindung nur über UDP möglich ist. Das wollen wir endlich ändern! So soll es in Zukunft möglich sein, mittels udp-over-tcp{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} existierende Workloads in Kubernetes Cluster, die nur TCP Load Balancing erlauben, zu integrieren. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 3. Gefyra-Konfigurationsdatei :: ::GlobalParagraph Ein weiteres spannendes Feature wird die Gefyra Konfigurationsdatei. Diese wird 2025 eine entscheidende Rolle spielen und die Grundarbeit für viele weitere Features legen. Sinn und Zweck der Datei ist es, Gefyra Setups ein wenig einfacher und reproduzierbarer zu gestalten. Man wird zum Beispiel konfigurieren können, dass beim gefyra run zwei Container lokal starten sollen. Und für einen davon soll automatisch eine Bridge angelegt werden. :: ::GlobalParagraph Adé also die Tage des Durchsuchens der Bash History nach dem richtigen run oder bridge Befehl. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 4. CI-Integration :: ::GlobalParagraph Sobald das Konfigurationsdatei Feature verfügbar ist, wird Gefyra dieses Jahr auch angepasst für CI Workflows. Dies soll kurzlebige Sessions und Reproduzierbarkeit ermöglichen / verbessern und dazu beitragen, dass eure CIs echte Use-Cases abbilden können. ::

::GlobalTitle{:size="lg" .mb-5} Das Highlight: User Bridges :: ::GlobalParagraph Nun aber zum größten geplanten Feature für 2025. Die User Bridges! :: ::GlobalParagraph Was genau sind aber User Bridges? Wie ihr bestimmt schon wisst, ermöglicht Gefyra das “bridgen” eines lokalen Containers und all seiner Netzwerk Requests in den target Cluster. Dadurch können echte Flows und Interaktionen mit anderen Micro-Services / Datenbanken / Task-Runnern getestet werden. Ganz ohne die Notwendigkeit, den Code zu deployen. :: ::GlobalParagraph Das große Problem an den bisherigen globalen Bridges ist, dass nur eine Person einen bestimmten Workload bridgen kann. Ein simultanes Entwickeln an zwei verschiedenen Features im gleichen Service ist also nicht möglich. :: ::GlobalParagraph Und hier kommen die User Bridges ins Spiel. Das Konzept sieht vor, dass das Ziel Workload im Cluster “kopiert” wird. ::

{.mx-auto .max-w-full}

::GlobalParagraph Gefyras Carrier setzt dann, wie bekannt, am originalen Workload an. Wenn nun ein Request, welcher bestimmten Regeln entspricht (mehr dazu gleich), registriert wird, wird dieser vom gepatchten Workload verarbeitet. Ansonsten wird er an die Kopie weitergereicht und vom originalen Code verarbeitet. ::

::GlobalParagraph Um all dies zu ermöglichen muss natürlich einiges geschehen: ::

::GlobalBlock{.ul-disk .mb-4}

• Carrier wird eine Version II bekommen. Diese wird mit Pingora{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid}, Cloudflares Rust Networking Bibliothek, umgesetzt. Durch Einsatz von pingora erhoffen wir uns schnellere Start-up-Zeiten, mehr Reliabilität und weniger Ressourcenverbrauch als mit der bisherigen nginx Lösung.
• Es wird in Zukunft sogenannte “bridge mount objects” geben. Diese sind Kubernetes CRDs, welche die User Bridges vorbereiten sollen und so ein noch schnelleres bridgen erlauben. Damit werden User Bridges der neue Status Quo!
• Header & URL matching. Diese Änderung ist wegweisend für die User Bridges. Der User soll mit diesen Optionen Regeln aufstellen, wie die User Bridge Requests verarbeitet. Hierbei ist eurer Fantasie keine Grenze gesetzt! Ein Header mit Regex Pfad matching auf die 5. Subroute? Kein Problem! ::

::GlobalTitle{:size="lg" .mb-5} Gefyra 2025: ein Jahr voller Developer-Optimierungen :: ::GlobalParagraph Die Roadmap für 2025 zeigt, dass Gefyra sich weiter in eine Richtung entwickelt, die das Kubernetes-Development noch flexibler und effizienter macht. Mit Features wie Copy Sync, UDP-over-TCP-Unterstützung und einer Konfigurationsdatei wird die Developer Experience deutlich verbessert. Besonders die User Bridges versprechen, ein Game-Changer zu sein, indem sie das simultane Entwickeln an mehreren Features im selben Service ermöglichen. :: ::GlobalParagraph Die kommenden Monate werden spannend, und wir freuen uns darauf, diese neuen Funktionen gemeinsam mit der Community umzusetzen. Hast du Feedback oder Ideen zu den geplanten Features? Dann komm gerne auf uns zu – Gefyra lebt von der Zusammenarbeit mit seinen Nutzern! ::

:::GlobalTitle{:size="lg" .mb-5 .mt-8} Häufige Fragen :::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 1. Was ist der Vorteil der neuen User Bridges in Gefyra? :: ::GlobalParagraph Mit den User Bridges kannst du parallel mit anderen Entwickler:innen am selben Kubernetes-Service arbeiten – ohne Deploys und ohne Konflikte. Das macht Teamwork im Microservices-Kontext deutlich einfacher. :: ::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 2. Wie hilft mir die Gefyra-Konfigurationsdatei im Alltag? :: ::GlobalParagraph Die neue gefyra.yaml erlaubt es dir, dein Setup einmal zu definieren und immer wieder reproduzierbar zu starten – ideal für Teams, CI/CD und strukturierte Workflows. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 3. Wird Gefyra 2025 auch für CI/CD nutzbar sein? :: ::GlobalParagraph Ja! Kurzlebige Sessions, automatisches Bridging und reproduzierbare Environments machen Gefyra bald CI-ready – perfekt, um echte Use Cases in deinen Pipelines zu testen. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 4. Warum ist Copy & Sync ein wichtiges Feature für Kubernetes-Development? :: ::GlobalParagraph Copy & Sync synchronisiert Dateien zwischen lokalem System und Cluster – z. B. Konfigurationsdateien, die im Cluster noch nicht vorhanden sind. Das spart Zeit und verhindert Fehlkonfigurationen. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 5. Welche Vorteile bringt die Unterstützung für UDP-over-TCP? :: ::GlobalParagraph Damit kannst du Gefyra auch in Clustern nutzen, die ausschließlich TCP-Traffic zulassen – etwa bei restriktiven Load Balancer-Settings. Mehr Kompatibilität, weniger Einschränkungen. ::

{.object-cover .max-w-full .mb-5}

:::globalTitle{:size="lg" .mb-5} WAS IST EINE ELEKTRONISCHE PATIENTENAKTE/GESUNDHEITSKARTE? ::: :::globalParagraph Im Gegensatz zu ihrem Vorgänger, der KVK (Krankenversicherungskarte), kann die eGK mehr als nur für die Abrechnung verwendet zu werden. Sie dient zur Authentifizierung von Patienten in Praxen und Kliniken. Mithilfe der Karte und einer zugehörigen PIN ist es Patienten möglich, ihrem behandelnden Mediziner Zugriff auf die eigene ePA zu geben. ::: :::globalParagraph Hierbei wird es zu Beginn so sein, dass ein Arzt Zugriff auf die komplette Akte bekommt, später ist ein beschränkter denkbar. Außerdem können vom behandelnden Mediziner Daten bzw. Dokumente wie Röntgenbilder, MRTs oder Arztbriefe in der elektronischen Akte des Patienten gespeichert werden. Die eigene Akte kann der Patient dann beispielsweise bei einer Überweisung an einen anderen Arzt auch via Gesundheitskarte freigeben. ::: :::globalParagraph Die elektronischen Patientenakten werden in der Telematikinfrastruktur (TI) gespeichert. Zugriff auf diese erhält man nur mit entsprechendem Heilberufsausweis. Dieser kommt wie die eGK in Form einer Chipkarte und dient zur Identifizierung eines Arztes. ::: :::globalParagraph Mehr Details zu dem Aufbau, der Funktionsweise und den Problemen der TI sind anschaulich in diesen beiden Vorträgen erklärt: :::

:::globalTitle{:size="sm" :tag="h4" .mb-5} „Hacker hin oder her“: Die elektronische Patientenakte kommt! ::: :::globalParagraph https://www.youtube.com/embed/q6l_B2fgJjM{.bs-link-blue :target="_blank"} ::: :::globalParagraph (Quelle: YouTube-Kanal media.ccc.de; Martin Tschirsich cbro, Dr. med. Christian Brodowski, Dr. André Zilch) :::

:::globalTitle{:size="sm" :tag="h4" .mb-5} 15 Jahre deutsche Telematikinfrastruktur (TI) ::: :::globalParagraph https://www.youtube.com/watch?v=lHdXeH9ROog{.bs-link-blue :target="_blank"} ::: :::globalParagraph (Quelle: YouTube-Kanal media.ccc.de; Christoph Saatjohann) :::

:::globalTitle{:size="lg" .mb-5} TECHNISCHE BETRACHTUNG DER EGK ::: :::globalParagraph Vor der Implementierung eines Python Skripts zum Auslesen der Gesundheitskarte sollte ein Verständnis über die technischen Grundlagen entwickelt werden. Betrachtet werden also die physische Karte sowie die Datenstrukturen auf dem Chip selbst. :::

:::globalTitle{:size="md" .mb-5} ÄUSSERLICHKEITEN ::: :::globalParagraph Die elektronische Gesundheitskarte ist eine einfache Chipkarte, eine sogenannte „Smart Card“ oder ICC (Integrated Circuit Card). Neben dem Chip sind Informationen über den Karteninhaber auf die Oberfläche gedruckt. ::: :::globalParagraph Ein weitere interessante Information stellt das kleine „G2“ in der oberen rechten Ecke der Karte da. Dieses steht für „Generation 2“ und stellt somit die Version der Karte dar. Darüber hinaus befindet sich auf der Vorderseite sichtbar der Chip, auf welchem alle Daten gespeichert sind. ::: :::globalParagraph So sieht beispielsweise eine Vorderseite und eine Rückseite aus: :::

{.object-cover .max-w-full .mb-5}

:::globalParagraph Auf der Rückseite findet man den Namen des Besitzers, den Firmennamen der Versicherung, eine Kennziffer für Besitzer und eine für die Karte, sowie das Geburtsdatum des Besitzers und das Ablaufdatum der Karte. :::

:::globalTitle{:size="lg" .mb-5} DATEN AUF DER EGK ::: :::globalParagraph Wie bereits erwähnt handelt es sich im eine sogenannte „Smart Card“. Diese werden hauptsächlich als ROM (Read Only Memory) verwendet - also um Zugriff auf Daten zu geben, nicht jedoch um neu beschrieben zu werden. Die elektronische Gesundheitskarte ist jedoch nicht nur als ROM ausgelegt, sondern kann auch neu beschrieben werden, beispielsweise um die Versicherungsstammdaten des Besitzers zu aktualisieren (z. B. bei Umzug oder nach Namensänderung). ::: :::globalParagraph Daten auf der eGK sind hierarchisch abgelegt. Dabei wird in Verzeichnisse (DF) und Datenspeicher (EF) unterschieden. Interessant ist an dieser Stelle vorrangig das Verzeichnis HCA (Health Care Application). In diesem befinden sich die Datenspeicher PD (persönliche Versichertendaten) und VD (Versicherungsdaten). (Quelle: Fachportal gematik ) ::: :::globalParagraph Neben diesen sind noch weitere Datenspeicher und Verzeichnisse verfügbar - diese sind hervorragend in einem Artikel des Fraunhofer-Instituts für offene Kommunikationssysteme erklärt: BMG AsK :::

{.object-cover .max-w-full .mb-5}

:::globalTitle{:size="lg" .mb-5} DATEN VON SMART CARDS LESEN ::: :::globalParagraph Um Daten von einer Smart Card zu lesen, benötigt man zunächst ein Kartenlesegerät. Man benötigt jedoch kein spezielles Lesegerät für die Gesundheitskarte - eine kurze Suche im Internet nach einem „Chipkartenleser“ oder einem „Smart Card Reader“ liefert viele Ergebnisse. ::: :::globalParagraph Die Kommunikation zwischen dem Lesegerät und der Karte erfolgt mittels APDU (Application Protocol Data Unit). Die Struktur von APDU ist in der Norm ISO/IEC 7816-4 definiert. Man unterscheidet zwischen Command APDU und Response APDU. :::globalParagraph Command APDU übertragen ein Kommando oder einen Befehl von dem Kartenlesegerät an die Chipkarte. Dieser besteht aus einem Header und einem optionalen Body. Response APDU dienen als Antwort der Karte auf ein Command APDU. Dieser besteht wiederum aus einem Trailer und einem optionalen Body. Der Aufbau im Detail ist im folgenden Wikipedia Artikel gut erklärt: Application Protocol Data Unit – Wikipedia :::

:::globalTitle{:size="lg" .mb-5} AUSLESEN VIA PYTHON SKRIPT ::: :::globalParagraph Zum Auslesen der elektronischen Gesundheitskarte wird ein Kartenlesegerät sowie ein funktionstüchtiger Python Interpreter benötigt. Zudem legen wir uns den „Implementierungsleitfaden zur Einbindung der eGK in die Primärsysteme der Leistungserbringer“ der gematik parat: Fachportal gematik :::

:::globalTitle{:size="lg" .mb-5} APDU VIA PYTHON ::: :::globalParagraph Sucht man nach Paketen, um APDU Kommandos via Python abzusetzen oder mit Smart Cards zu kommunizieren, kommt man nicht an dem Paket pyscard Python Smart Card Library vorbei. Die Bibliothek ermöglicht uns genau das, was wir wollen - via Python APDU Kommandos abzusenden und zu empfangen. Also erstellen wir ein virtuelle Umgebung (VirtualEnv) und installieren das Paket dort. ::: :::BlogCode{.mb-5}

virtualenv -p python3 ~/egk
pip3 install pyscard

::: :::globalParagraph Nach der Installation erzeugen wir eine Python Datei - /egk.py/: ::: :::BlogCode{.mb-5}

touch egk.py

::: :::globalParagraph In dieser wird nun der Code zum Auslesen der Karte untergebracht. Als erstes gilt es nun die Verbindung zu Lesegerät herzustellen ::: :::BlogCode{.mb-5}

from smartcard.System import readers

::: :::BlogCode{.mb-5}

class HealthCardReader:
    def init(self):
        r = readers()
        if len(r) < 1:
        raise Exception('No reader found.')
        self.reader = r[0]
        self.connection = self.reader.createConnection()

        self.connection.connect()

healthcard_reader = HealthCardReader()

::: :::globalParagraph An dieser Stelle nutzen wir die 'readers' Funktion der pyscard-Bibliothek. Sie gibt uns eine Liste von verfügbaren Kartenlesegeräten zurück. Sollte keines verfügbar sein, wird eine Exception ausgelöst. Ansonsten erhält unser 'HealthCardReader' Objekt eine 'connection'. Mithilfe dieser können wir nun Command APDUs an die Karte übertragen: ::: :::BlogCode{.mb-5}

...
healthcard_reader = HealthCardReader()
healthcard_reader.connection.transmit(apdu)

:::

:::globalTitle{:size="lg" .mb-5} DAS WEITERE VORGEHEN ERGIBT SICH AUS DER SPEZIFIKATION DER GEMATIK: ::: :::globalParagraph Dieses Diagramm stellt den Programmablauf zum Auslesen von persönlichen Daten bzw. Versicherungsdaten dar. :::

{.object-cover .max-w-full .mb-5}

:::globalParagraph Die entsprechenden APDU- Kommandos können ebenfalls aus der Spezifikation entnommen werden: :::

:::BlogCode{.mb-5}

COMMANDS = {
    'SELECT_MF': [0x00, 0xA4, 0x04, 0x0C, 0x07, 0xD2, 0x76, 0x00, 0x01, 0x44, 0x80, 0x00],
    'SELECT_HCA': [0x00, 0xA4, 0x04, 0x0C, 0x06, 0xD2, 0x76, 0x00, 0x00, 0x01, 0x02],
    'EF_VERSION_1': [0x00, 0xB2, 0x01, 0x84, 0x00],
    'EF_VERSION_2': [0x00, 0xB2, 0x02, 0x84, 0x00],
    'EF_VERSION_3': [0x00, 0xB2, 0x03, 0x84, 0x00],
    'SELECT_FILE_PD': [0x00, 0xB0, 0x81, 0x00, 0x02],
    'SELECT_FILE_VD': [0x00, 0xB0, 0x82, 0x00, 0x08]
}

::: :::globalParagraph Die Begriffe Root und MF (Masterfile) können hier als äquivalent angesehen werden. Zuerst erweitern wir unsere Klasse um ein paar Utilities: :::

:::BlogCode{.mb-5}

class HealthCardReader:
    def init(self):
        r = readers()
        if len(r) < 1:
        raise Exception('No reader found.')
        self.reader = r[0]
        self.connection = self.reader.createConnection()
        self.connection.connect()

  def create_read_command(self, pos, length):
    bpos = [pos >> 8 & 0xFF, pos & 0xFF]
    return [0x00, 0xB0, bpos[0], bpos[1], length]

    def read_file(self, offset, length):
    data = []
    max_read = 0xFC
    pointer = offset
    while len(data) < length:
        bytes_left = length - len(data)
        readlen = bytes_left if bytes_left < max_read else max_read
        data_chunk = self.run_command(self.create_read_command(pointer, readlen))
        pointer += readlen
        data.extend(data_chunk)
    return data

    def run_command(self, apdu):
        data, sw1, sw2 = self.connection.transmit(adpu)
        if (sw1, sw2) == (0x90, 0x00):
            return data
        raise Exception('Bad Status')

::: :::globalParagraph Mithilfe der neuen Utils können wir bequem Kommandos absetzen und Dateien von der Karte lesen. 'create_read_command' erlaubt es uns ein Command APDU zu erstellen, um einen bestimmten Bereich einer Datei zu lesen. 'read_file' wiederum erlaubt es uns eine komplette Datei auszulesen. 'run_command' erlaubt es uns jedes mal automatisch zu testen, ob unser Kommando erfolgreich war und wenn dies der Fall ist, das Ergebnis zurückzugeben. Nun können wir loslegen, um die Version der Karte zu erkennen und die PD auszulesen: :::

:::BlogCode{.mb-5}

healthcard_reader = HealthCardReader()
healthcard_reader.run_command(COMMANDS['SELECT_MF'])
ef_v_1 = healthcard_reader.run_command(COMMANDS['EF_VERSION_1'])
ef_v_2 = healthcard_reader.run_command(COMMANDS['EF_VERSION_2'])
ef_v_3 = healthcard_reader.run_command(COMMANDS['EF_VERSION_3'])

if ef_v_1 == '3.0.0' and ef_v_2 == '3.0.0' and ef_v_3 == '3.0.2':
    generation = 'G1'
elif ef_v_1 == '3.0.0' and ef_v_2 == '3.0.1' and ef_v_3 == '3.0.3':
    generation = 'G1 plus'
elif ef_v_1 == '4.0.0' and ef_v_2 == '4.0.0' and ef_v_3 == '4.0.2':
    generation = 'G2'

# Selektieren der PD
healthcard_reader.run_command(COMMANDS['SELECT_HCA'])
healthcard_reader.run_command(COMMANDS['SELECT_FILE_PD'])

# Auslesen der ersten beiden Bytes - diese enthalten die Länge der PD
data = healthcard_reader.run_command(healthcard_reader.create_read_command(0x00, 0x02))
pd_length = (data[0] << 8) + data[1]
# Abziehen der ersten beiden Bytes
pd_length -= 0x02

# Nochmaliges Selektieren der PD
healthcard_reader.run_command(COMMANDS['SELECT_MF'])
healthcard_reader.run_command(COMMANDS['SELECT_HCA'])
healthcard_reader.run_command(COMMANDS['SELECT_FILE_PD'])

# Auslesen der komprimierten Daten nach den ersten beiden Bytes, mit der emittelten Länge
patient_data_compressed =  healthcard_reader.read_file(0x02, pd_length)

:::

:::globalTitle{:size="lg" .mb-5} ENTPACKEN DER DATEN MIT PYTHON-STANDARDFUNKTIONEN ::: :::globalParagraph Nachdem Rohdaten von der Karte extrahiert sind müssen diese noch entpackt werden, da diese aktuell noch via gzip komprimiert vorliegen. ::: :::BlogCode{.mb-5}

# Vorbeugen von zlib.error (truncated stream)
patient_data_compressed.extend([0x00] * 16)
patient_data_compressed = bytearray(patient_data_compressed)
patient_data_compressed = bytes(patient_data_compressed)
# Dekomprimieren der Rohdaten
patient_data_xml = zlib.decompress(patient_data_compressed, 15 + 16)

::: :::globalParagraph Damit liegen die persönlichen Daten des Patienten im XML-Format vor. Diese können nun nach belieben via 'lxml' oder einer anderen XML-Bibliothek verarbeitet werden. :::

:::globalTitle{:size="lg" .mb-5} BLUESHOE VERÖFFENTLICHT PYTHON-HEALTHCARD ::: :::globalParagraph Alle Erfahrungen, die wir als Blueshoe während unserer Arbeit mit der elektronischen Gesundheitskarte gemacht haben sowie alle zu beachtenden Tücken, haben wir in einem Paket zum Auslesen der elektronischen Gesundheitskarte zusammengefasst. Das Paket python-healthcard ist OpenSource aus dem Hause Blueshoe und wird auch fortlaufend betreut. Damit habt ihr vielleicht genau die Hilfe, die ihr in eurem nächsten Software-Entwicklungsprojekt braucht. ::: :::globalParagraph python-healthcard gewährt dem Benutzer Zugang zu den persönlichen Daten sowie den Versicherungsdaten, welche auf einer eGK gespeichert sind. In unserem Projekt “Ofa Smart Scan” - einem digitalen Körperscanner für den Sanitätsfachhandel - findet die python-healthcard aktuell bereits Anwendung. Die Technologie erlaubt es, neue Kunden eines Sanitätshauses mitsamt ihrer persönlichen Daten innerhalb von Sekunden anzulegen und direkt einen Messvorgang für beispielsweise Kompressionsstrümpfe anzustoßen. ::: :::globalParagraph Wir freuen uns über Verbesserungsvorschläge, Lob und Kritik - gerne via GitHub oder per Mail an healthcard@blueshoe.de{.bs-link-blue} :::

In diesem Artikel erklären wir, welche Informationen Designer bereitstellen sollten, damit Entwickler Frontend-Projekte effizient und präzise umsetzen können. Basierend auf unseren Erfahrungen aus zahlreichen Kundenprojekten haben wir die häufigsten Probleme identifiziert und zeigen, wie sie vermieden werden können.

:GlobalDesignHandoffChecklist

Warum ein durchdachter Design-Handoff so wichtig ist

Das Problem: Unvollständige Design-Dokumentation

In vielen Projekten erhalten Entwickler Design-Dateien, die zwar visuell ansprechend sind, aber wichtige technische Details vermissen lassen. Das führt zu Situationen, in denen Entwickler selbst entscheiden müssen, wie Komponenten in verschiedenen Zuständen aussehen sollen, welche Breakpoints verwendet werden oder wie die Mobile-Navigation funktionieren soll.

Die Folgen:

• Verzögerungen durch Rückfragen und Klärungsbedarf
• Inkonsistenzen zwischen Design und Umsetzung
• Mehraufwand durch nachträgliche Anpassungen
• Frustration auf beiden Seiten – Designer und Entwickler

Die Lösung: Strukturierter Design-Handoff

Ein strukturierter Design-Handoff ist mehr als nur das Teilen einer Figma-Datei. Es ist eine umfassende Dokumentation, die alle Aspekte der visuellen und interaktiven Gestaltung abdeckt. Entwickler sollten in der Lage sein, das Design zu verstehen und umzusetzen, ohne ständig nachfragen zu müssen.

Alternative Ansatz: Vorgefertigte Design-Systeme verwenden

Eine Alternative zu individuellen Designs ist die Verwendung vorgefertigter Design-Systeme oder UI-Komponenten-Bibliotheken. Diese Systeme bieten fertige Komponenten, die Entwickler mit Design-Tokens (Farben, Typography, Spacing) anpassen können. Ein Beispiel ist ein Framework wie Flowbite{target="_blank"}, das Figma-Design-Dateien bereitstellt, die Designer anpassen können, sodass Entwickler vertraute UI-Bibliotheken nutzen können.

Wann vorgefertigte Design-Systeme sinnvoll sind:

• Das Team hat sich auf eine spezifische UI-Bibliothek geeinigt
• Das Projekt kann innerhalb der Grenzen des Design-Systems arbeiten
• Entwickler sind bereits mit dem gewählten Framework vertraut
• Time-to-Market ist kritisch und Anpassungsbedarf ist minimal

Die Realität: In der Praxis kennen jedoch viele Designer diese Frameworks nicht oder arbeiten mit kundenspezifischen, markenspezifischen Designs, die nicht mit Standard-Systemen übereinstimmen. Viele Projekte erfordern einzigartige visuelle Identitäten, die über das hinausgehen, was vorgefertigte Systeme bieten.

Der beste Ansatz: Idealerweise sollten Designer und Entwickler frühzeitig abstimmen, ob ein vorgefertigtes Design-System verwendet oder individuelle Designs erstellt werden sollen. Wenn ein Framework gewählt wird, können Designer darauf aufbauen und die Design-Tokens anpassen. Wenn individuelle Designs erstellt werden, ist ein vollständiger Handoff mit allen in diesem Artikel beschriebenen Informationen für eine präzise Umsetzung unerlässlich.

Dieser Artikel fokussiert auf das Szenario, in dem Designer individuelle Designs liefern – in diesen Fällen benötigen Entwickler eine umfassende Dokumentation, um das Design präzise umzusetzen.

Die essentiellen Bestandteile eines Design-Handoffs

1. Farbpalette: Die Grundlage der visuellen Identität

Eine vollständige Farbpalette ist fundamental für jede Frontend-Umsetzung. Sie sollte nicht nur die Grundfarben enthalten, sondern auch alle Varianten, die im Projekt verwendet werden.

Was eine vollständige Farbpalette enthalten sollte:

• Primärfarben mit allen Varianten (hell, dunkel, gesättigt)
• Sekundärfarben für Akzente und Highlights
• Neutrale Farben für Hintergründe, Texte und Borders
• Zustandsfarben für Hover, Fokus, Disabled, Error, Success
• Hex-Werte oder CSS-Variablen für direkte Umsetzung

Beispiel-Struktur einer Farbpalette:

/* Primärfarben */
--color-primary: #0066CC;
--color-primary-hover: #0052A3;
--color-primary-light: #E6F2FF;
--color-primary-dark: #004080;

/* Sekundärfarben */
--color-secondary: #FF6B35;
--color-secondary-hover: #E55A2B;

/* Neutrale Farben */
--color-background: #FFFFFF;
--color-surface: #F5F5F5;
--color-text: #1A1A1A;
--color-text-light: #666666;
--color-border: #E0E0E0;

/* Zustandsfarben */
--color-error: #DC3545;
--color-success: #28A745;
--color-warning: #FFC107;
--color-info: #17A2B8;
--color-disabled: #CCCCCC;

Warum das wichtig ist: Ohne eine vollständige Farbpalette müssen Entwickler Farbwerte erraten oder selbst definieren, was zu Inkonsistenzen führt. Eine präzise Farbpalette ermöglicht eine konsistente Umsetzung und erleichtert spätere Wartung und Anpassungen.

2. Komponenten mit verschiedenen Zuständen

Komponenten sind das Herzstück jeder Frontend-Anwendung. Für eine präzise Umsetzung benötigen Entwickler nicht nur das Standard-Design, sondern alle Zustände und Varianten einer Komponente.

Zustände, die dokumentiert sein sollten:

• Default: Der Standard-Zustand der Komponente
• Hover: Wie sieht die Komponente beim Darüberfahren aus?
• Fokus: Wie wird der Fokus visuell dargestellt (wichtig für Accessibility)?
• Active: Der Zustand während einer Interaktion
• Disabled: Wie sieht die deaktivierte Variante aus?
• Error: Fehlerzustände mit entsprechenden visuellen Hinweisen
• Success: Erfolgszustände für Bestätigungen

Zusätzliche Varianten:

• Größen: Small, Medium, Large
• Farbvarianten: Primary, Secondary, Tertiary
• Layout-Varianten: Mit/ohne Icon, verschiedene Textlängen
• Kontext-Varianten: In verschiedenen Umgebungen (Header, Footer, Modal)

Beispiel: Button-Komponente

Eine vollständig dokumentierte Button-Komponente sollte folgende Varianten enthalten:

Button Primary
├── Default (Hintergrund: Primärfarbe, Text: Weiß)
├── Hover (Hintergrund: Primärfarbe dunkler, Cursor: Pointer)
├── Fokus (Outline: 2px solid Fokusfarbe, Outline-Offset: 2px)
├── Active (Hintergrund: Primärfarbe noch dunkler)
├── Disabled (Hintergrund: Grau, Opacity: 0.6, Cursor: not-allowed)
└── Loading (Spinner-Icon, Text: "Wird geladen...")

Button Secondary
├── Default (Hintergrund: Transparent, Border: Primärfarbe)
├── Hover (Hintergrund: Primärfarbe hell, Text: Primärfarbe)
└── [weitere Zustände...]

Größen
├── Small (Padding: 8px 16px, Font-Size: 14px)
├── Medium (Padding: 12px 24px, Font-Size: 16px)
└── Large (Padding: 16px 32px, Font-Size: 18px)

Warum das wichtig ist: Fehlende Zustandsdefinitionen führen dazu, dass Entwickler selbst entscheiden müssen, wie Komponenten in verschiedenen Situationen aussehen. Das führt zu Inkonsistenzen und kann die User Experience beeinträchtigen.

3. Typography: Mehr als nur Schriftarten

Typography ist ein zentraler Bestandteil des Designs, der oft unterschätzt wird. Eine vollständige Typography-Dokumentation sollte alle Textstile enthalten, die im Projekt verwendet werden.

Was eine Typography-Dokumentation enthalten sollte:

• Schriftfamilien: Welche Fonts werden verwendet (Web-Fonts, System-Fonts)?
• Schriftgrößen: Alle verwendeten Font-Sizes mit entsprechenden Line-Heights
• Schriftgewichte: Regular, Medium, Bold, etc.
• Textstile: Headings (H1-H6), Body-Text, Captions, Labels
• Responsive Typography: Wie ändern sich Schriftgrößen auf verschiedenen Breakpoints?
• Farbzuordnungen: Welche Textfarbe wird in welchem Kontext verwendet?

Beispiel-Typography-System:

/* Headings */
--font-heading-1: 48px / 56px, Bold, 'Inter', sans-serif;
--font-heading-2: 36px / 44px, Bold, 'Inter', sans-serif;
--font-heading-3: 28px / 36px, SemiBold, 'Inter', sans-serif;
--font-heading-4: 24px / 32px, SemiBold, 'Inter', sans-serif;
--font-heading-5: 20px / 28px, Medium, 'Inter', sans-serif;
--font-heading-6: 18px / 24px, Medium, 'Inter', sans-serif;

/* Body Text */
--font-body-large: 18px / 28px, Regular, 'Inter', sans-serif;
--font-body: 16px / 24px, Regular, 'Inter', sans-serif;
--font-body-small: 14px / 20px, Regular, 'Inter', sans-serif;

/* Special */
--font-caption: 12px / 16px, Regular, 'Inter', sans-serif;
--font-label: 14px / 20px, Medium, 'Inter', sans-serif;
--font-button: 16px / 24px, Medium, 'Inter', sans-serif;

Warum das wichtig ist: Typography beeinflusst Lesbarkeit, Hierarchie und Gesamterscheinung einer Website erheblich. Unklare Typography-Definitionen führen zu inkonsistenten Textdarstellungen und können die User Experience negativ beeinflussen.

4. Breakpoints: Die Basis für responsive Design

Responsive Design ist heute Standard, aber viele Designer liefern nur 2-3 Breakpoints, obwohl 6 Breakpoints für eine präzise Umsetzung optimal wären. Wir empfehlen die Verwendung der Bootstrap-Standard-Breakpoints als Basis, da sie eine bewährte und konsistente Grundlage für responsive Layouts bieten.

Bootstrap-Standard-Breakpoints (empfohlen):

• Extra Small (xs): <576px (kleine Smartphones im Hochformat)
• Small (sm): ≥576px (große Smartphones im Querformat)
• Medium (md): ≥768px (Tablets)
• Large (lg): ≥992px (Standard-Desktops)
• Extra Large (xl): ≥1200px (große Desktops)
• Extra Extra Large (xxl): ≥1400px (sehr große Bildschirme)

Was für jeden Breakpoint dokumentiert sein sollte:

• Layout-Änderungen: Wie ändert sich das Grid-System?
• Komponenten-Anpassungen: Welche Komponenten werden anders dargestellt?
• Navigation: Wie funktioniert die Navigation auf verschiedenen Bildschirmgrößen?
• Typography: Wie ändern sich Schriftgrößen?
• Spacing: Wie ändern sich Abstände zwischen Elementen?

Beispiel-Breakpoint-Dokumentation (Bootstrap-Standard):

Extra Small (xs) - <576px
├── Navigation: Hamburger-Menü, Full-Screen Overlay
├── Grid: 1 Spalte, Padding: 16px
├── Typography: H1: 32px, Body: 14px
└── Komponenten: Stack-Layout, volle Breite

Small (sm) - ≥576px
├── Navigation: Hamburger-Menü, Side-Drawer
├── Grid: 1-2 Spalten, Padding: 20px
├── Typography: H1: 36px, Body: 15px
└── Komponenten: Angepasstes Layout, größere Touch-Targets

Medium (md) - ≥768px
├── Navigation: Hamburger-Menü, Side-Drawer oder kompaktes Menü
├── Grid: 2 Spalten, Padding: 24px
├── Typography: H1: 40px, Body: 16px
└── Komponenten: 2-Spalten-Layout möglich

Large (lg) - ≥992px
├── Navigation: Horizontales Menü, Dropdowns
├── Grid: 12 Spalten, Padding: 32px
├── Typography: H1: 48px, Body: 16px
└── Komponenten: Flex-Layout, verschiedene Breiten

Extra Large (xl) - ≥1200px
├── Navigation: Horizontales Menü mit erweiterten Features
├── Grid: 12 Spalten, max-width Container, Padding: 40px
├── Typography: H1: 48px, Body: 16px
└── Komponenten: Optimiertes Layout für große Bildschirme

Extra Extra Large (xxl) - ≥1400px
├── Navigation: Horizontales Menü, erweiterte Navigation
├── Grid: 12 Spalten, max-width Container, Padding: 48px
├── Typography: H1: 52px, Body: 18px
└── Komponenten: Maximale Breiten, optimierte Abstände

Warum das wichtig ist: Zu wenige Breakpoints führen zu Kompromissen bei der Umsetzung. Entwickler müssen dann selbst entscheiden, wie das Layout auf Bildschirmgrößen aussehen soll, die nicht im Design definiert sind. Die Verwendung der Bootstrap-Standard-Breakpoints bietet mehrere Vorteile: Sie sind bewährt, gut dokumentiert und werden von vielen Entwicklern bereits verstanden. Zudem ermöglichen sie eine konsistente Umsetzung, besonders wenn Bootstrap oder ähnliche Frameworks verwendet werden. Mehr Breakpoints bedeuten mehr Kontrolle und präzisere Umsetzung über alle Geräteklassen hinweg.

5. Abstände zwischen Komponenten: Das unsichtbare Design-Element

Spacing ist ein fundamentales Design-Element, das oft übersehen wird. Konsistente Abstände schaffen visuelle Hierarchie und verbessern die Lesbarkeit.

Was dokumentiert sein sollte:

• Spacing-System: Ein konsistentes Spacing-System (z.B. 4px, 8px, 16px, 24px, 32px, 48px, 64px)
• Komponenten-Abstände: Spezifische Abstände zwischen verschiedenen Komponenten
• Container-Padding: Innenabstände von Containern und Sections
• Responsive Spacing: Wie ändern sich Abstände auf verschiedenen Breakpoints?

Beispiel-Spacing-System:

--spacing-xs: 4px;
--spacing-sm: 8px;
--spacing-md: 16px;
--spacing-lg: 24px;
--spacing-xl: 32px;
--spacing-2xl: 48px;
--spacing-3xl: 64px;
--spacing-4xl: 96px;

Anwendungsbeispiele:

• Abstand zwischen Buttons: --spacing-md (16px)
• Abstand zwischen Sections: --spacing-3xl (64px)
• Padding in Cards: --spacing-lg (24px)
• Abstand zwischen Form-Elementen: --spacing-md (16px)

Warum das wichtig ist: Inkonsistente Abstände führen zu einem unprofessionellen Erscheinungsbild. Ein dokumentiertes Spacing-System ermöglicht konsistente Umsetzung und erleichtert die Wartung.

Die größten Herausforderungen: Navigation und Mobile-Design

Navigation mit Hover-Effekten: Ein häufiges Problem

Die Navigation ist oft einer der komplexesten Bereiche einer Website, besonders wenn Hover-Effekte und Dropdown-Menüs involviert sind. In der Vergangenheit haben wir häufig das Problem gehabt, dass viele Informationen nicht vorhanden waren oder nicht durchdacht waren.

Was bei Navigation-Designs häufig fehlt:

• Hover-Zustände: Wie sehen Hover-Effekte genau aus? Welche Animationen werden verwendet?
• Dropdown-Verhalten: Wie öffnen sich Dropdowns? Gibt es Animationen? Wie schließen sie sich?
• Mobile-Navigation: Wie funktioniert die Navigation auf mobilen Geräten? Gibt es ein Hamburger-Menü? Wie sieht das aus?
• Aktive Zustände: Wie wird der aktive Menüpunkt markiert?
• Übergänge: Welche Transitions werden verwendet?

Was eine vollständige Navigation-Dokumentation enthalten sollte:

Desktop Navigation
├── Default-Zustand
│   ├── Logo-Position und Größe
│   ├── Menüpunkt-Styling (Font, Größe, Farbe)
│   └── Abstände zwischen Menüpunkten
├── Hover-Zustand
│   ├── Hintergrundfarbe oder Unterstreichung
│   ├── Textfarbe-Änderung
│   ├── Transition-Dauer und Easing
│   └── Cursor-Änderung
├── Dropdown-Menü
│   ├── Trigger-Verhalten (Hover vs. Click)
│   ├── Dropdown-Position und Ausrichtung
│   ├── Dropdown-Styling (Hintergrund, Schatten, Border)
│   ├── Animation (Fade-in, Slide-down, etc.)
│   └── Sub-Menü-Verhalten
└── Aktiver Zustand
    ├── Visuelle Markierung
    └── Styling-Unterschiede

Mobile Navigation
├── Hamburger-Menü
│   ├── Icon-Position und Größe
│   ├── Animation beim Öffnen/Schließen
│   └── Icon-Transformation (zu X)
├── Off-Canvas-Menü
│   ├── Slide-Richtung (von links, rechts, oben)
│   ├── Hintergrund-Overlay
│   ├── Menü-Breite und Position
│   └── Animation und Transition
└── Menü-Items
    ├── Layout (Liste, Grid, etc.)
    ├── Abstände zwischen Items
    └── Touch-Target-Größen (mindestens 44x44px)

Warum das wichtig ist: Die Navigation ist oft der erste Kontaktpunkt für Nutzer. Unklare Navigation-Designs führen zu Verzögerungen in der Umsetzung und können die User Experience erheblich beeinträchtigen. Besonders problematisch ist, wenn Desktop-Designs vorhanden sind, aber Mobile-Varianten fehlen.

Mobile-Umsetzung: Oft vernachlässigt, aber kritisch

Die Mobile-Umsetzung ist einer der häufigsten Schmerzpunkte im Design-Handoff. Viele Designer liefern nur Desktop-Designs und erwarten, dass Entwickler selbst entscheiden, wie die Mobile-Variante aussehen soll.

Häufige Probleme bei Mobile-Designs:

• Fehlende Mobile-Designs: Nur Desktop-Designs werden geliefert
• Unvollständige Mobile-Designs: Einige Seiten haben Mobile-Designs, andere nicht
• Unklare Breakpoints: Es ist nicht klar, ab welcher Bildschirmgröße welche Variante verwendet wird
• Touch-Interaktionen: Keine Spezifikationen für Touch-Gesten und Interaktionen
• Performance: Keine Berücksichtigung von Ladezeiten und Performance auf mobilen Geräten

Was eine vollständige Mobile-Dokumentation enthalten sollte:

• Mobile-First-Ansatz: Designs für kleine Bildschirme zuerst
• Touch-Targets: Mindestgrößen für klickbare Elemente (44x44px)
• Navigation: Detaillierte Mobile-Navigation-Designs
• Komponenten-Anpassungen: Wie sehen Komponenten auf Mobile aus?
• Layout-Änderungen: Welche Layout-Änderungen sind auf Mobile nötig?
• Interaktionen: Touch-Gesten, Swipe-Verhalten, etc.

Beispiel-Mobile-Spezifikationen:

Mobile Navigation
├── Hamburger-Menü
│   ├── Position: Top-Left oder Top-Right
│   ├── Größe: 44x44px (Touch-Target)
│   ├── Icon: 3 Linien, Animation zu X beim Öffnen
│   └── Z-Index: Über allen anderen Elementen
├── Off-Canvas-Menü
│   ├── Slide-Richtung: Von links
│   ├── Breite: 80% der Bildschirmbreite, max. 320px
│   ├── Hintergrund: Weiß mit Schatten
│   ├── Overlay: Dunkler Hintergrund mit 50% Opacity
│   └── Animation: 300ms ease-in-out
└── Menü-Items
    ├── Layout: Vertikale Liste
    ├── Padding: 16px pro Item
    ├── Font-Size: 18px (größer für bessere Lesbarkeit)
    └── Touch-Target: Mindestens 44px Höhe

Mobile Komponenten
├── Buttons: Volle Breite oder angepasste Größe
├── Forms: Stack-Layout, größere Input-Felder
├── Cards: Volle Breite, angepasste Padding
└── Images: Responsive, optimiert für Mobile

Warum das wichtig ist: Mobile-Nutzung übersteigt in vielen Projekten die Desktop-Nutzung. Fehlende Mobile-Designs führen zu Verzögerungen, da Entwickler selbst entscheiden müssen, wie die Mobile-Variante aussehen soll. Eine gründliche Mobile-Umsetzung ist essentiell für den Projekterfolg.

Best Practices für einen erfolgreichen Design-Handoff

1. Strukturierte Figma-Datei

Eine gut organisierte Figma-Datei erleichtert die Arbeit erheblich. Entwickler sollten schnell finden können, was sie suchen.

Empfohlene Struktur:

Design System
├── Colors
│   ├── Primary
│   ├── Secondary
│   ├── Neutrals
│   └── States
├── Typography
│   ├── Headings
│   ├── Body
│   └── Special
├── Components
│   ├── Buttons (alle Zustände)
│   ├── Forms
│   ├── Cards
│   └── Navigation
├── Spacing
│   └── Spacing System
├── Breakpoints
│   └── Responsive Guidelines
└── Pages
    ├── Desktop
    │   ├── Homepage
    │   ├── About
    │   └── Contact
    └── Mobile
        ├── Homepage
        ├── About
        └── Contact

2. Kommentare und Anmerkungen

Kommentare in Figma können wichtige Kontextinformationen liefern, die im Design nicht offensichtlich sind.

Was kommentiert werden sollte:

• Interaktionen: Wie funktionieren Hover-Effekte, Animationen, etc.?
• Zustände: Welche Zustände gibt es und wann werden sie verwendet?
• Breakpoints: Ab welcher Bildschirmgröße ändert sich das Layout?
• Spezielle Anforderungen: Accessibility-Features, Performance-Überlegungen, etc.

3. Export-Optionen

Entwickler benötigen Assets in verschiedenen Formaten und Größen. Eine klare Export-Strategie spart Zeit.

Empfohlene Export-Formate:

• Icons: SVG (skalierbar, kleine Dateigröße)
• Bilder: WebP oder optimiertes JPG/PNG
• Logos: SVG für Vektorgrafiken, PNG für Rastergrafiken
• Farben: Hex-Werte oder CSS-Variablen

Häufige Fehler und wie man sie vermeidet

Fehler 1: Nur Desktop-Designs liefern

Problem: Viele Designer liefern nur Desktop-Designs und erwarten, dass Entwickler die Mobile-Variante selbst entwickeln.

Lösung: Immer Mobile-Designs mitliefern, mindestens für die wichtigsten Seiten. Wenn Zeit knapp ist, zumindest die Navigation und Hauptkomponenten auf Mobile designen.

Fehler 2: Fehlende Zustandsdefinitionen

Problem: Komponenten werden nur im Default-Zustand gezeigt, Hover, Fokus und andere Zustände fehlen.

Lösung: Alle Zustände dokumentieren. Wenn Zeit knapp ist, zumindest die wichtigsten Zustände (Hover, Fokus, Disabled) definieren.

Fehler 3: Unklare Breakpoints

Problem: Es ist nicht klar, ab welcher Bildschirmgröße welche Variante verwendet wird.

Lösung: Breakpoints explizit definieren und dokumentieren. Kommentare in Figma verwenden, um Breakpoint-Änderungen zu markieren.

Fehler 4: Inkonsistente Spacing

Problem: Abstände werden "nach Gefühl" gesetzt, ohne konsistentes System.

Lösung: Ein Spacing-System definieren und konsequent anwenden. Dies kann auch nachträglich dokumentiert werden.

Fehler 5: Fehlende Navigation-Spezifikationen

Problem: Navigation wird nur visuell gezeigt, ohne Details zu Hover-Effekten, Dropdowns oder Mobile-Varianten.

Lösung: Navigation gründlich durchdenken und alle Interaktionen dokumentieren. Besonders Mobile-Navigation nicht vernachlässigen.

Fazit: Investition in Qualität zahlt sich aus

Ein durchdachter Design-Handoff ist eine Investition, die sich mehrfach auszahlt. Die Zeit, die Designer in die vollständige Dokumentation investieren, spart Entwicklern Wochen an Arbeit und führt zu besseren Ergebnissen.

Die wichtigsten Takeaways:

• Vollständigkeit: Alle Zustände, Varianten und Breakpoints dokumentieren
• Mobile-First: Mobile-Designs nicht vernachlässigen
• Struktur: Design-Dateien gut organisieren
• Kommunikation: Kommentare und Anmerkungen für Kontext nutzen
• Konsistenz: Design-Systeme und Spacing-Systeme definieren

Ein guter Design-Handoff ist wie eine detaillierte Landkarte – er zeigt Entwicklern nicht nur das Ziel, sondern auch alle wichtigen Wegmarken und Hindernisse auf dem Weg dorthin. Mit einer vollständigen Dokumentation können Entwickler effizient arbeiten und hochwertige Ergebnisse liefern.

Hast du Erfahrungen mit Design-Handoffs gemacht? Teile deine Erkenntnisse in den Kommentaren und lass uns wissen, welche Informationen für dich am wichtigsten sind!

:GlobalDesignHandoffChecklist

FAQ – Häufige Fragen zum Design-Handoff

1. Welche Informationen benötigen Entwickler für einen erfolgreichen Design-Handoff?

Entwickler benötigen ein durchdachtes Figma-File oder ähnliches mit Farbpaletten, Komponenten in verschiedenen Zuständen (Hover, Fokus, Disabled), Typography-Definitionen, mindestens 6 Breakpoints (Bootstrap-Standard: xs, sm, md, lg, xl, xxl), Abstände zwischen Komponenten, sowie detaillierte Navigation-Designs inklusive Mobile-Varianten. Besonders wichtig sind durchdachte Hover-Effekte und eine gründliche Mobile-Umsetzung.

2. Warum ist die Mobile-Umsetzung beim Design-Handoff so wichtig?

Die Mobile-Umsetzung ist kritisch, weil viele Designer nur Desktop-Designs liefern. Entwickler benötigen jedoch detaillierte Mobile-Varianten für Navigation, Komponenten-Layouts und Interaktionen. Fehlende Mobile-Designs führen zu Verzögerungen, da Entwickler selbst entscheiden müssen, wie Elemente auf kleinen Bildschirmen dargestellt werden sollen.

3. Wie viele Breakpoints sollten im Design definiert sein?

Im Optimalfall sollten 6 Breakpoints definiert sein, basierend auf dem Bootstrap-Standard: Extra Small (xs) <576px, Small (sm) ≥576px, Medium (md) ≥768px, Large (lg) ≥992px, Extra Large (xl) ≥1200px und Extra Extra Large (xxl) ≥1400px. Diese Breakpoints bieten eine präzise responsive Umsetzung und sind bewährt, gut dokumentiert und werden von vielen Entwicklern bereits verstanden. In der Praxis werden oft nur 2-3 Breakpoints geliefert, was zu Kompromissen bei der Umsetzung führt. Mehr Breakpoints bedeuten mehr Kontrolle über das Layout auf verschiedenen Bildschirmgrößen.

4. Was gehört zu einer vollständigen Komponenten-Dokumentation?

Eine vollständige Komponenten-Dokumentation sollte alle Zustände einer Komponente enthalten: Default, Hover, Fokus, Disabled, Active, Error und Success. Zusätzlich sollten Varianten für verschiedene Größen, Farben oder Kontexte dokumentiert sein. Dies ermöglicht Entwicklern eine präzise Umsetzung ohne Rückfragen.

5. Warum sind Hover-Effekte bei der Navigation problematisch?

Hover-Effekte bei der Navigation sind problematisch, weil sie oft nicht durchdacht sind. Entwickler benötigen klare Spezifikationen für Übergänge, Animationen, Dropdown-Verhalten und Mobile-Alternativen. Fehlende Informationen führen zu Verzögerungen und Kompromissen bei der Umsetzung.

6. Welche Rolle spielt die Farbpalette im Design-Handoff?

Die Farbpalette ist fundamental wichtig, da sie die visuelle Identität definiert. Entwickler benötigen nicht nur die Grundfarben, sondern auch Varianten für Hover-Zustände, Fehlerzustände, Erfolgsmeldungen und Disabled-Zustände. Eine vollständige Farbpalette mit Hex-Werten oder CSS-Variablen erleichtert die Umsetzung erheblich.

7. Wie sollte eine Figma-Datei für den Handoff strukturiert sein?

Eine gut strukturierte Figma-Datei sollte klare Bereiche für Design System (Farben, Typography, Komponenten), Spacing-System, Breakpoints und Seiten-Designs (Desktop und Mobile) haben. Kommentare und Anmerkungen helfen, Kontext zu vermitteln. Eine logische Ordnerstruktur erleichtert Entwicklern die Navigation.

{.object-cover .max-w-full .mb-5}

:::GlobalTitle{:size="lg" .mb-5} Einführung ::: :::GlobalParagraph Hattest du schon einmal den Drang, Code zu schreiben und ihn überall auszuführen? Wenn ja, dann hast du wahrscheinlich schon Frameworks wie React Native und Flutter ausprobiert. Und wenn nicht, dann ist dieser Beitrag genau das Richtige für dich! ::: :::GlobalParagraph In diesem Artikel werden wir uns mit der erstaunlichen und sich schnell entwickelnden Welt (fast so schnell wie die Entwicklung von JS-Frameworks) der Multiplattform-Frameworks beschäftigen. Das Vorzeigebeispiel heute: Flutter. ::: :::GlobalParagraph Ich beginne mit einer kurzen Zusammenfassung der Geschichte von Flutter und den Vorteilen. Dann leite ich über zu einem kleinen App-Beispiel, das nativ auf Linux läuft und beende den Artikel mit einer kleinen Anmerkung, warum du für dein nächstes App-Projekt zu uns kommen solltest. :::

:::GlobalButton{:url="/technologien/flutter/" :label="Erfahre mehr über unsere Flutter-Entwicklungsdienste" :color="blue" .mb-6} :::

:::GlobalTitle{:size="lg" .mb-5} Geschichte und Vorteile ::: :::GlobalParagraph Nach ersten Entwürfen bereits im Jahr 2015 wurde Flutter 2017 mit Unterstützung für Android und iOS veröffentlicht. Im Jahr 2019 kündigte das Flutter-Team Unterstützung für Web- und Desktop-Plattformen an. Seitdem sind das Flutter-Framework selbst und sein Ökosystem gewachsen und haben sich zu einer wirklich einheitlichen Erfahrung auf allen Plattformen entwickelt. Einige der jüngsten Verbesserungen sind die neue Impeller-Rendering-Engine und Webassembly-Unterstützung für Web. ::: :::GlobalParagraph{.mb-5} Flutter ist eine Neuheit in der Welt der UI-Frameworks! Es liefert Anwendungen mit einer eigenen Rendering-Engine, die Pixeldaten direkt auf dem Bildschirm ausgibt. Dies steht im Gegensatz zu vielen anderen Frameworks, die sich auf die Zielplattform verlassen, um eine Rendering-Engine bereitzustellen. Native Android-Apps sind auf das Android-SDK auf Geräteebene angewiesen, während React Native dynamisch den integrierten UI-Stack der Zielplattform nutzt. Die Kontrolle über die Rendering-Pipeline von Flutter ist ein entscheidender Faktor für die Unterstützung mehrerer Plattformen. Sie ermöglicht es Entwicklern, identischen UI-Code für alle Zielplattformen zu verwenden, was die Erstellung plattformübergreifender Anwendungen einfacher denn je macht! :::

{.mx-auto .h-48 .max-w-full}

:::GlobalParagraph{.mt-5} Darüber hinaus bietet das Framework mit einem JIT-Compiler, der Codeänderungen in Sekundenschnelle neu verarbeitet, eine hervorragende DX. Dies ermöglicht schnelles Prototyping und einfaches Ausprobieren von Funktionalitäten. ::: :::GlobalParagraph Ein weiterer Vorteil ist, dass Flutter auf der Sprache Dart aufbaut. Diese Sprache bietet eine typsichere Umgebung. Sie nutzt eine Mischung aus statischer Typprüfung und Typinferenz, wobei die Typannotationen optional sind. Der Dart-Compiler verfügt außerdem über eine eingebaute Null-Prüfung, die alle lästigen Null-/None-Fehler direkt in der IDE abfängt. ::: :::GlobalParagraph Und nicht zuletzt: Flutter hat eine großartige Community mit einer Vielzahl von Plugins, die über den eingebauten Paketmanager pub einfach genutzt werden können. :::

:::GlobalTitle{:size="lg" .mb-5} Flutter Hands-On ::: :::GlobalParagraph Für diesen Blogartikel möchte ich eine kleine ToDo-App (was denn sonst?) bauen, die nativ unter Linux läuft. Flutter hat eine sehr gute Integration mit Firebase (Googles Plattform zur einfachen Entwicklung von Apps) oder anderen ähnlichen Cloud Infrastructure as a Service (CIaaS) Produkten wie Supabase. Aber für dieses Beispiel möchte ich, dass die App eine lokale Datenbank verwendet. Nämlich eine meiner Lieblings-NoSQL-Datenbanken: ObjectBox. Sie unterstützt Dart / Flutter und ist gebaut für Geschwindigkeit. :::

:::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Flutter-Einrichtung ::: :::GlobalParagraph Bevor du mit der Entwicklung deiner Apps beginnen kannst, muss das Flutter-SDK installiert werden. Dies ist von Plattform zu Plattform unterschiedlich, aber ein guter Startpunkt ist die SDK Installations Seite{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} des Flutter Projekts. Falls du so faul bist wie ich, empfehle ich version-fox. Das ist ein SDK-Versionsmanager geschrieben in GoLang. Nach der Installation und Konfiguration von version-fox{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid}, kannst du folgende Befehle ausführen um das Flutter Plugin hinzuzufügen und das SDK zu installieren: :::

::BlogCode{.mb-5}

vfox add flutter
vfox search flutter // this will open a selection with all available flutter versions
vfox use -g flutter@{use your version here}

::

:::GlobalParagraph Nach dem Ausführen dieser Befehle kann es schon losgehen! Um zu überprüfen ob alles geklappt hat kannst du folgenden Befehl ausführen: :::

::BlogCode{.mb-5}

flutter doctor -v

::

:::GlobalParagraph Dieser Befehl wird einige Informationen über deine aktuelle Flutter Installation ausgeben. Abhängig von deiner Plattform musst du eventuell einige Entwicklungspakete installieren. Bitte konsultiere die SDK Installationsseite, um die richtigen Pakete zu finden. :::

:::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Projekt Start ::: :::GlobalParagraph Der gesamte, für dieses Projekt erstellte, Code kann in diesem Github Repository{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} gefunden werden. ::: :::GlobalParagraph Flutter hat (wie Django) Management Befehle, um schnell Projekte und andere Templates, wie Plugins zu erstellen. Folgender Befehl kann genutzt werden um ein neues Projekt mit dem Base Template zu erstellen:

:::

::BlogCode{.mb-5}

flutter create --org de.blueshoe blue_todo

:: :::GlobalParagraph Dieser Befehl kreiert ein neues Projekt mit der folgenden Ordnerstruktur in blue_todo: ::: {.mx-auto .object-cover .max-w-full}

:::GlobalParagraph Wie du sehen kannst, hat Flutter automatisch Verzeichnisse für alle unterstützten Plattformen erstellt. Wir werden nur das lib- und das linux-Verzeichnis verwenden. lib enthält den dart- und plattform unspezifischen Code, während linux den plattformspezifischen Linux Code enthält. Flutter bietet die Kommunikation mit nativen Funktionen und Bibliotheken über sogenannte „Platform-Channels“. Diese sind ein mächtiges Werkzeug, um native Funktionalität und Leistung zu nutzen. Eine Erklärung dieser würde allerdings den Rahmen dieses Artikels sprengen. Aber vielleicht kommt ja bald ein neuer Artikel dazu? :::

:::GlobalParagraph Als nächstes installieren wir ein paar Abhängigkeiten! Du kannst auf pub.dev{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} nach diesen suchen. ::: ::BlogCode{.mb-5}

flutter pub add objectbox objectbox_flutter_libs:any flutter_bloc gap intl
flutter pub add --dev build_runner objectbox_generator:any

:: :::GlobalParagraph Dadurch werden die erforderlichen ObjectBox Abhängigkeiten sowie build_runner hinzugefügt, mit dem ObjectBox Code generieren kann. Außerdem wird flutter_bloc installiert, eine Business Logic Controller (BLoC) Implementierung für Flutter. BLoC ermöglicht eine einfacheres und besseres State Management (wir kommen später darauf zu sprechen, was State Mangement genau ist). Außerdem werden die Gap- und Intl-Abhängigkeiten installiert. Gap ist ein sehr hilfreiches Widget zum Anordnen von Widgets in einer Spalte oder Zeile. Und intl ermöglicht das Formatieren eines Datums. :::

:::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .pt-10 .mb-5} Projekt Implementierung ::: :::GlobalParagraph Tauchen wir nun in den Code ein! Die Standarddatei main.dart enthält die folgende Implementierung einer Counter-App: :::

::BlogCode{.mb-5}

import 'package:flutter/material.dart';

void main() {
 runApp(const MyApp());
}

class MyApp extends StatelessWidget {
 const MyApp({super.key});

 // This widget is the root of your application.
 @override
 Widget build(BuildContext context) {
   return MaterialApp(
     title: 'Flutter Demo',
     theme: ThemeData(
       colorScheme: ColorScheme.fromSeed(seedColor: Colors.blue),
       useMaterial3: true,
     ),
     home: const MyHomePage(title: 'Flutter Demo Home Page'),
   );
 }
}

class MyHomePage extends StatefulWidget {
 const MyHomePage({super.key, required this.title});

 final String title;

 @override
 State<MyHomePage> createState() => _MyHomePageState();
}

class _MyHomePageState extends State<MyHomePage> {
 int _counter = 0;

 void _incrementCounter() {
   setState(() {
     _counter++;
   });
 }

 @override
 Widget build(BuildContext context) {
   return Scaffold(
     appBar: AppBar(
       backgroundColor: Theme.of(context).colorScheme.inversePrimary,
       title: Text(widget.title),
     ),
     body: Center(
        child: Column(
         mainAxisAlignment: MainAxisAlignment.center,
         children: <Widget>[
           const Text(
             'You have pushed the button this many times:',
           ),
           Text(
             '$_counter',
             style: Theme.of(context).textTheme.headlineMedium,
           ),
         ],
       ),
     ),
     floatingActionButton: FloatingActionButton(
       onPressed: _incrementCounter,
       tooltip: 'Increment',
       child: const Icon(Icons.add),
     ),
   );
 }
}

::

:::GlobalParagraph Dieser Code deckt alle grundlegenden Prinzipien ab, wie man eine Flutter-Anwendung erstellt. Flutter basiert auf Widgets. Widgets sind die Bausteine der Benutzeroberfläche, und alles andere (Ihre Business-Logik) wird über den State gesteuert. State macht deine Anwendung reaktiv und interaktiv. Im Flutter-Beispiel haben wir einen FloatingActionButton (FAB) (ein Widget aus der MaterialDesign-Bibliothek). Der, wenn er gedrückt wird, eine Zählervariable inkrementiert. Das Framework ist dafür verantwortlich, seinen State neu zu generieren, wenn setState aufgerufen wird, und zeigt den inkrementierten Zähler an. :::

:::GlobalParagraph Dann lass uns doch mal flutter run -d linux ausführen und schauen wie das Beispiel aussieht: :::

{.mx-auto .object-cover .max-w-full}

:::GlobalParagraph Wie im Screenshot zu sehen, habe ich den FAB 5 Mal gedrückt und die Benutzeroberfläche wurde aktualisiert, um dies anzuzeigen. Flutter zeigt auch ein schönes Debug-Banner an, damit ich weiß, dass ich die Anwendung im Debug-Modus gestartet habe. :::

:::GlobalParagraph Beginnen wir nun mit der Implementierung unserer ToDo-App! Zuerst werde ich ein neues Verzeichnis namens business_logic erstellen. Dieses Verzeichnis wird unseren Flutter BLoC-Code beherbergen. Es folgen zwei weitere Verzeichnisse namens models und components. Bei einer größeren App sieht die Verzeichnisstruktur natürlich anders aus. Aber für dieses kleine Single Page Application Projekt ist das ausreichend. Nach den Verzeichnissen fügen wir den Business Logic Code hinzu: Wir werden in diesem Beispiel ein sogenanntes Cubit verwenden. Du kannst dir ein Cubit als einen weniger komplexen BLoC vorstellen. Zuerst müssen wir die States des Cubits definieren: :::

::BlogCode{.mb-5}

// todo_state.dart
part of 'todo_cubit.bloc.dart';

sealed class TodoState extends Equatable {
  const TodoState();

  @override
  List<Object> get props => [];
}

final class TodoInitial extends TodoState {}

final class TodoLoading extends TodoState {}

final class TodoDone extends TodoState {
  final List<Todo> todos;

  const TodoDone(this.todos);

  @override
  List<Object> get props => [
        todos,
      ];
}

// in case anything goes wrong
final class TodoFailed extends TodoState {}

::

:::GlobalParagraph States sind Klassen, die vom Cubit verwendet werden, um zwischen, nun ja, seinem aktuellen State zu unterscheiden. Das Ändern des States im Cubit wird sich in der Benutzeroberfläche widerspiegeln, und du solltest für verschiedene States unterschiedliche Dinge anzeigen. ::: :::GlobalParagraph Danach können wir unser Cubit hinzufügen: :::

::BlogCode{.mb-5}

// todo_cubit.bloc.dart
import 'package:blue_todo/models/todo.dart';
import 'package:blue_todo/objectbox.g.dart';
import 'package:equatable/equatable.dart';
import 'package:flutter_bloc/flutter_bloc.dart';

part 'todo_state.dart';

class TodoCubit extends Cubit<TodoState> {
  final Box todoBox;

  TodoCubit({required this.todoBox}) : super(TodoInitial()) {
    loadTodos();
  }

  loadTodos() async {
    emit(TodoLoading());

    try {
      final todos = List<Todo>.from(await todoBox.getAllAsync());
      emit(TodoDone(todos));
    } catch (ex) {
      emit(TodoFailed());
    }
  }

  addTodo(Todo todo) async {
    final state = this.state;

    if (state is TodoDone) {
      final id = await todoBox.putAsync(todo);
      todo.id = id;
      emit(
        TodoDone(
          [
            todo,
            ...state.todos,
          ],
        ),
      );
    }
  }

  deleteTodo(Todo toDelete) async {
    final state = this.state;

    if (state is TodoDone) {
      await todoBox.removeAsync(toDelete.id);
      emit(
        TodoDone(
          state.todos.where((t) => t.id != toDelete.id).toList(),
        ),
      );
    }
  }
}

::

:::GlobalParagraph Es gibt eine Menge zu sehen, also schauen wir uns den Code Schritt für Schritt an. Beginnen wir mit dem Cubit-Konstruktor. Er wird mit der Datenbank und dem Anfangs-State TodoInitial initiert. Dies kann ein beliebiger State sein, den Du definieren kannst. Er ruft auch loadTodos auf, sobald er initialisiert ist. ::: :::GlobalParagraph loadTodos “emitted” zuerst TodoLoading, was signalisieren soll, dass wir auf Daten warten oder etwas anderes im Hintergrund tun. emit ist die Methode, um States in einem BLoC/Cubit zu ändern. Dann holt loadTodos alle Todos aus der Datenbank und gibt den State TodoDone aus. Dieser State ist besonders, weil er die Todos speichert, die wir anzeigen wollen. ::: :::GlobalParagraph Es gibt zwei weitere Methoden im Cubit: addTodo und deleteTodo. Diese Methoden dienen zum Hinzufügen bzw. Entfernen eines Todos. Beide prüfen, ob wir uns im richtigen State befinden, bevor sie ihre jeweiligen Aktionen ausführen. Wenn der State nicht stimmt, wäre es klug, eine Fehlerbehandlung hinzuzufügen oder dem Benutzer einen Hinweis zu geben, dass etwas schief gelaufen ist. ::: :::GlobalParagraph Damit ist die gesamte Logik, die wir brauchen, fertig! ::: :::GlobalParagraph Jetzt können wir den UI-Code hinzufügen. Der komplette UI Code kann hier{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} eingesehen werden. :::

:::GlobalParagraph Ansonsten ist es am wichtigsten zu verstehen, wie wir BlocProvider und BlocBuilder benutzen können, um das UI, abhängig vom TodoState, zu verändern. ::: :::GlobalParagraph Lass uns deswegen den folgenden Code-Abschnitt ansehen: :::

::BlogCode{.mb-5}

BlocBuilder<TodoCubit, TodoState>(builder: (context, state) {
  if (state is TodoInitial || state is TodoLoading) {
    return const Center(
      child: CircularProgressIndicator.adaptive(),
    );
  }

  if (state is TodoFailed) {
    return const Center(
      child: Text("Failed to load ToDo's :("),
    );
  }

  final doneState = state as TodoDone;

  if (doneState.todos.isEmpty) {
    return const Text(
      "No ToDo's added yet. Add some via the bottom right FloatingActionButton!",
    );
  }

  ...
}

:: :::GlobalParagraph Wie du sehen kannst, wird das BlocBuilder Widget verwendet, um zwischen den TodoStates zu unterscheiden. Für jeden State geben wir etwas anderes und kontextbezogenes zurück. Du kannst auch auf andere Dinge als den State prüfen, z.B. ob die Todos leer sind. ::: :::GlobalParagraph Wenn keine der vorherigen Überprüfungen erfüllt ist, werden alle Todos mit dem folgenden Codeschnipsel angezeigt: :::

::BlogCode{.mb-5}

return Expanded(
        child: ListView.separated(
          itemCount: doneState.todos.length,
          itemBuilder: (context, index) => Card(
            child: Padding(
              padding: const EdgeInsets.all(16.0),
              child: ListTile(
                title: Text(doneState.todos[index].title!),
                subtitle: Text(doneState.todos[index].description!),
                trailing: Row(
                  mainAxisSize: MainAxisSize.min,
                  children: [
                    Text(
                      "due at: ${DateFormat('dd.MM.yyyy').format(doneState.todos[index].dueDate!)}",
                    ),
                    const Gap(8.0),
                    IconButton(
                        onPressed: () => _deleteTodo(
                              context,
                              doneState.todos[index],
                            ),
                        icon: Icon(MdiIcons.trashCanOutline))
                  ],
                ),
              ),
            ),
          ),
          separatorBuilder: (context, index) => const Divider(),
        ),
      );

:: :::GlobalParagraph Expanded ist ein Widget, das dem untergeordneten Widget mitteilt, dass es den gesamten verbleibenden Platz in der Hauptachse des übergeordneten Widgets einnehmen soll. In diesem Fall sollte die zugrunde liegende ListView den gesamten verbleibenden vertikalen Platz in der übergeordneten Column einnehmen. ::: :::GlobalParagraph Die ListView hat eine Builder-Eigenschaft, die für die Erstellung von Kindern der ListView und deren Anzeige verantwortlich ist. Die Kinder bestehen im Wesentlichen aus einer ListTile, einem Widget, das eine bestimmte Struktur für seine Kinder vorgibt. Auf diese Weise kannst Du einen Titel und einen Untertitel hinzufügen, die sich automatisch und immer untereinander auf der linken Seite des Widgets befinden. Die Eigenschaft Trailing dient zum Hinzufügen von Widgets am Ende der ListTile. Hier haben wir das Fälligkeitsdatum und einen Button zum Löschen hinzugefügt. Der Lösch-Button ruft _deleteTodo auf, was wiederum die deleteTodo-Methode des Cubits aufruft, wodurch der State geändert und die Benutzeroberfläche neu gezeichnet wird. ::: :::GlobalParagraph Ein weiterer interessanter Teil des Codes ist das Hinzufügen von ToDos. Wenn Du den FloatingActionButton drückst, erscheint ein Dialog, der einige Eingaben abfragt (z.B. Titel und Beschreibung) und wenn Du auf Speichern klickst, wird das ToDo an den Cubit übertragen und in der Datenbank gespeichert. ::: :::GlobalParagraph Die speziellen Widgets BlueshoeTextfield und BlueshoeDatefield sind im Git Repository auf GitHub{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} zu finden. ::: :::GlobalParagraph Und wie sieht das alles aus? Hier einige Screenshots: :::

{.mx-auto .object-cover .max-w-full}

:::GlobalParagraph Ohne ToDo’s :::

{.mx-auto .object-cover .max-w-full}

:::GlobalParagraph Ein ToDo hinzufügen :::

{.mx-auto .object-cover .max-w-full}

:::GlobalParagraph Sobald ein ToDo hinzugefügt ist ::: :::GlobalParagraph Ich hoffe, dieses kurze Beispiel hat Dir gezeigt, dass man mit Flutter sehr schnell vielseitige und schöne Apps bauen kann! :::

:::GlobalTitle{:size="lg" .mb-5} Blueshoe x Flutter :::

:::GlobalParagraph Bei Blueshoe streben wir nach höchster Performance und Usability in unseren Anwendungen. Mit Flutter können wir dieses Versprechen halten und alle Erwartungen unserer Kunden erfüllen. :::

:::GlobalParagraph Wenn Du jemanden für Deine nächste App suchst, dann zögere nicht, kontakt mit uns aufzunehmen! :::

:::GlobalTitle{:size="lg" .mb-5} Was ist Keycloak? :::

::GlobalPodcastSection{:videoId="6b_DXrESzgY" :videoPosition="right" .mb-5} :::GlobalParagraph Keycloak{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} ist eine Open-Source IAM-Lösung, die Single Sign-On (SSO), Benutzerverwaltung und Multi-Faktor-Authentifizierung (MFA) ermöglicht. ::: :::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Vorteile für Entwickler: ::: :::GlobalBlock{.ul-disk .mb-5}

• Einfache Integration mit OAuth2, OpenID Connect & SAML
• Höchste Sicherheit mit MFA & rollenbasierter Zugriffskontrolle (RBAC)
• Skalierbar – für kleine Teams & große Unternehmen ::: :::GlobalButton{:url="/technologien/keycloak-iam-loesung/" :label="Jetzt Keycloak mit Blueshoe in dein Projekt einbinden" :color="blue" .mb-6} ::: ::

:::GlobalTitle{:size="lg" .mb-5} Keycloak Integration: So bindest du Keycloak ein :::

:::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Schritt 1: Keycloak-Server einrichten ::: :::GlobalBlock{.ul-disk .mb-5}

• Lade Keycloak als Docker-Container oder installiere es manuell.
• Erstelle eine Realm für dein Projekt.
• Lege Benutzer und Rollen im Keycloak Admin-Panel an. :::

:::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Schritt 2: Keycloak mit deiner Anwendung verbinden ::: :::GlobalBlock{.ul-disk .mb-5}

• Django{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid}: Nutze pycloak für eine einfache OAuth2-Anbindung.
• Spring Boot: Verwende den Keycloak-Adapter für Spring Security.
• Node.js: Integriere Keycloak mit passport-keycloak für Authentifizierung. :::

:::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Schritt 3: SSO & Token-Authentifizierung nutzen ::: :::GlobalBlock{.ul-disk .mb-5}

• Implementiere Single Sign-On (SSO) mit OpenID Connect.
• Nutze Access Tokens für API-Sicherheit.
• Setze Multi-Faktor-Authentifizierung (MFA) für höhere Sicherheit ein. :::

:::GlobalTitle{:size="lg" .mb-5} Best Practices für eine sichere Keycloak-Implementierung :::

:::GlobalBlock{.ul-disk .mb-5}

• SSL/TLS aktivieren: Alle Verbindungen zu Keycloak müssen verschlüsselt sein.
• Rollenbasierten Zugriff nutzen: RBAC (Role-Based Access Control) verhindert unbefugten Zugriff.
• Token-Lebensdauer begrenzen: Verhindert Missbrauch abgelaufener Authentifizierungsdaten.
• Regelmäßige Updates: Halte Keycloak auf dem neuesten Stand für maximale Sicherheit. :::

:::GlobalParagraph Tipp: Mit unserem RAPID-Framework{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} setzen wir Keycloak 35% schneller um :::

:::GlobalTitle{:size="lg" .mb-5} Praxisbeispiel: Keycloak in Aktion :::

:::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Integration in bestehende Systeme ::: :::GlobalParagraph Die Integration von Keycloak in bestehende Systeme ist unkompliziert, da es flexible API-Schnittstellen bietet und sich gut in Frameworks wie Spring Boot, Django, Node.js und viele andere Technologien integrieren lässt. Egal, ob du eine Cloud-basierte Infrastruktur oder On-Premise-Systeme betreibst, Keycloak passt sich an die Anforderungen deines Unternehmens an. Dank seiner Open-Source-Natur ist es zudem vollständig anpassbar. Zum Beispiel haben wir bei Blueshoe ein Cookie-Cutter Template{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} für die einfache Anpassung des Keycloak Themes erstellt. :::

:::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Praxisbeispiel: FondsFinanz Makler Bildungsplattform ::: :::GlobalParagraph Ein konkretes Beispiel für eine erfolgreiche Implementierung von Keycloak ist die Backoffice-Welt der FondsFinanz Makler Bildungsplattform, eine Django-basierte Kubernetes-Anwendung mit verschiedenen Services. Hier verwaltet eine zentrale Keycloak-Instanz die Authentifizierung für alle Dienste und sorgt so für eine einheitliche und sichere Benutzerverwaltung. Dieses Setup ermöglicht den Entwicklern, sich auf die Geschäftslogik zu konzentrieren, während Keycloak sich um die Sicherheit kümmert. ::: :::GlobalParagraph Hierbei spielt auch pycloak{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} eine große Rolle. Durch pycloak konnten wir Keycloak mittels des oauth2-proxy Projekts{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} nahtlos in die Django-Anwendung integrieren. :::

:::GlobalParagraph Die obige Abbildung zeigt den Flow, wie pycloak die Authentifizierung, mittels des oauth2-proxys, in der Django-Anwendung umsetzt. Die Client-Andwendung navigiert zuerst zur gewünschten Resource und wird vom oauth2-proxy abgefangen. Dieser leitet (falls die Client-Anwendung nicht bereits authentifiziert ist) den Benutzer zur Keycloak-Login-Seite weiter. Hier muss sich der Benutzer authentifizieren und kann anschließend mit dem ausgegeben Access-Token die gewünschte Anwendung aufrufen. :::

:::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Praxisbeispiel: LUMA Delikatessen ::: :::GlobalParagraph Ein weiteres Beispiel ist die LUMA Delikatessen-Website{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid}, die auf Nuxt.js und Django basiert. Hier wird Keycloak ebenfalls als zentrale Authentifizierungslösung genutzt, um die Sicherheit und Benutzerfreundlichkeit zu gewährleisten. So haben wir zum Beispiel mittels unserem keycloak-theme-template{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} die Registrierungsseite und die standardmäßig verwendeten Keycloak Felder angepasst. Unter anderem wurde die Frage nach dem Geburtsdatum hinzugefügt, um etwaige Rabattaktionen zu ermöglichen. Das ganze sieht dann so aus: ::: {height="70%"}

:::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Praxisbeispiel: LMU Munich Media Monitoring ::: :::GlobalParagraph Keycloak bietet auch eine API an, die wir für das Munich Media Monitoring{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} der LMU verwenden, um Nutzer-Accounts nach einer gewissen Zeit zum Neu-Verifizieren ihrer Email-Adresse aufzurufen. Mit der User-Profile Funktion von Keycloak haben wir zusätzliche Felder zu den Nutzer-Accounts hinzugefügt, um zu markieren wann ein Nutzer die Email-Adresse neu verifizieren muss. Ein Kubernetes Cronjob kommuniziert mit der Keycloak API, um genau diese Nutzer zu ermitteln und mit einem POST über die Keycloak API die Email-Verifizierung zurückzusetzen. Verwendet einer dieser Nutzer danach das Munich Media Monitoring, kommt automatisch die Aufforderung von Keycloak zur Verifizierung der Email-Adresse. :::

:::GlobalTitle{:size="lg" .my-5} Warum Blueshoe als Partner für deine Keycloak-Integration? ::: :::GlobalParagraph Wir sind Experten für Open-Source IAM-Lösungen{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} und helfen Unternehmen seit über 10 Jahren bei der sicheren Keycloak-Implementierung. Zudem bieten wir mit pycloak{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} eine maßgeschneiderte Lösung für Python-basierte Anwendungen. Pycloak ist ein Package, das es Entwicklern ermöglicht, Keycloak nahtlos in Python-Projekte zu integrieren. Durch diese Entwicklung ist es Blueshoe gelungen, Keycloak noch zugänglicher und anpassbarer für Entwickler zu machen. ::: :::GlobalParagraph Unsere Vorteile: ::: :::GlobalBlock{.ul-disk .mb-5}

• 35 % schnellere Umsetzung durch unser RAPID-Framework{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid}
• Maßgeschneiderte Keycloak-Integration{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} für Django{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid}, Kubernetes{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} & Co.
• Expertise in OAuth2, OpenID Connect & SAML :::

::GlobalCallAnExpert{:bg="bg-bs-blue"} #buttonBlockTitle Sichere dein IAM-Projekt mit Keycloak ::

:::GlobalTitle{:size="lg" .mb-5 .mt-8} Häufige Fragen :::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 1. Wie kann ich Keycloak in meine bestehende Anwendung integrieren? ::

::GlobalParagraph Keycloak bietet verschiedene Möglichkeiten zur Integration: :: :::GlobalBlock{.ul-disk .mb-5}

• Web-Anwendungen: Nutze die Keycloak JavaScript-Adapter oder OAuth2-Flow für sichere Anmeldungen.
• Backend-APIs{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid}: Implementiere OpenID Connect oder OAuth2 zur Token-Validierung.
• Microservices/Kubernetes{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid}: Verwende oauth2-proxy oder Keycloak als Identity-Provider für dein Cluster.
• Tipp: Die Keycloak REST-API ermöglicht eine feingranulare Benutzerverwaltung. :::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 2. Welche Authentifizierungs-Protokolle unterstützt Keycloak? ::

::GlobalParagraph Keycloak unterstützt alle gängigen Protokolle für sichere Authentifizierung: :: :::GlobalBlock{.ul-disk .mb-5}

• OAuth2 (für API-Authentifizierung{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid})
• OpenID Connect (für Webanwendungen & SSO)
• SAML (für ältere Unternehmenssysteme)
• LDAP-Integration (für bestehende Nutzerverzeichnisse)
• Tipp: Wähle das passende Protokoll je nach Anwendung – OpenID Connect ist meist die beste Wahl für Web & Mobile. :::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 3. Wie setze ich rollenbasierte Zugriffskontrolle (RBAC) mit Keycloak um? ::

::GlobalParagraph Keycloak bietet ein flexibles Rollen- und Berechtigungssystem: :: :::GlobalBlock{.ul-disk .mb-5}

• Definiere Rollen & Berechtigungen in der Keycloak-Konsole.
• Weise Rollen Nutzern oder Gruppen zu (z. B. Admin, User, Editor).
• Validiere Rollen im Code: Dein Backend kann Keycloak-Token auslesen & Berechtigungen prüfen.
• Tipp: Nutze Keycloak’s "Authorization Services", um komplexe Zugriffskontrollen zu verwalten. :::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 4. Wie kann ich Keycloak lokal für Entwicklung & Tests starten? ::

::GlobalParagraph Keycloak kann lokal per Docker oder Standalone-Modus gestartet werden: :: ::BlogCode{.mb-4}

docker run -p 8080:8080 --name keycloak -e KEYCLOAK_ADMIN=admin -e KEYCLOAK_ADMIN_PASSWORD=admin quay.io/keycloak/keycloak start-dev

:: :::GlobalBlock{.ul-disk .mb-5}

• Vorteile: Schnelles Setup für lokale Entwicklung & Tests
• Tipp: Falls du Keycloak mit PostgreSQL oder Kubernetes nutzt, konfiguriere die Datenbank entsprechend mit Umgebungsvariablen. :::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 5. Wie setze ich Single Sign-On (SSO) mit Keycloak um? ::

::GlobalParagraph Keycloak ermöglicht SSO mit OpenID Connect oder SAML: :: :::GlobalBlock{.ul-disk .mb-5}

• Richte Keycloak als Identity-Provider ein.
• Verbinde deine Anwendungen mit Keycloak über OpenID Connect.
• Nutze einen zentralen Login für mehrere Apps – Benutzer müssen sich nur einmal anmelden.
• Tipp: Falls du bestehende Nutzerkonten migrieren musst, kannst du LDAP oder eine Custom-Authentifizierung nutzen. :::

Wir werfen einen Blick in den Werkzeugkasten, erläutern Einsatzmöglichkeiten der verschiedenen Tools und geben Beispiele, welche Lösungen angeboten werden.

{.object-cover .max-w-full .mb-5}

:::globalParagraph Kubernetes ist eine Open-Source-Technologie, um containerisierte Software zu verwalten und hilft Entwicklern dabei, einzelne Anwendungen für die Endnutzer hochverfügbar zu halten. ::: :::globalParagraph Die Technologie Kubernetes kann durch Entwickler vollkommen eigenständig genutzt werden - eben um “nur” Software zu verwalten. Eine Applikation kann dann i.d.R. eigenständig auf dem Cluster ausgeführt werden. Soll diese Applikation jedoch nicht nur im Cluster ausgeführt werden, sondern auch “von außen” erreichbar sein, z.B. durch einen Endanwender, ist zusätzlich zu Kubernetes noch eine Technologie wie Ingress notwendig. Damit beginnt schon der Aufbau einer ganzen Plattform. ::: :::globalParagraph Kubernetes kann mit einer Vielzahl eigenständiger Applikationen und anderen Technologien ergänzt werden, um so eine beliebig komplexe Plattform aufzubauen, bei der Kubernetes dann ein zentraler Bestandteil ist. Solche Plattformen können ganz individuelle Entwicklungsprozesse abbilden, je nachdem, wie einzelne Teams ihre Prozesse organisieren oder welche Unternehmensanforderungen abgebildet werden sollen. ::: :::globalParagraph In diesem Text wollen wir einzelne Technologien und Applikationen, die für den Aufbau einer solchen Plattform in Frage kommen, vorstellen und erläutern. Unsere Zielgruppe dabei sind einerseits Entwickler, die noch keine Erfahrung mit Kubernetes haben, andererseits aber auch Personen, die zwar im Feld der Softwareentwicklung tätig sind, aber selbst nicht entwickeln, sondern z.B. Projekte managen. ::: :::globalParagraph Die Liste der hier vorgestellten Applikationen und Technologien stellt dabei nur eine Auswahl der Möglichkeiten für einzelne Teilbereiche dar und ist nicht abschließend. :::

:::globalTitle{:size="lg" .mb-5} Managed Cluster und Kubernetes-Distributionen ::: :::globalTitle{:size="md" :tag="h3" .mb-5} Managed Kubernetes-Cluster ::: :::globalTitle{:size="sm" :tag="h4" .mb-5} Was machen Managed Kubernetes-Cluster? ::: :::globalParagraph Wie bereits in dem Artikel Kubernetes für Anfänger{.bs-link-blue}, handelt es sich bei Kubernetes (abgekürzt auch k8s) um eine Open-Source-Technologie, die von jedem frei genutzt werden kann. Zusätzlich gibt es aber noch Anbieter von so genannten managed Kubernetes-Clustern, die für die Nutzung von Kubernetes sowohl die Infrastruktur als auch eine erste Benutzeroberfläche bereitstellen. :::

:::globalTitle{:size="sm" :tag="h4" .mb-5} Welche Manageds Kubernetes-Cluster Anbieter gibt es? ::: :::globalParagraph Die bekanntesten Anbieter für managed Kubernetes-Cluster sind Azure Kubernetes Service (AKS), Google Kubernetes Engine (GKE) and Amazon Elastic Kubernetes Service (EKS). ::: :::globalParagraph Alle Anbieter stellen für die Arbeit mit Kubernetes eine Benutzeroberfläche und weitere Services bereit. Ob einzelne Services bereits im Basispreis enthalten sind oder über Lizenzen noch weiter zugekauft werden müssen, variiert stark je nach Anbieter. ::: :::globalParagraph Im Einzelfall sollte von den Entwicklern geprüft werden, welche Services einzelne Anbieter zur Verfügung stellen und ob diese notwendig und sinnvoll sind. AKS beispielsweise stellt in der Basis-Version bereits ein gutes Logging zur Verfügung, bei EKS muss ein solches zusätzlich zur Basisversion erworben werden. :::

:::globalTitle{:size="md" :tag="h3" .mb-5} Kubernetes-Distributionen ::: :::globalTitle{:size="sm" :tag="h4" .mb-5} Was sind Kubernetes-Distributionen? ::: :::globalParagraph Die Abgrenzung zwischen Anbietern von managed Kubernetes-Clustern und Anbietern von Kubernetes Distributionen ist nicht ganz einfach. ::: :::globalParagraph Ein Kubernetes-Cluster mit den notwendigen Nodes und Pods kann vollständig autonom betrieben werden. Dazu bedarf es auch nicht der Nutzung eines managed Clusters. ::: :::globalParagraph Die im weiteren Verlauf dieses Textes beschriebenen Tools können, müssen aber nicht zwangsläufig genutzt werden, wenn man einen Kubernetes-Cluster betreibt. Durch die Nutzung dieser Tools können beliebig komplexe Plattformen erstellt werden, deren Kernstück der Kubernetes-Cluster ist. Diese Tools wollen wir im Folgenden als “Ecosystem-Tool” bezeichnen. ::: :::globalParagraph Anbieter von Kubernetes-Distributionen stellen eine bereits vordefinierte Plattform mit einzelnen Ecosystem-Tools zur Verfügung. Anbieter von managed Kubernetes-Clustern hingegen stellen demgegenüber für die Nutzung von Kubernetes “nur” die Infrastruktur und eine erste Benutzeroberfläche mit einzelnen Funktionen zur Verfügung, die um beliebige Ecosystem-Tools erweitert werden können. ::: :::globalParagraph Kubernetes-Distributionen bieten den Mehrwert, dass Entwickler diese Tools nicht selbst in den Cluster integrieren müssen. Es ist davon auszugehen, dass alle in dieser Plattform genutzten Tools untereinander und mit dem Kubernetes-Cluster aufeinander abgestimmt konfiguriert sind, automatisiert regelmäßige Updates erhalten und somit fehlerfrei ausgeführt werden. ::: :::globalParagraph Es steht den Entwicklern aber frei, diese Plattformen wiederum in einen managed Kubernetes-Cluster zu integrieren und einige Anbieter von managed Kubernetes-Clustern bieten auch bereits eine Kubernetes-Distribution an. ::: :::globalParagraph Zusammengefasst kann man also sagen, dass managed Kubernetes-Cluster ein vorgefertigtes Grundgerüst für die Arbeit mit Kubernetes zur Verfügung stellen. Kubernetes-Distributionen gehen einen Schritt weiter und liefern zusätzlich bereits integrierte Tools als Paket. :::

:::globalTitle{:size="sm" :tag="h4" .mb-5} Welche Anbieter von Kubernetes-Distributionen gibt es? ::: :::globalParagraph Die bekanntesten Anbieter für eine Kubernetes-Distribution sind wahrscheinlich Red Hat OpenShift und Rancher Kubernetes Engine (RKE). :::

{.object-cover .w-full .mb-6}

:::globalTitle{:size="lg" .mb-5} Technologien, die in einem Kubernetes-Cluster installiert werden ::: :::globalTitle{:size="md" :tag="h3" .mb-5} Kubernetes Dashboard: Das Standard-Frontend ::: :::globalTitle{:size="sm" :tag="h4" .mb-5} Was ist das Kubernetes Dashboard? ::: :::globalParagraph Beim Kubernetes Dashboard handelt es sich um ein web-basiertes User-Interface. Kubernetes Dashboard ist ein Bestandteil von Kubernetes und bietet eine Benutzeroberfläche um beispielsweise containerisierte Software auf einen Cluster zu deployen oder dessen Ressourcen zu managen. Man bekommt damit einen Überblick über alle Applikationen und Services, die in einem Cluster laufen oder kann individuelle Kubernetes Ressourcen (wie Jobs, Deployments, etc.) modifizieren. ::: :::globalParagraph Kubernetes Dashboard als Benutzeroberfläche ist aber nicht per Default in einem Cluster installiert, sondern muss explizit dafür ausgewählt werden. ::: :::globalParagraph Ein Kubernetes Cluster kann auch ohne das Kubernetes Dashboard über die Kommandozeile verwaltet und gemonitored werden. Die Bedienbarkeit wird durch das Dashboard aber wesentlich vereinfacht. :::

:::globalTitle{:size="sm" :tag="h4" .mb-5} Welche Tools gibt es? ::: :::globalParagraph Das Kubernetes Dashboard ist das Standard-Frontend für einen Kubernetes-Cluster. Alternativ bieten auch Anbieter von managed Clustern wie AKS oder GKE ein eigenes Dashboard an. :::

:::globalTitle{:size="md" :tag="h3" .mb-5} Kommandozeilentool: Technologien, um mit einem Cluster zu kommunizieren ::: :::globalTitle{:size="sm" :tag="h4" .mb-5} Was sind Kommandozeilentools? ::: :::globalParagraph Einen Cluster muss man sich zwar als eigenständiges, in sich abgeschlossenes Gebilde vorstellen, aber unabhängig von seiner Umgebung ist ein Cluster dennoch nicht. Ein Cluster macht nur das, was ihm als Kommando vorgegeben wird. Es muss also einen Weg geben, wie Entwickler mit dem Cluster kommunizieren können. ::: :::globalParagraph Dafür gibt es Benutzeroberflächen, die Informationen zum Cluster gebündelt darstellen können und es Entwicklern erlauben, mit dem Cluster in Verbindung zu treten. Allerdings arbeiten die meisten Entwickler gerne mit sogenannten Komandozeilentools: Informationen können ohne große grafische Aufbereitung abgefragt oder an den Cluster weitergegeben werden. ::: :::globalParagraph Kommandozeilentools muss man sich wie integrierte Entwicklungsumgebungen bei der Softwareentwicklung vorstellen: Verschiedenen Tools haben einen unterschiedlichen Funktionsumfang und legen ihren jeweiligen Fokus auf unterschiedliche Anwendungsbereiche (siehe z.B. "Was ist eine IDE?"). Analog dazu gibt es auch unterschiedliche Kommandozeilentools, die die Entwickler je nach Präferenz für die Arbeit mit einem Kubernetes-Cluster nutzen können. :::

:::globalTitle{:size="sm" :tag="h4" .mb-5} Welche Komandozeilentools gibt es? ::: :::globalParagraph Tools, die hier zur Verfügung stehen, sind beispielsweise kubectl, kubectx oder kube-shell. ::: :::globalParagraph Um eine Analogie zum Auto zu bemühen, kann man sich vorstellen, dass Kubernetes selbst das Konzept der Autotür beinhaltet, über die Entwickler mit einem Kubernetes-Cluster in Verbindung treten können. Kommandozeilentools wiederum setzten das Konzept der Tür unterschiedlich um: Einmal öffnet sich die Türe nach vorne, einmal nach hinten und das dritte Tool ist eine Flügeltüre. Welches Kommandozeilentool genutzt wird, ist aber grundsätzlich egal und liegt in der Entscheidung der Entwickler. Unterschiedliche Entwickler, die aber mit dem gleichen Cluster arbeiten, können auch unterschiedliche Kommandozeilentools benutzen. :::

:::globalTitle{:size="md" :tag="h3" .mb-5} Service-Mesh: Technologie, um die Kommunikation zwischen Cluster-Bestandteilen zu managen ::: :::globalTitle{:size="sm" :tag="h4" .mb-5} Was machen Service-Meshes? ::: :::globalParagraph “Klassische” Anwendungen sind eher in der Form eines Monolithen konzipiert. “Moderne” cloud-native Anwendungsarchitekturen{.bs-link-blue} hingegen setzen auf einzelne Microservices und die Anwendung entsteht erst durch eine Verflechtung und Interaktion einzelner Microservices untereinander. Einzelne Services sind in Container verpackt, die in einzelnen Pods zusammengefasst sind, welche wiederum miteinander kommunizieren und Informationen austauschen (siehe dazu "Kubernetes für Anfänger"{.bs-link-blue}). ::: :::globalParagraph Die Kommunikation zwischen einzelnen Pods (,die den containerisierten Code enthalten) erfolgt in einem Kubernetes Cluster selbst und wird durch die Entwickler definiert. Zusätzlich kann durch die Entwickler noch ein sogenanntes Service Mesh eingesetzt werden, das es erlaubt, die Kommunikation zwischen Pods noch genauer zu spezifizieren. ::: :::globalParagraph Um das zu veranschaulichen, wollen wir uns an dieser Stelle einen Online-Shop vorstellen. Dem Kunden stehen beim Checkout beispielsweise 2 Zahlungsmöglichkeiten zur Verfügung: auf Rechnung und per Kreditkarte. Die Shopbetreiber wollen künftig aber auch die Bezahlung per Paypal möglich machen. Nachdem die Entwickler den dafür notwendigen Code erarbeitet und in einer Testumgebung geprüft haben, soll es nun einen ersten Test im Live-Shop geben. ::: :::globalParagraph Durch die Nutzung eines Service-Mesh kann die Neuentwicklung (Auswahl zwischen 3 Zahlungsmöglichkeiten) auf einem eigenen Pod im Cluster zur Verfügung gestellt werden. Die ursprüngliche Umsetzung (Auswahl nur zwischen 2 Zahlungsmöglichkeiten) kann im Cluster aber bestehen bleiben. Mit dem Service-Mesh können die Entwickler definieren, dass 80% der eingehenden Anfrage weiterhin auf den Pod mit dem ursprünglichen Stand (Auswahl nur von 2 Zahlungsmöglichkeiten) geleitet wird und nur 20% auf den Pod mit der Neuentwicklung. ::: :::globalParagraph Service-Meshes können aber noch mehr: Im obigen Beispiel wird über Service-Meshes definiert, was an die einzelnen Pods kommuniziert wird. Über Service-Meshes kann aber auch definiert werden, wie innerhalb des Clusters kommuniziert wird. Grundsätzlich ist die Kommunikation im Cluster beispielsweise nicht verschlüsselt, durch Service-Meshes kann eine zusätzliche Verschlüsselung definiert werden. :::

:::globalTitle{:size="sm" :tag="h4" .mb-5} Welche Service-Meshes Tools gibt es? ::: :::globalParagraph Tools, die die Technologie des Service-Mash bereitstellen, sind beispielsweise Istio, Linkerd oder Cilium. ::: :::globalParagraph Diese Tool stellen jeweils wieder einen unterschiedlichen Umfang an nutzbaren Möglichkeiten dar. Linkerd verfügt beispielsweise über sogenannte “Sidecar Proxies”, die den Aufbau einer verschlüsselten Kommunikation der Pods untereinander im Cluster erlauben. Istio hingegen bietet diese Funktion nicht. Dafür ist Istio im Vergleich zu Linkerd weniger komplex, in der Architektur schlanker und erfordert keine Code-Änderungen an der Kubernetes-Applikation selbst. Welches das Mittel der Wahl ist, muss also im Einzelfall durch die Entwickler geprüft und beurteilt werden (siehe auch "Was ist Linkerd"). :::

:::globalTitle{:size="md" :tag="h3" .mb-5} Ingress-Controller: Technologie um Anfragen an den Cluster zu kontrollieren ::: :::globalTitle{:size="sm" :tag="h4" .mb-5} Was bedeutet Ingress? ::: :::globalParagraph ‘Ingress traffic’ bezeichnet den Datenverkehr, der seinen Ursprung außerhalb eines Computernetzwerks hat und an dieses gerichtet ist. Bezogen auf einen Cluster bedeutet das, dass eine Anfrage von außerhalb des Clusters an diesen gestellt wird, also z.B. dass ein User eine Website oder einen Service aufruft, der in einem Cluster betrieben wird. Die Technologie oder Ressource “Ingress” macht HTTP- und HTTPS-Anfragen von außerhalb des Clusters für Dienste innerhalb des Clusters verfügbar. ::: :::globalParagraph Analog zum technischen Konzept von Kubernetes handelt es sich auch bei der Technologie “Ingress” um einen abstrakten technischen Bauplan. Die genaue Umsetzung des technischen Bauplans von Ingress liegt wieder beim jeweiligen Hersteller. Um auch hier die Analogie des Autos zu nutzen, liegt es in der Entscheidung des jeweiligen Autobauers, ob der Motor als Verbrennungs- oder Elektromotor umgesetzt wird. ::: :::globalParagraph Ingress selbst ist also das Konzept, wie externe Anfrage an einen Kubernetes-Cluster gestellt werden. Dazu zählt zum Beispiel, wie die Anzahl der externen Anfragen im Kubernetes Cluster ausbalanciert werden, oder dass einer im Cluster verfügbaren Applikation überhaupt eine von extern erreichbare URL zugewiesen wird. Die Ausführung des Konzepts liegt dann bei einem so genannten Ingress-Controller, also der Anbieter-spezifischen Ausgestaltung von Ingress. ::: :::globalParagraph Ingress-Controller sind dabei nicht nur in Zusammenhang mit Kubernetes-Clustern relevant, sondern für die Nutzung von allen Services, die innerhalb eines Computernetzwerkes für Datenverkehr von außen ansprechbar sein sollen - also auch für Services, die auf individuellen Servern gehostet werden. :::

:::globalTitle{:size="sm" :tag="h4" .mb-5} Welche Ingress-Controller gibt es? ::: :::globalParagraph Es gibt eine ganze Reihe an verfügbaren Ingress controllers. Zu den bekanntesten und in Kombination mit Kubernetes-Clustern häufig verwendeten Ingress-Controllern zählen Nginx und Traefik. ::: :::globalParagraph Beide haben wieder diverse Vor- und Nachteile, je nach Anwendungsfall. Welcher Ingress-Controller genutzt werden soll, muss zwingend von spezialisierten Entwicklern beurteilt werden und würde den Rahmen dieses Artikels bei weitem übersteigen. Wir können euch jedoch diese beiden Artikel über Ingress und Ingress controllers von der Kubernetes-Website empfehlen, damit ihr eure Research fortsetzen könnt. :::

{.object-cover .w-full .mb-6}

:::globalTitle{:size="lg" .mb-5} Technologien, die um einen Kubernetes-Cluster herum installiert werden ::: :::globalTitle{:size="md" :tag="h3" .mb-5} Technologien, um Code in Container zu verpacken ::: :::globalTitle{:size="sm" :tag="h4" .mb-5} Container Images ::: :::globalParagraph Kubernetes ist eine Technologie um containerisierte Software zu orchestrieren. Siehe dazu auch unseren Blog Posts Kubernetes für Anfänger{.bs-link-blue}, um mehr über dieses Thema zu erfahren. Ohne containerisierte Software ist die Nutzung von Kubernetes selbst gegenstandslos - eben weil Kubernetes nur mit containerisierter Software arbeiten kann. ::: :::globalParagraph Nachdem der Code für eine Anwendung durch Entwickler erarbeitet wurde, wird daraus ein sogenanntes ‘container image’ erstellt. In Kubernetes wird dann später auf das jeweilige Container Image referenziert. Verwaltet werden die Container Images entweder in einer eigenständigen Container Registry außerhalb des Clusters oder direkt im Cluster selbst. Erst wenn dieses referenzierte Container Image in Kubernetes ausgeführt wird, wird es technisch gesehen zu einem eigenständigen Container. ::: :::globalParagraph Ein Container Image ist ein read-only Template des Codes einer Anwendung, inklusive aller notwendigen Informationen, die für das Ausführen des Codes relevant sind, z.B. Konfigurationsdateien, Umgebungsvariablen, Bibliotheken, etc. Man kann sich ein Container Image also als unveränderliches digitales Bild des Codes vorstellen. Der Vorteil von Container Images liegt darin, dass sie dupliziert und von mehreren Entwickler gemeinsam genutzt werden können. Damit sind Container Images die idealen Ressourcen, um in einem Cluster geteilt zu werden. Anwendungscode kann so innerhalb eines Clusters zum Beispiel auf mehreren Pods ausgeführt und damit skaliert werden. ::: :::globalParagraph Ein weiterer Vorteil der Nutzung von Container Images besteht darin, dass das Image die Konfigurationen für die später entstehenden Container gleich enthält. Anders als bei der Ausführung von Softwarecode auf einem eigenen Server erhalten die Container mit den Informationen aus den Images direkt alle notwendigen Konfigurationsinformationen. Alle später auf Basis des Images generierten Container sind damit immer gleich konfiguriert. Wird Softwarecode auf jeweils eigenen Servern ausgeführt, muss die Konfiguration für jeden Server neu und einzeln vorgenommen werden - ein fehleranfälliges und zeitaufwändiges Vorgehen. Informiere dich sich weiter über Docker Images :::

:::globalTitle{:size="sm" :tag="h4" .mb-5} Tools zur Erstellung von Container Images ::: :::globalParagraph Der bekannteste Anbieter von Tools, um aus Softwarecode ein Container-Image zu erstellen, ist Docker. Mit Docker oder anderen Tools, wie rkt von CoreOS oder LXC, wird ein Container Image erstellt. ::: :::globalParagraph Bei Docker handelt es sich um ein virtualisiertes Betriebssystem für Container und verhält sich ähnlich wie eine Virtuelle Maschine (VM). Eine VM virtualisiert dabei Serverhardware, während Container das Betriebssystem eines Servers virtualisieren. ::: :::globalParagraph Erhalte hier einen guten Überblick über verschiedene Anbieter mit Vor- und Nachteilen im Vergleich zu Docker als Marktführer. Welches Tool zur Umsetzung dieser Technologie genutzt wird, hängt wesentlich von den technischen Voraussetzung und Präferenz der jeweiligen Entwickler ab (z.B. wird mit Windows, Linux oder Mac gearbeitet?). ::: :::globalParagraph Zur Verwaltung von Container Images kann beispielsweise quay.io, genutzt werden. Eine Reihe von Anbietern alternativer Tools zu quay.io findet sich heir Hervorheben möchten wir das Tool Harbor. Während es sich bei quay.io um ein Tool handelt, das eine Container Registry außerhalb des Cluster bereitstellt, kann Harbor direkt in den Cluster installiert werden und die Verwaltung der Images erfolgt damit auch direkt im Cluster. Ein zusätzlicher externer Dienst außerhalb des Clusters ist damit nicht mehr notwendig. Welche Variante hier sinnvoller ist, ist eine Entscheidung des Entwicklerteams und hängt von den individuellen Anforderungen an die zu erstellende Software ab. :::

:::globalTitle{:size="md" :tag="h3" .mb-5} Technologien, um Apps und Konfigurationen in einem Cluster zu managen ::: :::globalTitle{:size="sm" :tag="h4" .mb-5} Konfiguration eines Clusters mit yaml-Dateien ::: :::globalParagraph Nur weil ein Cluster existiert, ist er aber noch nicht sofort für den produktiven Betrieb bereit. Jeder Cluster verfügt über eine spezifische Konfiguration und jede neue Applikation in einem Cluster muss diese Konfiguration berücksichtigen, damit sie korrekt ausgeführt werden kann. ::: :::globalParagraph Die Konfiguration eines Clusters wird in sogenannten yaml-Dateien definiert. Yaml-Dateien enthalten Spezifikationen für das Deployment. ::: :::globalParagraph Sie können händisch durch die Entwickler erstellt werden. Nachteilig ist dabei, dass ein händisches Erstellen von Dateien grundsätzlich fehleranfällig ist. Zusätzlich benötigt ein komplexer Cluster mehrere yaml-Dateien, die alle dem gleichen Standard folgen müssen. Das bedeutet, dass jeder Entwickler in einem Team den Standard auch kennen und anwenden muss. Wird der Standard geändert, benötigt es zusätzliche Absprachen. ::: :::globalParagraph Um diesen Prozess effizienter, stabiler und effektiver zu gestalten, gibt es Tools, die Templates zur Verfügung stellen, so dass alle yaml-Dateien “gleich aussehen”. :::

:::globalTitle{:size="sm" :tag="h4" .mb-5} Helm zur Erzeugung von yaml-Dateien ::: :::globalParagraph Das bekannteste Tool, das außerhalb eines Clusters installiert wird, um yaml-Dateien zu erzeugen, ist Helm. ::: :::globalParagraph In sogenannten Helm Charts wird definiert, welche Abhängigkeiten zwischen den einzelnen Applikationen innerhalb des Cluster bestehen, welche Ressourcen aus Kubernetes benötigt werden und was sonst noch notwendig ist, um Container-Anwendungen bereitzustellen und auszuführen. ::: :::globalParagraph Ein Helm Chart kann dabei beliebig oft im Cluster genutzt werden um beliebig viele Instanzen einer Anwendung zu realisieren und das System so leicht zu skalieren (siehe auch "Was ist Helm?"). ::: :::globalParagraph Helm Charts können auch mit anderen Personen geteilt werden. Sie sind also die zentrale Instanz um eine Anwendung einmalig zu definieren und dann mit minimalem Aufwand von vielen Personen verwalten zu lassen. :::

:::globalTitle{:size="md" :tag="h3" .mb-5} Technologien zur lokalen Ausführung von Kubernetes ::: :::globalTitle{:size="sm" :tag="h4" .mb-5} Softwareentwicklung auf lokalen Rechnern ::: :::globalParagraph Dazu machen wir einen ganz kurzen Ausflug in die Arbeitswelt der Entwickler. In der Regel werden einzelne Bestandteile eines komplexen Codes entwickelt, einzelne Features, die später zusammengeführt werden. Entwickler produzieren Code also lokal auf ihren eigenen Rechnern und nicht direkt in komplexen Produktiv- oder Testumgebungen. Erst später werden die einzelnen Bestandteile dann zusammengeführt. ::: :::globalParagraph Dafür ist notwendig, dass Entwickler die projektspezifische Entwicklungsumgebung auf ihren eigenen Rechnern verfügbar haben, also die Rahmenkonfigurationen der späteren Test- und Produktivumgebung. Das ist immer notwendig, egal ob für den späteren Betrieb der Software Kubernetes genutzt wird oder nicht. ::: :::globalParagraph Die Herausforderung für die Entwickler liegt darin, diese Umgebung auf ihren lokalen Rechner richtig zu konfigurieren. Nur wenn gegen die richtige Konfiguration entwickelt wird, kann der Code später in der Produktiv- oder Testumgebung auch fehlerfrei ausgeführt werden. Bisher lag die große Herausforderung darin, dass jeder einzelne Entwickler die entsprechenden Konfigurationen selbst vornehmen musste. Enge Absprachen zwischen den Teams, die Software entwickeln (Development-Teams), und den Teams, die für die Konfiguration der später genutzten Server zuständig sind (Operations-Teams), sind dafür notwendig. Die Kommunikation zwischen beiden Teams läuft dabei oft nicht reibungslos. ::: :::globalParagraph Wird für die Ausführung von Softwarecode Kubernetes genutzt, gibt es nun aber eine ganze Reihe von Tools, die es ermöglichen, dass das Operations-Team die Konfiguration des Cluster selbstständig vornimmt, pflegt und wartet und die Entwicklerteams die Konfigurationen durch den Einsatz spezialisierter Tools ohne selbstständig Konfigurationsmaßnahmen oder notwendigen Absprachen auf ihren Rechner installieren können. Auch wenn sich die Konfigurationen am Cluster ändern, ermöglichen diese Tools, dass die geänderten Konfigurationen ohne weitere Absprachen zwischen den Teams auch auf die Rechner der Entwickler übernommen werden. :::

:::globalTitle{:size="sm" :tag="h4" .mb-5} Lokale Kubernetes Entwicklungstools ::: :::globalParagraph Beispiele für Tools, die diese Technologie anbieten, sind minikube, kind oder auch K3s. ::: :::globalParagraph Einen guten Überblick über die unterschiedlichen Umfänge dieser Tools und mögliche Anwendungsfälle findet sich hier. :::

:::globalTitle{:size="md" :tag="h3" .mb-5} Technologien, um Container zu “bridgen” ::: :::globalTitle{:size="sm" :tag="h4" .mb-5} Was bedeutet "bridgen"? ::: :::globalParagraph Zuerst müssen wir voranstellen, dass das Wort “bridgen” keine anerkannte Terminologie ist, um zu beschreiben, was die hier vorgestellten Tools machen. Um ehrlich zu sein: Wir haben den Begriff bei uns eingeführt, weil er den Zweck dieser Technologien sehr anschaulich beschreibt. Wenn ihr also das Internet nach dem Terminus “bridgen” in Zusammenhang mit Kubernetes durchsucht, werdet ihr vermutlich kaum sinnvolle Treffer erhalten. Daher möchten wir an dieser Stelle den Terminus “bridgen” und die dazugehörigen Tools näher vorstellen. ::: :::globalParagraph Um einen Cluster zu betreiben, bedarf es einiger Ressourcen: Vor allem Rechenleistung. Und Rechenleistung kostet Geld. Geld ist nicht unbegrenzt verfügbar und dass es sowohl in der kommerziellen als auch nicht-kommerziellen Softwareentwicklung nicht unbegrenzt verfügbar ist, müssen wir hier nicht philosophisch erörtern. ::: :::globalParagraph Auch wenn Entwickler einen Cluster bei sich lokal verfügbar machen, um die Softwareentwicklung selbst effektiver zu gestalten, kostet das Ressourcen und damit Geld. Man stelle sich nur vor, dass ein großes Entwicklerteam an einer Vielzahl kleinerer neuer Features für eine große Hotelbuchungsplattform arbeitet und dass jeder Entwickler einen lokal verfügbaren Cluster besitzt, um einen Vorstellung von der Größenordnung der notwendigen Ressourcen zu bekommen. ::: :::globalParagraph Auch um dieses Problem zu lösen, gibt es eine maßgeschneiderte Technologie. Installieren sich Entwickler ein Tool dieser Technologie lokal auf ihren Rechnern ist es möglich, dass sie den Code lokal entwickeln und in Containern verpacken, bei der Ausführung des Codes im Container auf den eigenen Rechner dem Container aber "vorgegaukelt" wird, er würde sich in einem Cluster befinden. ::: :::globalParagraph Dieses “Vorgaukeln” ist aber noch nicht das, was “bridgen” eigentlich meint. Bridgen beginnt technisch gesehen erst, wenn Entwickler an bereits bestehenden Code arbeiten, zum Beispiel um einen Bugfix auszuführen. Dabei kann ein Entwickler mit den entsprechenden Tools (siehe unten) einen Container auf seinem lokalen Rechner “klonen” und an bereits bestehenden Code arbeiten. Der überarbeitete Code kann im bestehenden Cluster auf einen Container gelegt und getestet werden, wobei er noch immer ausschließlich auf dem lokalen System des Entwicklers ausgeführt wird. Solange diese Bridge besteht, können alle User, die über die URL verfügen, auch auf diese Code-Änderung zugreifen. ::: :::globalParagraph Dabei ist aber zu bedenken, dass aller Traffic auf diesen Container dann auch über die lokale Entwicklungsumgebung des jeweiligen Entwicklers geht, dieses Verfahren ist also vor allem sinnvoll, um Arbeiten in einem Staging-Cluster durchzuführen: Bugfixes können damit direkt im Staging getestet werden. Für Arbeiten an einem Produktivcluster sollte dieses Verfahren eher nicht angewendet werden. :::

:::globalTitle{:size="sm" :tag="h4" .mb-5} Welche Bridging-Tools gibt es? ::: :::globalParagraph Eines der bekanntesten Tools zum Bridgen ist “Telepresence”. ::: :::globalParagraph Blueshoe hat für diese Zwecke auch ein eigenes Tool namens ‘Gefyra’ entwickelt. Gefyra ist zwar hinsichtlich der Funktionalitäten nicht ganz so umfangreich wie Telepresence, ist mit seinem Fokus in der Nutzung aber wesentlich komfortabler für die Entwickler bei der Erstellung einer Bridge. Eine Gegenüberstellung beider Produkte könnt ihr im Blog Post "An Alternative to Telepresence 2: Gefyra". :::

{.object-cover .w-full .mb-6}

:::globalTitle{:size="md" :tag="h3" .mb-5} Technologien, um den Entwicklern eine Entwicklungsumgebung zur Verfügung zu stellen, die der Produktionsumgebung entspricht ::: :::globalTitle{:size="sm" :tag="h4" .mb-5} Anforderungen an die Entwicklungsumgebung ::: :::globalParagraph Sind Arbeiten an Softwarecode erforderlich, der in einem Cluster ausgeführt wird, ist es notwendig, dass die Entwickler in der lokalen Entwicklungsumgebung ebenfalls über einen Cluster verfügen. ::: :::globalParagraph Dafür ist es sinnvoll, dass der lokale Cluster in der Konfiguration weitgehend dem Cluster entspricht, auf dem der Softwarecode später ausgeführt wird. Dafür gibt es Tools wie z.B. minikube (siehe oben). ::: :::globalParagraph Zusätzlich ist es genauso sinnvoll, wenn der lokale Entwicklungscluster auch "vorgefüllt" ist, d.h. dass die im Cluster vorhandenen Daten ebenfalls weitgehend den Livedaten entsprechen. Dazu gehören zum Beispiel Datenbanken, Datenbankeinträge, integrierte Drittsysteme, wie zum Beispiel Tools zum Identifikationsmanagement, etc.. ::: :::globalParagraph Das heißt, wir haben einerseits Tools, damit Cluster auf den lokalen Entwicklungsumgebung einzelner Entwickler erstellt werden können. Diese Tools stellen sicher, dass alle Entwickler jeweils über die gleichen Konfigurationen verfügen. Ein Beispiel dafür ist zum Beispiel minikube (siehe oben). ::: :::globalParagraph Andere Tools erlauben es den Entwicklern, bereits bestehenden Code im lokalen Entwicklungscluster zu bearbeiten und diesen Code dann vor dem Deployment im Cluster “auszuprobieren”. Beispieltools dafür sind “Telepresence” oder “Gefyra” (siehe oben). ::: :::globalParagraph Und dann gibt es noch die in diesem Abschnitt vorgestellten Tools, die es erlauben, lokale Cluster mit Daten und/oder Drittsystemen, die möglichst nahe am Livesystem sind, für die Entwickler zu provisionieren. :::

:::globalTitle{:size="sm" :tag="h4" .mb-5} Welche Tools gibt es? ::: :::globalParagraph Ein Tool, das die Vorprovisionierung von lokalen Clustern erlaubt, ist das von Blueshoe entwickelte Tool “Getdeck”. Wir sind von unserem Tool überzeugt und wenden es in unserer täglichen Arbeit an - gerne könnt ihr einen Termin mit uns buchen{.bs-link-blue}, in dem wir euch Getdeck näher vorstellen. :::

:::globalTitle{:size="md" :tag="h3" .mb-5} Technologien, um die Code-Qualität sicherzustellen ::: :::globalTitle{:size="sm" :tag="h4" .mb-5} Vorteile von CI/CD ::: :::globalParagraph Als Software nur auf Medien wie Disketten oder CD-Roms zur Verfügung stand, lag der Fokus für Entwickler auf der Erarbeitung einer dauerhaften Version von Software. Gab es ein Update, musste sich der User eine neue CD-Rom mit dem aktualisierten Code-Stand besorgen. ::: :::globalParagraph Heute ist dieses Vorgehen weitgehend überholt: Software entwickelt sich ständig weiter, Updates sind ständig verfügbar. Das heißt, dass heute auch ständig einzelne Programmbestandteile zusammengeführt und permanent auf deren Kompatibilität geprüft werden müssen. ::: :::globalParagraph Wird dieser Prozess rein linear gestaltet und die Komptabilität einzelner Softwarebestandteile erst ganz am Ende geprüft, können erhebliche Probleme auftreten. Für die Entwickler kann das zur “Integrationshölle” werden: Der Code für ein neues oder überarbeitetes Feature ist zwar fertiggestellt, aufgrund nicht-absehbarer Abhängigkeiten mit anderen Code-Bestandteilen läuft aber nichts wie geplant. Siehe dazu auch "Was ist Continuous Integration und was sind die Vorteile?". ::: :::globalParagraph Die Methode CI/CD möchte dafür Abhilfe schaffen. CI steht für “Continuous Integration”, einem Automatisierungsprozess für Entwickler. CD bedeutet sowohl “Continuous Delivery” (Codeänderungen werden automatisch getestet) als auch “Continuous Deployment” (Freigabeprozess von Codeänderungen beim Verfügbarmachen für die Endnutzer - also dem Deployment). :::

:::globalParagraph{.mt-4} Continuous Integration ::: :::globalParagraph Codeänderungen einzelner Entwickler werden regelmäßig miteinander zusammengeführt. Das bietet daher vor allem den Vorteil, dass Inkompatibilitäten wesentlich früher aufgedeckt werden können. :::

:::globalParagraph{.mt-4} Continuous Delivery & Continuous Deployment ::: :::globalParagraph Codeänderungen werden automatisierten Tests unterzogen und in Repositorys wie GitHub verfügbar gemacht. Dabei soll auch geprüft werden, wie sich der neue Code im Zusammenspiel mit bereits bestehendem Code auf dem Live-System verhält. ::: :::globalParagraph Mittlerweile gibt es spezifische Tools, die den CD-Prozess speziell für Software, die in einem Kubernetes-Cluster ausgeführt wird, verfügbar machen, Prüfungstools, die also explizit auf ein Kubernetes-Umfeld ausgelegt sind. :::

:::globalTitle{:size="sm" :tag="h4" .mb-5 .mt-4} Das Tool Argo CD ::: :::globalParagraph Wir bei Blueshoe nutzen dafür das Tool Argo CD. Argo CD ist ein Kubernetes Controller der ständig eine laufende Applikation überwacht und den aktuellen Livestand eines Codes gegen einen gewünschten Stand abgleicht, wie er in einem Git-Repository definiert ist (hier kann auch der neue Softwarecode enthalten sein). Abweichungen kann Argo CD entweder automatisiert beheben oder visualisiert Abweichungen für Entwickler, damit diese schnell manuell behoben werden können :::

:::globalTitle{:size="md" :tag="h3" .mb-5} Technologien zum Geheimnismanagement ::: :::globalTitle{:size="sm" :tag="h4" .mb-5} Geheimhaltung und Verschlüsselung von Daten ::: :::globalParagraph Bereits kleine Projekte benötigen für den Betrieb einige Daten, die geheim bleiben müssen und nur denjenigen Personen/Apps verfügbar sind, die sie auch wirklich brauchen. Dazu gehören unter anderem Passwörter für die Autorisierung bei anderen Services (Datenbank, API{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} , etc.) oder Keys für die Verschlüsselung von gespeicherten Daten. Da diese nicht in falsche Hände gelangen sollten, dürfen sie nicht unverschlüsselt (plain-text) in die versionierten Kubernetes-Ressourcen (Kustomize-Manifeste, Helm-Charts, …) geschrieben werden. Es gibt verschiedene Tools, die das Management von solchen Geheimnissen ermöglichen und dabei unterschiedliche Ansätze verfolgen. :::

:::globalTitle{:size="sm" :tag="h4" .mb-5} Welche Tools gibt es? ::: :::globalParagraph Secrets Plugin für Helm verschlüsselt Werte in den Helm-YAML-Dateien lokal mithilfe eines Keys (z.B. mit Mozilla SOPS), der nicht im Repo lebt und den Bearbeitern auf anderem Wege gegeben wird. Versioniert werden dann nur die verschlüsselten Geheimnisse. Bei der Anwendung der Charts entschlüsselt das Plugin diese Werte und bringt so die geheimen Daten in den Cluster. ::: :::globalParagraph Bitnami Sealed Secrets verfährt ähnlich, verschlüsselt die geheimen Daten allerdings im Cluster und generiert eigene Objekte, vom Typ SealedSecret, die versioniert werden können und die bei der Anwendung der Ressourcen dann von einem Operator entschlüsselt und in "echte" Kubernetes Secrets umgewandelt werden. ::: :::globalParagraph Andere Tools/Technologien, welche allein oder im Zusammenspiel mit den genannten Tools genutzt werden können, sind z.B. HashiCorp Vault, Azure Key Vault and AWS Secrets Manager. :::

:::globalTitle{:size="md" :tag="h3" .mb-5} 3.8 Technologien für Monitoring, Logging und Metrics Collection ::: :::globalParagraph Um in einem System mit vielen Bestandteilen den Überblick zu behalten, ist es sinnvoll, Logs und andere Daten, die Aufschluss über den Zustand einzelner Komponenten geben, an einer zentralen Stelle zusammenfließen zu lassen und übersichtlich aufzubereiten. Tools, welche in diesem Kontext genutzt werden, sind z.B. Prometheus, Open Telemetry, Grafana, Logstash. :::

{.object-cover .w-full .mb-6}

:::globalTitle{:size="lg" .mb-5} Cloud Native Development ::: :::globalParagraph Cloud Native Development{.bs-link-blue} beschreibt einen Software-Entwicklungsansatz, bei dem Applikationen von Anfang an für den Einsatz in der Cloud konzipiert werden (Ionos). Folglich ist es sinnvoll, auch die Entwicklung selbst schon so weit wie möglich in der späteren Cloud-Umgebung stattfinden zu lassen. ::: :::globalParagraph Mit unserem Blueshoe-eigenen Technologie-Stack bestehend aus Unikube, Gefyra und Getdeck{.bs-link-blue} haben wir wesentlich dazu beigetragen, diesen Prozess für ganze Entwicklerteams effizienter und effektiver zu gestalten. ::: :::globalParagraph Trotzdem möchten wir nicht verschweigen, dass es zu unseren eigenen Produkten auch einige nennenswerte Konkurrenten gibt, wie beispielsweise Okteto und Skaffold. ::: :::globalParagraph Trotzdem sind wir von unseren Produkten überzeugt: Sie bieten genau das, was Entwicklerteams benötigen, sind von uns umfangreich erprobt und finden immer weitere Wege in die Integration in andere Tools: Gefyra{.bs-link-blue} ist mittlerweile zu einer eigenen Docker Desktop Extension geworden. ::: :::globalParagraph Wenn du neugierig auf unsere Produkte geworden bist und mehr erfahren möchtest, kontaktiere uns{.bs-link-blue}! :::

{.object-cover .max-w-full .mb-5}

:::GlobalTitle{:size="lg" .mb-5} Einführung in Kubernetes Autoscaling ::: :::GlobalParagraph Kubernetes bringt bereits viel Automatismus und Möglichkeiten zur Effizienzoptimierung mit sich. Sei es das Zuweisen von Workloads zu den Nodes, Readiness- und Liveness - Probes, um hängende Container neu zu starten, oder ein dynamisches Hinzufügen oder Entfernen von Nodes mittels Cluster Autoscaler. Auch ein dynamisches Skalieren einzelner Workloads anhand der Ressourcen-Auslastung ist mittels Horizontal Pod Autoscaling möglich. Doch damit lassen sich nicht alle Anforderungen abdecken. Was ist z.B. mit einem Cluster, der nur werktags zu den Arbeitszeiten benötigt wird? In diesem Blogpost betrachten wir, wie du Kubernetes Workloads mittels KEDA anhand eines zeitbasierten Schedules skalieren kannst. :::

:::GlobalButton{:url="/technologien/docker-kubernetes/" :label="Erfahre mehr, wie wir dir mit Docker und Kubernetes behilflich sein können" :color="blue" .mb-6} :::

:::GlobalTitle{:size="lg" .mb-5} Was ist KEDA? :::

:::GlobalParagraph KEDA greift den Gedanken des Pod Autoscaling auf und erweitert ihn um die Möglichkeit, nicht nur anhand der Ressourcenauslastung zu skalieren, sondern auch anhand allgemeinerer Events. Die Events können z.B. auf Datenbank-Queries basieren, auf Metriken eines Message-Brokers, auf einem Cron-Schedule und vielem mehr. ::: :::GlobalParagraph Derzeit unterstützt KEDA 71 sogenannte Scaler, die du als Basis für das eventbasierte Autoscaling verwenden kannst. Du musst dazu lediglich ein ScaledObject anlegen, eine CustomResourceDefinition von KEDA. Der keda-operator, der im Cluster deployt ist, erzeugt daraufhin dynamisch eine entsprechende HorizontalPodAutoscaler Ressource, um deine selektierten Workloads anhand der spezifizierten Events zu skalieren. :::

:::GlobalTitle{:size="lg" .mb-5} Cron-Scaler um Betriebszeiten zu definieren ::: :::GlobalParagraph Um die Workloads eines Clusters außerhalb der Betriebszeiten auf 0 zu skalieren, nutzen wir den Cron-Scaler{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid}. Dieser ermöglicht es, ein Cron-Schedule mit Start- und Endzeit zu definieren, innerhalb dessen die Workloads auf eine gewünschte Anzahl an Replicas skaliert werden. Außerhalb des Schedules werden die Workloads auf die spezifizierte Mindestanzahl skaliert. ::: :::GlobalParagraph{.mb-4} Anhand eines exemplarischen ScaledObjects zum beschriebenen Szenario wirst du sehen, wie einfach die Konfiguration für unseren Anwendungsfall ist: :::

:::BlogCode{.mb-5}

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: cron-scaledobject
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-deployment
  minReplicaCount: 0
  maxReplicaCount: 3
  cooldownPeriod: 60
  triggers:
    - type: cron
      metadata:
        timezone: Europe/Berlin
        start: 0 6 * * 1-5
        end: 0 20 * * 1-5
        desiredReplicas: '3'

:::

:::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Was passiert hier? ::: :::GlobalParagraph Das selektierte Deployment ist my-deployment, im default-Namespace. Der minReplicaCount ist 0, damit es außerhalb der Betriebszeiten auf 0 skaliert wird. Start und Ende der Betriebszeit sind mit den Cron-Schedules 0 6 * * 1-5, bzw. 0 20 * * 1-5 spezifiziert. D.h. montags bis freitags zwischen 6:00 und 20:00 wird das Deployment auf die 3 Replicas skaliert, was durch den Parameter desiredReplicas angegeben ist. Dies sorgt für einen effizienteren Ressourcenverbrauch. :::

::GlobalCallAnExpert{:bg="bg-bs-blue"} #buttonBlockTitle Wir können auch Deine Apps dynamisch an den Bedarf anpassen. ::

:::GlobalTitle{:size="lg" .mb-5} Wie hoch ist die Kostenersparnis? ::: :::GlobalParagraph Die wirklich spannende Frage ist: Wie groß ist der Effizienzgewinn und somit die Kostenersparnis durch die Umsetzung von Betriebszeiten? Das hängt ganz stark von deinem Setup ab. :::

:::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Voraussetzung ::: :::GlobalParagraph Der Cluster Autoscaler muss aktiv sein, damit ungenutzte Nodes entfernt werden können. Die Höhe der Einsparungen hängt dann davon ab, wie viele Workloads außerhalb der Betriebszeiten pausiert werden können. :::

:::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Beispiel ::: :::GlobalBlock{.ul-disk .mb-4}

• Wenn in deinem Cluster 10 Anwendungen laufen und nur eine außerhalb der Betriebszeiten skaliert wird, bleibt der Effekt gering.
• Kannst du hingegen 9 Workloads pausieren, reduziert sich der Bedarf an Nodes erheblich – das spart spürbare Kosten. :::

:::GlobalTitle{:size="lg" .mb-5} Fazit ::: :::GlobalParagraph KEDA macht es sehr einfach, Kubernetes-Workloads anhand zeitbasierter Events dynamisch zu skalieren. Die Installation und die Spezifikation der ScaledObjects sind unkompliziert und nehmen wenig Zeit in Anspruch. ::: :::GlobalParagraph Auch wenn die genaue Kostenersparnis nicht pauschal prognostiziert werden kann, lohnt sich der Einsatz von KEDA langfristig, wenn deine Workloads eine zeitbasierte Charakteristik aufweisen. :::

:::GlobalTitle{:size="lg" .mb-5 .mt-8} Häufige Fragen :::

:::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 1. Was ist KEDA und wie unterscheidet es sich vom Kubernetes Horizontal Pod Autoscaler (HPA)? ::: :::GlobalParagraph KEDA (Kubernetes Event-Driven Autoscaling) erweitert das klassische Horizontal Pod Autoscaling (HPA) in Kubernetes. Während HPA Workloads basierend auf Ressourcen wie CPU- oder Speicherauslastung skaliert, ermöglicht KEDA das Autoscaling basierend auf externen Ereignissen. Dazu gehören Datenbank-Abfragen, Message-Broker-Metriken oder zeitgesteuerte Trigger. KEDA arbeitet ergänzend zum HPA, indem es externe Metriken übermittelt und so flexiblere Skalierungsmöglichkeiten schafft. :::

:::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 2. Welche Vorteile bietet KEDA für das dynamische Autoscaling von Kubernetes-Workloads? ::: :::GlobalParagraph KEDA bietet folgende Vorteile: ::: :::GlobalBlock{.ul-disk .mb-4}

• Flexibilität: Skalierung basierend auf externen Ereignissen (z. B. Kafka, Prometheus oder Azure Event Hubs).
• Zero Scaling: Workloads können auf 0 Pods reduziert werden, wenn keine Ressourcen benötigt werden.
• Einfache Integration: KEDA arbeitet nahtlos mit HPA zusammen und nutzt bestehende Kubernetes-Mechanismen.
• Kostenersparnis: Durch bedarfsgerechte Skalierung können unnötige Ressourcen vermieden werden.
• Breite Unterstützung: Mit über 70 Scalers ist KEDA vielseitig einsetzbar. :::

:::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 3. Wie funktioniert der Cron-Scaler von KEDA für zeitbasiertes Autoscaling? ::: :::GlobalParagraph Der Cron-Scaler in KEDA ermöglicht die zeitgesteuerte Skalierung von Workloads. Du definierst ein Cron-Schedule mit Start- und Endzeit sowie der gewünschten Anzahl an Replicas. Außerhalb dieses Zeitfensters werden Workloads auf die spezifizierte Mindestanzahl (z. B. 0 Pods) skaliert. ::: :::GlobalParagraph Beispiel: Ein Deployment kann von Montag bis Freitag zwischen 6:00 und 20:00 auf 3 Pods hochskaliert und außerhalb dieser Zeiten auf 0 reduziert werden. :::

:::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 4. Welche Ereignisquellen (Scaler) unterstützt KEDA für das Autoscaling? ::: :::GlobalParagraph KEDA unterstützt über 70 Scalers, darunter: ::: :::GlobalBlock{.ul-disk .mb-4}

• Message-Broker: Kafka, RabbitMQ, Azure Event Hubs.
• Datenbanken: MySQL, PostgreSQL, MongoDB.
• Metrikquellen: Prometheus, AWS CloudWatch, Azure Monitor.
• Zeitbasierte Trigger: Cron-Schedules.
• Weitere: Redis, GitHub Actions, AWS SQS, und mehr. ::: :::GlobalParagraph KEDA lässt sich zudem durch benutzerdefinierte Scaler erweitern, um nahezu jede Ereignisquelle zu integrieren. :::

:::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 5. Was bedeutet Zero Scaling und wie hilft KEDA dabei? ::: :::GlobalParagraph Zero Scaling bedeutet, dass Workloads vollständig deaktiviert werden, indem ihre Anzahl an Pods auf 0 gesetzt wird. KEDA ermöglicht dies durch die Nutzung von Ereignisquellen, die bei Bedarf Pods aktivieren. Dies reduziert die Ressourcennutzung drastisch, wenn keine Ereignisse vorliegen, und hilft, Kosten zu sparen, während die Cluster-Effizienz maximiert wird. :::

:::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 6. Ist KEDA für alle Kubernetes-Anwendungen geeignet oder gibt es Einschränkungen? ::: :::GlobalParagraph KEDA ist für viele Anwendungen geeignet, insbesondere für: ::: :::GlobalBlock{.ul-disk .mb-4}

• Event-getriebene Anwendungen (z. B. Message-Broker, Datenbankoperationen).
• Workloads mit zeitbasierten Anforderungen (z. B. Geschäftszeiten).
• Metrikbasierte Anwendungen, die auf externe Signale reagieren. ::: :::GlobalParagraph Einschränkungen: ::: :::GlobalBlock{.ul-disk .mb-4}
• KEDA ist auf Anwendungen ausgelegt, die skalierbare Architekturen verwenden (z. B. Deployments, Jobs).
• Workloads, die dauerhaft laufen müssen, profitieren weniger von KEDA, da Zero Scaling hier nicht möglich ist.
• Dein Cluster benötigt einen aktiven Cluster Autoscaler, um Nodes bei Zero Scaling zu entfernen. ::: :::GlobalParagraph{.mb-8} Tipp: Für Anwendungen mit festen Ressourcenanforderungen oder kontinuierlicher Verfügbarkeit ist HPA allein möglicherweise ausreichend. :::

{.object-cover .max-w-full .mb-5}

::GlobalTitle{:size="lg" .mb-5} Warum sind Backups so wichtig? :: ::GlobalParagraph Warum wir Backups grundsätzlich brauchen, muss ich - so hoffe ich - niemandem erklären. Tatsächlich gibt es aber neben den einfachen unternehmerischen Zielen auch betriebswirtschaftliche Bereiche, die sich dediziert mit dem Thema “Sicherung und Wiederherstellung” (und anderen) beschäftigen: Dem Business Continuity Planning (BCP{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid}). Darin werden auch die Begriffe “Resilienz” und “Kontinuität” eingeführt, welche im Zusammenhang mit IT-Systemen zwei wichtige Metriken definieren. Aber nicht nur unternehmerische Pläne sind zielgebend, sondern auch rechtliche Anforderungen müssen bedient werden (vor allem in Europa). So stellt die DSGVO, überall da wo personenbezogene Daten verarbeitet werden, mit ihrem Schutzziel der “Verfügbarkeit”, die im engen Zusammenhang mit der “Vertraulichkeit” und “Integrität” stehen, ebenso hohe Anforderungen an technische Maßnahmen und Prozesse. Ähnliches gilt für nationale Werbemittel-Gesetze, die beispielsweise auch Fristen für die Dauer der Aufbewahrung vorgeben. :: ::GlobalParagraph Leider hat die jüngere Geschichte gezeigt, dass Backups und das damit verbundene “Disaster Recovery”{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} immer noch nicht den Stellenwert genießen, die es eigentlich haben sollte. Es ist natürlich nachvollziehbar, dass Strategien zur Adressierung der oben beschriebenen Punkte keinen direkten positiven Einfluss auf den Unternehmenserfolg haben und daher intuitiv als zweitrangig bewertet werden. Aber resiliente Unternehmen, die eine gewisse Immunität gegenüber Störungen in ihren Abläufen entwickelt haben (sei es durch eigenes personelles Versagen, oder Einflüsse von außen, z.B. Hacker-Angriffe) und für ihre eigene Kontinuität sorgen, werden langfristig erfolgreicher sein. Denn der nächste Ausfall kommt bestimmt… ::

::GlobalButton{:url="/technologien/docker-kubernetes/" :label="Arbeitest du bereits mit Kubernetes? Schau dir unsere Lösungen für eine effiziente Infrastruktur an!" :color="blue" .mb-6} ::

::GlobalTitle{:size="lg" .mb-5} Backup-Methoden im Überblick ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Snapshots – Die schnelle und einfache Lösung ::

::GlobalParagraph Starten wir mit etwas Background: Je nachdem, welche Anforderungen konkret gestellt sind, muss die Backup-Strategie angepasst werden. Die Basis stellen aber in jedem Fall regelmäßige Snapshots dar: Diese sichern einmal den kompletten Datenbestand zum Zeitpunkt der Snapshot-Anforderung. Snapshots sind in der Regel einfach zu Organisieren, verbrauchen aber den meisten Speicherplatz und bieten dafür die schnellste und sicherste Form zur Wiederherstellung, da man mit Snapshots einen IT-Dienst 1-zu-1 starten kann. Die gesetzte Regelmäßigkeit für ein Snapshot-Backup stellt dann auch direkt den maximalen Zeitraum für einen mittelbar zulässigen Datenverlust im Falle einer Störung dar. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Differentielle Backups – Platzsparender, aber komplexer ::

::GlobalParagraph Zusätzlich zu den Snapshost können differentielle Backups erstellt werden. Diese sichern nur die Daten zwischen einem Snapshot (auch “Baseline”) und dem Zeitpunkt der Erstellung des differentiellen Backups. Je nach betroffenem IT-Dienst stellt das differentielle Backup aber bereits einen sehr viel größeren Aufwand zur Erstellung, Verwaltung und Wiederherstellung dar. Dafür kann aber Speicherplatz gegenüber einem Snapshot, und damit langfristig Kosten, gespart werden. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Point-in-Time Backups – Maximale Flexibilität ::

::GlobalParagraph Punkt in der Vergangenheit wiederherzustellen. Diese Form der Backups ist der Goldstandard, aber in komplexen (verteilten) IT-Systemen möglicherweise nicht zweifelsfrei zu erreichen. Dabei wird jede Transaktion, die das System in jeder beliebigen Form verändert, bereits zur Zeit der Bestätigung zusätzlich gesichert. Erfahrungsgemäß ist diese Backup-Strategie die aufwändigste. Es ist sehr anspruchsvoll, Point-in-Time Backups zu erstellen, diese zu organisieren und auch die Wiederherstellung von Systemen dauert entsprechend lange und ist aufwändig. Denn: Zunächst muss eine Baseline (aus einem Snapshot) eingespielt und danach alle Transaktionen in einem “Replay”-Verfahren in der korrekten Reihenfolge angewendet werden. Sollten dabei Bedingungen außerhalb der Systemgrenzen auftreten, die zum Zeitpunkt der Wiederherstellung nicht mehr gegeben sind (z.B. Daten in einem anderen Dienst haben sich verändert), kann auch der Wiederherstellungsprozess gestört werden. ::

::GlobalParagraph Da wir in jedem Falle einen guten Plan für Snapshot-Backups brauchen, konzentrieren wir uns in diesem Artikel, basierend auf dem Tech-Stack: Kubernetes, Google Cloud Storage, Cloud SQL und GitHub Actions, wie wir verlässliche Backups erstellen können. Ziel ist also, alles zu sichern, was notwendig ist, um den Betrieb eines IT-Dienstes aus einem Backup wiederherzustellen. ::

::GlobalButton{:url="/technologien/docker-kubernetes/" :label="Setzt du bereits auf Docker? Damit kannst du dein Backup-Handling noch weiter optimieren!" :color="blue" .mb-6} ::

::GlobalTitle{:size="lg" .mb-5} Ziel der Datenträger: Cloud Storage :: ::GlobalParagraph Fangen wir mal von hinten an: Wo sollen die Backups gespeichert werden? Cloud Storage eignet sich für viele Arten von Anwendungen. Zum einen können wir produktive (online, transaktionale) Daten speichern und ausliefern (z.B. Assets von einer Website wie Bilder oder Dokumente). Zum anderen können wir ihn als Transitmedium verwenden für den Austausch zwischen einem Quell- und Zielsystem - oder auch für die langfristige Lagerung von Daten. In den meisten Fällen endet aus unserer Sicht die Reise für das Backup hier, aber für das Backup geht es oftmals noch weiter in unternehmensnahe Speichermedien für eine redundante Ablage. ::

::GlobalTitle{:size="lg" .mb-5} Die Einrichtung aller notwendiger Backups :: ::GlobalParagraph Was soll denn eigentlich gesichert werden? Wir sprechen immer von Assets (Bilder, Videos, Dokumente, alle “beweglichen” Daten außerhalb der Datenbank, die nicht Teil der Code-Basis sind), den Datenbanken (also alle persistenten Datenspeicher) und dem Quellcode für die Anwendung. Darauf aufbauend gibt es immer noch reproduzierbare Artefakte, die auf Basis der bevorstehenden Daten erstellt werden können, z.B. der Inhalt eines Caches, Software Container Images (z.B. Docker). Diese sind nicht Teil der Backup-Strategie, weil sie entweder recht schnell und einfach neu aufgebaut werden können (z.B. ein Zwischenspeicher) oder oft auch sehr sicher aufbewahrt werden (z.B. Software Container Registries). ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Speicherort für Backups: Cloud Storage nutzen ::

::GlobalParagraph Es macht Sinn, auch den transaktionalen Cloud Storage zu sichern. Warum? Möglicherweise wurde ein Bucket nicht hochverfügbar konfiguriert (redundante Ablage aller Daten) oder das BCG (siehe oben) sieht auch die Absicherung gegen den Ausfall des Cloud-Providers vor. Alle typischen Cloud-Anbieter sehen hier bereits eine eingebaute und einfache Möglichkeit vor. Am Beispiel der Google Cloud kann das Backup eines Buckets in ein anderes Bucket per ClickOps einmalig eingerichtet werden. ::

{.object-cover .max-w-full .mb-5}

::GlobalParagraph Mithilfe von Google Transfer{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} können also ganz einfach Quellen, Ziele und Ausführungszeitpunkte eingestellt werden. Daneben gibt es noch weitere Einstellungen, z.B. wie mit gelöschten Daten umgegangen werden soll. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Datenbank Backup in Kubernetes mit Cloud SQL :: ::GlobalParagraph Interessanter wird es mit Cloud SQL Backups. Diese werden erfahrungsgemäß nicht “einfach“ zur Verfügung gestellt. Für eine PostgreSQL-kompatible Datenbank-Instanz kann also nicht per on-board Mittel ein SQL-Dump{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} erstellt werden (weder in der Google Cloud, noch bei AWS). Ich vermute, die vereinfachte Migration zu anderen Service-Anbietern steckt hier hinter dem fehlenden Dienst. Statt eines portablen SQL-Dumps kann also nur eine Cloud-proprietäre Backup-Lösung genutzt werden. Aber wir haben ja einen Kubernetes Cluster mit Zugriff auf die betreffenden Datenbanken verfügbar. ::

::GlobalParagraph Benötigt wird also ein Kubernetes CronJob der sich im gewünschten Intervall zur Datenbank verbindet und aus dieser ein Snapshot erstellt. Das ist glücklicherweise recht einfach. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Dockerfile für PostgreSQL Backup: ::

::GlobalParagraph Als Basis nutzen wir das offizielle postgres-Image. Das funktioniert so aber auch mit fast allen anderen (No-)SQL-Datenbanken mit offiziellen Clients. ::

:::BlogCode{.mb-5}

# --- Dockerfile ---
FROM postgres:latest-alpine

RUN apk add --update curl zip python3
RUN curl -sSL https://sdk.cloud.google.com | bash
ENV PATH $PATH:/root/google-cloud-sdk/bin

COPY backup.sh /
RUN chmod +x /backup.sh

:::

::GlobalParagraph Dieses container image ist bereits mit der psql-Client Anwendung vorbereitet. Zusätzlich benötigen wir aber noch die Tools, um Daten auf einem Google Cloud Storage abzulegen, sowie das Bash-Script, das das Backup anfordert und ablegen kann. Dieses container image muss gebaut und zugänglich gemacht werden. ::

::BlogCode{.mb-4}

# --- backup.sh ---

#!/bin/bash

if [ ! -z $DEBUG ]; then
    set -x
fi

# ENV variables for Postgres
HOSTNAME=$PG_HOSTNAME
PASSWORD=$PG_PASSWORD
USERNAME=$PG_USERNAME
DATABASE=$PG_DATABASE
OUTPUT_DIR="${PG_OUTPUT_DIR:-/pgbackup}"
NAME_PREFIX="${PG_PREFIX:-noprefix}"
ZIP_PASSWORD="${ZIP_PASSWORD:-setme}"
if [ $ZIP_PASSWORD = "setme" ]; then
    ZIP_PASSWORD=`cat /etc/gcp/zip-password`
fi
GS_STORAGE_BUCKET="${GS_BUCKET:-nonpublic}"

gcloud auth activate-service-account --key-file /etc/gcp/sa_credentials.json

date1=$(date +%Y%m%d-%H%M)
mkdir $OUTPUT_DIR
filename=$OUTPUT_DIR"/"$date1"-$NAME_PREFIX-$DATABASE.pg"

PGPASSWORD="$PASSWORD" pg_dump -h "$HOSTNAME" -p 5432 -U "$USERNAME" "$DATABASE" -Fc > $filename

du -h $filename

zip -r --encrypt -P $ZIP_PASSWORD $filename".zip" $filename
du -h $filename".zip"

gcloud storage cp $filename".zip" "gs://"$GS_STORAGE_BUCKET"/database/"$NAME_PREFIX"/"

::

::GlobalParagraph Dieses beispielhafte Bash-Script wird ausschließlich per Umgebungsvariablen gesteuert. Diese werden per Kubernetes Workload-Beschreibung eingebracht, z.B. über ein Kubernetes secret{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid}. Das Script unterstützt alle notwendigen Parameter um: ::

::GlobalBlock{.ol-decimal .mb-4}

1. sich zu einer PostgreSQL-Datenbank zu verbinden,
2. von dieser einen SQL-Dump (im portablen Postgres-Format) anzufordern,
3. diesen SQL-Dump zusätzlich per Zip-Passwort zu verschlüssel und nachvollziehbar zu benennen,
4. und schlussendlich in einen Cloud Storage Bucket hochzuladen. ::

::GlobalParagraph Wichtig: In diesem Beispiel wird ein Service Account{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} genutzt um Daten in das “-nonpublic”-Cloud Storage Bucket zu speichern. Hier unterscheiden sich die einzelnen Cloud-Anbieter in der Einrichtung des Service Accounts. In Google Kubernetes Engine wird anschließend das Service Account Token in einem Kubernetes secret hinterlegt und dann an den entsprechend Pod angehängt (unter /etc/gcp/sa_credentials.json). ::

::GlobalCallAnExpert{:bg="bg-bs-blue"} #buttonBlockTitle Du willst deine Backup-Strategie in Kubernetes richtig aufsetzen oder optimieren? ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Kubernetes CronJob zur Automatisierung ::

::GlobalParagraph Mit folgendem Kubernetes Workload-Objekt können wir schlussendlich einen regelmäßigen Job starten, der das Datenbank Backup nachvollziehbar ablegt. Die Notation von Kubernetes CronJobs kann in der Kubernetes Dokumentation nachgeschlagen{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} werden. ::

:::BlogCode{.mb-5}

apiVersion: batch/v1
kind: CronJob
metadata:
  name: pg-backup
spec:
  timeZone: "Europe/Berlin"
  schedule: "45 1 * * *"
  concurrencyPolicy: Forbid
  successfulJobsHistoryLimit: 0
  failedJobsHistoryLimit: 1
  jobTemplate:
    spec:
      template:
        spec:
          # this secret is manually created holding 1) the service account key, and 2) the zip-password string
          volumes:
            - name: gcs-service-account
              secret:
                secretName: gcsbackup
          containers:
            - name: pgbackup
              image: gcr.io/backup-images/pgbackup
              imagePullPolicy: Always
              command: ["/backup.sh"]
              volumeMounts:
                - mountPath: "/etc/gcp/"
                  name: gcs-service-account
                  readOnly: true
              env:
                - name: PG_DATABASE
                  valueFrom:
                    secretKeyRef:
                      name: shop-secret
                      key: DATABASE_NAME
                - name: PG_USERNAME
                  valueFrom:
                    secretKeyRef:
                      name: shop-secret
                      key: DATABASE_USER
                - name: PG_PASSWORD
                  valueFrom:
                    secretKeyRef:
                      name: shop-secret
                      key: DATABASE_PASSWORD
                - name: PG_HOSTNAME
                  valueFrom:
                    secretKeyRef:
                      name: shop-secret
                      key: DATABASE_HOST
                - name: PG_PREFIX
                  value: production
                # - name: DEBUG
                #   value: "on"
          restartPolicy: OnFailure

::: ::GlobalParagraph Auf diese Art und Weise können alle Parameter (z.B. die Backup-Kadenz, Zugänge) einfach per Kubernetes hinterlegt werden. Insbesondere bei einer Rotation des Passworts benötigt es also lediglich eine Anpassung im entsprechenden Kubernetes secret. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Code Backup mit GitHub Actions ::

::GlobalParagraph Nicht nur die beweglichen Daten müssen gespeichert werden, sondern auch die Code-Basis. Warum? Möglicherweise müssen statics (also Medien-Dateien, die Teil des Code sind, Logos, kleine Bilder, etc.) abgelegt werden oder aber die BCP sieht eben auch einen Plan für den Ausfall von GitHub vor. Natürlich ist von einem Ausfall von GitHub noch nicht der unmittelbare Betrieb der Anwendung betroffen, aber wenn es zu einem längeren Ausfall kommt, muss auch hier die Kontinuität sichergestellt werden. ::

::GlobalParagraph Glücklicherweise ist das Einrichten einer Backup-Action für ein Repository schnell eingerichtet. ::

:::BlogCode{.mb-5}

# --- .github/workflows/code_backup.yaml ---

name: Backup Repo to Google Storage Bucket
on:
  schedule:
    - cron: '0 0 * * 0'
  push:
    branches:
      - main
jobs:
  backup_repo:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write

    steps:
      - name: Checkout Repo
        uses: actions/checkout@v4

      - id: auth
        uses: google-github-actions/auth@v2
        with:
          credentials_json: ${{ secrets.GCP_CREDENTIALS }}

      - name: Set up Cloud SDK
        uses: google-github-actions/setup-gcloud@v2

      - name: Zip and Upload
        run: 'cd .. && zip --encrypt -P ${{ secrets.ZIP_PASSWORD }} -r our-backend.zip our-backend && gcloud storage cp our-backend.zip gs://-nonpublic/code/our-backend.zip'

:::

::GlobalParagraph Alle typischen Cloud-Anbieter stellen bereits eigene GitHub Actions bereit, um in einer GitHub Pipeline automatisch Daten in einem Cloud Storage Bucket abzulegen. In diesem Beispiel wird das Repository also ausgecheckt, auch wieder Zip-verschlüsselt und schließlich in das Cloud Storage Bucket hochgeladen. ::

{.object-cover .max-w-full .mb-5}

::GlobalParagraph Die verwendeten Umgebungsvariablen werden per Action Secrets in den Kontext eingefügt. ::

::GlobalTitle{:size="lg" .mb-5} Fazit: Kubernetes Backup Strategie für maximale Sicherheit :: ::GlobalParagraph Backups sind wichtig. In diesem Artikel habe ich einen Weg gezeigt, wie man mit Kubernetes, GitHub und einem Cloud Storage Bucket schnell und einfach ein Snapshot-Backup realisieren kann. Diese Backups können nun aus dem Cloud Storage wieder heruntergeladen werden, um sie auf anderen Speichermedien für die vorgegebene Zeit (und am besten nicht online) und für den Fall einer nötigen Wiederherstellung zu bewahren. ::

::GlobalParagraph Das Vorgehen, um eine Wiederherstellung durchzuführen, haben wir in diesem Artikel bewusst nicht behandelt, wollen das aber in einem der folgenden Artikel nachholen. ::

::GlobalParagraph Auch die Möglichkeiten von differentiellen Backups und Point-in-Time Backups wären eine sinnvolle Ergänzung. ::

::GlobalParagraph Aber was denkst du? Hast du Verbesserungsvorschläge oder bereits Erfahrungen mit diesem System gemacht? Lasst es uns unten in den Kommentaren wissen! ::

:::GlobalTitle{:size="lg" .mb-5 .mt-8} Häufige Fragen :::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 1. Warum brauche ich eine Backup-Strategie für Kubernetes? :: ::GlobalParagraph Kubernetes-Umgebungen sind dynamisch und bestehen aus vielen beweglichen Teilen. Datenbankeinträge, Code-Änderungen und Mediendateien können jederzeit verloren gehen – sei es durch Fehlkonfigurationen, Systemausfälle oder Cyberangriffe. Eine durchdachte Backup-Strategie stellt sicher, dass du deine Anwendungen und Daten schnell wiederherstellen kannst. :: ::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 2. Wie oft sollte ich ein Backup meiner Datenbank machen? :: ::GlobalParagraph Das hängt von deinen Anforderungen ab. Eine Snapshot-Strategie mit täglichen Backups ist für viele Anwendungen ein guter Start. Falls du eine hohe Datenänderungsrate hast, solltest du differenzielle oder Point-in-Time Backups in Betracht ziehen. Kubernetes CronJobs helfen dir, diese Automatisierungen effizient umzusetzen. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 3. Wo sollte ich meine Backups speichern? :: ::GlobalParagraph Cloud Storage ist eine der besten Optionen für sichere und skalierbare Backups. Google Cloud Storage, AWS S3 oder Azure Blob Storage bieten hohe Verfügbarkeit und integrierte Verschlüsselung. Alternativ kannst du Backups auf lokalen Servern oder externen Speichermedien ablegen, um eine zusätzliche Sicherheitsebene zu schaffen. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 4. Kann ich mit GitHub Actions auch meinen Code automatisch sichern? :: ::GlobalParagraph Ja! GitHub Actions kann genutzt werden, um automatische Code-Backups in ein Cloud Storage Bucket zu laden. So bist du abgesichert, falls es zu einem GitHub-Ausfall oder versehentlichen Löschvorgängen kommt. Unser Artikel enthält eine Beispiel-Workflow-Datei für dein Repository. ::

{.object-cover .max-w-full .mb-5}

:::globalParagraph “Cloud Native Kubernetes Development” a.k.a. wie kann ich möglichst viele techy Buzzwords in einen kurzen Blogtitel verpacken? Eigentlich möchte man auch noch “k8s” unterbringen, was als Kurzform für “Kubernetes” verwendet wird, aber wir wollen es auch nicht übertreiben. Um diesen Blogpost zu verstehen, wird ein gewisses Grundverständnis von Kubernetes vorausgesetzt. Falls das nicht gegeben ist, können wir diesen Comic von Google empfehlen. :::

{.object-cover .max-w-full .mb-5}

:::globalParagraph Nehmen wir an, du entwickelst ein neues Projekt, hast ein paar unabhängige Services darin identifiziert und bist zu dem Entschluss gekommen, dass es durchaus Sinn macht, diese in separate Container zu deployen und von Kubernetes orchestrieren zu lassen. Da es ein größeres Projekt ist, arbeiten mehrere Programmierer daran, die jeder für sich oder in kleinen Teams nur an je einem der Services arbeiten. :::

:::globalTitle{:size="lg" .mb-5} STATUS-QUO ::: :::globalParagraph Das gerade beschriebene Projektbeispiel hat sich mittlerweile zu einem durchaus üblichen Szenario entwickelt. Wie können wir nun gewährleisten, dass unsere Programmierer auch auf ihrem lokalen Laptop möglichst äquivalent zur Kubernetes-Architektur entwickeln können? Ein üblicher Weg, um Docker-Container lokal auszuführen ist docker-compose. Dieses ist vor allem in der Handhabung sehr einfach, hat aber den großen Nachteil, dass ein docker-compose-Setup nicht die letztendliche Production-Umgebung, also das Kubernetes-Setup abbildet. Im schlimmsten Fall hast du also etwas programmiert, das lokal in deinem docker-compose-Setup funktioniert, im Production-System dann aber nicht, da das Image anders ausgeführt wird. ::: :::globalParagraph Als Alternative wurden Technologien entwickelt, um Kubernetes Cluster auf dem lokalen Rechner zu simulieren. Minikube ist eine recht verbreitete Lösung, in letzter Zeit sind aber auch mehr und mehr Alternativen auf dem Vormarsch. Hier sind z.B. microk8s von Canonical zu nennen, oder k3s und k3d von Rancher, welche ressourcenschonender sind. K3d benutzt k3s, um mehrere Worker Nodes im lokalen Kubernetes-Cluster zu simulieren. Üblicherweise wird dann kubectl benutzt, um mit dem Cluster zu interagieren. ::: :::globalParagraph Als Entwickler musst du nun lediglich ein Docker-Image deines Services builden und deinen Kollegen zur Verfügung stellen. Diese können das Image in ihrem lokalen Cluster deployen und haben daraufhin den aktuellsten Stand deines Services lokal zur Verfügung. :::

:::globalTitle{:size="md" :tag="h4" .mb-5} ZWEI SPANNENDE HERAUSFORDERUNGEN SIND ZU DIESEM ZEITPUNKT ALLERDINGS NOCH OFFEN: ::: :::GlobalBlock{.ol-decimal .mb-5}

1. Wie kann ich an meinem Service arbeiten und stets den aktuellen Stand in meinem Cluster zur Verfügung haben, ohne ein neues Image builden und deployen zu müssen?
2. Wie kann ich lokal den Debugger verwenden? :::

:::globalTitle{:size="lg" .mb-5} KUBERNETES (CLOUD NATIVE) DEVELOPMENT BEI BLUESHOE ::: :::globalParagraph In den nächsten Abschnitten wollen wir uns anschauen, wie wir bei Blueshoe diese Herausforderungen meistern. Wir setzen dabei auf k3d als lokalen Kubernetes-Cluster sowie PyCharm als unsere Entwicklungsumgebung. Weiterhin nutzen wir Helm für das Management des Clusters sowie Telepresence um live Code-Reloading zu bewerkstelligen. Die folgenden Installationsbeispiele wurden alle auf einem aktuellen Ubuntu-System durchgeführt. :::

:::globalTitle{:size="md" .mb-5} K3D/K3S - “LIGHTWEIGHT KUBERNETES IN DOCKER” ::: :::globalParagraph k3d lässt sich sehr einfach installieren, Rancher stellt ein Installations-Script zur Verfügung: ::: :::BlogCode{.mb-5}

wget -q -O - https://raw.githubusercontent.com/rancher/k3d/master/install.sh | bash

:::

:::globalParagraph Die Installation von k3s ist ebenso simpel: ::: :::BlogCode{.mb-5}

curl -sfL https://get.k3s.io | sh -

:::

:::globalParagraph Ein neuer Cluster lässt sich mit folgendem Befehl anlegen: ::: :::BlogCode{.mb-5}

k3d create --api-port 6550 --publish 8080:80 --workers 2 --name buzzword-counter --enable-registry

::: :::globalParagraph Wir haben hier einen Cluster namens buzzword-counter erzeugt und u.a. den lokalen Port 8080 auf den Cluster-internen Port 80 gemappt, sodass wir unseren Cluster im Webbrowser unter dem Port 8080 erreichen können. Zusätzlich ermöglichen wir mit der Flag --enable-registry, dass lokale Docker-Images im Cluster deployed werden können. Die lokale Registry ist ein gewöhnlicher Docker-Container, der sich z.B. nach einem Neustart des Rechners mit "docker restart <>" wieder starten lässt. Dafür benötigen wir zusätzlich einen entsprechenden Eintrag in unserer /etc/hosts Datei: ::: :::BlogCode{.mb-5}

[...]
127.0.0.1     registry.local
[...]

::: :::globalParagraph Damit wir mittels kubectl mit unserem Cluster interagieren können, können wir entweder die KUBECONFIG-Umgebungsvariable exportieren oder den Inhalt der entsprechenden Datei in ~/.kube/config integrieren: ::: :::BlogCode{.mb-5}

export KUBECONFIG="$(k3d get-kubeconfig --name='buzzword-counter')"

:::

:::globalTitle{:size="md" .mb-5} HELM - “KUBERNETES PACKAGE MANAGER” ::: :::globalParagraph Wir benutzen oftmals Helm, um unsere Kubernetes Cluster zu managen. Helm beschreibt sich selbst als Package Manager für Kubernetes und ermöglicht auch die Abbildung komplexer Kubernetes Anwendungen in Templates. Das Buzzword lautet hier “Infrastructure as Code”. Durch die Templates kann unsere Anwendung jederzeit ohne größeren Aufwand in einen neuen Kubernetes Cluster deployed werden. Um Helm zu installieren, kann man einfach eine Binary-Datei herunterladen: Zum Download. :::

:::globalTitle{:size="sm" :tag="h4" .mb-5} BEISPIEL-DEPLOYMENT BUZZWORD-COUNTER ::: :::globalParagraph Um ein praktisches Beispiel zeigen zu können, haben wir ein simples Deployment für diesen Blog-Post erstellt und auf Github bereitgestellt: ::: :::globalParagraph BUZZWORD COUNTER ::: :::globalParagraph BUZZWORD CHARTS ::: :::globalParagraph Dieses Deployment enthält eine einfache Django-Anwendung, eine Celery Distributed Task Queue mit rabbitmq als Message Broker, um asynchrone Tasks abzuarbeiten, sowie eine PostgreSQL Datenbank. Mittels unserer Anwendung können wir Buzzwords zählen und auch neue Buzzwords hinzufügen. Letzteres ist als Celery-Task implementiert, was in diesem Beispielszenario zwar recht unnötig ist, aber die Funktionsweise unserer Celery Distributed Task Queue bestens demonstriert. ::: :::globalParagraph Der erste Schritt des Deployments ist das Bereitstellen der Anwendung als Docker-Image. Dazu müssen wir zunächst das Docker-Image builden (aus dem Verzeichnis der Django Anwendung) und in unsere lokale Registry pushen: ::: :::BlogCode{.mb-5}

docker build -t registry.local:5000/buzzword-counter:0.1.0 .
docker push registry.local:5000/buzzword-counter:0.1.0

::: :::globalParagraph Mit folgenden Befehlen (aus dem Verzeichnis der Helm Charts) wird die Anwendung mit der PostgreSQL- und der rabbitmq-Dependency im Kubernetes-Cluster installiert und konfiguriert: ::: :::BlogCode{.mb-5}

helm repo add bitnami https://charts.bitnami.com/bitnami
helm dep build buzzword-counter
helm install buzzword-counter buzzword-counter/

::: :::globalParagraph Mittels kubectl können wir uns z. B. anschauen, ob die Pods verfügbar sind, oder auch den Log-Output anzeigen lassen und verifizieren, dass einerseits der Runserver auf dem Web-Pod sowie der Celery-Worker auf dem Worker-Pod gestartet wurde: ::: :::BlogCode{.mb-5}

kubectl get deployments
kubectl get pods
kubectl logs -f buzzword-counter-web-XXXXX-XXXXXXXX
kubectl logs -f buzzword-counter-worker-XXXXX-XXXXXXXX

::: :::globalParagraph Nun haben wir also einen lokalen Kubernetes-Cluster, in dem unsere Anwendung installiert und konfiguriert ist. Damit wir unsere Seite lokal erreichen können, müssen wir noch folgende drei Befehle ausführen, die uns der Output von helm install ausgegeben hat: ::: :::BlogCode{.mb-5}

export POD_NAME=$(kubectl get pods --namespace default -l "app.kubernetes.io/name=buzzword-counter,app.kubernetes.io/instance=buzzword-counter" -o jsonpath="{.items[0].metadata.name}")
echo "Visit http://127.0.0.1:8080 to use your application"
kubectl --namespace default port-forward $POD_NAME 8080:80

::: :::globalParagraph Daraufhin können wir unseren Service auf der angegebenen URL erreichen. Starten wir einen Task, können wir uns dessen Output mittels kubectl im Log des Worker-Pods ansehen: ::: :::BlogCode{.mb-5}

kubectl logs -f buzzword-counter-worker-XXXXX-XXXXXXXX

:::

{.object-cover .w-full .mb-5}

:::globalTitle{:size="md" .mb-5} TELEPRESENCE - “FAST, LOCAL DEVELOPMENT FOR KUBERNETES” ::: :::globalParagraph Um live Code-Reloading zu erreichen, d.h. um Code-Änderungen, die wir in PyCharm tätigen, sofort im Cluster verfügbar zu haben, verwenden wir Telepresence. Telepresence ist ein sogenanntes Sandbox-Projekt der CNCF, der Cloud Native Computing Foundation. Ohne live Code-Reloading müssten wir nach jeder Änderung ein neues Docker-Image builden und im Cluster deployen, was umständlich und auf Dauer zeitintensiv ist. ::: :::globalParagraph Mittels Telepresence kannst du nun ein Docker-Image, das du lokal gebaut hast, in einem Cluster ausführen, indem ein Deployment “geswapt” wird. Technisch ist das durchaus spektakulär, für diesen Blog-Post genügt es jedoch, dass wir mit einem Command unser Buzzword-Counter-Web-Deployment unseres Kubernetes-Clusters austauschen können und stattdessen das angegebene Docker-Image ausgeführt wird. Zuvor müssen wir noch das Docker-Image bauen. Für beide Befehle müssen wir im Verzeichnis des Source Codes unserer Django-Anwendung sein: ::: :::BlogCode{.mb-5}

docker build -t buzzword-counter:local .
telepresence --swap-deployment buzzword-counter-web --expose 8080 --docker-run --rm -it -v $(pwd):/code buzzword-counter:local python manage.py runserver 0.0.0.0:8080

:::

:::globalParagraph Mit der Flag “-v $(pwd):/code” haben wir zusätzlich das aktuelle Verzeichnis in den Docker-Container gemounted, sodass die Code-Änderungen in PyCharm auch im Kubernetes-Cluster verfügbar sind. Da wir den Django-Runserver benutzen, funktioniert das live Reloading allerdings nur, wenn DEBUG=True gesetzt ist. Das können wir entweder über die Helm-Charts deployen oder einfach in unserem geswappten Deployment exportieren. Danach führen wir das run-Script aus: ::: :::BlogCode{.mb-5}

export DJANGO_DEBUG=True
/usr/src/run_app.sh

::: :::globalParagraph Wenn wir den Container swappen, müssen wir wieder die drei Befehle von oben für den port-forward des Pods ausführen. Daraufhin können wir Code in PyCharm ändern und einerseits im Log oder durch das Aufrufen der Seite im Browser verifizieren, dass der Runserver neu gestartet wurde: :::

{.object-cover .w-full .mb-5}

:::globalParagraph Wer genauer hinschaut, wird feststellen, dass Telepresence nicht auf einen lokalen Cluster beschränkt ist. Es lassen sich auch Deployments von remote Clustern swappen, sofern der Zugriff mittels kubectl möglich ist. Das kann z.B. zum Debuggen und Nachvollziehen von Bugs auf Test-Systemen sehr nützlich sein. Allerdings ist hier Vorsicht geboten, denn jeder Traffic des Deployments wird nach dem Swappen auf den lokalen Laptop geleitet. Das heißt dieses Vorgehen bietet sich maximal für Test-Systeme an und sollte bei den allermeisten Produktiv-Systemen tunlichst gemieden werden. :::

:::globalTitle{:size="md" .mb-5} PYTHON REMOTE DEBUG IN PYCHARM :::

:::globalParagraph Mittlerweile können wir also unsere Anwendung im lokalen Kubernetes-Cluster mit live Code-Reloading deployen. Wir haben unsere gebuzzwordete Mission erfüllt, die Production-Kubernetes-Umgebung ist lokal nachgebildet und wir können cloud native an unserem Service entwickeln. Das i-Tüpfelchen ist nun noch den PyCharm Debugger so zu konfigurieren, dass wir unsere Anwendung auch direkt in PyCharm debuggen können. Hierzu müssen wir zuerst Python Remote Debug in PyCharm konfigurieren: :::

{.object-cover .w-full .mb-5}

:::globalParagraph Zu beachten ist das Pfad-Mapping, denn hier muss unbedingt ein absoluter Pfad angegeben werden (der ~-Shortcut für das Home-Verzeichnis funktioniert nicht). Wie oben im Bild zu sehen ist, benötigt die Konfiguration außerdem eine spezifische Version des Python-Packages pydevd-pycharm. ::: :::globalParagraph Um zu verhindern, dass dieses Paket unnötig in unserem Production-Deployment ist, erzeugen wir ein zweites Dockerfile, das erweiterte pip-Requirements installiert. Weiterhin haben wir einen simplen View zu unserer Anwendung hinzugefügt (in urls.py), damit wir bequem per URL die Verbindung zwischen unserem Cluster und dem PyCharm Debugger herstellen können. Hier ist insbesondere darauf zu achten, dass die IP-Adresse und der Port mit der Konfiguration in PyCharm übereinstimmen. ::: :::BlogCode{.mb-5}

docker build -f Dockerfile.dev -t buzzword-counter:debug .
telepresence --swap-deployment buzzword-counter-web --expose 8080 --docker-run --rm -it -v $(pwd):/code buzzword-counter:debug bash

::: :::globalParagraph Daraufhin browsen wir die Debug-URL an. Auch hier müssen wir wieder daran denken, dass DEBUG=True gesetzt ist und wir den port-forward durchgeführt haben. Nun können wir auch schon einen Breakpoint in PyCharm setzen. Browsen wir den entsprechenden View an, wird die Ausführung durch den Debugger angehalten und wir können genauer untersuchen, warum ein Reduzieren des Counters diesen entweder auf 0 zurücksetzt oder sogar ein IntegrityError kommt: :::

{.object-cover .w-full .mb-5}

:::globalTitle{:size="lg" .mb-5} FAZIT ::: :::globalParagraph Mittels der Tools k3d/k3s, Helm, Telepresence und Python Remote Debug haben wir also das Brett namens “Cloud Native k8s Development” komplett durchbohrt. Unsere Entwickler können nun alle munter in ihrem eigenen lokalen Kubernetes-Cluster entwickeln. Vor allem Telepresence in Kombination mit Python Remote Debug ist eine sehr praktische Lösung. ::: :::globalParagraph Dennoch muss man festhalten, dass die Handhabung der Tools nicht ganz simpel ist bzw. eine gewisse Einarbeitungszeit benötigt. Vor allem im Vergleich zu docker-compose ist die Hürde wesentlich höher. Hier fehlt noch etwas, das die genannten Tools kombiniert und sich dennoch ohne große Einstiegshürde bedienen lässt. Bleibt gespannt, wir bei Blueshoe haben in letzter Zeit an einer Lösung gebastelt, die sich intern bereits bewährt hat. Demnächst werdet ihr auch in unserem Blog mehr davon lesen! ::: :::globalParagraph Abschließend natürlich noch der Buzzword-Counter: Ich bin insgesamt auf 23 unique Buzzwords gekommen. Hast du mitgezählt und bist auf einen anderen Wert gekommen? Dann lass es uns doch einfach in einem Kommentar wissen. :::

Wir betrachten diese Fragen und geben einen Überblick über Kubernetes und verwandte Themen. Nicht bis ins kleinste Detail, aber so, dass auch Nicht-Entwickler verstehen, was Kubernetes ist.

{.object-cover .max-w-full .mb-5}

Was ist Kubernetes

Kubernetes selbst ist keine Dienstleistung, die einzelne Anbieter anbieten. Vielmehr ist Kubernetes eine open-source Technologie, um Applikationen, die in Containern verpackt sind, zu managen und zu orchestrieren.

Theoretisch kann Kubernetes kostenlos auf GitHub heruntergeladen werden und wird dann auf lokalen Servern oder öffentlich (z.B. für einen Kunden) bereitgestellt.

Zusätzlich gibt es kostenpflichtige Angebote, die Kubernetes als open-source Technologie nutzen, aber darüber hinaus noch weitere Services zur Vereinfachung und Erweiterung von Kubernetes bereitstellen. Die bekanntesten Beispiele dafür sind Azure Kubernetes Service (AKS), Google Kubernetes Engine (GKE) oder Amazon Elastic Kubernetes Service (EKS). Die Nutzung dieser Services wird wahrscheinlich von den meisten Entwicklern genutzt werden.

Kubernetes ist in all diesen Angeboten weiterhin kostenlos, nicht aber die Cloud-Ressourcen oder Oberflächen, die die Anbieter bereitstellen. Die Kosten für die Verwaltung von EKS, AKS oder GKE sind oft gering, die Rechen- und Speicherkosten für Ressourcen, die die Dienste für Cloud-Ressourcen oder Oberflächen erheben, können sich aber schnell summieren.

Back to the roots: Monolithen vs. Microservices

Sehr vereinfacht gesagt gibt es in der Software-Entwicklung 2 Ansätze, um Software zu entwickeln: den monolithischen Ansatz und den Bau von Microservices.

Bei Monolithen sind alle relevanten Bestandteile in einer Applikation enthalten. Bei Microservices gibt es für jeden Bestandteil dagegen jeweils eine eigenständige Applikation, die nur einen eng umrissenen Aufgabenteil bearbeitet. Benötigt ein Microservice zur Erledigung seiner Aufgaben Input eines anderen Microservice, kommunizieren die einzelnen Microservices via Schnittstellen untereinander. Ein Vorteil von Microservices gegenüber einer monolithischen Architektur ist, dass, sollte ein Microservice ausfallen, nicht zwangsläufig das ganze System nicht mehr einsatzbereit ist. Es gibt aber nicht das überlegene Verfahren. Blueshoe nutzt bei seiner Arbeit meist Microservices, da für unsere Zwecke hier die Vorteile überwiegen.

Zur Nutzung von Kubernetes ist es nicht notwendig, dass Microservices genutzt werden. Kubernetes kann auch zum Betreiben von Monolithen herangezogen werden.

Für die Nutzung von Kubernetes ist es aber unabdingbar, dass die Softwareanwendung in einen Container verpackt ist - und das geht mit Monolithen und Microservices.

{.object-cover .max-w-full .mb-5}

Back to the roots: Container

Um auch Nicht-Entwicklern eine kurzen Einblick zu geben, warum Container genutzt werden, wollen wir ganz kurz und vereinfacht darauf eingehen.

Bei Software-Containern handelt es sich auch buchstäblich um Container. Sie bilden eine vordefinierte Umwelt, in der Code ausgeführt werden kann. Ein Container enthält also nicht nur Software, sondern bietet auch die Möglichkeit, die Umgebung, in der die Software ausgeführt wird (also den Container), vorzukonfigurieren. Bevor die Praxis der containerisierten Software aufgekommen ist, musste Software immer in unterschiedlichen Umgebungen ausgeführt werden, z.B. auf verschiedenen Computern. Es bestand also nicht nur die Herausforderung, dass die Software an sich fehlerfrei sein musste, sondern jede Umgebung musste auch gleich konfiguriert sein. Mit der Containerisierung von Software stellt der Container selbst die Umgebung dar, in der die Software ausgeführt wird. Der Container kann also auf unterschiedlichen Servern betrieben werden, ohne dass die einzelnen Server jeweils einzeln konfiguriert werden müssen.

Der bekannteste Anbieter, der das Verpacken von Software in Containern erlaubt, ist Docker. Daraus ergeben sich also "Docker Container." "Container" wird also oft mit "Docker-Container" synonym verwendet. Für die Nutzung von Kubernetes ist es notwendig, dass Software in Container verpackt ist. Mit welcher Technik das herbeigeführt wird, ist nicht relevant.

Wie groß die einzelnen, in Container verpackten Applikationen dabei sind (siehe oben: monolithische Architektur vs. Microservices) ist ebenfalls nicht relevant - Kubernetes kann für beide Ansätze genutzt werden.

Die Software, die in einen Container verpackt wurde, wird an einem definierten Ort abgelegt. Das wird als Docker-Image bezeichnet. Wird die Software ausgeführt, wird immer auf dieses Image referenziert. Die Software kann also in mehreren Instanzen ausgeführt werden, wenn auf dasselbe Image referenziert wird.

Was Kubernetes genau macht

Die open-source Technologie Kubernetes erlaubt es, Container in einem definierten Umfeld zu verwalten. Dieses Umfeld muss sich von seiner Umgebung klar abgrenzen, also einen so genannten Cluster bilden und auf einem lokalen System oder z.B. einer öffentlichen Cloud (die für Kunden zugangsbeschränkt werden kann) hergestellt werden.

Ein Cluster ist ein Zusammenschluss von verschiedenen Teilelementen, die zur Ausführung der Kubernetes Technologie benötigt werden, zum Beispiel Nodes, Pods, etc. Eine Node entspricht dabei einem Server, der eine Softwareapplikation ausführt. Damit eine Node eine Softwareapplikation ausführen kann, muss die Software in einem Container verpackt sein und in der Node bereitgestellt werden (mehr dazu später).

"Server vs. Node" oder: "pet vs. cattle"

Ohne die Nutzung von Kubernetes wird Software direkt auf einem Server ausgeführt. Die Software ist dabei nur auf diesem einen Server verfügbar. Ist der Server nicht mehr erreichbar, kann auch die Software nicht mehr ausgeführt werden.

Neben der Pflege der eigentlichen Software ist bei dieser Lösung die Serverpflege essentiell. Der Server ist damit wie ein pet - ein Haustier. Er wird gehegt und gepflegt, es soll ihm gut gehen, er soll lange leben und nie krank werden. Alles, damit der Server die Software stabil ausliefern kann.

Demgegenüber ist eine Node ein anonymes Arbeitstier oder eine Drohne - also ein cattle. Nur eine Nummer, ohne Namen, ohne Gesicht. Stirbt ein Arbeitstier, wird es, ohne Aufsehen zu erregen, direkt durch ein anderes ausgetauscht. Viele Arbeitstiere bilden eine Herde anonymer Individuen. Analog dazu bilden mehrere Nodes einen Cluster.

Wird Software auf einem individuellen Server ausgeführt und der Server ist nicht mehr erreichbar, kann die Software auch nicht mehr ausgeführt werden, der Service ist für die User nicht mehr nutzbar. Ist die Node, auf der eine in Containern verpackte Applikation ausgeführt wird, nicht mehr erreichbar, kann der Container sehr schnell auf eine andere Node transferiert und damit die Software weiter ausgeführt werden.

Für die Verschiebung eines Containers in eine andere Node sorgt dabei Kubernetes "ganz von selbst". Kubernetes ist im Beispiel also wie ein Aufseher, der dafür sorgt, dass immer ein Arbeitstier zur Verfügung steht, das die Applikation trägt. Kubernetes wird auch oft als ein Dienst bezeichnet, der Container orchestriert, indem er die Container wie ein Dirigent verfügbaren Nodes zuordnet.

Alternativen zu Kubernetes

Kubernetes ist nicht der einzige Dienst, um die Ausführung von Software in Container auf virtuellen Maschinen (den Nodes) zu orchestrieren. Neben Kubernetes gibt es noch eine ganze Reihe anderer Anbieter: Docker Swarm, Nomad oder Kontena seien hier als Alternativen genannt. Hier gibt es einen Überblick über die Vor- und Nachteile dieser und weiterer Applikationen im Vergleich zu Kubernetes{target="_blank"}. (Stand: 19.05.2022):

Warum Kubernetes nutzen?

Kubernetes bietet unbestreitbar viele Vorteile - aber gleichzeitig auch einige Nachteile. Ob Kubernetes genutzt werden soll oder nicht, will also gut überlegt sein.

Wir haben hier einige Argumente für und gegen Kubernetes zusammengetragen.

{.object-cover .max-w-full .mb-5}

Jedem Vorteil von Kubernetes kann auch ein Nachteil zugeordnet werden. Eine einfache Antwort auf die Frage "Soll ich Kubernetes nutzen?" gibt es also nicht. Jede Antwort ist so individuell wie jede Software oder jeder Kunde von Blueshoe.

Wir bei Blueshoe haben uns aus folgenden Gründen entschieden Kubernetes als Erste-Wahl-Lösung zur Orchestrierung von Applikationen in Container zu nutzen:

• Die Projekte, die wir betreuen bringen meist so komplexe Applikationen hervor, das sich der Einsatz von Kubernetes lohnt
• Unsere Entwickler können nicht alle alternativen Produkte, die es zur Orchestrierung von containerisierter Software gibt, gleich gut beherrschen. Wir haben uns entschlossen, Kubernetes-Experten zu werden. Unser Wissen dabei können wir auf viele Projekte übertragen. Die Ramp-up-Phase für uns war hoch, aber wir profitieren nun davon
• Kubernetes wird von (fast) allen Cloud-Anbietern unterstützt - anders als alternative Systeme zur Orchestrierung von containerisierter Software. Damit sind unsere Kunden bei der Anbieterwahl nicht beschränkt.

Soll man Kubernetes selbst hosten oder einen managed Service in Anspruch nehmen?

Wie oben beschrieben handelt es sich bei Kubernetes um eine open-source Technologie, die Nutzung ist also grundsätzlich (lizenz)kostenfrei und kann vollkommen selbstständig gehostet werden. AKS, GKE, EKS oder andere Anbieter haben dazu gemanaged Services im Angebot, die die Nutzung von Kubernetes erleichtern sollen. Die Nutzung dieser Services ist das, was die Anbieter in Rechnung stellen.

Was also tun? Selbst hosten oder Geld für einen managed Service bezahlen?

Dabei sind zwei Faktoren zu berücksichtigen: Einerseits der Faktor, welche "Hardware" und welche Services die Anbieter bereitstellen. Diesen Aspekt haben wir in unserem Blogpost "Managed vs. Unmanaged Kubernetes" bereits zusammengestellt.

Andererseits darf nicht vergessen werden, dass auch die Personalkosten für die Verwaltung eines vollständig selbst-gehosten Kubernetesclusters nicht zu vernachlässigen sind. Hier wird anschaulich verdeutlicht, dass wenn ein Cluster 24/7 gewartet werden muss, zumindest 4 Vollzeit-beschäftigte Entwickler vorgehalten werden sollen um auch Urlaubs- und Krankheitszeiten kompensieren zu können. Es wird davon ausgegangen, dass bei der Nutzung eines gemanagten Services, der zwar auch durch einen Entwickler betreut wird, eine Vollzeitstelle genügt.

Zu bedenken ist außerdem, dass die Kostenstruktur für Nodes, Rechenleistungen, etc. bei den einzelnen Anbietern zum Teil sehr undurchsichtig ist. Welche Kosten hier genau auf einen zukommen hängt wesentlich vom Umfang der zu verarbeitenden Informationen und der dafür notwendigen Rechenleistung ab. Die Kosten sind oft so dargestellt, dass es für Personen, die nicht mit der technischen Entwicklung und/oder Umsetzung von Software (z.B. Fachabteilungen) vertraut sind, kaum zu beurteilen ist, wie hoch die notwendigen Kapazitäten sind und welche Kosten anfallen werden. So können die Kosten beispielsweise je nach spontanem Nutzeraufkommen sehr stark variieren, da dadurch wesentlich mehr Rechenkapazität benötigt wird. Eine grobe Kostenschätzung für einen managed Service sollte auch immer mit einem inhaltlich involvierten Entwickler vorgenommen und nicht zu knapp kalkuliert werden.

Was man zum Bau von Kubernetes braucht

Im zweiten Teil wollen wir nun zu Kubernetes selbst kommen. Dabei sollen Begrifflichkeiten geklärt und aufgezeigt werden, wie diese im Einzelnen zusammenhängen.

Hier findet sich ein guter erster Überblick sowohl für Nicht-Entwickler als auch für Entwickler, die sich zum ersten Mal mit Kubernetes befassen{target="_blank"}. Wir greifen im Folgenden hauptsächlich auf diese Quelle zurück.

Cluster

Kubernetes kann nur in einem definierten Umfeld verwendet werden. Der Cluster selbst kann nicht mit Kubernetes gleichgestellt werden. Kubernetes bietet als Technologie aber die Möglichkeit, einen Cluster zu erstellen, der verschiedene Bestandteile gegen seine Umgebung abgrenzt.

Im Kontext von Kubernetes ist ein Cluster also ein Zusammenschluss von verschiedenen Bestandteilen, die für die Nutzung von Kubernetes benötigt werden, der klar von der Umwelt abgegrenzt ist. Neue Bestandteile (z.B. neue Nodes) müssen dem Cluster explizit durch einen Entwickler zugeordnet werden und können nicht automatisch in den Cluster gelangen.

{.object-cover .max-w-full .mb-5}

Node

Eine Node ist eine virtuelle Maschine oder ein physischer Computer. Eine Node ist der Bestandteil des Clusters, der die in Container verpackte Software ausführt. Die containerisierte Software selbst wird über Pods auf die Node gebracht.

Die Node selbst besitzt kleinere Applikationen um diese Arbeit auch durchführen zu können:

• Kubelet: Jede Node besitzt ein sogenanntes Kubelet, der die Node selbst managt und via API mit dem Control Plane kommuniziert
• Tools um die Container innerhalb der Node zu betreiben: Die Node stellt Platz zur Verfügung, um die containerisierte Software zu beherbergen. Allerdings kann es notwendig werden, dass Arbeiten an der containerisierten Software durchgeführt werden. Um die Software auf der Node bearbeiten zu können (z.B. zu starten) verfügt die Node über Tools, um die Software, die im Container auf der Node liegt, ansprechen zu können. In der Darstellung werden Docker-Container genutzt. Aus diesem Grund handelt es sich um ein spezielles Tool, um Docker-Container zu verwalten.

Zusätzlich können Nodes Pods umfassen, die wiederum containerisierte Software beinhalten. Dazu aber später mehr.

Control Plane

Der Control Plane ist das Herzstück von Kubernetes, die ausführende Kubernetes-Instanz (sozusagen die Schaltzentrale), die alle Aktivitäten im Cluster koordiniert. Ein Control Plane ist ebenfalls eine Node, allerdings mit der speziellen Aufgabe, den Cluster zu koordinieren.

Der Control Plane stellt eine API zur Verfügung, um mit den anderen Clusterbestandteilen zu kommunizieren.

Pods

Der Begriff "Pod" gehört bestimmt zu denjenigen, die im Kubernetes-Umfeld am meisten Verwendung finden. Pods haben nichts mit Star Wars zu tun, sondern sind die kleinsten Einheiten im Kubernetes-Universum.

Pods als kleinste eigenständige Einheiten im Cluster fassen mehrere Elemente sinnhaft zusammen, die im Deployment-Prozess in den Cluster gebracht werden. Pods sind also "Hülsen" und können beispielsweise folgende Elemente umschließen:

• geteilte Speichereinheiten, z.B. Volumes
• cluster-spezifische IP-Adressen
• Informationen darüber, wie Container betrieben werden, z.B. Image-Versionen der Applikation, Informationen zu Ports, etc.

Jeder Pod verfügt dabei über eine eigene IP-Adresse, die nur innerhalb des Clusters bekannt ist. Das heißt, die einzelnen Pods können nur im Cluster angesprochen und nicht von außen gesteuert werden.

Eine Node kann mehrere Pods beherbergen. Jeder Pod ist immer nur einer Node zugeordnet und verbleibt bei dieser Node bis sie gelöscht wird oder aufgrund anderer Fehler "stirbt". Passiert das,"stirbt" auch der Pod. Wenn das passiert, kann durch den Deployment-Prozess (siehe unten) der Pod auf einer anderen Node aber neu erzeugt werden und somit "ewig leben".

{.object-cover .max-w-full .mb-5}

{.object-cover .max-w-full .mb-5}

Replica-Sets und der Deployment-Prozess

Mit Node, Control Plane und Pods haben wir jetzt die einzelnen Bestandteile des Cluster besprochen. Aber wie agieren die einzelnen Bestandteile miteinander und wie tragen sie dazu bei, dass von Entwicklern geschriebener Code korrekt ausgeführt wird?

Dafür ist der Deployment-Prozess zuständig. Erst mit dem Deployment bringen Entwickler den Code in den Cluster. Im Deployment-Prozess wird beschrieben, wie oft einzelne Softwarebestandteile im Cluster ausgeführt werden sollen.

Hier wird beispielsweise beschrieben, welche Software ausgeführt werden soll. Die Software ist in ein Container-Image verpackt und das Image ist an einer definierten Stelle abgelegt (siehe oben). Wird im Deployment beschrieben, dass die Software einmalig ausgeführt werden soll, ist die Anzahl des Replica-Sets = 1 und es wird dafür ein Pod etabliert. Soll die Software öfters ausgeführt werden, ist die Anzahl des Replica-Sets beispielsweise =3. Im Replica-Set werden nun 3 Pods etabliert, die jeweils auf dasselbe Container-Image referenzieren.

Ist das Replica-Set = 3 und umfasst somit 3 Pods, können diese 3 Pods auf derselben Node ausgeführt werden. Alle drei Pods führen über die Referenz zum Container-Image mit demselben Code dann zwar dieselbe Software aus, es handelt sich aber um unterschiedliche Pods. Somit bleibt die oben beschriebene Prämisse bestehen, dass jeder Pod nur einmalig im Cluster enthalten sein kann und immer nur einer Node zugeordnet ist.

Ein Deployment kann mehrere Replica-Sets umfassen, die auf unterschiedliche oder auch dieselbe Software referenzieren.

Wie zuvor beschrieben bietet der Deployment-Prozess den Vorteil, dass, sollte eine Node z.B. gelöscht werden oder fehlerhaft sein, der Pod mit der beinhalteten Software auf einer anderen Node erneut erstellt werden kann. Die Information, wie ein Pod im Cluster ausgeführt werden soll, ist im Deployment beschrieben. Durchgeführt wird der Schritt, den Pod einer Node zuzuordnen durch einen Service (siehe unten).

Um das Deployment zu starten und zu managen, wird bei Kubernetes das Command-Line-Interface genutzt - das Kubectl. Kubectl ist für Nicht-Entwickler aber weniger relevant, die Bezeichnung sollte aber an dieser Stelle einmal erwähnt werden.

{.object-cover .max-w-full .mb-5} {.object-cover .max-w-full .mb-5}

Service, Label und Selector

{.object-cover .max-w-full .mb-5}

Ein Service in Kubernetes hat nichts mit einem "managed Kubernetes-Service" (siehe oben) zu tun, sondern ist ein Bestandteil im Cluster. Ein Service kann als eine Abstraktion verstanden werden, die Pods logisch zusammenfasst und definiert, wie die Pods miteinander interagieren können. Dabei interagieren die Pods nicht direkt miteinander. Vielmehr können den Pods Labels zugeordnet werden. Der Service verfügt dabei über den komplementären Selector. Über die Labels am Pod und die Selektoren am Service können Pods miteinander interagieren.

Der Cluster im Überblick

Zusammengefasst besteht ein Cluster aus mehreren Nodes, wovon eine Node den Control Plane darstellt.

Die Software, die im Cluster ausgeführt werden soll, ist in einen Container verpackt und als Container-Image an einem definierten Ort festgelegt. Im Cluster selbst wird also nicht die Software selbst abgelegt, sondern immer nur auf das Container-Image referenziert.

Im Deployment-Prozess wird beschrieben, welche Software in welcher Form (z.B. wie oft) ausgeführt werden soll. Dafür werden ein oder mehrere Replica-Sets angelegt. Der Deployment-Prozess ist auf dem Control Plane abgelegt.

Nach dem Deployment werden die im Deployment-Prozess definierten Pods im Cluster angelegt und auf die verschiedenen Nodes verteilt.

Services im Cluster verfügen über Selektoren, Pods können über die komplementären Labels zu den Selektoren verfügen. Durch dieses Schlüssel-/Schloss-Prinzip ist es möglich, dass die Pods miteinander in Interaktion stehen. Nur wenn ein Pod über ein Label verfügt, kann er mit anderen Pods interagieren, ansonsten steht der Pod für sich alleine.

{.object-cover .max-w-full .mb-5}

Clustergröße

Der Vorteil von Kubernetes ist, dass das System erkennen kann, wann eine Node (= virtuelle Maschine) nicht mehr betriebsbereit ist. Anstatt dass die Software dann nicht mehr ausgeführt werden könnte (wie das der Fall wäre, würde die Software auf einem einzelnen Server ausgeführt werden), kann Kubernetes die Software im Container automatisiert einer anderen funktionsfähigen Node zuordnen. Aus diesem Grund sollte ein Cluster im Produktivsystem aus mind. 3 Nodes bestehen: Davon ist eine Node der notwendige Control plane, die anderen beiden Nodes beherbergen die auszuführende Software in Pods. Ein Pod läuft dabei nur auf einer Node, die verbleibende Node steht dann "nur" für den Fall bereit, dass die andere ausfällt.

Zusammenfassung

Kubernetes selbst ist eine open-source-Software, die von jedem kostenfrei genutzt werden kann. Es handelt sich dabei um einen Dienst, der Software ausführt und gegenüber dem Betrieb von eigenständigen Servern eine ganze Reihe Vorteile bietet.

Anbieter wie AKS, GKE oder EKS stellen darüber hinaus weitere Services in Zusammenhang mit Kubernetes bereit, die die Administration erleichtern sollen. Für diese Services fallen aber eine ganze Reihe von Kosten an, die nicht leicht zu überblicken sind.

Kubernetes bezeichnet eine Technologie, die eine Reihe einzelner Komponenten umfasst. Erst im Zusammenspiel von Nodes, Pods und dem Control Plane kann ein Cluster erstellt werden, der zum Betrieb von Kubernetes notwendig ist.

Kubernetes ist kein Allheilmittel, das für jede Software gleichermaßen geeignet ist. Ob Kubernetes für den Betrieb einer speziellen Software oder für eine Organisation als ganze geeignet ist und ob die Services von AKS, GKE, EKS oder anderen hinzugekauft werden sollen, muss im Einzelfall beurteilt werden.

Wir hoffen, wir konnten euch einen guten Überblick geben, was Kubernetes ist, wie es sich von anderen Technologien zum Ausführen von Software unterscheidet und dass ein Pod in der Kubernetes-Welt nichts mit Podrennen in Star Wars Filmen zu tun hat.

{.object-cover .max-w-full .mb-5}

Einführung (Was ist das, warum brauchen wir es)

Standardmäßig halten Logs in Kubernetes nur während der Lebensdauer eines Pods. Um Logs länger als die Lebensdauer eines einzelnen Pods aufzubewahren, verwenden wir Log-Aggregation. Das bedeutet, dass wir Logs aus verschiedenen Quellen an einem einzigen Ort speichern, um sie auch nach einem Fehler leicht analysieren zu können. Während der ELK-Stack (kurz für Elasticsearch, Logstash, Kibana) eine beliebte Lösung für die Log-Aggregation ist, haben wir uns für etwas leichtgewichtigeres entschieden: Loki.

Entwickelt von Grafana Labs, ist "Loki ein horizontal skalierbares, hochverfügbares, mandantenfähiges Log-Aggregationssystem, das von Prometheus inspiriert ist". Loki ermöglicht eine einfache Sammlung von Logs aus verschiedenen Quellen mit unterschiedlichen Formaten, skalierbare Persistenz über Objektspeicher und einige weitere coole Funktionen, die wir später im Detail erklären werden. Werfen wir jetzt einen Blick auf das von uns erstellte Setup.

Deck

Wenn du nur einen schnellen Blick darauf werfen möchtest, kannst du Deck verwenden, um diesen Stack mit einem Befehl auf deinem Computer einzurichten. Nach der Installation von Deck{target="_blank"} kannst du Folgendes ausführen:

$ deck get https://raw.githubusercontent.com/Getdeck/wharf/main/loki/deck.yaml

Folge den Anweisungen, die nach Abschluss des Installationsprozesses angezeigt werden, um sich bei Grafana anzumelden und mit der Erkundung zu beginnen.

Setup

In diesem Artikel konzentrieren wir uns auf die Helm-Installation. Grafana Labs bietet eine Reihe von anderen Installationsmethoden{target="_blank"} an.

Im Helm-Chart-Repository von Grafana{target="_blank"} findest du 5 Charts, die mit Loki zusammenhängen. Loki-canary ermöglicht dir die Installation von Canary-Builds von Loki in deinem Cluster. Loki-distributed installiert die relevanten Komponenten als Microservices und bietet dir die üblichen Vorteile von Microservices wie Skalierbarkeit, Ausfallsicherheit usw., während du sie unabhängig voneinander konfigurieren kannst. Loki-simple-scalable ist ähnlich, jedoch sind einige der Komponenten immer aktiviert, was einige der Konfigurationsmöglichkeiten einschränkt. Das Chart mit dem Namen Loki wird einen einzelnen StatefulSet in deinem Cluster bereitstellen, der alles enthält, was du zum Ausführen von Loki benötigst. Das letzte in der Gruppe ist loki-stack, das zusätzlich zum Loki-Chart dasselbe StatefulSet bereitstellt, auch Promtail, Grafana und einige andere. Für unseren Anwendungsfall haben wir uns für das Loki-Chart entschieden. Neben Loki selbst werden in unserem Cluster auch Promtail und Grafana ausgeführt. Im folgenden Abschnitt zeigen wir dir, wie du diesen Log-Aggregations-Stack in deinem Cluster installieren kannst!

Voraussetzungen

Um mitzumachen, benötigst du einen Kubernetes-Cluster, auf den du über kubectl zugreifen kannst, und Helm muss auf deinem Computer eingerichtet sein.

Zunächst müssen wir das Chart-Repository von Grafana zu unserer lokalen Helm-Installation hinzufügen und die neuesten Charts abrufen, wie folgt:

$ helm repo add grafana https://grafana.github.io/helm-charts
$ helm repo update

Sobald das erledigt ist, können wir mit dem eigentlichen Installationsprozess beginnen.

Loki Installation

Lass uns damit beginnen, Loki in unserem Cluster zum Laufen zu bringen. Um deine Installation zu konfigurieren, wirf einen Blick auf die Werte, die das Loki-Chart über den Befehl 'helm show values' akzeptiert, und speichere diese in einer Datei.

$ helm show values grafana/loki > loki-values.yaml

Wir werden die Einstellungen nicht im Detail besprechen, da die meisten Werte auf ihren Standardwerten belassen werden können. Du solltest jedoch einen Blick auf den persistence-Schlüssel werfen, um Loki so zu konfigurieren, dass deine Protokolle tatsächlich in einem PersistentVolume gespeichert werden.

persistence:
    enabled: true
    accessModes:
    - ReadWriteOnce
    size: 10Gi
    annotations: {}

Sobald du die Werte an deine Vorlieben angepasst hast, installiere Loki in deinem Cluster mit dem folgenden Befehl:

$ helm upgrade --install loki grafana/loki -n loki -f loki-values.yaml

Nachdem das erledigt ist, kannst du überprüfen, ob alles funktioniert hat, indem du kubectl verwendest:

$ kubectl get pods -n loki
NAME                            READY   STATUS    RESTARTS   AGE
loki-0                          1/1     Running   0          1h

Wenn die Ausgabe ähnlich aussieht, herzlichen Glückwunsch! Das ist einer von drei Komponenten, die erfolgreich installiert wurden.

Promtail Installation

Als nächstes schauen wir uns Promtail an. Promtail hat 3 Hauptfunktionen, die für unsere Einrichtung wichtig sind:

1. Es erkennt Ziele (Pods, die in unserem Cluster ausgeführt werden)
2. Es beschriftet Logstreams (hängt Metadaten wie Pod/Dateinamen usw. an, um sie später einfacher identifizieren zu können)
3. Es versendet sie an unsere Loki-Instanz

Um es zu installieren, benötigen wir zuerst eine Werte-Datei, genau wie wir es für Loki getan haben:

$ helm show values grafana/promtail > promtail-values.yaml

Wie bei Loki können die meisten Werte auf ihren Standardwerten belassen werden, um Promtail zum Laufen zu bringen. Wir müssen jedoch Promtail mitteilen, wohin es die gesammelten Protokolle senden soll, indem wir Folgendes tun:

$ kubectl get svc -n loki
NAME            TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
loki            ClusterIP   10.101.163.181   <none>        3100/TCP   1h

Wir fragen kubectl nach den Diensten im Loki-Namespace und es wird uns mitgeteilt, dass es einen Dienst namens Loki gibt, der den Port 3100 freigibt. Um Promtail dazu zu bringen, unsere Protokolle an das richtige Ziel zu senden, zeigen wir es über den 'config'-Schlüssel in unserer Werte-Datei auf den Loki-Dienst.

config:
 logLevel: info
 serverPort: 3101
 lokiAddress: http://loki:3100/loki/api/v1/push

Unter 'lokiAddress' geben wir an, dass Promtail Protokolle an http://loki:3100/loki/api/v1/push{target="_blank"} senden soll. Beachte, dass du, wenn Loki nicht im selben Namespace wie Promtail läuft, die vollständige Service-Adressnotation verwenden musst, z. B. '..svc.cluster.local:'. Promtail läuft als DaemonSet und hat die folgenden Tolerations, um auf Master- und Worker-Knoten ausgeführt zu werden.

tolerations:
    - key: node-role.kubernetes.io/master
    operator: Exists
    effect: NoSchedule
    - key: node-role.kubernetes.io/control-plane
    operator: Exists
    effect: NoSchedule

Wenn du nicht möchtest, dass Promtail auf deinen Master-/Control-Plane-Knoten ausgeführt wird, kannst du dies hier ändern.

Jetzt, da wir die wichtigsten Werte festgelegt haben, lass uns das installieren!

$ helm upgrade --install promtail grafana/promtail --namespace=loki -f promtail-values.yaml

Überprüfe, ob alles wie erwartet funktioniert:

$ kubectl get ds -n loki
NAME       DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
promtail   8         8         8       8            8           <none>          1h

Du kannst auch mit dem Flag '-o wide' einen Blick auf die Pods werfen, um zu sehen, auf welchem Knoten sie ausgeführt werden:

$ kubectl get pods -n loki -o wide
NAME                            READY   STATUS    RESTARTS   AGE    IP         NODE                     NOMINATED NODE   READINESS GATES
promtail-2j9dj                  1/1     Running   0          1h    1.1.1.1     control-plane-3          <none>           <none>
promtail-5wjxl                  1/1     Running   0          1h    1.1.1.1     control-plane-1          <none>           <none>
promtail-9nvps                  1/1     Running   0          1h    1.1.1.1     worker-1                 <none>           <none>
promtail-brgj2                  1/1     Running   0          1h    1.1.1.1     worker-2                 <none>           <none>
promtail-cfnff                  1/1     Running   0          1h    1.1.1.1     control-plane-2          <none>           <none>
promtail-gtt6m                  1/1     Running   0          1h    1.1.1.1     worker-3                 <none>           <none>
promtail-hnh4z                  1/1     Running   0          1h    1.1.1.1     worker-4                 <none>           <none>
promtail-r4xsz                  1/1     Running   0          1h    1.1.1.1     worker-5                 <none>           <none>

Grafana Installation

Zu guter Letzt, lass uns eine Instanz von Grafana in unserem Cluster starten.

Die folgenden Werte ermöglichen die Persistenz. Wenn du möchtest, dass deine Grafana-Instanz E-Mails senden kann, kannst du SMTP wie unten gezeigt konfigurieren. Füge einfach deinen SMTP-Host und 'from_address' hinzu, um ein Secret mit deinen Anmeldeinformationen zu erstellen.

persistence:
 type: pvc
 enabled: true
 # storageClassName: default
 accessModes:
   - ReadWriteOnce
 size: 10Gi
grafana.ini:
 smtp:
   enabled: true
   host: smtp.smtpserver.io:465
   from_address: grafana@collectallthelogs.io
   skip_verify: true
smtp:
 # `existingSecret` is a reference to an existing secret containing the smtp configuration
 # for Grafana.
 existingSecret: "grafana-smtp"
 userKey: "user"
 passwordKey: "password"

Sobald du deine Werte konfiguriert hast, kannst du Grafana wie folgt in deinem Cluster installieren:

helm upgrade --install loki-grafana grafana/grafana --namespace=loki -f grafana-values.yaml

Überprüfe, ob alles reibungslos verlaufen ist:

$ kubectl get pods -n loki
NAME                            READY   STATUS    RESTARTS   AGE
loki-grafana-64b4b79494-8bt7c   1/1     Running   0          1h

Alle drei Komponenten sind einsatzbereit, super! Jetzt, da alles eingerichtet ist, schauen wir uns an, wie wir dies tatsächlich nutzen können.

:::GlobalPodcastSection{:videoId="tyvE9VlSWkE" :videoPosition="left" .mb-6} ::::GlobalPreTitle{:color="text-bs-green" .mb-3} UNSER KUBERNETES-PODCAST :::: ::::GlobalTitle{:tag="h3" .mb-6} Werkzeuge für das Handwerk: Die Navigation im Kubernetes-Ökosystem :::: ::::globalParagraph{:font-size="lg" .mb-4} Michael und Robert sprechen ausführlich über die Feinheiten der lokalen Kubernetes-Entwicklung und geben auch einige echte Codierungsbeispiele. :::: ::::globalParagraph{:font-size="lg" } Weitere Ausgaben unseres Podcasts findest du hier: :::: ::::GlobalButton{:url="/kubernetes-podcast/" :label="Mehr anzeigen" :color="green"} :::: :::

Verwendung

Verbinde deine neu erstellte Loki-Instanz einfach mit Grafana. Alles, was du tun musst, ist eine Datenquelle in Grafana zu erstellen. Unter Konfiguration → Datenquellen klicke auf 'Datenquelle hinzufügen' und wähle Loki aus der Liste aus. Dir wird dieses Einstellungsfenster angezeigt, in dem du nur die URL deiner Loki-Instanz konfigurieren musst, um deine Protokolle mit Grafana zu analysieren. Da Grafana im selben Namespace wie Loki läuft, reicht es aus, http://loki:3001{target="_blank"} anzugeben.

{.object-cover .max-w-full .mb-5}

Wenn du fertig bist, klicke auf 'Speichern & Testen' und voilà, du bist bereit, Abfragen gegen Loki auszuführen.

LogQL

'LogQL ist die von Grafana Loki inspirierte Abfragesprache, ähnlich wie PromQL. Abfragen fungieren wie ein verteilter grep, um Log-Quellen zu aggregieren. LogQL verwendet Labels und Operatoren zur Filterung.'

Mit LogQL kannst du einfach Abfragen gegen deine Protokolle ausführen. Du kannst entweder Protokollabfragen ausführen, um den Inhalt tatsächlicher Protokollzeilen zu erhalten, oder Metrikabfragen verwenden, um Werte basierend auf den Ergebnissen zu berechnen.

LogQL ist gut dokumentiert{target="_blank"}, daher gehen wir nicht auf jedes Feature im Detail ein, sondern geben dir stattdessen einige Abfragen, die du sofort gegen deine Protokolle ausführen kannst, um loszulegen. Gehe zum Explore-Panel in Grafana (${grafanaUrl}/explore), wähle deine Loki-Datenquelle im Dropdown-Menü aus und schau dir an, was Loki bisher für dich gesammelt hat.

Simple Log Query

Wenn du nur die Protokolle eines einzelnen Pods haben möchtest, ist es so einfach, eine Abfrage wie diese auszuführen:

{pod="loki-0"}

Grafana wählt automatisch das richtige Panel für dich aus und zeigt an, was dein Loki Pod protokolliert.

Fehler in einem Namespace

Diese Abfrage filtert Protokolle aus einem bestimmten Namespace, die das Wort "Fehler" enthalten. Sie zählt sie über den im Dashboard ausgewählten Bereich und gibt die Summe zurück, um dir einen einfachen Überblick darüber zu geben, was in deinem Cluster passiert.

sum(count_over_time({namespace="loki"} |= "error" [$__range]))

Durchschnittliche Antwortzeit in einem Namespace, nach Pfad und Anwendung

Diese Abfrage ist so komplex wie es in diesem Artikel wird. Sie sammelt Protokolle aus einem Namespace und wendet dann mehrere nützliche Funktionen von LogQL an, wie zum Beispiel Musterabgleich, reguläre Ausdrücke, Zeilenformatierung und Filterung. Am Ende erhältst du die durchschnittliche Antwortzeit von Anwendungen, die im angegebenen Namespace innerhalb des ausgewählten Intervalls ausgeführt werden. Sie filtern effektiv die Protokollzeilen heraus, die von Kubernetes Liveness- und Readiness-Probes generiert werden, gruppiert nach App-Label und Pfad. Hinweis: Diese genaue Abfrage funktioniert für das Protokollformat von Django Hurricane, aber du kannst sie anpassen, indem du das Muster an dein Protokollformat anpasst.

avg_over_time({namespace="application"} | pattern "<date> <time> <access> <level>     <code> <method> <path> <ip> <latency>" | regexp "(?P<latencyDecimal>[0-9]+\\.[0-9]+ms)" | line_format "{{.latencyDecimal}}" | regexp "(?P<latencyClean>[0-9]+\\.[0-9])" | unwrap latencyClean | __error__="" | path!="/alive" | path!="/ready" [$__interval]) by (path, app)

Sonstige Merkmale/Weitere Lektüre/Heiligtümer

Wenn du deine Logs nicht in deinem Cluster speichern möchtest, kannst du die gesammelten Daten an S3-kompatible Speicherlösungen wie Amazon S3 oder MinIO senden. Der Prozess der Log-Analyse/-Ansicht bleibt derselbe.

Die Dateispeicherung funktioniert nicht, wenn du das verteilte Chart verwendest, da mehrere Pods Lese-/Schreibvorgänge auf demselben PV durchführen müssten. Dies ist im Chart-Repository{target="_blank"} dokumentiert, wird jedoch leider nicht in der offiziellen Dokumentation von Loki erwähnt.

LogCLI{target="_blank"} ist das CLI-Tool von Loki, mit dem du deine Protokolle bequem von der Kommandozeile aus durchsuchen kannst. Hierfür musst du deine Loki-Instanz über HTTP freigeben oder Port-Forwarding von deinem Cluster zu deinem Computer verwenden.

{.object-cover .max-w-full .mb-5}

:::GlobalTitle{:size="lg" .mb-5} Skalierung der API - zu viel und zu wenig ::: :::GlobalParagraph Kubernetes erlaubt es bereits auf einfache Art und Weise, Workloads zu skalieren. Für diesen Artikel wird eine zustandslose (stateless) Application angenommen - eine simple REST API. ::: :::GlobalParagraph Diese ist in Form eines Deployments mit 4 Replicas (je 125 mCPU und 250 Mi Memory) im GKE Autopilot Cluster vorhanden. ::: :::GlobalParagraph Problemstellung: Nachts laufen diese 4 Replicas nahezu ohne Last. Am Tag reichen diese teilweise nicht aus. ::: :::GlobalParagraph Lösung: Automatische Skalierung der Services basierend auf deren Auslastung. ::: :::GlobalParagraph Im schlechtesten Falle werden die Applikationen während hoher Last noch OOM Killed - weil sie zu viel Speicher verbrauchen. :::

:::GlobalButton{:url="/loesungen/cloud-infrastruktur-beratung/" :label="Erfahre mehr über unsere Infrastrukur-Entwicklungsdienste" :color="blue" .mb-6} :::

:::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Wie viel CPU oder Arbeitsspeicher brauchen meine Pods? :::

:::GlobalParagraph Bevor die Skalierung konfiguriert wird, ist es wichtig herauszufinden, - was eigentlich typische Metriken für das Verhalten der zu skalierenden Applikation sind . Verbraucht diese viel CPU oder viel Arbeitsspeicher? Gibt es eine andere Metrik, welche mir Aufschluss über die Auslastung gibt (z.B. Request Queue-Länge)? ::: {.mx-auto .w-1/2}

:::GlobalParagraph{.mb-4} Ein einfacher Blick in die Google Cloud Dashboards unserer REST API zeigt, dass der Arbeitsspeicher schwankt und die CPU ab einem bestimmten Zeitpunkt eine recht konstante Auslastung hat. Die blaue Linie zeigt die tatsächliche Auslastung, die rote Linie die Limits. Der Arbeitsspeicher scheint hier deutlich volatiler und näher an seinen Limits - für die Skalierung unserer Applikation in Kubernetes wird der Memory als Grundlage genutzt. ::: :::GlobalParagraph Nun ist zwar klar, welche Metrik hergenommen wird, allerdings noch nicht, was die notwendigen Parameter sind. Die Memory Auslastung fällt selten unter 250 MB, was bedeutet, dass mindestens 2 Pods ständig verfügbar sein sollten. Wir laufen selten, aber zuverlässig an die Kapazitätsgrenze der aktuell 4 verfügbaren Replicas. Also nehmen wir mit etwas Puffer maximal 6 Replicas als höchste Auslastung an. :::

:::GlobalParagraph Anmerkung: Stark fluktuierende Auslastung des Arbeitsspeichers deutet auf Probleme in der Applikation hin. In diesem Falle ein Memory-Leak einer Abhängigkeit, welche nicht verändert werden kann. :::

:::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Skalierung in Kubernetes: der Horizontal Pod Autoscaler :::

:::GlobalParagraph Die Google Cloud erlaubt sowohl vertikale als auch horizontale Skalierung von Workloads. Vertikale Skalierung bedeutet, dass die verfügbaren Ressourcen (CPU, Memory) von Pods skaliert werden. Horizontale Skalierung erzeugt und entfernt ganze Pods desselben Deployments. :::

{.mx-auto .w-1/2}

:::GlobalParagraph Die grundlegenden Parameter sind schnell erstellt - das Minimum und Maximum der Skalierung der API ist mit den folgenden 2 Feldern erledigt: :::

{.mx-auto .w-1/2}

::GlobalCallAnExpert{:bg="bg-bs-blue"} #buttonBlockTitle Wir können auch Deine Apps dynamisch an den Bedarf anpassen. ::

:::GlobalParagraph Doch was ist nun die Baseline für die Skalierung selbst? Es wird einfach - für unser Beispiel - eine gewünschte “Idealauslastung” pro Pod festgelegt. Das Limit eines jeden Pods liegt bei 250 MB. Mit einer Auslastung von 80% oder 200 MB kommen wir (mit etwas Puffer) an die Belastungsgrenze des Services und brauchen eine neue Instanz. :::

{.mx-auto .w-1/2}

:::GlobalParagraph{.mb-4} Da das definierte Minimum 2 Pods sind - wird, sobald die Memory Auslastung im Schnitt 400 MB überschreitet, ein weiterer Pod hinzu skaliert. Wird diese dann wieder unterschritten, so entfernt der Horizontal Pod Autoscaler (HPA) diesen auch wieder. :::

:::GlobalParagraph Für alle Kubernetes Experten - natürlich lässt sich der HPA auch über Kubernetes Ressourcen definieren und somit als Konfiguration im Cluster hinterlegen - das typische DevOps Vorgehen. :::

:::BlogCode{.mb-5}

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: store-autoscale
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: store-autoscale
  minReplicas: 2
  maxReplicas: 6
  metrics:
    - resource:
        name: memory
        target:
          averageValue: 200
          type: AverageValue

:::

:::GlobalTitle{:size="lg" .mb-5} Fazit ::: :::GlobalParagraph{.mb-8} Mit ein paar Klicks - oder auch einer einfachen Kubernetes Ressourcen - lassen sich Kosten sparen und die Lastspitzen der REST API einfach abfangen. :::

{.object-cover .max-w-full .mb-5}

:::GlobalTitle{:size="lg" .mb-5} Vertex AI und SQLModel ::: :::GlobalParagraph Die Plattform Vertex AI ist ein Produkt der Google Cloud und bietet Entwicklern die Möglichkeit, generative AI in ihre Applikationen einzubinden. Die Möglichkeiten sind zahlreich: Input und Output können via Text, Audio und Video erfolgen und es stehen verschiedene AI Modelle zur Auswahl. Für diesen Blogpost beschränken wir uns auf Text als Eingabe- und Ausgabemedium. Vertex AI Tutorials wie dieses zeigen, wie einfach die Integration in Projekte gelingt. ::: :::GlobalParagraph SQLModel ist ein Python Paket, welches auf Pydantic (einer Validierungsbiibliothek) aufsetzt und es ermöglicht, die Python-Datenmodelle in Datenbanken zu speichern oder aus diesen zu lesen. Praktisch ein ORM (=Object–relational mapping) auf Pydantic Basis, das sich hervorragend für eine KI Datenbank eignet. Künstliche Intelligenz mit Python zu kombinieren, wird damit besonders einfach. :::

:::GlobalButton{:url="/loesungen/api-entwicklung/" :label="Erfahre mehr über unsere API-Entwicklungsdienste" :color="blue" .mb-6} :::

:::GlobalTitle{:size="lg" .mb-5} Datenmodell und Generierung von Daten :::

:::GlobalParagraph Folgendes Szenario nehmen wir an: Wir sind ein Buchladen und führen eine Datenbank mit Büchern. Es ist bekannt, wie viele Exemplare pro Buch im Lager vorhanden sind. Zu jedem Buch ist der Autor bekannt. ::: :::GlobalParagraph Das Datenmodell sieht folgendermaßen aus: :::

:::BlogCode{.mb-5}

class Author(SQLModel, table=True):
   id: Optional[int] = Field(default=None, primary_key=True)
   first_name: str
   last_name: str
   birthday: date

class Book(SQLModel, table=True):
   id: Optional[int] = Field(default=None, primary_key=True)
   name: str
   author_id: int = Field(default=None, foreign_key="author.id")
   num_in_stock: int = 0

:::

:::GlobalParagraph{.mb-4} Bücher und Autoren sind über eine klassische Foreign-Key-Beziehung miteinander verbunden. Es lassen sich mit SQLModel nun ganz einfach Queries an die Datenbank formulieren, um eine KI API aufzubauen - z.B. die Selektion aller Autoren mit einem bestimmten Vor- und Nachnamen: :::

:::BlogCode{.mb-5}

# select Author with matching first_name and last_name
statement = select(Author).where(Author.first_name == first_name, Author.last_name == last_name)

:::

:::GlobalParagraph Soweit so gut. Via Polyfactory generieren wir uns noch ein paar Testdaten: :::

:::BlogCode{.mb-5}

class AuthorFactory(ModelFactory[Author]):
   __model__ = Author
   __faker__ = Faker(locale="de_DE")
   id = Use(lambda: None)

   @classmethod
   def first_name(cls) -> str:
       return cls.__faker__.first_name()

   @classmethod
   def last_name(cls) -> str:
       return cls.__faker__.last_name()

class BookFactory(ModelFactory[Book]):
   __model__ = Book
   __faker__ = Faker(locale="de_DE")
   id = Use(lambda: None)

   @classmethod
   def name(cls) -> str:
       return cls.__faker__.catch_phrase()

def create_authors():
   for i in range(0, 1000):
       author = AuthorFactory.build()
       with Session(engine) as session:
           session.add(author)
           session.commit()
           for i in range(1, randrange(1, 10)):
               create_book(author_id=author.id)

def create_book(author_id):
   book = BookFactory.build(author_id=author_id)
   with Session(engine) as session:
       session.add(book)
       session.commit()

# init sqlite
engine = create_engine("sqlite:///database.db")
SQLModel.metadata.create_all(engine)
# call create fcnt
create_authors()

:::

:::GlobalParagraph Und schon haben wir 1000 verschiedene Autoren mit zwischen 1 und 10 Büchern. Die Bücher bekommen zufällige Verfügbarkeiten (Anzahl im Lager) zugeordnet. :::

::GlobalCallAnExpert{:bg="bg-bs-blue"} #buttonBlockTitle Wir können auch für Dich KI-Lösungen bauen. ::

:::GlobalTitle{:size="lg" .mb-5} Verbindung mit Vertex AI :::

:::GlobalParagraph Zuallererst wäre zu definieren, auf welche Funktionalität unser Agent Zugriff haben soll. Wir nehmen an, dass der Agent Bücher für einen bestimmten Autor ermitteln können soll und auch die Anzahl von Exemplaren auf dem Lager für ein bestimmtes Buch kennen muss. ::: :::GlobalParagraph Dafür werden folgende Hilfsfunktionen angelegt: :::

:::BlogCode{.mb-5}

from utils import (
   get_book_id_by_title,
   get_books_for_author,
   get_num_in_stock_for_book,
)

:::

:::GlobalParagraph Vertex AI braucht nun Informationen über die Funktionen, was diese tun und welche Eingabeparameter zu erwarten sind. Dies wird mithilfe von FunctionDeclarations gemacht: :::

:::BlogCode{.mb-5}

get_authors_for_book_func = FunctionDeclaration(
   name=GET_BOOK_BY_AUTHOR,
   description="Get a list of book names for an author.",
   parameters={
       "type": "object",
       "properties": {
           "first_name": {
               "type": "string",
               "description": "The first name of the author",
           },
           "last_name": {
               "type": "string",
               "description": "The last name of the author",
           },
       },
   },
)

:::

:::GlobalParagraph Die Funktion selbst sieht folgendermaßen aus: :::

:::BlogCode{.mb-5}

def get_books_for_author(first_name: str, last_name: str):
   with Session(engine) as session:
       statement = select(Author).where(Author.first_name == first_name, Author.last_name == last_name)
       author = session.exec(statement).first()
       statement = select(Book).where(Book.author_id == author.id)
       books = session.exec(statement=statement).all()
       return [book.name for book in books]

:::

:::GlobalParagraph Die Funktionen werden in ein "Tool" zusammengefasst und dem Modell zur Verfügung gestellt: :::

:::BlogCode{.mb-5}

tools = Tool(
   function_declarations=[
       get_authors_for_book_func,
       get_book_id_by_title_func,
       get_num_in_stock_for_book_func,
   ],
)
model = GenerativeModel(
   model_name="gemini-1.5-pro-002",
   generation_config=GenerationConfig(temperature=0),
   tools=[tools],
)

:::

:::GlobalParagraph Das Modell kann den Input eines Nutzers nun klassifizieren und eine Einschätzung geben, welche der Funktionen verwendet werden soll. Diese kann dann aufgegriffen werden: :::

:::BlogCode{.mb-5}

if function_calls:
   api_responses = []
   for func in function_calls:
       if func.name == GET_BOOK_BY_AUTHOR:
           api_responses.append(
               {
                   "name": func.name,
                   "content": get_books_for_author(
                       first_name=func.args["first_name"],
                       last_name=func.args["last_name"],
                   ),
               }
           )
       elif func.name == GET_BOOK_ID_BY_TITLE:
           api_responses.append(
               {
                   "name": func.name,
                   "content": get_book_id_by_title(
                       title=func.args["title"],
                   ),
               }
           )
       elif func.name == GET_NUM_IN_STOCK_FOR_BOOK:
           api_responses.append(
               {
                   "name": func.name,
                   "content": get_num_in_stock_for_book(
                       title=func.args["title"],
                   ),
               }
           )

   # Return the API response to Gemini
   for api_response in api_responses:
       name = api_response.pop("name")
       response = chat_session.send_message(
           [
               Part.from_function_response(
                   name=name,
                   response=api_response,
               )
           ]
       )
       print(response.text)

:::

:::GlobalParagraph Das Modell extrahiert also die Parameter aus der Eingabe des Nutzers. Diese kann dann im Funktionsaufruf verwendet werden. ::: :::GlobalParagraph Nun kann der Chat starten! :::

:::GlobalParagraph{.italic .mb-[-20px]} Which books are written by Guenther Hendriks? ::: :::GlobalParagraph{.italic .mb-2} Guenther Hendriks has written the following books: Digitized optimal circuit, Future-proofed content-based groupware, Universal clear-thinking Local Area Network, Digitized scalable service-desk, and Innovative full-range protocol. :::

:::GlobalParagraph{.italic .mb-[-20px]} How many copies of the first of those books are available? ::: :::GlobalParagraph{.italic .mb-8} There are 2089 copies of "Digitized optimal circuit" in stock. :::

:::GlobalTitle{:size="lg" .mb-5} Fazit ::: :::GlobalParagraph Die API von Vertex AI funktioniert generell gut. Aktuell dauert die Rückmeldung immer ein paar Sekunden, was je nach Use-Case eventuell zu viel sein könnte. Das Interface ist intuitiv und einfach zu bedienen. Für manche Anfragen kommt gar keine Rückmeldung von Vertex AI, was dann abgefangen werden muss. ::: :::GlobalParagraph Vertex AI macht es möglich, bestehende APIs und Datenbanken über natürliche Sprache zugänglich zu machen, was cool und schnell funktioniert, allerdings noch etwas ausreifen muss. Es erlaubt eine effiziente Nutzung der KI Datenbank und der Einbindung in verschiedene Systeme. Besonders für Entwickler, die KI programmieren mit Python wollen, ist dies eine spannende Lösung. :::

{.object-cover .max-w-full .mb-5}

:::globalParagraph Django CMS{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} bringt von Haus aus eine ganze Reihe Plugins mit. Darunter das TextPlugin. Es erlaubt uns einfach Texte in unser CMS einzufügen und diese zu bearbeiten. :::

{.object-cover .max-w-full .mb-5}

:::globalParagraph Weiterhin erlaubt uns Django CMS{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} innerhalb des Plugins weitere Plugins zu verschachteln. Das sieht dann folgendermaßen aus: :::

{.object-cover .max-w-full .mb-5}

:::globalParagraph Dies ergibt dann folgendes Ergebnis auf unsere Webseite: :::

{.object-cover .max-w-full .mb-5}

:::globalParagraph Hier ist nun ein LinkPlugin in einem TextPlugin verschachtelt. :::

:::globalTitle{:size="lg" .mb-5} DJANGOCMSPLUGIN_FILER_LINK – DAS DJANGO CMS LINK PLUGIN ::: :::globalParagraph Einfach, oder? Da der Link innerhalb des Textes steht, ist er dem TextPlugin untergeordnet. Das LinkPlugin erlaubt es uns einfach interne und externe Inhalte zu verlinken. Es folgen Beispiele: ::: :::globalParagraph Interne Verlinkung: :::

{.object-cover .max-w-full .mb-5}

:::globalParagraph Externe Verlinkung: :::

{.object-cover .max-w-full .mb-5}

:::globalParagraph E-Mail-Adresse: :::

{.object-cover .max-w-full .mb-5}

:::globalParagraph Datei: :::

{.object-cover .max-w-full .mb-5}

:::globalParagraph Weiterhin ist es möglich Vorlagen für den Link zu definieren, sodass seine Erscheinung einfach durch den Nutzer umgestellt werden kann: ::: :::globalParagraph Vorher :::

{.object-cover .max-w-full .mb-5}

:::globalParagraph Nachher :::

{.object-cover .max-w-full .mb-5}

:::globalParagraph Falls sich der Link in einem neuen Fenster öffnen soll ist dies einfach über eine Checkbox einzustellen. ::: :::globalParagraph Für die fortgeschrittenen Nutzer ist es möglich weitere Attribute an den Link zu hängen. ::: :::globalParagraph Möchte man beispielsweise einen „title“ zu dem Link hinzufügen wäre das hierüber problemlos möglich. :::

:::globalTitle{:size="lg" .mb-5} BLUESHOE’S ANPASSUNGEN FÜR DAS PLUGIN ::: :::globalParagraph Das Link Plugin bringt alle Basisfunktionalitäten mit, welche wir hierfür benötigen. An dieser Stelle haben wir noch etwas weitergedacht: Wie können wir das Plugin benutzerfreundlicher machen? Was passiert mit toten Links? :::

:::globalTitle{:size="lg" .mb-5} VERBESSERTE ÜBERSICHT ::: :::globalParagraph Um eine bessere Übersicht zu erlangen haben wir die Oberfläche des Plugins für Autoren und Editoren überarbeitet. Es werden nun nicht mehr alle Möglichkeiten interne, externe Verlinkungen sowie Mail- und Dateiverlinkungen untereinander angezeigt, sondern als Tableiste in der Administrationsoberfläche hinterlegt. :::

{.object-cover .max-w-full .mb-5}

:::globalParagraph Der Tab, für den eine Verlinkung hinterlegt ist, ist automatisch aktiv. Von nun an ist es nicht mehr möglich mehrere Verlinkungen zu hinterlegen, diese sind nun komplett exklusiv. Dadurch erlangt der Nutzer schneller eine Übersicht und die Oberfläche wirkt etwas schlanker (vergleiche obere Screenshots). :::

:::globalTitle{:size="lg" .mb-5} 404 UND 500 FEHLER VERMEIDEN ::: :::globalParagraph 404 Fehler treten auf, wenn die angeforderte Seite nicht auf dem Server gefunden werden kann. Das ist absolut normal, denn Webserver können natürlich nicht jede URL bedienen, welche bei ihnen angefragt wird. Dennoch möchte man natürlich sehen, ob 4xx Fehler verursacht werden, um beispielsweise Tippfehler in der URL durch eine Weiterleitung auszugleichen. Ebenso sollte man darauf achten, dass alle verlinkten Seiten funktionstüchtig sind und nicht mit einem 5xx Fehler antworten. ::: :::globalParagraph Dafür haben wir den LinkHealthState eingeführt und verwenden das Plugin regelmäßig bei unserer Softwareentwicklung. Über ein Dashboard im Django CMS{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} Administrator kann man alle Links, sowohl intern als auch extern, auf der Webseite analysieren und den Status der verlinkten Seiten einsehen. Dabei wird gelistet, ob der Link auf eine Weiterleitung (3xx), eine nicht erreichbare Seite (4xx) oder eine fehlerhafte Seite führt (5xx). Ist mit dem Link alles in Ordnung, so wird dieser nicht gelistet. Ein Button erlaubt es die Analyse neu auszuführen. :::

{.object-cover .max-w-full .mb-5}

:::globalParagraph Weiterhin werden fehlerhafte Links im Frontend gekennzeichnet, sodass Editoren schnell den entsprechenden Link auf einer Seite finden können. :::

{.object-cover .max-w-full .mb-5}

:::globalParagraph Somit ist das LinkPlugin nicht mehr nur ein herkömmliches Plugin, sondern erlaubt auch eine schnelle Analyse der Webseite um Linkkonsistenz gewährleisten zu können. Der aktuelle Entwicklungsstand ist unter https://github.com/Blueshoe/djangocms-link2{.bs-link-blue :target="_blank"} einsehbar. Feedback und Kritik zum Django-CMS Link Plugin von Blueshoe sind herzlich willkommen. :::

{.object-cover .max-w-full .mb-5}

:::globalParagraph Beim Thema Kubernetes (K8s){.bs-link-blue} stellen wir fest, dass bei einer der grundsätzlichen Entscheidungen und zwar, ob man managed oder unmanaged Kubernetes verwenden möchte, oftmals am wenigsten Wissen vorhanden ist. Das wollen wir ändern! :::

:::globalTitle{:size="lg" .mb-5} Kubernetes-Überblick ::: :::globalParagraph Wir setzen für diesen Blogpost ein gewisses Grundverständnis von Kubernetes{.bs-link-blue} (K8s) voraus. Dennoch wollen wir uns nochmal ganz kurz anschauen wie Kubernetes eigentlich funktioniert und vor allem wie damit interagiert wird: ::: :::globalParagraph Ganz unten an der Basis hat sich im Grunde nichts verändert, es werden “wie früher” immer noch virtuelle Server benutzt, um den Code auszuführen. Kubernetes fungiert als eine Art Abstraktions-Schicht über den virtuellen Servern, die dort Nodes genannt werden und zu einem Cluster zusammengefasst werden (siehe Schaubild unten von Kubernetes.io). Ich als Entwickler oder Operations-Spezialist muss mir also keine konkreten Gedanken machen, auf welcher Node meine Anwendung nun läuft. Ich muss Kubernetes nur in Form von Manifest-Dateien die Rahmenbedingungen meiner Anwendung beibringen, K8s kümmert sich dann darum, dass eine passende Node verwendet wird. :::

{.object-cover .w-full .mb-5}

:::globalParagraph Die direkte Interaktion mit den virtuellen Maschinen wird mir somit durch Kubernetes abgenommen. Im K8s-Manifest sind einige Informationen angegeben, darunter das Container-Image{.bs-link-blue} und dessen Version sowie die Spezifikation dazu, welcher Befehl ausgeführt wird. Hier findet man aber auch Dinge wie die Resource Requests und Limits – also Mindestanforderungen, die die Anwendung an CPU und Arbeitsspeicher stellt, bzw. welche Werte die Anwendung maximal beanspruchen darf. :::

:::globalTitle{:size="lg" .mb-5} Unmanaged Kubernetes ::: :::globalParagraph Das “unmanaged” im Begriff unmanaged Kubernetes bezieht sich darauf, dass ich mich selbst um die Kubernetes Installation und Instandhaltung kümmern muss, also selbst Kubernetes managen muss. Das ist vor allem nötig, wenn aus welchen Gründen auch immer ein Hosting bei einem Cloud-Anbieter nicht möglich oder nicht erwünscht ist. ::: :::globalParagraph Im Folgenden beschreiben wir einen üblichen, wenn auch gekürzten exemplarischen Ablauf für die manuelle Installation: ::: :::globalParagraph Zunächst müssen die K8s-Nodes, also virtuelle Maschinen erstellt werden. In diesem Beispiel gehen wir von 3 virtuellen Servern aus, einen für die sogenannte Master-Node und zwei weitere für sogenannte Worker-Nodes. Die Master-Node kontrolliert dabei die Worker-Nodes, d. h. die K8s-Software, die auf dem Master installiert ist, entscheidet letztendlich, auf welcher Worker-Node eine Anwendung ausgeführt wird. ::: :::globalParagraph Als nächstes müssen die benötigten Software-Pakete installiert und konfiguriert werden. Unter anderem wird kubeadm benötigt, um einerseits die Master-Node zu initialisieren und um andererseits die Worker-Nodes dem Master zuzuweisen. Durch diesen Schritt ist der Kubernetes-Cluster geschaffen und im Grunde genommen betriebsbereit. ::: :::globalParagraph Als nächstes können die K8s-Manifeste direkt, oder auch durch Anwendungen z. B. mittels helm installiert werden. ::: :::globalParagraph Alternativ zur Installation aller benötigten einzelnen Komponenten wäre es z. B. auch möglich microk8s von Canonical zu verwenden. Dieses wird oftmals benutzt, um für die lokale Entwicklung Kubernetes zu simulieren. Aber seit ein paar Jahren bezeichnet Canonical selbst microk8s als production-ready. Der Vorteil zur vorigen Methode ist, dass man sich hier auf die Installation von einem Paket beschränken kann. ::: :::globalParagraph Zu beachten ist, dass sich “unmanaged” natürlich auch auf die Instandhaltung bezieht. Alle Maintenance-Aufgaben, sei es z. B. die Bereitstellung und Konfiguration weiterer Worker-Nodes, weil die zur Verfügung stehenden Ressourcen nicht mehr ausreichen, oder auch nur regelmäßige Updates der Kubernetes-Version müssen komplett händisch geschehen. :::

:::globalTitle{:size="lg" .mb-5} Managed Kubernetes ::: :::globalParagraph Managed Kubernetes bezeichnet im Unterschied dazu nun eine Kubernetes-Installation, die von einem Provider zur Verfügung gestellt wird, bzw. bei einem Provider konfiguriert werden kann. Provider bzw. deren Services sind z. B. die Google Kubernetes Engine (GKE), Amazons AWS Elastic Kubernetes Service (EKS) oder auch managed Kubernetes bei IONOS. ::: :::globalParagraph Der Grad des “managed” ist dabei variabel. Oftmals wird “nur” die Möglichkeit bereitgestellt eine Kubernetes-Infrastruktur zu provisionieren, d. h. einen Cluster zu erstellen, sowie die Anzahl und Spezifikation der Worker-Nodes zu konfigurieren. Das ist bereits wesentlich komfortabler als unmanaged Kubernetes. Üblicherweise wird ein Web-Interface oder auch ein Command-Line-Interface zur Interaktion zur Verfügung gestellt. Darüber hinaus können z. B. zusätzliche Worker-Nodes hinzugefügt werden oder auch Updates auf eine neue Kubernetes-Version bequem eingespielt werden. ::: :::globalParagraph Ganz oben auf der “managed”-Skala steht z. B. das managed Kubernetes Angebot von Canonical. Dabei wird die komplette Kubernetes-Infrastruktur durch den Provider installiert und gewartet. Mit so einem Angebot schrumpft der Operations-Anteil auf das Erstellen der Kubernetes-Manifeste bzw. Helm-Charts. ::: :::globalParagraph Google hat am oberen Ende der “managed”-Skala den GKE Autopilot im Angebot. Bei diesem werden die Nodes automatisch passend zu den durch die Anwendung angeforderten Ressourcen skaliert. Als Entwickler bzw. Operations-Spezialist kann ich mich auch dort auf das Erstellen der Kubernetes-Manifeste bzw. Helm-Charts beschränken. Den GKE Autopilot werden wir uns in einem künftigen Blogpost nochmal etwas genauer anschauen. :::

:::globalTitle{:size="lg" .mb-5} Zusammenfassung ::: :::globalParagraph Unserer Erfahrung nach sind die meisten Projekte und Unternehmen mit managed Kubernetes besser beraten. Durch die verschiedenen Anbieter lassen sich viele Anforderungen hinsichtlich des Hostings abdecken. Je nach managed-Grad profitiert man von unterschiedlichem Komfort. Einer der größten Vorteile ist sicherlich, dass man sich nicht direkt um die Wartung des Clusters kümmern muss, sondern diese z. T. automatisiert erfolgt oder bequem per Web-Interface oder CLI zu erledigen ist. ::: :::globalParagraph Bestehen explizite Anforderungen von on-premise Hosting, oder aber triftige Gründe, Kubernetes z. B. in einem eigenen Rechenzentrum zu betreiben, dann führt kein Weg an unmanaged Kubernetes vorbei. ::: :::globalParagraph Gut zu wissen: Im Zusammenhang mit unserer neuen Kubernetes-Service-Plattform Unikube{.bs-link-blue} muss man sich die Frage managed vs. unmanaged Kubernetes gar nicht stellen. Für Unikube spielt es keine Rolle wie der K8s-Cluster installiert wurde, ob vollständig oder nur teilweise managed, unmanaged oder sogar nur lokal simuliert. :::

{.object-cover .max-w-full .mb-5}

:::globalParagraph Die ersten Hürden sind gemeistert. Wir wissen, warum wir Cloud Native entwickeln wollen, unsere Entwickler sind für den Prozess geschult und neue Projekte werden von Anfang an Cloud Native gestaltet. Dennoch kann die Migration zu Cloud Native eine echte Herausforderung darstellen. Deshalb erfahrt ihr am Ende dieses Artikels, wie Unikube bei der Migration unterstützen kann. :::

:::globalTitle{:size="lg" .mb-5} Art der Migration ::: :::globalParagraph Bei der Migration wollen wir letztlich, dass unsere Produktiv- und Staging-/Testing-Systeme mittels Kubernetes (K8s) gehostet werden und auch unserer Entwickler mit persönlichen, bzw. individuellen Kubernetes Clustern entwickeln. Wie das lokale Entwickeln mit Kubernetes aussehen kann, haben wir schon einmal in diesem Blog-Post{.bs-link-blue} erläutert. ::: :::globalParagraph Je nach Entwicklungsprozess bringt ein bestehendes Projekt verschiedene Elemente mit, auf denen man bei der Migration aufbauen kann oder die erst noch vorbereitet werden müssen. Einer der größeren Punkte ist, ob das Projekt bereits Container-Images verwendet oder nicht. Wir schauen uns drei Beispielprojekte an, die sich im Entwicklungsvorgehen und Hosting unterscheiden: ::: :::globalParagraph Zum einen ein Projekt das lokal mit Vagrant entwickelt wurde und mittels einem für Django-Projekte recht üblichen Tech-Stack von uwsgi und nginx gehostet ist. Die anderen beiden Projekte verwenden bereits Docker-Images. Für die lokale Entwicklung wird bei beiden Docker-Compose verwendet, eines wird auch mit Docker-Compose gehostet, das andere mit Kubernetes. ::: :::globalParagraph In der folgenden Grafik, die die zeitliche Entwicklung von Entwicklungs- und Hosting-Systemen veranschaulicht, können wir unsere Beispielprojekte eindeutig zuordnen. Für diesen Blogbeitrag ignorieren wir die erste Stufe, ‘Bare Metal’. Im Bereich ‘Development Platform’ finden wir unsere drei Projekte unter den Stufen 'Virtualized' und 'Containerized'. In der ‘Operating Platform’ können wir den Pfeilen folgen und finden unsere Projekte unter ‘Virtual Machines’, ‘Container Runtimes & PaaS’ sowie ‘Container-Orchestration’. Ziel ist es, dass alle drei Projekte sowohl in der Entwicklung als auch im Betrieb unter der Stufe ‘Container-Orchestrated’ erscheinen. :::

{.object-cover .w-full .mb-5}

:::globalTitle{:size="md" :tag="h3" .mb-5} Beispiel 1: Lokale Entwicklung mit Vagrant :::

:::globalParagraph Vagrant wurde entwickelt, um die Entwicklungsumgebung in einer komplett virtuellen Maschine (VM) abzubilden, um dort so gut wie irgend möglich die Produktivumgebung nachzustellen. Da im Cloud Native-Prozess keine kompletten VMs mehr verwendet, sondern die Anwendungen mit ihren Umgebungsvariablen in Container gepackt werden, ist der erste Schritt eine Migration hin zu Docker. ::: :::globalParagraph Dazu muss ein Dockerfile geschrieben werden, welches die Anwendung umfasst. An dieser Stelle kann es auch Sinn machen, zu überlegen, welche Teile der Anwendung in einzelne Services aufgeteilt werden könnten. Zuvor gab es ja nur eine Vagrant-VM, die Anwendung könnte im schlimmsten Fall ein riesiger Monolith sein. Zumindest Systeme, wie eine Datenbank oder ein Cache sollten nicht im Dockerfile landen, sondern als eigene Services konfiguriert werden. ::: :::globalParagraph Der zweite Schritt ist, die Kubernetes-Manifeste zu erstellen, z. B. mittels Helm. Das bedeutet, es müssen Helm-Charts geschrieben werden, die für alle benötigten Services die entsprechenden K8s-Ressourcen erzeugen. ::: :::globalParagraph Als letztes muss “nur” noch der Entwicklungsprozess auf Kubernetes umgestellt werden. Das heißt, unseren Entwicklern stehen persönliche, bzw. individuelle Cluster zur Verfügung. Das könnten zum einen lokale Cluster sein, welche z.B. mittels k3d, microk8s, oder minikube simuliert werden. Zum anderen könnten diese individuellen “Entwickler-Cluster” aber auch remote existieren. Sozusagen ein realer K8s-Cluster, der aber nur von einem Entwickler genutzt wird. :::

:::globalTitle{:size="md" :tag="h3" .mb-5} Beispiel 2: Lokale Entwicklung und Hosting mit Docker-Compose ::: :::globalParagraph Unser zweites Projekt verwendet Docker-Compose sowohl in der Entwicklung als auch beim Hosting des Produktivsystems, d. h. wir verfügen über ein oder mehrere Dockerfiles und haben uns bereits zu Beginn des Projekts grundlegend Gedanken dazu gemacht, welche verschiedenen Services die Anwendung benötigt. Diese sind im Docker-Compose.yaml abgebildet. ::: :::globalParagraph Der Hauptteil der Migration besteht darin die Kubernetes-Manifeste zu erstellen. Dies kann wie beim vorigen Projekt auch mittels Helm-Charts geschehen. Durch Helm-Charts sind Kubernetes-Manifeste einfacher zu pflegen. Das fällt insbesondere bei größeren Projekten ins Gewicht. Wenn z. B. Deployments recht ähnlich aufgebaut sind, lässt sich das in Helm-Templates geschickter abbilden (Stichwort DRY). Sollte das keine Anforderung sein, könnte man die Manifest-Dateien auch direkt aus dem Docker-Compose.yaml erzeugen. Kubernetes stellt dafür den Command kompose zur Verfügung. Die Verwendung ist simpel, ein einfaches kompose convert genügt, um die Dateien zu erzeugen. ::: :::globalParagraph Auch hier muss daraufhin natürlich der lokale Entwicklungsprozess auf Kubernetes umgestellt werden. :::

:::globalTitle{:size="md" :tag="h3" .mb-5} Beispiel 3: Lokale Entwicklung mit Docker-Compose, Hosting mit Kubernetes :::

:::globalParagraph Bei diesem Projekt haben wir unsere Anwendung bereits in Services unterteilt und wir haben ein oder mehrere Dockerfiles. Bei der lokalen Entwicklung kommt Docker-Compose zum Einsatz, gehostet wird mittels Kubernetes. Dementsprechend besteht eigentlich der einzige Schritt der Migration darin, den lokalen Entwicklungsprozess auf Kubernetes umzustellen. Ansonsten muss die Produktivumgebung für die lokale Entwicklung immer im Docker-Compose.yaml nachgestellt werden. Das ist zum einen ein gewisser zusätzlicher Aufwand, zum anderen hat man das Problem, dass die lokale Umgebung nicht exakt der Produktivumgebung entspricht und es somit beim Deployment zu unvorhergesehenen Problemen oder Nebenwirkungen kommen kann. :::

:::globalTitle{:size="lg" .mb-5} Herausforderungen bei der Migration ::: :::globalParagraph Bei der Migration unserer drei Beispielprojekte gilt es ein paar Herausforderungen zu meistern. Diese beziehen sich einerseits auf die Migration an und für sich. Andererseits auch darauf, wie die Umstellung des lokalen Entwicklungsprozesses von den Entwicklern aufgenommen wird und sie z. B. erst noch eine handvoll Tools lernen müssen. Wir treffen hier außerdem die Annahme, dass ein Operations-Spezialist mit Kubernetes-Expertise mit im Team ist, um die Helm Charts zu entwickeln. ::: :::globalParagraph Nun stellt sich die Frage, welche Hürden es aus Entwicklersicht noch gibt, um alle Projekte nach Cloud Native zu migrieren: ::: :::GlobalBlock{.ol-decimal .mb-5}

1. Umgang mit kubectl erlernen, um direkt mit dem Cluster interagieren zu können.
2. Live-reloading des Codes: Wenn der Code geändert wird, sollten die Änderungen möglichst schnell testbar sein, ohne zuerst ein neues Docker-Image builden und im lokalen Cluster deployen zu müssen. Dies ist z. B. mit Telepresence möglich, ein weiteres Tool das unsere Entwickler lernen müssen.
3. Der Debugger ist sicherlich für die meisten Entwickler sehr wichtig für einen optimalen Entwicklungsprozess. Dieser muss bei einem lokalen Kubernetes-Cluster nochmal explizit konfiguriert werden. Im Python-Umfeld z. B. mit python remote debug. ::: :::globalParagraph Unsere Entwickler müssen also drei weitere Tools zumindest in den Grundzügen lernen, um über den Funktionsumfang zu verfügen, den das Docker-Compose-Setup zur Verfügung gestellt hat. Das ist natürlich keine unmögliche Hürde, bedeutet aber zusätzlichen Aufwand. :::

:::globalTitle{:size="lg" .mb-5} Wie unterstützt Unikube bei der Migration? ::: :::globalParagraph Zum Abschluss betrachten wir noch kurz, wie Unikube{.bs-link-blue} bei der Migration nach Cloud Native ins Spiel kommt. Unikube fungiert praktisch als eine Art “Wrapper” für verschiedene Tools bzw. Funktionalitäten. Das bedeutet, dass ein Entwickler, der mit Unikube arbeitet, nur noch ein Tool und nicht mehr mehrere erlernen muss. Er muss sich somit außerdem kein detailliertes Kubernetes-Wissen mehr aneignen und auch nicht direkt mit dem Kubernetes-Cluster interagieren. ::: :::globalParagraph Unikube wurde unter dem Aspekt entwickelt, möglichst einfach und bequem per Command Line Interface zu benutzen zu sein. Der Anspruch ist hier, auf eine ähnliche Convenience zu kommen, wie man sie von Docker-Compose gewohnt ist. Und dabei wird auch noch ganz nebenbei die Kubernetes-Komplexität aufgelöst! ::: :::globalParagraph Seid gespannt, wie sich Unikube mit neuen Features weiterentwickelt und gebt uns gerne Input, z. B. auf GitHub. :::

{.object-cover .max-w-full .mb-5}

Einführung

In diesem Artikel vergleichen wir drei beliebte lokale Kubernetes-Entwicklungstools. Zusätzlich wird Getdeck Beiboot als remote Kubernetes-basierte Entwicklungsumgebung in den Vergleich aufgenommen.

Der Schwerpunkt dieses Blogbeitrags liegt auf der Bewertung der DX ("Developer Experience") in tatsächlichen Entwicklungsszenarien. Dies ist besonders wichtig, da du diese Tools möglicherweise auch für Produktbereitstellungen verwenden kannst. Die wichtigen Dimensionen für die Bewertung dieser Tools unterscheiden sich jedoch sehr zwischen Entwicklung und Produktionshosting.

Die folgenden Aspekte sind für Softwareentwicklungsfälle relevant:

• Einfache Installation
• Einfache Bedienung, Komplexität
• Funktionsvollständigkeit (insbesondere für die Entwicklung und Produktionsparität)
• Ressourcenverbrauch
• Gesamte Benutzerfreundlichkeit (die sogenannte Entwicklererfahrung, DX)

Diese Liste der Bewertungskriterien ist nicht abschließend. Es gibt auch einige Aspekte, die die Arbeit mit diesen Tools attraktiv machen, wie persönliche Vorlieben. Ich werde jedoch nicht auf alle diese Kriterien in diesem Artikel eingehen.

Alle Tools sind in der Lage, dem Entwickler eine dedizierte Kubernetes-Umgebung zum Erlernen von Kubernetes, zum Herumspielen oder zur Lösung von Entwicklungsaufgaben bereitzustellen.

Minikube vs. k3d

Minikube

minikube{target="_blank"} ist eine der ausgereiftesten Lösungen auf dem Markt. Als unser Team bei Blueshoe im Jahr 2017 begann, Kubernetes zu übernehmen, war minikube bereits verfügbar. Die erste Version 0.1.0 wurde am 30. Mai 2016 veröffentlicht, kurz nach dem ersten Commit auf Github{target="_blank"} am 16. April 2016.

{.object-cover .max-w-full .mb-5}

minikube wurde von einer Kubernetes SIG, einer Interessengruppe, gestartet, die den Bedarf an lokalen Kubernetes-Umgebungen erkannte. Heute ist die SIG eng mit dem Kubernetes-Entwicklungsteam verbunden{target="_blank"} und daher auf dem neuesten Stand des offiziellen Kubernetes-Codebasis.

:::GlobalPodcastSection{:videoId="tyvE9VlSWkE" :videoPosition="left" .mb-6} ::::GlobalPreTitle{:color="text-bs-green" .mb-3} TOOLS FOR THE CRAFT ::::

::::GlobalTitle{:tag="h3" .mb-6} E1: Kubernetes-Entwicklungsumgebungen ::::

::::GlobalParagraph{:font-size="lg" .mb-4} Michael und Robert sprechen darüber, wie wir von Docker Compose zu einer echten Entwicklung mit Kubernetes gekommen sind. Sie diskutieren die verschiedenen Herausforderungen und welche Tools helfen können, Entwicklungsumgebungen näher an die Produktionsumgebung heranzuführen. :::: :::

Alleskönner für verschiedene Plattformen

Ein sehr wichtiger Unterschied zwischen Minikube und allen anderen Teilnehmern ist, dass es Kubernetes-Cluster mit einem der verschiedenen Treiber{target="_blank"} bereitstellen kann. Diese Treiber implementieren die Art und Weise, wie du den Kubernetes-Cluster auf einer Entwicklungs-Maschine ausführst: entweder in einer virtuellen Maschine (z.B. Hyper-V, KVM2, QEMU oder andere) oder in einer Container-Laufzeitumgebung (z.B. mit Docker oder Podman). Wenn man sich Minikube mit den oben genannten Bewertungsaspekten ansieht, kann man Unterschiede in den Details zwischen diesen Treibern feststellen. Aber im Allgemeinen abstrahiert Minikube die Implementierung des Treibers für den Entwickler.

Daher ist es sehr wahrscheinlich, dass Minikube Kubernetes für praktisch jede Plattform ausführen kann, an der ein Entwickler arbeitet. Mit einer einheitlichen Benutzeroberfläche ist Minikube eine sehr plattformunabhängige Lösung. Wenn dein Team mit Windows, macOS, Linux oder sogar exotischeren Plattformen arbeitet, ist es ein großer Vorteil, wenn alle Mitglieder das gleiche Tool verwenden. Du kannst Wissen leichter teilen, Skripte für die Automatisierung bereitstellen und Dokumentation erstellen, die alle Plattformen gleichermaßen abdeckt.

Ein großer Pluspunkt für Minikube ist seine umfassende Dokumentation. Sie enthält nicht nur technische Referenzen, sondern auch eine lange Liste von Tutorials für viele spezifische Anwendungsfälle und Bereitstellungsszenarien.

Verwende alle K8s-Funktionen mit Minikube

Mit Minikube kann ein Entwickler praktisch jede erforderliche Kubernetes-Funktion verwenden. Einige von ihnen müssen mit dem Flag –feature-gates aktiviert werden. Dies ist eine Reihe von Schlüssel-Wert-Paaren, die Feature-Gates für experimentelle Funktionen beschreiben. Andere Funktionen werden vom Addons-System von Minikube gesteuert. Addons können von Drittanbietern integriert werden. Hier ist eine Liste von Addons von meinem System.

Diese Addons werden aktiviert mit...

minikube addons enable [...]

...und ermöglichen es einem Minikube-Cluster, diese bestimmte Funktion im lokalen Entwicklungsscluster bereitzustellen. Wenn du beispielsweise Volumesnapshots benötigst, wie wir es beim Aufbau des Getdeck Beiboot-Regalfeatures getan haben, führe einfach Folgendes aus:

minikube addons enable volumesnapshots

Das macht es sehr bequem, eine solche Funktion zu verwenden, ohne jede Entwicklungsumgebung von Anfang an aufzublähen. Außerdem stehen dem Team dieselben Addons zur Verfügung, vorausgesetzt, sie verwenden alle dieselbe Version von Minikube.

Minikube-Profile: mehrere logische Cluster auf einer Entwicklungs-Maschine

Als wir begannen, Kubernetes zu übernehmen, suchten wir nach einer Lösung, die es uns ermöglichte, mehrere logische Cluster auf einer Entwicklungs-Maschine zu verwalten. In den Jahren 2016/2017 legte Minikube nicht viel Wert auf dieses spezielle Feature. Es war nur möglich, einen Cluster pro Maschine zu starten, und es gab nur eine Single-Node-Cluster-Konfiguration. Aus diesem Grund haben wir uns bei Blueshoe entschieden, mit k3d zu arbeiten. Minikube hat jedoch dieses wichtige Entwickler-Feature aufgeholt und unterstützt jetzt mehrere sogenannte Minikube-Profile.

Minikube-Profile sind logische Cluster, die separat voneinander gestartet und gestoppt werden können. Es ermöglicht einem Entwickler, mehr als eine Kubernetes-basierte Entwicklungsumgebung zu haben. Denke nur an mehrere getrennte Projekte, die unterschiedliche Kubernetes-API-Versionen, Funktionen oder einfach unterschiedliche Workloads erfordern, die in ihnen ausgeführt werden. Du kannst...{target="_blank"}:

minikube start -p myprofile1

...ausführen und du erhältst einen leeren neuen Cluster mit einem frischen Profil, das neben anderen Profilen existieren kann.

k3d

k3d ist in Bezug auf die Bereitstellung auf einer Entwicklungs-Maschine eingeschränkter. Von Anfang an unterstützte k3d nur eine lokale Container-Runtime für die Ausführung des Kubernetes-Clusters. Wie ich zuvor erwähnt habe, war es jedoch immer möglich, mehrere separate Cluster für die Entwicklung auf einem Host zu verwalten. Das war ein echtes Killer-Feature, insbesondere für Blueshoe, da wir mehrere verschiedene Kubernetes-Projekte für verschiedene Kunden betreiben. Gerade bei unserer Wartungsarbeit ist es ein Muss, gleichzeitig eine topaktuelle (keine Sorge, ich habe diesen Begriff erfunden) Entwicklungsumgebung sowie eine stabile, produktionsnahe Umgebung zu haben. Als Entwickler muss ich Fehlerkorrekturen in kürzester Zeit bereitstellen und die Entwicklung neuer Funktionen vorantreiben.

{.object-cover .max-w-full .mb-5}

k3d basiert auf k3s, einer schlanken Kubernetes-Lösung, die von Rancher entwickelt wird. K3d ist jedoch nicht eng mit k3s verbunden und wird von einer Entwicklergemeinschaft{target="_blank"} vorangetrieben.

Das Besondere an k3s ist, dass es einige der standardmäßigen Kubernetes-Komponenten wie etcd{target="_blank"} durch weniger skalierbare und ressourcenintensive Alternativen (z. B. SQLite) ersetzt. Darüber hinaus wird das gesamte System in eine sehr kleine ausführbare Binärdatei kompiliert (weniger als 40 MiB), was auch den Speicherplatzbedarf sehr gering hält. Das Basis-Kubernetes-System k3s wurde ursprünglich für IoT- und Edge-Computing-Umgebungen entwickelt. Ich würde sagen, dass es auch für Entwicklungsumgebungen perfekt ist, da diese geringen Ressourcenanforderungen perfekt passen. Den Vergleich des Ressourcenverbrauchs werden wir später in diesem Artikel sehen.

Da k3d nur ein Wrapper für k3s ist, kann es sich auf die Entwicklererfahrung konzentrieren. Es wird mit sehr guter Dokumentation{target="_blank"} geliefert, genau wie bei Minikube, die auch Tutorials für bestimmte Anwendungsszenarien enthält. Zum Beispiel findest du ein Beispiel für einen Entwicklungsworkflow mit Tilt{target="_blank"} und einen Build-Push-Test-Zyklus mit k3d's Container-Image-Sharing{target="_blank"}-Funktion.

Gut für Teams: Teilen von k3d-Konfigurationen

Ein großer Vorteil, den k3d bietet (den Minikube zu diesem Zeitpunkt vermisst), ist, dass k3d eine Cluster-Konfigurationsdatei{target="_blank"} bereitstellt (ab Version 4.0.0). Dadurch können Entwicklungsteams die Konfiguration eines k3d-Clusters in einer lokalen YAML-Datei speichern, die im Team geteilt werden kann. Diese Datei enthält die Konfiguration für fast alle Parameter, die einen Cluster ausmachen, z. B. die Anzahl der Clusterknoten, die Kubernetes-Version, die lokal zugeordneten Ports, Registrierungen, Funktionen und vieles mehr. Mit dieser Datei kannst du die gleiche Cluster-Konfiguration im Team problemlos bereitstellen, ohne dass der Entwickler einer Anleitung oder einem Skript folgen muss, um seinen lokalen Kubernetes-Cluster einzurichten. Du kannst k3d cluster create --config mycluster1.yaml ausführen und alles wird wie angegeben bereitgestellt. Meiner Meinung nach ist das viel einfacher als das, was du derzeit mit Minikube tun kannst.

Keine Sorge um kubectl

Mit beiden Lösungen, Minikube und k3d, wird der kubectl-Kontext des Entwicklers automatisch auf den neu erstellten Cluster gesetzt. Beide Alternativen benennen ihren kube-Kontext nach dem Cluster-Namen/Profil-Namen, der beim Erstellen des Clusters angegeben wurde. Auf diese Weise kann der Entwickler problemlos mit der Arbeit beginnen, ohne sich um die kubectl-Konfiguration kümmern zu müssen.

Weniger Komplexität, weniger CLI-Befehle

Da k3d nicht die Komplexität von Minikube bietet, ist die CLI viel weniger umfassend, aber dennoch einfach. Ich würde sagen, für Entwickler, die mit der CLI arbeiten, ist das ein Pluspunkt. Insbesondere bei Verwendung der k3d-Konfigurationsdatei kann ich die meisten Eingaben auf der Befehlszeilenschnittstelle einsparen und die Oberfläche der CLI auf die wenigen erforderlichen Befehle reduzieren: Starten, Stoppen und Löschen eines Clusters.

Ich vermute, dass in k3d nur wenige Funktionen fehlen, da sie in k3s nicht unterstützt werden, aber für 95% der Entwicklungsarbeit sollte es völlig ausreichend sein. Sogar der Snapshot-Controller{target="_blank"} wurde kürzlich zu k3s hinzugefügt.

Minikube vs. kind

Kind ist ein weiteres Projekt, das von einer Kubernetes SIG{target="_blank"} vorangetrieben wird. An diesem Punkt konnte ich nicht herausfinden, warum es noch gepflegt wird (ich habe einen Grund gefunden, aber lies weiter). Kind ist ein Akronym für "Kubernetes in Docker" und entstand aus der Idee, Kubernetes auf einer Container-Runtime (anstelle einer virtuellen Maschine) auszuführen. Heutzutage bevorzugt minikube jedoch ebenfalls Docker als Bereitstellungsoption, sodass es in diesem wichtigen Punkt keinen Unterschied mehr zwischen minikube und kind gibt. Sie haben jedoch eine schöne Seite in ihrer Dokumentation, auf der die Prinzipien und Zielanwendungsfälle von Kind{target="_blank"} erklärt werden. Ich würde sagen, es läuft alles auf Automatisierung hinaus.

{.object-cover .max-w-full .mb-5}

Konfigurationsdateien und K8s-Funktionen

Ähnlich wie k3d bietet auch Kind die Möglichkeit, Konfigurationsdateien{target="_blank"} zu verwenden. Ähnlich wie bei k3d kannst du...

kind create cluster --config mycluster1.yaml

... ausführen, um einen lokalen Kubernetes-Cluster basierend auf der angegebenen Konfiguration zu erstellen.

Kind bietet auch Feature Gates, um experimentelle Kubernetes-Funktionen und viele andere Konfigurationsoptionen zu aktivieren.

Podman? Rootless? Kind!

Im Vergleich zu Minikube, wo die Verwendung von Podman als experimentell betrachtet wird, bietet Kind solide Unterstützung für Podman. Das Projektteam hat sogar erhebliche Anstrengungen unternommen, um Kind auch im rootless{target="_blank"}-Modus auszuführen. Für diejenigen, für die dies wichtig ist, ist Kind derzeit die einzige Lösung. Natürlich bringt es jedoch mehrere Einschränkungen mit sich.

Kind verfügt über eine weniger komplexe CLI im Vergleich zu Minikube. Sie verzichtet auch auf Emojis, was ein Vorteil sein kann. Aber das ist Geschmackssache.

Wenn man die Startseite beider Produkte vergleicht, behauptet Minikube, sich "[...] auf die Unterstützung von Anwendungsentwicklern und neuen Kubernetes-Benutzern zu konzentrieren{target="_blank"}.", während Kind "ursprünglich für das Testen von Kubernetes selbst entwickelt wurde, aber auch für die lokale Entwicklung oder CI verwendet werden kann". Ich denke, das gibt eine gewisse Vorahnung davon, worum es geht.

Vergleich von Minikube, k3d und Kind im Jahr 2023

Lass uns nun einen direkten Vergleich dieser drei Alternativen für die lokale Kubernetes-Entwicklung im Jahr 2023 durchführen.

Beliebtheit

Beliebtheit ist ein Indikator dafür, wie gesichert die fortlaufende Wartung eines Produkts ist. Eine gute Währung, um dies zu messen, ist die Anzahl der GitHub-Stargazers:

1. Minikube: >25,8k Sterne auf GitHub
2. Kind: >11,1k Sterne auf GitHub
3. k3d: >4,1k Sterne auf GitHub

Wie du sehen kannst, haben alle drei Kandidaten bereits eine erhebliche Beliebtheit auf GitHub. Minikube ist jedoch bei weitem die beliebteste Option. Ich würde sagen, dass alle drei Lösungen aufgrund ihrer lebendigen Community dauerhaft gewartet werden.

Leistungsbewertung

Die folgende Leistungsbewertung wurde auf einem Ubuntu-System durchgeführt, das auf einem Intel Core i7 (8. Generation) mit 16 GiB RAM läuft. Obwohl ich auf Linux arbeite, habe ich Docker Desktop auf meinem Rechner verwendet und hoffe, vergleichbare Ergebnisse mit anderen Plattformen zu sammeln.

Hinweis: Docker Desktop führt auf Linux ebenfalls eine QEMU-basierte virtuelle Maschine aus, genau wie auf Windows und macOS. Das Kubernetes in Docker Desktop wurde deaktiviert.

Ich habe die folgenden Versionen der Tools verwendet:

• Minikube: Minikube-Version: v1.26.1
• Kind: Kind v0.17.0 go1.19.2 linux/amd64
• k3d: k3d-Version v5.4.1

Cluster-Startzeit

In diesem Testfall messe ich die Zeit vom Anfordern eines neuen lokalen Clusters bis zu dessen Start. Ich habe keine speziellen Konfigurationen angegeben, sondern die Standardwerte verwendet.

Ich habe diesen Test fünfmal durchgeführt und das beste Ergebnis aller Messungen genommen, damit keine Container-Images während der gemessenen Zeit heruntergeladen werden.

Die Startzeiten sind wie folgt:

• Minikube (Docker): 29,448s
• k3d: 15,576 s
• Kind: 19,691 s

Die Startzeiten aller Kandidaten sind ziemlich nah beieinander. Wenn du beispielsweise zuerst die erforderlichen Container-Images herunterladen musst, wird dies wahrscheinlich den Gesamtprozess mehr beeinflussen als der zugrunde liegende Bootstrapping-Prozess. Mit Ausnahme des kvm2-Treibers von Minikube. Dieser Prozess ist viel aufwändiger und beinhaltet das Hochfahren einer gesamten virtuellen Maschine. Ich gehe davon aus, dass VM-basierte Treiber sowieso nicht die erste Wahl für die Mehrheit der Entwickler sind.

Cluster-Abschaltzeit

Ich habe die Zeiten für das Stoppen und Löschen eines Clusters gemessen. Ich habe diesen Test mehrmals durchgeführt und das beste Ergebnis aller Messungen genommen:

• Minikube (Docker): 2,616 s
• k3d: 0,700 s
• Kind: 0,805 s

Alle Tools stoppen und löschen ihre Cluster sehr schnell. Kein großer Unterschied zwischen ihnen.

Cluster-Ressourcenverbrauch

Ich habe einen lokalen Kubernetes-Cluster gestartet und etwa 120 s nach dem abgeschlossenen Start die Ressourcenverbräuche für einen im Leerlauf befindlichen Einzelknoten-Cluster überprüft. Dafür habe ich den Befehl "docker stats" verwendet.

Bitte beachte, dass ich traefik bei k3d deaktiviert habe, um eine vergleichbare Konfiguration zu erhalten. Da k3d mindestens zwei Container ausführt, habe ich die Verbräuche aggregiert.

Hier sind die Ergebnisse:

• Minikube mit Docker (CPUs=8, Memory=15681 MiB): CPU: ~20% Speicherauslastung: ~680,8 MiB
• K3d (CPUs=8, Memory=15681 MiB): CPU: ~20% Speicherauslastung: ~502 MiB
• Kind (CPUs=8, Memory=15681 MiB): CPU: ~20% Speicherauslastung: ~581 MiB

Bei Betrachtung der Ergebnisse kann man einige Unterschiede zwischen Minikube und k3d oder Kind erkennen. Für einen leeren und im Leerlauf befindlichen Cluster benötigt Minikube etwa 35% mehr Speicher als k3d und 17% mehr Speicher als Kind. Ich vermute, dass mit zunehmender Anzahl von Workloads der Ressourcenverbrauch von Minikube sehr schnell an die Grenze der Entwicklungsmaschine stoßen wird.

In jedem Fall war ich sehr überrascht von der CPU-Auslastung, die von 10% auf 50% stieg, obwohl in diesen Clustern nichts los war. Dieses Muster trat bei allen Kubernetes-Anbietern auf.

Benutzerfreundlichkeit und Entwicklererfahrung (DX)

Benutzerfreundlichkeit und DX sind sehr komplexe Themen und es ist schwierig, quantitative Metriken zu finden. Dennoch möchte ich einige meiner Erkenntnisse hervorheben, die mir an den Tools gefallen oder nicht gefallen.

Alle Tools sind derzeit nur als CLI (Befehlszeilenschnittstelle) verfügbar. Das ist für mich in Ordnung und wahrscheinlich für einen Großteil der Entwickler auf Linux und macOS. Soweit ich weiß, arbeiten nur wenige Entwickler unter Windows gerne mit einem Terminal. Aus ihrer Sicht bietet eine CLI wahrscheinlich nicht die bestmögliche DX. Es gibt jedoch einige GUIs (grafische Benutzeroberflächen). Meine Ergebnisse dazu habe ich im nächsten Kapitel hinzugefügt.

Minikube

Minikube wird mit einer CLI geliefert, die viele Emojis verwendet. Das ist eine sehr individuelle Vorliebe, aber ich finde sie ein wenig nervig. Allerdings können sie deaktiviert werden{target="_blank"}.

Die Installation ist sehr einfach. Du kannst es über Brew, ein Skript oder als Binärdatei herunterladen und manuell in deinen Pfad legen.

Minikube macht es sehr einfach und schnell, einen neuen Cluster zu erstellen. Es ist nur ein Befehl mit zwei Wörtern: minikube start. So einfach ist das. Wie gibt man Konfigurationsoptionen an? Genau! Direkt als Argument für den Startvorgang. Eine sehr wichtige Konfiguration ist die Kubernetes-API-Version. Es spielt keine Rolle, welche Version von Minikube du auf deinem lokalen Rechner installiert hast. Du kannst immer eine andere Kubernetes-API-Version{target="_blank"} als die Standardversion auswählen. Das ist sehr einfach und intuitiv. Dein Produktionscluster läuft auf Version 1.25.5, dann möchtest du Folgendes ausführen:

minikube start --kubernetes-version=1.25.5

...und du erhältst die richtige API- Version.

Andere grundlegende Clusteroperationen sind ähnlich: Das Anhalten, Stoppen oder Löschen des Clusters erfolgt immer mit nur einem Befehl.

Saubere CLI, schnelles Kubernetes Dashboard

Die Befehlspalette der minikube CLI ist sauber und übersichtlich. Wenn du mit mehreren Clustern parallel arbeitest, die entweder gestartet sind oder sich im Ruhezustand befinden, kannst du immer das Argument -p/--profile zu den meisten Aktionen hinzufügen und die gewünschte Aktion auf dem angegebenen Cluster ausführen.

Wie listet man alle vorhandenen Cluster auf der Maschine auf? Das ist eine

minikube profile list

...und dir wird eine Liste der erstellten Cluster angezeigt.

Wenn du einen laufenden Cluster hast, kannst du immer das offizielle Kubernetes-Dashboard mit minikube dashboard öffnen (für das Standardprofil). Natürlich kannst du das Kubernetes-Dashboard immer auf jedem Cluster installieren, aber dieser Befehl ist wirklich eine Abkürzung, um nach wenigen Sekunden eine visuelle Benutzeroberfläche für diesen Cluster zu erhalten.

{.object-cover .w-full .mb-5}

Ingress hinzufügen

Wenn du eine Kubernetes-Bereitstellung oder einen Dienst auf deiner lokalen Entwicklungsmaschine freigeben musst, verwende einfach die Netzwerk- und Verbindungskommandos:

• minikube service: gibt eine URL zurück, um eine Verbindung zu einem Service herzustellen
• minikube tunnel: Verbindung zu LoadBalancer-Services herstellen

Ein häufiges Komponente, die über Addons aktiviert werden muss, ist der Ingress-Controller. Normalerweise ist dies die bevorzugte Methode, um eine Anwendung freizugeben. Mit Minikube hast du standardmäßig keinen Ingress-Controller zur Verfügung, stattdessen musst du ihn manuell bereitstellen. Glücklicherweise gibt es ein Addon mit dem bekannten und weit verbreiteten "nginx-ingress". Führe einfach aus:

minikube addons enable ingress

und du kannst Ingress-Objekte erstellen, die unter http://192.168.49.2 bereitgestellt werden. Bitte beachte, dass die IP-Adresse deines Clusters eine andere sein kann. Du kannst sie herausfinden mit

minikube ip

Kritik

Es gibt nur eine Kritik, die ich an Minikube habe: die schlechten Automatisierungsoptionen. Es gibt keine Konfigurationsdatei, die ich einfach in den Befehl eingeben kann, um einen gesamten Cluster gemäß den Vorgaben einzurichten. Stattdessen muss ich all diese Befehle sequentiell ausführen. Das ist schade und kann in Zukunft verbessert werden.

Ein Befehl zum Generieren des Tab-Completion-Skripts ist auch für viele Terminals verfügbar.

k3d

Die Installation der k3d CLI ist sehr einfach. Du kannst sie über Brew, ein Skript oder als Binärdatei herunterladen und manuell in deinen Pfad legen. Die CLI benötigt jedoch etwas Zeit, um sich daran zu gewöhnen. Im Vergleich zu Minikube bietet k3d nicht so viele Funktionen auf der Befehlszeile, aber du kannst mit k3d fast alle erforderlichen Setups genauso gut realisieren.

Weniger CLI-Optionen, aber Ingress out of the box

Ein Entwickler wird die meisten praktischen Funktionen vermissen, die die Minikube CLI bietet, aber bei der k3d-CLI fehlen. Das ist jedoch kein großes Problem. Wenn du ein erfahrenerer Entwickler bist, arbeitest du wahrscheinlich sehr effizient mit kubectl und kennst andere Tools aus dem Ökosystem wie Helm oder Kustomize. Wenn du beispielsweise das Kubernetes-Dashboard benötigst, musst du es über Helm installieren (oder eine andere Installationsmethode). Das ist kein großes Problem, aber es ist nicht so bequem wie bei Minikube. Sobald du einen Cluster erstellt hast, wird dein globaler kubeconfig-Kontext so eingestellt, dass er auf den neuen Cluster zeigt.

k3d wird mit Traefik als Ingress-Controller geliefert. Es ist immer installiert, es sei denn du deaktivierst es explizit mit einem Konfigurationsflag. Bei Blueshoe fanden wir es sehr hilfreich, es immer verfügbar zu haben, da wir dieses wichtige Feature während der Entwicklungseinrichtung nicht extra handhaben mussten.

Port-Mapping

Das Festlegen des Port-Mappings auf deinem lokalen Rechner kann etwas umständlich sein. Wenn du beispielsweise eine Anwendung über Ingress auf Port 8080 auf deiner Entwicklungsmaschine freigeben möchtest, musst du dies während der Clustererstellung angeben. Und die Notation ist für Entwickler nicht super intuitiv. Schaue dir die Dokumentation an. Erstelle einen Cluster mit einer festen Reihe von Port-Mappings wie folgt:

k3d cluster create -p "8080:80@loadbalancer" -p "8443:443@loadbalancer" …

Es sind auch andere Portkonfigurationen möglich, aber aus Sicht der Entwicklererfahrung ist es nicht sehr praktisch, den gesamten Cluster neu zu erstellen, nur weil man vergessen hat, die Ports zuzuordnen.

Wenn du nur als Entwickler in einem Team arbeiten möchtest, erhältst du wahrscheinlich sowieso eine Cluster-Konfigurationsdatei. Mit dieser Datei und den richtigen Spezifikationen wird es dir leichtfallen, alles einzurichten. Du musst nur noch starten:

k3d cluster create --config myconfig.yaml

...und innerhalb weniger Sekunden bist du startklar. Das ist schnell und sehr bequem. Ein großes Plus für die Entwicklererfahrung mit k3d.

Es gibt auch einen Befehl, um das Tab-Completion-Skript für viele Terminals zu generieren.

kind

kind ist in den meisten Aspekten sehr ähnlich zu k3d. Genau wie k3d und minikube kannst du es mit beliebten Paketmanagern, Skripten und als einzelne ausführbare Datei installieren.

Wenn du bereits mit der k3d CLO vertraut bist, wirst du dich wahrscheinlich schnell an die kind CLI gewöhnen. Die Optionen sind fast identisch, und auch die Einschränkungen sind ähnlich.

Es gibt in diesem Abschnitt nicht viel hinzuzufügen.

Entwicklungsoptionen

Es kann herausfordernd und umständlich sein, deinen eigenen Code in einem der Kubernetes-Tools auszuführen. Zunächst musst du Container-Images erstellen, da Kubernetes nur das Ausführen von Container-Instanzen zulässt. Normalerweise bezieht Kubernetes diese Images aus einem externen Container-Register (wie Dockerhub, quay.io oder einem selbst gehosteten Register). Wenn ein Entwickler eigenen Code ausführen möchte, erfordert dies eine Arbeitslastspezifikation und ein Register, das das Container-Image bereitstellt. Dies kann zu einem enormen Effizienzverlust führen.

Glücklicherweise bieten alle Tools einige Workarounds oder Abkürzungen, um diese Hürde zu überwinden (zumindest teilweise).

Lokalen Code einbinden

minikube und k3d bieten die Möglichkeit, Code direkt von der Entwicklermaschine in den laufenden Kubernetes-Knoten einzubinden.

Mit k3d ist dies mit dem lokalen Pfadbereitsteller{target="_blank"} von k3s möglich. Ein Entwickler kann einen PersistentVolumeClaim{target="_blank"} erstellen, der auf einen Pfad im Host-System verweist. Anschließend kann dieser PVC in eine Container-Instanz eingebunden und im Container-Prozess verwendet werden. Dadurch kannst du entweder einen Container-Prozess mit dem aktuellen Code ausführen (den Container neu starten, sobald der Code geändert wurde) oder den Container-Prozess mit Hot-Reloading-Funktionen starten. Natürlich ist dies stark abhängig von einem Framework oder Prozess, der ausgeführt wird, und hat nichts mit Kubernetes zu tun. Dies funktioniert jedoch nur bei der Erstellung des Clusters wie folgt:

k3d cluster create my-cluster --volume /my/home/go/src/github.com/nginx:/data

Das Hinzufügen von Volumes nachdem der Cluster erstellt und ausgeführt wird, ist noch ein offenes Problem{target="_blank"}.

Mit dem minikube mount{target="_blank"}-Befehl ist dasselbe möglich. Du kannst sogar Speichervolumes nach der Erstellung des Clusters einbinden. Anstatt einen Kubernetes PVC zu verwenden, kannst du den Code mit der hostPath-Eigenschaft eines Pods einbinden, was es etwas bequemer macht.

Lokales Container-Image laden

Ein praktischerer und weniger invasiver Ansatz, um lokalen Code in minikube, k3d und kind auszuführen, ist die Load-Image-Funktion. Warum weniger invasiv? - Als Entwickler musst du die Kubernetes-Objekte (Pods, PVCs usw.) für deine lokale Umgebung nicht anpassen, basierend auf den Pfaden, die möglicherweise einzigartig für dein System sind (z. B. das Einbinden von Home-Verzeichnissen unterscheidet sich normalerweise zwischen Entwicklern). Stattdessen stellst du ein Container-Image für deinen lokalen Cluster zur Verfügung, ohne dass ein dediziertes Container-Register erforderlich ist. Das bedeutet, du erstellst ein lokales Container-Image basierend auf deinem aktuellen Code (z. B. docker build . -t myimage) und überträgst es direkt in dein lokales Kubernetes, um es auszuführen.

Dieser Ansatz wird von fast allen Kubernetes-Entwicklungstools wie tilt.dev{target="_blank"}, devspace{target="_blank"} und anderen genutzt. Diese Arten von Entwicklungstools führen automatisch einen Build-Load-Execute-Zyklus durch, während sie auf Codeänderungen achten. Dieser Ansatz ist langsamer als das Einbinden von lokalem Code mit einem angepassten Container-Prozess, aber zumindest modifiziert er (normalerweise) nicht die Kubernetes-Objekte.

Um dies mit minikube zu tun, führst du aus...

minikube image load <name>

Bei k3d lade ein Image mit...

k3d image import <name>

und bei kind ist es...

kind load docker-image <name>

...von deiner Konsole aus.

Es gibt noch einige andere verfügbare Tools wie ksync, das Code in Container kopiert, die in Kubernetes laufen, aber mit einem allgemeineren technischen Ansatz. Eine großartige Option für Entwickler, die mit jeder Art von Kubernetes-Umgebung, sei es lokal oder remote, arbeiten, wird im nächsten Abschnitt vorgestellt.

Die beste Alternative für die lokale Kubernetes-Entwicklung

Die oben genannten Optionen machen nicht alle erforderlichen Entwicklungsfunktionen leicht zugänglich. Zum Beispiel ist das Überschreiben von Umgebungsvariablen nicht sehr einfach, da sie aus verschiedenen Kubernetes-Objekten stammen können: ConfigMaps, Secrets, Pod-Spezifikationen, Downward API und andere. Ein Entwickler, der nicht daran gewöhnt ist, mit Kubernetes zu arbeiten, könnte Schwierigkeiten haben, mit Umgebungsvariablen herumzuspielen.

Der allmächtige Debugger, der nicht einfach an einen in Kubernetes ausgeführten Prozess angehängt werden kann, ist mit den oben genannten Optionen nicht sehr praktisch. Die oben genannten Optionen haben auch einige andere Nachteile.

An diesem Punkt hat Blueshoe beschlossen, ein anspruchsvolleres Entwicklungstool zu entwickeln, das Entwickler von der Zeit im Build-Load-Execute-Zyklus oder vom Ausführen lokaler Verzeichnisse in Kubernetes entlastet: Gefyra.

Gefyra verbindet sich nicht nur mit lokalen Kubernetes-Clustern, die auf minikube, k3d oder kind basieren. Es verbindet sich mit praktisch jedem Kubernetes-Cluster, der irgendwo läuft. Dies ermöglicht Gefyra-Benutzern, dedizierte Entwicklungsumgebungen in der Cloud zu erstellen und gleichzeitig lokales Codieren für die Entwickler bereitzustellen.

Gefyra führt den Code auf einer lokalen Docker-Laufzeitumgebung aus (ganz ohne Kubernetes), erledigt jedoch einige Netzwerk- und Prozessmagie, um die lokale Container-Instanz mit einem Kubernetes-Cluster zu verbinden. Der Prozess auf einer Entwicklermaschine fühlt sich an, als würde er direkt in einem Kubernetes-Namespace ausgeführt (einschließlich Netzwerkfunktionen) und bietet den Vorteil, dass alle gängigen Entwicklungstools lokal verfügbar sind. Dies kann die Entwicklungsgeschwindigkeit drastisch verbessern und gleichzeitig eine sehr gute Übereinstimmung zwischen Entwicklung und Produktion gewährleisten.

Wenn du eine Meinung zu Gefyra hast, fehlende Funktionen oder einen Fehler melden möchtest, kannst du gerne ein Issue oder eine Diskussion auf GitHub{target="_blank"} eröffnen.

Grafische Benutzeroberflächen und Docker Desktop

Wenn du nach einer grafischen Benutzeroberfläche für deinen lokalen Kubernetes-Cluster suchst, wirf einen Blick auf K3x{target="_blank"} und minikube GUI{target="_blank"}. Beide Projekte befinden sich zum Zeitpunkt des Verfassens dieses Artikels noch in einem sehr frühen Entwicklungsstadium.

Die Hauptziele dieser Projekte sind es, dem Benutzer zu ermöglichen, Kubernetes-Cluster mit einem Mausklick zu erstellen, zu starten und zu beenden. Darüber hinaus ermöglichen sie Entwicklern, die wichtigsten Operationen mit Tastenkombinationen zu verwalten und die Lernkurve bei der Verwendung von Kubernetes zu reduzieren.

Und dann gibt es Docker Desktop, das eine eigene Kubernetes-Lösung mitbringt. Allerdings bietet Kubernetes in Docker Desktop nicht wirklich die Funktionen, die minikube, k3d oder kind bieten. Du kannst lediglich einen Kubernetes-Cluster mit einer grafischen Benutzeroberfläche starten und stoppen.

Eine cloud-basierte Kubernetes-Entwicklungsumgebung mit Getdeck

Bei Blueshoe haben wir festgestellt, dass lokale Kubernetes-Cluster mit wachsenden Arbeitslasten eine Herausforderung darstellen. Insbesondere unter Windows und macOS verwandelt selbst eine geringe Anzahl von Entwicklungsaufgaben in Kubernetes die Entwicklungsmaschine in einen langsamen Zombie. Das war sehr unpraktisch, daher haben wir uns entschieden, nach anderen Lösungen für unsere Entwicklungsteams zu suchen. Für die komplexe Kubernetes-native Softwarearchitektur, an der wir arbeiten, war es nicht möglich, eine gemeinsame Cluster-Konfiguration zu erstellen. Das Aufteilen eines physischen Clusters mit Namespaces ist etwas, das viele Entwicklungsteams derzeit tun. Stattdessen wollten wir unseren Entwicklern dedizierte, vollwertige, bedarfsgesteuerte Kubernetes-Cluster zur Verfügung stellen. Aber mit allen Funktionen, die eine reife Entwicklungsorganisation benötigt, wie z.B. Lebenszyklusmanagement, Ressourcenbeschränkungen usw.

Dafür haben wir Getdeck entwickelt.

Mit Getdeck Beiboot muss ein Team von Entwicklern nur einen physischen Kubernetes-Cluster betreiben. Der Beiboot-Operator erstellt "virtuelle" Kubernetes-Cluster innerhalb des Host-Clusters und verwaltet deren Lebenszyklen. Die Erstellung einer ad-hoc Kubernetes-Umgebung dauert etwa 20 Sekunden und beansprucht keine Ressourcen auf einer Entwicklungsmaschine.

Darüber hinaus ermöglicht die Beiboot Shelf-Funktion Entwicklern, vorkonfigurierte Kubernetes-Cluster von der Stange zu erstellen. Das bedeutet, es dauert nur wenige Sekunden länger und Entwickler haben einen dedizierten Kubernetes-Cluster, der alle erforderlichen Arbeitslasten für ihre Aufgaben enthält und alle Daten enthält, die erforderlich sind, um die Produktionsinfrastruktur abzubilden. Dies ist nicht nur bequem für Entwicklungszwecke, sondern auch für automatisierte Aufgaben in CI/CD-Szenarien.

Und das Beste daran: Diese Cluster werden zum lokalen Rechner getunnelt, so dass es sich so anfühlt, als würden sie auf dem lokalen Host ausgeführt werden. Das ist sehr praktisch.

Getdeck kommt jetzt auch mit einer grafischen Benutzeroberfläche: Getdeck Desktop{target="_blank"}.

Damit können Entwickler Beiboot-Cluster in kürzester Zeit verwalten. Sie können eine Verbindung dazu herstellen und damit arbeiten, als würde es auf ihrem lokalen Rechner laufen, aber ohne dass der Computer abstürzt.

Du kannst dies mit unserem kostenlosen Getdeck-as-a-Service-Angebot einfach testen. Lade einfach die Desktop-App herunter, gib einige Ports ein, erstelle einen Cluster und beginne mit der Entwicklung in einem virtuellen Kubernetes-Cluster, der von uns gehostet und bezahlt wird. Der Cluster unterliegt folgenden Einschränkungen:

• maximale Lebensdauer des Clusters von 4 Stunden
• keine Sitzungszeitüberschreitung
• maximal 3 Knoten (maximal 2 Kerne, 6 GB RAM, 50 GB Speicher)
• maximal 1 Cluster gleichzeitig

Abschließende Bemerkungen

Es ist sehr schwierig, in diesem Vergleich einen Gewinner zu ermitteln. Alle drei etablierten Lösungen, minikube, k3d und kind, sind sehr ähnlich zueinander. Es gibt einige Vor- und Nachteile für jede Lösung, aber nichts, was wirklich herausragt. Das ist gut, denn es ist auch nicht wirklich möglich, das falsche Tool auszuwählen. Mir gefällt die allgemeine Benutzerfreundlichkeit aller dieser Tools, da sie eine professionelle Arbeitsumgebung ansprechen. Alle sind schnell, einfach zu installieren und ziemlich einfach zu bedienen.

Ich habe das Gefühl, dass minikube etwas voraus ist und der offiziellen Kubernetes-Entwicklungs-Roadmap am nächsten kommt. Insbesondere für einen einzelnen (potenziell unerfahrenen) Entwickler scheint die Einstiegshürde ziemlich niedrig zu sein. Es ist jedoch die Option mit dem höchsten Ressourcenbedarf. Ich würde Kubernetes-Einsteigern minikube empfehlen.

Bei Blueshoe waren wir in der Vergangenheit sehr zufrieden mit k3d. Besonders wenn du viele verschiedene Kubernetes-Cluster ausführst, wirst du über den geringeren Ressourcenverbrauch im Vergleich zu minikube erfreut sein. Wenn du in einem Team arbeitest, werden die mit k3d oder kind gelieferten Konfigurationsdateien für alle von großem Nutzen sein.

Für einige unserer automatisierten Testfälle sind wir auf minikube umgestiegen, aufgrund des --kubernetes-version Arguments. Es ist sehr einfach, die gewünschte Kubernetes-Version festzulegen und voilà, es läuft. Bei k3d musst du dir das entsprechende k3s Docker-Image ansehen, das verwendet werden soll.

Langfristig betrachten wir die lokale Kubernetes-Entwicklung tatsächlich nicht als nachhaltige Option. Remote-Entwicklungsumgebungen sind die Zukunft! Getdeck Beiboot wird alle auf Kubernetes basierenden Ressourcen ausführen, und mit Tools wie Gefyra ermöglichen wir Entwicklern, in einer echten Kubernetes-basierten Entwicklungsumgebung zu arbeiten.

Wenn du mehr über die Kubernetes-basierte Entwicklung erfahren möchtest, kannst du mir auf LinkedIn folgen{target="_blank"}, unserem Discord beitreten{target="_blank"} oder uns bei Blueshoe kontaktieren.

{.object-cover .max-w-full .mb-5}

Model Context Protocol

Das Model Context Protocol (MCP) ist eine Definition zur Bereitstellung von Kontext aus Anwendungen für LLMs. Vereinfacht gesagt beinhaltet das Protokoll Informationen, wie ein LLM eine Software (oftmals Schnittstellen) bedienen kann.

Dabei liegt es nahe, dass zur Definition eines MCP einer Anwendung bereits auf bestehende Strukturen, wie der OpenAPI Standard zurückgegriffen wird. Bevor wir MCP und OpenAPI jedoch zusammenbringen schauen wir als erstes auf ein paar Details des MCP.

Kommunikationsmodell des MCP

Die Kommunikation im Rahmen des MCP läuft als Client-Server Kommunikation ab. Der Client ist in diesem Fall das LLM, der Server ist eine Abstraktionsschicht der Anwendung, die bedient werden soll. Diese Schicht gibt an, wie der Client die dahinterliegende Anwendung bedienen kann.

Dabei kann die dahinterliegende Anwendung alles mögliche sein - eine Datenbank / Datenquelle, eine komplexe Anwendung, oder eine Schnittstelle. Als MCP Host wird hierbei das Programm bezeichnet, welches den MCP Client ausführt (z.B. Claude Desktop, ChatGPT).

Wichtig - die Grafik zeigt eine bidirektionale Kommunikation zwischen Client und Server. Das bedeutet, dass unser MCP Server aus dem Internet erreichbar sein muss. Lokal laufende MCP Server benötigen ein entsprechendes Setup, welche sie für die zumeist im Internet laufenden MCP Clients verfügbar macht (z.B. Claude Desktop oder Ngrok).

Resourcen und Tools im MCP

Ich möchte nicht zu tief in die Begrifflichkeiten des MCP einsteigen - alle Details können in der offiziellen Dokumentation{target="_blank"} gelesen werden. Wichtig für den Kontext des Blogposts sind vor allem Resources und Tools.

Resources{target="_blank"} sind vereinfacht gesprochen Datenquellen. Sie beschreiben wie der Client (das LLM) Daten von dem Server abrufen kann. Alle Formen von Daten sind denkbar: Text, Binärdaten, Bilder, Ton, Videos, strukturiert oder unstrukturiert. Für den Zugriff auf konkrete Resourcen werden i.d.R. Resource Templates verwendet. Diese erlauben dann Zugriff auf bestimmte Resourcen - beispielsweise "Gib mir die Bestellung mit der Nummer X341.".

Tools{target="_blank"} erlauben die Ausführung von Aktionen. Hierdurch wird den LLMs die Möglichkeit gegeben Aktionen mit laufenden Diensten durchzuführen. Das Anlegen oder Manipulieren eines Datensatzes, die Berechnung einer Aufgabe, das Auslösen einer Bestellung oder die Manipulation eines Bildes. Alles ist denkbar.

Verknüpfung eines LLM und einer Anwendung via MCP

Mit der Beschreibung von Resourcen und Tools verspricht das MCP nun, dass LLM in sinnvoller Art und Weise Anwendungen bedienen können. Sie heben Effizienzen und schaffen defacto eine neue Schnittstelle sowohl in der Maschine-Maschine als auch Mensch-Maschine Kommunikation. Schaut man in die Details zur Beschreibung Resourcen und Tools fällt auf, dass viele Informationen, welche für das MCP gebraucht werden, bereits in bestehenden Standard wie OpenAPI vorhanden sind. Die Beschreibung der Strukturen ist in beiden Fällen JSON basiert. Natürlich unterscheidet sich der Aufbau - hier kommt fastmcp ins Spiel.

Im Folgenden Teil haben wir das Python Paket fastmcp{target="_blank"} erkundet und Teilen unsere Erkenntnisse.

fastmcp - Das Pythonic MCP Paket

fastmcp ist eine Framework zur Implementierung des MCP Protokoll, geschrieben in Python. Version 1 des Paketes wurde in das offizielle Python SDK aufgenommen. Die, zum Zeitpunkt des Blogposts, aktuelle Version 2 konzentriert sich nun hauptsächlich auf gute Handhabbarkeit und einem möglichst kompletten Feature-Set.

Beim durchschauen der Dokumentation fällt direkt auf, dass es eine dedizierte Seite für die Integration von OpenAPI{target="_blank"} gibt. Das initiale Beispiel erscheint denkbar einfach:

import httpx
from fastmcp import FastMCP

# Create an HTTP client for your API
client = httpx.AsyncClient(base_url="https://blueshoe.youtrack.cloud/api/", headers={
    "Authorization": "###############",
    "Accept": "application/json",
})

# Load your OpenAPI spec 
openapi_spec = httpx.get("https://blueshoe.youtrack.cloud/api/openapi.json").json()

# Create the MCP server
mcp = FastMCP.from_openapi(
    openapi_spec=openapi_spec,
    client=client,
    name="blueshoe-youtrack",
)

if __name__ == "__main__":
    mcp.run()

Der Server bekommt eine URL mit dem OpenAPI JSON und eine Client Objekt zur Bedienung der API.

Meine Idee: ich möchte unser Ticket-System YouTrack, welches wir für das Projektmanagement bei Blueshoe einsetzen via LLM bedienbar machen. Los geht's.

Das funktioniert problemlos - nun wie können LLMs mit meinem Server kommunizieren? Die Dokumentation gibt hier 2 Möglichkeiten - Claude Desktop oder Ngrok. Wo liegen die Unterschiede?

MCP Lokal oder Remote?

fastmcp erlaubt es den geschriebenen Server einfach in das lokal installierte Programm Claude Desktop zu installieren. Die Kommunikation läuft dann per Stdio. Alternativ kann der Server an einen Port gebunden werden und die Kommunikation läuft dann per SSE (Server-Sent Events{target="_blank"}). Bei der Alternative kommt Ngrok{target="_blank"} ins Spiel. Ngrok bietet einfache Möglichkeiten lokale Programme ins Internet zu exponieren. Meine ersten Versuche startete ich mit Claude Desktop.

MCP via Claude Desktop

fastmcp kommt mit einem Kommando zum Installieren des MCP Servers in Claude Desktop. Hierbei befolgenden wie hauptsächlich die Dokumentation{target="_blank"} zur Anbindung an Claude Desktop. Also los:

fastmcp install server.py

Beim Start von Claude Desktop erschien dann folgende Meldung:

Erm, okay? Was ist das Problem? Ich starte den Server manuell. Funktioniert. Nach kurzer Untersuchung stelle ich fest: Das Installationskommando von fastmcp ist nicht sonderlich smart:

Leider wird durch das Installationskommando nicht der richtige Python-Interpreter ausgewählt. Dies führt dazu, dass das Skript nicht ausgeführt werden kann.

Hinweis: Ich habe hier ein kleines Stück des Pfades ausgeschnitten.

Okay, dies lässt sich einfach beheben. Im Verzeichnis meines Projektes führe ich folgendes Kommando aus:

which python3

Diesen Interpreter hinterlege ich dann anstelle von uv{target="_blank"} in den Konfigurationsdatei von Claude Desktop. Als Parameter wird dann nur der Pfad zur server.py eingetragen.

Problem gelöst! Claude Desktop startet ohne Probleme. Ich stelle eine Frage - welches Tickets wurden heute bearbeitet?

Ahja. Mist! Es stellt sich heraus, dass so eine, doch recht umfangreiche, OpenAPI Spezifikation direkt mal die "Längenlimits" sprengt. Umfangreich deutet ja erstmal auf eine recht gute Beschreibung hin. Ich halte viel von Jetbrains und ihren Produkten, entsprechend war meine Hoffnung hier, dass der Input des YouTrack OpenAPI sich hervorragend für mein Experiment eignet.

Ich habe noch weitere Modelle getestet, inkl. bezahlter Varianten. Leider laufe ich häufig in Limitierung von Token oder auch Ratelimits. Mein persönlicher Eindruck an dieser Stelle war von Ohnmacht geprägt. Alles easy zusammengesteckt, aber wie kann ich den Problemen auf den Grund gehen? Debugging habe ich dann in meiner Server-Skript via print gemacht, keine besonders nette Erfahrung.

MCP via Client Skript & Ngrok

Okay, Schluss mit den UIs - dann skripten wir unseren Client eben.

import anthropic
from rich import print

# Your server URL (replace with your actual URL)
url = 'https:/#####################.ngrok-free.app'

client = anthropic.Anthropic()

response = client.beta.messages.create(
    model="claude-3-5-haiku-20241022",
    max_tokens=1000,
    messages=[{"role": "user", "content": "What issues have been edited on Blueshoe YouTrack today?"}],
    mcp_servers=[
        {
            "type": "url",
            "url": f"{url}/sse",
            "name": "youtrack",
        }
    ],
    extra_headers={
        "anthropic-beta": "mcp-client-2025-04-04"
    }
)

print(response.content)

Mit ngrok machen wir unseren Server ins Internet verfügbar:

ngrok http 8000  

Das Client Skript bekommt die entsprechende Adresse und unsere Nachricht. Was wurde denn heute so in unserem YouTrack bearbeitet?

Ein paar interessante Ausgaben finden sich im Log:

BetaMCPToolUseBlock(
      id='mcptoolu_01JqQroumE3gHkVnYFZzRc7C',
      input={'query': 'updated: today'},
      name='POST_searchassist',
      server_name='youtrack',
      type='mcp_tool_use'
  )

Ohlala - eine Query updated: today - das sieht doch gut aus, oder?

Leider nicht - die schlussendliche Antwort sieht ungefähr so aus:

I apologize for the persistent errors. It seems there might be an issue with the YouTrack API tools at the moment. Without being able to directly query the system, I can provide some general advice: To find issues edited today in YouTrack, you would typically use a search query like "updated: today" in the YouTrack interface.

Benutz einfach das YouTrack UI! Leider kam das LLM auf keinen grünen Zweig bei der Benutzung der YouTrack API. Nachdem ich anfangs in Authentifizierungsprobleme gelaufen bin, welche ich alle beheben konnte, hatte das LLM eigentlich freie Bahn. Leider war es nicht im Stande eine gescheite API Abfrage zu formulieren. Auch vermeintlich simple Abfragen wie - Wieviele Tickets wurden heute bearbeitet? (wir wollen also "nur" eine Zahl) - haben nicht funktioniert.

Fazit zu MCP mit OpenAPI

Das Model Context Protocol ist eine gute Systematisierung zur Kommunikation von LLMs mit Bestandssystemen. Es bedeutet allerdings nicht, dass die Anbindung von Datenbanken oder Awendungen mit einem Fingerschnipsen erledigt sind. Selbst Schnittstellen mit hervorragenden OpenAPI Schemas können nicht ohne Weiteres integriert werden - es braucht hier entsprechendes Finetuning, sodass ein LLM gute Ergebnisse liefern kann.

Best Practices{target="_blank"} zur Erstellung von MCP Strukturen sind bereits vorhanden. Ein OpenAPI Schema kann die Grundlage für eine Integration bilden - allerdings ersetzt diese nicht die Implementierung.

Das Thema MCP ist nicht Plug'n Play. Es braucht auch hier gutes Engineering und klare Ziele, welche mit einer Integration verfolgt werden. Ich werde das Thema jedoch weiter verfolgen, vermutlich auch in einem weiteren Blogpost.

Eine Frage, welche ich mir als Autor von Software-Projekten stelle - wie testet man diese Integrationen eigentlich zuverlässig? Die Dokumentation von fastmcp erscheint mir im Bereich Testing{target="_blank"} etwas kurz. Wenn ihr da etwas wisst oder kennt, teilt das gerne in den Kommentaren.

{.object-cover .max-w-full .mb-5}

:::globalParagraph Ende 2020 haben wir dir unser neues Open-Source-Projekt Django-Hurricane präsentiert. Den Blogpost zur Vorstellung von Django-Hurricane kannst du hier lesen{.bs-link-blue}. Mit diesem Projekt wollen wir bei Blueshoe die Entwicklung in dem Bereich Django und Kubernetes vorantreiben und viele Routineaufgaben, die beim Aufsetzen des Projektes entstehen, von den Schultern der Entwickler nehmen und in ein robustes Framework verlagern. ::: :::globalParagraph Wir haben außerdem an der To-do-Liste im GitHub Repository gearbeitet und können jetzt hier einige neue Features von Django-Hurricane präsentieren. :::

{.object-cover .max-w-[350px] .mb-5}

:::globalTitle{:size="lg" .mb-5} Dokumentation ::: :::globalParagraph Wir haben intensiv an der Dokumentation gearbeitet. Neben dem User’s Guide, gibt es auch eine Low-Level API Dokumentation. Der User’s Guide gibt hilfreiche Informationen für die Nutzung von Django-Hurricane z. B. die verfügbaren Command-Optionen, nützliche Tipps für die Konfiguration und die allgemeine Aufklärung über die einzelnen Komponenten von Django-Hurricane. In der API-Dokumentation kann man die Funktionalitäten einzelner Komponente besser nachschauen. :::

{.object-cover .mb-5}

:::globalTitle{:size="lg" .mb-5} Management-Commands-Ausführung ::: :::globalParagraph Außerdem haben wir ein Feature implementiert, welches es ermöglicht, die Management-Commands direkt in dem „serve“-Command zu spezifizieren und auszuführen. Die neuen Command-Optionen sind: ::: :::GlobalBlock{.ul-disk .mb-5}

• no-metrics: Das Metriksammeln deaktivieren.
• command: Der wiederholbare Befehl, der die Management-Commands definiert. Die Commands werden vor dem Starten des HTTP-Servers ausgeführt. Da der Befehl wiederholbar ist, kann es mehrmals mit den unterschiedlichen Management-Commands definiert werden, die auch weitere Optionen haben können. In diesem Fall muss man die Optionen zusammen mit dem Namen des Commands in einem String angeben. ::: :::globalParagraph Ein Command mit den Management-Commands könnte wie folgt aussehen: :::

:::BlogCode{.mb-5}

python manage.py serve --command makemigrations --command “compilemessages --locale =de_DE”

:::

:::globalTitle{:size="lg" .mb-5} Probe-Endpoints ::: :::globalParagraph Probe-Endpoints können jetzt separat mit dem „serve“-Command definiert werden. Die Optionen dafür sind: ::: :::GlobalBlock{.ul-disk .mb-5}

• startup-probe: Der Pfad für Startup-Endpoint (default: /startup).
• readiness-probe: Der Pfad für Readiness-Endpoint (default: /ready).
• liveness-probe: Der Pfad für Liveness-Endpoint (default: /alive).
• req-queue-len: Der Schwellenwert für die Request-Warteschlange. Wenn dieser Wert überschritten wird, liefert der Readiness-Probe einen Request mit dem Status-Code 400. :::

:::globalTitle{:size="lg" .mb-5} Webhooks für Probe-Events ::: :::globalParagraph Darüber hinaus haben wir noch ein Feature für Django-Hurricane implementiert: Die Möglichkeit die Webhooks auf eine bestimmte Adresse zu verschicken. Es gibt mittlerweile drei Webhooks, die den drei Probes entsprechen. Der erste Webhook ist der Startup-Webhook. Er wird nach dem Start des HTTP-Servers ausgeführt und an die angegebene Adresse verschickt. Im Falle des Fehlstarts der Applikation wird ein Startup-Webhook mit dem Status „failed“ initiiert. Anschließend wird die Applikation gestoppt. ::: :::globalParagraph Die Liveness- und Readiness-Webhooks sind nach den entsprechenden Probe-Anfragen initiiert. Die Webhooks werden nur nach einer State-Änderung ausgeführt, d. h. entweder bei der ersten Probe-Anfrage, wobei der State von „None“ auf „Healthy/Unhealthy“ geändert wird. Ansonsten wird der Webhook bei der Änderung der States von „Healthy“ zu „Unhealthy“ oder von „Unhealthy“ zu „Healthy“ initiiert. Für die Webhooks mit dem Status „failed“ wird entsprechend auch der Fehler-Traceback mitgeschickt. ::: :::globalParagraph Damit die Webhooks überhaupt geschickt werden können, muss der Webhook-Command mit der URL-Adresse mitgegeben werden. Die Command-Option heißt „webhook-url” und wird als URL-Adresse für Webhooks mitgegeben. Der gesamte Befehl für die Ausführung der Applikation mit Webhooks würde wie folgt aussehen. ::: :::BlogCode{.mb-5}

python manage.py serve --webhook-url „http://<Adresse>“

:::

:::globalTitle{:size="lg" .mb-5} Dabei enthält jedes Webhook einige Daten: ::: :::GlobalBlock{.ul-disk .mb-5}

• Status: „failed“ oder „succeeded“, hängt davon ab, ob der Probe erfolgreich ausgeführt wird oder fehlt.
• Typ: „startup“, „readiness“ oder „liveness“.
• Timestamp: Zeitpunkt, wenn der Webhook initiiert wurde.
• Hostname: die Rechner- bzw. Serverbezeichnung.
• Version: Die Hurricane-Version.
• Error trace: Wenn der Webhook den Status „failed“ hat, schickt der Server auch die Fehlermeldung mit dem Fehlerpfad. :::

{.object-cover .max-w-full .mb-5}

:::globalParagraph Trotz unserer fleißigen Arbeit an der Django-Hurricane-To-do-Liste in den letzten Monaten, gibt es noch mehrere offene Checkboxen. Wir wären daher sehr dankbar für jegliche Hilfe bei der Weiterentwicklung von Django-Hurricane sowie bei allen unseren anderen Open-Source-Projekten. Wir freuen uns schon jetzt auf die neuen Challenges in der Weiterentwicklung und das Abhaken weiterer Checkboxen auf unserer To-do-Liste im GitHub Repository. :::

{.object-cover .max-w-full .mb-5} Anders als beim Sprung von Nuxt 2 zu 3 setzt das Team diesmal auf Evolution statt Revolution – ein Ansatz, der Entwicklern deutlich entgegenkommt.
In diesem Artikel werfen wir einen detaillierten Blick auf die wichtigsten Neuerungen und zeigen, wie Nuxt 4 den Entwickleralltag spürbar verbessert. Von der neuen Verzeichnisstruktur bis hin zu intelligenteren Data Fetching-Features – hier erfährst du alles, was du über die Framework-Evolution wissen musst.

Nuxt 4 – Evolution statt Revolution

Der Erfolg von Nuxt 3

Nuxt 3 hat die Vue-Entwicklung grundlegend verändert. Während frühere Ansätze oft mit komplexen Build-Konfigurationen und mühsamen SSR-Setups zu kämpfen hatten, brachte Nuxt 3 mit dem Nitro-Server, automatischen Imports und nahtloser TypeScript-Integration eine neue Leichtigkeit in die Entwicklung.

Die neue Strategie: Kontinuierliche Verbesserung

Das Nuxt-Team hat aus den Erfahrungen der Vergangenheit gelernt. Statt eines weiteren großen Rewrites setzen sie auf kontinuierliche Verbesserung bestehender Konzepte. Dieser Ansatz reduziert den Migrationsaufwand erheblich und ermöglicht es Entwicklern, schrittweise von den neuen Features zu profitieren.

Praktische Auswirkungen

Das Ergebnis ist ein Framework-Update, das bestehende Nuxt 3-Projekte ohne größere Umbrüche upgraden lässt. Die Verbesserungen sind sofort spürbar, während der Migrationsaufwand überschaubar bleibt – ein willkommener Kontrast zu früheren Major-Updates.

Die Top-Neuerungen in Nuxt 4 im Detail

Neue Projektstruktur: Bessere Organisation durch das app-Verzeichnis

Eine der auffälligsten Neuerungen in Nuxt 4 ist die optionale app/ Verzeichnisstruktur. Diese löst ein bekanntes Problem: In größeren Projekten sammeln sich schnell zahlreiche Ordner im Root-Verzeichnis an, was die Übersichtlichkeit beeinträchtigt.

Die neue Struktur trennt klar zwischen App-spezifischem Code und Konfigurationsdateien. Alle Anwendungsdateien werden unter app/ organisiert, während Konfigurationsdateien im Root-Verzeichnis verbleiben.

Vorteile der neuen Struktur:

• Klarere Trennung zwischen App-Code und Konfiguration
• Bessere Übersichtlichkeit in größeren Projekten
• Konsistenz mit anderen modernen Frameworks wie Next.js
• Verbesserte IDE-Unterstützung durch klarere Verzeichnisstruktur

Vergleich der Strukturen:

# Alte Struktur (Nuxt 3)
/
├── components/
├── pages/
├── composables/
├── layouts/
├── middleware/
├── plugins/
├── assets/
├── public/
├── server/
├── nuxt.config.ts
└── package.json

# Neue Struktur (Nuxt 4)
/
├── app/
│   ├── components/
│   ├── pages/
│   ├── composables/
│   ├── layouts/
│   ├── middleware/
│   ├── plugins/
│   ├── assets/
│   ├── utils/
│   ├── app.vue
│   └── app.config.ts
├── content/
├── layers/
├── modules/
├── public/
├── server/
├── shared/
├── nuxt.config.ts
└── package.json

Die neue Struktur macht es deutlich einfacher, zwischen App-spezifischem Code und Konfigurationsdateien zu unterscheiden. Besonders in größeren Teams und Enterprise-Projekten führt dies zu einer erheblich besseren Code-Organisation und reduziert die Zeit, die für die Suche nach spezifischen Dateien benötigt wird.

Singleton Data Fetching Layer: Revolutionäres Caching-System

Das Data Fetching in Nuxt 4 wurde grundlegend überarbeitet und führt das "Singleton Data Fetching Layer" ein. Diese Neuerung bringt erhebliche Verbesserungen in Performance und Konsistenz mit sich.

Was sich geändert hat:

1. Geteilte Refs für denselben Key: Alle Aufrufe von useAsyncData oder useFetch mit demselben Key teilen sich jetzt dieselben data, error und status Refs. Das bedeutet, dass alle Aufrufe mit einem expliziten Key keine widersprüchlichen deep, transform, pick, getCachedData oder default Optionen haben dürfen.

2. Erweiterte getCachedData Kontrolle: Die getCachedData Funktion wird jetzt bei jedem Datenabruf aufgerufen, auch wenn dies durch einen Watcher oder refreshNuxtData verursacht wird. Die Funktion erhält ein Kontext-Objekt mit der Ursache der Anfrage, was mehr Kontrolle über die Verwendung von gecachten Daten ermöglicht.

3. Reaktive Key-Unterstützung: Du kannst jetzt computed refs, plain refs oder Getter-Funktionen als Keys verwenden. Dies ermöglicht automatisches Data Refetching und speichert Daten separat.

4. Automatische Datenbereinigung: Wenn die letzte Komponente, die Daten mit useAsyncData abruft, unmounted wird, bereinigt Nuxt automatisch die entsprechenden Daten aus dem Cache.

Praktisches Beispiel: E-Commerce Produktseite

Stell dir vor, du baust eine E-Commerce-Seite mit Produktdetails und verwandten Produkten:

// Produktseite - lädt Produktdaten
const { data: product } = await useFetch(`/api/products/${productId}`, {
  key: `product-${productId}`
})

// Verwandte Produkte Komponente - teilt dieselben Daten
const { data: relatedProducts } = await useFetch(`/api/products/${productId}/related`, {
  key: `related-${productId}`
})

// Warenkorb Komponente - lädt Produktdaten erneut
const { data: cartProduct } = await useFetch(`/api/products/${productId}`, {
  key: `product-${productId}` // Gleicher Key = gleiche Daten!
})
// → Kein zusätzlicher API-Call, nutzt gecachte Daten

Was passiert hier:

• Ein API-Call für Produktdaten, aber drei Komponenten nutzen die Daten
• Automatisches Caching verhindert doppelte Anfragen
• Geteilte Refs sorgen dafür, dass alle Komponenten synchron bleiben

Reales Szenario: Blog mit Kommentaren

// Blog-Post Seite
const { data: post } = await useFetch(`/api/posts/${postId}`, {
  key: `post-${postId}`
})

// Kommentare Komponente (gleiche Seite)
const { data: comments } = await useFetch(`/api/posts/${postId}/comments`, {
  key: `comments-${postId}`
})

// User wechselt zu anderer Seite → Komponenten werden unmounted
// → Cache wird automatisch bereinigt (keine Memory Leaks!)

// User kehrt zurück → Daten werden neu geladen
// → Frische Daten, optimaler Speicherverbrauch

Vorteile in der Praxis:

• Weniger API-Calls = schnellere Ladezeiten
• Synchronisierte Daten = keine Inkonsistenzen zwischen Komponenten
• Automatisches Cleanup = keine Memory Leaks bei Navigation
• Intelligentes Caching = bessere User Experience

Pro-Tipp: Composable für wiederverwendbare Data Fetching Logic

Da alle Komponenten mit demselben Key automatisch die gleichen Daten teilen, macht es Sinn, die useAsyncData/useFetch Aufrufe in eigene Composables auszulagern:

// composables/useProduct.js
export function useProduct(productId: string) {
  return useAsyncData(
    `product-${productId}`,
    () => $fetch(`/api/products/${productId}`),
    { 
      deep: true,
      transform: (product) => ({ 
        ...product, 
        formattedPrice: `€${product.price.toFixed(2)}`,
        lastViewed: new Date()
      })
    }
  )
}

// In verschiedenen Komponenten
const { data: product } = await useProduct(productId)
// → Alle nutzen dieselben Daten und Transformations-Logic

Vorteile:

• Konsistente Keys über alle Komponenten hinweg
• Zentrale Transformations-Logic (Preis-Formatierung, etc.)
• Einfache Wartung und Updates
• TypeScript-Support durch zentrale Typen

Wichtige Hinweise:

• Konsistente Optionen: Alle Aufrufe mit demselben Key müssen identische deep, transform, pick, getCachedData oder default Optionen haben
• Reaktive Keys: Computed refs, plain refs oder Getter-Funktionen als Keys ermöglichen automatisches Refetching
• Memory Management: Automatische Bereinigung verhindert Memory Leaks bei großen Anwendungen

Konfiguration: Cache-Verhalten anpassen

Falls du das neue Cache-Verhalten deaktivieren möchtest, kannst du das in der nuxt.config.ts konfigurieren:

export default defineNuxtConfig({
  experimental: {
    granularCachedData: false,  // Deaktiviert das granulare Caching
    purgeCachedData: false      // Deaktiviert die automatische Bereinigung
  }
})

Wann das sinnvoll ist:

• Legacy-Projekte mit komplexen Caching-Anforderungen
• Schrittweise Migration von bestehenden Caching-Strategien
• Debugging von Cache-Problemen während der Entwicklung

Diese Verbesserungen sorgen dafür, dass unnötige API-Calls vermieden werden und die Anwendung deutlich performanter wird. Besonders bei komplexen Anwendungen mit vielen Datenquellen macht sich der Unterschied in der Praxis erheblich bemerkbar.

Developer Experience: Verbesserte Produktivität und Effizienz

Die Developer Experience wurde in Nuxt 4 erheblich verbessert, was sich direkt auf die Produktivität von Entwicklern auswirkt. Die Optimierungen konzentrieren sich auf schnellere Workflows und bessere Entwicklungstools.

Performance-Verbesserungen:

• Deutlich schnellere Startzeiten des Entwicklungsservers
• Verbesserte HMR-Zuverlässigkeit (Hot Module Replacement)
• Optimierte TypeScript-Integration für bessere Typsicherheit und Autovervollständigung
• Intelligente Build-Optimierungen für schnellere Compile-Zeiten

Praktische Verbesserungen:

• Nahtlose Integration mit modernen IDEs
• Bessere Fehlermeldungen und Debugging-Informationen
• Optimierte Bundle-Größe durch intelligente Tree-Shaking
• Verbesserte Source Maps für effizienteres Debugging

Diese Verbesserungen sorgen dafür, dass Entwickler weniger Zeit mit Warten und Debugging verbringen und sich mehr auf die eigentliche Entwicklung konzentrieren können.

Der Upgrade-Prozess: So gelingt der Umstieg von Nuxt 3 auf 4

Der Umstieg von Nuxt 3 auf Nuxt 4 wurde bewusst unkompliziert gestaltet. Das Nuxt-Team hat großen Wert darauf gelegt, dass bestehende Projekte ohne größere Änderungen migriert werden können. Nach dem Upgrade sind die meisten Nuxt 4 Verhaltensweisen bereits Standard, aber einige Features können noch konfiguriert werden, um Rückwärtskompatibilität während der Migration zu gewährleisten.

Schritt 1: Nuxt auf Version 4 aktualisieren

Der erste Schritt ist die Aktualisierung des Nuxt-Pakets auf Version 4:

# Mit npm
npm install nuxt@^4.0.0

# Mit yarn
yarn add nuxt@^4.0.0

# Mit pnpm
pnpm add nuxt@^4.0.0

# Mit bun
bun add nuxt@^4.0.0

Was passiert hier?

• Das nuxt Paket wird auf Version 4 aktualisiert
• Alle Nuxt 4 Verhaltensweisen werden aktiviert
• Die meisten bestehenden Konfigurationen bleiben funktional

Schritt 2: Migration durchführen

Du hast zwei Optionen für die Migration:

Option A: Automatische Migration mit Codemods (empfohlen)

Das Nuxt-Team hat mit dem Codemod-Team zusammengearbeitet, um viele Migrationsschritte zu automatisieren:

# Alle Migration-Codemods ausführen

# Mit npm
npx codemod@latest nuxt/4/migration-recipe

# Mit yarn
yarn dlx codemod@latest nuxt/4/migration-recipe

# Mit pnpm
pnpm dlx codemod@latest nuxt/4/migration-recipe

# Mit bun
bun x codemod@latest nuxt/4/migration-recipe

Was machen die Codemods?

• Automatische Anpassung der Verzeichnisstruktur
• Migration veralteter Konfigurationsoptionen
• Anpassung von TypeScript-Konfigurationen
• Update von Import-Pfaden und Aliases

Option B: Manuelle Migration

Falls du die Migration manuell durchführen möchtest oder die Codemods nicht alle Aspekte abdecken:

2.1 Neue Verzeichnisstruktur erstellen

Die neue Verzeichnisstruktur bietet bessere Performance und IDE-Unterstützung:

# Neues app/ Verzeichnis erstellen
mkdir app

# Bestehende Verzeichnisse in app/ verschieben
mv assets app/
mv components app/
mv composables app/
mv layouts app/
mv middleware app/
mv pages app/
mv plugins app/
mv utils app/

# App-spezifische Dateien verschieben
mv app.vue app/
mv error.vue app/
mv app.config.ts app/

2.2 Root-Verzeichnis bereinigen

Stelle sicher, dass diese Verzeichnisse im Root bleiben:

• nuxt.config.ts
• content/
• layers/
• modules/
• public/
• server/

2.3 TypeScript-Konfiguration anpassen

Nuxt 4 verwendet neue TypeScript-Projekt-Referenzen für bessere Typsicherheit:

// tsconfig.json
{
  "files": [],
  "references": [
    { "path": "./.nuxt/tsconfig.app.json" },
    { "path": "./.nuxt/tsconfig.server.json" },
    { "path": "./.nuxt/tsconfig.shared.json" },
    { "path": "./.nuxt/tsconfig.node.json" }
  ]
}

// package.json - Type-Checking Scripts aktualisieren
{
  "scripts": {
    "typecheck": "nuxt prepare && vue-tsc -b --noEmit"
  }
}

Type-Augmentierungen verschieben:

• App-Kontext: Verschiebe Dateien nach app/
• Server-Kontext: Verschiebe Dateien nach server/
• Geteilt: Verschiebe Dateien nach shared/

2.4 Konfiguration anpassen

Veraltete generate-Konfiguration migrieren:

// Alte Konfiguration (Nuxt 3)
export default defineNuxtConfig({
  generate: {
    exclude: ['/admin', '/private'],
    routes: ['/sitemap.xml', '/robots.txt']
  }
})

// Neue Konfiguration (Nuxt 4)
export default defineNuxtConfig({
  nitro: {
    prerender: {
      ignore: ['/admin', '/private'],
      routes: ['/sitemap.xml', '/robots.txt']
    }
  }
})

Experimentelle Features entfernen:

Diese Features sind in Nuxt 4 nicht mehr konfigurierbar:

• experimental.treeshakeClientOnly (immer true)
• experimental.configSchema (immer true)
• experimental.polyfillVueUseHead (immer false)
• experimental.respectNoSSRHeader (immer false)

Schritt 3: Testing und Validierung

# Entwicklungsserver starten
npm run dev

# Type-Checking ausführen
npm run typecheck

# Build testen
npm run build

# Alle Tests ausführen
npm run test

Was zu testen ist:

• Alle Seiten laden korrekt
• Data Fetching funktioniert
• TypeScript-Fehler sind behoben
• Performance-Verbesserungen sind sichtbar
• Alle Module und Plugins funktionieren

Schritt 4: Rückwärtskompatibilität (falls nötig)

Falls du die alte Verzeichnisstruktur beibehalten möchtest:

// nuxt.config.ts
export default defineNuxtConfig({
  // V3-Struktur beibehalten
  srcDir: '.',
  dir: {
    app: 'app'
  }
})

Wichtige Breaking Changes

Nuxt 4 bringt einige signifikante Änderungen mit sich, die bei der Migration beachtet werden müssen:

1. Neue Verzeichnisstruktur:

• Standard srcDir ist jetzt app/ statt Root-Verzeichnis
• serverDir ist jetzt <rootDir>/server statt <srcDir>/server
• layers/, modules/ und public/ werden relativ zu <rootDir> aufgelöst

2. Singleton Data Fetching Layer:

• Geteilte Refs für denselben Key in useAsyncData und useFetch
• Erweiterte getCachedData Kontrolle mit Kontext-Objekt
• Reaktive Key-Unterstützung für automatisches Refetching
• Automatische Datenbereinigung beim Unmounten

3. TypeScript-Konfiguration:

• Neue Projekt-Referenzen für bessere Typsicherheit
• Getrennte Konfigurationen für App, Server und Build-Zeit
• Type-Augmentierungen müssen in entsprechende Verzeichnisse (app/, server/, shared/)

Migration Guide: Für detaillierte Informationen empfehlen wir den offiziellen Nuxt 4 Upgrade Guide zu konsultieren.

Was bedeutet Nuxt 4 für die Zukunft? Ein Blick nach vorn

Die Roadmap: Was kommt nach Nuxt 4?

Das Nuxt-Team arbeitet bereits an Nuxt 5 und Nitro v3, die weitere revolutionäre Features bringen werden. Nuxt 4 bildet dabei das solide Fundament für diese zukünftigen Entwicklungen.

Geplante Features für die Zukunft:

• Erweiterte Server-Side Rendering Optimierungen
• Verbesserte Edge-Computing Unterstützung
• Erweiterte TypeScript-Integration
• Neue Performance-Metriken und Monitoring-Tools

Die Bedeutung für das Ökosystem

Module-Entwickler: Können ihre Module schrittweise an die neuen Features anpassen und von der verbesserten API profitieren.

Community: Profitieren von der verbesserten Developer Experience und den neuen Möglichkeiten für Performance-Optimierungen.

Enterprise: Haben eine stabile Basis für langfristige Projekte mit vorhersagbaren Upgrade-Pfaden.

Einordnung: Wie Nuxt seine Position als führendes Vue-Framework weiter ausbaut

Nuxt 4 festigt die Position als eines der modernsten und entwicklerfreundlichsten Vue-Frameworks und setzt neue Standards in der Web-Entwicklung. Die Fokussierung auf Stabilität und kontinuierliche Verbesserung macht es zur idealen Wahl für professionelle Projekte.

Wettbewerbsvorteile:

• Überlegene Developer Experience im Vergleich zu anderen Vue-Frameworks
• Bessere Performance durch intelligente Optimierungen
• Starke Community und umfangreiches Ökosystem
• Enterprise-ready mit langfristiger Unterstützung

Fazit: Warum sich das Upgrade auf Nuxt 4 jetzt lohnt

Zusammenfassung der wichtigsten Vorteile:

Performance: Deutlich schnellere Startzeiten und bessere HMR-Zuverlässigkeit sorgen für eine flüssigere Entwicklung.

Code-Qualität: Bessere Projektstruktur durch die neue src-Verzeichnisorganisation und optimierte TypeScript-Integration.

Produktivität: Intelligenteres Data Fetching und verbesserte Developer Experience führen zu weniger Wartezeiten und effizienterer Entwicklung.

Zukunftssicherheit: Stabile Basis für langfristige Projekte mit vorhersagbaren Upgrade-Pfaden.

Klare Handlungsempfehlung

Das Upgrade auf Nuxt 4 ist für alle Entwickler und Teams empfehlenswert, die bereits mit Nuxt 3 arbeiten. Die Verbesserungen sind sofort spürbar, während der Migrationsaufwand minimal bleibt.

Für Teams: Die verbesserte Developer Experience und Performance-Optimierungen rechtfertigen das Upgrade bereits nach kurzer Zeit.

Für Enterprise: Die Fokussierung auf Stabilität und langfristige Unterstützung macht Nuxt 4 zur idealen Wahl für professionelle Projekte.

Jetzt die offizielle Nuxt 4 Dokumentation ansehen und dein erstes Projekt mit Nuxt 4 starten!

Hast du bereits Erfahrungen mit Nuxt 4 gemacht? Teile deine Erkenntnisse in den Kommentaren und lass uns wissen, welche Features dich am meisten begeistern!

FAQ – Häufige Fragen zu Nuxt 4

1. Was sind die wichtigsten Neuerungen in Nuxt 4?

Die wichtigsten Neuerungen in Nuxt 4 sind die optionale src-Verzeichnisstruktur für bessere Projektorganisation, intelligenteres Data Fetching mit automatischem Caching und De-Duplizierung, sowie verbesserte Developer Experience mit schnellerem CLI und optimierter TypeScript-Integration. Der Fokus liegt auf Stabilität und einem reibungslosen Upgrade-Pfad von Nuxt 3.

2. Wie unterscheidet sich Nuxt 4 von Nuxt 3?

Nuxt 4 baut auf Nuxt 3 auf und setzt auf Evolution statt Revolution. Während Nuxt 3 einen kompletten Rewrite war, konzentriert sich Nuxt 4 auf die Verfeinerung bestehender Konzepte. Die neue src-Verzeichnisstruktur bietet bessere Organisation, das Data Fetching wurde intelligenter und die Developer Experience wurde durch schnellere Startzeiten und bessere HMR-Zuverlässigkeit verbessert.

3. Ist das Upgrade von Nuxt 3 auf Nuxt 4 kompliziert?

Nein, das Upgrade von Nuxt 3 auf Nuxt 4 wurde bewusst unkompliziert gestaltet. Das Nuxt-Team hat großen Wert darauf gelegt, dass bestehende Projekte ohne größere Änderungen migriert werden können. Die Breaking Changes sind minimal und die meisten bestehenden Projekte sollten ohne größere Anpassungen funktionieren.

4. Welche Vorteile bietet die neue src-Verzeichnisstruktur in Nuxt 4?

Die neue optionale src-Verzeichnisstruktur bietet eine klarere Trennung zwischen Konfigurationsdateien und dem eigentlichen App-Code. Dies führt zu besserer Übersicht in großen Projekten, konsistenter Struktur mit anderen modernen Frameworks und einer saubereren Projektorganisation. Alle App-spezifischen Dateien werden unter src/ organisiert, während Konfigurationsdateien im Root-Verzeichnis bleiben.

5. Wie verbessert Nuxt 4 das Data Fetching?

Nuxt 4 bringt intelligenteres Data Fetching mit automatischem Caching und De-Duplizierung von Anfragen mit demselben Key. Zusätzlich erfolgt eine automatische Bereinigung beim Unmounten von Komponenten, was Memory Leaks verhindert. Die verbesserte Fehlerbehandlung und Retry-Mechanismen sorgen für robustere Anwendungen.

6. Welche Performance-Verbesserungen bietet Nuxt 4?

Nuxt 4 bietet deutlich schnellere Startzeiten des Entwicklungsservers, verbesserte HMR-Zuverlässigkeit und optimierte TypeScript-Integration. Zusätzlich sorgen intelligente Build-Optimierungen für schnellere Compile-Zeiten und bessere Bundle-Größen durch verbessertes Tree-Shaking.

7. Kann ich Nuxt 4 Features bereits in Nuxt 3 testen?

Ja, du kannst Features aus Nuxt 4 bereits in Nuxt 3 testen, indem du die neuesten Beta-Versionen verwendest. Dies ermöglicht eine schrittweise Migration und frühzeitige Erkennung von Kompatibilitätsproblemen. Der offizielle Migration Guide bietet detaillierte Anweisungen für den Übergang.

8. Welche Breaking Changes gibt es in Nuxt 4?

Da Nuxt 4 auf Stabilität setzt, sind die Breaking Changes minimal. Die meisten bestehenden Projekte sollten ohne größere Anpassungen funktionieren. Wichtige Änderungen betreffen hauptsächlich die optionale src-Struktur und einige veraltete API-Funktionen, die durch modernere Alternativen ersetzt wurden.

{.object-cover .max-w-full .mb-5}

::GlobalTitle{:size="lg" .mb-4} Einleitung ::

::GlobalParagraph Nuxt ist ein vielseitiges Framework, das Entwicklern hilft, moderne Webanwendungen effizient zu erstellen. Ein entscheidender Aspekt bei der Entwicklung mit Nuxt ist die Wahl der richtigen Rendering-Methode. Die zwei Hauptoptionen sind: ::

::GlobalBlock{.ul-disk .mb-4}

• Statische Generierung (Nuxt Generate)
• Server-Rendering (Nuxt Server) ::

::GlobalParagraph Doch wann solltest du Nuxt Generate oder Nuxt Server verwenden? Dieser Artikel gibt dir eine klare Übersicht über die Nuxt Render-Strategien im Vergleich, zeigt ihre Vor- und Nachteile auf und stellt hybride Ansätze vor. ::

:::GlobalButton{:url="/technologien/vuejs-nuxt/" :label="Erfahre mehr über unsere Nuxt-Entwicklungsdienste" :color="blue" .mb-6} :::

::GlobalTitle{:size="lg" .mb-5} Statische Generierung (Nuxt Generate) ::

::GlobalParagraph Die statische Generierung ist ein Ansatz, bei dem während des Build-Prozesses HTML-Dateien erstellt werden, die dann direkt von einem Webserver oder CDN ausgeliefert werden. Das führt zu: ::

::GlobalBlock{.ul-disk .mb-4}

• Extrem schnellen Ladezeiten
• Weniger Abhängigkeit von Backend-Systemen ::

::GlobalParagraph Alle Seiten der Website werden während des Build-Prozesses generiert und als statische HTML-Dateien bereitgestellt. ::

::GlobalParagraph Ein häufiges Beispiel ist eine Blog-Website. Hier können alle Artikel während des Builds generiert werden. Zusätzlich kann ein Crawler genutzt werden, um alle internen Links automatisch zu erfassen und sicherzustellen, dass alle Inhalte basierend auf dem Index generiert werden: ::

::BlogCode

// nuxt.config.ts

export default defineNuxtConfig({
  nitro: {
    prerender: {
      crawlLinks: true,
      routes: ['/'],
    },
  }
})

::

::GlobalParagraph Mit dieser Konfiguration werden alle angegebenen Routen während des Build-Prozesses generiert und als statische HTML-Dateien bereitgestellt. Ein integrierter Crawler sorgt dafür, dass auch alle internen Links automatisch erfasst und generiert werden. Das entlastet den Webserver erheblich und ermöglicht blitzschnelle Ladezeiten. Die routes-Option in der Datei nuxt.config.ts gibt dabei genau an, welche Pfade während des Builds erstellt werden sollen. ::

::GlobalParagraph Um den statischen Generierungsmodus zu nutzen, führe folgendes npm-Kommando aus: ::

::BlogCode

npm run generate

::

::GlobalParagraph Nach dem Ausführen des Befehls npm run generate werden die statischen HTML-Dateien im Verzeichnis dist gespeichert. Um die Seite online zugänglich zu machen, musst du diese Dateien auf einen Webserver oder ein CDN hochladen. ::

::GlobalParagraph Zusammenfassung:

:::GlobalBlock{.ul-disk .my-4}

• Performance: Extrem schnelle Ladezeiten durch vorab generierte HTML-Dateien.
• Kosten: Reduziert die Abhängigkeit von serverseitigen Prozessen und verringert Hosting-Kosten.
• SEO-Optimierung: Bessere Indexierung durch vorgerenderte Inhalte.
• Einschränkungen: Keine Echtzeit-Inhalte, lange Build-Zeiten bei umfangreichen Websites. ::: ::

::GlobalParagraph Wie du Nuxt effizient nutzt, erfährst du in unserem Blog zur Webentwicklung mit Vue.js & Nuxt{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} . ::

::GlobalParagraph Weitere Informationen zur Konfiguration findest du in der offiziellen Nuxt-Dokumentation{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid}. ::

::GlobalTitle{:size="lg" .mb-5} Server-Rendering (Nuxt Server) ::

::GlobalParagraph Beim Server-Rendering wird die HTML-Ausgabe dynamisch auf einem Server generiert, sobald eine Anfrage gestellt wird. Dieser Ansatz eignet sich besonders für Anwendungen wie Dashboards, die personalisierte Inhalte oder häufig aktualisierte Daten bereitstellen: ::

::BlogCode

<!-- pages/dashboard.vue -->

<script setup lang="ts">
interface User {
  name: string
  lastLogin: string
}

const user = ref<User | null>(null)

const { data } = await useFetch<User>('/api/user')
user.value = data.value
</script>

<template>
  <div v-if="user">
    <h1>Willkommen, {{ user.name }}</h1>
    <p>Letzte Anmeldung: {{ user.lastLogin }}</p>
  </div>
</template>

::

::GlobalParagraph In diesem Beispiel wird die useFetch-Methode genutzt, um während des Server-Renderings stets aktuelle Nutzerdaten zu laden und an die Komponente zu übergeben. Dies stellt sicher, dass die Inhalte immer aktuell sind. Dank der Auto-Import-Funktionalität von Nuxt müssen Systemfunktionen wie ref und useFetch nicht separat importiert werden. ::

::GlobalParagraph Um den Server-Rendering-Modus zu nutzen, kannst du das folgende npm-Kommando ausführen: ::

::BlogCode

npm run build
npm run start

::

::GlobalParagraph Zusammenfassung:

:::GlobalBlock{.ul-disk .my-4}

• Flexibilität: Inhalte können in Echtzeit angepasst werden
• SEO-Vorteile: Immer aktuelle Inhalte für Suchmaschinen.
• Herausforderungen: Höherer Bedarf an Serverressourcen und komplexere Infrastruktur ::: ::

::GlobalParagraph Weitere Details findest du in der offiziellen Nuxt-Dokumentation zum Server-Rendering{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid}. ::

::GlobalTitle{:size="lg" .mb-5} Hybride Ansätze mit Nuxt ::

::GlobalParagraph Ein Hybridansatz kombiniert die Vorteile von statischer Generierung und Server-Rendering. Dabei kannst du ausgewählte Seiten statisch generieren, während andere dynamisch gerendert werden. Dies eignet sich besonders für Anwendungen mit gemischten Anforderungen, wie eine E-Commerce-Website mit statisch generierten Produktseiten und einer dynamischen Warenkorb-Funktion. ::

::BlogCode

<!-- pages/products/_id.vue -->

<script setup lang="ts">
interface Product {
  id: number
  name: string
  description: string
}

const route = useRoute()
const product = ref<Product | null>(null)

const { data } = await useFetch<Product>(`/api/products/${route.params.id}`)
product.value = data.value

function addToCart(productId: number) {
  // Dynamische Funktion zum Hinzufügen des Produkts in den Warenkorb
  // ...
}
</script>

<template>
  <div v-if="product">
    <h1>{{ product.name }}</h1>
    <p>{{ product.description }}</p>
    <button @click="addToCart(product.id)">
      In den Warenkorb
    </button>
  </div>
</template>

::

::GlobalParagraph In diesem Beispiel werden die Produktinformationen bereits beim Build-Prozess als statische HTML-Dateien generiert. Die Warenkorb-Funktion hingegen wird dynamisch gerendert, um Nutzern eine Interaktion in Echtzeit zu ermöglichen. ::

::GlobalCallAnExpert{:bg="bg-bs-blue"} #buttonBlockTitle Wir können auch Deine Apps mit Nuxt realisieren. ::

::GlobalParagraph Um eine Nuxt-Anwendung im Hybridmodus zu starten, kannst du die routeRules-Option in der Datei nuxt.config.ts verwenden. Hier ist ein Beispiel für einen Online-Shop: ::

::BlogCode

// nuxt.config.ts

export default defineNuxtConfig({
  routeRules: {
    '/': { prerender: true },
    '/products/**': { swr: 3600 },
    '/admin/**': { ssr: false },
    '/api/**': { cors: true },
    '/old-page': { redirect: '/new-page' }
  }
})

::

::GlobalParagraph Weitere Informationen zu den routeRules findest du in der offiziellen Nuxt-Dokumentation{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid}. ::

::GlobalParagraph Mit dieser Konfiguration werden die Produktseiten sowie die Startseite statisch generiert, während der Warenkorb und die Benutzerprofile dynamisch generiert werden. Beachte, dass Hybrid-Rendering nicht verfügbar ist, wenn nuxt generate verwendet wird. Um die Anwendung im Hybridmodus zu starten, führe die folgenden npm-Befehle aus: ::

::BlogCode

npm run build
npm run start

::

::GlobalParagraph Der Befehl npm run build erstellt die statischen HTML-Dateien und das Server-Bundle, und npm run start startet den Server, der sowohl die statischen Dateien als auch die dynamischen Inhalte ausliefert. Dies ermöglicht es dir, die Anwendung so zu testen, wie sie in der Produktion laufen würde. ::

::div{.mb-8 .mt-8 .relative } :::GlobalSliderSection{:numberCards=2 data-title="Successful projects" :bg="bg-bs-gray"} :::GlobalTitle{.mb-6 :size="lg" :tag="h3"} Beispielprojekte, die mit Nuxt und dem Hybridansatz realisiert wurden :::

:::GlobalParagraph Auch in komplexen Projekten können wir mit Nuxt dafür sorgen, dass die Seiten-Geschwindigkeit über dem Industrie-Standard liegt. :::

#card1 :GlobalPartial{content=slides/luma-3-blog}

#card2 :GlobalPartial{content=slides/wuc-1-blog}

::: ::

::GlobalParagraph Zusammenfassung:

:::GlobalBlock{.ul-disk .my-4}

• Kombination: Nutzt die Vorteile von statischer Generierung für schnelle Auslieferung und dynamisches Rendering für Echtzeit-Inhalte.
• Flexibilität: Perfekt für Anwendungen mit gemischten Anforderungen, z. B. E-Commerce oder Blogs mit dynamischen Kommentaren.
• Komplexität: Erfordert sorgfältige Planung und die richtige Konfiguration von Routen. ::: ::

::GlobalParagraph Wenn du mehr über Headless E-Commerce-Lösungen erfahren möchtest, besuche unsere Seite zu Headless E-Commerce{.bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid}. ::

::GlobalTitle{:size="lg" .mb-5} Fazit: Optimale Nutzung von Nuxt in der Produktion ::

::GlobalParagraph Die Wahl zwischen Nuxt Generate und Nuxt Server hängt von den Anforderungen deiner Anwendung ab: ::

::GlobalBlock{.ul-disk .my-4}

• Statische Generierung ist ideal für Websites mit gleichbleibendem Inhalt wie Blogs oder Marketingseiten.
• Server-Rendering bietet Flexibilität für dynamische oder personalisierte Inhalte.
• Hybride Ansätze vereinen Performance und Echtzeit-Interaktivität für komplexere Projekte. ::

::GlobalParagraph Hast du Fragen oder möchtest du Unterstützung bei der Umsetzung? Kontaktiere uns{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} – wir helfen dir, deine Nuxt-Projekte erfolgreich umzusetzen! ::

::GlobalParagraph{.mb-4} Weitere Informationen zu den Rendering-Konzepten findest du in der offiziellen Nuxt-Dokumentation{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid}. ::

:::GlobalTitle{:size="lg" .mb-5 .mt-8} Häufige Fragen :::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 1. Was ist der Unterschied zwischen Nuxt Generate und Nuxt Server? ::

::GlobalParagraph Nuxt Generate erstellt während des Build-Prozesses statische HTML-Dateien, die von einem Server oder CDN ausgeliefert werden. Nuxt Server hingegen rendert die Seiten dynamisch, wenn ein Nutzer sie anfragt. Beide Methoden haben unterschiedliche Anwendungsfälle und Vorteile. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 2. Wann sollte ich Nuxt Generate oder Nuxt Server verwenden? ::

::GlobalParagraph Nutze Nuxt Generate für Websites mit gleichbleibendem Inhalt wie Blogs oder Marketingseiten. Nuxt Server ist besser geeignet für Anwendungen mit personalisierten oder häufig aktualisierten Inhalten, wie Dashboards oder E-Commerce-Seiten. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 3. Welche Vorteile bietet statische Generierung für SEO und Performance? ::

::GlobalParagraph Mit Nuxt Generate sind die Ladezeiten extrem schnell, da HTML-Dateien vorgerendert werden. Das verbessert die SEO durch eine einfache Indexierung und reduziert Hosting-Kosten. Allerdings sind keine Echtzeit-Inhalte möglich, was je nach Anwendungsfall eine Einschränkung darstellen kann. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 4. Kann ich statische und dynamische Inhalte in Nuxt kombinieren? ::

::GlobalParagraph Ja, hybride Ansätze sind möglich. Du kannst zum Beispiel Blogartikel statisch generieren und dynamische Elemente wie Kommentare client-seitig rendern lassen. Dies vereint schnelle Performance mit Flexibilität und passt sich perfekt an unterschiedliche Anforderungen an. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 5. Wie richte ich den richtigen Nuxt Production Mode ein? ::

::GlobalParagraph{.mb-4} Für eine optimale Produktion nutzt du statische Generierung, wenn der Inhalt konstant ist, oder setzt auf Server-Rendering für dynamische Inhalte. Mit hybriden Ansätzen kannst du beides kombinieren. Eine saubere Konfiguration in der nuxt.config.ts ist entscheidend, um die bestmögliche Performance und Skalierbarkeit zu erreichen. ::

{.object-cover .max-w-full .mb-5}

::GlobalBlogLevelInfo

• Keycloak{target="_blank"} und OAuth2{target="_blank"}
• Nuxt Rendering Modes{target="_blank"}

Solltest du Fragen haben, oder dir etwas unklar sein, kannst du die Kommentarfunktion unter dem Artikel nutzen. ::

SSR, Hybrid, Generate - Authentifizierung je Modus

Als erstes ist es wichtig zu identifizieren, in welchem Modus die Nuxt Applikation betrieben wird. Hieraus ergeben sich unterschiedliche Anforderungen an die Authentifizierung. Einen Blogartikel zu den unterschiedlichen Modi gibt's hier{.bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid}.

Server-Side Rendering - Werden während des Server-Side Renderings Nutzer-Informationen verarbeitet wie Berechtigungen, Namen o.ä. - so benötigt der Nitro Server Zugriff auf diese. Entsprechend muss der Nitro/Nuxt Server validieren können ob eine Session authentifiziert bzw. autorisiert ist.

Client-Side Rendering - Es existiert keine Server-Logik. Alles wird auf der Client-Seite (dem Browser) verarbeitet - entsprechend läuft auch das Handling der Nutzer-Informationen/Session lediglich client-seitig.

Hybrid-Rendering - Je nach dem, ob die SSR Routen Nutzer-Session-Informationen benötigen oder nicht, muss die Keycloak Integration mitgedacht werden.

Option 1: Integration mit nuxt-auth-utils - New and improved

Die Integration von Keycloak und Nuxt durch nuxt-auth-utils{target="_blank"} könnte kaum einfacher sein. Ein wenig Konfiguration in der nuxt.config.js und schon steht das Grundgerüst:

runtimeConfig: {
    oauth: {
      keycloak: {
        serverUrl: 'https://keycloak.blueshoe.de',
        realm: 'Blueshoe',
        clientId: 'blueshoe-website',
        // clientSecret: '',
        redirectURL: 'https://blueshoe.de/auth/keycloak',
      },
    },
  },
  modules: [
    'nuxt-auth-utils',
  ]

Nun stehen komfortable Composables{target="_blank"} zur Verfügung:

const { loggedIn, user, session, fetch, clear, openInPopup } = useUserSession()

Mit den Informationen lassen sich schnell und einfach nutzerspezifische Informationen rendern:

<template>
  <span v-if="loggedIn">Hallo, {{ user.firstName }} {{ user.lastName }}</span>
  <span v-else>Hallo Gast</span>
</template>

Ebenso stehen auf SSR Seite nützliche Utils zur Verfügung{target="_blank"}. Benötigt eine Route zwingend eine gültige User-Session lässt sich dies einfach mit dem folgenden Composable realisieren:

const session = await requireUserSession(event)

Soweit so gut - doch wie funktioniert der Login?

Durch die Umgebungsvariablen hat das Modul nuxt-auth-utils alle Informationen zur Verfügung um die Login Weiterleitung zu Erzeugen und im Redirect (zurück) auf die Nuxt Applikation die Session zu verwenden.

💡 Hinweis: Die runtimeConfig ist selbst keine Umgebungsvariable, sondern die Art, wie Nuxt den Zugang zu Umgebungsvariablen ermöglicht. Mehr dazu in der Nuxt Dokumentation{target="_blank"}.

Hierfür wird einfach eine serverseitige Route erzeugt - unter server/auth/keycloak.get.ts :

export default defineOAuthKeycloakEventHandler({
  async onSuccess(event, { user }) {
    await setUserSession(event, {
      user: {
        keycloak: user.preferred_username,
      },
      loggedInAt: Date.now(),
    })

    return sendRedirect(event, '/')
  },
})

Ruft man nun /auth/keycloak/ auf - so wird man automatisch auf die laufende Keycloak Instanz weitergeleitet und erhält nach erfolgreichem Login eine Session.

Das Modul ist von Sébastien Chopin{target="_blank"} - dem Autor von Nuxt persönlich und hat mit (Stand Sep 2025) 95.000 Downloads pro Monat, regelmäßigen Updates sowie 1.400 Stargazern ein solides Standing und kann guten Gewissens empfohlen werden.

Option 2: Integration mit @sidebase/nuxt-auth - Battle-tested und einsatzbereit

Eine weitere Möglichkeit Nuxt und Keycloak zusammenzubringen ist das Paket @sidebase/nuxt-auth. Mit ein paar Anpassungen in der nuxt.config.js lässt sich das Modul einfach konfigurieren:

runtimeConfig: {
    public: {
      authOrigin: 'http://localhost:3000',
    },
  },

  modules: [
    '@sidebase/nuxt-auth',
  ],

  auth: {
    isEnabled: true,
    disableServerSideAuth: false,
    provider: {
      type: 'authjs',
      trustHost: false,
      defaultProvider: 'keycloak',
      addDefaultCallbackUrl: true,
    },
    sessionRefresh: {
      enablePeriodically: true,
      enableOnWindowFocus: true,
    },
  },

Wie die Konfiguration schon zeigt kümmert sich @sidebase/nuxt-auth selbstständig darum die Session zu aktualisieren. Keycloak existiert als vorgefertigter Provider. Wir legen folgende Datei an server/api/auth/[...].ts und konfigurieren den Provider:

import KeycloakProvider from 'next-auth/providers/keycloak'
import { NuxtAuthHandler } from '#auth'

export default NuxtAuthHandler({
  secret: 'your-secret-here',
  providers: [
    KeycloakProvider.default({
      clientId: process.env.KEYCLOAK_ID,
      clientSecret: process.env.KEYCLOAK_SECRET,
      issuer: process.env.KEYCLOAK_ISSUER,
    })
  ]
})

Hier gilt es zu beachten, dass als Issuer die URL zum Keycloak Realm angegeben werden muss: https://my-keycloak-domain.com/realms/My_Realm.

Zusätzlich lassen sich Callbacks definieren, um auf verschiedene Events zu reagieren:

export default NuxtAuthHandler({
	...
	callbacks: {
	    /* on before signin */
	    async signIn({ user, account, profile, email, credentials }) {
	      return true
	    },
	    /* on redirect to another url */
	    async redirect({ url, baseUrl }) {
	      return baseUrl
	    },
	    /* on session retrieval */
	    async session({ session, user, token }) {
	      return session
	    },
	    /* on JWT token creation or mutation */
	    async jwt({ token, user, account, profile, isNewUser }) {
	      return token
	    }
	  }
})

@sidebase/nuxt-auth erzeugt selbstständig eine Seite, die den Login zur Verfügung stellt und mit den gegebenen Providern integriert.

Die Daten des Nutzers stehen dann wie folgt in der Applikation bereit:

<script setup>
const {
  status,
  data,
  lastRefreshedAt,
  getCsrfToken,
  getProviders,
  getSession,
  signIn,
  signOut
} = useAuth()
</script>

Der Status gibt an, ob der Nutzer authentifiziert ist, oder nicht. data beinhaltet nutzerspezifische Daten.

Das Modul ist SSR kompatibel und erlaubt es basierend auf der Session unterschiedliche Informationen zu rendern.

@sidebase/nuxt-auth wird von der sidebase{target="_blank"} entwickelt und hat sich als zuverlässige Lösung für Authentifizierung in Nuxt-Anwendungen etabliert. Mit einer gut situierten Firma im Rücken und regelmäßigen Updates bietet es eine solide Grundlage für produktive Anwendungen und kann guten Gewissens empfohlen werden.

Fazit: nuxt-auth-utils oder @sidebase/nuxt

Wie so oft steckt der Teufel im Anwendungsfall. 😉 Beide Module haben einen guten Track-Record bezüglich Weiterentwicklung, die Integration ist einfach und die Composables sind sehr gut.

Möchte man die typischen Authentifizierungsseiten selbst überarbeiten, eignet sich @sidebase/nuxt-auth besser. Auch kommt das Modul mit einer konfigurierbaren einfachen Refresh-Logik für die User Session. nuxt-auth-utils hingegen "fühlt" sich etwas leichtgewichtiger an. Eine Anfrage{target="_blank"} für automatischen Session-Refresh steht aktuell noch aus. Diese lässt sich i.d.R. aber einfach selbständig nachrüsten.

Wir können beide Module wärmstens empfehlen und freuen uns auf Feedback zu den Erfahrungen mit Nuxt und Keycloak in den Kommentaren!

Wie habt ihr Nuxt und Keycloak "zusammengesteckt"? Gibt es bessere Wege? Was sind eure Erfahrungen mit den Modulen?

In diesem Artikel erklären wir, warum herkömmliche Slider-Bibliotheken in Nuxt-Projekten oft versagen, was Embla Carousel so besonders macht und wie du damit performante, SEO-freundliche Karussells implementierst. Von der Problemanalyse über die Lösung bis hin zu Best Practices für Produktionsumgebungen – alles was du für Top-Performance Slider in Nuxt brauchst.

Einleitung: Das Problem mit Slidern in Nuxt

Warum sind Slider in Nuxt eine Herausforderung?

Slider und Karussells gehören zu den häufigsten UI-Komponenten im Web. Sie werden für Produktgalerien, Testimonials, Blog-Posts und vieles mehr verwendet. Doch in Nuxt-Projekten mit Server-Side Rendering (SSR) können sie schnell zu Performance-Problemen führen und die User Experience negativ beeinflussen.

Das liegt daran, dass viele herkömmliche Slider-Bibliotheken wie Swiper.js, Slick Carousel oder Owl Carousel nicht für moderne SSR-Frameworks entwickelt wurden. Sie verursachen typischerweise folgende Probleme:

• Keine SSR-Unterstützung: Viele Slider funktionieren nur client-seitig und erzeugen Hydration-Mismatches
• Hydration-Mismatches: Unterschiede zwischen Server- und Client-Rendering führen zu JavaScript-Fehlern
• Große JavaScript-Bundles: 50-100KB zusätzlicher Code verlangsamen die Ladezeit
• Layout-Shifts: Unvorhersehbare Größenänderungen verschlechtern Core Web Vitals
• Schlechte SEO-Performance: Suchmaschinen können dynamische Inhalte nicht richtig indexieren
• Accessibility-Probleme: Viele Slider sind nicht barrierefrei und verstoßen gegen WCAG-Richtlinien

Die Lösung: Embla Carousel

Nach umfangreichen Tests verschiedener Slider-Bibliotheken in realen Nuxt-Projekten haben wir Embla Carousel als die beste Lösung für moderne Web-Anwendungen identifiziert. Embla wurde speziell für Frameworks wie Nuxt, Next.js und SvelteKit entwickelt und löst die typischen Probleme herkömmlicher Slider-Bibliotheken.

Was macht Embla Carousel so besonders:

• Native SSR-Unterstützung: Perfekte Integration mit Nuxt's Server-Side Rendering
• Minimale Bundle-Größe: Nur ~7KB gzipped vs. 50-100KB bei anderen Bibliotheken
• Hervorragende Performance: Optimierte Rendering-Engine ohne Virtual DOM Overhead
• Touch-Gesten und Accessibility: Vollständige WCAG-Konformität und mobile Optimierung
• TypeScript-Unterstützung: Vollständig typisiert für sichere Entwicklung
• Flexible Konfiguration: Anpassbar an jedes Design-System und Anforderung

:GlobalButton{:url="/technologien/vuejs-nuxt/" :label="Du willst Vue.js richtig einsetzen – Wir helfen dir dabei!" :target="_blank" :color="blue" .mb-6}

Warum herkömmliche Slider-Bibliotheken versagen

Swiper.js: Der Klassiker mit Problemen

Swiper.js{target="_blank"} ist zweifellos eine der beliebtesten Slider-Bibliotheken. Mit über 35.000 GitHub-Stars und einer großen Community scheint es die perfekte Wahl zu sein. Doch in Nuxt-Projekten stößt Swiper schnell an seine Grenzen.

Die Probleme mit Swiper.js sind vielfältig und reichen von der enormen Bundle-Größe von über 45KB gzipped für die Basis-Version bis hin zu grundlegenden SSR-Problemen. Swiper bietet keine native SSR-Unterstützung und erfordert Client-only-Wrapper, was zu häufigen Hydration-Issues führt. Diese Mismatches zwischen Server- und Client-Rendering können die User Experience erheblich beeinträchtigen. Zusätzlich leidet die Performance unter Virtual DOM Overhead und unnötigen Re-Renders, während grundlegende Accessibility-Features oft fehlen.

Slick Carousel: Der Legacy-Klassiker

Slick Carousel{target="_blank"} war lange Zeit der Standard für jQuery-basierte Slider. Doch in modernen Vue.js/Nuxt-Anwendungen ist es nicht mehr zeitgemäß.

Die jQuery-Abhängigkeit stellt eine unnötige Belastung in modernen Frameworks dar, während die fehlende SSR-Unterstützung bedeutet, dass Slick nur client-seitig funktioniert. Mit einer Bundle-Größe von über 30KB zusätzlich zu jQuery und einer veralteten Architektur, die nicht für moderne Web-Standards entwickelt wurde, ist Slick Carousel heute keine praktikable Option mehr.

Owl Carousel: Der vergessene Klassiker

Owl Carousel{target="_blank"} war einst beliebt, hat aber mit modernen Frameworks erhebliche Probleme.

Seit Jahren gibt es keine aktiven Updates, was zu SSR-Inkompatibilität führt. Das Framework funktioniert nicht mit Server-Side Rendering und leidet unter Performance-Problemen durch ineffiziente DOM-Manipulation. Zusätzlich fehlen Accessibility-Features und WCAG-Konformität, was es für moderne Web-Anwendungen ungeeignet macht.

Embla Carousel: Die moderne Alternative

Was ist Embla Carousel?

Embla Carousel{target="_blank"} ist eine moderne, leichte und performante Slider-Bibliothek, die speziell für moderne Web-Frameworks entwickelt wurde. Im Gegensatz zu herkömmlichen Slider-Bibliotheken wurde Embla von Grund auf für SSR, Performance und Accessibility konzipiert.

Die Entwicklungsphilosophie von Embla Carousel basiert auf vier fundamentalen Prinzipien: Framework-Agnostizismus ermöglicht die Verwendung mit Vue, React, Svelte und Vanilla JavaScript. Der Performance-first-Ansatz garantiert minimale Bundle-Größe und eine optimierte Rendering-Engine. Accessibility-by-default bedeutet, dass alle WCAG-Richtlinien von Anfang an beachtet werden. Und schließlich bietet Embla native Unterstützung für Server-Side Rendering, was es zur idealen Wahl für Nuxt-Projekte macht.

Technische Vorteile von Embla Carousel

1. Minimale Bundle-Größe Embla Carousel ist mit nur ~7KB gzipped extrem kompakt. Im Vergleich dazu benötigen Swiper.js über 45KB gzipped, Slick Carousel über 30KB gzipped plus jQuery, und Owl Carousel etwa 25KB gzipped. Diese deutliche Reduktion der Bundle-Größe führt zu schnelleren Ladezeiten und besserer Performance.

2. Optimierte Performance Embla Carousel verzichtet bewusst auf Virtual DOM und nutzt direkte DOM-Manipulation ohne Overhead. Intelligentes Caching sorgt für effiziente Speichernutzung, während Lazy Loading Bilder und Inhalte bedarfsgerecht lädt. Die Touch-Optimierung bietet native Touch-Gesten ohne zusätzliche Bibliotheken.

3. Native SSR-Unterstützung Embla Carousel ist hydration-frei und verursacht keine Mismatches zwischen Server und Client. Die SEO-freundliche Struktur ermöglicht es Suchmaschinen, alle Inhalte zu indexieren. Progressive Enhancement bedeutet, dass der Slider auch ohne JavaScript funktioniert.

4. Accessibility-Features Vollständige Tastatursteuerung ermöglicht die Navigation über Keyboard, während Screen Reader Support durch ARIA-Labels und semantische Struktur gewährleistet wird. Intelligente Fokus-Verwaltung und WCAG 2.1 AA Konformität erfüllen alle wichtigen Accessibility-Standards.

Für detaillierte Performance-Benchmarks und Vergleiche empfehlen wir die offizielle Embla Carousel API-Dokumentation.

Installation und Setup

1. Embla Carousel installieren

npm install embla-carousel-vue
# oder
yarn add embla-carousel-vue

2. Grundlegende Komponenten-Struktur

Die emblaCarouselVue Funktion bietet eine nahtlose Integration mit Vue. Ein minimales Setup benötigt einen overflow wrapper und einen scroll container. Hier ist die grundlegende Struktur:

<script setup>
import emblaCarouselVue from 'embla-carousel-vue'

const [emblaRef] = emblaCarouselVue()
</script>

<template>
  <div class="embla" ref="emblaRef">
    <div class="embla__container">
      <div class="embla__slide">Slide 1</div>
      <div class="embla__slide">Slide 2</div>
      <div class="embla__slide">Slide 3</div>
    </div>
  </div>
</template>

3. Styling des Carousels

Die emblaCarouselVue Funktion gibt uns eine emblaRef, die wir an unser Wrapper-Element mit der Klasse embla anhängen, um den Scroll-Overflow zu verstecken. Das Element mit der container Klasse ist der Scroll-Body, der die Slides scrollt. Hier ist das benötigte CSS:

<style scoped>
.embla {
  overflow: hidden;
}

.embla__container {
  display: flex;
}

.embla__slide {
  flex: 0 0 100%;
  min-width: 0;
}
</style>

4. Zugriff auf die Carousel API

Die emblaCarouselVue Funktion nimmt die Embla Carousel Optionen als ersten Parameter. Zusätzlich kannst du mit onMounted auf die API zugreifen:

<script setup>
import { onMounted } from 'vue'
import emblaCarouselVue from 'embla-carousel-vue'

const [emblaRef, emblaApi] = emblaCarouselVue({ loop: false })

onMounted(() => {
  if (emblaApi.value) {
    console.log(emblaApi.value.slideNodes()) // API-Zugriff
  }
})
</script>

<template>
  <div class="embla" ref="emblaRef">
    <div class="embla__container">
      <div class="embla__slide">Slide 1</div>
      <div class="embla__slide">Slide 2</div>
      <div class="embla__slide">Slide 3</div>
    </div>
  </div>
</template>

5. Plugins hinzufügen (optional)

Falls du Plugins verwenden möchtest, installiere zuerst das gewünschte Plugin. Zum Beispiel das Autoplay-Plugin:

npm install embla-carousel-autoplay
# oder
yarn add embla-carousel-autoplay

Die emblaCarouselVue Funktion akzeptiert Plugins als zweiten Parameter. Plugins müssen in einem Array übergeben werden:

<script setup>
import emblaCarouselVue from 'embla-carousel-vue'
import Autoplay from 'embla-carousel-autoplay'

const [emblaRef] = emblaCarouselVue({ loop: false }, [Autoplay()])
</script>

<template>
  <div class="embla" ref="emblaRef">
    <div class="embla__container">
      <div class="embla__slide">Slide 1</div>
      <div class="embla__slide">Slide 2</div>
      <div class="embla__slide">Slide 3</div>
      <div class="embla__slide">Slide 4</div>
    </div>
  </div>
</template>

Anwendungsfälle und Use Cases

Wann solltest du Embla Carousel verwenden?

Embla Carousel eignet sich besonders gut für verschiedene Anwendungsfälle, die wir im Detail betrachten wollen.

1. Produktgalerien Für E-Commerce-Websites sind hochperformante Produktgalerien essentiell. Embla Carousel bietet touch-optimierte Navigation für mobile Nutzer, Lazy Loading für schnelle Ladezeiten, Zoom-Funktionalität für detaillierte Produktansichten und eine SEO-freundliche Struktur für bessere Suchmaschinen-Rankings. Diese Kombination macht Embla zur idealen Wahl für Online-Shops, die auf Conversion und Performance setzen.

2. Testimonials und Reviews Kundenbewertungen sind entscheidend für die Conversion-Rate. Embla Carousel unterstützt diese Anforderung durch Autoplay-Funktionalität für automatische Rotation, Pause bei Hover für bessere Nutzerkontrolle, umfassende Accessibility-Features für alle Nutzer und responsives Design für alle Geräte. Diese Features sorgen dafür, dass Kundenbewertungen optimal präsentiert werden.

3. Blog-Post Slider Für Content-Marketing und Blog-Websites bietet Embla Carousel Infinite Loop für endlose Navigation, Keyboard Navigation für Power-User, Screen Reader Support für barrierefreien Zugang und Social Media Integration für Sharing-Funktionen. Diese Kombination macht den Slider ideal für Content-vermittelnde Websites.

4. Team-Mitglieder Präsentation Für Unternehmenswebsites und Portfolios bietet Embla Carousel Grid-Layout für mehrere Slides gleichzeitig, Hover-Effekte für interaktive Elemente, Smooth Transitions für professionelle Optik und Mobile-First Design für optimale Nutzung. Diese Features sorgen für eine professionelle Präsentation von Team-Mitgliedern.

Performance-Vorteile in der Praxis

SEO-Verbesserungen Durch die native SSR-Unterstützung kannst du die SEO-Performance deutlich verbessern. Die optimierten Core Web Vitals durch schnelles Rendering führen zu hohen Lighthouse Scores und guten Google PageSpeed Bewertungen für mobile Geräte. Die verbesserte Indexierung von Bildinhalten in der Search Console rundet die SEO-Vorteile ab.

Grundlegende Implementierung

Einfacher Slider

<template>
  <div class="embla" ref="emblaRef">
    <div class="embla__container">
      <div class="embla__slide" v-for="(slide, index) in slides" :key="index">
        <img :src="slide.image" :alt="slide.title" class="w-full h-64 object-cover" />
        <h3 class="text-xl font-bold mt-4">{{ slide.title }}</h3>
        <p class="text-gray-600">{{ slide.description }}</p>
      </div>
    </div>
  </div>
</template>

<script setup>
import { ref, onMounted } from 'vue'
import emblaCarouselVue from 'embla-carousel-vue'

const [emblaRef, emblaApi] = emblaCarouselVue()

const slides = ref([
  {
    image: '/img/blog/team/blue_shoes-47.jpg',
    title: 'Cloud Native Entwicklung',
    description: 'Moderne Anwendungen mit Docker, Kubernetes und Microservices',
    link: '/leistungen/cloud-native-entwicklung'
  },
  {
    image: '/img/blog/team/blue_shoes-3.jpg',
    title: 'Vue.js & Nuxt.js Expertise',
    description: 'Performante Frontend-Lösungen mit modernen Frameworks',
    link: '/technologien/vuejs-nuxt'
  },
  {
    image: '/img/blog/team/blue_shoes-28.jpg',
    title: 'DevOps & CI/CD',
    description: 'Automatisierte Deployment-Pipelines für maximale Effizienz',
    link: '/leistungen/devops-consulting'
  },
  {
    image: '/img/blog/team/blue_shoes-61.jpg',
    title: 'API-Entwicklung',
    description: 'RESTful APIs und GraphQL mit Python, FastAPI und Django',
    link: '/leistungen/api-entwicklung'
  }
])

onMounted(() => {
  if (emblaApi.value) {
    emblaApi.value.on('select', (event) => {
      const currentSlide = slides.value[event.selectedScrollSnap()]
      console.log(`Aktueller Slide: ${currentSlide.title}`)
    })
  }
})
</script>

<style scoped>
.embla {
  overflow: hidden;
}

.embla__container {
  display: flex;
  gap: 1rem;
}

.embla__slide {
  flex: 0 0 100%;
  min-width: 0;
}
</style>

Erweiterte Features und Konfiguration

Responsive Design und Breakpoints

Embla Carousel bietet hervorragende Unterstützung für responsive Design. Mit den integrierten Breakpoints kannst du das Verhalten des Sliders an verschiedene Bildschirmgrößen anpassen.

Die Vorteile der responsiven Konfiguration umfassen einen Mobile-First Approach, der für Touch-Geräte optimiert ist, Tablet-Optimierung mit angepasster Navigation für mittlere Bildschirme, Desktop-Enhancement mit erweiterten Features für große Bildschirme und Performance-Optimierung, bei der nur notwendige Features geladen werden.

Autoplay und Interaktivität

Die Autoplay-Funktionalität von Embla Carousel ist besonders benutzerfreundlich gestaltet.

Intelligente Autoplay-Features umfassen Pause bei Hover für automatisches Pausieren bei Nutzerinteraktion, Touch-Pause, das bei Touch-Gesten auf mobilen Geräten stoppt, Keyboard-Pause bei Tastatureingaben und Visibility API, das pausiert, wenn der Slider nicht sichtbar ist.

Touch-Gesten und Mobile Optimierung

Embla Carousel bietet native Touch-Unterstützung ohne zusätzliche Bibliotheken.

Die Touch-Features umfassen Swipe-Gesten für natürliche Swipe-Navigation, Momentum Scrolling mit Physik-basierten Animationen, Touch Resistance, die versehentliche Navigation verhindert, und Multi-Touch Support für Pinch-to-Zoom und andere Gesten.

Performance-Optimierungen

Lazy Loading für Bilder

Embla Carousel unterstützt nativ Lazy Loading für optimale Performance. Hier ist ein Beispiel für die Implementierung:

<template>
  <div class="embla" ref="emblaRef">
    <div class="embla__container">
      <div class="embla__slide" v-for="(slide, index) in slides" :key="index">
        <img 
          :src="slide.image" 
          :alt="slide.title" 
          loading="lazy"
          class="w-full h-64 object-cover"
        />
        <h3 class="text-xl font-bold mt-4">{{ slide.title }}</h3>
        <p class="text-gray-600">{{ slide.description }}</p>
      </div>
    </div>
  </div>
</template>

<script setup>
import emblaCarouselVue from 'embla-carousel-vue'

const [emblaRef] = emblaCarouselVue()
</script>

Intersection Observer für Performance

Für zusätzliche Performance-Optimierung kannst du Intersection Observer verwenden, um den Slider nur zu initialisieren, wenn er sichtbar ist:

<script setup>
import { ref, onMounted } from 'vue'
import emblaCarouselVue from 'embla-carousel-vue'

const isVisible = ref(false)
const sliderRef = ref(null)
const [emblaRef, emblaApi] = emblaCarouselVue()

onMounted(() => {
  const observer = new IntersectionObserver(
    ([entry]) => {
      isVisible.value = entry.isIntersecting
    },
    { threshold: 0.1 }
  )
  
  if (sliderRef.value) {
    observer.observe(sliderRef.value)
  }
})
</script>

<template>
  <div ref="sliderRef" class="embla" ref="emblaRef">
    <div class="embla__container">
      <div class="embla__slide" v-for="(slide, index) in slides" :key="index">
        <img :src="slide.image" :alt="slide.title" class="w-full h-64 object-cover" />
      </div>
    </div>
  </div>
</template>

Optimierte Bundle-Größe

Für Nuxt-Projekte kannst du die Bundle-Größe durch optimierte Konfiguration weiter reduzieren:

// nuxt.config.ts
export default defineNuxtConfig({
  build: {
    transpile: ['embla-carousel-vue']
  },
  vite: {
    optimizeDeps: {
      include: ['embla-carousel-vue']
    }
  }
})

Accessibility und SEO-Optimierung

Warum Accessibility für Slider wichtig ist

Slider sind oft kritische UI-Komponenten, die von allen Nutzern bedient werden können müssen. Embla Carousel wurde von Grund auf mit Accessibility im Fokus entwickelt und bietet native Unterstützung für Screen Reader, Keyboard-Navigation und WCAG 2.1 AA Konformität.

Die Vorteile für Slider-spezifische Accessibility reichen von vollständiger Tastatursteuerung für Power-User bis hin zu Screen Reader Support, der es blinden Nutzern ermöglicht, durch alle Slides zu navigieren. Embla's native ARIA-Labels und semantische Struktur sorgen dafür, dass jeder Slide korrekt beschrieben wird.

Embla Carousel Accessibility-Features

Embla Carousel bietet umfassende Accessibility-Features, die speziell für Slider-Implementierungen entwickelt wurden:

1. Keyboard Navigation für Slider

<template>
  <div 
    class="embla" 
    ref="emblaRef"
    @keydown="handleKeydown"
    tabindex="0"
    role="region"
    aria-label="Bildergalerie"
  >
    <div class="embla__container">
      <div class="embla__slide" v-for="(slide, index) in slides" :key="index">
        <img :src="slide.image" :alt="slide.title" class="w-full h-64 object-cover" />
      </div>
    </div>
  </div>
</template>

<script setup>
import emblaCarouselVue from 'embla-carousel-vue'

const [emblaRef, emblaApi] = emblaCarouselVue()

const handleKeydown = (event) => {
  switch (event.key) {
    case 'ArrowLeft':
      emblaApi.value?.scrollPrev()
      break
    case 'ArrowRight':
      emblaApi.value?.scrollNext()
      break
    case 'Home':
      emblaApi.value?.scrollTo(0)
      break
    case 'End':
      emblaApi.value?.scrollTo(slides.value.length - 1)
      break
  }
}
</script>

2. Screen Reader Support für Slider-Inhalte

<template>
  <div class="embla" ref="emblaRef">
    <div class="embla__container">
      <div 
        class="embla__slide" 
        v-for="(slide, index) in slides" 
        :key="index"
        :aria-label="`Slide ${index + 1} von ${slides.length}: ${slide.title}`"
        :aria-hidden="emblaApi?.selectedScrollSnap() !== index"
      >
        <img 
          :src="slide.image" 
          :alt="slide.title" 
          class="w-full h-64 object-cover"
        />
      </div>
    </div>
    
    <!-- Navigation mit ARIA-Labels -->
    <button 
      class="embla__prev" 
      @click="emblaApi?.scrollPrev()"
      aria-label="Vorheriger Slide"
      :aria-disabled="emblaApi?.canScrollPrev() === false"
    >
      ←
    </button>
    <button 
      class="embla__next" 
      @click="emblaApi?.scrollNext()"
      aria-label="Nächster Slide"
      :aria-disabled="emblaApi?.canScrollNext() === false"
    >
      →
    </button>
  </div>
</template>

<script setup>
import emblaCarouselVue from 'embla-carousel-vue'

const [emblaRef, emblaApi] = emblaCarouselVue()
</script>

SEO-Optimierung für Slider-Inhalte

Slider stellen eine besondere Herausforderung für SEO dar, da dynamische Inhalte oft von Suchmaschinen übersehen werden. Embla Carousel löst dieses Problem durch native SSR-Unterstützung und SEO-freundliche Strukturen.

Warum SEO für Slider kritisch ist:

• Bildindexierung: Suchmaschinen können alle Bilder in Slidern indexieren, nicht nur das erste
• Content-Accessibility: Alle Slide-Inhalte sind für Crawler verfügbar, nicht nur sichtbare
• Strukturierte Daten: Schema.org Markup für Karussell-Inhalte verbessert Snippets
• Core Web Vitals: Optimierte Performance verbessert Rankings für Seiten mit Slidern

SEO-Best Practices für Embla Slider:

• Semantische HTML-Struktur: Verwendung von korrekten HTML-Tags für Slider-Inhalte
• Aussagekräftige Alt-Texte: Jedes Bild im Slider benötigt beschreibende Alt-Texte
• Strukturierte Daten: Schema.org Markup für Karussell-Inhalte implementieren
• Meta-Beschreibungen: Optimierte Meta-Tags für jeden Slide-Inhalt

Best Practices für Slider-Implementierungen

Warum Slider-spezifische Optimierung wichtig ist

Slider sind oft die ersten Elemente, die Nutzer auf einer Seite sehen. Eine schlecht optimierte Slider-Implementierung kann die gesamte User Experience negativ beeinflussen. Embla Carousel bietet spezielle Features für Produktionsumgebungen.

Slider-spezifische Probleme:

• Langsame Ladezeiten: Große Bilder in Slidern verlangsamen die Initial Page Load
• Layout-Shifts: Unvorhersehbare Größenänderungen verschlechtern Core Web Vitals
• Touch-Probleme: Schlechte Touch-Optimierung auf mobilen Geräten
• Accessibility-Mängel: Viele Slider sind nicht barrierefrei

Error Handling für Slider

Robustes Error Handling ist besonders wichtig für Slider, da sie oft kritische Inhalte präsentieren:

1. Graceful Degradation für Slider

<script setup>
import { ref, onMounted } from 'vue'
import emblaCarouselVue from 'embla-carousel-vue'

const hasError = ref(false)
const errorMessage = ref('')
const isLoading = ref(true)

const [emblaRef, emblaApi] = emblaCarouselVue()

onMounted(() => {
  try {
    if (emblaApi.value) {
      emblaApi.value.on('error', (error) => {
        console.error('Slider error:', error)
        hasError.value = true
        errorMessage.value = 'Bildergalerie konnte nicht geladen werden'
      })
      
      emblaApi.value.on('init', () => {
        isLoading.value = false
        console.log('Slider erfolgreich initialisiert')
      })
    }
  } catch (error) {
    hasError.value = true
    errorMessage.value = `Fehler beim Initialisieren der Bildergalerie: ${error.message}`
    isLoading.value = false
    console.error('Slider initialization failed:', error)
  }
})
</script>

Progressive Enhancement für Slider

Slider müssen auch ohne JavaScript funktionieren, um SEO und Accessibility zu gewährleisten:

1. Progressive Enhancement für Slider

<template>
  <div class="embla">
    <!-- Fallback für SEO und No-JS -->
    <div class="embla__fallback" v-if="!isHydrated">
      <div v-for="(slide, index) in slides" :key="index" class="slide-fallback mb-8">
        <img 
          :src="slide.image" 
          :alt="slide.title" 
          class="w-full h-64 object-cover rounded-lg"
        />
        <h3 class="text-xl font-bold mt-4 text-gray-800">{{ slide.title }}</h3>
        <p class="text-gray-600 mt-2">{{ slide.description }}</p>
        <a 
          :href="slide.link" 
          class="inline-block mt-4 px-6 py-2 bg-blue-600 text-white rounded-lg hover:bg-blue-700 transition-colors"
        >
          Mehr erfahren
        </a>
      </div>
    </div>
    
    <!-- Hydrated Slider mit voller Funktionalität -->
    <div v-else class="embla" ref="emblaRef">
      <div class="embla__container">
        <div 
          class="embla__slide" 
          v-for="(slide, index) in slides" 
          :key="index"
        >
          <div class="relative group">
            <img 
              :src="slide.image" 
              :alt="slide.title" 
              class="w-full h-64 object-cover rounded-lg transition-transform group-hover:scale-105"
            />
            <div class="absolute inset-0 bg-black bg-opacity-40 rounded-lg opacity-0 group-hover:opacity-100 transition-opacity">
              <div class="absolute bottom-4 left-4 text-white">
                <h3 class="text-xl font-bold">{{ slide.title }}</h3>
                <p class="text-sm">{{ slide.description }}</p>
              </div>
            </div>
          </div>
        </div>
      </div>
    </div>
  </div>
</template>

<script setup>
import { ref } from 'vue'

const isHydrated = ref(false)

onMounted(() => {
  isHydrated.value = true
})
</script>

Performance-Metriken für Slider

Für Slider-spezifische Performance-Optimierung sind bestimmte Metriken besonders wichtig:

Slider-spezifische Metriken:

• Ladezeit: Slider sollten unter 1 Sekunde laden, da sie oft Above-the-Fold sind
• Interaktionsverzögerung: Slide-Wechsel sollten unter 100ms reagieren
• Memory Usage: Überwachung von Speicherlecks bei langen Slider-Sessions
• Touch-Responsiveness: Touch-Gesten sollten sofort reagieren
• Slide-Transition-Performance: Flüssige Übergänge zwischen Slides

Fazit: Warum Embla Carousel die beste Slider-Lösung ist

Nach jahrelanger Erfahrung mit verschiedenen Slider-Bibliotheken in Nuxt-Projekten können wir mit Sicherheit sagen: Embla Carousel ist die beste Lösung für moderne Slider-Implementierungen.

Zusammenfassung der Slider-Vorteile

Performance-Vorteile für Slider: Embla Carousel bietet eine kleine Bundle-Größe von nur ~7KB gzipped, was besonders wichtig ist, da Slider oft Above-the-Fold geladen werden. Hohe FPS und flüssige Animationen sorgen für professionelle Slide-Übergänge, während schnelle Ladezeiten durch optimierte Architektur die User Experience verbessern. Keine Hydration-Mismatches dank nativer SSR-Unterstützung machen Embla zur idealen Wahl für Nuxt-Projekte.

SEO- und Accessibility-Vorteile für Slider: Vollständige WCAG 2.1 AA Konformität ist besonders wichtig für Slider, da sie oft kritische Inhalte präsentieren. Bessere Google-Rankings durch optimierte Core Web Vitals, Screen Reader Support für barrierefreien Zugang zu allen Slides und Keyboard Navigation für Power-User machen Embla zur idealen Wahl für professionelle Slider-Implementierungen.

Entwickler-Erfahrung für Slider: TypeScript-Unterstützung für sichere Slider-Entwicklung, flexible Konfiguration für alle Slider-Anwendungsfälle, aktive Community und regelmäßige Updates sowie umfassende Dokumentation und Beispiele sorgen für eine hervorragende Entwicklererfahrung bei der Implementierung von Slidern.

Wann du Embla Carousel für Slider verwenden solltest

Perfekt geeignet für Slider in: Embla Carousel ist ideal für E-Commerce-Websites mit Produktgalerien, Corporate Websites mit Team-Präsentationen, Blog-Websites mit Content-Slidern, Portfolio-Websites mit Projekt-Galerien und Marketing-Websites mit Testimonial-Slidern.

Nicht geeignet für: Sehr einfache Bildergalerien ohne Interaktivität, Legacy-Projekte mit jQuery-Abhängigkeiten oder Projekte mit sehr spezifischen Anforderungen an andere Slider-Bibliotheken sind weniger geeignet für Embla Carousel.

Business-Impact für Slider-Implementierungen

Die Implementierung von Embla Carousel für Slider kann erhebliche Vorteile für dein Business bringen:

Performance-Impact für Slider: Schnellere Ladezeiten verbessern die User Experience bei Slidern, während bessere Core Web Vitals zu höheren Google-Rankings führen. Reduzierte Bounce-Rate durch schnellere Slider-Interaktionen rundet die Performance-Vorteile ab.

SEO-Impact für Slider: Verbesserte Bildindexierung durch SEO-freundliche Slider-Struktur, bessere Accessibility-Scores in Lighthouse und höhere Conversion-Rates durch optimierte Slider-User Experience sind die wichtigsten SEO-Vorteile.

Entwicklungs-Impact für Slider: Schnellere Entwicklung durch einfache Slider-Integration, weniger Bugs durch TypeScript und robuste Slider-Architektur sowie einfachere Wartung durch klare API und Dokumentation machen Embla Carousel zur idealen Wahl für Slider-Entwicklerteams.

FAQ – Häufige Fragen zu Embla Carousel in Nuxt

1. Warum ist Embla Carousel die beste Wahl für Nuxt SSR?

Embla Carousel bietet native SSR-Unterstützung, minimale Bundle-Größe und hervorragende Performance. Es ist speziell für moderne Web-Frameworks entwickelt und funktioniert nahtlos mit Nuxt's Server-Side Rendering. Im Gegensatz zu anderen Slider-Bibliotheken verursacht Embla keine Hydration-Mismatches und bietet optimale Performance für Nuxt-Projekte.

2. Wie implementiere ich Embla Carousel in einem Nuxt-Projekt?

Die Implementierung ist denkbar einfach: Installieren Sie das Embla Carousel Vue-Plugin mit npm install embla-carousel-vue und verwenden Sie die emblaCarouselVue Funktion in Ihren Komponenten. Erstellen Sie eine Client-only-Komponente für die Carousel-Funktionalität und nutzen Sie Nuxt's SSR-Features für optimale Performance. Die detaillierte Implementierung haben wir in diesem Artikel Schritt für Schritt erklärt.

3. Welche Performance-Optimierungen bietet Embla Carousel?

Embla Carousel bietet Lazy Loading, Touch-Gesten, Keyboard-Navigation, automatische Größenanpassung und minimale JavaScript-Ausführung. Diese Features sorgen für flüssige Animationen und optimale Nutzererfahrung. Zusätzlich unterstützt Embla Intersection Observer für bedarfsgerechte Initialisierung und bietet native Touch-Optimierung ohne zusätzliche Bibliotheken.

4. Kann ich Embla Carousel mit TypeScript in Nuxt verwenden?

Ja, Embla Carousel bietet vollständige TypeScript-Unterstützung. Die Typen sind bereits im Paket enthalten und bieten hervorragende IDE-Unterstützung für eine sichere Entwicklung. Die emblaCarouselVue Funktion ist vollständig typisiert und bietet IntelliSense für alle Optionen und Methoden.

5. Wie handle ich Bilder und Medien in Embla Carousel?

Embla Carousel unterstützt Lazy Loading für Bilder und bietet optimierte Medien-Handling-Features. Kombinieren Sie es mit Nuxt Image für zusätzliche Performance-Optimierungen. Das loading="lazy" Attribut wird nativ unterstützt, und Sie können Intersection Observer für zusätzliche Performance-Optimierungen verwenden.

6. Welche Alternativen zu Embla Carousel gibt es für Nuxt?

Alternativen sind Swiper.js, Splide.js oder Slick Carousel. Embla Carousel zeichnet sich jedoch durch bessere SSR-Unterstützung, kleinere Bundle-Größe und modernere Architektur aus. Wie wir in diesem Artikel gezeigt haben, haben herkömmliche Slider-Bibliotheken erhebliche Nachteile in Nuxt-Projekten, während Embla Carousel speziell für moderne Web-Frameworks entwickelt wurde.

:GlobalButton{:url="/kontakt/" :label="Brauchst du Hilfe bei der Slider-Implementierung? Kontaktiere uns!" :target="_blank" :color="green" .mt-8}

In diesem Artikel erklären wir, wie du TailwindCSS optimal in dein Nuxt 3-Projekt integrierst, welche Performance-Optimierungen du nutzen kannst und wie du ein skalierbares Design-System aufbaust.

::GlobalBlogLevelInfo

• TailwindCSS{target="_blank"} und Tailwind CSS für Nuxt{target="_blank"}
• Nuxt in Version 3{target="_blank"}
• Saubere Vue.js Komponenten

Solltest du Fragen haben, oder dir etwas unklar sein, kannst du die Kommentarfunktion unter dem Artikel nutzen. ::

Einleitung: TailwindCSS meets Nuxt 3

Was ist TailwindCSS?

TailwindCSS ist ein Utility-First CSS-Framework, das einen völlig anderen Ansatz als traditionelle CSS-Frameworks verfolgt. Statt vordefinierter Komponenten bietet es eine umfangreiche Sammlung von Utility-Klassen, die direkt im HTML verwendet werden können. Diese Klassen ermöglichen es, Designs direkt im Markup zu erstellen, ohne zwischen HTML und CSS-Dateien wechseln zu müssen.

Warum TailwindCSS mit Nuxt 3?

Die Kombination aus Nuxt 3 und TailwindCSS bietet eine leistungsstarke Grundlage für moderne Webanwendungen. Nuxt 3's Server-Side Rendering (SSR) und Static Site Generation (SSG) Fähigkeiten harmonieren perfekt mit TailwindCSS's Utility-First-Ansatz.

Vorteile der Kombination:

1. Schnelle Entwicklung

   • Direktes Styling im Template
   • Kein Kontextwechsel zwischen Dateien
   • Konsistente Design-Sprache

2. Optimierte Performance

   • Automatische PurgeCSS-Integration
   • Minimale Bundle-Größe
   • Effizientes Caching

3. Flexibilität

   • Einfache Anpassung an Design-Systeme
   • Responsive Design ohne Media Queries
   • Dark Mode Support

4. Developer Experience

   • Intuitive API
   • Gute IDE-Unterstützung
   • Umfangreiche Dokumentation

Nachteile und Herausforderungen:

1. Lernkurve

   • Neue Denkweise beim Styling
   • Viele Utility-Klassen zu lernen
   • Komplexere Templates

2. Team-Koordination

   • Konsistente Namenskonventionen nötig
   • Code-Reviews erfordern Tailwind-Kenntnisse
   • Potenzielle Template-Komplexität

3. Build-Zeit

   • Längere Build-Zeiten bei großen Projekten
   • Höherer Speicherverbrauch während der Entwicklung
   • Komplexere PostCSS-Konfiguration

::GlobalCallAnExpert{:bg="bg-bs-blue"} #buttonBlockTitle Wir können auch Deine Nuxt und Tailwind Projekte optimieren. ::

Entwicklungsumgebung einrichten

Bevor wir mit der Installation beginnen, sollten wir die Entwicklungsumgebung optimal einrichten. Hier sind die wichtigsten Tools und Einstellungen für VSCode:

1. VSCode Extensions

Installiere folgende Extensions für die beste Developer Experience:

• Tailwind CSS IntelliSense{target="_blank"}
  • Autocomplete für Tailwind-Klassen
  • Hover-Vorschau
  • Syntax-Highlighting

2. VSCode Einstellungen

Füge diese Einstellungen zu deiner settings.json hinzu:

{
  "editor.quickSuggestions": {
    "strings": true
  },
  "files.associations": {
    "*.css": "tailwindcss"
  },
}

3. Debug-Tools

Für die Entwicklung empfehlen wir folgende Tools:

• Tailwind CSS Debug Tools

  • Browser-DevTools für Tailwind
  • Komponenten-Inspektion
  • Responsive Design Testing

• Nuxt DevTools

  • Performance-Monitoring
  • Komponenten-Hierarchie
  • State-Management

Installation und Grundkonfiguration

Die Integration von TailwindCSS in Nuxt 3 ist dank des offiziellen Moduls @nuxtjs/tailwindcss sehr einfach. Das Modul kümmert sich automatisch um die grundlegende Konfiguration und optimiert TailwindCSS für die Nutzung mit Nuxt 3.

1. Voraussetzungen

Stelle sicher, dass du ein funktionierendes Nuxt 3-Projekt{target="_blank"} hast:

# Neues Nuxt 3 Projekt erstellen
npm create nuxt <project-name>
cd <project-name>

# Dependencies installieren
npm install

2. Installation

Die Installation erfolgt mit einem einzigen Befehl:

npx nuxi@latest module add tailwindcss

Alternativ kannst du auch npm oder yarn verwenden:

# Mit npm
npm install -D @nuxtjs/tailwindcss

# Mit yarn
yarn add -D @nuxtjs/tailwindcss

3. Nuxt-Konfiguration

Nach der Installation wird das Modul automatisch in deiner nuxt.config.ts aktiviert. Du kannst die Konfiguration bei Bedarf anpassen:

// nuxt.config.ts
export default defineNuxtConfig({
  modules: ['@nuxtjs/tailwindcss']
})

4. Tailwind-Konfiguration

Das Modul sucht automatisch nach folgenden Dateien:

• ./assets/css/tailwind.css
• ./tailwind.config.{js,cjs,mjs,ts}

Falls diese Dateien nicht existieren, werden sie automatisch mit einer Basis-Konfiguration erstellt. Du kannst die Konfiguration auch manuell anpassen:

// tailwind.config.ts
import type { Config } from 'tailwindcss'

export default {
  content: [
    './components/**/*.{js,vue,ts}',
    './layouts/**/*.vue',
    './pages/**/*.vue',
    './plugins/**/*.{js,ts}',
    './app.vue',
  ],
  theme: {
    extend: {
      colors: {
        'primary': {
          50: '#f0f9ff',
          100: '#e0f2fe',
          // ... weitere Abstufungen
          900: '#0c4a6e',
        }
      },
      fontFamily: {
        sans: ['Inter var', 'sans-serif'],
      }
    }
  },
  plugins: [
    require('@tailwindcss/typography'),
  ],
} satisfies Config

5. CSS-Direktiven

In deiner assets/css/tailwind.css Datei sollten die folgenden Direktiven enthalten sein:

@tailwind base;
@tailwind components;
@tailwind utilities;

6. Entwicklung starten

Starte den Entwicklungsserver und überprüfe die Installation:

npm run dev
# oder
yarn dev

Öffne die Tailwind-Viewer unter http://localhost:3000/_tailwind/ um deine Konfiguration zu überprüfen.

Vom Utility-Chaos zum skalierbaren Design-System

Die Sorge ist verständlich: Führt ein Utility-First-Ansatz nicht zwangsläufig zu überladenen, unleserlichen HTML-Templates? Die Antwort ist ein klares Jein. Ohne Struktur kann das passieren. Mit der richtigen Strategie wird TailwindCSS jedoch zur Grundlage für ein robustes und skalierbares Design-System.

Ein solches System ist der Schlüssel für nachhaltige Projekte. Es sorgt dafür, dass das Design konsistent bleibt, auch wenn das Projekt wächst und neue Entwickler an Bord kommen. Änderungen sind zentral an einer Stelle möglich, statt an hunderten von Stellen im Code.

Lass uns ansehen, wie du das mit TailwindCSS in Nuxt 3 praktisch umsetzt. Die Strategie ruht auf zwei Säulen.

1. Die tailwind.config.ts als dein Fundament

Betrachte die tailwind.config.js als die "Single Source of Truth" für dein Design. Hier definierst du alle grundlegenden visuellen Aspekte deiner Anwendung – die sogenannten Design-Tokens.

Anstatt hartkodierte Werte wie #3b82f6 im Code zu verstreuen, gibst du ihnen einen semantischen Namen. Das macht deine Absicht klarer und die Wartung zum Kinderspiel.

Schau dir diese erweiterte Konfiguration an:

// tailwind.config.ts
import type { Config } from 'tailwindcss'
import defaultTheme from 'tailwindcss/defaultTheme'

export default {
  content: [
    // ... deine Content-Pfade
  ],
  theme: {
    extend: {
      colors: {
        'primary': {
          '50': '#eff6ff',
          '100': '#dbeafe',
          '200': '#bfdbfe',
          '300': '#93c5fd',
          '400': '#60a5fa',
          '500': '#3b82f6', // Brand-Blau
          '600': '#2563eb',
          '700': '#1d4ed8',
          '800': '#1e40af',
          '900': '#1e3a8a',
          '950': '#172554',
        },
        'accent': {
            '500': '#f59e0b' // Ein Akzent-Gelb
        }
      },
      fontFamily: {
        sans: ['Inter var', ...defaultTheme.fontFamily.sans],
      },
      spacing: {
        '128': '32rem', // Eigene Abstands-Einheit
      }
    }
  },
  plugins: [
    require('@tailwindcss/typography'),
  ],
} satisfies Config

Jetzt verwendest du im Code nicht mehr text-blue-500, sondern text-primary-500. Wenn sich deine Markenfarbe ändert, musst du sie nur an einer einzigen Stelle in der Konfiguration anpassen. Alle Vorkommen werden automatisch aktualisiert.

2. Vue-Komponenten als wiederverwendbare Bausteine

Nachdem du die Design-Tokens als Fundament gelegt hast, kommt die zweite Säule: Abstraktion durch Komponenten. Statt lange und sich wiederholende Klassenlisten im Markup zu verwenden, kapselst du sie in wiederverwendbaren Vue-Komponenten.

Nehmen wir das Beispiel eines einfachen Buttons. Ohne Komponente könnte dein Code so aussehen:

<!-- Überall in deiner Anwendung verstreut -->
<button class="inline-flex items-center justify-center rounded-md px-4 py-2 text-base font-medium text-white transition-colors bg-primary-600 hover:bg-primary-700 focus:outline-none focus:ring-2 focus:ring-primary-500 focus:ring-offset-2">
  Aktion ausführen
</button>

Das ist nicht nur unübersichtlich, sondern auch ein Albtraum bei Änderungen.

Die Lösung ist, eine Button.vue-Komponente zu erstellen, wie sie im nächsten Abschnitt detailliert beschrieben wird. Die Verwendung reduziert sich dann auf eine saubere, lesbare Zeile:

<Button variant="primary">Aktion ausführen</Button>

Der Mehrwert ist enorm:

• Lesbarkeit: Der Code drückt die Absicht aus, nicht die Implementierungsdetails.
• Wartbarkeit: Das Button-Styling wird nur noch in der Button.vue geändert.
• Konsistenz: Alle Buttons sehen garantiert gleich aus.

Wenn du diese beiden Prinzipien – eine zentrale Konfiguration für die Design-Tokens und die Kapselung von UI-Logik in Komponenten – konsequent anwendest, baust du ein System, das mit deinem Projekt wachsen kann. Es bleibt wartbar, konsistent und macht die Einarbeitung für neue Teammitglieder deutlich einfacher.

Best Practices für Komponenten

1. Komponenten-Struktur

Hier ein Beispiel für eine optimierte Button-Komponente mit TailwindCSS:

<!-- components/Button.vue -->
<script setup lang="ts">
interface Props {
  variant?: 'primary' | 'secondary' | 'outline'
  size?: 'sm' | 'md' | 'lg'
}

const props = withDefaults(defineProps<Props>(), {
  variant: 'primary',
  size: 'md'
})

const buttonClasses = computed(() => {
  const baseClasses = 'inline-flex items-center justify-center rounded-md font-medium transition-colors focus:outline-none focus:ring-2 focus:ring-offset-2'
  
  const variants = {
    primary: 'bg-primary-600 text-white hover:bg-primary-700 focus:ring-primary-500',
    secondary: 'bg-gray-100 text-gray-900 hover:bg-gray-200 focus:ring-gray-500',
    outline: 'border border-gray-300 bg-white text-gray-700 hover:bg-gray-50 focus:ring-primary-500'
  }
  
  const sizes = {
    sm: 'px-3 py-1.5 text-sm',
    md: 'px-4 py-2 text-base',
    lg: 'px-6 py-3 text-lg'
  }
  
  return `${baseClasses} ${variants[props.variant]} ${sizes[props.size]}`
})
</script>

<template>
  <button :class="buttonClasses">
    <slot />
  </button>
</template>

2. Dark Mode Support

TailwindCSS bietet eine elegante Lösung für die Implementierung eines Dark Modes in Nuxt 3-Anwendungen. Der Dark Mode kann entweder systemabhängig oder manuell gesteuert werden. Hier erklären wir beide Ansätze:

Verwendung in Komponenten

Um den Dark Mode in deinen Komponenten zu nutzen, kannst du die dark: Variante von Tailwind-Klassen verwenden. Hier ein Beispiel für eine Karte-Komponente:

<template>
  <div class="bg-white dark:bg-gray-800 text-gray-900 dark:text-gray-100 p-4 rounded-lg shadow">
    <h2 class="text-xl font-bold mb-2">Titel</h2>
    <p class="text-gray-600 dark:text-gray-300">
      Dieser Text passt sich automatisch dem Dark Mode an.
    </p>
  </div>
</template>

Best Practices für Dark Mode

1. Konsistente Farbpalette

   • Definiere eine klare Farbpalette für beide Modi
   • Nutze semantische Farbnamen (z.B. primary, secondary)
   • Berücksichtige Kontrastverhältnisse

2. Performance

   • Vermeide unnötige Reflows beim Theme-Wechsel
   • Nutze CSS-Variablen für dynamische Werte
   • Implementiere Smooth Transitions

3. Zugänglichkeit

   • Stelle sicher, dass der Kontrast in beiden Modi ausreichend ist
   • Teste die Lesbarkeit aller Texte
   • Berücksichtige Farbenblindheit

4. Persistenz

   • Speichere die Benutzerpräferenz
   • Respektiere System-Einstellungen als Fallback
   • Implementiere einen sanften Übergang

In diesem Fall wird der Dark Mode automatisch aktiviert, wenn das Betriebssystem im Dark Mode ist.

Performance-Optimierungen für TailwindCSS in Nuxt 3

TailwindCSS ist nicht nur flexibel, sondern auch leistungsstark – aber ohne Optimierungen kann es deine Bundle-Größe aufblasen. Nuxt 3 und Tailwind bieten hier smarte Features, die du nutzen solltest, um Ladezeiten zu minimieren und die App flüssig zu halten.

1. PurgeCSS und Just-in-Time (JIT) Mode

Der JIT-Compiler von Tailwind generiert CSS nur für die Klassen, die du tatsächlich verwendest. In Nuxt 3 ist das standardmäßig aktiviert. Um es zu optimieren, stelle sicher, dass deine tailwind.config.ts alle relevanten Dateien im content-Array abdeckt:

// tailwind.config.ts
export default {
  content: [
    './components/**/*.{vue,js,ts}',
    './layouts/**/*.vue',
    './pages/**/*.vue',
    './plugins/**/*.{js,ts}',
    './nuxt.config.{js,ts}',
    './app.vue',
  ],
  // ...
}

Das reduziert ungenutztes CSS automatisch beim Build. Optional, für manuelle Tests oder Debugging:

npx tailwindcss -i assets/css/tailwind.css -o .output/public/_nuxt/tailwind.css --minify

2. Caching und Lazy Loading

In großen Projekten kann der Build-Prozess langsamer werden. Aktiviere Caching in Nuxt, indem du in nuxt.config.ts folgendes hinzufügst:

export default defineNuxtConfig({
  // ...
  nitro: {
    compressPublicAssets: true,
  },
})

Für dynamische Komponenten lade Tailwind-Styles lazy, z.B. mit Nuxt's <NuxtLazyHydrate>.

3. Bundle-Analyse

Verwende Tools wie

nuxt analyze

oder den Webpack Bundle Analyzer, um zu sehen, wie viel Tailwind zu deiner Bundle-Größe beiträgt. Ziel: Halte das finale CSS unter 10-20 KB.

Durch diese Maßnahmen sparst du Bandbreite und verbesserst die Core Web Vitals deiner App.

Häufige Fehler und wie du sie vermeidest

Selbst erfahrene Entwickler stolpern manchmal über Tailwind in Nuxt. Hier sind gängige Fallstricke und wie du sie umgehst:

1. Überladene Templates

Fehler: Zu viele Utility-Klassen direkt im HTML machen den Code unlesbar.

Lösung: Wie im Abschnitt zu Komponenten beschrieben, kapsle sie in Vue-Komponenten. Ergänze Props für Flexibilität, ohne den Markup zu komplizieren.

2. Inkonsistente Konfiguration

Fehler: Vergessene Pfade im content-Array führen dazu, dass Klassen nicht generiert werden.

Lösung: Überprüfe mit dem Tailwind-Viewer (/_tailwind/) und erweitere das Array bei Bedarf.

3. Performance-Probleme im Development

Fehler: Langsame Builds durch JIT in großen Projekten.

Lösung: Setze mode: 'jit' nur für Production und nutze tailwindcss --watch für schnelle Entwicklung.

4. Zugänglichkeitsfallen

Fehler: Vergessene Fokus-Styles oder unzureichender Kontrast.

Lösung: Integriere immer focus:-Varianten und teste mit Tools wie Lighthouse.

Indem du diese Fehler vermeidest, sparst du Zeit und Frust im Projektverlauf.

FAQ

Wie integriere ich TailwindCSS in ein bestehendes Nuxt 3-Projekt?

Die Integration von TailwindCSS in ein bestehendes Nuxt 3-Projekt ist einfach. Installieren Sie das offizielle Nuxt-Modul und konfigurieren Sie es in Ihrer nuxt.config.ts. Detaillierte Anweisungen finden Sie in der offiziellen Dokumentation.

Welche Performance-Optimierungen bietet TailwindCSS in Nuxt 3?

TailwindCSS in Nuxt 3 bietet Optimierungen wie PurgeCSS-Integration, JIT-Compiler, Caching und Bundle-Analyse. Diese Features reduzieren die Bundle-Größe und verbessern Ladezeiten. Mehr Details finden Sie im Abschnitt zu Performance-Optimierungen.

Wie erstelle ich ein skalierbares Design-System mit TailwindCSS in Nuxt 3?

Durch zentrale Konfiguration in tailwind.config.ts und wiederverwendbare Vue-Komponenten bauen Sie ein skalierbares System auf. Definieren Sie Design-Tokens und kapseln Sie Styles in Komponenten für Konsistenz und Wartbarkeit.

Welche Vorteile bietet die Kombination von TailwindCSS mit Nuxt 3?

Die Kombination bietet schnelle Entwicklung, optimierte Performance, konsistente Designs und hohe Wartbarkeit. Sie ermöglicht moderne, performante Webanwendungen mit Utility-First-Styling.

Wie implementiere ich Dark Mode in TailwindCSS mit Nuxt 3?

Aktivieren Sie Dark Mode in der tailwind.config.ts mit darkMode: 'class'. Verwenden Sie 'dark:'-Präfixe in Klassen und berücksichtigen Sie Best Practices für Konsistenz und Zugänglichkeit.

Welche häufigen Fehler sollte ich bei TailwindCSS in Nuxt 3 vermeiden?

Vermeiden Sie überladene Templates, inkonsistente Konfigurationen, Performance-Probleme und Zugänglichkeitsfallen. Kapseln Sie Styles in Komponenten und testen Sie regelmäßig.

{.object-cover .max-w-full .mb-5}

:::globalTitle{:size="lg" .mb-5} EKS vs. GKE – und warum ist das wichtig? ::: :::globalParagraph Laut dieser Statistik von Februar 2020 haben 540 Befragte auf die Frage "Welche der folgenden Container-Orchestratoren verwenden Sie?" geantwortet: ::: :::GlobalBlock{.ul-disk .mb-5}

• 37% aller Befragten verwenden EKS
• 21% der Befragten verwenden GKE ::: :::globalParagraph Bitte beachte, dass die Auswahl mehrerer Antworten möglich war, daher sind die Gruppen nicht exklusiv. Die Zahlen haben sich wahrscheinlich seitdem etwas geändert, aber es ist offensichtlich, dass diese beiden sehr beliebte Optionen in der Welt des verwalteten Kubernetes sind. Die Zahlen entsprechen auch der Verteilung der von Blueshoe verwalteten Kubernetes-Plattformen bis heute. ::: :::globalParagraph Natürlich sollten wir die Analyse der Container-Runtime-Leistung mit diesen beiden Lösungen beginnen. :::

:::globalTitle{:size="lg" .mb-5} Aber warum? ::: :::globalParagraph Einerseits ist es einfach interessant festzustellen, wie diese beiden großen Player im Vergleich zueinander abschneiden. Auf der einen Seite hast du Amazon Web Services - den Riesen auf dem Markt der Hyperscaler. Und auf der anderen Seite gibt es Google - den Technologieriesen und Pionier von Kubernetes{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} . ::: :::globalParagraph Aber noch wichtiger ist, dass es immer auf die Kosten ankommt. Wenn du bei vergleichbarem Preis 10% mehr Leistung bekommen kannst, möchten einige vielleicht die Portabilität von Kubernetes nutzen. Dabei geht es nicht um das Ökosystem oder potenziell angehängte Dienste (wie verwaltete Datenbanken oder Speicher), sondern um die reine Container-Runtime-Leistung. Ich wollte die Frage beantworten: "Mit welcher Geschwindigkeit läuft mein Code in einem ganz normalen Kubernetes-Cluster?". Und das ist, was ich gefunden habe: :::

:::globalTitle{:size="lg" .mb-5} Das Benchmark-Setup ::: :::globalParagraph Auf EKS habe ich einen Kubernetes-Cluster mit folgenden Spezifikationen erstellt: ::: :::GlobalBlock{.ul-disk .mb-5}

• Instanztyp: t3.xlarge
• Region: eu-west-1
• K8s-Version: 1.23
• Betriebssystem: Amazon Linux 2
• Container-Runtime: Docker
• Node-VM-Preis: 0,1824 USD pro Stunde ::: :::globalParagraph Um diese Parameter so genau wie möglich anzupassen, habe ich einen Google Kubernetes Engine-Cluster mit folgenden Spezifikationen erstellt: ::: :::GlobalBlock{.ul-disk .mb-5}
• Instanztyp: e2-standard-4
• Region: europe-north1-a
• K8s-Version: 1.23.14-gke.401
• Betriebssystem: Container-Optimized OS mit containerd (cos_containerd)
• Container-Runtime: containerd
• Node-VM-Preis: 0,147552 USD pro Stunde ::: :::globalParagraph Beide Maschinentypen umfassen eine 4 vCPU-Maschine mit 16 GB RAM, basierend auf einem Intel-Prozessor. Der Kubernetes-Knoten, auf dem der Test ausgeführt wurde, war ausschließlich dem Test-Pod gewidmet und nur mit anderen "Standard"-Pods dieses verwalteten Kubernetes-Angebots gefüllt. Ich habe keine speziellen Konfigurationen verwendet, sondern einfach einen Cluster mit den voreingestellten Werten bestellt. :::

:::globalTitle{:size="lg" .mb-5} Wie man die Container-Runtime benchmarkt ::: :::globalParagraph Eines der Hauptziele bei der Durchführung einer Leistungsanalyse besteht darin, eine sehr einfache Reproduktion zu ermöglichen. Glücklicherweise sprechen wir über Kubernetes, was bedeutet, dass es nur eine Frage des Schreibens von Kubernetes-Konfigurationen und deren Anwendung auf den Cluster ist. Dennoch gibt es einige wichtige Dinge zu beachten: ::: :::GlobalBlock{.ul-disk .mb-5}

• Wähle vergleichbare Kubernetes-Knoteninstanztypen, um den Vergleich so fair wie möglich zu gestalten
• Deploye die Benchmark-Workload nicht neben anderen Containern
• Verwende die gleiche Kubernetes-Version
• Notiere wichtige Unterschiede zwischen den Teilnehmern ::: :::globalParagraph Leider war es nicht gerade einfach, ein gutes Benchmark-Tool zu finden, das den Anforderungen entspricht, um die folgenden Teile zu benchmarken: ::: :::GlobalBlock{.ul-disk .mb-5}
• die CPU
• den Arbeitsspeicher (RAM)
• das Container-Dateisystem (nicht die angehängten Volumes, es geht um das native Dateisystem) :::

:::globalParagraph Ein recht häufig verwendetes Tool mit nur wenigen bekannten Schwächen ist sysbench. Mit etwa 5.000 Sternen auf GitHub und einer recht großen und aktiven Community könnte es für meine Anforderungen geeignet sein. Ein großer Pluspunkt ist die Erweiterbarkeit und die vielen integrierten komplexen Benchmark-Typen, wie z.B. Datenbank-Benchmarks usw. ::: :::globalParagraph Glücklicherweise hat jemand bei Severalnines bereits ein Container-Image für sysbench erstellt und es öffentlich zugänglich gemacht. Das Benchmark-Tool ist also einsatzbereit. ::: :::globalParagraph Um diesen Prozess zu vereinfachen und reproduzierbar zu machen, habe ich einen kleinen Test-Runner für sysbench gestartet. Dieses Tool plant das Benchmark im Cluster (mit einem Node-Selector), wartet auf den Abschluss des Jobs, analysiert das Ergebnis und erstellt eine Datei mit den Testergebnissen. ::: :::globalParagraph Ich habe den Code hier öffentlich gemacht. Er basiert auf Python und Poetry. Wenn du Poetry installiert hast, kannst du einfach 'poetry run benchmark' ausführen und es wird die Kapazität der CPU, des Arbeitsspeichers und des Dateisystems benchmarken. :::

:::GlobalPodcastSection{:videoId="tyvE9VlSWkE" :videoPosition="left" .mb-6} ::::GlobalPreTitle{:color="text-bs-green" .mb-3} UNSER KUBERNETES-PODCAST :::: ::::GlobalTitle{:tag="h3" .mb-6} TftC E1: Kubernetes-Entwicklungsumgebungen :::: ::::globalParagraph{:font-size="lg" .mb-4} Michael und Robert sprechen ausführlich über die Vor- und Nachteile der lokalen Kubernetes-Entwicklung und geben auch einige echte Codebeispiele. :::: ::::globalParagraph{:font-size="lg" } Weitere Ausgaben unseres Podcasts findest du hier: :::: ::::GlobalButton{:url="/kubernetes-podcast/" :label="Mehr anzeigen" :color="green"} :::: :::

:::globalTitle{:size="lg" .mb-5} Die Ergebnisse ::: :::globalParagraph Zusammenfassend lässt sich sagen, dass EKS in allen Metriken eine höhere Leistung bietet. Insbesondere die Datei-E/A-Leistung bei GKE ist ehrlich gesagt schlecht. Wir sprechen über 10% weniger Leistung bei der CPU, 9% weniger beim Arbeitsspeicher und eine große Lücke bei den Dateioperationen für einen Standard-Kubernetes-Cluster. Schauen wir uns die Ergebnisse genauer an. :::

:::globalTitle{:size="md" .mb-5} CPU-Leistung ::: :::globalParagraph Der sysbench-Befehl zum Ausführen des CPU-Tests lautet: sysbench --test=cpu --time=60 run ::: :::globalParagraph Dieser Befehl führt den CPU-Benchmark eine Minute lang aus. :::

:::globalTitle{:size="md" .mb-5} 1) GKE vs. EKS: CPU-Ereignisse pro Sekunde ::: :::globalParagraph Sysbench erfasst die ausgeführten Schleifen (auch Ereignisse genannt) und berechnet alle Primzahlen bis zu einem bestimmten Parameter in einem bestimmten Zeitrahmen. Es zeigt an, wie viel CPU-Zeit dem Prozess gewährt wurde und wie schnell die Berechnung im Allgemeinen war. ::: {.object-cover .w-max-full .mb-5} :::globalParagraph Das Ergebnis zeigt einen schockierenden Unterschied von etwa 11% mehr Ereignissen auf EKS im Vergleich zu GKE. Da du für die Zeit deines Kubernetes-Knotens bezahlst, ist es entscheidend, dass in dieser Zeit möglichst viele Berechnungen durchgeführt werden. :::

:::globalTitle{:size="md" .mb-5} 2) GKE vs. EKS: CPU-Latenz ::: :::globalParagraph Sysbench erfasst die CPU-Latenz für ein angefordertes Ereignis. Es aggregiert die Ergebnisse und gibt die minimalen, maximalen, durchschnittlichen und 95. Perzentil-Werte zurück. ::: {.object-cover .w-max-full .mb-5}

:::globalParagraph Wie du sehen kannst, ist die Leistung des containerd-basierten Runtimes von GKE nicht signifikant langsamer als der docker-basierte Runtime von EKS. Dennoch beträgt der Unterschied im 95. Perzentil etwa 2%. Dies kann auf die relativ kurze Laufzeit des Benchmarks und andere Faktoren zurückzuführen sein. :::

:::globalTitle{:size="md" .mb-5} Speicherleistung ::: :::globalParagraph Der sysbench-Befehl zum Ausführen des Speichertests (RAM) lautet: sysbench --test=memory --memory-total-size=500G run ::: :::globalParagraph Dieser Befehl schreibt 500 Gigabyte in den Hauptspeicher und erfasst die Schreibgeschwindigkeit. ::: {.object-cover .w-max-full .mb-5}

:::globalParagraph Auch hier ist GKE etwa 9% langsamer als der Container-Runtime von EKS, wenn es darum geht, viel in den Hauptspeicher zu schreiben. Auf einem EKS-Cluster kann dein Code potenziell mit 4,25 Gigabyte pro Sekunde in den RAM schreiben, während auf GKE dein Container nur mit 3,87 Gigabyte pro Sekunde schaufeln kann. Im Vergleich dazu läuft mein Laptop mit etwa 6,36 Gigabyte pro Sekunde. Daher ist keines der Ergebnisse überwältigend. :::

:::globalTitle{:size="md" .mb-5} GKE vs EKS: Datei-E/A-Leistung ::: :::globalParagraph Die Ergebnisse zur Dateisystemleistung zeichnen ein besonders dramatisches Bild. Der sysbench-Befehl zum Ausführen des Dateitests lautet: :::

:::GlobalBlock{.ul-disk .mb-5}

• sysbench --test=fileio --file-num=5 --file-total-size=5G prepare
• sysbench --test=fileio --file-total-size=5G --file-num=5 --file-test-mode=rndrw --time=100 --max-requests=0 run :::

:::globalTitle{:size="md" .mb-5} 1) GKE vs EKS: Dateidurchsatz ::: :::globalParagraph Der Dateidurchsatz-Benchmark schreibt einfach eine Datei in das Dateisystem und liest eine künstliche Datei aus dem Dateisystem. ::: {.object-cover .w-max-full .mb-5}

:::globalParagraph Die Schreib- und Leseleistung eines Containers, der auf EKS läuft, ist bei Lesevorgängen etwa 95% besser und bei Schreibvorgängen etwa 94% besser. Diese Metrik könnte relevant werden, wenn eine Anwendung Dateien aus dem temporären Speicher im Container schreibt und liest. :::

:::globalTitle{:size="md" .mb-5} 2) Datei-E/A-Latenz ::: {.object-cover .w-max-full .mb-5}

:::globalParagraph Die Dateilatenz ist für beide Plattformen nahezu gleich. Persönlich würde ich der maximalen Latenz nicht allzu viel Bedeutung beimessen (diese kann von Lauf zu Lauf stark variieren), sondern eher das 95. Perzentil betrachten. Mit dieser Metrik übertrifft EKS GKE um eine Größenordnung. :::

:::globalTitle{:size="md" .mb-5} 3) Dateioperationen pro Sekunde ::: {.object-cover .w-max-full .mb-5}

:::globalParagraph Die geringe Anzahl von Dateioperationen pro Sekunde auf GKE ist nur eine Folge der vorherigen Ergebnisse. Bitte beachte, dass diese Bewertungen zur Dateisystemleistung auf dem nativen Dateisystem des Containers ausgeführt werden. Es ist keine zusätzliche Storage Class an den Pod angehängt, auf dem der Benchmark läuft. :::

:::globalTitle{:size="lg" .mb-5} Abschließende Bemerkungen :::

:::globalParagraph Ich war etwas schockiert über die Ergebnisse nach dem Vergleich dieser beiden verwalteten Kubernetes-Plattformen und ihrer Container-Runtime-Leistung. Wie du sehen kannst, ist der Preis des GKE-Knotens in diesen Regionen etwa 22% niedriger als der entsprechende Preis bei AWS EKS. Das gleicht zumindest ein wenig den Unterschied in der Leistung aus, aber diese Fakten können die Entscheidung beeinflussen, wo eine containerisierte Workload in Zukunft platziert werden soll. ::: :::globalParagraph Beim Versuch, die Ergebnisse zu verstehen, stieß ich auf das Nitro-System von Amazon, eine Hardware-Technologie, die Amazon Web Service für ihre eigene Cloud-Computing-Plattform entwickelt hat. Sind diese Ergebnisse ein Beweis für die versprochenen Leistungsgewinne? Spielt der docker-basierte Container-Runtime von AWS dabei eine Rolle? ::: :::globalParagraph Bei Blueshoe arbeiten wir gerne mit der Google Cloud Platform, da wir sie im Allgemeinen als benutzerfreundlicher und übersichtlicher im Vergleich zur AWS-Konsole betrachten. Leistungsüberlegungen sind in der Tat sehr wichtig, aber es gibt auch andere wesentliche Kriterien bei der Auswahl eines verwalteten Kubernetes-Angebots. Bitte nimm diesen Benchmark auch mit einer Prise Salz, da es viele Konfigurationen gibt, die einen großen Einfluss auf die Gesamtsystemleistung haben können. ::: :::globalParagraph Fühle dich frei, folge mir auf LinkedIn oder trete unserem Discord bei. :::

{.object-cover .max-w-full .mb-5}

:::globalTitle{:size="lg" .mb-5} WARUM SETZT BLUESHOE AUF DJANGO? ::: :::globalParagraph In vielen unserer Projekte setzen wir Django ein. Insbesondere, wenn wir uns einem neuen, potentiellen Kunden vorstellen, fragt dieser: „Warum setzt Blueshoe{.bs-link-blue} auf Django? Ihre Mitbewerber setzen vorrangig auf PHP Systeme wie Wordpress, Drupal bzw. Magento, Shopware oder WooCommerce.“ ::: :::globalParagraph An dieser Stelle muss ich sagen, dass der Vergleich zwischen PHP-Systemen, wie den oben genannten, und Django nicht ganz fair ist. ::: :::globalParagraph PHP ist eine Programmiersprache, Django ein Web Framework, Wordpress und Drupal sind CMS Systeme, Magento und WooCommerce sind E-Commerce-Systeme. :::

:::globalTitle{:size="lg" .mb-5} PHP IST EINE KRUX ::: :::globalParagraph PHP ist eine Programmiersprache mit weiter Verbreitung. Es gibt viele Quellen und viele Projekte. Jedoch entfernt sich die moderne Welt der Webentwicklung langsam aber sicher von PHP: ::: :::globalParagraph Suchanfragen für PHP: :::

{.object-cover .max-w-full .mb-5}

:::globalParagraph Suchanfragen für das weit verbreitete Zend Framework (PHP basiert): :::

{.object-cover .max-w-full .mb-5}

:::globalParagraph Jeff Atwood beschreibt PHP in seinem Artikel „The PHP Singularity“[1]: „PHP isn't so much a language as a random collection of arbitrary stuff, a virtual explosion at the keyword and function factory.“ ::: :::globalParagraph Folgt man Jeff Atwood’s Artikel, wird schnell klar: PHP ist eine schrecklich schlecht designte Programmiersprache. Warum gibt es dann so viele Projekte, welche auf PHP basieren? Dafür könnte es folgende Gründe geben: ::: :::GlobalBlock{.ul-disk .mb-5}

• PHP war frühzeitig (PHP 1 erschien 1995)[2] eine Möglichkeit serverseitige Logik zu implementieren.
• PHP ist billig. Nahezu jeder Webspace-Anbieter erlaubt es PHP auszuführen. Das Deployment ist simpel, simpler geht es nicht. Einfach die Dateien auf den Server laden und schon läuft’s.
• Aufgrund der früh wachsenden Nachfrage sind natürlich viele Jobs im PHP Umfeld entstanden, was zur Folge hat, dass auch mehr Projekte in PHP umgesetzt werden ::: :::globalParagraph Systeme, die auf dieser Basis aufsetzen, sind auf den ersten Blick billig und einfach zu handhaben. Genauso einfach läuft aber auch das Boot aus dem Ruder: Sicherheitslücken, schlechte Wartbarkeit, schlechte Code Qualität[3]. Schlechte Wartbarkeit ist bekanntlich teuer, da die Einarbeitungszeit in vorhandenen Code für Entwickler in der Regel höher ist oder weil der Entwickler eine so spezielle Kenntnis von dem System hat, dass er mit der Zeit immer mehr Geld verlangen kann. Eine Abhängigkeit des Auftraggebers, ein „Vendor lock-in“, entsteht. :::

:::globalTitle{:size="lg" .mb-5} PYTHON ALS FUNDAMENT ::: :::globalParagraph Saubere Strukturen, eine gute Code-Qualität sowie eine entsprechend leichtgewichtige Wartbarkeit liegen in der Natur von Python. Im Gegensatz zu anderen Programmiersprachen bildet Python seine Struktur durch Einrückung ab. Dies zwingt den Entwickler nicht nur, eine konstante Struktur bei der Einrückung und Strukturierung seines Codes zu verwenden, sondern macht es wesentlich einfacher für andere Entwickler, sich in ein Projekt einzulesen. ::: :::globalParagraph Ein kurzes Beispiel: ::: :::globalTitle{:size="md" .mb-5} PHP ::: :::BlogCode{.mb-5}

for ($i = 1; $i < 10; $i++) {
  if $($i % 2 == 0) {
    echo $I;
  }
}

::: :::globalTitle{:size="md" .mb-5} Python ::: :::BlogCode{.mb-5}

for i in range(0, 10, 2):
   print i

::: :::globalParagraph Natürlich repräsentiert dieses Beispiel keinen umfassenden Vergleich beider Sprachen. Es soll lediglich eine grobe Vorstellung über die Lesbarkeit beider Sprachen vermitteln. ::: :::globalParagraph Weiterhin gibt es mit PEP8[4] eine klare Richtlinie, wie Python Code zu formatieren ist. Unsere Entwicklungsumgebungen bei Blueshoe sind so konfiguriert, dass diese auf Konformität zu PEP8 prüfen. ::: :::globalParagraph Schön und gut, wir haben nun gezeigt, dass Python seinen Entwickler zu einer gewissen Strukturierung „erzieht“. Aber können professionelle PHP Entwickler dies nicht auch? ::: :::globalParagraph Natürlich gibt es auch PHP Entwickler, welche es schaffen, ihren Code sauber zu strukturieren und lesbar zu halten. In der Praxis sieht man heute leider noch viel zu oft sogenannten Spaghetti Code, wenn man durch PHP Projekte schaut. Python sollte somit auf langfristige Sicht nicht teurer als PHP sein, da die Wartungskosten in der Regel gering gehalten werden können. :::

:::globalTitle{:size="lg" .mb-5} DJANGO – DAS GERÜST UNSERER WEBANWENDUNG ::: :::globalParagraph Warum genau setzt Blueshoe nun auf Django und was genau ist Django eigentlich? ::: :::globalParagraph Django ist ein Framework zur Entwicklung von Webanwendungen. Damit gibt Django einen gewissen Workflow vor – eine Struktur in der Entwicklung von Webanwendungen. Hält man diese ein, fällt es wiederum neuen Entwicklern leicht, sich in den Code eines neuen Projektes einzulesen. Dies hat nicht nur zur Folge, dass das Projekt besser strukturiert und organisiert ist, sondern auch Zeit eingespart wird, was sich sich wiederum in den Kosten widerspiegelt. ::: :::globalParagraph Django bringt von Haus aus verschiedene Sicherheitsmechanismen mit, welche standardmäßig Pflicht bei der Implementierung sind. Beispielsweise Cross-Site Request Forgery (CSRF) wird durch den Einsatz von CSRF-Token unterbunden. Cross-Site Scripting wird ebenfalls von Haus aus von der Django-Template Engine unterbunden. Ein Entwickler muss sich aktiv gegen diesen Schutz für eine Variable entscheiden, um diesen Schutz zu deaktivieren. Unter anderen Angriffsvektoren, welche Django so klein wie nur möglich hält, ist auch SQL Injection. Das Open Web Application Security Project (OWASP) kategorisierte SQL Injection 2013 als Nummer 1 Schwachstelle oder auch den potenziell größten Angriffsvektor.[5] ::: :::globalParagraph Django bezeichnet sich selbst als „The web framework for perfectionists with deadlines“[6]. Das Entwicklungs-Team um Django hat sich grundlegende Philosophien für die Entwicklung des Frameworks festgelegt[7]. Diese sind natürlich keine Neuerfindung in der IT-Welt, sondern gelten auch für andere Projekte und Softwaresysteme. Es ist jedoch bemerkenswert, wie strikt diese im Django-Projekt verfolgt und eingehalten werden. Dies wird von der Community sehr gut angenommen und liegt uns bei Blueshoe sehr am Herzen. Die Folgen sind der Traum eines jeden Auftraggebers (von Software): ::: :::GlobalBlock{.ul-disk .mb-5}

• Wiederverwendbare Komponenten = weniger Zeit, geringere Kosten
• Einfache Erweiterbarkeit des Systems = Projekt als Grundlage für Weiterentwicklung
• Einfachheit, Lesbarkeit = Keine Abhängigkeit vom Auftragnehmer
• Up to date Sicherheitsmechanismen (für Webanwendungen) ::: :::globalParagraph Gut, Django ist sicher, es ist sehr strukturiert, hat eine sehr gute Wartbarkeit und erlaubt es, in kurzer Zeit viel Funktionalität umzusetzen. Aber wer setzt auf Django? Gibt es Beispiele bekannter Webseiten, welche auf Python/Django setzen? :::

:::globalParagraph Wer setzt sonst noch auf Python/Django? ::: :::globalParagraph Es gibt zahlreiche, darunter sehr bekannte, Webseiten die Python/Django einsetzen. Ein paar hier: :::

{.object-cover .max-w-full .mb-5}

:::globalTitle{:size="md" :tag="h3" .mb-5} Dropbox: ::: :::globalParagraph Viele Instanzen in der Dropbox-Infrastruktur führen Python-Code aus. Der hauptsächliche Grund für Dropbox war die schnelle Entwicklung ihrer Features, welche Python ermöglichte. :::

:::globalTitle{:size="md" :tag="h3" .mb-5} YouTube[8]: ::: :::globalParagraph 2009 sprengte YouTube die Grenze von einer Milliarde Views pro Tag. YouTube setzt auf einen Application Server, welcher in Python geschrieben wurde. Um verschiedenen Auslastungen gerecht zu werden, kann YouTube einfach Maschinen hinzu- bzw. abschalten. Python ist bei hoher Auslastung der YouTube-Infrastruktur in der Regel nicht das Bottleneck. YouTube setzt Python außerdem vor allem wegen seiner Möglichkeiten zur schnellen und flexiblen Entwicklung ein. :::

:::globalTitle{:size="md" :tag="h3" .mb-5} Pinterest[9]: ::: :::globalParagraph Pinterest zahlt in Hochzeiten 52$ pro Stunde für ihre Server. Der meiste Traffic kommt dabei nachmittags und abends. Über Nacht kann die Gesamtanzahl der Instanzen auf 40% reduziert werden, was in einer Kostenreduktion bis auf 15$ pro Stunde resultieren kann. Hauptsächlich werden zum Ausliefern der Inhalte Django und Tornado (ein Python-Web-Framework und Asynchronous Network Library)[10] eingesetzt. :::

:::globalTitle{:size="md" :tag="h3" .mb-5} Spotify[11]: ::: :::globalParagraph Spotifys Backend besteht aus vielen unterschiedlichen Services. 80% dieser Dienste sind in Python geschrieben. Einer der wesentlichen Gründe für Spotify ist die schnelle Entwicklung, die Python mit sich bringt. Für die Abarbeitung asynchroner Tasks sowie (ca. 90% der) Map-Reduce Tasks in Spotify’s Hadoop Cluster wird Python hergenommen. :::

:::globalTitle{:size="md" :tag="h3" .mb-5} Instagram[12]: ::: :::globalParagraph Mit mehreren Millionen Requests pro Sekunde zeigt Instagram erfolgreich, wie perfekt Django zum Bauen von Web-Applications ist. Die Gesamtarchitektur ist natürlich komplex, Kern der Instagram Server ist jedoch Django als Application Server. :::

:::globalTitle{:size="md" :tag="h3" .mb-5} Disqus[13]: ::: :::globalParagraph Disqus wird auf zahlreichen Webseiten als Kommentar-Plugin verwendet. Mit (Stand 2013) 45.000 Anfragen pro Sekunde ist Disqus eine Webanwendung, welche extrem skaliert. Django wird fast ausschließlich für die Bearbeitung aller Anfragen auf Disqus verwendet. Natürlich kommen hier Technologien zum Einsatz, welche „Django das Leben erleichtern“ (z.B. Caches). Trotzdem gilt auch hier: Ein solides Fundament (wie beispielsweise Django) wird gebraucht, um stabile, sichere und skalierbare Webanwendungen zu entwickeln. :::

:::globalTitle{:size="lg" .mb-5} BLUESHOE <3 PYTHON/DJANGO ::: :::globalParagraph Python und Django haben aktive Communities, sie werden ständig weiterentwickelt und erlauben es uns, in kurzer Zeit hochqualitative Software zu schreiben. Deshalb lieben wir Python und Django. Kürzere Umsetzungszeiten bei Change Requests , hohe Sicherheitsstandards und geringe Kosten bei der Wartung/Pflege, diese Dinge lieben unsere Kunden. Es ist uns bei Blueshoe wichtig, dass unsere Kunden und Partner verstehen, warum wir diese Technologie als Grundlage vieler Projekte für uns gewählt haben. ::: :::globalParagraph Lange Rede, kurzer Sinn: Python/Django sind grandiose Fundamente für unterschiedlichste Projekte. Wir setzen darauf und unsere Erfahrungen sprechen für sich. Täglich erwarten uns neue Herausforderungen und wir wurden niemals von Django enttäuscht. Es trifft einfach den Kern unserer Mentalität: Auch wir sind Perfektionisten mit Deadlines. ::: :::globalParagraph Es gibt übrigens auch ein wundervolles Content Management System, dass auf Django basiert: :::

:::globalParagraph [1]http://blog.codinghorror.com/the-php-singularity/{.bs-link-blue :target="_blank"}

[2]http://php.net/manual/de/history.php.php{.bs-link-blue :target="_blank"}

[3]https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/#stance{.bs-link-blue :target="_blank"}

[4]https://www.python.org/dev/peps/pep-0008{.bs-link-blue :target="_blank"}

[5]https://www.owasp.org/index.php/Top_10_2013-Top_10{.bs-link-blue :target="_blank"}

[6]https://www.djangoproject.com/{.bs-link-blue :target="_blank"}

[7]https://docs.djangoproject.com/en/stable/misc/design-philosophies/{.bs-link-blue :target="_blank"}

[8]http://highscalability.com/youtube-architecture{.bs-link-blue :target="_blank"}

[9]http://highscalability.com/blog/2012/5/21/pinterest-architecture-update-18-million-visitors-10x-growth.html{.bs-link-blue :target="_blank"}

[10]http://www.tornadoweb.org/en/stable/{.bs-link-blue :target="_blank"}

[11]https://labs.spotify.com/2013/03/20/how-we-use-python-at-spotify/{.bs-link-blue :target="_blank"}

[12]http://instagram-engineering.tumblr.com/post/13649370142/what-powers-instagram-hundreds-of-instances{.bs-link-blue :target="_blank"}

[13]http://blog.disqus.com/post/62187806135/scaling-django-to-8-billion-page-views{.bs-link-blue :target="_blank"} :::

{.object-cover .max-w-full .mb-5}

Natürlich sind Zeitschätzungen nie 100% exakt. Projekte bringen oft unerwartete Herausforderungen mit sich: technische Hürden, fehlende Infos oder sich ändernde Anforderungen. Deshalb planen wir immer einen Puffer mit ein. Dieser Puffer gibt uns den nötigen Spielraum, um flexibel auf solche Situationen zu reagieren, ohne den gesamten Zeitplan durcheinanderzubringen.

Wichtig ist, dass der Puffer weder zu knapp noch zu großzügig bemessen ist. Er basiert auf Erfahrung und der Komplexität der jeweiligen Aufgabe. Und genauso wichtig: Wir kommunizieren transparent, wie sich die Zeitschätzung zusammensetzt – inklusive Puffer. So wissen alle Beteiligten jederzeit, woran sie sind und können besser planen.

Bei Blueshoe setzen wir deshalb auf einen klaren, strukturierten Workflow, mit dem wir Zeitschätzungen direkt im Ticketsystem erfassen und nachvollziehbar machen. In diesem Artikel geben wir einen Einblick, wie wir das genau machen und warum das für uns so gut funktioniert.

{.object-cover .max-w-full .mb-5}

Unser Zeitschätzungsprozess im Detail

Wenn ein Kunde mit einer neuen Anforderung oder einem Problem auf uns zukommt, das eine Zeitschätzung braucht, starten wir einen klar strukturierten Prozess. Unser Projektmanager legt dafür ein eigenes Zeitschätzungsticket als Unterticket zum Hauptticket an und weist es einem Entwickler zu. Im Team klären wir dann intern, welche Aufgaben anstehen, welche Voraussetzungen erfüllt sein müssen und ob es Abhängigkeiten gibt. Falls Fragen auftauchen, beziehen wir den Kunden natürlich direkt mit ein – so vermeiden wir Missverständnisse von Anfang an.

Der Entwickler, der das Ticket bekommt, ist verantwortlich für eine realistische und sorgfältige Einschätzung. Wenn nötig, holt er sich Unterstützung von Kollegen, damit die Schätzung so genau wie möglich wird. Damit wir immer auf Nummer sicher gehen, prüfen wir jede Zeitschätzung zusätzlich durch einen zweiten Entwickler.

{.object-cover .max-w-full .mb-5}

Am Ende bekommt der Kunde von uns eine transparente Übersicht mit der fertigen Zeitschätzung und der Aufteilung der einzelnen Aufgaben. So kann er ganz entspannt entscheiden, ob er die Schätzung freigibt oder ob noch offene Fragen geklärt werden müssen.

Wichtige Rahmenbedingungen für Zeitschätzungen

• Maximaler Zeitaufwand: Wir halten Zeitschätzungen möglichst schlank: Ideal ist, dass sie nicht mehr als 1–2 Stunden Aufwand bedeuten.
• Analysebudget: Sollte sich abzeichnen, dass eine Aufgabe komplexer ist und die Zeitschätzung mehr Zeit braucht, sprechen wir das frühzeitig mit dem Kunden ab und beantragen ein Analysebudget.
• Zweite Meinung: Außerdem setzen wir auf den Blick von zwei Entwicklern: Jede Zeitschätzung wird von einem zweiten Entwickler geprüft und bestätigt. So stellen wir sicher, dass unsere Einschätzungen realistisch und qualitativ hochwertig sind.

Struktur eines Zeitschätzungstickets

Das Zeitschätzungsticket folgt einer klaren Struktur:

• Aufgabenpakete und Schritte
  Eine Auflistung der Tasks 1-X, mit optionalen Notizen und detaillierten Beschreibungen.
• Annahmen und Voraussetzungen
  Welche Abhängigkeiten bestehen? Gibt es Voraussetzungen, die vom Kunden oder anderen Teams erfüllt sein müssen?
• Technische Limitierungen & Risiken
  Mögliche technische Herausforderungen oder Risiken, die den Aufwand beeinflussen können.
• Testaufwand
  Einschätzung des notwendigen Testaufwands.
• Puffer
  Der Projektmanager ergänzt den Zeitpuffer für Unvorhergesehenes.
• Confidence-Level
  Falls die Schätzung weniger als 100% sicher ist, werden die Unbekannten klar aufgelistet.

Fazit

Unser klar strukturierter Zeitschätzungs-Workflow sorgt dafür, dass alle Beteiligten jederzeit den Überblick behalten. Transparenz, realistische Planung und offene Kommunikation zwischen Kunden, Projektmanagement und Entwicklung sind für uns selbstverständlich. So können wir neue Anforderungen schnell und effizient einschätzen und umsetzen – zum Vorteil für alle.

Wenn du mehr über unsere Arbeitsweise wissen möchtest oder Unterstützung bei deinem Projekt brauchen, melde dich einfach bei uns! Wir freuen uns auf den Austausch.

{.object-cover .max-w-full .mb-5}

::GlobalTitle{:size="lg" .mb-4} Schneller Start von Python-Apps ::

::GlobalParagraph Warum benötigen wir überhaupt Applikationen, die schnell starten? Blueshoe ist hauptsächlich im Cloud-Entwicklungsbereich tätig. Unsere Applikationen tragen unterschiedliche Lasten zu unterschiedlichen Zeiten. Lastspitzen müssen schnell abgefangen werden, Services müssen skalieren. Wenn ein Service jedoch 10, 20 oder gar 30 Sekunden zum Starten braucht, kann dies fatal für Lastspitzen sein, da die Skalierung zu langsam geschieht. Dies gilt sowohl für klassische Kubernetes-Workloads{:target="_blank" .text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} als auch für den Einsatz von FaaS (Function-as-a-Service){:target="_blank" .text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid}. ::

::GlobalParagraph Ein weiterer wichtiger Aspekt ist die reine Entwicklungsarbeit. In der Regel starten Services in Debug-Setups oder Entwicklungsumgebungen noch langsamer als in Produktion. Wenn ich also meinen Service immer wieder neu starte und dabei warten muss, unterbrechen diese Wartezeiten den Arbeitsfluss und stören den Entwickler. ::

::GlobalParagraph Ebenso können lange Startzeiten ein Symptom von weiteren, zugrunde liegenden Problemen sein – beispielsweise Memory Leaks. ::

:::GlobalButton{:url="/technologien/python-django-agentur/" :label="Erfahre mehr über unsere Django-Entwicklungsdienste" :color="blue" .mb-6} :::

::GlobalTitle{:size="lg" .mb-5} Tools zur Analyse der Python-App Importzeit ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Pythons Bordmittel: -X importtime ::

::GlobalParagraph Tatsächlich bringt Python selbst schon ein wichtiges Mittel zur Analyse der Importzeiten mit: die Flag -X importtime. Startet man den Python-Interpreter seiner Applikation mit dieser Flag, wird eine Aufstellung über die verschiedenen Importzeiten der importierten Module ausgegeben: ::

::BlogCode{.mb-4}

...
import time:      1110 |       1569 | django.contrib.messages.storage.base
import time:       705 |        705 | django.contrib.admin.decorators
import time:      2103 |       2103 |       django.contrib.admin.utils
import time:      3080 |       5182 |     django.contrib.admin.helpers
import time:      3219 |       3219 |     django.contrib.admin.widgets
import time:      1862 |       1862 |     django.contrib.admin.checks
import time:       649 |        649 |     django.contrib.admin.exceptions
import time:       716 |        716 |       django.contrib.admin.templatetags
import time:      1328 |       2044 |     django.contrib.admin.templatetags.admin_urls
import time:       843 |        843 |     django.views.decorators.csrf
import time:      3891 |      17687 |   django.contrib.admin.options
import time:      1793 |      19479 | django.contrib.admin.filters
...

::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Visuelle Analyse ::

::GlobalParagraph Soweit so gut! Um das Ganze besser analysieren zu können, wird dieser Output in kmichel’s Importtime Graph{:target="_blank" .text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} eingefügt: ::

{.object-cover .max-w-full .mb-5 .mx-auto}

::GlobalParagraph So erhält man eine visuelle Repräsentation über die Dauer der Imports verschiedener Module. Jede Fläche steht für ein Modul, welches unter Umständen Subflächen enthält. Je größer eine Fläche, desto länger die Importzeit. ::

::GlobalTitle{:size="lg" .mb-5} Weitere Tools zur Analyse von Importzeiten ::

::GlobalParagraph Neben der -X importtime-Flag gibt es weitere nützliche Tools, die bei der Analyse und Optimierung der Startzeit helfen können: ::

::GlobalBlock{.ol-decimal .my-4}

1. Py-Spy:{:target="_blank" .text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} Ein leistungsstarker Profiler, der ohne Instrumentierung arbeitet. Py-Spy kann genutzt werden, um genau zu verstehen, wie viel Zeit während der Initialisierungsphase aufgewendet wird.
2. Scalene:{:target="_blank" .text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} Ein hochpräziser Profiler, der CPU- und Speicherverbrauch analysiert. Er eignet sich hervorragend, um teure Initialisierungen zu identifizieren.
3. cProfile:{:target="_blank" .text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} Ein in Python integrierter Profiler, der nicht nur während der Laufzeit, sondern auch während der Startzeit Einblicke liefert. Kombiniert mit pstats{:target="_blank" .text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} oder Tools wie snakeviz{:target="_blank" .text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} kann der Output visuell analysiert werden.
4. Modulegraph:{:target="_blank" .text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} Dieses Tool kann Abhängigkeiten zwischen Modulen visualisieren, um unnötige oder doppelte Imports leichter aufzuspüren. ::

::GlobalCallAnExpert{:bg="bg-bs-blue"} #buttonBlockTitle Wir können auch deine Python oder Django Apps optimieren. ::

::GlobalTitle{:size="lg" .mb-5} Tipps zur Optimierung der Importzeiten :: ::GlobalParagraph Nachdem nun klar ist, welche Python-Module genauer anzusehen sind, stellt sich die Frage: Was ist zu tun? Wie verkürze ich die Zeiten? Hierbei gehen wir bei Blueshoe wie folgt vor ::

::GlobalBlock{.ol-decimal .my-4}

1. Dead-Code: Wird der Code noch gebraucht? Falls nein – raus damit. Nicht verwendete Imports oder Module tragen unnötig zur Startzeit bei.
2. Externe Abhängigkeit überprüfen: Handelt es sich um eine externe Abhängigkeit? Falls ja, sollte geprüft werden, ob es eine neuere Version gibt, die optimiert ist. Gerade bei umfangreichen Bibliotheken wie Django oder NumPy werden regelmäßig Performance-Verbesserungen eingebaut.
3. Initialisierung überprüfen: Führt ein Modul bei der Initialisierung Code aus, der nicht zwingend notwendig ist? Dies könnte z. B. eine komplexe Konfigurationsprüfung oder initiale Datenbankabfragen umfassen. Solche Prozesse sollten möglichst spät in der Laufzeit erfolgen.
4. Import-Struktur verbessern: Gruppiere Imports logisch und überprüfe, ob sich einige Module zusammenfassen lassen, um redundante Abhängigkeiten zu reduzieren. Ein gutes Beispiel sind Utility-Module, die oft nur selektiv genutzt werden. ::

::GlobalParagraph Deine Python-App startet zu langsam? Reduziere die Startzeit mit Blueshoe: Zur Optimierung!{:target="_blank" .text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} ::

::GlobalTitle{:size="lg" .mb-5} Fazit ::

::GlobalParagraph Eine kurze Startzeit von Python-Applikationen ist essenziell – sei es für die reibungslose Skalierung in Cloud-Umgebungen oder für eine angenehme Entwicklererfahrung. Mit einfachen Mitteln wie -X importtime, weiteren Tools wie z. B. Py-Spy oder Scalene und einer strukturierten Herangehensweise lassen sich Importzeiten analysieren und optimieren. So sorgt man dafür, dass Applikationen schneller starten, effizienter arbeiten und insgesamt stabiler sind. ::

::GlobalParagraph Wie optimierst du die Startzeit deiner Python-Apps? Teile deine Erfahrungen und Tipps gerne in den Kommentaren! ::

:::GlobalTitle{:size="lg" .mb-5 .mt-8} Häufige Fragen :::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 1. Wie kann ich die Startzeit meiner Python App analysieren? ::

::GlobalParagraph Verwende das -X importtime-Flag von Python, um die Importzeiten deiner Module zu messen. Mit Tools wie kmichel’s Importtime Graph oder Py-Spy kannst du diese Daten visualisieren und Engpässe identifizieren. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 2. Welche Tools helfen, die Django App Startzeit zu optimieren? ::

::GlobalParagraph Einige der besten Tools sind: ::

::GlobalBlock{.ul-disk}

• Py-Spy für schnelle Analysen ohne Instrumentierung
• Scalene für detaillierte CPU- und Speicherprofile
• cProfile, das in Python integriert ist, für umfassende Laufzeitanalysen
• Modulegraph zur Visualisierung von Abhängigkeiten ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 3. Was sind die häufigsten Ursachen für lange Startzeiten bei Python Apps? ::

::GlobalBlock{.ul-disk .mb-5}

• Unnötige oder doppelte Imports
• Komplexe Initialisierungsvorgänge (z. B. Datenbankabfragen beim Start)
• Nicht genutzte Module oder Dead-Code
• Schlechte Organisation der Importstruktur ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 4.\ Wie kann ich die Startzeit meiner Django App in Kubernetes-Containern reduzieren? ::

::GlobalBlock{.ul-disk .mb-5}

• Optimiere die Importstruktur, um Ladezeiten zu minimieren.
• Nutze Lazy Initialization, um teure Prozesse erst bei Bedarf zu starten.
• Aktualisiere externe Bibliotheken auf schlankere Versionen. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 5. Warum ist eine kurze Startzeit für Python-Apps in der Cloud wichtig? ::

::GlobalParagraph{.mb-4} Schnelle Startzeiten ermöglichen eine effiziente Skalierung bei Lastspitzen, insbesondere in Kubernetes-Setups. Lange Startzeiten können die Skalierung verzögern und die Performance deiner Anwendungen negativ beeinflussen. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 6. Welche Rolle spielt die Startzeit von Python Apps beim horizontalen Pod-Autoscaling in Kubernetes? ::

::GlobalParagraph{.mb-4} Beim horizontalen Pod-Autoscaling (HPA) in Kubernetes{:target="_blank" .text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} werden zusätzliche Pods basierend auf der Last automatisch gestartet. Wenn die Python App Startzeit zu lang ist, können die neuen Pods die steigende Last nicht rechtzeitig bewältigen, was zu Verzögerungen und potenziellen Ausfällen führt. Optimierte Startzeiten sorgen für eine reibungslose Skalierung und bessere Verfügbarkeit. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 7. Kann die Optimierung der Python Startzeit die Entwicklungszeit reduzieren? ::

::GlobalParagraph{.mb-4} Ja, definitiv! In Entwicklungs- und Debug-Umgebungen sind Neustarts von Services häufig erforderlich. Kurze Python App Startzeiten bedeuten weniger Wartezeit für Entwickler, was den Workflow erheblich verbessert und zu einer produktiveren Entwicklungsumgebung führt. ::

{.object-cover .max-w-full .mb-5}

::GlobalBlogLevelInfo

• Rust Programmiersprache{target="_blank"}
• Optional PyO3{:target="_blank"}
• Optional uv{:target="_blank"}

Solltest du Fragen haben, oder dir etwas unklar sein, kannst du die Kommentarfunktion unter dem Artikel nutzen. ::

::GlobalTitle{:size="lg" .mb-4} Pfuzzer: Ein Python Fuzzy Searcher mit Rust ::

::GlobalParagraph Die Kombination von Rust und Python wird immer beliebter, insbesondere für performance-sensitive Anwendungen. Mit PyO3{:target="_blank" .text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} lassen sich Rust-Module als Python-Erweiterung nutzen, wodurch sich die Geschwindigkeit und Effizienz von Rust mit der Flexibilität von Python verbinden lassen. ::

::GlobalParagraph Ein herausragendes Beispiel für diese Integration ist Pfuzzer – eine Python-Bibliothek für Fuzzy Search, die auf der leistungsstarken Rust-Bibliothek Nucleo{:target="_blank" .text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} basiert. Doch Pfuzzer ist mehr als nur eine praktische Lösung für unscharfe Suchanfragen: Es zeigt, wie PyO3 genutzt werden kann, um Rust-Code nahtlos in Python einzubinden und rechenintensive Prozesse zu optimieren. ::

::GlobalParagraph In diesem Artikel erfährst du, wie Pfuzzer funktioniert, wie PyO3 die Entwicklung von Rust-Erweiterungen für Python erleichtert und wie du eine Fuzzy Search in Python mit Rust umsetzen kannst. ::

:::GlobalButton{:url="/technologien/python-django-agentur/" :label="Erfahre mehr über unsere Python-Entwicklungsdienste" :color="blue" .mb-6} :::

::GlobalTitle{:size="lg" .mb-5} Was ist PyO3? ::

::GlobalParagraph PyO3 ist ein Framework, das Rust-Code als native Python-Module verfügbar macht. Damit lassen sich Rust-Programme in Python integrieren, ohne auf Leistung oder Speichersicherheit verzichten zu müssen. Mit PyO3 kannst du: ::

::GlobalBlock{.ul-disk .my-4}

• Python-APIs mit Rust entwickeln
• Bestehende Rust-Bibliotheken in Python einbinden
• Python-Funktionen aus Rust heraus aufrufen ::

::GlobalParagraph Das Framework übernimmt technische Details wie Speicherverwaltung, Datenstrukturen und die Interaktion zwischen Python- und Rust-Laufzeit. ::

::GlobalParagraph Dank der hohen Performance von Rust und der Flexibilität von Python ist PyO3 ideal für rechenintensive Anwendungen, darunter Datenverarbeitung, maschinelles Lernen und performante Fuzzy-Suchfunktionen – wie es Pfuzzer demonstriert. ::

::GlobalTitle{:size="lg" .mb-5} Pfuzzer: Ein Python-Modul für Fuzzy Search mit Rust ::

::GlobalParagraph Pfuzzer ist eine Python-Bibliothek für Fuzzy Search, die auf der Rust-Bibliothek Nucleo basiert. Sie ermöglicht eine schnelle und effiziente unscharfe Suche – ideal für Anwendungen mit großen Datenmengen. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Warum Rust für Fuzzy Search? ::

::GlobalBlock{.ul-disk .my-4}

• Performance: Rust ist deutlich schneller als reines Python
• Speichersicherheit: Kein Garbage Collector, kein Memory Leak
• Einfache Integration: Mit PyO3 als Python-Erweiterung in Rust nutzbar ::

::GlobalTitle{:size="lg" .mb-5} Pfuzzer installieren und einrichten :: ::GlobalParagraph Um ein Rust-Projekt mit PyO3 in Python zu nutzen, eignet sich Maturin{:target="_blank" .text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid}. Maturin erleichtert den Build-Prozess, indem es Rust-Code als Python-Wheel kompiliert. So kann das Modul wie jede andere Python-Bibliothek installiert und verwendet werden. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Einrichtung eines PyO3-Projekts ::

::GlobalTitle{:font="font-oswald" :size="s" :tag="h4" .mb-2} 1. Projekt erstellen :: ::GlobalParagraph Für die Projektstruktur nutzen wir den uv Package Manager:: ::

::BlogCode{.mb-4}

$ mkdir pfuzzer
$ cd pfuzzer
$ uv venv
$ uv add maturin
$ . .env/bin/activate

::

::GlobalTitle{:font="font-oswald" :size="s" :tag="h4" .mb-2} 2. Maturin initialisieren :: ::GlobalParagraph Führe Maturin aus und lasse dir alle benötigten Dateien erstellen: ::

::BlogCode{.mb-4}

$ maturin init
✔  🤷 What kind of bindings to use? · pyo3
   ✨ Done! New project created pfuzzer

::

::GlobalParagraph Dieser Befehl erzeugt die Dateien Cargo.toml (Rust-Dependency-Management) und lib.rs (Rust-Code, der aus Python aufgerufen wird). ::

::GlobalParagraph Der Befehl maturin develop installiert dann dein frisch erstelltes Rust Package in dem vorher erstellten virtualenv. Da wir uv benutzen muss die --uv flag ergänzt werden. Mit maturin build –release kann das Package für den Roll-Out gebuildet werden. ::

::GlobalTitle{:size="lg" .mb-5} Pfuzzer: Implementierung und Funktionsweise :: ::GlobalParagraph Das Pfuzzer Python Package ist ein Wrapper für die Rust Library nucleo. Wie bereits gezeigt ist ein Wrapper einer bestehenden Library leicht mit PyO3 umzusetzen. Trotzdem will ich kurz auf die Implementierung eingehen und die Funktionsweise erklären. Der gesamte Code kann hier eingesehen{:target="_blank" .text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} werden. :: ::GlobalParagraph Dank PyO3 ist die Implementierung recht einfach. So stellt es mehrere Rust Attributes bereit, um Rust Code in Python aufrufbar zu machen. Hier z. B. die Implementierung des grundsätzlichen Python Moduls: ::

::BlogCode{.mb-4}

mod python_classes;
use pyo3::prelude::*;
/// A Python fuzzy searcher module implemented in Rust.
#[pymodule]
fn pfuzzer(m: &Bound<'_, PyModule>) -> PyResult<()> {
    m.add_class::<python_classes::pfuzzer::Pfuzzer>()?;
    Ok(())
}

::

::GlobalParagraph Das ist so wenig Code, man könnte fast meinen, es ist bereits in Python geschrieben. Aber kurz die wichtigsten Abschnitte erklärt: ::

::GlobalBlock{.ol-decimal .my-4}

1. #[pymodule] --> teilt dem compiler mit, dass es sich hier um ein Python Modul handelt. Dadurch wird in die Funktion PyModule als Variable injected, welche dann als Eingangspunkt für unser Python Modul benutzt werden kann.
2. m.add_class::<...> --> weist unserem Modul eine Klasse zu, in diesem Fall die noch nicht spezifizierte Pfuzzer Klasse. ::

::GlobalCallAnExpert{:bg="bg-bs-blue"} #buttonBlockTitle Wir können auch deine Python Anwendung mit Rust und PyO3 beschleunigen. ::

::GlobalParagraph Es gibt noch andere Möglichkeiten Rust Code dem Modul zuzuweisen. Darunter m.add_function. Anders als bei add_class wird hier allerdings nicht die Turbofish syntax verwendet sondern man muss die Rust Function mit einem Makro aufrufen. Mehr dazu in den PyO3 docs{:target="_blank" .text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid}. ::

::GlobalTitle{:size="lg" .mb-5} Pfuzzer-Klasse in Rust umsetzen ::

::GlobalParagraph Da Rust keine Klassen kennt, verwenden wir stattdessen Structs, um das Verhalten der Pfuzzer-Klasse zu definieren: :: ::BlogCode{.mb-4}

#[pyclass]
pub struct Pfuzzer {
    pub matcher: Matcher,
}

::

::GlobalParagraph Als Attribut wird hier pyclass vergeben. Dadurch wird das Struct als Python Klasse markiert und kann dann, wie vorher gezeigt, dem Modul zugewiesen werden. ::

::GlobalTitle{:size="lg" .mb-5} Konstruktor für Pfuzzer ::

::GlobalParagraph Jede gute Klasse braucht natürlich auch einen Konstruktor: ::

::BlogCode{.mb-4}

use nucleo::{Config, Matcher, Utf32Str};

#[pymethods]
impl Pfuzzer {
    #[new]
    pub fn new() -> PyResult<Self> {
        Ok(Pfuzzer {
            matcher: Matcher::new(Config::DEFAULT),
        })
    }

...

::

::GlobalParagraph Durch #[pymethods] deklarieren wir den gesamten Implementation Block als Python Methoden der Pfuzzer Klasse. Der Konstruktor selbst wird mit #[new] markiert. Aktuell unterstützt PyO3 nämlich nur die __new__ Magic Method und nicht __init__. ::

::GlobalTitle{:size="lg" .mb-5} Fuzzy Search in Rust: compare_strings Methode ::

::GlobalParagraph Zu guter Letzt noch die eigentliche “Logik” unseres Wrappers. Ich darf präsentieren, die compare_strings Methode: ::

::BlogCode{.mb-4}

pub fn compare_strings(&self, targets: Vec<String>, query: String) -> Vec<Option<u16>> {
        let mut res = Vec::<Option<u16>>::new();
        for target in targets {
            res.push(self.matcher.to_owned().fuzzy_match(
                Utf32Str::Ascii(target.as_bytes()),
                Utf32Str::Ascii(query.as_bytes()),
            ))
        }
        return res;
    }

::

::GlobalParagraph Wie man schnell erkennen kann, benutzt sie den nucleo Matcher und führt für jeden Ziel String das fuzzy matching anhand des angegebenen Query Strings aus.
Ergebnis der Methode ist dann ein optionaler Integer pro Ziel String, welcher aussagt, wie gut der Query String mit dem Ziel String übereinstimmt. Je höher das Ergebnis, desto besser die Übereinstimmung. Ein Null / None Wert sagt aus, dass Ziel und Query überhaupt nicht (oder zumindest nicht messbar) übereinstimmen. ::

::GlobalTitle{:size="lg" .mb-5} Pfuzzer in Python verwenden ::

::GlobalParagraph Und wie sieht das Ganze nun in Python aus? Bitteschön: ::

::BlogCode{.mb-4}

from pfuzzer import Pfuzzer

pf = Pfuzzer()

print(pf.compare_strings(["hello world", "hello blueshoe"], "helo world"))

>>> [257, None]

::

::GlobalParagraph Laut Ergebnis Matrix, ist also der erste String der String, welcher am besten mit der Query übereinstimmt. ::

::GlobalParagraph Wenn du noch Ideen für neue Features für Pfuzzer, oder gar Optimierungsgedanken, hast dann lass gerne einen Kommentar da. Oder mach ein Issue auf Github{:target="_blank" .text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} auf! ::

::GlobalTitle{:size="lg" .mb-5} Fazit: Rust und Python effizient kombiniert :: ::GlobalParagraph In diesem Artikel haben wir gezeigt, wie Rust und Python mit PyO3 zusammenarbeiten, um performante Lösungen für Fuzzy Search zu ermöglichen. Pfuzzer ist ein Beispiel dafür, wie sich die Geschwindigkeit und Sicherheit von Rust mit der Flexibilität von Python verbinden lassen. Die nahtlose Integration über PyO3 und Maturin eröffnet neue Möglichkeiten – besonders für rechenintensive Anwendungen wie Datenverarbeitung und maschinelles Lernen. :: ::GlobalParagraph Wenn auch du Lust auf richtig schnelles Python hast, dann schreib uns gerne in den Kommentaren und wir erörtern die Einsatzmöglichkeiten von Rust in deinem Python Projekt! Auch über Kommentare zu deinem Einsatz von PyO3 freuen wir uns! ::

:::GlobalTitle{:size="lg" .mb-5 .mt-8} Häufige Fragen :::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 1. Wie kann ich ein Python-Modul mit Rust und PyO3 erstellen? ::

::GlobalParagraph Um ein Rust-Modul für Python zu schreiben, brauchst du PyO3 und Maturin. Die grundlegenden Schritte: :: ::GlobalBlock{.ol-decimal .my-4}

1. Rust-Umgebung einrichten: Folgende Kommandos: cargo new --lib my_project, cd my_project.
2. PyO3 hinzufügen: Füge in der Cargo.toml die Dependency pyo3 = { version = "0.18", features = ["extension-module"] } hinzu.
3. Modul implementieren: use pyo3::prelude::*; und #[pymodule]
4. Mit Maturin bauen: maturin build ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 2. Wie funktioniert Fuzzy Search in Rust mit der Nucleo-Bibliothek? ::

::GlobalParagraph Die Nucleo-Bibliothek bietet einen leistungsstarken Fuzzy Matching Algorithmus, um die Ähnlichkeit zwischen Strings zu berechnen. Pfuzzer nutzt diese Bibliothek für schnelle unscharfe Suchen in Python. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 3. Kann ich Rust-Module in bestehenden Python-Projekten verwenden? ::

::GlobalParagraph Ja! Rust-Module lassen sich problemlos in bestehende Python-Projekte integrieren. Dank PyO3 kannst du Rust-Funktionen direkt als Python-Module importieren und nutzen. ::

{.object-cover .max-w-full .mb-5}

:::globalTitle{:size="lg" .mb-5} Die Bedeutung von APIs in der modernen Softwareentwicklung ::: :::globalParagraph Es gibt einen sehr guten Artikel von Darius Kazemi mit dem Titel "The land before modern APIs" über die Anfänge von ARPANET im Jahr 1970 und wie diese Entscheidungen die heutige Softwareentwicklung immer noch beeinflussen. Eine dieser Entscheidungen war die Spezifikation von Fehler- und Antwortcodes für das "RJE-Protokoll", was zu den HTTP-Statuscodes führte, die wir alle kennen und "lieben". ::: :::globalParagraph Aber warum sind diese frühen Entscheidungen so wichtig und das moderne API-Design so bedeutsam für unsere tägliche Arbeit? :::globalParagraph Nun, der von Entwicklern im Jahr 1970 geebnete Weg führte zur Entwicklung von Web-APIs in den frühen 2000er Jahren. Der Artikel von Kin Lane mit dem Titel "Intro to APIs: History of APIs" fasst die Geschichte von APIs sehr gut zusammen. Kurz gesagt, APIs gingen von einem kommerziellen Anwendungsfall über die Sozialisierung des Internets bis hin zur Unterstützung von Geräten der nächsten Generation. Es gibt sogar einen "API-Hub" für APIs! Das alles zeigt, dass APIs eine große Rolle in der modernen Softwareentwicklung spielen. ::: :::globalParagraph Obwohl wir unsere APIs lieben, gibt es immer noch eine laufende Debatte darüber, wie eine API unter der Haube funktionieren sollte. Vor 2015 entschied man sich in der Regel für ein REST-basiertes API-Design. Aber dann hat Facebook die GraphQL-Sprache für die API-Entwicklung als Open Source veröffentlicht und uns eine neue Möglichkeit gegeben, mit unseren Daten zu interagieren. ::: :::globalParagraph In diesem Beitrag möchte ich einen kleinen Überblick über REST und GraphQL geben, diese beiden vergleichen und schließlich einige andere Ansätze für das API-Design erwähnen. ::: :::globalParagraph{.mb-5} Also, wollen wir anfangen? :::

:::GlobalButton{:url="/loesungen/api-entwicklung/" :label="Erfahre mehr über unsere API-Entwicklungsdienste" :color="blue" .mb-6} :::

:::globalTitle{:size="lg" .mb-5} Die Grundlagen und Stärken von REST-APIs verstehen ::: :::globalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Eigenschaften von REST-APIs ::: :::globalParagraph REST APIs{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} weisen zwei grundlegende Eigenschaften auf, die ihrem Design zugrunde liegen: Zustandslosigkeit und die Verwendung von HTTP-Methoden. Erstens implementieren REST-APIs das zustandslose Paradigma, was bedeutet, dass jede Anfrage eines Clients an den Server alle erforderlichen Informationen enthalten muss, um sie zu verstehen und zu erfüllen, ohne auf vorherige Interaktionen angewiesen zu sein. Dies vereinfacht die Serverimplementierung und Skalierbarkeit, da keine Sitzungsdaten auf dem Server gespeichert werden müssen. Zweitens nutzen REST-APIs die vielseitigen Methoden des HTTP-Protokolls, wie z.B. GET, POST, PUT, DELETE, um verschiedene Aktionen auf Ressourcen auszuführen. Diese Methoden ermöglichen es Entwicklern, APIs zu erstellen, die eng mit den Prinzipien von CRUD (Create, Read, Update, Delete) übereinstimmen und die Klarheit, Vorhersagbarkeit und Zugänglichkeit ihrer API-Endpunkte verbessern. ::: :::globalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Anwendungsfälle von REST ::: :::globalParagraph Wenn du eine API{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} mit einem klar definierten Client-Server-Vertrag planst (das bedeutet unter anderem weniger Flexibilität bei den Serverantworten), ist REST eine sehr gute Option für dich. REST ist nicht nur effizient und einfach zu implementieren, sondern wird auch von allen Programmiersprachen weitgehend unterstützt, die mit HTTP-Methoden arbeiten können. ::: :::globalParagraph Obwohl REST vordefinierte Anfragen erwartet und nur festgelegte Antworten liefert, bietet es dennoch eine hohe Flexibilität für die Erstellung einer API. Mit REST kannst du alles aufbauen! ::: :::globalParagraph Ein einfaches Beispiel könnte eine einfache API sein, die die Bilder von http.cat abruft und an den Benutzer zurückgibt: ::: ::BlogCode{.mb-5}

from fastapi import FastAPI
from fastapi.responses import Response
import requests

app = FastAPI()

@app.get("/{status_code}", description="Get cat status code", response_class=Response)
async def get_cat_status_code(status_code: int):
    response = requests.get(f"https://http.cat/{status_code}")
    return Response(response.content, media_type="image/jpeg")

:: :::globalParagraph Bitte beachte, dass http.cat bereits eine API ist, die ein Bild zurückgibt (es ist nicht ungewöhnlich, andere APIs in deiner API aufzurufen). Aber dieses Beispiel soll nur zeigen, was mit einer einfachen REST-API möglich ist und wie sie dem HTTP-Methodenmodell entspricht. Lass uns das genauer betrachten! ::: :::globalParagraph In diesem Beispiel habe ich das beliebte FastAPI-Paket für Python verwendet. Es ermöglicht die einfache Erstellung von REST-APIs. ::: :::globalParagraph @app.get definiert eine HTTP-GET-Methode auf dem Stammverzeichnis mit dem Pfadparameter status_code. In der Methode get_cat_status_code mache ich dann eine GET-Anfrage an die http.cat-API (unter Verwendung des bereitgestellten status_code) und gebe schließlich die Bildbytes als FastAPI Response-Objekt zurück. ::: :::globalParagraph{.mb-6} Damit ist dieses kurze REST-Beispiel abgeschlossen. :::

::GlobalPartial{content=catcher-1}

:::globalTitle{:size="lg" .mb-5} GraphQL: Ein "Neuling" unter den APIs ::: :::globalParagraph Obwohl GraphQL seit 2015 existiert, ist es im Vergleich zu REST oder sogar älteren Technologien wie SOAP-basierten APIs immer noch recht neu in der API-Welt. ::: ::: :::globalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Eigenschaften von GraphQL ::: :::globalParagraph{.mb-5} GraphQL APIs{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} besitzen charakteristische Merkmale, die sie von traditionellen REST-APIs unterscheiden und einen flexibleren und effizienteren Ansatz für die Datenabfrage bieten. Eine bemerkenswerte Funktion von GraphQL ist seine Fähigkeit, Abfragen zu optimieren und den Datentransfer zu minimieren. Im Gegensatz zu REST-APIs, bei denen Endpunkte festgelegt sind und vordefinierte Datenstrukturen zurückgeben, ermöglicht GraphQL den Clients, genau anzugeben, welche Daten sie mit einer einzigen Abfrage benötigen. Diese Fähigkeit beseitigt Probleme mit Über- und Unterabfrage, die bei REST-APIs häufig auftreten, bei denen Clients möglicherweise mehr oder weniger Daten erhalten als erforderlich. Darüber hinaus ermöglicht das Typsystem von GraphQL Clients, verschachtelte oder verwandte Daten in einer einzigen Abfrage anzufordern, wodurch die Notwendigkeit für mehrere Anfragen an den Server reduziert wird. Durch Bereitstellung einer präzisen und deklarativen Syntax für die Datenabfrage ermöglicht GraphQL den Clients, nur die erforderlichen Daten abzurufen, was zu einer effizienteren Netzwerknutzung und einer verbesserten Leistung führt. Darüber hinaus unterstützt GraphQL Funktionen wie Query Batching und Caching, wodurch der Datentransfer optimiert und die Latenz für Client-Anwendungen reduziert wird. Insgesamt verbessern die Abfrageoptimierungsfunktionen von GraphQL die Effizienz und Reaktionsfähigkeit von API-Interaktionen und machen es zu einer hervorragenden Wahl für die moderne Anwendungsentwicklung. resulting in more efficient network usage and improved performance. ::: :::globalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Anwendungsfälle von GraphQL ::: :::globalParagraph Der Anwendungsfall für GraphQL-APIs unterscheidet sich etwas von REST. GraphQL sollte in datenreichen Umgebungen mit komplexen Anforderungen verwendet werden. Es ist auch sinnvoll, wenn du mehrere Clients mit unterschiedlichen Datenanforderungen hast. ::: :::globalParagraph Lass uns das gleiche Beispiel wie bei der REST-API einrichten und mit GraphQL einige http.cat-Bilder abrufen! ::: :::globalParagraph Hier ist der Hauptcode für die API mit FastAPI und seiner GraphQL-Integration mit strawberry: ::: ::BlogCode{.mb-5}

import strawberry
from fastapi import FastAPI
from strawberry.asgi import GraphQL

@strawberry.type
class Cat:
    url: str

@strawberry.type
class Query:
    @strawberry.field
    def cat(self, status_code: int) -> Cat:
        return Cat(url=f"https://http.cat/{status_code}")

schema = strawberry.Schema(query=Query)

graphql_app = GraphQL(schema)

app = FastAPI()
app.add_route("/graphql", graphql_app)
app.add_websocket_route("/graphql", graphql_app)

:: :::globalParagraph Zuerst definieren wir einen strawberry-Typ namens Cat, dann einen weiteren namens Query. Query hat ein Feld namens cat, das ein implizites Feld url hat. Das Erstellen eines GraphQL-Schemas kann mit strawberry-Schema erfolgen, indem es der Query class übergeben wird. ::: :::globalParagraph Wie du sehen kannst, ist GraphQL nicht in der Lage, die Bildbytes direkt zurückzugeben, was bedeutet, dass du solche Dinge selbst erledigen musst. Es benötigt auch einen Client auf der anderen Seite, der eine Abfrage gegen unsere API ausführen kann. Glücklicherweise hat strawberry einen integrierten Server, der einen solchen Client bereitstellt: {.object-cover .max-w-full .mb-5} ::: :::globalParagraph Auf der linken Seite siehst du die von mir zusammengestellte Abfrage und auf der rechten Seite die JSON-Antwort von der GraphQL-API. :::

:::globalTitle{:size="lg" .mb-5} Vergleich von REST und GraphQL ::: :::globalParagraph Im Internet liest man oft über REST vs GraphQL. Meiner Meinung nach kann man diese beiden Technologien nicht gegeneinander antreten lassen. Es handelt sich um zwei sehr unterschiedliche Ansätze zur Interaktion mit Daten, auf die wir zugreifen möchten. Daher ist ein Vergleich zwischen diesen beiden nicht fair und man kann nicht generell sagen, dass ein Ansatz besser ist als der andere. Ich würde eher vorschlagen, wann man welchen Ansatz verwenden sollte. ::: :::globalParagraph Wenn du dich in einer Umgebung befindest, in der du die Anforderungen mehrerer Clients erfüllen musst, die unterschiedlich geformte Daten benötigen, solltest du wahrscheinlich GraphQL verwenden. Mit seiner einfachen Abfragesprache kannst du schnelle, effiziente Antworten für deine Clients und ihre unterschiedlichen Anforderungen erzielen. ::: :::globalParagraph Auf der anderen Seite, wenn du etwas strenger in Bezug auf Serverantworten sein kannst und gern eine gute Zwischenspeicherung von Anfragen hättest, könnte eine REST-basierte API das Richtige für dich sein. Aufgrund ihrer Standardisierung und der Verwendung von HTTP-Methoden ist REST weit verbreitet und verwendbar. Mit ihrem Aufruf zur klaren Trennung von Zuständigkeiten und der architektonischen Kommunikation ohne Zustand ist sie auch eine sehr skalierbare Lösung. :::

:::globalTitle{:size="lg" .mb-5} Übersicht über alternative API-Technologien ::: :::globalParagraph Zum Schluss möchte ich zwei alternative Ansätze zur API-Entwicklung{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} erwähnen, die wir bei Blueshoe ebenfalls verwenden und anbieten. ::: :::globalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} gRPC und seine Rolle in Microservices ::: :::globalParagraph gRPC (das g steht nicht für Google) ist ein Open-Source-RPC-Framework, das ursprünglich von Google entwickelt wurde. Es basiert auf HTTP/2, Protocol Buffers (protobuf) und anderen modernen Technologien und bietet eine robuste und effiziente Möglichkeit, Dienste in verschiedenen Umgebungen zu verbinden. ::: :::globalParagraph gRPC bietet viele Vorteile in Microservice-Architekturen{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid}. Einige davon sind: ::: ::GlobalBlock{:font-size="lg" :color="text-bs-text" .ul-disk .mb-5}

• Effiziente Serialisierung mit Protocol Buffers: gRPC verwendet Protocol Buffers als seine Interface Definition Language (IDL) zur Definition von Serviceverträgen und zur Serialisierung von Daten. Protocol Buffers bieten ein kompaktes Binärformat und effiziente Serialisierungs- und Deserialisierungsprozesse, was zu kleineren Nachrichtengrößen und schnellerer Datenübertragung führt. Diese Effizienz ist insbesondere in Microservices{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid}-Umgebungen mit hohem Datendurchsatz von Vorteil.
• Starke Typisierung und Codegenerierung: Die gleiche Technologie von Protocol Buffers wird auch für die Typisierung und Codegenerierung verwendet. Dadurch kann die Entwicklung beschleunigt und menschliche Fehler minimiert werden.
• Bidirektionales Streaming und Flusssteuerung: gRPC unterstützt verschiedene Kommunikationsmuster, einschließlich unärer, serverseitiger Streaming, clientseitiger Streaming und bidirektionaler Streaming. Diese Flexibilität ermöglicht es Diensten, Daten in Echtzeit effizient auszutauschen und unterstützt Anwendungsfälle wie Chat-Anwendungen, Echtzeitanalyse und ereignisgesteuerte Architekturen. Darüber hinaus verhindern die integrierten Flusssteuerungsmechanismen von gRPC Probleme wie Rückstau und gewährleisten eine optimale Ressourcennutzung und Systemstabilität. ::

:::globalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} SOAP als Unternehmenslösung ::: :::globalParagraph SOAP (Simple Object Access Protocol), ein Protokoll zum Austausch strukturierter Informationen bei der Implementierung von Webdiensten, ist seit Jahrzehnten Teil von Unternehmensanwendungen. Es bietet eine standardisierte Möglichkeit für Anwendungen, über Netzwerke zu kommunizieren und ermöglicht die Interoperabilität zwischen verschiedenen Systemen und Plattformen. Trotz Kritik an seiner Verbosity und Komplexität im Vergleich zu neueren Protokollen wie REST ist SOAP aufgrund seiner Zuverlässigkeit, Erweiterbarkeit und umfassenden Sicherheitsfunktionen in Unternehmensumgebungen weiterhin beliebt. :::

:::globalTitle{:color="text-bs-green" :font="font-oswald" :size="sm" :tag="h4" .mb-5} Sicherheitsfunktionen von SOAP ::: ::GlobalBlock{:font-size="lg" :color="text-bs-text" .ul-disk .mb-5}

• Sicherheit auf Nachrichtenebene: SOAP unterstützt Sicherheit auf Nachrichtenebene, indem einzelne Nachrichten zwischen Client und Server verschlüsselt und signiert werden können. Dadurch wird die Vertraulichkeit, Integrität und Authentizität von Daten gewährleistet und das Risiko von Abhören, Manipulation und unbefugtem Zugriff auf sensible Informationen verringert. Durch die Verschlüsselung von Payloads und das Anhängen digitaler Signaturen an Nachrichten hilft SOAP Unternehmen, die Vertraulichkeit und Integrität ihrer Daten auch während der Übertragung über nicht vertrauenswürdige Netzwerke aufrechtzuerhalten.
• WS-Security-Standard: SOAP integriert sich nahtlos in den WS-Security-Standard, eine weit verbreitete Spezifikation zur Sicherung von Webdiensten. WS-Security bietet einen Rahmen für die Integration verschiedener Sicherheitsmechanismen wie Verschlüsselung, digitale Signaturen und Authentifizierungstoken in SOAP-Nachrichten. Diese Standardisierung gewährleistet die Interoperabilität und Kompatibilität zwischen verschiedenen Implementierungen und ermöglicht Unternehmen, auf ein breites Ökosystem von Sicherheitstools und -lösungen zurückzugreifen, um ihre auf SOAP basierenden Dienste zu schützen. ::

:::globalTitle{:size="md" .mb-5} Zusammenfassung ::: :::globalParagraph Wie du siehst, gibt es viele Möglichkeiten, eine API{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} zu implementieren, und die Wahl der richtigen Technologie kann manchmal schwierig sein. Ich hoffe, mit diesem kurzen Überblick einen Hinweis darauf geben zu können, wann man einen bestimmten Ansatz verwenden sollte, um deine API zu erstellen. Und wenn du jemals eine maßgeschneiderte Lösung brauchst, melde dich bei uns{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid}! :::

:::GlobalPodcastSection{:videoId="tyvE9VlSWkE" :videoPosition="left" .mb-6} ::::GlobalPreTitle{:color="text-bs-green" .mb-3} Unser Kubernetes-Podcast :::: ::::GlobalTitle{:tag="h3" .mb-6} Tools for the Craft: Navigating the Kubernetes ecosystem :::: ::::globalParagraph{:font-size="lg" .mb-4} Michael und Robert sprechen ausführlich über die Vor- und Nachteile der lokalen Kubernetes-Entwicklung und geben auch einige echte Codierungsbeispiele. :::: ::::globalParagraph{:font-size="lg" } Weitere Ausgaben unseres Podcasts findest du hier: :::: ::::GlobalButton{:url="/kubernetes-podcast/" :label="Mehr anzeigen" :color="green"} :::: :::

{.object-cover .max-w-full .mb-5}

Das Thema saisonales SEO ist sehr umfangreich und bietet vielerlei Optionen, Wege und Möglichkeiten. Grund genug, sich damit einmal auseinanderzusetzen und abzuschätzen, ob es sich lohnt, bestimmte (saisonale) SEO-Maßnahmen umzusetzen – insbesondere dann, wenn einzelne Produkte nicht immer angeboten werden (können).

Einzelne Aspekte und Optionen sind dabei von Bedeutung, die im folgenden Text eine entsprechende Wichtigkeit haben. So findet man einfach heraus, wie man im E-Commerce durch Suchmaschinenoptimierung größere Erfolge erzielen kann, wenn Produkte nicht immer griffbereit sind.

Es folgen drei Tipps mit ersten Anregungen:

TIPP 1: SO KANN MAN MIT ALTEN PRODUKTSEITEN IM ONLINE SHOP UMGEHEN

Jedes Produkt in einem E-Commerce-Shop hat im Idealfall eine eigene Produktseite. Nun kann es allerdings vorkommen, dass ein Artikel nicht mehr verkauft wird, da die Produktion eingestellt wurde oder er ausverkauft ist.

{.object-cover .max-w-full .mb-5}

Wie geht man in einem solchen Fall mit der Produktseite um, die an sich nicht mehr gebraucht wird? Es gibt hierfür zwei Ansätze, die in Frage kommen können:

Man leitet die Seite auf ein ähnliches Produkt weiter

• Man nutzt eine Weiterleitung auf die Kategorie des Artikels, sodass der Kunde aus einer anderen Auswahl wählen kann.

TIPP 2: DAS KANN MAN MIT SAISONALEN ARTIKELN MACHEN

In vielen Online-Shops wird zudem mit saisonalen Artikeln gearbeitet, die jeweils nur für einen begrenzten Zeitraum gefragt sind oder angeboten werden. Im Zusammenhang mit SEO-Maßnahmen sollte man hier bedenken, wie man mit Produktseiten für saisonale Waren umgehen kann. Immerhin ranken auch derartige Seiten und bringen somit potentielle Kunden zum Online-Shop.

{.object-cover .max-w-full .mb-5}

Wenn dann allerdings kein Artikel angeboten wird, kann dies ein Nachteil sein. Um auch dann eine Möglichkeit zu finden, einen Verkauf zu erzielen, sind unterschiedliche Wege möglich. Keinesfalls sollte man die Seite so lassen, wie sie ist – das kann zu unzufriedenen Kunden und einem schnellen Absprung führen.

Stattdessen sind zum Beispiel diese Lösungen vielversprechender:

• Den Nutzer auf alternative (eventuell auch saisonale) Produkte aufmerksam machen
• Den Nutzer direkt auf alternative Artikel weiterleiten
• Einen Hinweis einbringen, dass der Artikel nur in einem bestimmten Zeitraum (mit entsprechender Angabe dessen) erhältlich ist und gleichzeitig auf das allgemeine Angebot des Online Shops verweisen

TIPP 3: SO GEHT MAN MIT AKTUELL VERGRIFFENEN ARTIKELN UM

Es kann vorkommen, dass ein Artikel in einem Online-Shop kurzzeitig nicht erhältlich ist. Eine größere Nachfrage kann dazu führen, ebenso aber auch ein zu geringer Lagerbestand. Dennoch werden sich Kunden natürlich weiterhin für den Artikel interessieren und ihn kaufen wollen.

{.object-cover .max-w-full .mb-5}

Je nachdem, wie lange der Artikel nicht griffbereit ist, sollte man SEO-technische Maßnahmen ergreifen. In Frage können dabei zum Beispiel diese Optionen kommen:

• Man bietet dem Kunden per Redirect Alternativen an, zum Beispiel gleichwertige Artikel anderer Marken
• Eine Info, wann der Artikel wieder verfügbar ist, sollte auf jeden Fall vorhanden sein
• Man bietet dem Kunden an, sich informieren zu lassen, wenn der Artikel wieder vorhanden ist, sodass dann ein Kauf möglich ist und kann somit gleichzeitig ggf. schon E-Mail-Adressen von potentiellen Kunden einsammeln
• Generell ist es ratsam, auf der Produktseite dann auch alternative Artikel zu verlinken, die für den Kunden in Frage kommen können

Grundsätzlich sind SEO-Maßnahmen nur ein Bestandteil einer ausgereiften Inbound-Marketing-Strategie. Nur eine ganzheitliche Betrachtung deines Angebots kann zu nachhaltigen Erfolgen führen. Wir helfen dir gern!

{.object-cover .max-w-full .mb-5}

:::globalTitle{:size="lg" .mb-5} WARUM BESCHÄFTIGEN WIR UNS MIT DOCKER IMAGES? ::: :::globalParagraph Docker Images haben sich auch bei Blueshoe als präferierte Technologie herausgestellt, um einerseits Anwendungen lokal zu entwickeln, und, um andererseits die Anwendungen in einem Testing-/Staging- oder Produktiv-System zu betreiben (“Deployment”). Neben der ungewohnten Situation als Python-Entwickler plötzlich wieder eine gewisse Build-Wartezeit zu haben, sind uns mit als erstes die zum Teil großen resultierenden Docker Images aufgefallen. :::

:::globalTitle{:size="lg" .mb-5} GRÖSSE DER DOCKER IMAGES MINIMIEREN ::: :::globalParagraph Gerade das Minimieren der Imagegröße spielt für uns eine zentrale Rolle für die Erstellung unserer Dockerfiles. Das Docker Image sollte natürlich über alles Benötigte verfügen, um die Anwendung ausführen zu können - aber eben auch nicht mehr. Überflüssiges sind z. B. Software-Pakete und Libraries, die nur zum Kompilieren oder für das Ausführen automatisierter Tests benötigt werden. ::: :::globalParagraph Man kann gleich mehrere Gründe finden, wieso in einem Docker Image nur das absolut Nötigste vorhanden sein sollte: ::: :::GlobalBlock{.ul-disk .mb-5}

• Zum einen wird die Sicherheit des Images erhöht. Um eine simple Django-Anwendung auszuführen, benötige ich sicherlich kein ausgewachsenes Debian- oder Ubuntu-Image. Es genügt ein einfaches Python-Image als Basis, das praktisch kaum mehr können muss als mittels eines Python-Interpreters bzw. Application Server die Django-Anwendung auszuführen. Warum wird dadurch nun die Sicherheit erhöht? Ganz einfach, weniger Libraries reduzieren die Anzahl der Angriffsflächen. Der hier verlinkte Artikel ist zwar bereits ein Jahr alt, erläutert aber aufschlussreich die zugrunde liegende Problematik und stellt dar, wie man mit kleineren Versionen des Basis-Images bekannte CVEs (Common Vulnerabilities and Exposures) reduzieren kann.
• Ein weiterer Aspekt ist die Geschwindigkeit. Im Betrieb kann es oberflächlich betrachtet eigentlich egal sein, ob das Docker Image nun zwei Gigabyte oder nur 200 Megabyte groß ist. Das Deployment ist oftmals automatisiert und ob es nun ein paar Minuten länger dauert, bis der (neue) Code bereitsteht, spielt i. d. R. auch keine große Rolle. Aber hier gilt natürlich: Was wir an unnötigem Datenverbrauch und überflüssigen Datenübertragungen einsparen können, sollten wir einsparen.
• Als Entwickler kann ich hauptsächlich von kleinen Docker Images profitieren, wenn ich keine automatisierte Build-Pipeline habe, sondern die Images selbst baue und z. B. in einer Container Registry (der zentrale Speicher für Images) bereitstelle. Habe ich nun ein Dockerfile erzeugt, das zwei Gigabyte groß ist, und sitze Corona-bedingt im Home Office bei nicht ganz so optimaler Internetverbindung, kann der Upload durchaus eine gewisse Zeit dauern. Ärgerlich ist es allemal, wenn der Entwicklungsprozess unnötig in die Länge gezogen wird und sei es auch nur für eine halbe Minute bei jedem Build.
• Der nächste Aspekt ist der Ressourcenverbrauch. Nicht nur auf meinem Laptop, der mit der Zeit durch immer mehr Docker Images zugemüllt wird, die ich regelmäßig aufräumen muss, sondern auch in der Container Registry. Diese könnte z. B. von Gitlab gehostet sein. Klar ist Speicherplatz i. d. R. kein sonderlich großer Kostenfaktor, wenn allerdings jedes Docker Image ein bis zwei Gigabyte groß wird, und Woche für Woche dutzende Images in die Registry gepusht werden, kann sich der angesammelte Speicherplatz durchaus auf eine respektable Menge summieren. Wenn wir es schaffen, die Docker Images auf die Hälfte oder ein Viertel ihrer Größe zu reduzieren, haben wir schon einiges gewonnen.
• Zu guter Letzt ist natürlich auch die Umwelt zu nennen. Jedes Docker Image wird zunächst mal in eine Registry gepusht und von dort wieder heruntergeladen. Sei es nun auf den Laptop eines Entwicklers, oder von einem Produktiv-System. Wenn meine Docker Images unnötigerweise viermal so groß sind, wie sie sein müssten, sorge ich dafür, dass permanent viermal so viel Traffic durch die Verwendung meiner Images entsteht oder zusätzliche Speichersysteme betrieben werden müssen. :::

{.object-cover .max-w-full .mb-5}

:::globalTitle{:size="md" .mb-5} WELCHE ANFORDERUNGEN BESTEHEN FÜR EIN DOCKER IMAGE? ::: :::globalParagraph Trotz aller Minimierung der Imagegröße müssen natürlich auch einige Anforderungen bedacht werden. Wenn ich meine Docker Images bis aufs letzte Megabyte optimiere, danach aber nicht mehr vernünftig damit entwickeln kann, oder die Anwendung nicht robust läuft, ist nicht viel gewonnen. Im Endeffekt kann man die Überlegungen auf die drei Ebenen Entwicklung, Testing/Staging und Production herunterbrechen. ::: :::globalParagraph Als Entwickler möchte ich möglichst wenig in meinem Arbeitsfluss gestört werden, mein Komfort steht hier definitiv im Vordergrund. Das heißt, ich benötige ein Docker Image, das im Idealfall eine möglichst geringe Build-Zeit hat und das z. B. live code-reloading unterstützt. Außerdem möchte ich vielleicht noch weitere Tools wie den Python Remote Debugger oder auch Telepresence einsetzen. Evtl. benötige ich dafür weitere Dependencies, die z. B. in einem Produktiv-System nicht relevant sind. ::: :::globalParagraph Für Testing-, bzw. Staging- und für Produktiv-Systeme sehen die Anforderungen sehr ähnlich aus. Hier steht ganz klar die Sicherheit an erster Stelle. Ich möchte möglichst wenig Libraries und Packages auf dem System haben, die für die Ausführung der Anwendung gar nicht gebraucht werden. Eigentlich sollte ich als Entwickler gar keinen Bedarf mehr haben, mit dem laufenden Container zu interagieren, wodurch hier sämtliche Bedenken bzgl. Komfort vernachlässigt werden können. ::: :::globalParagraph Aber gerade auf einem Testing-/Staging-System kann es dennoch sehr praktisch sein, wenn ich dort zu Debugging-Zwecken gewisse Packages verfügbar habe. Das ist allerdings nicht unbedingt ein Argument dafür, diese Packages bereits im Docker Image für den Fall der Fälle bereitzuhalten. Mittels Telepresence lässt sich ja z. B. in einer Kubernetes-Umgebung ein Deployment austauschen. Das bedeutet, ich kann mir lokal ein Docker Image bauen, das all meine benötigten Dependencies bereitstellt, und dieses in meinem Testing-/Staging-Cluster ausführen. Wie man das bewerkstelligen kann, haben wir in einem unserer letzten Blogposts - Cloud Native Kubernetes development{.bs-link-blue} - dargestellt. ::: :::globalParagraph Gerade zu Beginn der Entwicklungsphase eines Projekts kann der oben beschriebene Use-Case recht häufig auftreten. Für ein Produktiv-System sollte das aber eigentlich keine Rolle mehr spielen. Dort möchte ich vielleicht noch Logs betrachten, was einerseits mittels kubectl bewerkstelligt werden kann oder evtl. auch mit einer Log-Collector-Lösung. Im Endeffekt möchte ich, dass das Testing-/Staging-System mit dem identischen Docker Image ausgeführt wird, wie das Produktiv-System. Ansonsten besteht z. B. die Gefahr, dass im Produktiv-System ein Fehlverhalten auftritt, welches im Testing-/Staging-System aufgrund der unterschiedlichen Umgebung nicht aufgetreten ist. ::: :::globalParagraph Auch von Operations-Seite können Anforderungen kommen, z. B. in Form eines Vulnerability-Checks, um zu gewährleisten, dass bekannte Vulnerabilities, wo es möglich ist, gar nicht erst im Image vorhanden sind, bzw. damit behebbare Vulnerabilities auch behoben sind. Weiterhin kann auch eine Company-Policy Einfluss auf das Dockerfile haben, entweder die der eigenen Firma oder die des Auftraggebers. Ein Szenario wäre z. B. der Ausschluss bestimmter Basis Images oder das Gewährleisten der Verfügbarkeit gewisser Packages oder Libraries. :::

:::globalTitle{:size="lg" .mb-5} EVOLUTION EINES DOCKER IMAGES ::: :::globalParagraph In den folgenden Abschnitten wollen wir nun betrachten, welche Schritte man konkret vornehmen kann, um das eigene Dockerfile zu optimieren. Zunächst schauen wir uns Voraussetzungen an, die das resultierende Docker Image beeinflussen können. Außerdem werfen wir einen Blick auf die Strategien und Patterns für Dockerfiles, bevor wir uns in mehreren Iterationen die Auswirkungen der Optimierungen anschauen. :::

:::globalTitle{:size="md" .mb-5} VORAUSSETZUNGEN ::: :::globalParagraph An erster Stelle steht die Auswahl des Basis Images. Dieses muss auch im Dockerfile an erster Stelle definiert werden. Für eine Django-Anwendung genügt uns ein Python Base Image. Wir könnten zwar natürlich auch einfach ein Ubuntu Image wählen, aber wir wollen die Image-Größe ja möglichst klein halten und redundante Packages gar nicht erst im Image haben. Der Docker Hub stellt viele vorgefertigte Images bereit. Auch für Python gibt es verschiedene Images, die anhand der Python Versionsnummer oder auch mit den Begriffen slim und alpine unterschieden werden. ::: :::globalParagraph Das “Standard” Python Base Image basiert auf Debian Buster und stellt somit die größte der drei Varianten dar. Die slim Variante basiert ebenfalls auf Debian Buster, allerdings mit herunter getrimmten Packages. Das resultierende Image ist somit natürlich kleiner. Die dritte Variante ist alpine und basiert, wie der Name vermuten lässt, auf Alpine Linux. Das entsprechende Python Base Image hat die geringste Größe, allerdings kann es gut sein, dass man benötigte Packages im Dockerfile nachinstallieren muss. ::: :::globalParagraph Einen u. U. großen Einfluss auf das Dockerfile haben auch die System Runtime und Build Dependencies. Gerade beim Base Image gilt zu beachten, dass ein auf Alpine basierendes Image mit musl libc ausgeliefert wird und nicht mit glibc, wie auf Debian-basierten Base Images. Selbiges gilt für gcc, der GNU Compiler Collection, die nicht standardmäßig auf Alpine verfügbar ist. ::: :::globalParagraph Als Django-Entwicklung haben Anwendungen natürlich einige pip-Requirements. Je nach gewähltem Basis-Image muss das Dockerfile also sicherstellen, dass alle für die pip-Requirements benötigten System-Packages und Libraries installiert sind. Aber auch die pip-Requirements selbst können Auswirkungen auf das Dockerfile haben, wenn ich zusätzliche Packages für die Entwicklung habe, die jedoch im Produktiv-Betrieb nicht benötigt werden und dort auch nicht vorhanden sein sollen. Ein Beispiel dafür ist das pydevd-pycharm Package, welches wir lediglich für den Python Remote Debugger in PyCharm benötigen. :::

:::globalTitle{:size="md" .mb-5} STRATEGIEN UND PATTERNS FÜR DOCKERFILES ::: :::globalParagraph Mit der Zeit haben sich verschiedene Strategien und Patterns entwickelt, um Dockerfiles zu gestalten und zu optimieren. Die Herausforderung, eine kleine Image-Größe zu erhalten, knüpft sich stark daran, wie aus dem Dockerfile ein Image wird. Jede Instruktion fügt einen neuen Layer hinzu, wobei jeder Layer auf dem vorherigen aufbaut. Mit diesem Wissen ist es natürlich naheliegend zu versuchen, die Anzahl der Layer und die Größe der verschiedenen Layer möglichst gering zu halten. Man kann z. B. nicht mehr benötigte Artefakte innerhalb eines Layers löschen, oder mit verschiedenen Shell Tricks und anderen Logiken verschiedene Instruktionen in einem Layer zusammenfassen. ::: :::globalParagraph Ein mittlerweile veraltetes Pattern ist das sogenannte Builder Pattern. Hierfür erstellt man ein Dockerfile für die Entwicklung, das Builder-Dockerfile. Dieses enthält alles benötigte, um die Applikation zu bauen. Für die Testing-/Staging- und Produktiv-Umgebungen erstellt man ein zweites, herunter getrimmtes Dockerfile. Dieses enthält die Anwendung an sich und ansonsten nur das Nötigste, um die Software auszuführen. Dieser Ansatz ist zwar machbar, hat allerdings zwei große Nachteile: Zum einen ist es definitiv nicht ideal zwei verschiedene Dockerfiles warten zu müssen, zum anderen entsteht dadurch ein komplizierter Workflow: ::: :::GlobalBlock{.ul-disk .mb-5}

• Builder Image kompilieren
• Container anhand Builder Image erstellen
• benötigte Artefakte aus Container kopieren bzw. extrahieren
• Container löschen
• Production Image anhand der extrahierten Artefakte builden :::

:::globalParagraph Dieser Ablauf lässt sich natürlich durch Scripts automatisieren, ist aber dennoch nicht ideal. ::: :::globalParagraph Als bessere Lösung finden mittlerweile sogenannte Multi-Stage Dockerfiles immer mehr Verbreitung. Diese werden von Docker selbst empfohlen. Ein Multi-Stage Dockerfile folgt einer eigentlich recht simplen Struktur: ::: :::globalParagraph Die verschiedenen Stages werden durch FROM-Statements voneinander getrennt. Dabei kann eine “Stage” auch immer mit einem Namen versehen werden, was es einfacher macht, diese Stage zu referenzieren. Da jede Stage mit einem FROM-Statement beginnt, wird auch in jeder Stage ein neues Base-Image verwendet. Der Vorteil mehrere Stages ist nun, dass sich einzelne Artefakte aus einer Stage selektiv in eine nächste kopieren lassen. Es ist auch möglich an einer gewissen Stage zu stoppen, um z. B. Debugging-Funktionalitäten bereitzustellen, also um verschiedene Stages für Development/Debug und Staging/Production zu unterstützen. ::: :::globalParagraph Wird während des Build-Prozesses keine Stage angegeben, an der gestoppt werden soll, wird das komplette Dockerfile durchlaufen, was im Docker Image für das Produktiv-System resultieren sollte. Im Vergleich zum Builder Pattern wird dabei nur ein Dockerfile benötigt und es ist kein Build-Script nötig, um den Workflow abzubilden. :::

:::globalTitle{:size="lg" .mb-5} EVALUATION VERSCHIEDENER DOCKERFILES ::: :::globalParagraph Mit all diesem Wissen machen wir uns nun an die Evaluation verschiedener Dockerfiles. Wir haben sechs verschiedene Dockerfiles geschrieben, die wir anhand der Größe evaluiert haben. Zunächst schauen wir uns nun der Reihe nach die Dockerfiles mit den gewählten Optimierungen an. Allen Dockerfiles ist gemeinsam, dass postgresql-client bzw. postgresql-dev installiert wird, das Kopieren und Installieren von pip-Requirements sowie das Kopieren der Anwendung. :::

:::globalTitle{:size="sm" .mb-5} DOCKERFILE 1 - NAIVE ::: :::BlogCode{.mb-5}

FROM python:3.8

RUN apt-get update
RUN apt-get install -y --no-install-recommends postgresql-client

COPY requirements.txt /requirements.txt
RUN pip install -r /requirements.txt

COPY src /app

WORKDIR /app

::: :::globalParagraph Das erste Dockerfile basiert auf dem python:3.8 Basis Image. Wir bekommen also alle Debian “Nuts and Bolts” mitgeliefert, um innerhalb des Containers praktisch ohne Einschränkungen arbeiten zu können. :::

:::globalTitle{:size="sm" .mb-5} DOCKERFILE 2 - NAIVE, LÖSCHEN DER APT-LISTS ::: :::BlogCode{.mb-5}

FROM python:3.8

RUN apt-get update \
    && apt-get install -y --no-install-recommends postgresql-client \
    && rm -rf /var/lib/apt/lists/*

COPY requirements.txt /requirements.txt
RUN pip install -r /requirements.txt

COPY src /app

WORKDIR /app

::: :::globalParagraph Dieses Dockerfile ist identisch zum ersten, mit der Ausnahme, dass nach der Installation der benötigten zusätzlichen Packages der Inhalt des Verzeichnisses /var/lib/apt/lists/ gelöscht wird. In diesem Verzeichnis werden nach einem apt update Paketlisten gespeichert, die für unser Docker Image nicht mehr relevant sind. :::

:::globalTitle{:size="sm" .mb-5} DOCKERFILE 3 - ALPINE NAIVE ::: :::BlogCode{.mb-5}

FROM python:3.8-alpine

RUN apk update && apk --no-cache add libpq gcc python3-dev musl-dev linux-headers postgresql-dev

COPY requirements.txt /requirements.txt
RUN pip install -r /requirements.txt

COPY src /app

WORKDIR /app

::: :::globalParagraph Unser drittes Dockerfile basiert ganz simpel auf Alpine Linux. Da in Alpine einige Packages für den Betrieb der Anwendung fehlen, müssen diese zunächst noch installiert werden. :::

:::globalTitle{:size="sm" .mb-5} DOCKERFILE 4 - ALPINE LINUX, LÖSCHEN VON BUILD DEPENDENCIES ::: :::BlogCode{.mb-5}

FROM python:3.8-alpine

COPY requirements.txt /requirements.txt

RUN apk update && apk add --no-cache --virtual .build-deps gcc python3-dev musl-dev linux-headers postgresql-dev && \
 apk --no-cache add libpq && \
 pip install -r /requirements.txt && \
 apk del .build-deps

COPY src /app
WORKDIR /app

::: :::globalParagraph Das nächste auf Alpine Linux basierende Dockerfile fügt im Grunde auch nur ein Löschen von Build Dependencies hinzu, also von zusätzlich installierten Packages, die nur für das Builden des Images benötigt werden, nicht aber für das Ausführen der Anwendung. Damit das in nur einer Anweisung funktioniert, muss die COPY-Anweisung für die pip-Requirements nach oben geschoben werden, um das Installieren der pip-Requirements zwischen dem Installieren und Löschen der Build Dependencies durchführen zu können. :::

:::globalTitle{:size="sm" .mb-5} DOCKERFILE 5 - ALPINE LINUX, MULTI-STAGE ::: :::BlogCode{.mb-5}

FROM python:3.8-alpine as base

FROM base as builder

RUN apk update && apk add gcc python3-dev musl-dev linux-headers postgresql-dev
RUN mkdir /install
WORKDIR /install
COPY requirements.txt /requirements.txt
RUN pip install --prefix=/install -r /requirements.txt

FROM base

COPY --from=builder /install /usr/local
COPY src /app
RUN apk --no-cache add libpq
WORKDIR /app

::: :::globalParagraph Das letzte Dockerfile nutzt das Multi-Stage Pattern. Beide Stages nutzen das Alpine Linux Python Base Image. In der ersten Stage, builder, werden die benötigten Build Dependencies installiert, das Verzeichnis /install als WORKDIR genutzt sowie anschließend die pip-Requirements kopiert und installiert. Die zweite Stage kopiert nun den Inhalt aus dem /install-Verzeichnis der ersten Stage, kopiert den Code der Anwendung und installiert mit libpq noch ein Package, das für die Ausführung der Anwendung benötigt wird. :::

:::globalTitle{:size="md" .mb-5} AUSWERTUNG DER RESULTIERENDEN GRÖSSEN ::: :::globalParagraph Folgende Tabelle zeigt die resultierende Größe der Docker Images für unsere fünf Dockerfiles: :::

{.object-cover .max-w-full .mb-5}

:::globalParagraph Den quantitativ deutlichsten Sprung kann man bei der Nutzung des Alpine-basierten Base Images beobachten. Sind die beiden Debian-basierten Docker Images noch jeweils über ein Gigabyte groß, spart die Nutzung von Alpine Linux über die Hälfte ein. Das daraus resultierende Image ist nur noch knapp unter 400 Megabyte groß. Durch geschickt geschriebene Anweisungen und somit optimiertere Dockerfiles können wir die Größe sogar mehr als halbieren und sind letztendlich bei 176 Megabyte. ::: :::globalParagraph Das Multi-Stage Dockerfile liegt bei knapp 155 Megabyte. Im Vergleich zum zuvor optimierten Dockerfile haben wir hier nicht allzu viel eingespart. Das Dockerfile ist durch die verschiedenen Stages zwar etwas umfangreicher, aber auch wesentlich aufgeräumter und wie weiter oben erläutert, mit den verschiedenen Stages deutlich flexibler. Mit diesem Image sind wir bei einer Größe von gerade mal 15% des ersten naiven Debian-basierten Images angelangt. Auch im Vergleich zum naiven Alpine-basierten Image haben wir mehr als 60% eingespart. :::

:::globalTitle{:size="lg" .mb-5} UNSERE EMPFEHLUNG: MULTI-STAGE DOCKERFILES ::: :::globalParagraph Unsere ganz klare Empfehlung ist die Verwendung von Multi-Stage Dockerfiles. Wie wir bei der Evaluation beeindruckend sehen können, lässt sich die resultierende Image-Größe dadurch deutlich reduzieren. Sofern es die Gegebenheiten und die Anwendung zulassen, sollte hinsichtlich der Image-Größe auch ein Alpine-basiertes Base Image verwendet werden. ::: :::globalParagraph Aber nicht nur aufgrund der resultierenden Image-Größe können wir Multi-Stage Builds empfehlen. Vor allem die Flexibilität durch die verschiedenen Stages ist aus unserer Sicht ein großer Pluspunkt. Damit können wir unseren Entwicklungsprozess bis hin zum Production-Deployment mit nur einem Dockerfile unterstützen und müssen nicht mehrere Dockerfiles maintainen. :::

::GlobalBlogLevelInfo

• Kubernetes Basics
• Docker Basics
• HTTP Caching{target="_blank"} Basics
• Varnish HTTP Cache{target="_blank"}

Solltest du Fragen haben, oder dir etwas unklar sein, kannst du die Kommentarfunktion unter dem Artikel nutzen. ::

Warum Varnish deine Website transformiert

Performance ist alles im Web. Wenn deine Nutzer warten müssen, springen sie ab. Varnish löst dieses Problem elegant: Als HTTP-Cache sitzt er vor deiner Anwendung und liefert Inhalte blitzschnell aus dem Speicher aus. Das Ergebnis? Bis zu 90% weniger Last auf dein Backend und deutlich schnellere Ladezeiten.

Lass uns starten: Das brauchst du

Bevor wir loslegen, hier kurz die vier Dateien, die du für ein einfaches Setup benötigst:

• default.vcl: deine Varnish-Konfiguration
• Dockerfile: damit baust du dein Varnish-Image inklusive VCL
• varnish.yaml: Deployment und Service für Kubernetes
• Ingress.yaml: optional, damit deine Website über einen Domainnamen erreichbar wird

Die VCL Datei verstehen und anpassen

Schauen wir uns erstmal die einzelnen Teile der default.vcl genauer an:

backend default {
    .host = "website-svc";
    .port = "3001";
    .first_byte_timeout = 300s;
}

Der erste Block legt dein Backend fest. website-svc ist dabei der Name des Kubernetes-Services, auf den Varnish zugreift. Der Port 3001 ist der Port deiner Anwendung (zum Beispiel Django), der innerhalb des Clusters erreichbar ist. Mit first_byte_timeout stellst du ein, wie lange Varnish auf die erste Antwort vom Backend wartet.

sub vcl_recv {
    if (req.method == "GET" && req.http.Cookie !~ "sessionid") {
        unset req.http.Cookie;
    }
}

vcl_recv wird bei jeder eingehenden Anfrage aufgerufen. Hier wird entschieden, ob Cookies entfernt werden. In diesem Fall entfernt Varnish alle Cookies von GET-Requests, die nicht sessionid enthalten. Das macht Caching effektiver, weil verschiedene Cookie-Werte sonst unterschiedliche Cache-Objekte erzeugen würden.

sub vcl_backend_response {
    if (bereq.url ~ "^/de-de/aktuelles/.*") {
        set beresp.ttl = 2h;
    } else {
        set beresp.ttl = 12h;
    }
}

vcl_backend_response wird aufgerufen, wenn Varnish das Backend befragt hat und die Antwort verarbeitet. Hier legst du fest, wie lange Varnish den Inhalt cachen soll. Nachrichten-Seiten bekommen hier zum Beispiel nur 2 Stunden, alles andere bleibt 12 Stunden im Cache.

Fortgeschrittene VCL-Techniken für die Praxis

Grace Mode & Saint Mode (Backend-Ausfall überbrücken):
Mit Grace und Saint Mode kannst du veraltete Inhalte ausliefern, wenn das Backend nicht erreichbar ist. Das erhöht die Ausfallsicherheit enorm.

sub vcl_backend_fetch {
    if (beresp.status == 500 || beresp.status == 503) {
        set beresp.saintmode = 5m; // Markiere Backend für 5 Min. als "krank"
        return (abandon);
    }
    set beresp.grace = 2h; // Erlaube, diesen Inhalt 2h über seine TTL hinaus zu servieren
}

Cache-Keys anpassen:
Manipuliere den Cache-Key, um z.B. unwichtige Query-Parameter zu ignorieren und so die Hit-Rate zu erhöhen.

sub vcl_hash {
    // Nur 'id' und 'lang' für den Cache-Key berücksichtigen
    if (req.url ~ "\?") {
        set req.hash += regsuball(req.url, "^.*\?((?:id|lang)=[^&]+).*$", "\1");
    }
    // ...
}

Sicheres Purging via API:
Richte einen sicheren HTTP-Endpoint zum gezielten Leeren des Caches ein.

acl purge {
    "localhost";
    "192.168.1.0"/24; // Erlaube Purging nur aus diesem Netz
}

sub vcl_recv {
    if (req.method == "PURGE") {
        if (!client.ip ~ purge) {
            return (synth(405, "Not allowed."));
        }
        return (hash);
    }
}

Dockerfile: VCL ins Image legen

FROM varnish:stable
COPY default.vcl /etc/varnish/

So stellst du sicher, dass deine VCL immer direkt im Container liegt. Dein Image baust du anschließend mit:

docker build -t varnish:latest .

Deployment und Service definieren

Das Deployment sorgt dafür, dass dein Varnish-Pod dauerhaft läuft und Kubernetes ihn automatisch neu startet, wenn er abstürzt. In unserem Beispiel läuft nur eine Instanz (replicas: 1), für Produktionsumgebungen kannst du hier aber auch mehrere Replikas eintragen.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: varnish
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: varnish
    spec:
      containers:
      - name: varnish
        image: varnish:latest
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: varnish
spec:
  selector:
    app: varnish
  ports:
    - port: 80
      targetPort: 80

Der zugehörige Service macht deinen Pod im Cluster erreichbar. Er verbindet den Ingress oder andere Pods mit deinem Varnish-Container. Wichtig ist dabei, dass targetPort und containerPort zusammenpassen.

Super! Damit ist nun dein Pod im Cluster erreichbar.

Ingress-Konfiguration für Domain-Routing

Der Ingress ist das letzte Glied in der Kette. Er sorgt dafür, dass Anfragen aus dem Internet in deinen Cluster gelangen und dort an den richtigen Service, also deinen Varnish, weitergeleitet werden. Dadurch kannst du Domains und TLS-Zertifikate zentral verwalten.

Ein einfaches Beispiel sieht so aus:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: varnish-ingress
  annotations:
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
spec:
  ingressClassName: nginx
  rules:
  - host: "example.com"
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: varnish
            port:
              number: 80

Achte darauf, dass der Name des Services und der Port exakt zu deinem vorher definierten Service passen. So wird der komplette Webtraffic durch Varnish geschleust und deine Anwendung profitiert vom Cache.

Monitoring und Debugging

Hier noch ein paar praktische Befehle, um deinen Cache und den Varnish-Server zu überwachen und besser zu steuern:

varnishstat

Zeigt live Cache-Statistiken, zum Beispiel Hits und Misses.

varnishlog

Zeigt genau, warum Requests gecacht wurden oder nicht.

varnishadm ban "req.url ~ .*"

Damit leerst du gezielt den Cache und erzwingst neue Inhalte.

varnishadm ping

Prüft, ob dein Varnish-Admin erreichbar ist.

varnishadm status

Zeigt den aktuellen Status deines Varnish-Prozesses.

Best Practices für optimales Caching

1. Cache-Strategien definieren

• Statische Inhalte länger cachen (CSS, JS, Bilder)
• Dynamische Inhalte kürzer cachen
• Session-basierte Inhalte individuell behandeln

2. Performance-Monitoring einrichten

• Regelmäßig Cache-Hit-Rate überprüfen
• Speicherauslastung im Blick behalten
• Backend-Gesundheit überwachen

3. Cache-Invalidierung planen

• Automatisierte Prozesse für Content-Updates
• Gezielte Invalidierung statt komplettes Leeren
• Health-Checks für Backend-Server

Varnish im Vergleich: Die richtige Caching-Strategie wählen

Varnish ist extrem mächtig, aber nicht immer die einzige Lösung. Wie schlägt es sich im Vergleich zu anderen Caching-Mechanismen?

| Caching-Lösung | Stärken | Schwächen | Optimal für... | | :------------------ | :--------------------------------------------------------------------- | :--------------------------------------------------------------- | :---------------------------------------------------------------------------------------------- | | Varnish Cache | Maximale Flexibilität durch VCL; Caching von ganzen HTTP-Objekten; Features wie Grace/Saint Mode. | Höhere Komplexität als einfache Caches; kein nativer TLS-Support (benötigt einen Proxy davor). | ...komplexe Websites (z.B. E-Commerce, News-Portale) mit dynamischen Inhalten, die eine feingranulare Cache-Steuerung benötigen. | | Nginx Caching | Einfache Konfiguration; direkt im Webserver integriert; sehr performant; kann TLS terminieren. | Weniger flexible Cache-Logik als Varnish; primär für statische Assets und einfache Responses. | ...einfachere Websites und Anwendungen, bei denen ein unkomplizierter Cache für statische Dateien und API-Antworten ausreicht. | | CDN (z.B. Cloudflare) | Global verteilt (geringe Latenz weltweit); Schutz vor DDoS-Angriffen; einfaches Setup. | Kostenintensiver; weniger Kontrolle über die Cache-Invalidierung; "Blackbox". | ...global agierende Websites, die von einem verteilten Cache und zusätzlichen Sicherheitsfeatures profitieren wollen. |

Häufig gestellte Fragen (FAQ)

Wie kann ich überprüfen, ob eine Seite aus dem Varnish-Cache geladen wird?

Überprüfe die HTTP-Header der Antwort in den Entwicklertools deines Browsers. Varnish fügt typischerweise Header wie X-Varnish (interne Transaktions-ID) und Age (wie lange das Objekt im Cache liegt) hinzu. Ein Age-Wert größer als 0 ist ein sicheres Zeichen für einen Cache-Hit.

Warum ist meine Cache-Hit-Rate niedrig?

Die häufigsten Gründe sind:

1. Cookies: Varnish cacht standardmäßig keine Anfragen mit Cookies. Passe deine vcl_recv an, um unnötige Cookies zu entfernen.
2. Set-Cookie-Header vom Backend: Wenn dein Backend einen Set-Cookie-Header sendet, wird die Antwort nicht gecacht.
3. Cache-Control-Header: Achte auf Cache-Control: private oder max-age=0 vom Backend.

Wie schütze ich den Varnish-Admin-Port in Kubernetes?

Der Admin-Port sollte niemals extern erreichbar sein. Stelle sicher, dass dein Kubernetes-Service für Varnish nur den HTTP-Port (z.B. 80) freigibt. Der Zugriff auf varnishadm sollte nur über kubectl exec in den Pod erfolgen.

Wie viel RAM bzw. Speicher brauche ich für Varnish?

Das hängt stark von deinem Usage‑Profil ab. Empfohlen wird eine RAM‑Konfiguration zwischen 1 GB und 16 GB, kombiniert mit SSD‑Speicher.

Kann Varnish auch ohne Query‑Parameter cachen?

Ja, du kannst Query‑Parameter entfernen (z. B. per RegEx in VCL), um nur ein Objekt zu cachen:

sub vcl_recv {
  set req.url = regsub(req.url, "\?.*", "");
}

Wie lassen sich benutzerdefinierte Fehlerseiten konfigurieren?

Über vcl_error kannst du eigene HTML‑Seiten mit einer synthetischen Antwort erstellen. Beispiel:

sub vcl_error {
  set obj.http.Content-Type = "text/html; charset=utf-8";
  synthetic {"<html>…</html>"};
  deliver;
}

Fazit

Damit bist du jetzt komplett durch. Dein Setup von default.vcl bis zum Ingress steht und Varnish sorgt jetzt dafür, dass deine Seite deutlich schneller lädt. Mit der richtigen Konfiguration wird Varnish zum geheimen Helden deiner Website-Performance.

:GlobalButton{:url="https://varnish-cache.org" :label="Mehr über Varnish erfahren" :target="_blank" :color="blue" .mb-6}

{.object-cover .max-w-full .mb-5}

::GlobalTitle{:size="lg" .mb-5} Was ist Visual Regression Testing? :: ::GlobalParagraph Visual Regression Testing ermöglicht die Identifizierung von optischen Veränderungen basierend auf einer vorher festgelegten Basis. Diese Veränderungen beinhalten unter Umständen Regressionen, welche somit schnell und kostengünstig erkannt werden. Moderne Anwendungen beinhalten oftmals eine Menge JavaScript und CSS. Änderungen an dem Quellcode, oder auch einfache Updates können zu Seiteneffekten führen. Um diese aufzudecken, eignet sich Visual Regression Testing sehr gut. ::

::GlobalTitle{:size="lg" .mb-5} Wie funktioniert Visual Regression Testing? :: ::GlobalParagraph Das Vorgehen für VRT-Tools ist immer ähnlich: :: ::GlobalBlock{.ol-decimal .mb-4}

1. Es wird eine Menge von Komponenten oder Seiten definiert, welche zu prüfen sind.
2. Basierend darauf wird eine Baseline generiert.
3. Bei Code Änderungen und Updates werden Screenshots gemacht und diese mit der Baseline verglichen. ::

::GlobalParagraph Oftmals arbeiten Tools im Bereich des Testing für visuelle Regressionen mit einem Threshold. Das bedeutet, die Abweichung von der Baseline hat eine Toleranz - absolut oder relativ. Beispielsweise könnte man festlegen, dass 10 Pixel oder 1% Abweichung von der Baseline akzeptiert werden. :: ::GlobalParagraph Warum ist das so? - Das Rendering von Websites unterscheidet sich teilweise von Browser zu Browser sowie Betriebssystem zu Betriebssystem. Hier ist eine gewisse Toleranz ausgesprochen hilfreich. ::

::GlobalTitle{:size="lg" .mb-5} Lost Pixel in der Praxis :: ::GlobalParagraph Lost Pixel{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} ist ein Tool der Firma nineLemon. Es ist cloud-basiert. Die einfachste Integration in eine CI Pipeline lässt sich mit Github Actions realisieren. Dabei übernimmt die Lost Pixel Cloud Applikation die Verwaltung der Baseline. Die Screenshots der Baseline müssen nicht in das Repository eingecheckt werden. ::

{.mx-auto .max-w-full}

::GlobalParagraph{.italic .mb-4 .text-center} (Quelle: https://lost-pixel.com{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid}) ::

::GlobalParagraph Mit der Einbindung der bereitgestellten Github Action werden automatisch Screenshots der festgelegten Seiten/Komponenten erstellt und mit der Baseline verglichen. Die Lost Pixel Cloud Applikation bietet hier hervorragende Ansichten für den Vorher-Nachher Vergleich. ::

{.mx-auto .max-w-full}

::GlobalParagraph{.italic .mb-4 .text-center} (Quelle: https://lost-pixel.com{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} links nachher, rechts vorher) ::

::GlobalParagraph Über die simple Benutzeroberfläche lassen sich Änderungen an der Baseline akzeptieren oder ablehnen. Bei Ablehnung wird der entsprechende Pull Request auf Github als “fehlgeschlagen” markiert. ::

::GlobalTitle{:size="lg" .mb-5} Lost Pixel mit Gitlab :: ::GlobalParagraph Github Actions ist de facto die “first class citizen” Implementierung von Lost Pixel in CI Pipelines. In diesem Abschnitt möchten wir zeigen, wie wir Lost Pixel mit der Software Gitlab verwenden. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Erstellung der Baseline für Visual Regression Testing :: ::GlobalParagraph Zuerst wird die Basis erzeugt. Hierfür muss die lostpixel.config.js angelegt werden: ::

::BlogCode{.mb-4}

module.exports = {
  pageShots: {
    pages: [
      { path: '/pattern-library/render-pattern/cms/blocks/patterns/text/text.html', name: 'text', threshold: 0.01 },
    ],
    breakpoints: [320, 640, 1024, 1200, 1920],
    baseUrl: 'http://localhost:8000',
  },
  waitBeforeScreenshot: 2000,
  waitForLastRequest: 5000,
  failOnDifference: true,
  shotConcurrency: 1,
  generateOnly: true,
}

:: ::GlobalParagraph Diese Konfiguration nutzt "Page Shots". Damit werden lediglich ganzseitige Screenshots von den entsprechenden URLs gemacht. Eine detaillierte Aufstellung der Einstellungen ist hier zu finden{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid}. Der Parameter breakpoints ermöglicht es, unterschiedliche Bildschirmauflösungen gleichzeitig zu prüfen. :: ::GlobalParagraph Zur Erzeugung und zum Vergleich der Baseline nutzen wir Docker Images, um Unterschiede durch Betriebssystem oder Browser zu minimieren. Hierfür wird die Baseline folgendermaßen erzeugt: ::

::BlogCode{.mb-4}

docker run --rm -v $PWD:$PWD -e WORKSPACE=$PWD -e DOCKER=1 -e LOST_PIXEL_DISABLE_TELEMETRY=0 -e LOST_PIXEL_MODE=update --network="host" lostpixel/lost-pixel:v3.22.0

:: ::GlobalParagraph Damit wird die Baseline neu erzeugt und lokal abgelegt. Da die Lost Pixel Cloud Plattform nicht mit Gitlab nutzbar ist, müssen diese Dateien ins Git Repository eingecheckt werden. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Installation von Lost Pixel auf dem Gitlab Runner :: ::GlobalParagraph Zuallererst muss sichergestellt werden, dass Lost Pixel CLI in der Pipeline verfügbar ist: ::

::BlogCode{.mb-4}

apt-get update
apt-get install -y nodejs npm curl
npm i -g lost-pixel
npx playwright@1.47.2 install --with-deps chromium

:: ::GlobalParagraph Playwright wird in genau der Version installiert, welche für Lost Pixel benötigt wird. :: ::GlobalParagraph Playwright ist ein modernes, von Microsoft entwickeltes End-to-End-Testframework, das für das Testen von Webanwendungen genutzt wird. Es ermöglicht automatisierte UI-Tests in mehreren Browsern. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Visual Regression Testing in der CI Pipeline :: ::GlobalParagraph Die Ausführung des Vergleichs ist nun denkbar einfach. Wir starten unsere Applikation (in unserem Fall eine Django App) und führen das Kommando zum Vergleich aus: ::

::BlogCode{.mb-4}

python /app/die/manage.py serve --static &
npx lost-pixel local

:: ::GlobalParagraph Wir stellen sicher, dass die Screenshots temporär verfügbar sind um Unterschiede einfach untersuchen zu können. So können fehlgeschlagene Jobs einfach untersucht werden: :: ::BlogCode{.mb-4}

# gitlab-ci.yaml
artifacts:
  paths:
    - .lostpixel/difference/*
    - .lostpixel/current/*
  expire_in: 1 week
  when: always

:: ::GlobalParagraph Anbei ein Auszug aus eine möglichen gitlab-ci.yaml. In diesem Fall führen wir eine Django Applikationen mit einer temporär verfügbaren, lokalen Postgres Datenbank aus: :: ::BlogCode{.mb-4}

# gitlab-ci.yaml

stages:
  - lint
  - build
  - test
  - release
  - deploy

# [...]

visual_regression:
  stage: test
  image:
    name: ${TEST_IMAGE_NAME}
    docker:
      user: root
  services:
    - postgres:17-alpine
  before_script:
    - apt-get update
    - apt-get install -y nodejs npm curl
    - python die/manage.py migrate && npm i -g lost-pixel
    - npx playwright@1.47.2 install --with-deps chromium
  script:
    - python /app/die/manage.py serve --static &
    - npx lost-pixel local
  variables:
  # [...]
  artifacts:
    paths:
      - .lostpixel/difference/*
      - .lostpixel/current/*
    expire_in: 1 week
    when: always

::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Auswertung des Visual Regression Tests :: ::GlobalParagraph Sollte der Job fehlschlagen lassen sich nun die Ergebnisse in der Seitenleiste von Gitlab einfach aufrufen: ::

{.mx-auto}

::GlobalParagraph Mit einem Klick auf Durchsuchen kann die Ordnerstruktur der Artefakte durchsucht werden: ::

{.mx-auto}

::GlobalCallAnExpert{:bg="bg-bs-blue"} #buttonBlockTitle Wir können visuelle Regression Tests auch für deine App einrichten. ::

::GlobalTitle{:size="lg" .mb-5} Welche alternativen Tools gibt es für Visual Regression Testing? :: ::GlobalParagraph Neben Lost Pixel, dem Tools welches wir bei Blueshoe vornehmlich für Visual Regression Testing{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} verwenden, gibt es auch einige Alternativen: :: ::GlobalParagraph Cloud-basierte Tools :: ::GlobalBlock{.ul-disk .mb-4}

• Applitools Eyes{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} – KI-gestützte visuelle Tests mit Integration in viele Testframeworks
• Percy (by BrowserStack){:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} – Automatisierte UI-Screenshots mit GitHub-Integration
• Visual AI by LambdaTest{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} – Cloud-basierte visuelle Regressionstests
• Chromatic{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} – Speziell für Storybook-basierte UI-Tests ::

::GlobalParagraph Open-Source & Selbst-gehostete Tools :: ::GlobalBlock{.ul-disk .mb-8}

• BackstopJS{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} – Headless Browser-basierte visuelle Regressionstests
• Wraith{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} – Von BBC entwickeltes Open-Source-Tool für Screenshot-Vergleiche
• Resemble.js{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} – JavaScript-Bibliothek für pixelgenaue Bildvergleiche
• Pixelmatch{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} – Leichtgewichtige Bildvergleichsbibliothek für visuelle Regressio ::

::GlobalTitle{:size="lg" .mb-5} Fazit :: ::GlobalParagraph{.mb-4} In der heutigen agilen Entwicklungswelt ist Visual Regression Testing ein entscheidender Bestandteil der Qualitätssicherung. Es hilft, unbeabsichtigte UI-Änderungen frühzeitig zu erkennen und stellt sicher, dass neue Features oder Bugfixes keine bestehenden Designelemente zerstören. :: ::GlobalParagraph{.mb-4} Durch den Einsatz moderner Tools wie Lost Pixel können Teams visuelle Tests effizient in ihre CI/CD-Pipelines integrieren und so die Konsistenz und Benutzerfreundlichkeit ihrer Anwendungen bewahren. Besonders im Zeitalter von komplexen Webanwendungen und responsivem Design ist ein zuverlässiges visuelles Testing ein echter Gamechanger. :: ::GlobalParagraph Letztendlich spart Visual Regression Testing nicht nur Zeit und Kosten für manuelle UI-Überprüfungen, sondern trägt auch dazu bei, ein perfektes Nutzererlebnis zu gewährleisten – und das auf allen Geräten und Browsern. 🚀 ::

:::GlobalTitle{:size="lg" .mb-5 .mt-8} Häufige Fragen :::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 1. Was ist Lost Pixel und warum sollte ich es in GitLab nutzen? :: ::GlobalParagraph Lost Pixel ist ein Open-Source-Tool für visuelle Regressionstests. In GitLab-Pipelines hilft es, visuelle Unterschiede in der UI frühzeitig zu erkennen und Builds zu stoppen, wenn unerwartete Änderungen auftreten. :: ::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 2. Wie kann ich verhindern, dass nicht-relevante Änderungen Tests fehlschlagen lassen? :: ::GlobalBlock{.ul-disk .mb-4}

• Nutze --diff-threshold, um geringfügige Abweichungen zu ignorieren
• Verwende excludeSelectors, um dynamische Elemente (z. B. Datumsangaben) auszuschließen
• Stelle sicher, dass Screenshots unter identischen Bedingungen (Viewport, Theme) erstellt werden ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 3. Wie kann ich Lost Pixel mit GitLab Merge Requests kombinieren? :: ::GlobalParagraph Lost Pixel kann so konfiguriert werden, dass es bei Merge Requests ein visuelles Diff generiert und als Kommentar im MR anzeigt. Nutze dazu eine GitLab CI/CD-Integration oder externe Bots. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 4. Wie kann ich Lost Pixel so einrichten, dass nur manuell genehmigte Änderungen als neue Referenz gelten? :: ::GlobalBlock{.ul-disk .mb-4}

• Erstelle eine dedizierte baseline-Branch für Referenz-Screenshots
• Nutze einen CI/CD-Job, der nur nach Review geänderte Screenshots in die baseline-Branch merged ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 5. Warum schlägt Lost Pixel in GitLab zufällig fehl? ::

::GlobalBlock{.ul-disk .mb-4}

• Unstabile Screenshots entstehen oft durch zufällige UI-Elemente oder Animationen.
• Nutze den --wait-Parameter, um sicherzustellen, dass alle UI-Elemente gerendert wurden. ::

Was ist Open Source – und warum ist es für Unternehmen so wichtig?

Open Source bedeutet, dass der Quellcode einer Software frei zugänglich ist. Jeder darf sie nutzen, verändern und weiterverbreiten – ganz legal. Das klingt nicht nur gut, sondern revolutioniert die Art, wie Unternehmen Software einsetzen.

Immer mehr Firmen setzen auf Open-Source-Software, um Kosten zu sparen, flexibler zu arbeiten und nicht mehr von proprietären Anbietern abhängig zu sein. Doch was genau macht Open Source so attraktiv – und welche Herausforderungen gibt’s?

Die Vorteile von Open-Source-Software für Unternehmen

Kosteneffizienz durch Lizenzfreiheit

Einer der größten Pluspunkte: Keine Lizenzkosten. Proprietäre Software frisst oft einen großen Teil des IT-Budgets. Mit Open Source sparst du dir nicht nur die Lizenz, sondern auch teure Upgrades und versteckte Gebühren.

Flexibilität & Anpassbarkeit

Du hast die Kontrolle:

• Der Quellcode gehört dir. Du kannst Funktionen anpassen, erweitern oder ganz neu entwickeln.
• Statt dich an Anbieter-Roadmaps zu halten, baust du deine Software so, wie sie zu deinem Geschäftsmodell passt.

Vendor Lock-in? Nicht mit Open Source

Proprietäre Software macht’s schwer, das System zu wechseln. Bei Open Source ist das anders: Du kannst selbst entscheiden, ob du Cloud, On-Premise oder Hybrid willst – ohne dich an einen Anbieter wie AWS oder Azure zu binden. Beispiel: Tools wie Kubernetes oder OpenStack ermöglichen genau das. Bei Blueshoe setzen wir gezielt auf Docker und Kubernetes, um skalierbare, containerisierte Lösungen zu bauen – flexibel, effizient, zukunftssicher.

Schnellere Innovation dank Open-Source-Community

Die Community schläft nie. Weltweit arbeiten Entwickler*innen an neuen Features, Bugfixes und Sicherheitsupdates – oft schneller als bei kommerziellen Anbietern. Tools wie Kubernetes, Django, Vue.js oder Next.js bieten dir modernste Entwicklungsmöglichkeiten – ohne Lizenzbindung.

Bei Blueshoe kombinieren wir Vue.js / Nuxt.js im Frontend mit Django / Wagtail im Backend. So bauen wir flexible Webanwendungen mit Open-Source-Stack, die du jederzeit erweitern kannst.

Open Source heißt auch: Cloud-Native & skalierbar

Skalierbarkeit ist heute Pflicht. Und genau dafür ist Open-Source-Software gemacht: Technologien wie Docker und Kubernetes sind Cloud-native von Anfang an und machen dich unabhängig von starren Plattformen.

Ob du in kleinen Schritten wächst oder riesige Plattformen betreibst – mit Open Source kannst du deine IT-Infrastruktur flexibel skalieren.

Herausforderungen – und wie du sie löst

Support & Wartung

Nicht jede Open-Source-Software bringt professionellen Support mit. Aber keine Panik: Lösung: Setze auf einen erfahrenen Partner wie Blueshoe. Wir übernehmen Support, Wartung und Weiterentwicklung – ganz ohne Lizenzvertrag.

Updates & Sicherheit

Sicherheitslücken? Die gibt’s überall. Aber bei Open Source trägst du die Verantwortung für regelmäßige Updates und Patches.

Unsere Lösung: Mit automatisierter Wartung und Sicherheitsprozessen sorgen wir bei Blueshoe dafür, dass deine Software sicher bleibt – dauerhaft.

::GlobalCallAnExpert{:bg="bg-bs-blue"} #buttonBlockTitle Wenn Du mehr über Open-Source Software erfahren willst ... ::

Open-Source-Software-Beispiel: So gelingt der Umstieg

Du willst wissen, wie ein Wechsel zu Open Source in der Praxis aussieht? Hier ein typisches Beispiel:

Best Practices für Open-Source-Integration in Unternehmen

Damit Open Source richtig fliegt, braucht’s eine klare Strategie. Hier unsere Tipps:

1. Schrittweise einführen: Pilotprojekte starten und Erfahrungen sammeln.
2. Internes Know-how aufbauen: Entwicklerteams mit Open-Source-Skills ausstatten.
3. API-first denken: Integration in bestehende Systeme clever planen.
4. Security ernst nehmen: Regelmäßige Updates, Backups & Security-Scans.
5. Experten ins Boot holen: Blueshoe begleitet dich mit Beratung & Support.

Fazit: Open Source = Unabhängigkeit + Effizienz

Open-Source-Software bietet Unternehmen zahlreiche Vorteile – von Kosteneinsparungen über mehr Flexibilität bis hin zu erhöhter Sicherheit. Mit der richtigen Strategie lassen sich mögliche Herausforderungen problemlos bewältigen. Wer Open Source gezielt einsetzt, kann sich unabhängiger aufstellen und langfristig effizienter arbeiten. Unternehmen, die auf Open Source setzen, gewinnen nicht nur technologische Freiheit, sondern auch einen nachhaltigen Wettbewerbsvorteil.

Bei Blueshoe begleiten wir Unternehmen dabei, Open-Source-Technologien erfolgreich in ihre Prozesse zu integrieren – von der Entwicklung skalierbarer Webanwendungen mit Wagtail CMS bis hin zur Umsetzung moderner Cloud-Architekturen mit Docker und Kubernetes. Sprich uns an und erfahre, wie wir Open Source für dein Unternehmen optimal nutzen können!

FAQ – Häufige Fragen zu Open-Source Sofware

1. Was ist Open Source?

Open Source bedeutet, dass der Quellcode einer Software öffentlich zugänglich ist. Unternehmen können ihn einsehen, anpassen und weiterentwickeln – ohne teure Lizenzgebühren. Das fördert Innovation, Transparenz und Sicherheit.

2. Was ist Open-Source-Software?

Open-Source-Software (OSS) ist Software, die von einer Community entwickelt wird und frei genutzt werden kann. Beispiele sind Linux, Kubernetes, Nextcloud oder Odoo.

3. Was ist die Bedeutung von Open Source für Unternehmen?

Für Unternehmen bedeutet Open Source mehr Freiheit, geringere Kosten und keine Abhängigkeit von einem Anbieter (Vendor Lock-in). Zudem ermöglicht Open Source eine flexible IT-Strategie und bessere Sicherheitskontrolle.

4. Was sind Beispiele für Open-Source-Software in Unternehmen?

Hier sind einige Open-Source-Software-Beispiele für Unternehmen:

• ERP & CRM: Odoo, ERPNext, SuiteCRM
• Cloud & Hosting: OpenStack, Kubernetes
• Sicherheit: WireGuard (VPN), OpenSSL, Vault
• Webentwicklung: Django, Vue, FastAPI, Nuxt

5. Welche Best Practices gibt es für die Open-Source-Integration in Unternehmen?

✔ Schrittweise Einführung: Erst einzelne Open-Source-Lösungen testen, dann erweitern.
✔ Interne Expertise aufbauen: IT-Teams schulen, Open-Source-Strategie definieren.
✔ APIs & Middleware nutzen: Open Source nahtlos mit bestehenden Systemen verbinden.
✔ Sicherheitsupdates priorisieren: Automatische Updates & Security-Checks einrichten.
✔ Mit Open-Source-Partnern zusammenarbeiten: Experten für Support & Wartung einbinden (z. B. Blueshoe 😉).

6. Ist Open-Source-Software wirklich sicher?

Ja, Open Source kann sogar sicherer als proprietäre Software sein!
✅ Transparenter Code → Sicherheitslücken können geprüft & schneller geschlossen werden.
✅ Regelmäßige Updates → Community & Unternehmen verbessern die Software kontinuierlich.
✅ Keine versteckten Hintertüren → Proprietäre Software kann versteckte Schwachstellen haben.

::GlobalBlogLevelInfo

• IPSec{:target="_blank"} und VPN
• Strongswan{:target="_blank"}
• Internet Key Exchange (IKE){:target="_blank"}

Solltest du Fragen haben, oder dir etwas unklar sein, kannst du die Kommentarfunktion unter dem Artikel nutzen. ::

1. Problemstellung

Manchmal steht eine wichtige Datenbank nicht im eigenen Cluster, sondern hinter einer Firewall auf einem externen Server. Der Zugriff erfolgt nur über ein VPN – zum Beispiel via IPSec mit einer WatchGuard-Appliance. Die Herausforderung: Wie erreichen Anwendungen im Cluster diesen Service zuverlässig und sicher?

2. Zielbild

Ziel war es, eine schlanke und wartbare Lösung zu schaffen, die:

• von innerhalb des Clusters auf fest definierte externe Services via VPN zugreifen kann,
• klar zwischen Staging- und Produktionszugängen unterscheidet,
• flexibel konfigurierbar bleibt,
• mit Kubernetes-Standards arbeitet (Probes, Services, ConfigMaps etc.).

3. Lösungsidee

Wir haben einen dedizierten Pod mit Strongswan und Nginx aufgesetzt:

• Strongswan übernimmt den Aufbau des IPSec-Tunnels zum externen VPN-Endpunkt.
• Nginx fungiert als TCP-Proxy und leitet Anfragen aus dem Cluster an den externen Service weiter.
• Je nach Umgebung (Staging oder Production) wird der Nginx entsprechend konfiguriert.

Innerhalb des Clusters können andere Services einfach via ClusterIP auf den Nginx zugreifen, der dann die Verbindung über das VPN übernimmt.

4. Umsetzung in Kubernetes

a) Dockerfile

Im Container laufen Nginx und Strongswan nebeneinander. Ein Startscript entscheidet je nach ENVIRONMENT-Variable, welche Konfigurationsdateien verwendet werden.

FROM nginx:1.27.3-alpine
RUN apk add --no-cache strongswan netcat-openbsd
...
CMD ["/scripts/startup.sh"]

b) Nginx-Konfiguration

Für Production gibt es eine einzige TCP-Weiterleitung (z. B. auf Port 8080), im Staging sind es zwei (8080 + 8081 für Prod/Staging).

stream {
  upstream ext-db-production {
    server NGINX_EXTDB_IP_PRODUCTION:NGINX_EXTDB_PORT_PRODUCTION;
  }
  server {
    listen 8080;
    proxy_pass ext-db-production;
  }
  ...
}

::GlobalCallAnExpert{:bg="bg-bs-blue"} #buttonBlockTitle Wir können auch Deine Kubernetes Apps per VPN verbinden. ::

c) VPN-Setup mit Strongswan

Der Tunnel wird über swanctl.conf und Umgebungsvariablen dynamisch konfiguriert. So können IP-Adressen, PSK und Subnetze per Helm Template eingespielt werden.

connections {
   k8s-ext-db {
      remote_addrs = SWANCTL_CONF_REMOTE_ADDRS

      local {
         auth = psk
         id = SWANCTL_CONF_LOCAL_ID
      }
      remote {
         auth = psk
      }
      children {
         net-net {
            local_ts  = SWANCTL_CONF_LOCAL_TS
            remote_ts = SWANCTL_CONF_REMOTE_TS
            esp_proposals = SWANCTL_CONF_ESP_PROPOSALS
            ...
         }
      }
      version = 2
      proposals = SWANCTL_CONF_PROPOSALS
      ...
   }
}

secrets {
   ike-k8s-nors {
      id-k8s = SWANCTL_CONF_LOCAL_ID
      secret = SWANCTL_CONF_SECRET_PSK_TOKEN
   }
}

Die großgeschriebenen Variablen in allen Config-Dateien werden vom Startup Script mit Werten aus den Umgebungsvariablen ersetzt. Dadurch kann der Pod für verschiedene Umgebungen dynamisch konfiguriert werden. Die Werte könnten natürlich auch direkt angegeben werden.

Das Startup Script führt dann nur noch folgende Commands aus um die VPN Verbindung aufzubauen:

swanctl --load-all
ipsec up k8s-ext-db

d) Health-Probes

Ein Shell-Skript prüft regelmäßig:

• ob die VPN-Ziel-IP erreichbar ist: nc -z -w 1 $PROBE_STRONGSWAN_IP $PROBE_STRONGSWAN_PORT
• ob der interne Nginx eine /healthz-Route bedient: curl -f -LI $PROBE_NGINX_IP:$PROBE_NGINX_PORT/healthz

Nur wenn beide Bedingungen erfüllt sind, wird der Exit-Code 0 zurückgeben. Damit lassen sich die Pods gut in Kubernetes überwachen und restarten, falls etwas hängt.

5. Besonderheiten

• Der Pod benötigt die NET_ADMIN-Capability, damit Strongswan Routing-Tables setzen darf.
• Production und Staging unterscheiden sich nicht nur in den Zielsystemen, sondern auch in der Menge der angebundenen externen Dienste.
• Der gesamte Tunnel läuft in einem dedizierten Service – andere Pods im Cluster brauchen davon nichts zu wissen.

6. Pod Manifest

Hier ein Beispiel für das Pod-Manifest:

apiVersion: v1
kind: Pod
metadata:
  name: vpn-client
  namespace: vpn
spec:
  containers:
  - name: vpn
    image: your-vpn-image:1.0.0
    imagePullPolicy: Always
    envFrom:
    - configMapRef:
        name: vpn-client-configmap
    ports:
    - containerPort: 8080
      name: ext-db-prod
      protocol: TCP
    livenessProbe:
      exec:
        command:
        - /scripts/probe.sh
      failureThreshold: 3
      periodSeconds: 10
      successThreshold: 1
      timeoutSeconds: 2
    readinessProbe:
      exec:
        command:
        - /scripts/probe.sh
      failureThreshold: 1
      periodSeconds: 10
      successThreshold: 1
      timeoutSeconds: 2
    startupProbe:
      exec:
        command:
        - /scripts/probe.sh
      failureThreshold: 40
      periodSeconds: 5
      successThreshold: 1
      timeoutSeconds: 2
    securityContext:
      capabilities:
        add:
        - NET_ADMIN

7. Fazit

Die Kombination aus Strongswan und Nginx ist eine robuste, leichtgewichtige Möglichkeit, externe Dienste über VPN in Kubernetes anzubinden. Die strikte Trennung nach Umgebungen, flexible Helm-Templates und Kubernetes-Probes machen die Lösung production-ready – ohne Overhead durch zusätzliche Tools.

8. Häufige Fragen

1. Warum brauche ich ein VPN in Kubernetes?

Ein VPN ermöglicht sichere Verbindungen zwischen deinem Cluster und externen Systemen, etwa Datenbanken oder Legacy-Systemen, die nicht öffentlich erreichbar sind. Es ist besonders sinnvoll, wenn sensible Daten übertragen werden oder direkte IP-Kommunikation erforderlich ist.

2. Was ist StrongSwan und warum eignet es sich für Kubernetes?

StrongSwan ist eine etablierte Open-Source-VPN-Lösung für IPsec-basierte Tunnel. Sie ist leichtgewichtig, zuverlässig und lässt sich durch ihre Modularität gut in containerisierte Umgebungen wie Kubernetes integrieren.

3. Wie integriere ich StrongSwan in Kubernetes?

StrongSwan kann als dediziertes Deployment in einem Pod betrieben werden. Über eine angepasste Netzwerkkonfiguration und iptables-Routing wird der Traffic durch das VPN geleitet. NGINX oder andere Proxies übernehmen dabei das Routing zum Zielsystem über das VPN.

4. Gibt es Helm-Charts für StrongSwan in Kubernetes?

Nein, es gibt keine offiziellen Helm-Charts. Die meisten Setups nutzen eigene Deployments mit Docker-Images, Konfigurationsdateien und init-Skripten. Das kann zwar mühselig sein, ermöglicht aber maximale Flexibilität bei der VPN-Einrichtung.

5. Welche Alternativen zu StrongSwan gibt es?

Je nach Anforderungen kannst du auch WireGuard (modern, schnell), OpenVPN (bewährt, aber komplexer) oder VPN-Services von Cloud-Anbietern wie AWS Site-to-Site VPN oder Azure VPN Gateway einsetzen.

In diesem Artikel erklären wir, wie Vue Vapor funktioniert, welche Vorteile es gegenüber dem bisherigen Vue.js 3 Virtual DOM bringt, und worauf du als Entwickler achten solltest, um das volle Performance-Potenzial zu entfalten. Außerdem vergleichen wir Vue Vapor vs. Vue 3, und werfen einen Blick auf moderne Konzepte wie Partial Hydration und server-driven UI.

Einleitung: Eine neue Ära für Vue

Mit Vue Vapor läutet das Vue-Core-Team ein neues Kapitel in der Geschichte des beliebten Frameworks ein. Statt sich wie bisher auf den Virtual DOM zu verlassen, geht Vue Vapor einen radikal anderen Weg: Es setzt auf Compile-Time Optimierungen und ein vollständig DOM-basiertes Rendering – ganz ohne diffing, patching oder VDOM-Abgleich.

Das Ziel? Maximale Performance bei minimalem Overhead.

:GlobalButton{:url="/technologien/vuejs-nuxt/" :label="Du willst Vue.js richtig einsetzen – Wir helfen dir dabei!" :target="_blank" :color="blue" .mb-6}

Warum Vue den Virtual DOM über Bord wirft

Der Virtual DOM war lange Zeit ein cleverer Kompromiss: Er ermöglichte eine deklarative Programmierweise, ohne direkt mit dem echten DOM zu arbeiten. Doch dieser Ansatz bringt auch Nachteile mit sich:

• Performance-Kosten beim Vergleichen von VDOM und realem DOM (Diffing)
• Zusätzlicher Speicherverbrauch durch Virtual Node-Strukturen
• Komplexität bei größeren Komponentenbäumen

Mit zunehmenden Anforderungen an Ladezeit, Energieeffizienz (z. B. auf mobilen Geräten) und Interaktivität (z. B. in E-Commerce oder SaaS) wurde klar: Der VDOM ist nicht mehr der schnellste Weg zum Ziel.

Was ist Vue Vapor?

Vue Vapor ist eine neue Rendering Engine für Vue.js, die vollständig VDOM-frei arbeitet. Sie basiert auf einem intelligenten Compile-Time-Ansatz, der den Code beim Build analysiert und exakt den minimal notwendigen DOM-Code generiert. Statt allgemeiner "diffbarer" Komponenten entsteht präziser, spezialisierter Output.

Kernmerkmale von Vue Vapor:

• Kein Virtual DOM → keine Diffing-Operationen zur Laufzeit
• Statisch analysierter & kompilierter DOM-Code
• Minimaler JavaScript-Overhead
• Automatische Optimierungen für SSR, CSR & Hydration
• Integration mit modernen Patterns wie Partial Hydration & Server-driven UI

Wie funktioniert das in der Praxis?

Statt eine generische Render-Funktion zu erzeugen, analysiert der Vue-Vapor-Compiler die Komponente bereits beim Build. Dabei werden Reaktivität, bedingte Renderpfade, Loops und sogar Event-Handler optimiert und "hart verdrahtet" in DOM-Manipulationen umgewandelt.

Beispiel: Button-Komponente mit Vue Vapor

<!-- herkömmliche Vue-Komponente -->
<script setup lang="ts">
const count = ref(0)
</script>

<template>
  <button @click="count++">
    Clicked {{ count }} times
  </button>
</template>

Ergibt mit Vue 3 eine render-Funktion mit VDOM-Diffing. Mit Vue Vapor hingegen wird direkt generierter DOM-Code erzeugt, der weiß: Nur textContent dieses einen DOM-Nodes muss bei Änderung aktualisiert werden – nichts weiter.

Performance-Vergleich: Vue 3 vs. Vue Vapor

Statt auf diffbasierte Updates zur Laufzeit zu setzen, erzeugt Vue Vapor bereits beim Build optimierten DOM-Code. Das reduziert JavaScript-Overhead und macht das Rendering besonders bei komplexen oder dynamischen Komponenten spürbar effizienter.

Während Vue 3 auf den bewährten Virtual DOM setzt, verfolgt Vue Vapor einen radikal anderen Ansatz – mit klaren Vorteilen bei initialem Rendern, Hydration und Speicherverbrauch.

Erste Tests und Erfahrungsberichte aus der Community deuten auf eine deutlich bessere Performance hin, insbesondere im SSR-Kontext und bei mobilen Anwendungen. Offizielle, reproduzierbare Benchmarks des Vue-Core-Teams stehen aktuell jedoch noch aus.

Was Entwickler jetzt beachten müssen

Vue Vapor ist opt-in. Du entscheidest, ob du es aktivierst – aktuell noch experimentell, aber bereits stabil genug für Tests und neue Projekte. Voraussetzungen:

• Vue ≥ 3.5 (Vapor Preview)
• @vue/compiler-vapor als zusätzliche Dependency
• Komponenten müssen Single File Components (SFCs) sein
• Keine dynamischen Komponenten oder $refs auf Root-Ebene
• SSR/CSR-Hybrid-Projekte sollten auf Partial Hydration achten

👉 Wichtig: Einige Features wie v-html, dynamische Komponenten oder nicht-deterministisches Verhalten (z. B. Math.random()) sind mit Vapor nicht kompatibel – zumindest nicht ohne Workarounds.

Moderne Konzepte: Partial Hydration & Server-driven UI

::GlobalCallAnExpert{:bg="bg-bs-blue"} #buttonBlockTitle Wir können auch Deine Vue und Nuxt Apps beschleunigen ::

Partial Hydration

Vue Vapor spielt perfekt mit Partial Hydration zusammen. Hierbei wird nur der interaktive Teil einer Seite hydratisiert – der Rest bleibt statisch. Das spart Ladezeit und vermeidet unnötige JavaScript-Ausführung.

Server-driven UI

Mit serverseitiger Steuerung von UI-Elementen (z. B. über JSON-Payloads oder ViewModel-Strukturen) wird Vue Vapor zur idealen Grundlage für headless-optimierte Frontends. Du renderst, was gebraucht wird – und sonst nichts.

Fazit: Warum Vue Vapor ein echter Gamechanger ist

Vue Vapor zeigt, wie modernes Frontend ohne VDOM funktionieren kann – schneller, schlanker, intelligenter. Für Performance-kritische Anwendungen (z. B. E-Commerce, Dashboards, PWAs) ist es eine vielversprechende Zukunftstechnologie.

Unser Tipp: Jetzt testen, lernen und den Kopf auf die Post-VDOM-Zukunft ausrichten. Der Unterschied ist nicht nur messbar – er ist spürbar.

FAQ – Häufige Fragen zu Vue Vapor

Was ist Vue Vapor?

Vue Vapor ist eine neuartige Rendering-Engine aus dem Vue-Ökosystem, die vollständig auf den Virtual DOM verzichtet. Stattdessen setzt sie auf einen Compiler-first-Ansatz, der direkt optimierten DOM-Code erzeugt – für maximale Performance und minimalen Overhead.

Warum verzichtet Vue Vapor auf den Virtual DOM?

Der klassische Virtual DOM erzeugt zusätzlichen Rechenaufwand beim DOM-Diffing. Vue Vapor eliminiert diesen Schritt, indem es schon zur Build-Zeit den effizientesten DOM-Code generiert. Das macht das Rendering deutlich schneller, besonders bei großen oder interaktiven Anwendungen.

Wie unterscheidet sich Vue Vapor von Vue 3?

Vue 3 verwendet weiterhin den Virtual DOM. Vue Vapor hingegen ersetzt diesen durch eine statisch analysierte Rendering-Strategie, die keinen diffing-basierten Vergleich mehr benötigt. Das Ergebnis: Weniger Speicherverbrauch und ein spürbarer Performance-Boost bei typischen Vue-Anwendungen.

Ist Vue Vapor bereits für Produktionsprojekte geeignet?

Aktuell befindet sich Vue Vapor noch im experimentellen Stadium. Es richtet sich primär an Entwickler, die Cutting-Edge-Technologien evaluieren möchten. Für stabile Produktivumgebungen bleibt Vue 3 derzeit der empfohlene Standard.

Kann ich Vue Vapor mit Nuxt verwenden?

Noch nicht. Derzeit basiert Nuxt vollständig auf Vue 3. Eine Integration von Vue Vapor ist mittelfristig denkbar – vor allem, wenn es eine stabile Version und offizielle Unterstützung durch das Nuxt-Team gibt.

Welche Alternativen gibt es zu Vue Vapor?

Ähnliche Ansätze verfolgen z. B. React Server Components, SvelteKit oder Qwik. Alle zielen auf bessere Frontend-Performance durch reduzierten Overhead und intelligentere Hydration-Strategien – jedoch mit unterschiedlichen Architekturen und Philosophien.

Was ist Prop Drilling in Vue.js?

Prop Drilling bedeutet, dass Daten von einer übergeordneten Komponente (Parent) durch mehrere Zwischen Komponenten hindurch an eine tiefer liegende Komponente (Child) weitergereicht werden.

Beispiel für Prop Drilling

Angenommen, eine tief liegende Komponente benötigt eine Information von einer übergeordneten Komponente:

<!-- App.vue -->
<script setup>
import { ref } from 'vue';
import ParentComponent from './ParentComponent.vue';

const username = ref('Max');
</script>
<template>
  <ParentComponent :username="username" />
</template>

<!-- ParentComponent.vue -->
<script setup>
import ChildComponent from './ChildComponent.vue';

defineProps(['username']);
</script>

<template>
  <ChildComponent :username="username" />
</template>

<!-- ChildComponent.vue -->
<script setup>
defineProps(['username']);
</script>

<template>
  <p>Hallo, {{ username }}!</p>
</template>

Hier wird username von App.vue über ParentComponent.vue an ChildComponent.vue weitergereicht – selbst wenn ParentComponent den Wert gar nicht benötigt.

Warum solltest du Prop Drilling in Vue vermeiden?

In kleinen Projekten geht’s vielleicht noch – aber spätestens, wenn dein Code wächst, wirst du es bereuen. Hier die größten Pain Points beim Prop Drilling in Vue.js:

❌ Unübersichtlicher Code: Wenn eine Prop durch viele Komponenten weitergereicht wird, kann es schwierig werden, den Datenfluss nachzuvollziehen.
❌ Hoher Wartungsaufwand: Falls sich eine Prop ändert, müssen alle beteiligten Komponenten angepasst werden.
❌ Geringe Wiederverwendbarkeit: Komponenten werden unnötig voneinander abhängig, da sie Daten weitergeben müssen, die sie gar nicht selbst nutzen.

Wenn du Vue.js Best Practices suchst, führt kein Weg daran vorbei: Prop Drilling vermeiden, wo immer es geht.

:GlobalButton{:url="/technologien/vuejs-nuxt/" :label="Du willst Vue.js richtig einsetzen – Wir helfen dir dabei!" :target="_blank" :color="blue" .mb-6}

Vue.js Datenfluss optimieren – Alternativen zu Prop Drilling

Zum Glück bietet Vue verschiedene Lösungen, um Daten effizient weiterzugeben, ohne sie durch jede Zwischenkomponente zu schleifen.

1. provide und inject in Vue.js - Die eingebaute Lösung

Vue bietet mit provide und inject eine native Möglichkeit, Daten an tiefer liegende Komponenten weiterzugeben.

Beispiel mit provide und inject

<!-- App.vue -->
<script setup>
import { provide, ref } from 'vue';
import ChildComponent from './ChildComponent.vue';

const username = ref('Max');
provide('username', username);
</script>

<template>
  <ChildComponent />
</template>

<!-- ChildComponent.vue -->
<script setup>
import { inject } from 'vue';

const username = inject('username');
</script>

<template>
  <p>Hallo, {{ username }}!</p>
</template>

Vorteile von mit provide und inject:

✅ Keine unnötigen Props in Zwischenkomponenten
✅ Bessere Struktur und Lesbarkeit
✅ Ideal für Themes, Lokalisierung, Form Handling

Nachteile:

⚠️ Funktioniert nur innerhalb eines Komponentenbaums
⚠️ Datenfluss ist weniger offensichtlich

Trotzdem: Für kleinere bis mittlere Projekte eine super Lösung, um Prop Drilling in Vue zu vermeiden.

2. State Management mit Pinia

Für größere Anwendungen ist ein State-Management-Tool wie Pinia{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid}) eine noch bessere Alternative.

Beispiel mit Pinia

Zunächst muss Pinia installiert werden:

yarn add pinia
# or
npm install pinia

Dann wird ein Store erstellt:

// stores/user.ts
import { defineStore } from 'pinia';
import { ref } from 'vue';

export const useUserStore = defineStore('user', () => {
  const username = ref<string>('Max');

  return {
    username,
  };
});

Nun kann der Store in jeder Komponente genutzt werden:

<!-- ChildComponent.vue -->
<script setup>
import { useUserStore } from '@/stores/user';

const userStore = useUserStore();
</script>

<template>
  <p>Hallo, {{ userStore.username }}!</p>
</template>

Vorteile von Pinia:

✅ Zentrale Verwaltung aller Zustände
✅ Kein Prop Drilling
✅ Perfekt für große, komplexe Vue-Projekte

Mit Pinia kannst du deinen Vue.js Datenfluss optimieren und den Code endlich entkoppeln und skalieren.

Fazit: So vermeidest du Prop Drilling in Vue.js richtig

Prop Drilling kann zu unübersichtlichem Code und hohem Wartungsaufwand führen. Glücklicherweise bietet Vue mit provide/inject und Pinia bessere Alternativen für saubere und wartbare Datenflüsse.

• Für kleinere Projekte ist provide/inject oft schon genug.
• Bei größeren Projekten kommst du an einem sauberen State Management mit Pinia nicht vorbei.

Mit der richtigen Methode lässt sich Prop Drilling vermeiden, wodurch eine bessere Code-Struktur und Wartbarkeit sichergestellt wird.

Beide Lösungen helfen dir, vue.js best practices umzusetzen und deinen Komponentenbaum zu entwirren.

FAQ – Häufige Fragen zu Prop Drilling in Vue

1. Wann ist Prop Drilling okay?

Prop Drilling ist in Ordnung, wenn eine Prop nur durch eine oder zwei Komponenten weitergereicht wird und keine komplexen Datenstrukturen involviert sind. In kleinen Projekten kann es eine einfache Lösung sein, ohne zusätzlichen Code für State-Management oder provide/inject.

2. Wann sollte provide und inject anstelle von Props verwendet werden?

Diese Methode eignet sich besonders für global relevante Daten wie Theme-Einstellungen, Übersetzungen oder übergeordnete Form-Validierungen. Sie ist ideal, wenn Daten an viele untergeordnete Komponenten weitergegeben werden sollen, ohne unnötige Prop-Ketten zu erzeugen.

3. Wann ist Pinia die bessere Lösung?

Pinia sollte verwendet werden, wenn mehrere Komponenten unabhängig voneinander auf denselben Zustand zugreifen müssen. Es ist besonders nützlich für Benutzerverwaltung, Warenkörbe oder größere Anwendungen, in denen Daten aus verschiedenen Bereichen der Anwendung benötigt werden.

4. Kann provide und inject mit Pinia kombiniert werden?

Ja! Beispielsweise kann provide genutzt werden, um eine Instanz eines Pinia-Stores nur innerhalb eines bestimmten Komponentenbaums zu überschreiben, ohne den globalen Zustand zu verändern.

5. Gibt es noch andere Alternativen zur Datenweitergabe?

Ja. Je nach Anwendungsfall können Composables genutzt werden, um wiederverwendbare Logik und State zu kapseln. In seltenen Fällen kann auch ein Event Bus sinnvoll sein, insbesondere wenn Ereignisse zwischen nicht direkt verwandten Komponenten ausgetauscht werden müssen.

{.object-cover .max-w-full .mb-5}

::GlobalTitle{:size="lg" .mb-5} Was ist Wagtail Localize? :: ::GlobalParagraph Wagtail{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} ist ein leistungsfähiges Django CMS zur Verwaltung von Webinhalten. Wenn du eine mehrsprachige Webseite betreiben willst, hilft dir Wagtail Localize{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid}, Inhalte einfach zu übersetzen und zu verwalten. ::

::GlobalParagraph Mit Wagtail Localize kannst du: ::

::GlobalBlock{.ul-disk .mb-4}

• Mehrsprachige Inhalte direkt in der Wagtail-Admin-Oberfläche verwalten
• Automatische oder manuelle Übersetzungen nutzen
• Übersetzungsworkflows und lokale Anpassungen (z. B. für SEO) steuern
• Mehrsprachige Webseiten SEO-optimiert und effizient aufbauen ::

:::GlobalButton{:url="/technologien/wagtail-cms/" :label="Du möchtest dein Wagtail-Projekt auf den Weg bringen? Erfahre, wie Wagtail deine Webprojekte schneller, flexibler und skalierbar macht." :target="_blank" :color="blue" .mb-6} :::

::GlobalTitle{:size="lg" .mb-5} Installation und Erste Schritte ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 1. Wagtail Localize installieren ::

::GlobalParagraph Installiere das Paket mit pip: ::

::BlogCode{.mb-5}

pip install wagtail-localize

::

::GlobalParagraph Füge wagtail_localize in die INSTALLED_APPS deiner settings.py ein: ::

::BlogCode{.mb-5}

INSTALLED_APPS = [
    "wagtail_localize",
    "wagtail_localize.locales",  # Ermöglicht die Verwaltung mehrsprachiger Inhalte
    "wagtail.contrib.modeladmin",
    *INSTALLED_APPS,
]

:: ::GlobalParagraph Führe die Migrationen aus: ::

::BlogCode{.mb-5}

python manage.py migrate wagtail_localize

::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 2. Sprachen konfigurieren ::

::GlobalParagraph In settings.py definierst du die unterstützten Sprachen: :: ::BlogCode{.mb-5}

from django.utils.translation import gettext_lazy as _

LANGUAGES = [
    ("en", _("English")),
    ("de", _("Deutsch")),
    ("fr", _("Français")),
]

WAGTAIL_CONTENT_LANGUAGES = LANGUAGES

::

::GlobalParagraph Aktiviere die Mehrsprachigkeitsoption in Wagtail: ::

::BlogCode{.mb-5}

WAGTAIL_I18N_ENABLED = True

::

::GlobalTitle{:size="lg" .mb-5} Mehrsprachige Seiten in Wagtail verwalten ::

::GlobalParagraph Wagtail verwaltet mehrsprachige Seiten automatisch über Locales. Dafür erstellt Wagtail für jede Sprache eine separate Version der Seite, die du erstellt hast. Die Sprachen und Seiten können über die Admin-Oberfläche verwaltet werden. Die Sprachverwaltung kannst du an folgenden Screenshot sehen: ::

{.mx-auto .max-w-full}

::GlobalParagraph Um jetzt in Wagtail Custom-Seiten anzulegen, genügt es, das normale Page-Modell zu benutzen. ::

::GlobalParagraph Beispiel einer mehrsprachigen Seite: ::

::BlogCode{.mb-5}

from wagtail.models import Page
class CustomPage(Page):
    pass

::

::GlobalParagraph Diese Klasse wird dann automatisch von Wagtail Localize verwaltet und kann in verschiedenen Sprachen im Seitenmenü angelegt werden. ::

{.mx-auto .max-w-full}

::GlobalParagraph Jetzt hast du bereits alles, um erste Seiten in mehreren Sprachen zu verwalten! Es gibt aber noch mehr. ::

::GlobalTitle{:size="lg" .mb-5} Wann brauchst du TranslatableMixin? :: ::GlobalParagraph Falls du Snippets oder andere Datenmodelle mehrsprachig verwalten willst, nutze TranslatableMixin{:target="_blank" .bs-link-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid}. :: ::GlobalParagraph Beispiel für ein übersetzbares Snippet (z. B. eine Personen-Datenbank): ::

::BlogCode{.mb-5}

from wagtail.snippets.models import register_snippet
from wagtail_localize.models import TranslatableMixin
from django.db import models
from wagtail.admin.panels import FieldPanel
from django.utils.translation import gettext_lazy as _

@register_snippet
class Person(TranslatableMixin, models.Model):
    first_name = models.CharField(max_length=200)
    last_name = models.CharField(max_length=200)
    email = models.EmailField(blank=True, null=True)
    job_function = models.CharField(_("Function"), max_length=400, blank=True, null=True)
    job_function_international = models.CharField(_("Function international"), max_length=400, blank=True, null=True)
    image = models.ForeignKey("wagtailimages.Image", null=True, blank=True, on_delete=models.SET_NULL, related_name="+")
    phone = models.CharField(_("Phone"), max_length=200, blank=True, null=True)
    mobile = models.CharField(_("Mobile"), max_length=200, blank=True, null=True)
    country = models.CharField(_("Country"), max_length=200, blank=True, null=True)

    panels = [
        FieldPanel("first_name"),
        FieldPanel("last_name"),
        FieldPanel("email"),
        FieldPanel("job_function"),
        FieldPanel("job_function_international"),
        FieldPanel("image"),
        FieldPanel("phone"),
        FieldPanel("mobile"),
        FieldPanel("country"),
    ]

    def __str__(self):
        return f"{self.first_name} {self.last_name}"

::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Typische Anwendungsfälle für TranslatableMixin: :: ::GlobalBlock{.ul-disk .mb-4}

• Übersetzbare Team-Mitglieder-Profile
• Mehrsprachige Produktbeschreibungen in einer Datenbank
• Globale Einstellungen, die sprachspezifisch angepasst werden sollen ::

::GlobalTitle{:size="lg" .mb-5} Best Practices für Wagtail Localize ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 1. Einheitliche Sprachverwaltung :: ::GlobalBlock{.ul-disk .mb-4}

• Stelle sicher, dass alle Sprachversionen einer Seite die gleiche Grundstruktur haben.
• Übersetze nicht nur den Inhalt, sondern passe auch SEO-relevante Daten (Titel, Meta-Beschreibungen) an. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 2. SEO für Mehrsprachigkeit optimieren :: ::GlobalBlock{.ul-disk .mb-4}

• Nutze hreflang-Tags, um Suchmaschinen zu zeigen, welche Version für welche Sprache gedacht ist.
• Stelle sicher, dass URLs sprachspezifisch sind, z. B. /de/about/ statt /about-de/. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 3. Performance beachten :: ::GlobalBlock{.ul-disk .mb-4}

• Caching aktivieren, um häufig genutzte Übersetzungen schneller auszuliefern. ::

:::GlobalButton{:url="/technologien/wagtail-cms/" :label="Nutze Wagtail für leistungsstarke, mehrsprachige Websites mit einfacher Verwaltung. Jetzt mehr erfahren!" :target="_blank" :color="blue" .mb-6} :::

::GlobalTitle{:size="lg" .mb-5} Dein Einstieg in Wagtail Localize ::

::GlobalParagraph Mit Wagtail Localize erstellst du mehrsprachige Django-Webseiten schnell, effizient und SEO-optimiert. Dank einfacher Konfiguration und Übersetzungs-Features ist es ein starkes Tool für internationale Webprojekte. :: ::GlobalParagraph Nutze die Best Practices, um eine nachhaltige und gut strukturierte mehrsprachige Webseite aufzubauen! ::

:::GlobalTitle{:size="lg" .mb-5 .mt-8} Häufige Fragen :::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 1. Was ist Wagtail Localize und warum sollte ich es nutzen? :: ::GlobalParagraph Wagtail Localize ist ein leistungsstarkes Übersetzungs-Tool für das Wagtail CMS. Es ermöglicht dir, mehrsprachige Webseiten effizient zu verwalten, Inhalte direkt in der Admin-Oberfläche zu übersetzen und Übersetzungs-Workflows flexibel zu steuern. :: ::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 2. Wie installiere ich Wagtail Localize in meinem Django-Projekt? :: ::GlobalParagraph Die Installation erfolgt in drei einfachen Schritten: :: ::GlobalBlock{.ul-disk .mb-4}

• Paket installieren: pip install wagtail-localize
• In INSTALLED_APPS aufnehmen
• Migrationen ausführen mit python manage.py migrate wagtail_localize ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 3. Unterstützt Wagtail Localize automatische Übersetzungen? :: ::GlobalParagraph Ja! Du kannst Inhalte manuell übersetzen oder eine automatische Übersetzung (z. B. via DeepL oder Google Translate API) in den Workflow integrieren. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 4. Wie funktioniert die Sprachverwaltung in Wagtail? :: ::GlobalParagraph Wagtail nutzt das Locale-System, um Sprachversionen einer Seite zu verwalten. Jede Sprache erhält eine eigene Seitenversion, die du im Admin-Bereich anpassen kannst. ::

::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} 5. Ist Wagtail Localize gut für SEO? :: ::GlobalParagraph Ja! Wagtail Localize unterstützt SEO-Best Practices für mehrsprachige Webseiten, darunter: :: ::GlobalBlock{.ul-disk .mb-4}

• hreflang-Tags zur Kennzeichnung von Sprachversionen
• Sprachspezifische URLs (/de/ statt /about-de/)
• Individuelle SEO-Texte pro Sprache ::

{.object-cover .max-w-full .mb-5}

1. Warum wir auf quartalsweise Wartungsreports setzen

Würde Heraklit noch heute leben, würde er wohl sagen: "Das einzige Konstante in Software ist Veränderung". So stammt dieses Zitat eben von Jeff Atwood. Software ist nie wirklich „fertig“. Sobald sie produktiv im Einsatz ist, muss sie gewartet werden. Dafür werden wir von unseren Kunden mit Wartungsvereinbarungen beauftragt{target="_blank"}, sodass wir regelmäßig einen abgesprochenen Zeitaufwand in die Pflege, Anpassung und Weiterentwicklung der Projekte stecken. Die meisten unserer Kunden möchten oder können dabei inhaltlich nicht im Detail mitgestalten. Genau deshalb übernehmen wir als Dienstleister die verlässliche Einplanung und Durchführung der Wartungsaufgaben.

Damit unsere Kunden abseits des Ticketsystems einen Überblick in vergangene und künftige Wartungsaufgaben bekommen, erstellen wir quartalsweise Wartungsreports. Unsere Kunden haben die Möglichkeit, die geleisteten Tätigkeiten auf den Prüfstand zu stellen und auf künftige Tätigkeiten einzuwirken. Die Reports schaffen Transparenz über den Zustand komplexer Systeme. Schließlich sind sie ein wichtiges Werkzeug für langfristige Zusammenarbeit.

2. Was unsere Reports enthalten

Unsere Reports folgen einer klaren Struktur. Neben den klassischen Zahlen zu Supportzeiten enthalten sie technische Bewertungen, z.B. zur Stabilität der eingesetzten Softwarekomponenten, Backup-Mechanismen und Sicherheitsaspekte. Die Übersicht der eingesetzten Softwarekomponenten sieht z.B. folgendermaßen aus:

Ergänzt wird das durch Kennzahlen aus Monitoring-Systemen, wie z.B. ein Überblick der Fehlerauswertung mittels Sentry{target="_blank"}: Weiterhin gibt es einen Überblick zur Testabdeckung:

Eine Einschätzung zu Risiken, Herausforderungen und geplanten Themen für das kommende Quartal runden den Wartungsreport ab.

3. Wie wir unsere Reports vorbereiten

Die Reports entstehen quartalsweise als Teil der Wartungsroutine. Ein Report wird dabei von mindestens zwei Personen erstellt. Sofern der Kunde keine expliziten Wünsche hat, setzen wir thematische Schwerpunkte, die wir für das Quartal etwas genauer beleuchten. Wir prüfen Daten aus verschiedenen Systemen, konsolidieren sie und bewerten Trends. Jede Empfehlung wird von unserem Team besprochen, bevor sie in den Report fließt.

Im Laufe der Zeit hat sich ein schöner Nebeneffekt ergeben: Der Termin, in dem unser Team den Report für einen Kunden vorbereitet, ist eine ideale Gelegenheit, um Ideen und Entwicklungsmöglichkeit für die Projekte des Kunden zu brainstormen und zu besprechen. Man beschäftigt sich intensiv mit dem Projekt eines Kunden, ist aber nicht in detaillierte Arbeit verstrickt, wodurch ein übergreifender Blick möglich ist.

4. Der Austausch mit unseren Kunden

Der Report wird in einem gemeinsamen Call besprochen. Für unsere Kunden ist das die ideale Gelegenheit, um Fragen zu stellen, Prioritäten zu setzen oder Themen anzustoßen. Für uns ist der Report ein fester Touchpoint, um Feedback zu erhalten und neue Ideen zu entwickeln. Unsere Kunden bekommen die Reports als PDFs zur Verfügung gestellt. Auch weniger technisch versierte Kunden verstehen durch die strukturierte Darstellung, wo ihr System steht. Hier haben wir schon häufiger gehört, dass die Reports sehr hilfreich sind, um innerhalb des Unternehmens oder gegenüber Vorgesetzten Transparenz für das Thema Wartung zu schaffen.

5. Warum Transparenz Vertrauen schafft

Regelmäßige, nachvollziehbare Reports schaffen Sicherheit. Sie geben einen Überblick über den Zustand komplexer Systeme und ihrer Zukunftssicherheit. Durch die Regelmäßigkeit können Kunden Entwicklungen über Zeiträume hinweg nachvollziehen und auch selbst steuernd eingreifen, ohne sich mit den sehr technischen Details der Wartungstätigkeiten auseinandersetzen zu müssen.

6. Fazit: Gemeinsam an stabilen und zukunftssicheren Systemen arbeiten

Unsere Wartungsreports sind kein Pflichtdokument, sondern ein Spiegel unserer Zusammenarbeit. Sie zeigen, was erreicht wurde, wo wir stehen und welche Chancen und Herausforderungen im nächsten Quartal warten. So sorgen wir gemeinsam dafür, dass Systeme langfristig stabil, sicher und entwicklungsfähig{target="_blank"} bleiben.

{.object-cover .max-w-full .mb-5}

:::globalParagraph Seit ca. einem Jahr taucht ein kleiner Blitz mit der Kennung „AMP“ in den mobilen SERPs (Search Engine Result Pages) auf. Dahinter versteckt sich ein Projekt, initiiert von Google: AMP. :::

{.object-cover .max-w-full .mb-5}

:::globalParagraph Quelle: https://moz.com/blog/google-amp-search-results :::

:::globalTitle{:size="lg" .mb-5} WOFÜR STEHT AMP? ::: :::globalParagraph AMP steht für Accelerated Mobile Pages. Es geht also um die Beschleunigung von Mobilen Webseiten, richtig? Ungefähr. Mehr oder weniger. Das große Ziel von AMP ist es die User Experience unserer Nutzer auf Webseiten zu verbessern. Dies realisiert AMP hauptsächlich durch die Verbesserung der Geschwindigkeit der jeweiligen Page. Klickt man auf einen Link mit der oben dargestellten Kennung, so öffnet sich die Seite blitzschnell. Der Mehrwert wird schnell ersichtlich, schaut man auf den Impact, welchen die Geschwindigkeit einer Webseite auf Besucherzahlen, Verweildauer, CTR und Conversion-Rates hat. ::: :::globalParagraph Die Geschwindigkeit / Ladezeit von Webseiten hat eine signifikante Relevanz für Besucherzahlen und Conversion-Rates gewonnen. Der Artikel „Find Out How You Stack Up to New Industry Benchmarks for Mobile Page Speed“[1] befasst sich genau damit. Im Januar analysierte ein Team bei Google 900.000 „mobile ad landing pages“. ::: :::globalParagraph Ergebnis: ::: :::globalParagraph Egal in welche Branche wir schauen, mobile Webseiten sind absolut überladen. ::: :::globalParagraph Je mehr Elemente, seien es Bilder, Skripte oder Stylings, auf einer Webseite verwendet werden, desto schlechter wird die Performance. ::: :::globalParagraph Die Bounce Rate, zu Deutsch „Absprungrate“, sprich die Wahrscheinlichkeit das der Nutzer nur eine Seite anschaut, steigt enorm mit der Ladezeit einer Seite an. :::

{.object-cover .max-w-full .mb-5}

:::globalParagraph Die durchschnittliche Zeit bis zum ersten Byte der Antwort (Time to first Byte oder auch TTFB) sollte im besten Falle unter 1.3s liegen. Das klingt simpel, scheint es aber nicht zu sein. Schauen wir uns die durchschnittliche TTFB in Deutschland an, schafft es niemand annähernd an diese Zeit. :::

{.object-cover .max-w-full .mb-5}

:::globalParagraph Woran liegt das? Dies kann verschiedene Ursachen haben. Ein langsamer Server, ein schlecht konfigurierter oder fehlender Cache oder einfach die falsche Wahl des Hosting Anbieters (was somit eine der vorherigen Ursachen begünstigt) können dazu führen, dass eine Webseite erstmal 2-3 Sekunden braucht um überhaupt zu antworten. Das bedeutet, dass in dieser Zeit noch keine Inhalte ausgeliefert wurden, sondern lediglich die Kommunikation zwischen Browser und Webserver initiiert ist. ::: :::globalParagraph Eine Seite sollte im Idealfall weniger als 500kB „wiegen“. Das klingt logisch, je weniger zu übertragen ist, desto schneller ist die Übertragung abgeschlossen. Gerade für Nutzer welche auf mobilen Endgeräte surfen, wenn das Netz mal wieder etwas schlechter ist, sind schlanke Webseiten eine Freude. Wie schaut es denn da so im Schnitt bei den deutschen Webseiten aus? :::

{.object-cover .max-w-full .mb-5}

:::globalParagraph Interessanterweise schafft es auch hier niemand annähernd an die Empfehlung von Google. Dabei müsste es doch so leicht sein, oder? Verzichtet man einfach auf ein wenig „Schnick-Schnack“, ein paar Bildchen weniger und schon geschafft? Dies wird wohl kaum die Lösung sein. Es gibt fast immer gute Gründe entsprechende Inhalte auf den Seiten zu platzieren. Entsprechend ist die Kürzung von Inhalten und Medien der letzte Schritt, welchen wir bei Blueshoe für die Optimierung einer Seite gehen würden. Vorher schauen wir auf andere Faktoren wie z.B. die Komprimierung von Bildern, Skripten und Styles oder das nachladen von Inhalten. Werden z.B. Bilder erst nachgeladen, sobald sie durch Scrollen in den Fokus des Nutzers kommen, wird der initiale Seitenaufruf wesentlich schneller. ::: :::globalParagraph Dies sind lediglich 2 Faktoren aus dem Bericht „Find Out How You Stack Up to New Industry Benchmarks for Mobile Page Speed“. Es gibt noch weitere Merkmale, nach denen man seine Seite optimieren kann und sollte. Google hilft bereits dabei die eigene Webseite zu untersuchen: https://testmysite.thinkwithgoogle.com - das Tool basiert auf den PageSpeed Insights[2] von Google. ::: :::globalParagraph Nun haben wir gelernt, dass noch vieles falsch läuft bezüglich der Gestaltung und Auslieferung von mobilen Webseiten. Aber wer kann nun eigentlich von AMP profitieren? :::

:::globalTitle{:size="lg" .mb-5} AMP - NUR FÜR PUBLISHER INTERESSANT? ::: :::globalParagraph Schaut man sich um, wer AMP bereits massiv einsetzt, stößt man vorrangig auf Publisher wie Wired, The Washington Post oder The New York Times[3]. Zufall? Nein, das Team hinter AMP ist früh eine Partnerschaft mit den Verlagen eingegangen, da diese in erster Linie von den schnellen Ladezeiten profitieren können. Hat es Ihnen etwas gebracht auf AMP zu setzen? Definitiv, ja. Schaut man auf die Case Studies erscheint der Mehrwert von AMP offensichtlich: 23% Anstieg von wiederkehrenden Besuchern für die Washington Post[4] und 25% Anstieg in der CTR der Suchergebnisse für Wired[5]. ::: :::globalParagraph Für Webseiten, welche Inhalte veröffentlichen und bereitstellen macht es also anscheinend Sinn. Je nach Aufwand sicher auch für Blogger und Hobbyautoren. Aber was ist mit den anderen Seiten? ::: :::globalParagraph WeGo – eine der größten Suchmaschinen für Flüge und Hotels in Indien, haben ihre Landingpages für Flüge mit AMP und PWA (Progressive Web Apps) gestaltet. Das bedeutet konkret: Wenn ein Nutzer Flug Singapur – Bangalore bei Google eingibt, so erscheint die Landingpage für diesen Flug in den Suchergebnissen. Klickt der Nutzer auf jenes Suchergebnis, so öffnet sich die Seite mit einem bereits vorausgefüllten Formular. Im Hintergrund werden bereits die nächsten Schritte geladen (Eingabe von Hin- und Rückflugdatum usw.) Für den Nutzer erscheint der Prozess hierdurch ohne Ladezeit. Dadurch haben sich erhebliche Verbesserung in der Conversion bei WeGo eingestellt[6]. ::: :::globalParagraph Ebay hat begonnen AMP für ihre Seite auszurollen und wird dies weiterhin ausbauen[7]. ::: :::globalParagraph Macht AMP also für E-Commerce Seiten Sinn? Auf jeden Fall. Das AMP Team hat bereits angekündigt, die Möglichkeiten für den Bau von Webseiten mit AMP im Sinne von E-Commerce zu erweitern. Einige der dazu benötigten Komponenten wurden vor kurzem auf der AMP Conference vorgestellt. Dieses Beispiel zeigt einen einfachen Konfigurator für ein Produkt auf einer Seite. Es ist (fast) alles da, was unser E-Commerce Herz begehrt: Galerie-Slider, Video, Auswahl von Farben und der „Warenkorb“-Button. Lediglich das Eingabefeld für die Menge ist noch ein Auswahlfeld. Somit kann die Menge vom Nutzer nicht frei bestimmt werden. Aber keine Sorge, Input Felder sind bereits verfügbar[8]. ::: :::globalParagraph AMP Seiten werden also auch im E-Commerce relevant. Vorstellbar sind Produkt Landingpages, welche mit AMP ausgestattet sind oder einfach die Produktseiten der E-Commerce Webseite/des Shops. Die Landingpages könnten den Nutzer weiter zum Produkt führen oder sogar direkt in den Warenkorb legen lassen. :::

:::globalTitle{:size="lg" .mb-5} WELCHEN EINFLUSS HAT AMP AUF SUCHMASCHINEN-RANKINGS? ::: :::globalParagraph Schön und gut, Seiten werden also schneller, aber wie schaut es denn mit SEO aus? Verbessern sich meine Rankings? Google belohnt mich doch sicher, wenn ich AMP in meine Seite integriere! ::: :::globalParagraph Die Integration von AMP in eine Webseite bringt keinen Boost im Ranking[9]. Jedoch kann AMP indirekt Auswirkungen auf das Ranking haben: durch den PageSpeed, durch bessere Nutzerzahlen und daraus resultierenden Aktionen wie z.B. das Teilen von Links. Google hat bis jetzt noch kein Statement abgegeben, ob AMP zukünftig ein Ranking-Faktor wird, oder nicht. Es gibt viele Spekulationen, „googelt“ man nach „AMP ranking factor“. Dies könnte zum absoluten Durchbruch von AMP führen. ::: :::globalParagraph Nichtsdestotrotz ist AMP eine sehr gute Strategie Teile der eignen Webseite zu verbessern, die User Experience zu erhöhen und somit die eigene Präsenz im Web aufzuwerten. Verbessert man die eigene Webseite, so konsumieren Nutzer mehr Inhalte – was zu höheren Verkaufszahlen, einer stärkeren Bindung oder einfach nur zufriedeneren Lesern führt. :::

:::globalTitle{:size="lg" .mb-5} WIE GEHT ES WEITER MIT AMP? ::: :::globalParagraph AMP wird von Google professionell vorangetrieben und natürlich gibt es auch eine Roadmap[10]. Wie sieht es also in naher Zukunft aus, was für Möglichkeiten wird uns AMP bieten? ::: :::globalParagraph Die Möglichkeiten komplexe Webseiten sowie bestehende Konventionen in AMP umzusetzen werden in Zukunft stetig wachsen. Features wie Autocomplete, Smart Buttons, Tabs, Parallax Scrolling, Hero Video Player, Lightbox sind bereits in Planung oder sogar schon umgesetzt. Entwickler werden sich zwar auf AMP Komponenten beschränken, aber dank der hervorragenden Community (307 Contributors und 9777 Stars auf Github)[11] werden diese ständig weiterentwickelt, verbessert oder gar ganz neue Komponenten entwickelt. ::: :::globalParagraph Im nächsten Artikel wird es wieder etwas technischer: Wie AMP aus technischer Sicht funktioniert und auf wie man AMP in Kombination mit Django einsetzen kann werden wir in den nächsten Wochen hier zeigen. Stay tuned! ::: :::globalParagraph Als Webagentur für Softwareentwicklung haben wir bei Blueshoe bereits unsere Erfahrungen mit AMP gesammelt und in der Verbindung mit Django-CMS umgesetzt. Bei Fragen stehen wir gerne beratend zur Seite! Hier gibt es aber schon mal ein paar mehr Infos zu Django-CMS: ::: :::globalParagraph Webseiten mit Django-CMS{.bs-link-blue} ::: :::globalParagraph Hier noch einer kleiner Talk von der PyConWeb in München, den Robert kürzlich über das Thema Google AMP in Django hielt: :::

:::GlobalPodcastSection{:videoId="NkrucRmfPrM" :videoPosition="right" :bg="bg-white"}

:::

:::globalParagraph [1]https://www.thinkwithgoogle.com/articles/mobile-page-speed-new-industry-benchmarks.html{.bs-link-blue :target="_blank"}

[2]https://developers.google.com/speed/pagespeed/insights/?hl=de{.bs-link-blue :target="_blank"}

[3]https://www.ampproject.org/learn/who-uses-amp/publishers{.bs-link-blue :target="_blank"}

[4]https://www.ampproject.org/case-studies/washingtonpost{.bs-link-blue :target="_blank"}

[5]https://www.ampproject.org/case-studies/wired{.bs-link-blue :target="_blank"}

[6]https://youtu.be/lX8szUWpfjk?t=3h14m28s{.bs-link-blue :target="_blank"}

[7]https://youtu.be/lX8szUWpfjk?t=2h20m55s{.bs-link-blue :target="_blank"}

[8]https://www.ampproject.org/docs/reference/components/dynamic/amp-form{.bs-link-blue :target="_blank"}

[9]https://moz.com/blog/google-amp-search-results{.bs-link-blue :target="_blank"}

[10]https://www.ampproject.org/roadmap{.bs-link-blue :target="_blank"}

[11] Stand 12.12 Uhr 17. März 2017 :::

{.object-cover .max-w-full .mb-5}

:::globalTitle{:size="lg" :tag="h2" .mb-5} EIN CMS FÜR DIE ZUKUNFT ::: :::globalParagraph Django-CMS ist aktuell in Version 3.4 LTS. Die LTS (Long-term support) Version wird für mindestens die nächsten 2 Jahre mit sicherheits-relevanten Updates versorgt. Darüber hinaus wird aber für viele Jahre hinaus die Kompatibilität aller darauf aufbauenden Module sichergestellt. Daher bietet django-CMS 3.4 LTS die geeignete Grundlage, um auch langfristig angelegte Softwareentwicklungs-Projekte{.bs-link-blue} darauf zu realisieren. :::

:::globalTitle{:size="lg" :tag="h2" .mb-5} WER ENTWICKELT DJANGO CMS? ::: :::globalParagraph Der Kern von Django CMS{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} wird maßgeblich von der Schweizer Unternehmung Divio AG entwickelt und öffentlich zugänglich gemacht. Da Blueshoe{.bs-link-blue} ein Partner von Divio ist, sind wir auch in der Lage, Einfluss auf die Roadmap und Entwicklung zu nehmen. Django CMS{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} ist mit seiner einfachen und intuitiven Bedienoberfläche nicht nur kompatibel zu allen aktuellen Web-Browsern, sondern kann auch hervorragend mit mobilen Geräten wie Tablets und Smartphones, gesteuert werden. Deshalb mögen wir es so gerne! :::

:::globalTitle{:size="lg" :tag="h2" .mb-5} EINFACHES BEARBEITEN VON INHALTEN ::: :::globalParagraph Wir schwören auf Django CMS{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} und haben keinen Kunden, der nicht von der simplen Art und Weise Inhalte zu editieren vollkommen überzeugt ist. Redakteure müssen sich nicht durch aufwändige und komplexe Backend-Ansichten navigieren – ein Doppelklick auf den Inhalt reicht, um diesen zu verändern. ::: :::globalParagraph Inhalte werden in „Plugins“ dargestellt. Diese können nach dem Drag-and-Drop-Prinzip an einer beliebigen Stelle auf der Seite platziert werden. Damit hat der Administrator die Möglichkeit Struktur und Inhalt der Seite zu bearbeiten, ohne dabei mit HTML-Code in Berührung zu kommen. Die Trennung von Code und Inhalt, aber dennoch eine große Flexibilität in der Darstellung, ist eine weitere Stärke von Django-CMS. Plugins können auch ohne Weiteres verschachtelte Inhaltsstrukturen abbilden. Der Fantasie sind damit in der Strukturierung von Seiten keine Grenzen gesetzt. :::

{.object-cover .max-w-full .mb-5}

:::globalParagraph Automatisch generierte Seiten werden über sogenannte „Apps“ erstellt. Diese können auf Bestände in der Datenbank zurückgreifen und Ansichten mit Listen, Tabellen oder anderen Darstellungsformen generieren. Diese müssen dann nicht explizit durch einen Administrator angelegt werden. Über Apps lassen sich in Django CMS{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} die komplexesten Herausforderungen meistern. :::

:::globalTitle{:size="lg" :tag="h2" .mb-5} TAXONOMIE IN DJANGO CMS ::: :::globalParagraph Seiten werden in einem Seitenbaum organisiert. Ganz im Stile von Django CMS{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} kann der Seitenbaum durch einfache "drag'n'drop" Bedienung beliebig und in wenigen Sekunden angepasst werden. Eine Seite vom der zweiten Hierarchie-Ebene auf die Erste holen? Kein Problem, drag'n'drop. Reihenfolge in der Baumstruktur ändern? Kein Problem, drag'n'drop. Das schöne dabei ist, dass es somit kein Problem ist im Verlauf der Erstellung einer Seite auch mal seine Meinung zu ändern. Nichts ist in Stein gemeißelt und Änderungen in Sekundenschnelle umgesetzt. :::

{.object-cover .max-w-full .mb-5}

:::globalParagraph Für jede Seite kann eine weitere Sprache angelegt werden. Jedoch ist es unproblematisch, wenn eine Seite mal nicht in jeder Sprache verfügbar sein soll. Doch nicht nur das Frontend ist mehrsprachig, auch im Backend werden unterschiedliche Sprachen unterstützt. Bei Django CMS{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} wurde akribisch darauf geachtet, das multilinguale Webseiten möglichst einfach erstellt und gepflegt werden können. :::

:::globalTitle{:size="lg" :tag="h2" .mb-5} STATE-OF-THE-ART FEATURES ::: :::globalParagraph Aus technischer Sicht bietet Django CMS{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} alle state-of-the-art Funktionalitäten, die man erwartet: von LDAP Authentifizierung bis hin zu einer Versionsverwaltung mit Vergleichsansicht und Audit-Trail. Darüber hinaus bietet Django CMS{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} ein umfassendes Rechtemanagement, welches nach Belieben erweitert und angepasst werden kann. Dieses findet Anwendung sowohl bei der Rollenverteilung für Administratoren als auch für das „Absichern“ von zugangsgeschützten Seiten. :::

:::globalTitle{:size="lg" :tag="h2" .mb-5} VIELE WEBSITES ABER NUR EIN BACKEND ::: :::globalParagraph Genau wie bei der Multilingualität war es Kern der Entwicklung von Django CMS{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} den Betrieb multipler Webseiten, auch auf völlig unterschiedlichen Domains, so einfach wie möglich zu gestalten. Eine einzige Installation des CMS genügt um alle ihre Seiten unter einen Hut zu bringen. Entwickelte Features, wie bspw. spezielle Plugins können dann bspw. über alle Seiten hinweg deployed und genutzt werden. Aber auch die Einschränkung von Features oder Styles auf nur eine einzelne Instanz der Installation ist ohne weiteres möglich. Plugins lassen sich z. B. auch Seitenübergreifend kopieren und in die Inhaltsstruktur einer anderen Seite einfach einfügen. Das erspart oft viel Arbeit und erleichtert die Verwaltung multipler Seiten ungemein. :::

:::globalTitle{:size="lg" :tag="h2" .mb-5} SKALIERBARKEIT, BACK-UPS UND UPDATES ::: :::globalParagraph Die Architektur von Django CMS{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} erlaubt das einfache Betreiben derselben Anwendungen auf unterschiedlichen Server-Instanzen. Dies ist besonders wichtig, wenn durch sehr hohes Besucheraufkommen eine horizontale Skalierung angestrebt werden soll. ::: :::globalParagraph Als Backup-Strategie setzten wir typischerweise inkrementelle Datenbank-Snapshots ein. Diese können bei Bedarf problemlos zurückgespielt werden. Updates werden über den Paketmanager „Pip“ abgebildet. Diese werden zunächst umfänglich auf dem Staging-System getestet, bevor sie in das Live-System eingespielt werden. :::

:::globalTitle{:size="lg" :tag="h2" .mb-5} BEISPIELE FÜR Django CMS{.text-bs-blue .hover:underline .hover:decoration-bs-blue .hover:decoration-solid} WEBSEITEN ::: :::GlobalBlock{.ul-disk .mb-5}

• Ofa Bamberg
• Campbell Hörmann Steuerkanzlei
• CreditGate24.com
• Samberger24 :::

{.object-cover .max-w-full .mb-5}

:::GlobalTitle{:size="lg" .mb-5} Was ist Vue.js? ::: :::GlobalParagraph Die erste Version von Vue.js ist im Jahr 2014 erschienen. Ähnlich wie ReactJS fokussiert Vue.js sich darauf, ein Entwicklungsgerüst (Framework) für reaktive Anwendungen zur Verfügung zu stellen. Vue.js befindet sich mittlerweile in Version 3, es hat stark an Reife gewonnen und wird von Unternehmen wie Google, Netflix, Facebook und Adobe eingesetzt. ::: :::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Schlüsselfunktionen von Vue.js: ::: :::GlobalBlock{.ul-disk .mb-4}

• Reaktives Databinding: eines der Hauptmerkmale ist die Verwendung von Referenzen in der Verarbeitung von Daten. So lassen sich Variablen an mehreren Stellen gleichzeitig aktualisieren
• Computed Properties: diese berechnen Werte basierend auf Referenzen. Aktualisiert sich eine Referenz, so wird auch die computed Property aktualisiert.
• Komponenten: Vue.js erlaubt die Erstellung von Komponenten als SFC - Single-File Components. Diese kapseln alle relevanten Informationen - DOM-Struktur, JS Logik und CSS-Styles in einer Datei.
• Progressive: Vue.js ist in verschiedene Teilprojekte untergliedert, sodass entsprechend der Anforderung an eine Software nur die notwendigen Abhängigkeiten installiert werden müssen :::

{.mx-auto .h-48 .max-w-full .mt-4} :::GlobalParagraph{.text-center} Das Vue.js Logo :::

:::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Beliebtheit und Community: ::: :::GlobalParagraph{.mb-4} Das Vue.js Projekt zählt mittlerweile über 16.000 Follower wohingegen der alte Platzhirsch React mit nur knapp 5.000 Followern abgeschlagen wirkt. Vue. Im Gegensatz zu den Frameworks Angular (Microsoft) und React (Meta) wird Vue.js von einer unabhängigen Community von freien Entwicklern vorangetrieben. :::

:::GlobalButton{:url="/technologien/vuejs-nuxt/" :label="Erfahre mehr über unsere Vue.js-Entwicklungsdienste" :color="blue" .mb-6} :::

:::GlobalTitle{:size="lg" .mb-5} Einführung in Nuxt ::: :::GlobalParagraph Nuxt ist ein SSR-Framework (Serverseitiges Rendern), welches auf Vue.js aufbaut. Vue.js selbst ist dafür konzipiert, im Browser Anwendungen zu entwickeln. Nuxt nimmt Vue.js als Grundlage und ermöglicht die Generierung HTML und Vue.js Strukturen auf der Serverseite. ::: :::GlobalTitle{:color="text-bs-blue" :font="font-oswald" :size="md" :tag="h3" .mb-5} Was Serverseitiges Rendering (SSR)? ::: :::GlobalParagraph Mithilfe des SSR wird der gesamte DOM - sprich die Struktur des HTML - bereits auf dem Webserver erzeugt und direkt an den Browser ausgeliefert. Dieser spart somit zum einen Rechenleistung, zum anderen sind alle Informationen, welche für Suchmaschinen relevant sind (SEO) auch bereits im HTML enthalten. Während in einer reinen Vue.js Anwendung relevante Daten asynchron, bzw. nachträglich geladen werden können, sorgt Nuxt dafür, dass diese Daten zur Zeit des Abrufs der Seite bereits zur Verfügung stehen. :::