> ## Documentation Index
> Fetch the complete documentation index at: https://docs.coreweave.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Configurer l’agent Launch

> Configurez les options avancées de l’agent pour W&B Launch, notamment les générateurs Docker et Kaniko ainsi que les paramètres du registre de conteneurs.

<h1 id="advanced-agent-setup">
  Configuration avancée de l’agent
</h1>

Ce guide explique comment configurer l’agent W\&B Launch pour builder des images de conteneur dans différents environnements, téléverser ces images vers des registres de conteneurs cloud et personnaliser le processus de build. Consultez-le si vous devez exécuter des jobs Launch nécessitant le build d’images et que vous souhaitez contrôler où et comment l’agent produit ces images. Cette page s’adresse aux administrateurs et aux opérateurs qui déploient et gèrent l’agent Launch.

<Note>
  Le build n’est requis que pour les jobs Git et les jobs d’artifact de code. Les jobs d’image n’en nécessitent pas.

  Pour plus d’informations sur les types de jobs, consultez [Créer un job Launch](/fr/products/wandb/platform/launch/create-launch-job).
</Note>

<h2 id="builders">
  Générateurs
</h2>

L’agent Launch prend en charge deux générateurs pour produire des images de conteneur. Choisissez le générateur adapté à l’environnement dans lequel l’agent s’exécute.

L’agent Launch peut builder des images à l’aide de [Docker](https://docs.docker.com/) ou de [Kaniko](https://github.com/GoogleContainerTools/kaniko).

* Kaniko : builde une image de conteneur dans Kubernetes sans avoir à exécuter le build dans un conteneur privilégié.
* Docker : builde une image de conteneur en exécutant localement une commande `docker build`.

Le type de générateur est défini par la clé `builder.type` dans la configuration de l’agent Launch. Définissez-la sur `docker` ou `kaniko`, ou sur `noop` pour désactiver le build. Par défaut, le chart Helm de l’agent définit `builder.type` sur `noop`. L’agent utilise d’autres clés de la section `builder` pour configurer le processus de build.

Si vous ne spécifiez aucun générateur dans la configuration de l’agent et qu’une CLI `docker` fonctionnelle est détectée, l’agent utilise Docker par défaut. Si Docker n’est pas disponible, l’agent utilise `noop` par défaut.

<Note>
  Utilisez Kaniko pour builder des images dans un cluster Kubernetes. Utilisez Docker dans tous les autres cas.
</Note>

<h2 id="push-to-a-container-registry">
  Téléverser vers un registre de conteneurs
</h2>

Pour exécuter les images buildées sur votre cible de calcul, l’agent doit les téléverser vers un registre de conteneurs depuis lequel la cible peut les récupérer. Les sections suivantes expliquent comment l’agent applique des tags aux images et les téléverse.

L’agent Launch attribue à chaque image qu’il builde un tag correspondant à un hachage unique de la source. L’agent téléverse ensuite l’image vers le registre spécifié dans la clé `builder.destination`.

Par exemple, si vous définissez la clé `builder.destination` sur `my-registry.example.com/my-repository`, l’agent applique un tag à l’image et la téléverse vers `my-registry.example.com/my-repository:[SOURCE-HASH]`. Si l’image existe déjà dans le registre, l’agent ne procède pas au build.

<h3 id="agent-configuration">
  Configuration de l’agent
</h3>

L’agent lit sa configuration à partir d’un fichier YAML. La manière de fournir ce fichier dépend de la façon dont vous exécutez l’agent.

Si vous déployez l’agent avec le chart Helm, fournissez la configuration de l’agent dans la clé `agentConfig` du fichier `values.yaml`.

Si vous lancez vous-même l’agent avec `wandb launch-agent`, indiquez le chemin d’un fichier YAML de configuration de l’agent à l’aide de l’option `--config`. Par défaut, l’agent charge la configuration à partir de `~/.config/wandb/launch-config.yaml`.

Dans la configuration de votre agent Launch (`launch-config.yaml`), fournissez respectivement le nom de l’environnement de la ressource cible et le registre de conteneurs dans les clés `environment` et `registry`.

Les onglets suivants montrent comment configurer l’agent Launch en fonction de votre environnement et de votre registre.

<Tabs>
  <Tab title="AWS">
    La configuration de l’environnement AWS nécessite la clé region. Définissez-la sur la région AWS dans laquelle l’agent s’exécute.

    ```yaml title="launch-config.yaml" theme={"system"}
    environment:
      type: aws
      region: [AWS-REGION]
    builder:
      type: [BUILDER-TYPE]
      # URI du dépôt ECR dans lequel l’agent stocke les images.
      # Assurez-vous que la région correspond à celle configurée dans votre
      # environnement.
      destination: [ACCOUNT-ID].ecr.[AWS-REGION].amazonaws.com/[REPOSITORY-NAME]
      # Si vous utilisez Kaniko, indiquez le bucket S3 dans lequel l’agent stocke le
      # contexte de build.
      build-context-store: s3://[BUCKET-NAME]/[PATH]
    ```

    L’agent utilise `boto3` pour charger les identifiants d’authentification AWS par défaut. Consultez la [documentation de boto3](https://boto3.amazonaws.com/v1/documentation/api/latest/index.html) pour savoir comment configurer les identifiants d’authentification AWS par défaut.
  </Tab>

  <Tab title="Google Cloud">
    L’environnement Google Cloud nécessite les clés region et project. Définissez `region` sur la région dans laquelle l’agent s’exécute, et `project` sur le projet Google Cloud dans lequel il s’exécute. L’agent utilise `google.auth.default()` en Python pour charger les identifiants d’authentification par défaut.

    ```yaml title="launch-config.yaml" theme={"system"}
    environment:
      type: gcp
      region: [GCP-REGION]
      project: [GCP-PROJECT-ID]
    builder:
      type: [BUILDER-TYPE]
      # URI du dépôt Artifact Registry et nom de l’image où l’agent
      # stocke les images. Assurez-vous que la région et le projet correspondent à ceux
      # configurés dans votre environnement.
      uri: [REGION]-docker.pkg.dev/[PROJECT-ID]/[REPOSITORY-NAME]/[IMAGE-NAME]
      # Si vous utilisez Kaniko, indiquez le bucket GCS dans lequel l’agent stocke le
      # contexte de build.
      build-context-store: gs://[BUCKET-NAME]/[PATH]
    ```

    Consultez la [documentation de `google-auth`](https://google-auth.readthedocs.io/en/latest/reference/google.auth.html#google.auth.default) pour savoir comment configurer les identifiants d’authentification Google Cloud par défaut afin de les rendre disponibles pour l’agent.
  </Tab>

  <Tab title="Azure">
    L’environnement Azure ne nécessite aucune clé supplémentaire. Au démarrage, l’agent utilise `azure.identity.DefaultAzureCredential()` pour charger les identifiants d’authentification Azure par défaut.

    ```yaml title="launch-config.yaml" theme={"system"}
    environment:
      type: azure
    builder:
      type: [BUILDER-TYPE]
      # URI du dépôt Azure Container Registry dans lequel l’agent stocke les images.
      destination: https://[REGISTRY-NAME].azurecr.io/[REPOSITORY-NAME]
      # Si vous utilisez Kaniko, indiquez le conteneur Azure Blob Storage dans lequel l’agent
      # stocke le contexte de build.
      build-context-store: https://[STORAGE-ACCOUNT-NAME].blob.core.windows.net/[CONTAINER-NAME]
    ```

    Consultez la [documentation d’`azure-identity`](https://learn.microsoft.com/python/api/azure-identity/azure.identity.defaultazurecredential?view=azure-python) pour savoir comment configurer les identifiants d’authentification Azure par défaut.
  </Tab>
</Tabs>

<h2 id="agent-permissions">
  Autorisations de l’agent
</h2>

L’agent doit être autorisé à téléverser des images vers votre registre de conteneurs et, si vous utilisez Kaniko, à lire et à écrire le contexte de build dans le stockage cloud. Les autorisations requises pour l’agent varient selon le cas d’utilisation.

<h3 id="cloud-registry-permissions">
  Autorisations du registre cloud
</h3>

L’agent a besoin d’autorisations sur le registre pour pouvoir créer des dépôts et téléverser des couches d’image ainsi que des images taguées. Les agents Launch doivent disposer des autorisations suivantes pour interagir avec les registres cloud.

<Tabs>
  <Tab title="AWS">
    ```yaml theme={"system"}
    {
      'Version': '2012-10-17',
      'Statement':
        [
          {
            'Effect': 'Allow',
            'Action':
              [
                'ecr:CreateRepository',
                'ecr:UploadLayerPart',
                'ecr:PutImage',
                'ecr:CompleteLayerUpload',
                'ecr:InitiateLayerUpload',
                'ecr:DescribeRepositories',
                'ecr:DescribeImages',
                'ecr:BatchCheckLayerAvailability',
                'ecr:BatchDeleteImage',
              ],
            'Resource': 'arn:aws:ecr:[REGION]:[ACCOUNT-ID]:repository/[REPOSITORY]',
          },
          {
            'Effect': 'Allow',
            'Action': 'ecr:GetAuthorizationToken',
            'Resource': '*',
          },
        ],
    }
    ```
  </Tab>

  <Tab title="Google Cloud">
    ```js theme={"system"}
    artifactregistry.dockerimages.list;
    artifactregistry.repositories.downloadArtifacts;
    artifactregistry.repositories.list;
    artifactregistry.repositories.uploadArtifacts;
    ```
  </Tab>

  <Tab title="Azure">
    Ajoutez le [rôle `AcrPush`](https://learn.microsoft.com/azure/role-based-access-control/built-in-roles/containers#acrpush) si vous utilisez le générateur Kaniko.
  </Tab>
</Tabs>

<h3 id="storage-permissions-for-kaniko">
  Autorisations de stockage pour Kaniko
</h3>

Si l’agent Launch utilise le générateur Kaniko, il doit être autorisé à téléverser des données vers un stockage cloud. Kaniko utilise un magasin de contexte situé en dehors du pod qui exécute le job de build.

<Tabs>
  <Tab title="AWS">
    Sur AWS, utilisez Amazon S3 comme magasin de contexte pour le générateur Kaniko. Appliquez la stratégie suivante pour accorder à l’agent l’accès à un bucket S3 :

    ```json theme={"system"}
    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Sid": "ListObjectsInBucket",
          "Effect": "Allow",
          "Action": ["s3:ListBucket"],
          "Resource": ["arn:aws:s3:::[BUCKET-NAME]"]
        },
        {
          "Sid": "AllObjectActions",
          "Effect": "Allow",
          "Action": "s3:*Object",
          "Resource": ["arn:aws:s3:::[BUCKET-NAME]/*"]
        }
      ]
    }
    ```
  </Tab>

  <Tab title="Google Cloud">
    Sur Google Cloud, l’agent a besoin des autorisations IAM suivantes pour téléverser des contextes de build vers GCS :

    ```js theme={"system"}
    storage.buckets.get;
    storage.objects.create;
    storage.objects.delete;
    storage.objects.get;
    ```
  </Tab>

  <Tab title="Azure">
    L’agent a besoin du rôle [Storage Blob Data Contributor](https://learn.microsoft.com/azure/role-based-access-control/built-in-roles#storage-blob-data-contributor) pour téléverser des contextes de build vers Azure Blob Storage.
  </Tab>
</Tabs>

<h2 id="customize-the-kaniko-build">
  Personnaliser le build Kaniko
</h2>

Pour redéfinir des valeurs par défaut, comme le comportement de mise en cache ou les variables d’environnement du pod de build, personnalisez le Job Kubernetes exécuté par Kaniko. Indiquez la spécification du Job Kubernetes utilisée par le job Kaniko dans la clé `builder.kaniko-config` de la configuration de l’agent. Par exemple :

```yaml title="launch-config.yaml" theme={"system"}
builder:
  type: kaniko
  build-context-store: [MY-BUILD-CONTEXT-STORE]
  destination: [MY-IMAGE-DESTINATION]
  build-job-name: wandb-image-build
  kaniko-config:
    spec:
      template:
        spec:
          containers:
          - args:
            - "--cache=false" # Les arguments doivent respecter le format "key=value"
            env:
            - name: "MY_ENV_VAR"
              value: "my-env-var-value"
```

<h2 id="deploy-launch-agent-into-coreweave">
  Déployer l’agent Launch sur CoreWeave
</h2>

Si vos charges de travail bénéficient d’une infrastructure accélérée par GPU, vous pouvez déployer l’agent Launch sur CoreWeave Cloud. CoreWeave est une infrastructure cloud conçue pour les charges de travail accélérées par GPU.

Pour savoir comment déployer l’agent Launch sur CoreWeave, consultez la documentation CoreWeave.

<Note>
  Vous devez créer un [compte CoreWeave](https://cloud.coreweave.com/login) pour déployer l’agent Launch sur une infrastructure CoreWeave.
</Note>


## Related topics

- [Tutoriel : configurer W&B Launch sur SageMaker](/fr/products/wandb/platform/launch/setup-launch-sagemaker.md)