TP : Créer un site de monitoring de sites web
Fonctionnalités
Lister et gérer
les sites
Mise à jour auto du
statut des sites
Envoyer un message
si K.O
Lister et gérer
Liste accessible publiquement + consultation d'un site particulier et de son historique.
Gestion sécurisée via une connexion admin -> compte en bdd.
Présence des fonctions suivantes :
- Ajouter
- Modifier
- Supprimer
Mise à jour du statut
Mise à jour entièrement automatique et faîtes toutes les 2 minutes avec historique.
Basée sur les codes HTTP de retour. Avec 4 status :
- Inaccessible -> 4xx
- Erreur serveur -> 5xx
- Accessible -> 2xx
- Impossible de joindre le serveur -> 999
Envoie des messages
Envoie des messages quand on a un serveur inaccessible/une erreur serveur au moins 3 fois de suite.
Envoie par mail.
Pas d'envoi de message si un message a déjà été envoyé pour le site il y a moins de 2h.
API
Le site doit posséder une API qui permet de :
- Lister les sites
- Ajouter un site
- Supprimer un site
- Consulter le statut actuel d'un site
- Consulter l'historique d'un site
Quelques règles
Organisation du travail
Groupe de 2
Rendu au plus tard le 15 fév. 23:59:59
Copie -> 0
Comment se fait la note ?
5 pts pour le bon déploiement
5 pts pour différents trucs
10 pts pour les tests automatisés
Déploiement
Le déploiement est automatisé dans un docker avec php, apache, mariadb & supervisor.
Toute votre app sera déployée dans le dossier /var/www/html/httpstatus.
Le site est exécuté par un apache2 avec .htaccess activés.
Une commande composer install sera exécutée au déploiement.
L'URL de l'app sera de la forme http://example.fr/httpstatus/.
Supervisor & déploiement
Si vous avez besoin d’exécuter régulièrement une commande (spoiler alert, you do), le docker fait tourner supervisor.
Pour ajouter une tâche dans supervisor, créez un fichier supervisor.conf, il sera automatiquement copié dans le dossier /etc/supervisor/conf.d.
Pour rappel, toute votre app sera stockée dans le dossier /var/www/html/httpstatus. Adaptez votre fichier supervisor !
Règles de rendu
Le rendu se fait via le site tpsubmit.plebweb.fr
(1 rendu par groupe)
Le dépôt GitHub doit contenir tout votre code, directement à la racine. Je prend la branche master.
Votre projet doit contenir un fichier create_database.sql qui crée la base SQL de votre projet. La base doit s'appeler nom1_nom2 (remplacez par vos noms).
Pour vous connecter à MySQL, utilisez l'utilisateur "root" avec le mot de passe "bernardbernard".
Règles de rendu
Les noms et prénoms des membres du groupe doivent êtres inscrits dans un fichier names.txt à la racine du projet. Inscrivez un nom et prenom par ligne.
Votre base dois contenir au moins 1 utilisateur admin.
Il devra avoir un email 'deschaussettes@yopmail.com', un mot de passe 'password', et une clef api 'abcdefghjaimelesapis'.
Règles de l'API
Votre API doit respecter certaines règles.
L'API doit retourner du JSON.
Votre API doit être protégée par une clef API. Celle-ci est passée via un paramètre GET nommé api_key.
Vous embêtez pas avec du REST. Toutes les requêtes doivent être en GET (sauf pour add un site, en POST).
Règles de l'API
Le endpoint de base de l'API doit être : /httpstatus/api/.
Ce endpoint retourne un tableau avec au moins une clef "list" qui contient un lien (absolu) vers le endpoint qui liste les sites.
{
'version': 1,
'list': 'http://example.fr/httpstatus/api/list/'
}Exemple :
Règles de l'API
Le endpoint qui liste les sites retourne un tableau avec une entrée "websites" qui contient un tableau des sites, avec pour chacun son id, url, ainsi que les liens vers les endpoints "delete", "status", et "history". Utilisez ces noms comme clefs.
{
'version': 1,
'websites': [
{
'id': 973,
'url': 'http://toto.com',
'delete': 'http://example.fr/httpstatus/api/delete/973',
'status': 'http://example.fr/httpstatus/api/status/973',
'history': 'http://example.fr/httpstatus/api/history/973',
},
...
]
}Règles de l'API
Le endpoint qui affiche le status d'un site doit retourner l'id du site (id), son url (url) et son dernier status (status).
Le status est un objet avec code de retour (code) et date du status (at).
{
'id': 973,
'url': 'http://toto.com',
'status': {
'code': 200,
'at': '2019-02-01 10:00:12'
}
}Règles de l'API
Le endpoint qui affiche l'history d'un site doit retourner l'id du site (id), son url (url) et ses status (status) (trié par date décroissante). Les status contiennent le code de retour (code) et la date (at).
{
'id': 973,
'url': 'http://toto.com',
'status': [
{
'code': 200,
'at': '2019-01-10 10:00:11'
},
{
'code': 500,
'at': '2019-01-10 09:58:11'
},
{
'code': 200,
'at': '2019-01-10 09:56:11'
},
]
}Règles de l'API
Pour ajouter un site, on utilise le endpoint /httpstatus/api/add et on renseigne un seul paramètre POST nommé 'url', qui contient l'url du site.
{
'success': true,
'id': 7269,
}En cas de succès, le endpoint doit retourner un json avec une entrée "id" qui contient l'id du site créé.
Il se passe quoi si :
Le site se déploie mal ?
Je passe 60 secondes sur votre site.
Si au bout de ce temps j'ai pas réussi à réparer, je me pose pas la question, c'est zéro.
Le rendu est en retard ?
Bah c'est zéro.
Je modifie le git après le rendu ?
Toutes les modis après la date seront supprimées. Si le système arrive pas à les supprimer tout seul, bah c'est zéro aussi.
Je copie le code d'un collègue en changeant les variables ?
J'ai un outil qui détecte ça ! Modifier une variable, changer l'ordre du code, etc. Ça modifie pas VRAIMENT la signature d'un programme.
Les tests automatiques ne fonctionnent pas ?
Ça dépend. Les tests automatiques suivent le parcours suivant :
1 - Liste les sites
2 - Ajoute trois sites
3 - Supprime un des trois sites.
4 - Attend 10 minutes
5 - Demande le statut des deux sites et leur historique
6 - Vérifie si on a reçu un mail d'alerte sur le mail d'admin
Chaque action gagne des points, elles sont exécutées dans l'ordre, ça stop au premier fail.
Questions ?
TP HTTP STATUS
By plebweb
