メインコンテンツへスキップ

Dify Enterprise Edition デプロイメントガイド(AWS)

本ドキュメントでは、AWS クラウド環境に Dify Enterprise Edition をデプロイする方法について説明します。以下のいずれかの方法でデプロイを完了できます:
  • Terraform 経由(推奨)
  • CDK 経由
  • 手動でインフラストラクチャを作成してデプロイ(非推奨)

オプション 1:Terraform によるビルド

Terraform 関連のスクリプトとドキュメントを取得するには、Dify 技術サポートチームにお問い合わせください。

前提条件

  1. ローカルに kubectlhelmaws cli がインストールされていること。
  2. 以下のリソースを作成する権限を持つ AWS アカウント。
Terraform は、Dify Enterprise Edition のデプロイをサポートするために、以下のクラウドリソースを自動的に作成します。事前に Terraform 設定ファイルを変更してリソース仕様を調整できます。
  • AWS EKS(Elastic Kubernetes Service):Dify コアサービスのデプロイ用。ノードはインターネットアクセスまたは NAT Gateway 設定が必要
  • AWS S3(Simple Storage Service):永続ストレージ用
  • AWS ECR(Elastic Container Registry):Dify プラグインのインストール用。Dify イメージと Helm Charts のホスティングも可能
  • AWS RDS Aurora Postgres:アプリケーションデータと監査レコードを保存するリレーショナルデータベース
  • AWS OpenSearch:RAG(Retrieval Augmented Generation)関連機能用のベクトルデータベース
  • Amazon ElastiCache:データアクセスを高速化するマネージド Redis キャッシュサービス

オプション 2:CDK によるビルド

AWS CDK デプロイメント を参照してください。

オプション 3:手動でインフラストラクチャを作成してデプロイ

1. インフラストラクチャの作成

以下の表の推奨設定を参考に、実際のニーズに応じてインフラストラクチャを作成してください。(二重括弧内のコンテンツを実際の値に置き換えてください)
バージョンに関する注意(重要): 以下の表に記載しているバージョンは「利用可能な範囲/バージョン系列」の目安です。実際のデプロイ前に、必ず対象 AWS リージョンのコンソール、または AWS CLI で各サービスが現在サポートしているバージョン(EKS Kubernetes、Aurora PostgreSQL、OpenSearch、ElastiCache Redis など)を確認してください。リージョン差分やバージョン廃止により、リソース作成に失敗する可能性があります。

テスト環境インフラストラクチャ設定リファレンス

注意: 単一ノードで unstructured サービスを有効にする場合は、ディスク容量を 40 GB に増やしてください。
コンポーネントタイプ設定項目仕様説明
EKS クラスタークラスター名dify-{your_custom_deployment_id}-eks-clusterカスタム命名
Kubernetes バージョン1.2x~1.3x(対象リージョンの EKS でサポートされるバージョンに準拠)事前確認:対象リージョンの EKS Kubernetes バージョン対応一覧
ノードインスタンスタイプm7a.xlarge (amd64) / m7g.xlarge (arm64)4 vCPU、16GB RAM
ノード数1-2(希望:1)最小コスト設定
ノードディスクサイズ40 GBgp3、暗号化
AMI タイプAL2023_x86_64 / ARM_64_STANDARDAmazon Linux 2023
S3 バケットバケット名dify-{your_custom_deployment_id}-storageカスタム命名
バージョニング有効ファイルバージョン管理
暗号化AES256サーバーサイド暗号化
パブリックアクセス完全にブロックセキュリティ設定
ストレージ容量計画100GBテスト環境容量
RDS
(Aurora Serverless v2)
クラスター識別子dify-{your_custom_deployment_id}-aurora-postgresカスタム命名
エンジンバージョンAurora PostgreSQL(PostgreSQL 14+ 互換、対象リージョンのサポートに準拠)事前確認:対象リージョンで選択可能な Aurora PostgreSQL エンジンバージョン
インスタンス数1単一インスタンス、コスト最適化
インスタンスタイプdb.serverlessServerless v2 専用
最小/最大キャパシティ1 - 8 ACU自動スケーリング
ストレージ暗号化有効保存時暗号化
バックアップ保持期間7 日自動バックアップ
Performance Insights無効コスト最適化
作成するデータベースdify, enterprise, audit, dify_plugin_daemon4 つのデータベース
OpenSearchドメイン名dify-{your_custom_deployment_id}-opensearchカスタム命名
エンジンバージョンOpenSearch 2.x(対象リージョンのサポートに準拠)事前確認:Amazon OpenSearch Service がサポートするエンジンバージョン
インスタンスタイプt3.medium.search2 vCPU, 4 GB RAM
インスタンス数1単一ノード
ストレージタイプ/サイズEBS gp3 / 100 GBテスト環境(単一ノード)
セキュリティ機能保存時暗号化、ノード間暗号化、HTTPS 強制包括的セキュリティ
ElastiCache
(Redis)
レプリケーショングループ IDdify-{your_custom_deployment_id}-redisカスタム命名
エンジンバージョンRedis 7.x(対象リージョンの ElastiCache のサポートに準拠)事前確認:ElastiCache for Redis がサポートするエンジンバージョン
ノードタイプcache.t4g.small2 vCPU, 1.37 GB RAM
キャッシュノード数1単一ノードモード
マルチ AZ無効単一 AZ デプロイメント
スナップショット保持期間0 日バックアップなし
IAM ロールEKS クラスターロールdify-{your_custom_deployment_id}-cluster-roleAmazonEKSClusterPolicy
EKS ノードグループロールdify-{your_custom_deployment_id}-node-group-roleWorker + CNI + ECR ポリシー
S3 アクセスロールdify-{your_custom_deployment_id}-s3-roleS3 フルアクセス
S3+ECR アクセスロールdify-{your_custom_deployment_id}-s3-ecr-roleS3 + ECR フルアクセス
ECR プルロールdify-{your_custom_deployment_id}-ecr-pull-roleECR 読み取り専用アクセス
その他のリソースECR リポジトリ2(メインアプリ + プラグイン)イメージストレージ
Secrets Manager1RDS 認証情報

本番環境インフラストラクチャ設定リファレンス

コンポーネントタイプ設定項目仕様説明
EKS クラスタークラスター名dify-{your_custom_deployment_id}-eks-clusterカスタム命名
Kubernetes バージョン1.2x~1.3x(対象リージョンの EKS でサポートされるバージョンに準拠)事前確認:対象リージョンの EKS Kubernetes バージョン対応一覧
ノードインスタンスタイプm7a.xlarge (amd64) / m7g.xlarge (arm64)4 vCPU、16GB RAM
ノード数6~10(希望:6)本番環境構成
ノードディスクサイズ20 GBgp3、暗号化
AMI タイプAL2023_x86_64 / ARM_64_STANDARDAmazon Linux 2023
S3 バケットバケット名dify-{your_custom_deployment_id}-storageカスタム命名
バージョニング有効ファイルバージョン管理
暗号化AES256サーバーサイド暗号化
パブリックアクセス完全にブロックセキュリティ設定
ストレージ容量計画512GB本番環境容量
RDS
(Aurora Serverless v2)
クラスター識別子dify-{your_custom_deployment_id}-aurora-postgresカスタム命名
エンジンバージョンAurora PostgreSQL(PostgreSQL 14+ 互換、対象リージョンのサポートに準拠)事前確認:対象リージョンで選択可能な Aurora PostgreSQL エンジンバージョン
インスタンス数1単一インスタンス、コスト最適化
インスタンスタイプdb.serverlessServerless v2 専用
最小/最大キャパシティ4 - 8 ACU自動スケーリング
ストレージ暗号化有効保存時暗号化
バックアップ保持期間30 日自動バックアップ
Performance Insights有効本番では有効化推奨
作成するデータベースdify, enterprise, audit, dify_plugin_daemon4 つのデータベース
OpenSearchドメイン名dify-{your_custom_deployment_id}-opensearchカスタム命名
エンジンバージョンOpenSearch 2.x(対象リージョンのサポートに準拠)事前確認:Amazon OpenSearch Service がサポートするエンジンバージョン
インスタンスタイプr5.large.search2 vCPU, 16 GB RAM(各ノード)
インスタンス数33 ノードクラスター(合計 6 vCPU, 48 GB RAM)
ストレージタイプ/サイズEBS gp3 / 30 GB各ノード 30 GB
セキュリティ機能保存時暗号化、ノード間暗号化、HTTPS 強制包括的セキュリティ
ElastiCache
(Redis)
レプリケーショングループ IDdify-{your_custom_deployment_id}-redisカスタム命名
エンジンバージョンRedis 7.x(対象リージョンの ElastiCache のサポートに準拠)事前確認:ElastiCache for Redis がサポートするエンジンバージョン
ノードタイプcache.t4g.medium~2 vCPU, ~3 GB RAM
キャッシュノード数2プライマリ + 読み取りレプリカ
自動フェイルオーバー有効高可用性
マルチ AZ有効クロス AZ デプロイ
スナップショット保持期間7 日自動バックアップ
IAM ロールEKS クラスターロールdify-{your_custom_deployment_id}-cluster-roleAmazonEKSClusterPolicy
EKS ノードグループロールdify-{your_custom_deployment_id}-node-group-roleWorker + CNI + ECR ポリシー
S3 アクセスロールdify-{your_custom_deployment_id}-s3-roleS3 フルアクセス
S3+ECR アクセスロールdify-{your_custom_deployment_id}-s3-ecr-roleS3 + ECR フルアクセス
ECR プルロールdify-{your_custom_deployment_id}-ecr-pull-roleECR 読み取り専用アクセス
その他のリソースECR リポジトリ2(メインアプリ + プラグイン)イメージストレージ
Secrets Manager1RDS 認証情報
また、インフラストラクチャのセキュリティを確保するために、適切な Virtual Private Cloud(VPC)とセキュリティグループ(SG)を作成する必要があります。

2. values.yaml の設定

データベース、S3、その他のインフラストラクチャを作成した後、以下の例を参考に values.yaml を設定してください(二重括弧内のコンテンツを実際の値に置き換えてください)。その前に、データベースに difyenterpriseauditdify_plugin_daemon の 4 つのデータベースを作成し、values.yamlrds_main_database_name などの対応する設定項目を置き換える必要があります。
###################################
# Persistence Configration
###################################
persistence:
  type: "s3"
  s3:
    endpoint: "{s3_endpoint}"
    accessKey: ""
    secretKey: ""
    region: "{region}"
    bucketName: "{s3_bucket_name}"
    addressType: ""
    useAwsManagedIam: true
    useAwsS3: true

###################################
# External postgres
###################################
externalPostgres:
  enabled: true
  address: "{rds_address}"
  port: 5432
  credentials:
    dify:
      database: "{rds_main_database_name}"
      username: "postgres"
      password: "{rds_password}"
      sslmode: "require"
    plugin_daemon:
      database: "{rds_plugin_daemon_database_name}"
      username: "postgres"
      password: "{rds_password}"
      sslmode: "require"
    enterprise:
      database: "{rds_enterprise_database_name}"
      username: "postgres"
      password: "{rds_password}"
      sslmode: "require"
    audit:
      database: "{rds_audit_database_name}"
      username: "postgres"
      password: "{rds_password}"
      sslmode: "require"

###################################
# External Redis
###################################
externalRedis:
  enabled: true
  host: "{redis_address}"
  port: 6379
  username: ""
  password: ""
  useSSL: false

###################################
# External Vector Database
###################################
vectorDB:
  useExternal: true
  externalType: "opensearch"
  externalOpenSearch:
    host: "{opensearch_address}"
    port: 443
    user: "{opensearch_user}"
    password: "{opensearch_password}"
    useTLS: true

3. S3 と ECR 権限の設定

Dify サービスが正常に起動し、プラグインシステムが正しく機能するために、apiworkerworkerBeatplugin_daemonplugin_connector サービスには S3 アクセス権限が必要であり、plugin_connector サービスには ECR アクセス権限も必要です。plugin_connector サービスがこれらの権限を必要とする具体的な理由については、後で詳しく説明します。 権限は以下の 2 つの方法のいずれかで設定できます:
  • IRSA モード:IAM Roles for Service Accounts、安全できめ細かな権限制御を可能にする(推奨)
  • アクセスキー(AK/SK)モード:環境変数を介して認証情報を提供

IRSA モード設定

Dify では、IRSA を使用して ServiceAccount 権限を設定することを推奨しています。ワンクリック IRSA デプロイメントスクリプトについては、Dify 技術サポートチームにお問い合わせください。 IRSA は OIDC プロバイダーを介して EKS クラスターと IAM 間の信頼関係を確立し、Pod がアクセスキーを設定することなく ServiceAccount を通じて安全に AWS 権限を取得できるようにします。全体的なアーキテクチャは以下のとおりです:
┌─────────────────────┐
│   OIDC Provider     │
└────────┬────────────┘
         │ (Federated Trust)

┌────────────────────────────────────────────────────────────┐
│  Role: S3 アクセスロール                                     │
│  ├─ Policy: S3 ポリシー (s3:*)                               │
│  └─ SA: dify-api-sa, dify-plugin-connector-sa              │
├────────────────────────────────────────────────────────────┤
│  Role: S3+ECR アクセスロール                                  │
│  ├─ Policy: S3 ポリシー (s3:*)                               │
│  ├─ Policy: ECR ポリシー (ECR read/write/push + CloudTrail)  │
│  └─ SA: dify-plugin-crd-sa                                 │
├────────────────────────────────────────────────────────────┤
│  Role: ECR プルロール                                        │
│  ├─ Policy: ECR プル専用ポリシー (ECR pull only)              │
│  └─ SA: dify-plugin-runner-sa                              │
└────────────────────────────────────────────────────────────┘
以下は、Dify Enterprise Edition に必要な ServiceAccount 権限の説明です:
Service Accountコンポーネント権限の説明スコープ
dify-enterpriseEnterprise サービスnamespaces に対する getlistwatch 権限を持ち、名前空間情報の取得と監視に使用。Role(名前空間レベル)
dify-plugin-saPlugin Controllerdifyplugins(CRD)とその finalizers/statusleaseseventsservicesconfigmapsdeploymentsjobsingresses などのリソースに対する完全な管理権限を持つ。Role(プラグイン名前空間)
dify-plugin-connector-saPlugin Connector & Daemondify-plugin-connector-roledify-plugin-sa と同じ)から権限を継承。Role(プラグイン名前空間)
Custom Service Account各種サービスコンポーネントデフォルトでは空(default サービスアカウントを使用)、values.yaml で設定可能。設定に応じて
customServiceAccountプラグインカスタムサービスアカウントプラグイン実行時のカスタム権限用、デフォルトでは空、設定で指定可能。設定に応じて
runnerServiceAccountPlugin Runner サービスアカウントプラグインランナー専用のサービスアカウント、デフォルトでは空、設定で指定可能。設定に応じて
💡 CRD インストールに関する特別な注意 Dify Enterprise Edition は、インストール時に名前空間レベルの権限のみを必要とします。ただし、CRD 自体はクラスターレベルのリソースであるため、インストール時には適切なクラスター権限が必要です。クラスターレベルの権限がない場合は、最初に CRD を別途インストールし、その後残りのコンポーネントをインストールできます。CRD 自体は、Kubernetes に登録された API 構造宣言にすぎません。対応する Controller が名前空間レベルの場合、名前空間をまたいでリソースにアクセスしたり変更したりすることはできません。
ステップ 1:IAM OIDC プロバイダーの確認
IRSA を設定する前に、クラスターで IAM OIDC プロバイダーが有効になっていることを確認してください。クラスターが手動で作成された場合は、eksctl コマンドラインツールを使用して有効化または確認することをお勧めします。IAM OIDC プロバイダーは、EKS クラスターが Pod の ID を IAM に証明できる信頼関係を確立し、Pod が AWS 権限を安全に取得できるようにします。
eksctl utils associate-iam-oidc-provider --cluster <your-cluster-name> --approve
IRSA の設定には、AWS ロールとポリシー、およびクラスター ServiceAccount の作成が必要です。ServiceAccount を作成する際は、Helm 設定との競合による権限割り当ての失敗を避けるため、デフォルトの名前を維持することをお勧めします。
ステップ 2:AWS IAM ポリシーの作成
以下の 3 つの IAM ポリシーを作成する必要があります: ポリシー 1:S3 アクセスポリシー(名前はカスタマイズ可能、例:DifyS3Policy
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "s3:*",
            "Resource": "arn:aws:s3:::{your-s3-bucket}/*"
        }
    ]
}
ポリシー 2:ECR フルアクセスポリシー(名前はカスタマイズ可能、例:DifyECRPolicy プラグインイメージのプッシュと管理に使用され、ECR 認証、リポジトリ管理、イメージプッシュ、および監査ログの権限を含みます:
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ECRAuthAndDiscovery",
            "Effect": "Allow",
            "Action": [
                "ecr:GetAuthorizationToken",
                "ecr:DescribeRepositories",
                "ecr:DescribeImages",
                "ecr:GetRepositoryPolicy",
                "ecr:GetLifecyclePolicy",
                "ecr:GetLifecyclePolicyPreview"
            ],
            "Resource": "*"
        },
        {
            "Sid": "ECRRepoManagement",
            "Effect": "Allow",
            "Action": [
                "ecr:CreateRepository",
                "ecr:TagResource"
            ],
            "Resource": "*"
        },
        {
            "Sid": "ECRImagePush",
            "Effect": "Allow",
            "Action": [
                "ecr:BatchCheckLayerAvailability",
                "ecr:CompleteLayerUpload",
                "ecr:InitiateLayerUpload",
                "ecr:UploadLayerPart",
                "ecr:PutImage"
            ],
            "Resource": "arn:aws:ecr:{region}:{account_id}:repository/{your_ecr_repo_prefix}*"
        },
        {
            "Sid": "AuditLogging",
            "Effect": "Allow",
            "Action": "cloudtrail:LookupEvents",
            "Resource": "*"
        }
    ]
}
{your_ecr_repo_prefix} は ECR リポジトリ名のプレフィックスです。例えば、ステップ 5 で imageRepoPrefix123456789.dkr.ecr.us-east-1.amazonaws.com/dify-ee と設定した場合、ここでの ECR リポジトリプレフィックスは dify-ee であり、Resource は arn:aws:ecr:us-east-1:123456789:repository/dify-ee* と記入します。
ポリシー 3:ECR プル専用ポリシー(名前はカスタマイズ可能、例:DifyECRPullOnlyPolicy プラグインランタイムイメージのプルにのみ使用されます:
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ECRAuth",
            "Effect": "Allow",
            "Action": "ecr:GetAuthorizationToken",
            "Resource": "*"
        },
        {
            "Sid": "ECRImagePull",
            "Effect": "Allow",
            "Action": [
                "ecr:BatchGetImage",
                "ecr:GetDownloadUrlForLayer",
                "ecr:DescribeImages"
            ],
            "Resource": "arn:aws:ecr:{region}:{account_id}:repository/{your_ecr_repo_prefix}*"
        }
    ]
}
ステップ 3:AWS IAM ロールの作成
以下の 3 つのロールを作成し、ステップ 2 のポリシーを対応するロールにアタッチします(ロール名はカスタマイズ可能):
ロール名(例)アタッチするポリシー用途
DifyS3RoleS3 アクセスポリシーS3 ストレージアクセス
DifyS3ECRRoleS3 アクセスポリシー + ECR フルアクセスポリシーS3 + ECR イメージプッシュ/管理
DifyECRPullRoleECR プル専用ポリシーECR イメージプル
対応するロール ARN を取得します:
DIFY_EE_S3_ROLE_ARN=arn:aws:iam::{account_id}:role/{your_s3_role_name}
DIFY_EE_S3_ECR_ROLE_ARN=arn:aws:iam::{account_id}:role/{your_s3_ecr_role_name}
DIFY_EE_ECR_PULL_ROLE_ARN=arn:aws:iam::{account_id}:role/{your_ecr_pull_role_name}
各ロールの信頼ポリシー(Trust Policy)は、OIDC プロバイダーのフェデレーション認証として設定する必要があります。以下は信頼ポリシーのテンプレートです:
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::{account_id}:oidc-provider/oidc.eks.{region}.amazonaws.com/id/{oidc_id}"
            },
            "Action": "sts:AssumeRoleWithWebIdentity"
        }
    ]
}
{oidc_id} を EKS クラスターの OIDC プロバイダー ID に置き換えてください。以下のコマンドで取得できます:
aws eks describe-cluster --name <cluster-name> --query "cluster.identity.oidc.issuer" --output text | cut -d '/' -f 5
ステップ 4:ロールを EKS ServiceAccount にバインド
ServiceAccount(SA)は、EKS の Pod が特定の AWS 権限を取得してクラウドリソース(S3 など)にアクセスできるようにするメカニズムです。
以下の 4 つの ServiceAccount を作成し、対応するロール ARN を eks.amazonaws.com/role-arn アノテーションに追加します:
ServiceAccount名前空間バインドするロール有効な権限
dify-api-sadifyS3 アクセスロールS3 アクセス
dify-plugin-crd-sadifyS3+ECR アクセスロールS3 + ECR プッシュ/プル
dify-plugin-runner-sadifyECR プルロールECR プルのみ
dify-plugin-connector-sadifyS3 アクセスロールS3 アクセス(Helm が自動割り当て)
ServiceAccount 作成のコマンド例($DIFY_EE_* をステップ 3 で取得したロール ARN に置き換えてください):
kubectl create serviceaccount dify-api-sa -n dify
kubectl annotate serviceaccount dify-api-sa -n dify \
  eks.amazonaws.com/role-arn=$DIFY_EE_S3_ROLE_ARN

kubectl create serviceaccount dify-plugin-crd-sa -n dify
kubectl annotate serviceaccount dify-plugin-crd-sa -n dify \
  eks.amazonaws.com/role-arn=$DIFY_EE_S3_ECR_ROLE_ARN

kubectl create serviceaccount dify-plugin-runner-sa -n dify
kubectl annotate serviceaccount dify-plugin-runner-sa -n dify \
  eks.amazonaws.com/role-arn=$DIFY_EE_ECR_PULL_ROLE_ARN

kubectl create serviceaccount dify-plugin-connector-sa -n dify
kubectl annotate serviceaccount dify-plugin-connector-sa -n dify \
  eks.amazonaws.com/role-arn=$DIFY_EE_S3_ROLE_ARN
ステップ 5:values.yaml で ServiceAccount を設定
Helm の values.yaml を変更し、以下の設定を追加します(以下は ServiceAccount と ECR 関連の設定のみを示しており、その他の設定は省略されています)。imageRepoPrefix はカスタマイズ可能です:
api:
  serviceAccountName: "dify-api-sa"
worker:
  serviceAccountName: "dify-api-sa"
workerBeat:
  serviceAccountName: "dify-api-sa"
plugin_connector:
  imageRepoSecret: "image-repo-secret" # 注意:IRSA モードを使用する場合でも、この Secret を作成する必要があります。任意のコンテンツを含めることができます。
  customServiceAccount: "dify-plugin-crd-sa"
  runnerServiceAccount: "dify-plugin-runner-sa"
  imageRepoPrefix: "{account_id}.dkr.ecr.{region}.amazonaws.com/dify-ee" 
  imageRepoType: ecr
  ecrRegion: "{region}"
‼️ dify-plugin-connector-sa は Helm Chart テンプレートを通じて plugin_connector サービスに自動的に割り当てられます。dify-plugin-crd-sadify-plugin-runner-sa は、プラグインをビルドおよび実行する Pod に使用されます。

アクセスキーモード設定

ステップ 1:認証情報の準備
S3 と ECR 権限のみを持つ IAM ユーザーを作成し、そのアクセスキーとシークレットキーを取得します。
ステップ 2:Kubernetes Secret の作成
kubectl create secret generic image-repo-secret --from-file=<path to .aws/credentials>
この Secret は、次のステップで values.yamlimageRepoSecret を介して plugin_connector サービスに設定する必要があります。
ステップ 3:values.yaml の設定
persistence:
  type: "s3"
  s3:
    endpoint: "https://s3.{region_code}.amazonaws.com"
    region: "{region_code}"
    bucketName: "your_bucket_name"
    useAwsS3: true
    useAwsManagedIam: false
    accessKey: "{your access key}"
    secretKey: "{your secret key}"

plugin_daemon:
  enabled: true
  replicas: 1
  apiKey: "dify123456"

plugin_connector:
  apiKey: "dify123456"
  imageRepoSecret: "image-repo-secret"
  imageRepoPrefix: "{account_id}.dkr.ecr.{region}.amazonaws.com/dify-ee"
  imageRepoType: ecr
  ecrRegion: "us-west-2"

4. AWS ALB(Application Load Balancer)のインストール

Dify Enterprise Edition をドメイン名でアクセス可能にするには、AWS ALB(Application Load Balancer)をインストールする必要があります。Nginx Ingress Controller やその他の Ingress Controller を使用することもできます。AWS ALB は Dify Enterprise Edition とシームレスに統合され、より良いパフォーマンスとスケーラビリティを提供するため推奨されます。 AWS ALB のインストールガイドについては、https://docs.aws.amazon.com/eks/latest/userguide/lbc-manifest.html をご覧ください。
AWS ALB をインストールできない場合は、代替として Nginx Ingress Controller を使用できます:
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/main/deploy/static/provider/kind/deploy.yaml
AWS ALB のインストールが完了したら、以下のコマンドでサービスが正常に実行されているか確認できます:
kubectl get deployment -n kube-system aws-load-balancer-controller
インストール後、values.yaml で Ingress を設定します:
ingress:
  enabled: true
  className: "alb"  # AWS ALB Ingress Controller を使用
  annotations: {
    kubernetes.io/ingress.class: alb,
    alb.ingress.kubernetes.io/scheme: internet-facing,
    alb.ingress.kubernetes.io/target-type: ip,
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS": 443}]',
    alb.ingress.kubernetes.io/ssl-redirect: '443',
    alb.ingress.kubernetes.io/certificate-arn: 'arn:aws:acm:{region}:{account_id}:certificate/{cert_uuid}', # ドメイン証明書の AWS ACM 証明書を入力できます
  }
*SSL 証明書を介して Dify Enterprise Edition サービスを公開するには、ALB アノテーションで証明書を設定し、global 設定で TLS を有効にします。AWS Certificate Manager を通じてドメインを検証し、証明書を作成できます。
global:
  appSecretKey: 'owb3+S+C3b/4iG6YNAiWGIY4kOuX4MnUWHjcPxzyPKvGyxlQUISAWOmi'
  consoleApiDomain: "console.dify.yourdomain.com"
  consoleWebDomain: "console.dify.yourdomain.com"
  serviceApiDomain: "api.dify.yourdomain.com"
  appApiDomain: "app.dify.yourdomain.com"
  appWebDomain: "app.dify.yourdomain.com"
  filesDomain: "upload.dify.yourdomain.com"
  enterpriseDomain: "enterprise.dify.yourdomain.com"
  useTLS: true

5. インストールの実行

詳細なインストール手順については、https://langgenius.github.io/dify-helm/#/ をご覧ください。
‼️ default 名前空間に Dify をインストールすることは推奨されません。

6. サービスステータスの確認

  1. kubectl アクセス認証情報を更新:
aws eks update-kubeconfig --region $AWS_REGION --name $CLUSTER_NAME
  1. EKS ノードが正常に実行されていることを確認:
kubectl get nodes
  1. Dify サービスステータスを確認:
kubectl get pods -n {your namespace}
  1. ALB が正常に動作していることを確認:
aws elbv2 describe-load-balancers --output json
‼️ 上記のコマンド出力から DNSName を CNAME レコードとして設定し、Dify に必要な各ドメインに解決してください。

7. サービスの初期化

インストールが完了しました。enterprise.dify.yourdomain.com にアクセスして、Dify Enterprise Edition 管理コンソールにログインし、さらなる設定と使用を行ってください。