Pour ce tutoriel nous utiliserons la registry provisionné ici et le projet hébergé dans ce repository. J’ai remis les commandes utilisées pour créer la Azure Container Registry, pour plus de précision vous pourrez consulter le précédent article 🙂 Le but de ce tutoriel est de partir d’un projet ASP .Net Core conteneurisé et le déployer dans un cluster Kubernetes dans Azure (AKS).
Introduction à Azure Kubernetes Service
Avant de présenter Azure Kubernetes Service en tant que produit Azure, il faut s’intéresser à l’outil Kubernetes lui même.
Kubernetes est une plateforme open source d’orchestration de containers créée par Google, puis offert à la Cloud Native Computing Foundation en 2015.
Kubernetes permet d’automatiser le déploiement et la gestion d’applications conteneurisées. K8s gère le cycle de vie des services en proposant scalabilité et haute disponibilité.
Kubernetes peut fonctionner avec n’importe quel système de container conforme au standard Open Container Initiative et notamment le plus connu d’entre eux : Docker.
Continuer la lecture de « Introduction à Azure Kubernetes Service »
Visual Studio & Container Registry
Aujourd’hui nous allons déployer une application dockerisée dans une container registry puis une WebApp directement depuis Visual Studio. Pour tester son application c’est rapide et efficace 🙂
Nous obtiendrons le même résultat que dans l’article précédent, mais bien plus rapidement !
Création du projet
Démarrons depuis un nouveau projet Visual Studio :
Je demande le support Docker Linux pour une Application Web ASP.Net Core. L’environnement local Docker doit être configuré en mode “Docker for Linux”.
Publication
Après avoir testé en local mon site web, je peux effectuer un clic droit sur mon projet puis Publier. Je choisis une publication sur une App Service Linux comme ci-dessous :
Je configure mon App Service en précisant ma Container Registry :
Une fois le déploiement terminé, une page s’ouvre sur mon application déployée :
Sur le portail Azure, je retrouve ma registry et ma web app provisionnées et opérationnelles.
Maintenant, petit focus sur la notion de réplication 🙂 Quelques explications sur la fonctionnalité :
Les entreprises qui souhaitent une présence locale ou une sauvegarde à chaud choisissent d’exécuter des services à partir de plusieurs régions Azure. La meilleure pratique recommandée consiste à placer un registre de conteneurs dans chaque région où les images sont exécutées afin de permettre des opérations à proximité du réseau pour des transferts de calque d’image rapides et fiables. La géoréplication permet à un registre de conteneurs Azure de fonctionner comme un registre unique desservant plusieurs régions à l’aide de registres régionaux à multiples maîtres.
Un registre géorépliqué offre les avantages suivants :
– Noms de registre/d’image/de balise uniques utilisables dans plusieurs régions
– Accès au registre à proximité du réseau à partir des déploiements régionaux
– Aucuns frais de sortie supplémentaires, les images étant extraites à partir d’un registre local répliqué dans la même région que l’hôte de votre conteneur
– Gestion unique d’un registre dans plusieurs régions.
Je dois d’abord upgrader ma registry en mode Premium pour avoir accès à cette fonctionnalité ! Pour plus de détails sur le pricing d’une container registry, voir ici !
Je peux alors ajouter une zone de réplication en sélectionnant l’emplacement voulu sur la carte :
Je valide :
Déploiement en cours …
Réplication active en France 🙂 Ma registry est maintenant déployée dans deux régions différentes !
Bonne conteneurisation, à bientôt !
Thomas
Azure Container Registry
Aujourd’hui nous allons :
- Créer une web application Asp .Net Core
- La déployer dans une Azure Container Registry
- L’exécuter dans une Container Instance
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 :
- Avoir Docker For Windows sur son environnement Windows 10
- Activer Shared Drives dans les options de Docker.
Etre en mode “Linux Containers” plutot que Windows Container.
Voici le DockerFile de mon application, créé par défaut :
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 :
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
Je créé une registry dans mon groupe de ressource : az acr create --resource-group rg_registry --name containeregistrythomas --sku Basic --admin-enabled true
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 !
Déploiement
De retour sur notre environnement Windows nous allons pousser notre image Docker dans notre 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:latestPuis docker push containeregistrythomas.azurecr.io/linuxwebsite:latest
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
En sortie si tout s’est bien passé j’obtiens :
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
Si je tente d’accéder à l’url récupérée grâce à la commande précédente : bingo, tout roule 🙂
Dans le prochain article, nous verrons comment déployer dans une Azure Registry directement depuis Visual Studio 🙂
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 !
ASF : prenons du recul !
Hello !
Pour conclure je vous propose de détailler maintenant les problématiques que nous avons résolus grâce à notre architecture.
Au niveau du projet et du code .Net
- Projet Visual Studio correctement découpé : « separation of concerns »
- Temps d’exécution des builds bien plus rapide.
- Montée en compétence plus rapide sur les projets
- Moins de couplage entre les composants.
Au niveau de l’application
- En cas de modification, on doit tester un service.
- Déploiements plus facile et plus fréquent puisqu’ils sont réalisés sur un périmètre restreint
- La mise à l’échelle est plus simple puisqu’il est facile grâce à ASF de provisionner une nouvelle instance de microservice.
Reprenons notre analyse FURPSE pour détailler les avantages de notre architecture :
- Fiabilité : Notre application est beaucoup plus légère, et la couche de services est résiliente grâce à l’autoscaling Azure Service Fabric.
- Performance : Les temps de réponse sont équivalent mais la charge de calcul est répartis entre service dans le Cloud.
- Maintenabilité : Le code est correctement découpé, il est donc bien plus facile à tester et debugger.
- Evolutivité : En cas d’évolution sur un service, on doit redéployer ce service et non plus toute l’application. On peux effectuer une migration techniques / technologiques de façon plus simple sur un contexte réduit.
Nous avons donc répondu aux problématiques de notre existant et rendus notre application facilement déployable, testable, maintenable, évolutive et tolérante aux pannes.
Intégration et déploiement continu avec Azure Service Fabric
Nous allons maintenant détailler la mise en place de VSTS (Azure DevOps), notre outil ALM, pour notre projet Service Fabric.
Intégrations
Premier besoin, un outil de gestion de version. J’ai utilisé Git et le pattern d’utilisation GitFlow pour la gestion des branches. Ce pattern propose une façon d’utiliser Git. Pour mes besoins je n’ai utilisé que les branche Develop et Master.
J’ai donc créé un projet sur VSTS. il faut ensuite utiliser l’URL du dépôt pour s’y connecter depuis Team Services de Visual Studio et pousser son code.
J’ai ensuite configuré mon build à partir du template Azure Service Fabric :
En exécution ça donne ça :
Déploiements
Pour le déploiement vers notre environnement Cloud Service Fabric c’est très simple, une seule étape VSTS suffit :
Bien sur dans un vrai contexte projet le pipeline sera plus fournis, avec de multiples environnement : dev, qualification, intégration, pre-production …
Pour la configuration de ma tache de déploiement, il faudra configurer correctement la section Cluster Connexion qui fera le lien entre VSTS et ma plateforme Azure :
Les informations demandées par cet écran sont expliquées par les infobulle. Si vous n’avez pas associé de mot de passe à votre certificat, laissez le champ vide.
Pendant l’étape de déploiement de notre projet Service Fabric, l’Explorer affichera également des informations sur le déploiement :
La mise à jour se fait sans interruption de service puisque le déploiement se fait par nœud. A un instant T du déploiement il y aura donc deux versions de votre application en exécution simultanée. A chaque mise à jour de nœuds, Azure Service Fabric réalise des tests pour vérifier que votre installation s’est bien passée. Si l’update à échoué, un rollback vers la précédente version est automatiquement réalisé.
Pour une gestion plus poussée des montée de version, on pourra mettre en place le « Blue / Green Deployment » qui nous permettra de valider la version à jour de notre service (par des tests sur l’interface swagger par exemple) sur un nœud précis avant de la déployer sur les autres.
Pour aller plus loin
Canary Release / Blue Green Deployment
A bientôt !
Thomas
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éé :
Pour déployer dans Azure, j’aurais pu également utiliser Azure 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.
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 :
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 :
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.
Le monitoring de nos services en local :
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.
Pour le déploiement vers notre cluster, il faudra configurer le fichier cloud.xml :
- 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 !