Esta semana actualicé uno de mis sitios web de ASP.NET Core 2.2 a la última versión LTS (Soporte a largo plazo) de ASP.NET Core 3.1. Ahora quiero hacer lo mismo con mi sitio de podcasts Y moverlo a Linux al mismo tiempo. Azure App Service para Linux tiene muy buenos precios y me permitió pasar a un plan Premium v2 de Standard, que me da el doble de memoria con un 35 % de descuento.
Históricamente, mi podcast se ha ejecutado en ASP.NET Core en Azure App Service para Windows. ¿Cómo sé si se ejecutará en Linux? Bueno, lo intentaré a ver!
Yo uso WSL (Subsistema de Windows para Linux) y tú también deberías hacerlo. Es muy probable que tenga WSL listo para funcionar en su máquina y simplemente no lo haya activado. Combine WSL (o el nuevo WSL2) con Windows Terminal y estará en un lugar encantador en Windows con la capacidad de desarrollar cualquier cosa para cualquier lugar.
Primero, veamos si puedo ejecutar mi sitio de podcast ASP.NET Core existente (ahora actualizado a .NET Core 3.1) en Linux. Iniciaré Ubuntu 18.04 en Windows y ejecutaré dotnet --version para ver si ya tengo algo instalado. Puede que no tengas nada. Tengo 3.0 parece:
$ dotnet --version
3.0.100
Ok, querré instalar .NET Core 3.1 en la instancia de Ubuntu de WSL. Recuerde, el hecho de que tenga .NET 3.1 instalado en Windows no significa que esté instalado en mis instancias de Linux/WSL. Necesito mantenerlos por mi cuenta. Otra forma de verlo es que tengo la instalación win-x64 de .NET 3.1 y ahora necesito la de linux-x64.
- NOTA: Es cierto que podría "
dotnet publish -r linux-x64" y luego transfiera los archivos publicados completos resultantes a Linux/WSL. Depende de cómo quiera dividir la responsabilidad. ¿Quiero compilar en Windows y ejecutar en Linux/Linux? O quiero compilar y ejecutar desde Linux. Ambos son válidos, solo depende de sus elecciones, paciencia y familiaridad. - ENTENDIDO: Además, si está accediendo a archivos de Windows en /mnt/c bajo WSL que fueron clonados por git desde Windows, tenga en cuenta que existen sutilezas si Git para Windows y Git para Ubuntu están accediendo al índice/archivos al mismo tiempo. Es más fácil, seguro y rápido clonar otra copia dentro del sistema de archivos WSL/Linux.
Me dirigiré a https://dotnet.microsoft.com/download y obtendré .NET Core 3.1 para Ubuntu. Si usa apt, y supongo que lo hace, hay una configuración preliminar y luego es simple
sudo apt-get install dotnet-sdk-3.1
Sin sudar. Vamos a "dotnet build " y espero lo mejor!
Puede ser sorprendente, pero si no está haciendo nada complicado o específico de Windows, su aplicación .NET Core debería compilar lo mismo en Windows que en Linux. Si ESTÁ haciendo algo interesante o específico del sistema operativo, puede #ifdef su camino a la gloria si insiste.
Puntos de bonificación si tiene pruebas unitarias, y yo las tengo, así que a continuación ejecutaré mis pruebas unitarias y veré cómo va.
OPCIÓN: Escribo cosas como build.ps1 y test.ps1 que usan PowerShell, ya que PowerShell ya está en Windows. Luego instalo PowerShell (solo para las secuencias de comandos, no para el shelling) en Linux para poder usar mis secuencias de comandos .ps1 en todas partes. El mismo test.ps1 y build.ps1 y dockertest.ps1, etc. simplemente funciona en todas las plataformas. Asegúrate de tener un shebang #!/usr/bin/pwsh en la parte superior de sus archivos ps1 para que pueda ejecutarlos (chmod +x ) en Linux.
Ejecuto test.ps1 que ejecuta este comando
dotnet test /p:CollectCoverage=true /p:CoverletOutputFormat=lcov /p:CoverletOutput=./lcov .\hanselminutes.core.tests
con cobertor para cobertor de código y... ¡funciona! Nuevamente, esto puede ser sorprendente, pero si no tiene ninguna ruta codificada, suponga que existe una unidad C:\ y evite el registro y otras cosas específicas de Windows, las cosas funcionan.
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% |
+--------------------------+--------+--------+--------+
Puedo construir, puedo probar, pero ¿puedo ejecutarlo? ¿Qué pasa con la ejecución y las pruebas en contenedores?
Estoy ejecutando WSL2 en mi sistema y estoy haciendo todo esto en Ubuntu 18.04 Y estoy ejecutando Docker WSL Tech Preview. ¿Por qué no ver si también puedo ejecutar mis pruebas en Docker? Desde Docker para Windows habilitaré la compatibilidad con WSL2 experimental y luego desde el menú Recursos, Integración WSL habilitaré Docker dentro de mi instancia de Ubuntu 18.04 (sus instancias y sus nombres serán los suyos).
Puedo confirmar que está funcionando con "información de la ventana acoplable" en WSL y hablando con una instancia de trabajo. Debería poder ejecutar "docker info" en AMBOS Windows Y 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...
Enfriar. Recordé que también necesitaba actualizar mi Dockerfile desde el SDK 2.2 en Docker Hub al SDK 3.1 de Microsoft Container Registry, por lo que esta línea cambia:
#FROM microsoft/dotnet:2.2-sdk AS build
FROM mcr.microsoft.com/dotnet/core/sdk:3.1 as build
así como la versión de tiempo de ejecución final para la aplicación más adelante en el Dockerfile. Básicamente, asegúrese de que su Dockerfile use las versiones correctas.
#FROM microsoft/dotnet:2.1-aspnetcore-runtime AS runtime
FROM mcr.microsoft.com/dotnet/core/aspnet:3.1 AS runtime
También realizo el volumen de los resultados de las pruebas, por lo que hay esta instrucción If ofensiva en test.ps1. SÍ, sé que debería hacer todas las rutas con / y hacerlas relativas.
#!/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
}
De todos modos, funciona y funciona maravillosamente. Ahora tengo pruebas ejecutándose en Windows y Linux y en Docker (en un contenedor de Linux) administrado por WSL2. Todo funciona en todas partes. Ahora que funciona bien en WSL, sé que funcionará muy bien en Azure en Linux.
Pasar de Azure App Service en Windows a Linux
Esto también fue bastante simple.
Publicaré en un blog en detalle cómo construyo y uso los sitios en Azure DevOps y cómo pasé de .NET 2.2 con las canalizaciones clásicas de DevOps "Wizard Built" a .NET Core 3.1 y una canalización YAML registrada con control de fuente a continuación. semana.
La versión corta es hacer un Plan de servicio de aplicaciones de Linux (recuerde que un "Plan de servicio de aplicaciones" es una máquina virtual de la que no se preocupa. Vea en la selección a continuación que el Plan de Linux tiene un icono de pingüino. También recuerde que puede tenga tantas aplicaciones dentro de su plan como desee (y caben en la memoria y los recursos). Cuando selecciona una "Pila" para su aplicación dentro de Azure App Service para Linux, está seleccionando efectivamente una imagen de Docker que Azure administra para tú.
Comencé implementando en staging.mydomain.com y probándolo. Puede usar Azure Front Door o CloudFlare para administrar el tráfico y luego intercambiar el DNS. Probé en Staging por un tiempo, luego cambié el DNS directamente. Esperé unas horas a que el tráfico se drenara del sitio de podcasts de Windows y luego lo detuve. Después de un día o dos sin tráfico, lo eliminé. Si hice bien mi trabajo, ninguno de ustedes notó que el sitio se movió de Windows a Linux, de .NET Core 2.2 a .NET Core 3.1. Debería ser tan rápido o más rápido sin tiempo de inactividad.
Aquí hay una instantánea de mi Azure Portal. A partir de hoy, he movido mi página de inicio, mi portal de administración de azúcar en la sangre y mi sitio de podcasts a un único plan de servicio de aplicaciones de Linux. Cada uno está alojado en GitHub y cada uno se implementa automáticamente con Azure DevOps.
La próxima gran migración a la nube será este blog que aún ejecuta .NET Framework 4.x. Publicaré en un blog cómo se registra el podcast en GitHub y luego se implementa con Azure DevOps la próxima semana.
¿Qué migraciones geniales has hecho TÚ últimamente, querido lector?
Patrocinador :¿Como C#? ¡Nosotros también! Es por eso que hemos desarrollado un IDE .NET rápido, inteligente y multiplataforma que le brinda aún más poder de codificación. Análisis de código inteligente, finalización de código enriquecido, búsqueda y navegación instantáneas, un depurador avanzado... Con JetBrains Rider, todo lo que necesita está al alcance de su mano. Codifique C# a la velocidad del pensamiento en Linux, Mac o Windows. ¡Pruebe JetBrains Rider hoy mismo!