24.06.2021
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.
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.
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.
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:
A command using the management commands could look as follows:
python manage.py serve --command makemigrations --command “compilemessages --locale =de_DE”
Probe endpoints can now be defined separately using the ‘serve’ command. The options for this are:
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://<Adresse>“
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.
Michael and Robert are talking about the various options developers have for running remote Kubernetes development environments.
More editions of our podcast can be found here: