mysql:
ingress:
annotations:
```
4. 사용자 정의 설정으로 에이전트를 시작하여 W\&B 서버 애플리케이션을 설치, 구성 및 관리할 수 있도록 합니다:
```shell theme={null}
kubectl apply -f operator.yaml
```
배포가 완료될 때까지 기다립니다. 몇 분 정도 소요됩니다.
5. 웹 UI를 사용하여 설치를 확인하려면 첫 번째 관리자 사용자 계정을 생성한 다음 [설치 확인](#verify-the-installation)에 설명된 확인 단계를 따르십시오.
### Helm Terraform 모듈로 W\&B 배포
이 방법은 일관성과 반복성을 위해 Terraform의 infrastructure-as-code 접근 방식을 활용하여 특정 요구 사항에 맞춘 맞춤형 배포를 가능하게 합니다. 공식 W\&B Helm 기반 Terraform 모듈은 [여기](https://github.com/wandb/helm-charts/tree/main/charts/operator-wandb)에 있습니다.
다음 코드는 시작점으로 사용할 수 있으며 프로덕션 등급 배포에 필요한 모든 설정 옵션을 포함하고 있습니다.
```hcl theme={null}
module "wandb" {
source = "wandb/wandb/helm"
spec = {
values = {
global = {
host = "https://"
license = "eyJhbGnUzaH...j9ZieKQ2x5GGfw"
bucket = {
}
mysql = {
}
}
ingress = {
annotations = {
"a" = "b"
"x" = "y"
}
}
}
}
}
```
설정 옵션은 [설정 레퍼런스](#configuration-reference-for-wb-operator)에 설명된 것과 동일하지만 구문은 HCL(HashiCorp Configuration Language)을 따라야 합니다. Terraform 모듈은 W\&B 사용자 정의 리소스 정의(CRD)를 생성합니다.
W\&B가 고객을 위해 "전용 클라우드 (Dedicated Cloud)" 설치를 배포하기 위해 Helm Terraform 모듈을 어떻게 사용하는지 보려면 다음 링크를 참조하십시오:
* [AWS](https://github.com/wandb/terraform-aws-wandb/blob/45e1d746f53e78e73e68f911a1f8cad5408e74b6/main.tf#L225)
* [Azure](https://github.com/wandb/terraform-azurerm-wandb/blob/170e03136b6b6fc758102d59dacda99768854045/main.tf#L155)
* [Google Cloud](https://github.com/wandb/terraform-google-wandb/blob/49ddc3383df4cefc04337a2ae784f57ce2a2c699/main.tf#L189)
### W\&B 클라우드 Terraform 모듈로 W\&B 배포
W\&B는 AWS, Google Cloud 및 Azure를 위한 일련의 Terraform 모듈을 제공합니다. 이 모듈들은 Kubernetes 클러스터, 로드 밸런서, MySQL 데이터베이스 등을 포함한 전체 인프라와 W\&B 서버 애플리케이션을 배포합니다. W\&B Kubernetes Operator는 이미 다음과 같은 버전의 공식 W\&B 클라우드 전용 Terraform 모듈에 포함되어 있습니다:
| Terraform Registry | 소스 코드 | 버전 |
| ------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | ------- |
| [AWS](https://registry.terraform.io/modules/wandb/wandb/aws/latest) | [https://github.com/wandb/terraform-aws-wandb](https://github.com/wandb/terraform-aws-wandb) | v4.0.0+ |
| [Azure](https://github.com/wandb/terraform-azurerm-wandb) | [https://github.com/wandb/terraform-azurerm-wandb](https://github.com/wandb/terraform-azurerm-wandb) | v2.0.0+ |
| [Google Cloud](https://github.com/wandb/terraform-google-wandb) | [https://github.com/wandb/terraform-google-wandb](https://github.com/wandb/terraform-google-wandb) | v2.0.0+ |
이 인테그레이션은 최소한의 설정으로 인스턴스에서 W\&B Kubernetes Operator를 사용할 준비가 되도록 보장하여 클라우드 환경에서 W\&B 서버를 배포하고 관리할 수 있는 간소화된 경로를 제공합니다.
이 모듈을 사용하는 방법에 대한 자세한 설명은 문서의 [Self-Managed 설치 섹션](/platform/hosting/hosting-options/self-managed#deploy-wb-server-within-self-managed-cloud-accounts)을 참조하십시오.
### 설치 확인
To verify the installation, W\&B recommends using the [W\&B CLI](/models/ref/cli/). The verify command executes several tests that verify all components and configurations.
This step assumes that the first admin user account is created with the browser.
Follow these steps to verify the installation:
1. Install the W\&B CLI:
```bash theme={null}
pip install wandb
```
2. Log in to W\&B:
```bash theme={null}
wandb login --host=https://YOUR_DNS_DOMAIN
```
For example:
```bash theme={null}
wandb login --host=https://wandb.company-name.com
```
3. Verify the installation:
```bash theme={null}
wandb verify
```
A successful installation and fully working W\&B deployment shows the following output:
```console theme={null}
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...........................✅
```
Contact W\&B Support if you encounter errors.
## W\&B 관리 콘솔 엑세스
W\&B Kubernetes 에이전트에는 관리 콘솔이 함께 제공됩니다. 주소는 `${HOST_URI}/console`입니다(예: `https://wandb.company-name.com/console`).
관리 콘솔에 로그인하는 방법은 두 가지가 있습니다:
1. 브라우저에서 W\&B 애플리케이션을 열고 로그인합니다. `${HOST_URI}/` 주소로 W\&B 애플리케이션에 로그인합니다(예: `https://wandb.company-name.com/`).
2. 콘솔에 엑세스합니다. 오른쪽 상단의 아이콘을 클릭한 다음 **System console**을 클릭합니다. 관리자 권한이 있는 사용자만 **System console** 항목을 볼 수 있습니다.
옵션 1이 작동하지 않는 경우에만 다음 단계를 사용하여 콘솔에 엑세스할 것을 권장합니다.
1. 브라우저에서 콘솔 애플리케이션을 엽니다. 위에 설명된 URL을 열면 로그인 화면으로 리디렉션됩니다:
2. 설치 시 생성되는 Kubernetes secret에서 비밀번호를 검색합니다:
```shell theme={null}
kubectl get secret wandb-password -o jsonpath='{.data.password}' | base64 -d
```
비밀번호를 복사합니다.
3. 콘솔에 로그인합니다. 복사한 비밀번호를 붙여넣고 **Login**을 클릭합니다.
## W\&B Kubernetes 에이전트 업데이트
이 섹션에서는 W\&B Kubernetes 에이전트를 업데이트하는 방법을 설명합니다.
* W\&B Kubernetes 에이전트를 업데이트해도 W\&B 서버 애플리케이션은 업데이트되지 않습니다.
* W\&B Kubernetes 에이전트를 사용하지 않는 Helm 차트를 사용하는 경우, W\&B 에이전트 업데이트 지침을 따르기 전에 [여기](#migrate-Self-Managed-instances-to-wb-operator)의 지침을 참조하십시오.
아래의 코드조각을 터미널에 복사하여 붙여넣으십시오.
1. 먼저 [`helm repo update`](https://helm.sh/docs/helm/helm_repo_update/)를 사용하여 저장소를 업데이트합니다:
```shell theme={null}
helm repo update
```
2. 다음으로 [`helm upgrade`](https://helm.sh/docs/helm/helm_upgrade/)를 사용하여 Helm 차트를 업데이트합니다:
```shell theme={null}
helm upgrade operator wandb/operator -n wandb-cr --reuse-values
```
## W\&B 서버 애플리케이션 업데이트
W\&B Kubernetes 에이전트를 사용하는 경우 더 이상 W\&B 서버 애플리케이션을 직접 업데이트할 필요가 없습니다.
에이전트는 새로운 버전의 W\&B 소프트웨어가 릴리스되면 W\&B 서버 애플리케이션을 자동으로 업데이트합니다.
## Self-Managed 인스턴스를 W\&B 에이전트로 마이그레이션
다음 섹션에서는 사용자가 직접 관리하던 W\&B 서버 설치를 W\&B 에이전트가 관리하도록 마이그레이션하는 방법을 설명합니다. 마이그레이션 프로세스는 W\&B 서버를 어떻게 설치했느냐에 따라 달라집니다:
W\&B 에이전트는 W\&B 서버를 위한 기본이자 권장되는 설치 방법입니다. 궁금한 점이 있으면 [고객 지원](mailto:support@wandb.com) 또는 W\&B 팀에 문의하십시오.
* 공식 W\&B 클라우드 Terraform 모듈을 사용한 경우 해당 문서로 이동하여 단계를 따르십시오:
* [AWS](#migrate-to-operator-based-aws-terraform-modules)
* [Google Cloud](#migrate-to-operator-based-google-cloud-terraform-modules)
* [Azure](#migrate-to-operator-based-azure-terraform-modules)
* [W\&B Non-Operator Helm 차트](https://github.com/wandb/helm-charts/tree/main/charts/wandb)를 사용한 경우 [여기](#migrate-to-operator-based-helm-chart)에서 계속하십시오.
* [Terraform과 함께 W\&B Non-Operator Helm 차트](https://registry.terraform.io/modules/wandb/wandb/kubernetes/latest)를 사용한 경우 [여기](#migrate-to-operator-based-terraform-helm-chart)에서 계속하십시오.
* manifest로 Kubernetes 리소스를 생성한 경우 [여기](#migrate-to-operator-based-helm-chart)에서 계속하십시오.
### 에이전트 기반 AWS Terraform 모듈로 마이그레이션
마이그레이션 프로세스에 대한 자세한 설명은 [여기](https://github.com/wandb/helm-charts/tree/main/charts/operator-wandb)에서 계속하십시오.
### 에이전트 기반 Google Cloud Terraform 모듈로 마이그레이션
질문이 있거나 도움이 필요한 경우 [고객 지원](mailto:support@wandb.com) 또는 W\&B 팀에 문의하십시오.
### 에이전트 기반 Azure Terraform 모듈로 마이그레이션
질문이 있거나 도움이 필요한 경우 [고객 지원](mailto:support@wandb.com) 또는 W\&B 팀에 문의하십시오.
### 에이전트 기반 Helm 차트로 마이그레이션
에이전트 기반 Helm 차트로 마이그레이션하려면 다음 단계를 따르십시오:
1. 현재 W\&B 설정을 가져옵니다. 에이전트 기반이 아닌 버전의 Helm 차트로 W\&B가 배포된 경우 다음과 같이 값을 내보냅니다:
```shell theme={null}
helm get values wandb
```
Kubernetes manifest로 W\&B가 배포된 경우 다음과 같이 값을 내보냅니다:
```shell theme={null}
kubectl get deployment wandb -o yaml
```
이제 다음 단계에 필요한 모든 설정 값을 확보했습니다.
2. `operator.yaml`이라는 파일을 생성합니다. [설정 레퍼런스](#configuration-reference-for-wb-operator)에 설명된 형식을 따릅니다. 1단계의 값을 사용합니다.
3. 현재 배포의 pod 수를 0으로 확장합니다. 이 단계는 현재 배포를 중지합니다.
```shell theme={null}
kubectl scale --replicas=0 deployment wandb
```
4. Helm 차트 저장소를 업데이트합니다:
```shell theme={null}
helm repo update
```
5. 새 Helm 차트를 설치합니다:
```shell theme={null}
helm upgrade --install operator wandb/operator -n wandb-cr --create-namespace
```
6. 새 Helm 차트를 구성하고 W\&B 애플리케이션 배포를 트리거합니다. 새 설정을 적용합니다.
```shell theme={null}
kubectl apply -f operator.yaml
```
배포가 완료되는 데 몇 분 정도 걸립니다.
7. 설치를 확인합니다. [설치 확인](#verify-the-installation)의 단계를 따라 모든 것이 작동하는지 확인하십시오.
8. 이전 설치를 제거합니다. 이전 Helm 차트를 제거하거나 manifest로 생성된 리소스를 삭제합니다.
### 에이전트 기반 Terraform Helm 차트로 마이그레이션
에이전트 기반 Helm 차트로 마이그레이션하려면 다음 단계를 따르십시오:
1. Terraform 설정을 준비합니다. Terraform 설정에서 이전 배포의 Terraform 코드를 [여기](#deploy-wb-with-helm-terraform-module)에 설명된 코드로 교체합니다. 이전과 동일한 변수를 설정합니다. .tfvars 파일이 있는 경우 변경하지 마십시오.
2. Terraform을 실행합니다. terraform init, plan 및 apply를 실행합니다.
3. 설치를 확인합니다. [설치 확인](#verify-the-installation)의 단계를 따라 모든 것이 작동하는지 확인하십시오.
4. 이전 설치를 제거합니다. 이전 Helm 차트를 제거하거나 manifest로 생성된 리소스를 삭제합니다.
## W\&B 서버 설정 레퍼런스
이 섹션에서는 W\&B 서버 애플리케이션의 설정 옵션을 설명합니다. 애플리케이션은 [WeightsAndBiases](#how-it-works)라는 사용자 정의 리소스 정의로 설정을 받습니다. 일부 설정 옵션은 아래 설정을 통해 노출되며, 일부는 환경 변수로 설정해야 합니다.
문서에는 두 가지 환경 변수 목록이 있습니다: [기본](/platform/hosting/env-vars/) 및 [고급](/platform/hosting/iam/advanced_env_vars/). 필요한 설정 옵션이 Helm 차트를 통해 노출되지 않는 경우에만 환경 변수를 사용하십시오.
### 기본 예시
이 예시는 W\&B에 필요한 최소값 세트를 정의합니다. 보다 현실적인 프로덕션 예시는 [전체 예시](#complete-example)를 참조하십시오.
이 YAML 파일은 버전, 환경 변수, 데이터베이스와 같은 외부 리소스 및 기타 필요한 설정을 포함하여 W\&B 배포의 원하는 상태를 정의합니다.
```yaml theme={null}
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://
license: eyJhbGnUzaH...j9ZieKQ2x5GGfw
bucket:
2. 설치 시 생성되는 Kubernetes secret에서 비밀번호를 검색합니다:
```shell theme={null}
kubectl get secret wandb-password -o jsonpath='{.data.password}' | base64 -d
```
비밀번호를 복사합니다.
3. 콘솔에 로그인합니다. 복사한 비밀번호를 붙여넣고 **Login**을 클릭합니다.
mysql:
ingress:
annotations:
```
전체 값 세트는 [W\&B Helm 저장소](https://github.com/wandb/helm-charts/blob/main/charts/operator-wandb/values.yaml)에서 찾을 수 있습니다. **재정의해야 하는 값만 변경하십시오**.
### 전체 예시
이 설정 예시는 Google Cloud Storage를 사용하여 Google Cloud Anthos에 W\&B를 배포합니다:
```yaml theme={null}
apiVersion: apps.wandb.com/v1
kind: WeightsAndBiases
metadata:
labels:
app.kubernetes.io/name: weightsandbiases
app.kubernetes.io/instance: wandb
name: wandb
namespace: default
spec:
values:
global:
host: https://abc-wandb.sandbox-gcp.wandb.ml
bucket:
name: abc-wandb-moving-pipefish
provider: gcs
mysql:
database: wandb_local
host: 10.218.0.2
name: wandb_local
password: 8wtX6cJHizAZvYScjDzZcUarK4zZGjpV
port: 3306
user: wandb
redis:
host: redis.example.com
port: 6379
password: password
api:
enabled: true
glue:
enabled: true
executor:
enabled: true
license: eyJhbGnUzaHgyQjQyQWhEU3...ZieKQ2x5GGfw
ingress:
annotations:
ingress.gcp.kubernetes.io/pre-shared-cert: abc-wandb-cert-creative-puma
kubernetes.io/ingress.class: gce
kubernetes.io/ingress.global-static-ip-name: abc-wandb-operator-address
```
### 호스트 (Host)
```yaml theme={null}
# 프로토콜을 포함한 FQDN을 제공하십시오
global:
# 예시 호스트 이름, 실제 값으로 교체하십시오
host: https://wandb.example.com
```
### 오브젝트 스토리지 (bucket)
**AWS**
```yaml theme={null}
global:
bucket:
provider: "s3"
name: ""
kmsKey: ""
region: ""
```
**Google Cloud**
```yaml theme={null}
global:
bucket:
provider: "gcs"
name: ""
```
**Azure**
```yaml theme={null}
global:
bucket:
provider: "az"
name: ""
secretKey: ""
```
**기타 제공업체 (Minio, Ceph 등)**
기타 S3 호환 제공업체의 경우 버킷 설정을 다음과 같이 지정하십시오:
```yaml theme={null}
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`를 참조하려면:
```yaml theme={null}
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
```yaml theme={null}
global:
mysql:
# 예시 값, 실제 값으로 교체하십시오
host: db.example.com
port: 3306
database: wandb_local
user: wandb
password: 8wtX6cJH...ZcUarK4zZGjpV
```
secret에서 `password`를 참조하려면:
```yaml theme={null}
global:
mysql:
# 예시 값, 실제 값으로 교체하십시오
host: db.example.com
port: 3306
database: wandb_local
user: wandb
passwordSecret:
name: database-secret
passwordKey: MYSQL_WANDB_PASSWORD
```
### 라이선스 (License)
```yaml theme={null}
global:
# 예시 라이선스, 실제 값으로 교체하십시오
license: eyJhbGnUzaHgyQjQy...VFnPS_KETXg1hi
```
secret에서 `license`를 참조하려면:
```yaml theme={null}
global:
licenseSecret:
name: license-secret
key: CUSTOMER_WANDB_LICENSE
```
### 인그레스 (Ingress)
인그레스 클래스를 확인하려면 이 FAQ [항목](#how-to-identify-the-kubernetes-ingress-class)을 참조하십시오.
**TLS 미사용 시**
```yaml theme={null}
global:
# 중요: Ingress는 YAML에서 ‘global’과 동일한 레벨에 있어야 합니다 (자식이 아님)
ingress:
class: ""
```
**TLS 사용 시**
인증서를 포함하는 secret을 생성합니다
```console theme={null}
kubectl create secret tls wandb-ingress-tls --key wandb-ingress-tls.key --cert wandb-ingress-tls.crt
```
인그레스 설정에서 secret을 참조합니다
```yaml theme={null}
global:
# 중요: Ingress는 YAML에서 ‘global’과 동일한 레벨에 있어야 합니다 (자식이 아님)
ingress:
class: ""
annotations:
{}
# kubernetes.io/ingress.class: nginx
# kubernetes.io/tls-acme: "true"
tls:
- secretName: wandb-ingress-tls
hosts:
-
```
Nginx의 경우 다음 어노테이션을 추가해야 할 수도 있습니다:
```
ingress:
annotations:
nginx.ingress.kubernetes.io/proxy-body-size: 0
```
### 사용자 정의 Kubernetes ServiceAccounts
W\&B pod를 실행하기 위해 사용자 정의 Kubernetes 서비스 계정을 지정하십시오.
다음 코드조각은 지정된 이름으로 배포의 일부로 서비스 계정을 생성합니다:
```yaml theme={null}
app:
serviceAccount:
name: custom-service-account
create: true
parquet:
serviceAccount:
name: custom-service-account
create: true
global:
...
```
하위 시스템 "app" 및 "parquet"은 지정된 서비스 계정에서 실행됩니다. 다른 하위 시스템은 기본 서비스 계정에서 실행됩니다.
클러스터에 서비스 계정이 이미 존재하는 경우 `create: false`로 설정하십시오:
```yaml theme={null}
app:
serviceAccount:
name: custom-service-account
create: false
parquet:
serviceAccount:
name: custom-service-account
create: false
global:
...
```
app, parquet, console 등 다양한 하위 시스템에 서비스 계정을 지정할 수 있습니다:
```yaml theme={null}
app:
serviceAccount:
name: custom-service-account
create: true
console:
serviceAccount:
name: custom-service-account
create: true
global:
...
```
하위 시스템마다 다른 서비스 계정을 사용할 수 있습니다:
```yaml theme={null}
app:
serviceAccount:
name: custom-service-account
create: false
console:
serviceAccount:
name: another-custom-service-account
create: true
global:
...
```
### 외부 Redis
```yaml theme={null}
redis:
install: false
global:
redis:
host: ""
port: 6379
password: ""
parameters: {}
caCert: ""
```
secret에서 `password`를 참조하려면:
```console theme={null}
kubectl create secret generic redis-secret --from-literal=redis-password=supersecret
```
아래 설정에서 이를 참조합니다:
```yaml theme={null}
redis:
install: false
global:
redis:
host: redis.example
port: 9001
auth:
enabled: true
secret: redis-secret
key: redis-password
```
### LDAP
현재 Helm 차트의 LDAP 설정 지원은 제한적입니다. LDAP 구성을 위해 W\&B 지원팀 또는 AISE에 문의하십시오.
`global.extraEnv`에서 환경 변수를 설정하여 LDAP을 구성하십시오:
```yaml theme={null}
global:
extraEnv:
LDAP_ADDRESS: ldaps://ldap.company.example.com
LDAP_BASE_DN: cn=accounts,dc=company,dc=example,dc=com
LDAP_USER_BASE_DN: cn=users,cn=accounts,dc=company,dc=example,dc=com
LDAP_GROUP_BASE_DN: cn=groups,cn=accounts,dc=company,dc=example,dc=com
LDAP_BIND_DN: uid=ldapbind,cn=sysaccounts,cn=etc,dc=company,dc=example,dc=com
LDAP_BIND_PW: ********************
LDAP_ATTRIBUTES: email=mail,name=cn
LDAP_TLS_ENABLE: "true"
LDAP_LOGIN: "true"
LDAP_USER_OBJECT_CLASS: user
LDAP_GROUP_OBJECT_CLASS: group
```
이 레거시 접근 방식은 더 이상 권장되지 않습니다. 이 섹션은 참조용으로 제공됩니다.
**TLS 미사용 시**
```yaml theme={null}
global:
ldap:
enabled: true
# "ldap://" 또는 "ldaps://"를 포함한 LDAP 서버 주소
host:
# 사용자 검색에 사용할 LDAP search base
baseDN:
# 바인딩에 사용할 LDAP 사용자 (익명 바인딩을 사용하지 않는 경우)
bindDN:
# 바인딩에 사용할 LDAP 비밀번호를 포함하는 Secret 이름 및 키 (익명 바인딩을 사용하지 않는 경우)
bindPW:
# 이메일 및 그룹 ID 속성 이름에 대한 LDAP 속성 (쉼표로 구분된 문자열 값)
attributes:
# LDAP 그룹 허용 목록
groupAllowList:
# LDAP TLS 활성화
tls: false
```
**TLS 사용 시**
LDAP TLS 인증서 구성에는 인증서 내용으로 미리 생성된 config map이 필요합니다.
config map을 생성하려면 다음 코맨드를 사용할 수 있습니다:
```console theme={null}
kubectl create configmap ldap-tls-cert --from-file=certificate.crt
```
그리고 아래 예시와 같이 YAML에서 config map을 사용합니다
```yaml theme={null}
global:
ldap:
enabled: true
# "ldap://" 또는 "ldaps://"를 포함한 LDAP 서버 주소
host:
# 사용자 검색에 사용할 LDAP search base
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
```yaml theme={null}
global:
auth:
sessionLengthHours: 720
oidc:
clientId: ""
secret: ""
# IdP에서 요구하는 경우에만 포함하십시오.
authMethod: ""
issuer: ""
```
`authMethod`는 선택 사항입니다.
### SMTP
```yaml theme={null}
global:
email:
smtp:
host: ""
port: 587
user: ""
password: ""
```
### 환경 변수
```yaml theme={null}
global:
extraEnv:
GLOBAL_ENV: "example"
```
### 사용자 정의 인증 기관 (Custom CA)
`customCACerts`는 리스트 형태이며 여러 개의 인증서를 가질 수 있습니다. `customCACerts`에 지정된 인증 기관은 W\&B 서버 애플리케이션에만 적용됩니다.
```yaml theme={null}
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에도 저장할 수 있습니다:
```yaml theme={null}
global:
caCertsConfigMap: custom-ca-certs
```
ConfigMap은 다음과 같아야 합니다:
```yaml theme={null}
apiVersion: v1
kind: ConfigMap
metadata:
name: custom-ca-certs
data:
ca-cert1.crt: |
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
ca-cert2.crt: |
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
```
ConfigMap을 사용하는 경우 ConfigMap의 각 키는 `.crt`로 끝나야 합니다 (예: `my-cert.crt` 또는 `ca-cert1.crt`). 이 명명 규칙은 `update-ca-certificates`가 각 인증서를 파싱하여 시스템 CA 저장소에 추가하는 데 필요합니다.
### 사용자 정의 보안 컨텍스트
각 W\&B 구성 요소는 다음과 같은 형식의 사용자 정의 보안 컨텍스트 설정을 지원합니다:
```yaml theme={null}
pod:
securityContext:
runAsNonRoot: true
runAsUser: 1001
runAsGroup: 0
fsGroup: 1001
fsGroupChangePolicy: Always
seccompProfile:
type: RuntimeDefault
container:
securityContext:
capabilities:
drop:
- ALL
readOnlyRootFilesystem: false
allowPrivilegeEscalation: false
```
`runAsGroup:`에 유효한 유일한 값은 `0`입니다. 다른 값은 오류입니다.
예를 들어, 애플리케이션 pod를 구성하려면 설정에 `app` 섹션을 추가하십시오:
```yaml theme={null}
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 에이전트 설정 레퍼런스
이 섹션에서는 W\&B Kubernetes 에이전트(`wandb-controller-manager`)의 설정 옵션을 설명합니다. 에이전트는 YAML 파일 형식으로 설정을 받습니다.
기본적으로 W\&B Kubernetes 에이전트는 설정 파일이 필요하지 않습니다. 필요한 경우에만 설정 파일을 생성하십시오. 예를 들어 사용자 정의 인증 기관을 지정하거나, 에어갭 환경에 배포하는 등의 경우에 설정 파일이 필요할 수 있습니다.
전체 spec 사용자 정의 목록은 [Helm 저장소](https://github.com/wandb/helm-charts/blob/main/charts/operator/values.yaml)에서 찾을 수 있습니다.
### 사용자 정의 CA
사용자 정의 인증 기관(`customCACerts`)은 리스트 형태이며 여러 개의 인증서를 가질 수 있습니다. 이 인증 기관들은 추가될 때 W\&B Kubernetes 에이전트(`wandb-controller-manager`)에만 적용됩니다.
```yaml theme={null}
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에도 저장할 수 있습니다:
```yaml theme={null}
caCertsConfigMap: custom-ca-certs
```
ConfigMap은 다음과 같아야 합니다:
```yaml theme={null}
apiVersion: v1
kind: ConfigMap
metadata:
name: custom-ca-certs
data:
ca-cert1.crt: |
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
ca-cert2.crt: |
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
```
ConfigMap의 각 키는 `.crt`로 끝나야 합니다 (예: `my-cert.crt` 또는 `ca-cert1.crt`). 이 명명 규칙은 `update-ca-certificates`가 각 인증서를 파싱하여 시스템 CA 저장소에 추가하는 데 필요합니다.
## FAQ
### 각 개별 pod의 목적/역할은 무엇인가요?
* **`wandb-app`**: GraphQL API 및 프런트엔드 애플리케이션을 포함한 W\&B의 핵심입니다. 플랫폼 기능의 대부분을 구동합니다.
* **`wandb-console`**: `/console`을 통해 엑세스하는 관리 콘솔입니다.
* **`wandb-otel`**: 관리 콘솔에 표시하기 위해 Kubernetes 레이어의 리소스에서 메트릭과 로그를 수집하는 OpenTelemetry 에이전트입니다.
* **`wandb-prometheus`**: 관리 콘솔에 표시하기 위해 다양한 구성 요소에서 메트릭을 캡처하는 Prometheus 서버입니다.
* **`wandb-parquet`**: `wandb-app` pod와 분리된 백엔드 마이크로서비스로, 데이터베이스 데이터를 Parquet 형식으로 오브젝트 스토리지에 내보냅니다.
* **`wandb-weave`**: UI에서 쿼리 테이블을 로드하고 다양한 핵심 앱 기능을 지원하는 또 다른 백엔드 마이크로서비스입니다.
* **`wandb-weave-trace`**: LLM 기반 애플리케이션의 추적, 실험, 평가, 배포 및 개선을 위한 프레임워크입니다. 이 프레임워크는 `wandb-app` pod를 통해 엑세스됩니다.
### W\&B 에이전트 콘솔 비밀번호를 어떻게 얻나요?
[W\&B Kubernetes 에이전트 관리 콘솔 엑세스](#access-the-wb-management-console)를 참조하십시오.
### 인그레스가 작동하지 않을 때 W\&B 에이전트 콘솔에 어떻게 엑세스하나요?
Kubernetes 클러스터에 도달할 수 있는 호스트에서 다음 코맨드를 실행하십시오:
```console theme={null}
kubectl port-forward svc/wandb-console 8082
```
브라우저에서 `https://localhost:8082/` console로 콘솔에 엑세스합니다.
비밀번호를 얻는 방법은 [W\&B Kubernetes 에이전트 관리 콘솔 엑세스](#access-the-wb-management-console)를 참조하십시오 (옵션 2).
### W\&B 서버 로그는 어떻게 보나요?
애플리케이션 pod의 이름은 **wandb-app-xxx**입니다.
```console theme={null}
kubectl get pods
kubectl logs wandb-XXXXX-XXXXX
```
### Kubernetes 인그레스 클래스를 어떻게 확인하나요?
다음 명령을 실행하여 클러스터에 설치된 인그레스 클래스를 확인할 수 있습니다.
```console theme={null}
kubectl get ingressclass
```