Configuration avancée de l’agent
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.
- 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
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é.
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.
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.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’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.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>
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.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>
azure-identity pour plus d’informations sur la configuration des identifiants Azure par défaut. Autorisations des registres cloud
{
'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
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;
Le rôle Storage Blob Data Contributor est requis pour que l’agent puisse téléverser les contextes de build vers Azure Blob Storage. Personnaliser le build Kaniko
builder.kaniko-config de la configuration de l’agent. Par exemple :
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 devrez créer un compte CoreWeave afin de déployer l’agent Launch sur une infrastructure CoreWeave. 
