Questa settimana ho aggiornato uno dei miei siti Web da ASP.NET Core 2.2 all'ultima versione LTS (Long Term Support) di ASP.NET Core 3.1. Ora voglio fare lo stesso con il mio sito di podcast E spostarlo su Linux allo stesso tempo. Servizio app di Azure per Linux ha dei prezzi molto convenienti e mi ha permesso di passare a un piano Premium v2 da Standard che mi offre il doppio della memoria con uno sconto del 35%.
Il mio podcast è stato storicamente eseguito su ASP.NET Core nel servizio app di Azure per Windows. Come faccio a sapere se funzionerà su Linux? Bene, ci proverò vedere!
Io uso WSL (sottosistema Windows per Linux) e anche tu dovresti. È molto probabile che tu abbia WSL pronto per l'uso sul tuo computer e che tu non l'abbia acceso. Combina WSL (o il nuovo WSL2) con Windows Terminal e sei in una posizione incantevole su Windows con la possibilità di sviluppare qualsiasi cosa per qualsiasi luogo.
Innanzitutto, vediamo se riesco a eseguire il mio sito di podcast ASP.NET Core esistente (ora aggiornato a .NET Core 3.1) su Linux. Avvierò Ubuntu 18.04 su Windows ed eseguirò dotnet --version per vedere se ho già installato qualcosa. Potresti non avere niente. Ho 3.0 sembra:
$ dotnet --version
3.0.100
Ok, vorrò installare .NET Core 3.1 sull'istanza Ubuntu di WSL. Ricorda, solo perché ho .NET 3.1 installato in Windows non significa che sia installato nelle mie istanze Linux/WSL. Devo mantenerli da solo. Un altro modo per pensarci è che ho l'installazione win-x64 di .NET 3.1 e ora ho bisogno di quella linux-x64.
- NOTA: È vero che potrei "
dotnet publish -r linux-x64" e quindi scp i file pubblicati completi risultanti su Linux/WSL. Dipende da come voglio dividere le responsabilità. Voglio compilare su Windows ed eseguire su Linux/Linux? Oppure voglio compilare ed eseguire da Linux. Entrambi sono validi, dipende solo dalle tue scelte, pazienza e familiarità. - GOTCHA: Inoltre, se stai accedendo a file Windows in /mnt/c in WSL che sono stati clonati da Windows, tieni presente che ci sono sottigliezze se Git per Windows e Git per Ubuntu accedono all'indice/ai file contemporaneamente. È più facile, più sicuro e più veloce semplicemente clonare un'altra copia all'interno del filesystem WSL/Linux.
Andrò su https://dotnet.microsoft.com/download e otterrò .NET Core 3.1 per Ubuntu. Se usi apt, e suppongo che tu lo faccia, c'è una configurazione preliminare e poi è un semplice
sudo apt-get install dotnet-sdk-3.1
Nessun sudore. Diciamo "dotnet build " e speriamo per il meglio!
Potrebbe essere sorprendente, ma se non stai facendo nulla di complicato o specifico di Windows, la tua app .NET Core dovrebbe semplicemente creare lo stesso su Windows come su Linux. Se stai facendo qualcosa di interessante o specifico per il sistema operativo, puoi #ifdef la tua strada verso la gloria se insisti.
Punti bonus se hai Unit Tests - e io li ho - quindi eseguirò i miei unit test e vedrò come va.
OPZIONE: Scrivo cose come build.ps1 e test.ps1 che usano PowerShell poiché PowerShell è già su Windows. Quindi installo PowerShell (solo per lo scripting, non per lo shelling) su Linux in modo da poter usare i miei script .ps1 ovunque. Lo stesso test.ps1 e build.ps1 e dockertest.ps1, ecc. Funzionano su tutte le piattaforme. Assicurati di avere uno shebang #!/usr/bin/pwsh nella parte superiore dei tuoi file ps1 in modo da poterli semplicemente eseguire (chmod +x ) su Linux.
Eseguo test.ps1 che esegue questo comando
dotnet test /p:CollectCoverage=true /p:CoverletOutputFormat=lcov /p:CoverletOutput=./lcov .\hanselminutes.core.tests
con coverlet per la copertura del codice e... funziona! Ancora una volta, questo potrebbe essere sorprendente, ma se non hai percorsi codificati, fai supposizioni sull'esistenza di un'unità C:\ ed evita il registro e altre cose specifiche di Windows, le cose funzionano.
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% |
+--------------------------+--------+--------+--------+
Posso costruire, posso testare, ma posso eseguirlo? Che dire dell'esecuzione e del test nei container?
Sto eseguendo WSL2 sul mio sistema e sto facendo tutto questo in Ubuntu 18.04 E sto eseguendo Docker WSL Tech Preview. Perché non vedere se posso eseguire i miei test anche in Docker? Da Docker per Windows abiliterò il supporto sperimentale WSL2 e poi dal menu Risorse, Integrazione WSL abiliterò Docker all'interno della mia istanza Ubuntu 18.04 (le tue istanze e i loro nomi saranno i tuoi).
Posso confermare che sta funzionando con "informazioni docker" in WSL e parlando con un'istanza funzionante. Dovrei essere in grado di eseguire "informazioni docker" in SIA Windows CHE 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...
Freddo. Mi sono ricordato che dovevo anche aggiornare il mio Dockerfile dall'SDK 2.2 sull'hub Docker all'SDK 3.1 da Microsoft Container Registry, quindi questa modifica di una riga:
#FROM microsoft/dotnet:2.2-sdk AS build
FROM mcr.microsoft.com/dotnet/core/sdk:3.1 as build
così come la versione di runtime finale per l'app più avanti nel Dockerfile. Fondamentalmente assicurati che il tuo Dockerfile utilizzi le versioni corrette.
#FROM microsoft/dotnet:2.1-aspnetcore-runtime AS runtime
FROM mcr.microsoft.com/dotnet/core/aspnet:3.1 AS runtime
Ho anche montato il volume dei risultati dei test, quindi c'è questa istruzione If offensiva nel test.ps1. SÌ, so che dovrei semplicemente fare tutti i percorsi con / e renderli relativi.
#!/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
}
In ogni caso, funziona e funziona meravigliosamente. Ora ho i test in esecuzione in Windows e Linux e in Docker (in un contenitore Linux) gestiti da WSL2. Tutto funziona ovunque. Ora che funziona bene su WSL, so che funzionerà benissimo in Azure su Linux.
Spostamento dal servizio app di Azure su Windows a Linux
Anche questo era piuttosto semplice.
Illustrerò in dettaglio come creo e distribuisco i siti in Azure DevOps e come sono passato da .NET 2.2 con le pipeline DevOps classiche "Wizard Built" a .NET Core 3.1 e una pipeline YAML archiviata nel controllo del codice sorgente. settimana.
La versione breve è creare un piano di servizio app Linux (ricorda che un "piano di servizio app" è una macchina virtuale di cui non ti preoccupi. Vedi nella selezione di seguito che il piano Linux ha un'icona a forma di pinguino. Ricorda inoltre che puoi avere tutte le app che desideri nel tuo piano (e si adatteranno alla memoria e alle risorse).Quando selezioni uno "Stack" per la tua app all'interno del Servizio app di Azure per Linux, stai effettivamente selezionando un'immagine Docker per la quale Azure gestisce tu.
Ho iniziato distribuendo su staging.mydomain.com e provandolo. È possibile usare Azure Front Door o CloudFlare per gestire il traffico e quindi scambiare il DNS. Ho testato su Staging per un po', quindi ho appena cambiato il DNS direttamente. Ho aspettato alcune ore che il traffico defluisse dal sito di podcast di Windows e poi l'ho interrotto. Dopo un giorno o due senza traffico l'ho cancellato. Se ho fatto bene il mio lavoro, nessuno di voi ha notato che il sito è stato spostato da Windows a Linux, da .NET Core 2.2 a .NET Core 3.1. Dovrebbe essere veloce o veloce senza tempi di inattività.
Ecco uno scatto del mio portale di Azure. Ad oggi, ho spostato la mia home page, il mio portale di gestione della glicemia e il mio sito di podcast in un unico piano di servizio app Linux. Ciascuno è ospitato su GitHub e ciascuno viene distribuito automaticamente con Azure DevOps.
La prossima grande migrazione al cloud sarà questo blog che esegue ancora .NET Framework 4.x. Scriverò sul blog come il podcast viene archiviato in GitHub e poi distribuito con Azure DevOps la prossima settimana.
Quali fantastiche migrazioni hai fatto ultimamente, caro lettore?
Sponsor :Come C#? Anche noi! Ecco perché abbiamo sviluppato un IDE .NET veloce, intelligente e multipiattaforma che ti offre ancora più potenza di codifica. Analisi del codice intelligente, completamento del codice completo, ricerca e navigazione istantanea, un debugger avanzato... Con JetBrains Rider, tutto ciò di cui hai bisogno è a portata di mano. Codifica C# alla velocità del pensiero su Linux, Mac o Windows. Prova JetBrains Rider oggi!