**Aidez à améliorer cette page** 

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.

Pour contribuer à ce guide de l'utilisateur, cliquez sur le GitHub lien **Modifier cette page sur** qui se trouve dans le volet droit de chaque page.

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.

# Créez une variante personnalisée de l'AMI Bottlerocket pour Amazon EKS
<a name="bottlerocket-custom-variant"></a>

Lorsque vous exécutez des charges de travail GPU sur Amazon Elastic Kubernetes Service (Amazon EKS), vous choisissez une variante de Bottlerocket. La variante doit correspondre à votre version de Kubernetes et à votre type d'accélérateur. Bottlerocket propose des variantes validées pour les configurations courantes. Toutefois, il se peut que votre organisation ait besoin d'une autre variante pour l'une des raisons suivantes :
+ Une nouvelle branche de pilotes NVIDIA
+ Une version pilote épinglée pour la conformité réglementaire
+ Packages supplémentaires pour la surveillance
+ Une base de référence renforcée requise par votre équipe de sécurité

Comme [Bottlerocket](https://github.com/bottlerocket-os/bottlerocket) sur le GitHub site Web est entièrement open source, vous pouvez créer une variante personnalisée qui répond à ces besoins. Cette rubrique explique comment cloner une variante existante et remplacer le pilote NVIDIA de la branche R580 par le pilote R595 (version 595.71.05). Vous créez ensuite l'image et vous l'enregistrez en tant qu'AMI privée.

**Important**  
Le type d'instance G7 EC2 nécessite la version 595 ou ultérieure du pilote NVIDIA. Les AMI NVIDIA EKS Bottlerocket incluent actuellement la version 580 du pilote NVIDIA, qui ne prend pas en charge les instances G7.  
Consultez le [référentiel Bottlerocket](https://github.com/bottlerocket-os/bottlerocket) sur le GitHub site Web pour obtenir des instructions sur la création d'une variante avec la version 595 du pilote NVIDIA. Cette rubrique décrit le processus complet à partir de l'[étape 1](#bottlerocket-custom-variant-step1).

## Comment fonctionne le système de compilation
<a name="bottlerocket-custom-variant-build-system"></a>

Lorsque vous courez`cargo make -e BUILDSYS_VARIANT=aws-k8s-1.36-nvidia`, trois choses se produisent :
+  **Récupérez les dépendances.** Twoliter (l'orchestrateur de build de Bottlerocket) lit `Twoliter.toml` et extrait trois artefacts de l'Open Container Initiative (OCI) à partir de : `public.ecr.aws/bottlerocket`
  +  **bottlerocket-sdk** — une image de conteneur contenant la chaîne d'outils complète de compilation croisée (macros GCC, Rust, Go, RPM).
  +  **bottlerocket-kernel-kit** — RPM prédéfinis pour les noyaux, les modules de noyau (y compris les packages NVIDIA kmod) et les micrologiciels.
  +  **bottlerocket-core-kit** — RPM prédéfinis pour l'espace utilisateur : kubelet, containerd, le plugin pour appareils NVIDIA et la boîte à outils de conteneurs, les plugins de paramètres et les services système.

     `Twoliter.toml`épingle les versions et `Twoliter.lock` verrouille leurs résumés. Pour modifier l'un ou l'autre, exécutez `./tools/twoliter/twoliter update` pour résoudre à nouveau.
+  **Créez la variante.** Twoliter lance une version Docker dans le conteneur du SDK. Il compile la caisse de paramètres par défaut de votre variante, résout l'arbre de dépendance RPM à partir des kits et assemble le tout dans une image disque.
+  **Sortie.** Twoliter écrit le `.img.lz4` fichier final dans. `build/images/` Le build produit un résultat déterministe : les mêmes `Twoliter.toml` pins et variantes génèrent `Cargo.toml` toujours la même image, quel que soit l'hôte.

## Disposition du référentiel
<a name="bottlerocket-custom-variant-repo-layout"></a>

Les répertoires suivants sont pertinents pour le travail sur les variantes :

```
bottlerocket/
├── Cargo.toml                       # workspace: lists every variant
├── Twoliter.toml                    # pins SDK + kit versions
├── Twoliter.lock                    # locked digests for the above
├── Licenses.toml                    # you create this (NVIDIA license acknowledgement)
├── Infra.toml                       # you create this (AMI publish regions)
│
├── variants/
│   ├── aws-k8s-1.36-nvidia/         # example variant you'll copy
│   │   ├── Cargo.toml               #   package list + kernel params
│   │   └── amispec.toml             #   symlink → ../shared/amispec-split.toml
│   └── shared/                      # shared AMI spec templates
│
├── sources/
│   ├── Cargo.toml                   # workspace: lists every settings-defaults crate
│   ├── shared-defaults/             # the actual defaults (symlink targets)
│   └── settings-defaults/
│       └── aws-k8s-1.36-nvidia/
│           ├── Cargo.toml
│           └── defaults.d/          # 30+ symlinks into shared-defaults/
│
└── packages/
    ├── settings-defaults/
    │   └── settings-defaults.spec   # RPM: declares which variants exist
    └── settings-plugins/
        └── settings-plugins.spec    # RPM: maps variants to settings plugins
```

Consultez les remarques suivantes concernant la structure du référentiel :
+ Une variante est principalement constituée de métadonnées. Les kits externes fournissent le noyau, les pilotes et l'espace utilisateur.
+ Settings-defaults les fichiers sont des liens symboliques et non des copies. À utiliser `cp -R` (sauf `cp -r` sur macOS) pour les conserver.
+ L'ajout d'une variante nécessite des modifications à cinq endroits : deux `Cargo.toml` fichiers d'espace de travail, deux `.spec` fichiers et`README.md`.

## Conditions préalables
<a name="bottlerocket-custom-variant-prereqs"></a>

Pour terminer la procédure pas à pas, vous devez :
+ Un AWS compte autorisé à lancer des instances EC2 et à enregistrer des AMI
+ Une instance EC2 (ou un hôte Linux x86\_64 équivalent) avec au moins 8 cœurs, 16 Go de mémoire et 150 Go de disque
+ Ubuntu 24.04 LTS (ou Fedora ; macOS n'est pas pris en charge en tant qu'hôte de build)
+ Docker 20.10 ou version ultérieure
+ Rust (chaîne d'outils stable, installée via rustup)
+ cargo-make (dernière version)
+ Connaissance des concepts de packaging Git, Rust Cargo et RPM

**Note**  
Lorsque vous aurez terminé cette procédure pas à pas, mettez fin à l'instance EC2 et annulez l'enregistrement des AMI dont vous n'avez plus besoin pour éviter des frais récurrents. Pour obtenir des instructions sur le nettoyage, voir[Nettoyage](#bottlerocket-custom-variant-cleanup).

## Étape 1 : préparer l'hôte de compilation
<a name="bottlerocket-custom-variant-step1"></a>

Lancez une instance EC2, par exemple une `c7i.8xlarge` (32 vCPU, 64 GiB de mémoire). Utilisez un volume racine gp3 de 150 Go et attachez la politique `AmazonSSMManagedInstanceCore` gérée pour l'accès SSM.

Connectez-vous à l'instance à l'aide du gestionnaire de session AWS Systems Manager (SSM) :

```
aws ssm start-session --target <instance-id>
cd ~
```

Installez les packages de système d'exploitation requis :

```
apt-get update
apt-get install -y build-essential openssl libssl-dev pkg-config lz4 \
                   git ca-certificates curl gnupg
```

**Note**  
Les `BUILDING.md` références officielles`liblz4-tool`. Dans les versions récentes d'Ubuntu, le package est nommé`lz4`.

Installez Docker à l'aide des commandes suivantes :

```
install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg \
  -o /etc/apt/keyrings/docker.asc
chmod a+r /etc/apt/keyrings/docker.asc
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] \
  https://download.docker.com/linux/ubuntu noble stable" \
  > /etc/apt/sources.list.d/docker.list
apt-get update
apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin
systemctl enable --now docker
```

Installez Rust et cargo-make à l'aide des commandes suivantes :

```
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y
. "$HOME/.cargo/env"
cargo install cargo-make
```

## Étape 2 : Cloner le dépôt
<a name="bottlerocket-custom-variant-step2"></a>

Clonez le [référentiel Bottlerocket](https://github.com/bottlerocket-os/bottlerocket) sur le GitHub site Web et naviguez dans le répertoire :

```
cd ~/bottlerocket
```

Pour créer une version reproductible, consultez une version étiquetée (par exemple,`git checkout v1.62.1`). Pour utiliser les derniers packages, restez sur la `develop` succursale.

## Étape 3 : vérifier les versions du kit
<a name="bottlerocket-custom-variant-step3"></a>

Ouvrez `Twoliter.toml` et confirmez les versions du kit. Pour le support du R595, vous avez besoin de `bottlerocket-kernel-kit` la version 6.2.2 ou ultérieure :

```
[[kit]]
name = "bottlerocket-kernel-kit"
version = "6.2.2"
vendor = "bottlerocket"
```

Si la version est plus ancienne, mettez-la à jour et régénérez le verrou :

```
./tools/twoliter/twoliter update
```

## Étape 4 : contourner le problème du chemin de fabrication de la cargaison
<a name="bottlerocket-custom-variant-step4"></a>

Deux litres se fixent `CARGO_HOME` à`~/bottlerocket/.cargo`, ce qui empêche le processus interne de chargement de trouver votre marque de cargaison installée dans le monde entier. Créer un lien symbolique

```
mkdir -p ~/bottlerocket/.cargo/bin
ln -sf /root/.cargo/bin/cargo-make ~/bottlerocket/.cargo/bin/cargo-make
```

Sans cette étape, la compilation échoue avec`error: no such command: make`.

## Étape 5 : Trouvez les succursales de chauffeurs disponibles
<a name="bottlerocket-custom-variant-step5"></a>

Les packages NVIDIA kmod sont livrés à l'intérieur`bottlerocket-kernel-kit`. Pour plus d'informations sur les packages de pilotes disponibles, consultez le [répertoire des packages kernel-kit](https://github.com/bottlerocket-os/bottlerocket-kernel-kit) sur le GitHub site Web ou les [notes de version](https://github.com/bottlerocket-os/bottlerocket-kernel-kit/releases) sur le GitHub site Web.

Pour le noyau 6.18 (utilisé par les `aws-k8s-1.36` variantes) :

```
kmod-6.18-nvidia-r580   ← driver 580.159.03 (current default)
kmod-6.18-nvidia-r595   ← driver 595.71.05
```

Pour le noyau 6.12 (utilisé par`aws-k8s-1.33`,`1.34`,`1.35`) :

```
kmod-6.12-nvidia-r580
kmod-6.12-nvidia-r595
```

**Note**  
Chaque package kmod contient des sous-packages (`-tesla`,,`-open-gpu`, `-grid``-fabricmanager`,`-imex`). La référence officielle des variantes NVIDIA de Bottlerocket`-tesla`, qui extrait tous les sous-packages requis via des dépendances RPM. Au démarrage, Bottlerocket sélectionne automatiquement la variante de pilote appropriée en fonction du type d'instance.

## Étape 6 : Création de la nouvelle variante
<a name="bottlerocket-custom-variant-step6"></a>

Copiez la variante existante. `cp -R`À utiliser pour préserver les liens symboliques :

```
cp -R variants/aws-k8s-1.36-nvidia variants/aws-k8s-1.36-nvidia-595
cp -R sources/settings-defaults/aws-k8s-1.36-nvidia \
      sources/settings-defaults/aws-k8s-1.36-nvidia-595
```

Modifier `variants/aws-k8s-1.36-nvidia-595/Cargo.toml` :

```
- name = "aws-k8s-1_36-nvidia"
+ name = "aws-k8s-1_36-nvidia-595"

- "kmod-6.18-nvidia-r580-tesla",
+ "kmod-6.18-nvidia-r595-tesla",
```

Modifier `sources/settings-defaults/aws-k8s-1.36-nvidia-595/Cargo.toml` :

```
- name = "settings-defaults-aws-k8s-1_36-nvidia"
+ name = "settings-defaults-aws-k8s-1_36-nvidia-595"
```

## Étape 7 : Enregistrer la variante
<a name="bottlerocket-custom-variant-step7"></a>

Enregistrez la nouvelle variante dans cinq fichiers :

 **1. `Cargo.toml`**— ajoutez le membre de l'espace de travail :

```
 "variants/aws-k8s-1.36-nvidia",
+    "variants/aws-k8s-1.36-nvidia-595",
 "variants/aws-k8s-1.36-nvidia-fips",
```

 **2. `sources/Cargo.toml`**— ajoute le membre settings-defaults :

```
 "settings-defaults/aws-k8s-1.36-nvidia",
+    "settings-defaults/aws-k8s-1.36-nvidia-595",
```

 **3. `packages/settings-defaults/settings-defaults.spec`**— ajoute un `%package` bloc, des entrées dans les deux boucles de construction et une `%files` section :

```
%package aws-k8s-1.36-nvidia-595
Summary: Settings defaults for the aws-k8s 1.36 nvidia-595 variant
Requires: %{_cross_os}variant(aws-k8s-1.36-nvidia-595)
Provides: %{_cross_os}settings-defaults(any)
Provides: %{_cross_os}settings-defaults(aws-k8s-1.36-nvidia-595)
Conflicts: %{_cross_os}settings-defaults(any)

%description aws-k8s-1.36-nvidia-595
%{summary}.
```

Ajoutez aux deux `for defaults in` boucles :

```
    aws-k8s-1.36-nvidia \
+   aws-k8s-1.36-nvidia-595 \
    metal-dev \
```

Ajoutez la `%files` section :

```
%files aws-k8s-1.36-nvidia-595
%{_cross_defaultsdir}/aws-k8s-1.36-nvidia-595.toml
%{_cross_tmpfilesdir}/storewolf-defaults-aws-k8s-1.36-nvidia-595.conf
```

 **4. `packages/settings-plugins/settings-plugins.spec`**— ajoute une `Provides:` ligne sous `%package aws-k8s-nvidia` :

```
 Provides: %{_cross_os}settings-plugin(aws-k8s-1.36-nvidia)
+Provides: %{_cross_os}settings-plugin(aws-k8s-1.36-nvidia-595)
 Conflicts: %{_cross_os}settings-plugin(any)
```

## Étape 8 : Actualiser le fichier de verrouillage
<a name="bottlerocket-custom-variant-step8"></a>

L'ajout d'un membre de l'espace de travail est invalide`sources/Cargo.lock`. Rafraîchissez-le :

```
cd ~/bottlerocket/sources
cargo update --workspace
```

**Important**  
N'utilisez pas`cargo generate-lockfile`. Il réécrit l'intégralité du fichier de verrouillage et supprime les dépendances transitives, ce qui entraîne des erreurs de version dupliquée. `cargo-deny`

## Étape 9 : Création du fichier de licence NVIDIA
<a name="bottlerocket-custom-variant-step9"></a>

NVIDIA restreint la redistribution des sources de pilotes. Vous devez ajouter un accusé de réception de licence explicite avant de créer :

```
cat > ~/bottlerocket/Licenses.toml <<'EOF'
[nvidia]
spdx-id = "LicensesRef-NVIDIA-Customer-Use"
licenses = [
  { path = "LICENSE", license-url = "https://www.nvidia.com/en-us/drivers/nvidia-license/" }
]
EOF
```

## Étape 10 : créer et publier l'AMI
<a name="bottlerocket-custom-variant-step10"></a>

Créez une `Infra.toml` annonce avec vos régions cibles :

```
cat > ~/bottlerocket/Infra.toml <<'EOF'
[aws]
regions = ["us-west-2", "us-east-1", "us-east-2"]
EOF
```

Créez l'image :

```
cd ~/bottlerocket
cargo make \
  -e BUILDSYS_VARIANT=aws-k8s-1.36-nvidia-595 \
  -e BUILDSYS_UPSTREAM_SOURCE_FALLBACK=true \
  -e BUILDSYS_UPSTREAM_LICENSE_FETCH=true \
  -e BUILDSYS_JOBS=32
```

La première version extrait le SDK et les images du kit (environ 2 Go au total). Les builds suivants prennent de 3 à 5 minutes sur un hôte à 32 cœurs.

Publiez l'AMI :

```
cargo make \
  -e BUILDSYS_VARIANT=aws-k8s-1.36-nvidia-595 \
  -e PUBLISH_REGIONS=us-west-2,us-east-1,us-east-2 \
  ami
```

Le build écrit des identifiants d'AMI dans`build/images/x86_64-aws-k8s-1.36-nvidia-595/latest/*-amis.json`. Utilisez-les dans vos groupes de nœuds gérés par EKS, dans Karpenter `EC2NodeClass` ou dans vos modèles de lancement.

## Autres combinaisons que vous pouvez créer
<a name="bottlerocket-custom-variant-other-combinations"></a>

Cette procédure pas à pas remplace la branche du pilote NVIDIA, mais vous pouvez utiliser la même approche pour tous les packages disponibles dans les kits en amont. Les exemples suivants montrent ce que vous pouvez assembler sans avoir à bifurquer un kit :


| Ce que tu veux | Ce qu'il faut changer dans la variante `Cargo.toml`  | 
| --- | --- | 
| Branche de pilotes NVIDIA différente |  `kmod-6.18-nvidia-r580-tesla` → `kmod-6.18-nvidia-r595-tesla`  | 
| Version de noyau différente |  `kernel-6.18`→ `kernel-6.12` (ajustez le kmod en conséquence) | 
| Supprimer complètement NVIDIA | Supprimez les trois `nvidia-*` lignes de `included-packages`  | 
| Ajouter le support EFA | Ajouter `kmod-6.18-efa` à `included-packages`  | 
| Changer de version d'exécution du conteneur |  `containerd-2.2` → `containerd-2.1`  | 

Pour plus d'informations sur les packages disponibles, consultez le [kit de noyau](https://github.com/bottlerocket-os/bottlerocket-kernel-kit) sur le GitHub site Web et le [kit de base sur le site Web](https://github.com/bottlerocket-os/bottlerocket-core-kit). GitHub 

**Important**  
Le système de fichiers racine de Bottlerocket est immuable. Vous ne pouvez pas installer de packages au moment de l'exécution. Chaque package des kits est compilé de manière croisée spécifiquement pour Bottlerocket : les RPM standard en amont ne fonctionnent pas. Si vous avez besoin d'un logiciel qui n'est pas déjà inclus dans un kit, envisagez [des conteneurs bootstrap](https://github.com/bottlerocket-os/bottlerocket#bootstrap-containers-settings) sur le GitHub site Web ou [des conteneurs hôtes](https://github.com/bottlerocket-os/bottlerocket#host-containers) sur le GitHub site Web comme alternative d'exécution.

## Nettoyage
<a name="bottlerocket-custom-variant-cleanup"></a>

Si vous n'avez plus besoin de l'hôte de build, mettez fin à l'instance EC2 pour éviter des frais récurrents. Les AMI sont conservées indépendamment dans votre compte ; désenregistrez-les avec la console EC2 ou la CLI si vous n'en avez plus besoin.

## Résumé
<a name="bottlerocket-custom-variant-summary"></a>

Cette rubrique explique comment créer une variante personnalisée de Bottlerocket avec une branche de pilote NVIDIA différente. Le processus consiste à copier une variante existante, à modifier une référence de package, à enregistrer la nouvelle variante dans l'espace de travail et dans les spécifications RPM, puis à exécuter le build. La même approche s'applique à toute personnalisation : échange de versions du noyau, ajout de packages ou création de variantes pour les nouvelles versions de Kubernetes.