Vérification

Après le déploiement, exécutez ces vérifications pour confirmer que le nœud CDN edge fonctionne correctement. Accordez 2 à 3 minutes après terraform apply pour que cloud-init termine l’installation de NGINX.

Bilan de santé

Vérifiez que NGINX est en cours d’exécution et qu’il répond :

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

Sortie attendue :

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

Si vous utilisez les sorties Terraform :

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

Absence de cache (première requête)

La première requête vers n’importe quel chemin sera un cache miss — le nœud edge récupère le contenu depuis le serveur d’origine :

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

Recherchez ces en-têtes dans la réponse :

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

MISS signifie que le contenu n’était pas en cache et a été récupéré depuis le serveur d’origine.

Succès de cache (requête suivante)

Répétez immédiatement la même requête :

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

En-têtes attendus :

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

HIT confirme que la réponse a été servie depuis le cache disque NGINX sans contacter le serveur d’origine.

Inspection du répertoire de cache

Connectez-vous en SSH à la machine virtuelle pour vérifier que le contenu mis en cache existe sur le disque :

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

Statut NGINX

Vérifiez que NGINX est en cours d’exécution et que la configuration est valide :

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

Connectivité vers le serveur d’origine

Vérifiez que le nœud edge peut atteindre le serveur d’origine :

ssh azureuser@<PUBLIC_IP>

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

En cas d’échec, vérifiez :

1. La variable origin_server est correcte dans la configuration Terraform
2. Le serveur d’origine autorise les connexions entrantes depuis l’adresse IP publique du nœud edge
3. La résolution DNS fonctionne depuis la machine virtuelle (nslookup your-origin.example.com)

Progression de cloud-init

Surveillez la progression du provisionnement via le journal cloud-init :

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

Phases attendues : [init], [nic] (détection dynamique de la carte réseau), [complete].

Si cloud-init signale des erreurs :

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

Test de bout en bout

Exécutez un cycle de requête complet et vérifiez la chaîne de réponse :

# 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"

Sortie attendue :

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

Vérification des en-têtes des fournisseurs CDN

Vérifiez que tous les en-têtes des fournisseurs CDN sont correctement injectés en interrogeant le chemin /headers (lors de l’utilisation de httpbin.org comme serveur d’origine) :

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

La réponse attendue inclut les en-têtes de l’ensemble des cinq fournisseurs :

{
    "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 de détection des appareils

Testez avec un User-Agent mobile pour vérifier que les en-têtes de détection des appareils changent :

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"

Résultat attendu :

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

Dépannage

NGINX ne fonctionne pas

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

cloud-init non terminé

Après terraform apply, cloud-init prend 2 à 3 minutes. Vérifiez la progression :

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

Le cache affiche toujours MISS

• Vérifiez que le serveur d’origine renvoie des codes de réponse pouvant être mis en cache (200, 301, 302)
• Vérifiez que le serveur d’origine n’envoie pas d’en-têtes Cache-Control: no-cache ou no-store
• Consultez les journaux d’erreurs NGINX : sudo tail -f /var/log/nginx/error.log

Connexion refusée sur le port 80/443

• Vérifiez que les règles NSG sont appliquées : az network nsg rule list --nsg-name "$(terraform output -raw nsg_name)" --resource-group "$(terraform output -raw resource_group_name)" -o table
• Vérifiez que NGINX est en écoute : ssh azureuser@<PUBLIC_IP> "sudo ss -tlnp | grep nginx"