Table of Contents
Authlete レジストリから Helm チャートおよびコンテナイメージにアクセスするには、以下の手順に従ってください。
kubectl create ns authlete
以下のコマンドを使用してログインします:
helm registry login -u <ORG_ID> -p <TOKEN> artifacts.authlete.com
<ORG_ID>
および <TOKEN>
を実際の値に置き換えてください。
ログインが完了すると、レジストリから Helm チャートを取得できるようになります。
Authlete の Helm チャートは OCI フォーマットで配布されています。以下のコマンドでチャートを取得してローカルに展開します:
# 安定版の最新バージョンは 1.0.0
helm pull oci://artifacts.authlete.com/authlete-platform-chart --version 1.0.0 --untar
cd authlete-platform-chart
Authlete のコンテナイメージへのアクセスには 2 つのオプションがあります:
オプション A: 直接レジストリアクセス(開発/評価環境)
開発または評価目的の環境では、Authlete のレジストリから直接イメージを取得可能です:
# レジストリ認証用のシークレットを作成
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: イメージのミラー(本番環境推奨)
本番環境では、イメージのミラー セクションを参照し、イメージをプライベートレジストリにミラーリングしてください。
信頼性と制御性を高めるため、Authlete 提供のコンテナイメージを自社のレジストリにミラーリングすることを推奨します。これにより、Authlete のレジストリへの直接依存を避け、再現性のあるデプロイが可能になります。
イメージ | 説明 | 対応バージョンタグ |
---|---|---|
server | OAuth 2.0 および OpenID Connect 処理を担うコア API サーバー | 3.0.11 |
server-db-schema | API サーバー用の DB スキーマ初期化ツール | v3.0.11 |
idp | ユーザー認証と管理を行う ID プロバイダサーバー | 1.0.5 |
idp-db-schema | IDP サーバー用の DB スキーマ初期化ツール | v1.0.5 |
console | プラットフォーム設定および監視用の React ベース管理コンソール | v1.0.5 |
authlete-nginx | TLS 終端とルーティングを担当する Nginx リバースプロキシ | 1.26.3 |
valkey | パフォーマンス向上と DB 負荷軽減のためのキャッシュサービス | 8.0.1 |
gce-proxy | GCP 環境での安全な DB 接続のための Cloud SQL プロキシ | 1.34.0 |
authlete-bootstrapper | プラットフォーム初回デプロイ時のみ使用される初期化サービス | 1.0.0 |
# 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 を使用してイメージを直接プッシュすることもできます。
# 対象レジストリのベースを設定
TARGET_REGISTRY="ghcr.io/your-org-name"
# イメージのコピーコマンド
crane cp artifacts.authlete.com/server:3.0.11 $TARGET_REGISTRY/server:3.0.11
crane cp artifacts.authlete.com/server-db-schema:v3.0.11 $TARGET_REGISTRY/server-db-schema:v3.0.11
crane cp artifacts.authlete.com/idp:1.0.5 $TARGET_REGISTRY/idp:1.0.5
crane cp artifacts.authlete.com/idp-db-schema:v1.0.5 $TARGET_REGISTRY/idp-db-schema:v1.0.5
crane cp artifacts.authlete.com/console:v1.0.5 $TARGET_REGISTRY/console:v1.0.5
crane cp artifacts.authlete.com/authlete-nginx:1.26.3 $TARGET_REGISTRY/authlete-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.34.0 $TARGET_REGISTRY/gce-proxy:1.34.0
crane cp artifacts.authlete.com/authlete-bootstrapper:1.0.0 $TARGET_REGISTRY/authlete-bootstrapper:1.0.0
デフォルトの values.yaml
はチャートに同梱されています。カスタム設定のために中身を確認・修正できます。
global.repo
を自社レジストリに設定します:
global:
id: "authlete-platform"
repo: "registry.your-company.com" # 必須: 自社のコンテナレジストリ
domains
セクションに設定します: # 必須: これらのドメインは利用者からアクセス可能である必要があります
api: "api.your-domain.com" # API サーバー
idp: "login.your-domain.com" # IDP サーバー
console: "console.your-domain.com" # 管理コンソール
authlete
ネームスペースに kubernetes.io/tls
タイプの Kubernetes シークレットを作成してください。証明書はすべてのドメイン(例: api.example.com、login.example.com、console.example.com)をカバーしている必要があります。ワイルドカードまたは SAN 証明書を使用できます。kubectl create secret tls proxy-certs \
--cert=./tls.crt \
--key=./tls.key \
-n authlete
このプラットフォームでは、API サーバー用と IDP サーバー用に 2 つのデータベースが必要です。接続情報は secret-values.yaml
に設定してください。
注:MySQL 8.0+ を利用する場合、以下の設定が必要です:
- Character set:
utf8mb4
- Collation:
utf8mb4_0900_ai_ci
secret-values.yaml
ファイルも含まれています。これを自社のデータベースおよび Authlete 管理者アカウント用に修正してください。database:
idp: # IDP サーバー用データベース
name: idp
user: authlete
password: !raw ***** # パスワード
host: localhost
connectionOpts: "sslMode=DISABLED&useSSL=false&allowPublicKeyRetrieval=true" # 必要に応じて追加設定
api: # API サーバー用データベース
name: server
user: authlete
password: !raw ******
host: localhost
connectionOpts: "sslMode=DISABLED&useSSL=false&allowPublicKeyRetrieval=true" # 必要に応じて追加設定
idp:
auth:
adminUser:
email: "admin@authlete.com"
password: !raw ******
encryptionSecret: ********
GCP Cloud SQL を使用する場合:
cloudSql:
enabled: true
image: gce-proxy:1.34.0
instance: project:region:instance # Cloud SQL インスタンス名
port: 3306
他のクラウドプロバイダーを使用する場合は、Cloud SQL プロキシを無効にして直接接続を使用します:
cloudSql:
enabled: false
このプラットフォームは 2 種類のキャッシュ構成に対応しています:
デフォルトでは、キャッシュとして Valkey Pod をデプロイします。この構成は values.yaml
に定義されており、そのまま使用可能です:
redis:
name: redis
enabled: true
image: valkey:8.0.1
# -- リソース要件
resources:
requests:
cpu: 10m
memory: 440M
limits:
cpu: 1
memory: 440M
本番環境ではマネージドキャッシュサービスの利用を推奨します。以下のサービスに対応しています:
GCP 利用者への注意:Memorystore for Valkey を使用する際は、Private Service Connect(PSC)とサービス接続ポリシーを利用した接続を推奨します。これがサポートされている唯一のネットワーク方式です。詳細な手順は Memorystore for Valkey ネットワーク構成ガイド を参照してください。
マネージドキャッシュサービスを使用するには:
values.yaml
内で Valkey を無効化します:redis:
enabled: false
api:
env:
- name: MEMCACHE_ENABLE
value: "true"
- name: MEMCACHE_HOST
value: "<your-cache-service-host-or-ip>" # ホスト名または IP アドレス
注:キャッシュサービスがクラスターモードの場合は以下の環境変数も追加してください:
- name: MEMCACHE_BACKEND
value: "redis-cluster"
Helm を使用してコアコンポーネントをインストールします:
helm install authlete-platform . -n authlete -f secret-values.yaml
インストールの確認:
# 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
redis-5f8f64df5d-xxxxx 1/1 Running 0 2m
注意:初回のデプロイにはイメージの取得とデータベース初期化のために最大 5 分程度かかることがあります。
以下のコンポーネントは要件に応じてインストールが可能です:
インストールコマンド:
helm upgrade authlete-platform . -f secret-values.yaml -n authlete
オプションコンポーネントの確認:
# 新しい 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
最後のステップとして、Authlete デプロイメントを外部に公開するためのロードバランサーサービスを構成します。
注意:以下のコマンドは GCP 専用です。他のクラウドプロバイダー(AWS、Azure など)を使用している場合は、各プロバイダーのドキュメントを参照して静的 IP アドレスを予約してください。
GCP では、GKE LoadBalancer サービスが同じリージョンに割り当てられた IP のみをサポートするため、リージョン固定の静的 IP を予約する必要があります。
# GCP 固有のコマンド
# 静的 IP アドレスを予約
gcloud compute addresses create authlete-ip --region=us-central1
# 予約済み IP アドレスを取得
gcloud compute addresses describe authlete-ip --region=us-central1
proxy-lb-service.yaml
というファイルを作成してください: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 を入力
kubectl apply -f proxy-lb-service.yaml -n authlete
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 を通じてアクセス可能になります。
3 つのドメインすべてに対して、ロードバランサーの IP アドレスを指すように DNS レコードを作成してください:
# 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 設定の確認:
# 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 は利用準備が整っています。
次の手順で管理コンソールにアクセスできます:
https://console.your-domain.com
にアクセスsecret-values.yaml
に設定した管理者アカウントでログイン注意:コンソールにアクセスできない場合は、以下の項目を確認してください:
- DNS レコードがすべてのネームサーバーに伝播されているか
- ロードバランサーのヘルスチェックが成功しているか
- TLS 証明書がすべてのドメインに対して有効であるか