Azure Devops Pipeline (CI/CD) – Relancer les services

.net 6.0, Asp.net Core, Azure, Azure Devops, CI/CD, Debian, Nginx, Non classé, pipeline

Services Debian systemctl Suite à mon dernier article, j’ai été confronté à un problème que j’ai mis longtemps à identifier. Lorsque je mets à jour mon site web, mettons celui du staging avec une nouvelle publication, je modifie les fichiers à la racine du projet, c’est à dire var/etc/www/staging.blazordemo.reactor.fr/ dans mon cas. Pour ma part j’applique une politique du "j’effface tout" et "j’upload tout". Pas de remplacement de fichier. C’est plus long mais je suis certain qu’il y a pas un mauvais fichier en ligne.  Hormis des pb de cache ou de rafraichissement, mon site web est bien à jour.  Mais pas mon service Kernel. En tout cas sur linux Nginx, lorsque je rajoute par exemple un controler "api/plateform" coté serveur, si je ne relance pas mon service avec les commandes suivantes : sudo systemctl stop kestrel-staging.blazordemo.reactor.fr.service sudo systemctl start kestrel-staging.blazordemo.reactor.fr.service sudo systemctl status kestrel-staging.blazordemo.reactor.fr.service mon api « plateform » ne sera pas accessible. En tapant ces commandes, l’api est accessible. Il serait bon d’inclure cela dans la pipeline, histoire qu’on est rien à faire à la main à chaque run de pipeline si le code c# est modifié coté serveur. Pour cela, il suffit de rajouter ces lignes : – task: SSH@0 displayName: ‘Restart Kestrel Service’ inputs: sshEndpoint: ‘SSH to Ikoula’ runOptions: ‘commands’ commands: | sudo systemctl stop kestrel-staging.blazordemo.reactor.fr.service sudo systemctl start kestrel-staging.blazordemo.reactor.fr.service sudo systemctl status kestrel-staging.blazordemo.reactor.fr.service readyTimeout: ‘20000’ Ca donne ça dans les ‘logs’ des jobs de l’execution du pipeline :

Azure Devops Pipeline (CI/CD) – Environnement

.net 6.0, Architecture, Asp.net Core, Azure, Azure Devops, Blazor, C#, CI/CD, Non classé, pipeline

Problème du dernier post Je me suis bien pris la tête sur le dernier billet au sujet d’un nouveau problème qui est apparu lorsque j’ai voulu diviser mon site web en 2, une partie staging et une partie prod. Ca pourrait tout aussi bien être "preprod", "recette" etc… Avant j’avais qu’un seul site web: blazordemo.reactor.fr. Celui ci a sa config Nginx et son service systemd qui fait tourner Kernel via un proxy sur le port 7777. (voir article ) J’en ai créé un nouveau "staging.blazordemo.reactor.fr".  L’idée est de faire comme les pros, un site web de "staging" et un de "prod".  dev : locale, tambouille de developeur, avec une base de données crado, des machins bricolés, des trucs à jours ou pas… staging:  distante, même environnement que la prod (meme serveur de base de données, même OS, même TOUT, sauf les données qui sont normalement copiés et anonymisés dans le meilleurs des mondes) prod: distante, le site qu’on update le vendredi soir 🙂 Donc j’ai crée "staging.blazordemo.reactor.fr". Sauf que j’ai pas modifié mon service qui fait tourner Kestrel via proxy sur port 7777.  Et j’ai mis un temps fou à m’en apercevoir. (j’ai été jusqu’a faire un gros delete de mon repertoire www. Nginx continuait à me servir un beau site web… même après un reboot. car le service était le meme…) Donc il me faut 2 services… Un de staging, l’autre de prod. Le tout sur un port proxy différent bien évidement.  Bien entendu, ce problème n’existe pas si le staging et la prod ne sont pas sur le meme serveur, ce qui est TRES recommandé. Cependant, je trouve l’exercice intéressant car il pousse dans les retranchements et force à de bonnes pratiques. Mon ancienne technique Dans le projet Blazor Server, dans Program.cs j’ajoutais ceci  Une ligne de compilation conditionnelle qui me changait le port si on était en release (ce que je considèrais comme mon unique prod).  Je pourrais ajouter une condition STAGING avec un port 7776 et m’en servir pour la version staging. A mon sens une directive de compilation n’a rien a voir avec les environnements, je veux dire c’est liés, mais c’est pas son but de définir du paramétrage de port…  Je pense qu’on peut faire mieux, avec les fichiers de conf appsettings.js. Créeons deux autres fichiers de config, un pour la prod et l’autre pour le staging. Normalement vous avez déjà par défaut un fichier appsettings.Development.json launchSettings.json Si vous travaillez avec Visual Studio ou VS Code vous devez savoir que vous avez des options de lancement de votre app qui sont configurable dans le fichier Properties/launchSettings.json Encore un fichier de config qui sème le doute… { « iisSettings »: { « windowsAuthentication »: false, « anonymousAuthentication »: true, « iisExpress »: { « applicationUrl »: « http://localhost:54778 », « sslPort »: 44382 } }, « profiles »: { « BlazorDemo.Server »: { « commandName »: « Project », « dotnetRunMessages »: true, « launchBrowser »: true, « inspectUri »: « {wsProtocol}://{url.hostname}:{url.port}/_framework/debug/ws-proxy?browser={browserInspectUri} », « applicationUrl »: « https://localhost:7249;http://localhost:5249 », « environmentVariables »: { « ASPNETCORE_ENVIRONMENT »: « Development » } }, « IIS Express »: { « commandName »: « IISExpress », « launchBrowser »: true, « inspectUri »: « {wsProtocol}://{url.hostname}:{url.port}/_framework/debug/ws-proxy?browser={browserInspectUri} », « environmentVariables »: { « ASPNETCORE_ENVIRONMENT »: « Development » } } } } Comme on peut le voir dans la section "profiles", je peux lancer mon app soit : Via IIS Express  Via la commande dotnet run La première est historique, je pense qu’on en parlera plus dans qq temps. Avant .net core on était obliger de lancer un server utilisant le .net Framework sous IIS qui est le serveur de Windows. La version Express est la version de dévelopement. Pour moi c’est voué à mourrir, mais certains ont des habitudes et Microsoft les forces pas à les changers.  Depuis .net Core (et donc .net 5 et 6), on peut executer nos app sur n’importe quel OS et serveur web comme apache ou nginx sous linux. On a un serveur web intermédiaire appelé Kestrel qui fait le job. D’ailleurs c’est lui que l’on utilise en dévelopement.  En executant une commande dotnet run sur notre projet serveur, on lance un Kestrel. C’est lui que l’on veut paramétrer pour avoir une config dev, staging, prod.  C’est possible d’éditer en développement ce fichier pour changer de port. Mais c’est uniquement un fichier de conf pour une execution en dev local. C’est pas un fichier de configuration plateforme de prod.  Je place ça là car c’est un fichier qui peut vous semer le doute lors de vos devops et test local. AppSettings.{ENV}.json On va modifier le fichier appSettings.Developement.json et lui rajouter ceci  { « Plateform »: « Dev », « Kestrel »: { « EndPoints »: { « Http »: { « Url »: « http://localhost:1234 » } } }, « Logging »: { « LogLevel »: { « Default »: « Information », « Microsoft.AspNetCore »: « Warning » } } } Perso je rajoute une ligne "Environment" qui me permet de voir dans sur quel type d’environement je suis (et plus tard de l’afficher dans l’app).  Ce qui nous intéresse c’est la section Kestrel. On ajoute un EndPoints et on lui précise un port.  Faites un dotnet run sur votre projet à présent : On a un warning qui nous dit que l’adresse utilisé va écrasé celle du launchsetting.json. C’est ce qu’on veut. On voit bien la nouvelle adresse http://localhost:1234.  C’était pour la démo, en dev ça sert a rien de faire cela, autant utiliser le launchSettings.json qui est la pour ça. Donc enlever la ligne Kestrel, c’était pour la démo. Par contre on va mettre ces configs pour appsettings.staging.json  { « Plateform »: « Staging », « Kestrel »: { « EndPoints »: { « Http »: { « Url »: « http://localhost:7776 » } } }, « Logging »: { « LogLevel »: { « Default »: « Information », « Microsoft.AspNetCore »: « Warning » } } } et appsettings.prod.json { « Plateform »: « Prod », « Kestrel »: { « EndPoints »: { « Http »: { « Url »: « http://localhost:7777 » } } }, « Logging »: { « LogLevel »: { « Default »: « Information », « Microsoft.AspNetCore »: « Warning » } } } ASPNETCORE_ENVIRONMENT Encore une chose à savoir. Pour déterminer sur quel environement .net se trouve, il utilise une variable d’environement ASPNETCORE_ENVIRONMENT Elle est d’ailleurs clairement définie dans le fichier launchSettings.json à "Development". Donc en dev, le fichier de config appsettings utilisé sera appsettings.development.json Pour que ce mécanisme fonctionne en prod, soit on définie la variable ASPNETCORE_ENVIRONMENT à "Production" soit par défaut, si elle n’existe pas, c’est déjà le cas (attention moi j’ai nommé mon appsettings prod et non production). Le problème c’est que une variable d’environement est définie pour tout…

Azure Devops Pipeline (CI/CD) – Deploy

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

Objectif : déploiement en production Dans la précédente partie on a déployé une pipeline sur Azure DevOps. Celle ci nous permet de lancer une build dès que la branche master de notre repo Blazor Sandbox reçoit un nouveau commit. De cette manière on s’assure que le build fonctionne ou pas. On est prévenu du résultat par email.  Ce qui serait intéressant, c’est de pouvoir la déployer sur un serveur web automatiquement en cas de succès.  Ma config J’ai un serveur VPS chez iKoula pour 4€/mois, avec une debian linux.  Ca tourne plutot bien. Mais bon, j’ai pas beaucoup de traffic 🙂 Donc j’ai un site web https://dev.blazordemo.reactor.fr et https://blazordemo.reactor.fr qui tournent tous les deux sous Nginx. Derrière chez deux services kestrel asp.net core sous .net 6.0. (pour faire bien, il aurait fallut dissocier la prod de mon dev (ou recette, staging). Petit budget… Dans /var/www/blazordemo.reactor.fr et /var/www/dev.blazordemo.reactor.fr j’ai mes publications de site web asp.net core Blazor WASM (le serveur et le client WASM "all in one"). L’idée est de dire à Azure Devops Pipeline, lorsque la branche master reçoit un nouveau commit, tu publies une version du serveur et tu balances le tout via SSH (sftp). Pipeline YAML On est fixé sur les objectifs. Maintenant il faut traduire cela en YAML. Voici un bout de doc : https://docs.microsoft.com/fr-fr/azure/devops/pipelines/tasks/deploy/copy-files-over-ssh?view=azure-devops En premier lieu, je vais reprendre la précédente pipeline et modifier build par publish. La différence est notable pour Blazor Server WASM. (voir mon article) Un petit commit + push et on voit que Azure Devops lance un nouveau job. On attend qu’il termine et passe au vert. Je pense qu’on va procédé ainsi, à taton. Petit pas par petit pas.  Une modif + commit + push + retour du Job.  Point SSH/SFTP Pour accéder à mon serveur en toute sécurité, je me connecte via SSH. Je prends donc la main à distance depuis mon poste windows sur mon serveur debian linux, qq part en France. J’ai un mot de passe et un login. Et roule ma poule.  Mais on peut faire mieux. J’ai ajouté une paire de clé privée/publique et une passphrase. Ainsi, il faut avoir la clé privée + la passphrase pour accéder.  C’est plus sécurisant pour moi. Je laisse l’accès SSH classique pour des opérations plus ponctuelles. J’ai de mon côté une serie de fichier .bat qui lance une commande de publication .net core et des commandes winscp (permet de lancer des commandes SFTP depuis Windows). La connection se fait via cette clé et cette passphrase. Ainsi, je peux en un double clic mettre à jour ma prod/staging/recette/dev depuis mon poste, sans lacher mon mdp. Au lieu de le faire à la main depuis un client sftp. Ca marche ! C’est moins rapide qu’un client sftp (car les fichiers uplodé ne sont pas lancés en parrallele). J’ai deux types de scripts. La totale, qui met a jour toute la publication : et un autre "rapide" qui ne mets a jours que le minimum pour aller vite : et son fichier .bat  Donc l’idée, c’est de faire pareil sous Azure Devops. Yaml On va rajouter une nouvelle tâche dans notre pipeline YAML avec CopyFilesOverSSH 4 éléments sont à renseigner : sshEndPoint : c’est le nom de notre connexion SSH que l’on va configurer plus loin sourceFolder : le chemin relatif de votre publish. L’agent de build va s’occuper de récupérer votre publish au bon endroit. Attention au majuscule et minuscule si l’agent est sur linux !!! targetFolder: le chemin de destination de votre publication sur la machine cible.  cleanTargetFolder : facultatif, mais effacer le contenu de la destination fait pas de mal.  Service Connections Le sshEndpoint de tout à l’heure est à configurer dans les "project settings" dans la section Pieplines/Service Connections  Il reste plus qu’à créer la votre en cliquant sur le bouton new connection Sélectionnez SSH : puis remplissez selon votre config, en uploadant votre clé privée. Attention, celle ci doit être au format .pem. Et voila. C’est tout.  Relancer votre pipeline avec un petit git add commit push.  Normalement vous devriez avoir que du vert !

Azure Devops Pipeline (CI/CD) – First Build

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

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

Cloud VPS Hebergement asp.net Framework et Core

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

Je commence à avoir ma petite expérience concernant l’hébergement d’un site asp.net. Et je vais vous en faire part. Je n’ai qu’une contrainte, faire tourner asp.net. Donc ça implique Windows. Enfin jusqu’à ce que je fasse le deuil de mes sites asp.net qui n’ont pas été migrés en .net Core. On reviendra sur ce point plus tard.  J’en profite pour hoster qq site web vitrine pro, des sites de POCs, des projets perso et pro etc… J’ai du monter facile à une quinzaine de site web. Pendant un temps. VPS OVH 40€/mois J’ai du commencer à louer un serveur vers 2010, avec 1&1 qui s’est rebatisé IONOS. C’était pas top de mémoire. Je suis passé chez OVH et pendant presque 8 ans ça a bien tourné.  Un jour j’ai eu un udpate de Windows qu’a foutu la merde. Mon serveur ne voulait plus redémarrer, il restait coincé juste apres le login. Mode sans échec ne faisant rien. Bref, à distance, je pouvais rien faire. Et j’ai donc eu à faire avec le support d’OVH. Chose en 8 ans que je n’avais pas eu à faire.  C’est la que j’ai entendu parlé de la réputation désastreuse de ce support qui est fondé. Un ticket est traité avec lenteur voir meme laissé comme mort pour être automatiquement détruit dans le temps. Bref, mon serveur en caraf pendant plusieurs jours voir semaine, m’a ammené à étudier la concurrence.  L’offre VPS linux est toujours abordable. Le problème c’est l’ajout d’un serveur Windows. Ca a un coup. Qui je l’apprendrai plus tard, est plus cher chez les concurrents. Je trouvais aussi les performances du serveur OVH un peu à la ramasse. De plus il m’occroyait seulement 50Go (Windows en bouffant un tiers, voir la moitié) et je passais souvent du temps a faire du ménage. Bref, il me fallait un coup de pied au cul pour bouger. Cloud Azure Je suis développeur .net Microsoft depuis maintenant 20 ans. J’ai donc suivis Azure de près.  Pas assez car je pige toujours pas combien ça coute. Ca Microsoft l’a bien compris et donc il propose 12 mois gratos avec un maximum de 150€ / mois je crois. Ce qui laisse largement assez pour tester plein de truc.  C’est ce que j’ai fait. Seulement j’ai jamais mis mes sites dessus. Par paresse car tout marchait bien sur OVH. Donc je suis resté sur des essais seulement.  Mais je dois dire que c’est un sacré bordel Azure… Cloud AWS J’ai tenté l’expérience AWS. Ce que j’aimais bien c’est qu’on pouvait tout faire en ligne de commande (sur Azure aussi, mais je l’ai testé bien plus tard). Ce qui me pose problème avec AWS c’est le controle des couts. J’ai tenté de rester au maximum gratuit. Mais c’est facile de sortir des cases sans s’en rendre compte. J’ai donc laissé un site web + BD de tester tourner (sans visite) et ca m’a quand même couté 17€/mois.  Car c’est malheureux, mais tout est décomposé. Faut une base de donnée qui est un service a part. De la resource calcul, des firewalls, de la réplication si on veut bien faire… Bref, ça part d’un truc simple et on se retrouve avec une usine a Gaz. Sans maitrise des couts.  Le pire c’est que lorsque j’ai tout fermé, j’avais quand meme des factures à 0.01€. Ce qui me laissait un gout de beau bordel… VPS Scaleway Dedibox 60€/mois Dedibox m’a séduit. Au début. Déjà parce que je pensais qu’avec le même budget précedent chez OVH, dans les 40€/mois, j’allais avoir un serveur dédié et plus de ressource. C’était vrai. Sauf pour le prix. En effet l’option Windows est cher, et elle n’est pas fixe (par CPU je crois). Elle évolue avec le pack que l’on choisit. Bref j’ai augmenté mes couts. Je passe à 60€. J’avais aussi un nouveau projet ou je pensais avoir du traffic, donc j’ai anticipé une bonne bécane. Ca a servit à rien mais je pouvais pas le savoir. J’ai donc cherché ailleurs…   Hebergeur PlanetHoster 6€/mois J’y croyais pas trop, mais au final quelle surprise ! J’ai dégagé Dedibox qui me coutait trop cher, et je suis tombé sur PlanetHoster. On peut mettre autant de site que l’on veut, tant qu’on a un peu de resource (CPU, Mémoire, IO) En gros on part avec un pack pour 6€ on ceci :  8 CPU16 GB RAM16 MB/s I/O https://www.planethoster.com/fr/Hebergements-World Que l’on répartie sur ses sites comme on veut. Très pratique lorsque l’on s’attend à un pick de charge.  On peut jouer avec du python, node.js, Php et Ruby. Si ils ajoutent .net Core ça serait un must.  Mais j’ai gardé mes sites vitrines et qq POCs. De plus aujourd’hui les sites webs deviennent vite des apps mobile PWA SPA. Donc du JS. J’en ai qq une.  J’ai rajouté qq resources. En tout ca me coute 100€/an. C’est stable, très administrable. Le support répond et résoud les ticket surtout.  Mais bon, comment je fais tourner Asp.net Core ? Ha oui, car à ce stade j’ai laché tout mes anciens site Asp.Net Framework. Je me focalise maintenant sur .net Core.  VPS iKoula 4€/mois Retour au VPS ! Mais ce coup si fini Windows. Bonjour Linux.  Et que ca fait plaisir de voir ces couts aussi bas. Sans déconner, un serveur à 4€ par mois. C’est ouf.  Alors j’ai choisi iKoula, pour essayer. J’ai une offre pas cher. J’aurais pu revenir sur OVH mais ils m’ont trop déçu.  Alors la grosse différence avec les VPS d’avant, c’est que la plus d’interface graphique. Retour à la ligne de commande.   Faut tout monter à la main. Pas grave.  J’ai pas besoin de grand chose : dotnet pour faire tourner un serveur kestrel en proxy Nginx pour serveur web (qui sera devant le proxy kestrel) un firewall, histoire de pas tout laisser ouvert.  letsencrypt pour un certificat ssl. https://docs.microsoft.com/fr-fr/aspnet/core/host-and-deploy/linux-nginx?view=aspnetcore-6.0   Une fois qu’on a payer sur iKoula, on nous propose de lacher une clé publique RSA pour le SSH. (facultatif). Ensuite il faut se connecter via…

Conteneuriser et exploiter un cluster via AKS

AKS, Architecture, Azure, DockerLaisser un commentaire

Dans cet article nous allons suivre le tutoriel de la doc de microsoft tutorial-kubernetes-prepare-app J’ai pour ma part totalement effacé toute resource sur Azure (free trial) pour partir d’une feuille blanche car certain nom de resource été similaire. Ce tuto part du principe que l’on a une application qui fonctionne en dev. On souhaite la conteneuriser, la distribuer sur un registry online puis s’en servir via AKS. Ensuite on verra comment scaler l’app. Ce tuto est plutot long, mais je pense complet sur les sujet essentiels.   1 – Création d’une image docker On va cloner une app de demo sur github, mais si vous avez la votre, prennez la. Ouvrez un terminal, créer un répertoire de travail et se mettre dedans puis taper : git clone https://github.com/Azure-Samples/azure-voting-app-redis.git L’image est très légère. Faut dire que le code aussi. En se rendant dans le repertoire azure-voting-app-redis on peut voir quelques fichiers dont un qui va particulièrement nous intéresser : docker-compose.yaml version: ‘3’ services:   azure-vote-back:     image: redis     container_name: azure-vote-back     ports:         – « 6379:6379 »   azure-vote-front:     build: ./azure-vote     image: azure-vote-front     container_name: azure-vote-front     environment:       REDIS: azure-vote-back     ports:         – « 8080:80 » Ce fichier est relativement simple. Nous avons deux services basées sur une image redis et une app web dont l’image est azure-vote-front. L’image Redis proviendra du registry Docker Hub (version officielle) et la seconde sera buildé avec un dockerfile situé dans le projet web azure-vote. Voici ce dockerfile : FROM tiangolo/uwsgi-nginx-flask:python3.6 RUN pip install redis ADD /azure-vote /app Ce dockerfile va créer un conteneur basé sur l’image tiangolo/uwsgi-nginx-flask (950 Mo) (avec python 3.6). On execute ensuite une commande pour installer redis (via python) et on ajoute le code source du site web dans un repertoire sur le conteneur nommé app. On a plus qu’a taper la commande docker-compose up -d ce qui va monter les deux images dans le registry local. Dans un premier temps cela va télécharger les image de  tiangolo et redis si vous ne les avez pas déjà sur votre poste. Ensuite docker-compose va builder l’image de notre app. (attention, il faudra la rebuilder pour la mettre a jour dans une prochaine image). La commande suivante va lister vos images locales : $ docker images REPOSITORY TAG IMAGE ID CREATED SIZE azure-vote-front latest 9cc914e25834 40 seconds ago 694MB redis latest a1b99da73d05 7 days ago 106MB tiangolo/uwsgi-nginx-flask flask 788ca94b2313 9 months ago $ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 82411933e8f9 azure-vote-front « /usr/bin/supervisord » 57 seconds ago Up 30 seconds 443/tcp, 0.0.0.0:8080->80/tcp azure-vote-front b68fed4b66b6 redis « docker-entrypoint… » 57 seconds ago Up 30 seconds 0.0.0.0:6379->6379/tcp azure-vote-back En lisant nos conteneurs lancé par docker on voit bien nos deux images. On a plus qu’à tester l’url http://localhost:8080 et on devrait voir notre app tourner localement! Un petit docker-compose down pour libérer ces process docker et cette partie est finie. 2 – Envoyer nos conteneurs vers Azure Container Registry La première chose à faire est de créer une instance d’Azure Container Registry (ACR) En premier lieu on créer le groupe de ressources : az group create –name myResourceGroup –location eastus Pour info celui ci n’apparaitra pas sur le portail pour le moment car il est vide. Il faut lui rajouter un élement. Voici la commande pour créer un ACR : az acr create –resource-group myResourceGroup –name myACR35 –sku Basic Le nom du registry doit être unique car il sera accessible publiquement via une url comme celle ci myacr.azurecr.io En tapant cette commande, azure nous indique que ce nom est déjà occupé et nous livre une adress web pour vérifier les nom existant. On va renommer noter myACR en qq chose de libre, myACR35 à l’air de passer : > az acr create –resource-group myResourceGroup –name myACR35 –sku Basic { « adminUserEnabled »: false, « creationDate »: « 2020-01-30T10:12:36.101431+00:00 », « id »: « /subscriptions/eaeaae83-9dcd-405b-8f02-4e58e0e30bbb/resourceGroups/myResourceGroup/providers/Microsoft.ContainerRegistry/registries /myACR35 », « location »: « eastus », « loginServer »: « myacr35.azurecr.io », « name »: « myACR35 », « networkRuleSet »: null, « policies »: { « quarantinePolicy »: { « status »: « disabled » }, « retentionPolicy »: { « days »: 7, « lastUpdatedTime »: « 2020-01-30T10:12:37.145663+00:00 », « status »: « disabled » }, « trustPolicy »: { « status »: « disabled », « type »: « Notary » } }, « provisioningState »: « Succeeded », « resourceGroup »: « myResourceGroup », « sku »: { « name »: « Basic », « tier »: « Basic » }, « status »: null, « storageAccount »: null, « tags »: {}, « type »: « Microsoft.ContainerRegistry/registries » } L’ACR myACR35 étant créé on va s’y connecter : > az acr login –name myACR35 Uppercase characters are detected in the registry name. When using its server url in docker commands, to avoid authentication errors, use al l lowercase. Login Succeeded Le retour de cette commande nous indique qu’il serait préférable à l’avenir d’utiliser un  nom en minuscule. Balisage (tag) Pour utiliser l’image conteneur azure-vote-front avec ACR, on doit baliser cette image avec l’adresse du serveur de connexion de votre registre. Celle ci se trouve dans le retour json précedent : « loginServer »: « myacr35.azurecr.io » Si vous ne l’avez plus, vous pouvez l’obtenir avec la commande suivante : az acr list –resource-group myResourceGroup –query « [].{acrLoginServer:loginServer} » –output table À présent, étiquetez votre image azure-vote-front locale avec l’adresse myacr35.azurecr.io (en minuscule) du registre de conteneurs. Pour indiquer la version de l’image, ajoutez :v1 à la fin du nom de l’image :  docker tag azure-vote-front myacr35.azurecr.io/azure-vote-front:v1 PS D:\Kubernetes\AKSText2\azure-voting-app-redis> docker images REPOSITORY TAG IMAGE ID CREATED SIZE azure-vote-front latest df60d4cc1f96 About an hour ago 965MB myacr35.azurecr.io/azure-vote-front v1 df60d4cc1f96 About an hour ago 965MB On remarque alors qu’une nouvelle image est présente dans la liste (docker image) celle ci étant balisé sur notre serveur distant. Envoyer l’image docker push myacr35.azurecr.io/azure-vote-front:v1 On envoit notre image via la commande docker push. Cela peut prendre qq minutes suivant la taille de celle ci. Quand celle ci sera uploadé, on ira vérifier avec cette commande qui liste les images de notre repo de conteneur distant : > az acr repository list –name myacr35 –output table Result —————- azure-vote-front Notre image est bien sur notre Azure Container Registery myACR35. 3 – Déployer un cluster az aks create –resource-group myResourceGroup –name myAKSCluster –node-count 2 –generate-ssh-keys –attach-acr myacr35 Cette commande permet la création d’un cluster de 2 nodes branché sur le registre ACR que l’on vient de créer. Vous devriez voir au bout de qq minutes un retour en JSON : { « aadProfile »: null, « addonProfiles »: null, « agentPoolProfiles »: [ { « availabilityZones »: null, « count »: 2, « enableAutoScaling »: null, « enableNodePublicIp »: null, « maxCount »: null, « maxPods »: 110, « minCount »: null, « name »: « nodepool1 », « nodeTaints »: null, « orchestratorVersion »: « 1.14.8 », « osDiskSizeGb »: 100, « osType »: « Linux », « provisioningState »: « Succeeded », « scaleSetEvictionPolicy »: null, « scaleSetPriority »: null, « type »:…

Tuto AKS – mise en place

AKS, Architecture, Azure, Non classéLaisser un commentaire

Dans cet article nous allons mettre en place AKS sur Azure en ligne de commande. AKS en ligne de commande : https://docs.microsoft.com/fr-fr/azure/aks/kubernetes-walkthrough Prérequis : avoir installer deux VMs sur azure (voir le tuto précédent) En avant Guingamp : az aks create –resource-group TutorialResources –name myAKSCluster –node-count 1 –enable-addons monitoring –generate-ssh-keys Cette commande va créer AKS sur un cluster nommé myAKSCluster avec une seule node et du monitoring. Ca prends qq minutes… La commande va normalement vous renvoyer du JSON avec toute la config installée : Json { « aadProfile »: null, « addonProfiles »: { « omsagent »: { « config »: { « logAnalyticsWorkspaceResourceID »: « /subscriptions/eaeaae83-9dcd-405b-8f02-4e58e0e30bbb/resourcegroups/defaultresourcegroup-eus/providers/microsoft.operationalinsights/workspaces/defaultworkspace-eaeaae83-9dcd-405b-8f02-4e58e0e30bbb-eus » }, « enabled »: true } }, « agentPoolProfiles »: [ { « availabilityZones »: null, « count »: 1, « enableAutoScaling »: null, « enableNodePublicIp »: null, « maxCount »: null, « maxPods »: 110, « minCount »: null, « name »: « nodepool1 », « nodeTaints »: null, « orchestratorVersion »: « 1.14.8 », « osDiskSizeGb »: 100, « osType »: « Linux », « provisioningState »: « Succeeded », « scaleSetEvictionPolicy »: null, « scaleSetPriority »: null, « type »: « VirtualMachineScaleSets », « vmSize »: « Standard_DS2_v2 », « vnetSubnetId »: null } ], « apiServerAccessProfile »: null, « dnsPrefix »: « myAKSClust-TutorialResource-eaeaae », « enablePodSecurityPolicy »: null, « enableRbac »: true, « fqdn »: « myaksclust-tutorialresource-eaeaae-955218b3.hcp.eastus.azmk8s.io », « id »: « /subscriptions/eaeaae83-9dcd-405b-8f02-4e58e0e30bbb/resourcegroups/TutorialResources/providers/Microsoft.ContainerService/managedClusters/myAKSCluster », « identity »: null, « kubernetesVersion »: « 1.14.8 », « linuxProfile »: { « adminUsername »: « azureuser », « ssh »: { « publicKeys »: [ { « keyData »: « ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCxi46MPyNjpH/kBnXxU5t4bPcWpeCrByvAH9p6uzM+IDda+NTrWHpEmUr1IVZS7CXku5lpl6v3WJjuK1E35DdB5s2ewB7VR6iYKHgruqduAeprMdUx34xeXxn7cc9/QC1b83Lw7k+oyYYYoIfYcy9q/beIlBco8Eidj6GxNRk74fHd3H5r99W0pqA4IfIFpksOb19iiO+pgiABgewmAQETldclajNjVuV6G3cVDdFILGUXjSA/Z1d1eWoqh00XbtyY7sl3LkLd6puHTm1Qt5UlcD4mZKpI2ggqWicHVLA2Eq2Fz7GE637CdYsqXXs5eDJUeBA8S+d2fas00zMB4Pyb » } ] } }, « location »: « eastus », « maxAgentPools »: 8, « name »: « myAKSCluster », « networkProfile »: { « dnsServiceIp »: « 10.0.0.10 », « dockerBridgeCidr »: « 172.17.0.1/16 », « loadBalancerProfile »: { « effectiveOutboundIps »: [ { « id »: « /subscriptions/eaeaae83-9dcd-405b-8f02-4e58e0e30bbb/resourceGroups/MC_TutorialResources_myAKSCluster_eastus/providers/Microsoft.Network/publicIPAddresses/449f34d6-68cb-49ad-aa08-825d6448e1d7 », « resourceGroup »: « MC_TutorialResources_myAKSCluster_eastus » } ], « managedOutboundIps »: { « count »: 1 }, « outboundIpPrefixes »: null, « outboundIps »: null }, « loadBalancerSku »: « Standard », « networkPlugin »: « kubenet », « networkPolicy »: null, « outboundType »: « loadBalancer », « podCidr »: « 10.244.0.0/16 », « serviceCidr »: « 10.0.0.0/16 » }, « nodeResourceGroup »: « MC_TutorialResources_myAKSCluster_eastus », « privateFqdn »: null, « provisioningState »: « Succeeded », « resourceGroup »: « TutorialResources », « servicePrincipalProfile »: { « clientId »: « f00bf5fa-37b4-42e5-9f2f-33ff3f32c672 », « secret »: null }, « tags »: null, « type »: « Microsoft.ContainerService/ManagedClusters », « windowsProfile »: null } AKS est maintenant installé dans le groupe de ressource « TutorialResources » Lors de la création d’un cluster AKS, un deuxième groupe de ressources est automatiquement créé pour stocker les ressources AKS. Pour ma part il s’appelle DefaultResourceGroup-EUS. Dedans on y trouve ceci : Le premier est un « espace de travail Log Analytics ». Le second est une « solution ».  Pour le moment je ne sais pas trop a quoi correspond ce dernier. Enfin, l’installation d’AKS a généré un troisieme groupe de ressources avec 5 éléments : Dans l’ordre affiché nous avons un équilibreur de charge un groupe de sécurité réseau une adresse IP publique une table de routage un réseau virtuel. Voilà, beaucoup d’élément on été automatiquement installé. C’est une configuration par défaut qu’il faudra bien sûr ajuster aux besoins.  Pour la suite on va avoir besoin de kubectl qui est le client de ligne de commande Kubernetes. Si vous avez DockerDesktop avec la case Kubernetes cochée, vous devriez déjà l’avoir. Sinon vous pouvez toujours l’obtenir avec cette commande : az aks install-cli Pour se connecter à notre cluster aks via kubectl : az aks get-credentials –resource-group TutorialResources –name myAKSCluster   réponse : Merged « myAKSCluster » as current context in C:\Users\Yann\.kube\config   Pour voir les nodes : kubectl get nodes On y est, Kubernetes est installé sur notre cluster et tourne avec une seule node. 

Azure CLI – tuto 2 VMs

AKS, Architecture, Azure, Non classé

Tuto pour apprendre avec Azure CLI à monter des VMs et ensuite utiliser AKS (prochain tuto). Prérequis : avoir un compte Azure (il en existe des gratuits avec 170€ de crédits) et Azure Cli installé sur sa machine. Azure cli : https://docs.microsoft.com/fr-fr/cli/azure/get-started-with-azure-cli?view=azure-cli-latest Création d’une VM 1 Pour tester azure cli, on va lui demander sa version az –version azure-cli 2.0.80 (…) On va maintenant se connecter sur Azure via cette commande az login Cela ouvre un browser pour se connecter au portail web. Après connextion, le terminal affiche les abonnements Azure Nous allons créer un groupe de ressources : az group create –name TutorialResources –location eastus Il n’est pas apparu sur le portail web d’Azure. Sans doute car je n’avais aucune ressources dedans pour le moment. Nous allons maintenant créer notre première Virtual Machine en ligne de commande : az vm create –resource-group TutorialResources ` –name TutorialVM1 ` –image UbuntuLTS ` –generate-ssh-keys ` –output json ` –admin-username yannvasseur ` –verbose Note : sous powershell une commande multi ligne se termine par ` (en bash c’est \ ) j’ai dû rajouter –admin-username yannvasseur ` à cette commande car on avait une erreur sinon. Il faut qq minutes pour créer une VM, voici ce que la commande nous retourne : { « fqdns »: «  », « id »: « /subscriptions/eaeaae83-9dcd-405b-8f02-4e58e0e30bbb/resourceGroups/TutorialResources/providers/Microsoft.Compute/virtualMachines/TutorialVM1 », « location »: « eastus », « macAddress »: « 00-0D-3A-8D-7D-07 », « powerState »: « VM running », « privateIpAddress »: « 10.0.0.4 », « publicIpAddress »: « 13.90.91.229 », « resourceGroup »: « TutorialResources », « zones »: «  » } Pour obtenir plus d’information sur cette VM : az vm show –name TutorialVM1 –resource-group TutorialResources Le listing que vous obtenez est plutot long, mais d’autant plus complet. Remarquez que l’on a pas de password pour l’administrateur. Json results : Si on se connecte sur le portail web Azure, on voit tout ce qui a été créé : Dans l’ordre affiché on a une machine virtuelle Standard DS1 v2 (1 processeurs virtuels, 3.5 Gio de mémoire) sous Linux (ubuntu 18.04), un disque de 30Go SSD premium, un groupe de sécurité réseau (un firewall), une adresse IP publique (13.90.91.229), une interface réseau et un réseau privé virtuel (10.0.0.0/16). L’emplacement est USA est. Tout ca en une ligne de commande ! VM2 On va maintenant en créer une deuxieme parce qu’on est foufou. Mais avant cela on va récupérer des infos sur notre premiere VM concernant notre subnet (sous réseau) afin que nos deux VMs soient sur le même réseau : az vm show –name TutorialVM1 ` –resource-group TutorialResources ` –query ‘networkProfile.networkInterfaces[].id’ ` –output tsv Résultat : /subscriptions/eaeaae83-9dcd-405b-8f02-4e58e0e30bbb/resourceGroups/TutorialResources/providers/Microsoft.Network/networkInterfaces/TutorialVM1VMNic Cette commande nous permet d’obtenir l’id de notre interface réseau VM1. A partir de cet id, on va demander a azure toutes les informations de cette interface réseau : az network nic show –ids /subscriptions/eaeaae83-9dcd-405b-8f02-4e58e0e30bbb/resourceGroups/TutorialResources/providers/Microsoft.Network/networkInterfaces/TutorialVM1VMNic info interface réseau On va devoir récupérer l’id de l’IP (et pour plus tard on aura peut etre besoin de l’id du sous réseau) az network nic show –ids /subscriptions/eaeaae83-9dcd-405b-8f02-4e58e0e30bbb/resourceGroups/TutorialResources/providers/Microsoft.Network/networkInterfaces/TutorialVM1VMNic ` –query ‘{IP:ipConfigurations[].publicIpAddress.id, Subnet:ipConfigurations[].subnet.id}’ ` -o json Voici le résultat, sous forme de donnée JSON : { « IP »: [ « /subscriptions/eaeaae83-9dcd-405b-8f02-4e58e0e30bbb/resourceGroups/TutorialResources/providers/Microsoft.Network/publicIPAddresses/TutorialVM1PublicIP » ], « Subnet »: [ « /subscriptions/eaeaae83-9dcd-405b-8f02-4e58e0e30bbb/resourceGroups/TutorialResources/providers/Microsoft.Network/virtualNetworks/TutorialVM1VNET/subnets/TutorialVM1Subnet » ] } Maintenant on va créer une deuxième VM avec cette commande az vm create –resource-group TutorialResources ` –name TutorialVM2 ` –image UbuntuLTS ` –generate-ssh-keys ` –subnet /subscriptions/eaeaae83-9dcd-405b-8f02-4e58e0e30bbb/resourceGroups/TutorialResources/providers/Microsoft.Network/virtualNetworks/TutorialVM1VNET/subnets/TutorialVM1Subnet ` –admin-username yannvasseur ` –output json ` –verbose Notez que l’on juste rajouté un sous réseau et renommer son nom. Voici le résultat : Use existing SSH public key file: C:\\Users\\Yann\\.ssh\\id_rsa.pub Accepted: vm_deploy_Ud4Y1LjR5olzzHxJhIQ1kNiWStjJCeBn (Microsoft.Resources/deployments) { « fqdns »: «  », « id »: « /subscriptions/eaeaae83-9dcd-405b-8f02-4e58e0e30bbb/resourceGroups/TutorialResources/providers/Microsoft.Compute/virtualMachines/TutorialVM2 », « location »: « eastus », « macAddress »: « 00-0D-3A-18-E6-A5 », « powerState »: « VM running », « privateIpAddress »: « 10.0.0.5 », « publicIpAddress »: « 40.117.142.145 », « resourceGroup »: « TutorialResources », « zones »: «  » } command ran in 103.297 seconds. Et voila notre 2ime VM est créée. Ce qui est vérifié sur le portail web : Nettoyage Si vou souhaitez tout effacer, c’est par ici : https://docs.microsoft.com/fr-fr/cli/azure/azure-cli-vm-tutorial?tutorial-step=7&view=azure-cli-latest

Kubernetes & AKS – Intro

AKS, Architecture, Azure, Docker, Kubernetes, Non classé

Intro Kubernetes (communément appelé « K8S ») est un système open source qui vise à fournir une « plate-forme permettant d’automatiser le déploiement, la montée en charge et la mise en œuvre de conteneurs d’application sur des clusters de serveurs ». Il fonctionne avec toute une série de technologies de conteneurisation, et est souvent utilisé avec Docker. Il a été conçu à l’origine par Google, puis offert à la Cloud Native Computing Foundation. (Wikipedia) AKS (Azure Kubernete Service) est un service Kubernetes sur Azure. Il permet d’automatiser le déploiement, la mise à l’échelle et le fonctionnement de conteneurs d’application entre des clusters d’hôtes. C’est un orchestrateur de conteneur. Cela signifie qu’il est en charge de monter des conteneurs suivant un plan que l’on fixe. Il peut par exemple automatiser la charge (monter des conteneurs supplémentaire), relancer un conteneur défaillant, prévoir une réduction ou une augmentation de charge (planification) et donc adapter des besoins suivant des critères (horraire, ponctuel, exceptionnel, CPU, Bandwidth…) https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/ L’image ci dessous permet d’illustrer ce qu’est un cluster de conteneurs : Un cluster Kubernetes regroupe plusieurs hôtes Docker et les expose sous la forme d’un seul hôte Docker virtuel. Vous pouvez donc déployer plusieurs conteneurs sur le cluster et effectuer un scale-out d’un nombre illimité d’instances de conteneurs. Le cluster prend en charge tous les détails complexes de la gestion, comme la scalabilité, l’intégrité,etc. Structure et topologie Kubernetes dispose d’une structure basée sur un Master Node et des Nodes. Le Master Node contrôle les nodes. Ces dernières sont des machines virtuelles ou physique. Sur une node on peut retrouver un ou des Pods. Un namespace permet de segmenter des pods, volumes, secrets, configmap… On peut avoir deux namespaces (par exemple dev et staging) sur le même cluster. (là où d’habitude on travaillait avec des machines séparées sur une app monolithique) kubectl est l’application en ligne de commande permettant d’interragir avec Kubernetes. Il est possible d’utiliser Kubernetes sur votre machine locale avec Docker Desktop en cochant cet option : Il est donc possible de travailler localement et préparer ses fichier yaml pour AKS (dev, staging, prod) Pour cela il faut aussi préparer nos conteneurs et les déposer sur un registre (Docker Registry sur Azure) afin qu’ils puissent être utilisé par AKS. Ressources pour se former : Podcast Devapps.be Introduction à Kubernetes : https://www.youtube.com/watch?v=b5vJsYR-Vbo La doc microsoft : https://docs.microsoft.com/fr-fr/azure/aks/ Comprendre Kubernetes en 3 minutes : https://www.youtube.com/watch?v=uyiDNcSmwFw (perso j’ai rien compris…) Celle la est mieux https://www.youtube.com/watch?v=QJ4fODH6DXI xavki : https://www.youtube.com/watch?v=vFfngcRPj9M Web2Day 2017 : https://www.youtube.com/watch?v=zztKO0iRX_w&t=175s