Set up launch agent

고급 에이전트 설정

본 가이드는 다양한 환경에서 컨테이너 이미지를 빌드하기 위해 W&B Launch 에이전트를 설정하는 방법에 대한 정보를 제공합니다.

빌더

Launch 에이전트는 Docker 또는 Kaniko를 사용하여 이미지를 빌드할 수 있습니다.

  • Kaniko: 권한이 필요한 컨테이너로 빌드를 실행하지 않고 Kubernetes에서 컨테이너 이미지를 빌드합니다.
  • Docker: 로컬에서 docker build 코맨드를 실행하여 컨테이너 이미지를 빌드합니다.

빌더 유형은 launch 에이전트 설정에서 builder.type 키를 docker, kaniko 또는 noop(빌드 해제)으로 설정하여 제어할 수 있습니다. 기본적으로 에이전트 helm chart는 builder.typenoop로 설정합니다. builder 섹션의 추가 키는 빌드 프로세스를 구성하는 데 사용됩니다.

에이전트 설정에 빌더가 지정되지 않고 작동하는 docker CLI가 발견되면 에이전트는 기본적으로 Docker를 사용합니다. Docker를 사용할 수 없으면 에이전트는 기본적으로 noop를 사용합니다.

컨테이너 레지스트리에 푸시

Launch 에이전트는 빌드하는 모든 이미지에 고유한 소스 해시로 태그를 지정합니다. 에이전트는 builder.destination 키에 지정된 레지스트리에 이미지를 푸시합니다.

예를 들어, builder.destination 키가 my-registry.example.com/my-repository로 설정된 경우 에이전트는 이미지를 my-registry.example.com/my-repository:<source-hash>로 태그 지정하고 푸시합니다. 이미지가 레지스트리에 존재하면 빌드는 건너뜁니다.

에이전트 설정

Helm chart를 통해 에이전트를 배포하는 경우 에이전트 설정은 values.yaml 파일의 agentConfig 키에 제공되어야 합니다.

wandb launch-agent로 에이전트를 직접 호출하는 경우 --config 플래그를 사용하여 에이전트 설정을 YAML 파일 경로로 제공할 수 있습니다. 기본적으로 설정은 ~/.config/wandb/launch-config.yaml에서 로드됩니다.

launch 에이전트 설정(launch-config.yaml) 내에서 대상 리소스 환경의 이름과 environmentregistry 키에 대한 컨테이너 레지스트리를 각각 제공합니다.

다음 탭은 환경 및 레지스트리를 기반으로 launch 에이전트를 구성하는 방법을 보여줍니다.

AWS 환경 설정에는 region 키가 필요합니다. region은 에이전트가 실행되는 AWS region이어야 합니다.

environment:
  type: aws
  region: <aws-region>
builder:
  type: <kaniko|docker>
  # 에이전트가 이미지를 저장할 ECR 리포지토리의 URI입니다.
  # region이 환경에 구성한 region과 일치하는지 확인하십시오.
  destination: <account-id>.ecr.<aws-region>.amazonaws.com/<repository-name>
  # Kaniko를 사용하는 경우 에이전트가 빌드 컨텍스트를 저장할 S3 버킷을 지정합니다.
  build-context-store: s3://<bucket-name>/<path>

에이전트는 boto3을 사용하여 기본 AWS 자격 증명을 로드합니다. 기본 AWS 자격 증명을 구성하는 방법에 대한 자세한 내용은 boto3 설명서를 참조하세요.

Google Cloud 환경에는 region 및 project 키가 필요합니다. region을 에이전트가 실행되는 region으로 설정합니다. project를 에이전트가 실행되는 Google Cloud 프로젝트로 설정합니다. 에이전트는 Python에서 google.auth.default()를 사용하여 기본 자격 증명을 로드합니다.

environment:
  type: gcp
  region: <gcp-region>
  project: <gcp-project-id>
builder:
  type: <kaniko|docker>
  # 에이전트가 이미지를 저장할 Artifact Registry 리포지토리 및 이미지 이름의 URI입니다.
  # region 및 프로젝트가 환경에 구성한 것과 일치하는지 확인하십시오.
  uri: <region>-docker.pkg.dev/<project-id>/<repository-name>/<image-name>
  # Kaniko를 사용하는 경우 에이전트가 빌드 컨텍스트를 저장할 GCS 버킷을 지정합니다.
  build-context-store: gs://<bucket-name>/<path>

에이전트에서 사용할 수 있도록 기본 GCP 자격 증명을 구성하는 방법에 대한 자세한 내용은 google-auth 설명서를 참조하세요.

Azure 환경은 추가 키가 필요하지 않습니다. 에이전트가 시작되면 azure.identity.DefaultAzureCredential()을 사용하여 기본 Azure 자격 증명을 로드합니다.

environment:
  type: azure
builder:
  type: <kaniko|docker>
  # 에이전트가 이미지를 저장할 Azure Container Registry 리포지토리의 URI입니다.
  destination: https://<registry-name>.azurecr.io/<repository-name>
  # Kaniko를 사용하는 경우 에이전트가 빌드 컨텍스트를 저장할 Azure Blob Storage 컨테이너를 지정합니다.
  build-context-store: https://<storage-account-name>.blob.core.windows.net/<container-name>

기본 Azure 자격 증명을 구성하는 방법에 대한 자세한 내용은 azure-identity 설명서를 참조하세요.

에이전트 권한

필요한 에이전트 권한은 유스 케이스에 따라 다릅니다.

클라우드 레지스트리 권한

다음은 클라우드 레지스트리와 상호 작용하기 위해 launch 에이전트에서 일반적으로 요구하는 권한입니다.

{
  '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;

Kaniko 빌더를 사용하는 경우 AcrPush 역할을 추가합니다.

Kaniko의 스토리지 권한

에이전트가 Kaniko 빌더를 사용하는 경우 launch 에이전트는 클라우드 스토리지에 푸시할 수 있는 권한이 필요합니다. Kaniko는 빌드 job을 실행하는 pod 외부의 컨텍스트 저장소를 사용합니다.

AWS에서 Kaniko 빌더에 권장되는 컨텍스트 저장소는 Amazon S3입니다. 다음 정책을 사용하여 에이전트에 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>/*"]
    }
  ]
}

GCP에서 에이전트가 빌드 컨텍스트를 GCS에 업로드하려면 다음 IAM 권한이 필요합니다.

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

에이전트가 빌드 컨텍스트를 Azure Blob Storage에 업로드하려면 Storage Blob Data Contributor 역할이 필요합니다.

Kaniko 빌드 사용자 정의

에이전트 설정의 builder.kaniko-config 키에서 Kaniko job이 사용하는 Kubernetes Job 사양을 지정합니다. 예:

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" # Args must be in the format "key=value"
            env:
            - name: "MY_ENV_VAR"
              value: "my-env-var-value"

CoreWeave에 Launch 에이전트 배포

선택적으로 W&B Launch 에이전트를 CoreWeave Cloud 인프라에 배포합니다. CoreWeave는 GPU 가속 워크로드를 위해 특별히 구축된 클라우드 인프라입니다.

Launch 에이전트를 CoreWeave에 배포하는 방법에 대한 자세한 내용은 CoreWeave 설명서를 참조하세요.