Self-managed

• 1: Reference Architecture
• 2: Run W&B Server on Kubernetes
• 2.1: Kubernetes operator for air-gapped instances
• 3: Install on public cloud
• 3.1: Deploy W&B Platform on AWS
• 3.2: Deploy W&B Platform on GCP
• 3.3: Deploy W&B Platform on Azure
• 4: Deploy W&B Platform On-premises
• 5: Update W&B license and version

1 - Reference Architecture

이 페이지에서는 Weights & Biases 배포를 위한 참조 아키텍처를 설명하고 플랫폼의 프로덕션 배포를 지원하기 위해 권장되는 인프라 및 리소스를 간략하게 설명합니다.

Weights & Biases(W&B)에 대해 선택한 배포 환경에 따라 다양한 서비스를 통해 배포의 복원력을 향상시킬 수 있습니다.

예를 들어 주요 클라우드 공급자는 데이터베이스 구성, 유지 관리, 고가용성 및 복원력의 복잡성을 줄이는 데 도움이 되는 강력한 관리형 데이터베이스 서비스를 제공합니다.

이 참조 아키텍처는 몇 가지 일반적인 배포 시나리오를 다루고 최적의 성능과 안정성을 위해 W&B 배포를 클라우드 공급업체 서비스와 통합하는 방법을 보여줍니다.

시작하기 전에

모든 애플리케이션을 프로덕션 환경에서 실행하는 데에는 자체적인 어려움이 따르며 W&B도 예외는 아닙니다. Google은 프로세스를 간소화하는 것을 목표로 하지만 고유한 아키텍처 및 설계 결정에 따라 특정 복잡성이 발생할 수 있습니다. 일반적으로 프로덕션 배포를 관리하려면 하드웨어, 운영 체제, 네트워킹, 스토리지, 보안, W&B 플랫폼 자체 및 기타 종속성을 포함한 다양한 구성 요소를 감독해야 합니다. 이 책임은 환경의 초기 설정과 지속적인 유지 관리 모두에 적용됩니다.

W&B를 사용한 자체 관리 방식이 팀 및 특정 요구 사항에 적합한지 신중하게 고려하십시오.

프로덕션 등급 애플리케이션을 실행하고 유지 관리하는 방법에 대한 확실한 이해는 자체 관리 W&B를 배포하기 전에 중요한 전제 조건입니다. 팀에 지원이 필요한 경우 Google의 Professional Services 팀과 파트너가 구현 및 최적화에 대한 지원을 제공합니다.

직접 관리하는 대신 W&B 실행을 위한 관리형 솔루션에 대한 자세한 내용은 W&B 멀티 테넌트 클라우드 및 W&B 전용 클라우드를 참조하십시오.

인프라

애플리케이션 레이어

애플리케이션 레이어는 노드 장애에 대한 복원력을 갖춘 다중 노드 Kubernetes 클러스터로 구성됩니다. Kubernetes 클러스터는 W&B의 포드를 실행하고 유지 관리합니다.

스토리지 레이어

스토리지 레이어는 MySQL 데이터베이스와 오브젝트 스토리지로 구성됩니다. MySQL 데이터베이스는 메타데이터를 저장하고 오브젝트 스토리지는 모델 및 데이터셋과 같은 아티팩트를 저장합니다.

인프라 요구 사항

Kubernetes

W&B Server 애플리케이션은 여러 포드를 배포하는 Kubernetes Operator로 배포됩니다. 이러한 이유로 W&B에는 다음이 포함된 Kubernetes 클러스터가 필요합니다.

• 완전히 구성되고 작동하는 Ingress 컨트롤러.
• Persistent Volumes를 프로비저닝하는 기능.

MySQL

W&B는 메타데이터를 MySQL 데이터베이스에 저장합니다. 데이터베이스의 성능 및 스토리지 요구 사항은 모델 파라미터 및 관련 메타데이터의 형태에 따라 달라집니다. 예를 들어 더 많은 트레이닝 run을 추적할수록 데이터베이스 크기가 커지고 run 테이블, 사용자 워크스페이스 및 리포트의 쿼리를 기반으로 데이터베이스에 대한 부하가 증가합니다.

자체 관리 MySQL 데이터베이스를 배포할 때 다음 사항을 고려하십시오.

• 백업. 데이터베이스를 별도의 시설에 주기적으로 백업해야 합니다. W&B는 최소 1주일의 보존 기간으로 매일 백업하는 것이 좋습니다.
• 성능. 서버가 실행되는 디스크는 빨라야 합니다. W&B는 SSD 또는 가속화된 NAS에서 데이터베이스를 실행하는 것이 좋습니다.
• 모니터링. 데이터베이스의 부하를 모니터링해야 합니다. CPU 사용량이 시스템의 40%를 초과하여 5분 이상 유지되면 서버에 리소스가 부족하다는 좋은 징조일 수 있습니다.
• 가용성. 가용성 및 내구성 요구 사항에 따라 기본 서버에서 모든 업데이트를 실시간으로 스트리밍하고 기본 서버가 충돌하거나 손상될 경우 장애 조치하는 데 사용할 수 있는 별도의 시스템에서 핫 스탠바이를 구성할 수 있습니다.

오브젝트 스토리지

W&B에는 사전 서명된 URL 및 CORS 지원이 포함된 오브젝트 스토리지가 필요하며 다음 중 하나로 배포됩니다.

• Amazon S3
• Azure Cloud Storage
• Google Cloud Storage
• Amazon S3와 호환되는 스토리지 서비스

버전

네트워킹

네트워크로 연결된 배포의 경우 설치 및 런타임 모두 중에 이러한 엔드포인트에 대한 송신이 필요합니다.

• https://deploy.wandb.ai
• https://charts.wandb.ai
• https://docker.io
• https://quay.io
• https://gcr.io

에어 갭 배포에 대한 자세한 내용은 에어 갭 인스턴스용 Kubernetes operator를 참조하십시오. W&B와 오브젝트 스토리지에 대한 엑세스는 트레이닝 인프라와 Experiments의 요구 사항을 추적하는 각 시스템에 필요합니다.

DNS

W&B 배포의 정규화된 도메인 이름(FQDN)은 A 레코드를 사용하여 수신/로드 밸런서의 IP 어드레스로 확인되어야 합니다.

SSL/TLS

W&B에는 클라이언트와 서버 간의 보안 통신을 위한 유효한 서명된 SSL/TLS 인증서가 필요합니다. SSL/TLS 종료는 수신/로드 밸런서에서 발생해야 합니다. W&B Server 애플리케이션은 SSL 또는 TLS 연결을 종료하지 않습니다.

참고: W&B는 자체 서명된 인증서 및 사용자 지정 CA의 사용을 권장하지 않습니다.

지원되는 CPU 아키텍처

W&B는 Intel(x86) CPU 아키텍처에서 실행됩니다. ARM은 지원되지 않습니다.

인프라 프로비저닝

Terraform은 프로덕션 환경을 위해 W&B를 배포하는 데 권장되는 방법입니다. Terraform을 사용하면 필요한 리소스, 다른 리소스에 대한 참조 및 종속성을 정의합니다. W&B는 주요 클라우드 공급자를 위한 Terraform 모듈을 제공합니다. 자세한 내용은 자체 관리 클라우드 계정 내에서 W&B Server 배포를 참조하십시오.

크기 조정

배포를 계획할 때 다음 일반 지침을 시작점으로 사용하십시오. W&B는 새로운 배포의 모든 구성 요소를 면밀히 모니터링하고 관찰된 사용 패턴에 따라 조정하는 것이 좋습니다. 시간이 지남에 따라 프로덕션 배포를 계속 모니터링하고 최적의 성능을 유지하기 위해 필요에 따라 조정하십시오.

모델만 해당

Kubernetes

숫자는 Kubernetes 작업자 노드당 개수입니다.

MySQL

숫자는 MySQL 노드당 개수입니다.

Weave만 해당

Kubernetes

숫자는 Kubernetes 작업자 노드당 개수입니다.

MySQL

숫자는 MySQL 노드당 개수입니다.

모델 및 Weave

Kubernetes

숫자는 Kubernetes 작업자 노드당 개수입니다.

MySQL

숫자는 MySQL 노드당 개수입니다.

클라우드 공급자 인스턴스 권장 사항

서비스

머신 유형

이러한 권장 사항은 클라우드 인프라에서 W&B의 자체 관리 배포의 각 노드에 적용됩니다.

AWS

GCP

Azure

2 - Run W&B Server on Kubernetes

W&B Kubernetes Operator

W&B Kubernetes Operator를 사용하면 Kubernetes에서 W&B Server 배포를 간소화하고, 관리하고, 문제를 해결하고, 확장할 수 있습니다. 이 Operator는 W&B 인스턴스를 위한 스마트 도우미라고 생각하면 됩니다.

W&B Server 아키텍처와 디자인은 AI 개발자 툴링 기능을 확장하고, 고성능, 더 나은 확장성, 더 쉬운 관리를 위한 적절한 기본 요소를 제공하기 위해 지속적으로 발전하고 있습니다. 이러한 발전은 컴퓨팅 서비스, 관련 스토리지 및 이들 간의 연결에 적용됩니다. 모든 배포 유형에서 지속적인 업데이트와 개선을 용이하게 하기 위해 W&B는 Kubernetes operator를 사용합니다.

Kubernetes operator에 대한 자세한 내용은 Kubernetes 설명서의 Operator 패턴을 참조하세요.

아키텍처 전환 이유

과거에는 W&B 애플리케이션이 Kubernetes 클러스터 내의 단일 배포 및 pod 또는 단일 Docker 컨테이너로 배포되었습니다. W&B는 데이터베이스 및 오브젝트 저장소를 외부화할 것을 권장해 왔으며 앞으로도 계속 권장할 것입니다. 데이터베이스 및 오브젝트 저장소를 외부화하면 애플리케이션의 상태가 분리됩니다.

애플리케이션이 성장함에 따라 모놀리식 컨테이너에서 분산 시스템(마이크로서비스)으로 발전해야 할 필요성이 분명해졌습니다. 이러한 변경은 백엔드 로직 처리를 용이하게 하고 내장된 Kubernetes 인프라 기능을 원활하게 도입합니다. 분산 시스템은 또한 W&B가 의존하는 추가 기능에 필수적인 새로운 서비스 배포를 지원합니다.

2024년 이전에는 Kubernetes 관련 변경 사항이 있을 때마다 terraform-kubernetes-wandb Terraform 모듈을 수동으로 업데이트해야 했습니다. Terraform 모듈을 업데이트하면 클라우드 공급자 간의 호환성이 보장되고 필요한 Terraform 변수가 구성되며 각 백엔드 또는 Kubernetes 수준 변경에 대해 Terraform 적용이 실행됩니다.

W&B 지원팀이 각 고객의 Terraform 모듈 업그레이드를 지원해야 했기 때문에 이 프로세스는 확장 가능하지 않았습니다.

해결책은 중앙 deploy.wandb.ai 서버에 연결하여 주어진 릴리스 채널에 대한 최신 사양 변경 사항을 요청하고 적용하는 operator를 구현하는 것이었습니다. 라이선스가 유효한 한 업데이트가 수신됩니다. Helm은 W&B operator의 배포 메커니즘이자 operator가 W&B Kubernetes 스택의 모든 설정 템플릿을 처리하는 수단(Helm-ception)으로 사용됩니다.

작동 방식

helm 또는 소스에서 operator를 설치할 수 있습니다. 자세한 내용은 charts/operator를 참조하세요.

설치 프로세스는 controller-manager라는 배포를 생성하고 weightsandbiases.apps.wandb.com이라는 custom resource 정의(shortName: wandb)를 사용하며, 단일 spec을 가져와 클러스터에 적용합니다.

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: weightsandbiases.apps.wandb.com

controller-manager는 커스텀 리소스, 릴리스 채널 및 사용자 정의 설정의 사양을 기반으로 charts/operator-wandb를 설치합니다. 이 설정 사양 계층 구조는 사용자 측에서 최대한의 설정 유연성을 제공하고 W&B가 새로운 이미지, 설정, 기능 및 Helm 업데이트를 자동으로 릴리스할 수 있도록 합니다.

설정 옵션은 설정 사양 계층 구조 및 설정 참조를 참조하세요.

설정 사양 계층 구조

설정 사양은 상위 수준 사양이 하위 수준 사양보다 우선하는 계층적 모델을 따릅니다. 작동 방식은 다음과 같습니다.

• 릴리스 채널 값: 이 기본 수준 설정은 배포를 위해 W&B가 설정한 릴리스 채널을 기반으로 기본값과 설정을 설정합니다.
• 사용자 입력 값: 사용자는 시스템 콘솔을 통해 릴리스 채널 사양에서 제공하는 기본 설정을 재정의할 수 있습니다.
• 커스텀 리소스 값: 사용자로부터 오는 최고 수준의 사양입니다. 여기에 지정된 모든 값은 사용자 입력 및 릴리스 채널 사양을 모두 재정의합니다. 설정 옵션에 대한 자세한 설명은 설정 참조를 참조하세요.

이 계층적 모델은 업그레이드 및 변경에 대한 관리 가능하고 체계적인 접근 방식을 유지하면서 다양한 요구 사항을 충족할 수 있도록 설정이 유연하고 사용자 정의 가능하도록 합니다.

W&B Kubernetes Operator 사용 요구 사항

W&B Kubernetes operator로 W&B를 배포하려면 다음 요구 사항을 충족해야 합니다.

참조 아키텍처를 참조하세요. 또한 유효한 W&B Server 라이선스를 획득하세요.

자체 관리 설치를 설정하고 구성하는 방법에 대한 자세한 설명은 이 가이드를 참조하세요.

설치 방법에 따라 다음 요구 사항을 충족해야 할 수도 있습니다.

• 올바른 Kubernetes 클러스터 컨텍스트로 설치 및 구성된 Kubectl.
• Helm이 설치되어 있습니다.

에어 갭 설치

에어 갭 환경에 W&B Kubernetes Operator를 설치하는 방법은 Kubernetes를 사용하여 에어 갭 환경에 W&B 배포 튜토리얼을 참조하세요.

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

이 섹션에서는 W&B Kubernetes operator를 배포하는 다양한 방법을 설명합니다.

다음 중 하나를 선택하세요.

• 필요한 모든 외부 서비스를 프로비저닝하고 Helm CLI를 사용하여 W&B를 Kubernetes에 배포하려면 여기를 계속 진행하세요.
• Terraform을 사용하여 인프라 및 W&B Server를 관리하려면 여기를 계속 진행하세요.
• W&B Cloud Terraform Modules를 사용하려면 여기를 계속 진행하세요.

Helm CLI를 사용하여 W&B 배포

W&B는 W&B Kubernetes operator를 Kubernetes 클러스터에 배포하기 위한 Helm Chart를 제공합니다. 이 접근 방식을 사용하면 Helm CLI 또는 ArgoCD와 같은 지속적인 배포 툴을 사용하여 W&B Server를 배포할 수 있습니다. 위에 언급된 요구 사항이 충족되었는지 확인하세요.

다음 단계에 따라 Helm CLI로 W&B Kubernetes Operator를 설치하세요.

1. W&B Helm 저장소를 추가합니다. W&B Helm chart는 W&B Helm 저장소에서 사용할 수 있습니다. 다음 코맨드를 사용하여 저장소를 추가합니다.

helm repo add wandb https://charts.wandb.ai
helm repo update

2. Kubernetes 클러스터에 Operator를 설치합니다. 다음을 복사하여 붙여넣습니다.

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

3. W&B Server 설치를 트리거하도록 W&B operator 커스텀 리소스를 구성합니다. 이 예제 설정을 operator.yaml이라는 파일에 복사하여 W&B 배포를 사용자 정의할 수 있도록 합니다. 설정 참조를 참조하세요.

   apiVersion: apps.wandb.com/v1
   kind: WeightsAndBiases
   metadata:
     labels:
       app.kubernetes.io/instance: wandb
       app.kubernetes.io/name: weightsandbiases
     name: wandb
     namespace: default
   
   spec:
     chart:
       url: http://charts.yourdomain.com
       name: operator-wandb
       version: 0.18.0
   
     values:
       global:
         host: https://wandb.yourdomain.com
         license: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
         bucket:
           accessKey: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
           secretKey: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
           name: s3.yourdomain.com:port #Ex.: s3.yourdomain.com:9000
           path: bucket_name
           provider: s3
           region: us-east-1
         mysql:
           database: wandb
           host: mysql.home.lab
           password: password
           port: 3306
           user: wandb
         extraEnv:
           ENABLE_REGISTRY_UI: 'true'
   
       # Ensure it's set to use your own MySQL
       mysql:
         install: false
   
       app:
         image:
           repository: registry.yourdomain.com/local
           tag: 0.59.2
   
       console:
         image:
           repository: registry.yourdomain.com/console
           tag: 2.12.2
   
       ingress:
         annotations:
           nginx.ingress.kubernetes.io/proxy-body-size: 64m
         class: nginx
   

   W&B Server 애플리케이션을 설치하고 구성할 수 있도록 커스텀 설정으로 Operator를 시작합니다.

   kubectl apply -f operator.yaml
   

   배포가 완료될 때까지 기다립니다. 몇 분 정도 걸립니다.

4. 웹 UI를 사용하여 설치를 확인하려면 첫 번째 관리자 사용자 계정을 만든 다음 설치 확인에 설명된 확인 단계를 따르세요.

Helm Terraform Module을 사용하여 W&B 배포

이 방법을 사용하면 일관성과 반복성을 위해 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 커스텀 리소스 정의 (CRD)를 생성합니다.

W&B&Biases가 Helm Terraform 모듈을 사용하여 고객을 위한 “전용 클라우드” 설치를 배포하는 방법을 보려면 다음 링크를 따르세요.

• AWS
• Azure
• GCP

W&B Cloud Terraform 모듈을 사용하여 W&B 배포

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

이 통합은 W&B Kubernetes Operator가 최소한의 설정으로 인스턴스에 사용할 준비가 되어 있는지 확인하여 클라우드 환경에서 W&B Server를 배포하고 관리하는 간소화된 경로를 제공합니다.

이러한 모듈을 사용하는 방법에 대한 자세한 설명은 문서의 자체 관리 설치 섹션의 이 섹션을 참조하세요.

설치 확인

설치를 확인하기 위해 W&B는 W&B CLI를 사용하는 것이 좋습니다. 확인 코맨드는 모든 구성 요소와 구성을 확인하는 여러 테스트를 실행합니다.

다음 단계에 따라 설치를 확인하세요.

1. W&B CLI를 설치합니다.

   pip install wandb
   

2. W&B에 로그인합니다.

   wandb login --host=https://YOUR_DNS_DOMAIN
   

   예:

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

3. 설치를 확인합니다.

   wandb verify
   

설치가 완료되고 W&B 배포가 완전히 작동하면 다음 출력이 표시됩니다.

Default host selected:  https://wandb.company-name.com
Find detailed logs for this test at: /var/folders/pn/b3g3gnc11_sbsykqkm3tx5rh0000gp/T/tmpdtdjbxua/wandb
Checking if logged in...................................................✅
Checking signed URL upload..............................................✅
Checking ability to send large payloads through proxy...................✅
Checking requests to base url...........................................✅
Checking requests made over signed URLs.................................✅
Checking CORs configuration of the bucket...............................✅
Checking wandb package version is up to date............................✅
Checking logged metrics, saving and downloading a file..................✅
Checking artifact save and download workflows...........................✅

W&B Management Console 엑세스

W&B Kubernetes operator에는 관리 콘솔이 함께 제공됩니다. 예를 들어 https://wandb.company-name.com/ 콘솔과 같이 ${HOST_URI}/console에 있습니다.

관리 콘솔에 로그인하는 방법에는 두 가지가 있습니다.

• 옵션 1 (권장)
• 옵션 2

W&B Kubernetes operator 업데이트

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

아래의 코드 조각을 복사하여 터미널에 붙여넣습니다.

1. 먼저 helm repo update로 저장소를 업데이트합니다.

   helm repo update
   

2. 다음으로 helm upgrade로 Helm chart를 업데이트합니다.

   helm upgrade operator wandb/operator -n wandb-cr --reuse-values
   

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

W&B Kubernetes operator를 사용하는 경우 더 이상 W&B Server 애플리케이션을 업데이트할 필요가 없습니다.

operator는 W&B 소프트웨어의 새 버전이 릴리스되면 W&B Server 애플리케이션을 자동으로 업데이트합니다.

자체 관리 인스턴스를 W&B Operator로 마이그레이션

다음 섹션에서는 자체 W&B Server 설치를 자체 관리하는 것에서 W&B Operator를 사용하여 이 작업을 수행하는 것으로 마이그레이션하는 방법을 설명합니다. 마이그레이션 프로세스는 W&B Server를 설치한 방법에 따라 다릅니다.

• 공식 W&B Cloud Terraform Modules를 사용한 경우 적절한 설명서로 이동하여 해당 단계를 따르세요.
  • AWS
  • GCP
  • Azure
• W&B 비-Operator Helm chart를 사용한 경우 여기를 계속 진행하세요.
• Terraform이 포함된 W&B 비-Operator Helm chart를 사용한 경우 여기를 계속 진행하세요.
• 매니페스트로 Kubernetes 리소스를 생성한 경우 여기를 계속 진행하세요.

Operator 기반 AWS Terraform Modules로 마이그레이션

마이그레이션 프로세스에 대한 자세한 설명은 여기를 계속 진행하세요.

Operator 기반 GCP Terraform Modules로 마이그레이션

질문이 있거나 지원이 필요한 경우 고객 지원 또는 W&B 팀에 문의하세요.

Operator 기반 Azure Terraform Modules로 마이그레이션

질문이 있거나 지원이 필요한 경우 고객 지원 또는 W&B 팀에 문의하세요.

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

다음 단계에 따라 Operator 기반 Helm chart로 마이그레이션하세요.

1. 현재 W&B 설정을 가져옵니다. W&B가 비-operator 기반 버전의 Helm chart로 배포된 경우 다음과 같이 값을 내보냅니다.

   helm get values wandb
   

   W&B가 Kubernetes 매니페스트로 배포된 경우 다음과 같이 값을 내보냅니다.

   kubectl get deployment wandb -o yaml
   

   이제 다음 단계에 필요한 모든 설정 값이 있습니다.

2. operator.yaml이라는 파일을 만듭니다. 설정 참조에 설명된 형식을 따르세요. 1단계의 값을 사용합니다.

3. 현재 배포를 0개의 pod로 확장합니다. 이 단계는 현재 배포를 중지합니다.

   kubectl scale --replicas=0 deployment wandb
   

4. Helm chart 저장소를 업데이트합니다.

   helm repo update
   

5. 새 Helm chart를 설치합니다.

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

6. 새 helm chart를 구성하고 W&B 애플리케이션 배포를 트리거합니다. 새 구성을 적용합니다.

   kubectl apply -f operator.yaml
   

   배포가 완료되는 데 몇 분 정도 걸립니다.

7. 설치를 확인합니다. 설치 확인의 단계에 따라 모든 것이 작동하는지 확인합니다.

8. 이전 설치를 제거합니다. 이전 helm chart를 제거하거나 매니페스트로 생성된 리소스를 삭제합니다.

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

다음 단계에 따라 Operator 기반 Helm chart로 마이그레이션하세요.

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

W&B Server에 대한 설정 참조

이 섹션에서는 W&B Server 애플리케이션에 대한 설정 옵션을 설명합니다. 애플리케이션은 WeightsAndBiases라는 커스텀 리소스 정의로 설정을 수신합니다. 일부 설정 옵션은 아래 설정으로 노출되고 일부는 환경 변수로 설정해야 합니다.

설명서에는 기본 및 고급의 두 가지 환경 변수 목록이 있습니다. 필요한 설정 옵션이 Helm Chart를 사용하여 노출되지 않은 경우에만 환경 변수를 사용하세요.

프로덕션 배포를 위한 W&B Server 애플리케이션 설정 파일에는 다음 내용이 필요합니다. 이 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 저장소에서 전체 값 집합을 찾고 재정의해야 하는 값만 변경하세요.

전체 예제

다음은 GCP Ingress 및 GCS(GCP 오브젝트 스토리지)가 포함된 GCP Kubernetes를 사용하는 예제 설정입니다.

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
      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

Host

 # 프로토콜과 함께 FQDN을 제공합니다.
global:
  # 예제 호스트 이름, 자신의 호스트 이름으로 바꿉니다.
  host: https://wandb.example.com

오브젝트 스토리지 (bucket)

AWS

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

GCP

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

Azure

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

기타 공급자 (Minio, Ceph 등)

다른 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이어야 합니다.

secret에서 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

secret에서 password를 참조하려면 다음과 같이 합니다.

global:
   mysql:
     # 예제 값, 자신의 값으로 바꿉니다.
     host: db.example.com
     port: 3306
     database: wandb_local
     user: wandb
     passwordSecret:
       name: database-secret
       passwordKey: MYSQL_WANDB_PASSWORD

License

global:
  # 예제 라이선스, 자신의 라이선스로 바꿉니다.
  license: eyJhbGnUzaHgyQjQy...VFnPS_KETXg1hi

secret에서 license를 참조하려면 다음과 같이 합니다.

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

Ingress

Ingress 클래스를 식별하려면 이 FAQ 항목을 참조하세요.

TLS 없음

global:
# 중요: Ingress는 YAML에서 'global'과 같은 수준에 있습니다 (하위 수준이 아님).
ingress:
  class: ""

TLS 사용

인증서가 포함된 secret을 만듭니다.

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

Ingress 설정에서 secret을 참조합니다.

global:
# 중요: Ingress는 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: 64m

커스텀 Kubernetes ServiceAccounts

W&B pod를 실행할 커스텀 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:
  ...

외부 Redis

redis:
  install: false

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

secret에서 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

TLS 없음

global:
  ldap:
    enabled: true
    # "ldap://" 또는 "ldaps://"를 포함한 LDAP 서버 어드레스
    host:
    # 사용자를 찾는 데 사용할 LDAP 검색 기준
    baseDN:
    # 바인딩할 LDAP 사용자 (익명 바인딩을 사용하지 않는 경우)
    bindDN:
    # 바인딩할 LDAP 비밀번호가 포함된 Secret 이름 및 키 (익명 바인딩을 사용하지 않는 경우)
    bindPW:
    # 쉼표로 구분된 문자열 값으로 된 이메일 및 그룹 ID 어트리뷰트 이름에 대한 LDAP 어트리뷰트입니다.
    attributes:
    # LDAP 그룹 허용 목록
    groupAllowList:
    # LDAP TLS 활성화
    tls: false

TLS 사용

LDAP TLS 인증서 설정에는 인증서 콘텐츠로 미리 생성된 구성 맵이 필요합니다.

구성 맵을 생성하려면 다음 코맨드를 사용할 수 있습니다.

kubectl create configmap ldap-tls-cert --from-file=certificate.crt

아래 예제와 같이 YAML에서 구성 맵을 사용합니다.

global:
  ldap:
    enabled: true
    # "ldap://" 또는 "ldaps://"를 포함한 LDAP 서버 어드레스
    host:
    # 사용자를 찾는 데 사용할 LDAP 검색 기준
    baseDN:
    # 바인딩할 LDAP 사용자 (익명 바인딩을 사용하지 않는 경우)
    bindDN:
    # 바인딩할 LDAP 비밀번호가 포함된 Secret 이름 및 키 (익명 바인딩을 사용하지 않는 경우)
    bindPW:
    # 쉼표로 구분된 문자열 값으로 된 이메일 및 그룹 ID 어트리뷰트 이름에 대한 LDAP 어트리뷰트입니다.
    attributes:
    # LDAP 그룹 허용 목록
    groupAllowList:
    # LDAP TLS 활성화
    tls: true
    # LDAP 서버용 CA 인증서가 포함된 ConfigMap 이름 및 키
    tlsCert:
      configMap:
        name: "ldap-tls-cert"
        key: "certificate.crt"

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 인증서는 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-----    

커스텀 보안 컨텍스트

각 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

예를 들어 애플리케이션 pod를 구성하려면 구성에 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에는 설정 파일이 필요하지 않습니다. 필요한 경우 설정 파일을 만듭니다. 예를 들어 커스텀 인증 기관을 지정하거나 에어 갭 환경에 배포하기 위해 설정 파일이 필요할 수 있습니다.

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 인증서는 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-----    

FAQ

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

• wandb-app: GraphQL API 및 프런트엔드 애플리케이션을 포함한 W&B의 핵심입니다. 대부분의 플랫폼 기능을 제공합니다.
• wandb-console: /console을 통해 엑세스할 수 있는 관리 콘솔입니다.
• wandb-otel: Kubernetes 계층의 리소스에서 메트릭 및 로그를 수집하여 관리 콘솔에 표시하는 OpenTelemetry 에이전트입니다.
• wandb-prometheus: 관리 콘솔에 표시하기 위해 다양한 구성 요소에서 메트릭을 캡처하는 Prometheus 서버입니다.
• wandb-parquet: 데이터베이스 데이터를 Parquet 형식으로 오브젝트 스토리지로 내보내는 wandb-app pod와 분리된 백엔드 마이크로서비스입니다.
• wandb-weave: UI에서 쿼리 테이블을 로드하고 다양한 핵심 앱 기능을 지원하는 또 다른 백엔드 마이크로서비스입니다.
• wandb-weave-trace: LLM 기반 애플리케이션을 추적, 실험, 평가, 배포 및 개선하기 위한 프레임워크입니다. 이 프레임워크는 wandb-app pod를 통해 엑세스할 수 있습니다.

W&B Operator Console 비밀번호를 얻는 방법

W&B Kubernetes Operator Management Console 엑세스를 참조하세요.

Ingress가 작동하지 않는 경우 W&B Operator Console에 엑세스하는 방법

Kubernetes 클러스터에 연결할 수 있는 호스트에서 다음 코맨드를 실행합니다.

kubectl port-forward svc/wandb-console 8082

https://localhost:8082/ 콘솔에서 브라우저의 콘솔에 엑세스합니다.

비밀번호를 얻는 방법에 대한 내용은 W&B Kubernetes Operator Management Console 엑세스 (옵션 2)를 참조하세요.

W&B Server 로그를 보는 방법

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

kubectl get pods
kubectl logs wandb-XXXXX-XXXXX

Kubernetes ingress 클래스를 식별하는 방법

다음을 실행하여 클러스터에 설치된 ingress 클래스를 가져올 수 있습니다.

kubectl get ingressclass

2.1 - Kubernetes operator for air-gapped instances

도입

본 가이드는 에어 갭(air-gapped) 고객 관리 환경에 W&B 플랫폼을 배포하는 단계별 지침을 제공합니다.

Helm 차트와 컨테이너 이미지를 호스팅하려면 내부 저장소 또는 레지스트리를 사용하세요. Kubernetes 클러스터에 적절한 엑세스 권한을 가진 셸 콘솔에서 모든 코맨드를 실행합니다.

Kubernetes 애플리케이션을 배포하는 데 사용하는 모든 지속적 배포 툴링에서 유사한 코맨드를 활용할 수 있습니다.

1단계: 전제 조건

시작하기 전에 환경이 다음 요구 사항을 충족하는지 확인하세요.

• Kubernetes 버전 >= 1.28
• Helm 버전 >= 3
• 필요한 W&B 이미지가 있는 내부 컨테이너 레지스트리에 대한 엑세스
• W&B Helm 차트에 대한 내부 Helm 저장소에 대한 엑세스

2단계: 내부 컨테이너 레지스트리 준비

배포를 진행하기 전에 다음 컨테이너 이미지가 내부 컨테이너 레지스트리에서 사용 가능한지 확인해야 합니다.

• docker.io/wandb/controller
• docker.io/wandb/local
• docker.io/wandb/console
• docker.io/bitnami/redis
• docker.io/otel/opentelemetry-collector-contrib
• quay.io/prometheus/prometheus
• quay.io/prometheus-operator/prometheus-config-reloader

이러한 이미지는 W&B 컴포넌트의 성공적인 배포에 매우 중요합니다. W&B는 WSM을 사용하여 컨테이너 레지스트리를 준비하는 것을 권장합니다.

조직에서 이미 내부 컨테이너 레지스트리를 사용하는 경우 이미지를 추가할 수 있습니다. 그렇지 않으면 다음 섹션에 따라 WSM을 사용하여 컨테이너 저장소를 준비하세요.

WSM 사용 또는 조직의 자체 프로세스를 사용하여 Operator의 요구 사항을 추적하고 이미지 업그레이드를 확인하고 다운로드하는 것은 사용자의 책임입니다.

WSM 설치

다음 방법 중 하나를 사용하여 WSM을 설치합니다.

Bash

GitHub에서 직접 Bash 스크립트를 실행합니다.

curl -sSL https://raw.githubusercontent.com/wandb/wsm/main/install.sh | bash

스크립트는 스크립트를 실행한 폴더에 바이너리를 다운로드합니다. 다른 폴더로 이동하려면 다음을 실행합니다.

sudo mv wsm /usr/local/bin

GitHub

W&B 관리 wandb/wsm GitHub 저장소( https://github.com/wandb/wsm )에서 WSM을 다운로드하거나 복제합니다. 최신 릴리스는 wandb/wsm 릴리스 노트를 참조하세요.

이미지 및 해당 버전 나열

wsm list를 사용하여 최신 이미지 버전 목록을 가져옵니다.

wsm list

출력은 다음과 같습니다.

:package: 배포에 필요한 모든 이미지를 나열하는 프로세스를 시작합니다...
Operator Images:
  wandb/controller:1.16.1
W&B Images:
  wandb/local:0.62.2
  docker.io/bitnami/redis:7.2.4-debian-12-r9
  quay.io/prometheus-operator/prometheus-config-reloader:v0.67.0
  quay.io/prometheus/prometheus:v2.47.0
  otel/opentelemetry-collector-contrib:0.97.0
  wandb/console:2.13.1
다음은 W&B를 배포하는 데 필요한 이미지입니다. 이러한 이미지가 내부 컨테이너 레지스트리에서 사용 가능한지 확인하고 values.yaml을 적절하게 업데이트하십시오.

이미지 다운로드

wsm download를 사용하여 최신 버전의 모든 이미지를 다운로드합니다.

wsm download

출력은 다음과 같습니다.

Downloading operator helm chart
Downloading wandb helm chart
✓ wandb/controller:1.16.1
✓ docker.io/bitnami/redis:7.2.4-debian-12-r9
✓ otel/opentelemetry-collector-contrib:0.97.0
✓ quay.io/prometheus-operator/prometheus-config-reloader:v0.67.0
✓ wandb/console:2.13.1
✓ quay.io/prometheus/prometheus:v2.47.0

  Done! Installed 7 packages.

WSM은 각 이미지에 대해 .tgz 아카이브를 bundle 디렉토리에 다운로드합니다.

3단계: 내부 Helm 차트 저장소 준비

컨테이너 이미지와 함께 다음 Helm 차트가 내부 Helm 차트 저장소에서 사용 가능한지 확인해야 합니다. 마지막 단계에서 소개된 WSM 툴은 Helm 차트도 다운로드할 수 있습니다. 또는 여기에서 다운로드하세요.

• W&B Operator
• W&B Platform

operator 차트는 컨트롤러 관리자라고도 하는 W&B Operator를 배포하는 데 사용됩니다. platform 차트는 CRD(사용자 정의 리소스 정의)에 구성된 값을 사용하여 W&B 플랫폼을 배포하는 데 사용됩니다.

4단계: Helm 저장소 설정

이제 내부 저장소에서 W&B Helm 차트를 가져오도록 Helm 저장소를 구성합니다. 다음 코맨드를 실행하여 Helm 저장소를 추가하고 업데이트합니다.

helm repo add local-repo https://charts.yourdomain.com
helm repo update

5단계: Kubernetes operator 설치

컨트롤러 관리자라고도 하는 W&B Kubernetes operator는 W&B 플랫폼 컴포넌트 관리를 담당합니다. 에어 갭 환경에 설치하려면 내부 컨테이너 레지스트리를 사용하도록 구성해야 합니다.

이렇게 하려면 내부 컨테이너 레지스트리를 사용하도록 기본 이미지 설정을 재정의하고 예상되는 배포 유형을 나타내기 위해 airgapped: true 키를 설정해야 합니다. 아래와 같이 values.yaml 파일을 업데이트합니다.

image:
  repository: registry.yourdomain.com/library/controller
  tag: 1.13.3
airgapped: true

태그를 내부 레지스트리에서 사용 가능한 버전으로 바꿉니다.

operator 및 CRD를 설치합니다.

helm upgrade --install operator wandb/operator -n wandb --create-namespace -f values.yaml

지원되는 값에 대한 자세한 내용은 Kubernetes operator GitHub 저장소를 참조하세요.

6단계: W&B 사용자 정의 리소스 구성

W&B Kubernetes operator를 설치한 후에는 내부 Helm 저장소 및 컨테이너 레지스트리를 가리키도록 사용자 정의 리소스(CR)를 구성해야 합니다.

이 구성은 Kubernetes operator가 W&B 플랫폼의 필요한 컴포넌트를 배포할 때 내부 레지스트리 및 저장소를 사용하도록 보장합니다.

이 예제 CR을 wandb.yaml이라는 새 파일에 복사합니다.

apiVersion: apps.wandb.com/v1
kind: WeightsAndBiases
metadata:
  labels:
    app.kubernetes.io/instance: wandb
    app.kubernetes.io/name: weightsandbiases
  name: wandb
  namespace: default

spec:
  chart:
    url: http://charts.yourdomain.com
    name: operator-wandb
    version: 0.18.0

  values:
    global:
      host: https://wandb.yourdomain.com
      license: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
      bucket:
        accessKey: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
        secretKey: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
        name: s3.yourdomain.com:port #Ex.: s3.yourdomain.com:9000
        path: bucket_name
        provider: s3
        region: us-east-1
      mysql:
        database: wandb
        host: mysql.home.lab
        password: password
        port: 3306
        user: wandb
      extraEnv:
        ENABLE_REGISTRY_UI: 'true'
    
    # If install: true, Helm installs a MySQL database for the deployment to use. Set to `false` to use your own external MySQL deployment.
    mysql:
      install: false

    app:
      image:
        repository: registry.yourdomain.com/local
        tag: 0.59.2

    console:
      image:
        repository: registry.yourdomain.com/console
        tag: 2.12.2

    ingress:
      annotations:
        nginx.ingress.kubernetes.io/proxy-body-size: 64m
      class: nginx

    

W&B 플랫폼을 배포하기 위해 Kubernetes Operator는 CR의 값을 사용하여 내부 저장소에서 operator-wandb Helm 차트를 구성합니다.

모든 태그/버전을 내부 레지스트리에서 사용 가능한 버전으로 바꿉니다.

앞의 구성 파일 작성에 대한 자세한 내용은 여기에서 확인할 수 있습니다.

7단계: W&B 플랫폼 배포

이제 Kubernetes operator와 CR이 구성되었으므로 wandb.yaml 구성을 적용하여 W&B 플랫폼을 배포합니다.

kubectl apply -f wandb.yaml

FAQ

배포 프로세스 중에 자주 묻는 질문(FAQ) 및 문제 해결 팁은 아래를 참조하십시오.

다른 ingress 클래스가 있습니다. 해당 클래스를 사용할 수 있습니까?

예, values.yaml에서 ingress 설정을 수정하여 ingress 클래스를 구성할 수 있습니다.

인증서 번들에 인증서가 두 개 이상 있습니다. 작동합니까?

values.yaml의 customCACerts 섹션에서 인증서를 여러 항목으로 분할해야 합니다.

Kubernetes operator가 무인 업데이트를 적용하지 못하도록 하는 방법은 무엇입니까? 가능합니까?

W&B 콘솔에서 자동 업데이트를 해제할 수 있습니다. 지원되는 버전에 대한 질문은 W&B 팀에 문의하십시오. 또한 W&B는 지난 6개월 동안 릴리스된 플랫폼 버전을 지원합니다. W&B는 주기적인 업그레이드를 수행하는 것이 좋습니다.

환경이 퍼블릭 저장소에 연결되어 있지 않은 경우 배포가 작동합니까?

구성에서 airgapped를 true로 설정하면 Kubernetes operator는 내부 리소스만 사용하고 퍼블릭 저장소에 연결을 시도하지 않습니다.

3 - Install on public cloud

3.1 - Deploy W&B Platform on AWS

W&B는 AWS에 플랫폼을 배포하기 위해 W&B Server AWS Terraform Module 사용을 권장합니다.

시작하기 전에, W&B는 Terraform에서 사용 가능한 원격 백엔드 중 하나를 선택하여 상태 파일을 저장하는 것을 권장합니다.

상태 파일은 모든 구성 요소를 다시 만들지 않고도 업그레이드를 롤아웃하거나 배포를 변경하는 데 필요한 리소스입니다.

Terraform Module은 다음의 필수 구성 요소를 배포합니다.

• 로드 밸런서
• AWS Identity & Access Management (IAM)
• AWS Key Management System (KMS)
• Amazon Aurora MySQL
• Amazon VPC
• Amazon S3
• Amazon Route53
• Amazon Certificate Manager (ACM)
• Amazon Elastic Load Balancing (ALB)
• Amazon Secrets Manager

다른 배포 옵션은 다음의 선택적 구성 요소를 포함할 수도 있습니다.

• Redis용 Elastic Cache
• SQS

사전 필수 권한

Terraform을 실행하는 계정은 도입에서 설명된 모든 구성 요소를 생성할 수 있는 권한과 IAM 정책 및 IAM 역할을 생성하고 역할에 리소스를 할당할 수 있는 권한이 필요합니다.

일반적인 단계

이 주제의 단계는 이 문서에서 다루는 모든 배포 옵션에 공통적입니다.

1. 개발 환경을 준비합니다.

   • Terraform 설치
   • W&B는 버전 관리를 위해 Git 저장소를 만드는 것을 권장합니다.

2. 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"
   

   namespace 변수는 Terraform이 생성한 모든 리소스의 접두사로 사용되는 문자열이므로 배포하기 전에 tvfars 파일에 변수를 정의해야 합니다.

   subdomain과 domain의 조합은 W&B가 구성될 FQDN을 형성합니다. 위의 예에서 W&B FQDN은 wandb-aws.wandb.ml이 되고, FQDN 레코드가 생성될 DNS zone_id가 됩니다.

   allowed_inbound_cidr 및 allowed_inbound_ipv6_cidr도 설정해야 합니다. 모듈에서 이는 필수 입력입니다. 이전 예제는 모든 소스에서 W&B 설치에 대한 엑세스를 허용합니다.

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

   선택 사항이지만, 이 문서의 시작 부분에서 언급한 원격 백엔드 설정을 추가하는 것이 좋습니다.

4. variables.tf 파일을 만듭니다.

   terraform.tfvars에 구성된 모든 옵션에 대해 Terraform은 해당 변수 선언이 필요합니다.

   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 클러스터 Kubernetes 버전"
    nullable    = false
    type        = string
   }
   

권장 배포 옵션

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

1. main.tf를 만듭니다.

   일반적인 단계에서 파일을 생성한 동일한 디렉터리에 다음 내용으로 main.tf 파일을 만듭니다.

   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
   
     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
    }
   

2. W&B 배포

   W&B를 배포하려면 다음 코맨드를 실행합니다.

   terraform init
   terraform apply -var-file=terraform.tfvars
   

REDIS 활성화

다른 배포 옵션은 Redis를 사용하여 SQL 쿼리를 캐시하고 Experiments에 대한 메트릭을 로드할 때 애플리케이션 응답 속도를 높입니다.

캐시를 활성화하려면 권장 배포 섹션에 설명된 동일한 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**
}
[...]

메시지 브로커(대기열) 활성화

배포 옵션 3은 외부 message broker를 활성화하는 것으로 구성됩니다. W&B가 내장된 브로커를 제공하므로 이는 선택 사항입니다. 이 옵션은 성능 향상을 제공하지 않습니다.

메시지 브로커를 제공하는 AWS 리소스는 SQS이며, 이를 활성화하려면 권장 배포 섹션에 설명된 동일한 main.tf에 use_internal_queue = false 옵션을 추가해야 합니다.

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**

[...]
}

기타 배포 옵션

동일한 파일에 모든 구성을 추가하여 세 가지 배포 옵션을 모두 결합할 수 있습니다. Terraform Module은 표준 옵션과 배포 - 권장에서 찾을 수 있는 최소 구성과 함께 결합할 수 있는 여러 옵션을 제공합니다.

수동 구성

Amazon S3 버킷을 W&B의 파일 스토리지 백엔드로 사용하려면 다음을 수행해야 합니다.

• Amazon S3 버킷 및 버킷 알림 생성
• SQS 대기열 생성
• W&B를 실행하는 노드에 권한 부여

버킷에서 오브젝트 생성 알림을 수신하도록 구성된 SQS 대기열과 함께 버킷을 만들어야 합니다. 인스턴스에는 이 대기열에서 읽을 수 있는 권한이 필요합니다.

S3 버킷 및 버킷 알림 생성

아래 절차에 따라 Amazon S3 버킷을 만들고 버킷 알림을 활성화합니다.

1. AWS 콘솔에서 Amazon S3로 이동합니다.
2. 버킷 만들기를 선택합니다.
3. 고급 설정 내에서 이벤트 섹션 내에서 알림 추가를 선택합니다.
4. 이전에 구성한 SQS 대기열로 전송되도록 모든 오브젝트 생성 이벤트를 구성합니다.

CORS 엑세스를 활성화합니다. CORS 구성은 다음과 같아야 합니다.

<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<CORSRule>
    <AllowedOrigin>http://YOUR-W&B-SERVER-IP</AllowedOrigin>
    <AllowedMethod>GET</AllowedMethod>
    <AllowedMethod>PUT</AllowedMethod>
    <AllowedHeader>*</AllowedHeader>
</CORSRule>
</CORSConfiguration>

SQS 대기열 생성

SQS 대기열을 만들려면 아래 절차를 따르세요.

1. AWS 콘솔에서 Amazon SQS로 이동합니다.
2. 대기열 만들기를 선택합니다.
3. 세부 정보 섹션에서 표준 대기열 유형을 선택합니다.
4. 엑세스 정책 섹션에서 다음 보안 주체에 대한 권한을 추가합니다.

• SendMessage
• ReceiveMessage
• ChangeMessageVisibility
• DeleteMessage
• GetQueueUrl

선택적으로 엑세스 정책 섹션에서 고급 엑세스 정책을 추가합니다. 예를 들어, 명령문이 있는 Amazon SQS에 엑세스하기 위한 정책은 다음과 같습니다.

{
    "Version" : "2012-10-17",
    "Statement" : [
      {
        "Effect" : "Allow",
        "Principal" : "*",
        "Action" : ["sqs:SendMessage"],
        "Resource" : "<sqs-queue-arn>",
        "Condition" : {
          "ArnEquals" : { "aws:SourceArn" : "<s3-bucket-arn>" }
        }
      }
    ]
}

W&B를 실행하는 노드에 권한 부여

W&B 서버가 실행 중인 노드는 Amazon S3 및 Amazon SQS에 대한 엑세스를 허용하도록 구성해야 합니다. 선택한 서버 배포 유형에 따라 다음 정책 명령문을 노드 역할에 추가해야 할 수 있습니다.

{
   "Statement":[
      {
         "Sid":"",
         "Effect":"Allow",
         "Action":"s3:*",
         "Resource":"arn:aws:s3:::<WANDB_BUCKET>"
      },
      {
         "Sid":"",
         "Effect":"Allow",
         "Action":[
            "sqs:*"
         ],
         "Resource":"arn:aws:sqs:<REGION>:<ACCOUNT>:<WANDB_QUEUE>"
      }
   ]
}

W&B 서버 구성

마지막으로 W&B 서버를 구성합니다.

1. http(s)://YOUR-W&B-SERVER-HOST/system-admin에서 W&B 설정 페이지로 이동합니다.
2. **외부 파일 스토리지 백엔드 사용 옵션을 활성화합니다.
3. 다음 형식으로 Amazon S3 버킷, 리전 및 Amazon SQS 대기열에 대한 정보를 제공합니다.

• 파일 스토리지 버킷: s3://<버킷 이름>
• 파일 스토리지 리전(AWS 전용): <리전>
• 알림 구독: sqs://<대기열 이름>

4. 설정 업데이트를 선택하여 새 설정을 적용합니다.

W&B 버전 업그레이드

다음 단계에 따라 W&B를 업데이트합니다.

1. wandb_app 모듈의 구성에 wandb_version을 추가합니다. 업그레이드할 W&B 버전을 제공합니다. 예를 들어, 다음 줄은 W&B 버전 0.48.1을 지정합니다.

module "wandb_app" {
    source  = "wandb/wandb/kubernetes"
    version = "~>1.0"

    license       = var.license
    wandb_version = "0.48.1"

2. 구성을 업데이트한 후 권장 배포 섹션에 설명된 단계를 완료합니다.

운영자 기반 AWS Terraform 모듈로 마이그레이션

이 섹션에서는 terraform-aws-wandb 모듈을 사용하여 pre-operator 환경에서 post-operator 환경으로 업그레이드하는 데 필요한 단계를 자세히 설명합니다.

이전 및 이후 아키텍처

이전에는 W&B 아키텍처에서 다음을 사용했습니다.

module "wandb_infra" {
  source  = "wandb/wandb/aws"
  version = "1.16.10"
  ...
}

인프라를 제어합니다.

그리고 이 모듈을 사용하여 W&B 서버를 배포합니다.

module "wandb_app" {
  source  = "wandb/wandb/kubernetes"
  version = "1.12.0"
}

전환 후 아키텍처는 다음을 사용합니다.

module "wandb_infra" {
  source  = "wandb/wandb/aws"
  version = "4.7.2"
  ...
}

인프라 설치와 Kubernetes 클러스터에 대한 W&B 서버를 모두 관리하므로 post-operator.tf에서 module "wandb_app"이 필요하지 않습니다.

이러한 아키텍처 변경을 통해 SRE/인프라 팀의 수동 Terraform 작업 없이도 추가 기능(예: OpenTelemetry, Prometheus, HPA, Kafka 및 이미지 업데이트)을 사용할 수 있습니다.

W&B Pre-Operator의 기본 설치를 시작하려면 post-operator.tf에 .disabled 파일 확장명이 있고 pre-operator.tf가 활성 상태인지(확장명이 .disabled가 아닌지) 확인합니다. 해당 파일은 여기에서 찾을 수 있습니다.

전제 조건

마이그레이션 프로세스를 시작하기 전에 다음 전제 조건이 충족되었는지 확인합니다.

• Egress: 배포가 에어 갭이 될 수 없습니다. **Release Channel**에 대한 최신 사양을 가져오려면 deploy.wandb.ai에 엑세스해야 합니다.
• AWS 자격 증명: AWS 리소스와 상호 작용하도록 구성된 적절한 AWS 자격 증명.
• Terraform 설치됨: 시스템에 최신 버전의 Terraform이 설치되어 있어야 합니다.
• Route53 호스팅 영역: 애플리케이션이 제공될 도메인에 해당하는 기존 Route53 호스팅 영역.
• Pre-Operator Terraform 파일: pre-operator.tf 및 pre-operator.tfvars와 같은 관련 변수 파일이 올바르게 설정되었는지 확인합니다.

Pre-Operator 설정

다음 Terraform 코맨드를 실행하여 Pre-Operator 설정에 대한 구성을 초기화하고 적용합니다.

terraform init -upgrade
terraform apply -var-file=./pre-operator.tfvars

pre-operator.tf는 다음과 유사해야 합니다.

namespace     = "operator-upgrade"
domain_name   = "sandbox-aws.wandb.ml"
zone_id       = "Z032246913CW32RVRY0WU"
subdomain     = "operator-upgrade"
wandb_license = "ey..."
wandb_version = "0.51.2"

pre-operator.tf 구성은 두 개의 모듈을 호출합니다.

module "wandb_infra" {
  source  = "wandb/wandb/aws"
  version = "1.16.10"
  ...
}

이 모듈은 인프라를 가동합니다.

module "wandb_app" {
  source  = "wandb/wandb/kubernetes"
  version = "1.12.0"
}

이 모듈은 애플리케이션을 배포합니다.

Post-Operator 설정

pre-operator.tf에 .disabled 확장명이 있고 post-operator.tf가 활성 상태인지 확인합니다.

post-operator.tfvars에는 추가 변수가 포함되어 있습니다.

...
# wandb_version = "0.51.2"는 이제 릴리스 채널을 통해 관리되거나 사용자 사양에 설정됩니다.

# 업그레이드에 필요한 운영자 변수:
size                 = "small"
enable_dummy_dns     = true
enable_operator_alb  = true
custom_domain_filter = "sandbox-aws.wandb.ml"

다음 코맨드를 실행하여 Post-Operator 구성을 초기화하고 적용합니다.

terraform init -upgrade
terraform apply -var-file=./post-operator.tfvars

계획 및 적용 단계에서는 다음 리소스를 업데이트합니다.

actions:
  create:
    - aws_efs_backup_policy.storage_class
    - aws_efs_file_system.storage_class
    - aws_efs_mount_target.storage_class["0"]
    - aws_efs_mount_target.storage_class["1"]
    - aws_eks_addon.efs
    - aws_iam_openid_connect_provider.eks
    - aws_iam_policy.secrets_manager
    - aws_iam_role_policy_attachment.ebs_csi
    - aws_iam_role_policy_attachment.eks_efs
    - aws_iam_role_policy_attachment.node_secrets_manager
    - aws_security_group.storage_class_nfs
    - aws_security_group_rule.nfs_ingress
    - random_pet.efs
    - aws_s3_bucket_acl.file_storage
    - aws_s3_bucket_cors_configuration.file_storage
    - aws_s3_bucket_ownership_controls.file_storage
    - aws_s3_bucket_server_side_encryption_configuration.file_storage
    - helm_release.operator
    - helm_release.wandb
    - aws_cloudwatch_log_group.this[0]
    - aws_iam_policy.default
    - aws_iam_role.default
    - aws_iam_role_policy_attachment.default
    - helm_release.external_dns
    - aws_default_network_acl.this[0]
    - aws_default_route_table.default[0]
    - aws_iam_policy.default
    - aws_iam_role.default
    - aws_iam_role_policy_attachment.default
    - helm_release.aws_load_balancer_controller

  update_in_place:
    - aws_iam_policy.node_IMDSv2
    - aws_iam_policy.node_cloudwatch
    - aws_iam_policy.node_kms
    - aws_iam_policy.node_s3
    - aws_iam_policy.node_sqs
    - aws_eks_cluster.this[0]
    - aws_elasticache_replication_group.default
    - aws_rds_cluster.this[0]
    - aws_rds_cluster_instance.this["1"]
    - aws_default_security_group.this[0]
    - aws_subnet.private[0]
    - aws_subnet.private[1]
    - aws_subnet.public[0]
    - aws_subnet.public[1]
    - aws_launch_template.workers["primary"]

  destroy:
    - kubernetes_config_map.config_map
    - kubernetes_deployment.wandb
    - kubernetes_priority_class.priority
    - kubernetes_secret.secret
    - kubernetes_service.prometheus
    - kubernetes_service.service
    - random_id.snapshot_identifier[0]

  replace:
    - aws_autoscaling_attachment.autoscaling_attachment["primary"]
    - aws_route53_record.alb
    - aws_eks_node_group.workers["primary"]

다음과 같은 내용이 표시됩니다.

post-operator.tf에는 다음과 같은 단일 항목이 있습니다.

module "wandb_infra" {
  source  = "wandb/wandb/aws"
  version = "4.7.2"
  ...
}

post-operator 구성의 변경 사항:

1. 필수 Provider 업데이트: provider 호환성을 위해 required_providers.aws.version을 3.6에서 4.0으로 변경합니다.
2. DNS 및 로드 밸런서 구성: Ingress를 통해 DNS 레코드 및 AWS 로드 밸런서 설정을 관리하려면 enable_dummy_dns 및 enable_operator_alb를 통합합니다.
3. 라이선스 및 크기 구성: 새로운 운영 요구 사항에 맞게 license 및 size 파라미터를 wandb_infra 모듈로 직접 전송합니다.
4. 사용자 지정 도메인 처리: 필요한 경우 kube-system 네임스페이스 내에서 외부 DNS pod 로그를 확인하여 DNS 문제를 해결하려면 custom_domain_filter를 사용합니다.
5. Helm Provider 구성: Kubernetes 리소스를 효과적으로 관리하려면 Helm provider를 활성화하고 구성합니다.

provider "helm" {
  kubernetes {
    host                   = data.aws_eks_cluster.app_cluster.endpoint
    cluster_ca_certificate = base64decode(data.aws_eks_cluster.app_cluster.certificate_authority[0].data)
    token                  = data.aws_eks_cluster_auth.app_cluster.token
    exec {
      api_version = "client.authentication.k8s.io/v1beta1"
      args        = ["eks", "get-token", "--cluster-name", data.aws_eks_cluster.app_cluster.name]
      command     = "aws"
    }
  }
}

이 포괄적인 설정을 통해 운영자 모델에서 활성화된 새로운 효율성과 기능을 활용하여 Pre-Operator에서 Post-Operator 구성으로 원활하게 전환할 수 있습니다.

3.2 - Deploy W&B Platform on GCP

W&B Server를 자체 관리하기로 결정했다면, GCP에 플랫폼을 배포하기 위해 W&B Server GCP Terraform Module을 사용하는 것이 좋습니다.

모듈 문서는 광범위하며 사용 가능한 모든 옵션이 포함되어 있습니다.

시작하기 전에 Terraform에서 사용 가능한 원격 백엔드 중 하나를 선택하여 State File을 저장하는 것이 좋습니다.

State File은 모든 구성 요소를 다시 만들지 않고도 업그레이드를 롤아웃하거나 배포를 변경하는 데 필요한 리소스입니다.

Terraform Module은 다음과 같은 필수 구성 요소를 배포합니다.

• VPC
• Cloud SQL for MySQL
• Cloud Storage Bucket
• Google Kubernetes Engine
• KMS Crypto Key
• Load Balancer

다른 배포 옵션에는 다음과 같은 선택적 구성 요소가 포함될 수도 있습니다.

• Redis용 메모리 저장소
• Pub/Sub 메시지 시스템

사전 필수 권한

terraform을 실행할 계정은 사용된 GCP 프로젝트에서 roles/owner 역할을 가지고 있어야 합니다.

일반적인 단계

이 항목의 단계는 이 문서에서 다루는 모든 배포 옵션에 공통적입니다.

1. 개발 환경을 준비합니다.

   • Terraform을 설치합니다.
   • 사용할 코드로 Git 저장소를 만드는 것이 좋지만, 파일을 로컬에 보관할 수도 있습니다.
   • Google Cloud Console에서 프로젝트를 만듭니다.
   • GCP로 인증합니다 (gcloud 설치되었는지 확인). gcloud auth application-default login

2. 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의 조합은 Weights & Biases가 구성될 FQDN을 형성합니다. 위의 예에서 Weights & Biases FQDN은 wandb-gcp.wandb.ml입니다.

3. 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 = "리소스에 사용되는 네임스페이스 접두사"
   }
   
   variable "domain_name" {
     type        = string
     description = "Weights & Biases UI에 엑세스하기 위한 도메인 이름입니다."
   }
   
   variable "subdomain" {
     type        = string
     description = "Weights & Biases UI에 엑세스하기 위한 하위 도메인입니다."
   }
   
   variable "license" {
     type        = string
     description = "W&B License"
   }
   

배포 - 권장 (~20분)

이는 모든 필수 구성 요소를 만들고 Kubernetes Cluster에 최신 버전의 W&B를 설치하는 가장 간단한 배포 옵션 구성입니다.

1. main.tf를 만듭니다.

   일반적인 단계에서 파일을 만든 동일한 디렉토리에 다음 내용으로 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
   }
   
   # Spin up all required services
   module "wandb" {
     source  = "wandb/wandb/google"
     version = "~> 5.0"
   
     namespace   = var.namespace
     license     = var.license
     domain_name = var.domain_name
     subdomain   = var.subdomain
   }
   
   # You'll want to update your DNS with the provisioned IP address
   output "url" {
     value = module.wandb.url
   }
   
   output "address" {
     value = module.wandb.address
   }
   
   output "bucket_name" {
     value = module.wandb.bucket_name
   }
   

2. W&B를 배포합니다.

   W&B를 배포하려면 다음 코맨드를 실행합니다.

   terraform init
   terraform apply -var-file=terraform.tfvars
   

REDIS Cache를 사용한 배포

또 다른 배포 옵션은 Redis를 사용하여 SQL 쿼리를 캐시하고 Experiments에 대한 메트릭 로드 시 애플리케이션 응답 속도를 높이는 것입니다.

캐시를 활성화하려면 권장되는 배포 옵션 섹션에 지정된 동일한 main.tf 파일에 옵션 create_redis = true를 추가해야 합니다.

[...]

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

  namespace    = var.namespace
  license      = var.license
  domain_name  = var.domain_name
  subdomain    = var.subdomain
  allowed_inbound_cidrs = ["*"]
  #Enable Redis
  create_redis = true

}
[...]

외부 큐를 사용한 배포

배포 옵션 3은 외부 message broker를 활성화하는 것으로 구성됩니다. W&B는 broker가 내장되어 있으므로 선택 사항입니다. 이 옵션은 성능 향상을 제공하지 않습니다.

메시지 broker를 제공하는 GCP 리소스는 Pub/Sub이며, 이를 활성화하려면 권장되는 배포 옵션 섹션에 지정된 동일한 main.tf에 옵션 use_internal_queue = false를 추가해야 합니다.

[...]

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

  namespace          = var.namespace
  license            = var.license
  domain_name        = var.domain_name
  subdomain          = var.subdomain
  allowed_inbound_cidrs = ["*"]
  #Create and use Pub/Sub
  use_internal_queue = false

}

[...]

기타 배포 옵션

동일한 파일에 모든 구성을 추가하여 세 가지 배포 옵션을 모두 결합할 수 있습니다. Terraform Module은 배포 - 권장에서 찾은 표준 옵션 및 최소 구성과 함께 결합할 수 있는 여러 옵션을 제공합니다.

수동 구성

GCP Storage 버킷을 W&B의 파일 스토리지 백엔드로 사용하려면 다음을 만들어야 합니다.

• PubSub Topic 및 Subscription
• Storage Bucket
• PubSub Notification

PubSub Topic 및 Subscription 만들기

PubSub 토픽 및 구독을 만들려면 아래 절차를 따르십시오.

1. GCP Console 내에서 Pub/Sub 서비스로 이동합니다.
2. 토픽 만들기를 선택하고 토픽 이름을 입력합니다.
3. 페이지 하단에서 구독 만들기를 선택합니다. 전달 유형이 Pull로 설정되어 있는지 확인합니다.
4. 만들기를 클릭합니다.

인스턴스를 실행하는 서비스 계정 또는 계정이 이 구독에 대해 pubsub.admin 역할을 가지고 있는지 확인합니다. 자세한 내용은 https://cloud.google.com/pubsub/docs/access-control#console을 참조하십시오.

Storage Bucket 만들기

1. Cloud Storage Buckets 페이지로 이동합니다.
2. 버킷 만들기를 선택하고 버킷 이름을 입력합니다. Standard 스토리지 클래스를 선택해야 합니다.

인스턴스를 실행하는 서비스 계정 또는 계정이 다음을 모두 가지고 있는지 확인합니다.

• 이전 단계에서 만든 버킷에 대한 엑세스 권한
• 이 버킷에 대한 storage.objectAdmin 역할 자세한 내용은 https://cloud.google.com/storage/docs/access-control/using-iam-permissions#bucket-add를 참조하십시오.

3. CORS 엑세스를 활성화합니다. 이는 커맨드라인을 사용해서만 수행할 수 있습니다. 먼저 다음 CORS 구성으로 JSON 파일을 만듭니다.

cors:
- maxAgeSeconds: 3600
  method:
   - GET
   - PUT
     origin:
   - '<YOUR_W&B_SERVER_HOST>'
     responseHeader:
   - Content-Type

origin 값의 체계, 호스트 및 포트가 정확히 일치해야 합니다.

4. gcloud가 설치되어 있고 올바른 GCP 프로젝트에 로그인되어 있는지 확인합니다.
5. 다음을 실행합니다.

gcloud storage buckets update gs://<BUCKET_NAME> --cors-file=<CORS_CONFIG_FILE>

PubSub Notification 만들기

커맨드라인에서 아래 절차에 따라 Storage Bucket에서 Pub/Sub 토픽으로의 알림 스트림을 만듭니다.

1. GCP 프로젝트에 로그인합니다.
2. 터미널에서 다음을 실행합니다.

gcloud pubsub topics list  # 참조용 토픽 이름 나열
gcloud storage ls          # 참조용 버킷 이름 나열

# 버킷 알림 만들기
gcloud storage buckets notifications create gs://<BUCKET_NAME> --topic=<TOPIC_NAME>

자세한 참조는 Cloud Storage 웹사이트에서 확인할 수 있습니다.

W&B 서버 구성

1. 마지막으로 http(s)://YOUR-W&B-SERVER-HOST/console/settings/system에서 W&B System Connections 페이지로 이동합니다.
2. Google Cloud Storage (gcs) 제공자를 선택합니다.
3. GCS 버킷 이름을 제공합니다.

4. 설정 업데이트를 눌러 새 설정을 적용합니다.

W&B Server 업그레이드

W&B를 업데이트하려면 여기에 설명된 단계를 따르십시오.

1. wandb_app 모듈의 구성에 wandb_version을 추가합니다. 업그레이드할 W&B 버전을 제공합니다. 예를 들어, 다음 줄은 W&B 버전 0.48.1을 지정합니다.

module "wandb_app" {
    source  = "wandb/wandb/kubernetes"
    version = "~>5.0"

    license       = var.license
    wandb_version = "0.58.1"

2. 구성을 업데이트한 후 배포 옵션 섹션에 설명된 단계를 완료합니다.

3.3 - Deploy W&B Platform on Azure

W&B Server를 자체 관리하기로 결정했다면 W&B Server Azure Terraform Module을 사용하여 Azure에 플랫폼을 배포하는 것이 좋습니다.

모듈 설명서는 광범위하며 사용할 수 있는 모든 옵션이 포함되어 있습니다. 이 문서에서는 몇 가지 배포 옵션을 다룹니다.

시작하기 전에 Terraform에 사용할 수 있는 remote backends 중 하나를 선택하여 State File을 저장하는 것이 좋습니다.

State File은 모든 구성 요소를 다시 생성하지 않고도 업그레이드를 롤아웃하거나 배포를 변경하는 데 필요한 리소스입니다.

Terraform Module은 다음과 같은 필수 구성 요소를 배포합니다.

• Azure Resource Group
• Azure Virtual Network (VPC)
• Azure MySQL Flexible Server
• Azure Storage Account & Blob Storage
• Azure Kubernetes Service
• Azure Application Gateway

다른 배포 옵션에는 다음과 같은 선택적 구성 요소도 포함될 수 있습니다.

• Azure Cache for Redis
• Azure Event Grid

전제 조건 권한

AzureRM provider를 구성하는 가장 간단한 방법은 Azure CLI를 이용하는 것이지만, Azure Service Principal을 사용한 자동화도 유용할 수 있습니다. 어떤 인증 방법을 사용하든 Terraform을 실행할 계정은 도입부에 설명된 모든 구성 요소를 생성할 수 있어야 합니다.

일반적인 단계

이 주제의 단계는 이 문서에서 다루는 모든 배포 옵션에 공통적입니다.

1. 개발 환경을 준비합니다.

• Terraform을 설치합니다.
• 사용할 코드로 Git repository를 만드는 것이 좋지만, 파일을 로컬에 보관할 수도 있습니다.

2. terraform.tfvars 파일 만들기 tvfars 파일 내용은 설치 유형에 따라 사용자 정의할 수 있지만, 최소 권장 사항은 아래 예제와 같습니다.

    namespace     = "wandb"
    wandb_license = "xxxxxxxxxxyyyyyyyyyyyzzzzzzz"
    subdomain     = "wandb-aws"
    domain_name   = "wandb.ml"
    location      = "westeurope"
   

   여기에 정의된 변수는 배포 전에 결정해야 합니다. namespace 변수는 Terraform에서 생성한 모든 리소스의 접두사가 되는 문자열입니다.

   subdomain과 domain의 조합은 Weights & Biases가 구성될 FQDN을 형성합니다. 위의 예에서 W&B FQDN은 wandb-aws.wandb.ml이고 FQDN 레코드가 생성될 DNS zone_id입니다.

3. versions.tf 파일 만들기 이 파일에는 AWS에 W&B를 배포하는 데 필요한 Terraform 및 Terraform provider 버전이 포함됩니다.

terraform {
  required_version = "~> 1.3"

  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 3.17"
    }
  }
}

AWS provider를 구성하려면 Terraform 공식 문서를 참조하세요.

선택 사항이지만, 매우 권장되는 방법으로 이 문서의 시작 부분에서 언급한 remote backend configuration을 추가할 수 있습니다.

4. variables.tf 파일 만들기. terraform.tfvars에서 구성된 모든 옵션에 대해 Terraform은 해당 변수 선언이 필요합니다.

  variable "namespace" {
    type        = string
    description = "리소스 접두사에 사용되는 문자열입니다."
  }

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

  variable "domain_name" {
    type        = string
    description = "Weights & Biases UI에 엑세스하기 위한 도메인입니다."
  }

  variable "subdomain" {
    type        = string
    default     = null
    description = "Weights & Biases UI에 엑세스하기 위한 서브 도메인입니다. 기본값은 Route53 Route에 레코드를 생성합니다."
  }

  variable "license" {
    type        = string
    description = "wandb/local 라이선스"
  }

권장 배포

이것은 가장 간단한 배포 옵션 구성으로, 모든 필수 구성 요소를 생성하고 Kubernetes Cluster에 최신 버전의 W&B를 설치합니다.

1. main.tf 만들기 일반적인 단계에서 파일을 만든 동일한 디렉토리에 다음 내용으로 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
}

2. W&B에 배포 W&B를 배포하려면 다음 코맨드를 실행합니다.

   terraform init
   terraform apply -var-file=terraform.tfvars
   

REDIS Cache를 사용한 배포

또 다른 배포 옵션은 Redis를 사용하여 SQL 쿼리를 캐시하고 Experiments에 대한 메트릭을 로드할 때 애플리케이션 응답 속도를 높입니다.

캐시를 활성화하려면 권장 배포에서 사용한 것과 동일한 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 # Redis 생성
  [...]

외부 큐를 사용한 배포

배포 옵션 3은 외부 message broker를 활성화하는 것으로 구성됩니다. W&B는 broker를 내장하고 있기 때문에 선택 사항입니다. 이 옵션은 성능 향상을 가져오지 않습니다.

메시지 broker를 제공하는 Azure 리소스는 Azure Event Grid이며, 이를 활성화하려면 권장 배포에서 사용한 것과 동일한 main.tf에 use_internal_queue = false 옵션을 추가해야 합니다.

# 필요한 모든 서비스 시작
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 # Azure Event Grid 활성화
  [...]
}

기타 배포 옵션

동일한 파일에 모든 구성을 추가하여 세 가지 배포 옵션을 모두 결합할 수 있습니다. Terraform Module은 표준 옵션과 권장 배포에서 찾을 수 있는 최소 구성과 함께 결합할 수 있는 여러 옵션을 제공합니다.

4 - Deploy W&B Platform On-premises

관련 질문은 W&B Sales 팀에 문의하십시오: contact@wandb.com.

인프라 가이드라인

W&B 배포를 시작하기 전에 참조 아키텍처, 특히 인프라 요구 사항을 참조하십시오.

MySQL 데이터베이스

확장 가능한 MySQL 데이터베이스 운영을 간소화하는 여러 엔터프라이즈 서비스가 있습니다. W&B에서는 다음 솔루션 중 하나를 살펴보는 것이 좋습니다.

https://www.percona.com/software/mysql-database/percona-server

https://github.com/mysql/mysql-operator

W&B Server MySQL 8.0을 실행하거나 MySQL 5.7에서 8.0으로 업그레이드하는 경우 아래 조건을 충족하십시오.

binlog_format = 'ROW'
innodb_online_alter_log_max_size = 268435456
sync_binlog = 1
innodb_flush_log_at_trx_commit = 1
binlog_row_image = 'MINIMAL'

MySQL 8.0에서 sort_buffer_size를 처리하는 방식이 변경되었으므로 sort_buffer_size 파라미터를 기본값인 262144에서 업데이트해야 할 수 있습니다. W&B와 함께 MySQL이 효율적으로 작동하도록 값을 67108864 (64MiB)로 설정하는 것이 좋습니다. MySQL은 v8.0.28부터 이 설정을 지원합니다.

데이터베이스 고려 사항

다음 SQL 쿼리를 사용하여 데이터베이스와 사용자를 만듭니다. SOME_PASSWORD를 원하는 비밀번호로 바꿉니다.

CREATE USER 'wandb_local'@'%' IDENTIFIED BY 'SOME_PASSWORD';
CREATE DATABASE wandb_local CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
GRANT ALL ON wandb_local.* TO 'wandb_local'@'%' WITH GRANT OPTION;

파라미터 그룹 설정

데이터베이스 성능을 튜닝하려면 다음 파라미터 그룹이 설정되었는지 확인하십시오.

binlog_format = 'ROW'
innodb_online_alter_log_max_size = 268435456
sync_binlog = 1
innodb_flush_log_at_trx_commit = 1
binlog_row_image = 'MINIMAL'
sort_buffer_size = 67108864

오브젝트 스토리지

오브젝트 스토리지는 Minio cluster 또는 서명된 URL을 지원하는 Amazon S3 호환 오브젝트 스토리지에서 외부적으로 호스팅할 수 있습니다. 다음 스크립트를 실행하여 오브젝트 스토리지가 서명된 URL을 지원하는지 확인하십시오.

또한 다음 CORS 정책을 오브젝트 스토리지에 적용해야 합니다.

<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<CORSRule>
    <AllowedOrigin>http://YOUR-W&B-SERVER-IP</AllowedOrigin>
    <AllowedMethod>GET</AllowedMethod>
    <AllowedMethod>PUT</AllowedMethod>
    <AllowedMethod>HEAD</AllowedMethod>
    <AllowedHeader>*</AllowedHeader>
</CORSRule>
</CORSConfiguration>

Amazon S3 호환 오브젝트 스토리지에 연결할 때 연결 문자열에 자격 증명을 지정할 수 있습니다. 예를 들어 다음과 같이 지정할 수 있습니다.

s3://$ACCESS_KEY:$SECRET_KEY@$HOST/$BUCKET_NAME

선택적으로 오브젝트 스토리지에 대해 신뢰할 수 있는 SSL 인증서를 구성한 경우 W&B에 TLS를 통해서만 연결하도록 지시할 수 있습니다. 이렇게 하려면 URL에 tls 쿼리 파라미터를 추가하십시오. 예를 들어 다음 URL 예제는 Amazon S3 URI에 TLS 쿼리 파라미터를 추가하는 방법을 보여줍니다.

s3://$ACCESS_KEY:$SECRET_KEY@$HOST/$BUCKET_NAME?tls=true

타사 오브젝트 스토리지를 사용하는 경우 BUCKET_QUEUE를 internal://로 설정하십시오. 이렇게 하면 W&B 서버가 외부 SQS 대기열 또는 이와 동등한 대기열에 의존하는 대신 모든 오브젝트 알림을 내부적으로 관리합니다.

자체 오브젝트 스토리지를 실행할 때 고려해야 할 가장 중요한 사항은 다음과 같습니다.

1. 저장 용량 및 성능. 자기 디스크를 사용해도 괜찮지만 이러한 디스크의 용량을 모니터링해야 합니다. 평균적인 W&B 사용량은 10~100GB입니다. 사용량이 많으면 페타바이트의 스토리지 소비가 발생할 수 있습니다.
2. 결함 허용 오차. 최소한 오브젝트를 저장하는 물리적 디스크는 RAID 어레이에 있어야 합니다. minio를 사용하는 경우 분산 모드로 실행하는 것을 고려하십시오.
3. 가용성. 스토리지를 사용할 수 있는지 확인하기 위해 모니터링을 구성해야 합니다.

자체 오브젝트 스토리지 서비스를 실행하는 대신 다음과 같은 여러 엔터프라이즈 대안이 있습니다.

1. https://aws.amazon.com/s3/outposts/
2. https://www.netapp.com/data-storage/storagegrid/

MinIO 설정

minio를 사용하는 경우 다음 코맨드를 실행하여 버킷을 만들 수 있습니다.

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

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

권장되는 설치 방법은 공식 W&B Helm 차트를 사용하는 것입니다. 이 섹션에 따라 W&B Server 애플리케이션을 배포하십시오.

OpenShift

W&B는 OpenShift Kubernetes cluster 내에서 운영하는 것을 지원합니다.

권한 없는 사용자로 컨테이너 실행

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

Kubernetes에 대한 보안 컨텍스트 예제는 다음과 유사합니다.

spec:
  securityContext:
    runAsUser: 100000
    runAsGroup: 0

네트워킹

로드 밸런서

적절한 네트워크 경계에서 네트워크 요청을 중지하는 로드 밸런서를 실행합니다.

일반적인 로드 밸런서에는 다음이 포함됩니다.

1. Nginx Ingress
2. Istio
3. Caddy
4. Cloudflare
5. Apache
6. HAProxy

기계 학습 페이로드를 실행하는 데 사용되는 모든 장치와 웹 브라우저를 통해 서비스에 액세스하는 데 사용되는 장치가 이 엔드포인트와 통신할 수 있는지 확인하십시오.

SSL / TLS

W&B Server는 SSL을 중지하지 않습니다. 보안 정책에서 신뢰할 수 있는 네트워크 내에서 SSL 통신을 요구하는 경우 Istio와 같은 툴과 side car containers를 사용하는 것이 좋습니다. 로드 밸런서 자체는 유효한 인증서로 SSL을 종료해야 합니다. 자체 서명된 인증서를 사용하는 것은 지원되지 않으며 사용자에게 여러 가지 문제가 발생할 수 있습니다. 가능하다면 Let’s Encrypt와 같은 서비스를 사용하여 로드 밸런서에 신뢰할 수 있는 인증서를 제공하는 것이 좋습니다. Caddy 및 Cloudflare와 같은 서비스는 SSL을 관리합니다.

Nginx 구성 예제

다음은 nginx를 역방향 프록시로 사용하는 구성 예제입니다.

events {}
http {
    # If we receive X-Forwarded-Proto, pass it through; otherwise, pass along the
    # scheme used to connect to this server
    map $http_x_forwarded_proto $proxy_x_forwarded_proto {
        default $http_x_forwarded_proto;
        ''      $scheme;
    }

    # Also, in the above case, force HTTPS
    map $http_x_forwarded_proto $sts {
        default '';
        "https" "max-age=31536000; includeSubDomains";
    }

    # If we receive X-Forwarded-Host, pass it though; otherwise, pass along $http_host
    map $http_x_forwarded_host $proxy_x_forwarded_host {
        default $http_x_forwarded_host;
        ''      $http_host;
    }

    # If we receive X-Forwarded-Port, pass it through; otherwise, pass along the
    # server port the client connected to
    map $http_x_forwarded_port $proxy_x_forwarded_port {
        default $http_x_forwarded_port;
        ''      $server_port;
    }

    # If we receive Upgrade, set Connection to "upgrade"; otherwise, delete any
    # Connection header that may have been passed to this server
    map $http_upgrade $proxy_connection {
        default upgrade;
        '' close;
    }

    server {
        listen 443 ssl;
        server_name         www.example.com;
        ssl_certificate     www.example.com.crt;
        ssl_certificate_key www.example.com.key;

        proxy_http_version 1.1;
        proxy_buffering off;
        proxy_set_header Host $http_host;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $proxy_connection;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $proxy_x_forwarded_proto;
        proxy_set_header X-Forwarded-Host $proxy_x_forwarded_host;

        location / {
            proxy_pass  http://$YOUR_UPSTREAM_SERVER_IP:8080/;
        }

        keepalive_timeout 10;
    }
}

설치 확인

W&B Server가 올바르게 구성되었는지 확인하십시오. 터미널에서 다음 코맨드를 실행합니다.

pip install wandb
wandb login --host=https://YOUR_DNS_DOMAIN
wandb verify

로그 파일을 확인하여 W&B Server가 시작 시에 발생하는 오류를 확인하십시오. 다음 코맨드를 실행합니다.

• Docker
• Kubernetes

docker logs wandb-local

kubectl get pods
kubectl logs wandb-XXXXX-XXXXX

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

5 - Update W&B license and version

W&B 서버를 설치한 방법과 동일한 방법으로 W&B 서버 버전 및 라이선스를 업데이트합니다. 다음 표에는 다양한 배포 방법을 기준으로 라이선스 및 버전을 업데이트하는 방법이 나와 있습니다.

Terraform으로 업데이트

Terraform을 사용하여 라이선스 및 버전을 업데이트합니다. 다음 표에는 클라우드 플랫폼을 기반으로 W&B에서 관리하는 Terraform 모듈이 나와 있습니다.

1. 먼저, 해당 클라우드 공급자에 대해 W&B에서 관리하는 Terraform 모듈로 이동합니다. 이전 표를 참조하여 클라우드 공급자를 기반으로 적절한 Terraform 모듈을 찾으십시오.

2. Terraform 구성 내에서 Terraform wandb_app 모듈 구성에서 wandb_version 및 license를 업데이트합니다.

   module "wandb_app" {
       source  = "wandb/wandb/<cloud-specific-module>"
       version = "new_version"
       license       = "new_license_key" # Your new license key
       wandb_version = "new_wandb_version" # Desired W&B version
       ...
   }
   

3. terraform plan 및 terraform apply를 사용하여 Terraform 구성을 적용합니다.

   terraform init
   terraform apply
   

4. (선택 사항) terraform.tfvars 또는 기타 .tfvars 파일을 사용하는 경우

   새 W&B 버전 및 라이선스 키로 terraform.tfvars 파일을 업데이트하거나 만듭니다.

   terraform plan -var-file="terraform.tfvars"
   

   구성을 적용합니다. Terraform 워크스페이스 디렉토리에서 다음을 실행합니다.

   terraform apply -var-file="terraform.tfvars"
   

Helm으로 업데이트

사양으로 W&B 업데이트

1. Helm 차트 *.yaml 구성 파일에서 image.tag 및/또는 license 값을 수정하여 새 버전을 지정합니다.

   license: 'new_license'
   image:
     repository: wandb/local
     tag: 'new_version'
   

2. 다음 코맨드를 사용하여 Helm 업그레이드를 실행합니다.

   helm repo update
   helm upgrade --namespace=wandb --create-namespace \
     --install wandb wandb/wandb --version ${chart_version} \
     -f ${wandb_install_spec.yaml}
   

라이선스 및 버전 직접 업데이트

1. 새 라이선스 키와 이미지 태그를 환경 변수로 설정합니다.

   export LICENSE='new_license'
   export TAG='new_version'
   

2. 아래 코맨드를 사용하여 Helm 릴리스를 업그레이드하고 새 값을 기존 구성과 병합합니다.

   helm repo update
   helm upgrade --namespace=wandb --create-namespace \
     --install wandb wandb/wandb --version ${chart_version} \
     --reuse-values --set license=$LICENSE --set image.tag=$TAG
   

자세한 내용은 퍼블릭 저장소의 업그레이드 가이드를 참조하십시오.

관리 UI로 업데이트

이 방법은 일반적으로 자체 호스팅 Docker 설치에서 W&B 서버 컨테이너의 환경 변수로 설정되지 않은 라이선스를 업데이트하는 데만 사용할 수 있습니다.

1. 업그레이드하려는 배포에 대해 올바른 organization 및 배포 ID와 일치하는지 확인하면서 W&B 배포 페이지에서 새 라이선스를 가져옵니다.
2. <host-url>/system-settings에서 W&B 관리 UI에 엑세스합니다.
3. 라이선스 관리 섹션으로 이동합니다.
4. 새 라이선스 키를 입력하고 변경 사항을 저장합니다.