Verifica

Dopo la distribuzione, eseguire questi controlli per confermare che il nodo edge CDN funzioni correttamente. Attendere 2-3 minuti dopo terraform apply affinché cloud-init completi l’installazione di NGINX.

Controllo di integrità

Verificare che NGINX sia in esecuzione e risponda:

curl -s "http://<PUBLIC_IP>/health" | jq .

Output atteso:

{
  "status": "healthy",
  "component": "cdn-edge",
  "engine": "nginx",
  "vendor_profiles": [
    "akamai",
    "cloudflare",
    "cloudfront",
    "fastly",
    "azure-front-door"
  ]
}

Se si utilizzano gli output di Terraform:

curl -s "$(terraform output -raw health_check_url)" | jq .

Cache Miss (prima richiesta)

La prima richiesta a qualsiasi percorso sarà un cache miss — l’edge recupera i dati dal server di origine:

curl -I "http://<PUBLIC_IP>/"

Cercare queste intestazioni nella risposta:

X-Cache-Status: MISS
X-CDN-Edge: cdn-simulator

MISS indica che il contenuto non era nella cache ed è stato recuperato dal server di origine.

Cache Hit (richiesta successiva)

Ripetere immediatamente la stessa richiesta:

curl -I "http://<PUBLIC_IP>/"

Intestazioni attese:

X-Cache-Status: HIT
X-CDN-Edge: cdn-simulator

HIT conferma che la risposta è stata servita dalla cache su disco di NGINX senza contattare il server di origine.

Ispezione della directory della cache

Connettersi tramite SSH alla VM per verificare che il contenuto memorizzato nella cache esista su disco:

ssh azureuser@<PUBLIC_IP>

# Check cache directory has content
sudo find /var/cache/nginx/cdn -type f | head -20

# Check cache size
sudo du -sh /var/cache/nginx/cdn

Stato di NGINX

Verificare che NGINX sia in esecuzione e che la configurazione sia valida:

ssh azureuser@<PUBLIC_IP>

# Check service status
sudo systemctl status nginx

# Validate configuration
sudo nginx -t

# View active connections (if stub_status is enabled)
curl -s http://localhost/health

Connettività al server di origine

Verificare che il nodo edge possa raggiungere il server di origine:

ssh azureuser@<PUBLIC_IP>

# Test connectivity to origin (replace with your origin URL)
curl -I "https://your-origin.example.com/"

In caso di errore, verificare:

1. La variabile origin_server è corretta nella configurazione Terraform
2. Il server di origine consente connessioni in entrata dall’IP pubblico del nodo edge
3. La risoluzione DNS funziona dalla VM (nslookup your-origin.example.com)

Avanzamento di cloud-init

Monitorare l’avanzamento del provisioning tramite il log di cloud-init:

ssh azureuser@<PUBLIC_IP> "tail -f /var/log/cloud-init-progress.log"

Fasi previste: [init], [nic] (rilevamento NIC dinamico), [complete].

Se cloud-init segnala errori:

ssh azureuser@<PUBLIC_IP> "sudo cloud-init status --long"

Test end-to-end

Eseguire un ciclo di richiesta completo e verificare la catena di risposta:

# First request — MISS (fetches from origin)
echo "=== Request 1 (expect MISS) ==="
curl -s -o /dev/null -w "HTTP %{http_code} | Cache: %{header:X-Cache-Status}\n" "http://<PUBLIC_IP>/test-path"

# Second request — HIT (served from cache)
echo "=== Request 2 (expect HIT) ==="
curl -s -o /dev/null -w "HTTP %{http_code} | Cache: %{header:X-Cache-Status}\n" "http://<PUBLIC_IP>/test-path"

Output atteso:

=== Request 1 (expect MISS) ===
HTTP 200 | Cache: MISS
=== Request 2 (expect HIT) ===
HTTP 200 | Cache: HIT

Verifica delle intestazioni dei vendor CDN

Verificare che tutte le intestazioni dei vendor CDN vengano iniettate richiedendo il percorso /headers (quando si utilizza httpbin.org come server di origine):

curl -s "http://<PUBLIC_IP>/headers" | python3 -m json.tool

La risposta attesa include le intestazioni di tutti e cinque i vendor:

{
    "headers": {
        "True-Client-Ip": "<YOUR_CLIENT_IP>",
        "Cf-Connecting-Ip": "<YOUR_CLIENT_IP>",
        "Cf-Ipcountry": "US",
        "Cf-Ray": "<request_id>-SJC",
        "Cf-Bot-Score": "85",
        "Cf-Ja3-Hash": "e7d705a3286e19ea42f587b344ee6865",
        "Cloudfront-Viewer-Country": "US",
        "Cloudfront-Viewer-City": "San Jose",
        "Cloudfront-Is-Desktop-Viewer": "true",
        "Cloudfront-Is-Mobile-Viewer": "false",
        "Fastly-Client-Ip": "<YOUR_CLIENT_IP>",
        "X-Akamai-Edgescape": "georegion=263,country_code=US,...",
        "X-Azure-Clientip": "<YOUR_CLIENT_IP>",
        "X-Azure-Fdid": "a0a0a0a0-bbbb-cccc-dddd-e1e1e1e1e1e1",
        "X-Geo-Country-Code": "US"
    }
}

Test di rilevamento del dispositivo

Eseguire il test con un User-Agent mobile per verificare che le intestazioni di rilevamento del dispositivo cambino:

curl -s "http://<PUBLIC_IP>/headers?device=mobile" \
  -H "User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X)" \
  | python3 -m json.tool | grep -E "Is-Mobile|Is-Desktop|is_mobile"

Risultato atteso:

"Cloudfront-Is-Desktop-Viewer": "false",
"Cloudfront-Is-Mobile-Viewer": "true",

Risoluzione dei problemi

NGINX non in esecuzione

ssh azureuser@<PUBLIC_IP>
sudo systemctl status nginx
sudo journalctl -u nginx --no-pager -n 50

Cloud-init non completato

Dopo terraform apply, cloud-init richiede 2-3 minuti. Verificare l’avanzamento:

ssh azureuser@<PUBLIC_IP>
sudo cloud-init status
sudo tail -f /var/log/cloud-init-output.log

Cache che mostra sempre MISS

• Verificare che il server di origine restituisca codici di risposta memorizzabili nella cache (200, 301, 302)
• Verificare che il server di origine non invii intestazioni Cache-Control: no-cache o no-store
• Controllare i log degli errori di NGINX: sudo tail -f /var/log/nginx/error.log

Connessione rifiutata sulla porta 80/443

• Verificare che le regole NSG siano applicate: az network nsg rule list --nsg-name "$(terraform output -raw nsg_name)" --resource-group "$(terraform output -raw resource_group_name)" -o table
• Verificare che NGINX sia in ascolto: ssh azureuser@<PUBLIC_IP> "sudo ss -tlnp | grep nginx"