DIIAGE: ajout derniers cours
This commit is contained in:
@ -0,0 +1,18 @@
|
||||
# Préparation: Stratégie de communication dans l'IoT
|
||||
|
||||
## Problématiques
|
||||
|
||||
- Quelles sont les différentes stratégies envisageables pour faire communiquer des flottes d'objets connectés ?
|
||||
- Quelles techniques sont utilisées pour assurer la scalabilité des communications ?
|
||||
- Quelles techniques sont utilisées pour la découverte des services disponibles dans l'environnement immédiat (ou non) des objets connectés ?
|
||||
|
||||
## Ressources
|
||||
|
||||
- [Choosing the right communication pattern for the Internet of Things - Intel](https://software.intel.com/en-us/articles/communication-patterns-for-the-internet-of-things)
|
||||
- [Multicast DNS - Wikipédia](https://en.wikipedia.org/wiki/Multicast_DNS)
|
||||
- [Zeroconf - Wikipédia](https://fr.wikipedia.org/wiki/Zeroconf)
|
||||
- [Consul - Service Discovery and Configuration](https://www.consul.io/)
|
||||
- [NATS - Simple High Performance Messaging Server](https://nats.io/)
|
||||
- [ZeroMQ - Multi language communication librairy](http://zeromq.org/)
|
||||
- [MQTT - M2M communication protocol](http://mqtt.org/)
|
||||
- [UPnP](https://en.wikipedia.org/wiki/Universal_Plug_and_Play)
|
||||
@ -0,0 +1,50 @@
|
||||
<style>
|
||||
* {
|
||||
font-size: 0.8em !important;
|
||||
}
|
||||
</style>
|
||||
|
||||
# Authentification: QCM
|
||||
|
||||
- **Nom**
|
||||
- **Prénom**
|
||||
- **Classe**
|
||||
- **Date**
|
||||
|
||||
## Consigne
|
||||
|
||||
Pour chaque question, entourer **la ou les bonnes réponses**.
|
||||
|
||||
**Attention**, certaines questions sont volontairement rédigées sous la forme plurielle. Cela n'implique pas forcément qu'il y a plusieurs bonnes réponses.
|
||||
|
||||
## Questions
|
||||
|
||||
### A. Dans un modèle de communication `publish/subscribe`, les agents communiquent via l'envoi de:
|
||||
|
||||
1. messages
|
||||
2. sémaphores
|
||||
3. signaux
|
||||
|
||||
### B. Dans le contexte de la communication inter-agents, un "broker" a pour rôle:
|
||||
|
||||
1. De déduire automatiquement le sujet d'un message par rapport à son contenu
|
||||
2. De découpler les producteurs et consommateurs d'information
|
||||
3. D'acheminer et router les messages entre les différents les producteurs d'informations et les consommateurs de ces informations
|
||||
|
||||
### C. Le protocole mDNS utilise pour la découverte de services
|
||||
|
||||
1. Une adresse IP multicast
|
||||
2. Un serveur de "rendez vous"
|
||||
3. Du broadcast UDP
|
||||
|
||||
### D. En dehors d'une communication directe possible (réseaux différents, NAT, etc), les agents utilisent habituellement pour se découvrir mutuellement:
|
||||
|
||||
1. Un serveur de "rendez vous"
|
||||
2. Un registre global
|
||||
3. Des champs TXT sur un enregistrement DNS
|
||||
|
||||
### E. L'utilisation d'une "queue" dans un protocole de communication basée sur les messages permet de:
|
||||
|
||||
1. S'assurer que les messages produits ne sont consommés que par N agents au maximum
|
||||
2. Répartir la charge liée au traitement d'un message
|
||||
3. Décharger le "broker" du traitement de certains messages
|
||||
@ -0,0 +1,30 @@
|
||||
# TP - Créer un réseau d'agents indépendants communicants
|
||||
|
||||
## Avertissement
|
||||
|
||||
Ceci est un **TP de classe**. Vous devez vous répartir les tâches et travailler par binome/trinome/etc. N'essayez pas d'implémenter l'ensemble des agents de manière individuelle. Vous devez donc également vous mettre d'accord sur le format des messages pour que vos agents soient inter-opérables.
|
||||
|
||||
## Contexte
|
||||
|
||||
Créer un réseau d'agents indépendants capables de récolter/partager des informations sur vos machines respectives. Ces agents devront communiquer via un serveur NATS en suivant le paradigme `publish/subscribe`.
|
||||
|
||||
Les agents suivants devraient être implémentés:
|
||||
|
||||
- Un agent récoltant l'espace disque utilisé sur votre machine et publiant celui ci sur le réseau.
|
||||
- Un agent récoltant la température des CPU de votre machine (sur Linux, voir `/sys/class/thermal`).
|
||||
- Un agent d'alerte réagissant aux messages des agents "Espace disque" et "Température CPU". Si les valeurs dépassent un seuil prédéfini (le choix reste à votre discrétion), cet agent doit envoyer un message d'alerte sur le réseau.
|
||||
- Un agent de transmission des alertes. Lorsque cet agent reçoit un message d'alerte via le serveur NATS, il doit transformer celui ci en courriel et l'envoyer à une adresse prédéfinie.
|
||||
|
||||
> Ce type de topologie avec des agents indépendants est typique d'un réseau "IoT".
|
||||
>
|
||||
> Chaque agent que vous implémenterez est assimilable à un objet avec une fonction précise (capteur d'humidité, thermomètre, capteur de présence, etc...).
|
||||
>
|
||||
> Ces objets communiquent par l'envoi/réception de messages sur un médium/protocole de transport commun (ici TCP/IP + NATS). Dans la réalité, ces objets pourraient utiliser du Bluetooth, des ondes radio, une connexion 4G...
|
||||
|
||||
|
||||
## Consignes
|
||||
|
||||
- Récupérer/installer un serveur [NATS](https://nats.io/download/nats-io/gnatsd/) et le lancer sur une de vos machines. Ce serveur NATS servira de canal de communication entre vos agents.
|
||||
- À l'aide du [langage de votre choix](https://nats.io/download/) implémenter un des agents décrits ci dessus. Si vous préférez travailler avec des scripts (Bash ou Powershell, à votre convenance), vous pouvez utiliser l'utilitaire [nuts](https://forge.cadoles.com/wpetit/nuts) pour gérer la communication avec le serveur NATS. **Vous n'êtes pas obligé d'implémenter vos agents avec le même langage.**
|
||||
- Concevoir un protocole commun pour que vos agents puissent communiquer ensemble.
|
||||
- S'assurer que les agents implémentés sont interopérables et que les alertes par courriel sont correctement envoyées.
|
||||
@ -0,0 +1,82 @@
|
||||
# Évaluation - TP
|
||||
|
||||
## Objectifs
|
||||
|
||||
1. Implémenter un micro-projet dans un temps donné
|
||||
2. Respecter les consignes
|
||||
3. S'organiser pour respecter les contraintes de temps et réaliser le contrat
|
||||
4. Appliquer les concepts et principes découverts lors des sessions précédentes
|
||||
|
||||
## Sujet
|
||||
|
||||
Concevoir et implémenter une architecture élastique de base de données autour des solutions [CockroachDB](https://www.cockroachlabs.com/docs/stable/), [Docker](https://docs.docker.com/) et [NATS](https://nats.io/).
|
||||
|
||||
### Contexte
|
||||
|
||||
Un client souhaite mettre en place une infrastructure élastique autour d'une base de données relationnelle.
|
||||
|
||||
Son système d'information est d’ors et déjà basé sur Docker pour la conteneurisation et NATS pour l'échange de messages entre les différents services de son environnement applicatif.
|
||||
|
||||
Son objectif est de pouvoir (à travers l'envoi de messages NATS) d'ajouter/supprimer des instances de base de données pour s'adapter automatiquement au niveau de charge de l'environnement applicatif.
|
||||
|
||||
Il voudrait qu'on lui fournisse un prototype implémentant les fonctionnalités suivantes:
|
||||
|
||||
- Un script `bootstrap-env.sh` qui créait un environnement basé sur Docker avec une instance de CockroachDB en mode cluster et un serveur NATS dans des conteneurs différents.
|
||||
- Un script `add-node.sh` qui démarre un nouveau conteneur CockroachDB qui rejoindra automatiquement le cluster déjà existant.
|
||||
- Un script `remove-node.sh` qui arrête un des conteneurs CockroachDB en cours d'exécution si il en reste plus de 1.
|
||||
- Un script `db-node-add-subscriber.sh` qui une fois lancé s'abonne à la publication du sujet `db.node.add` sur le serveur NATS et invoque automatiquement le script `add-node.sh`.
|
||||
- Un script `db-node-remove-subscriber.sh` qui une fois lancé s'abonne à la publication du sujet `db.node.remove` sur le serveur NATS et invoque automatiquement le script `remove-node.sh`.
|
||||
- Un script `test.sh` qui publie des messages sur le serveur NATS afin de tester le bon fonctionnement du prototype.
|
||||
|
||||
Un fichier `README` devra être fourni décrivant la procédure d'installation et d'utilisation du prototype.
|
||||
|
||||
Il voudrait également qu'on lui fournisse un [diagramme de séquence](https://fr.wikipedia.org/wiki/Diagramme_de_s%C3%A9quence) pour les développeurs et les administrateurs opérationnels illustrant les processus suivants:
|
||||
|
||||
- Ajout d'une nouvelle instance CockroachDB via un message NATS
|
||||
- Suppression d'une instance CockroachDB via un message NATS
|
||||
|
||||
Il aimerait enfin qu'on lui présente une potentielle solution, accompagnée d'un [diagramme d'activité](https://fr.wikipedia.org/wiki/Diagramme_d%27activit%C3%A9), pour limiter le nombre maximum d'instances CockroachDB en cours d'exécution à un instant T.
|
||||
|
||||
## Contraintes concernant l'implémentation
|
||||
|
||||
- Vos scripts doivent utiliser l'interpréteur Bash.
|
||||
- Le code doit être commenté.
|
||||
- Vous pouvez utiliser [nuts](./https://forge.cadoles.com/wpetit/nuts) (voir la section Release pour télécharger les binaires) pour la partie communication avec le serveur NATS.
|
||||
|
||||
## Éléments attendus
|
||||
|
||||
- Un répertoire nommé `projet` contenant les fichiers suivants:
|
||||
- `bootstrap-env.sh`
|
||||
- `add-node.sh`
|
||||
- `remove-node.sh`
|
||||
- `db-node-add-subscriber.sh`
|
||||
- `db-node-remove-subscriber.sh`
|
||||
- `test.sh`
|
||||
- `README`
|
||||
- Un fichier PDF nommé `document_achitecture.pdf` comprennant les diagrammes de séquence ainsi que la proposition de solution pour limiter le nombre maximum d'instances, accompagné de son diagramme d'activité.
|
||||
|
||||
Votre TP est à téléverser sur la plateforme de partage dans le répertoire défini par l'intervenant **avant la fin de la journée** (l'horodatage de création du fichier sur l'application fera foi). **Il ne devra pas être modifié après cette journée**.
|
||||
|
||||
L'archive (zip ou tar.gz, à votre convenance) comprenant vos fichiers devra respecter le format suivant:
|
||||
|
||||
```
|
||||
[prenom]_[nom]_evaluation.[extension]
|
||||
```
|
||||
|
||||
_Grille de notation page suivante_
|
||||
|
||||
<div style="page-break-after: always;"></div>
|
||||
|
||||
## Grille de notation
|
||||
|
||||
| Critère | Description | Points maximum |
|
||||
|---------|-------------|----------------|
|
||||
| Respect des consignes | Les consignes sont respectées. | 3 |
|
||||
| Implémentation | Le prototype fourni est fonctionnel. | 6 |
|
||||
| Documentation | Le code est commenté. Le fichier `README` est clair et exhaustif. | 3 |
|
||||
| Document d'architecture | Les diagrammes de séquences sont représentatifs du comportement du prototype. La proposition de solution est claire et argumentée. Le diagramme d'activité illustre correctement la solution présentée. | 6 |
|
||||
| Orthographe et vocabulaire | Les règles d’orthographe et le choix du vocabulaire est correct (l'usage d'anglicismes ne sera pas pénalisé). | 2 |
|
||||
| Prototypage de la solution proposée | Vous avez implémenté la solution de limitation des instances proposée et elle est fonctionnelle. | 3 (points bonus) |
|
||||
|
||||
**Le total de vos points ne peut excéder 20.**
|
||||
|
||||
Reference in New Issue
Block a user