> ## Documentation Index
> Fetch the complete documentation index at: https://wb-21fd5541-wbdocs-1882.mintlify.site/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 builders Docker et Kaniko ainsi que les paramètres du registre de conteneurs.

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

Ce guide explique comment configurer l’agent Launch de W\&B pour générer des images de conteneur dans différents environnements.

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

  Voir [Créer un launch job](/fr/platform/launch/create-launch-job/) pour en savoir plus sur les types de job.
</Note>

<div id="builders">
  ## Builders
</div>

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

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

Le type de builder se contrôle avec la clé `builder.type` dans la configuration de l’agent Launch, en utilisant les valeurs `docker`, `kaniko` ou `noop` pour désactiver le build. Par défaut, le chart Helm de l’agent définit `builder.type` sur `noop`. Les clés supplémentaires de la section `builder` sont utilisées pour configurer le processus de build.

Si aucun builder n’est spécifié dans la configuration de l’agent et qu’une CLI `docker` fonctionnelle est détectée, l’agent utilisera Docker par défaut. Si Docker n’est pas disponible, l’agent utilisera `noop` par défaut.

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

<div id="pushing-to-a-container-registry">
  ## Publication dans un registre de conteneurs
</div>

L’agent Launch attribue à toutes les images qu’il construit un tag basé sur un hachage source unique. Il envoie l’image vers le registre spécifié dans la clé `builder.destination`.

Par exemple, si la clé `builder.destination` est définie sur `my-registry.example.com/my-repository`, l’agent tague l’image et l’envoie vers `my-registry.example.com/my-repository:<source-hash>`. Si l’image existe déjà dans le registre, le build est ignoré.

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

Si vous déployez l’agent via notre chart Helm, la configuration de l’agent doit être renseignée dans la clé `agentConfig` du fichier `values.yaml`.

Si vous lancez vous-même l’agent avec `wandb launch-agent`, vous pouvez fournir sa configuration en indiquant le chemin vers un fichier YAML avec l’option `--config`. Par défaut, la configuration est chargée depuis `~/.config/wandb/launch-config.yaml`.

Dans la configuration de votre agent Launch (`launch-config.yaml`), indiquez 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`. Celle-ci doit correspondre à la région AWS dans laquelle l’agent s’exécute.

    ```yaml title="launch-config.yaml" theme={null}
    environment:
      type: aws
      region: <aws-region>
    builder:
      type: <kaniko|docker>
      # URI du dépôt ECR où l’agent stockera 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, spécifiez le bucket S3 où l’agent stockera le
      # contexte de build.
      build-context-store: s3://<bucket-name>/<path>
    ```

    L’agent utilise boto3 pour charger les identifiants AWS par défaut. Voir la [documentation boto3](https://boto3.amazonaws.com/v1/documentation/api/latest/index.html) pour plus d’informations sur la configuration des identifiants 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. Définissez `project` sur le projet Google Cloud dans lequel l’agent s’exécute. L’agent utilise `google.auth.default()` en Python pour charger les identifiants par défaut.

    ```yaml title="launch-config.yaml" theme={null}
    environment:
      type: gcp
      region: <gcp-region>
      project: <gcp-project-id>
    builder:
      type: <kaniko|docker>
      # URI du dépôt Artifact Registry et nom de l’image où l’agent
      # stockera 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, spécifiez le bucket GCS où l’agent stockera le
      # contexte de build.
      build-context-store: gs://<bucket-name>/<path>
    ```

    Voir la [documentation `google-auth`](https://google-auth.readthedocs.io/en/latest/reference/google.auth.html#google.auth.default) pour plus d’informations sur la configuration des identifiants Google Cloud par défaut afin qu’ils soient 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 Azure par défaut.

    ```yaml title="launch-config.yaml" theme={null}
    environment:
      type: azure
    builder:
      type: <kaniko|docker>
      # URI du dépôt Azure Container Registry où l’agent stockera les images.
      destination: https://<registry-name>.azurecr.io/<repository-name>
      # Si vous utilisez Kaniko, spécifiez le conteneur Azure Blob Storage où l’agent
      # stockera le contexte de build.
      build-context-store: https://<storage-account-name>.blob.core.windows.net/<container-name>
    ```

    Voir la [documentation `azure-identity`](https://learn.microsoft.com/python/api/azure-identity/azure.identity.defaultazurecredential?view=azure-python) pour plus d’informations sur la configuration des identifiants Azure par défaut.
  </Tab>
</Tabs>

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

Les autorisations requises pour l’agent varient selon le cas d’utilisation.

<div id="cloud-registry-permissions">
  ### Autorisations des registres cloud
</div>

Voici les autorisations généralement requises pour que les agents Launch puissent interagir avec des registres cloud.

<Tabs>
  <Tab title="AWS">
    ```yaml theme={null}
    {
      '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={null}
    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 builder Kaniko.
  </Tab>
</Tabs>

<div id="storage-permissions-for-kaniko">
  ### Autorisations d'accès au stockage pour Kaniko
</div>

L'agent Launch doit disposer de l'autorisation d'écrire dans le stockage cloud s'il utilise le builder Kaniko. Kaniko utilise un stockage de contexte en dehors du pod qui exécute le job de build.

<Tabs>
  <Tab title="AWS">
    Le stockage de contexte recommandé pour le builder Kaniko sur AWS est Amazon S3. La politique suivante peut être utilisée pour donner à l'agent l'accès à un bucket S3 :

    ```json theme={null}
    {
      "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, les autorisations IAM suivantes sont requises pour que l'agent puisse téléverser les contextes de build vers GCS :

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

  <Tab title="Azure">
    Le rôle [Storage Blob Data Contributor](https://learn.microsoft.com/azure/role-based-access-control/built-in-roles#storage-blob-data-contributor) est requis pour que l'agent puisse téléverser les contextes de build vers Azure Blob Storage.
  </Tab>
</Tabs>

<div id="customizing-the-kaniko-build">
  ## Personnaliser le build Kaniko
</div>

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={null}
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 être au format "clé=valeur"
            env:
            - name: "MY_ENV_VAR"
              value: "my-env-var-value"
```

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

Vous pouvez également déployer l’agent Launch de W\&B sur l’infrastructure cloud de CoreWeave. CoreWeave est une infrastructure cloud spécialement conçue pour les charges de travail accélérées par GPU.

Pour savoir comment déployer l’agent Launch sur CoreWeave, voir la [documentation de CoreWeave](https://docs.coreweave.com/partners/weights-and-biases#integration).

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