デプロイ関連の問題

再インストール方法

実行中のサービスを停止します。マネージャーのルートディレクトリで以下のコマンドを実行してください（正常停止時は stoped と表示されます）。
```
bash ./service.sh stopall
```
```
rm -f ./installer.stage
```
サービスファイルをバックアップします。バックアップ先は任意に変更できます。初回デプロイ時は通常バックアップ不要のため、rm -rf /data/mingdao/ で直接削除しても構いません。
```
mv /data/mingdao/ /home/hapbak/
```
以下のコマンドをそれぞれ実行し、クリーンアップが完了したことを再確認します。すべての出力が空であることを確認し、空でない場合は該当プロセスを終了してください。
```
docker ps | grep mingdaoyun
```
```
netstat -ntpl | grep 38881
```
```
ps -ef | grep 'mingdaoyun\|service.sh' | grep -v grep
```
以下のコマンドでマネージャーを再起動します。起動後、ブラウザーのシークレットモードで http://{服务器IP}:38881 にアクセスし、再インストールします。
```
bash ./service.sh start
```

初期化に失敗した場合

cat /data/mingdao/script/mingdaoyun.log コマンドで失敗理由を確認できます。主な原因は 空き容量不足、イメージが存在しない、ポート占有、iptables失敗 等です。iptables失敗の場合、ファイアウォールを停止するとiptablesルールがクリアされるため、Dockerを再起動しデフォルトのiptablesルールを再生成し、問題解消後に再インストールしてください。

コンテナ内でインターネットに接続できない場合

firewalldをファイアウォールとして利用している場合、コンテナから外部ネットワークにアクセスできないことがあります（通常、HAPサービスは外部ネットワークとの連携を必要としませんが、メールやSMS送信など一部機能で通信が必要になる場合があります）。以下のファイアウォールルールを追加してください。（172.16.0.1/12はコンテナ内のネットワークセグメントです）

永続的な許可：

firewall-cmd --zone=trusted --add-source=172.16.0.1/12 --permanent

一時的な許可：

firewall-cmd --zone=trusted --add-source=172.16.0.1/12

初期化完了後に「ログアウトしました。再度ログインしてください」と表示される場合

主な原因：ディスクの IOPS 性能が低いと、サービス起動中にディスク I/O が逼迫し、ストレージコンポーネントの起動が遅れることがあります。

対処方法：

/data/mingdao/script/docker-compose.yaml に環境変数を追加して、マイクロサービスの起動を遅らせます。追加後、インストールマネージャーのディレクトリで bash service.sh restartall を実行してください。再起動完了後、初期情報を再入力します。

services:
  app:
    environment:
      ENV_ROLE_MODE_WAITMS: "90000"

ENV_ROLE_MODE_WAITMS の単位はミリ秒で、デフォルトは30秒です。
この例では待機時間を90秒に延長し、マイクロサービス起動前にストレージコンポーネントが起動できるようにします。
解決しない場合は、180秒などに延長して再起動し、確認してください。
待機時間を延長するとサービス全体の起動も遅くなります。高性能ディスクへのデプロイを推奨します。詳しくはサーバーの基本性能要件を参照してください。

サービス起動後に「Service response code error」が出る場合

現象説明：サービス起動後に「Service response code error」というエラーが表示される場合がありますが、後続アクセスは可能な場合もあります。

原因：ディスクI/O性能が低い環境（例：データディスクがHDDの場合）、サービス起動が遅延します。サービス起動後5分でヘルスチェックが行われ、タイムアウト内で応答が返らないとこのエラーとなります。

確認方法：

HAPページにアクセス可能か確認します。正常に利用できればコアサービスは起動しています。
マイクロサービスコンテナのログを以下で確認します：

docker logs $(docker ps | grep -E 'mingdaoyun-community|mingdaoyun-hap' | awk '{print $1}')

INFOレベルが中心なら正常動作です。
ERRORやWARNレベルのログがあれば注意してください。

推奨事項：安定したサービス運用・パフォーマンス・データ安全のため、高性能ディスクへのデプロイを推奨します。主要クラウドサービスの標準ディスクで推奨基本性能を満たします。物理サーバーの場合はSSD利用を推奨します。

サーバー起動時の自動起動設定方法

インストールマネージャのパスが /usr/local/MDPrivateDeployment/ の場合、主要OSごとの設定方法は以下の通りです。

systemd方式
rc.local方式

実装方法：OS標準のsystemdサービスを利用し、HAPサービスの起動コマンドをカスタムユニットファイルmanager.serviceに記載し、サーバーの起動時にHAPサービスを自動起動させます。

/etc/systemd/system/manager.service ファイルに以下のコマンドで直接作成できます：

cat > /etc/systemd/system/manager.service <<'EOF'
[Unit]
Description=Manager
After=docker.service
Wants=docker.service
[Service]
Type=oneshot
WorkingDirectory=/usr/local/MDPrivateDeployment
ExecStart=/bin/bash service.sh restartall
RemainAfterExit=yes
StandardOutput=append:/usr/local/MDPrivateDeployment/manager.log
StandardError=append:/usr/local/MDPrivateDeployment/manager.log
[Install]
WantedBy=multi-user.target
EOF

サーバーの自動起動設定：

systemctl daemon-reload
systemctl enable manager

実装方法：OS標準のrc-localサービスを利用し、HAPサービスの起動コマンドを起動スクリプトに記載し、サーバーの起動時に自動起動させます。

CentOS
Debian
Ubuntu

/etc/rc.d/rc.local ファイルの末尾に以下のコマンドでHAPサービス起動コマンドを追加します：

cat >> /etc/rc.d/rc.local << EOF
sleep 30
cd /usr/local/MDPrivateDeployment/ && /bin/bash ./service.sh restartall
EOF

実行権限設定（必須）：chmod +x /etc/rc.d/rc.local

Debianではrc-localサービスがデフォルト無効なので、手動で有効化します。手順：

rc-localサービスの状態確認

systemctl status rc-local

起動済みなら4へ、未起動なら次へ進みます。

初期rc.localファイル作成＆実行権限付与

echo '#!/bin/bash' > /etc/rc.local
chmod +x /etc/rc.local

サービスを起動

systemctl enable rc-local
systemctl start rc-local
systemctl status rc-local

正常起動を確認し、以降でコマンド自動実行

/etc/rc.local末尾にHAPサービス起動コマンド追加

cat >> /etc/rc.local << EOF
sleep 30
cd /usr/local/MDPrivateDeployment/ && /bin/bash ./service.sh restartall
EOF

Ubuntuもrc-localサービスがデフォルト無効なので、手動で有効化します。手順：

サービス状態確認

systemctl status rc-local

有効なら5へ、無効なら次へ。

/lib/systemd/system/rc-local.service ファイル編集まずバックアップ：

cp /lib/systemd/system/rc-local.service /lib/systemd/system/rc-local.service.bak

次に末尾に以下設定追加：

cat >> /lib/systemd/system/rc-local.service << EOF
[Install]
WantedBy=multi-user.target
EOF

初期rc.localファイル作成＆実行権限設定

echo '#!/bin/bash' > /etc/rc.local
chmod +x /etc/rc.local

サービス起動

systemctl daemon-reload
systemctl enable rc-local
systemctl start rc-local
systemctl status rc-local

/etc/rc.local末尾にHAPサービス起動コマンド追加

cat >> /etc/rc.local << EOF
sleep 30
cd /usr/local/MDPrivateDeployment/ && /bin/bash ./service.sh restartall
EOF

サーバー再起動後にHAPサービスが正常起動しない場合

managerのルートディレクトリで bash ./service.sh stopall を実行し、service.pid が残っている場合は rm -f service.pid で削除します。その後 bash ./service.sh startall を実行し、起動完了まで待ちます。

キー紛失やサーバーIDが表示されない場合の対処

サービス停止：managerルートディレクトリで bash ./service.sh stopall を実行
ps -ef | grep 'mingdaoyun|service.sh' | grep -v grep で該当プロセスが残っていれば全てpidをkill
bash ./service.sh startall を実行し、コマンド完了まで待ちます

Kafka起動失敗時

HAPのスタンドアロンモードではKafkaサービスがコンテナ内組み込みコンポーネントとして動作します。Kafka不可用時、以下の問題が発生します：

ワークフローが正常動作しない
ワークシート行データの登録が遅い
統計機能の異常やデータ非同期

運用中、Kafkaはメッセージデータやオフセット情報をローカルデータディレクトリに保存します。異常停止（停電・メモリ不足による強制終了等）の場合、KafkaおよびZookeeperのメタデータファイルに下記障害が発生します：

ログデータファイル破損：メッセージログ・オフセットファイルの書き込み未完了による検証失敗
Zookeeper状態不整合：トランザクションログ未コミットでKafkaがクラスタメタデータをロードできない
Kafka起動ハング：リカバリフェーズでインデックス・ログファイル不整合検出→異常復旧ループ

スタンドアロンモードのKafkaではクラスタレプリカ機構がないため、自動回復不能。障害データ削除・Kafkaの再初期化のみで復旧可能です。

コンテナログでKafka起動失敗を確認したら、以下手順で修復：

managerルートディレクトリで bash ./service.sh stopall 実行
Kafka・Zookeeperの異常データディレクトリをリネーム

mv /data/mingdao/script/volume/data/kafka{,_bak_$(date +%Y%m%d%H%M)}
mv /data/mingdao/script/volume/data/zookeeper{,_bak_$(date +%Y%m%d%H%M)}

managerルートディレクトリで bash ./service.sh startall を実行

ドキュメントのオンラインプレビュー不可の場合

ドキュメントプレビューサービスはマイクロサービスアプリのファイル読み取りが必要です。イントラネットからシステム外部公開アドレスにアクセスできない場合、プレビュー失敗となります。この場合は docker-compose.yaml のdoc設定に環境変数 ENV_FILE_INNER_URI を追加し、イントラネット用アドレスを指定してください：

services:
  doc:
    environment:
      ENV_FILE_INNER_URI: "10.140.100.6:8880"

ワークシートをExcelでエクスポートできない場合

ワークシート内のデータ量によっては、エクスポート時に504 Gateway Time-outなどが発生しますが、これはプロキシ層のデフォルトタイムアウトやファイルサイズ制限が原因です。以下（nginx例）の設定追加で対策できます。

location ~ /excelapi {
proxy_set_header Host $http_host;
proxy_read_timeout 1800s;
client_max_body_size 256m;
proxy_pass http://hap; # 実際のupstream名に合わせて修正
}

添付ファイルアップロード時にインターフェースがタイムアウトする場合

4MB超ファイルのアップロードはデフォルトでスライスアップロードとなります。ネットワークにより一部スライスのアップロード失敗が全体失敗となることがあります。以下（nginx例）を追加してください。

location ~ /file {
proxy_set_header Host $http_host;
proxy_read_timeout 3600s;
client_max_body_size 20480m;
proxy_pass http://hap; # 実際のupstream名に合わせて修正
}

ワークフロー一覧の取得失敗、添付ファイルダウンロード不可等の場合

HAPサービスへのプロキシ追加時は、/data/mingdao/script/docker-compose.yaml 内の関連環境変数値が、プロキシ経由アクセス時のアドレスと一致しているか確認し、すべて推奨設定が含まれていることを確認してください。詳細：プロキシ設定参照。

サブパスデプロイの有効化

microserviceアプリのdocker-compose.yaml の ENV_MINGDAO_SUBPATH 環境変数を以下のように調整します。

services:
  app:
    environment:
      ENV_MINGDAO_SUBPATH: "/hap" # 例：/hap を追加

2つのアクセスポイントを有効化する方法

microserviceアプリのdocker-compose.yamlの ENV_EXT_MINGDAO_PROTO、ENV_EXT_MINGDAO_HOST、ENV_EXT_MINGDAO_PORT をセットします（ENV_MINGDAO_PROTO、ENV_MINGDAO_HOST、ENV_MINGDAO_PORTの各組み合わせで1セット）。ポート18880を公開（ホスト側ポートは任意設定可、例では18880）、http://example1.domain.com をホストの18880ポートへリダイレクトします（内部・外部IP直指定ならDNS不要）。設定例：

services:
  app:
    environment:
      ENV_EXT_MINGDAO_PROTO: "http"
      ENV_EXT_MINGDAO_HOST: "example1.domain.com"
      ENV_EXT_MINGDAO_PORT: "18880"
    ports:
      - 8880:8880
      - 18880:18880

デフォルトの保存先パスの変更方法

新規インストール

バージョン3.6.0以降

HAP manager起動前（. /service.sh start実行前）にservice.shのinstallDirパラメータ値を修正します。

3.6.0未満

HAP manager起動前（. /service.sh start実行前）に /etc/pdcaptain.json を作成し、dataDirプロパティを指定します。下記設定で /app/hap ディレクトリに関連ファイルが保存されます。

{
"dataDir": "/app/hap"
}

移行

バージョン3.6.0以降

インストール済みHAPの場合、service.sh の installDir 値を修正し、HAPサービス停止後に /data/mingdao の全ファイルを installDir に移動して再起動します。

3.6.0未満

インストール済みHAPの場合、/etc/pdcaptain.json を作成し保存先dataDirを指定、サービス停止後/data/mingdao配下全ファイルを新dataDirへ移動、サービス再起動します。

外部接続向けストレージコンポーネント公開方法

スタンドアロンデプロイモードでは、mysql、mongodb、redis、kafka、file、elasticsearchなどの依存ストレージコンポーネントはコンテナ内で立ち上がり、外部公開はデフォルトで無効です。外部接続が必要な場合は、microserviceアプリのdocker-compose.yaml のports項目で下記のように該当ポートを公開します。

事前にデータセキュリティのドキュメント内容を十分確認してください。 ⚠️⚠️⚠️

services:
  sc:
    ports:
      - 3306:3306   # mysql
      - 27017:27017 # mongodb
      - 6379:6379   # redis
      - 9092:9092   # kafka
      - 9000:9000   # file
      - 9200:9200   # elasticsearch

スタンドアロンモードで一部の外部ストレージコンポーネントのみ有効化する方法

microserviceアプリのdocker-compose.yamlに環境変数ENV_STANDALONE_DISABLE_SERVICESを設定し、mysql、mongodb、redis、kafka、file、elasticsearchの任意組み合わせで設定可能です。

services:
  app:
    environment:
      ENV_STANDALONE_DISABLE_SERVICES: "redis,file" # 複数の場合はカンマ区切り

カスタムストレージコンポーネントを有効化する場合は、対応サービスの接続先も環境変数経由で設定してください。環境変数詳細参照。

mongodbの最大メモリ容量カスタマイズ方法

microserviceアプリdocker-compose.yamlの環境変数ENV_MONGODB_CACHEGBで設定できます。デフォルト値は「（物理メモリ-10）/2」（単位：GB）です。

services:
  app:
    environment:
      ENV_MONGODB_CACHEGB: "3"

Redisの最大使用メモリをカスタマイズする方法

設定ファイルに ENV_REDIS_MAXMEMORY 環境変数を追加します。デフォルトでは無制限です。上限を設定すると、LRUアルゴリズムに基づいてデータが削除されます。

services:
  app:
    environment:
      ENV_REDIS_MAXMEMORY: "5gb"

他システムからIFrame参照する方法

デフォルトで同一ドメインIFrame埋め込みに対応しています。他システムから参照したい場合は、microserviceアプリのdocker-compose.yamlの環境変数ENV_FRAME_OPTIONSを設定します。ALLOWALL、SAMEORIGIN、DENY、ALLOW-FROM uriが指定可能です。

services:
  app:
    environment:
      ENV_FRAME_OPTIONS: "ALLOWALL"

IPホワイトリストによるアクセス制御設定方法

クライアント第1段のプロキシで制御する必要があります。設定例は以下の通りです。

# 例1

http {
server {
......
# 192.168.0.1のみ許可
allow 192.168.0.1;
# 192.168.0.1/32サブネットも許可
allow 192.168.0.1/32;
# その他全て拒否
deny all;
location / {
......
}
}
}

# 例2

http {
server {
......
location / {
allow 192.168.0.1;
allow 192.168.0.1/32;
deny all;
}
}
}

ワークフローのWebhook実行タイムアウト設定方法

microserviceアプリdocker-compose.yamlの環境変数ENV_WORKFLOW_WEBHOOK_TIMEOUTを設定します。デフォルトは10秒です。

services:
  app:
    environment:
      ENV_WORKFLOW_WEBHOOK_TIMEOUT: "30"

ワークフローのコードブロック実行タイムアウト設定方法

microserviceアプリdocker-compose.yamlのcommandサービスの環境変数ENV_WORKFLOW_COMMAND_TIMEOUTを設定します。デフォルトは10秒です。

services:
  command:
    environment:
      ENV_WORKFLOW_COMMAND_TIMEOUT: "30"

ワークフローのコードブロック最大メモリ容量のカスタマイズ方法

microserviceアプリdocker-compose.yamlのcommandサービスの環境変数ENV_WORKFLOW_COMMAND_MAXMEMORYを設定します。デフォルトは64MBです。

services:
  command:
    environment:
      ENV_WORKFLOW_COMMAND_MAXMEMORY: "128"

ワークフローのメッセージキューのパーティション数・滞留状況の確認と消費スレッド数の設定

消費スレッド数を変更する前に、Kafka の関連 Topic（WorkFlow、WorkFlow-Batch、WorkFlow-Button、WorkFlow-Process、WorkFlow-Router、WorkSheet、WorkSheet-Batch、WorkSheet-Router、WorkSheet-onlyimport）のパーティション数を調整してください。デフォルトは 10 です。消費スレッド数はパーティション数を超えないように設定してください。

コンテナに入ります：docker exec -it $(docker ps | grep '\-sc' | awk '{print $1}') bash

現在のパーティション数とメッセージの滞留状況を確認します。

/usr/local/kafka/bin/kafka-consumer-groups.sh --bootstrap-server ${ENV_KAFKA_ENDPOINTS:=127.0.0.1:9092} --describe --group md-workflow-consumer

上記のコマンドで Note: This will not show information about old Zookeeper-based consumers. と表示された場合は、次の手順で確認してください。

サーバーからインターネットに接続できる場合
サーバーからインターネットに接続できない場合

cd /tmp/ && wget https://pdpublic.mingdao.com/private-deployment/offline/common/kafka_2.13-3.4.0.tgz

# Kafka パッケージをダウンロードし、デプロイ先サーバーの /tmp/ にアップロードしてください：
https://pdpublic.mingdao.com/private-deployment/offline/common/kafka_2.13-3.4.0.tgz

docker cp /tmp/kafka_2.13-3.4.0.tgz $(docker ps | grep '\-sc' | awk '{print $1}'):/tmp/
docker exec -it $(docker ps | grep '\-sc' | awk '{print $1}') bash
cd /tmp/ && tar -zxvf kafka_2.13-3.4.0.tgz
cd /tmp/kafka_2.13-3.4.0/bin/ && ./kafka-consumer-groups.sh --bootstrap-server ${ENV_KAFKA_ENDPOINTS:=127.0.0.1:9092} --describe --group md-workflow-consumer

必要に応じて Kafka のパーティション数を調整します（以下は 20 に変更する例です）。

/usr/local/kafka/bin/kafka-topics.sh --alter --bootstrap-server ${ENV_KAFKA_ENDPOINTS:=127.0.0.1:9092} --partitions 20 --topic WorkFlow
/usr/local/kafka/bin/kafka-topics.sh --alter --bootstrap-server ${ENV_KAFKA_ENDPOINTS:=127.0.0.1:9092} --partitions 20 --topic WorkFlow-Batch
/usr/local/kafka/bin/kafka-topics.sh --alter --bootstrap-server ${ENV_KAFKA_ENDPOINTS:=127.0.0.1:9092} --partitions 20 --topic WorkFlow-Button
/usr/local/kafka/bin/kafka-topics.sh --alter --bootstrap-server ${ENV_KAFKA_ENDPOINTS:=127.0.0.1:9092} --partitions 20 --topic WorkFlow-Process
/usr/local/kafka/bin/kafka-topics.sh --alter --bootstrap-server ${ENV_KAFKA_ENDPOINTS:=127.0.0.1:9092} --partitions 20 --topic WorkFlow-Router
/usr/local/kafka/bin/kafka-topics.sh --alter --bootstrap-server ${ENV_KAFKA_ENDPOINTS:=127.0.0.1:9092} --partitions 20 --topic WorkSheet
/usr/local/kafka/bin/kafka-topics.sh --alter --bootstrap-server ${ENV_KAFKA_ENDPOINTS:=127.0.0.1:9092} --partitions 20 --topic WorkSheet-Batch
/usr/local/kafka/bin/kafka-topics.sh --alter --bootstrap-server ${ENV_KAFKA_ENDPOINTS:=127.0.0.1:9092} --partitions 20 --topic WorkSheet-Router
/usr/local/kafka/bin/kafka-topics.sh --alter --bootstrap-server ${ENV_KAFKA_ENDPOINTS:=127.0.0.1:9092} --partitions 20 --topic WorkSheet-onlyimport

設定ファイルに ENV_WORKFLOW_CONSUMER_THREADS を追加します。デフォルトは 10 です。サーバーのリソースに応じて設定し、過大な値を指定しないでください。以下は 20 に設定する例です。
```
services:
  app:
    environment:
      ENV_WORKFLOW_CONSUMER_THREADS: "20"
```

ワークシートイベントによるワークフロー遅延トリガーの設定方法

設定ファイルに ENV_WORKFLOW_TRIGER_DELAY_SECONDS を追加します。デフォルトは 5 秒です。以下は 1 秒に設定する例です。

services:
  app:
    environment:
      ENV_WORKFLOW_TRIGER_DELAY_SECONDS: "1"

ワークシートのメッセージキューのパーティション数・滞留状況の確認と消費スレッド数の設定

消費スレッド数を変更する前に、Kafka の関連 Topic（ws-editcontrols、ws-passiverelation、ws-formulaensure）のパーティション数を調整してください。デフォルトは 3 です。消費スレッド数はパーティション数を超えないように設定してください。

コンテナに入ります：docker exec -it $(docker ps | grep '\-sc' | awk '{print $1}') bash

現在のパーティション数とメッセージの滞留状況を確認します。

/usr/local/kafka/bin/kafka-consumer-groups.sh --bootstrap-server ${ENV_KAFKA_ENDPOINTS:=127.0.0.1:9092} --describe --group worksheet-passiverelation
/usr/local/kafka/bin/kafka-consumer-groups.sh --bootstrap-server ${ENV_KAFKA_ENDPOINTS:=127.0.0.1:9092} --describe --group worksheet-editcontrols
/usr/local/kafka/bin/kafka-consumer-groups.sh --bootstrap-server ${ENV_KAFKA_ENDPOINTS:=127.0.0.1:9092} --describe --group worksheet-formula

上記のコマンドで Note: This will not show information about old Zookeeper-based consumers. と表示された場合は、次の手順で確認してください。

サーバーからインターネットに接続できる場合
サーバーからインターネットに接続できない場合

cd /tmp/ && wget https://pdpublic.mingdao.com/private-deployment/offline/common/kafka_2.13-3.4.0.tgz

# Kafka パッケージをダウンロードし、デプロイ先サーバーの /tmp/ にアップロードしてください：
https://pdpublic.mingdao.com/private-deployment/offline/common/kafka_2.13-3.4.0.tgz

docker cp /tmp/kafka_2.13-3.4.0.tgz $(docker ps | grep '\-sc' | awk '{print $1}'):/tmp/
docker exec -it $(docker ps | grep '\-sc' | awk '{print $1}') bash
cd /tmp/ && tar -zxvf kafka_2.13-3.4.0.tgz
cd /tmp/kafka_2.13-3.4.0/bin/ && ./kafka-consumer-groups.sh --bootstrap-server ${ENV_KAFKA_ENDPOINTS:=127.0.0.1:9092} --describe --group worksheet-passiverelation
cd /tmp/kafka_2.13-3.4.0/bin/ && ./kafka-consumer-groups.sh --bootstrap-server ${ENV_KAFKA_ENDPOINTS:=127.0.0.1:9092} --describe --group worksheet-editcontrols
cd /tmp/kafka_2.13-3.4.0/bin/ && ./kafka-consumer-groups.sh --bootstrap-server ${ENV_KAFKA_ENDPOINTS:=127.0.0.1:9092} --describe --group worksheet-formula

必要に応じて Kafka のパーティション数を調整します（以下は 20 に変更する例です）。

/usr/local/kafka/bin/kafka-topics.sh --alter --bootstrap-server ${ENV_KAFKA_ENDPOINTS:=127.0.0.1:9092} --partitions 20 --topic ws-editcontrols
/usr/local/kafka/bin/kafka-topics.sh --alter --bootstrap-server ${ENV_KAFKA_ENDPOINTS:=127.0.0.1:9092} --partitions 20 --topic ws-passiverelation
/usr/local/kafka/bin/kafka-topics.sh --alter --bootstrap-server ${ENV_KAFKA_ENDPOINTS:=127.0.0.1:9092} --partitions 20 --topic ws-formulaensure

設定ファイルに ENV_WORKSHEET_CONSUMER_THREADS を追加します。デフォルトは 2 です。サーバーのリソースに応じて設定し、過大な値を指定しないでください。以下は 10 に設定する例です。
```
services:
  app:
    environment:
      ENV_WORKSHEET_CONSUMER_THREADS: "10"
```

機能モジュールのスタイルカスタマイズ方法

カスタムスタイルファイル（例：freestyle.css）を作成し、ブラウザ要素検索でタグ・ID・クラスを特定後、カスタムスタイル（例：機能モジュールの非表示・フォント／背景色変更など）設定

/* メッセージ機能モジュールを非表示 */
#chat {display:none!important }

microserviceアプリのdocker-compose.yaml内で、カスタムスタイルファイルをコンテナ（/usr/local/MDPrivateDeployment/www/staticfiles/mdcss/freestyle.css）にマウントし、サービス再起動で反映

services:
  app:
    volumes:
      - freestyle.css ホストパス:/usr/local/MDPrivateDeployment/www/staticfiles/mdcss/freestyle.css

詳細は https://github.com/mingdaocom/pd-openweb 参照

グローバルJavascriptスクリプトの追加方法

Google Analytics、Baidu統計、GrowingIO、SENSORS等の分析エンジン導入が可能です。

カスタム拡張スクリプトファイル（例：freestyle.js）を作成し、サードパーティ提供スクリプトをコピー。多くの場合、ユーザー固有ID等の情報参照が必要で、HAPシステムでmd.global.Accountのグローバルオブジェクトから情報取得可能。
microserviceアプリdocker-compose.yamlで拡張スクリプトファイル（/usr/local/MDPrivateDeployment/www/staticfiles/mdjs/freestyle.js）をコンテナにマウント、サービス再起動で有効化

services:
  app:
    volumes:
      - freestyle.js ホストパス:/usr/local/MDPrivateDeployment/www/staticfiles/mdjs/freestyle.js

詳細は https://github.com/mingdaocom/pd-openweb 参照

ログイン時に毎回認証コードを表示するかのカスタマイズ方法

microserviceアプリのdocker-compose.yamlでENV_LOGIN_CAPTCHA_LIMIT_COUNTを0にすると、毎回認証コードが表示されます。

services:
  app:
    environment:
      ENV_LOGIN_CAPTCHA_LIMIT_COUNT: "0"

連続ログイン失敗回数・ロック開始、ロック時間のカスタマイズ

ENV_LOGIN_LOCK_LIMIT_COUNT（デフォルト5）、ENV_LOGIN_LOCK_MINUTES（デフォルト20分）を設定

services:
  app:
    environment:
      ENV_LOGIN_LOCK_LIMIT_COUNT: "4"
      ENV_LOGIN_LOCK_MINUTES: "30"

同一IPによる連続ログイン失敗回数・ロック開始・ロック時間のカスタマイズ

ENV_LOGIN_IP_LOCK_LIMIT_COUNT・ENV_LOGIN_IP_LOCK_MINUTES（単位：分）を設定します。

有効化には、プロキシ側で X-Real-IP（プロキシ設定参照）ヘッダー追加が必須です。同一IPのクライアントが多いイントラ環境では全員影響となるためご注意ください。

services:
  app:
    environment:
      ENV_LOGIN_IP_LOCK_LIMIT_COUNT: "10"
      ENV_LOGIN_IP_LOCK_MINUTES: "30"

アップロードファイル拡張子のブラック・ホワイトリスト設定

microserviceアプリ（スタンドアロンモード・ファイルストレージサービスのクラスターモード両対応）で、 ENV_FILEEXT_BLOCKLIST（ブラックリスト、デフォルト：.exe,.vbs,.bat,.cmd,.com,.sh） ENV_FILEEXT_ALLOWLIST（ホワイトリスト、デフォ：.exe,.vbs,.bat,.cmd,.com,.sh）環境変数をdocker-compose.yamlで設定します。 ENV_FILEEXT_ALLOWLISTをセットした場合、ENV_FILEEXT_BLOCKLISTは自動的に無効になります。

services:
  app:
    environment:
      ENV_FILEEXT_BLOCKLIST: ".exe,.sh,.html"
      ENV_FILEEXT_ALLOWLIST: ".docx,.txt,.png"

添付ファイルのアップロード・ダウンロード時トークン有効期限の設定

microserviceアプリdocker-compose.yamlで ENV_FILE_UPLOAD_TOKEN_EXPIRE_MINUTES（アップロード、デフォ120分/最大5256000分） ENV_FILE_DOWNLOAD_TOKEN_EXPIRE_MINUTES（ダウンロード、デフォ60分/最大5256000分）環境変数を設定します。

services:
  app:
    environment:
      ENV_FILE_UPLOAD_TOKEN_EXPIRE_MINUTES: "10"
      ENV_FILE_DOWNLOAD_TOKEN_EXPIRE_MINUTES: "10"

Feishuへのメッセージキューによる送信

Feishu連携モードで、設定ファイルに ENV_INTEGRATE_MESSAGE_MQ_ENABLE を追加すると、メッセージキューによる送信が有効になり、APIの呼び出し頻度を抑えてレート制限を回避できます。

services:
  app:
    environment:
      ENV_INTEGRATE_MESSAGE_MQ_ENABLE: "true"

Amap API Keyの設定方法

Gaodeオープンプラットフォーム https://lbs.amap.com で開発者アカウント登録（個人・企業どちらも可）
アプリ作成・Key設定。サービスプラットフォームで「Web（JS API）」を選択し、KeyとセキュリティKeyを取得
HAPシステムのプラットフォーム管理＞連携＞基本＞マップサービスでAmapタイプ選択しAPI KeyとセキュリティKeyを登録
システム位置情報・マップ機能使用時に異常発生ならAmap使用量不足を確認。Amapコンソールでリアルタイム利用量を参照、利用量不足時は https://lbs.amap.com/upgrade#price 参照、通常は基本検索サービス流量パック購入で対応可能

オンライン翻訳リソースファイルの参照方法

デフォルトでは、マイクロサービスイメージに内包された翻訳リソースファイルを参照します。バージョン更新サイクルが不定なため、最新翻訳リソースを迅速に参照する用途で外部翻訳リソースの指定が可能です。

microserviceアプリのdocker-compose.yamlで環境変数ENV_TRANSLATION_SOURCE_HOST_V2を追加します。

services:
  app:
    environment:
      ENV_TRANSLATION_SOURCE_HOST_V2: "https://alifile.mingdaocloud.com/lang/HAP-Private"

注意点：

デプロイ環境はhttps://alifile.mingdaocloud.com/lang/HAP-Private へのアクセスが必要です
フロントエンドでの二次開発は推奨しません（文言内容の非互換や翻訳ズレが生じる可能性）

WebフロントエンドをCDN配信リソースで参照させる方法

クラウドマーケット（例：Tencent Cloud、Alibaba Cloud）でCDNを購入（既存サービスがあれば不要）
アクセラレーション用ドメイン設定とバックエンド（HAPシステムアクセス）を接続
microserviceアプリdocker-compose.yamlでENV_CDN_URI環境変数に「アクセラレーション用ドメイン名」を指定

services:
  app:
    environment:
      ENV_CDN_URI: "アクセラレーション用ドメイン名"

コンテナにhosts名前解決を追加する方法

appサービスに extra_hosts を追加します。

services:
  app:
    extra_hosts:
      - "a.domain.com:192.168.1.10"
      - "b.domain.com:172.17.13.42"

アップグレード後に画面左下のバージョン番号が正しく表示されない場合

設定ファイルのappサービスに ENV_APP_VERSION を追加し、サービスを再起動してください。

services:
  app:
    environment:
      ENV_APP_VERSION: "7.5.3"

再インストール方法​

初期化に失敗した場合​

コンテナ内でインターネットに接続できない場合​

初期化完了後に「ログアウトしました。再度ログインしてください」と表示される場合​

サービス起動後に「Service response code error」が出る場合​

サーバー起動時の自動起動設定方法​

サーバー再起動後にHAPサービスが正常起動しない場合​

キー紛失やサーバーIDが表示されない場合の対処​

Kafka起動失敗時​

ドキュメントのオンラインプレビュー不可の場合​

ワークシートをExcelでエクスポートできない場合​

添付ファイルアップロード時にインターフェースがタイムアウトする場合​

ワークフロー一覧の取得失敗、添付ファイルダウンロード不可等の場合​

サブパスデプロイの有効化​

2つのアクセスポイントを有効化する方法​

デフォルトの保存先パスの変更方法​

バージョン3.6.0以降​

3.6.0未満​

バージョン3.6.0以降​

3.6.0未満​

外部接続向けストレージコンポーネント公開方法​

スタンドアロンモードで一部の外部ストレージコンポーネントのみ有効化する方法​

mongodbの最大メモリ容量カスタマイズ方法​

Redisの最大使用メモリをカスタマイズする方法​

他システムからIFrame参照する方法​

IPホワイトリストによるアクセス制御設定方法​

ワークフローのWebhook実行タイムアウト設定方法​

ワークフローのコードブロック実行タイムアウト設定方法​

ワークフローのコードブロック最大メモリ容量のカスタマイズ方法​

ワークフローのメッセージキューのパーティション数・滞留状況の確認と消費スレッド数の設定​

ワークシートイベントによるワークフロー遅延トリガーの設定方法​

ワークシートのメッセージキューのパーティション数・滞留状況の確認と消費スレッド数の設定​

機能モジュールのスタイルカスタマイズ方法​

グローバルJavascriptスクリプトの追加方法​

ログイン時に毎回認証コードを表示するかのカスタマイズ方法​

連続ログイン失敗回数・ロック開始、ロック時間のカスタマイズ​

同一IPによる連続ログイン失敗回数・ロック開始・ロック時間のカスタマイズ​

アップロードファイル拡張子のブラック・ホワイトリスト設定​

添付ファイルのアップロード・ダウンロード時トークン有効期限の設定​

Feishuへのメッセージキューによる送信​

Amap API Keyの設定方法​

オンライン翻訳リソースファイルの参照方法​

WebフロントエンドをCDN配信リソースで参照させる方法​

コンテナにhosts名前解決を追加する方法​

アップグレード後に画面左下のバージョン番号が正しく表示されない場合​

再インストール方法

初期化に失敗した場合

コンテナ内でインターネットに接続できない場合

初期化完了後に「ログアウトしました。再度ログインしてください」と表示される場合

サービス起動後に「Service response code error」が出る場合

サーバー起動時の自動起動設定方法

サーバー再起動後にHAPサービスが正常起動しない場合

キー紛失やサーバーIDが表示されない場合の対処

Kafka起動失敗時

ドキュメントのオンラインプレビュー不可の場合

ワークシートをExcelでエクスポートできない場合

添付ファイルアップロード時にインターフェースがタイムアウトする場合

ワークフロー一覧の取得失敗、添付ファイルダウンロード不可等の場合

サブパスデプロイの有効化

2つのアクセスポイントを有効化する方法

デフォルトの保存先パスの変更方法

バージョン3.6.0以降

3.6.0未満

バージョン3.6.0以降

3.6.0未満

外部接続向けストレージコンポーネント公開方法

スタンドアロンモードで一部の外部ストレージコンポーネントのみ有効化する方法

mongodbの最大メモリ容量カスタマイズ方法

Redisの最大使用メモリをカスタマイズする方法

他システムからIFrame参照する方法

IPホワイトリストによるアクセス制御設定方法

ワークフローのWebhook実行タイムアウト設定方法

ワークフローのコードブロック実行タイムアウト設定方法

ワークフローのコードブロック最大メモリ容量のカスタマイズ方法

ワークフローのメッセージキューのパーティション数・滞留状況の確認と消費スレッド数の設定

ワークシートイベントによるワークフロー遅延トリガーの設定方法

ワークシートのメッセージキューのパーティション数・滞留状況の確認と消費スレッド数の設定

機能モジュールのスタイルカスタマイズ方法

グローバルJavascriptスクリプトの追加方法

ログイン時に毎回認証コードを表示するかのカスタマイズ方法

連続ログイン失敗回数・ロック開始、ロック時間のカスタマイズ

同一IPによる連続ログイン失敗回数・ロック開始・ロック時間のカスタマイズ

アップロードファイル拡張子のブラック・ホワイトリスト設定

添付ファイルのアップロード・ダウンロード時トークン有効期限の設定

Feishuへのメッセージキューによる送信

Amap API Keyの設定方法

オンライン翻訳リソースファイルの参照方法

WebフロントエンドをCDN配信リソースで参照させる方法

コンテナにhosts名前解決を追加する方法

アップグレード後に画面左下のバージョン番号が正しく表示されない場合