에어갭 Kubernetes에 배포 - Weights & Biases Documentation

소개

이 가이드는 에어갭(air-gapped), 분리 또는 제한된 네트워크의 고객 관리 환경에 W&B Platform을 배포하는 단계별 지침을 제공합니다. 이 가이드를 따르면 W&B 이미지와 차트를 호스팅하기 위한 내부 컨테이너 레지스트리와 Helm 저장소를 설정하고, W&B Kubernetes Operator를 설치하며, 외부 인터넷 연결 없이 W&B Platform을 배포할 수 있습니다. 이 가이드는 규제되거나 격리된 네트워크에서 Kubernetes 인프라를 관리하는 플랫폼 관리자와 DevOps 엔지니어를 대상으로 합니다. 에어갭 배포는 다음과 같은 환경에서 일반적입니다.

보안이 중요한 정부 시설.
엄격한 네트워크 격리가 필요한 금융 기관.
규정 준수 요구 사항이 있는 의료 기관.
산업 제어 시스템(ICS) 환경.
기밀 네트워크를 사용하는 연구 시설.

Kubernetes 클러스터에 적절한 접근 권한이 있는 셸 콘솔에서 이 명령어를 실행하세요. 이 명령어는 Kubernetes 애플리케이션을 배포하는 데 사용하는 모든 CI/CD 도구에 맞게 조정할 수 있습니다. 인터넷 연결이 가능한 표준 온프레미스 Kubernetes 배포의 경우 Kubernetes Operator로 W&B 배포를 참조하세요.

사전 요구 사항

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

버전 요구사항

소프트웨어	최소 버전
Kubernetes	v1.34 이상 (지원되는 Kubernetes 버전)
Helm	v3.x
MySQL	W&B Self-Managed 배포에서는 보안 패치와 중요한 버그 수정이 제공되는 지원되는 MySQL 버전을 실행해야 합니다. MySQL 8.4.x를 설치하거나 업그레이드하세요. 또는 공급자가 지원되며 패치가 적용된 것으로 문서화한 관리형 서비스 버전을 사용하세요. Aurora MySQL 버전 string은 커뮤니티 MySQL 버전과 다릅니다. 전체 엔진 버전 string을 보려면 `SELECT version()`을 사용하고, Aurora 버전을 보려면 `SELECT aurora_version()`을 사용하세요. Aurora MySQL version 3는 MySQL 8.0.x와 호환되며 계속 지원됩니다. 대상 버전을 선택할 때는 Amazon Aurora versioning 및 클라우드 제공업체 문서를 참조하세요.
Redis	v7.x
ClickHouse	Self-Managed 배포에서 Weave 및 일부 Models OLAP 특성을 사용하려면 필요합니다. 최소 버전은 활성화된 특성과 W&B Server 버전에 따라 달라집니다. 업그레이드를 위한 ClickHouse 호환성 및 지원되는 W&B Server 릴리스를 참조하세요.

SSL/TLS 요구 사항

W&B는 클라이언트와 서버 간의 보안 통신을 위해 유효한 공인 SSL/TLS 인증서를 요구합니다. SSL/TLS 종료는 인그레스 또는 로드 밸런서에서 이루어져야 합니다. W&B Server 애플리케이션은 SSL 또는 TLS 연결을 종료하지 않습니다.

W&B는 자체 서명 인증서 또는 사용자 지정 CA를 지원하지 않습니다. 자체 서명 인증서는 사용자에게 문제를 일으키며 지원되지 않습니다.

가능하다면 Let’s Encrypt와 같은 서비스를 사용해 로드 밸런서에 신뢰할 수 있는 인증서를 제공하세요. Caddy 및 Cloudflare와 같은 서비스는 SSL을 대신 관리해 줍니다. 보안 정책상 신뢰할 수 있는 네트워크 내부에서도 SSL 통신이 필요하다면, Istio와 사이드카 컨테이너 같은 도구를 사용하는 것을 고려하세요.

하드웨어 요구 사항

CPU 아키텍처: W&B는 Intel(x86) CPU 아키텍처에서만 실행됩니다. ARM은 지원되지 않습니다. 사이징: Kubernetes 노드와 MySQL의 CPU, 메모리, 디스크 사이징 권장 사항은 레퍼런스 아키텍처의 Sizing 섹션을 참조하세요. 요구 사항은 Models, Weave 또는 둘 다를 실행하는지에 따라 달라집니다.

MySQL 데이터베이스

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

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

Redis

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

Amazon ElastiCache
Google Cloud Memorystore
Azure Cache for Redis
클라우드 또는 온프레미스 인프라에서 자체 호스팅되는 Redis

객체 저장소

W&B에는 사전 서명된 URL 및 CORS를 지원하는 오브젝트 저장소가 필요합니다. W&B는 다음 저장소 공급자를 권장합니다.

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

MinIO Open Source는 유지 관리 모드 상태이며, 활발한 개발이 이루어지지 않고 사전 컴파일된 바이너리도 제공되지 않습니다. 프로덕션 배포의 경우, W&B는 관리형 오브젝트 저장소 서비스 또는 MinIO Enterprise (AIStor)와 같은 엔터프라이즈 S3 호환 솔루션을 권장합니다.

공급자를 선택한 후에는 W&B가 해당 버킷에 액세스할 수 있도록 버킷을 설정하세요. IAM 정책, CORS 설정, 액세스 설정을 포함한 자세한 버킷 프로비저닝 지침은 Bring Your Own Bucket (BYOB) 가이드를 참조하세요. 용량 및 성능 지침을 포함한 오브젝트 저장소 요구 사항의 전체 목록은 레퍼런스 아키텍처의 오브젝트 저장소 섹션을 참조하세요. 객체 저장소 프로비저닝에 관한 자세한 안내는 Bring Your Own Bucket (BYOB) 가이드를 참조하세요. 에어갭 환경에서는 일반적으로 MinIO Enterprise, NetApp StorageGRID, Dell ECS와 같은 온프레미스 S3 호환 저장소를 사용합니다.

에어갭 환경별 요구 사항

앞의 표준 요구 사항 외에도 에어갭 배포에는 다음이 필요합니다.

내부 컨테이너 레지스트리: 필요한 모든 W&B 이미지가 포함된 Harbor, JFrog Artifactory 또는 Nexus와 같은 프라이빗 컨테이너 레지스트리에 대한 액세스.
내부 Helm 저장소: W&B Helm 차트가 있는 프라이빗 Helm 차트 저장소에 대한 액세스.
이미지 전송 기능: 인터넷에 연결된 시스템에서 에어갭 레지스트리로 컨테이너 이미지를 전송할 수 있는 방법.
라이선스 파일: 유효한 W&B 엔터프라이즈 라이선스. 라이선스를 획득하려면(예: 인터넷에 연결된 시스템에서) Requirements 페이지의 License 섹션을 참조하거나 W&B account team에 문의하세요.

네트워킹 및 로드 밸런서 설정을 포함한 전체 인프라 요구 사항은 레퍼런스 아키텍처를 참조하세요.

에어갭 환경 준비

다음 단계에서는 W&B 컨테이너 이미지와 Helm 차트를 호스팅할 에어갭 환경을 준비합니다. Operator를 설치하거나 플랫폼을 배포하기 전에 다음 단계를 완료하세요.

Step 1: 내부 컨테이너 레지스트리 설정

Kubernetes 클러스터는 퍼블릭 레지스트리에서 이미지를 가져올 수 없으므로, 배포 전에 필요한 모든 컨테이너 이미지를 내부 에어갭 컨테이너 레지스트리에서 사용할 수 있어야 합니다.

W&B Operator의 요구 사항을 추적하고 컨테이너 레지스트리를 최신 이미지로 정기적으로 유지 관리하는 것은 사용자의 책임입니다. 필요한 컨테이너 이미지와 버전의 최신 목록은 Helm 차트를 참고하거나 W&B 지원팀 또는 배정된 W&B 지원 엔지니어에게 문의하세요.

핵심 W&B 구성 요소 컨테이너

다음 핵심 이미지는 필수입니다:

docker.io/wandb/controller: W&B Kubernetes Operator.
docker.io/wandb/local: W&B 애플리케이션 서버.
docker.io/wandb/console: W&B 관리 콘솔.
docker.io/wandb/megabinary: W&B 마이크로서비스(API, executor, glue, parquet).

종속성 컨테이너

다음 타사 종속성 이미지는 필수입니다:

docker.io/bitnamilegacy/redis: 테스트 및 개발 중 로컬 Redis 배포에 필요합니다. 프로덕션 Redis 요구 사항은 사전 요구 사항의 Redis 섹션을 참조하세요.
docker.io/otel/opentelemetry-collector-contrib: 메트릭과 로그를 수집하는 OpenTelemetry 에이전트.
quay.io/prometheus/prometheus: 메트릭 수집용 Prometheus.
quay.io/prometheus-operator/prometheus-config-reloader: Prometheus 종속성.

전체 이미지 목록 조회

Helm 차트에서 필요한 이미지와 버전의 전체 목록을 추출하려면 다음 단계를 따르세요.

인터넷에 연결된 시스템에서 W&B Helm charts 저장소로부터 W&B Helm 차트를 다운로드합니다.
# helm-charts 저장소 복제 git clone https://github.com/wandb/helm-charts.git cd helm-charts

values.yaml 파일을 확인해 모든 컨테이너 이미지와 해당 버전을 파악합니다.

# operator 차트에서 이미지 참조 추출
helm show values charts/operator | grep -E "repository:|tag:" | grep -v "^#"

# platform 차트에서 이미지 참조 추출
helm show values charts/operator-wandb | grep -E "repository:|tag:" | grep -v "^#"

또는 다음 명령을 사용해 저장소 이름만 추출할 수 있습니다(버전 태그 제외).

helm show values charts/operator-wandb \
  | awk -F': *' '/^[[:space:]]*repository:/{print $2}' \
  | grep -v "^#" \
  | sort -u

저장소 목록은 다음과 비슷하게 표시됩니다.

wandb/controller
wandb/local
wandb/console
wandb/megabinary
wandb/weave-python
wandb/weave-trace
otel/opentelemetry-collector-contrib
prometheus/prometheus
prometheus-operator/prometheus-config-reloader
bitnamilegacy/redis

각 이미지의 정확한 버전 태그를 조회하려면 앞서 나온 첫 번째 명령(grep -E "repository:|tag:")을 사용하세요. 그러면 저장소 이름과 해당 버전 태그가 함께 표시됩니다.

이미지를 에어갭 레지스트리로 전송

인터넷에 연결된 시스템에서 필요한 모든 이미지를 pull한 후 저장하세요.

다음 예시의 버전 번호는 앞 단계에서 Helm 차트를 검사해 확인한 실제 버전으로 바꾸세요. 여기에 표시된 버전은 예시일 뿐이며, 시간이 지나면 오래될 수 있습니다.

셸 변수를 사용해 버전을 일관되게 관리하세요:

# 버전 변수 설정(Helm 차트 버전에 맞게 업데이트)
CONTROLLER_VERSION="1.13.3"
APP_VERSION="0.59.2"
CONSOLE_VERSION="2.12.2"

# 이미지 pull
docker pull wandb/controller:${CONTROLLER_VERSION}
docker pull wandb/local:${APP_VERSION}
docker pull wandb/console:${CONSOLE_VERSION}
docker pull wandb/megabinary:${APP_VERSION}
# ... 필요한 다른 모든 이미지도 해당 버전으로 pull

# 이미지를 .tar 파일로 저장
docker save wandb/controller:${CONTROLLER_VERSION} -o wandb-controller-${CONTROLLER_VERSION}.tar
docker save wandb/local:${APP_VERSION} -o wandb-local-${APP_VERSION}.tar
docker save wandb/console:${CONSOLE_VERSION} -o wandb-console-${CONSOLE_VERSION}.tar
docker save wandb/megabinary:${APP_VERSION} -o wandb-megabinary-${APP_VERSION}.tar
# ... 다른 모든 이미지도 저장

USB 드라이브나 보안 파일 전송 등 승인된 방법을 사용해 .tar 파일을 에어갭 환경으로 옮기세요.

에어갭 환경에서 이미지를 로드한 다음 내부 레지스트리로 push하세요:

# 위에서 사용한 것과 동일한 버전 변수 설정
CONTROLLER_VERSION="1.13.3"
APP_VERSION="0.59.2"
CONSOLE_VERSION="2.12.2"
INTERNAL_REGISTRY="registry.yourdomain.com"

# 이미지 로드
docker load -i wandb-controller-${CONTROLLER_VERSION}.tar
docker load -i wandb-local-${APP_VERSION}.tar
docker load -i wandb-console-${CONSOLE_VERSION}.tar
docker load -i wandb-megabinary-${APP_VERSION}.tar
# ... 다른 모든 이미지 로드

# 내부 레지스트리용 태그 지정
docker tag wandb/controller:${CONTROLLER_VERSION} ${INTERNAL_REGISTRY}/wandb/controller:${CONTROLLER_VERSION}
docker tag wandb/local:${APP_VERSION} ${INTERNAL_REGISTRY}/wandb/local:${APP_VERSION}
docker tag wandb/console:${CONSOLE_VERSION} ${INTERNAL_REGISTRY}/wandb/console:${CONSOLE_VERSION}
docker tag wandb/megabinary:${APP_VERSION} ${INTERNAL_REGISTRY}/wandb/megabinary:${APP_VERSION}
# ... 다른 모든 이미지 태그 지정

# 내부 레지스트리로 push
docker push ${INTERNAL_REGISTRY}/wandb/controller:${CONTROLLER_VERSION}
docker push ${INTERNAL_REGISTRY}/wandb/local:${APP_VERSION}
docker push ${INTERNAL_REGISTRY}/wandb/console:${CONSOLE_VERSION}
docker push ${INTERNAL_REGISTRY}/wandb/megabinary:${APP_VERSION}
# ... 다른 모든 이미지 push

Step 2: 내부 Helm 차트 저장소 설정

컨테이너 이미지가 준비되면 Kubernetes Operator도 W&B Helm 차트에 액세스할 수 있어야 합니다. 내부 Helm 저장소에서 다음 Helm 차트를 사용할 수 있는지 확인하세요:

인터넷에 연결된 시스템에서 chart를 다운로드합니다:

# W&B Helm 저장소 추가
helm repo add wandb https://wandb.github.io/helm-charts
helm repo update

# chart 다운로드
helm pull wandb/operator --version 1.13.3
helm pull wandb/operator-wandb --version 0.18.0

.tgz chart 파일을 에어갭 환경으로 전송한 다음, 저장소 절차에 따라 내부 Helm 저장소에 업로드합니다. operator chart는 W&B Kubernetes Operator(Controller Manager)를 배포합니다. operator-wandb chart는 Custom Resource(CR)에 설정된 값을 사용해 W&B Platform을 배포합니다.

step 3: Helm 저장소 접근 설정

후속 설치 명령에서 차트를 찾을 수 있도록 에어갭 환경의 로컬 Helm 클라이언트가 내부 저장소를 가리키도록 설정합니다.

에어갭 환경에서 Helm이 내부 저장소를 사용하도록 설정합니다:
helm repo add local-repo https://charts.yourdomain.com helm repo update

차트를 사용할 수 있는지 확인합니다:

helm search repo local-repo/operator
helm search repo local-repo/operator-wandb

에어갭 환경에서 W&B 배포

내부 레지스트리와 Helm 저장소를 준비했다면 이제 Kubernetes Operator를 설치하고 외부 서비스를 구성한 다음 W&B Platform을 배포할 수 있습니다.

Step 4: Kubernetes Operator 설치

W&B Kubernetes Operator(컨트롤러 매니저)는 W&B Platform 컴포넌트를 관리합니다. 에어갭 환경에 설치하려면 내부 컨테이너 레지스트리를 사용하도록 설정하세요.

다음 내용으로 values.yaml 파일을 생성합니다:
image: repository: registry.yourdomain.com/wandb/controller tag: 1.13.3 airgapped: true
저장소와 태그는 Step 1에서 내부 레지스트리로 전송한 실제 버전으로 바꾸세요. 여기 표시된 버전(1.13.3)은 예시이며, 시간이 지나면 더 이상 최신 버전이 아닐 수 있습니다.

Operator와 Custom Resource Definition(CRD)을 설치합니다:

helm upgrade --install operator local-repo/operator \
  --namespace wandb \
  --create-namespace \
  --values values.yaml

Operator가 실행 중인지 확인합니다:
kubectl get pods -n wandb
Operator 파드가 Running 상태로 표시되어야 합니다.

이제 W&B Kubernetes Operator가 설치되었으며, 내부 차트 저장소에서 W&B Platform을 배포할 준비가 되었습니다. 지원되는 값에 대한 자세한 내용은 Kubernetes Operator GitHub 저장소 values 파일을 참고하세요.

Step 5: MySQL 데이터베이스 설정

W&B Custom Resource를 설정하기 전에 외부 MySQL 데이터베이스를 설정하세요. 프로덕션 배포의 경우, 가능한 환경에서는 관리형 데이터베이스 서비스를 사용할 것을 W&B에서 강력히 권장합니다. 하지만 자체 MySQL 인스턴스를 실행 중이라면 데이터베이스와 사용자를 생성하세요: 다음 SQL 명령을 사용해 데이터베이스와 사용자를 생성합니다. [PASSWORD]는 안전한 비밀번호로 바꾸세요:

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

MySQL 설정 매개변수는 레퍼런스 아키텍처 MySQL 설정 섹션을 참조하세요.

6단계: W&B Custom Resource 설정

W&B Kubernetes Operator를 설치한 후에는 Custom Resource(CR)가 내부 Helm 저장소와 컨테이너 레지스트리를 가리키도록 설정하세요. 이렇게 설정하면 W&B Platform의 필수 컴포넌트를 배포할 때 Kubernetes Operator가 공개 소스에 연결을 시도하는 대신 내부 레지스트리와 저장소를 사용하게 됩니다.

다음 예시 설정에는 시간이 지나면 더 이상 최신이 아닐 수 있는 이미지 버전 태그가 포함되어 있습니다. 모든 tag: 값을 1단계에서 내부 레지스트리로 전송한 실제 버전으로 바꾸세요.

다음 내용으로 wandb.yaml 파일을 만드세요:

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

spec:
  chart:
    url: https://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:9000
        path: wandb
        provider: s3
        region: us-east-1
      
      mysql:
        database: wandb
        host: mysql.yourdomain.com
        password: [YOUR-MYSQL-PASSWORD]
        port: 3306
        user: wandb
      
      redis:
        host: redis.yourdomain.com
        port: 6379
        password: [YOUR-REDIS-PASSWORD]
      
      api:
        enabled: true
      
      glue:
        enabled: true
      
      executor:
        enabled: true
      
      extraEnv:
        ENABLE_REGISTRY_UI: 'true'

    # 모든 컴포넌트 이미지가 내부 레지스트리를 사용하도록 설정
    app:
      image:
        repository: registry.yourdomain.com/wandb/local
        tag: 0.59.2

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

    api:
      image:
        repository: registry.yourdomain.com/wandb/megabinary
        tag: 0.59.2

    executor:
      image:
        repository: registry.yourdomain.com/wandb/megabinary
        tag: 0.59.2

    glue:
      image:
        repository: registry.yourdomain.com/wandb/megabinary
        tag: 0.59.2

    parquet:
      image:
        repository: registry.yourdomain.com/wandb/megabinary
        tag: 0.59.2

    weave:
      image:
        repository: registry.yourdomain.com/wandb/weave-python
        tag: 0.59.2

    otel:
      image:
        repository: registry.yourdomain.com/otel/opentelemetry-collector-contrib
        tag: 0.97.0

    prometheus:
      server:
        image:
          repository: registry.yourdomain.com/prometheus/prometheus
          tag: v2.47.0
      configmapReload:
        prometheus:
          image:
            repository: registry.yourdomain.com/prometheus-operator/prometheus-config-reloader
            tag: v0.67.0

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

호스트 이름, 비밀번호, 태그와 같은 모든 플레이스홀더 값은 실제 설정 값으로 바꾸세요. 앞의 예시는 가장 일반적으로 사용되는 컴포넌트를 보여줍니다.

배포 요구 사항에 따라 다음과 같은 추가 컴포넌트의 이미지 저장소도 설정해야 할 수 있습니다:

settingsMigrationJob
weave-trace
filestream
flat-runs-table

설정 가능한 컴포넌트의 전체 목록은 W&B Helm 저장소 values file을 참고하세요.

7단계: W&B Platform 배포

Custom Resource를 적용하면 operator가 wandb.yaml의 설정과 이미지 참조를 사용해 operator-wandb chart에 정의된 W&B Platform 컴포넌트를 설치합니다.

플랫폼을 배포하려면 W&B Custom Resource를 적용하세요:
kubectl apply -f wandb.yaml

배포 진행 상황을 모니터링하세요:

# 생성되는 파드 확인
kubectl get pods -n wandb --watch

# 배포 상태 확인
kubectl get weightsandbiases -n wandb

# operator 로그 보기
kubectl logs -n wandb deployment/wandb-operator-controller-manager

operator가 필요한 모든 컴포넌트를 생성하므로 배포에 몇 분 정도 걸릴 수 있습니다.

OpenShift 설정

W&B는 에어갭 OpenShift Kubernetes 클러스터에서의 배포를 지원합니다. OpenShift 배포에는 OpenShift의 더 엄격한 보안 정책으로 인해 보안 컨텍스트 설정이 추가로 필요합니다. OpenShift에 배포하는 경우 앞선 단계에 더해 이 섹션의 설정도 적용하세요.

OpenShift 보안 컨텍스트 제약 조건

OpenShift는 파드 권한을 제어하기 위해 SCC(Security Context Constraints)를 사용합니다. 기본적으로 OpenShift는 파드에 restricted SCC를 할당하므로, 루트로 실행할 수 없으며 특정 사용자 ID가 필요합니다.

옵션 1: restricted SCC 사용(권장)

Custom Resource에서 적절한 보안 컨텍스트를 설정해 W&B 컴포넌트가 restricted SCC로 실행되도록 구성합니다:

spec:
  values:
    # 모든 파드에 대한 보안 컨텍스트 구성
    app:
      podSecurityContext:
        fsGroup: 1000
        runAsUser: 1000
        runAsNonRoot: true
      securityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop:
            - ALL
        runAsNonRoot: true
        seccompProfile:
          type: RuntimeDefault

    console:
      podSecurityContext:
        fsGroup: 1000
        runAsUser: 1000
        runAsNonRoot: true
      securityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop:
            - ALL
        runAsNonRoot: true
        seccompProfile:
          type: RuntimeDefault

    # 다른 컴포넌트에 대해 반복: api, executor, glue, parquet, weave

옵션 2: 맞춤형 SCC 만들기(필요한 경우)

배포에 restricted SCC에서 제공하지 않는 기능이 필요하면 맞춤형 SCC를 만드세요:

apiVersion: security.openshift.io/v1
kind: SecurityContextConstraints
metadata:
  name: wandb-scc
allowHostDirVolumePlugin: false
allowHostIPC: false
allowHostNetwork: false
allowHostPID: false
allowHostPorts: false
allowPrivilegeEscalation: false
allowPrivilegedContainer: false
allowedCapabilities: []
defaultAddCapabilities: []
fsGroup:
  type: MustRunAs
  ranges:
    - min: 1000
      max: 65535
readOnlyRootFilesystem: false
requiredDropCapabilities:
  - ALL
runAsUser:
  type: MustRunAsRange
  uidRangeMin: 1000
  uidRangeMax: 65535
seLinuxContext:
  type: MustRunAs
supplementalGroups:
  type: RunAsAny
volumes:
  - configMap
  - downwardAPI
  - emptyDir
  - persistentVolumeClaim
  - projected
  - secret

SCC를 적용합니다:
oc apply -f wandb-scc.yaml

W&B 서비스 계정에 SCC를 바인딩합니다:

oc adm policy add-scc-to-user wandb-scc -z wandb-app -n wandb
oc adm policy add-scc-to-user wandb-scc -z wandb-console -n wandb

OpenShift Routes

OpenShift는 표준 Kubernetes 인그레스 대신 Routes를 사용합니다. W&B가 OpenShift Routes를 사용하도록 구성하세요:

spec:
  values:
    ingress:
      enabled: false
    
    route:
      enabled: true
      host: wandb.apps.openshift.yourdomain.com
      tls:
        enabled: true
        termination: edge
        insecureEdgeTerminationPolicy: Redirect

OpenShift 이미지 풀 설정

인증이 필요한 내부 이미지 레지스트리를 OpenShift 클러스터에서 사용하는 경우:

이미지 풀 시크릿을 생성합니다:

kubectl create secret docker-registry wandb-registry-secret \
  --docker-server=registry.yourdomain.com \
  --docker-username=[USERNAME] \
  --docker-password=[PASSWORD] \
  --namespace=wandb

Custom Resource에서 시크릿을 레퍼런스합니다:

spec:
  values:
    imagePullSecrets:
      - name: wandb-registry-secret

OpenShift 전체 예시

다음 예시는 OpenShift 에어갭 배포를 위한 전체 CR 예시입니다:

이 예시의 모든 tag: 값은 1단계에서 내부 레지스트리로 전송한 실제 버전으로 바꾸세요. 여기에 표시된 버전은 예시이며 시간이 지나면 오래될 수 있습니다.

apiVersion: apps.wandb.com/v1
kind: WeightsAndBiases
metadata:
  name: wandb
  namespace: wandb

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

  values:
    global:
      host: https://wandb.apps.openshift.yourdomain.com
      license: [YOUR-LICENSE]
      
      bucket:
        accessKey: [YOUR-ACCESS-KEY]
        secretKey: [YOUR-SECRET-KEY]
        name: s3.yourdomain.com:9000
        path: wandb
        provider: s3
        region: us-east-1
      
      mysql:
        database: wandb
        host: mysql.yourdomain.com
        password: [YOUR-MYSQL-PASSWORD]
        port: 3306
        user: wandb
      
      redis:
        host: redis.yourdomain.com
        port: 6379
        password: [YOUR-REDIS-PASSWORD]

    # OpenShift 전용: Ingress 대신 Routes 사용
    ingress:
      enabled: false
    
    route:
      enabled: true
      host: wandb.apps.openshift.yourdomain.com
      tls:
        enabled: true
        termination: edge

    # 내부 레지스트리용 이미지 풀 시크릿
    imagePullSecrets:
      - name: wandb-registry-secret

    # OpenShift restricted SCC를 위한 보안 컨텍스트
    app:
      image:
        repository: registry.yourdomain.com/wandb/local
        tag: 0.59.2
      podSecurityContext:
        fsGroup: 1000
        runAsUser: 1000
        runAsNonRoot: true
      securityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop:
            - ALL
        runAsNonRoot: true
        seccompProfile:
          type: RuntimeDefault

    console:
      image:
        repository: registry.yourdomain.com/wandb/console
        tag: 2.12.2
      podSecurityContext:
        fsGroup: 1000
        runAsUser: 1000
        runAsNonRoot: true
      securityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop:
            - ALL
        runAsNonRoot: true
        seccompProfile:
          type: RuntimeDefault

    # api, executor, glue, parquet, weave에도 동일한 보안 컨텍스트 적용
    # (간결성을 위해 생략)

보안 요구 사항에 맞는 포괄적인 OpenShift 설정 예시가 필요하시면 W&B 지원팀 또는 배정된 W&B 지원 엔지니어에게 문의하세요.

설치를 확인하세요

W&B를 배포한 후 플랫폼에 연결할 수 있는지, 파드가 정상 상태인지, 그리고 배포가 내부 리소스만 사용하는지 확인할 수 있도록 설치가 제대로 작동하는지 확인하세요. 일반적인 확인 단계를 따른 다음, 다음 섹션의 추가 에어갭 점검을 완료하세요. 설치를 확인하려면 W&B에서는 W&B CLI 사용을 권장합니다. wandb 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

명령어가 실행된 후 설치에 성공하면 다음 출력이 표시됩니다:

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

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

추가 에어갭 검증

에어갭 배포의 경우 다음 사항도 확인하세요:

이미지 pull: 모든 파드가 내부 레지스트리에서 이미지를 성공적으로 pull했는지 확인합니다:
kubectl get pods -n wandb -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.phase}{"\t"}{.status.containerStatuses[*].image}{"\n"}{end}'
모든 이미지는 내부 레지스트리를 가리켜야 하며, 모든 파드는 Running 상태여야 합니다.
외부 연결: W&B가 외부 연결을 시도하지 않는지 확인합니다(에어갭 모드에서는 외부 연결을 시도하면 안 됩니다):
kubectl logs -n wandb deployment/wandb-app --tail=100 | grep -i "connection"
라이선스 검증: W&B 콘솔에 접속해 라이선스가 활성 상태인지 확인합니다.

문제 해결

이미지 pull 오류

파드가 이미지를 pull하지 못하면 다음을 확인하세요:

내부 레지스트리에 이미지가 있는지 확인하세요.
이미지 풀 시크릿이 올바르게 설정되었는지 확인하세요.
Kubernetes 노드에서 레지스트리까지의 네트워크 연결을 확인하세요.
레지스트리 인증 자격 증명을 확인하세요.

이미지 pull을 수동으로 테스트하려면:

kubectl run test-pull --image=registry.yourdomain.com/wandb/local:0.59.2 --namespace=wandb
kubectl logs test-pull -n wandb
kubectl delete pod test-pull -n wandb

OpenShift SCC 오류

OpenShift에서 파드가 권한 오류로 실행에 실패하는 경우:

# 사용 중인 SCC 확인
oc get pod [POD-NAME] -n wandb -o yaml | grep scc

# 서비스 계정 권한 확인
oc describe scc wandb-scc
oc get rolebinding -n wandb

Helm chart를 찾을 수 없음

Operator가 플랫폼 chart를 찾지 못하면 다음을 확인합니다:

Custom Resource의 chart 저장소 URL을 확인합니다.
Operator 파드가 내부 Helm 저장소에 접속할 수 있는지 확인합니다.
저장소에 chart가 있는지 확인합니다:
helm search repo local-repo/operator-wandb

자주 묻는 질문

다른 인그레스 클래스를 사용할 수 있나요?

예. Custom Resource의 인그레스 설정을 수정해 인그레스 클래스를 설정하세요.

spec:
  values:
    ingress:
      class: your-ingress-class

여러 인증서가 포함된 인증서 번들은 어떻게 처리하나요?

인증서를 customCACerts 섹션에서 여러 항목으로 나누세요:

spec:
  values:
    customCACerts:
      cert1.crt: |
        -----BEGIN CERTIFICATE-----
        ...
        -----END CERTIFICATE-----
      cert2.crt: |
        -----BEGIN CERTIFICATE-----
        ...
        -----END CERTIFICATE-----

자동 업데이트를 방지하려면 어떻게 해야 하나요?

W&B가 자동으로 업데이트되지 않도록 Operator를 구성하려면 다음을 수행하세요.

Operator 설치에서 airgapped: true를 설정합니다(이렇게 하면 자동 업데이트 확인이 비활성화됩니다).
Custom Resource에서 spec.chart.version을 수동으로 업데이트해 버전 업데이트를 제어합니다.
필요한 경우 W&B System Console에서 자동 업데이트를 비활성화합니다.

자세한 내용은 자동 앱 버전 업데이트 비활성화를 참조하세요.

W&B는 Self-Managed 인스턴스를 사용하는 고객에게 지원을 유지하고 최신 특성, 성능 개선, 수정 사항을 받기 위해 최소 분기마다 한 번 이상 배포를 최신 릴리스로 업데이트할 것을 강력히 권장합니다. W&B는 메이저 릴리스를 최초 릴리스 날짜로부터 12개월 동안 지원합니다. 자세한 내용은 릴리스 정책 및 프로세스를 참고하세요.

배포는 공개 리포지토리에 연결하지 않아도 작동하나요?

예. Operator 설정에 airgapped: true를 지정하면 Kubernetes Operator는 내부 리소스만 사용하고 공개 리포지토리에 연결을 시도하지 않습니다.

에어갭 환경에서 W&B를 어떻게 업데이트하나요?

W&B를 업데이트하려면 다음 단계를 따르세요.

인터넷에 연결된 시스템에서 새 컨테이너 이미지를 가져옵니다.
이미지를 에어갭 레지스트리로 전송합니다.
새 Helm chart를 내부 저장소에 업로드합니다.
Custom Resource에서 spec.chart.version 및 이미지 태그를 업데이트합니다.
업데이트된 Custom Resource를 적용합니다. Operator가 W&B 컴포넌트에 대해 롤링 업데이트를 수행합니다.

다음 단계

배포를 성공적으로 완료한 후, 다음 작업을 완료하세요:

사용자 인증 구성: SSO 또는 기타 인증 방법을 설정합니다.
모니터링 설정: W&B 인스턴스와 인프라에 대한 모니터링을 구성합니다.
업데이트 계획 수립: Server upgrade process를 검토하고 업데이트 주기를 수립합니다.
백업 구성: MySQL 데이터베이스용 백업 절차를 수립합니다.
프로세스 문서화: 특정 에어갭 업데이트 절차를 위한 운영 절차서를 작성합니다.

도움 받기

배포 중 문제가 발생하면 다음을 확인하세요:

인프라 관련 지침은 레퍼런스 아키텍처를 검토하세요
설정 관련 세부 사항은 Operator guide에서 확인하세요
W&B 지원팀 또는 배정된 W&B 지원 엔지니어에게 문의하세요
OpenShift 관련 문제는 Red Hat OpenShift 문서를 참조하세요

​소개

​사전 요구 사항

​버전 요구사항

​SSL/TLS 요구 사항

​하드웨어 요구 사항

​MySQL 데이터베이스

​Redis

​객체 저장소

​에어갭 환경별 요구 사항

​에어갭 환경 준비

​Step 1: 내부 컨테이너 레지스트리 설정

​핵심 W&B 구성 요소 컨테이너

​종속성 컨테이너

​전체 이미지 목록 조회

​이미지를 에어갭 레지스트리로 전송

​Step 2: 내부 Helm 차트 저장소 설정

​step 3: Helm 저장소 접근 설정

​에어갭 환경에서 W&B 배포

​Step 4: Kubernetes Operator 설치

​Step 5: MySQL 데이터베이스 설정

​6단계: W&B Custom Resource 설정

​7단계: W&B Platform 배포

​OpenShift 설정

​OpenShift 보안 컨텍스트 제약 조건

​옵션 1: restricted SCC 사용(권장)

​옵션 2: 맞춤형 SCC 만들기(필요한 경우)

​OpenShift Routes

​OpenShift 이미지 풀 설정

​OpenShift 전체 예시

​설치를 확인하세요

​추가 에어갭 검증

​문제 해결

​이미지 pull 오류

​OpenShift SCC 오류

​Helm chart를 찾을 수 없음

​자주 묻는 질문

​다른 인그레스 클래스를 사용할 수 있나요?

​여러 인증서가 포함된 인증서 번들은 어떻게 처리하나요?

​자동 업데이트를 방지하려면 어떻게 해야 하나요?

​배포는 공개 리포지토리에 연결하지 않아도 작동하나요?

​에어갭 환경에서 W&B를 어떻게 업데이트하나요?

​다음 단계

​도움 받기

소개

사전 요구 사항

버전 요구사항

SSL/TLS 요구 사항

하드웨어 요구 사항

MySQL 데이터베이스

Redis

객체 저장소

에어갭 환경별 요구 사항

에어갭 환경 준비

Step 1: 내부 컨테이너 레지스트리 설정

핵심 W&B 구성 요소 컨테이너

종속성 컨테이너

전체 이미지 목록 조회

이미지를 에어갭 레지스트리로 전송

Step 2: 내부 Helm 차트 저장소 설정

step 3: Helm 저장소 접근 설정

에어갭 환경에서 W&B 배포

Step 4: Kubernetes Operator 설치

Step 5: MySQL 데이터베이스 설정

6단계: W&B Custom Resource 설정

7단계: W&B Platform 배포

OpenShift 설정

OpenShift 보안 컨텍스트 제약 조건

옵션 1: restricted SCC 사용(권장)

옵션 2: 맞춤형 SCC 만들기(필요한 경우)

OpenShift Routes

OpenShift 이미지 풀 설정

OpenShift 전체 예시

설치를 확인하세요

추가 에어갭 검증

문제 해결

이미지 pull 오류

OpenShift SCC 오류

Helm chart를 찾을 수 없음

자주 묻는 질문

다른 인그레스 클래스를 사용할 수 있나요?

여러 인증서가 포함된 인증서 번들은 어떻게 처리하나요?

자동 업데이트를 방지하려면 어떻게 해야 하나요?

배포는 공개 리포지토리에 연결하지 않아도 작동하나요?

에어갭 환경에서 W&B를 어떻게 업데이트하나요?

다음 단계

도움 받기