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.

​

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, envoyer ces images vers des registres de conteneurs cloud et personnaliser le processus de build. Utilisez-le lorsque vous devez exécuter des jobs Launch qui nécessitent la création 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.

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.

​

Générateurs

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

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 la construction dans un conteneur privilégié.
• Docker : crée une image de conteneur en exécutant localement une commande docker build.

Contrôlez le type de générateur avec la clé builder.type dans la configuration de l’agent Launch. Définissez-la sur docker, kaniko ou noop pour désactiver la construction. Par défaut, le chart Helm de l’agent définit builder.type sur noop. L’agent utilise des clés supplémentaires dans la section builder pour configurer le processus de construction.

Si vous ne spécifiez pas de 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.

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

​

Téléverser vers un registre de conteneurs

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

L’agent Launch attribue à toutes les images qu’il construit un tag basé sur un hachage source unique. Il téléverse 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 la téléverse 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

L’agent lit sa configuration à partir d’un fichier YAML. L’endroit où vous fournissez 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, fournissez la configuration de l’agent sous la forme du chemin d’accès à un fichier YAML à l’aide de l’indicateur --config. Par défaut, l’agent charge la configuration 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

La configuration de l’environnement AWS nécessite la clé region. Définissez region sur la région AWS dans laquelle l’agent s’exécute.

launch-config.yaml

environment:
  type: aws
  region: [AWS-REGION]
builder:
  type: [BUILDER-TYPE]
  # URI du dépôt ECR où 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, spécifiez le bucket S3 où l’agent stocke 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.

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.

launch-config.yaml

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, spécifiez le bucket GCS où l’agent stocke 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.

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.

launch-config.yaml

environment:
  type: azure
builder:
  type: [BUILDER-TYPE]
  # URI du dépôt Azure Container Registry où l’agent stocke les images.
  destination: https://[REGISTRY-NAME].azurecr.io/[REPOSITORY-NAME]
  # Si vous utilisez Kaniko, spécifiez le conteneur Azure Blob Storage où l’agent
  # stocke 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

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

​

Autorisations des registres cloud

L’agent a besoin d’autorisations sur le registre afin de pouvoir créer des dépôts, téléverser des couches d’image et téléverser des images avec balises. Les autorisations suivantes sont requises pour que les agents Launch puissent interagir avec des registres cloud.

AWS

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

Google Cloud

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

Azure

Ajoutez le rôle AcrPush si vous utilisez le générateur Kaniko.

​

Autorisations de stockage pour Kaniko

L’agent Launch doit disposer des autorisations nécessaires pour téléverser vers le stockage cloud s’il utilise le générateur Kaniko. Kaniko utilise un stockage de contexte situé en dehors du pod qui exécute le job de build.

AWS

Utilisez Amazon S3 comme stockage de contexte pour le générateur Kaniko sur AWS. Utilisez la stratégie suivante 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]/*"]
    }
  ]
}

Google Cloud

Sur Google Cloud, l’agent doit disposer des autorisations IAM suivantes pour téléverser les contextes de build vers GCS :

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

Azure

L’agent doit disposer du rôle Storage Blob Data Contributor pour téléverser les contextes de build vers Azure Blob Storage.

​

Personnaliser le build Kaniko

Pour redéfinir les valeurs par défaut, comme le comportement de la 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 :

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

Si vos charges de travail tirent parti d’une infrastructure accélérée par GPU, vous pouvez déployer l’agent Launch sur CoreWeave Cloud. 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.