mirror of
https://github.com/netbox-community/netbox.git
synced 2025-07-23 04:22:01 -06:00
docs: fix typos and markdownlint warnings in webhooks docs
This commit is contained in:
parent
edd8e9e41e
commit
a61473dd98
@ -9,12 +9,15 @@ When enabled, the user may subscribe webhooks to certain model events. These eve
|
||||
The models which may have webhooks registered to them are:
|
||||
|
||||
DCIM:
|
||||
|
||||
- Site
|
||||
- Rack
|
||||
- RackGroup
|
||||
- Device
|
||||
- Interface
|
||||
|
||||
IPAM:
|
||||
|
||||
- VRF
|
||||
- IPAddress
|
||||
- Prefix
|
||||
@ -22,13 +25,19 @@ IPAM:
|
||||
- VLAN
|
||||
- VLANGroup
|
||||
- Service
|
||||
|
||||
Tenancy:
|
||||
|
||||
- Tenant
|
||||
- TenantGroup
|
||||
|
||||
Ciruits:
|
||||
|
||||
- Circuit
|
||||
- Provider
|
||||
Virtulization:
|
||||
|
||||
Virtualization:
|
||||
|
||||
- Cluster
|
||||
- ClusterGroup
|
||||
- VirtualMachine
|
||||
@ -41,8 +50,9 @@ Webhooks are created and updated under extras in the admin site.
|
||||
|
||||
### Request
|
||||
|
||||
The webhook POST request is structured as so (assuming `application/json` as the Content-Type:
|
||||
```
|
||||
The webhook POST request is structured as so (assuming `application/json` as the Content-Type):
|
||||
|
||||
```no-highlight
|
||||
{
|
||||
"event": "created",
|
||||
"signal_received_timestamp": 1508769597,
|
||||
@ -54,7 +64,8 @@ The webhook POST request is structured as so (assuming `application/json` as the
|
||||
```
|
||||
|
||||
`data` is the serialized representation of the model instance(s) from the event. The same serializers from the NetBox API are used. So an example of the payload for a Site delete event would be:
|
||||
```
|
||||
|
||||
```no-highlight
|
||||
{
|
||||
"event": "deleted",
|
||||
"signal_received_timestamp": 1508781858.544069,
|
||||
@ -89,17 +100,20 @@ A request is considered successful if the response status code is any one of a l
|
||||
|
||||
The webhook backend feature is considered an "advanced" feature and requires some extra effort to get it running. This is due the fact that a background worker is needed to process events in a non blocking way, i.e. the webhooks are sent in the background as not to interrupt what a user is doing in the NetBox foreground.
|
||||
|
||||
To do this, you must install [Redis](https://redis.io/) or simply be able to connect to an existing redis server. Redis is a lightweight, in memory database. Redis is used as a means of persistance between NetBox and the background worker for the queue of webhooks to be sent. It can be installed through most package managers.
|
||||
To do this, you must install [Redis](https://redis.io/) or simply be able to connect to an existing redis server. Redis is a lightweight, in memory database. Redis is used as a means of persistence between NetBox and the background worker for the queue of webhooks to be sent. It can be installed through most package managers.
|
||||
|
||||
```no-highlight
|
||||
# apt-get install redis-server
|
||||
```
|
||||
|
||||
The only other component needed is [Django-rq](https://github.com/ui/django-rq) which implements [python-rq](http://python-rq.org/) in a native Django context. This should be done from the same place NetBox is installed, i.e. the same python namespace where you run the upgrade script. Python-rq is a simple background job queueing system sitting on top of redis.
|
||||
|
||||
```no-highlight
|
||||
pip install django-rq
|
||||
```
|
||||
|
||||
As mentioned before, the feature requires running a background process. This means we need to run another process along side the NetBox application. We can do this conveniently by modifying the supervisord unit used to run NetBox. Taking the configuration provided from the [installation guide](../installation/web-server/#supervisord_installation) modify it to look like this:
|
||||
|
||||
```no-highlight
|
||||
[program:netbox-core]
|
||||
command = gunicorn -c /opt/netbox/gunicorn_config.py netbox.wsgi
|
||||
@ -114,6 +128,7 @@ user = www-data
|
||||
[group:netbox]
|
||||
programs=netbox-core,netbox-webhook-backend
|
||||
```
|
||||
|
||||
!!! note
|
||||
`[program:netbox]` was changed to `[program:netbox-core]`
|
||||
|
||||
@ -126,12 +141,13 @@ Then, restart the supervisor service to detect the changes:
|
||||
```
|
||||
|
||||
!!! note
|
||||
Now any time you start or stop netbox using `supervisorctl`, you will need to refer to the
|
||||
netbox process as `netbox:*` (before this was just `netbox`). This is due to the fact that
|
||||
Now any time you start or stop NetBox using `supervisorctl`, you will need to refer to the
|
||||
NetBox process as `netbox:*` (before this was just `netbox`). This is due to the fact that
|
||||
we are now running multiple processes with supervisor, and `netbox:*` tells supervisor to
|
||||
act on all netbox processes (netbox-core and netbox-webhook-backend in this case).
|
||||
act on all NetBox processes (`netbox-core` and `netbox-webhook-backend` in this case).
|
||||
|
||||
Now you need only add the configuration settings to connect to redis and enable the webhook backend feature.
|
||||
|
||||
- In your `configuration.py` Set [WEBHOOKS_ENABLED](../configuration/optional-settings/#webhooks_enabled) to `True`.
|
||||
- If needed, set the optional redis connection settings. By default, they will allow connecting to DB 0 on a locally installed redis server with no password.
|
||||
- [REDIS_DB](../configuration/optional-settings/#redis_db)
|
||||
@ -148,4 +164,4 @@ Now you may restart NetBox as normal and the webhook backend should start runnin
|
||||
|
||||
## Backend Status
|
||||
|
||||
Django-rq includes a status page in the admin site which can be used to view the result of processed webhooks and manually retry any failed webhooks. Access it from http://netbox.local/admin/webhook-backend-status/
|
||||
Django-rq includes a status page in the admin site which can be used to view the result of processed webhooks and manually retry any failed webhooks. Access it from http://netbox.local/admin/webhook-backend-status/.
|
||||
|
Loading…
Reference in New Issue
Block a user