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 :
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 !
