Configuration avancée de l’agent

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

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 pour en savoir plus sur les types de job.

Builders

L’agent Launch peut créer des images à l’aide de Docker ou de 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.

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

Publication dans un registre de conteneurs

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é.

Configuration de l’agent

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.

AWS
Google Cloud
Azure

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.

launch-config.yaml

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 pour plus d’informations sur la configuration des identifiants AWS par défaut.

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.

launch-config.yaml

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 pour plus d’informations sur la configuration des identifiants Google Cloud par défaut afin qu’ils soient disponibles pour l’agent.

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.

launch-config.yaml

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 pour plus d’informations sur la configuration des identifiants Azure par défaut.

Autorisations de l’agent

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

Autorisations des registres cloud

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

AWS
Google Cloud
Azure

{
  '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': '*',
      },
    ],
}

artifactregistry.dockerimages.list;
artifactregistry.repositories.downloadArtifacts;
artifactregistry.repositories.list;
artifactregistry.repositories.uploadArtifacts;

Ajoutez le rôle AcrPush si vous utilisez le builder Kaniko.

Autorisations d’accès au stockage pour Kaniko

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.

AWS
Google Cloud
Azure

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 :

{
  "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>/*"]
    }
  ]
}

Sur Google Cloud, les autorisations IAM suivantes sont requises pour que l’agent puisse téléverser les contextes de build vers GCS :

storage.buckets.get;
storage.objects.create;
storage.objects.delete;
storage.objects.get;

Personnaliser le build 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 :

launch-config.yaml

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"

Déployer l’agent Launch sur CoreWeave

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.

Vous devrez créer un compte CoreWeave afin de déployer l’agent Launch sur une infrastructure CoreWeave.

Configurer Launch

Créer et déployer des jobs

Avancé

FAQ de Launch

Référence de l’API de la bibliothèque Launch

Configurer l’agent Launch

Configuration avancée de l’agent

Builders

Publication dans un registre de conteneurs

Configuration de l’agent

Autorisations de l’agent

Autorisations des registres cloud

Autorisations d’accès au stockage pour Kaniko

Personnaliser le build Kaniko

Déployer l’agent Launch sur CoreWeave

​Configuration avancée de l’agent

​Builders

​Publication dans un registre de conteneurs

​Configuration de l’agent

​Autorisations de l’agent

​Autorisations des registres cloud

​Autorisations d’accès au stockage pour Kaniko

​Personnaliser le build Kaniko

​Déployer l’agent Launch sur CoreWeave

Configuration avancée de l’agent

Builders

Publication dans un registre de conteneurs

Configuration de l’agent

Autorisations de l’agent

Autorisations des registres cloud

Autorisations d’accès au stockage pour Kaniko

Personnaliser le build Kaniko

Déployer l’agent Launch sur CoreWeave