Launch 에이전트 설정

​

고급 에이전트 설정

이 가이드는 다양한 환경에서 컨테이너 이미지를 빌드하도록 W&B Launch 에이전트를 설정하는 방법을 설명합니다.

빌드는 git 및 코드 아티팩트 작업에만 필요합니다. 이미지 작업에는 빌드가 필요하지 않습니다.

작업 유형에 대한 자세한 내용은 Launch 작업 생성을 참조하세요.

​

빌더

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

• Kaniko: 권한이 상승된(privileged) 컨테이너로 빌드를 실행하지 않고, Kubernetes에서 컨테이너 이미지를 빌드합니다.
• Docker: 로컬에서 docker build 명령을 실행해 컨테이너 이미지를 빌드합니다.

빌더 유형은 Launch 에이전트 설정의 builder.type 키로 제어할 수 있으며, docker 또는 kaniko로 설정하거나, 빌드를 끄려면 noop으로 설정합니다. 기본적으로 에이전트 Helm 차트는 builder.type을 noop으로 설정합니다. builder 섹션의 추가 키들은 빌드 프로세스를 구성하는 데 사용됩니다.

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

Kubernetes 클러스터에서 이미지를 빌드할 때는 Kaniko를 사용하세요. 그 외 모든 경우에는 Docker를 사용하세요.

​

컨테이너 레지스트리로 푸시하기

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

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

​

에이전트 구성

Helm 차트를 통해 에이전트를 배포하는 경우, 에이전트 설정은 values.yaml 파일의 agentConfig 키에 지정해야 합니다.

wandb launch-agent로 직접 에이전트를 실행하는 경우, --config 플래그와 함께 YAML 파일 경로를 지정해 에이전트 설정을 전달할 수 있습니다. 기본적으로 설정은 ~/.config/wandb/launch-config.yaml에서 로드됩니다.

Launch 에이전트 설정 파일(launch-config.yaml)에서 대상 리소스 환경의 이름과 컨테이너 레지스트리를 각각 environment 및 registry 키에 지정합니다.

아래 탭에서는 환경과 레지스트리에 따라 Launch 에이전트를 구성하는 방법을 보여 줍니다.

AWS

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

launch-config.yaml

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

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

Google Cloud

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

launch-config.yaml

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

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

Azure

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

launch-config.yaml

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 문서를 참조하세요.

​

에이전트 권한

에이전트에 필요한 권한은 사용 사례에 따라 다릅니다.

​

클라우드 레지스트리 권한

다음은 런치 에이전트가 클라우드 레지스트리와 상호작용할 때 일반적으로 필요한 권한입니다.

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

Kaniko 빌더를 사용하는 경우 AcrPush 역할을 추가하세요.

​

Kaniko를 위한 스토리지 권한

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

AWS

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

Google Cloud

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

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

Azure

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

​

Kaniko 빌드 사용자 정의

에이전트 구성의 builder.kaniko-config 키에 Kaniko 작업에서 사용할 Kubernetes Job 스펙을 지정합니다. 예를 들어:

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" # Args는 "key=value" 형식이어야 합니다
            env:
            - name: "MY_ENV_VAR"
              value: "my-env-var-value"

​

CoreWeave에 Launch agent 배포

선택적으로 W&B Launch agent를 CoreWeave Cloud 인프라에 배포할 수 있습니다. CoreWeave는 GPU 가속 워크로드를 위해 특화된 클라우드 인프라입니다.

Launch agent를 CoreWeave에 배포하는 방법에 대한 자세한 내용은 CoreWeave 문서를 참조하세요.

Launch agent를 CoreWeave 인프라에 배포하려면 CoreWeave 계정을 생성해야 합니다.