LAWS Meetup 2 Julien Simon Hands on AWS IoT complete

Transcript

Merci beaucoup. C'est toujours génial de voir les présentations des gens qui font les vrais projets. Je suis épaté par le fait qu'il y avait une courbe d'apprentissage raide sur plein de trucs, dont CloudFormation. Après, c'est vrai qu'une fois qu'on maîtrise même les bases, on peut aller beaucoup plus vite, détruire et recréer ces environnements 50 fois par jour plutôt que de cliquer dans la console. On va parler d'un produit très différent, qui a été lancé il y a un peu moins d'un an, appelé AWS IoT. Je vais vous expliquer ce qu'est AWS IoT, les grands concepts, ce qu'on essaie de faire avec, et détailler les grands composants de la plateforme. On parlera des devices, les petits équipements que nous connectons à notre plateforme, des SDK disponibles, et d'un cas concret avec la plateforme Arduino U. On parlera du protocole MQTT, utilisé entre les devices et le cloud, de la gestion et de la sécurisation des devices, qu'on appelle des "things" dans la terminologie AWS IoT. On va se concentrer sur la partie device, la partie embarquée, et sur comment remonter les données à partir de ces devices vers le cloud AWS, les envoyer dans les bases de données, comme DynamoDB. Dans ma démo, je vais montrer comment les remonter dans DynamoDB et quelles sont les options pour le faire. On abordera un sujet souvent négligé dans les présentations AWS IoT : le débogage. Je suis le premier à avoir mis ça dans des slides AWS, car c'est enterré dans la documentation. Les développeurs du service ne développent pas les applications ou ne les testent pas suffisamment. On va regarder des lignes de commande, car une représentation concrète montre que c'est du réel. Je veux que vous sortiez d'ici avec l'envie de jouer, de vouloir essayer et de pouvoir reproduire mes démos. Vous aurez toutes les slides, et vous pourrez refaire mes démos chez vous sans vous casser la tête. AWS IoT signifie Internet of Things, l'internet des objets. Notre vision et ce que nos clients nous ont demandé de développer, c'est une plateforme simple qui permet de remonter et de collecter des données de manière sécurisée et légère, pour les analyser dans les systèmes AWS. Nos clients ont des projets IoT avec des capteurs qui remontent des données, et ils veulent les stocker chez nous. Ces devices ne parlent pas forcément TCP/IP ou HTTPS, et ils veulent les pousser dans DynamoDB ou RDS. Tout commence avec un SDK, une librairie installée sur un device qui contient les API indispensables et le protocole de communication. On parle au device gateway, disponible en Europe sur Dublin et Francfort, et dans d'autres régions. On doit enregistrer ces devices, leur donner une identité, leur assigner un certificat X509, une paire de clés pour l'authentification et la crypto. La sécurité est primordiale chez AWS, et aucune communication n'a lieu sans sécurité. On peut configurer un moteur de règles sur le gateway qui analyse tous les messages, applique des règles avec une syntaxe SQL, et dirige les messages vers des services, des back-ends, ou même des API tierces. Il y a une autre partie de la plateforme, le device shadow, qui est une image du device au sein du gateway. Cette image existe tout le temps et permet à l'application d'interagir avec elle. Le shadow contient le dernier état connu du device, ce qui est utile car les devices ne sont pas toujours connectés. Par exemple, si vous avez un capteur de température, le shadow contiendra la dernière température remontée. Si le device se déconnecte, l'application pourra toujours lire le dernier état connu sans time-out. Si le device se reconnecte, il pourra lire l'état du shadow et se mettre à jour. Par exemple, imaginez une pompe d'arrosage pour votre jardin. Si vous commandez l'arrosage via votre smartphone et que la pompe est déconnectée, elle se reconnectera et lira l'état du shadow pour savoir si elle doit arroser immédiatement ou attendre. Le device a toujours le choix d'appliquer ou non l'état lu. Tout est pilotable par API, en ligne de commande, ou programmatiquement avec tous les SDKs. Depuis le 7 avril, IoT est disponible à Francfort. Parlons des devices. On a des starter kits disponibles sur notre site web. En termes de SDK, on supporte l'Arduino Yún, qui marche bien sur tous les Linux embarqués et sur les laptops en Node.js. On peut commencer à développer des applis IoT sur votre laptop en Node.js en vous connectant au gateway. J'ai un client Java qui parle MQTT, que je vous montrerai. Pour les devices embarqués avec moins de capacités, il y a un SDK portable avec un guide de portage dans la documentation. L'Arduino Yún est une plateforme simple avec des capteurs, une SD card, un USB, Ethernet, et Wi-Fi. Il a deux cœurs : un Arduino pour le temps réel et un Linux embarqué pour la communication. Les API sur l'Arduino appellent du code Python sur le Linux, ce qui est transparent pour vous. En termes de gestion d'énergie, vous pouvez mettre en veille le cœur Linux et faire tourner votre code uniquement sur le cœur Arduino. Pour configurer un device, vous téléchargez le SDK Arduino, l'installez, et vous avez un device prêt à fonctionner. Une fois configuré, il faut l'enregistrer sur le gateway, gérer la communication sécurisée et sa politique de sécurité. Pour créer un nouveau device, vous faites AWS IoT, Create Thing, puis lui donnez un nom. Ensuite, vous créez un certificat et des clés, que vous copiez sur le device. Vous pouvez aussi utiliser vos propres certificats. Dans AWS, par défaut, rien n'est autorisé. Vous devez définir des politiques pour autoriser des actions. Par exemple, vous pouvez autoriser un device à publier des messages dans un topic spécifique. Une fois la politique créée, vous l'associez au certificat, et le device est prêt à fonctionner. La configuration prend 10 à 15 minutes. Pour connecter un device, vous utilisez le code de connexion avec l'identifiant, le nom du gateway, son port, le nom et l'identifiant du device, et le nom du certificat. Une fois connecté, vous pouvez publier et recevoir des messages via MQTT, un protocole standard et économe en ressources, adapté aux petits devices. MQTT fonctionne en publish-subscribe sur des topics. Un device peut s'abonner ou publier dans un topic. Par exemple, un device peut envoyer des messages de température dans un topic, et une application mobile peut s'abonner à ce topic. La qualité de service (QoS) dans MQTT a trois modes : QoS0 (pas de garantie), QoS1 (acquittement), et QoS2 (livraison exactement une fois). AWS IoT ne supporte pas encore QoS2. Pour s'abonner et publier, vous utilisez des fonctions simples. Par exemple, un device peut lire la température et publier un message JSON dans un topic avec QoS0. Un autre device peut s'abonner à ce topic et exécuter un callback pour traiter le message. Le moteur de règles d'AWS IoT permet de diriger les messages vers des services AWS, comme DynamoDB, S3, ou Kinesis. On peut aussi pousser des données vers Elasticsearch, CloudWatch, et Machine Learning. Lambda est une intégration intéressante pour pousser des messages vers des services tiers ou des APIs externes. En résumé, AWS IoT permet de connecter des devices, de collecter et traiter des données de manière sécurisée, et de les intégrer dans des applications traditionnelles. En particulier ici, vous pourrez dire, la data qui arrive dans ce message, je m'en sers pour faire une prédiction. Le cas d'utilisation idéal pour ça, c'est que vous voulez faire de la maintenance préventive ou de la détection de panne, ou dire, mon device, là, il est dans cet état-là. Peut-être que quand ça fait 10 fois qu'il est dans cet état-là depuis 24 heures, en fait, je sais qu'il va tomber dans les deux jours. Vous avez construit un modèle qui vous démontre ça et vous pourriez faire de la prévention en disant, je te passe l'état du device, il va bien, il va bien, tu me réponds qu'il est tombé en panne. Donc je peux déclencher une action. L'intégration avec Machine Learning est un peu différente des autres services. On prend la data qui est dans le message et on l'utilise pour faire une invocation sur un modèle de prédiction. Si l'action ne marche pas, elle ne marche pas et la règle ne fonctionne pas. Du coup, on perd le message ? Non, tu ne perds pas le message. Le message, lui, il reste dans le gateway et il sera envoyé à son destinataire. Ce côté-là est complètement indépendant. Si il y a un deuxième là, il se parle comme ça, très bien. Après, le moteur de règles fait son boulot. Si la règle merde, il y aura une erreur dans les logs. C'est pour ça qu'il faut parler de debugging. Parce que mes premières règles ne marchaient pas du tout, c'était difficile à débloquer jusqu'à ce que je comprenne. Donc mon message ne sera pas perdu, mais par contre l'action ne se passera pas bien. La syntaxe est du SQL, donc typiquement vous allez faire select margama et seul un select étoile from température qui est le topic pour dire, air température supérieure à 35 degrés. Vous allez faire select sur les champs des messages JSON. C'est super sympa que tout le monde connaisse SQL. Au moins select. Select, R, après les alquer tables étaient seuls avec les personnes. Je suis présent, vous le savez sûrement plus que moi. Non, mais voilà, c'est une syntaxe qui est sympa, il y a des petites fonctions pour faire de la manipulation de shell et tout. Ils auraient pu inventer une usine à gaz et ils ont eu le bon sens de faire un truc assez sympa. Donc voilà un petit exemple qui est pratique. Celui que j'ai utilisé, c'est la règle mais écrite en format JSON pour voir le SQL select étoile from topic one. Je n'ai pas mis de clause where, c'est-à-dire je prends tous les champs de JSON de tous les messages qui arrivent. Ce n'est pas une règle très intelligente. Et qu'est-ce que je fais ? Je vois mon action, c'est une action DynamoDB. J'écris dans DynamoDB avec le nom de la table, le rôle pour autoriser IoT à écrire en Dynamo, toujours la sécurité, la clé de hachage de la table Dynamo, et puis la clé de tri de la table Dynamo. Et puis après je crée la table. Je crée la règle. Je vais vous montrer dans la console aussi, évidemment, vous pouvez le faire dans la console. Le debugging est donc là à ce stade. Maintenant, vous avez des données qui remontent sur le gateway, puis vous êtes capable de les envoyer où vous voulez. Après, c'est plus de la vie aussi, ça devient du big data, ça devient Elasticsearch. Comment on débloque les applications même simples ? Croyez pas que ça a marché du coup, je vous mentirais. On peut tester avec MQTT.fx, généralement c'est une bonne première étape pour dire, ok, qu'est-ce qui publie mon device ? J'ai un device qui publie sur un topic, je veux voir ce qu'il envoie concrètement avec MQTT.fx, vous abonner à son topic comme j'ai fait, puis vous voyez ce qu'il envoie. C'est une première étape. Vous pouvez aussi envoyer des messages avec MQTT.fx. Vous pouvez faire publish sur des topics, vous pouvez faire un test manuel en disant, je vais envoyer des messages à mon device, je vais voir ce qu'il répond. Ce n'est pas extraordinaire, ce n'est pas suffisant. Le seul moyen de voir en particulier des problèmes de permission qui arrivent souvent, des problèmes de règles mal écrites, des problèmes d'action mal configurés, des problèmes de JSON mal formé, etc., c'est en activant CloudWatch Logs pour IoT. Malheureusement, ce n'est pas activé par défaut. Sur Lambda, vous savez que à chaque fois vous créez une nouvelle version du Lambda, vous avez un log group qui est créé dans CloudWatch et là vous voyez tout ce qui passe sur la Lambda. Vous pouvez plonger là-dedans, c'est bien pratique. Pour IoT, ils ne l'ont pas activé par défaut, je pense que c'est une erreur, j'espère qu'on va la corriger. Ça complique beaucoup la vie pour remonter les erreurs. J'ai trois certificats. Et puis j'ai trois politiques. Donc si je clique sur un certificat, je vois quelque chose. Il m'en manque un morceau. Il me manque un bout là. J'ai dû fermer un panneau. C'est bon. C'est quand on clique là-dessus, il y a un panneau à droite. Généralement, c'est un jaune troué qui se donne de la page. Un petit rouleau. Il va y avoir 16 points. C'est celui-là ? Oui. On espère avec un signe juste. C'est là. Ah, il va bien marcher mieux. Attends, settings. Ah, c'est peut-être ça qu'il fallait. C'est peut-être ça qu'il fallait rien. Ah, si tu cliques sur settings, ça peut être un peu... T'es sûr qu'il marche, ton Bifil ? Ah. Ah, je préfère... Ah, je... Ah ouais, tu as raison maintenant, on peut niveler les lobes. D'accord, ça c'est nouveau, tu vas pas les rater. Donc ce que je voulais vous montrer c'était plutôt ça. On va y arriver. Ok, c'est un peu petit peut-être. Ça arrive à y aller quand même ? Donc on va regarder quand même un certificat. Voilà, c'est bon. Ce qu'on voit, c'est surtout que c'est... Voilà, il y a le certificat lui-même, ça c'est pas très important. On voit que c'est attaché, ce que je vous disais tout à l'heure, on a ce trio thing, policy et certificat. Et donc là j'ai la règle, ça fait le température DynamoDB, qui est enabled, et qui va faire donc select température. Ah non, la position est technique. Donc je select température, from température. Je vais sélectionner dans le topic température, le champ s'appelle température. Et je fais une action sur Dynamo, voilà ce que je vous ai montré tout à l'heure. Donc je vais écrire dans la table, ça s'appelle IoT température, avec comme H key le device, et comme range key un timestamp. D'ailleurs c'est la fonction timestamp que j'appelle, donc je le rajoute dans le message. Dans le message qui est envoyé par mon device, il n'y a pas de timestamp. Ok ? Alors, regardons un peu ce que ça donne. Donc on va reprendre l'Arduino. On va regarder d'abord... Alors du coup je ne sais pas lequel c'est pour l'instant celui-là. Donc ça c'est la console série. Ils sont branchés en USB mais c'est vraiment juste pour la ligne, je le dis à chaque fois parce que des fois les gens croient que je me dis comme le truc. Ça se passe vraiment, vraiment en WiFi. Il n'y avait rien qui passe sur l'USB à part du courant. Donc là j'ai un Arduino. Donc là est-ce qu'il publie celui-là ? Est-ce que c'est celui qui publie ou celui qui a produit ? Ça c'est celui qui... 140. Ça, c'est celui qui reçoit. Si je regarde la console de l'autre. Ça, c'est celui qui va publier. Ça, c'est le capteur de température. Si vous voulez bien réfléchir à la console. Allô ? Voilà. Ok, donc on a mis le code tout à l'heure. Donc on va vérifier que ça marche maintenant. C'est beau hein ? Tout ça pour ça ! Donc là qu'est-ce qui se passe ? Je lis la température, j'envoie un message avec la température. Vous voyez il n'y a pas de timestamp, c'est vraiment rajouté après, je vais vous montrer l'inamore. Et donc il envoie son message, le message arrive, il arrive dans l'autre, dans le topic température, sur lequel l'autre Arduino est abonné, et il le reçoit automatiquement. Ça réagit quand même vite, c'est aller-retour Dublin, aller-retour Dublin en WiFi. Donc vous voyez, c'est quand même un protocole, voilà, quand on dit léger, effectivement c'est assez léger, il n'y a pas de connexion à établir, il n'y a rien de très lourd. En plus là c'est QoS0, il n'y a pas d'équipement, il balance. Et donc si on regarde maintenant, donc à force ça se remplit, ça se remplit. Donc qu'est-ce qu'on voit ? On voit comme HKEY, j'ai mon device, le timestamp que j'ai rajouté et puis le payload que j'ai écrit, qui est juste le champ température. Donc si je refresh ça, voilà on voit les messages qui... On doit avoir du 30 degrés, voilà ça y est, ok. Et à partir de là, je pourrais avoir des applications qui font des queries sur Dynamo. Et puis une fois de plus, à ce moment-là, c'est plus de l'IoT. Et à ce moment-là, il viendra de créer plusieurs colonnes, etc. Ou c'est juste un champ ? Alors ouais, non, non, là c'est... Alors après, oui, DynamoDB, c'est une base NoSQL. Donc il n'y a pas de schéma, tu peux avoir autant de colonnes que tu veux y compris creuses, c'est-à-dire tu pourras voir des messages, tous les items n'ont pas besoin d'avoir les mêmes colonnes. Mais là j'ai fait un truc très très simple. Ce qu'on ferait vraiment, si on veut faire un truc un peu plus malin, c'est on passerait par une Lambda qui invoquerait une Lambda qui ferait de la mise en forme, qui ferait ce qu'elle a à faire. Là j'ai fait vraiment le truc, le raccourci brutal où j'écris directement la payload dans Dynamo. Mais effectivement, oui, c'est pas la mise en forme la plus sympa du monde. Ok ? Bon, ben voilà, je crois que j'ai terminé. Merci beaucoup. S'il y a d'autres questions, je serais ravi de répondre. Sinon on a des pizzas. Si vous voulez jouer, allez-y, faites le concours de la conférence. On peut faire gagner le switcher comme ça. On n'est pas nombreux. Lardino doit rester sur la table. On fait comme ça ? Allez go ! Je suis parti ! Il commence. C'est un jeu pour détecter celui qui a Ebola ! Ah ! 30-15 ! 30-34 !