Tag: azure, cloud, devops, app-service, blob-storage, entra-id, serverless
Livello: intermedio
TL;DR: Panoramica operativa dei servizi core di Microsoft Azure (calcolo, storage, networking, identity e monitoring) per architetture cloud scalabili e sicure.
Resource Group come contenitore logico per ciclo di vita, permessi RBAC e billing unificato.
Azure App Service per hosting PaaS gestito di web app e API con scaling automatico e deployment slot.
Azure Functions per architetture serverless event-driven con trigger e binding dichiarativi.
Azure Blob Storage per archiviazione a oggetti (Hot, Cool, Cold, Archive tier).
Virtual Network (VNet) e Subnet per isolamento di rete privato ed estensione on-premises.
Network Security Group (NSG) per filtraggio del traffico inbound e outbound su porte e IP.
Microsoft Entra ID (ex Azure AD) per identità, autenticazione OAuth2/OIDC e accesso condizionale.
Managed Identities (System-assigned o User-assigned) per eliminare credenziali cablate nel codice.
Azure Key Vault per gestione sicura di segreti, certificati e chiavi crittografiche.
Azure Monitor e Application Insights per telemetria distribuita, metriche, log e alert.
Q: Come gestisci l'autenticazione tra un'applicazione su App Service e un database SQL o Blob Storage?R: Configuro una Managed Identity su App Service e assegno il ruolo RBAC necessario sulla risorsa di destinazione, accedendo tramite DefaultAzureCredential senza hardcodare password.
Q: Qual è la differenza principale tra deployment slot e un deployment diretto in produzione?R: Lo slot permette di testare il nuovo build in staging sulla stessa infrastruttura ed eseguire uno swap a tempo zero senza downtime e con rollback immediato in caso di anomalie.
Q: Quando conviene usare Azure Functions rispetto ad Azure App Service?R: Scelgo le Functions per carichi di lavoro event-driven, sporadici o picchi imprevisti con modello a consumo, mentre App Service è ideale per web API continue, monolite containerizzati o microservizi persistenti.
Usare IP pubblici sulle risorse PaaS invece di abilitare Private Endpoints o Service Endpoints.
Lasciare segreti di connessione nelle variabili d'ambiente invece di referenziare Azure Key Vault.
Ignorare i costi di egress del traffico tra diverse region o verso Internet.
Mancata configurazione dell'auto-swap o dei warmup endpoint durante lo swap degli slot in App Service.
Non impostare i budget alert a livello di Subscription o Resource Group.
# Login ad Azure e selezione sottoscrizione
az login
az account set --subscription "<subscription-id>"
# Creazione Resource Group
az group create --name rg-production --location westeurope
# Creazione App Service Plan (Linux) e Web App
az appservice plan create --name plan-prod --resource-group rg-production --sku B1 --is-linux
az webapp create --resource-group rg-production --plan plan-prod --name app-service-prod --runtime "NODE:20-lts"
# Abilitazione Managed Identity su Web App
az webapp identity assign --resource-group rg-production --name app-service-prod
# Lettura segreto da Azure Key Vault
az keyvault secret show --vault-name kv-prod --name "DatabasePassword" --query value -o tsv
TypeScript
// Esempio utilizzo DefaultAzureCredential in TypeScript
import { DefaultAzureCredential } from "@azure/identity";
import { SecretClient } from "@azure/keyvault-secrets";
const keyVaultUrl = "https://kv-prod.vault.azure.net";
const credential = new DefaultAzureCredential();
const client = new SecretClient(keyVaultUrl, credential);
const secret = await client.getSecret("DatabasePassword");
console.log(secret.value);
[ ] Meccanismo di routing e DNS con Azure Front Door e Application Gateway
[ ] Politiche di retention e costi di ingestion per Azure Log Analytics Workspace
[ ] Differenze tra Service Endpoint e Private Link / Private Endpoint
[x] Configurazione di Managed Identities per accesso a Key Vault
[x] Gestione degli slot di deployment e swap su Azure App Service