W&B Platform

• 1: Deployment options
• 1.1: Use W&B Multi-tenant SaaS
• 1.2: Dedicated Cloud
• 1.2.1: Supported Dedicated Cloud regions
• 1.2.2: Export data from Dedicated cloud
• 1.3: Self-managed
• 1.3.1: Reference Architecture
• 1.3.2: Run W&B Server on Kubernetes
• 1.3.2.1: Kubernetes operator for air-gapped instances
• 1.3.3: Install on public cloud
• 1.3.3.1: Deploy W&B Platform on AWS
• 1.3.3.2: Deploy W&B Platform on GCP
• 1.3.3.3: Deploy W&B Platform on Azure
• 1.3.4: Deploy W&B Platform On-premises
• 1.3.5: Update W&B license and version
• 2: Identity and access management (IAM)
• 2.1: Authentication
• 2.1.1: Configure SSO with LDAP
• 2.1.2: Configure SSO with OIDC
• 2.1.3: Use federated identities with SDK
• 2.1.4: Use service accounts to automate workflows
• 2.2: Access management
• 2.2.1: Manage your organization
• 2.2.2: Manage access control for projects
• 2.3: Automate user and team management
• 2.4: Manage users, groups, and roles with SCIM
• 2.5: Advanced IAM configuration
• 3: Data security
• 3.1: Bring your own bucket (BYOB)
• 3.2: Access BYOB using pre-signed URLs
• 3.3: Configure IP allowlisting for Dedicated Cloud
• 3.4: Configure private connectivity to Dedicated Cloud
• 3.5: Data encryption in Dedicated cloud
• 4: Configure privacy settings
• 5: Monitoring and usage
• 5.1: Track user activity with audit logs
• 5.2: Use Prometheus monitoring
• 5.3: Configure Slack alerts
• 5.4: View organization dashboard
• 6: Configure SMTP
• 7: Configure environment variables
• 8: Release process for W&B Server

1 - Deployment options

1.1 - Use W&B Multi-tenant SaaS

W&B Multi-tenant Cloud는 W&B의 Google Cloud Platform (GCP) 계정의 GPC의 북미 지역에 배포된 완전 관리형 플랫폼입니다. W&B Multi-tenant Cloud는 트래픽 증가 또는 감소에 따라 플랫폼이 적절하게 확장되도록 GCP에서 자동 확장을 활용합니다.

데이터 보안

엔터프라이즈 플랜 사용자가 아닌 경우 모든 데이터는 공유 클라우드 스토리지에만 저장되고 공유 클라우드 컴퓨팅 서비스로 처리됩니다. 요금제에 따라 스토리지 제한이 적용될 수 있습니다.

엔터프라이즈 플랜 사용자는 보안 스토리지 커넥터를 사용하여 자체 버킷(BYOB)을 가져올 수 있습니다 팀 레벨에서 모델, 데이터셋 등과 같은 파일을 저장할 수 있습니다. 여러 팀에 대해 단일 버킷을 구성하거나 여러 W&B Teams에 대해 별도의 버킷을 사용할 수 있습니다. 팀에 대해 보안 스토리지 커넥터를 구성하지 않으면 해당 데이터는 공유 클라우드 스토리지에 저장됩니다.

ID 및 엑세스 관리 (IAM)

엔터프라이즈 플랜을 사용하는 경우 W&B 조직에서 안전한 인증 및 효과적인 권한 부여를 위해 ID 및 엑세스 관리 기능을 사용할 수 있습니다. Multi-tenant Cloud의 IAM에 사용할 수 있는 기능은 다음과 같습니다.

• OIDC 또는 SAML을 사용한 SSO 인증. 조직에 대해 SSO를 구성하려면 W&B 팀 또는 지원팀에 문의하세요.
• 조직 범위 내에서 그리고 팀 내에서 적절한 user 역할을 구성합니다.
• W&B project의 범위를 정의하여 누가 W&B runs를 보고, 편집하고, 제출할 수 있는지 제한된 projects으로 제한합니다.

모니터링

Organization 관리자는 계정 보기의 Billing 탭에서 계정 사용량 및 청구를 관리할 수 있습니다. Multi-tenant Cloud에서 공유 클라우드 스토리지를 사용하는 경우 관리자는 조직의 여러 팀에서 스토리지 사용량을 최적화할 수 있습니다.

유지 관리

W&B Multi-tenant Cloud는 멀티 테넌트, 완전 관리형 플랫폼입니다. W&B Multi-tenant Cloud는 W&B에서 관리하므로 W&B 플랫폼을 프로비저닝하고 유지 관리하는 오버헤드 및 비용이 발생하지 않습니다.

규정 준수

Multi-tenant Cloud에 대한 보안 제어는 내부 및 외부에서 주기적으로 감사됩니다. SOC2 보고서 및 기타 보안 및 규정 준수 문서를 요청하려면 W&B Security Portal를 참조하세요.

다음 단계

엔터프라이즈 기능이 필요하지 않은 경우 Multi-tenant Cloud에 직접 엑세스하세요. 엔터프라이즈 플랜을 시작하려면 이 양식을 제출하세요.

1.2 - Dedicated Cloud

전용 클라우드 (싱글 테넌트 SaaS) 사용

W&B 전용 클라우드는 W&B의 AWS, GCP 또는 Azure 클라우드 계정에 배포된 싱글 테넌트, 완전 관리형 플랫폼입니다. 각 전용 클라우드 인스턴스는 다른 W&B 전용 클라우드 인스턴스와 격리된 자체 네트워크, 컴퓨팅 및 스토리지를 가지고 있습니다. W&B 특정 메타데이터 및 데이터는 격리된 클라우드 스토리지에 저장되고 격리된 클라우드 컴퓨팅 서비스를 사용하여 처리됩니다.

W&B 전용 클라우드는 각 클라우드 공급자에 대해 여러 글로벌 지역에서 사용 가능합니다.

데이터 보안

보안 스토리지 커넥터를 사용하여 모델, 데이터셋 등과 같은 파일을 저장하기 위해 인스턴스 및 Teams 수준에서 자체 버킷(BYOB)을 가져올 수 있습니다.

W&B 멀티 테넌트 클라우드와 유사하게 여러 Teams에 대해 단일 버킷을 구성하거나 다른 Teams에 대해 별도의 버킷을 사용할 수 있습니다. Team에 대해 보안 스토리지 커넥터를 구성하지 않으면 해당 데이터는 인스턴스 수준 버킷에 저장됩니다.

보안 스토리지 커넥터를 사용한 BYOB 외에도 IP 허용 목록을 활용하여 신뢰할 수 있는 네트워크 위치에서만 전용 클라우드 인스턴스에 대한 엑세스를 제한할 수 있습니다.

클라우드 공급자의 보안 연결 솔루션을 사용하여 전용 클라우드 인스턴스에 비공개로 연결할 수도 있습니다.

ID 및 엑세스 관리 (IAM)

W&B Organization에서 보안 인증 및 효과적인 권한 부여를 위해 ID 및 엑세스 관리 기능을 사용하십시오. 전용 클라우드 인스턴스의 IAM에 사용할 수 있는 기능은 다음과 같습니다.

• OpenID Connect (OIDC)를 사용하는 SSO 또는 LDAP를 사용하여 인증합니다.
• 조직 범위 및 Team 내에서 적절한 User 역할 구성합니다.
• W&B project의 범위를 정의하여 제한된 Projects를 통해 누가 W&B runs를 보고, 편집하고, 제출할 수 있는지 제한합니다.
• ID 페더레이션으로 JSON 웹 토큰을 활용하여 W&B API에 엑세스합니다.

모니터링

감사 로그를 사용하여 Team 내의 User 활동을 추적하고 엔터프라이즈 거버넌스 요구 사항을 준수하십시오. 또한 W&B Organization 대시보드에서 전용 클라우드 인스턴스의 조직 사용량을 볼 수 있습니다.

유지 관리

W&B 멀티 테넌트 클라우드와 유사하게 전용 클라우드를 사용하면 W&B 플랫폼을 프로비저닝하고 유지 관리하는 오버헤드 및 비용이 발생하지 않습니다.

W&B가 전용 클라우드에서 업데이트를 관리하는 방법을 이해하려면 서버 릴리스 프로세스를 참조하십시오.

규정 준수

W&B 전용 클라우드에 대한 보안 제어는 내부 및 외부에서 주기적으로 감사됩니다. 제품 평가를 위한 보안 및 규정 준수 문서를 요청하려면 W&B 보안 포털을 참조하십시오.

마이그레이션 옵션

자체 관리 인스턴스 또는 멀티 테넌트 클라우드에서 전용 클라우드로의 마이그레이션이 지원됩니다.

다음 단계

전용 클라우드 사용에 관심이 있으시면 이 양식을 제출하십시오.

1.2.1 - Supported Dedicated Cloud regions

AWS, GCP, 및 Azure는 전 세계 여러 위치에서 클라우드 컴퓨팅 서비스를 지원합니다. 글로벌 리전은 데이터 상주 및 규정 준수, 지연 시간, 비용 효율성 등과 관련된 요구 사항을 충족하는 데 도움이 됩니다. W&B는 전용 클라우드에 사용 가능한 여러 글로벌 리전을 지원합니다.

지원되는 AWS 리전

다음 표는 W&B가 현재 전용 클라우드 인스턴스에 대해 지원하는 AWS 리전을 나열합니다.

AWS 리전에 대한 자세한 내용은 AWS 설명서의 리전, 가용 영역 및 로컬 영역을 참조하십시오.

AWS 리전을 선택할 때 고려해야 할 요소에 대한 개요는 작업에 적합한 리전 선택 시 고려 사항을 참조하십시오.

지원되는 GCP 리전

다음 표는 W&B가 현재 전용 클라우드 인스턴스에 대해 지원하는 GCP 리전을 나열합니다.

GCP 리전에 대한 자세한 내용은 GCP 설명서의 리전 및 영역을 참조하십시오.

지원되는 Azure 리전

다음 표는 W&B가 현재 전용 클라우드 인스턴스에 대해 지원하는 Azure 리전을 나열합니다.

Azure 리전에 대한 자세한 내용은 Azure 설명서의 Azure 지역을 참조하십시오.

1.2.2 - Export data from Dedicated cloud

전용 클라우드 인스턴스에서 관리하는 모든 데이터를 내보내려면 W&B SDK API를 사용하여 Import and Export API로 run, 메트릭, Artifacts 등을 추출할 수 있습니다. 다음 표는 주요 내보내기 유스 케이스를 다룹니다.

Secure Storage Connector를 사용하여 전용 클라우드에 저장된 Artifacts를 관리하는 경우 W&B SDK API를 사용하여 Artifacts를 내보낼 필요가 없을 수 있습니다.

1.3 - Self-managed

자체 관리형 클라우드 또는 온-프레미스 인프라 사용

AWS, GCP 또는 Azure 클라우드 계정 또는 온-프레미스 인프라 내에 W&B Server를 배포합니다.

IT/DevOps/MLOps 팀은 배포 프로비저닝, 업그레이드 관리 및 자체 관리형 W&B Server 인스턴스의 지속적인 유지 관리를 담당합니다.

자체 관리형 클라우드 계정 내에 W&B Server 배포

W&B는 공식 W&B Terraform 스크립트를 사용하여 AWS, GCP 또는 Azure 클라우드 계정에 W&B Server를 배포할 것을 권장합니다.

AWS, GCP 또는 Azure에서 W&B Server를 설정하는 방법에 대한 자세한 내용은 특정 클라우드 공급자 문서를 참조하세요.

온-프레미스 인프라에 W&B Server 배포

온-프레미스 인프라에서 W&B Server를 설정하려면 여러 인프라 구성 요소를 구성해야 합니다. 이러한 구성 요소에는 다음이 포함되지만 이에 국한되지는 않습니다.

• (강력 권장) Kubernetes 클러스터
• MySQL 8 데이터베이스 클러스터
• Amazon S3 호환 오브젝트 스토리지
• Redis 캐시 클러스터

온-프레미스 인프라에 W&B Server를 설치하는 방법에 대한 자세한 내용은 온-프레미스 인프라에 설치를 참조하세요. W&B는 다양한 구성 요소에 대한 권장 사항을 제공하고 설치 프로세스에 대한 지침을 제공할 수 있습니다.

사용자 지정 클라우드 플랫폼에 W&B Server 배포

AWS, GCP 또는 Azure가 아닌 클라우드 플랫폼에 W&B Server를 배포할 수 있습니다. 이에 대한 요구 사항은 온-프레미스 인프라에 배포하는 것과 유사합니다.

W&B Server 라이선스 받기

W&B 서버 설정을 완료하려면 W&B 트라이얼 라이선스가 필요합니다. Deploy Manager를 열어 무료 트라이얼 라이선스를 생성하세요.

URL은 W&B Local용 라이선스 받기 양식으로 리디렉션됩니다. 다음 정보를 제공하세요.

1. 플랫폼 선택 단계에서 배포 유형을 선택합니다.
2. 기본 정보 단계에서 라이선스 소유자를 선택하거나 새 조직을 추가합니다.
3. 라이선스 받기 단계의 인스턴스 이름 필드에 인스턴스 이름을 제공하고 필요에 따라 설명 필드에 설명을 제공합니다.
4. 라이선스 키 생성 버튼을 선택합니다.

인스턴스와 연결된 라이선스와 함께 배포 개요가 있는 페이지가 표시됩니다.

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

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

1.3.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는 내부 리소스만 사용하고 퍼블릭 저장소에 연결을 시도하지 않습니다.

1.3.3 - Install on public cloud

1.3.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 구성으로 원활하게 전환할 수 있습니다.

1.3.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. 구성을 업데이트한 후 배포 옵션 섹션에 설명된 단계를 완료합니다.

1.3.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은 표준 옵션과 권장 배포에서 찾을 수 있는 최소 구성과 함께 결합할 수 있는 여러 옵션을 제공합니다.

1.3.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 지원팀에 문의하십시오.

1.3.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. 새 라이선스 키를 입력하고 변경 사항을 저장합니다.

2 - Identity and access management (IAM)

W&B 플랫폼은 W&B 내에 세 가지 IAM 범위, 즉 Organizations, Teams 및 Projects를 가지고 있습니다.

Organization

Organization 은 W&B 계정 또는 인스턴스의 루트 범위입니다. 계정 또는 인스턴스의 모든 작업은 사용자 관리, 팀 관리, 팀 내 프로젝트 관리, 사용량 추적 등을 포함하여 해당 루트 범위 내에서 수행됩니다.

Multi-tenant Cloud를 사용하는 경우, 각 Organization은 사업부, 개인 사용자, 다른 기업과의 합작 파트너십 등에 해당할 수 있습니다.

전용 클라우드(Dedicated Cloud) 또는 자체 관리 인스턴스를 사용하는 경우, 하나의 Organization에 해당합니다. 회사는 여러 사업부 또는 부서에 매핑하기 위해 여러 개의 전용 클라우드(Dedicated Cloud) 또는 자체 관리 인스턴스를 가질 수 있지만, 이는 사업 또는 부서 전체에서 AI 실무자를 관리하는 선택적인 방법입니다.

자세한 내용은 Organizations 관리를 참조하십시오.

Team

Team 은 Organization 내의 하위 범위로, 사업부/기능, 부서 또는 회사 내 프로젝트 팀에 매핑될 수 있습니다. 배포 유형 및 가격 계획에 따라 Organization 내에 여러 개의 Team이 있을 수 있습니다.

AI 프로젝트는 Team 컨텍스트 내에서 구성됩니다. Team 내의 엑세스 제어는 Team 관리자가 관리하며, 이들은 상위 Organization 수준의 관리자일 수도 아닐 수도 있습니다.

자세한 내용은 Team 추가 및 관리를 참조하십시오.

Project

Project 는 Team 내의 하위 범위로, 특정 의도된 결과를 가진 실제 AI 프로젝트에 매핑됩니다. Team 내에 여러 개의 Project가 있을 수 있습니다. 각 Project에는 누가 엑세스할 수 있는지 결정하는 가시성 모드가 있습니다.

모든 Project는 Workspaces 및 Reports로 구성되며, 관련 Artifacts, Sweeps 및 Automations에 연결됩니다.

2.1 - Authentication

2.1.1 - Configure SSO with LDAP

W&B 서버 LDAP 서버로 인증 정보를 인증합니다. 다음 가이드는 W&B 서버의 설정을 구성하는 방법을 설명합니다. 필수 및 선택적 설정과 시스템 설정 UI에서 LDAP 연결을 구성하는 방법에 대한 지침을 다룹니다. 또한 어드레스, 기본 식별 이름, 속성과 같은 LDAP 설정의 다양한 입력에 대한 정보를 제공합니다. 이러한 속성은 W&B 앱 UI 또는 환경 변수를 사용하여 지정할 수 있습니다. 익명 바인딩 또는 관리자 DN 및 비밀번호를 사용하여 바인딩을 설정할 수 있습니다.

LDAP 연결 구성

• W&B App
• Environment variable

설정 파라미터

다음 표는 필수 및 선택적 LDAP 설정을 나열하고 설명합니다.

2.1.2 - Configure SSO with OIDC

Weights & Biases 서버는 OpenID Connect (OIDC) 호환 ID 공급자를 지원하므로 Okta, Keycloak, Auth0, Google, Entra와 같은 외부 ID 공급자를 통해 사용자 ID 및 그룹 멤버십을 관리할 수 있습니다.

OpenID Connect (OIDC)

W&B 서버는 외부 IdP(Identity Provider)와 통합하기 위해 다음과 같은 OIDC 인증 흐름을 지원합니다.

1. Form Post를 사용하는 암시적 흐름
2. PKCE(Proof Key for Code Exchange)를 사용하는 Authorization Code 흐름

이러한 흐름은 사용자를 인증하고 엑세스 제어를 관리하는 데 필요한 ID 정보(ID 토큰 형태)를 W&B 서버에 제공합니다.

ID 토큰은 이름, 사용자 이름, 이메일, 그룹 멤버십과 같은 사용자 ID 정보가 포함된 JWT입니다. W&B 서버는 이 토큰을 사용하여 사용자를 인증하고 시스템 내 적절한 역할 또는 그룹에 매핑합니다.

W&B 서버의 맥락에서 엑세스 토큰은 사용자를 대신하여 API에 대한 요청을 승인하지만 W&B 서버의 주요 관심사는 사용자 인증 및 ID이므로 ID 토큰만 필요합니다.

환경 변수를 사용하여 IAM 옵션 구성을 전용 클라우드 또는 자체 관리형 인스턴스에 설정할 수 있습니다.

전용 클라우드 또는 자체 관리형 W&B 서버 설치를 위해 ID 공급자를 구성하는 데 도움이 되도록 다양한 IdP에 대한 다음 가이드라인을 따르세요. SaaS 버전의 W&B를 사용하는 경우 조직의 Auth0 테넌트 구성에 대한 지원은 support@wandb.com으로 문의하세요.

• Cognito
• Okta
• Entra

W&B 서버에서 SSO 설정

SSO를 설정하려면 관리자 권한과 다음 정보가 필요합니다.

• OIDC 클라이언트 ID
• OIDC 인증 방법(implicit 또는 pkce)
• OIDC 발급자 URL
• OIDC 클라이언트 암호(선택 사항, IdP 설정 방법에 따라 다름)

W&B 서버 UI를 사용하거나 환경 변수를 wandb/local 포드로 전달하여 SSO를 구성할 수 있습니다. 환경 변수가 UI보다 우선합니다.

• System Console
• System settings

시스템 콘솔은 시스템 설정 페이지의 후속 버전입니다. W&B Kubernetes Operator 기반 배포에서 사용할 수 있습니다.

1. W&B 관리 콘솔 엑세스를 참조하세요.

2. 설정으로 이동한 다음 인증으로 이동합니다. 유형 드롭다운에서 OIDC를 선택합니다.

3. 값을 입력합니다.

4. 저장을 클릭합니다.

5. 로그아웃한 다음 다시 로그인합니다. 이번에는 IdP 로그인 화면을 사용합니다.

1. Weights & Biases 인스턴스에 로그인합니다.

2. W&B 앱으로 이동합니다.

   

3. 드롭다운에서 시스템 설정을 선택합니다.

   

4. 발급자, 클라이언트 ID 및 인증 방법을 입력합니다.

5. 설정 업데이트를 선택합니다.

SAML(Security Assertion Markup Language)

W&B 서버는 SAML을 지원하지 않습니다.

2.1.3 - Use federated identities with SDK

W&B SDK를 통해 조직의 자격 증명을 사용하여 로그인하려면 아이덴티티 연동을 사용하세요. W&B 조직 관리자가 조직에 대해 SSO를 구성한 경우, 이미 조직의 자격 증명을 사용하여 W&B 앱 UI에 로그인하고 있을 것입니다. 이러한 의미에서 아이덴티티 연동은 W&B SDK에 대한 SSO와 유사하지만 JSON Web Tokens (JWTs)를 직접 사용한다는 차이점이 있습니다. API 키 대신 아이덴티티 연동을 사용할 수 있습니다.

RFC 7523은 SDK와의 아이덴티티 연동의 기본 토대를 형성합니다.

JWT 발급자 설정

첫 번째 단계로 조직 관리자는 W&B 조직과 공개적으로 엑세스 가능한 JWT 발급자 간의 연동을 설정해야 합니다.

• 조직 대시보드에서 설정 탭으로 이동합니다.
• 인증 옵션에서 JWT 발급자 설정을 누릅니다.
• 텍스트 상자에 JWT 발급자 URL을 추가하고 만들기를 누릅니다.

W&B는 자동으로 ${ISSUER_URL}/.well-known/oidc-configuration 경로에서 OIDC 검색 문서를 찾고 검색 문서의 관련 URL에서 JSON Web Key Set (JWKS)을 찾으려고 시도합니다. JWKS는 JWT가 관련 아이덴티티 공급자에 의해 발급되었는지 확인하기 위해 JWT의 실시간 유효성 검사에 사용됩니다.

JWT를 사용하여 W&B에 엑세스

W&B 조직에 대해 JWT 발급자가 설정되면 사용자는 해당 아이덴티티 공급자가 발급한 JWT를 사용하여 관련 W&B 프로젝트에 엑세스할 수 있습니다. JWT를 사용하는 메커니즘은 다음과 같습니다.

• 조직에서 사용할 수 있는 메커니즘 중 하나를 사용하여 아이덴티티 공급자에 로그인해야 합니다. 일부 공급자는 API 또는 SDK를 사용하여 자동화된 방식으로 엑세스할 수 있지만 일부는 관련 UI를 사용해야만 엑세스할 수 있습니다. 자세한 내용은 W&B 조직 관리자 또는 JWT 발급자 소유자에게 문의하세요.
• 아이덴티티 공급자에 로그인한 후 JWT를 검색했으면 안전한 위치의 파일에 저장하고 환경 변수 WANDB_IDENTITY_TOKEN_FILE에 절대 파일 경로를 구성합니다.
• W&B SDK 또는 CLI를 사용하여 W&B 프로젝트에 엑세스합니다. SDK 또는 CLI는 JWT를 자동으로 감지하고 JWT가 성공적으로 유효성 검사된 후 W&B 엑세스 토큰으로 교환해야 합니다. W&B 엑세스 토큰은 AI 워크플로우를 활성화하기 위한 관련 API에 엑세스하는 데 사용됩니다. 즉, run, 메트릭, Artifacts 등을 로그합니다. 엑세스 토큰은 기본적으로 ~/.config/wandb/credentials.json 경로에 저장됩니다. 환경 변수 WANDB_CREDENTIALS_FILE을 지정하여 해당 경로를 변경할 수 있습니다.

JWT 유효성 검사

JWT를 W&B 엑세스 토큰으로 교환한 다음 프로젝트에 엑세스하는 워크플로우의 일부로 JWT는 다음 유효성 검사를 거칩니다.

• JWT 서명은 W&B 조직 수준에서 JWKS를 사용하여 확인됩니다. 이것이 첫 번째 방어선이며, 실패하면 JWKS 또는 JWT 서명 방식에 문제가 있음을 의미합니다.
• JWT의 iss 클레임은 조직 수준에서 구성된 발급자 URL과 같아야 합니다.
• JWT의 sub 클레임은 W&B 조직에 구성된 사용자의 이메일 주소와 같아야 합니다.
• JWT의 aud 클레임은 AI 워크플로우의 일부로 엑세스하는 프로젝트를 수용하는 W&B 조직의 이름과 같아야 합니다. 전용 클라우드 또는 자체 관리 인스턴스의 경우 인스턴스 수준 환경 변수 SKIP_AUDIENCE_VALIDATION을 true로 구성하여 대상 클레임의 유효성 검사를 건너뛰거나 wandb를 대상으로 사용할 수 있습니다.
• JWT의 exp 클레임은 토큰이 유효한지 또는 만료되었는지 확인하기 위해 검사되며 갱신해야 합니다.

외부 서비스 계정

W&B는 오랫동안 오래 지속되는 API 키가 있는 기본 제공 서비스 계정을 지원해 왔습니다. SDK 및 CLI에 대한 아이덴티티 연동 기능을 사용하면 조직 수준에서 구성된 동일한 발급자가 발급한 경우 JWT를 인증에 사용할 수 있는 외부 서비스 계정을 가져올 수도 있습니다. 팀 관리자는 기본 제공 서비스 계정과 마찬가지로 팀 범위 내에서 외부 서비스 계정을 구성할 수 있습니다.

외부 서비스 계정을 구성하려면:

• 팀의 서비스 계정 탭으로 이동합니다.
• 새 서비스 계정을 누릅니다.
• 서비스 계정 이름을 제공하고 인증 방법으로 Federated Identity를 선택하고 Subject를 제공하고 만들기를 누릅니다.

외부 서비스 계정의 sub 클레임은 팀 관리자가 팀 수준 서비스 계정 탭에서 해당 제목으로 구성한 것과 동일해야 합니다. 해당 클레임은 JWT 유효성 검사의 일부로 확인됩니다. aud 클레임 요구 사항은 인간 사용자 JWT의 요구 사항과 유사합니다.

외부 서비스 계정의 JWT를 사용하여 W&B에 엑세스할 때 초기 JWT를 생성하고 지속적으로 갱신하는 워크플로우를 자동화하는 것이 일반적으로 더 쉽습니다. 외부 서비스 계정을 사용하여 기록된 run을 인간 사용자에게 귀속시키려면 기본 제공 서비스 계정에 대해 수행되는 방식과 유사하게 AI 워크플로우에 대해 환경 변수 WANDB_USERNAME 또는 WANDB_USER_EMAIL을 구성할 수 있습니다.

2.1.4 - Use service accounts to automate workflows

서비스 계정은 팀 내 또는 팀 간의 프로젝트에서 일반적인 작업을 자동으로 수행할 수 있는 비인간 또는 머신 사용자를 나타냅니다.

• 조직 관리자는 조직 범위에서 서비스 계정을 만들 수 있습니다.
• 팀 관리자는 해당 팀 범위에서 서비스 계정을 만들 수 있습니다.

서비스 계정의 API 키를 통해 호출자는 서비스 계정 범위 내에서 프로젝트를 읽거나 쓸 수 있습니다.

서비스 계정을 사용하면 여러 사용자 또는 팀에서 워크플로우를 중앙 집중식으로 관리하고, W&B Models에 대한 실험 트래킹을 자동화하거나, W&B Weave에 대한 추적을 기록할 수 있습니다. 환경 변수 WANDB_USERNAME 또는 WANDB_USER_EMAIL을 사용하여 서비스 계정에서 관리하는 워크플로우와 인간 사용자의 ID를 연결할 수 있습니다.

조직 범위 서비스 계정

조직 범위의 서비스 계정은 제한된 프로젝트를 제외하고 팀에 관계없이 조직의 모든 프로젝트에서 읽고 쓸 수 있는 권한을 갖습니다. 조직 범위의 서비스 계정이 제한된 프로젝트에 엑세스하려면 해당 프로젝트의 관리자가 서비스 계정을 프로젝트에 명시적으로 추가해야 합니다.

조직 관리자는 조직 또는 계정 대시보드의 Service Accounts 탭에서 조직 범위의 서비스 계정에 대한 API 키를 얻을 수 있습니다.

새로운 조직 범위의 서비스 계정을 만들려면:

• 조직 대시보드의 Service Accounts 탭에서 New service account 버튼을 클릭합니다.
• Name을 입력합니다.
• 서비스 계정의 기본 팀을 선택합니다.
• Create를 클릭합니다.
• 새로 생성된 서비스 계정 옆에 있는 Copy API key를 클릭합니다.
• 복사한 API 키를 비밀 관리자 또는 안전하지만 엑세스 가능한 다른 위치에 저장합니다.

팀 범위 서비스 계정

팀 범위의 서비스 계정은 해당 팀의 제한된 프로젝트를 제외하고 팀 내의 모든 프로젝트에서 읽고 쓸 수 있습니다. 팀 범위의 서비스 계정이 제한된 프로젝트에 엑세스하려면 해당 프로젝트의 관리자가 서비스 계정을 프로젝트에 명시적으로 추가해야 합니다.

팀 관리자는 팀의 <WANDB_HOST_URL>/<your-team-name>/service-accounts에서 팀 범위의 서비스 계정에 대한 API 키를 얻을 수 있습니다. 또는 팀의 Team settings로 이동한 다음 Service Accounts 탭을 참조할 수 있습니다.

팀의 새로운 팀 범위 서비스 계정을 만들려면:

• 팀의 Service Accounts 탭에서 New service account 버튼을 클릭합니다.
• Name을 입력합니다.
• 인증 방법으로 **Generate API key (Built-in)**을 선택합니다.
• Create를 클릭합니다.
• 새로 생성된 서비스 계정 옆에 있는 Copy API key를 클릭합니다.
• 복사한 API 키를 비밀 관리자 또는 안전하지만 엑세스 가능한 다른 위치에 저장합니다.

팀 범위의 서비스 계정을 사용하는 모델 트레이닝 또는 생성적 AI 앱 환경에서 팀을 구성하지 않으면 모델 run 또는 weave 추적이 서비스 계정의 상위 팀 내에서 명명된 프로젝트에 기록됩니다. 이러한 시나리오에서 WANDB_USERNAME 또는 WANDB_USER_EMAIL 변수를 사용한 사용자 속성은 참조된 사용자가 서비스 계정의 상위 팀에 속하지 않는 한 작동하지 않습니다.

외부 서비스 계정

Built-in 서비스 계정 외에도 W&B는 JSON 웹 토큰(JWT)을 발급할 수 있는 ID 공급자(IdP)와 함께 Identity federation를 사용하여 W&B SDK 및 CLI를 통해 팀 범위의 External service accounts를 지원합니다.

2.2 - Access management

조직 내에서 사용자 및 팀 관리하기

고유한 조직 도메인으로 W&B에 처음 가입하는 사용자는 해당 조직의 인스턴스 관리자 역할로 지정됩니다. 조직 관리자는 특정 사용자에게 팀 관리자 역할을 할당합니다.

팀 관리자는 팀 내에서 관리 권한을 가진 조직의 사용자입니다.

조직 관리자는 https://wandb.ai/account-settings/에서 조직의 계정 설정을 엑세스하고 사용하여 사용자를 초대하고, 사용자의 역할을 할당하거나 업데이트하고, 팀을 만들고, 조직에서 사용자를 제거하고, 청구 관리자를 할당하는 등의 작업을 수행할 수 있습니다. 자세한 내용은 사용자 추가 및 관리를 참조하세요.

조직 관리자가 팀을 생성하면 인스턴스 관리자 또는 팀 관리자는 다음을 수행할 수 있습니다.

• 기본적으로 관리자만 해당 팀에 사용자를 초대하거나 팀에서 사용자를 제거할 수 있습니다. 이 행동 을 변경하려면 팀 설정을 참조하세요.
• 팀 멤버의 역할을 할당하거나 업데이트합니다.
• 새 사용자가 조직에 가입할 때 자동으로 팀에 추가합니다.

조직 관리자와 팀 관리자는 모두 https://wandb.ai/<your-team-name>에서 팀 대시보드 를 사용하여 팀을 관리합니다. 자세한 내용과 팀의 기본 개인 정보 보호 설정을 구성하려면 팀 추가 및 관리를 참조하세요.

특정 Projects 에 대한 가시성 제한

W&B project 의 범위를 정의하여 누가 W&B runs 를 보고, 편집하고, 제출할 수 있는지 제한합니다. 팀이 민감하거나 기밀 데이터를 다루는 경우 project 를 볼 수 있는 사람을 제한하는 것이 특히 유용합니다.

조직 관리자, 팀 관리자 또는 project 소유자는 project 의 가시성을 설정하고 편집할 수 있습니다.

자세한 내용은 Project visibility를 참조하세요.

2.2.1 - Manage your organization

Organizations의 관리자는 Organization 내에서 개별 사용자를 관리하고 Teams를 관리할 수 있습니다.

Team 관리자는 Teams를 관리할 수 있습니다.

Organization에서 사용자 관리를 간소화하려면 사용자 및 Team 관리 자동화를 참조하십시오.

Organization 이름 변경

1. https://wandb.ai/home 으로 이동합니다.
2. 페이지 오른쪽 상단에서 User menu 드롭다운을 선택합니다. 드롭다운의 Account 섹션에서 Settings를 선택합니다.
3. Settings 탭에서 General을 선택합니다.
4. Change name 버튼을 선택합니다.
5. 나타나는 모달에서 Organization의 새 이름을 입력하고 Save name 버튼을 선택합니다.

사용자 추가 및 관리

관리자는 Organization의 대시보드를 사용하여 다음을 수행할 수 있습니다.

• 사용자 초대 또는 제거
• 사용자의 Organization 역할 할당 또는 업데이트, 사용자 지정 역할 생성
• 결제 관리자 할당

Organization 관리자가 사용자를 Organization에 추가할 수 있는 방법은 여러 가지가 있습니다.

1. Member-by-invite
2. SSO를 사용한 자동 프로비저닝
3. 도메인 캡처

Seats 및 가격

다음 표는 Models 및 Weave의 Seats 작동 방식을 요약한 것입니다.

사용자 초대

관리자는 사용자를 Organization 내의 특정 Teams뿐만 아니라 Organization에 초대할 수 있습니다.

• Multi-tenant SaaS Cloud
• Dedicated or Self-managed

사용자 자동 프로비저닝

SSO를 구성하고 SSO 제공업체에서 허용하는 경우 일치하는 이메일 도메인을 가진 W&B 사용자는 Single Sign-On (SSO)으로 W&B Organization에 로그인할 수 있습니다. SSO는 모든 Enterprise 라이선스에서 사용할 수 있습니다.

W&B는 자동 프로비저닝 사용자에게 기본적으로 “Member” 역할을 할당합니다. 자동 프로비저닝 사용자의 역할은 언제든지 변경할 수 있습니다.

SSO를 통한 자동 프로비저닝 사용자는 Dedicated Cloud 인스턴스 및 Self-managed 배포에서 기본적으로 켜져 있습니다. 자동 프로비저닝을 끌 수 있습니다. 자동 프로비저닝을 끄면 특정 사용자를 W&B Organization에 선택적으로 추가할 수 있습니다.

다음 탭에서는 배포 유형에 따라 SSO를 끄는 방법을 설명합니다.

• Dedicated cloud
• Self-managed

사용자 지정 역할 만들기

Organization 관리자는 View-Only 또는 Member 역할을 기반으로 새 역할을 구성하고 세분화된 엑세스 제어를 위해 추가 권한을 추가할 수 있습니다. Team 관리자는 Team member에게 사용자 지정 역할을 할당할 수 있습니다. 사용자 지정 역할은 Organization 수준에서 생성되지만 Team 수준에서 할당됩니다.

사용자 지정 역할을 만들려면:

• Multi-tenant SaaS Cloud
• Dedicated or Self-managed

이제 Team 관리자는 Team 설정에서 Team의 구성원에게 사용자 지정 역할을 할당할 수 있습니다.

도메인 캡처

도메인 캡처는 직원이 회사 Organization에 가입하여 새 사용자가 회사 관할 구역 외부에서 에셋을 생성하지 않도록 하는 데 도움이 됩니다.

• Multi-tenant SaaS Cloud
• Dedicated or Self-managed

사용자의 역할 할당 또는 업데이트

Organization의 모든 구성원은 W&B Models 및 Weave 모두에 대한 Organization 역할과 Seat를 갖습니다. 그들이 가지고 있는 Seat 유형은 그들의 결제 상태와 각 제품 라인에서 그들이 할 수 있는 작업을 결정합니다.

사용자를 Organization에 초대할 때 처음으로 Organization 역할을 할당합니다. 나중에 사용자의 역할을 변경할 수 있습니다.

Organization 내의 사용자는 다음 역할 중 하나를 가질 수 있습니다.

사용자의 역할을 변경하려면:

1. https://wandb.ai/home 으로 이동합니다.
2. 페이지 오른쪽 상단에서 User menu 드롭다운을 선택합니다. 드롭다운에서 Users를 선택합니다.
3. 검색 창에 사용자의 이름 또는 이메일을 입력합니다.
4. 사용자 이름 옆에 있는 TEAM ROLE 드롭다운에서 역할을 선택합니다.

사용자 엑세스 할당 또는 업데이트

Organization 내의 사용자는 다음 Models Seat 또는 Weave 엑세스 유형 중 하나를 갖습니다. full, viewer 또는 no access.

Model Seat 유형 및 Weave 엑세스 유형은 Organization 수준에서 정의되며 Team에서 상속됩니다. 사용자의 Seat 유형을 변경하려면 Organization 설정으로 이동하여 다음 단계를 따르십시오.

1. SaaS 사용자의 경우 https://wandb.ai/account-settings/<organization>/settings에서 Organization 설정으로 이동합니다. 꺾쇠 괄호 (<>)로 묶인 값을 Organization 이름으로 바꿔야 합니다. 다른 Dedicated 및 Self-managed 배포의 경우 https://<your-instance>.wandb.io/org/dashboard로 이동합니다.
2. Users 탭을 선택합니다.
3. Role 드롭다운에서 사용자에게 할당할 Seat 유형을 선택합니다.

사용자 제거

1. https://wandb.ai/home 으로 이동합니다.
2. 페이지 오른쪽 상단에서 User menu 드롭다운을 선택합니다. 드롭다운에서 Users를 선택합니다.
3. 검색 창에 사용자의 이름 또는 이메일을 입력합니다.
4. 나타날 때 줄임표 또는 세 개의 점 아이콘 (…)을 선택합니다.
5. 드롭다운에서 Remove member를 선택합니다.

결제 관리자 할당

1. https://wandb.ai/home 으로 이동합니다.
2. 페이지 오른쪽 상단에서 User menu 드롭다운을 선택합니다. 드롭다운에서 Users를 선택합니다.
3. 검색 창에 사용자의 이름 또는 이메일을 입력합니다.
4. Billing admin 열에서 결제 관리자로 할당할 사용자를 선택합니다.

Teams 추가 및 관리

Organization 대시보드를 사용하여 Organization 내에서 Teams를 만들고 관리합니다. Organization 관리자 또는 Team 관리자는 다음을 수행할 수 있습니다.

• 사용자를 Team에 초대하거나 Team에서 사용자를 제거합니다.
• Team member의 역할을 관리합니다.
• 사용자가 Organization에 가입할 때 Team에 사용자를 자동으로 추가합니다.
• https://wandb.ai/<team-name>에서 Team의 대시보드를 사용하여 Team 스토리지를 관리합니다.

Team 만들기

Organization 대시보드를 사용하여 Team을 만듭니다.

1. https://wandb.ai/home 으로 이동합니다.
2. 왼쪽 네비게이션 패널의 Teams 아래에서 Create a team to collaborate를 선택합니다.
3. 나타나는 모달에서 Team name 필드에 Team 이름을 입력합니다.
4. 스토리지 유형을 선택합니다.
5. Create team 버튼을 선택합니다.

Create team 버튼을 선택하면 W&B에서 https://wandb.ai/<team-name>의 새 Team 페이지로 리디렉션합니다. 여기서 <team-name>은 Team을 만들 때 제공하는 이름으로 구성됩니다.

Team이 있으면 해당 Team에 사용자를 추가할 수 있습니다.

Team에 사용자 초대

Organization에서 Team에 사용자를 초대합니다. Team의 대시보드를 사용하여 이메일 주소 또는 W&B 사용자 이름(이미 W&B 계정이 있는 경우)을 사용하여 사용자를 초대합니다.

1. https://wandb.ai/<team-name>로 이동합니다.
2. 대시보드의 왼쪽 글로벌 네비게이션에서 Team settings를 선택합니다.
3. Users 탭을 선택합니다.
4. Invite a new user를 선택합니다.
5. 나타나는 모달에서 Email or username 필드에 사용자의 이메일을 입력하고 Select a team 역할 드롭다운에서 해당 사용자에게 할당할 역할을 선택합니다. 사용자가 Team에서 가질 수 있는 역할에 대한 자세한 내용은 Team 역할을 참조하십시오.
6. Send invite 버튼을 클릭합니다.

기본적으로 Team 또는 인스턴스 관리자만 Team에 구성원을 초대할 수 있습니다. 이 동작을 변경하려면 Team 설정을 참조하십시오.

이메일 초대를 통해 수동으로 사용자를 초대하는 것 외에도 새 사용자의 이메일이 Organization의 도메인과 일치하는 경우 새 사용자를 Team에 자동으로 추가할 수 있습니다.

가입 시 Team Organization에 구성원 일치

새 사용자가 가입할 때 Organization 내에서 Teams를 검색할 수 있도록 허용합니다. 새 사용자는 Organization의 확인된 이메일 도메인과 일치하는 확인된 이메일 도메인이 있어야 합니다. 확인된 새 사용자는 W&B 계정에 가입할 때 Organization에 속한 확인된 Teams 목록을 볼 수 있습니다.

Organization 관리자는 도메인 클레임을 활성화해야 합니다. 도메인 캡처를 활성화하려면 도메인 캡처에 설명된 단계를 참조하십시오.

Team member의 역할 할당 또는 업데이트

1. Team member 이름 옆에 있는 계정 유형 아이콘을 선택합니다.
2. 드롭다운에서 해당 Team member가 가질 계정 유형을 선택합니다.

다음 표는 Team 구성원에게 할당할 수 있는 역할을 나열합니다.

Team에서 사용자 제거

Team의 대시보드를 사용하여 Team에서 사용자를 제거합니다. W&B는 run을 생성한 구성원이 더 이상 해당 Team에 없더라도 Team에서 생성된 run을 보존합니다.

1. https://wandb.ai/<team-name>로 이동합니다.
2. 왼쪽 네비게이션 바에서 Team settings를 선택합니다.
3. Users 탭을 선택합니다.
4. 삭제할 사용자 이름 옆에 마우스를 가져갑니다. 나타날 때 줄임표 또는 세 개의 점 아이콘 (…)을 선택합니다.
5. 드롭다운에서 Remove user를 선택합니다.

2.2.2 - Manage access control for projects

W&B 프로젝트의 범위를 정의하여 누가 해당 프로젝트를 보고, 편집하고, W&B run을 제출할 수 있는지 제한합니다.

W&B 팀 내의 모든 프로젝트에 대한 엑세스 수준을 구성하기 위해 몇 가지 제어 기능을 함께 사용할 수 있습니다. 가시성 범위는 더 높은 수준의 메커니즘입니다. 이를 사용하여 어떤 사용자 그룹이 프로젝트에서 run을 보거나 제출할 수 있는지 제어합니다. Team 또는 Restricted 가시성 범위를 가진 프로젝트의 경우 프로젝트 수준 역할을 사용하여 각 사용자가 프로젝트 내에서 갖는 엑세스 수준을 제어할 수 있습니다.

가시성 범위

선택할 수 있는 프로젝트 가시성 범위는 네 가지가 있습니다. 가장 공개적인 것부터 가장 사적인 것 순으로 나열하면 다음과 같습니다.

새 프로젝트 또는 기존 프로젝트에서 가시성 범위 설정

프로젝트를 생성할 때 또는 나중에 편집할 때 프로젝트의 가시성 범위를 설정합니다.

새 프로젝트를 생성할 때 가시성 범위 설정

1. SaaS Cloud, 전용 클라우드 또는 자체 관리 인스턴스에서 W&B 조직으로 이동합니다.
2. 왼쪽 사이드바의 내 프로젝트 섹션에서 새 프로젝트 만들기 버튼을 클릭합니다. 또는 팀의 Projects 탭으로 이동하여 오른쪽 상단 모서리에 있는 새 프로젝트 만들기 버튼을 클릭합니다.
3. 상위 팀을 선택하고 프로젝트 이름을 입력한 후 프로젝트 가시성 드롭다운에서 원하는 범위를 선택합니다.

Restricted 가시성을 선택한 경우 다음 단계를 완료하십시오.

4. 팀 멤버 초대 필드에 하나 이상의 W&B 팀 멤버 이름을 입력합니다. 프로젝트에서 협업하는 데 필수적인 팀 멤버만 추가하십시오.

기존 프로젝트의 가시성 범위 편집

1. W&B 프로젝트로 이동합니다.
2. 왼쪽 열에서 Overview 탭을 선택합니다.
3. 오른쪽 상단 모서리에 있는 프로젝트 세부 정보 편집 버튼을 클릭합니다.
4. 프로젝트 가시성 드롭다운에서 원하는 범위를 선택합니다.

Restricted 가시성을 선택한 경우 다음 단계를 완료하십시오.

5. 프로젝트의 Users 탭으로 이동하여 사용자 추가 버튼을 클릭하여 특정 사용자를 제한된 프로젝트에 초대합니다.

제한된 범위에 대한 기타 주요 참고 사항

• 제한된 프로젝트에서 팀 수준 서비스 계정을 사용하려면 해당 계정을 프로젝트에 특별히 초대하거나 추가해야 합니다. 그렇지 않으면 팀 수준 서비스 계정은 기본적으로 제한된 프로젝트에 엑세스할 수 없습니다.
• 제한된 프로젝트에서 run을 이동할 수는 없지만 제한되지 않은 프로젝트에서 제한된 프로젝트로 run을 이동할 수 있습니다.
• 팀 개인 정보 설정 **향후 모든 팀 프로젝트를 비공개로 설정(공개 공유 불가)**에 관계없이 제한된 프로젝트의 가시성을 Team 범위로만 변환할 수 있습니다.
• 제한된 프로젝트의 소유자가 더 이상 상위 팀에 속하지 않으면 팀 관리자는 프로젝트에서 원활한 운영을 보장하기 위해 소유자를 변경해야 합니다.

프로젝트 수준 역할

팀의 Team 또는 Restricted 범위 프로젝트의 경우 사용자에게 특정 역할을 할당할 수 있으며, 이는 해당 사용자의 팀 수준 역할과 다를 수 있습니다. 예를 들어 사용자가 팀 수준에서 Member 역할을 하는 경우 해당 팀의 Team 또는 Restricted 범위 프로젝트 내에서 해당 사용자에게 View-Only 또는 Admin 또는 사용 가능한 사용자 지정 역할을 할당할 수 있습니다.

사용자에게 프로젝트 수준 역할 할당

1. W&B 프로젝트로 이동합니다.
2. 왼쪽 열에서 Overview 탭을 선택합니다.
3. 프로젝트의 Users 탭으로 이동합니다.
4. 프로젝트 역할 필드에서 해당 사용자에 대해 현재 할당된 역할을 클릭하면 다른 사용 가능한 역할 목록이 있는 드롭다운이 열립니다.
5. 드롭다운에서 다른 역할을 선택합니다. 즉시 저장됩니다.

프로젝트 수준 역할에 대한 기타 주요 참고 사항

• 기본적으로 team 또는 restricted 범위 프로젝트의 모든 사용자에 대한 프로젝트 수준 역할은 해당 팀 수준 역할을 상속합니다.
• 팀 수준에서 View-only 역할을 가진 사용자의 프로젝트 수준 역할은 변경할 수 없습니다.
• 특정 프로젝트 내에서 사용자의 프로젝트 수준 역할이 팀 수준 역할과 동일하고 팀 관리자가 팀 수준 역할을 변경하면 관련 프로젝트 역할이 자동으로 변경되어 팀 수준 역할을 추적합니다.
• 특정 프로젝트 내에서 사용자의 프로젝트 수준 역할을 팀 수준 역할과 다르게 변경하고 팀 관리자가 팀 수준 역할을 변경하면 관련 프로젝트 수준 역할은 그대로 유지됩니다.
• 프로젝트 수준 역할이 팀 수준 역할과 다른 경우 restricted 프로젝트에서 사용자를 제거하고 일정 시간이 지난 후 사용자를 프로젝트에 다시 추가하면 기본 동작으로 인해 팀 수준 역할을 상속합니다. 필요한 경우 프로젝트 수준 역할을 다시 변경하여 팀 수준 역할과 다르게 만들어야 합니다.

2.3 - Automate user and team management

SCIM API

SCIM API를 사용하여 사용자 및 사용자가 속한 Teams를 효율적이고 반복 가능한 방식으로 관리합니다. SCIM API를 사용하여 사용자 정의 역할을 관리하거나 W&B organization의 사용자에게 역할을 할당할 수도 있습니다. 역할 엔드포인트는 공식 SCIM 스키마의 일부가 아닙니다. W&B는 사용자 정의 역할의 자동 관리를 지원하기 위해 역할 엔드포인트를 추가합니다.

SCIM API는 다음과 같은 경우에 특히 유용합니다.

• 사용자 프로비저닝 및 프로비저닝 해제를 대규모로 관리하려는 경우
• SCIM을 지원하는 ID 공급자로 사용자를 관리하려는 경우

SCIM API는 크게 User, Group, Roles의 세 가지 범주로 나뉩니다.

User SCIM API

User SCIM API를 사용하면 W&B organization에서 사용자를 생성, 비활성화, 사용자 세부 정보를 가져오거나 모든 사용자 목록을 가져올 수 있습니다. 이 API는 organization의 사용자에게 미리 정의된 역할 또는 사용자 정의 역할을 할당하는 기능도 지원합니다.

Group SCIM API

Group SCIM API를 사용하면 organization에서 Teams를 생성하거나 제거하는 것을 포함하여 W&B Teams를 관리할 수 있습니다. PATCH Group을 사용하여 기존 Team에서 사용자를 추가하거나 제거합니다.

Custom role API

Custom role SCIM API를 사용하면 organization에서 사용자 정의 역할을 생성, 나열 또는 업데이트하는 것을 포함하여 사용자 정의 역할을 관리할 수 있습니다.

W&B Python SDK API

SCIM API를 통해 사용자 및 Team 관리를 자동화할 수 있는 것처럼 W&B Python SDK API에서 사용할 수 있는 일부 메소드를 사용하여 이 목적을 달성할 수도 있습니다. 다음 메소드를 기록해 두십시오.

2.4 - Manage users, groups, and roles with SCIM

SCIM(System for Cross-domain Identity Management) API를 통해 인스턴스 또는 organization 관리자는 W&B organization에서 사용자, 그룹 및 사용자 지정 역할을 관리할 수 있습니다. SCIM 그룹은 W&B Teams에 매핑됩니다.

SCIM API는 <host-url>/scim/에서 액세스할 수 있으며 RC7643 프로토콜에서 찾을 수 있는 필드의 서브셋으로 /Users 및 /Groups 엔드포인트를 지원합니다. 또한 공식 SCIM 스키마의 일부가 아닌 /Roles 엔드포인트도 포함합니다. W&B는 W&B organization에서 사용자 지정 역할의 자동 관리를 지원하기 위해 /Roles 엔드포인트를 추가합니다.

인증

Organization 또는 인스턴스 관리자는 API 키로 기본 인증을 사용하여 SCIM API에 액세스할 수 있습니다. HTTP 요청의 Authorization 헤더를 Basic 문자열 뒤에 공백, 그런 다음 username:API-KEY 형식으로 base-64로 인코딩된 문자열로 설정합니다. 즉, 사용자 이름과 API 키를 : 문자로 구분된 값으로 바꾸고 결과를 base-64로 인코딩합니다. 예를 들어 demo:p@55w0rd로 인증하려면 헤더는 Authorization: Basic ZGVtbzpwQDU1dzByZA==여야 합니다.

사용자 리소스

SCIM 사용자 리소스는 W&B Users에 매핑됩니다.

사용자 가져오기

• 엔드포인트: <host-url>/scim/Users/{id}
• 메서드: GET
• 설명: 사용자 고유 ID를 제공하여 SaaS Cloud organization 또는 Dedicated Cloud 또는 Self-managed 인스턴스에서 특정 사용자에 대한 정보를 검색합니다.
• 요청 예시:

GET /scim/Users/abc

• 응답 예시:

(Status 200)

{
    "active": true,
    "displayName": "Dev User 1",
    "emails": {
        "Value": "dev-user1@test.com",
        "Display": "",
        "Type": "",
        "Primary": true
    },
    "id": "abc",
    "meta": {
        "resourceType": "User",
        "created": "2023-10-01T00:00:00Z",
        "lastModified": "2023-10-01T00:00:00Z",
        "location": "Users/abc"
    },
    "schemas": [
        "urn:ietf:params:scim:schemas:core:2.0:User"
    ],
    "userName": "dev-user1"
}

사용자 목록

• 엔드포인트: <host-url>/scim/Users
• 메서드: GET
• 설명: SaaS Cloud organization 또는 Dedicated Cloud 또는 Self-managed 인스턴스에서 모든 사용자 목록을 검색합니다.
• 요청 예시:

GET /scim/Users

• 응답 예시:

(Status 200)

{
    "Resources": [
        {
            "active": true,
            "displayName": "Dev User 1",
            "emails": {
                "Value": "dev-user1@test.com",
                "Display": "",
                "Type": "",
                "Primary": true
            },
            "id": "abc",
            "meta": {
                "resourceType": "User",
                "created": "2023-10-01T00:00:00Z",
                "lastModified": "2023-10-01T00:00:00Z",
                "location": "Users/abc"
            },
            "schemas": [
                "urn:ietf:params:scim:schemas:core:2.0:User"
            ],
            "userName": "dev-user1"
        }
    ],
    "itemsPerPage": 9999,
    "schemas": [
        "urn:ietf:params:scim:api:messages:2.0:ListResponse"
    ],
    "startIndex": 1,
    "totalResults": 1
}

사용자 생성

• 엔드포인트: <host-url>/scim/Users
• 메서드: POST
• 설명: 새 사용자 리소스를 만듭니다.
• 지원되는 필드:

• 요청 예시:

POST /scim/Users

{
  "schemas": [
    "urn:ietf:params:scim:schemas:core:2.0:User"
  ],
  "emails": [
    {
      "primary": true,
      "value": "admin-user2@test.com"
    }
  ],
  "userName": "dev-user2"
}

• 응답 예시:

(Status 201)

{
    "active": true,
    "displayName": "Dev User 2",
    "emails": {
        "Value": "dev-user2@test.com",
        "Display": "",
        "Type": "",
        "Primary": true
    },
    "id": "def",
    "meta": {
        "resourceType": "User",
        "created": "2023-10-01T00:00:00Z",
        "location": "Users/def"
    },
    "schemas": [
        "urn:ietf:params:scim:schemas:core:2.0:User"
    ],
    "userName": "dev-user2"
}

사용자 삭제

• 엔드포인트: <host-url>/scim/Users/{id}
• 메서드: DELETE
• 설명: 사용자 고유 ID를 제공하여 SaaS Cloud organization 또는 Dedicated Cloud 또는 Self-managed 인스턴스에서 사용자를 완전히 삭제합니다. 필요한 경우 사용자 생성 API를 사용하여 사용자를 organization 또는 인스턴스에 다시 추가합니다.
• 요청 예시:

DELETE /scim/Users/abc

• 응답 예시:

(Status 204)

사용자 비활성화

• 엔드포인트: <host-url>/scim/Users/{id}
• 메서드: PATCH
• 설명: 사용자 고유 ID를 제공하여 Dedicated Cloud 또는 Self-managed 인스턴스에서 사용자를 일시적으로 비활성화합니다. 필요한 경우 사용자 다시 활성화 API를 사용하여 사용자를 다시 활성화합니다.
• 지원되는 필드:

• 요청 예시:

PATCH /scim/Users/abc

{
    "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
    "Operations": [
        {
            "op": "replace",
            "value": {"active": false}
        }
    ]
}

• 응답 예시: 이것은 User 오브젝트를 반환합니다.

(Status 200)

{
    "active": true,
    "displayName": "Dev User 1",
    "emails": {
        "Value": "dev-user1@test.com",
        "Display": "",
        "Type": "",
        "Primary": true
    },
    "id": "abc",
    "meta": {
        "resourceType": "User",
        "created": "2023-10-01T00:00:00Z",
        "lastModified": "2023-10-01T00:00:00Z",
        "location": "Users/abc"
    },
    "schemas": [
        "urn:ietf:params:scim:schemas:core:2.0:User"
    ],
    "userName": "dev-user1"
}

사용자 다시 활성화

• 엔드포인트: <host-url>/scim/Users/{id}
• 메서드: PATCH
• 설명: 사용자 고유 ID를 제공하여 Dedicated Cloud 또는 Self-managed 인스턴스에서 비활성화된 사용자를 다시 활성화합니다.
• 지원되는 필드:

• 요청 예시:

PATCH /scim/Users/abc

{
    "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
    "Operations": [
        {
            "op": "replace",
            "value": {"active": true}
        }
    ]
}

• 응답 예시: 이것은 User 오브젝트를 반환합니다.

(Status 200)

{
    "active": true,
    "displayName": "Dev User 1",
    "emails": {
        "Value": "dev-user1@test.com",
        "Display": "",
        "Type": "",
        "Primary": true
    },
    "id": "abc",
    "meta": {
        "resourceType": "User",
        "created": "2023-10-01T00:00:00Z",
        "lastModified": "2023-10-01T00:00:00Z",
        "location": "Users/abc"
    },
    "schemas": [
        "urn:ietf:params:scim:schemas:core:2.0:User"
    ],
    "userName": "dev-user1"
}

사용자에게 organization 수준 역할 할당

• 엔드포인트: <host-url>/scim/Users/{id}
• 메서드: PATCH
• 설명: 사용자에게 organization 수준 역할을 할당합니다. 역할은 여기에 설명된 대로 admin, viewer 또는 member 중 하나일 수 있습니다. SaaS Cloud의 경우 사용자 설정에서 SCIM API에 대한 올바른 organization을 구성했는지 확인합니다.
• 지원되는 필드:

• 요청 예시:

PATCH /scim/Users/abc

{
    "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
    "Operations": [
        {
            "op": "replace",
            "path": "organizationRole",
            "value": "admin" // 사용자의 organization 범위 역할을 admin으로 설정합니다.
        }
    ]
}

• 응답 예시: 이것은 User 오브젝트를 반환합니다.

(Status 200)

{
    "active": true,
    "displayName": "Dev User 1",
    "emails": {
        "Value": "dev-user1@test.com",
        "Display": "",
        "Type": "",
        "Primary": true
    },
    "id": "abc",
    "meta": {
        "resourceType": "User",
        "created": "2023-10-01T00:00:00Z",
        "lastModified": "2023-10-01T00:00:00Z",
        "location": "Users/abc"
    },
    "schemas": [
        "urn:ietf:params:scim:schemas:core:2.0:User"
    ],
    "userName": "dev-user1",
    "teamRoles": [  // 사용자가 속한 모든 Teams에서 사용자의 역할을 반환합니다.
        {
            "teamName": "team1",
            "roleName": "admin"
        }
    ],
    "organizationRole": "admin" // organization 범위에서 사용자의 역할을 반환합니다.
}