J'ai mis à jour l'un de mes sites Web d'ASP.NET Core 2.2 vers la dernière version LTS (Long Term Support) d'ASP.NET Core 3.1 cette semaine. Maintenant, je veux faire la même chose avec mon site de podcast ET le déplacer vers Linux en même temps. Azure App Service pour Linux a de très bons prix et m'a permis de passer à un plan Premium v2 de Standard qui me donne le double de la mémoire à 35 % de réduction.
Mon podcast a toujours été exécuté sur ASP.NET Core sur Azure App Service pour Windows. Comment savoir s'il fonctionnera sous Linux ? Bon je vais essayer tu verras !
J'utilise WSL (Windows Subsystem for Linux) et vous devriez en faire autant. Il est très probable que vous ayez WSL prêt à fonctionner sur votre machine et que vous ne l'ayez tout simplement pas activé. Combinez WSL (ou le nouveau WSL2) avec le terminal Windows et vous êtes dans un bel endroit sur Windows avec la possibilité de développer n'importe quoi pour n'importe où.
Voyons d'abord si je peux exécuter mon site de podcast ASP.NET Core existant (maintenant mis à jour vers .NET Core 3.1) sous Linux. Je vais démarrer Ubuntu 18.04 sous Windows et exécuter dotnet --version pour voir si quelque chose est déjà installé. Vous n'avez peut-être rien. J'ai 3.0 il me semble :
$ dotnet --version
3.0.100
Ok, je veux installer .NET Core 3.1 sur l'instance Ubuntu de WSL. N'oubliez pas que ce n'est pas parce que .NET 3.1 est installé dans Windows qu'il est installé dans mes instances Linux/WSL. Je dois les entretenir moi-même. Une autre façon d'y penser est que j'ai l'installation win-x64 de .NET 3.1 et maintenant j'ai besoin de l'installation linux-x64.
- REMARQUE : C'est vrai que je pourrais "
dotnet publish -r linux-x64" puis scp les fichiers publiés complets résultants vers Linux/WSL. Cela dépend de la manière dont je souhaite répartir les responsabilités. Est-ce que je veux construire sur Windows et exécuter sur Linux/Linux ? Ou est-ce que je veux construire et exécuter à partir de Linux. Les deux sont valables, cela dépend simplement de vos choix, de votre patience et de votre familiarité. - GOTCHA : De plus, si vous accédez à des fichiers Windows sur /mnt/c sous WSL qui ont été clonés par git à partir de Windows, sachez qu'il existe des subtilités si Git pour Windows et Git pour Ubuntu accèdent à l'index/aux fichiers en même temps. Il est plus simple, plus sûr et plus rapide de cloner simplement une autre copie dans le système de fichiers WSL/Linux.
Je vais me diriger vers https://dotnet.microsoft.com/download et obtenir .NET Core 3.1 pour Ubuntu. Si vous utilisez apt, et je suppose que vous le faites, il y a une configuration préliminaire et ensuite c'est simple
sudo apt-get install dotnet-sdk-3.1
Pas de transpiration. Soit "dotnet build " et espérons le meilleur !
Cela peut être surprenant, mais si vous ne faites rien de délicat ou de spécifique à Windows, votre application .NET Core devrait simplement créer la même chose sur Windows que sur Linux. Si vous faites quelque chose d'intéressant ou spécifique au système d'exploitation, vous pouvez #ifdef votre chemin vers la gloire si vous insistez.
Des points bonus si vous avez des tests unitaires - et j'en ai - alors je vais ensuite exécuter mes tests unitaires et voir comment ça se passe.
OPTION : J'écris des choses comme build.ps1 et test.ps1 qui utilisent PowerShell car PowerShell est déjà sur Windows. Ensuite, j'installe PowerShell (juste pour le script, pas le shell) sur Linux afin de pouvoir utiliser mes scripts .ps1 partout. Les mêmes test.ps1 et build.ps1 et dockertest.ps1, etc. fonctionnent sur toutes les plates-formes. Assurez-vous d'avoir un shebang
#!/usr/bin/pwshen haut de vos fichiers ps1 pour que vous puissiez simplement les exécuter (chmod +x) sous Linux.
Je lance test.ps1 qui exécute cette commande
dotnet test /p:CollectCoverage=true /p:CoverletOutputFormat=lcov /p:CoverletOutput=./lcov .\hanselminutes.core.tests
avec couvre-lit pour la couverture du code et... ça marche ! Encore une fois, cela peut être surprenant, mais si vous n'avez pas de chemins codés en dur, faites des hypothèses sur l'existence d'un lecteur C:\ et évitez le registre et d'autres éléments spécifiques à Windows, les choses fonctionnent.
Test Run Successful.
Total tests: 23
Passed: 23
Total time: 9.6340 Seconds
Calculating coverage result...
Generating report './lcov.info'
+--------------------------+--------+--------+--------+
| Module | Line | Branch | Method |
+--------------------------+--------+--------+--------+
| hanselminutes.core.Views | 60.71% | 59.03% | 41.17% |
+--------------------------+--------+--------+--------+
| hanselminutes.core | 82.51% | 81.61% | 85.39% |
+--------------------------+--------+--------+--------+
Je peux construire, je peux tester, mais puis-je l'exécuter ? Qu'en est-il de l'exécution et des tests dans des conteneurs ?
J'exécute WSL2 sur mon système et j'ai fait tout cela dans Ubuntu 18.04 ET j'exécute Docker WSL Tech Preview. Pourquoi ne pas voir si je peux également exécuter mes tests sous Docker ? À partir de Docker pour Windows, j'activerai la prise en charge expérimentale de WSL2, puis dans le menu Ressources, Intégration WSL, j'activerai Docker dans mon instance Ubuntu 18.04 (vos instances et leurs noms vous appartiendront).
Je peux confirmer que cela fonctionne avec "docker info" sous WSL et parle à une instance de travail. Je devrais pouvoir exécuter "docker info" dans Windows ET WSL.
$ docker info
Client:
Debug Mode: false
Server:
Containers: 18
Running: 18
Paused: 0
Stopped: 0
Images: 31
Server Version: 19.03.5
Storage Driver: overlay2
Backing Filesystem: extfs
...snip...
Cool. Je me suis souvenu que je devais également mettre à jour mon Dockerfile du SDK 2.2 sur le hub Docker vers le SDK 3.1 de Microsoft Container Registry, donc ce changement de ligne :
#FROM microsoft/dotnet:2.2-sdk AS build
FROM mcr.microsoft.com/dotnet/core/sdk:3.1 as build
ainsi que la version d'exécution finale de l'application plus tard dans le Dockerfile. Assurez-vous essentiellement que votre Dockerfile utilise les bonnes versions.
#FROM microsoft/dotnet:2.1-aspnetcore-runtime AS runtime
FROM mcr.microsoft.com/dotnet/core/aspnet:3.1 AS runtime
Je monte également en volume les résultats des tests, il y a donc cette instruction If offensante dans le test.ps1. OUI, je sais que je devrais juste faire tous les chemins avec / et les rendre relatifs.
#!/usr/bin/pwsh
docker build --pull --target testrunner -t podcast:test .
if ($IsWindows)
{
docker run --rm -v d:\github\hanselminutes-core\TestResults:/app/hanselminutes.core.tests/TestResults podcast:test
}
else
{
docker run --rm -v ~/hanselminutes-core/TestResults:/app/hanselminutes.core.tests/TestResults podcast:test
}
Peu importe, ça marche et ça marche à merveille. Maintenant, j'ai des tests en cours d'exécution sous Windows et Linux et dans Docker (dans un conteneur Linux) géré par WSL2. Tout fonctionne partout. Maintenant qu'il fonctionne bien sur WSL, je sais qu'il fonctionnera très bien dans Azure sur Linux.
Passage d'Azure App Service sur Windows vers Linux
C'était assez simple aussi.
Je vais bloguer en détail sur la façon dont je crée et déploie les sites dans Azure DevOps et comment je suis passé de .NET 2.2 avec des pipelines DevOps classiques "Wizard Built" à un .NET Core 3.1 et un pipeline YAML archivé de contrôle de source ensuite semaine.
La version courte est de créer un plan de service d'application Linux (rappelez-vous qu'un "plan de service d'application" est une machine virtuelle dont vous ne vous inquiétez pas. Voyez dans le choix ci-dessous que le plan Linux a une icône de pingouin. Rappelez-vous également que vous pouvez avoir autant d'applications dans votre plan que vous le souhaitez (et tenir dans la mémoire et les ressources).Lorsque vous sélectionnez une "pile" pour votre application dans Azure App Service pour Linux, vous sélectionnez effectivement une image Docker gérée par Azure. vous.
J'ai commencé par déployer sur staging.mydomain.com et l'essayer. Vous pouvez utiliser Azure Front Door ou CloudFlare pour gérer le trafic, puis échanger le DNS. J'ai testé sur Staging pendant un certain temps, puis j'ai juste changé le DNS directement. J'ai attendu quelques heures que le trafic s'écoule du site de podcast Windows, puis je l'ai arrêté. Après un jour ou deux sans trafic, je l'ai supprimé. Si j'ai bien fait mon travail, aucun d'entre vous n'a remarqué que le site est passé de Windows à Linux, de .NET Core 2.2 à .NET Core 3.1. Il devrait être aussi rapide ou plus rapide sans temps d'arrêt.
Voici un aperçu de mon portail Azure. À ce jour, j'ai déplacé ma page d'accueil, mon portail de gestion de la glycémie et mon site de podcast sur un seul plan de service d'application Linux. Chacun est hébergé sur GitHub et chacun se déploie automatiquement avec Azure DevOps.
La prochaine grande migration vers le cloud sera ce blog qui exécute toujours .NET Framework 4.x. Je vais bloguer sur la façon dont le podcast est enregistré dans GitHub puis déployé avec Azure DevOps la semaine prochaine.
Quelles migrations intéressantes avez-VOUS faites récemment, cher lecteur ?
Parrain :Vous aimez C# ? Nous aussi ! C'est pourquoi nous avons développé un IDE .NET rapide, intelligent et multiplateforme qui vous donne encore plus de puissance de codage. Analyse de code intelligente, complétion de code enrichie, recherche et navigation instantanées, débogueur avancé... Avec JetBrains Rider, tout ce dont vous avez besoin est à portée de main. Codez C# à la vitesse de la pensée sur Linux, Mac ou Windows. Essayez JetBrains Rider dès aujourd'hui !