13.04.2021
What's new?
Coole neue Features für 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 präsentiert. Den Blogpost zur Vorstellung von Django-Hurricane kannst du hier lesen. 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 gearbeitet und können jetzt hier einige neue Features von Django-Hurricane präsentieren.
Dokumentation
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.
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:
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 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.
python manage.py serve --webhook-url „http://<Adresse>“
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 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.
ADRESSE
