DKIM SPF, le WTF sur MX

DevOps, Non classé

Si vous avez vous aussi des problèmes pour envoyer des emails à des boites Gmail depuis votre boite pro, et que vous avez un message de retour comme ceci, Mail Delevery System This is the mail system at host mo536.mail-out.ovh.net. I’m sorry to have to inform you that your message could not be delivered to one or more recipients. It’s attached below. For further assistance, please send mail to postmaster. If you do so, please include this problem report. You can delete your own text from the attached returned message. The mail system <ape.crevin@gmail.com>: host gmail-smtp-in.l.google.com[74.125.206.27] said: 550-5.7.26 This mail is unauthenticated, which poses a security risk to the 550-5.7.26 sender and Gmail users, and has been blocked. The sender must 550-5.7.26 authenticate with at least one of SPF or DKIM. For this message, 550-5.7.26 DKIM checks did not pass and SPF check for [outquest.fr] did not 550-5.7.26 pass with ip: [51.210.91.12]. The sender should visit 550-5.7.26 https://support.google.com/mail/answer/81126#authentication for 550 5.7.26 instructions on setting up authentication. v7-20020adfebc7000000b00307774d73a8si474631wrn.1056 – gsmtp (in reply to end of DATA command)   alors vous êtes au bon endroit. Cependant , je vais pas m’étendre sur le sujet car, c’est relou, ya 2 pellos qui viendront lire cet article, et surtout je pense que ca va être automatisé d’ici peut de tps.  Outil de test Voici deux liens qui permettent de comprendre ce qu’il se passe https://www.mail-tester.com/ Cet outil permet d’avoir pas mal d’info sur votre serveur mail, il m’a permit de debuger le SPF  https://toolbox.googleapps.com/apps/checkmx/ Ce dernier permet de voir comment Google voit les choses… mais en fait je pense qu’il aide pas bcp, je mets ça là…  Ma config J’ai un service email chez OVH (Email Pro), mais mon Register DNS est ailleurs (PlanetHoster) et pour le moment je veux pas changer car mon dns outquest.fr est gratuit à vie chez eux.  Faut savoir qu’à mon avis, si on a tout chez OVH, DNS et MX ça doit se faire tout seul… mais en vrai j’en sais rien.    SPF Voici la ligne supplémentaire que j’ai ajouté à mon DNS TXT 14400 outquest.fr.  « v=spf1 include:_spf.google.com include:mx.ovh.com ~all » Honnêtement je pige pas trop ce que ça fait, ni même si la partie google n’est pas de trop (je pense qu’elle est de trop) mais bon, ça à l’air de marcher alors je touche plus à rien.  DKIM DKIM c’est un échange de clé privé/public pour vérifier que vous envoyer bien du serveur officiel (outquest.fr pour moi) et que vous n’êtes pas un usurpateur (spammer) Pour ce faire, chez OVH ya toute une procédure ici  https://help.ovhcloud.com/csm/fr-dns-zone-dkim?id=kb_article_view&sysparm_article=KB0058101#pour-e-mail-pro Lisez bien toutes les petites lignes et faites gaffe la doc est pas toujours à jour et l’API en beta… Donc faut faire qq manipulation directement via l’API d’OVH https://api.ovh.com/console/#/email/pro à l’étape 3, le status va être à « Todo », puis passer à « waitingRecord » au bout de qq minutes.  Faites l’étape 4 en attendant. Celle ci consiste à rajouter une entrée DNS, qui elle même va mettre du temps à se propager (d’où le status « waitingRecord ») à l’étape 5 ou vous dit qu’il faut attendre que ce status passe à « ready ». Donc revenir à l’étape 3 et retenter de tps en tps jusqu’à obtenir un status « ready ».       Etape 1 [« ovhemp1076131-selector1″ »ovhemp1076131-selector2 »] Etape 2 Etape 3 après qq minutes, le status passe de todo à waitingRecord Etape 4 Pour passer à l’étape 5, il faut que l’état status soit « ready ».  J’ai cru à un délais de propagation lent du CNAME, mais deux jours plus tard, c’était autre chose.  Alors le support d’OVH m’a gentillement répondu qu’il me manquait un point dans mon CNAME. Voici la cible à utiliser :ovhemp1076131-selector1._domainkey.2370.ad.dkim.mail.ovh.net Voici la cible que j’ai configuré :ovhemp1076131-selector1._domainkey2370.ad.dkim.mail.ovh.net. Le targetRecord reçu de l’API est donc faux. Par contre la doc est ok. Donc si on a pas l’oeil, c’est tendu…  Après changement j’ai refais l’étape 3 : { customerRecord: « ovhemp1076131-selector1._domainkey.outquest.fr » header: « from;to;subject;date » lastUpdate: « 2023-06-13T16:34:35+00:00 » recordType: « CNAME » selectorName: « ovhemp1076131-selector1 » status: « ready » targetRecord: « ovhemp1076131-selector1._domainkey2370.ad.dkim.mail.ovh.net » taskPendingId: 0 } Etape 5 On y est, ce coup ci l’API nous renvoit qq chose qui ressemble à la doc.  Résultat En refaisant un test email avec https://www.mail-tester.com/ j’obtiens un score de 8.2/10 (7/10 avant). Ma DKIM est bien configurée.

Signoz et OpenTelemetry avec une app .net sous linux

.net 6.0, Asp .net, Asp.net Core, Azure Devops, C#, Debian, DevOps, Microsoft .net, Nginx

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

Azure Devops, CI/CD, DevOps

Qu’est ce qu’Azure Devops ? A quoi ça sert ? Comment l’utiliser ?  Je vais tenter d’expliquer par l’exemple et l’expérience ce que l’on peut faire avec Azure Devops Un bref historique Il est l’héritier de plusieurs anciens outils. Si je remonte loin on a VSS (visual source safe) qui était le svn de Microsoft, un gestionnaire de code source. Ensuite on a eu Team Foundation Server qui était un peu plus sérieux, on commençait à voir des outils annexes comme un board avec des work items. Git étant devenu une référence, Microsoft s’est adapté et a la intégré sur toutes ses plateformes. On a eu aussi VS Online (Visual Studio Online) et dans le même temps Microsoft rachetait HockeyApp qui deviendra App Center (spécialisé dans l’application mobile). C’est indépendant, mais j’imagine que demain tout ne fera qu’un. Et puis est né Azure Devops. Tout ça pour dire qu’il est pas arrivé comme ça. C’est le fruit d’années d’évolution et de savoir faire.   Azure Devops est gratuit.  Azure Devops est multi projets, multi utilisateurs, … voir ici pour le limites A quoi ça sert ? Alors qu’on soit bien clair, Azure Devops n’est pas indispenable… jusqu’à ce qu’on s’en serve… Azure Devops c’est une plateforme web qui regroupe plusieurs gros services : Board : un outil qui permet de créer des work items et de les organiser suivant des méthodes agile (scrum, kanban) Repos : un repo git, où l’on peut y voir les commits, pushes, branches, tags, pull requests Pipelines : orchestrateur automatique. Permet de lancer des « scripts » yaml et d’automatiser notre chaine de livraison continue.  Test Plans : La section test. Artefacts : ce que vous aller produire se retrouve ici.  Les deux derniers, j’en parlerai pas, je connais pas bien. Les 3 premiers sont des supers outils, ils sont liés.  En premier lieux on va utiliser Board pour s’organiser, créer des tâches et les répartir aux membres de l’équipe. Bien entendu il nous faut un repos Git. Ils nous permet de gérer notre code source. Enfin, quand le projet avance, on ajoute de l’automatisation pour que notre chaine de livraison continue fonctionne toute seule.  Comment l’utiliser ? Pour cela j’ai écris 9 articles qui se focalise sur la chaine de livraison/déploement continue CI/CD 1 – Première pipeline, On y apprend à faire un build tout simple : Azure Devops Pipeline (CI/CD) – First Build 2 – Deploiement via SSH Azure Devops Pipeline (CI/CD) – Deploy 3- Versioning Azure Devops Pipeline (CI/CD) – Versioning 4- Gestion des environnements Azure Devops Pipeline (CI/CD) – Environnement Azure Devops Pipeline (CI/CD) – Relancer les services 5- Git Flow Azure Devops – Git Flow intro 6- Pull Request Azure Devops – Pull Request Azure Devops – Pull Request (part 2) Voilà, j’espère que ça pourra servir à quelqu’un 🙂 

Azure Devops – Pull Request (part 2)

Azure Devops, CI/CD, DevOps, Git, Git Flow, pipeline

Cet article est la suite de https://reactor.fr/azure-devops-pull-request/ On avait créé des règles de branche sur la master : interdiction d’effacer cette branche pas de git push direct sur cette branche règle de Pull Request (light) Ceci nous permet de sécuriser la branche master. Faisons de même avec la branche develop. Rappels Git Flow On a vu la PR develop –> master.  Maintenant, on va ajouter une PR sur chaque commit vers la branche develop. Si on applique Git Flow, on aura une branche feature qui devra à un moment livrer son contenu sur la develop.  La PR intervient à ce moment.  Règle de branche develop sur Azure Devops On va donc fairre un clic sur le menu de la ligne représentant la branche develop dans Repos – Branches, puis on sélection "Branch Policies" Pour la branch dévelop, j’ai rajouté plus de contraintes que la master. En effet je veux qu’en premier lieu chaque commit sur la branch dévelop corresponde à un work item. Ensuite si il y a une intervention d’un reviewer, celle ci doit être résolut par un commentaire. Dans la pratique ça peut simplement être une question qui ne demande pas vraiment d’intervention. Mais ça peut aller jusqu’à ce que le reviewer demande un refacto voir refuse carrément le code (c’est rare…) Je limite aussi le type de merge afin d’avoir un historique lisible et en cohérence avec la branche master. Ensuite j’ajoute une règle de build. Je sélectionne une nouvelle Pipeline que je viens de juste de crée : pool: vmImage: ubuntu-latest variables: buildConfiguration: ‘Release’ projectBlazorWasmServer: ‘src/BlazorDemo/BlazorDemo/Server/BlazorDemo.Server.csproj’ steps: # Publish Blazor Demo Server – task: DotNetCoreCLI@2 displayName: Publish inputs: command: publish publishWebProjects: false projects: ‘$(projectBlazorWasmServer)’ arguments: ‘–configuration $(buildConfiguration) –output $(build.artifactstagingdirectory)’ zipAfterPublish: false modifyOutputPath: false La seule différence avec l’autre pipeline de build, c’est que je ne précise pas le trigger. En effet, je ne connais pas le nom de la branche feature. Donc par défault ce sera la source de la PR concernée. Mise en situation Mon tech lead m’a affecté une tâche. On va aller la créer pour la simuler, normalement elle est déjà existante : Je suis développeur, je dois donc créer une branche si elle n’existe pas déjà. Sut mon terminal je tape : git checkout -b feat/LoginPage Je développe, quand j’ai fini : git add . git commit -m « mon travail sur la page login » git push –set-upstream origin feat/LoginPage Je peux bien évidement avoir plusieurs commit et/ou avoir d’autre commit d’autre développeurs. D’ailleurs (si vous avez les droits) n’importe qui peut aller voir ce qu’il se passe sur cette branche depuis Azure Devops : La Pull Request feat -> develop Azure Devops sait qu’une branche feat/LoginPage est en cours et vous propose directement de choisir celle ci et de créer une pull request à partir de celle ci. Dans mon cas j’ai eu ceci : C’était pas voulu, mais j’ai eu la surprise de voir que j’ai un conflit de merge. Et c’est finalement un point intéressant à montrer.  J’ai pas récupéré la branche develop dans mon dev sur ma branche feature. Et honnetement ça arrive TOUT LE TEMPS.  Normal, qq a pu entre temps livrer qq chose sur la branche develop. Il faut donc s’assurer que ce nouveau code s’intègre au mien. Il faut alors lancer toute une série de commandes git: git checkout develop git pull git checkout feat/LoginPage git rebase develop git pull git push Explication : on change de branche pour aller sur develop. On récupère la dernière version de cette branche. On re bascule sur notre branche feat. On applique ces nouveautés (rebase permet de garder un historique chronlogique en mettant nos modifs après celle de develop). A ce stade on est iso en local. Faut faire un pull pour que ça lance un merge automatique (ca met au carré le repo local et le distant et prépare au push) Et enfin on push sur le repo distant.   Maintenant on retourne sur Azure devops : Ya plus de conflit ! 🙂 si on regarde de plus prêt Il ne reste plus qu’à associer notre PR à un Work Item : Ce qui résoud le problème : On peut valider le PR : Ceci effacera la branche feat/LoginPage Au final : Conclusion Pourquoi c’est génial ? C’est vrai qu’avant on publiait directement sur develop et tout allait bien. Et vous avez pas tort. Chacun travail comme il le souhaite.  Avec cette façon de faire, vous allez prendre un petit plus de temps à faire un "peu de paprasse". Mais on a un suivi très intéressant sur chaque étape de la construction de morceau d’application. Tout est lié, et tout le monde peu savoir ce qu’il se passe. Qui travaille sur quoi et quand. Attention, faut pas le voir comme un outil de flicage, mais plutot un outil d’orchestration dans une équipe logiciel.  L’élément que j’ai peu évoqué ici, et qui est relié à a chaque PR c’est le board. Le Board permet de suivre des work items de plusieurs types : Chacun s’organise comme il veut. On peut créer autant de work item que l’on veut et utiliser scrum ou kanban Le développeur se focalise sur sa feature et traite de bout en bout celle ci (jusqu’à la branche develop) Le tech lead suit tout ça. A chaque fin de sprint, ou quand il le souhaite, il peut faire une release. Le product owner est au courant des évolutions de son app.  Azure Devops est vraiment un super outil.  Et j’ai pas fait le tour de toutes ses possibilités.

Azure Devops – Pull Request

.net 6.0, Azure Devops, DevOps, Git, Git Flow, pipeline

Dans mon dernier article, j’ai introduis Git Flow avec un exemple, la naissance d’une application.  A un moment, je raconte l’évolution de l’équipe de dev et de leur organisation autour du code source. On y parle de Pull Request.  La PR est une procédure de validation d’un ensemble de commits regroupés dans une branche feature (quand on applique Git Flow). On peut aussi appliquer une PR de la branche develop vers master. C’est ce qu’on appelle une "release".  Chacun ayant ses stratégies, je vous propose la mienne, qui va bien pour un petit/moyen projet :  Situation J’ai 2 branches principales : master. A considérer comme la branche release car c’est ce code qui part en prod. develop. Son code part en staging. Ca sert aux dev pour voir le résultat de leur travail sans influencer la prod. Quand j’estime que la branche develop a quelque chose d’intéressant, je pousse le code vers la master (merge).  Cette action est réalisé via une Pull Request depuis Azure Devops. Je ne fais aucune manipulation git. Tout ce passe sur Azure Devops. D’ailleurs j’ai interdit toute manipulation de la branche master en dehors d’une PR. Voyons voir comment faire cela : Règle de branche master Sur Azure Devops, il faut se rendre sur l’onglet "Repos" puis "Branches" : Cliquez sur le bouton à droite de la branche master, ce qui ouvre un menu. Cliquez sur Branch Policies. Nous y voila, si on lit la première ligne, elle nous dit que si une seule des options est cochée, alors la branche ne peut pas être effacée et toute modification devra passer par une PR. Quelque part, je pourrais m’arréter la car c’est tout ce dont j’ai besoin. Mais on va voir qu’il y a quelques options bien intéressantes : Require a minimum number of reviewers. J’ai une équipe de 1 dev, moi. donc je vais m’auto évalué, ça n’a pas de sens. Je n’ai pas coché cette case. Mais c’est intéressant dès lors qu’on valide par un second dev (lead tech pour la master).  – Check for linked work items. Cette option est intéressante dès lors que l’on travaille avec un backlog. Ce qui n’est pas mon cas pour ce projet "demo". Mais c’est conseillé. En effet, vous allez améliorer chaque PR avec un "work item" qui sera donné par votre product owner ou votre tech lead. C’est hyper quali de faire ça. Surtout intéressante depuis une branche feature vers la develop. Ici depuis la branche develop vers la master, on aurait plus un ensemble de feature. A voir avec les types de work item. Si ca se trouve ça peut coller.  Check for comment resolution option pas obligatoire. Si coché, cela force à valider tout commentaire dans le code. On le verra plus tard, mais si un reviewer constate un manquement, une erreur ou une objection dans le code, il le signifie par un "commentaire". Si celui ci n’est pas "résolut", alors on peut pas valider la PR. A tester avec votre équipe. La encore, c’est intéressant pour une PR vers la branche develop  Limit merge types cette option permet de laisser le choix lorsque la PR est validé, de choisir le type de merge que l’on souhaite appliquer à la branche cible. Pour mon cas, je ne laisse pas le choix, j’impose un squash merge. La encore, c’est les goûts et les couleurs. It’s up to you. Je pense qu’un article entier peut y être consacré. On en discute encore dans l’équipe où je bosse…  On va maintenant rajouter des règles de build : On ajoute une règle qui impose qu’un build s’execute correctement. Pour cela on doit construire une pipeline de build. Si la branche develop ne build pas, alors on ne fait pas le merge. Pour ma part, le build est un publish. Ce qui revient a peu prêt au même (un publish est un build + génération des fichiers statics web dans le cas d’une app Blazor WASM).  Ma première Pull Request On va tester tout ça. On va dans Repos – Pull request Cliquez sur New pull request : Il faut choisir sa source et sa destination, pour nous, develop –> master Notez que j’ai juste mis un titre. On peut ajouter des reviewers et bien sûr un work item. Tout ca on le verra dans une pull request de type feature –> develop. Cliquez sur Create. Voici ce qui se passe : Première chose, on a un élément requis qui doit se lancer. Celui ci c’est notre "règle de build" écrite juste avant.  Notez aussi qu’il y a un check "No merge conflict". Ce qui permet de vérifier en amont qu’on a pas foiré un merge/rebase malencontreux.  Si on attends qq secondes : On voit notre pipeline qui se lance et qui passe au vert si notre publish est ok.  En haut a droite on a un bouton approve qui va concerner des validations "humaines". Tout est vert. On a un pre-merge ok. Un build ok. Pas de reviewer, et pas d’autre règle (j’ai volontairement fait en sorte que ce soit pas trop compliqué pour cet exemple)  Si on clic sur Complete On a un message qui veut supprimer develop. On veut pas. Surtout pas. D’ailleurs on fera en sorte par la suite de rendre develop ineffacable.  Le squash commit est l’unique option, comme indiqué dans les règles de la branche master que l’on vient de définir. On peut si on veut rajouter un commentaire personalisé de commit.   On clique sur Complete merge, quand il est fini, on a cette info : Et si on vérifie nos pipeline, notre DEPLOY master to prod est lancée ! On vient d’automatiser notre branche master. Elle est sécurisée (personne hormis une PR peut la modifier). Elle est tracable et on peut échanger via une interface web sur une operation qui d’habitude se passe en ligne de commande dans un coin.  De plus en rajoutant une seconde pipeline, lorsque la PR est validé puis mergé, on a un deploy automatique vers la prod.…

Azure Devops – Git Flow intro

.net 6.0, CI/CD, DevOps, Git, Git Flow, Non classé

Intro Git Flow tu connais ? non ? Et Git tu connais ? non…ouais faut faire un effort la monsieur (ou madame). Alors git j’explique pas. Si tu connais pas reviens me voir, mais va tout de suite apprendre qq commandes car c’est juste une tuerie ce truc. Quand t’as connus vss, svn ou team foundation server, tu sais que git te sauve la vie. Il est juste incontournable aujourd’hui. Ho tu pourras faire semblant qq heures, mais tu vas vite te retrouver dans l’impasse. Un conseil, tarde pas trop, apprends git ! Et en ligne de commande, pas avec un outil (quoi qu’un outil peut éventuellement t’aider, mais crois moi, fait tout en ligne de commande…) J’ai personnellement tardé à y passer. Trop. Et j’ai aussi utilisé des outils graphiques. Personne n’est parfait ! Alors si tu es encore la, tu sais ce qu’est une branche, un merge ou un rebase, un commit…   C’est quoi Git Flow ? A lire, surtout le premier : voici 3 liens : https://danielkummer.github.io/git-flow-cheatsheet/index.fr_FR.html https://grafikart.fr/tutoriels/git-flow-742 https://git-flow.readthedocs.io/fr/latest/presentation.html Ca cause Git Flow mieux que moi. Je suis ici pour vulgariser. Alors Git Flow c’est un ensemble de commandes git qui permettent de s’organiser autour du code source d’une application. Git Flow propose une stratégie pour gérer le cycle de vie d’une application coté code source, du développement locale jusqu’aux versions releases finale en passant par des branches qui auront un but précis.  En vrai, c’est juste des commandes git ! C’est une surcouche qui facilite la vie. Enfin en théorie. Perso j’utilise les principes de Git Flow mais pas ses commandes.  Pour expliquer Git Flow, on va se mettre dans un contexte, imaginons la vie d’une application, par exemple Tonder, une app web pour flirter.   V0.0.1 alpha – naissance d’une app Il était une fois un développeur en recherche d’amour (il veut ken à donf) et il lui vient une idée d’application qu’il nomma Tonder. Le dev est tout seul sur son projet. Il bosse dessus comme un ouf et sort sa premiere app Tonder Alpha 0.0.1 Il est content, mais c’est une version alpha. Elle tourne sur un serveur à lui dans sa piaule, bancale, comme son code.  V0.1.0 bêta Arpès quelques jours de discussion avec son hamster, son app ressemble à quelque chose, il veut faire tester son app et la rend disponible en version bêta privé. Il a donc une « prod » (toujours dans sa piaule) et il s’appercoit qu’il devient difficile de travailler directement sur sa prod sans prendre le risque de tout péter. Alors il crée une version « staging » sur laquelle il bosse.  Mais pour le moment, il existe qu’une « version » de son code. Aucun historique, tout est en local sur un disque dur de sa machine. Un virus, un feu domestique, un coup de foudre, pire trouver une meuf et avoir des gosses… il peut tout perdre.  Notre dev se dit qu’il serait bien d’avoir un controleur de code source qui lui permettra de  sauvegarder son code sur un cloud le rendre accessible à d’autre dev via ce cloud pouvoir gérer l’historique de son code  Alors il crée son repo Git, qq part où il sait qu’il sera accessible et disponible.  V1.0.0 Première release officielle Ca y est, notre dev sort enfin au grand publique sa super App. Il est fiert. Il est content. Son poil brille (il a pas pris de douche depuis 72h, 15 cannettes de coca trainent sur le bureau, il ne sait même plus quel jour on est, et si d’ailleurs c’est le jour ou la nuit …) Les retours utilisateurs arrivent. Il les traite comme il peut, avec le mécanisme suivant : « je code en dev locale, puis si ca marche je passe sur staging puis si ca plante pas je balance sur la production ». Il fait tout à la main, pas d’automatisation, il se dit qu’il a pas le temps pour ça et que c’est qu’une petite release de plus, ça prendra 5 min… Ils se dit qu’il aimerait bien un peu d’aide… et prendre l’air… V1.0.547 Ca build à donf Notre développeur ne compte plus le nombre de build qu’il a fait. Toujours à la main. Ce coup ci il décide d’automatiser sa chaine de livraison/deploiement continue. Il passe par : son premier build automatisé : https://reactor.fr/azure-devops-pipeline-ci-cd-first-build son premier deploiement automatisé : https://reactor.fr/azure-devops-pipeline-ci-cd-deploy ses versions automatisées : https://reactor.fr/azure-devops-pipeline-ci-cd-versioning multi environnement : https://reactor.fr/azure-devops-pipeline-ci-cd-environnement Il est vraiment satisfait. Certe il vient d’y passé quelques heures. Mais a présent il ne s’occupe ni de son staging, ni de sa prod. Tout est fait automatiquement. Et du coup il peut prendre l’air… ça lui rappel d’ailleurs qu’il a un chien… mais il est où son chien ? V1.1.41 1er co développeur Enfin un peu d’aide ! Un nouveau dev arrive en renfort. Git devient indispensable.  Jusque là, le repo git contient 2 branches, une master et une develop.  La branche develop est celle que les développeurs utilisent.  La master sert de branche « release ». Quand on estime que l’on a quelque chose, on pousse du code depuis la branche develop vers la master.  Une pipeline s’occupe de mettre à jour le staging dès que la branche develop reçoit un commit. Une pipeline s’occupe de mettre à jour la prod dès que la branche master reçoit un commit. Nos deux devs travaillent en simultané sur la branche dev. A chaque commit, on a run de pipeline, ca fait bcp de deploiement pour parfois pas grand chose. Alors nos deux devs décident de travailler en branche.  Chacun aura sa branche au départ. Mais nos développeurs se rendront compte qu’avoir une branche chacun revient à avoir deux versions de la branche develop (en plus de celle ci). Il ne profite pas des avancés de chacun et attendent que la branche develop soit à jour pour récupérer le travail de l’autre, via des cherry-pick ou des rebases hasardeux. C’est un peu confu, et nos deux devs décident d’appliquer Git Flow avec des branches feature (fonctionalités).  Ainsi, ils peuvent travailler tous les deux sur une feature si il…

Azure Devops Pipeline (CI/CD) – Secrets

Asp .net, Asp.net Core, Azure Devops, C#, DevOpsLaisser un commentaire

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) – First Build

Asp.net Core, Azure, Azure Devops, Blazor, C#, DevOps

Intro En général, quand on découvre une techno, on fonce direct en dev local et on s’amuse. C’est ce que j’ai fait aussi, mais j’ai pas tardé à mettre en prod. Car par expérience,  mieux vaut avoir les problèmes au début, tant que le projet est pas trop gros ou trop compliqué.  Donc l’idée de ce billet, c’est voir comment on pourrait monter une chaine CI/CD (continious intergration/ continuious deployement) sur un projet blazor de base.  Projet de base Blazor Avec Visual Studio 2022 Community, on créer un projet Blazor WASM, avec Hebergement Asp.net core et PWA : Pour ma part je l’ai nommé BlazorDemo.  Je me suis permis de modifier qu’une seule ligne, dans program.cs du projet server. Je spécifie juste un port pour ma prod. Voir artile https://reactor.fr/net-core-sous-linux-nginx-80-http-443-https-firewall/ Azure DevOps Pipelines Azure Devops, c’est GitHub, Maven, Jenkins et j’en passe tout ça dans une appli web.  Ca nous permet de faire du CI/CD depuis nos propres repos (qu’ils soient sur BitBucket, Azure devops, GitHub, ou autre…) L’idée est de partir sur deux branches git, une master et une develop.  La master sera considéré comme la Prod. La develop comme la branche de travail.  A chaque fois que la branche master recevra un commit, on lancera une "pipeline" qui fera plusieurs actions, comme builder, lancer des tests et deployer.   A l’avenir, la branche master ne pourra plus recevoir de commit directement, ceci sera bloqué par defaut. Le seul moyen sera de faire une Pull Request depuis la branche develop vers la branche master. Ceci afin de mettre en place de bonne pratique de développement et de gestion de code source.  Bien sûr on pourrait pousser le concept plus loin, en pratiquant du Git Flow par exemple. Mais restons simple pour bien comprendre les mécanismes d’AzureDevOps 1ere pipeline Commençons par créer notre première pipeline. Menu Pipeline Cliquez sur New Pipeline Comme je le disais tout à l’heure, notre code source peut se situer sur différent repos, choisissez le votre : On choisit ensuite son repos, dans mon cas ceci :  Ensuite il faut choisir un modèle de script YAML. Alors ici, c’est pas clair je trouve. J’ai choisis "Asp.net Core" qui n’est pas présenté comme premier choix. Ce qui pourrait m’induire en erreur. Enfin de toute manière, c’est qu’un modèle, qu’on peut modifier par la suite. Voici le résultat : En cliquant sur Save and Run, puis valider l’écran suivant par defaut, vous allez ajouter un fichier "azure-pipelines.yml" a la racine de votre repo, sur la branche master. S’en suit un run automatique, qui au bout de qq seconde va échouer : En cliquant dessus pour voir le détail : Puis sur Job et sur l’élément en rouge : On a le détail du pourquoi le job a échoué. On a le détail du pourquoi le job a échoué. Ca nous dit que l’on a pas spécifier de projet à compiler… et c’est vrai MSBUILD : error MSB1003: Specify a project or solution file. The current working directory does not contain a project or solution file. Correctif de la 1ere pipeline Vous pouvez corriger directement depuis la plateforme azure devops pour bien le faire depuis votre editeur préféré et jouer qq commande git. Pour ma part je préfère cette derniere.  Je récupère donc via un git pull ma branche master sur mon visual studio code et je modifie le fichier azure-pipelines.yml avec cette ligne script: dotnet build –configuration $(buildConfiguration) src/BlazorDemo/BlazorDemo/Server/BlazorDemo.Server.csproj Le path ici peut différer selon votre répertoire repos. (moi j’ai mis tout ca dans un folder src, qui contient un répertoire  blazordemo qui contient un répertoire "solution" blazordemo. Quand votre modification est faites, il faut alors mettre a jour le repo distant avec un commit.  Rappelons que lorsque la branche master subit un nouveau commit, ca lance automatiquement cette pipeline. Et normalement vous obtenez un build vert :  Et voila, on a fait notre première pipelines qui fait qq chose de très basique pour le moment, builder !

.net Core sous Linux Nginx 80 http 443 https firewall

Asp.net Core, C#, Debian, DevOps, Nginx1 Commentaire

En voila un titre bien déguelasse. Suite à l’article précédent (comment heberger asp.net, un bref historique) je voulais consigner ici mes trouvailles concernant la mise en place d’un site web asp.net core sur Linux Debian.  Pour cela j’ai loué un VPS Linux chez iKoula pour 4€.  On a donc un accès SSH suite à l’obtention de ce dernier, on se connecte et je vous montre comment on fait un site web qui marche en .net Core.   Sources Voici les quelques sites web qui m’ont servit dans cet article. # Installer Dotnethttps://docs.microsoft.com/fr-fr/dotnet/core/install/linux-debian# Installer un firewall UFWhttps://debian-facile.org/doc:systeme:ufw# Installer NGinxhttps://idroot.us/install-nginx-debian-11/https://www.howtoforge.com/how-to-install-nginx-on-debian-11/# Config Nginxhttps://docs.microsoft.com/fr-fr/aspnet/core/host-and-deploy/linux-nginx?view=aspnetcore-6.0# Multi Sitehttps://webdock.io/en/docs/how-guides/shared-hosting-multiple-websites/how-configure-nginx-to-serve-multiple-websites-single-vps Projet web Asp.net core On commence par la création locale d’un site web en asp.net core .net 5. Qu’il faut bien entendu avoir sur son poste. Je vous renvois à la doc pour toute la paprasse,  https://docs.microsoft.com/fr-fr/aspnet/core/getting-started/?view=aspnetcore-6.0&tabs=windows C’est une des meilleurs doc du web, donc profitez en. Je vais pas la réinventer, je vais a l’essentiel. La commande suivante va vous créer une api web de base.  dotnet new webapi -o TodoApi On va garder l’exemple de microsoft « TodoApi », qui est en fait une api toute conne avec un seul control qui donne la météo. Je m’en fou total de ce truc, c’est pour l’exemple.  Pour moi il manque une route, celle de la « home ». Alors je rajoute un controler « home Histoire d’avoir qq chose à afficher à la racine du site. On teste le site web  dotnet run.  De base vos ports sont 5001 sur https (avec un certificat local de developer) et 5000 en http.  Ces ports sont localisés dans  Properties/launchSettings.json dans la propriété applicationUrl Si comme moi, vous avez plusieurs sites asp.net core, vous allez probablement changer ces ports. Et on va le voir par la suite cela a une grande importance. Moi je le fait directement dans le code source, mais ya d’autre méthodes. Le site tourne on va le publier  avec la commande suivante  dotnet publish -c Release Ce qui va créer un nouveau répertoire  binReleasenet5.0publish Ou on aura tous les fichiers nécessaires pour notre site web en production dedans.  Install Server VPS Alors avant toute chose, je suis pas un expert linux. Si je dis une connerie, faut le signaler dans les commentaires svp. J’ai un passif Windows qui m’a éloignié de Linux, meme si de base, je suis ingé système et réseau, de ya 20 ans… On commence, on se connecte en SSH.  Alors perso, j’ai découvert une extension de visual studio code qui facilite la vie. C’est Remote-SSH.Ca permet d’éditer des fichiers distants directement dans VS (et d’avoir tous les outils, couleurs, syntaxe, etc…) Mais ca fait aussi explorateur de fichier, FTP et bien entendu on a toujours une ligne de commande à porté de main, tout ca dans VS code. Un must have. Dotnet 5.0 Alors le serveur est une version Debian 11 de linux. C’est important de checker avant si .net Core est compatible ou pashttps://docs.microsoft.com/fr-fr/dotnet/core/install/linux   Nous on continue sur une Debian 11 :https://docs.microsoft.com/fr-fr/dotnet/core/install/linux-debian   On référence les packages Microsoft(wgt ==> w g e t, va savoir pourquoi je peux pas écrire ce mot la sur wordpress) wgt https://packages.microsoft.com/config/debian/11/packages-microsoft-prod.deb -O packages-microsoft-prod.debsudo dpkg -i packages-microsoft-prod.debrm packages-microsoft-prod.deb   Puis on install le SDK .Net 5.0 (la version 6.0 est sortie peu de temps avant cet article, donc passer en 6.0 c’est mieux)   sudo apt-get updatesudo apt-get install -y apt-transport-httpssudo apt-get updatesudo apt-get install -y dotnet-sdk-5.0 Nginx Pré install  sudo apt update sudo apt upgrade sudo apt install curl gnupg2 ca-certificates lsb-release Install sudo apt install nginx On Check nginx -v Ce qui donne pour moi : nginx version: nginx/1.18.0  on en profite pour installer un firewall ufw apt-get update && apt-get install ufw et on l’active  ufw enable Alors attention, ca pourrait couper votre connexion SSH, mais les gars ils sont pas trop con, ils ont par defaut ouvert le port 22.  On ajoute les règles de bases NGinx sudo ufw allow ‘Nginx HTTP’ A ce stade on devrait avoir un site web qui tourne. Donc aller changer votre DNS pour modifier ou ajouter un domain, par exemple prout.com qui pointe vers l’ip de votre serveur. Profitez en pour ajouter une nouvelle entrée A dans votre zone DNS todoapi.prout.com qui pointe vers la meme IP. Ca peut prendre jusqu’à 24h, mais aujourd’hui ca va plus vite. Si c’est un .fr ca devrait pas trainer. Sinon, faut pinger l’adresse jusqu’à avoir une réponse et une IP qui va bien.  Aller dans votre navigateur préféré et taper votre domaine, pour moi : http://prout.com et si vous voulez pas attendre taper directement l’ip de votre serveur. Notez que pour le moment on parle pas encore de https.  Et bimm : Tu n’as un beau serveur d’enculé ! Config Nginx On fait un pti point pour comprendre les choses.  Dans /var/www/html on a le code source de notre site web.  Dans /etc/Nginx on a notre serveur web Nginx et ses conf Le répertoire sites-available va contenir les configurations de nos sites web. Le répertoire sites-enabled va contenir des liens vers les config précédentes. Ce qui les rendra actives ! C’est ce que l’on va faire, on va créer un nouveau site. Pour cela on va commencer par mettre un nouveau répertoire dans /var/www qui va contenir le publish de tout à l’heure. Alors on y va, on copie… Ensuite il faut créer un fichier dans /etc/nginx/sites-available/, par exemple todoapi.prout.com.conf et on y met ceci server {    server_name todoapi.prout.com;    root /var/www/todapi;    location / {        proxy_pass         http://127.0.0.1:5002;        proxy_http_version 1.1;        proxy_set_header   Upgrade $http_upgrade;        proxy_set_header   Connection keep-alive;        proxy_set_header   Host $host;        proxy_cache_bypass $http_upgrade;        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;        proxy_set_header   X-Forwarded-Proto $scheme;    }  }   Noter 3 points, le serveur name avec le DNS de tout à l’heure. le root avec l’emplacement de notre publish. Et enfin le proxy pass et son port 5002. On…

Cloud VPS Hebergement asp.net Framework et Core

Asp .net, Asp.net Core, AWS, Azure, DevOps, Microsoft .net1 Commentaire

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…