}
mysql = {
}
}
ingress = {
annotations = {
"a" = "b"
"x" = "y"
}
}
}
}
}
```
設定オプションは[設定参照](#configuration-reference-for-wb-operator)に記載されているものと同じですが、構文は HashiCorp Configuration Language (HCL) に従う必要があります。Terraform モジュールは、W\&B カスタムリソース定義 (CRD) を作成します。
W\&B\&Biases 自身が「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)
* [GCP](https://github.com/wandb/terraform-google-wandb/blob/49ddc3383df4cefc04337a2ae784f57ce2a2c699/main.tf#L189)
### W\&B Cloud Terraform Modules で W\&B をデプロイする
W\&B は AWS、GCP、および Azure のための Terraform Modules を提供しています。これらのモジュールは、Kubernetes クラスター、ロードバランサー、MySQL データベースなどのインフラ全体と同様に W\&B Server アプリケーションをデプロイします。これらの公式 W\&B クラウド固有の Terraform Modules には、W\&B Kubernetes オペレーターが既に組み込まれています。
| Terraform Registry | Source Code | Version |
| ------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | ------- |
| [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+ |
| [GCP](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 インスタンス用の W\&B Kubernetes オペレーターの準備が整い、クラウド環境での W\&B Server のデプロイと管理がスムーズに行えます。
これらのモジュールの使用方法の詳細な説明については、[セルフマネージドインストールセクション](/ja/platform/hosting/hosting-options/self-managed#deploy-wb-server-within-self-managed-cloud-accounts)のドキュメントを参照してください。
### インストールを検証する
インストールを検証するには、W\&B は [W\&B CLI](/ja/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 管理コンソールへのアクセス
W\&B Kubernetes オペレーターには管理コンソールが付属しています。 `${HOST_URI}/console` にあり、例えば `https://wandb.company-name.com/` です。
管理コンソールにログインする方法は2つあります:
1. W\&B アプリケーションをブラウザで開き、ログインします。W\&B アプリケーションには `${HOST_URI}/` でログインします。例えば `https://wandb.company-name.com/`
2. コンソールにアクセスします。右上のアイコンをクリックし、次に **System console** をクリックします。管理者権限を持つユーザーだけが **System console** エントリを見ることができます。
W\&B は、Option 1 が機能しない場合のみ、以下の手順を使用してコンソールにアクセスすることを推奨します。
1. ブラウザでコンソールアプリケーションを開きます。上記で説明されている URL を開くと、ログイン画面にリダイレクトされます:
2. インストールが生成する Kubernetes シークレットからパスワードを取得します:
```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 chart を使用している場合は、続いて 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 Server アプリケーションの更新
W\&B Kubernetes オペレーターを使用する場合、W\&B Server アプリケーションの更新は不要です。
オペレーターは、W\&B のソフトウェアの新しいバージョンがリリースされると、W\&B Server アプリケーションを自動的に更新します。
## W\&B オペレーターへのセルフマネージドインスタンスの移行
このセクションでは、自分自身で W\&B Server インストールを管理することから、W\&B オペレーターを使用してこれを実行するための移行プロセスを説明しています。移行プロセスは、W\&B Server をインストールした方法によって異なります:
W\&B オペレーターは、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 Non-Operator Helm チャート](https://github.com/wandb/helm-charts/tree/main/charts/wandb)を使用した場合は[こちら](#migrate-to-operator-based-helm-chart)を続けてください。
* [W\&B Non-Operator Helm チャート with Terraform](https://registry.terraform.io/modules/wandb/wandb/kubernetes/latest) を使用した場合は[こちら](#migrate-to-operator-based-terraform-helm-chart)を続けてください。
* Kubernetes マニフェストでリソースを作成した場合は[こちら](#migrate-to-operator-based-helm-chart)を続けてください。
### オペレーターを基にした AWS Terraform Modules への移行
移行プロセスの詳細な説明については、こちら [here](/ja/platform/hosting/self-managed/aws-tf/#migrate-to-operator-based-aws-terraform-modules)を参照してください。
### オペレーターを基にした GCP Terraform Modules への移行
質問がある場合や支援が必要な際は、[カスタマーサポート](mailto:support@wandb.com)または W\&B チームにお問い合わせください。
### オペレーターを基にした Azure Terraform Modules への移行
質問がある場合や支援が必要な際は、[カスタマーサポート](mailto:support@wandb.com)または W\&B チームにお問い合わせください。
### オペレーターを基にした Helm チャートへの移行
オペレーターを基にした Helm チャートへの移行手順は次のとおりです:
1. 現在の W\&B 設定を取得します。W\&B がオペレーターを基にしていないバージョンの Helm チャートでデプロイされている場合、次のように値をエクスポートします:
```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 ポッドにスケールします。このステップで現在のデプロイメントを停止します。
```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 チャートをアンインストールするか、マニフェストで作成されたリソースを削除します。
### オペレーターを基にした Terraform Helm チャートへの移行
オペレーターを基にした Helm チャートへの移行手順は次のとおりです:
1. Terraform 設定を準備します。Terraform 設定内の古いデプロイメントの Terraform コードを、[こちら](#deploy-wb-with-helm-terraform-module)で説明されているものに置き換えます。以前と同じ変数を設定します。.tfvars ファイルがある場合、それを変更しないでください。
2. Terraform run を実行します。terraform init、plan、および apply を実行します。
3. インストールを検証します。すべてが正常に動作することを確認するために、[インストールの検証](#verify-the-installation)の手順に従います。
4. 古いインストールの削除。古い helm チャートをアンインストールするか、マニフェストで作成されたリソースを削除します。
## Configuration Reference for W\&B Server
このセクションでは、W\&B サーバーアプリケーションの設定オプションについて説明します。アプリケーションは、[WeightsAndBiases](#how-it-works)というカスタムリソース定義としてその設定を受け取ります。一部の設定オプションは以下の設定で公開され、他は環境変数として設定する必要があります。
ドキュメントには環境変数が2つのリストに分かれています：[basic](/ja/platform/hosting/env-vars/) および [advanced](/ja/platform/hosting/iam/advanced_env_vars/)。必要な設定オプションが Helm Chart を使用して公開されていない場合にのみ環境変数を使用してください。
本番展開用の W\&B サーバーアプリケーションの設定ファイルには、以下の内容が必要です。この 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 シークレットからパスワードを取得します:
```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)にあります。オーバーライドする必要がある値のみを変更してください。
### 完全な例
これは、GCP Kubernetes を使用した GCP Ingress および GCS（GCP オブジェクトストレージ）を使用した設定例です：
```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
```
### ホスト
```yaml theme={null}
# プロトコルと共に完全修飾ドメイン名を提供
global:
# ホスト名の例、独自のものに置き換え
host: https://wandb example com
```
### オブジェクトストレージ (バケット)
**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` にする必要があります。
`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
```
`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
```
### ライセンス
```yaml theme={null}
global:
# 例のライセンス、独自のものに置き換え
license: eyJhbGnUzaHgyQjQy...VFnPS_KETXg1hi
```
`license` をシークレットから参照するには：
```yaml theme={null}
global:
licenseSecret:
name: license-secret
key: CUSTOMER_WANDB_LICENSE
```
### Ingress
Kubernetes ingress クラスを識別する方法については、FAQ [エントリ](#how-to-identify-the-kubernetes-ingress-class)を参照してください。
**TLS なし**
```yaml theme={null}
global:
# 重要: Ingress は YAML の `global` と同じレベルにあります（子ではありません）
ingress:
class: ""
```
**TLS 使用**
証明書が含まれるシークレットを作成します
```console theme={null}
kubectl create secret tls wandb-ingress-tls --key wandb-ingress-tls.key --cert wandb-ingress-tls.crt
```
Ingress 設定でシークレットを参照します
```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 ポッドを実行するためにカスタム Kubernetes Service Account を指定します。
次のスニペットは、指定された名前でデプロイメントの一部としてサービスアカウントを作成します：
```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: ""
```
`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 サーバーアドレスには "ldap://" または "ldaps://" を含める
host:
# ユーザーを見つけるために使用する LDAP 検索ベース
baseDN:
# バインドに使用する LDAP ユーザー（匿名バインドを使用しない場合）
bindDN:
# バインドに使用する LDAP パスワードを含むシークレットの名前とキー（匿名バインドを使用しない場合）
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 サーバーアドレスには "ldap://" または "ldaps://" を含める
host:
# ユーザーを見つけるために使用する LDAP 検索ベース
baseDN:
# バインドに使用する LDAP ユーザー（匿名バインドを使用しない場合）
bindDN:
# バインドに使用する LDAP パスワードを含むシークレットの名前とキー（匿名バインドを使用しない場合）
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 サーバーアプリケーションのみに適用されます。
```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-----
```
証明書機関を 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` だけが有効な値です。 他の値はエラーです。
アプリケーションポッドを設定するには、設定に `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` にも適用されます。
## Configuration Reference for W\&B Operator
このセクションでは、W\&B Kubernetes オペレーター（`wandb-controller-manager`）の設定オプションを説明しています。オペレーターは、YAML ファイルの形式でその設定を受け取ります。
デフォルトでは、W\&B Kubernetes オペレーターには設定ファイルは必要ありません。必要な場合にだけ設定ファイルを作成します。たとえば、カスタム証明書機関を指定したり、エアギャップ環境にデプロイしたりする必要がある場合などです。
仕様のカスタマイズの完全なリストは、[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
### 各個別のポッドの役割/目的は何ですか？
* **`wandb-app`**: W\&B の中枢であり、GraphQL API およびフロントエンドアプリケーションを含みます。これは私たちのプラットフォームの大部分の機能を提供します。
* **`wandb-console`**: 管理コンソールであり、`/console` を通じてアクセスできます。
* **`wandb-otel`**: OpenTelemetry エージェントであり、Kubernetes レイヤーでのリソースからメトリクスおよびログを収集して管理コンソールに表示します。
* **`wandb-prometheus`**: Prometheus サーバーであり、管理コンソールに表示するためにさまざまなコンポーネントからメトリクスを収集します。
* **`wandb-parquet`**: `wandb-app` ポッドとは別のバックエンドマイクロサービスであり、データベースデータを Parquet 形式でオブジェクトストレージにエクスポートします。
* **`wandb-weave`**: UI でクエリテーブルをロードし、さまざまなコアアプリ機能をサポートする別のバックエンドマイクロサービス。
* **`wandb-weave-trace`**: LLM ベースのアプリケーションを追跡、実験、評価、展開、および改善するためのフレームワーク。このフレームワークは `wandb-app` ポッドを介してアクセスできます。
### W\&B オペレーターコンソールパスワードの取得方法
[W\&B Kubernetes オペレーターマネジメントコンソールへのアクセス](#access-the-wb-management-console)を参照してください。
### Ingress が機能しない場合に W\&B Operator Console にアクセスする方法
Kubernetes クラスターに到達可能なホストで以下のコマンドを実行してください：
```console theme={null}
kubectl port-forward svc/wandb-console 8082
```
`https://localhost:8082/` console でブラウザからコンソールにアクセスしてください。
コンソールのパスワードの取得方法については、[W\&B Kubernetes オペレーターマネジメントコンソールへのアクセス](#access-the-wb-management-console)（Option 2）を参照してください。
### W\&B Server のログを表示する方法
アプリケーションポッドの名前は **wandb-app-xxx** です。
```console theme={null}
kubectl get pods
kubectl logs wandb-XXXXX-XXXXX
```
### Kubernetes ingress クラスを識別する方法
クラスターにインストールされている ingress クラスを取得するには、次のコマンドを実行します:
```console theme={null}
kubectl get ingressclass
```