> ## Documentation Index
> Fetch the complete documentation index at: https://developers.authlete.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Kubernetes インストールガイド

> Kubernetes 環境において Helm を使用して Authlete をデプロイするための Kubernetes インストールガイドをご覧ください。

## 前提条件

* MySQL インスタンス（v8.0+）にアクセス可能な Kubernetes クラスター（v1.24 以降）
* 最低限必要なクラスターリソース：4 vCPU、16GB RAM
* テーブルに対する読み書きおよび削除権限を持つデータベース認証情報
* Helm（バージョン 3.17.0 以降）
* API、Console、IDP エンドポイント用のドメイン名

## インストール手順

Authlete レジストリから Helm チャートおよびコンテナイメージにアクセスするには、以下の手順に従ってください。

### セットアップフェーズ

#### 1. 組織の作成

* [Authlete Console](https://console.authlete.com) にログインします。
* 自社用の組織を作成します。
* **Organization ID** を控えておきます。

![new-org](https://storage.googleapis.com/authlete-website/resources/tutorial-getting-started-images/8.png)

#### 2. アクセスのリクエスト

* **Organization ID** と **Organization Name** を Authlete サポートに共有します。
* Authlete は、あなたの組織に対してレジストリアクセスを許可します。

#### 3. 組織トークンの発行

* Authlete Console にて、組織用の **Token** を発行します。
* **Organization ID** と **Token** は認証に必要なので手元に保持しておいてください。

![user-permissions](https://storage.googleapis.com/authlete-website/resources/terraform/starting/2.png)

### 準備フェーズ

#### 1. Kubernetes ネームスペースの作成

```bash theme={null}
kubectl create ns authlete
```

#### 2. Helm レジストリへのログイン

以下のコマンドを使用してログインします：

```bash theme={null}
helm registry login -u <ORG_ID> -p <TOKEN> artifacts.authlete.com
```

`<ORG_ID>` および `<TOKEN>` を実際の値に置き換えてください。

ログインが完了すると、レジストリから Helm チャートを取得できるようになります。

#### 3. Helm チャートの取得

Authlete の Helm チャートは OCI フォーマットで配布されています。以下のコマンドでチャートを取得してローカルに展開します：

```bash theme={null}
# 安定版の最新バージョンは 2.1.3
helm pull oci://artifacts.authlete.com/authlete-platform-chart --version 2.1.3 --untar
cd authlete-platform-chart
```

#### 4. イメージレジストリの設定

Authlete のコンテナイメージへのアクセスには 2 つのオプションがあります：

**オプション A: 直接レジストリアクセス（開発／評価環境）**

開発または評価目的の環境では、Authlete のレジストリから直接イメージを取得可能です：

```bash theme={null}
# レジストリ認証用のシークレットを作成
kubectl create secret docker-registry authlete-registry \
-n authlete \
--docker-server=artifacts.authlete.com \
--docker-username=<ORG_ID> \
--docker-password=<TOKEN>

# デフォルトの ServiceAccount にこのシークレットを設定
kubectl patch serviceaccount default \
-n authlete \
-p '{"imagePullSecrets": [{"name": "authlete-registry"}]}'
```

**オプション B: イメージのミラー（本番環境推奨）**

本番環境では、[イメージのミラー](#5-mirror-images) セクションを参照し、イメージをプライベートレジストリにミラーリングしてください。

#### 5. イメージのミラー

信頼性と制御性を高めるため、Authlete 提供のコンテナイメージを自社のレジストリにミラーリングすることを推奨します。これにより、Authlete のレジストリへの直接依存を避け、再現性のあるデプロイが可能になります。

| イメージ                  | 説明                                            | 対応バージョンタグ |
| --------------------- | --------------------------------------------- | --------- |
| server                | OAuth 2.0 および OpenID Connect 処理を担うコア API サーバー | 3.0.27    |
| server-db-schema      | API サーバー用の DB 初期化ツール                          | v3.0.27   |
| idp                   | ユーザー認証と管理を行う ID プロバイダサーバー                     | 1.0.23    |
| idp-db-schema         | IdP サーバー用のデータベーススキーマ初期化ツール                    | v1.0.23   |
| console               | プラットフォーム設定および監視用の React ベース管理コンソール            | 1.0.17    |
| nginx                 | TLS 終端とルーティングを担当する Nginx リバースプロキシ             | 1.29.1    |
| valkey                | パフォーマンス向上と DB 負荷軽減のためのキャッシュサービス               | 8.0.1     |
| gce-proxy             | GCP 環境での安全な DB 接続のための Cloud SQL プロキシ          | 1.37.0    |
| authlete-bootstrapper | プラットフォーム初回デプロイ時のみ使用される初期化サービス                 | 1.1.0     |

```bash theme={null}
# Authlete レジストリにログイン
docker login artifacts.authlete.com -u <ORG_ID> -p <TOKEN>

# イメージを取得
docker pull artifacts.authlete.com/<image>:<tag>

# タグを付けて自社レジストリにプッシュ
docker tag artifacts.authlete.com/<image>:<tag> registry.mycompany.com/<image>:<tag>
docker push registry.mycompany.com/<image>:<tag>
```

`values.yaml` を更新して、インストール前にミラーしたイメージパスを使用してください。

代替として、[crane](https://github.com/google/go-containerregistry/tree/main/cmd/crane) を使用してイメージを直接プッシュすることもできます。

##### crane を使用したミラー

```bash theme={null}
# 対象レジストリのベースを設定
TARGET_REGISTRY="ghcr.io/your-org-name"

# イメージコピーコマンド
crane cp artifacts.authlete.com/server:3.0.19 $TARGET_REGISTRY/server:3.0.19
crane cp artifacts.authlete.com/server-db-schema:v3.0.19 $TARGET_REGISTRY/server-db-schema:v3.0.19
crane cp artifacts.authlete.com/idp:1.0.18 $TARGET_REGISTRY/idp:1.0.18
crane cp artifacts.authlete.com/idp-db-schema:v1.0.18 $TARGET_REGISTRY/idp-db-schema:v1.0.18
crane cp artifacts.authlete.com/console:1.0.11 $TARGET_REGISTRY/console:1.0.11
crane cp artifacts.authlete.com/nginx:1.26.3 $TARGET_REGISTRY/nginx:1.26.3
crane cp artifacts.authlete.com/valkey:8.0.1 $TARGET_REGISTRY/valkey:8.0.1
crane cp artifacts.authlete.com/gce-proxy:1.37.0 $TARGET_REGISTRY/gce-proxy:1.37.0
crane cp artifacts.authlete.com/authlete-bootstrapper:1.1.0 $TARGET_REGISTRY/authlete-bootstrapper:1.1.0
```

### 設定フェーズ

#### 1. Values とシークレットの設定

* 既定の `values.yaml` はチャートに同梱されています。必要に応じて内容を確認・変更してください。

* `global.repo` を自社レジストリに設定します。

```yaml theme={null}
global:
  id: "authlete-platform"
  repo: "registry.your-company.com"  # 必須: 自社のコンテナレジストリ
```

* ドメイン名を `domains` セクションに設定します：

```yaml theme={null}
  # 必須: これらのドメインは利用者からアクセス可能である必要があります
  api: "api.your-domain.com"     # API サーバー
  idp: "login.your-domain.com"   # IDP サーバー
  console: "console.your-domain.com"  # 管理コンソール
```

#### 2. TLS 証明書の設定

* ドメイン用の TLS 証明書（例: Let's Encrypt や社内の証明機関から取得）を用意し、`authlete` ネームスペースに `kubernetes.io/tls` タイプの Kubernetes シークレットを作成してください。証明書はすべてのドメイン（例: api.example.com、login.example.com、console.example.com）をカバーしている必要があります。ワイルドカードまたは SAN 証明書を使用できます。

```bash theme={null}
kubectl create secret tls proxy-certs \
  --cert=./tls.crt \
  --key=./tls.key \
  -n authlete
```

*注意： proxy-certsを外部シークレットマネージャーから管理する場合は、このステップを省略し、「外部シークレットマネージャー」のセクションをご参照ください。*

#### 3. データベースおよびメモリキャッシュへの TLS 接続を有効化 (任意)

##### アプリケーション設定

環境変数の変更だけで TLS 暗号化を有効化できます。

**Redis**: Redis 接続で TLS 暗号化が必要な場合は、MEMCACHE\_HOST に `rediss://` を指定します。

```yaml theme={null}
cache:
  api:
    enabled: true
    auth:
      enabled: false
    connection:
      tls: true
      host: redis
      port: 6379
  idp:
    enabled: true
    auth:
      enabled: false
    connection:
      tls: true
      host: redis
      port: 6379
```

**Database**: データベースへの TLS 接続は `sslMode` プロパティで有効化します。

```yaml theme={null}
database:
  idp:  # IdP サーバーのデータベース
    name: idp
    host: localhost
    connectionParams:
      allowPublicKeyRetrieval: true
      sslMode: verify-ca # ここで sslMode を設定
  api: # API サーバーのデータベース
    name: server
    host: localhost
    connectionParams:
      allowPublicKeyRetrieval: true
      sslMode: verify-ca # ここで sslMode を設定
```

> **注記**: Cloud SQL Proxy を使用する場合、接続はプロキシにより既に暗号化されるため、sslMode は `disable` を設定してください。追加の TLS 層を有効にすると動作しません。

> **注記**: Redis やデータベースが提示する TLS 証明書がプライベート CA によって発行されている場合は、すべての証明書を含むカスタムバンドルを作成し、アプリケーションに読み込ませる必要があります。詳細は [Private CA](#private-ca-optional) セクションを参照してください。

4. #### Private CA (Optional)

プライベート CA 証明書で TLS を使用するには、必要な証明書をすべて含むカスタムバンドルを Helm チャートの外部で作成します。次に、そのバンドルを含む ConfigMap を作成します。要件は以下のとおりです。

* ConfigMap 名は "custom-ca-bundle" とすること
* 少なくとも `ca-bundle.p12` と `ca-bundle.crt` の 2 つのキーを含めること

##### CA バンドルの作成

[trust-manager のドキュメント](https://cert-manager.io/docs/trust/trust-manager/#securely-maintaining-a-trust-manager-installation) に記載の方法で公開 CA バンドルを抽出することを推奨します。以下では、そのバンドルを含む ConfigMap の作成方法を説明します。

##### trust-manager を使ったバンドル作成 (任意)

trust-manager を使うと、Kubernetes で信頼バンドルの管理が容易になります。インストール手順は [trust-manager の公式ドキュメント](https://cert-manager.io/docs/trust/trust-manager) を参照してください。trust-manager をインストールしたら、単一の Bundle オブジェクトを作成します。必要な証明書をすべて含む ConfigMap は自動的に生成されます。

以下は trust-manager が最終バンドルを組み立てるための `Bundle` の例です。この Bundle のマニフェストファイル名は `bundle-creation.yaml` とします。

```yaml theme={null}
apiVersion: trust.cert-manager.io/v1alpha1
kind: Bundle
metadata:
  name: custom-ca-bundle
spec:
  sources:
  - useDefaultCAs: true

  # A manually specified PEM-encoded cert, included directly into the Bundle
  - inLine: |
      -----BEGIN CERTIFICATE-----
      MIIC5zCCAc+gAwIBAgIBADANBgkqhkiG9w0BAQsFADAVMRMwEQYDVQQDEwprdWJl
      ...
      ... contents of proxy's CA certificate ...
      -----END CERTIFICATE-----
  - inLine: |
      -----BEGIN CERTIFICATE-----
      ... contents of mysql's CA certificate ...
      -----END CERTIFICATE-----
  - inLine: |
      -----BEGIN CERTIFICATE-----
      ... contents of valkey's CA certificate ...
      -----END CERTIFICATE-----
  target:
    # All ConfigMaps will include a PEM-formatted bundle, here named "root-certs.pem"
    # and in this case we also request binary formatted bundles in PKCS#12 format,
    # here named "bundle.p12".
    configMap:
      key: "ca-bundle.crt"
    additionalFormats:
      pkcs12:
        key: "ca-bundle.p12"
    namespaceSelector:
      matchLabels:
        kubernetes.io/metadata.name: "authlete" # Deployment namespace
```

最後に、次のコマンドで Bundle を作成します。

```bash theme={null}
kubectl create -f bundle-creation.yaml -n authlete
```

> **注記**: cert-manager が提供する公式の Debian trust パッケージを使用している場合は、trust パッケージが最新に保たれているか定期的に確認してください。

##### バンドルの手動作成

以下の手順では、docker コマンドを使ってカスタムバンドルを数ステップで作成します。

> **注記**: 以下のチュートリアルはサンプルコードです。バンドルの作成・保管・更新を安全に行うことはお客様の責務です。

1. `gen-bundles.sh` ファイルを作成

```bash theme={null}
# Input/output directories
SRC="/certs"                                         # crt ファイルを配置する場所
DST="/usr/local/share/ca-certificates/custom"        # update-ca-certificates が監視するディレクトリ
OUT="/bundle"                                        # バンドルの出力先

# 出力ディレクトリをクリーンアップ
rm -f $OUT/*

# 出力ディレクトリを作成
mkdir -p "$DST"

# 必要なパッケージをインストール (Java の truststore 生成に ca-certificates-java が必要)
apt-get -y update
apt-cache madison ca-certificates
DEBIAN_FRONTEND=noninteractive apt-get install -y --no-install-recommends openssl default-jre-headless ca-certificates-java "ca-certificates=20230311+deb12u1"

# 1) 追加証明書の配置 (*.pem / *.crt を .crt として配置)
cp -v ${SRC}/* ${DST}/
# .pem も .crt として扱うため拡張子を統一したい場合は以下を有効化
# for f in "$DST"/*.pem; do mv -v "$f" "${f%.pem}.crt"; done

# 2) システム & Java truststore を更新
update-ca-certificates -f

# 3) 出力 (PEM と PKCS12)
cp -v /etc/ssl/certs/ca-certificates.crt "$OUT/ca-bundle.crt"
keytool -importkeystore -srckeystore /etc/ssl/certs/java/cacerts -destkeystore $OUT/ca-bundle.p12 -deststoretype PKCS12 -srcstorepass changeit -deststorepass changeit
```

2. バンドルをビルド

```bash theme={null}
docker run --rm --user root -v "$PWD/certs:/certs:ro" -v "$PWD/out:/bundle" -v "$PWD/gen-bundles.sh:/usr/local/bin/gen-bundles.sh:ro" --entrypoint bash docker.io/library/debian:12-slim -c "sh /usr/local/bin/gen-bundles.sh"
```

3. `ca-bundle.p12` と `ca-bundle.crt` が準備できたら、次のように Kubernetes の ConfigMap を作成します。

```bash theme={null}
kubectl create cm custom-ca-bundle --from-file=ca-bundle.p12 --from-file=ca-bundle.crt
```

> **注記**::
> trust-manager のバンドル作成に使用されている現在の Debian ベースイメージは [docker.io/library/debian:12-slim](https://github.com/cert-manager/trust-manager/blob/main/make/00_debian_bookworm_version.mk) で、ca-certificates のターゲットバージョンは `20230311+deb12u1.0` です。

##### アプリケーションからカスタムバンドルを読み込む

バンドルの準備ができたら、アプリケーションから利用できるように追加設定を行います。`.Values.global.tls.caBundle.enabled` を "true" に設定して、バンドルをアプリケーションの Pod にマウントします。

```yaml theme={null}
  tls:
    caBundle:
      enabled: true # これを有効にする
      type: ConfigMap
      name: custom-ca-bundle
      trustStore:
        password: "changeit"
```

##### バンドルの更新

新しいバンドルを作成して既存のものと置き換えた場合は、IdP、Authlete Server、プロキシの各 Pod (アプリケーション) を再起動してください。再起動時に、アプリケーションが更新後のバンドルを読み込みます。

#### 5. データベース接続を設定

本プラットフォームは 2 つのデータベースを必要とします。1 つは API サーバー用、もう 1 つは IdP サーバー用です。`secret-values.yaml` で接続情報を設定します。

> **注記**: MySQL 8.0+ を使用する場合、データベースは次の設定で構成してください:
>
> * 文字セット: `utf8mb4`
> * 照合順序: `utf8mb4_0900_ai_ci`

* チャートアーカイブには `secret-values.yaml` のテンプレートも同梱されています。データベースおよび Authlete 管理者の資格情報に合わせて修正してください。

```yaml theme={null}
database:
  idp:  # IdP サーバーのデータベース
    user: authlete      # DB ユーザー
    password: !raw ***** # ユーザーパスワード
  api: # API サーバーのデータベース
    user: authlete
    password: !raw ******

idp:
  auth:
    adminUser:
      email: "admin@authlete.com"
      password: !raw ******
  encryptionSecret: ********
```

GCP Cloud SQL を使用する場合：

```yaml theme={null}
  cloudSql:
    enabled: true
    image: gce-proxy:1.37.0
    instance: project:region:instance  # Cloud SQL インスタンス名
    port: 3306
```

他のクラウドプロバイダーを使用する場合は、Cloud SQL プロキシを無効にして直接接続を使用します：

```yaml theme={null}
cloudSql:
  enabled: false
```

> ※ AWS-EKSでMySQLデータベースのDNS名を使用される場合：
> ・RDS-Proxyを使用する場合：`host: sample-db.proxy-stu901vwx234.us-east-1.rds.amazonaws.com`
> ・RDS-Proxyを使用しない場合：`host: sample-db.cluster-stu901vwx234.us-east-1.rds.amazonaws.com`

#### 6. キャッシュの設定

以下が現在サポートされているキャッシュソリューション：

##### マネージドキャッシュサービス

本番環境ではマネージドキャッシュサービスの利用を推奨します。以下のサービスに対応しています：

* **Google Cloud Platform**：Memorystore for Valkey
* **Amazon Web Services**：ElastiCache for Redis or Serverless-Valkey
* **Azure**：Azure Cache for Redis

> **GCP 利用者への注意**：Memorystore for Valkey を使用する際は、Private Service Connect（PSC）とサービス接続ポリシーを利用した接続を推奨します。これがサポートされている唯一のネットワーク方式です。詳細な手順は [Memorystore for Valkey ネットワーク構成ガイド](https://cloud.google.com/memorystore/docs/valkey/networking) を参照してください。

マネージドキャッシュサービスを使用するには、`values.yaml`を下記の通りに編集します：

```yaml theme={null}
cache:
  api:
    enabled: true
    auth:
      enabled: false
    connection:
      tls: false
      host: redis
      port: 6379
  idp:
    enabled: true
    auth:
      enabled: false
    connection:
      tls: false
      host: redis
      port: 6379
```

> **注意**：キャッシュサービスがクラスターモードの場合は以下の環境変数も追加してください：

```yaml theme={null}
    - name: MEMCACHE_BACKEND
      value: "redis-cluster"
```

#### 7. 外部シークレットマネージャー

外部シークレットマネージャーを使用する場合、Helmデプロイに必要なシークレットがクラスター上に存在し、適切に構成されている必要があります。シークレットが見つからない場合は、デプロイおよびアップグレードの工程が失敗します。

必要なシークレットは`authlete-credentials`と`proxy-certs`（`proxy-certs`を外部シークレットマネージャーで管理する場合）です。

##### 外部シークレットマネージャーに`authlete-secret`のシークレットを追加します。

##### Cache Authが無効の場合：

```yaml theme={null}
{
  "database": {
    "idp": {
      "user": "root",
      "password": "<placeholder-idp-db-password>"
    },
    "api": {
      "user": "root",
      "password": "<placeholder-api-db-password>"
    }
  },
  "idp": {
    "adminUser": {
      "email": "admin@authlete.com",
      "password": "mypassword"
    },
    "encryptionSecret": "<placeholder-random-secret>"
  }
}
```

##### Cache Authが有効の場合：

```yaml theme={null}
{
  "database": {
    "idp": {
      "user": "root",
      "password": "<placeholder-idp-db-password>"
    },
    "api": {
      "user": "root",
      "password": "<placeholder-api-db-password>"
    }
  },
  "idp": {
    "adminUser": {
      "email": "admin@authlete.com",
      "password": "mypassword"
    },
    "encryptionSecret": "<placeholder-random-secret>"
  },
  "cache": {
    "api": {
      "auth": {
        "user": "default",
        "password": "<placeholder-api-cache-password>"
      }
    },
    "idp": {
      "auth": {
        "user": "default",
        "password": "<placeholder-idp-cache-password>"
      }
    }
  }
}
```

```yaml theme={null}
<ClusterSecretStore-name>をクラスターのClusterSecretStore名に置き換えてください。

kubectl apply -f - <<EOF
apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
  name: authlete-secret
  namespace: authlete
spec:
  refreshInterval: 30s
  secretStoreRef:
    kind: ClusterSecretStore
    name: <ClusterSecretStore-name>
  target:
    name: authlete-credentials
    creationPolicy: Owner
  data:
  # IDP Database
  - secretKey: authlete-idp-db-user
    remoteRef:
      key: authlete-secret
      property: database.idp.user
  - secretKey: authlete-idp-db-password
    remoteRef:
      key: authlete-secret
      property: database.idp.password
  # Cache Authが有効になっている場合
  - secretKey: authlete-api-memcache-auth-user
    remoteRef:
      key: authlete-secret
      property: cache.api.auth.user
  - secretKey: authlete-api-memcache-auth-password
    remoteRef:
      key: authlete-secret
      property: cache.api.auth.password
  - secretKey: authlete-idp-memcache-auth-user
    remoteRef:
      key: authlete-secret
      property: cache.idp.auth.user
  - secretKey: authlete-idp-memcache-auth-password
    remoteRef:
      key: authlete-secret
      property: cache.idp.auth.password
  # API Database
  - secretKey: authlete-api-db-user
    remoteRef:
      key: authlete-secret
      property: database.api.user
  - secretKey: authlete-api-db-password
    remoteRef:
      key: authlete-secret
      property: database.api.password
  # IDP Admin
  - secretKey: authlete-idp-admin-email
    remoteRef:
      key: authlete-secret
      property: idp.adminUser.email
  - secretKey: authlete-idp-admin-password
    remoteRef:
      key: authlete-secret
      property: idp.adminUser.password
  - secretKey: authlete-idp-encryption-secret
    remoteRef:
      key: authlete-secret
      property: idp.encryptionSecret
EOF
```

外部シークレットマネージャーでプロキシ証明書（proxy-certs）を管理する場合は、`authlete-proxy-secret`のシークレットを作成してください

```yaml theme={null}
# 外部シークレットマネージャー上に証明書を保存する場合、JSONキーは下記のものと一致しているかご確認ください:
- `tls.crt` for the certificate chain
- `tls.key` for the private key

# 使用例:
{
  "tls.crt": "-----BEGIN CERTIFICATE-----\nMIIE...server-cert-data...==\n-----END CERTIFICATE-----\n-----BEGIN CERTIFICATE-----\nMIIF...intermediate-cert...==\n-----END CERTIFICATE-----",
  "tls.key": "-----BEGIN PRIVATE KEY-----\nMIIE...private-key-data...==\n-----END PRIVATE KEY-----"
}

# TLS証明書の外部シークレットマネージャーへの移行は任意です。
# 移行しない場合は、「インストール手順 → 設定フェーズ → TLS証明書の設定のセクションに従ってTLS証明書を設定してください。
```

```yaml theme={null}
kubectl apply -f - <<EOF
apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
  name: authlete-proxy-secret
  namespace: authlete
spec:
  refreshInterval: 30s
  secretStoreRef:
  # <ClusterSecretStore-name>をクラスターのClusterSecretStore名に置き換えてください。
    kind: ClusterSecretStore
    name: <ClusterSecretStore-name>
  target:
    name: proxy-certs
    creationPolicy: Owner
  data:
  # TLS Certificates
  - secretKey: tls.crt
    remoteRef:
      key: authlete-proxy-secret
      property: tls.crt
  - secretKey: tls.key
    remoteRef:
      key: authlete-proxy-secret
      property: tls.key
EOF

```

**注意**: Helmチャートの`externalSecrets`機能を有効化する場合は、`values.yaml`を下記のように更新して下さい。

```yaml theme={null}
externalSecrets:
  enabled: true  # ESMを有効化する場合は'true' | デフォルト値は'false'
```

#### 8. Podアフィニティの設定

Podアフィニティを有効化するには、`values.yaml`を下記のように編集してください:

```yaml theme={null}
global:
  apiAffinity: true
```

`apiAffinity`はデフォルトとして`false`に設定されており、その場合podアフィニティは無効になります。
Podアフィニティを有効化することによって、API podと同じノードに存在するプロキシpodをスケジューリングすることが可能になり、パーフォーマンスを向上させ、またネットワークレイテンシーを軽減させることができます。

#### 9. その他の設定オプション

##### プロキシ設定

ドメイン名が非常に長い場合、`map_hash_max_size` パラメータの制限に達する可能性があります。`mapHashBucketSize` と `serverNamesHashBucketSize` の値を増やすことで回避できます。

```yaml theme={null}
  configs:
    mapHashBucketSize: 128 # ここを調整
    serverNamesHashBucketSize: 128 # ここを調整
```

##### DB スキーマ更新フック

Liquibase の変更セットに含まれる新しい変更を自動適用し、アプリケーションと同じバージョンのデータベーススキーマを保つため、DB スキーマ更新フックを導入しました。**これらのフックは冪等であり、アップグレード版と旧版の間でスキーマに変更がない限り、既存のデータベーススキーマを変更しません。**

これらのフックは、インストール時およびアプリケーションバージョン更新時にスキーマを作成・更新するために必要です。ただし、新規アプリケーションをデプロイしない、またはスキーマ変更が見込まれない場合は無効化できます。

```yaml theme={null}
hooks:
  serviceAccount: ""
  idpDbSchemaUpgrade:
    enabled: true # 無効化可能
  serverDbSchemaUpgrade:
    enabled: true # 無効化可能
```

### デプロイフェーズ

#### 1. コアプラットフォームコンポーネントのインストール

Helm を使用してコアコンポーネントをインストールします。

##### 外部シークレットマネージャーを使用しない場合:

```bash theme={null}
helm install authlete-platform . -n authlete -f secret-values.yaml
```

##### 外部シークレットマネージャーを使用する場合:

```bash theme={null}
helm install authlete-platform . -n authlete
```

##### インストールの確認：

```bash theme={null}
# Pod のステータス確認
kubectl get pods -n authlete
```

期待される出力例：

```
NAME                       READY   STATUS    RESTARTS   AGE
api-6b78f87847-xxxxx       2/2     Running   0          2m
proxy-6c99bdc94b-xxxxx     1/1     Running   0          2m
```

注意：初回のデプロイにはイメージの取得とデータベース初期化のために最大 5 分程度かかることがあります。

#### 2. オプションコンポーネントのインストール

要件に応じて、以下の任意コンポーネントをインストールすることも可能です。

* 管理コンソール: Authlete プラットフォームの主な設定 UI
* IdP サーバー: ユーザー認証と管理のための OIDC 準拠 IdP

##### 外部シークレットマネージャーを使用しない場合:

```bash theme={null}
helm upgrade authlete-platform . -n authlete -f secret-values.yaml
```

##### 外部シークレットマネージャーを使用する場合:

```bash theme={null}
helm upgrade authlete-platform . -n authlete
```

##### オプションコンポーネントの確認：

```bash theme={null}
# 新しい Pod のステータス確認
kubectl get pods -n authlete
```

期待される出力例：

```
NAME                       READY   STATUS    RESTARTS   AGE
console-6b78f87847-xxxxx   1/1     Running   0          2m
idp-6c99bdc94b-xxxxx       2/2     Running   0          2m
```

#### 3. ロードバランサーの構成

最後のステップとして、Authlete デプロイメントを外部に公開するためのロードバランサーサービスを構成します。

1. まず、クラウドプロバイダーで静的外部 IP アドレスを予約します。

> 注意：以下のコマンドは GCP 専用です。他のクラウドプロバイダー（AWS、Azure など）を使用している場合は、各プロバイダーのドキュメントを参照して静的 IP アドレスを予約してください。\
> **GCP では、GKE LoadBalancer サービスが同じリージョンに割り当てられた IP のみをサポートするため、リージョン固定の静的 IP を予約する必要があります。**

```bash theme={null}
# GCP 固有のコマンド
# 静的 IP アドレスを予約
gcloud compute addresses create authlete-ip --region=us-central1

# 予約済み IP アドレスを取得
gcloud compute addresses describe authlete-ip --region=us-central1
```

2. 予約した IP を使用してロードバランサーサービスを作成します。以下の内容で `proxy-lb-service.yaml` というファイルを作成してください：

**以下がGKEの使用例になります**

```yaml theme={null}
apiVersion: v1
kind: Service
metadata:
  labels:
    app: proxy
  name: proxy-lb
spec:
  externalTrafficPolicy: Local
  ports:
  - name: https
    port: 443
    protocol: TCP
    targetPort: 8443
  selector:
    app: proxy
  sessionAffinity: None
  type: LoadBalancer
  loadBalancerIP: #external_static_ip  # ここに予約済みの静的 IP を入力
```

**以下がAWS-EKSの使用例になります**

```yaml theme={null}
apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-eip-allocations: eipalloc-xxxxxxxxxxxxxxxxx  # Replace with your EIP allocation ID
    service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
    service.beta.kubernetes.io/aws-load-balancer-subnets: subnet-xxxxxxxxx  # Replace with your subnet ID
    service.beta.kubernetes.io/aws-load-balancer-type: external
    service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip
  labels:
    app: proxy
  name: proxy-lb
spec:
  externalTrafficPolicy: Local
  ports:
  - name: https
    port: 443
    protocol: TCP
    targetPort: 8443
  selector:
    app: proxy
  sessionAffinity: None
  type: LoadBalancer
```

3. ロードバランサー設定を適用します：

```bash theme={null}
kubectl apply -f proxy-lb-service.yaml -n authlete
```

4. ロードバランサーの構成を確認します：

```bash theme={null}
kubectl get service proxy-lb -n authlete
```

次のような出力が得られるはずです：

```
NAME       TYPE           CLUSTER-IP      EXTERNAL-IP          PORT(S)         AGE
proxy-lb   LoadBalancer   10.x.x.x        YOUR_STATIC_IP       443:32xxx/TCP   1m
```

`EXTERNAL-IP` に予約した IP アドレスが表示されれば、Authlete デプロイメントは HTTPS 経由でその IP を通じてアクセス可能になります。

#### 4. ドメインとロードバランサーのマッピング

3 つのドメインすべてに対して、ロードバランサーの IP アドレスを指すように DNS レコードを作成してください：

```dns theme={null}
# API サーバー
api.your-domain.com.     IN  A     YOUR_STATIC_IP

# IDP サーバー
login.your-domain.com.   IN  A     YOUR_STATIC_IP

# 管理コンソール
console.your-domain.com. IN  A     YOUR_STATIC_IP
```

DNS 設定の確認：

```bash theme={null}
# DNS 設定のテスト
dig +short api.your-domain.com
dig +short login.your-domain.com
dig +short console.your-domain.com

# HTTPS エンドポイントのテスト
curl -I https://api.your-domain.com/api/info
```

すべてのドメインがロードバランサーの IP に解決され、エンドポイントにアクセス可能であれば、Authlete は利用準備が整っています。

次の手順で管理コンソールにアクセスできます：

1. ブラウザで `https://console.your-domain.com` にアクセス
2. `secret-values.yaml` に設定した管理者アカウントでログイン
3. Authlete サービスの構成を開始

> **注意**：コンソールにアクセスできない場合は、以下の項目を確認してください：
>
> * DNS レコードがすべてのネームサーバーに伝播されているか
> * ロードバランサーのヘルスチェックが成功しているか
> * TLS 証明書がすべてのドメインに対して有効であるか

## Helmチャートチェンジログ

現在のHelmチャートバージョンは`2.1.3`です。

### 2025年11月06日アップデート

* Redisに対してACL(Access Control List)サポートが実装されました

### 2025年10月02日アップデート

* 外部シークレットマネージャーのサポートが実装されました

### 2025年09月12日アップデート

* プライベート証明書認証局（CA）を通したTLS接続のサポートが実装されました
* 不足していた内部接続向けのIPレンジが追加されました
* `map_hash_bucket_size`および`server_names_hash_bucket_size`パラメーターが、より大きな値を受け付けられるように拡張されました