24.06.2021

What's new

Cool new features for Django-Hurricane

We are pushing the development in the areas of Django and Kubernetes with our open-source project Django-Hurricane. Today, we’d like to show you some new features.

Cool new features for Django-Hurricane

Towards the end of 2020, we told you about our new open-source project Django-Hurricane. You can read our blog post about the launch here. With this project, we want to drive the Django and Kubernetes development forward and make our developers’ lives easier by eliminating a lot of routine jobs that pop up during the project set-up, transferring them to a robust framework.

We also worked on the to-do list in the GitHub Repository and are now able to show you some new features of Django-Hurricane.

Documentation

We have done extensive work on the documentation. Apart from the user guide, there’s also a low-level API documentation. The user guide provides helpful information about the use of Django-Hurricane, such as the available command options, useful tips for the configuration as well as general information about the individual components of Django-Hurricane. In the API documentation, you’ll be able to look up the features of those individual components.

Running management commands

We have also implemented a feature which allows for the management commands to be specified and run directly in the ‘serve’ command. The new command options are:

no-metrics: deactivate the collection of metrics.
command: the repeatable instruction that defines the management commands. The commands are carried out before the HTTP server is started. As the command can be run more than once, it can be repeatedly defined with those different management commands that might also have further options. In this case, you have to specify both the options and the name of the command in a string.

A command using the management commands could look as follows:

python manage.py serve --command makemigrations --command “compilemessages --locale =de_DE”

Probe Endpoints

Probe endpoints can now be defined separately using the ‘serve’ command. The options for this are:

startup-probe: the path for the startup endpoint (default: /startup).
readiness-probe: the path for the readiness endpoint (default: /ready).
liveness-probe: the path for the liveness endpoint (default: /alive).
req-queue-len: the threshold for the request queue. If this threshold is exceeded, the readiness probe will trigger a request with the status code 400.

Webhooks for probe events

In addition to this, we have also implemented a new feature for Django-Hurricane: the ability to send webhooks to a specific address. By now, there are three webhooks which correspond to the three probes. The first one is the startup webhook. It is run after the start of the HTTP server and sent to the specified address. Should the application have failed to start, a startup webhook with the status ‘failed’ is initiated. After this, the application is stopped.

The liveness and readiness webhooks are initiated after the respective probe requests. The webhooks are only run following a change in state – i. e. when the first probe request occurs, which changes the state from ‘None’ to ‘Healthy/Unhealthy’, as well as when the state changes from ‘Healthy’ to ‘Unhealthy’ or from ‘Unhealthy’ to ‘Healthy’. In the case of a webhook with the status ‘failed’, a corresponding error traceback is also sent.

In order for the webhooks to be sent at all, the URL has to be provided along with the webhook command. The command option is called ‘webhook-url’ and is provided as a URL for webhooks. The entire command for running the application together with webhooks would look as follows:

python manage.py serve --webhook-url „http://“

Every one of the webhooks also contains certain data:

Status: ‘failed’ or ‘succeeded’ – this depends on whether the probe is run successfully or whether it fails.
Type: ‘startup’, ‘readiness’ or ‘liveness’.
Timestamp: the moment when the webhook was initiated.
Hostname: the name of the computer or server.
Version: the Hurricane version.
Error trace: if the webhook has the status ‘failed’, the server will send the error message along with the error path.

cyclone

Despite all our hard work on the Django-Hurricane to-do list in the last few months, we’ve still got some unchecked boxed left. We’d therefore be very grateful for any help with the further development of Django-Hurricane as well as any of our other open-source projects. We’re already excited about the new challenges of the development and are looking forward to ticking off some more boxes in our GitHub Repository to-do list.