Keep in Touch!

Contenuti

C# 9 and .NET 5

Azure App Service Static Web Apps

Static Web Apps (Preview)

Giovedì 21 Maggio - Stavo lavorando tranquillamente quando un post su Twitter dal titolo “Introducing App Service Static Web Apps” ha attirato la mia attenzione. Mi sono bastate le prime righe per non capire (quasi) più nulla.

Modern web apps are increasingly adopting static front-end design patterns with client-side processing powered by JavaScript. This paradigm requires us to think differently about how we deploy and host web apps that don’t rely on web servers and consequently require a new structure of supporting cloud resources. This week at Build, our annual celebration of all things developer, we are happy to announce that Azure App Service has been expanded with a new hosting offer tailored specifically for static web apps, empowering developers to focus on the business logic that differentiates their apps rather than the infrastructure that hosts them.

Sapete a cosa ho pensato appena letto?

Con l’inizio del mese ho migrato il mio blog alla piattaforma GoHugo e l’ho spostato su Cloud Azure sfruttando il Blob Storage. Perchè negarmi questa novità?

Ora vi spiegherò come effettuare la pubblicazione del vostro primo sito statico sfruttando “Static Web Apps” dal portale Azure.

Prima di partire vi indico quello che vi occorre:

  • Account GitHub con un sito statico da pubblicare
  • Account Azure

New Resource - Static Web Apps

La creazie di una “Static Web Apps” è molto semplice e non richiede un vostro intervento tecnico.

  • Create a resource
  • Static Web App (Preview)
  • Selezionare Subscription e Resource Group
  • Inserire il Name della Static Web Apps (che non sarà l’url)
  • Selezionare la Region (in questo momento di preview il servizio è disponibile solamente in Central US, East US2, East Asia, West Europe, West US2)
  • Effettuare la Login a GitHub
  • Selezionare Organization, Repository & Branch
  • Proseguendo nel tab Build avrete la possibità di “Provide initial build variables. These can later be modified in the workflow file.” tra cui App location, Api location e App artifact location
  • Completato il tutto potrete fare la Review e creare la nuova risorsa.

Da azurestaticapps a Custom URL

Una volta creata la risorsa vi verrà assegnata un indirizzo URL sulla seguente linea

https://polite-XYZ-0QWERTY903.azurestaticapps.net/

(* XYZ & QWERTY sono state aggiunte a mano da me sostituendo parte dell’indirizzo originale)

Entrando nella risorsa via portale troveremo nella colonna di sinistra la voce Custom Domains e per farlo dovrete entrare nelle impostazioni del vostro dominio ed intervenire sui CNAME

  • Configure records with your DNS provider: To add a custom domain, first configure a CNAME record with your DNS provider.
wwwCNAMEpolite-XYZ-0QWERTY903.azurestaticapps.net
  • Validate custom domain: Enter the desired custom domain you wish to add below. Dopo avere inserito il vostro dominio potete procedere con la validazione.

Area di Staging

Una nota molto interessante, che mi riservo per un prossimo articolo è la possibilità di avere l’area di stagin per non applicare subito le modifiche live. Se vi state chiedendo come è possibile questo la risposta è molto semplice: PULL REQUEST.

Questo lo si intuisce facilmente dalla pipeline yml generata quando create l’ambiente

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
name: Azure Static Web Apps CI/CD

on:
  push:
    branches:
    - master
  pull_request:
    types: [opened, synchronize, reopened, closed]
    branches:
    - master

jobs:
  build_and_deploy_job:
    if: github.event_name == 'push' || (github.event_name == 'pull_request' && github.event.action != 'closed')
    runs-on: ubuntu-latest
    name: Build and Deploy Job
    steps:
    - uses: actions/checkout@v2
    - name: Build And Deploy
      id: builddeploy
      uses: Azure/static-web-apps-deploy@v0.0.1-preview
      with:
        azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN_XXX }}
        repo_token: ${{ secrets.GITHUB_TOKEN }} # Used for Github integrations (i.e. PR comments)
        action: 'upload'
        ###### Repository/Build Configurations - These values can be configured to match you app requirements. ######
        # For more information regarding Static Web App workflow configurations, please visit: https://aka.ms/swaworkflowconfig 
        app_location: '/' # App source code path
        api_location: 'api' # Api source code path - optional
        app_artifact_location: '' # Built app content directory - optional
        ###### End of Repository/Build Configurations ######

  close_pull_request_job:
    if: github.event_name == 'pull_request' && github.event.action == 'closed'
    runs-on: ubuntu-latest
    name: Close Pull Request Job
    steps:
    - name: Close Pull Request
      id: closepullrequest
      uses: Azure/static-web-apps-deploy@v0.0.1-preview
      with:
        azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN_XXX }}
        action: 'close'

Prime Impressioni

Ho fatto una prova di qualche ora e posso dire che mi piace il nuovo prodotto di Microsoft. Le prime note che voglio fare sono le seguenti:

  • La SKU è FREE
  • Non è richiesto un CDN per avere il Custom Domain (a differenza di un blob storage)
  • Purtroppo la pagina 404 non è personalizzabile
  • GitHub: Al momento è un vincolo come scelta di repository. Sarà vincente? O dovranno integrare anche altri source control?
  • La configurazione fornita in fase di creazione non è modificabile. Questo è bloccante in quanto il cambio è fattibile tramite ricreazione dell’ambiente (e modifica dei CNAME con relativo tempo di propagazione)

Lo ammetto, ero partito tutto bello convinto di migrare il mio blog su App Service Static Web App e l’avevo anche fatto come scritto su linkedin

Su una scala da 1 a 10, secondo voi quanto ho resistito a migrare il mio blog da #blobstorage a #azurestaticapps dopo avere letto la notizia questo pomeriggio nonostante il servizio sia ancora in preview? Ovviamente ho cambiato a tempo zero l’amato #endpoint del #cdn ed il gioco è stato trasparente. Si, lo ammetto … sono peggio dei bambini, ma a me il #cloud #azure piace ;) Grazie mamma #microsoft per questo regalo

Nel giro di poco mi sono reso conto di alcuni dettagli che mi hanno fatto decidere di rimettere operativa la pipeline di build tramite blob storage e l’utilizzo di CDN. Perchè?

  • Ero in difficoltà con la pipeline di GoHugo nonostante le indicazioni presenti sul sito Microsoft
  • La configurazione non potevo cambiarla se non cancellando e ricreando tutto

A questo punto preferisco rimettere momentaneamente in piedi lo stack precedente e dedicarmi nel fine settimana e sperimentare. Una volta trovata una linea per fare il publish automaticamente allora sarò ben felice di spegnere il CDN e cambiare i CNAME sul mio dominio.