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

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.

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.

1. Établir le contrat de livraison

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.

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.

2. Préparer les identifiants et les outils

Installez dans CI une version Fastly CLI épinglée et examinée, puis vérifiez-la avec fastly version. Authentifiez-vous localement avec fastly auth login ou 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.

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.

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.

Utilisez fastly log-tail pour un diagnostic de staging court et contrôlé. Il 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.

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.

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, puis vérifiez à la fois la révision des données et le package servi.

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é.

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