Si parla molto di Cloud ed in particolar modo di Containers, vediamo come pubblicare un’applicazione Blazor Server in un Container.

Se non avete ancora sviluppato un’applicazione Blazor Server potete scaricare l’App Blazing Google Maps dal repository EtabetaWeb su GitHub. Nella cartella “AppCode” è presente il file per aprire la soluzione in Visual Studio e la sottocartella con i sorgenti del progetto.

Installiamo Docker Desktop

Verificati i requisiti di sistema (RAM 4 GB, Windows 10 64-bit in versione Pro, Enterprise o Education), procediamo con l’installazione di Docker, disponibile sia in versione Docker Desktop per Windows che Docker Desktop per Mac.

L’installazione è piuttosto semplice ma lanciando l’applicazione potreste ricevere il seguente errore: “cannot enable hyper-v service”. In questo caso occorre verificare che nel BIOS sia abilitata la funzionalità di virtualizzazione. Se vi sono ulteriori messaggi vi suggerisco di verificare che anche i relativi servizi di Windows siano abilitati.

Cos’è Docker

Docker è una piattaforma open source per il deployment e la gestione dei container ovvero dei contenitori all’interno dei quali vengono inserite ed eseguite applicazioni specifiche.

Questi contenitori sono isolati l’uno dall’altro e vengono eseguiti su un kernel del sistema operativo condiviso rendendoli molto più leggeri rispetto alle macchine virtuali.

Come funziona Docker

Tutto parte dal DockerFIle. Questo serve per la definizione dell’immagine della nostra applicazione e contiene l’indicazione dei comandi, delle librerie e delle dipendenze da utilizzare.

Con il comando “docker build” verrà generata l’immagine della nostra applicazione e successivamente con il comando “docker run” verrà istanziato il container sull’immagine precedentemente creata.

Aggiungiamo il DockerFile alla nostra applicazione

Apriamo la nostra applicazione in Visual Studio, posizioniamoci sul file di progetto e con il tasto destro selezioniamo la voce “Aggiungi” > “Supporto Docker”

Successivamente ci verrà richiesto il sistema operativo di destinazione. Possiamo scegliere tra Linux e Windows.

Qui vanno fatte due considerazioni:

  1. il sistema operativo Linux, in caso di pubblicazione su Azure, può risultare più economico;
  2. se la nostra applicazione richiede funzionalità specifiche di Windows, opteremo per questa scelta;

Come vedremo di seguito, il file generato è composto da più sezioni ognuna delle quali inizia con la parola “FROM“. Il file immagine è costituito da una serie di layer tutti in modalità di sola lettura, il container aggiunge un top layer (chiamato anche container layer) in modalità lettura-scrittura.

FROM mcr.microsoft.com/dotnet/core/aspnet:3.1-buster-slim AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443

Nella prima sezione viene definito il layer di base per la creazione della nostra immagine. In questo layer sono referenziati i runtime del .NET Core e le porte 80 e 443 su cui il container si mette in ascolto. Inoltre, con il comando “WORKDIR /app”, viene impostata la cartella per l’esecuzione della nostra applicazione.

FROM mcr.microsoft.com/dotnet/core/sdk:3.1-buster AS build
WORKDIR /src
COPY ["BlazingGoogleMaps.Server/BlazingGoogleMaps.Server.csproj", "BlazingGoogleMaps.Server/"]
RUN dotnet restore "BlazingGoogleMaps.Server/BlazingGoogleMaps.Server.csproj"
COPY . .
WORKDIR "/src/BlazingGoogleMaps.Server"
RUN dotnet build "BlazingGoogleMaps.Server.csproj" -c Release -o /app/build

In questa sezione viene definita la compilazione della nostra applicazione referenziando il .NET Core SDK. Nella seconda riga viene impostata la cartella “WORKDIR /src” che conterrà i files da compilare e poi copiare nella cartella “/app/build”.

FROM build AS publish
RUN dotnet publish "BlazingGoogleMaps.Server.csproj" -c Release -o /app/publish

In questo layer i files vengono pubblicati nella relativa cartella “/app/publish”.

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "BlazingGoogleMaps.Server.dll"]

L’ultima sezione crea l’immagine finale della nostra applicazione. Qui viene usata l’immagine di base definita nel primo layer. Viene impostata la “WORKDIR /app” e copiati i file che sono stati pubblicati nello step precedente. Infine, viene impostato l’entry point per l’applicazione.

Avvio del container

Dopo aver generato il DockerFile, Visual Studio lo eseguirà automaticamente generando l’immagine e avviando il container che potremo vedere nella dashboard di Docker Desktop.

Possiamo ora lanciare la nostra applicazione Blazor Server “containerizzata” sia da Visual Studio che dalla dashboard di Docker Desktop.

Conclusioni

Se sei uno sviluppatore ti sarà capitato sicuramente che nella fase di deploy, in ambiente di produzione, l’applicazione non risponda esattamente come nell’ambiente di testing. Questo problema è spesso dovuto alle differenze tra i due ambienti, alle risorse e alle configurazioni utilizzate.

I container permettono di pacchettizzare l’applicazione e le sue dipendenze in un file unico e consentono agli sviluppatori di creare ambienti isolati da altre applicazioni. Così il sistema rimane coerente e indipendentemente da dove venga poi eseguito il deployment dell’applicazione.