Kubernetes Operator를 사용해 W&B 배포 - Weights & Biases Documentation

Overview

W&B Kubernetes Operator는 Kubernetes(클라우드 또는 온프레미스)에서 W&B Server를 배포하는 데 권장되는 방식입니다. Operator의 개요, W&B가 이를 사용하는 이유, 그리고 설정 계층 구조가 어떻게 작동하는지에 대해서는 Self-Managed를 참조하세요.

시작하기 전에

Kubernetes Operator로 W&B를 배포하기 전에 인프라가 모든 요구 사항을 충족하는지 확인하세요:

인프라 요구 사항 검토: 다음 항목에 대한 자세한 내용은 Self-Managed infrastructure requirements 페이지를 참조하세요.

소프트웨어 버전 요구 사항(Kubernetes, MySQL, Redis, Helm)
- 하드웨어 요구 사항(CPU 아키텍처, 권장 사양)
- Kubernetes 클러스터 설정
- 네트워킹, SSL/TLS, DNS 요구 사항

W&B Server 라이선스 획득: Requirements 페이지의 License 섹션을 참조하세요.
외부 서비스 프로비저닝: 배포 전에 MySQL, Redis, 객체 저장소를 설정하세요.

추가 정보는 레퍼런스 아키텍처 페이지를 참조하세요.

MySQL 데이터베이스

W&B를 사용하려면 외부 MySQL 데이터베이스가 필요합니다. 프로덕션 환경에서는 W&B는 관리형 데이터베이스 서비스 사용을 강력히 권장합니다:

관리형 데이터베이스 서비스는 자동 백업, 모니터링, 고가용성, 패치 적용을 제공하며 운영 오버헤드를 줄여줍니다. 사이징 권장 사항과 설정 파라미터를 포함한 전체 MySQL 요구 사항은 레퍼런스 아키텍처를 참조하세요. 데이터베이스 생성 SQL은 bare-metal guide를 참조하세요. 배포 환경의 데이터베이스 설정에 대해 궁금한 점이 있으면 지원팀 또는 AISE에 문의하세요. 설정 매개변수와 데이터베이스 생성 방법을 포함한 전체 MySQL 설정 지침은 requirements 페이지의 MySQL 섹션을 참조하세요.

Redis

W&B는 작업 큐잉과 데이터 캐싱을 위해 W&B 컴포넌트가 사용하는 단일 노드 Redis 7.x 배포에 의존합니다. 테스트 및 개념 검증을 편리하게 수행할 수 있도록, W&B Self-Managed에는 로컬 Redis 배포가 포함되어 있지만 이는 프로덕션 배포에는 적합하지 않습니다. 프로덕션 배포의 경우 W&B는 다음 환경의 Redis 인스턴스에 연결할 수 있습니다:

AWS Elasticache
Google Cloud Memory Store
Azure Cache for Redis
사용자의 클라우드 또는 온프레미스 인프라에서 호스팅되는 Redis 배포

Helm values에서 외부 Redis 인스턴스를 설정하는 방법에 대한 자세한 내용은 External Redis 설정 섹션을 참조하세요.

객체 저장소

W&B에는 사전 서명된 URL 및 CORS를 지원하는 객체 저장소가 필요합니다. 권장 저장소 제공업체:

Amazon S3: 업계 최고 수준의 확장성, 데이터 가용성, 보안, 성능을 제공하는 객체 저장소 서비스입니다.
Google Cloud Storage: 비정형 데이터를 대규모로 저장하기 위한 관리형 서비스입니다.
Azure Blob Storage: 대량의 비정형 데이터를 저장하기 위한 클라우드 기반 객체 저장소 솔루션입니다.
CoreWeave AI Object Storage: AI 워크로드에 최적화된 고성능 S3 호환 객체 저장소 서비스입니다.
엔터프라이즈 S3 호환 저장소: MinIO Enterprise (AIStor), NetApp StorageGRID, 또는 기타 엔터프라이즈급 솔루션

MinIO Open Source는 활성 개발이나 사전 컴파일된 바이너리 없이 유지 관리 모드에 있습니다. 프로덕션 배포의 경우 W&B는 관리형 객체 저장소 서비스 또는 MinIO Enterprise (AIStor)와 같은 엔터프라이즈 S3 호환 솔루션 사용을 권장합니다.

IAM 정책, CORS 설정, 액세스 설정을 포함한 자세한 버킷 프로비저닝 지침은 Bring Your Own Bucket (BYOB) 가이드를 참조하세요. 전체 요구 사항은 레퍼런스 아키텍처 객체 저장소 섹션을 참조하세요.

저장소 버킷 프로비저닝

W&B를 설정하기 전에 적절한 IAM 정책, CORS 설정, 액세스 자격 증명을 갖춰 객체 저장소 버킷을 프로비저닝하세요. 다음 항목에 대한 자세한 step별 프로비저닝 지침은 Bring Your Own Bucket (BYOB) 가이드를 참조하세요:

Amazon S3(IAM 정책 및 버킷 정책 포함)
Google Cloud Storage(PubSub 알림 포함)
Azure Blob Storage(관리형 ID 포함)
CoreWeave AI Object Storage
S3 호환 저장소(MinIO Enterprise, NetApp StorageGRID, 기타 엔터프라이즈 솔루션 포함)

Helm values에서 객체 저장소를 설정하는 방법에 대한 자세한 내용은 객체 저장소 설정 섹션을 참조하세요.

OpenShift Kubernetes 클러스터

W&B는 클라우드, 온프레미스 및 에어갭 환경의 OpenShift Kubernetes 클러스터에서의 배포를 지원합니다.

W&B는 공식 W&B Helm chart를 사용해 설치할 것을 권장합니다.

컨테이너를 비특권 사용자로 실행

기본적으로 컨테이너는 $UID 999를 사용합니다. 오케스트레이터에서 컨테이너를 non-root 사용자로 실행해야 하는 경우 $UID >= 100000 및 $GID 0을 지정하세요.

파일 시스템 권한이 제대로 작동하려면 W&B는 반드시 루트 그룹($GID=0)으로 시작해야 합니다.

각 W&B 구성 요소의 security context를 설정하세요. 예를 들어 API 구성 요소를 설정하려면 다음과 같습니다.

api:
  install: true
  image:
    repository: wandb/megabinary
    tag: 0.74.1  # 실제 버전으로 교체하세요
  pod:
    securityContext:
      fsGroup: 10001
      fsGroupChangePolicy: Always
      runAsGroup: 0
      runAsNonRoot: true
      runAsUser: 10001
      seccompProfile:
        type: RuntimeDefault
  container:
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
          - ALL
      privileged: false
      readOnlyRootFilesystem: false

필요한 경우 app 또는 console 같은 다른 컴포넌트에 대한 맞춤형 security context를 설정하세요. 자세한 내용은 맞춤형 security context를 참조하세요.

W&B Server 애플리케이션 배포

Helm과 함께 사용하는 W&B Kubernetes Operator는 클라우드, 온프레미스, 에어갭 환경을 포함한 모든 W&B Self-Managed 배포에 권장되는 설치 방법입니다.

배포 방법을 선택하세요:

Helm CLI
Terraform

W&B는 Kubernetes 클러스터에 W&B Kubernetes Operator를 배포할 수 있도록 Helm chart를 제공합니다. 이 방식을 사용하면 Helm CLI 또는 ArgoCD와 같은 지속적 전달 도구로 W&B Server를 배포할 수 있습니다.배포 환경별 고려 사항은 환경별 고려 사항 및 퍼블릭 클라우드에서 Terraform으로 배포를 참조하세요. 외부와 분리된 환경의 경우 Air-Gapped Kubernetes에 배포를 참조하세요.Helm CLI로 W&B Kubernetes Operator를 설치하려면 다음 단계를 따르세요.

W&B Helm 저장소를 추가합니다. W&B Helm chart는 W&B Helm 저장소에서 사용할 수 있습니다.
```
helm repo add wandb https://charts.wandb.ai
helm repo update
```

Kubernetes 클러스터에 Operator를 설치합니다.

helm upgrade --install operator wandb/operator -n wandb-cr --create-namespace

W&B Operator custom resource를 설정해 W&B Server 설치를 트리거합니다. W&B 배포 설정이 포함된 operator.yaml 파일을 만드세요. 사용 가능한 모든 옵션은 설정 레퍼런스를 참고하세요. 다음은 최소 예제 설정입니다.

apiVersion: apps.wandb.com/v1
kind: WeightsAndBiases
metadata:
  labels:
    app.kubernetes.io/name: weightsandbiases
    app.kubernetes.io/instance: wandb
  name: wandb
  namespace: default
spec:
  values:
    global:
      host: https://<HOST_URI>
      license: eyJhbGnUzaH...j9ZieKQ2x5GGfw
      bucket:
        <details depend on the provider>
      mysql:
        <redacted>
    ingress:
      annotations:
        <redacted>

맞춤형 설정으로 Operator를 시작해 W&B Server application을 설치, 설정, 관리할 수 있도록 합니다.
```
kubectl apply -f operator.yaml
```
배포가 완료될 때까지 기다리세요. 몇 분 정도 걸립니다.
웹 UI를 사용해 설치를 확인하려면 먼저 첫 번째 관리자 사용자 계정을 만든 다음 설치 확인에 안내된 확인 단계를 따르세요.

Terraform을 사용해 infrastructure-as-code 방식으로 W&B를 배포합니다. 다음 중에서 선택하세요:

Helm Terraform Module: 기존 Kubernetes 인프라에 Operator를 배포합니다
Cloud Terraform Modules: AWS, Google Cloud, Azure용 전체 인프라 + 애플리케이션 배포

배포별 고려 사항은 환경별 고려 사항 및 퍼블릭 클라우드에서 Terraform으로 배포를 참조하세요. 연결이 차단된 환경의 경우 Air-Gapped Kubernetes에 배포를 참조하세요.

Helm Terraform Module

이 방법을 사용하면 특정 요구 사항에 맞게 배포를 사용자 지정할 수 있으며, Terraform의 infrastructure-as-code 접근 방식을 활용해 일관성과 반복 가능성을 확보할 수 있습니다. 공식 W&B Helm 기반 Terraform Module은 여기에서 확인할 수 있습니다.다음 코드를 시작점으로 사용하세요. 여기에는 프로덕션급 배포에 필요한 모든 설정 옵션이 포함되어 있습니다:

module "wandb" {
  source  = "wandb/wandb/helm"

  spec = {
    values = {
      global = {
        host    = "https://<HOST_URI>"
        license = "eyJhbGnUzaH...j9ZieKQ2x5GGfw"

        bucket = {
          <details depend on the provider>
        }

        mysql = {
          <redacted>
        }
      }

      ingress = {
        annotations = {
          "a" = "b"
          "x" = "y"
        }
      }
    }
  }
}

설정 옵션은 설정 레퍼런스에 설명된 내용과 동일하지만, 구문은 HashiCorp Configuration Language(HCL)를 따라야 합니다. Terraform 모듈은 W&B Custom Resource Definition(CRD)을 생성합니다.W&B가 고객을 위해 Dedicated Cloud 설치를 배포할 때 Helm Terraform 모듈을 실제로 어떻게 사용하는지 보려면 다음 링크를 참조하세요.

클라우드 Terraform 모듈

W&B는 AWS, Google Cloud, Azure용 Terraform 모듈 세트를 제공합니다. 이러한 모듈은 Kubernetes 클러스터, 로드 밸런서, MySQL 데이터베이스 등을 포함한 전체 인프라와 W&B Server 애플리케이션을 함께 배포합니다. W&B Kubernetes Operator는 다음 버전의 공식 W&B 클라우드별 Terraform 모듈에 이미 사전 통합되어 있습니다.

Terraform Registry	Source Code	Version
AWS	https://github.com/wandb/terraform-aws-wandb	v4.0.0+
Azure	https://github.com/wandb/terraform-azurerm-wandb	v2.0.0+
Google Cloud	https://github.com/wandb/terraform-google-wandb	v2.0.0+

이 인테그레이션을 통해 W&B Kubernetes Operator를 최소한의 설정만으로 인스턴스에서 바로 사용할 수 있으므로, 클라우드 환경에서 W&B Server를 더 간편하게 배포하고 관리할 수 있습니다.이러한 클라우드별 모듈 사용에 대한 자세한 지침은 아래의 퍼블릭 클라우드에서 Terraform으로 배포를 참조하세요.

설치 확인하기

설치를 확인하려면 W&B에서는 W&B CLI 사용을 권장합니다. verify 명령어는 모든 컴포넌트와 설정을 확인하는 여러 테스트를 실행합니다.

이 단계에서는 첫 번째 관리자 사용자 계정이 브라우저에서 생성되었다고 가정합니다.

설치를 확인하려면 다음 단계를 따르세요:

W&B CLI를 설치합니다:

pip install wandb

W&B에 로그인합니다:

wandb login --host=https://YOUR_DNS_DOMAIN

예를 들어:

wandb login --host=https://wandb.company-name.com

설치를 확인하세요:

wandb verify

설치에 성공하고 W&B 배포 환경이 정상적으로 작동하면 다음과 같은 출력이 표시됩니다:

Default host selected:  https://wandb.company-name.com
이 테스트의 상세 로그 위치: /var/folders/pn/b3g3gnc11_sbsykqkm3tx5rh0000gp/T/tmpdtdjbxua/wandb
로그인 여부 확인 중...................................................✅
서명된 URL 업로드 확인 중..............................................✅
프록시를 통한 대용량 페이로드 전송 가능 여부 확인 중...................✅
기본 URL에 대한 요청 확인 중...........................................✅
서명된 URL을 통한 요청 확인 중.................................✅
버킷의 CORS 설정 확인 중...............................✅
wandb 패키지 버전 최신 여부 확인 중............................✅
로깅된 메트릭, 파일 저장 및 다운로드 확인 중..................✅
artifact 저장 및 다운로드 워크플로 확인 중...........................✅

오류가 발생하면 W&B 지원팀에 문의하세요.

환경별 고려 사항

Kubernetes는 온프레미스에서 실행하든 클라우드에서 실행하든 동일합니다. 주요 차이는 이름 지정 방식과 관리형 서비스(예: MySQL과 RDS, 또는 S3와 온프레미스 객체 저장소)에 있습니다. 이 섹션에서는 환경에 따라 달라지는 고려 사항을 다룹니다.

온프레미스 및 베어메탈

온프레미스 또는 베어메탈 Kubernetes에 배포할 때는 다음 사항에 유의하세요.

로드 밸런서 설정

온프레미스 Kubernetes 클러스터는 일반적으로 로드 밸런서를 수동으로 설정해야 합니다. 옵션은 다음과 같습니다.

외부 로드 밸런서: 기존 하드웨어 또는 소프트웨어 로드 밸런서(F5, HAProxy 등)를 설정합니다.
Nginx Ingress Controller: NodePort 또는 호스트 네트워킹을 사용해 nginx-ingress-controller를 배포합니다.
MetalLB: 베어메탈 Kubernetes 클러스터에서는 MetalLB가 로드 밸런서 서비스를 제공합니다.

자세한 로드 밸런서 설정 예시는 레퍼런스 아키텍처의 networking 섹션을 참조하세요.

영구 저장소

Kubernetes 클러스터에 영구 볼륨용 StorageClass가 구성되어 있는지 확인하세요. W&B 컴포넌트는 캐싱 및 임시 데이터 저장을 위해 영구 저장소가 필요할 수 있습니다. 일반적인 온프레미스 저장소 옵션:

NFS 기반 저장소 클래스
Ceph/Rook 저장소
로컬 영구 볼륨
엔터프라이즈 저장소 솔루션(NetApp, Pure Storage 등)

DNS 및 인증서 관리

온프레미스 배포의 경우:

W&B 호스트명을 가리키도록 내부 DNS 레코드를 설정합니다
내부 Certificate Authority(CA)에서 SSL/TLS 인증서를 발급받습니다
자체 서명 인증서를 사용하는 경우 Operator가 CA 인증서를 신뢰하도록 설정합니다

인증서 설정에 대한 자세한 내용은 SSL/TLS 요구 사항을 참조하세요.

OpenShift 배포

W&B는 OpenShift Kubernetes 클러스터에 배포하는 것을 완벽하게 지원합니다. OpenShift 배포에는 OpenShift의 더 엄격한 보안 정책으로 인해 추가적인 security context 설정이 필요합니다. OpenShift 관련 설정 세부 정보는 위의 OpenShift Kubernetes 클러스터를 참조하세요. 에어갭 환경에서의 포괄적인 OpenShift 예시는 Air-Gapped Kubernetes에 배포를 참조하세요.

온프레미스 및 S3 호환 환경용 객체 저장소

객체 저장소 버킷을 프로비저닝한 후(객체 저장소 프로비저닝 참조), W&B Custom Resource에 이를 구성하세요. AWS S3 (온프레미스) 온프레미스 AWS S3(Outposts 또는 호환 스토리지 사용)의 경우:

bucket:
  kmsKey: <kms key arn>  # 선택 사항: 암호화용 KMS 키
  name: <bucket name>    # 예시: wandb
  path: ""               # 빈 문자열로 유지
  provider: s3
  region: <region>       # 예시: us-east-1

S3 호환 저장소(MinIO, Ceph, NetApp 등) S3 호환 저장소 시스템에서는:

bucket:
  kmsKey: null
  name: <s3 endpoint>    # 예시: s3.example.com:9000
  path: <bucket name>    # 예시: wandb
  provider: s3
  region: <region>       # 예시: us-east-1

S3 호환 저장소에 TLS를 활성화하려면 버킷 경로에 ?tls=true를 추가하세요:

bucket:
  path: "wandb?tls=true"

인증서를 신뢰할 수 있어야 합니다. 자체 서명된 인증서를 사용하려면 추가 설정이 필요합니다. 자세한 내용은 SSL/TLS requirements를 참조하세요.

온프레미스 객체 저장소의 주요 고려 사항 자체 객체 저장소를 운영하는 경우 다음 사항을 고려하세요.

저장소 용량 및 성능: 디스크 용량을 주의 깊게 모니터링하세요. 일반적인 W&B 사용량은 수십~수백 기가바이트 수준입니다. 사용량이 많으면 저장소 사용량이 페타바이트 단위에 이를 수 있습니다.
내결함성: 최소한 물리 디스크에는 RAID 어레이를 사용하세요. S3 호환 저장소의 경우 분산 또는 고가용성 설정을 사용하세요.
가용성: 저장소의 가용성을 유지할 수 있도록 모니터링을 설정하세요.

MinIO 고려 사항

MinIO Open Source는 현재 maintenance mode이며 활발한 개발이 진행되지 않습니다. 사전 컴파일된 바이너리는 더 이상 제공되지 않으며, 중요한 보안 수정만 사례별로 검토됩니다. 프로덕션 배포의 경우 W&B는 관리형 객체 저장소 서비스 또는 MinIO Enterprise (AIStor) 사용을 권장합니다.

온프레미스 객체 저장소를 위한 엔터프라이즈 대안은 다음과 같습니다.

기존 MinIO 배포 또는 MinIO Enterprise를 사용 중인 경우 MinIO 클라이언트를 사용해 버킷을 생성할 수 있습니다:

mc config host add local http://$MINIO_HOST:$MINIO_PORT "$MINIO_ACCESS_KEY" "$MINIO_SECRET_KEY" --api s3v4
mc mb --region=us-east-1 local/wandb-files

Terraform을 사용한 퍼블릭 클라우드

AWS, Google Cloud 또는 Azure에서 인프라와 애플리케이션을 전체 배포하려면 아래의 퍼블릭 클라우드에서 Terraform으로 배포를 참조하세요.

Terraform으로 퍼블릭 클라우드에 배포하기

W&B는 W&B Multi-tenant Cloud 또는 W&B Dedicated Cloud와 같은 완전 관리형 배포 옵션을 권장합니다. W&B 완전 관리형 서비스는 사용이 간편하고 안전하며, 최소한의 설정만 필요하거나 아예 필요하지 않습니다.

W&B는 퍼블릭 클라우드 제공업체에 플랫폼을 배포할 수 있도록 Terraform 모듈을 제공합니다. 이러한 모듈은 인프라 프로비저닝과 W&B Server 설치를 자동화합니다. 시작하기 전에 W&B는 Terraform에서 State File을 저장할 원격 백엔드 중 하나를 선택할 것을 권장합니다. State File은 모든 컴포넌트를 다시 생성하지 않고도 배포에 업그레이드를 적용하거나 변경할 때 필요한 리소스입니다. 클라우드 제공업체를 선택하세요:

AWS
Google Cloud
Azure

W&B는 AWS에 플랫폼을 배포할 때 W&B Server AWS Terraform Module 사용을 권장합니다.Terraform Module은 다음 필수 컴포넌트를 배포합니다:

로드 밸런서
AWS Identity & Access Management (IAM)
AWS 키 관리 시스템(KMS)
Amazon Aurora MySQL
Amazon VPC
Amazon S3
Amazon Route 53
Amazon Certificate Manager (ACM)
Amazon Elastic Load Balancing (ALB)
Amazon Secrets Manager

선택적 컴포넌트는 다음과 같습니다:

Redis용 ElastiCache
SQS

사전 필요 권한

Terraform를 실행하는 계정은 위에서 설명한 모든 컴포넌트를 생성할 수 있어야 하며, IAM 정책 및 IAM 역할을 생성하고 리소스에 역할을 할당하는 권한도 필요합니다.

일반 step

이 섹션의 단계는 모든 배포 옵션에 공통으로 적용됩니다.

개발 환경을 준비하세요.
- Terraform을 설치하세요.
- W&B는 버전 관리를 위해 Git 저장소를 만드는 것을 권장합니다.
terraform.tfvars 파일을 생성하세요. tvfars 파일의 내용은 설치 유형에 따라 사용자 지정할 수 있지만, 최소 권장 구성은 아래 예시와 같습니다.
```
namespace                  = "wandb"
license                    = "xxxxxxxxxxyyyyyyyyyyyzzzzzzz"
subdomain                  = "wandb-aws"
domain_name                = "wandb.ml"
zone_id                    = "xxxxxxxxxxxxxxxx"
allowed_inbound_cidr       = ["0.0.0.0/0"]
allowed_inbound_ipv6_cidr  = ["::/0"]
eks_cluster_version        = "1.29"
```
배포하기 전에 tvfars 파일에서 변수를 정의해야 합니다. namespace 변수는 Terraform이 생성하는 모든 리소스에 접두사로 붙는 문자열이기 때문입니다. subdomain과 domain을 조합하면 W&B 인스턴스의 FQDN이 됩니다. 위 예시에서 W&B FQDN은 wandb-aws.wandb.ml이며, FQDN 레코드는 해당 DNS zone_id에 생성됩니다. allowed_inbound_cidr와 allowed_inbound_ipv6_cidr도 모두 설정해야 합니다. 모듈에서는 이것이 필수 입력값입니다. 다음 예시에서는 모든 source에서 W&B 설치에 접근할 수 있도록 허용합니다.
versions.tf 파일 만들기 이 파일에는 AWS에 W&B를 배포하는 데 필요한 Terraform과 Terraform provider의 버전이 포함되어 있습니다:
```
provider "aws" {
  region = "eu-central-1"

  default_tags {
    tags = {
      GithubRepo = "terraform-aws-wandb"
      GithubOrg  = "wandb"
      Enviroment = "Example"
      Example    = "PublicDnsExternal"
    }
  }
}
```
AWS provider를 설정하려면 Terraform 공식 문서를 참고하세요. 선택 사항이지만, 이 문서 앞부분에서 언급한 원격 백엔드 설정을 추가하는 것을 강력히 권장합니다.

variables.tf 파일을 생성합니다 Terraform에서는 terraform.tfvars에 설정된 각 옵션마다 이에 대응하는 변수 선언이 필요합니다.

variable "namespace" {
  type        = string
  description = "리소스에 사용되는 이름 접두사"
}

variable "domain_name" {
  type        = string
  description = "인스턴스에 접근하는 데 사용되는 도메인 이름."
}

variable "subdomain" {
  type        = string
  default     = null
  description = "Weights & Biases UI에 접근하기 위한 서브도메인."
}

variable "license" {
  type = string
}

variable "zone_id" {
  type        = string
  description = "Weights & Biases 서브도메인을 생성할 도메인."
}

variable "allowed_inbound_cidr" {
 description = "wandb-server에 접근이 허용된 CIDR 목록."
 nullable    = false
 type        = list(string)
}

variable "allowed_inbound_ipv6_cidr" {
 description = "wandb-server에 접근이 허용된 CIDR 목록."
 nullable    = false
 type        = list(string)
}

variable "eks_cluster_version" {
 description = "EKS 클러스터 쿠버네티스 버전"
 nullable    = false
 type        = string
}

권장 배포

이것은 모든 필수 컴포넌트를 생성하고 Kubernetes Cluster에 W&B 최신 버전을 설치하는 가장 간단한 배포 옵션 설정입니다.

main.tf 파일 생성 General Steps에서 파일을 만든 동일한 디렉터리에 다음 내용으로 main.tf 파일을 만드세요:

module "wandb_infra" {
  source  = "wandb/wandb/aws"
  version = "~>7.0"

  namespace   = var.namespace
  domain_name = var.domain_name
  license     = var.license
  subdomain   = var.subdomain
  zone_id     = var.zone_id

  allowed_inbound_cidr           = var.allowed_inbound_cidr
  allowed_inbound_ipv6_cidr      = var.allowed_inbound_ipv6_cidr

  public_access                  = true
  external_dns                   = true
  kubernetes_public_access       = true
  kubernetes_public_access_cidrs = ["0.0.0.0/0"]
  eks_cluster_version            = var.eks_cluster_version
}

 data "aws_eks_cluster" "eks_cluster_id" {
   name = module.wandb_infra.cluster_name
 }

 data "aws_eks_cluster_auth" "eks_cluster_auth" {
   name = module.wandb_infra.cluster_name
 }

 provider "kubernetes" {
   host                   = data.aws_eks_cluster.eks_cluster_id.endpoint
   cluster_ca_certificate = base64decode(data.aws_eks_cluster.eks_cluster_id.certificate_authority.0.data)
   token                  = data.aws_eks_cluster_auth.eks_cluster_auth.token
 }


 provider "helm" {
   kubernetes {
     host                   = data.aws_eks_cluster.eks_cluster_id.endpoint
     cluster_ca_certificate = base64decode(data.aws_eks_cluster.eks_cluster_id.certificate_authority.0.data)
     token                  = data.aws_eks_cluster_auth.eks_cluster_auth.token
   }
 }

 output "url" {
   value = module.wandb_infra.url
 }

 output "bucket" {
   value = module.wandb_infra.bucket_name
 }

W&B 배포하기 W&B를 배포하려면 다음 명령어를 실행하세요:
```
terraform init
terraform apply -var-file=terraform.tfvars
```

Redis 활성화

Redis를 사용해 SQL 쿼리를 캐시하고 메트릭 로딩 시 애플리케이션 응답 속도를 높이려면 main.tf 파일에 create_elasticache_subnet = true 옵션을 추가하세요:

module "wandb_infra" {
  source  = "wandb/wandb/aws"
  version = "~>7.0"

  namespace   = var.namespace
  domain_name = var.domain_name
  subdomain   = var.subdomain
  zone_id     = var.zone_id
  create_elasticache_subnet = true
}
[...]

메시지 브로커(큐) 활성화

SQS를 사용하여 외부 메시지 브로커를 활성화하려면 main.tf 파일에 use_internal_queue = false 옵션을 추가하세요:

W&B에는 내장 브로커가 포함되어 있으므로 이는 선택 사항입니다. 이 옵션은 성능 향상을 제공하지 않습니다.

module "wandb_infra" {
  source  = "wandb/wandb/aws"
  version = "~>7.0"

  namespace   = var.namespace
  domain_name = var.domain_name
  subdomain   = var.subdomain
  zone_id     = var.zone_id
  use_internal_queue = false

[...]
}

추가 리소스

W&B는 Google Cloud에 플랫폼을 배포할 때 W&B Server Google Cloud Terraform Module 사용을 권장합니다.모듈 문서는 방대하며 사용 가능한 모든 옵션을 담고 있습니다.시작하기 전에, W&B는 Terraform에서 State File을 저장할 원격 백엔드 중 하나를 선택할 것을 권장합니다. State File은 모든 컴포넌트를 재생성하지 않고도 배포 환경에서 업그레이드를 적용하거나 변경 사항을 반영하는 데 필요한 리소스입니다.Terraform Module은 다음의 필수 컴포넌트를 배포합니다:

VPC
MySQL용 Cloud SQL
클라우드 저장소 버킷
Google Kubernetes Engine
Memorystore for Redis
KMS 암호화 키
로드 밸런서

선택적 컴포넌트는 다음과 같습니다:

Pub/Sub 메시징 시스템

사전 필요 권한

Terraform를 실행할 계정은 사용하는 Google Cloud 프로젝트에서 roles/owner 역할이 있어야 합니다.

일반 step

이 섹션의 단계는 모든 배포 옵션에 공통으로 적용됩니다.

개발 환경을 준비하세요.
- Terraform을 설치합니다.
- W&B는 사용할 코드가 포함된 Git 저장소를 만드는 것을 권장하지만, 파일을 로컬에 보관해도 됩니다.
- Google Cloud Console에서 프로젝트를 생성합니다.
- gcloud auth application-default login을 사용해 Google Cloud에 인증합니다(먼저 gcloud를 설치해야 합니다).
terraform.tfvars 파일을 생성하세요. tvfars 파일 내용은 설치 유형에 맞게 사용자 지정할 수 있지만, 최소 권장 구성은 아래 예시와 같습니다.
```
project_id  = "wandb-project"
region      = "europe-west2"
zone        = "europe-west2-a"
namespace   = "wandb"
license     = "xxxxxxxxxxyyyyyyyyyyyzzzzzzz"
subdomain   = "wandb-gcp"
domain_name = "wandb.ml"
```
여기에서 정의한 변수는 배포 전에 미리 정해야 합니다. namespace 변수는 Terraform이 생성하는 모든 리소스 이름 앞에 붙는 문자열입니다. subdomain과 domain을 조합해 W&B를 설정할 FQDN을 구성합니다. 위 예시에서 W&B의 FQDN은 wandb-gcp.wandb.ml입니다.

variables.tf 파일을 만듭니다. terraform.tfvars에 설정한 각 옵션에 대해 Terraform에는 해당하는 변수 선언이 필요합니다.

variable "project_id" {
  type        = string
  description = "Project ID"
}

variable "region" {
  type        = string
  description = "Google region"
}

variable "zone" {
  type        = string
  description = "Google zone"
}

variable "namespace" {
  type        = string
  description = "Namespace prefix used for resources"
}

variable "domain_name" {
  type        = string
  description = "Domain name for accessing the Weights & Biases UI."
}

variable "subdomain" {
  type        = string
  description = "Subdomain for access the Weights & Biases UI."
}

variable "license" {
  type        = string
  description = "W&B License"
}

권장 배포

이것은 모든 필수 컴포넌트를 생성하고 Kubernetes 클러스터에 최신 버전의 W&B를 설치하는 가장 간단한 배포 옵션 설정입니다.

main.tf를 생성하세요 General Steps에서 파일을 만든 것과 같은 디렉터리에 다음 내용으로 main.tf 파일을 만드세요:

provider "google" {
 project = var.project_id
 region  = var.region
 zone    = var.zone
}

provider "google-beta" {
 project = var.project_id
 region  = var.region
 zone    = var.zone
}

data "google_client_config" "current" {}

provider "kubernetes" {
  host                   = "https://${module.wandb.cluster_endpoint}"
  cluster_ca_certificate = base64decode(module.wandb.cluster_ca_certificate)
  token                  = data.google_client_config.current.access_token
}

provider "helm" {
  kubernetes {
    host                   = "https://${module.wandb.cluster_endpoint}"
    cluster_ca_certificate = base64decode(module.wandb.cluster_ca_certificate)
    token                  = data.google_client_config.current.access_token
  }
}

# 필요한 모든 서비스 시작
module "wandb" {
  source  = "wandb/wandb/google"
  version = "~> 10.0"

  namespace   = var.namespace
  license     = var.license
  domain_name = var.domain_name
  subdomain   = var.subdomain
}

# 프로비저닝된 IP 주소로 DNS를 업데이트해야 합니다
output "url" {
  value = module.wandb.url
}

output "address" {
  value = module.wandb.address
}

output "bucket_name" {
  value = module.wandb.bucket_name
}

W&B 배포 W&B를 배포하려면 다음 명령어를 실행하세요:
```
terraform init
terraform apply -var-file=terraform.tfvars
```

Redis 활성화

Redis를 사용하여 SQL 쿼리를 캐시하고 메트릭 로딩 시 애플리케이션 응답 속도를 높이려면 main.tf 파일에 create_redis = true 옵션을 추가하세요:

[...]

module "wandb" {
  source  = "wandb/wandb/google"
  version = "~> 10.0"

  namespace    = var.namespace
  license      = var.license
  domain_name  = var.domain_name
  subdomain    = var.subdomain
  create_redis = true
}
[...]

메시지 브로커(큐) 활성화

Pub/Sub를 사용하여 외부 메시지 브로커를 활성화하려면 main.tf 파일에 use_internal_queue = false 옵션을 추가하세요:

W&B에는 내장 브로커가 포함되어 있으므로 이는 선택 사항입니다. 이 옵션으로는 성능이 향상되지 않습니다.

[...]

module "wandb" {
  source  = "wandb/wandb/google"
  version = "~> 10.0"

  namespace          = var.namespace
  license            = var.license
  domain_name        = var.domain_name
  subdomain          = var.subdomain
  use_internal_queue = false
}

[...]

추가 리소스

W&B는 Azure에 플랫폼을 배포할 때 W&B Server Azure Terraform Module 사용을 권장합니다.모듈 문서는 방대하며 사용 가능한 모든 옵션을 담고 있습니다.Terraform Module은 다음의 필수 컴포넌트를 배포합니다:

Azure 리소스 그룹
Azure Virtual Network (VPC)
Azure MySQL Flexible Server
Azure Storage 계정 & Blob Storage
Azure Kubernetes Service
Azure Application Gateway

선택적 컴포넌트는 다음과 같습니다:

Azure Cache for Redis
Azure Event Grid

사전 필요 권한

AzureRM 공급자를 설정하는 가장 간단한 방법은 Azure CLI를 사용하는 것이지만, 자동화 환경에서는 Azure Service Principal을 활용하는 것도 유용합니다.사용하는 인증 방법에 관계없이, Terraform을 실행할 계정은 위에서 설명한 모든 컴포넌트를 생성할 수 있어야 합니다.

일반 step

이 섹션의 단계는 모든 배포 옵션에 공통으로 적용됩니다.

개발 환경을 준비하세요.
- Terraform을 설치합니다.
- W&B는 사용할 코드를 담은 Git 저장소를 만드는 것을 권장하지만, 파일은 로컬에 보관해도 됩니다.
terraform.tfvars 파일을 생성하세요. tvfars 파일 내용은 설치 유형에 따라 사용자 지정할 수 있지만, 최소 권장 구성은 아래 예시와 같습니다.
```
 namespace     = "wandb"
 wandb_license = "xxxxxxxxxxyyyyyyyyyyyzzzzzzz"
 subdomain     = "wandb-azure"
 domain_name   = "wandb.ml"
 location      = "westeurope"
```
여기서 정의된 변수는 배포 전에 결정해야 합니다. namespace 변수는 Terraform이 생성하는 모든 리소스의 접두사로 사용되는 문자열입니다. subdomain과 domain을 조합해 W&B를 설정할 FQDN을 만듭니다. 위 예시에서 W&B의 FQDN은 wandb-azure.wandb.ml입니다.
versions.tf 파일을 생성하세요 이 파일에는 Azure에 W&B를 배포하는 데 필요한 Terraform 및 Terraform provider 버전이 들어 있습니다:
```
  terraform {
 required_version = "~> 1.3"

 required_providers {
   azurerm = {
     source  = "hashicorp/azurerm"
     version = "~> 3.17"
   }
 }
  }
```
Azure provider를 설정하려면 Terraform 공식 문서를 참고하세요. 선택 사항이지만 강력히 권장되므로, 이 문서의 앞부분에서 언급한 remote backend 설정을 추가하세요.

variables.tf 파일을 생성하세요 terraform.tfvars에 설정된 각 옵션에는 Terraform에서 해당 변수를 선언해야 합니다.

    variable "namespace" {
      type        = string
      description = "String used for prefix resources."
    }

    variable "location" {
      type        = string
      description = "Azure Resource Group location"
    }

    variable "domain_name" {
      type        = string
      description = "Domain for accessing the Weights & Biases UI."
    }

    variable "subdomain" {
      type        = string
      default     = null
      description = "Subdomain for accessing the Weights & Biases UI. Default creates record at Route53 Route."
    }

    variable "license" {
      type        = string
      description = "Your wandb/local license"
    }

권장 배포 방식

이것은 모든 필수 컴포넌트를 생성하고 Kubernetes 클러스터에 최신 버전의 W&B를 설치하는 가장 간단한 배포 옵션 설정입니다.

main.tf 파일 생성 General Steps에서 파일을 만든 것과 같은 디렉터리에, 다음 내용을 포함하는 main.tf 파일을 만드세요:

  provider "azurerm" {
 features {}
  }

  provider "kubernetes" {
 host                   = module.wandb.cluster_host
 cluster_ca_certificate = base64decode(module.wandb.cluster_ca_certificate)
 client_key             = base64decode(module.wandb.cluster_client_key)
 client_certificate     = base64decode(module.wandb.cluster_client_certificate)
  }

  provider "helm" {
 kubernetes {
   host                   = module.wandb.cluster_host
   cluster_ca_certificate = base64decode(module.wandb.cluster_ca_certificate)
   client_key             = base64decode(module.wandb.cluster_client_key)
   client_certificate     = base64decode(module.wandb.cluster_client_certificate)
 }
  }

  # 필요한 모든 서비스 시작
  module "wandb" {
 source  = "wandb/wandb/azurerm"
 version = "~> 1.2"

 namespace   = var.namespace
 location    = var.location
 license     = var.license
 domain_name = var.domain_name
 subdomain   = var.subdomain

 deletion_protection = false

 tags = {
   "Example" : "PublicDns"
 }
  }

  output "address" {
 value = module.wandb.address
  }

  output "url" {
 value = module.wandb.url
  }

W&B 배포하기 W&B를 배포하려면 다음 명령어를 실행하세요:
```
terraform init
terraform apply -var-file=terraform.tfvars
```

Redis 활성화

Redis를 사용하여 SQL 쿼리를 캐시하고 메트릭 로딩 시 애플리케이션 응답 속도를 높이려면 main.tf 파일에 create_redis = true 옵션을 추가하세요:

# 필요한 모든 서비스 시작
module "wandb" {
  source  = "wandb/wandb/azurerm"
  version = "~> 1.2"

  namespace   = var.namespace
  location    = var.location
  license     = var.license
  domain_name = var.domain_name
  subdomain   = var.subdomain

  create_redis = true
  [...]
}

메시지 브로커(큐) 활성화

Azure Event Grid를 사용하여 외부 메시지 브로커를 활성화하려면 main.tf 파일에 use_internal_queue = false 옵션을 추가하세요:

W&B에는 내장 브로커가 포함되어 있으므로 이는 선택 사항입니다. 이 옵션으로는 성능이 향상되지 않습니다.

# 필요한 모든 서비스 시작
module "wandb" {
  source  = "wandb/wandb/azurerm"
  version = "~> 1.2"

  namespace   = var.namespace
  location    = var.location
  license     = var.license
  domain_name = var.domain_name
  subdomain   = var.subdomain

  use_internal_queue = false
  [...]
}

추가 리소스

기타 배포 옵션

모든 설정을 동일한 파일에 추가하면 여러 배포 옵션을 조합할 수 있습니다. 각 Terraform 모듈은 표준 옵션 및 권장 배포 섹션에 나와 있는 최소 설정과 함께 조합할 수 있는 여러 옵션을 제공합니다. 사용 가능한 옵션의 전체 목록은 사용 중인 클라우드 제공업체의 모듈 문서를 참고하세요:

W&B 관리 콘솔에 액세스

W&B Kubernetes Operator에는 관리 콘솔이 함께 제공됩니다. 관리 콘솔은 ${HOST_URI}/console에 있으며, 예를 들어 https://wandb.company-name.com/console입니다. 관리 콘솔에 로그인하는 방법은 두 가지입니다.

옵션 1(권장)
옵션 2

브라우저에서 W&B 애플리케이션을 열고 로그인합니다. ${HOST_URI}/(예: https://wandb.company-name.com/)에서 W&B 애플리케이션에 로그인합니다.
콘솔에 액세스합니다. 오른쪽 상단의 아이콘을 클릭한 다음 System console을 클릭합니다. 관리자 권한이 있는 사용자만 System console 항목을 볼 수 있습니다.

W&B는 옵션 1이 작동하지 않는 경우에만 아래 단계에 따라 콘솔에 액세스할 것을 권장합니다.

브라우저에서 콘솔 애플리케이션을 엽니다. 위에 설명된 URL을 열면 로그인 화면으로 리디렉션됩니다.
설치 시 생성된 Kubernetes secret에서 비밀번호를 조회합니다.
```
kubectl get secret wandb-password -o jsonpath='{.data.password}' | base64 -d
```
비밀번호를 복사합니다.
콘솔에 로그인합니다. 복사한 비밀번호를 붙여넣은 다음 Login을 클릭합니다.

W&B Kubernetes Operator 업데이트

이 섹션에서는 W&B Kubernetes Operator를 업데이트하는 방법을 설명합니다.

W&B Kubernetes Operator를 업데이트해도 W&B Server 애플리케이션은 업데이트되지 않습니다.
W&B Operator를 업데이트하기 전에, W&B Kubernetes Operator를 사용하지 않는 Helm chart를 사용 중이라면 여기의 지침을 참조하세요.

아래 코드 스니펫을 터미널에 복사해 붙여넣으세요.

먼저, helm repo update를 사용해 repo를 업데이트합니다:
```
helm repo update
```
다음으로, helm upgrade를 사용해 Helm 차트를 업데이트합니다:
```
helm upgrade operator wandb/operator -n wandb-cr --reuse-values
```

W&B Server 애플리케이션 업데이트

W&B Kubernetes Operator를 사용하는 경우에는 더 이상 W&B Server 애플리케이션을 직접 업데이트할 필요가 없습니다. W&B의 새 소프트웨어 버전이 릴리스되면 Operator가 W&B Server 애플리케이션을 자동으로 업데이트합니다.

Self-Managed 인스턴스를 W&B Operator로 마이그레이션하기

다음 섹션에서는 직접 관리하는 W&B Server 설치를 W&B Operator를 사용해 관리하는 방식으로 마이그레이션하는 방법을 설명합니다. 마이그레이션 절차는 W&B Server를 설치한 방식에 따라 달라집니다:

W&B Operator는 W&B Server의 기본이자 권장되는 설치 방법입니다. 궁금한 점이 있으면 Customer Support 또는 담당 W&B 팀에 문의하세요.

공식 W&B Cloud Terraform Modules를 사용한 경우, 해당 문서로 이동하여 안내된 step을 따르세요:
- AWS
- Google Cloud
- Azure
W&B Non-Operator Helm chart를 사용한 경우, 여기로 계속 진행하세요.
Terraform과 함께 W&B Non-Operator Helm chart를 사용한 경우, 여기로 계속 진행하세요.
manifest로 Kubernetes 리소스를 생성한 경우, 여기로 계속 진행하세요.

Operator 기반 AWS Terraform 모듈로 이전

이전 절차에 대한 자세한 설명은 여기를 참조하세요.

Operator 기반 Google Cloud Terraform 모듈로 마이그레이션

질문이 있거나 도움이 필요하면 Customer Support 또는 담당 W&B 팀에 문의하세요.

Operator 기반 Azure Terraform 모듈로 마이그레이션

질문이 있거나 도움이 필요하면 Customer Support 또는 담당 W&B 팀에 문의하세요.

Operator 기반 Helm chart로 마이그레이션

다음 step에 따라 Operator 기반 Helm chart로 마이그레이션하세요:

현재 W&B 설정을 조회합니다. W&B가 Operator 기반이 아닌 버전의 Helm chart로 배포된 경우, 다음과 같이 값을 내보냅니다:
```
helm get values wandb
```
W&B가 Kubernetes 매니페스트로 배포된 경우, 다음과 같이 값을 내보냅니다:
```
kubectl get deployment wandb -o yaml
```
이제 다음 step에 필요한 모든 설정 값을 확보했습니다.
operator.yaml이라는 파일을 생성합니다. 설정 레퍼런스에 설명된 형식을 따르세요. step 1의 값을 사용합니다.
현재 deployment를 파드 0개로 스케일합니다. 이렇게 하면 현재 deployment가 중지됩니다.
```
kubectl scale --replicas=0 deployment wandb
```
Helm chart 리포지토리를 업데이트합니다:
```
helm repo update
```

새 Helm chart를 설치합니다:

helm upgrade --install operator wandb/operator -n wandb-cr --create-namespace

새 Helm chart를 설정하고 W&B 애플리케이션 배포를 트리거합니다. 새 설정을 적용합니다.
```
kubectl apply -f operator.yaml
```
배포가 완료되기까지 몇 분 정도 걸립니다.
설치를 확인합니다. 설치 확인의 step에 따라 모든 것이 제대로 작동하는지 확인하세요.
이전 설치를 제거합니다. 이전 Helm chart를 제거하거나 매니페스트로 생성한 리소스를 삭제합니다.

Operator 기반 Terraform Helm chart로 마이그레이션

Operator 기반 Helm chart로 마이그레이션하려면 다음 step을 따르세요:

Terraform 설정을 준비합니다. Terraform 설정에서 기존 배포의 Terraform 코드를 여기에 설명된 코드로 교체합니다. 이전과 동일한 변수를 설정합니다. .tfvars 파일이 있다면 변경하지 마세요.
Terraform을 실행합니다. terraform init, plan, apply를 실행합니다.
설치를 확인합니다. 설치 확인의 단계를 따라 모든 것이 정상적으로 작동하는지 확인합니다.
이전 설치를 제거합니다. 기존 Helm chart를 제거하거나 매니페스트로 생성한 리소스를 삭제합니다.

W&B Server 설정 레퍼런스

이 섹션에서는 W&B Server 애플리케이션의 설정 옵션을 설명합니다. 이 애플리케이션은 WeightsAndBiases라는 이름의 커스텀 리소스 정의로 설정을 전달받습니다. 일부 설정 옵션은 아래 설정에서 제공되며, 일부는 환경 변수로 설정해야 합니다. 문서에는 환경 변수 목록이 두 가지 있습니다: basic 및 advanced. 필요한 설정 옵션이 Helm chart를 통해 제공되지 않는 경우에만 환경 변수를 사용하세요.

기본 예제

이 예제는 W&B에 필요한 최소한의 값 집합을 정의합니다. 더 현실적인 프로덕션 예제는 Complete example을 참조하세요. 이 YAML 파일은 버전, 환경 변수, 데이터베이스와 같은 외부 리소스, 기타 필요한 설정을 포함한 W&B 배포의 목표 상태를 정의합니다.

apiVersion: apps.wandb.com/v1
kind: WeightsAndBiases
metadata:
  labels:
    app.kubernetes.io/name: weightsandbiases
    app.kubernetes.io/instance: wandb
  name: wandb
  namespace: default
spec:
  values:
    global:
      host: https://<HOST_URI>
      license: eyJhbGnUzaH...j9ZieKQ2x5GGfw
      bucket:
        <details depend on the provider>
      mysql:
        <redacted>
    ingress:
      annotations:
        <redacted>

W&B Helm 저장소에서 전체 설정값을 확인하세요. 재정의가 필요한 값만 변경하세요.

전체 예제

이 예제 설정은 Google Cloud Storage를 사용해 W&B를 Google Cloud Anthos에 배포합니다:

apiVersion: apps.wandb.com/v1
kind: WeightsAndBiases
metadata:
  labels:
    app.kubernetes.io/name: weightsandbiases
    app.kubernetes.io/instance: wandb
  name: wandb
  namespace: default
spec:
  values:
    global:
      host: https://abc-wandb.sandbox-gcp.wandb.ml
      bucket:
        name: abc-wandb-moving-pipefish
        provider: gcs
      mysql:
        database: wandb_local
        host: 10.218.0.2
        name: wandb_local
        password: 8wtX6cJHizAZvYScjDzZcUarK4zZGjpV
        port: 3306
        user: wandb
      redis:
        host: redis.example.com
        port: 6379
        password: password
      api:
        enabled: true
      glue:
        enabled: true
      executor:
        enabled: true
      license: eyJhbGnUzaHgyQjQyQWhEU3...ZieKQ2x5GGfw
    ingress:
      annotations:
        ingress.gcp.kubernetes.io/pre-shared-cert: abc-wandb-cert-creative-puma
        kubernetes.io/ingress.class: gce
        kubernetes.io/ingress.global-static-ip-name: abc-wandb-operator-address

호스트

 # 프로토콜을 포함한 FQDN을 입력하세요
global:
  # 예시 호스트 이름입니다. 본인의 것으로 교체하세요
  host: https://wandb.example.com

객체 저장소 (버킷)

AWS

global:
  bucket:
    provider: "s3"
    name: ""
    kmsKey: ""
    region: ""

Google Cloud

global:
  bucket:
    provider: "gcs"
    name: ""

Azure

global:
  bucket:
    provider: "az"
    name: ""
    secretKey: ""

기타 제공업체(Minio, Ceph 및 기타 S3 호환 저장소) 다른 S3 호환 제공업체의 경우 버킷 설정을 다음과 같이 지정합니다:

global:
  bucket:
    # 예시 값입니다. 실제 값으로 교체하세요
    provider: s3
    name: storage.example.com
    kmsKey: null
    path: wandb
    region: default
    accessKey: 5WOA500...P5DK7I
    secretKey: HDKYe4Q...JAp1YyjysnX

AWS 외부에 호스팅된 S3 호환 저장소의 경우 kmsKey는 null이어야 합니다. 시크릿에서 accessKey와 secretKey를 참조하려면:

global:
  bucket:
    # 예시 값입니다. 실제 값으로 교체하세요
    provider: s3
    name: storage.example.com
    kmsKey: null
    path: wandb
    region: default
    secret:
      secretName: bucket-secret
      accessKeyName: ACCESS_KEY
      secretKeyName: SECRET_KEY

MySQL

global:
   mysql:
     # 예시 값입니다. 실제 값으로 교체하세요.
     host: db.example.com
     port: 3306
     database: wandb_local
     user: wandb
     password: 8wtX6cJH...ZcUarK4zZGjpV 

시크릿의 password를 참조하려면:

global:
   mysql:
     # 예시 값입니다. 실제 값으로 교체하세요.
     host: db.example.com
     port: 3306
     database: wandb_local
     user: wandb
     passwordSecret:
       name: database-secret
       passwordKey: MYSQL_WANDB_PASSWORD

라이선스

global:
  # 예시 라이선스입니다. 본인의 라이선스로 교체하세요.
  license: eyJhbGnUzaHgyQjQy...VFnPS_KETXg1hi

시크릿의 license를 참조하려면:

global:
  licenseSecret:
    name: license-secret
    key: CUSTOMER_WANDB_LICENSE

인그레스

인그레스 클래스를 파악하려면 이 FAQ 항목을 참조하세요. TLS 없이

global:
# 중요: 인그레스는 YAML에서 'global'과 동일한 레벨에 위치합니다 (하위 항목 아님)
ingress:
  class: ""

TLS 사용 시 인증서가 포함된 시크릿을 생성합니다

kubectl create secret tls wandb-ingress-tls --key wandb-ingress-tls.key --cert wandb-ingress-tls.crt

인그레스 설정에서 시크릿 참조하기

global:
# 중요: 인그레스는 YAML에서 'global'과 동일한 레벨에 위치합니다 (하위 항목 아님)
ingress:
  class: ""
  annotations:
    {}
    # kubernetes.io/ingress.class: nginx
    # kubernetes.io/tls-acme: "true"
  tls: 
    - secretName: wandb-ingress-tls
      hosts:
        - <HOST_URI>

Nginx의 경우 다음 어노테이션을 추가해야 할 수 있습니다.

ingress:
  annotations:
    nginx.ingress.kubernetes.io/proxy-body-size: 0

맞춤형 Kubernetes 서비스 계정

W&B 파드를 실행할 맞춤형 Kubernetes 서비스 계정을 지정합니다. 다음 스니펫은 배포 시 지정한 이름으로 서비스 계정을 생성합니다.

app:
  serviceAccount:
    name: custom-service-account
    create: true

parquet:
  serviceAccount:
    name: custom-service-account
    create: true

global:
  ...

서브시스템 “app” 및 “parquet”는 지정된 서비스 계정으로 실행됩니다. 다른 서브시스템은 기본 서비스 계정으로 실행됩니다. 서비스 계정이 클러스터에 이미 존재하는 경우 create: false로 설정합니다:

app:
  serviceAccount:
    name: custom-service-account
    create: false

parquet:
  serviceAccount:
    name: custom-service-account
    create: false
    
global:
  ...

app, parquet, console 등 여러 서브시스템에 서비스 계정을 지정할 수 있습니다:

app:
  serviceAccount:
    name: custom-service-account
    create: true

console:
  serviceAccount:
    name: custom-service-account
    create: true

global:
  ...

각 서브시스템의 서비스 계정은 서로 다를 수 있습니다:

app:
  serviceAccount:
    name: custom-service-account
    create: false

console:
  serviceAccount:
    name: another-custom-service-account
    create: true

global:
  ...

External Redis

redis:
  install: false

global:
  redis:
    host: ""
    port: 6379
    password: ""
    parameters: {}
    caCert: ""

시크릿의 password를 참조하려면:

kubectl create secret generic redis-secret --from-literal=redis-password=supersecret

아래 설정에서 이를 참조하세요:

redis:
  install: false

global:
  redis:
    host: redis.example
    port: 9001
    auth:
      enabled: true
      secret: redis-secret
      key: redis-password

LDAP

현재 Helm chart에서는 LDAP 설정 지원이 제한적입니다. LDAP 설정에 도움이 필요하면 W&B 지원팀 또는 AISE에 문의하세요.

global.extraEnv에서 환경 변수를 설정해 LDAP를 구성하세요:

global:
  extraEnv:
    LDAP_ADDRESS: ldaps://ldap.company.example.com
    LDAP_BASE_DN: cn=accounts,dc=company,dc=example,dc=com
    LDAP_USER_BASE_DN: cn=users,cn=accounts,dc=company,dc=example,dc=com
    LDAP_GROUP_BASE_DN: cn=groups,cn=accounts,dc=company,dc=example,dc=com
    LDAP_BIND_DN: uid=ldapbind,cn=sysaccounts,cn=etc,dc=company,dc=example,dc=com
    LDAP_BIND_PW: ********************
    LDAP_ATTRIBUTES: email=mail,name=cn
    LDAP_TLS_ENABLE: "true"
    LDAP_LOGIN: "true"
    LDAP_USER_OBJECT_CLASS: user
    LDAP_GROUP_OBJECT_CLASS: group

OIDC SSO

global: 
  auth:
    sessionLengthHours: 720
    oidc:
      clientId: ""
      secret: ""
      # IdP에서 필요한 경우에만 포함하세요.
      authMethod: ""
      issuer: ""

authMethod은 선택 사항입니다.

SMTP

global:
  email:
    smtp:
      host: ""
      port: 587
      user: ""
      password: ""

환경 변수

global:
  extraEnv:
    GLOBAL_ENV: "example"

맞춤형 인증 기관

customCACerts는 목록이므로 여러 인증서를 지정할 수 있습니다. customCACerts에 지정한 인증 기관은 W&B Server 애플리케이션에만 적용됩니다.

global:
  customCACerts:
  - |
    -----BEGIN CERTIFICATE-----
    MIIBnDCCAUKgAwIBAg.....................fucMwCgYIKoZIzj0EAwIwLDEQ
    MA4GA1UEChMHSG9tZU.....................tZUxhYiBSb290IENBMB4XDTI0
    MDQwMTA4MjgzMFoXDT.....................oNWYggsMo8O+0mWLYMAoGCCqG
    SM49BAMCA0gAMEUCIQ.....................hwuJgyQRaqMI149div72V2QIg
    P5GD+5I+02yEp58Cwxd5Bj2CvyQwTjTO4hiVl1Xd0M0=
    -----END CERTIFICATE-----
  - |
    -----BEGIN CERTIFICATE-----
    MIIBxTCCAWugAwIB.......................qaJcwCgYIKoZIzj0EAwIwLDEQ
    MA4GA1UEChMHSG9t.......................tZUxhYiBSb290IENBMB4XDTI0
    MDQwMTA4MjgzMVoX.......................UK+moK4nZYvpNpqfvz/7m5wKU
    SAAwRQIhAIzXZMW4.......................E8UFqsCcILdXjAiA7iTluM0IU
    aIgJYVqKxXt25blH/VyBRzvNhViesfkNUQ==
    -----END CERTIFICATE-----

CA certificates는 ConfigMap에 저장할 수도 있습니다:

global:
  caCertsConfigMap: custom-ca-certs

ConfigMap은 다음과 같은 형식이어야 합니다:

apiVersion: v1
kind: ConfigMap
metadata:
  name: custom-ca-certs
data:
  ca-cert1.crt: |
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----
  ca-cert2.crt: |
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----

ConfigMap을 사용하는 경우 ConfigMap의 각 키는 .crt로 끝나야 합니다(예: my-cert.crt 또는 ca-cert1.crt). update-ca-certificates가 각 인증서를 파싱해 시스템 CA 저장소에 추가하려면 이 명명 규칙을 따라야 합니다.

맞춤형 보안 컨텍스트

각 W&B 구성 요소는 다음 형식의 맞춤형 보안 컨텍스트 설정을 지원합니다:

pod:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1001
    runAsGroup: 0
    fsGroup: 1001
    fsGroupChangePolicy: Always
    seccompProfile:
      type: RuntimeDefault
container:
  securityContext:
    capabilities:
      drop:
        - ALL
    readOnlyRootFilesystem: false
    allowPrivilegeEscalation: false 

runAsGroup:에 유효한 값은 0뿐입니다. 그 외의 값은 모두 오류입니다.

예를 들어 애플리케이션 파드를 설정하려면 설정에 app 섹션을 추가하세요:

global:
  ...
app:
  pod:
    securityContext:
      runAsNonRoot: true
      runAsUser: 1001
      runAsGroup: 0
      fsGroup: 1001
      fsGroupChangePolicy: Always
      seccompProfile:
        type: RuntimeDefault
  container:
    securityContext:
      capabilities:
        drop:
          - ALL
      readOnlyRootFilesystem: false
      allowPrivilegeEscalation: false 

동일한 개념은 console, weave, weave-trace, parquet에도 적용됩니다.

W&B Operator용 설정 레퍼런스

이 섹션에서는 W&B Kubernetes Operator(wandb-controller-manager)의 설정 옵션을 설명합니다. Operator는 YAML 파일 형식으로 설정을 전달받습니다. 기본적으로 W&B Kubernetes Operator에는 설정 파일이 필요하지 않습니다. 필요한 경우에만 설정 파일을 만드세요. 예를 들어, 사용자 지정 인증 기관(CA)을 지정하거나 에어갭 환경에 배포해야 하는 경우 설정 파일이 필요할 수 있습니다. spec 사용자 지정의 전체 목록은 Helm 저장소에서 확인하세요.

맞춤형 CA

맞춤형 인증 기관(customCACerts)은 여러 인증서를 포함할 수 있는 목록입니다. 이렇게 추가한 인증 기관은 W&B Kubernetes operator(wandb-controller-manager)에만 적용됩니다.

customCACerts:
- |
  -----BEGIN CERTIFICATE-----
  MIIBnDCCAUKgAwIBAg.....................fucMwCgYIKoZIzj0EAwIwLDEQ
  MA4GA1UEChMHSG9tZU.....................tZUxhYiBSb290IENBMB4XDTI0
  MDQwMTA4MjgzMFoXDT.....................oNWYggsMo8O+0mWLYMAoGCCqG
  SM49BAMCA0gAMEUCIQ.....................hwuJgyQRaqMI149div72V2QIg
  P5GD+5I+02yEp58Cwxd5Bj2CvyQwTjTO4hiVl1Xd0M0=
  -----END CERTIFICATE-----
- |
  -----BEGIN CERTIFICATE-----
  MIIBxTCCAWugAwIB.......................qaJcwCgYIKoZIzj0EAwIwLDEQ
  MA4GA1UEChMHSG9t.......................tZUxhYiBSb290IENBMB4XDTI0
  MDQwMTA4MjgzMVoX.......................UK+moK4nZYvpNpqfvz/7m5wKU
  SAAwRQIhAIzXZMW4.......................E8UFqsCcILdXjAiA7iTluM0IU
  aIgJYVqKxXt25blH/VyBRzvNhViesfkNUQ==
  -----END CERTIFICATE-----

CA certificates를 ConfigMap에도 저장할 수 있습니다:

caCertsConfigMap: custom-ca-certs

ConfigMap은 다음과 같아야 합니다:

apiVersion: v1
kind: ConfigMap
metadata:
  name: custom-ca-certs
data:
  ca-cert1.crt: |
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----
  ca-cert2.crt: |
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----

ConfigMap의 각 키는 반드시 .crt로 끝나야 합니다(예: my-cert.crt 또는 ca-cert1.crt). update-ca-certificates가 각 인증서를 인식해 시스템 CA 저장소에 추가하려면 이 명명 규칙을 따라야 합니다.

FAQ

각 개별 파드의 목적/역할은 무엇인가요?

wandb-app: GraphQL API와 프런트엔드 애플리케이션을 포함한 W&B의 핵심입니다. 플랫폼의 대부분의 기능을 담당합니다.
wandb-console: /console을 통해 접속하는 관리 콘솔입니다.
wandb-otel: Kubernetes 계층의 리소스에서 메트릭과 로그를 수집해 관리 콘솔에 표시하는 OpenTelemetry 에이전트입니다.
wandb-prometheus: 다양한 컴포넌트에서 메트릭을 수집해 관리 콘솔에 표시하는 Prometheus 서버입니다.
wandb-parquet: 데이터베이스 데이터를 Parquet 형식으로 객체 저장소에 내보내는, wandb-app 파드와 분리된 백엔드 마이크로서비스입니다.
wandb-weave: UI에서 쿼리 테이블을 로드하고 앱의 다양한 핵심 기능을 지원하는 또 다른 백엔드 마이크로서비스입니다.
wandb-weave-trace: LLM 기반 애플리케이션을 추적, 실험, 평가, 배포 및 개선하기 위한 프레임워크입니다. 이 프레임워크는 wandb-app 파드를 통해 액세스합니다.

W&B Operator Console 비밀번호를 조회하는 방법

W&B Kubernetes Operator 관리 콘솔에 접속하기를 참조하세요.

인그레스가 작동하지 않을 때 W&B Operator Console에 접속하는 방법

Kubernetes 클러스터에 접속할 수 있는 호스트에서 다음 명령어를 실행합니다:

kubectl port-forward svc/wandb-console 8082

브라우저에서 https://localhost:8082/ 콘솔에 접속합니다. 비밀번호를 확인하는 방법(옵션 2)은 W&B Kubernetes Operator 관리 콘솔에 접속하기를 참조하세요.

W&B Server 로그를 확인하는 방법

애플리케이션 파드 이름은 wandb-app-xxx입니다.

kubectl get pods
kubectl logs wandb-XXXXX-XXXXX

Kubernetes 인그레스 클래스를 파악하는 방법

다음을 실행하면 클러스터에 설치된 인그레스 클래스를 확인할 수 있습니다.

kubectl get ingressclass

W&B에 오신 것을 환영합니다

제품

플랫폼 세부 정보

리소스

​Overview

​시작하기 전에

​MySQL 데이터베이스

​Redis

​객체 저장소

​저장소 버킷 프로비저닝

​OpenShift Kubernetes 클러스터

​컨테이너를 비특권 사용자로 실행

​W&B Server 애플리케이션 배포

​Helm Terraform Module

​클라우드 Terraform 모듈

​설치 확인하기

​환경별 고려 사항

​온프레미스 및 베어메탈

​로드 밸런서 설정

​영구 저장소

​DNS 및 인증서 관리

​OpenShift 배포

​온프레미스 및 S3 호환 환경용 객체 저장소

​Terraform을 사용한 퍼블릭 클라우드

​Terraform으로 퍼블릭 클라우드에 배포하기

​사전 필요 권한

​일반 step

​권장 배포

​Redis 활성화

​메시지 브로커(큐) 활성화

​추가 리소스

​사전 필요 권한

​일반 step

​권장 배포

​Redis 활성화

​메시지 브로커(큐) 활성화

​추가 리소스

​사전 필요 권한

​일반 step

​권장 배포 방식

​Redis 활성화

​메시지 브로커(큐) 활성화

​추가 리소스

​기타 배포 옵션

​W&B 관리 콘솔에 액세스

​W&B Kubernetes Operator 업데이트

​W&B Server 애플리케이션 업데이트

​Self-Managed 인스턴스를 W&B Operator로 마이그레이션하기

​Operator 기반 AWS Terraform 모듈로 이전

​Operator 기반 Google Cloud Terraform 모듈로 마이그레이션

​Operator 기반 Azure Terraform 모듈로 마이그레이션

​Operator 기반 Helm chart로 마이그레이션

​Operator 기반 Terraform Helm chart로 마이그레이션

​W&B Server 설정 레퍼런스

​기본 예제

​전체 예제

​호스트

​객체 저장소 (버킷)

​MySQL

​라이선스

​인그레스

​맞춤형 Kubernetes 서비스 계정

​External Redis

​LDAP

​OIDC SSO

​SMTP

​환경 변수

​맞춤형 인증 기관

​맞춤형 보안 컨텍스트

​W&B Operator용 설정 레퍼런스

​맞춤형 CA

​FAQ

​각 개별 파드의 목적/역할은 무엇인가요?

​W&B Operator Console 비밀번호를 조회하는 방법

​인그레스가 작동하지 않을 때 W&B Operator Console에 접속하는 방법

​W&B Server 로그를 확인하는 방법

​Kubernetes 인그레스 클래스를 파악하는 방법

Overview

시작하기 전에

MySQL 데이터베이스

Redis

객체 저장소

저장소 버킷 프로비저닝

OpenShift Kubernetes 클러스터

컨테이너를 비특권 사용자로 실행

W&B Server 애플리케이션 배포

Helm Terraform Module

클라우드 Terraform 모듈

설치 확인하기

환경별 고려 사항

온프레미스 및 베어메탈

로드 밸런서 설정

영구 저장소

DNS 및 인증서 관리

OpenShift 배포

온프레미스 및 S3 호환 환경용 객체 저장소

Terraform을 사용한 퍼블릭 클라우드

Terraform으로 퍼블릭 클라우드에 배포하기

사전 필요 권한

일반 step

권장 배포

Redis 활성화

메시지 브로커(큐) 활성화

추가 리소스

사전 필요 권한

일반 step

권장 배포

Redis 활성화

메시지 브로커(큐) 활성화

추가 리소스

사전 필요 권한

일반 step

권장 배포 방식

Redis 활성화

메시지 브로커(큐) 활성화

추가 리소스

기타 배포 옵션

W&B 관리 콘솔에 액세스

W&B Kubernetes Operator 업데이트

W&B Server 애플리케이션 업데이트

Self-Managed 인스턴스를 W&B Operator로 마이그레이션하기

Operator 기반 AWS Terraform 모듈로 이전

Operator 기반 Google Cloud Terraform 모듈로 마이그레이션

Operator 기반 Azure Terraform 모듈로 마이그레이션

Operator 기반 Helm chart로 마이그레이션

Operator 기반 Terraform Helm chart로 마이그레이션

W&B Server 설정 레퍼런스

기본 예제

전체 예제

호스트

객체 저장소 (버킷)

MySQL

라이선스

인그레스

맞춤형 Kubernetes 서비스 계정

External Redis

LDAP

OIDC SSO

SMTP

환경 변수

맞춤형 인증 기관

맞춤형 보안 컨텍스트

W&B Operator용 설정 레퍼런스

맞춤형 CA

FAQ

각 개별 파드의 목적/역할은 무엇인가요?

W&B Operator Console 비밀번호를 조회하는 방법

인그레스가 작동하지 않을 때 W&B Operator Console에 접속하는 방법

W&B Server 로그를 확인하는 방법

Kubernetes 인그레스 클래스를 파악하는 방법