Django isup
This commit is contained in:
parent
5643df184f
commit
86aebaa08c
|
@ -0,0 +1,108 @@
|
||||||
|
status: hidden
|
||||||
|
title: Python — Django isup
|
||||||
|
slug: inuik9Ah-django-isup
|
||||||
|
robots: noindex
|
||||||
|
|
||||||
|
|
||||||
|
Le nom du rendu est `isup`, le protocole de rendu est
|
||||||
|
[là](https://mdk.fr/pages/obiree2uaza2sh-rendu.html).
|
||||||
|
|
||||||
|
Le nom du projet Django est libre, l'app Django doit s'appeler `isup`.
|
||||||
|
|
||||||
|
|
||||||
|
## Survol
|
||||||
|
|
||||||
|
Votre projet sera composé de :
|
||||||
|
|
||||||
|
- Au moins deux modèles : `Domain` et `Check`.
|
||||||
|
- Un `Domain` est lié à un `django.contrib.auth.User` (son propriétaire) via une `models.ForeignKey`.
|
||||||
|
- Un `Domain` contient au minimum :
|
||||||
|
- `name` ou `domain` (le nom de domaine),
|
||||||
|
- `is_up` (booléen à True si le site est accessible),
|
||||||
|
- `since` qui indique depuis quand le site est up ou down.
|
||||||
|
- Un `Check` est lié à un domaine (un domaine peut avoir plusieurs checks).
|
||||||
|
- Un `Check` contient au minimum :
|
||||||
|
- La date de vérification,
|
||||||
|
- un booléen `is_up`
|
||||||
|
- un message d'explication comme « HTTPS certificate expired », « Timeout », « Up », ...
|
||||||
|
- Au moins une vue Django pour la page d'accueil.
|
||||||
|
- De quoi [créer un
|
||||||
|
compte](https://docs.djangoproject.com/en/4.0/topics/auth/default/#django.contrib.auth.forms.UserCreationForm)
|
||||||
|
(via Django, pas forcément via l'API), car seuls les utilisateurs
|
||||||
|
loggés peuvent créer des domaines (qui leur appartiendront).
|
||||||
|
- `djangorestframework` pour gérer la sérialisation des modèles, les permissions, les vues d'API, les routes d'API.
|
||||||
|
|
||||||
|
|
||||||
|
## L'API
|
||||||
|
|
||||||
|
Je m'attends à pouvoir utiliser votre API de cette manière :
|
||||||
|
|
||||||
|
```text
|
||||||
|
GET /api/domains/ # Lister tous les domaines connus et leurs état (avec de la pagination si nécessaire).
|
||||||
|
POST /api/domains/ -d '{"domain": "mdk.fr"}' # Pour ajouter un nom de domaine (qui appartient à celui qui fait le POST).
|
||||||
|
GET /api/domains/1/ # Afficher les informations du premier domaine.
|
||||||
|
PUT /api/domains/1/ # Modifier le domaine 1, seulement autorisé si j'en suis propriétaire.
|
||||||
|
DELETE /api/domains/1/ # Supprimer le domaine 1, seulement autorisé si j'en suis propriétaire.
|
||||||
|
GET /api/checks/ # Lister toutes les vérifications qui ont été effectuées.
|
||||||
|
GET /api/checks/?domain=1 # Lister toutes les vérifications effectuées pour le domaine 1.
|
||||||
|
GET /api/checks/1 # Afficher le check d'id 1.
|
||||||
|
```
|
||||||
|
|
||||||
|
Les checks sont en lecture seule, donc pas de `POST`, `PUT`, `DELETE` dessus.
|
||||||
|
|
||||||
|
Si vous voulez que votre API soit REST, la représentation d'un domaine **doit** contenir un lien vers ses `checks` :
|
||||||
|
|
||||||
|
```json
|
||||||
|
{
|
||||||
|
"domain": "mdk.fr",
|
||||||
|
"is_up": true,
|
||||||
|
"checks_url": "http://localhost:8000/uptime/checks/?domain=1",
|
||||||
|
"url": "http://localhost:8000/uptime/domains/1/"
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
|
||||||
|
## Vérification périodique des domaines connus.
|
||||||
|
|
||||||
|
Vous utiliserez une
|
||||||
|
[Management Command](https://docs.djangoproject.com/en/3.2/howto/custom-management-commands/)
|
||||||
|
pour mettre à jour votre table, c'est là que votre script implémenté en cours sera utile.
|
||||||
|
|
||||||
|
La commande peut s'appeler `check` par exemple. Sur un serveur de
|
||||||
|
prod, le serveur devra l'appeler périodiquement, par exemples toutes
|
||||||
|
les 5mn, via un
|
||||||
|
[timer](https://www.freedesktop.org/software/systemd/man/systemd.timer.html)
|
||||||
|
ou un [cron](https://manpages.debian.org/bullseye/cron/crontab.5.en.html).
|
||||||
|
|
||||||
|
En dev vous pouvez simplement lancer `python manage.py check` à la
|
||||||
|
main de temps en temps.
|
||||||
|
|
||||||
|
Cette commande doit lancer une nouvelle vérification de **tous** les
|
||||||
|
domaines connus, chaque résultat (up ou down) doit être documenté dans
|
||||||
|
le modèle `Checks`.
|
||||||
|
|
||||||
|
|
||||||
|
## La page d'accueil
|
||||||
|
|
||||||
|
La page d'accueil doit être la plus "Django-less" possible :
|
||||||
|
|
||||||
|
- Une simple route.
|
||||||
|
- Une simple vue d'une seule ligne avec `render`.
|
||||||
|
- Un template avec au besoin du HTML, du JS, du CSS mais **pas** de templating Django (pas de `{{`, pas de `{%`).
|
||||||
|
|
||||||
|
Vous êtes autorisés à stocker le JS et le CSS en
|
||||||
|
[statique](https://docs.djangoproject.com/en/4.0/howto/static-files/),
|
||||||
|
mais je n'ai rien contre tout mettre dans le même fichier vu que je
|
||||||
|
suis dev back #sinvergüenza.
|
||||||
|
|
||||||
|
Quand je dis « Django-less » je veux dire que le front doit pouvoir
|
||||||
|
fonctionner en dehors de Django, et que dans un vrai projet avec une
|
||||||
|
équipe *front* et une équipe *back* j'aimerai que cette home, ce JS,
|
||||||
|
et ce CSS puisse être géré dans un autre repo, sans qu'à aucun moment
|
||||||
|
les devs front n'aient besoin de savoir que c'est du Django côté back.
|
||||||
|
|
||||||
|
Vous pouvez donc utiliser le framework front à la mode cette semaine.
|
||||||
|
|
||||||
|
Pour récupérer la liste des noms de domaines et leur état, le front
|
||||||
|
devra donc utiliser l'API. Pas besoin d'être loggé pour ça, on ne
|
||||||
|
modifie rien, on ne fait que consulter, keep it simple stupid.
|
Loading…
Reference in New Issue