---
title: "Coole neue Features für Django-Hurricane"
description: "Mit Django-Hurricane treiben wir bei Blueshoe die Entwicklung mit Django und Kubernetes voran. Heute stellen wir dir einige Features vor."
canonical_url: "https://www.blueshoe.de/blog/neue-features-fuer-django-hurricane/"
---
Mit dem Open-Source-Projekt Django-Hurricane wollen wir bei Blueshoe die Entwicklung in dem Bereich django und Kubernetes vorantreiben. Heute möchten wir dir einige neue Features vorstellen.
Ende 2020 haben wir dir unser neues
Open-Source-Projekt
[Django-Hurricane](https://django-hurricane.io/) präsentiert. Den Blogpost zur Vorstellung von Django-Hurricane kannst du [hier lesen](/blog/django-fuer-kubernetes/). 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.
Wir haben außerdem an der To-do-Liste im [GitHub Repository](https://github.com/django-hurricane/django-hurricane) gearbeitet und können jetzt hier einige **neue Features von Django-Hurricane** präsentieren.
Dokumentation
Wir haben intensiv an der [Dokumentation](https://django-hurricane.readthedocs.io/en/latest/) 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.
**Management-Commands-Ausführung**
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:
- 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.
Ein Command mit den Management-Commands könnte wie folgt aussehen:
```docker
python manage.py serve --command makemigrations --command “compilemessages --locale =de_DE”
```
**Probe-Endpoints**
Probe-Endpoints können jetzt separat mit dem „serve“-Command definiert werden. Die Optionen dafür sind:
- 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.
**Webhooks für Probe-Events**
Darüber hinaus haben wir noch ein Feature für [Django-Hurricane](https://django-hurricane.io/) 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.
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.
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.
```docker
python manage.py serve --webhook-url „http://“
```
Dabei enthält jedes Webhook einige Daten:
- 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.
Trotz unserer fleißigen Arbeit an der **Django-Hurricane-**[To-do-Liste](https://django-hurricane.readthedocs.io/en/latest/todos.html) 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](https://django-hurricane.io/) 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.
## Sitemap
See the full [sitemap](/sitemap.md) for all pages.