Signoz et OpenTelemetry avec une app .net sous linux

Disclamer A l’heure ou j’écris cet article, le code source d’OpenTelemetry et Signoz sont en alpha/beta/pre-release.  Certaine lib sont en release officielle. J’édite au fur et à mesure certaine infos. Le code évolue et cet article aussi.  Il n’est certainement plus « à la page » lorsque vous lirez ces ligne.  Et de même, la doc officielle, celle de Microsoft et les ReadMe des repos ne sont pas tous mis à jours en temps et en heure.  C’est un sujet chaud pattate !!! Besoins Comme d’habitude, j’écris un article avec un vrai besoin et une application dans la vraie vie.  J’ai un serveur en prod et je souhaite le monitorer pour : observer son comportement (nombre de requêtes, % de CPU/RAM/Disk, periode d’activité/repos etc) analyser des problèmes, avoir accès aux logs sans ouvrir un terminal être alerté en cas de problème et pouvoir définir ces alertes avoir une vue d’ensemble avec des KPI de base   Contexte Depuis peu (qq années) on a la possibilité de faire tourner du .net sous linux. Ca change quoi allez vous me dire ?  Personnelement une question de coût. Un VPS (virual private server) sous linux c’est au moins deux fois moins cher que sous Windows (ça dépend avec quel fournisseur et les prix ont aussi évolué dans le temps). Mais aujourd’hui un VPS linux est utlra compétitif. Et j’ai pas de besoin cloud (même si j’y pense). Avec Windows on était habitué à installer des outils graphiques supplémentaires. Et meme de base on avait des outils de monitoring. Sous linux, c’est moins évident car on utilise principalement la ligne de commande. Et personnellement j’y retrouve pas mon compte. Même si on peut aussi mettre une interface graphique, c’est pas le but d’un serveur. Enfin, je voudrais pouvoir consulter ceci sans me loguer en ssh (depuis une interface web) et avoir des alertes email et sms serait top.  Actuellement je développe un nouveau produit (https://outquest.fr). Celui ci comporte un site web (game) et un site backoffice (qg). Le site officiel (outquest.fr) et le shop sont hébergés ailleurs (planethoster). J’ai une prod et un staging. (donc 4 site webs au final). J’ai commencé avec un serveur low cost à 2.99€/mois (Debian, 1 core,  2 Go Ram, 25Go SSD …) chez Ikoula. Franchement à ce prix la, ça marche bien pour faire tourner 4 sites webs.(avec que moi dessus hein !) Ces 4 sites web tournent sous 4 services kernel (autorestart) linux et géré par un serveur web frontal NGinx.  –> pour la config voir cet article J’ai de plus une CI/CD géré par azure devops (voir article Azure Devops) qui me permet via des pipelines de deployer automatiquement mon code sur les serveurs web respectif à chaque push git sur mes branches dev et master.  Ca a dla gueule ! Pour un mec tout seul (pour le moment) je sors la grosse artillerie. J’aurais pu partir direct avec un site web en prod et debuger dessus à l’ancienne. Mais j’aime bien apprendre à faire les choses bien :). Et justement, pour faire bien, la prochaine étape c’est le monitoring des serveurs (ya aussi les backups, je pense que j’en ferai un article à part).  Du coup j’ai voulu tester une solution qui me paraissait pas mal, un APM (Application Performance Management) : CheckMK.  Le souci c’est que j’ai vu trop gros (ce machin permet de gérer tout un parc informatique, plusieurs serveurs, node, kubernetes…) Et en l’installation, le machin à fait fondre mon serveur. Plus moyen d’y accéder pendant un temps et pas moyen de le redémarrer (j’ai contacté le support, ce qui m’a pris plusieurs jours, à ce prix la fallait pas attendre des miracles.) Le bon moment pour passer à un niveau supérieur.  A ce stade j’avais ma prod et mon staging sur la meme petite bécanne. Du coup je me dis qu’il faudra quand meme passer sur qq chose de plus sérieux pour la prod. J’ai donc opté pour un VPS OMGServ avec cette config :  Et une option payante supplémentaire de backup. (snapshots) CheckMK tourne déjà beaucoup mieux, mais comme je le disais c’est pas une solution pour moi. Ca install une bardé de trucs dont Apache2, qui fout la merde avec mon Nginx.  Après qq recherches, je suis tombé sur Signoz et OpenTelemetry. Et c’est ce qu’il me faut !   Signoz   Signoz est une interface web permettant de visualiser un ensemble de données sur votre serveur linux.  C’est une solution Open Source, récente et encore en dev. C’est un concurrent à DataDog (payant).  Elle permet de monitorer des applications et de fournir des éléments pertinents pour les devops.  Cette solution naît d’un constat. Les équipes techniques sont frustrées d’utiliser pleins d’outils différents provenants de sources de données elles aussi différentes pour voir leurs logs/metrics/traces …   De plus les outils existants sont « lourds », taillé pour de la grosse boite (faut bien vendre) avec des standards propriétaires et non générique.  Je n’ai pas de recul suffisant mais mon sentiment c’est que c’est compliqué et qu’un outil simple, uniformisé gratuit et open source manquait à ce niveau pour un niveau « intermediaire » (PME, TPME, indé) Un standard est en train d’émerger concernant toute ces données que l’on appelle OpenTelemetry. OpenTelemetry Encore un nouveau framework ? C’est quoi, une couche de plus ? OpenTelemetry c’est une collection d’outil, d’APIs et de SDKs permettant de mesurer, generer, collecter et exporter des données de télémetrie (metrics, logs et traces) afin de mieux analyser le comportement et les performances de nos applications.  Super mais qui porte le truc ? Est ce que c’est un projet qui va être adopté ? Oui, en tout cas par Microsoft : https://learn.microsoft.com/en-us/azure/azure-monitor/app/opentelemetry-overview Vu l’investissement de Microsoft pour les projets à succès Open Source, et vu le besoin, je pense qu’OpenTelemetry a de l’avenir.  Installer Signoz Il existe plusieurs façon d’installer Signoz, j’ai choisi pour ma part la version Standalone (https://signoz.io/docs/install/docker/) sur mon VPS linux Debian 11. Vous devrez télécharger le repo git : git clone -b main https://github.com/SigNoz/signoz.git puis vous rendre dans le répertoire suivant :…

Azure Devops Pipeline (CI/CD) – Secrets

Cet article concerne le secret de certaine informations, comme un mot de passe, un clé privée etc.  Dutant mon apprentissage sur azure devops, je suis passé par cette étape. Cependant je ne me suis pas servi précisément de ces varibles/files secrets au final car j’ai utilisé le "service connexions" . Néanmoins je trouve cela instrucif, alors je partage. YAML – sécurité Vous avez remarqué, je ne vous ai pas communiqué ma passphrase ni ma clé privée. Sinon vous auriez accès a mon serveur. Ma clé est sur mon poste de dev. La passphrase lisible dans mes scripts d’upload automatique. C’est pas ouf question sécu. Mais vu que je bosse tout seul dessus… ça va, ça passe.  Qu’en est il lorsque l’on travaille à plusieurs dev, avec des sys admins, du cloisement et un niveau de sécurité qui nécessite de pas trop déconner ? Il faut trouver un moyen de sécuriser ces données. Azure Devops utilise des "secure files" et des "secure variables" pour faire cela.  https://docs.microsoft.com/en-us/azure/devops/pipelines/library/secure-files?view=azure-devops Ces données sont HORS repo git. Ainsi personne n’y aura accès en dehors de vous et des autorisations que vous leurs donnerez sur Azure Devops. Par contre elles seront stockées sur Azure Devops… les américains, la CIA, la NSA tout ça tout ça…   Commençons par enregistrer notre passphrase et lui donner la permission pour la pipeline du projet Azure Devops "Blazor Sandbox". Pour cela on va créer une nouveau groupe de variables que j’ai nommé IKoulaGroup. Il faut aller dans Pipelines/Library et cliquer sur Variable group.  Ajouter une variable, donner lui un nom (ex MyPassPhraseIkoula) et une valeur (dans l’exemple Bangali) Notez qu’à droite de la valeur d’une variable se trouve un petit bouton cadena qui permet de masquer celle ci. On y reviendra. Retour sur le YAML Maintenant que l’on a notre variable stockée sur Azure Devops on va pouvoir la récupérer dans notre pipeline Voici comment : On a une première variable qui était déjà là, celle qui concerne le type de build ‘Release’. Elle a un nom et une valeur. Celle ci ne concerne que la pipeline et ne sera vu que de l’agent qui s’occupe de cette pipeline.  Ensuite on a la déclaration du groupe IkoulaGroup qui contient une variable dont le nom est "MyPassPhrase" avec une valeur. Plus d’info sur la doc officielle ici. Plus loin on affiche ces variables avec un echo. Deux façons de récupérer notre variable MyPassPhrase.  tout simplement en l’appellant par $(MyPassPhrase) en utilisant une « expression de runtime » avec $[variables.MyPassPhraseIkoula]. Je pige pas trop ce truc, mais je pose ça la des fois que ça serve plus tard.  Concrètement, je n’arrive pas à récupérer la variable avec cette deuxième technique. Par contre j’ai bien ma variable avec la première façon :On a récupéré notre passphrase "Bangali" de tout à l’heure.  Maintenant un mot de passe ou une passphrase c’est pas censé être affiché tel quel. Vous vous souvenez du petit bouton cadena de tout à l’heure, qui se trouve a droite de votre variable dans la library de pipeline, cliquez dessus pour le vérouiller ainsi : penser à sauvegarder et relancer la même pipeline : notez que cette fois ci, le contenu de la variable est masqué par des **** On sait maintenant comment cacher des informations. 

Azure Devops Pipeline (CI/CD) – Deploy

Objectif : déploiement en production Dans la précédente partie on a déployé une pipeline sur Azure DevOps. Celle ci nous permet de lancer une build dès que la branche master de notre repo Blazor Sandbox reçoit un nouveau commit. De cette manière on s’assure que le build fonctionne ou pas. On est prévenu du résultat par email.  Ce qui serait intéressant, c’est de pouvoir la déployer sur un serveur web automatiquement en cas de succès.  Ma config J’ai un serveur VPS chez iKoula pour 4€/mois, avec une debian linux.  Ca tourne plutot bien. Mais bon, j’ai pas beaucoup de traffic 🙂 Donc j’ai un site web https://dev.blazordemo.reactor.fr et https://blazordemo.reactor.fr qui tournent tous les deux sous Nginx. Derrière chez deux services kestrel asp.net core sous .net 6.0. (pour faire bien, il aurait fallut dissocier la prod de mon dev (ou recette, staging). Petit budget… Dans /var/www/blazordemo.reactor.fr et /var/www/dev.blazordemo.reactor.fr j’ai mes publications de site web asp.net core Blazor WASM (le serveur et le client WASM "all in one"). L’idée est de dire à Azure Devops Pipeline, lorsque la branche master reçoit un nouveau commit, tu publies une version du serveur et tu balances le tout via SSH (sftp). Pipeline YAML On est fixé sur les objectifs. Maintenant il faut traduire cela en YAML. Voici un bout de doc : https://docs.microsoft.com/fr-fr/azure/devops/pipelines/tasks/deploy/copy-files-over-ssh?view=azure-devops En premier lieu, je vais reprendre la précédente pipeline et modifier build par publish. La différence est notable pour Blazor Server WASM. (voir mon article) Un petit commit + push et on voit que Azure Devops lance un nouveau job. On attend qu’il termine et passe au vert. Je pense qu’on va procédé ainsi, à taton. Petit pas par petit pas.  Une modif + commit + push + retour du Job.  Point SSH/SFTP Pour accéder à mon serveur en toute sécurité, je me connecte via SSH. Je prends donc la main à distance depuis mon poste windows sur mon serveur debian linux, qq part en France. J’ai un mot de passe et un login. Et roule ma poule.  Mais on peut faire mieux. J’ai ajouté une paire de clé privée/publique et une passphrase. Ainsi, il faut avoir la clé privée + la passphrase pour accéder.  C’est plus sécurisant pour moi. Je laisse l’accès SSH classique pour des opérations plus ponctuelles. J’ai de mon côté une serie de fichier .bat qui lance une commande de publication .net core et des commandes winscp (permet de lancer des commandes SFTP depuis Windows). La connection se fait via cette clé et cette passphrase. Ainsi, je peux en un double clic mettre à jour ma prod/staging/recette/dev depuis mon poste, sans lacher mon mdp. Au lieu de le faire à la main depuis un client sftp. Ca marche ! C’est moins rapide qu’un client sftp (car les fichiers uplodé ne sont pas lancés en parrallele). J’ai deux types de scripts. La totale, qui met a jour toute la publication : et un autre "rapide" qui ne mets a jours que le minimum pour aller vite : et son fichier .bat  Donc l’idée, c’est de faire pareil sous Azure Devops. Yaml On va rajouter une nouvelle tâche dans notre pipeline YAML avec CopyFilesOverSSH 4 éléments sont à renseigner : sshEndPoint : c’est le nom de notre connexion SSH que l’on va configurer plus loin sourceFolder : le chemin relatif de votre publish. L’agent de build va s’occuper de récupérer votre publish au bon endroit. Attention au majuscule et minuscule si l’agent est sur linux !!! targetFolder: le chemin de destination de votre publication sur la machine cible.  cleanTargetFolder : facultatif, mais effacer le contenu de la destination fait pas de mal.  Service Connections Le sshEndpoint de tout à l’heure est à configurer dans les "project settings" dans la section Pieplines/Service Connections  Il reste plus qu’à créer la votre en cliquant sur le bouton new connection Sélectionnez SSH : puis remplissez selon votre config, en uploadant votre clé privée. Attention, celle ci doit être au format .pem. Et voila. C’est tout.  Relancer votre pipeline avec un petit git add commit push.  Normalement vous devriez avoir que du vert !

Blazor .net 6.0 – décollage

Découverte de Blazor J’ai été très très emballé lorsque j’en ai entendu parlé pour la premiière fois de Blazor. Bien que j’attendais à ce qu’il soit tué dans l’oeuf. Car au début, c’était un side project Microsoft sans prétention. Quelle idée, faire du web avec du C# ? et pourquoi pas VbScript tant qu’on y est… 🙂 Nan mais sans déconner, le js ça va deux minutes. Donc faire une web app en C# je signe.  J’ai donc taté du blazor en mode tuto au début. Puis j’ai oublié. Et me revoila ! Je vais présenter ici mes découvertes. En fait j’ai fait des erreurs et je voulais les écrires pour que qq évite de galérer comme moi.  Blazor .net 6.0 Bon la ça déconne plus. Blazor est officiellement inclu dans .net (depuis .net Core 3.1 il me semble) et donc on peut code pour de vrai, pour de vrai client. Et la ça change tout. Fini les tutos. Alors on  commence avec un nouveau projet sous VS2022. Et celui ci nous propose deux solutions :  Blazor WebAssembly  Balzor Server Blazor Server Ce type de projet est n’y plus n’y moins qu’un projet ASP.net Core avec du Razor en couche de présentation. Si auparavent vous avez fait du web.form pour les plus vieux, du MVC5 ou de l’Asp.net Core vous allez pas être trop perdu.  Pour les autres, on est sur une application classique de type Client (browser) Server (IIS, Apache, Nginx, Kernel…) En ajoutant une couche SignalR vous avez un site web qui déboite. Mais qui ne gère pas le offline. Blazor WebAssembly Le vrai plus est la pour moi. On peut envisager de faire une application web PWA avec .net. Et ça pour un dev Microsoft de 20 ans, c’est juste de la bombe pour moi. Et qui plus est, qui peut tourner sur un OS Linux. (voir articles sur les coûts) Donc Blazor Wasm pour les intimes et une tuerie. On va pouvoir utiliser la puissance du language C#, les outils VS et VS Code, et toutes les libs qu’on a l’habitude d’utiliser depuis des années.  Je vais parler dans le reste de l’article que de Blazor Wasm.      Comment ça marche ? L’objectif de l’article est de vous amener à bien comprendre comment Balzor fonctionne. D’un point de vue architecture applicative et d’un point de vue réseau/serveur.  Lorsque l’on créer un nouveau projet, VS2022 nous demande si on souhaite héberger le site via Asp.net Core. (kernel) Il nous demande aussi si l’on souhaite utiliser des fonctionnalités PWA. Pour ma part oui pour les deux.  Voici la différence entre un projet WASM sans serveur (à droite) et un projet avec : Le projet BlazorApp1.Client et BlazorApp2 (sans server) constituent l’application web PWA. On y trouve du code C#. Mais au final on aura que du code html/css/js pure en sortie et un dossier _framework, qui lui par contre contient qq dll indispensable au bon fonctionnement de blazor.  Voici une publication : On a un webconfig et un repertoire wwwroot qui contient ceci:     C’est la que ca devient chelou. Si on se place coté browser, et surtout en mode déconnecté, on a pas besoin d’un serveur (web, pure static de fichier), (sauf bien entendu lors du premier chargement). Ensuite on peut très bien s’en passer de ce serveur. D’ailleurs pourquoi pas héberger ce client sur un CDN (content delivery Network) Mais alors on a quoi si on se place coté serveur ? Bonne question. C’est la que l’hôte Asp.net Core intervient.  Comme on peut le voir dans le premier projet, on a un projet Server et un projet Shared. Shared est juste un projet de classe, rien de méchant on partage du code commun avec les deux autres projets.  Le projet Server par contre est le code qui va gérer la partie serveur, comme son nom l’indique. Et lui aura aussi la partie cliente. Regarder les sorties d’une publication du projet serveur :  On retrouve bien wwwroot de la partie cliente ! Ceux sont ces fichiers static que le serveur va gérer par la suite avec le browser. Donc pour résumer : On a un projet Blazor Server : projet classique client/serveur (rendu server sur chaque page) avec une liaison SignalR.  On a un projet Blazor WASM : projet PWA (client web autonome) qui peut avoir des options d’hébergement avec l’ajout d’un projet Server + Share. J’avoue qu’on s’y perds avec le terme « Server ». A mon avis les équipes de microsoft on du aussi gamberger pas mal sur le naming. Mais en fait, quand on sait, c’est clair. (complètement conne cette phrase…)   Mes erreurs Sotrie de build Lorsque l’on travaille en debug local, on ne fait pas trop attention à tout cela. Mais dès lors qu’on passe en prod c’est plus la même histoire.  La ou j’ai merdé, c’est de considérer le dossier bin/Release comme ma sortie pour la prod. Erreur ! Allez y faire un tour, on a uniquement la génération du projet courant. Ce qui est logique. Mais la petite nouveauté c’est la publication qui intègre le projet Client dans la sortie du projet Server.  Autre erreur, les ports.  En local on peut configurer les ports des projets Client et Server via le fichier properties/launchSettings.json.Et on peut executer les deux projets. Modifier les ports de ces fichiers et lancer un run.  Mais dans tous les cas ceux qui comptent pour la prod sont ceux du projet serveur. Et moi comme un con, j’avais le projet Client comme projet de démarrage. A éviter car j’ai perdu beaucoup de temps à rien comprendre.  Voila, j’y ai passé presque deux jours (config Ngix sur linux). Donc je résume un peu. Je me disais que ca valait bien un billet. ++

Cloud VPS Hebergement asp.net Framework et Core

Je commence à avoir ma petite expérience concernant l’hébergement d’un site asp.net. Et je vais vous en faire part. Je n’ai qu’une contrainte, faire tourner asp.net. Donc ça implique Windows. Enfin jusqu’à ce que je fasse le deuil de mes sites asp.net qui n’ont pas été migrés en .net Core. On reviendra sur ce point plus tard.  J’en profite pour hoster qq site web vitrine pro, des sites de POCs, des projets perso et pro etc… J’ai du monter facile à une quinzaine de site web. Pendant un temps. VPS OVH 40€/mois J’ai du commencer à louer un serveur vers 2010, avec 1&1 qui s’est rebatisé IONOS. C’était pas top de mémoire. Je suis passé chez OVH et pendant presque 8 ans ça a bien tourné.  Un jour j’ai eu un udpate de Windows qu’a foutu la merde. Mon serveur ne voulait plus redémarrer, il restait coincé juste apres le login. Mode sans échec ne faisant rien. Bref, à distance, je pouvais rien faire. Et j’ai donc eu à faire avec le support d’OVH. Chose en 8 ans que je n’avais pas eu à faire.  C’est la que j’ai entendu parlé de la réputation désastreuse de ce support qui est fondé. Un ticket est traité avec lenteur voir meme laissé comme mort pour être automatiquement détruit dans le temps. Bref, mon serveur en caraf pendant plusieurs jours voir semaine, m’a ammené à étudier la concurrence.  L’offre VPS linux est toujours abordable. Le problème c’est l’ajout d’un serveur Windows. Ca a un coup. Qui je l’apprendrai plus tard, est plus cher chez les concurrents. Je trouvais aussi les performances du serveur OVH un peu à la ramasse. De plus il m’occroyait seulement 50Go (Windows en bouffant un tiers, voir la moitié) et je passais souvent du temps a faire du ménage. Bref, il me fallait un coup de pied au cul pour bouger. Cloud Azure Je suis développeur .net Microsoft depuis maintenant 20 ans. J’ai donc suivis Azure de près.  Pas assez car je pige toujours pas combien ça coute. Ca Microsoft l’a bien compris et donc il propose 12 mois gratos avec un maximum de 150€ / mois je crois. Ce qui laisse largement assez pour tester plein de truc.  C’est ce que j’ai fait. Seulement j’ai jamais mis mes sites dessus. Par paresse car tout marchait bien sur OVH. Donc je suis resté sur des essais seulement.  Mais je dois dire que c’est un sacré bordel Azure… Cloud AWS J’ai tenté l’expérience AWS. Ce que j’aimais bien c’est qu’on pouvait tout faire en ligne de commande (sur Azure aussi, mais je l’ai testé bien plus tard). Ce qui me pose problème avec AWS c’est le controle des couts. J’ai tenté de rester au maximum gratuit. Mais c’est facile de sortir des cases sans s’en rendre compte. J’ai donc laissé un site web + BD de tester tourner (sans visite) et ca m’a quand même couté 17€/mois.  Car c’est malheureux, mais tout est décomposé. Faut une base de donnée qui est un service a part. De la resource calcul, des firewalls, de la réplication si on veut bien faire… Bref, ça part d’un truc simple et on se retrouve avec une usine a Gaz. Sans maitrise des couts.  Le pire c’est que lorsque j’ai tout fermé, j’avais quand meme des factures à 0.01€. Ce qui me laissait un gout de beau bordel… VPS Scaleway Dedibox 60€/mois Dedibox m’a séduit. Au début. Déjà parce que je pensais qu’avec le même budget précedent chez OVH, dans les 40€/mois, j’allais avoir un serveur dédié et plus de ressource. C’était vrai. Sauf pour le prix. En effet l’option Windows est cher, et elle n’est pas fixe (par CPU je crois). Elle évolue avec le pack que l’on choisit. Bref j’ai augmenté mes couts. Je passe à 60€. J’avais aussi un nouveau projet ou je pensais avoir du traffic, donc j’ai anticipé une bonne bécane. Ca a servit à rien mais je pouvais pas le savoir. J’ai donc cherché ailleurs…   Hebergeur PlanetHoster 6€/mois J’y croyais pas trop, mais au final quelle surprise ! J’ai dégagé Dedibox qui me coutait trop cher, et je suis tombé sur PlanetHoster. On peut mettre autant de site que l’on veut, tant qu’on a un peu de resource (CPU, Mémoire, IO) En gros on part avec un pack pour 6€ on ceci :  8 CPU16 GB RAM16 MB/s I/O https://www.planethoster.com/fr/Hebergements-World Que l’on répartie sur ses sites comme on veut. Très pratique lorsque l’on s’attend à un pick de charge.  On peut jouer avec du python, node.js, Php et Ruby. Si ils ajoutent .net Core ça serait un must.  Mais j’ai gardé mes sites vitrines et qq POCs. De plus aujourd’hui les sites webs deviennent vite des apps mobile PWA SPA. Donc du JS. J’en ai qq une.  J’ai rajouté qq resources. En tout ca me coute 100€/an. C’est stable, très administrable. Le support répond et résoud les ticket surtout.  Mais bon, comment je fais tourner Asp.net Core ? Ha oui, car à ce stade j’ai laché tout mes anciens site Asp.Net Framework. Je me focalise maintenant sur .net Core.  VPS iKoula 4€/mois Retour au VPS ! Mais ce coup si fini Windows. Bonjour Linux.  Et que ca fait plaisir de voir ces couts aussi bas. Sans déconner, un serveur à 4€ par mois. C’est ouf.  Alors j’ai choisi iKoula, pour essayer. J’ai une offre pas cher. J’aurais pu revenir sur OVH mais ils m’ont trop déçu.  Alors la grosse différence avec les VPS d’avant, c’est que la plus d’interface graphique. Retour à la ligne de commande.   Faut tout monter à la main. Pas grave.  J’ai pas besoin de grand chose : dotnet pour faire tourner un serveur kestrel en proxy Nginx pour serveur web (qui sera devant le proxy kestrel) un firewall, histoire de pas tout laisser ouvert.  letsencrypt pour un certificat ssl. https://docs.microsoft.com/fr-fr/aspnet/core/host-and-deploy/linux-nginx?view=aspnetcore-6.0   Une fois qu’on a payer sur iKoula, on nous propose de lacher une clé publique RSA pour le SSH. (facultatif). Ensuite il faut se connecter via…

Nadine project using Asp.net Core 2.1 with SignalR, GPIO and Raspberry pi 3

This is a personal project. I wanted to discover Asp.net Core 2.1 and SignalR. I use a Raspberry pi 3 with an external board so I can easily plug cables and play with leds and buttons on GPIOs. Here is the goal : count on an input (Gpio 17) linked to a photo-electric cell the number of passage of a fake fabric bottle line, simulated here by one propal of an old usb fan. The signal is read on Gpio17 by the raspberry pi and sent via SignalR to a web client (which is also host on the same raspberry pi server, with asp.net core razor pages.) So I can read the counter on my web page in real time (almost). GIT source code : https://github.com/couscousbzh/Nadine Youtube Demo here : https://youtu.be/c3wAWcoAf0M What you need A Raspberry pi 3 + power A testing board + cables (https://www.amazon.fr/gp/product/B01I58Y766/ref=oh_aui_detailpage_o08_s00?ie=UTF8&psc=1) A case (optional https://www.amazon.fr/gp/product/B01KZ26LKA/ref=oh_aui_detailpage_o09_s00?ie=UTF8&psc=1) A SSH client (putty or mobaXTerm) A button (I use a little button on board and a eletric photo cell, but I guess you don’t have one…) Some cables How it works In Asp.net Core you can manage WebHost as usual (your web site) but you can add other host that can act like a service. This is what i’ve done. I create two services, webhost and a timehostedservice. If my english is not so bad, I understood that host and webhost services will be « Generic Host » in the future. So I guess this will change in the future. I notice some diffences when creating it. With webhost service you can configure it in one line (CreateDefaultBuilder) but there is no such thing for host. Anyway, all of this is coded in program.cs and startup.cs (this one is basically only used for webhost) Timehost is a loop, you set the frequence you’d like. I set a 1 ms loop. So every 1ms, I call a worker to do a job. Which is basically just to read Gpio 17 input state. I start the webhost first and then the timehost. Webhost takes time to launch. And if counting starts, it needs to connect to Hub and do a start connexion first. But if the webhost is not yet started, I have an error. So I delay the worker init to 10s. I know this is ugly, this is something I wanted to correct but I spent too much time. And by the way, i am not sure that running 2 services like that is the best solution. Maybe doing 2 separate projects with their own life is better. So I did not loose my time on this. Web Service (host) Basic project made with a « dotnet new webapp » cli command. Then I follow the microsoft guide line : https://docs.microsoft.com/fr-fr/aspnet/core/signalr/introduction?view=aspnetcore-2.1 this give me a little chat room exemple using SignalR. Then, I add a Counter Page. The goal of this is to simulate a counter (like a bottle counter sensor) and upload the value directly in client web page, using SignalR. Template Gentelella : https://github.com/puikinsh/gentelella npm init -y npm install @aspnet/signalr npm install gentelella –save dotnet build WARNING : all of my code use hard IP adresse 192.168.8.123, please change it to yours or add a dynamic system. GPIOs Service (host) Thanks to Jeremy Lindsay, I could use the GPIOs as I wanted. Here is some usefull links : https://jeremylindsayni.wordpress.com/2017/05/01/controlling-gpio-pins-using-a-net-core-2-webapi-on-a-raspberry-pi-using-windows-10-or-ubuntu/ https://jeremylindsayni.wordpress.com/2017/04/05/turning-gpio-pins-high-and-low-on-a-raspberry-pi-3-using-net-core-2-and-ubuntu/ https://jeremylindsayni.wordpress.com/2017/04/18/write-net-core-2-once-run-anywhere-hardware-access-on-raspberry-pi-3-with-ubuntu-and-windows-10-iot-core/ I copy some classes into /GpioManager folder. And my code is basically located into the worker class (/HostedServices/Worker.cs) Here is some usefull commands For Raspbian Debian 9 Jessie you need to do the following (only once): sudo apt-get update sudo apt-get install curl libunwind8 gettext apt-transport-https chmod 755 ./MyWebApp export ASPNETCORE_URLS= »http://*:5000″ export ASPNETCORE_URLS= »http://192.168.8.123:5000″ echo $ASPNETCORE_URLS ./MyWebApp WiringPi WiringPi is a lib for linux (not C#) this can be helpfull to check input status or manually set them. gpio readall gpio mode 0 in (0 match GPIO 17) gpio mode 2 in (2 match GPIO 27) gpio mode 5 out (5 match GPIO 24) Deploying Deploy Asp.net Core 2.1 https://github.com/dotnet/core/blob/master/samples/RaspberryPiInstructions.md#linux On dev environnement : dotnet publish -c Release -r linux-arm copy publish folder content to RapsberryPi or I wrote some powershell script that can helps to deploy in one command line. .\ps-deploy-raspian.ps1 -ip 192.168.8.123 -destination « /home/pi/Dotnet/Nadine » -username pi sudo ./home/Dotnet/Nadine/Nadine

Retour d’expérience sur Angular JS + Web API 2 + Oauth2

    Démo live Listy : http://listy.reactor.fr Pour la petite histoire, on m’a demandé de faire un devis concernant une application web. Normalement on ne commence pas le travail tant qu’on a pas un acompte et surtout un cahier des charges bien ficelé. Surtout lorsque le client n’est au final plus trop sur de lui… qu’il doit réfléchir. Bref vous l’avez compris, j’ai travaillé à perte. Mais j’ai beaucoup gagné en compétence… En effet le sujet est simple : créer une liste d’envie sur internet. Il en existe déjà quelques une plus ou moins abouties. Le principe consiste à faire une liste de course avec des liens web et de sortir une liste au final à partager avec ses amis. Au premier abord, pas un énorme intérêt. Dans mon cas personnel j’adhère à l’idée pour noël, au lieu d’acheter des cadeaux pourris (chose que l’on fait quand même pour le fun), on se fait une liste d’objets utiles ou qui peuvent nous intéresser, chacun s’organisant comme il veut pour offrir le ou les cadeaux en question. J’avais besoin d’un projet comme celui ci pour enfin me former sur Angular. Entre temps j’ai fait une conf sur Angular 2 et bon… je tombe mal on va dire. Mais l’expérience en valait la peine. Ici je vais vous présenter ce que j’ai fait, les méthodes utilisées, les softs, plateformes… et surtout ce qui m’a posé problème en vous donnant les solutions. 1) Architecture :   Je voulais une architecture qui me permet de totalement découpler les services de l’application. Un peu d’historique : 1) Il y a quelques années, et ça se fait encore bien sur, on avait un site web (Asp.net WebForm) hébergé sur un IIS qui avait sa propre base de donnée. Du all in one. Très pratique. En effet pour accéder aux données on pouvait directement taper dans la BD pour afficher une donnée. Depuis les développeurs ont structuré leurs applications en ajoutant des couches, notamment la couche d’accès aux données (DAL) et une couche métier. Avantage : plus propre, réutilisable, maintenance plus simple, on peut changer de BD sans tout péter…Inconvénient, plus compliqué pour un débutant, plus de code donc un peu plus lourd à maintenir (oui c’est aussi écrit en avantage…) 2) On a vu ensuite apparaitre dans Visual Studio le modèle MVC. Depuis on ne parle que de lui. D’ailleurs j’ai cru lire quelque part que Microsoft allait laisser tomber WebForms dans ces prochaines versions de Visual Studio. J’ai personnellement mit du temps à m’y mettre. C’est une autre façon de concevoir son application qui a aussi ses avantages et inconvénients. Mais l’intérêt majeure face aux WebForms, c’est que l’on peut y faire des tests. J’en parlerai pas ici, c’est pas mon fort. La encore on avait tendance à accéder aux BD directement, soit en mode crado, soit via une couche. 3) Puis les sites webs ont proposé des fonctionnalités que l’on aurait bien vu dans nos mobiles, dans une application. Problème : comment accéder à nos données ? Sur le site web, on a quelques éléments de sécurité et fonctionnalités « intégrés » de façon native (la session, le système de fichier, droit utilisateurs, …) ce que j’appelle du all in one. Mais la le client, c’est à dire l’application mobile est totalement déconnecté de mon environnement de production. Qui plus est, sur un OS potentiellement différent et potentiellement dangereux, pas stable, hostile… pire entre les deux on a INTERNET le mal absolut si j’en crois mon ancien employeur Jaques Séguéla… Qui depuis à compris qu’il pouvait se faire du blé alors il a changé d’avis. Bref, comment faire ? Pour cela un web service était nécessaire. Jusque la j’avais travaillé avec SOAP. Mais bon SOAP c’est pas vraiment une archi, c’est plutot un protocole. Et puis SOAP c’est chiant. Depuis on ne parle plus (ou presque) que de REST. REST (Representational State Transfer) comme son nom ne l’indique pas est sans état (en fait dans le titre on parle d’état d’une ressource, et non de l’application). Ceci à des conséquences pour l’expérience utilisateur, surtout pour les « sessions » car en faite il n’y en a pas ! Vous pouvez laisser votre application dans un état et la retrouver dans le même état quelques temps après. En général, par exemple avec Asp.net WebForm, votre temps de sessions par défaut était de 20 min. Les développeur avait tendance à stocker pas mal de chose dedans. C’était très pratique mais on perdait tout ou presque à la fin de session (sauf bricolage ou stockage en BD). Ici pas de session. Cela va avoir un impact pour la sécurité de nos données (nous le verrons plus tard). Mais surtout, enfin pour moi, l’expérience utilisateur va en être affecté positivement : suivant le niveau de sécurité voulut, on peut maintenir un équivalent « session » sur plusieurs heure, voir jour. Comme sur Facebook ou l’on a pas besoin de se reconnecter toutes les heures. Un autre intérêt de REST c’est qu’au niveau maintenance et évolution des serveurs c’est plus simple à gérer. Mais le gros gros intérêt de REST, c’est qu’il vous permet de gérer n’importe quel type de client. Ici nous parlerons d’un client web Angular.js, mais rien ne vous empêche de créer une app Native Android ou un client Windows 10, le serveur n’aura besoin d’aucun update ! Il est prêt pour tout, ce qui change du tout au tout par rapport à un site php ou asp.net. (moins vrai avec la dernière version d’Asp.net qui combine MVC et API2) Coté client la encore, de la souplesse. J’utilise Angular principalement pour des raisons de formation, mais aussi pour éventuellement reprendre ce code et l’utiliser avec Ionic ! Ce formidable framework est basé sur Angular et propose de déployer son app, grâce à Cordova, sur plusieurs OS mobile comme iOS, Android ou Windows Phone. Donc vous l’aurez compris, utiliser ce genre d’architecture permet de voir loin ! 2) La construction Pour l’IDE, j’ai opté pour Visual Studio 2015, normal vu que je…