C# 9 – Introduction

Les nouveautés du C# 9

Microsoft nous a récemment parlé du C# 9 durant la Build 2020, les experts INFEENY vont donc vous détailler et vous expliquer les nouveautés du C# 9.

Le Target typed

Ce que nous attendions depuis longtemps est enfin arrivé : le type ciblé (target typed). Il s’agit d’utiliser le mot-clé new() et seulement celui-ci pour instancier une class. Nous n’avons plus besoin de nous soucier du type à la création d’un objet à condition qu’il puisse être déduit par le compilateur.

Avant :


Classname objet =  new Classname(param1, param2) ;

Devient


Classname objet = new(param1, param2) ;

Comme nous pouvons le voir, dans la deuxième partie, le nom de la class avant le mot-clé new n’est plus utile.

Les propriétés Init-only

Avant C# 9 il fallait que des propriétés soit modifiables pour que l’initialisation de l’objet fonctionne. Cependant C# 9 introduit les accesseurs init qui permettent de set une valeur à une propriété qu’à l’instanciation de notre class.

Exemple :


public class Players
{
public int X { get; init; }
public int Y { get; init; }
}

Avec cette class l’utilisateur pourra donc modifier X et Y seulement pendant l’instanciation de la class sinon il renverra une erreur.

Le type record

Avant le C# 9, nous devions créer une class avec toutes propriétés déclarées dans celle-ci, ainsi que de surcharger (override) l’opérateur Equals et le GetHashCode. Enfin, créer un constructeur si besoin pour chaque propriété que l’on voulait set. Cela est de même pour le destructeur. Ce qui était fastidieux pour finalement peu d’utilité.

Aujourd’hui, C# 9 nous permet de faire cela en une simple ligne de code grâce au mot-clé data. Les propriétés crées seront en init-only. L’avantage du type record est donc sa simplicité. Cependant, sachez que vos propriétés seront immuables (const).

Avant :


class Players 
{
private int X {get;}
private int Y {get;}

public Players(int x, int y) 
{
this.X = x;
this.Y = y;
}
}

Devient


public data class Players(int X, int Y); // ici les propriétés sont en init-only,

si vous vouliez faire de l’héritage


public data class Mage : Players{int Mana} ; // cette class contiendra les propriétés X, Y, Mana

L’expression With

Si nous voulions modifier les valeurs des propriétés de notre class nous devrions donc créer une copie de cette classe en modifiant la valeur qui nous intéresse. C# 9 introduit donc une nouvelle expression : with. Cette expression clone l’objet d’origine, en remplaçant les valeurs des propriétés spécifiées entre les accolades. Pour cet exemple nous allons utiliser la class créer au-dessus avec data. Exemple :


Players player1 = new(1, 2) ;
Players player2 = player1 with {Y = 42};

La gestion des paramètre NULL

En plus du mot-clé with, C# 9 introduit une syntaxe simple pour vérifier automatiquement si des paramètres de fonction sont null. Cette syntaxe est représentée par un ‘ !’ après le nom du paramètre de votre fonction à vérifier. Si la variable a pour valeur null, il throw une exception du type ArgumentNullException.

Avant :


public string saysomethings(string somethings) 
{
if (somethings == null)

throw new ArgumentNullException(nameof(somethings));

return $"you say {somethings}";
}

Devient


public string saysomethings(string somethings!) => $"you say {somethings}";

L’égalité basé sur les valeurs

C# 9 a introduit une nouvelle fonctionnalité à l’opérateur Equals. Cette fonctionnalité permet donc de comparer deux objets selon les valeurs des propriétés et non pas l’objet en lui-même. Equals va donc comparer champs par champs et renvoyer true s’ils sont tous égaux.

La covariance du type de retour (modification)

Un nom bien compliqué qui vous simplifiera beaucoup la vie. Avant C# 9, en héritant d’une class, si nous voulions Override une méthode nous devions avoir le même type de retour que la méthode mère. C# 9 introduit le fait de pouvoir modifier ce type de retour. Exemple:


public class anyClass
{
public virtual anyClass Clone() => new anyClass();
}

public class SpecificAnyClass : anyClass
{
// Override with a more specific return type
public override SpecificAnyClass Clone() => new SpecificAnyClass();
}

Top level Programs ( Programmation au niveaux supérieur)

C#9 simplifie aussi l’écriture de code en permettant de le rédiger au niveau supérieur de votre fichier.

Avant :


using System;

class Program
{
static void Main()
{
Console.WriteLine("Hello World!");
}
}

Devient


using System; Console.WriteLine("Hello World!");

Pour finir, C# 9 ajoute aussi un dernier mot-clé : not. Il fonctionne de la même manière que « != ».

Exemple


if (player is not Mage) { … }

Pour conclure :

Nous avons balayé les principales fonctionnalités de C# 9

L’évolution du language C++ par son créateur – de 2006 à 2020

Le créateur du language C++ explique les changements introduits dans le C++ ISO de 2006 à 2020.

Thriving in a Crowded and ChangingWorld: C++ 2006–2020

BJARNE STROUSTRUP, Morgan Stanley and Columbia University, USA
Shepherd: Yannis Smaragdakis, University of Athens, Greece

By 2006, C++ had been in widespread industrial use for 20 years. It contained parts that had survived unchanged since introduced into C in the early 1970s as well as features that were novel in the early 2000s. From 2006 to 2020, the C++ developer community grew from about 3 million to about 4.5 million. It was a period where new programming models emerged, hardware architectures evolved, new application domains gained massive importance, and quite a few well-financed and professionally marketed languages fought for dominance. How did C++ ś an older language without serious commercial backing ś manage to thrive in the face of all that?
This paper focuses on the major changes to the ISO C++ standard for the 2011, 2014, 2017, and 2020 revisions.
The standard library is about 3/4 of the C++20 standard, but this paper’s primary focus is on language features and the programming techniques they support.
The paper contains long lists of features documenting the growth of C++. Significant technical points are discussed and illustrated with short code fragments. In addition, it presents some failed proposals and the discussions that led to their failure. It offers a perspective on the bewildering flow of facts and features across the years. The emphasis is on the ideas, people, and processes that shaped the language.
Themes include efforts to preserve the essence of C++ through evolutionary changes, to simplify its use, to improve support for generic programming, to better support compile-time programming, to extend support for concurrency and parallel programming, and to maintain stable support for decades’ old code.
The ISO C++ standard evolves through a consensus process. Inevitably, there is competition among proposals and clashes (usually polite ones) over direction, design philosophies, and principles. The committee is now larger and more active than ever, with as many as 250 people turning up to week-long meetings three times a year and many more taking part electronically. We try (not always successfully) to mitigate the effects of design by committee, bureaucratic paralysis, and excessive enthusiasm for a variety of language fashions.
Specific language-technical topics include the memory model, concurrency and parallelism, compile-time computation, move-semantics, exceptions, lambda expressions, and modules. Designing a mechanism for specifying a template’s requirements on its arguments that is sufficiently flexible and precise yet doesn’t impose run-time costs turned out to be hard. The repeated attempts to design łconceptsž to do that have their roots back in the 1980s and touch upon many key design issues for C++ and for generic programming.
The description is based on personal participation in the key events and design decisions, backed by the thousands of papers and hundreds of meeting minutes in the ISO C++ standards committee’s archives.

Downloadez le document de 168 pages: https://dl.acm.org/doi/pdf/10.1145/3386320

Le développement moderne Desktop Windows 10

Le modèle de développement selon Microsoft est très complexe car il est permissif. En effet, Microsoft n’impose rien, Microsoft propose des technologies au fur et à mesure des années et des nouveaux kits de développement. Mais comment décider ; que choisir pour développer une application ?

Si on suit la BUILD 2020, on parle de MAUI et de WinUI3. Soyons clair, ce n’est pas sérieux. Voici le détail de mon analyse.

Un rappel historique

Dans les années 90, 2000, le modèle était le suivant : Windows C Win32, C++ MFC ou Visual Basic, voir Delphi (Borland). Le modèle de ces années là est la domination du monde fenêtré. Soit SDI (Single Document Interface) soit MDI (Multi Document Interface). Le modèle MDI était populaire avec Word, Excel et consistait à avoir plusieurs fenêtres ouvertes dans la même application. Avec le modèle MDI, le paradigme était la programmation objet et le modèle des User Controls et de OLE2. OLE2 c’est les composants COM, les contrôles ActiveX, le pilotage OLE Automation et les Compound Documents ou documents composites qui consistent par exemple, à mettre un bout d’Excel (des graphiques) dans un document Word. Ce modèle OLE2 n’a jamais été égalé par se sophistication et sa beauté (oui c’est beau). Il faut reconnaitre qu’il y avait une certaine complexité avec toutes ces interfaces COM mais le résultat était magnifique. Les contrôles ActiveX ont eu un certain succès et l’avènement a été Visual Basic 6 avec ses multitudes de contrôles OCX.

L’arrivée de NET en 2001

En 2001, Microsoft présente NET avec Windows Forms. C’est un succès immédiat.

WPF en 2006 dans Vista

En 2006, Microsoft distribue WPF dans Windows Vista. Nom de code Avallon, de grandes ambitions ais l’OS Vista est une catastrophe et le projet est retardé et l’OS ne contiendra rien fait en NET. Tout sera implémenté en C++ cat WinDiv n’est pas content de NET (fiabilité, robustesse, vitesse). Il y a des incompréhensions entre DevDiv (qui produit NET) et WinDiv et le fossé est toujours présent en 2020 !

La mort de Windows Phone et Silverlight

Quand Microsoft sort le Windows Phone, avant 2010, seul le C# et WPF sont autorisés. XAML everywhere. L’adoption en terme d’apps est un fiasco. Le C++ est alors supporté mais le mal est fait. Le Store ne contient aucune apps ou si peu. De plus, WPF et Silverlight ne tiennent pas leurs promesses. C’est lourd, c’est lent, le modèle MVVM est indebuggable. La cata. La division WInDiv reprend les choses en main et coupe la branche. Silverlight est dead. Enfin en LTS mais il n’y auara plus d’évolutions. On sait ce que Microsoft veut dire dans ces cas-là. Quand les réponses ne sont aps données et que l’on en parle plus, on sait ce que cela veut dire.

Windows 8

En parallèle, en 20011, Windows 8 sort son modèle d’applications Metro. Les fans du NET pensent que NET est enfin dans Windows ! Manqué ! C’est des contrôles natifs fait en C++, les fameuses API WinRT faites… en COM. Microsoft ne parle plus de WPF et le modèle c’est WinRT, COM et XAML.

Pire, les applications Store et Accessoires sont faites en JS avec WinJS. Courrier est le parfait exemple. Pour le camp WPF, c’est une trahison. JS est mis en avant à la place de C# et NET et surtout WPF. Le Manager de WPF démissionne après avoir vidé son sac sur reddit et enflammé la toile. Microsoft ne bouge pas et confirme que le retour est au Win32 et à COM et surtout que les erreurs Windows Phone se seront plus commises ! Dans le monde Windows, on ne renie pas la famille Win32 sans impunité. Win32, c’est GDI32, USER32 et KERNEL32, c’est l’héritage de Dave Cutler, le père de Windows NT, Dieu. Les Boss de Windows ont sifflé la fin de la récréation. Les ISV ont indiqué que WPF ne permet pas de faire des applications Desktop comme ils le désirent. Le problème, c’est que de nombreux développeurs ont rejoint le rang de la communauté NET pour faire du XAML et du WPF. Il y a un certain désarroi dans la communauté WPF. Ils se sentent trahi par Microsoft. Il faut dire que Microsoft joue sur les deux tableaux en prônant la modernité et nous ressort du COM et des extensions à IUnknown… Moi à ça me plait car c’est mon monde et je sais que chaque classes C# est un composant COM mais le commun des développeurs NET ne le sait pas.

Windows 10

Depuis WinRT, Microsoft a sorti un framework pour ocntinuer l’avenir OLE2. Oui Monsieur ! WinRT arrive avec un framework nommé WRL (Windows Runtime Language) et surtout C++/CX, un C++ qui supporte WinRT et le XAML. Ce sont des templates C++ qui prennent la suite de ATL/COM. ATL est une suite de templates C++ pour faire du COM et de OLE2. C’est très efficace et toujours utilisé.

NET Core

Microsoft fusionne NET Framework et NET Core 3.1 pur faire NET 5. Il va y avoir un nouveau designer pour WinForms et WPF.

MAUI

La fusion de Xamarin.Forms, Mono avec GTK+ va fournir un environnement multi-plateforme qui va séduire de nombreux nouveaux venus dans le monde Microsoft. A suivre…

WinUI

En 2019, Microsoft annonce un projet open-source XAML Island permettant l’inclusion des contrôles Windows 10 dans les application NET et Win32. Rapidement renommé WinUI, se projet open-source prend de l’importance chez Microsoft et c’est propulsé comme l’avenir de l’UI selon Microsoft à la BUILD 2020. L’application de référence est XAML Control Gallery et présente les contrôles simples et la panoplie de contrôles XAML disponibles dans Microsoft.UI.Xaml.Controls.dll. Ces contrôles natifs sont livrés avec leur code source et disponible sous forme de package Nuget pour C# mais aussi utilisable en WinRT avec CPP/WinRT de Kenny Kerr.

La Question à 1 million de dollars : Que choisir ?

Là c’est ouvert. Les développeurs s’accrochent aux branches. NET Core leur ouvre un second souffle. Mais le grand gagnant est le retour de WinForms pour NET Core. Pourquoi ? Parce que c’est simple, orienté objet et évènementiel et surtout utilisable par tous. IL n’y a pas de modèle foireux comme MVVM. Les évènements arrivent dans des routines et on gère tout dedans. Même en faisant de la délégation à une classe centrale, tout est débuggable. Bref, ce n’est pas WPF et MVVM. Quand une technologie n’est pas simple, elle n’est pas adoptée.

XAML

Je suis très sceptique sur XAML. C’est le cœur de WPF et la mayonnaise n’a jamais prise. Déjà, le XAML est illisible. Le modèle MVVM est complexe est non standardisé. Tout le monde fait le sait. C’est foireux ! WinUI se veut l’avenir mais c’est du XAML. Alors je dis oui mais à une condition. Pas de modèle MVVM. Pas de commandes, pas de routing, pas de messages, pas de binding. On fait du XAML évènementiel comme ne WinForms. Les samples Microsoft me donnent raison, il n’y a pas de MVVM.

Win32 et C/C++ (for ever)

Le cœur de Windows est fait en C et en C++. Le modèle Windows repose toujours (et encore plus maintenant) sur le C++ Moderne (C++17) et la base de code installée en C/C++ est tellement importante que Microsoft ne fera pas la révolution. WinUI passera par l’introduction simple de contrôles XAML dans les applications existantes. Cela fera partie de Windows et du Windows SDK comme CPP/WinRT. Il n’y a que les néophytes qui pensent que Microsoft fera la révolution en NET et en C#. Microsoft fait 95% de ses logiciels en C++. La performance est primordiale. D’ailleurs, le projet Réunion à pour but de délivrer du C++ pour tous les langages via des projections (principes de CPP/WinRT) via les nouvelles API faites en WinRT. Les packages VCLibs et Microsoft.XAML sont la preuve de ce mouvement.  Autre application faites en WinUI, le Windows Terminal. Il incorpore cmd, powershell et bash. Il y a un support WinUI pour les Settings et les onglets (Tabs).

La stratégie floue de Microsoft

Microsoft produit des technologies et des produits. D’un côté, il y a Azure et de l’autre Windows, Office et les produits serveurs. Microsoft veut de nouveaux développeurs sur sa plateforme donc il y a aussi du TS, du Rust/WinRT et du React Native. Microsoft est une grosse machine et il est parfois nécessaire d’avoir le point de vue des vieux gurus pour s’en sortir. Chez Microsoft, il y a des technologies pour les POC et des technologies pour faire des vrais logiciels qui durent mais aussi du jetable.

Conclusion

Ce n’est pas parce que ça existe qu’il faut l’utiliser

Confucius.

Project Réunion

Qu’est ce que Le Projet Réunion nous apporte ?

Projet Réunion nous apporte trois nouvelles fonctionnalités dans lesquelles vos applications pourront piocher:

  1. De nouvelles API
  2. Un sous-ensembles D’API
  3. Des API convergentes

Les nouvelles API (new) : 

De nouvelles fonctionnalités Windows seront fournies dans le projet Réunion, celles-ci seront transparentes dans leurs identités, leurs packagings et leurs isolations. De plus elles partageront une interface commune ce qui vous permettra de l’utiliser peu importe le type de votre application (MSIX, MSI, Setup.exe, Desktop Bridge, AppContainer).

New APIs

Ces API sont autonomes et ont pour but de répondre à des problèmes spécifiques que vos applications peuvent rencontrer, elles vous aideront aussi à mettre en place des fonctionnalités supplémentaires.

Voici une liste potentielle des différents types d’API qui ne seront pas forcément pressent le premier jour :

  • Stockage et gestion des données dans un seul endroit pour garder en ordre le système de l’utilisateur
  • Cloud app support pour la gestion de l’identité ainsi que de la connectivité afin d’utiliser Azure
  • Packaging et système intégration pour que Windows comprenne ce que fait votre application
  • Aide de communication entre différentes applications (app-To-app) pour que vos applications fonctionnent ensemble.
  •  API d’accès aux ressources pour les caméras, les microphones et la localisation qui respectent la vie privée.

Comment utiliser ces nouvelles API ?

Pour utiliser ces API il vous suffit d’ajouter dans un premier temps le package NuGet « Project Reunion » et dans un second temps d’en faire appelle dans votre code. Les API seront disponibles dans toutes les versions de Windows ainsi que pour toutes les applications. Si certaines API se comportent autrement (du a son identité, d’un isolement particulier ou d’un cycle de vie différents) vos applications sont en mesures de le détecter grâce aux contrôles du type « TheType.IsSupported ».

Les API convergentes (converged):

Projet Réunion propose des Api de surface qui permettent de faire la liaisons entre Win32 et les fonctionnalités UWP/AppContainer déjà présentes dans la plate-forme. Les auteurs de comme partagé (Frameworks ou autre) peuvent avoir recours a une seule méthode afin d’éviter leurs propres verifications  » if (AppContainer) { x } else { y } ». Projet Reunion fournit des implémentations « polyfill » des API lorsque c’est nécessaire pour que votre application puisse fonctionner sur d’autres versions de Windows sans vérification supplémentaires.

Converged APIs

Voici quelque exemple d’API convergentes :

  • Window Content Frame abstraction entre WIn32 et UWP
  • Application lifecycle behaviors pour le démarrage, la déconnexion , ‘intégration du gestionnaire de redémarrage, le redémarrage pour la mise à jour
  • Assistance au démarrage et aux tâches de fond pour réduire la puissance et les performances de votre
  • Gestion des ressources d’application pour les chaîne de caractères(strings), les images, les résolution d’affichages et localisation

Une fois que vous avez ajouté les références a Projet Réunion l’application pourras commencer à migrer des blocs de fonctionnalités vers L’utilisation de ces API convergentes  entièrement prises en charge. Vous pouvez donc migrer autant de fonctionnalités que nécessaire, en conservant le style ainsi que le comportement de votre application. Ces API seront similaires a celles du SDK ce qui facilitera la transition. En ce qui concerne les API Win32 « Flat C » existantes, une API convergente sera ajoutée puis envoyer dans votre langage et votre runtime.

Lorsque les applications aurons migré pour Projet Réunion il sera plus facile d’alterner entre déploiement et isolation. En effet Projet Réunion gère l’accès au ressources à partir d’un processus avec un faible niveau d’intégrité (LOWIL) ou AppContainer pour que votre application puisse référencer les ressources tout en respectant le choix de l’utilisateur ainsi que les contrôles de confidentialité.

Converged APIs

Les sous-ensembles d’API (Subset Family):

Les sous-ensembles API vous permettent de commencer a utiliser les fonctionnalités de Project Reunion avec des changements minimaux de votre code déja existant. Cela fonctionne en utilisant un ensemble d’en-têtes et de mises en œuvre mis à jour et rationalisés.

Le Projet Réunion aide a rester dans l’ensemble des API que des Windows peu prendre en charge dans toutes les editions and les points de terminaison (endpoints).

Projet Reunion définit un sous-ensemble d’API prises en charge dans toutes les versions Windows. Si votre code cible ce sous-ensemble et utilise les Project reunion new API avec les Project Converged API il fonctionnera partout où Windows fonctionne sans ajout supplémentaire.

Les fonctionnalités prises en charge par le sous-ensemble de Project Reunion comprennent des sous-ensembles de :

  • Windowing, Input, Messaging, GDI, and GUI subsystem functionality
  • Filesystem and storage access
  • Networking
  • Printing
  • Process, threading, memory management, basic application services
  • DirectX, D3D, DirectML

Comment migrer vers l’ensemble d’API de Projet Reunion Subset ?

Pour migrer votre application il vous suffit de supprimer toute les références aux headers de Windows Kit (windows.h, kernel32.lib, user32.lib, winsock.h, etc) puis ajouter les références au header principal de Projet Reunion Subsete et aux lib d’importation.

Point important, malgres que de nombreuses API font parties du Kit WIndows ainsi que du sous-ensemble de Projet Réunion, il se peut que vous ayer quelques changements a effectuer dans votre code ou dans le comportement de votre application.

Composantes du Projet Réunion (Project Reunion Family Components) ?

Ce qui est disponible dès maintenant

Ces composants sont à votre disposition dès maintenant et respectent la « promesse de la famille du projet Réunion », à savoir qu’ils disposent d’une API unique pour toutes sortes d’applications.

  • WinUI 3 pour XAML vous aide à créer des UX fluides pour toutes sortes d’applications grâce à la puissance de XAML. Ce composant {lien vers repo} fait partie de la famille de fonctionnalités de Project Reunion, s’appuyant sur l’identité + le packaging + les idées transparentes de déploiement que Project Reunion prend également en charge pour votre application.
  • C++/WinRT, RUST/WinRT et C#/WinRT fournissent des projections en langage natif de Windows, de Project Reunion et de vos propres types personnalisés définis dans les métadonnées. Consommez les API du kit Windows, produisez-les pour les utiliser avec d’autres projections prises en charge et créez vos propres nouvelles projections de langage.
  • MSIX-Core vous permet de conditionner votre application pour la distribuer sur les machines Windows Desktop via le magasin ou votre propre pipeline de livraison. MSIX-Core vous permet d’utiliser les parties réutilisées de l’histoire du packaging MSIX sur les anciennes versions de Windows.

Ce qui est bientôt disponible

Bien que nous pensions qu’elles soient intéressantes pour les candidatures, c’est à vous de nous le dire ! Le travail au grand jour consiste en partie à apprendre ensemble les besoins des développeurs d’applications. Vous trouverez ci-dessous un ensemble de fonctionnalités qu’il semble intéressant de mettre à disposition dans le cadre d’un modèle convergent ou nouveau, mais c’est à vous de nous le dire ! Certaines sont liées à un fil de discussion proposant la fonctionnalité. +1 celles que vous aimez, commentez la conception détaillée et la direction, et aidez-nous à déterminer où nous allons.

  • WebView2, qui s’appuie sur Edge/Chromium, vous permet de créer facilement votre application en HTML+JS une fois et de la réutiliser sur toutes les plateformes. L’utilisation par WebView2 de technologies du Projet Réunion comme WinUI3 comme cadre d’hébergement vous permet d’exécuter un UX moderne basé sur le web sur toutes les éditions de Windows.
  • Modern Lifecycle helpers permettent à votre application d’être sensible à la consommation d’énergie et de réagir aux changements dans la gestion de l’énergie du système d’exécution et dans l’état de l’utilisateur. Elles aident également votre application à redémarrer après le redémarrage de l’utilisateur, enregistrent votre application pour qu’elle puisse être redémarrée et réduisent les redémarrages liés aux mises à jour.
  • Startup tasks donnent vie à votre application lorsque l’utilisateur se connecte pour se reconnecter, commencer à travailler sans surutiliser les ressources ou être prêt à une utilisation rapide. Les fonctions de choix de l’utilisateur et de gestion de l’énergie vous permettent de réduire votre impact sur le chemin critique de la connexion.
  • Update Scan Integration permet de maintenir votre application à jour automatiquement pendant son exécution, en même temps que d’autres tâches de maintenance du système.
  • Accès aux ressources utilisateur même à partir d’AppContainer et d’applications isolées. Vos applications AppContainer peuvent accéder à de puissantes technologies Win32 comme le presse-papiers, la communication entre processus et l’espace de nommage Windows Shell avec le consentement de l’utilisateur par le biais d’un courtage.
  • Modern Resource Tooling pour que vous puissiez utiliser la puissance de ResX/ResW dans vos applications Win32 au lieu de MUI.

Orientation future

Nous avons pour objectif de développer le Projet Réunion afin de fournir une version moderne, simple et accessible d’une grande partie de la puissance de la plate-forme d’application Windows. Le fait de travailler au grand jour avec notre communauté de développement garantit que nous faisons d’abord les bonnes choses pour résoudre les problèmes auxquels vos applications sont confrontées sur les versions actuelles et futures de Windows.

Certaines fonctionnalités seront d’abord livrées en tant que composants du projet Reunion. Lorsque nous pensons à faire évoluer la plate-forme, il est important de s’assurer que les nouvelles fonctionnalités et caractéristiques sont disponibles pour notre communauté de développeurs dès qu’elles sont prêtes à être utilisées. Les nouvelles fonctionnalités de la plate-forme vous aideront à les adopter dès qu’elles seront disponibles, sans que vous ayez à les cibler ou à les réécrire.

À mesure que votre application utilisera davantage de fonctionnalités de Project Reunion, elle sera prête pour des cibles supplémentaires telles que le packaging, l’identité, l’AppContainer et d’autres futures éditions Windows. Dépendre des API de Project Reunion signifie que nous prenons en charge le travail pour que ces API continuent à fonctionner au fur et à mesure de l’évolution de Windows. En restant dans la surface de l’API du Projet Réunion, vous vous assurez que votre application peut répondre à la plus large gamme d’éditions et de versions de Windows tout en utilisant des fonctionnalités à jour.

Comment nous procédons

Travailler au grand jour

Le Projet Réunion s’appuie sur la puissance de l’open-source et les fonctionnalités de GitHub pour vous livrer du code aussi vite que nous pouvons l’imaginer. Vous devez vous sentir libre de bifurquer, de créer des demandes de retrait, d’ouvrir des problèmes, de proposer des résolutions aux problèmes. Vous pouvez voir et influencer toutes nos fonctionnalités via le « issue tracker ». Vous devez vous attendre à ce que nous vous écoutions et que nous vous fournissions un retour d’information constructif.

Constructions et artifacts

Le code dans le cadre du projet Réunion GitHub repo s’appuie sur une boucle CI/CD et produit des DLL et des métadonnées fraîchement construites sur chaque demande de retrait. Le résultat comprend un paquet NuGet contenant les métadonnées pour le projet Reunion et un MSIX prêt à être livré pour être inclus dans votre demande comme redistribuable ou comme référence de paquet. Ajoutez une référence au paquet de Project Reunion et commencez à construire. Pour vous aider à déployer vos applications, nous inclurons un MSIX Framework Package ainsi que des instructions sur la façon de déployer ce MSIX à partir de votre installateur existant.

Versionnement
Le projet Reunion utilisera des définitions d’API basées sur des métadonnées fortement typées sur lesquelles vos applications peuvent prendre une dépendance à long terme suivant le cycle de vie de notre support publié. Nous utiliserons SemVer 2 pour identifier clairement les niveaux de forme des API qui permettent à ces API d’évoluer vers de nouvelles fonctionnalités sans compromettre les applications existantes. Project Reunion aide à maintenir les applications à jour grâce à des Framework Packages qui sont mis à jour avec des changements non cassants le cas échéant.

Extension des API
Une partie de ce que le Projet Réunion fournit est l’accès à des fonctionnalités qui se trouvent dans Windows, mais pour lesquelles il n’y a pas d’API publique. Nous travaillons sur les détails, mais notre plan est de fournir un paquet secondaire de code qui fournit une API publique sur ces composants précédemment non exposés. Ces composants seront mis en œuvre en tant que source fermée, mais ils seront accompagnés d’une surface d’API basée sur les métadonnées, pouvant être appelée et prise en charge par le public, et seront inclus dans les paquets du cadre du projet Reunion pour être utilisés par les applications.

Courtage
Les processus UWP (AppContainer, Low-IL) sont destinés à protéger à la fois l’utilisateur et l’application elle-même contre d’autres applications. L’accès aux ressources de l’utilisateur et du système est limité à l’ensemble des courtiers pris en charge pour ces ressources. Le projet Reunion comprend également un paquet principal qui fonctionne au niveau d’intégrité de l’utilisateur (moyen-IL, parfois appelé « full trust ») et peut fournir un accès approuvé par l’utilisateur à des ressources auparavant non disponibles pour les processus AppContainer et Low-IL.
Ce modèle est aujourd’hui disponible pour les applications AppContainer en tant que « composant de confiance totale » – le projet Reunion vise à fournir un modèle et une plate-forme communs pour ces composants personnalisés.

Ce que le Project Reunion n’est pas

Le Projet Réunion n’est pas un nouveau modèle d’application ou une nouvelle plate-forme de Windows. Il n’y aura pas de « nouvelle application Project Reunion » pour Visual Studio, VSCode ou d’autres environnements de développement.
Vous aurez toujours un accès complet au SDK Windows et aux kits associés. Au fil du temps, les fonctionnalités offertes par Project Reunion iront au-delà de la simple fusion des modèles Win32 et UWP existants et fourniront des fonctionnalités supplémentaires à toutes les applications à utiliser.

Project Reunion n’est pas un nouveau modèle d’empaquetage ou d’isolation des applications. Il n’est pas nécessaire de modifier votre application pour accéder à la fonctionnalité de Project Reunion, si ce n’est en utilisant la nouvelle fonctionnalité elle-même. Si les API que vous utilisez ont besoin d’une identité ou d’un packaging, ces exigences seront indiquées.

Le Projet Réunion n’est pas un nouveau modèle de sécurité ou de confidentialité pour les applications. Les histoires de sécurité, de confidentialité, de fiabilité et d’identité de votre application continuent de fonctionner avec Project Reunion. Il y a peut-être des endroits où le Projet Réunion aide votre application à être plus consciente des préoccupations des clients en matière de sécurité ou de confidentialité. Le Projet Réunion vous aide à utiliser des fonctionnalités modernes de sécurité et de confidentialité qui évoluent en fonction des besoins de votre application.

Le Projet Réunion n’est pas un moyen d’exécuter votre application dans le cloud. L’utilisation de la technologie de Project Reunion vous permettra d’intégrer votre application dans des familles d’API modernes qui sont prêtes pour le cloud. Des composants clés comme le cycle de vie moderne et l’isolation des états permettent de préparer votre application à fonctionner où que soient vos clients.

Project Réunion – Overview

Qu’est-ce que Le Projet Réunion ?
Project Reunion est la vision Microsoft pour unifier et faire évoluer la plate-forme de développeur Windows pour faciliter la génération d’applications formidables qui fonctionnent sur toutes les versions et appareils Windows 10 que les gens utilisent.

Project Reunion facilite la construction d’une grande application Windows en fournissant une plate-forme unifiée pour les applications Win32 et les applications UWP nouvelles et existantes. Il unifiera l’accès aux API Win32 et UWP existantes et les rendra disponibles découplés à partir du système d’exploitation, via des outils comme NuGet.

Project Reunion vous aidera à mettre à jour et à moderniser vos applications existantes avec les dernières fonctionnalités, qu’elles soient C++, .NET (y compris WPF, Windows Forms et UWP) ou React Native. Au fur et à mesure que Microsoft découple les API existantes et ajoute de nouvelles API, un travail pour polyfiller est réalisé, au besoin, de sorte que les API fonctionnent à un niveau bas entre les versions prises en charge de Windows.

Comment utiliser ?
WinUI 3 Preview 1 est l’un des premiers composants du voyage Project Reunion : c’est le cadre d’interface utilisateur natif moderne pour Windows, maintenant disponible pour tous les développeurs d’applications Windows dans les applications UWP et Bureau. À l’aide de WinUI, vous pourrez créer de nouvelles applications avec interface utilisateur moderne qui s’adapte et scalent à tous les appareils, ou moderniserez progressivement l’interface utilisateur des applications de bureau existantes, y compris C++, WPF et WinForms.

 

WinUI 3 – L’avenir du développement UI pour les devices Windows 10

La conférence BUILD nous annonce WinUI 3 : c’est l’avenir du développement UI sous les devices Windows 10.

Depuis l’apparition de Windows 10, de nouveaux contrôles graphiques sont apparus au sein du système d’exploitation. Les applications Accessoires comme la calculatrice, courrier, paint 3D ou le panneau de configuration ont un nouveau look, plus épuré, plus « Fluent ».

Les nouveaux contrôles graphiques sont implémentés en C++ et mis à disposition dans System32 via la librairie dynamique Microsoft.UI.Xaml.dll. Vous allez me dire Xaml ? Mais je connais, c’est WPF ? Et bien oui mais non… La Division qui fait Windows n’est pas très fan de WPF et de NET en général donc il n’y en a pas dans Windows. Par contre, il existe une implémentation Xaml en C++ ! Et la syntaxe/technologie Xaml est commune entre Windows et WPF.

Avec WinUI, il est possible de mettre des contrôles XAML Windows 10 et ce même pour les premières versions de Windows 10 dans des applications Win32, WinForms ou WPF.

Introduction au monde Fluent

Voici le look Fluent Design. Cela vous rappelle le panneau de configuration Windows 10 ?

C’est du XAML. L’écran est entièrement configuré en XML de type XAML.

Introduction aux contrôles natif C++

Le module se nomme Microsoft.UI.Xaml.dll et il contient tous les contrôles Xaml Windows 10. Il utilise les API WinRT du mode UWP.

Rappel des repo github utiles:

La Direction Technique et les Experts Infeeny vous préparent une série de contenus sur WinUI. A suivre.

 

 

7 astuces pour améliorer le télétravail et juguler la profusion de contenu dans Teams

Vous retrouverez dans cet article, l’ensemble des Questions/Réponses du webinar Infeeny x Avepoint du 12 mai 2020.

1 – A partir de Teams Corporate peut-on interagir avec un contact hors entreprises (consumer) ?

Il est tout à fait possible d’interagir avec un contact externe sur le Teams de votre entreprise. Pour cela, votre administrateur Office 365 doit :

  1. Autoriser l’accès aux personnes externes sur Microsoft Teams, ces derniers se verront donc attribuer le statut « d’invités ».
  2. Avoir activé les fonctionnalités de conversations et de réunions sur Teams. Une fois ces 2 conditions remplies, vous pourrez interagir avec les personnes externes (créer une nouvelle conversation, les inviter dans une équipe et collaborer avec elles, etc …). Il faut bien-sûr que le contact externe ait déjà un compte Microsoft afin de pouvoir aller sur Teams.

 

2 – En mode vidéo calls, on est limité à 20 personnes. Cependant, nous ne voyons que 4 intervenants. Est-il possible de modifier cela ?

Avec la recrudescence des logiciels de visioconférence depuis le Covid-19, Microsoft a décidé d’améliorer cet élément. Vous pourrez bientôt (à partir de mai) afficher 9 flux vidéo à la fois.

 

3 – Comment faciliter le travail entre différents environnements ? Je veux dire dans Teams de différentes sociétés ?

Vous pouvez facilement interagir avec un contact externe à votre entreprise via Teams. Pour cela, votre administrateur Office 365 doit autoriser l’accès aux personnes externes sur Teams, ces derniers se verront donc attribuer le statut « d’invités ». Il faut que l’une des deux sociétés invite les membres de la deuxième dans une équipe et vous pourrez ensuite interagir et collaborer ensemble.

 

4 – Pour vos Webinar, pourquoi utiliser GotoWebinar au lieu de Teams ?

Nous utilisons GoToWebinar plutôt que Microsoft Teams selon les directives de Microsoft, de utiliser les plateformes d’hébergement tierces pour les événements virtuels.

 

5 – Où trouver des ressources (templates) d’organisations / d’équipes déjà fait ? Genre un coworking space, ou une école, ou un bureau d’avocats ?

Vous trouverez plus d’informations sur les modèles de Teams de base (Ex: Standard (default), Éducation (3), Commerce de détails (2) et Santé (2)). Cependant, il est important de noter que ces modèles demandent des configurations globales pour être disponibles dans votre environnement.

 

6 – Dans la roadmap de MS, il est prévu d’interagir les conversations Skype avec Teams avant la fin avril, avez-vous des infos ?

L’interopérabilité entre Skype et Teams est déjà disponible, voici quelques articles techniques qui pourront vous aiguiller sur ce sujet et qui nous l’espérons vous donnera les éléments de réponses que vous recherchez:

https://docs.microsoft.com/fr-fr/microsoftteams/teams-and-skypeforbusiness-coexistence-and-interoperability

https://docs.microsoft.com/fr-fr/microsoftteams/teams-skype-interop

 

7 – Est-ce que Teams fonctionne avec web Outlook ? Merci

Vous pouvez créer une réunion et insérer un lien de conférence Teams à partir du web app Outlook, à condition d’avoir Office 365. Pour cela, il vous suffit créer un « Nouvel événement » et au lieu d’insérer une salle de réunion, choisissez l’option « Réaliser une réunion en ligne » puis « Teams ». Une fois que votre invitation est prête, vous n’avez plus qu’à l’envoyer !

 

8 – Peut-on empêcher l’utilisation des Apps dans Teams ?

Oui… De plusieurs façons, cet élément est contrôlé par l’administrateur de votre environnement Teams.

Vous pouvez bloquer l’utilisation des Apps :

– Premièrement, par la nature de l’App (Microsoft, Tierce-partie ou par App tenant).

– Deuxièmement, par App individuelle et, finalement, par utilisateurs/employés de votre environnement.

 

9 – Comment créer des équipes (Teams) ?

Si activé par votre société, à même l’interface Teams, vous serez en mesure de créer une nouvelle équipe Teams (voir démo). Si cette option n’est pas activée, il se peut que votre société utilise une autre approche via, par exemple, la soumission d’une demande précise par mail ou encore via une application tierce tel que ou similaire à AvePoint MyHub.

 

10 – Pour une réunion de 50 minutes, il faut planifier 50 minutes ou 1 heure ?

Effectivement, tout comme Outlook le permet, Teams permet de planifier des durées de réunions en dehors du standard 30 ou 60 minutes comme, par exemple 50 minutes :

Réunion Teams Infeeny

 

11 – Comment fonctionne la traduction ? Je ne la retrouve pas dans mon environnement.

Le responsable de votre environnement Teams doit dans un 1er temps l’activer via PowerShell ou via le Centre d’Administration de Microsoft Teams.

Si votre administrateur opte pour la seconde option, il devra aller dans les « Stratégies de messagerie » et créer ou modifier une stratégie, puis activer l’option « Messaging Policies » (on/off) > « Activé par défaut ».

Cette fonctionnalité n’est pas disponible pour les communités gouvernementales et en Allemagne.

Pour information, la fonctionnalité utilise le « Translator Text API » basé sur le moteur de traduction machine Microsoft.

 

Abonnez-vous à notre page LinkedIn et retrouvez toutes nos actualités autour de l’univers Modern Workplace. 

 

 

 

L&L Kubernetes et AKS

Retrouvez notre Expert Christophe, dans une vidéo sur Kubernetes et AKS. La vidéo est Level 100, accessible à tous. URL sur Youtube: ici

Contenu: Il s’agit de prendre un projet Web API sous Visual Studio 2019 avec support Docker (container Linux) et de construire l’image Docker en local. Ensuite on pousse cette image dans une registry ACR afin de faire un déploiement dans un cluster AKS. Ensuite, on aborde kubectl, l’outil console de Kubernetes.

Pour réaliser toutes les opérations techniques, un HOWTO est à télécharger sur https://infeeny.com/net-core-sous-aks/

Développement Web ASP .NET Core

Bonjour, dans cet article, nous allons vous présenter la solution eShopWeb, voici comment va se décomposer l’article :

    • Architecture monolithique
    • Design Pattern MVC
    • Entity Framework Core
    •  eShopWeb
      • Introduction
      • Explication de la fonctionnalité Add to Basket
      • Explication de la fonctionnalité Checkout

Architecture monolithique

Le terme monolithique est plutôt utilisé lorsque l’on parle de conception d’application (ou architecture) et représente le modèle dit « traditionnel » d’une application. On peut considérer ce genre d’architecture comme un bloc unifié (contrairement aux micro-services).

Néanmoins, on peut mettre différentes couches de données (par exemple du MVC, mais nous reviendrons sur l’explication de se terme plus loin dans cet article). Ce qui signifie que les différents composants sont intrinsèquement connectés les uns aux autres et sont la plupart du temps dépendant de chacune des couches existantes.

L’inconvénient principal est lors de la mise à jour d’un élément, il faut alors réécrire une bonne partie de l’application (si ce n’est son entièreté). Par opposition, l’architecture monolithique permet un meilleur rendement que l’architecture micro-services. Mais surtout l’aspect monolithique permet de facilité les tests et le débogage car il y a moins d’éléments à prendre en compte.

Patron de conception : Modèle – Vue – Contrôleur (MVC)

Ce qu’on appelle en français un patron de conception est appelé en anglais design pattern. Et celui du MVC permet de séparer la logique du code :

  • Modèle : Un modèle permet de gérer les données du site. Il va donc chercher les informations dans la base de données, les organiser et les assembler pour ensuite être traité par le Contrôleur.
  • Vue : Une vue va comme son nom l’indique s’occuper de l’affichage. Il n’y a quasiment aucun calcul dans cette partie car son seul but est de récupérer des variables pour savoir ce qui va être affiché.
  • Contrôleur : Un contrôleur va gérer la logique du code. Il sert d’intermédiaire entre le modèle et la vue. Globalement, il va demander au modèle les données et les analyser puis il renvoie le texte qu’il faut afficher à la vue.

On peut, en complément du Contrôleur, avoir une couche que l’on va nommer communément Service, qui va se charger de la récupération de données pour une API par exemple.

Entity Framework Core

Entity Framework Core est un ORM créé par Microsoft, il vous permet d’effectuer des opérations CRUD sans avoir besoin d’écrire des requêtes SQL.

Pour reprendre à la base : qu’est-ce qu’un ORM ?

ORM signifie Object Relational Mapping ou Mapping Objet Relationnel en français. C’est une couche supplémentaire à notre application.

Mais qu’est-ce que ça signifie concrètement : que ça se place entre un programme applicatif et une base de données relationnelle afin de simuler une base de données orientée objet. On va donc associer une classe et une table et pour chacun des attributs de la classe qui vont correspondre à un champ de la table associée.

Avantages

  • Réduction de la quantité de code est réduite et que l’on gagne en homogénéité avec le reste du code (pour les langages orientés objets).
  • On va pouvoir travailler directement avec des objets complexes.
  • Plus besoin d’écrire nos requêtes SQL.
  • Moins de travail pour les développeurs

Inconvénients

L’utilisation d’ORM, induit une couche logicielle supplémentaire ce qui forcément nuit aux performances de l’application et rend particulièrement délicate la maintenance de l’application. Ainsi que la durée de vie de l’application.

Modeling

Entity Framework Core va via une commande « mapper » des classes complexes. Il va donc faire une requête à la base de données et remplir les données de nos classes associé au même table.

Les classes à remplir s’appellent des Modèles. Voici un exemple dans la solution eShopWeb :

namespace Microsoft.eShopWeb.Web.ViewModels
{
  public class CatalogItemViewModel
  {
     public int Id { get; set; }
     public string Name { get; set; }
     public string PictureUri { get; set; }
     public decimal Price { get; set; }
  }
}

Comme vous pouvez le voir, ce Modèle correspond aux informations relatives à un objet présent dans le catalogue.

Maintenant, voici l’objet Catalog qui contient tout les items et d’autres informations :

using Microsoft.AspNetCore.Mvc.Rendering; using System.Collections.Generic; namespace Microsoft.eShopWeb.Web.ViewModels {   
  public class CatalogIndexViewModel   
  {     
    public IEnumerable<CatalogItemViewModel> CatalogItems { get; set; } public IEnumerable<SelectListItem> Brands { get; set; }     
    public IEnumerable<SelectListItem> Types { get; set; }     
    public int? BrandFilterApplied { get; set; }     
    public int? TypesFilterApplied { get; set; }     
    public PaginationInfoViewModel PaginationInfo { get; set; }  
 
  } 
}

Pour pouvoir le remplir (binding), nous allons donc maintenant voir un nouvel exemple :

using Microsoft.eShopWeb.ApplicationCore.Entities;
using System.Collections.Generic;
using System.Threading.Tasks; namespace Microsoft.eShopWeb.ApplicationCore.Interfaces {   
  public interface IAsyncRepository<T> where T : BaseEntity, IAggregateRoot   
  {     
    Task<T> GetByIdAsync(int id);     
    Task<IReadOnlyList<T>> ListAllAsync();     
    Task<IReadOnlyList<T>> ListAsync(ISpecification<T> spec);     
    Task<T> AddAsync(T entity);
    Task UpdateAsync(T entity);     
    Task DeleteAsync(T entity);     Task<int> CountAsync(ISpecification<T> spec);   
  } }

Ci-dessus, c’est là où nous faisons appel à EntityFrameworkCore.

Et dans le Service : CatalogViewModelService.cs

public async Task<CatalogIndexViewModel> GetCatalogItems(int pageIndex, int itemsPage, int? brandId, int? typeId) {   
  _logger.LogInformation("GetCatalogItems called.");   
  var filterSpecification = new CatalogFilterSpecification(brandId, typeId);
  var filterPaginatedSpecification =   new CatalogFilterPaginatedSpecification(itemsPage * pageIndex, itemsPage, brandId, typeId);   // the implementation below using ForEach and Count. We need a List.   
  var itemsOnPage = await _itemRepository.ListAsync(filterPaginatedSpecification);   var totalItems = await _itemRepository.CountAsync(filterSpecification);   var vm = new CatalogIndexViewModel()   
{     
  CatalogItems = itemsOnPage.Select(i => new CatalogItemViewModel()     
  {        
    Id = i.Id,        
    Name = i.Name,       
    PictureUri = _uriComposer.ComposePicUri(i.PictureUri),        
    Price = i.Price     
  }),     
  
  Brands = await GetBrands(),     
  Types = await GetTypes(),     
  BrandFilterApplied = brandId ?? 0,     
  TypesFilterApplied = typeId ?? 0,     
  PaginationInfo = new PaginationInfoViewModel()    
  {       
    ActualPage = pageIndex,       
    ItemsPerPage = itemsOnPage.Count,       
    TotalItems = totalItems,       
    TotalPages = int.Parse(Math.Ceiling(((decimal)totalItems / itemsPage)).ToString())     
  }   
};   
  vm.PaginationInfo.Next = (vm.PaginationInfo.ActualPage == vm.PaginationInfo.TotalPages - 1) ? "is-disabled" : "";   
  vm.PaginationInfo.Previous = (vm.PaginationInfo.ActualPage == 0) ? "is-disabled" : "";   
  return vm; }

 

Providers

Un provider n’est ni plus ni moins qu’une librairie utilisable. Dans notre cas, celle qui nous intéresse particulièrement et dont on va parler est la librairie InMemory qui est un Fournisseur en Mémoire.

InMemory Provider

Ce fournisseur est utile lorsque l’on souhaite tester des composants en utilisant quelque chose qui se rapproche de la connexion à la base de données réelle, sans les frais des opérations de la base de données réelle.

L’avantage de ce fournisseur en mémoire et que l’on peut tester notre code par rapport à une base de données en mémoire au lieu de devoir en installer une et de la configurer.

Solution eShopWeb

Nous allons maintenant voir plus en détail cette solution et nous allons nous pencher sur les deux fonctionnalités majeures :

  • Add to Basket
  • Checkout

Add to Basket

Le « Add to Basket » comme son nom l’indique, vous permet d’ajouter un article dans votre panier.

eshopweb.PNG

Accueil du site

Voilà à quoi ressemble le site eShopWeb. Une fois que vous cliquez sur Add to Basket, vous êtes directement redirigé vers votre panier.  via l’URL : https://localhost:44315/Basket

Capturebasket.PNG

Que se passe-t-il au niveau du code ?

L’image représentant l’accueil du site est dans le code, lié au fichier _product.cshtml qui lorsqu’un utilisateur clique sur ADD TO BASKET il sera redirigé ver l’URL suivante : http://localhost:port/Basket

Cette URL correspond au fichier Index.cshtml qui est couplé au fichier Index.cshtml.cs et c’est ce fichier cshtml.cs qui va posséder la « logique » de la page avec une méthode OnPost.

public async Task<IActionResult> OnPost(CatalogItemViewModel productDetails) {   
    if (productDetails?.Id == null)   
    {     
        return RedirectToPage("/Index");   
    }   

    await SetBasketModelAsync(); //Vérifie si l'on est connecté.   
    await _basketService.AddItemToBasket(BasketModel.Id, productDetails.Id, productDetails.Price); //Ajout de l'objet au panier.   
    await SetBasketModelAsync();  
    return RedirectToPage(); }

Dans cette méthode OnPost, on peut voir :

  • Une condition if, afin de vérifier si l’ID du produit n’existe pas
    • Si cette condition se vérifie, l’utilisateur sera redirigé vers l’URL http://localhost:port/Index
    • Sinon, on vérifie d’abord que l’utilisateur est connecté grâce à SetBasketModelAsync()
  • Ce SetBasketModelAsync() va quant à lui, vérifier si l’utilisateur est connecté et s’il a déjà un panier de fait sinon l’utilisateur n’est pas encore connecté mais possède un panier avec les éléments qu’il aura ajouté dedans.
  • Suite à cela, on va ajouter le produit dans le panier en prenant en compte, l’id du panier, l’id du produit ainsi que le prix de celui-ci en passant par la classe BasketService :
public async Task AddItemToBasket(int basketId, int catalogItemId, decimal price, int quantity = 1) //Cette méthode ajoute le produit en premier. {   
    var basket = await _basketRepository.GetByIdAsync(basketId); //Vérifie à quel panier il doit l'ajouter.   
    basket.AddItem(catalogItemId, price, quantity); //Appel de la méthode dans Basket.cs   
    await _basketRepository.UpdateAsync(basket); }

Pour rappel, la variable _basketRepository basé sur la classe BasketRepository correpond à notre Entity Framework Core.

    • Ce même Service (BasketService) va tout d’abord Get le panier via l’id passé en paramètre (le nom du paramètre : basketId) et le stocker dans la variable basket (qui correspondra à une variable initialisée avec la classe Basket)
    • Puis on va ajouter un produit via la méthode AddItem que nous allons voir par la suite et qui prend en paramètres l’id du catalogue, le prix du produit et la quantité (par défaut initialisée à 1).
    • La dernière ligne va nous permettre de charger notre panier dans la base de donnée.
public void AddItem(int catalogItemId, decimal unitPrice, int quantity = 1) //méthode d'ajout 
{
  if (!Items.Any(i => i.CatalogItemId == catalogItemId))
    {
       _items.Add(new BasketItem(catalogItemId, quantity, unitPrice));
       return;
    }
  var existingItem = Items.FirstOrDefault(i => i.CatalogItemId == catalogItemId);
  existingItem.AddQuantity(quantity);
}
  •  le If va nous permettre de savoir si le produit se trouve déjà dans notre liste de produit.
  • Si non, nous entrons dans le If et nous l’ajoutons.
  • Si oui, nous allons simplement mettre à jour la quantité de ce produit.

 

Passons maintenant à la partie Paiement (Checkout)

Il existe deux cas pour cette partie :

  • Soit vous êtes connecté
    • Le bouton CHECKOUT dans le fichier Index.cshtml va vous emmener sur le fichier Checkout.cshtml.
      • Ce fichier est lié au fichier Checkout.cshtml.cs qui va s’occuper de toute la logique.
      • La méthode dans Checkout.cshtml.cs qui nous intéresse est la méthode OnPost :
public async Task<IActionResult> OnPost(Dictionary<string, int> items) {   
    await SetBasketModelAsync();   
    await _basketService.SetQuantities(BasketModel.Id, items);   
    await _orderService.CreateOrderAsync(BasketModel.Id, new Address("123 Main St.", "Kent", "OH", "United States", "44240"));   
    await _basketService.DeleteBasketAsync(BasketModel.Id);   
    return RedirectToPage(); 
}
        • La méthode SetBasketModelAsync() comme précédemment va vérifier si vous êtes connectés ou non en tant qu’utilisateur
        • Le _basketService.SetQuantities() va set le nombre d’articles présent dans notre panier
        • Le _orderService.CreateOrderAsync() fait appel au service OrderService et permet l’ajout de notre commande (on va le détailler comment cela fonctionne un peu plus tard).
        • Le _basketService.DeleteBasketAsync() va détruire le panier dans la base de donnée.
    • Pour revenir au _orderService.CreateOrderAsync() :
public async Task CreateOrderAsync(int basketId, Address shippingAddress) { var basket = await _basketRepository.GetByIdAsync(basketId);   Guard.Against.NullBasket(basketId, basket);
var items = new List<OrderItem>();
foreach (var item in basket.Items)
{
var catalogItem = await _itemRepository.GetByIdAsync(item.CatalogItemId);     var itemOrdered = new CatalogItemOrdered(catalogItem.Id, catalogItem.Name, _uriComposer.ComposePicUri(catalogItem.PictureUri));
var orderItem = new OrderItem(itemOrdered, item.UnitPrice, item.Quantity);     items.Add(orderItem); }
var order = new Order(basket.BuyerId, shippingAddress, items);
await _orderRepository.AddAsync(order);
}

Que fait cette méthode ?

  • On get d’abord le panier
  • Ensuite on regarde si le panier est null
  • Nous créons une liste d’item à commander
  • Dans la boucle nous allons remplir cette liste en récupérant les éléments se trouvant dans notre panier
  • Nous allons créer un nouvel objet Order
  • Et l’ajouter dans la base de donner (appel de OrderRepository.AddAsync())

MVC : Comment les interactions sont faites

order.PNG

Mes commandes – Images

 

Cette page est la représentation graphique de la View (vue) : MyOrders.cshtml

@model IEnumerable<OrderViewModel>
@{
ViewData["Title"] = "My Order History";
}

<div class="esh-orders">
<div class="container">
<h1>@ViewData["Title"]</h1>
<article class="esh-orders-titles row">
<section class="esh-orders-title col-xs-2">Order number</section>
<section class="esh-orders-title col-xs-4">Date</section>
<section class="esh-orders-title col-xs-2">Total</section>
<section class="esh-orders-title col-xs-2">Status</section>
<section class="esh-orders-title col-xs-2"></section>
</article>
@if (Model != null && Model.Any())
{
@foreach (var item in Model)
{
<article class="esh-orders-items row">
<section class="esh-orders-item col-xs-2">@Html.DisplayFor(modelItem => item.OrderNumber)</section>
<section class="esh-orders-item col-xs-4">@Html.DisplayFor(modelItem => item.OrderDate)</section>
<section class="esh-orders-item col-xs-2">$ @Html.DisplayFor(modelItem => item.Total)</section>
<section class="esh-orders-item col-xs-2">@Html.DisplayFor(modelItem => item.Status)</section>
<section class="esh-orders-item col-xs-1">
<a class="esh-orders-link" asp-controller="Order" asp-action="Detail" asp-route-orderId="@item.OrderNumber">Detail</a>
</section>
<section class="esh-orders-item col-xs-1">
@if (item.Status.ToLower() == "submitted")
{
<a class="esh-orders-link" asp-controller="Order" asp-action="cancel" asp-route-orderId="@item.OrderNumber">Cancel</a>
}
</section>
</article>
}
}
</div>
</div>

Cette View est directement lié au Contrôleur : OrderController, plus particulièrement à la méthode MyOrders :

[HttpGet()]
public async Task<IActionResult> MyOrders()
{
var viewModel = await _mediator.Send(new GetMyOrders(User.Identity.Name));

return View(viewModel);
}

Comme nous pouvons le voir ici, la première ligne correspond au contrôle de données (ici, nous récupérons la liste des commandes dans la base de données). Puis nous retournons la vue de notre Contrôleur (l’image Mes commandes – Images ci-dessus).

Si nous cliquons sur un des boutons DETAIL, nous aurons accès au détail du produit sélectionné (la sélection se fait par l’id du produit) :

<section class="esh-orders-item col-xs-1">
<a class="esh-orders-link" asp-controller="Order" asp-action="Detail" asp-route-orderId="@item.OrderNumber">Detail</a>
</section>

L’appel à Detail dans le fichier order.cshtmlIci, on va appeler la méthode de l’OrderController s’appelant Detail.

[HttpGet("{orderId}")]
public async Task<IActionResult> Detail(int orderId)
{
var viewModel = await _mediator.Send(new GetOrderDetails(User.Identity.Name, orderId));

if (viewModel == null)
{
return BadRequest("No such order found for this user.");
}

return View(viewModel);
}

On peut observer que dans le Contrôleur, nous récupérons le détail de la commande. Et nous retournons la bonne vue associée :

@model OrderViewModel
@{
ViewData["Title"] = "My Order History";
}
@{
ViewData["Title"] = "Order Detail";
}

<div class="esh-orders-detail">
<div class="container">
<section class="esh-orders-detail-section">
<article class="esh-orders-detail-titles row">
<section class="esh-orders-detail-title col-xs-3">Order number</section>
<section class="esh-orders-detail-title col-xs-3">Date</section>
<section class="esh-orders-detail-title col-xs-2">Total</section>
<section class="esh-orders-detail-title col-xs-3">Status</section>
</article>

<article class="esh-orders-detail-items row">
<section class="esh-orders-detail-item col-xs-3">@Model.OrderNumber</section>
<section class="esh-orders-detail-item col-xs-3">@Model.OrderDate</section>
<section class="esh-orders-detail-item col-xs-2">$@Model.Total.ToString("N2")</section>
<section class="esh-orders-detail-item col-xs-3">@Model.Status</section>
</article>
</section>

<section class="esh-orders-detail-section">
<article class="esh-orders-detail-titles row">
<section class="esh-orders-detail-title col-xs-12">Shipping Address</section>
</article>

<article class="esh-orders-detail-items row">
<section class="esh-orders-detail-item col-xs-12">@Model.ShippingAddress.Street</section>
</article>

<article class="esh-orders-detail-items row">
<section class="esh-orders-detail-item col-xs-12">@Model.ShippingAddress.City</section>
</article>

<article class="esh-orders-detail-items row">
<section class="esh-orders-detail-item col-xs-12">@Model.ShippingAddress.Country</section>
</article>
</section>

<section class="esh-orders-detail-section">
<article class="esh-orders-detail-titles row">
<section class="esh-orders-detail-title col-xs-12">ORDER DETAILS</section>
</article>

@for (int i = 0; i < Model.OrderItems.Count; i++)
{
var item = Model.OrderItems[i];
<article class="esh-orders-detail-items esh-orders-detail-items--border row">
<section class="esh-orders-detail-item col-md-4 hidden-md-down">
<img class="esh-orders-detail-image" src="@item.PictureUrl">
</section>
<section class="esh-orders-detail-item esh-orders-detail-item--middle col-xs-3">@item.ProductName</section>
<section class="esh-orders-detail-item esh-orders-detail-item--middle col-xs-1">$ @item.UnitPrice.ToString("N2")</section>
<section class="esh-orders-detail-item esh-orders-detail-item--middle col-xs-1">@item.Units</section>
<section class="esh-orders-detail-item esh-orders-detail-item--middle col-xs-2">$ @Math.Round(item.Units * item.UnitPrice, 2).ToString("N2")</section>
</article>
}
</section>

<section class="esh-orders-detail-section esh-orders-detail-section--right">
<article class="esh-orders-detail-titles esh-basket-titles--clean row">
<section class="esh-orders-detail-title col-xs-9"></section>
<section class="esh-orders-detail-title col-xs-2">TOTAL</section>
</article>

<article class="esh-orders-detail-items row">
<section class="esh-orders-detail-item col-xs-9"></section>
<section class="esh-orders-detail-item esh-orders-detail-item--mark col-xs-2">$ @Model.Total.ToString("N2")</section>
</article>
</section>
</div>
</div>

Fichier .cshtml se traduisant en élément graphique par l’image ci-dessous :

order_details.PNG

Détail du produit Mug

Il en va de même pour toutes les pages, chaque pages fonctionnant de la même façon. Notre Contrôleur va gérer nos données (Modèle) et retourner la Vue correspondante au Contrôleur.

 

Conclusion

Ce qu’on peut tirer de ce projet, est l’application d’une architecture monolithique en opposition avec le eShopOnContainers qui se base sur les micro-services.

Ce sont deux approches différentes et qui ont chacune leurs avantages et leurs inconvénients.

Néanmoins ces derniers temps, les entreprises privilégient les micro-services avec Docker et le concept de conteneurisation.

Article écrit par :

  • Julie LACOGNATA <julie.lacognata@infeeny.com>
  • Kévin ANSARD <kevin.ansard@infeeny.com>

Déploiement d’un projet Web API .NET Core 3.1 avec Azure Kubernetes Services (AKS)

Nous avons eu l’occasion de travailler à deux reprises avec Kubernetes.

Deux univers bien distinct : Windows et Linux

Ce qu’il faut savoir, c’est que Kubernetes ne fonctionne pas sous Windows dans son plus simple appareil, il faut donc utiliser Linux pour pouvoir le découvrir et pour l’apprendre concrètement.

Si vous voulez l’utiliser sous Windows, il vous faudra utiliser des services externes type AKS. Néanmoins, pour ma part, je trouve que la compréhension d’un outil via ce genre de plateforme est assez biaisé, car trop « magique”. Cela demande une certaines rigueur,une curiosité et un intérêt différent que si vous le faisiez directement sous Linux.

Prérequis pour ce tutoriel

  • Visual Studio 2019 (ou Visual Studio Code)
  • Internet (pour accéder au portail Azure)
  • Powershell
  • Helm
  • Chocolatey
  • Docker
  • Azure-CLI

Création d’une Web API .NET Core 3.1 avec un container Docker sous Linux

Aujourd’hui, nous allons voir ensemble comment créer une Web API sous .NET Core 3.1 et la déployer sous Azure.

Ouvrez votre Visual Studio et créer un nouveau projet ASP .NET Core Application.

Choisissez ensuite API (faites attention à bien avoir sélectionné .NET Core ainsi que la version 3.1) puis dans le panneau de configuration à droite dans la partie “Advanced” de cocher “Enable Docker Support” et de choisir Linux.

1_HIycDu3ImbMFl2B6aDqQbA.png

Choix de la création de projet via Visual Studio et support Docker avec des containers Linux.

L’API par défaut que crée Microsoft, s’appelle WeatherForecast, et dans notre cas nous avons choisis de nommer notre projet WeatherForecastLinux (pour les personnes manquant d’inspiration pour le nommage, c’est cadeau…).

On va donc constater qu’un fichier Dockerfile est présent. Si vous pratiquez Docker ou que vous avez quelques bases dessus vous connaissez donc son utilité. Pour expliquer pourquoi il est présent, vous vous doutez fortement que c’est dû au fait qu’on ait coché la case de support de Docker lors de la création du projet.

Pour les personnes ne sachant pas ce qu’est un Dockerfile, voici une définition succincte : c’est un fichier texte contenant des instructions sur la façon de construire une image Docker.

Voilà à quoi ressemble notre Dockerfile auto-généré :

FROM mcr.microsoft.com/dotnet/core/aspnet:3.1-buster-slim AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443
FROM mcr.microsoft.com/dotnet/core/sdk:3.1-buster AS build
WORKDIR /src
COPY [“WeatherForecastLinux.csproj”, “”]
RUN dotnet restore “./WeatherForecastLinux.csproj”
COPY . .
WORKDIR “/src/.”
RUN dotnet build “WeatherForecastLinux.csproj” -c Release -o /app/build

FROM build AS publish
RUN dotnet publish “WeatherForecastLinux.csproj” -c Release -o /app/publish
FROM base AS final
WORKDIR /app
COPY — from=publish /app/publish .
ENTRYPOINT [“dotnet”, “WeatherForecastLinux.dll”]

Si vous souhaitez vérifier que votre application se lance correctement, je vous suggère de cliquer sur :

1_FzBBfH9h-p7ucjzNtQugBw.png

Le fait de cliquer sur Docker, va permettre de build et de run le Dockerfile et donc de créer l’image Docker.

Nous allons maintenant ouvrir une fenêtre PowerShell :

  • Soit vous l’ouvrez directement dans le dossier de votre projet
  • Soit vous vous placez au bon endroit pour être au niveau de votre Dockerfile

Le build et le run précédent vous on créée une image, pour vérifier le nom de celui-ci vous pouvez directement taper la commande :

docker ps -a

Ou

docker images
Picture1.png

Dans notre cas, l’image qui nous intéresse est : weatherforecastlinux

 

Maintenant que toutes les fondations sont posées, nous pouvons maintenant passer au déploiement.

Azure Kubernetes Service (AKS)

Tout d’abord, assurez-vous d’avoir accès au Portail Azure, si ce n’est pas le cas créer vous un compte via une adresse Microsoft, et utiliser les 150€ gratuit fournit de base par Microsoft (si vous êtes vigilant dans vos différentes opérations avec Azure, vous ne devriez pas utiliser tout ce crédit en un coup).

Petit disclaimer : il y aura forcément un aspect « magique » ou un aspect de confusion pour les nouveaux arrivants sur Azure (et parfois même pour les plus anciens…) car Azure est très vaste, mais ne vous inquiétez pas, c’est tout à fait normal !

Il nous faudra tout d’abord installer Azure-CLI sur notre poste, afin d’utiliser la commande az (qui nous permet de faire de l’Azure directement via notre fenêtre Powershell). Pour se faire, ouvrir Powershell en mode administrateur et utiliser la commande suivante :

Invoke-WebRequest -Uri  -OutFile .\AzureCLI.msi; Start-Process msiexec.exe -Wait -ArgumentList ‘/I AzureCLI.msi /quiet’

Redémarrer votre Powershell pour que la commande puisse être active. Si cela ne fonctionne pas chez vous, installez le .msi directement sur le site et installez-le classiquement.

Il vous faut maintenant vous connecter, pour que votre instance et les informations soient bien raccorder à votre Portail Azure :

az login -u votremail@mail.com -p votremotdepasse

Kubernetes

Kubernetes est un orchestrateur. On peut dire que c’est un ensemble de services réseaux qui permet de lancer des pods Docker en cluster avec une gestion de Load Balancing.

Pods

Les pods correspondent au processus en cours d’exécution et encapsulent un ou des conteneurs applicatifs. Ce sont des instances uniques, cela signifie qu’ils possèdent :

  • Une IP unique
  • Un fichier qui indique comment le conteneur doit être exécuté
  • Des ressources de stockage

Ce qu’il faut retenir, si nous devions résumer un peu tout ça, c’est que les pods peuvent correspondre à une application ayant sa propre mémoire, sa propre IP. Néanmoins, un pod a une durée de vie définit et ne sera pas en mesure de se relancer automatiquement de lui-même.

Load Balancing

Ou répartition de charge en français, désigne un processus de répartition d’un ensemble de tâche sur un ensemble de ressources. Le but étant de rendre le traitement global plus efficace, en permettant d’optimiser le temps de réponse pour chaque tâche tout en évitant un surcharge inégale des nœuds de calculs.

Création d’un Resource Group Azure : WeatherForecastAPI_RG

Resource Group (ou RG)

Un resource group ou groupe de ressources est en quelque sorte un conteneur dit « logique » ayant pour objectif de regrouper différentes entités (Web API, VM, Base de données, etc…). Toutes les entités présentes au sein du groupe sont alors accessibles.

Dans notre cas, cela va nous permettre de créer un cluster et de déployer notre application directement dans ce RG.

Pour pouvoir créer un groupe de ressources en ligne de commande :

az group create --name WeatherForecastAPI_RG --location francecentral

La réponse à cette commande devra vous apparaître sous cette forme :

{
  "id": "/subscriptions/caf29a4f-0f21-45d9-b52e-f1e0c0b8e4be/resourceGroups/WeatherForecastAPI_RG",
  "location": "francecentral",
  "managedBy": null,
  "name": "WeatherForecastAPI_RG",
  "properties": {
    "provisioningState": "Succeeded"
  },
  "tags": null,
  "type": "Microsoft.Resources/resourceGroups"
}

Comme nous pouvons le voir, nous retrouvons le nom de notre Resource Group ainsi que son state (Succeeded). Nous pouvons également voir que nous avons bien la localisation précédemment choisie qui nous est retournée.

Build de l’image Docker

Docker

Docker est une plateforme de conteneurisation. Et les conteneurs ressemblent en tout point à des machines virtuelles ou seul le système d’exploitation ou OS aura été virtualisé. Docker permet de regrouper tout le nécessaire de notre application et est donc qualifiée de compacte, puissante et innovante avec une scalabilité importante.

Nous allons donc builder l’image dont on parle un peu plus haut : weatherforecastlinux mais cette fois nous allons récupérer le tag avec le mot clef -t (que vous pouvez également voir sur la capture d’écran plus  haut).

docker build -t weatherforecastlinux:dev .

Si tout se déroule correctement vous êtes censés avoir une mention de toutes les étapes présente dans votre Dockerfile ainsi que la notion Successfully

Création de la registry WEFCACR dans Azure Container Registry (ACR)

Registry

Une registry est une sorte de « repository » d’images. Grossièrement on peut dire que c’est un espace de stockage d’images.

Pour pouvoir la créer sous Azure en ligne de commande :

az acr create --resource-group WeatherForecastAPI_RG --name WEFCACR --sku Basic

La commande ci-dessus permet de créer une registry, en spécifiant le Resource Group ainsi que le nom que l’on souhaite donner à la registry (ici WEFACR). Le –sku Basic est un élément sans importance, d’ailleurs si vous ne l’indiquez pas, par défaut il vous sera rajouté.

La commande suivante, vous permet de lister les différentes registry.

az acr list --resource-group WeatherForecastAPI_RG --query "[].{acrLoginServer:loginServer}" --output table

Enfin la commande az acr login, vous permet comme son nom l’indique de vous connecter à Azure Container Registry (ACR).

az acr login --name WEFCACR

Tag de l’image Docker avec la registry wefcacr.azurecr.io

La commande ci-dessous, vous permet de taguer votre image docker en lui donnant un nouveau nom :

docker tag weatherforecastlinux:dev wefcacr.azurecr.io/weatherforecast:dev

Se connecter dans la registry WEFCACR

az acr login --name WEFCACR

 

Push de l’image Docker dans WEFCACR

On va push l’image dans la registry en faisant un docker push et en spécifiant le nom de la registry (que l’on peut retrouver à l’aide de la commande az acr list) et en spécifiant le nom de l’image ainsi que son tag.

docker push wefcacr.azurecr.io/weatherforecast:dev

 

Création du cluster AKS WEFCACRCluster

Cluster

Un cluster Azure peut être considéré comme une « grappe », il peut utiliser des nœuds et exécuter des conteneurs.

Allez sur le portail Azure et dans la barre de rechercher, taper Kubernetes services :

Kubernetes_services.png

Cliquez sur le bouton Add, vous atteindrez cette page :

Picture2.png

Puis cliquer sur Ajouter, votre Cluster mettra un certains temps à se créer ce qui est tout à fait normal. Il vous faudra donc patienter deux minutes grand maximum, avant de lancer la commande suivante :

Connexion au cluster WEFCACRCluster

az aks get-credentials --resource-group WeatherForecastAPI_RG --name WEFCACRCluster

permet d’associer le ressource group a notre cluster

Liaison entre le cluster AKS et la registry

az aks update -n WEFCACRCluster -g WeatherForecastAPI_RG --attach-acr WEFCACR

ici nous attachons notre cluster a notre registry en spécifiant a qu’elle ressources groupe notre cluster appartient

Installation de Helm sous Windows

Helm est un gestionnaire de paquets pour Kubernetes qui va permettre d’installer et de gérer le cycle de vie de nos applications.

Pour l’installer sous Windows, il vous faut installer Chocolatey et pour se faire voici la première commande permettant d’installer Chocolatey (gestionnaire de paquets pour Windows qui vous permet d’installer ou de désinstaller des applications grâce à la commande choco).

Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))
  • Installation de Helm via Chocolatey
choco install kubernetes-helm

 

Création des fichiers avec Helm

Nous allons créer un dossier chart, qui sera architecturé de la façon suivante :

  • chart/
    • Chart.yaml
    • values.yaml
    • templates/
      • deployment.yaml
      • service.yaml

Architecture du fichier Chart.yaml

name: aspnet3-demo
version: 1.0.0

Architecture du fichier values.yaml

environment: development

apphost: k8s

label:
name: dockerwithlinux

container:
name: dockerwithlinux
pullpolicy: IfNotPresent
image: jlaacr02.azurecr.io/app1
tag: v1
port: 80
replicas: 3

service:
port: 8888
#type: ClusterIP
type: NodePort

Ce fichier va nous permettre de définir quelle image nous allons pull et quel tag utiliser, ainsi que les port que nous voulons.

Architecture du fichier templates/deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}-deployment
  labels:
    app: {{ .Values.label.name }}
spec:
  replicas: {{ .Values.replicas }}
  selector:
    matchLabels:
      app: {{ .Values.label.name }}
  template:
    metadata:
      labels:
        app: {{ .Values.label.name }}
        environment: {{ .Values.environment }}
    spec:
      containers:
        - name: {{ .Values.container.name }}
          image: {{ .Values.container.image }}:{{ .Values.container.tag }}
          imagePullPolicy: {{ .Values.container.pullPolicy }}
          ports:
            - containerPort: {{ .Values.container.port }}
          env:
            - name: apphost
              value: {{ .Values.apphost }}
            - name: appenvironment
              value: {{ .Values.environment}}

Ce fichier forme notre application en type deployement .

Architecture du fichier templates/service.yaml

apiVersion: v1
kind: Service
metadata:
  name: {{ .Release.Name }}-service
  labels:
    app: {{ .Values.label.name }}
spec:
  ports:
  - port: {{ .Values.service.port}}
    protocol: TCP
    targetPort: {{ .Values.container.port }}
  selector:
    app: {{ .Values.label.name }}
  type: {{ .Values.service.type }}

Ce fichier forme notre application pour le mode service.

Déploiement dans AKS via Helm

La commande ci-dessous permet de déployer notre image.

helm install dockerwithlinux ./chart

Déploiement dans AKS sans Helm

Nous allons créer un fichier my1.yaml :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: dockerwithlinux-app
spec:
  selector:
    matchLabels:
      run: dockerwithlinux
  replicas: 3
  template:
    metadata:
      labels:
        run: dockerwithlinux
    spec:
      containers:
        - name: dockerwithlinux
          image: jlaacr02.azurecr.io/dockerwithlinux:v1
          ports:
            - containerPort: 80
              protocol: TCP
---
apiVersion: v1
kind: Service
metadata:
  name: dockerwithlinux-service
  labels:
    app: dockerwithlinux
spec:
  ports:
  - port: 8888
    protocol: TCP
    targetPort: 80
  selector:
    app: dockerwithlinux
  type: NodePort

Déploiement dans Kubernetes du fichier my1.yaml

kubectl apply -f my1.yaml

Exposition du déploiement en service

kubectl expose deployment dockerwithlinux-deployment --type=LoadBalancer --name=dockerwithlinux-service

Récupération de l’adresse IP externe du service

kubectl get service dockerwithlinux-service

Cette commande nous permet de récupérer notre service ainsi que l’IP externe qui sera tout d’abord dans un état dit « pending » (en attente en français).

getservices.PNG

Nous en avons créé un deuxième de service ici, mais fiez-vous à la commande get-service que vous voyez.

Comme nous pouvons le voir ici, par rapport à ce que nous disions, nos avons un EXTERNAL-IP ou IP externe qui prend tout d’abord un état « en attente » en fonction de l’état de votre cluster (vous n’aurez pas du tout la même IP que nous donc dans l’étape du dessous pensez bien à mettre votre EXTERNAL-IP que la commande vous indiquera).

Test du service

Comme vu juste au dessus, nous allons donc récupérer notre EXTERNAL-IP est l’inclure dans la commande suivante :

curl 20.40.148.135/controllerName/methodName

Mettre capture d’écran.

Nous allons maintenant nous rendre sur le portail Azure, afin de visualiser le cluster WEFACRCluster.

Monitoring

Cluster

portailcluster.PNG

Nous voici à présent sur le portail Azure, dans notre Cluster (pour rappel, pour y accéder il faut aller au niveau de Kubernetes Services, puis sur votre Cluster, et aller dans l’onglet Insights). On peut constater les diverses activités de celui-ci.

On peut voir la quantité de CPU utilisé, la mémoire, le nombre de nœuds ainsi que l’activité des pods.

Contrôleurs

Vous restez sur votre Cluster, et vous devez sélectionner Controller :

controller.PNG

Cette partie contrôleurs, peut s’apparenter au portail Kubernetes qui nous permet de visualiser les différents états de nos images.

 

Conclusion

Comme nous avons pu le voir tout au long de ce tutoriel, Azure est une sorte de baguette magique surpuissante, mais qui dissimule un pouvoir mal compris ou mal utilisé par beaucoup d’entre nous finalement. Hors malgré cela, il ne faut pas simplement le pointer du doigt en disant que c’est le mal, mais plutôt essayer de comprendre en profondeur où cela veut nous mener. Kubernetes et Docker sont de plus en plus mis sur le devant de la scène et pour une meilleure compréhension, nous avons tendance à penser qu’il vaut mieux que vous vous formiez indépendamment d’Azure, car la dissimulation est le pire ennemi du savoir et dans notre milieu, en tant que développeurs, le savoir et la capacité d’apprendre par nous-même est, selon nous, primordial.

 

Article écrit par :

  • Julie LACOGNATA <julie.lacognata@infeeny.com>
  • Kévin ANSARD <kevin.ansard@infeeny.com>