Azure Container Registry

Aujourd’hui nous allons :

Il s’agit de mon premier article sur la toute nouvelle version de Visual Studio : VS 2019 actuellement en version 16.1.1. Le code source de cette application, créé par le générateur de projet Visual Studio est ici : github.com !

Prérequis

Les prérequis pour ce tuto :

4 - Azure Container Registry
  • Avoir Docker For Windows sur son environnement Windows 10
  • Activer Shared Drives dans les options de Docker.
3 - Azure Container Registry

Etre en mode “Linux Containers” plutot que Windows Container.

5 - Azure Container Registry

Voici le DockerFile de mon application, créé par défaut :

2 - Azure Container Registry

En exécution locale, Visual Studio va me créer mon image Docker, instancier un conteneur basée sur cette image et le déployer. Je peux alors le tester en local, et le débugger :

1 1 1024x493 - Azure Container Registry

Création de la registry

Maintenant je veux créer une registry Docker pour héberger mes belles images !
Direction : Azure ! Cette registry nous permettra de gérer nos images Docker pour ensuite pouvoir les déployer facilement dans une Web App, une instance de conteneur, un cluster Kubernetes, Service Fabric …

Dans la console Azure Cloud Shell : >_ (A noter qu’il est tout à fait possible de réaliser ces opérations également en local après s’être identifié sur son tenant Azure via la commande az login)

Je créé un groupe de ressource rg_registry : az group create --name rg_registry --location eastus

6 1024x404 - Azure Container Registry

Je créé une registry dans mon groupe de ressource : az acr create --resource-group rg_registry --name containeregistrythomas --sku Basic --admin-enabled true

7 1024x312 - Azure Container Registry

Pour plus d’information sur le pricing de la registry (–sku) voir : pricing ACR

Je peux vérifier sur le portail le bon déroulement de l’opération :

Rendez vous sur la page “Clés d’accès”. Les informations d’authentification vont nous servir très vite !

8 1 1024x338 - Azure Container Registry
9 1 1024x318 - Azure Container Registry

Déploiement

De retour sur notre environnement Windows nous allons pousser notre image Docker dans notre Registry !

11 1 1024x106 - Azure Container Registry

Je me connecte à ma registry : docker login --username containeregistrythomas --password <passwd> containeregistrythomas.azurecr.io

Je demande la liste des images disponible sur mon environnement : docker images

Avant de pouvoir push mon image , il faut que je la tag pour ma registry : docker tag websitedockerlinux containeregistrythomas.azurecr.io/linuxwebsite:latest
Puis docker push containeregistrythomas.azurecr.io/linuxwebsite:latest

12 - Azure Container Registry
13 - Azure Container Registry

Il est temps de retourner sur le portail Azure…

Je créé une instance de conteneur à partir de mon image : az container create --resource-group rg_registry --name instancelinuxwebsite --image containeregistrythomas.azurecr.io/linuxwebsite:latest --dns-name-label containerLinux --ports 80

14 1024x115 - Azure Container Registry

En sortie si tout s’est bien passé j’obtiens :

15 1024x721 - Azure Container Registry

Il faut maintenant que je puisse y accéder. Je peux récupérer les infos à partir de cette commande :
az container show --resource-group rg_registry --name instancelinuxwebsite --query "{FQDN:ipAddress.fqdn,ProvisioningState:provisioningState}" --out table

16 1024x69 - Azure Container Registry

Si je tente d’accéder à l’url récupérée grâce à la commande précédente : bingo, tout roule 🙂

17 1024x553 - Azure Container Registry

Dans le prochain article, nous verrons comment déployer dans une Azure Registry directement depuis Visual Studio 🙂

Bye !

Thomas

Microsoft Build 2019

Hello ! Voici les 3 news du Build 2019 qui ont retenu mon attention !

RE2V5Vt - Microsoft Build 2019
.Net 5 !

Microsoft annonce pour 2020 la publication d’un Framework .Net unifié. Il n’y aura plus de distinction .Net et .Net Core, il n’y aura qu’un Framework .Net qui permettra de cibler les environnements Windows, Linux, MacOs etc … La prochaine version de .Net Core, après .Net Core 3, prévu pour Septembre 2019, sera donc .Net 5.

dotnet5 platform 1024x546 - Microsoft Build 2019

Le projet vise à améliorer .NET de plusieurs manières:

  • Créer un environnement d’exécution et de framework .Net unique, natif et uniforme.
  • Gérer une base de code unique sur laquelle les développeurs peuvent travailler et innover.
  • Utiliser le meilleur de chaque monde (.Net, .Net Core, Xamarin, Mono)

Le tout open source et multi-plateforme dans la lignée de .Net Core et de ce qui à fait son succès.

dotnet schedule 1024x566 - Microsoft Build 2019

Microsoft prévoit de livrer .NET Core 3.0 en septembre, .NET 5 en novembre 2020, puis prévoit une version majeure une fois par an, tous les mois de novembre.

Visual Studio Container Tools Extension

Microsoft continu ces efforts pour le développement d’application conteneurisé dans Visual Studio. A installer depuis le Marketplace cette extension, à utiliser en complément de Visual Studio Tools for Containers, offre de nouvelles fonctionnalités de création, débogage et monitoring d’app conteneurisées 🙂

1 - Microsoft Build 2019
Windows Terminal
microsoft new windows terminal - Microsoft Build 2019

Microsoft lance une nouvelle interface de ligne de commande : Windows Terminal. Elle est conçu pour être l’emplacement central pour l’accès à des environnements tels que PowerShell, Cmd et Windows Subsystem for Linux (WSL). Nouveautés très attendues, la gestion des onglets dans le terminal ! On pourra également y ajouter des thèmes ainsi que des extensions.

windows terminal 050002D001660163 1024x576 - Microsoft Build 2019

Voila pour les principales news du Build 2019 ! Bye !

Thomas

Keep Calm & PoC sur Azure

Hi ! “Les idées, en général, cela ne manque pas. Pour ce qui est du temps, c’est déjà plus délicat. Durant cette présentation, nous verrons quels outils et services Azure peuvent nous aider à développer un PoC rapidement”.

Ci-dessous les sujets abordés au Meetup Mug .Net de mars. Meetup organisé par Nicolas Mariot et présenté par Christophe Maneu !

Azure Functions : Offre Serverless : on déploie une méthode et on définit un trigger qui déclenche cette fonction (appel http, enregistrement en base, arrivée d’un message sur un ServiceBus…).

Azure App Service : Offre PAAS : hébergement d’application web . Net ou .Net Core (et même Java, Php, Node) . Dockerisé ou non.

Web API ASP.NET Core

Azure App Service

Azure DevOps : Anciennement TFS / VSTS : outils d’intégration / déploiement continu de Microsoft.

Microservices et Application Lifecycle Management

Microsoft Visual Studio Team Services

Application Insights : Monitoring des applications déployées.

Logic Apps : moteur de workflow. Équivalent de Microsoft Flow, mais avec des connecteurs pour Azure.

Azure DevOps Project : Pour générer automatiquement une solution Visual Studio + pipeline d’intégration / Déploiement continu + hébergement.

Il n’y a plus qu’à ouvrir Visual studio et se brancher sur le repository, toute l’indus et l’hébergement Cloud est fait.

Azure DevOps Project

Azure Blob Storage : Stockage

Votre compte MSDN vous permet d’activer un crédit Azure de 150$ par mois pour faire vos tests : https://my.visualstudio.com/benefits

Bon PoC dans Azure !

3 - Keep Calm & PoC sur Azure

Centre de déploiement et DevOps Project

Pour mon test dans le précédent article, j’avais besoin de créer et déployer rapidement dans Azure une WebAPI.

Deux possibilités !

J’ai créé le projet sous Visual Studio, je l’ai publié sur Azure. Si je veux ensuite gérer le projet sous Azure DevOps (VSTS ) je peux utiliser le module Centre de déploiement de la Web Application. J’obtiens alors très simplement une configuration de build et release pour le déploiement vers Azure et je n’ai plus qu’a pousser mon code sur le dépôt créé :

4 - Centre de déploiement et DevOps Project

5 - Centre de déploiement et DevOps Project

6 - Centre de déploiement et DevOps Project

Pour déployer dans Azure, j’aurais pu également utiliser Azure DevOps Project !

3 - Centre de déploiement et DevOps Project

Cette outils permet depuis Azure et sans besoin préalable de :

  • Créer une Web Application du langage / framework de votre choix.
  • Créer un projet et un repository git dans VSTS
  • Configurer CI et CD.

Cet outils est très facile à utiliser, il suffit de quatre étapes pour générer un pipe d’intégration et de déploiement continue vers Azure.

2 - Centre de déploiement et DevOps Project

Il ne reste plus qu’a récupérer le code source créée par Azure DevOps en se connectant au repository pour pouvoir commencer à travailler. Notre configuration de builds et de releases est déjà opérationnelle.

A l’heure actuelle, février 2019, Azure DevOps Project s’enrichit :

7 - Centre de déploiement et DevOps Project

Pour les projets basés sur le Framework Core nous pouvons générer le code, et le pipeline CI/CD en quelques clics pour les solutions :

  • WebApplication Windows ou Linux
  • WebApp conteneurisé avec Docker
  • Fonction pour faire du serverless
  • Service Fabric pour du microservices made in Microsoft
  • Kubernetes Service pour du microservices managé via K8s.

Pour tester un nouveau produit, il n’y a rien de plus facile !

Thomas

Comment implémenter les appels à Azure Service Fabric ?

Pour la communication entre services nous avions listé deux possibilités :

  • Echange synchrone via commande HTTP
  • Échange asynchrone via un bus d’évènement basé sur le protocole AMQP.

Ici je vais expliquer la communication synchrone par appel HTTP. A mon sens pour démarrer sur cette architecture nous pouvons commencer par cette approche. Si par le suite le besoin est présent alors une utilisation d’Azure Service Bus peux être implémenter et déployer progressivement.

Voici une méthode permettant à notre application cliente d’appeler un service dans Service Fabric :

1 1 - Comment implémenter les appels à Azure Service Fabric ?

Il s’agit d’un appel d’une API REST tout à fait classique. Notre service est exposé via le port 82. Pour ce faire nous avons ouvert le port sur notre cluster lors de la création et configuré le port de notre service dans le fichier ServiceManifest.xml du projet : Verifier la section Resources/Endpoints du fichier.

Si un autre service de mon cluster Service Fabric doit réaliser le même appel, l’url sera la suivante : http://localhost:19081/OrangeTechsMicroservices/Clients/1. On remarque que l’appel se fait sur localhost (quel que soit l’environnement) et que le port utilisé est celui du reverse proxy Service Fabric.

Comme déjà évoqué, la complexité des appels HTTP est plutôt faible, nous verrons que l’utilisation de Service Bus pour effectuer des échanges asynchrones n’est pas aussi évidente et demande un peu plus de réflexion.

A bientôt !

Tester son projet Azure Service Fabric

Hello,

Suite à la création de notre projet nous allons aujourd’hui le tester en local puis le déployer dans Azure.

En local il est possible d’exécuter son projet Azure Service Fabric comme si il était déployé dans le Cloud puisque le déploiement de notre application se fait dans un cluster Service Fabric local, exécuté sur le poste de développement. On a ensuite accès à l’écran d’administration et nous pouvons debugger notre application comme n’importe quel projet .Net.

5 1 - Tester son projet Azure Service Fabric

6 1 - Tester son projet Azure Service Fabric

Le monitoring de nos services en local :

7 1 - Tester son projet Azure Service Fabric

Pour effectuer nos premiers tests de déploiement, on peut utiliser la publication Visual Studio qui s’interface très bien avec Azure. Attention pour les publication de « mise à jour » pensez à cocher « Mettre à niveau l’application » comme ci-dessous et à modifier les numéros de versions du manifeste.

8 - Tester son projet Azure Service Fabric

Pour le déploiement vers notre cluster, il faudra configurer le fichier cloud.xml :

9 - Tester son projet Azure Service Fabric

  • ConnectionEndpoint : L’URL de notre cluster sur le port 19000
  • ServerCertThumbprint : Identifiant du certificat de notre cluster.

Précisions intéressante, Il est possible de déployer son projet sur un cluster public ! Pour effectuer un POC avec un crédit Azure restreint c’est très utile, voir : https://try.servicefabric.azure.com/

A bientôt !

Application Service Fabric dans Visual Studio 2017

Hello !

Suite à la création de notre cluster Service Fabric dans Azure, nous allons aujourd’hui détailler la création de notre projet dans Visual Studio 2017.

Création du projet

Tout d’abord il faut configurer le poste du développeur pour utiliser les templates de projets  ASF. Pour télécharger et installer le SDK rendez vous ici : https://docs.microsoft.com/fr-fr/azure/service-fabric/service-fabric-get-started

Nous pouvons maintenant créer notre projet Cloud de type Application Service Fabric :

1 - Application Service Fabric dans Visual Studio 2017

Nous devons ajouter un premier service à notre projet :

2 - Application Service Fabric dans Visual Studio 2017

Pour bien comprendre les différents type de service (au delà du framework .Net utilisé) que nous pourrons héberger dans notre cluster, je vous invite à consulter ce lien.

Pour faire simple nous pouvons retenir :

  • Service sans état : service “classique” ou les données sont stockés dans une source de connées externe (base de données, fichier xml).
  • Service avec état : le service conserve des données qui sont répliquées entre chaque instance du service grâce aux types Reliable. Ainsi si un client tente d’accéder à une donnée du service, peu importe l’instance qui est appelée, la donnée sera la même.

Je choisis le type de projet ASP .Net Core que je veux implémenter comme pour un projet .Net Core classique :

3 - Application Service Fabric dans Visual Studio 2017

Si par la suite je veux ajouter un nouveau projet à mon application il faudra faire clic droit sur notre projet principal et Ajouter > Nouveau Service Service Fabric pour que ce nouveau projet sois lié à notre environnement ASF.

4 - Application Service Fabric dans Visual Studio 2017

On voit ici que la différence majeure entre un service ASP .Net Core standart et un service ASP .Net Core dans Service Fabric c’est le projet par défaut créé par Visual Studio (ici Orange.Techs.Microservices).

Celui-ci contient des fichiers de configurations pour le build et déploiement de nos services dans un cluster Service Fabric. En revanche nos services en eux mêmes (ici Orange.Techs.Microservices.StatelessAPI) sont identiques aux services de type WebApi que nous connaissons déja !

Par conséquent vous retrouvez facilement vos habitudes de développement au niveau des services ! Un point plus que positif à prendre en compte pour l’adoption de cet environnement 🙂

Azure Web App Deployment Slots

Hello !

Un sujet d’actualité aujourd’hui, suite au récent rachat de GitHub par Microsoft, avec la configuration d’un pipe DevOps à partir d’un projet GitHub et en bonus la présentation des slots de déploiement Azure.

Nous allons donc brancher VSTS sur un projet de mon dépôt GitHub.

On commence par créer un nouveau projet :

1 1 - Azure Web App Deployment SlotsInitialisation du dépôt :

2 1 - Azure Web App Deployment Slots

Sélectionner Build and Release > Build > New pipeline et choisir GitHub 🙂

3 1 - Azure Web App Deployment Slots

Il s’agit toujours d’un projet ASP.NET Core :

4 1 - Azure Web App Deployment Slots

On pense à décocher “Publish Web Projects” qui ne concerne pas le type de projet WebAPI :

5 1 - Azure Web App Deployment Slots

Et on lance une build !

6 1 - Azure Web App Deployment Slots

Nous pouvons maintenant configurer notre Release. Build and Release > Release > New definition. Nous allons choisir un template un peu différent de ce que nous avons déjà testé jusqu’a présent !

7 1 - Azure Web App Deployment Slots

Je relie ma release à ma build :

8 1 - Azure Web App Deployment Slots

Je met en place le déploiement continu :

9 1 - Azure Web App Deployment Slots

Petite pause dans la configuration VSTS, nous devons également paramétrer notre Web App Azure !

Je choisis de créer une Web App et je remplis les informations habituelles :

10 1 - Azure Web App Deployment Slots

Une fois ma Web App créée je vais paramétrer un emplacement de déploiement. Ceux-ci sont bien utiles quand il s’agit d’avoir à disposition un environnement de test iso à la production. Ces emplacements de déploiements sont des “sous applications”  appartenant au même service plan que votre Web App.

11 1 - Azure Web App Deployment Slots

J’ajoute un environnement “preprod” identique à la production :

12 1 - Azure Web App Deployment Slots

J’ai désormais deux environnements à ma disposition, donc deux URL. La deuxième étant taggé avec le suffixe “preprod” qui correspond au nom de mon slot :

13 1 - Azure Web App Deployment Slots

Et ma Web App de production :

14 1 - Azure Web App Deployment Slots

Je peux vérifier que mes deux Web Apps sont fonctionnelles :

15 1 - Azure Web App Deployment SlotsPassons à la configuration de ma release !

Je remplis comme d’habitude Azure Subscription, le nom de ma Web App et du groupe de ressource associé mais je dois en plus choisir sur quel slot déployer mon application !

16 1 - Azure Web App Deployment Slots

Je choisis dans un premier temps de déployer sur preprod :

17 2 - Azure Web App Deployment Slots

Je pense à modifier le package à déployer :

19 1 - Azure Web App Deployment Slots

Et je vais désactiver la deuxième étape du déploiement. Cette étape effectue un échange entre ces deux environnements, mais ici je ne veux pas que ce swap soit fait automatiquement …

21 1 - Azure Web App Deployment Slots

Ma release est prête !

22 1 - Azure Web App Deployment SlotsJ’effectue une demande de déploiement :

23 1 - Azure Web App Deployment Slots

Release en cours !

24 1 - Azure Web App Deployment Slots

J’ai des informations détaillée sur le déploiement via l’onglet Logs :

25 1 - Azure Web App Deployment Slots

Une fois le déploiement terminé, j’obtiens sur mon environnement “preprod” :

26 1 - Azure Web App Deployment Slots

Mon application est donc opérationnelle sur cet environnement !

Sur l’URL “prod” en revanche :

15 1 - Azure Web App Deployment SlotsRien n’a changé ! C’est ce que nous voulons. Nous avons donc une version N-1 en production et une version N en preprod.

Je peux donc valider tranquillement le fonctionnement de mon API REST. En cas d’erreur, ma production n’est pas impactée et je peux apporter mes modifications. Une fois que tout est testé / vérifié / validé nous pouvons échanger nos environnements.

je retourne sur ma Web API :

27 1 - Azure Web App Deployment Slots

Et je clique sur le bouton Échanger à droite du bouton Arrêter. Je n’ai plus qu’un clic à faire pour swapper entre mes deux environnements !

28 1 - Azure Web App Deployment Slots

Ma preprod est maintenant devenu la prod et inversement. Mon environnement de preprod contient maintenant la version N-1 de mon application tendis que la prod est en version N.

30 1 - Azure Web App Deployment Slots

En cas d’anomalie détectée un peu tard, je n’ai qu’a reproduire l’opération pour que mes utilisateurs récupèrent immédiatement la version N-1 de l’API !

Dernier sujet aujourd’hui, la fonctionnalité “Test en production”. Reprenons notre déploiement de tout à l’heure avec :

  • En preprod : version N
  • En prod : version N-1

Je peux grâce à cette fonctionnalité orienter un certain volume du trafic utilisateur vers la version de preprod à la place de la production. Ainsi un certain pourcentage des utilisateurs vont pouvoir tester en condition réelle la nouvelle version de l’API. Une fois que le test me semble concluant, je peux procéder au swap !

29 1 - Azure Web App Deployment Slots

Récapitulons les avantages de ces emplacements de déploiements :

  • Pas d’intéruption de service pendant un déploiement. Tout est transparent pour l’utilisateur.
  • Possibilité de tester sur un emplacement dans les mêmes conditions que la production. Quand les tests sont validés, on opère le swap des environnements.
  • Possibilité de rediriger progressivement le flux des utilisateurs pour tester la nouvelle version et vérifier qu’elle répond correctement à l’augmentation du trafic réseaux.
  • Suite au swap, l’emplacement “preprod” contient la version qui était en production. Ainsi, en cas d’anomalie un rollback est facile à opérer.

Cette notion de deployment slot est une mise en oeuvre concrète des patterns “Blue/Green Deployment” et “Canary Release“. Je vous laisse suivre les liens pour une approche plus théorique du sujet 🙂