}
mysql = {
}
}
ingress = {
annotations = {
"a" = "b"
"x" = "y"
}
}
}
}
}
```
설정 옵션은 [설정 참조](#configuration-reference-for-wb-operator)에 설명된 것과 동일하지만 구문은 HashiCorp Configuration Language (HCL)를 따라야 합니다. Terraform 모듈은 W\&B 커스텀 리소스 정의 (CRD)를 생성합니다.
W\&B\&Biases가 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)
* [GCP](https://github.com/wandb/terraform-google-wandb/blob/49ddc3383df4cefc04337a2ae784f57ce2a2c699/main.tf#L189)
### 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와 함께 미리 준비되어 있습니다.
| Terraform 레지스트리 | 소스 코드 | 버전 |
| ---------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | ------- |
| [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://registry.terraform.io/modules/wandb/terraform-azurerm-wandb) | [https://github.com/wandb/terraform-azurerm-wandb](https://github.com/wandb/terraform-azurerm-wandb) | v2.0.0+ |
| [GCP](https://registry.terraform.io/modules/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 Server를 배포하고 관리하는 간소화된 경로를 제공합니다.
이러한 모듈을 사용하는 방법에 대한 자세한 설명은 문서의 [자체 관리 설치 섹션](/ko/platform/hosting/hosting-options/self-managed#deploy-wb-server-within-self-managed-cloud-accounts)을 참조하세요.
### 설치 확인
설치를 확인하기 위해 W\&B는 [W\&B CLI](/ko/models/ref/cli/)를 사용하는 것이 좋습니다. 확인 코맨드는 모든 구성 요소와 구성을 확인하는 여러 테스트를 실행합니다.
이 단계에서는 첫 번째 관리자 사용자 계정이 브라우저로 생성되었다고 가정합니다.
다음 단계에 따라 설치를 확인하세요.
1. W\&B CLI를 설치합니다.
```shell theme={null}
pip install wandb
```
2. W\&B에 로그인합니다.
```shell theme={null}
wandb login --host=https://YOUR_DNS_DOMAIN
```
예:
```shell theme={null}
wandb login --host=https://wandb.company-name.com
```
3. 설치를 확인합니다.
```shell theme={null}
wandb verify
```
설치가 완료되고 W\&B 배포가 완전히 작동하면 다음 출력이 표시됩니다.
```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...........................✅
```
## W\&B Management Console 엑세스
W\&B Kubernetes operator에는 관리 콘솔이 함께 제공됩니다. 예를 들어 `https://wandb.company-name.com/` 콘솔과 같이 `${HOST_URI}/console`에 있습니다.
관리 콘솔에 로그인하는 방법에는 두 가지가 있습니다.
1. 브라우저에서 W\&B 애플리케이션을 열고 로그인합니다. `${HOST_URI}/` (예: `https://wandb.company-name.com/`)로 W\&B 애플리케이션에 로그인합니다.
2. 콘솔에 엑세스합니다. 오른쪽 상단 모서리에 있는 아이콘을 클릭한 다음 **시스템 콘솔**을 클릭합니다. 관리자 권한이 있는 사용자만 **시스템 콘솔** 항목을 볼 수 있습니다.
옵션 1이 작동하지 않는 경우에만 다음 단계에 따라 콘솔에 엑세스하는 것이 좋습니다.
1. 브라우저에서 콘솔 애플리케이션을 엽니다. 위에서 설명한 URL을 열면 로그인 화면으로 리디렉션됩니다.
2. 설치에서 생성되는 Kubernetes secret에서 비밀번호를 검색합니다.
```shell theme={null}
kubectl get secret wandb-password -o jsonpath='{.data.password}' | base64 -d
```
비밀번호를 복사합니다.
3. 콘솔에 로그인합니다. 복사한 비밀번호를 붙여넣은 다음 **로그인**을 클릭합니다.
## W\&B Kubernetes operator 업데이트
이 섹션에서는 W\&B Kubernetes operator를 업데이트하는 방법을 설명합니다.
* W\&B Kubernetes operator를 업데이트해도 W\&B server 애플리케이션은 업데이트되지 않습니다.
* W\&B operator를 업데이트하기 위해 진행하기 전에 W\&B Kubernetes operator를 사용하지 않는 Helm chart를 사용하는 경우 [여기](#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 chart를 업데이트합니다.
```shell theme={null}
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 Operator는 W\&B Server의 기본 및 권장 설치 방법입니다. 질문이 있는 경우 [고객 지원](mailto:support@wandb.com) 또는 W\&B 팀에 문의하세요.
* 공식 W\&B Cloud Terraform Modules를 사용한 경우 적절한 설명서로 이동하여 해당 단계를 따르세요.
* [AWS](#migrate-to-operator-based-aws-terraform-modules)
* [GCP](#migrate-to-operator-based-gcp-terraform-modules)
* [Azure](#migrate-to-operator-based-azure-terraform-modules)
* [W\&B 비-Operator Helm chart](https://github.com/wandb/helm-charts/tree/main/charts/wandb)를 사용한 경우 [여기](#migrate-to-operator-based-helm-chart)를 계속 진행하세요.
* [Terraform이 포함된 W\&B 비-Operator Helm chart](https://registry.terraform.io/modules/wandb/wandb/kubernetes/latest)를 사용한 경우 [여기](#migrate-to-operator-based-terraform-helm-chart)를 계속 진행하세요.
* 매니페스트로 Kubernetes 리소스를 생성한 경우 [여기](#migrate-to-operator-based-helm-chart)를 계속 진행하세요.
### Operator 기반 AWS Terraform Modules로 마이그레이션
마이그레이션 프로세스에 대한 자세한 설명은 [여기](/ko/platform/hosting/operator/#deploy-wb-with-helm-cli)를 계속 진행하세요.
### Operator 기반 GCP Terraform Modules로 마이그레이션
질문이 있거나 지원이 필요한 경우 [고객 지원](mailto:support@wandb.com) 또는 W\&B 팀에 문의하세요.
### Operator 기반 Azure Terraform Modules로 마이그레이션
질문이 있거나 지원이 필요한 경우 [고객 지원](mailto:support@wandb.com) 또는 W\&B 팀에 문의하세요.
### Operator 기반 Helm chart로 마이그레이션
다음 단계에 따라 Operator 기반 Helm chart로 마이그레이션하세요.
1. 현재 W\&B 설정을 가져옵니다. W\&B가 비-operator 기반 버전의 Helm chart로 배포된 경우 다음과 같이 값을 내보냅니다.
```shell theme={null}
helm get values wandb
```
W\&B가 Kubernetes 매니페스트로 배포된 경우 다음과 같이 값을 내보냅니다.
```shell theme={null}
kubectl get deployment wandb -o yaml
```
이제 다음 단계에 필요한 모든 설정 값이 있습니다.
2. `operator.yaml`이라는 파일을 만듭니다. [설정 참조](#configuration-reference-for-wb-operator)에 설명된 형식을 따르세요. 1단계의 값을 사용합니다.
3. 현재 배포를 0개의 pod로 확장합니다. 이 단계는 현재 배포를 중지합니다.
```shell theme={null}
kubectl scale --replicas=0 deployment wandb
```
4. Helm chart 저장소를 업데이트합니다.
```shell theme={null}
helm repo update
```
5. 새 Helm chart를 설치합니다.
```shell theme={null}
helm upgrade --install operator wandb/operator -n wandb-cr --create-namespace
```
6. 새 helm chart를 구성하고 W\&B 애플리케이션 배포를 트리거합니다. 새 구성을 적용합니다.
```shell theme={null}
kubectl apply -f operator.yaml
```
배포가 완료되는 데 몇 분 정도 걸립니다.
7. 설치를 확인합니다. [설치 확인](#verify-the-installation)의 단계에 따라 모든 것이 작동하는지 확인합니다.
8. 이전 설치를 제거합니다. 이전 helm chart를 제거하거나 매니페스트로 생성된 리소스를 삭제합니다.
### Operator 기반 Terraform Helm chart로 마이그레이션
다음 단계에 따라 Operator 기반 Helm chart로 마이그레이션하세요.
1. Terraform 설정을 준비합니다. Terraform 설정에서 이전 배포의 Terraform 코드를 [여기](#deploy-wb-with-helm-terraform-module)에 설명된 코드로 바꿉니다. 이전과 동일한 변수를 설정합니다. .tfvars 파일이 있는 경우 변경하지 마세요.
2. Terraform 실행을 실행합니다. terraform init, plan 및 apply를 실행합니다.
3. 설치를 확인합니다. [설치 확인](#verify-the-installation)의 단계에 따라 모든 것이 작동하는지 확인합니다.
4. 이전 설치를 제거합니다. 이전 helm chart를 제거하거나 매니페스트로 생성된 리소스를 삭제합니다.
## W\&B Server에 대한 설정 참조
이 섹션에서는 W\&B Server 애플리케이션에 대한 설정 옵션을 설명합니다. 애플리케이션은 [WeightsAndBiases](#how-it-works)라는 커스텀 리소스 정의로 설정을 수신합니다. 일부 설정 옵션은 아래 설정으로 노출되고 일부는 환경 변수로 설정해야 합니다.
설명서에는 [기본](/ko/platform/hosting/env-vars/) 및 [고급](/ko/platform/hosting/iam/advanced_env_vars/)의 두 가지 환경 변수 목록이 있습니다. 필요한 설정 옵션이 Helm Chart를 사용하여 노출되지 않은 경우에만 환경 변수를 사용하세요.
프로덕션 배포를 위한 W\&B Server 애플리케이션 설정 파일에는 다음 내용이 필요합니다. 이 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. 콘솔에 로그인합니다. 복사한 비밀번호를 붙여넣은 다음 **로그인**을 클릭합니다.
mysql:
ingress:
annotations:
```
[W\&B Helm 저장소](https://github.com/wandb/helm-charts/blob/main/charts/operator-wandb/values.yaml)에서 전체 값 집합을 찾고 재정의해야 하는 값만 변경하세요.
### 전체 예제
다음은 GCP Ingress 및 GCS(GCP 오브젝트 스토리지)가 포함된 GCP Kubernetes를 사용하는 예제 설정입니다.
```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
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: ""
```
**GCP**
```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
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
```
Ingress 설정에서 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: 64m
```
### 커스텀 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
**TLS 없음**
```yaml theme={null}
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 인증서 설정에는 인증서 콘텐츠로 미리 생성된 구성 맵이 필요합니다.
구성 맵을 생성하려면 다음 코맨드를 사용할 수 있습니다.
```console theme={null}
kubectl create configmap ldap-tls-cert --from-file=certificate.crt
```
아래 예제와 같이 YAML에서 구성 맵을 사용합니다.
```yaml theme={null}
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
```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"
```
### 커스텀 인증 기관
`customCACerts`는 목록이며 여러 인증서를 사용할 수 있습니다. `customCACerts`에 지정된 인증 기관은 W\&B Server 애플리케이션에만 적용됩니다.
```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 Operator에 대한 설정 참조
이 섹션에서는 W\&B Kubernetes operator (`wandb-controller-manager`)에 대한 설정 옵션을 설명합니다. operator는 YAML 파일 형식으로 설정을 수신합니다.
기본적으로 W\&B Kubernetes operator에는 설정 파일이 필요하지 않습니다. 필요한 경우 설정 파일을 만듭니다. 예를 들어 커스텀 인증 기관을 지정하거나 에어 갭 환경에 배포하기 위해 설정 파일이 필요할 수 있습니다.
Helm 저장소에서 전체 사양 사용자 정의 [목록](https://github.com/wandb/helm-charts/blob/main/charts/operator/values.yaml)을 찾으세요.
### 커스텀 CA
커스텀 인증 기관(`customCACerts`)은 목록이며 여러 인증서를 사용할 수 있습니다. 추가된 경우 이러한 인증 기관은 W\&B Kubernetes operator (`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`**: 데이터베이스 데이터를 Parquet 형식으로 오브젝트 스토리지로 내보내는 `wandb-app` pod와 분리된 백엔드 마이크로서비스입니다.
* **`wandb-weave`**: UI에서 쿼리 테이블을 로드하고 다양한 핵심 앱 기능을 지원하는 또 다른 백엔드 마이크로서비스입니다.
* **`wandb-weave-trace`**: LLM 기반 애플리케이션을 추적, 실험, 평가, 배포 및 개선하기 위한 프레임워크입니다. 이 프레임워크는 `wandb-app` pod를 통해 엑세스할 수 있습니다.
### W\&B Operator Console 비밀번호를 얻는 방법
[W\&B Kubernetes Operator Management Console 엑세스](#access-the-wb-management-console)를 참조하세요.
### Ingress가 작동하지 않는 경우 W\&B Operator Console에 엑세스하는 방법
Kubernetes 클러스터에 연결할 수 있는 호스트에서 다음 코맨드를 실행합니다.
```console theme={null}
kubectl port-forward svc/wandb-console 8082
```
`https://localhost:8082/` 콘솔에서 브라우저의 콘솔에 엑세스합니다.
비밀번호를 얻는 방법에 대한 내용은 [W\&B Kubernetes Operator Management Console 엑세스](#access-the-wb-management-console) (옵션 2)를 참조하세요.
### W\&B Server 로그를 보는 방법
애플리케이션 pod의 이름은 **wandb-app-xxx**입니다.
```console theme={null}
kubectl get pods
kubectl logs wandb-XXXXX-XXXXX
```
### Kubernetes ingress 클래스를 식별하는 방법
다음을 실행하여 클러스터에 설치된 ingress 클래스를 가져올 수 있습니다.
```console theme={null}
kubectl get ingressclass
```