Launch 에이전트 설정하기

​

고급 에이전트 설정

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

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

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

​

Builders

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>

에이전트는 boto3를 사용하여 기본 AWS 자격 증명을 로드합니다. 기본 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 문서를 참조하세요.

​

에이전트 권한

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

​

클라우드 레지스트리 권한

아래는 Launch 에이전트가 클라우드 레지스트리와 상호 작용하는 데 일반적으로 필요한 권한입니다.

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 빌더를 사용하는 경우 클라우드 스토리지에 푸시할 수 있는 권한이 필요합니다. Kaniko는 빌드 job을 실행하는 파드 외부의 컨텍스트 저장소를 사용합니다.

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

​

CoreWeave에 Launch 에이전트 배포

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

Launch 에이전트를 CoreWeave에 배포하는 방법에 대한 정보는 CoreWeave 문서를 참조하세요.

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