Déploiement Fastly Compute en toute sécurité : packages, versions, backends et restauration

Publié le

14 juil. 2026

Mis à jour le

15 juil. 2026

Temps de lecture

25 min de lecture

Fastly Compute exécute du code applicatif WebAssembly à la périphérie. Cela permet de distribuer rapidement de petites décisions de requête, la composition des réponses et des appels d'origine soigneusement bornés, mais signifie aussi qu'une mauvaise livraison peut affecter le trafic mondial. Traitez le package Compute, sa configuration de service Fastly et ses magasins de données d'exécution comme des surfaces de déploiement séparées avec des contrôles distincts.

Un orchestrateur d'edge managé se place devant de nombreuses origines et fournisseurs à la fois, et voit chaque déploiement Fastly Compute comme une variable parmi d'autres pouvant faire bouger la latence ou le taux d'erreur d'un client. À cette échelle, une activation non revue ou un rollback jamais testé n'est plus l'incident d'une seule équipe.

Ce tutoriel s'adresse aux ingénieurs DevOps et de plateforme qui exploitent un service Compute avec une ou plusieurs origines HTTP. Il emploie la terminologie de la Fastly CLI et du plan de contrôle en vigueur à la publication. Confirmez les droits du compte, les limites de produit et le comportement de la CLI dans la documentation Fastly liée avant d'automatiser les commandes.

Prérequis

• Un service Fastly Compute hors production et un domaine d'origine dédié, ainsi que le bon ID de service de production et une version active antérieure identifiable.
• Un token CI à moindre privilège stocké dans le gestionnaire de secrets CI, une Fastly CLI épinglée et la chaîne d'outils du langage du projet.
• Un contrat de backend validé couvrant TLS, le host override, les contrôles de santé et les délais d'attente, ainsi qu'un responsable d'origine capable de valider le trafic.
• Des données de test synthétiques, une télémétrie de périphérie et d'origine conservée, des conditions d'arrêt de mise en production et un opérateur de restauration nommé.

1. Établir le contrat de déploiement Fastly Compute

Commencez par un contrat étroit pour chaque route. Consignez les méthodes et limites de corps acceptées ; la clé de cache et la possibilité de mise en cache ; le backend sélectionné ; les en-têtes sortants ; les délais d'attente ; la politique de nouvelle tentative ; les classes de réponse attendues ; et le comportement de repli. Incluez un identifiant de livraison dans un en-tête de réponse uniquement pour un domaine de test restreint ou une route de diagnostic authentifiée, et non comme dépendance pour les clients.

Une manière utile de penser un déploiement Fastly Compute : quatre artefacts couplés qui doivent évoluer ensemble mais se vérifient indépendamment — le paquet WebAssembly, la configuration de service numérotée, le contrat de backend et les magasins de données d'exécution. La plupart des incidents de production viennent de l'un de ces quatre éléments modifié sans que les autres n'aient été revus au même moment.

Les services Fastly ont des versions de configuration numérotées. Une version peut être clonée, validée, activée et verrouillée ; les versions verrouillées ne peuvent pas être modifiées. Conservez ensemble dans l'enregistrement de déploiement l'ID de service, le numéro de version active, le digest du package, la révision source et le changement de configuration. C'est le minimum de preuves nécessaire pour distinguer une régression de package d'un changement d'origine, de backend ou de magasin de données.

Définissez les conditions d'arrêt avant le déploiement : réponses 5xx élevées à l'origine, délais d'attente du backend, résultat d'autorisation modifié, régression de clé de cache ou augmentation de latence p95/p99 au-delà du budget de route. Nommez l'opérateur qui peut activer la version précédente connue comme fiable et l'équipe d'origine qui reçoit une alerte de trafic direct vers l'origine ou de pic de connexions.

Scénario Acme Shop

Pour ancrer ce guide, prenons Acme Shop, un commerçant qui expose uniquement GET /products/<slug> via un service Compute. Le gestionnaire appelle le backend statique revu acme_catalog_origin ; il renvoie 405 pour toute autre méthode et 404 pour toute autre route, et ne traite ni le compte, ni le paiement, ni les écritures. Nous reviendrons sur Acme Shop dans les sections suivantes pour illustrer le contrat de livraison, les tests par couches et la restauration.

2. Préparer les identifiants et les outils

Installez dans CI une version Fastly CLI épinglée et examinée. Pour la vérifier et vous authentifier localement, exécutez :

fastly version
fastly auth login

Vous pouvez également vous authentifier avec un profil CLI. Dans CI, fournissez FASTLY_API_TOKEN depuis le gestionnaire de secrets CI plutôt que de le committer, l'afficher ou le placer dans fastly.toml. La CLI documente les flags de commande, variables d'environnement et stockage local d'identifiants comme options d'authentification ; utilisez un token limité au service et aux opérations dont le pipeline a réellement besoin.

La CLI compile localement un package Compute et charge l'artefact résultant. Installez la chaîne d'outils du langage requise par le starter ou SDK sélectionné, puis épinglez sa version dans le dépôt ou l'image de build. Construisez depuis une installation de dépendances propre fondée sur le lockfile. Un compilateur, une dépendance transitive ou un bundle généré qui change signifie qu'un package ayant la même révision source peut ne pas être la même livraison.

Pour un nouveau projet, initialisez un starter pris en charge plutôt que d'inventer le manifeste :

mkdir edge-router
cd edge-router
fastly compute init

L'initialiseur écrit fastly.toml. Pour les projets JavaScript, installez les dépendances déclarées avant de construire. Pour un service existant, définissez service_id dans le manifeste ou fournissez-le via l'environnement CI afin que le pipeline ne puisse pas créer accidentellement un nouveau service de production.

Paquets WebAssembly en périphérie : limites de ressources et dimensionnement

Compute exécute vos paquets WebAssembly en périphérie dans un bac à sable par requête plutôt qu'un processus de longue durée, d'où des plafonds de ressources stricts qu'un déploiement applicatif classique n'a pas à considérer. Concevez le gestionnaire selon ces limites, pas selon ce qui fonctionne par hasard en test local :

Un paquet qui a compilé et servi correctement en développement peut encore échouer en production purement à cause de la forme de la requête : une charge utile plus grande ou un amont plus lent peut franchir un plafond de temps CPU ou de mémoire qu'un petit test synthétique n'approche jamais. Incluez une entrée de pire cas dans les tests de staging, et traitez un événement Memory Exceeded ou vCPU Limit comme un défaut de code, pas une instabilité d'infrastructure. fastly compute validate vérifie en plus la structure d'un paquet avant le chargement, sans le déployer — exécutez-le en CI juste après le build comme porte rapide et non destructive :

fastly compute build
fastly compute validate --package pkg/edge-router.tar.gz

La validation détecte tôt un manifeste malformé ou une erreur de packaging ; elle n'évalue pas le comportement CPU ou mémoire à l'exécution, que seul le trafic de staging révèle.

3. Séparer package, configuration de service et données d'exécution

fastly.toml décrit comment la CLI construit et package l'application, et peut configurer le serveur local. Ce n'est pas un emplacement pour un token API de production ou un secret applicatif en clair. Sa commande scripts.build doit produire bin/main.wasm ; la CLI package cet artefact pour le chargement.

Conservez la configuration de service sous revue avec le package : domaines, TLS, backends statiques, contrôles de santé, host override, vérification TLS, délais d'attente des backends, limites de connexions, endpoints de journalisation et politique de cache. L'API backend les expose comme champs de configuration. En particulier, un délai d'attente de backend Compute est un échec de connexion, pas une réponse partiellement réussie ; définissez donc dans le code une échéance au niveau de la route plus courte que le budget visible par l'utilisateur et gérez délibérément l'échec.

Utilisez le bon magasin de données de périphérie pour chaque valeur d'exécution :

• Config Store : configuration petite, non sensible et peu fréquemment modifiée, comme une carte de routes ou une valeur par défaut de fonctionnalité.
• KV Store : données plus volumineuses, non sensibles, nécessitant des mises à jour plus fréquentes, après évaluation des implications de cohérence éventuelle.
• Secret Store : petites valeurs sensibles, comme tokens API, clés de signature ou mots de passe.

Ces magasins sont sans version : les mises à jour prennent effet sans incrément de version de service. C'est utile opérationnellement, mais une mise à jour de données peut modifier le comportement de production indépendamment d'un déploiement de package. Donnez à chaque magasin un responsable, un enregistrement de changement, une règle de validation et une procédure de restauration. N'utilisez pas de cache partagé, Config Store, en-têtes de requête ou logs pour transporter un secret.

4. Rendre le comportement du backend explicite

Un backend nommé est le contrat d'origine. Spécifiez le nom d'hôte ou l'adresse, le port, les exigences TLS, les attentes de certificat et SNI, le host override si nécessaire, les délais de connexion/premier octet/globaux, le contrôle de santé et la limite de concurrence. Vérifiez que l'origine accepte l'en-tête Host résultant et que son certificat correspond au nom de vérification configuré. Ne désactivez pas les vérifications de certificat pour faire passer un déploiement.

Les backends statiques sont configurés sur le service Fastly. Les backends dynamiques peuvent être utiles pour un routage de tenant contrôlé, mais dérivez-les uniquement d'une valeur de configuration autorisée, jamais directement d'une URL ou d'un en-tête Host fourni par l'utilisateur. Sinon, un service Compute peut devenir un relais SSRF. Appliquez une carte explicite route-vers-backend et refusez les routes inconnues.

Pour le développement local, définissez un substitut de backend inoffensif et des données de magasin de test. Cela appartient à un manifeste réservé au développement ou à un fixture de test ignoré, pas à un fichier de secrets de production :

manifest_version = 3
name = "edge-router"
language = "javascript"
service_id = "YOUR_NON_PRODUCTION_SERVICE_ID"

[local_server.backends.origin]
url = "http://127.0.0.1:8080"
override_host = "origin.test"
health = "healthy"

[local_server.secret_stores]
test_secrets = { file = "test/fixtures/secrets.json", format = "json" }

Utilisez de fausses valeurs dans test/fixtures/secrets.json, ajoutez le fichier à .gitignore s'il peut contenir des identifiants de développeur et ne dirigez jamais un test local vers une origine de production non protégée. Les données locales de Secret Store sont des données de test ; le chiffrement local ne modélise pas la protection de Secret Store en production.

5. Tester par couches avant le chargement

Construisez le package exact que CI déploiera :

fastly compute build

L'artefact attendu est une archive de package sous pkg/. Enregistrez sa somme de contrôle et ses métadonnées de build avec la révision source. Exécutez les tests unitaires du langage avant cette commande, puis exercez le comportement HTTP avec le serveur local Fastly :

fastly compute serve --watch
curl -i http://127.0.0.1:7676/health
curl -i -H 'Host: app.test' http://127.0.0.1:7676/products/42

Testez le succès, une entrée invalide, une entrée non authentifiée, une réponse publique pouvant être mise en cache, une réponse privée, un 4xx de backend, un refus de connexion, une origine lente et un backend non sain. Vérifiez que les secrets, en-têtes d'autorisation, cookies et en-têtes de routage internes sont absents des réponses et des logs.

Le serveur local est utile, mais n'est pas une réplique de production. Fastly documente qu'il ne possède pas de cache HTTP readthrough, donc le comportement cache-control et le taux de cache hit ne peuvent pas être prouvés localement. Il ne transite pas non plus par l'infrastructure de routage Fastly, ne fournit pas plusieurs détails et en-têtes de connexion, et utilise une santé de backend configurée ou simulée. Testez ces propriétés sur un service Fastly isolé avec un domaine hors production avant l'activation en production.

Un gestionnaire minimal illustre ce contrat pour Acme Shop. Il n'admet qu'une seule route publique en lecture et un backend nommé, et rejette les requêtes porteuses d'identité avant que le cache readthrough ne puisse les consulter ou les alimenter ; le nom du backend est une valeur de configuration de service revue, pas une entrée client :

/// <reference types="@fastly/js-compute" />

addEventListener("fetch", (event) => event.respondWith(handle(event.request)));

async function handle(request) {
  const url = new URL(request.url);
  if (url.pathname === "/health") return new Response("ok\n", { status: 200 });
  if (request.method !== "GET") return new Response("Method Not Allowed", { status: 405 });
  if (!/^\/products\/[a-z0-9-]+$/.test(url.pathname)) return new Response("Not Found", { status: 404 });
  if (request.headers.has("Authorization") || request.headers.has("Cookie")) {
    return new Response("Public catalogue endpoint does not accept credentials", { status: 400 });
  }

  return fetch(request, { backend: "acme_catalog_origin" });
}

Le fetch() final utilise délibérément le cache readthrough normal de Compute seulement après que la requête a satisfait le contrat public anonyme. Si cette route doit un jour accepter des identifiants, ne retirez pas ce garde-fou : envoyez la requête authentifiée avec cacheOverride: new CacheOverride("pass") ou concevez une route privée et une politique de cache revues séparément.

6. Déployer vers un service isolé et l'observer

Déployez d'abord vers un service distinct de développement ou de staging avec une origine et un domaine hors production :

fastly compute deploy --service-id "$FASTLY_SERVICE_ID" --status-check-path /health

La CLI prend en charge un ID de service, une version de service sélectionnée, un commentaire de déploiement ainsi qu'un chemin et un délai d'attente de contrôle d'état. Exigez une réponse de santé significative qui vérifie les dépendances requises par la route sans exposer de données. Un 200 d'un processus qui ne peut pas joindre son origine requise n'est pas une porte de livraison adéquate.

Distinguez ce service hors production de l'environnement de staging natif de Fastly, qui active une version candidate du même service de production sans servir de trafic réel via PUT /service/$service_id/version/$version/activate/staging, accessible par une IP Anycast dédiée sur le même réseau et la même configuration TLS que la production. C'est plus fidèle que le serveur local, avec de vraies limites : il exige une activation de production préalable, ne couvre pas domaine/TLS, ne partage pas le cache de production, et son trafic est facturé comme tel — réservez-le à la dernière porte avant l'activation.

Utilisez la commande suivante pour un diagnostic de staging court et contrôlé :

fastly log-tail

Elle diffuse la sortie standard, l'erreur standard et les erreurs d'exécution, mais n'est pas un journal d'audit de production. Configurez un endpoint de journalisation en temps réel pour une télémétrie de production conservée. Émettez des champs structurés à cardinalité bornée tels que :

• ID de requête ou trace, modèle de route, méthode, état et classe de réponse
• digest de package ou ID de livraison, version de service, backend sélectionné et résultat de cache
• latence de backend, raison de délai d'attente ou de nouvelle tentative et mode d'échec sûr
• révision de configuration opaque ou identifiant de version de secret, jamais la valeur du secret

Masquez Authorization, Cookie, URL signées, tokens clients, corps de requête et paramètres de requête sensibles à la source. Joignez les événements Fastly aux logs d'accès d'origine par un ID de requête ou contexte de trace afin qu'une alerte puisse indiquer si la périphérie, la connexion backend ou l'application d'origine est responsable.

Rejouez sur ce service isolé les mêmes cas positifs, négatifs et de panne que sur le serveur local. Si le contrôle de santé, le contrat de route ou le budget d'erreur du backend échoue à cette étape, n'activez pas la production.

7. Activer délibérément et conserver la restauration

Pour la production, clonez la version de service active dans le panneau de contrôle Fastly ou via votre workflow d'infrastructure. Appliquez les changements de backend et de service prévus à ce clone, validez-le, chargez le package revu vers la version ciblée et activez seulement après validation des portes de déploiement. Verrouillez la bonne version obtenue afin que les modifications ultérieures nécessitent une nouvelle version révisable.

Immédiatement après l'activation, exécutez des requêtes synthétiques depuis des régions représentatives et comparez-les à la référence. Surveillez le taux de 5xx de périphérie et d'origine, le taux de délais d'attente du backend, le volume de requêtes d'origine, les résultats de cache, la latence p95/p99 et les échecs d'authentification. Fastly indique que les packages de remplacement peuvent prendre jusqu'à environ une minute avant de commencer à traiter les requêtes ; conservez donc une fenêtre d'observation plus longue que la propagation et le réchauffement normal du cache.

Restauration

La restauration est une opération d'activation, pas une reconstruction sous pression :

1. Conservez le package précédent fonctionnel et la version de service verrouillée identifiables dans l'enregistrement de livraison.
2. Si une condition d'arrêt est atteinte, activez cette version connue comme fiable avec le plan de contrôle ou l'automatisation API approuvée.
3. Vérifiez la version active, les contrôles synthétiques, le volume d'origine, le taux d'erreur et les logs après propagation.
4. Conservez le package défaillant, le numéro de version, les logs et métriques corrélés pour l'enquête. Ne modifiez pas la version défaillante sur place.

Si l'incident provient d'une mise à jour sans version de Config, KV ou Secret Store, l'activation d'une version de service antérieure ne l'annulera pas. Utilisez la procédure de restauration propre au magasin, en consignant l'ancienne valeur avant tout changement, puis vérifiez à la fois la révision des données et le package servi.

Pourquoi le rollback Compute est rapide mais l'activation est tout-ou-rien

Le rollback Compute est une activation quasi instantanée, pour la même raison qu'il n'offre pas de déploiement progressif natif : une version de service est une unité atomique. Activer une version — en avant ou en arrière — remplace 100 % du trafic ; Fastly ne propose pas de canary natif par pourcentage ni de répartition pondérée entre deux versions Compute. Construisez vos portes de mise en production autour de cette contrainte.

Là où un déploiement progressif est requis, les équipes le construisent elles-mêmes via une petite couche de routage : un service Fastly transfère vers deux backends (courant et candidat) par director ou sélection pondérée, déplaçant une part configurable du trafic sous les mêmes conditions d'arrêt qu'une activation complète — au prix d'un service supplémentaire à sécuriser et d'un cache à repenser. Réservez cette approche aux routes où une mauvaise mise en production coûte assez cher pour la justifier ; sinon, privilégiez une activation en étapes filtrée par des portes. C'est aussi pourquoi le contrat de livraison de la section 1 compte davantage ici : le rollback Compute ne pouvant pas annuler partiellement une mauvaise mise en production, la seule vraie mitigation est d'intercepter la régression avant l'activation complète, la version verrouillée précédente restant prête à être réactivée dès qu'une condition d'arrêt se déclenche.

Adéquation à la périphérie et réserves opérationnelles

Choisissez Compute uniquement là où son modèle d'exécution permet le résultat. Les gestionnaires de requêtes s'exécutent par défaut dans des sandbox WebAssembly isolées et Fastly impose des limites de ressources produit. Gardez le travail du gestionnaire borné, définissez de petits délais d'attente sortants, limitez les nouvelles tentatives et rendez les erreurs sûres. Une boucle de tentatives depuis de nombreux POP peut amplifier une origine dégradée.

Ne supposez pas qu'un emplacement de périphérie fait autorité pour l'identité utilisateur, les stocks, les soldes, l'état de paiement ou l'ordre des écritures. Lisez l'état depuis un système d'enregistrement conçu à cet effet, exposez l'obsolescence lorsqu'elle importe et envoyez le travail long vers un traitement asynchrone durable. Ne mettez en cache que des données publiques ou correctement isolées ; ne mettez jamais une réponse avec données de compte dans une clé partagée.

Protégez également l'origine indépendamment. Restreignez l'entrée de l'origine à Fastly ou à une connectivité privée lorsque possible, authentifiez le trafic périphérie-vers-origine et écrasez les en-têtes de transfert non fiables à la frontière de confiance. Le routage Compute améliore le contrôle de diffusion ; il ne remplace pas les contrôles réseau de l'origine, l'autorisation applicative ni un plan de réponse aux incidents testé.

Dépannage

Liste de contrôle de livraison

Avant chaque activation de production, confirmez que la révision source et la somme de contrôle du package sont enregistrées ; que l'ID de service et la version cible sont intentionnels ; que les backends valident TLS et ont des délais testés ; que les magasins d'exécution contiennent des données validées ; que les tests locaux et de staging couvrent les chemins d'échec ; que les logs conservés peuvent corréler l'activité de périphérie et d'origine ; que la version précédente est connue ; et que le responsable de restauration et les seuils sont d'astreinte.

Références Fastly principales

• Démarrer avec Compute
• Référence Fastly CLI
• Commandes Compute CLI
• Référence du manifeste de package fastly.toml
• Tester et déboguer sur la plateforme Compute
• Référence API des versions de service Fastly
• Référence API backend
• À propos des magasins de données de périphérie
• Limites de ressources Compute
• Référence de la commande fastly compute validate
• Travailler avec le staging