Documentation Index Fetch the complete documentation index at: https://docs.jitera.ai/llms.txt
Use this file to discover all available pages before exploring further.
このガイドでは、Azure ネイティブサービスを使用して Azure AKS に Jitera Self-Hosted をデプロイする手順を説明します。
このガイドの例では、以下のサンプル値を使用しています。実際の値に置き換えてください：
Helmリリース名 / ネームスペース ：jitera（つまりhelm install jitera ./charts/jitera --namespace jitera）— Kubernetesリソース名はこれがプレフィックスとして付与されます（例：jitera-automation-rails、jitera-ultron）リソースグループ ：jitera-rgクラスター名 ：jitera-clusterストレージアカウント ：jiterastoragexxxxコンテナ名 ：jitera-default、jitera-public、jitera-export、jitera-ultronドメイン ：jitera.yourdomain.comシークレット名 ：jitera-registry（イメージプルシークレット）、jitera-tls（TLS証明書） 前提条件チェックリスト まずデプロイ要件 のチェックリストを完了してから、以下のAzure固有の項目を確認してください：
Azure インフラストラクチャのセットアップ このセクションのAzure CLIコマンドは例として提供されています。お客様の環境では異なる設定が必要な場合があります。詳細な手順については、Azureの公式ドキュメントを参照してください。 本番環境で外部マネージドサービス（Azure Database for PostgreSQL、Cosmos DB、Azure Cache for Redis、Azure Communication Services）を使用する場合 ：これらのサービスの作成をAKSクラスター作成（ステップ 1）と並行して開始してください。マネージドデータベースは通常10〜20分で利用可能になり、Helmインストール実行前に準備が完了している必要があります。設定の詳細は外部Azureサービス セクションを参照してください。ステップ 1: リソースグループと AKS クラスターの作成 クラスター仕様 を満たすAKSクラスターを作成します。以下はAzure CLIを使用した例です：この例では3x Standard_D4s_v3ノード（合計12 vCPU、48 GB）をプロビジョニングしており、評価環境の最小値 を満たしています。本番環境のデプロイメントでは、Standard_D8s_v3インスタンスを使用するか、ノード数を増やして本番環境の最小値 （16コア、64 GB）を満たしてください。サイジングガイド でティア推奨事項を参照してください。 # 変数を設定 export RESOURCE_GROUP = "jitera-rg" export LOCATION = "japaneast" export CLUSTER_NAME = "jitera-cluster" # リソースグループを作成 az group create --name $RESOURCE_GROUP --location $LOCATION # AKS クラスターを作成 az aks create \ --resource-group $RESOURCE_GROUP \ --name $CLUSTER_NAME \ --node-count 3 \ --node-vm-size Standard_D4s_v3 \ --kubernetes-version 1.35 \ --enable-managed-identity \ --generate-ssh-keys # 認証情報を取得 az aks get-credentials --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME
この例ではシンプルさのためデフォルトネットワークを使用しています。本番環境のデプロイメントでは、ネットワーク分離のためにカスタムVNet、サブネット、ネットワークセキュリティグループ（NSG）を設定してください。AKSネットワークドキュメント を参照してください。 ロードバランサーとインバウンドIP制限。 Jiteraは、Kongイングレスコントローラー経由で**Azure Standard Load Balancer（SLB）**をデフォルトでプロビジョニングします。Application GatewayとFront Doorはイングレス層としてはサポートされていません（ただしWAF用途でSLBの前段 に配置することは可能です — 下記を参照）。Layer-4のIP許可リストには、Network Security Group（NSG）を事前に作成し、AKSノードサブネットに関連付けてください。これによりNSGのライフサイクルをHelmチャートから切り離し、サブネット境界でトラフィックをフィルタリングできます（SLBのDSRセッション追跡パスの外側）。Azureでは kong.proxy.loadBalancerSourceRanges（および service.beta.kubernetes.io/azure-allowed-ip-ranges アノテーション）を使用しないでください 。Standard LBのフロントエンドにソース範囲フィルタを適用すると、同一VNet内のヘアピン通信が失敗します — Podから自LBのパブリックIPへの接続（Boost → Automation、jitera init、cert-manager HTTP-01自己チェック）がSYN受信後、SYN-ACKの戻り経路でドロップされます。このDSRセッション追跡のバグはLBのフロントエンドでフィルタを適用した場合にのみ発生し、サブネットNSGでは発生しません。 NSGのインバウンドルールには、最低限以下を含める必要があります：
信頼できるクライアントCIDR（オフィス / VPN）からの 443/tcp
VirtualNetwork サービスタグからの 443/tcp（Podヘアピン通信および公開Ingressドメインへのクラスター内トラフィックに必要）その他すべてを明示的な Deny-All ルールで拒否（またはデフォルト拒否に依存）
詳細は AKSネットワークセキュリティのドキュメント および NSGの概要 を参照してください。 Azure WAF。 Azure Standard Load BalancerはL4専用のため、WAFは提供されません。L7 WAFが必要な場合は、Azure Application Gateway with WAF_v2 または Azure Front Door with WAF をSLBの前段に配置してください。これらはKongの前段に位置し — Kongは引き続きクラスター内部のイングレスとして機能します。
信頼済みプロキシ。 本番環境では、kong.env.trusted_ips（チャートのデフォルトは 0.0.0.0/0,::/0）とJiteraアプリケーション層の信頼済みプロキシを、LB / Application Gateway / Front DoorのソースCIDRに絞り込んでください。信頼済みプロキシ を参照してください。AKSのネットワーク。 JiteraはAzure CNI （従来の / ノードサブネットモード）で動作検証されています — Azure CNI OverlayおよびCiliumデータプレーンは対象外 です。PodのIPはノードサブネットから払い出されるため、そのサブネットにアタッチしたNSGはノードとPodの両方に適用されます — これが上記のインバウンドIP制限が前提とする動作です。az aks create のCLIバージョンが別モードをデフォルトにしている場合は、明示的に --network-plugin azure を指定してください。
カスタム VNet には Network Contributor ロールが必要です。 AKS を Bring-Your-Own（BYO）VNet にデプロイする場合、クラスターのマネージド ID はサブネットに参加する権限を自動的には持ちません。LoadBalancer Service のパブリック IP のプロビジョニングに失敗し、Service のイベントに LinkedAuthorizationFailed エラーが表示されて <pending> 状態のまま停止します。AKS クラスターのシステム割り当てマネージド ID に対して、サブネットスコープで Network Contributor ロールを付与してください： # AKS マネージド ID のプリンシパル ID を取得 PRINCIPAL_ID = $( az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME \ --query identity.principalId -o tsv ) # サブネット ID を取得 SUBNET_ID = $( az network vnet subnet show --resource-group $RESOURCE_GROUP \ --vnet-name < vnet-nam e > --name < subnet-nam e > --query id -o tsv ) # Network Contributor ロールを付与 az role assignment create \ --assignee " $PRINCIPAL_ID " \ --role "Network Contributor" \ --scope " $SUBNET_ID "
デフォルトの AKS 管理 VNet を使用する場合は不要です。 クラスター作成の詳細な手順については Azure Kubernetes Serviceドキュメント を参照してください。
ステップ 2: ストレージアカウントの作成 ストレージ設定 に記載されたアクセスレベルでストレージアカウントと4つのコンテナを作成し、ストレージアカウントにCORSを設定します。
パブリック コンテナのアクセスレベルは**Blob（Blobの匿名読み取りアクセスのみ）**に設定する必要があります。その他のコンテナはプライベートのままにしてください。CORSのAllowedOriginsには、メインドメインとチャットドメインの両方 を含める必要があります（例：https://app.example.com と https://chat.example.com）。オリジンが不足していると、アプリケーションでファイルアップロードが失敗します。
デフォルトバケットとパブリックバケットに必要なCORSルールについては、オブジェクトストレージ — CORS設定 を参照してください。
ストレージアカウントの作成については Azure Blob Storageドキュメント 、CORS設定 を参照してください。
Helm設定 storage : provider : AzureStorage secret : azure : STORAGE_ACCOUNT_NAME : "jiterastoragexxxx" STORAGE_ACCESS_KEY : "<YOUR_ACCESS_KEY>" CONTAINER : "jitera-default" PUBLIC_CONTAINER : "jitera-public" EXPORT_PROJECT_CONTAINER : "jitera-export" ULTRON_CONTAINER : "jitera-ultron"
Helmチャートにはストレージアカウントのアクセスキー（STORAGE_ACCOUNT_NAMEとSTORAGE_ACCESS_KEY）が必要です。ワークロードIDおよびマネージドIDは、アプリケーションストレージでは現在サポートされていません。アクセスキーはストレージアカウントへのフルアクセスを提供します — ストレージアカウントをJitera専用にするか、Azureストレージファイアウォール を使用してネットワークアクセスを制限してください。
ステップ 3: メールサービスの設定 メール配信用にAzure Communication Servicesをセットアップします。詳細な最新の手順については Azure Communication Servicesドキュメント を参照してください。
# Communication Service の作成 az communication create \ --name jitera-comm \ --resource-group jitera-rg \ --location global \ --data-location unitedstates
AzureポータルでCommunication Servicesに移動します
メール > ドメイン > ドメインの接続 に移動しますEmail Communication Service を選択し、AzureManagedDomain を接続します
接続されたドメインの MailFrom アドレスを確認します（形式：DoNotReply@<random-uuid>.azurecomm.net）
Entra ID アプリケーション 経由でSMTP認証情報を作成します — Azure Communication Services SMTP認証 を参照してください SMTP認証情報はCommunication Serviceの接続文字列やアクセスキーとは異なります 。SMTPユーザー名は3つのEntra ID値（<communication-service-name>.<entra-app-client-id>.<tenant-id>）から構成され、パスワードはEntra IDアプリケーションのクライアントシークレットです。az communication list-key の出力をSMTP認証に使用しないでください。
Helm設定 mailer : smtp_settings : address : smtp.azurecomm.net user_name : "<ACS_SMTP_USERNAME>" password : "<ACS_SMTP_PASSWORD>" default_from_email : "DoNotReply@<random-uuid>.azurecomm.net" # Azureポータルの MailFrom アドレスと一致させる必要があります
ステップ 4: TLS 証明書のセットアップ 証明書は両方 のホスト名（メインドメインとチャットドメイン）をカバーする必要があります。
Let’s Encryptによる自動証明書管理のためにcert-managerをインストールします。インストールとClusterIssuerの設定については cert-managerドキュメント を参照してください。
例：cert-manager のインストールと ClusterIssuer の作成
helm repo add jetstack https://charts.jetstack.io helm repo update helm install cert-manager jetstack/cert-manager \ --namespace cert-manager \ --create-namespace \ --set crds.enabled= true
# cluster-issuer.yaml apiVersion : cert-manager.io/v1 kind : ClusterIssuer metadata : name : letsencrypt-prod spec : acme : server : https://acme-v02.api.letsencrypt.org/directory email : admin@yourdomain.com privateKeySecretRef : name : letsencrypt-prod solvers : - http01 : ingress : class : kong
kubectl apply -f cluster-issuer.yaml
上記のHTTP-01ソルバーでは、KongがACMEチャレンジリクエスト（/.well-known/acme-challenge/）を正しくルーティングする必要があります。証明書の発行に失敗する場合は、Ingressルーティングの依存関係を回避できるDNS-01ソルバー の使用を検討してください。 Helm valuesではcert-manager.io/cluster-issuer: letsencrypt-prodアノテーションを使用して自動的に証明書をリクエストします（ステップ3: Valuesファイルの作成を参照）。 Jitera のインストール ステップ 1: Namespace とレジストリシークレットの作成 kubectl create namespace jitera kubectl create secret docker-registry jitera-registry \ --namespace jitera \ --docker-server=registry.jitera.com \ --docker-username= "your-username" \ --docker-password= "your-password"
シークレット名（jitera-registry）はHelm valuesファイルのimagePullSecretsエントリと一致する必要があります。不一致の場合、すべてのPodでイメージプルが失敗します。
ステップ 2: Values ファイルの作成 Azureデプロイメント用のvaluesファイルを作成します。すべてのプレースホルダー値（<...>）を実際の設定に置き換えてください。ここに記載されていないパラメータはデフォルト値が使用されます — 完全なリストはHelm Valuesリファレンス を参照してください。
# values-azure.yaml # ============================================================ # コア設定 — 以下のパラメータはすべてオーバーライドが必要です # ============================================================ # --- レジストリ認証情報（Jiteraから提供） --- registryCredentials : server : "<REGISTRY_URL>" username : "<REGISTRY_USERNAME>" password : "<REGISTRY_PASSWORD>" email : "<REGISTRY_EMAIL>" # --- ドメイン --- ingress : domainName : "app.yourdomain.com" chatDomainName : "chat.yourdomain.com" # --- JWT --- jwt : secret : "<GENERATE_WITH_pwgen_64_1>" # --- 内部シークレット（それぞれユニークな値を生成） --- automation : env : PUBLIC_OPEN_AI_INTERNAL_SECRET : "<GENERATE_RANDOM_SECRET>" ultron : secret : PUBLIC_OPEN_AI_INTERNAL_SECRET : "<SAME_VALUE_AS_ABOVE>" credentials : hasura : HASURA_GRAPHQL_ADMIN_SECRET : "<GENERATE_RANDOM_SECRET>" boost : JITERA_BOOST_API_KEY_MAIN : "<GENERATE_WITH_pwgen_32_1>" JITERA_BOOST_AUTO_API_KEY : "<SAME_AS_HASURA_ADMIN_SECRET>" JITERA_BOOST_OPENAI_KEY_LITELLM : "<GENERATE_WITH_pwgen_32_1>" JITERA_BOOST_ROLLBAR_ACCESS_TOKEN : "" # Rollbarトークンを設定するか空のまま html_conversion : BEARER_TOKEN : "<GENERATE_WITH_pwgen_32_1>" # --- データベース認証情報（クラスター内） --- postgresql : postgresql : username : "<DB_USERNAME>" password : "<DB_PASSWORD>" database : "<DB_NAME>" postgresPassword : "<POSTGRES_SUPERUSER_PASSWORD>" pgvector : postgresql : username : "<PGVECTOR_USERNAME>" password : "<PGVECTOR_PASSWORD>" database : "<PGVECTOR_DB_NAME>" mongodb : auth : databases : [ "<MONGO_DB_NAME>" ] usernames : [ "<MONGO_USERNAME>" ] passwords : [ "<MONGO_PASSWORD>" ] rabbitmq : auth : password : "<RABBITMQ_PASSWORD>" erlangCookie : "<GENERATE_RANDOM_STRING>" # --- ストレージ — Azure Blob Storage --- storage : provider : AzureStorage secret : azure : STORAGE_ACCOUNT_NAME : "<STORAGE_ACCOUNT_NAME>" STORAGE_ACCESS_KEY : "<STORAGE_ACCESS_KEY>" CONTAINER : "jitera-default" ULTRON_CONTAINER : "jitera-ultron" EXPORT_PROJECT_CONTAINER : "jitera-export" PUBLIC_CONTAINER : "jitera-public" document_converter : env : USE_AZURE : "true" ultron : env : STORAGE_DISK : "azure" # --- メール — SMTP --- mailer : smtp_settings : address : "<SMTP_HOST>" user_name : "<SMTP_USERNAME>" password : "<SMTP_PASSWORD>" default_from_email : "noreply@yourdomain.com" # --- 会社情報 --- company : name : "<YOUR_COMPANY_NAME>" brand_name : "<YOUR_BRAND_NAME>" domain : "@yourdomain.com" language : "en" # --- AI / LLMプライマリプロバイダー（1つ選択、下のタブを参照） --- # このコードブロックの下にあるAIプロバイダータブを参照してください。 # ============================================================ # オプション設定 # ============================================================ # 以下はデフォルト値で動作します。必要な場合のみオーバーライドしてください。 # 参照: /ja/self-hosted-v26.02.16.2/reference/helm-values # # インテグレーション: credentials.github.*, credentials.gitlab.*, credentials.figma.* # サインアップ制御: automation.env.SECURED_SIGN_UP, frontend.env.REACT_APP_SECURED_SIGN_UP # StorageClass: postgresql.persistence.storageClassName, mongodb.persistence.storageClass 等 # 外部データベース: externalPostgres.*, externalRedis.*, externalMongodb.*, externalRabbitmq.* # モニタリング: monitoring.* # エラーモニタリング: credentials.rollbar.* # モニタリングドメイン: ingress.grafana.domain, ingress.prometheus.domain
環境がDocker Hubへのアクセスを制限している場合、すべてのイメージの取得先をJitera ACRレジストリに変更できます。設定方法はコンテナレジストリ を参照してください。 AI / LLMプライマリプロバイダー 1つ のプライマリプロバイダーを選択し、対応する設定をvaluesファイルに追加してください。AI_MODE設定はUltronのプライマリLLMルーティングを決定します。追加プロバイダー（AWS Bedrock/Claude、Anthropic Direct API、Google Gemini、vLLM）は併用可能です — 詳細はAI設定 を参照してください。openai : AI_MODE : azure secretKeys : azure : AZURE_OPENAI_KEYS : '["<AZURE_OPENAI_KEY>"]' AZURE_OPENAI_INSTANCE_NAMES : '["<AZURE_OPENAI_INSTANCE_NAME>"]' AZURE_OPENAI_VERSION : "2024-10-21" AZURE_OPENAI_DEVELOPMENT_NAME : "gpt-4.1" AZURE_OPENAI_EMBEDDING_DEVELOPMENT_NAME : "text-embedding-ada-002" AZURE_OPENAI_VISION_DEVELOPMENT_NAME : "gpt-4o" AZURE_OPENAI_GPT_4O_DEVELOPMENT_NAME : "gpt-4o" AZURE_OPENAI_GPT_4O_MINI_DEVELOPMENT_NAME : "gpt-4o-mini" openai : OPENAI_MAIN_MODEL_NAME : "gpt-4.1" credentials : boost : # デプロイ済みモデル — 完全な設定文字列を指定 JITERA_BOOST_API_CONFIG_AZURE_INSTANCE_1_41 : "behavior=azure,url=https://<INSTANCE>.openai.azure.com/openai/deployments/gpt-4.1,headers={ \" api-key \" : \" <KEY> \" },query_params={ \" api-version \" : \" 2024-10-21 \" }" JITERA_BOOST_API_CONFIG_AZURE_INSTANCE_1_41_MINI : "behavior=azure,url=https://<INSTANCE>.openai.azure.com/openai/deployments/gpt-4.1-mini,headers={ \" api-key \" : \" <KEY> \" },query_params={ \" api-version \" : \" 2024-10-21 \" }" JITERA_BOOST_API_CONFIG_AZURE_INSTANCE_1_41_NANO : "behavior=azure,url=https://<INSTANCE>.openai.azure.com/openai/deployments/gpt-4.1-nano,headers={ \" api-key \" : \" <KEY> \" },query_params={ \" api-version \" : \" 2024-10-21 \" }" JITERA_BOOST_API_CONFIG_AZURE_INSTANCE_1_4O : "behavior=azure,url=https://<INSTANCE>.openai.azure.com/openai/deployments/gpt-4o,headers={ \" api-key \" : \" <KEY> \" },query_params={ \" api-version \" : \" 2024-10-21 \" }" JITERA_BOOST_API_CONFIG_AZURE_INSTANCE_1_4O_MINI : "behavior=azure,url=https://<INSTANCE>.openai.azure.com/openai/deployments/gpt-4o-mini,headers={ \" api-key \" : \" <KEY> \" },query_params={ \" api-version \" : \" 2024-10-21 \" }" JITERA_BOOST_API_CONFIG_AZURE_INSTANCE_1_ADA : "behavior=azure,url=https://<INSTANCE>.openai.azure.com/openai/deployments/text-embedding-ada-002,headers={ \" api-key \" : \" <KEY> \" },query_params={ \" api-version \" : \" 2024-10-21 \" }" # 未デプロイモデル — 起動時クラッシュ防止のため空文字列でオーバーライド必須 JITERA_BOOST_API_CONFIG_AZURE_INSTANCE_1_O1 : "" JITERA_BOOST_API_CONFIG_AZURE_INSTANCE_1_O3 : "" JITERA_BOOST_API_CONFIG_AZURE_INSTANCE_1_O3_MINI : "" JITERA_BOOST_API_CONFIG_AZURE_INSTANCE_1_O4_MINI : ""
カスタムサブドメイン要件、すべてのBoost設定キー、モデルデプロイメント、SuperAdmin登録を含む完全なセットアップについては、AI設定 — Azure OpenAI を参照してください。 openai : AI_MODE : open_ai secretKeys : openai : OPENAI_API_KEY : "<OPENAI_API_KEY>" OPENAI_API_KEYS : '["<OPENAI_API_KEY>"]' OPENAI_VISION_KEY : "<OPENAI_API_KEY>" OPENAI_EMBEDDING_KEY : "<OPENAI_API_KEY>" OPENAI_MAIN_MODEL_NAME : "gpt-4o"
Boost設定とモデル登録については、AI設定 — OpenAI を参照してください。 上記の例ではStorageClassを指定していません — クラスターのデフォルトが使用されます。AKSでは通常managed-csiまたはmanaged-premiumです。kubectl get storageclassで確認できます。オーバーライドするには、postgresql.persistence、pgvector.persistence、mongodb.persistenceセクションにstorageClassNameを追加してください。
設定可能なパラメータの完全なリファレンスについては Helm Valuesリファレンス を参照してください。
ステップ 2.5: デフォルトStorageClassの確認 Helmチャートのモニタリングスタックとクラスター内データベースは、クラスターのデフォルトStorageClassに依存するPersistentVolumeClaimを使用します。AKSでは通常managed-csiがデフォルトです。確認してください：
kubectl get storageclass # managed-csiに「(default)」が表示されることを確認
デフォルトStorageClassが存在しない場合は設定してください：
kubectl patch storageclass managed-csi -p '{"metadata": {"annotations": {"storageclass.kubernetes.io/is-default-class": "true"}}}'
デフォルトStorageClassはデータベースを外部化する場合でも必要です — モニタリングスタック（Grafana、Prometheus、Loki、Tempo）は引き続き永続ボリュームを必要とします。デフォルトStorageClassがない場合、Podはunbound immediate PersistentVolumeClaimsでPending状態のままになります。クラスターがmanaged-csiではなくmanaged-premiumを使用している場合は、適宜置き換えてください。
ステップ 3: Jitera のインストール # Jitera Helmチャートzipを展開 unzip jitera-helm-chart.zip # Jiteraをインストール helm install jitera ./charts/jitera \ --namespace jitera \ --values values-azure.yaml \ --wait \ --timeout 15m
初回インストールでは --timeout 15m フラグが重要です。データベースの初期化とマイグレーションに数分かかることがあります。インストールがタイムアウトした場合は、再試行前に kubectl get pods -n jitera でPodステータスを確認してください。
外部 Azure サービス（オプション） 本番環境の高可用性デプロイメントでは、データベースをマネージドサービスに外部化することを検討してください。セットアップ手順については、Azureの公式ドキュメントを参照してください：
Azure Database for PostgreSQL の使用 PostgreSQL 14.x を実行するAzure Database for PostgreSQL Flexible Serverを作成してください。検証済みバージョンについては外部サービス を参照してください。Jiteraには以下のPostgreSQL拡張機能が必要です：btree_gist、citext、cube、pg_stat_statements、pg_trgm、pgcrypto、uuid-ossp、vector。これらはデプロイ時に自動的にインストールされます。Azure Database for PostgreSQL Flexible Serverでは、デプロイ前にazure.extensionsサーバーパラメーターでこれらの拡張機能を許可リストに追加する必要があります。詳細はAzure Database for PostgreSQLのPostgreSQL拡張機能 を参照してください。
# values-azure.yaml への追加 postgresql : enabled : false externalPostgres : enabled : true host : jitera-postgres.postgres.database.azure.com port : "5432" dbName : jitera username : jiteraadmin password : "YourSecurePassword123!"
Azure Database for PostgreSQL（PGVector）の使用 PostgreSQL 16.x を実行する別のAzure Database for PostgreSQL Flexible Serverを作成してください。検証済みバージョンについては外部サービス を参照してください。Jiteraにはプライマリデータベースと同じPostgreSQL拡張機能が必要です：btree_gist、citext、cube、pg_stat_statements、pg_trgm、pgcrypto、uuid-ossp、vector。これらはデプロイ時に自動的にインストールされます。Azure Database for PostgreSQL Flexible Serverでは、azure.extensionsサーバーパラメーターでこれらの拡張機能を許可リストに追加する必要があります。詳細はAzure Database for PostgreSQLでのpgvector を参照してください。
# values-azure.yaml への追加 pgvector : enabled : false externalPgvector : enabled : true host : jitera-pgvector.postgres.database.azure.com port : "5432" database : jitera_pgvector username : jiteraadmin password : "YourSecurePassword123!" sslMode : disable
TLS制限については外部サービス — PGVector を参照してください。
Azure Cosmos DB for MongoDB の使用 接続URI要件については外部サービス — MongoDB を参照してください。
# values-azure.yaml への追加 mongodb : enabled : false externalMongodb : enabled : true mongodb_uri : "mongodb://jitera-cosmos:xxxxx@jitera-cosmos.mongo.cosmos.azure.com:10255/jitera?ssl=true&replicaSet=globaldb"
Azure Cache for Redis の使用 # values-azure.yaml への追加 redis : enabled : false externalRedis : enabled : true host : jitera-redis.redis.cache.windows.net port : 6380 username : "" # 必須 — Azure Cache for Redisの場合は空のまま（ACLユーザー名なし） password : "your-redis-access-key" useTls : true
インストール後の確認 ステップ 1: Pod ステータスの確認 # すべての Pod が Running であること kubectl get pods -n jitera # 期待される出力: # NAME READY STATUS RESTARTS AGE # jitera-api-xxxxx 1/1 Running 0 5m # jitera-web-xxxxx 1/1 Running 0 5m # jitera-worker-xxxxx 1/1 Running 0 5m # jitera-postgresql-0 1/1 Running 0 5m # jitera-mongodb-0 1/1 Running 0 5m # jitera-redis-master-0 1/1 Running 0 5m
ステップ 2: ロードバランサー IP の取得 kubectl get svc -n jitera -l app.kubernetes.io/name=kong # EXTERNAL-IP をメモしてください
ステップ 3: DNS の設定 両方 のホスト名（メインドメインとチャットドメイン）をロードバランサーIPに向けるAレコードを作成します。ホスト名の詳細についてはデプロイ要件 を参照してください。app.example.com A <load-balancer-ip> chat.example.com A <load-balancer-ip>
# ロードバランサーIPを取得 LB_IP = $( kubectl get svc -n jitera -l app.kubernetes.io/name=kong -o jsonpath='{.items[0].status.loadBalancer.ingress[0].ip}' ) # Aレコードを作成 az network dns record-set a add-record \ --resource-group < YOUR_DNS_RESOURCE_GROU P > \ --zone-name example.com \ --record-set-name app \ --ipv4-address $LB_IP az network dns record-set a add-record \ --resource-group < YOUR_DNS_RESOURCE_GROU P > \ --zone-name example.com \ --record-set-name chat \ --ipv4-address $LB_IP
詳細な手順については Azure DNSドキュメント を参照してください。 ステップ 4: TLS 証明書の確認 # 証明書が発行されていることを確認 kubectl get certificate -n jitera # READY = True と表示されるはずです
トラブルシューティング Pod が起動しない # Pod イベントを確認 kubectl describe pod < pod-nam e > -n jitera # ログを確認 kubectl logs < pod-nam e > -n jitera # よくある問題: # - イメージプルエラー: レジストリ認証情報を確認 # - リソース問題: ノードのキャパシティを確認 # - PVC 問題: ストレージクラスが存在するか確認
証明書が発行されない # 証明書のステータスを確認 kubectl describe certificate jitera-tls -n jitera # cert-manager のログを確認 kubectl logs -n cert-manager -l app=cert-manager # よくある問題: # - DNS が伝播されていない # - HTTP-01 チャレンジ用に Ingress にアクセスできない # - Let's Encrypt のレート制限
ロードバランサーの問題 # Kong プロキシサービスを確認 kubectl get svc -n jitera -l app.kubernetes.io/name=kong # Kong Pod のログを確認 kubectl logs -n jitera -l app.kubernetes.io/name=kong # よくある問題: # - クォータ制限超過 # - ネットワークセキュリティグループがトラフィックをブロック
データベース接続の問題 # PostgreSQL 接続をテスト kubectl run -it --rm psql --image=postgres:15 --restart=Never -- \ psql -h jitera-postgresql -U jitera -d jitera
ストレージアクセスの問題 # 設定されているストレージプロバイダーを確認 kubectl get configmap jitera-ultron -n jitera -o jsonpath='{.data.STORAGE_DISK}' # Ultron シークレットの Azure 認証情報を確認 kubectl get secret jitera-ultron -n jitera \ -o jsonpath='{.data.AZURE_STORAGE_ACCOUNT_NAME}' | base64 -d # Automation シークレット（secrets.yml）のストレージ設定を確認 kubectl get secret jitera-automation -n jitera \ -o jsonpath='{.data.secrets\.yml}' | base64 -d | grep -A 5 'storage_service\|azure:' # Ultron シークレットのストレージ設定を確認 kubectl get secret jitera-ultron -n jitera -o json | \ jq '.data | to_entries[] | select(.key | test("AZURE_STORAGE")) | {(.key): (.value | @base64d)}' # Pod からの接続をテスト kubectl exec -it deploy/jitera-automation-rails -n jitera -- \ curl -s -o /dev/null -w "%{http_code}" https://jiterastoragexxxx.blob.core.windows.net # ストレージアカウントへのアクセスを検証 az storage container list \ --account-name jiterastoragexxxx \ --auth-mode key
ストレージ CORS エラー ブラウザコンソールで CORS エラーが表示される場合:
ストレージアカウントの CORS 設定にお使いのドメインが含まれていることを確認してください
許可されたメソッドに必要な HTTP メソッドがすべて含まれていることを確認してください
ストレージエンドポイントがブラウザからアクセス可能であることを確認してください
az storage cors list --account-name jiterastoragexxxx --services b
メールのテスト # Rails コンソールにアクセス kubectl exec -it deploy/jitera-automation-rails -n jitera -- rails console # テストメールの送信 ActionMailer::Base.mail( from: 'noreply@yourdomain.com', to: 'test@example.com', subject: 'Test Email', body: 'This is a test email from Jitera.' ).deliver_now
# 環境変数の確認 kubectl exec -it deploy/jitera-automation-rails -n jitera -- \ env | grep -i smtp # メールエラーの automation ログ確認 kubectl logs deploy/jitera-automation-rails -n jitera | grep -i mail
メール接続拒否 # SMTP サーバーへの到達性を確認 kubectl exec -it deploy/jitera-automation-rails -n jitera -- \ telnet smtp.azurecomm.net 587 # NSG ルールで送信ポート 587 が許可されていることを確認
メール認証失敗
認証情報が正しいことを確認します
Azureポータルでメールドメインが接続されていることを確認します（Communication Services > メール > ドメイン ）
default_from_email がポータルに表示される MailFrom アドレス（DoNotReply@<random-uuid>.azurecomm.net）と一致していることを確認します
# シークレット値の確認 kubectl get secret jitera-mailer -n jitera -o yaml
メールが配信されない
迷惑メール/ジャンクフォルダを確認します
ドメインの SPF/DKIM レコードを確認します
Azure Communication Services でドメインが検証済みであることを確認します
Azure Communication Services のログで配信失敗を確認します
デプロイメントの削除 Jiteraをクラスターから完全に削除します。
この操作は元に戻せません 。クラスター内のすべてのデータ（データベース、キャッシュ、メッセージキュー）が永久に削除されます。実行前にすべてのデータをバックアップしてください。
# Helmリリースをアンインストール helm uninstall jitera -n jitera # 名前空間を削除（残りのリソースをすべて削除） kubectl delete namespace jitera
外部リソース（ストレージアカウント、Azure Databaseインスタンス、Cosmos DB、Azure Cache for Redis、証明書、DNSレコード）はhelm uninstallでは削除されません 。Azureポータル、CLI、またはTerraformを使用して別途削除する必要があります。
関連ドキュメント
バックアップとリストア アップグレード前のデータベースバックアップ手順
