Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Des mises en cache pour améliorer les performances Vous pouvez faire des économies lors de vos générations de projet en utilisant un cache. Un cache peut stocker les éléments réutilisables de votre environnement de génération et les utiliser sur plusieurs générations. Votre projet de génération peut utiliser l'un des deux types de mise en cache suivants : Amazon S3 ou local. Si vous utilisez un cache local, vous devez choisir un ou plusieurs des trois modes de cache : le cache source, le cache de couche Docker et le cache personnalisé. **Note** Le mode de cache de couche Docker est disponible pour l'environnement Linux uniquement. Si vous choisissez ce mode, vous devez exécuter votre build en mode privilégié. CodeBuild le mode privilégié des projets accorde à son conteneur l'accès à tous les appareils. Pour de plus amples informations, veuillez consulter [Privilège d'exécution et fonctionnalités Linux](https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities) sur le site web Docker Docs. **Topics** + [Mise en cache d'Amazon S3](caching-s3.md) + [Mise en cache locale](caching-local.md) + [Spécifier un cache local](specify-caching-local.md) # Mise en cache d'Amazon S3 La mise en cache Amazon S3 stocke le cache dans un compartiment Amazon S3 disponible sur plusieurs hôtes de build. C'est une bonne option pour les artefacts de construction de petite ou moyenne taille qui sont plus coûteux à créer qu'à télécharger. Pour utiliser Amazon S3 dans une version, vous pouvez spécifier les chemins des fichiers que vous souhaitez mettre en cache`buildspec.yml`. CodeBuild stockera et mettra automatiquement à jour le cache à l'emplacement Amazon S3 configuré sur le projet. Si vous ne spécifiez pas les chemins des fichiers, CodeBuild nous ferons de notre mieux pour mettre en cache les dépendances linguistiques courantes afin d'accélérer les compilations. Vous pouvez consulter les détails du cache dans les journaux de compilation. En outre, si vous souhaitez disposer de plusieurs versions du cache, vous pouvez définir une clé de cache dans le`buildspec.yml`. CodeBuild stocke le cache dans le contexte de cette clé de cache et crée une copie de cache unique qui ne sera pas mise à jour une fois créée. Les clés de cache peuvent également être partagées entre les projets. Les fonctionnalités telles que les clés dynamiques, le versionnement du cache et le partage du cache entre les versions ne sont disponibles que lorsqu'une clé est spécifiée. Pour en savoir plus sur la syntaxe du cache dans le fichier buildspec, consultez [cache](build-spec-ref.md#build-spec.cache) la référence buildspec. **Topics** + [Génération de clés dynamiques](#caching-s3-dynamic) + [codebuild-hash-files](#caching-s3-dynamic.codebuild-hash-files) + [Version du cache](#caching-s3-version) + [Partage du cache entre projets](#caching-s3-sharing) + [Exemples de spécifications de construction](#caching-s3-examples) ## Génération de clés dynamiques Une clé de cache peut inclure des commandes shell et des variables d'environnement pour la rendre unique, ce qui permet des mises à jour automatiques du cache en cas de modification de clé. Par exemple, vous pouvez définir une clé en utilisant le hachage du `package-lock.json` fichier. Lorsque les dépendances de ce fichier changent, le hachage, et donc la clé de cache, change, ce qui déclenche la création automatique d'un nouveau cache. ``` cache: key: npm-key-$(codebuild-hash-files package-lock.json) ``` CodeBuild évaluera l'expression `$(codebuild-hash-files package-lock.json)` pour obtenir la clé finale : ``` npm-key-abc123 ``` Vous pouvez également définir une clé de cache à l'aide de variables d'environnement, telles que`CODEBUILD_RESOLVED_SOURCE_VERSION`. Cela garantit que chaque fois que votre source change, une nouvelle clé est générée, ce qui entraîne l'enregistrement automatique d'un nouveau cache : ``` cache: key: npm-key-$CODEBUILD_RESOLVED_SOURCE_VERSION ``` CodeBuild évaluera l'expression et obtiendra la clé finale : ``` npm-key-046e8b67481d53bdc86c3f6affdd5d1afae6d369 ``` ## codebuild-hash-files `codebuild-hash-files`est un outil CLI qui calcule un hachage SHA-256 pour un ensemble de fichiers du répertoire CodeBuild source à l'aide de modèles globaux : ``` codebuild-hash-files ... ``` Voici quelques exemples d'utilisation de `codebuild-hash-files` : ``` codebuild-hash-files package-lock.json codebuild-hash-files '**/*.md' ``` ## Version du cache La version du cache est un hachage généré à partir des chemins des répertoires mis en cache. Si deux caches ont des versions différentes, ils sont traités comme des caches distincts pendant le processus de mise en correspondance. Par exemple, les deux caches suivants sont considérés comme différents car ils font référence à des chemins différents : ``` version: 0.2 phases: build: commands: - pip install pandas==2.2.3 --target pip-dependencies cache: key: pip-dependencies paths: - "pip-dependencies/**/*" ``` ``` version: 0.2 phases: build: commands: - pip install pandas==2.2.3 --target tmp/pip-dependencies cache: key: pip-dependencies paths: - "tmp/pip-dependencies/**/*" ``` ## Partage du cache entre projets Vous pouvez utiliser le champ `cacheNamespace` API situé sous la `cache` section pour partager un cache entre plusieurs projets. Ce champ définit l'étendue du cache. Pour partager un cache, vous devez effectuer les opérations suivantes : + Utilise le même`cacheNamespace`. + Spécifiez le même cache`key`. + Définissez des chemins de cache identiques. + Utilisez les mêmes compartiments Amazon S3 et `pathPrefix` s'ils sont définis. Cela garantit la cohérence et permet le partage du cache entre les projets. ### Spécifier un espace de noms de cache (console) 1. Ouvrez la AWS CodeBuild console sur [https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home). 1. Sélectionnez **Create a project (Créer un projet)**. Pour plus d’informations, consultez [Création d'un projet de génération (console)](create-project.md#create-project-console) et [Exécution d'une génération (console)](run-build-console.md). 1. Dans **Artefacts**, sélectionnez **Configuration supplémentaire**. 1. Pour **le type de cache**, choisissez **Amazon S3**. 1. Pour **Espace de noms du cache - facultatif**, entrez une valeur d'espace de noms. ![\[Paramètre d'espace de noms du cache dans la CodeBuild console.\]](http://docs.aws.amazon.com/fr_fr/codebuild/latest/userguide/images/s3-cache-namespace.png) 1. Continuez avec les valeurs par défaut, puis choisissez **Create build project**. ### Spécifiez un espace de noms de cache ()AWS CLI Vous pouvez utiliser le `--cache` paramètre dans le AWS CLI pour spécifier un espace de noms de cache. ``` --cache '{"type": "S3", "location": "your-s3-bucket", "cacheNamespace": "test-cache-namespace"}' ``` ## Exemples de spécifications de construction Voici plusieurs exemples de spécifications de construction pour les langages courants : **Topics** + [Cache les dépendances de Node.js](#caching-s3-examples.nodejs) + [Dépendances du cache en Python](#caching-s3-examples.python) + [Dépendances du cache Ruby](#caching-s3-examples.ruby) + [Dépendances de Cache Go](#caching-s3-examples.go) ### Cache les dépendances de Node.js Si votre projet inclut un `package-lock.json` fichier et l'utilise `npm` pour gérer les dépendances de Node.js, l'exemple suivant montre comment configurer la mise en cache. Par défaut, `npm` installe les dépendances dans le `node_modules` répertoire. ``` version: 0.2 phases: build: commands: - npm install cache: key: npm-$(codebuild-hash-files package-lock.json) paths: - "node_modules/**/*" ``` ### Dépendances du cache en Python Si votre projet inclut un `requirements.txt` fichier et utilise pip pour gérer les dépendances Python, l'exemple suivant montre comment configurer la mise en cache. Par défaut, pip installe les packages dans le répertoire du `site-packages` système. ``` version: 0.2 phases: build: commands: - pip install -r requirements.txt cache: key: python-$(codebuild-hash-files requirements.txt) paths: - "/root/.pyenv/versions/${python_version}/lib/python${python_major_version}/site-packages/**/*" ``` En outre, vous pouvez installer des dépendances dans un répertoire spécifique et configurer la mise en cache pour ce répertoire. ``` version: 0.2 phases: build: commands: - pip install -r requirements.txt --target python-dependencies cache: key: python-$(codebuild-hash-files requirements.txt) paths: - "python-dependencies/**/*" ``` ### Dépendances du cache Ruby Si votre projet inclut un `Gemfile.lock` fichier et l'utilise `Bundler` pour gérer les dépendances des gemmes, l'exemple suivant montre comment configurer efficacement la mise en cache. ``` version: 0.2 phases: build: commands: - bundle install --path vendor/bundle cache: key: ruby-$(codebuild-hash-files Gemfile.lock) paths: - "vendor/bundle/**/*" ``` ### Dépendances de Cache Go Si votre projet inclut un `go.sum` fichier et utilise des modules Go pour gérer les dépendances, l'exemple suivant montre comment configurer la mise en cache. Par défaut, les modules Go sont téléchargés et stockés dans le `${GOPATH}/pkg/mod` répertoire. ``` version: 0.2 phases: build: commands: - go mod download cache: key: go-$(codebuild-hash-files go.sum) paths: - "/go/pkg/mod/**/*" ``` # Mise en cache locale La mise en cache locale stocke un cache localement sur un hôte de génération. Le cache est disponible uniquement sur cet hôte de génération. C'est une bonne option pour les artefacts de build de taille intermédiaire à grande, car le cache est immédiatement disponible sur l'hôte de build. Ce n'est pas la meilleure option si vos builds sont rares. Cela signifie que les performances de génération ne sont pas affectés par le temps de transfert réseau. Si vous choisissez la mise en cache locale, vous devez choisir un ou plusieurs des modes de cache suivants : + Le mode de cache source met en cache des métadonnées Git pour des sources principales et secondaires. Lorsque le cache est créé, les générations suivantes extraient uniquement les modifications apportées entre les validations. Ce mode est un bon choix pour les projets avec un répertoire de travail propre et une source correspondant à un référentiel Git de grande taille. Si vous choisissez cette option et que votre projet n'utilise pas de référentiel Git (AWS CodeCommit, GitHub, GitHub Enterprise Server ou Bitbucket), l'option est ignorée. + Le mode de cache de couche Docker met en cache des couches Docker existantes. Ce mode est un bon choix pour les projets qui génèrent ou extraient des images Docker de taille importante. Il permet d'éviter les problèmes de performances causées par l'extraction d'images Docker de grande taille à partir du réseau. **Note** Vous pouvez utiliser un cache de couche Docker uniquement dans l'environnement Linux. L'indicateur `privileged` doit être défini de sorte que votre projet dispose des autorisations Docker requises. Par défaut, le démon Docker est activé pour les versions non VPC. Si vous souhaitez utiliser des conteneurs Docker pour les builds VPC, [consultez Runtime Privilege et Linux](https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities) Capabilities sur le site Web de Docker Docs et activez le mode privilégié. De plus, Windows ne prend pas en charge le mode privilégié. Vous devez prendre en compte les implications de sécurité avant d'utiliser un cache de couche Docker. + Le mode de cache personnalisé met en cache les répertoires que vous spécifiez dans le fichier buildspec. Ce mode est un bon choix si votre scénario de génération n'est pas adapté à un des deux autres modes de cache local. Si vous utilisez un cache personnalisé : + Seuls les répertoires peuvent être spécifiés pour la mise en cache. Vous ne pouvez pas spécifier de fichiers individuels. + Les liens symboliques sont utilisés pour référencer les répertoires mis en cache. + Les répertoires mis en cache sont liés à votre génération avant que ses sources de projet soient téléchargées. Les éléments mis en cache remplacent les éléments source s'ils portent le même nom. Les répertoires sont spécifiés à l'aide de chemins de cache dans le fichier buildspec. Pour de plus amples informations, veuillez consulter [Syntaxe d'un fichier buildspec](build-spec-ref.md#build-spec-ref-syntax). + Évitez les noms de répertoire identiques dans la source et dans le cache. Les répertoires mis en cache localement peuvent remplacer ou supprimer le contenu des répertoires du référentiel source portant le même nom. **Note** La mise en cache locale n'est pas prise en charge avec le type d'`LINUX_GPU_CONTAINER`environnement et le type de `BUILD_GENERAL1_2XLARGE` calcul. Pour de plus amples informations, veuillez consulter [Modes et types de calcul de l'environnement de création](build-env-ref-compute-types.md). **Note** La mise en cache locale n'est pas prise en charge lorsque vous configurez CodeBuild pour fonctionner avec un VPC. Pour plus d'informations sur l'utilisation VPCs avec CodeBuild, consultez[Utilisation AWS CodeBuild avec Amazon Virtual Private Cloud](vpc-support.md). # Spécifier un cache local Vous pouvez utiliser la console AWS CLI, le SDK ou CloudFormation pour spécifier un cache local. Pour plus d'informations sur la mise en cache locale, consultez[Mise en cache locale](caching-local.md). **Topics** + [Spécification d'une mise en cache locale (CLI)](#caching-local-cli) + [Spécification d'une mise en cache locale (console)](#caching-local-console) + [Spécification d'une mise en cache locale (CloudFormation)](#caching-local-cfn) ## Spécification d'une mise en cache locale (CLI) Vous pouvez utiliser le `--cache` paramètre dans le AWS CLI pour spécifier chacun des trois types de cache locaux. + Pour spécifier un cache source : ``` --cache type=LOCAL,mode=[LOCAL_SOURCE_CACHE] ``` + Pour spécifier un cache de couche Docker : ``` --cache type=LOCAL,mode=[LOCAL_DOCKER_LAYER_CACHE] ``` + Pour spécifier un cache personnalisé : ``` --cache type=LOCAL,mode=[LOCAL_CUSTOM_CACHE] ``` Pour de plus amples informations, veuillez consulter [Création d'un projet de génération (AWS CLI)](create-project.md#create-project-cli). ## Spécification d'une mise en cache locale (console) Vous spécifiez un cache dans la section **Artifacts (Artefacts)** de la console. Pour **le type de cache**, choisissez **Amazon S3** ou **Local**. Si vous choisissez **Local**, choisissez une ou plusieurs des trois options de cache local. ![\[Spécifiez un cache local en choisissant une ou plusieurs des trois options de cache local.\]](http://docs.aws.amazon.com/fr_fr/codebuild/latest/userguide/images/local-cache.png) Pour de plus amples informations, veuillez consulter [Création d'un projet de génération (console)](create-project.md#create-project-console). ## Spécification d'une mise en cache locale (CloudFormation) Si vous avez l' CloudFormation habitude de spécifier un cache local, sur la `Cache` propriété, pour`Type`, spécifiez`LOCAL`. L'exemple de CloudFormation code au format YAML suivant spécifie les trois types de cache locaux. Vous pouvez spécifier n'importe quelle combinaison de types. Si vous utilisez un cache de couche Docker, sous `Environment`, vous devez définir `PrivilegedMode` sur `true` et `Type` sur `LINUX_CONTAINER`. ``` CodeBuildProject: Type: AWS::CodeBuild::Project Properties: Name: MyProject ServiceRole: Artifacts: Type: S3 Location: Name: myArtifact EncryptionDisabled: true OverrideArtifactName: true Environment: Type: LINUX_CONTAINER ComputeType: BUILD_GENERAL1_SMALL Image: aws/codebuild/standard:5.0 Certificate: # PrivilegedMode must be true if you specify LOCAL_DOCKER_LAYER_CACHE PrivilegedMode: true Source: Type: GITHUB Location: InsecureSsl: true GitCloneDepth: 1 ReportBuildStatus: false TimeoutInMinutes: 10 Cache: Type: LOCAL Modes: # You can specify one or more cache mode, - LOCAL_CUSTOM_CACHE - LOCAL_DOCKER_LAYER_CACHE - LOCAL_SOURCE_CACHE ``` **Note** Par défaut, le démon Docker est activé pour les versions non VPC. Si vous souhaitez utiliser des conteneurs Docker pour les builds VPC, [consultez Runtime Privilege et Linux](https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities) Capabilities sur le site Web de Docker Docs et activez le mode privilégié. De plus, Windows ne prend pas en charge le mode privilégié. Pour de plus amples informations, veuillez consulter [Création d'un projet de génération (CloudFormation)](create-project.md#create-project-cloud-formation).