Aller au contenu

AWS Mis à jour le 2026-07-04

Layers Lambda : partager les dépendances sans chaos de versions

Les layers Lambda permettent aux fonctions de partager des dépendances, mais des versions de layer non épinglées désynchronisent les environnements en douce. Comment les layers fonctionnent vraiment, les limites qui mordent, et la discipline de versionnage qui prévient le chaos.

Un layer Lambda est une archive zip extraite dans /opt de l’environnement d’exécution, posée sous votre code de fonction — une façon de livrer des dépendances partagées, des runtimes personnalisés ou des extensions une seule fois plutôt que de les empaqueter dans chaque fonction. Les layers règlent un vrai problème d’empaquetage, mais ils introduisent un problème de versionnage en échange : les versions de layer sont immuables et référencées par numéro, les fonctions ne se mettent jamais à jour automatiquement, et une équipe sans discipline d’épinglage finit avec douze fonctions sur neuf versions différentes du « même » layer. La mécanique s’apprend en dix minutes; la discipline est le vrai travail.

Ce qui se passe

Quand vous publiez un layer, AWS le stocke comme une nouvelle version immuable — version 1, 2, 3, et ainsi de suite — chacune avec son propre ARN se terminant par le numéro de version. Une fonction référence des ARN de versions de layer précis (jusqu’à cinq layers par fonction), et au démarrage à froid Lambda les télécharge et les extrait dans /opt en ordre, les layers suivants écrasant les précédents en cas de collision de chemins. Le code de la fonction plus tous les layers doivent tenir dans la même limite de 250 Mo décompressés qui s’applique aux fonctions en zip; les layers ne l’étendent pas.

Pour que le runtime trouve le contenu du layer, le zip doit suivre la convention de répertoires du runtime : python/ pour les paquets Python, nodejs/node_modules/ pour Node.js, java/lib/ pour Java, et bin/ pour les exécutables qui doivent atterrir sur le PATH. Trompez-vous de structure de dossiers et le layer s’attache sans problème mais les imports échouent — le billet de soutien le plus fréquent sur les layers.

Le chaos de versions arrive par deux portes. Un, « latest » n’existe pas : chaque attachement vise une version numérotée, donc publier la version 14 d’un layer ne change rien nulle part tant que chaque fonction n’est pas mise à jour pour la référencer — les équipes qui mettent à jour certaines fonctions et en oublient d’autres dérivent immédiatement. Deux, supprimer une version de layer ne brise pas les fonctions en cours (elles gardent leur copie), mais ça brise le prochain déploiement de toute fonction qui la référence encore — c’est comme ça qu’un script de ménage fait tomber une mise en production du vendredi.

Deux choses que les layers ne font explicitement pas : ils ne réduisent pas le temps de démarrage à froid (les mêmes octets se chargent dans les deux cas), et ils n’agissent pas comme un gestionnaire de paquets — il n’y a pas de résolution de dépendances, juste de l’extraction de zip en ordre.

Quoi vérifier en premier

  • Quelles versions de layer chaque fonction référence, contre ce qui est courant. L’écart entre les deux est votre mesure de dérive.
  • La taille combinée contre la limite de 250 Mo décompressés. Layers plus code partagent le budget; un gros layer de dépendances ML peut ne laisser aucune place à la fonction.
  • La structure de répertoires dans le zip du layer. python/lib/python3.12/site-packages/... fonctionne aussi pour Python, mais un site-packages nu à la racine, non.
  • La compatibilité de runtime. Un layer bâti avec des extensions natives pour x86_64 ne chargera pas sur une fonction arm64, et les paquets compilés sur un Mac échouent fréquemment sur Amazon Linux.

Comment vérifier

Listez les versions d’un layer et voyez ce qu’une fonction utilise réellement :

aws lambda list-layer-versions --layer-name shared-deps \
  --query 'LayerVersions[].[Version,CreatedDate,CompatibleRuntimes[0]]' --output table

aws lambda get-function-configuration --function-name my-function \
  --query 'Layers[].Arn'

Auditez la dérive à travers la flotte :

aws lambda list-functions \
  --query 'Functions[?Layers != `null`].[FunctionName, Layers[].Arn]' --output json

Pour voir exactement ce qu’un layer contient, tirez-le et inspectez l’arborescence :

aws lambda get-layer-version --layer-name shared-deps --version-number 14 \
  --query 'Content.Location' --output text
# curl sur l'URL présignée, dézipper, et vérifier les dossiers de premier niveau

Dans la console : Lambda > Layers liste les layers et les versions; les attachements d’une fonction sont à Lambda > Functions > (fonction) > Code, en défilant jusqu’au panneau Layers. Les conventions d’empaquetage par runtime sont documentées à https://docs.aws.amazon.com/lambda/.

L’approche

  1. Décidez ce qui appartient à un layer, point. Bons candidats : une bibliothèque interne partagée et stable, un ensemble de dépendances lourd utilisé par plusieurs fonctions (pilotes de base de données, agents d’observabilité), des extensions de fournisseurs, et des binaires comme ffmpeg. Mauvais candidats : tout ce qui change avec le code applicatif — ça appartient au paquet de la fonction, versionné avec le code qui l’utilise.
  2. Bâtissez les layers en CI, sur l’architecture cible. Bâtissez le zip dans un conteneur qui correspond au runtime Lambda (basé Amazon Linux, bonne version de Python/Node, bonne architecture) pour que les extensions natives chargent vraiment. La publication est un seul appel : aws lambda publish-layer-version --layer-name shared-deps --zip-file fileb://layer.zip --compatible-runtimes python3.13 --compatible-architectures arm64.
  3. Épinglez les versions dans l’IaC, toujours. L’ARN de version du layer vit dans Terraform/CloudFormation/SAM à côté de la fonction, si bien que chaque environnement déclare exactement ce qu’il roule et la dérive se voit dans un diff plutôt que de se découvrir dans un incident.
  4. Déployez les nouvelles versions comme des mises en production, pas comme des retouches. Publiez la nouvelle version, mettez à jour les références en pré-production, testez, puis promouvez le même numéro de version à travers les environnements. L’immuabilité qui cause le chaos est aussi ce qui rend le retour arrière trivial — repointez vers l’ancien ARN.
  5. Retirez les vieilles versions délibérément. Ne supprimez une version de layer qu’après avoir confirmé qu’aucune fonction ne la référence (l’audit de flotte ci-dessus), et gardez la dernière version reconnue bonne jusqu’à ce que la suivante ait survécu un moment en production.

Quand ce n’est pas la bonne approche

Si vos dépendances sont assez grosses ou nombreuses pour que vous vous battiez contre la limite de 250 Mo, cessez de vous battre — l’empaquetage en image de conteneur monte le plafond à 10 Go et amène l’outillage de dépendances Docker normal avec lui. Si une seule fonction utilise une dépendance, un layer ajoute de l’indirection sans gain de réutilisation; empaquetez-la. Et n’adoptez pas les layers en espérant des démarrages à froid plus rapides — ce bénéfice est du folklore, comme couvert dans Démarrages à froid Lambda : ce qui aide vraiment.

Erreurs fréquentes

  • Mauvaise structure de répertoires dans le zip, produisant des erreurs Unable to import module sur un layer qui s’est attaché sans se plaindre.
  • Bâtir sur macOS et livrer des fichiers .so natifs qu’Amazon Linux ne peut pas charger.
  • Considérer la version de layer la plus récente comme implicitement déployée partout, parce que rien dans la console n’avertit de la dérive.
  • Supprimer de vieilles versions de layer pendant le ménage et briser le prochain déploiement d’une fonction que personne ne se rappelait encore épinglée à la version 3.

Garder le contrôle

  • Roulez l’audit de dérive de la flotte chaque mois et traitez plus de deux versions actives du même layer comme un constat.
  • Tenez un journal des changements par layer — version, contenu, changements cassants — puisqu’AWS ne stocke qu’un champ de description.
  • Nommez les layers par contenu et version majeure (pg-driver-v2) pour que les refontes incompatibles reçoivent un nouveau nom plutôt qu’un saut de version surprenant.
  • Ajoutez une vérification CI qui échoue quand la taille décompressée combinée fonction-plus-layers dépasse un seuil interne sous les 250 Mo durs.

Les layers sont un outil d’empaquetage correct déguisé en gestionnaire de dépendances — traitez chaque version de layer comme un artéfact de mise en production, épinglé et promu à travers les environnements, et le chaos ne commence jamais. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.