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.
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 !
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 !
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:latest Puis 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 🙂
Hello ! Voici les 3 news du Build 2019 qui ont retenu mon attention !
.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.
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.
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 🙂
Windows Terminal
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.
Voila pour les principales news du Build 2019 ! Bye !
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.
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.
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 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éé :
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 !
Après un mois de décembre en vacances et un changement de travail début Janvier qui expliquent le peu d’activité sur le blog je vous annonce la reprise des hostilités !
