メインコンテンツへ移動

デプロイ関連の問題

再インストール方法​

  1. 実行中のHAPサービスがあれば停止します。managerのルートディレクトリで bash ./service.sh stopall を実行し、停止されたことを確認します(正常停止時に「stopped」と表示されます)。
  2. HAPサービスのファイルをバックアップします。mv /data/mingdao/ /home/hapbak/ を実行します(バックアップの保存先は任意で指定可能です。初回のデプロイ時は不要な場合が多く、rm -rf /data/mingdao/ でも構いません)。
  3. クリーンアップが完了していることを再度確認します。docker ps | grep mingdaoyun、netstat -ntpl | grep 38881、ps -ef | grep 'mingdaoyun|service.sh' | grep -v grep を各々実行し、出力が空であることを確認します。
  4. bash ./service.sh start でmanagerを再起動し、http://{サーバーIP}:38881 にアクセスして再インストールします。

初期化に失敗した場合​

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

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

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

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

確認方法:

  1. HAPページにアクセス可能か確認します。正常に利用できればコアサービスは起動しています。
  2. マイクロサービスコンテナのログを以下で確認します:
docker logs $(docker ps | grep -E 'mingdaoyun-community|mingdaoyun-hap' | awk '{print $1}')
  • INFOレベルが中心なら正常動作です。
  • ERRORやWARNレベルのログがあれば注意してください。

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

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

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

実装方法: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

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

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

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

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

Kafka起動失敗時​

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

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

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

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

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

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

  1. managerルートディレクトリで bash ./service.sh stopall 実行
  2. 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)}
  1. 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"

他システムから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 です。消費スレッド数はパーティション数を超えないように設定してください。

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

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

    /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
      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
  3. 必要に応じて 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
  4. 設定ファイルに 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 です。消費スレッド数はパーティション数を超えないように設定してください。

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

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

    /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
      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
  3. 必要に応じて 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
  4. 設定ファイルに ENV_WORKSHEET_CONSUMER_THREADS を追加します。デフォルトは 2 です。サーバーのリソースに応じて設定し、過大な値を指定しないでください。以下は 10 に設定する例です。

    services:
    app:
    environment:
    ENV_WORKSHEET_CONSUMER_THREADS: "10"

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

  1. カスタムスタイルファイル(例:freestyle.css)を作成し、ブラウザ要素検索でタグ・ID・クラスを特定後、カスタムスタイル(例:機能モジュールの非表示・フォント/背景色変更など)設定
/* メッセージ機能モジュールを非表示 */
#chat {display:none!important }
  1. 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等の分析エンジン導入が可能です。

  1. カスタム拡張スクリプトファイル(例:freestyle.js)を作成し、サードパーティ提供スクリプトをコピー。多くの場合、ユーザー固有ID等の情報参照が必要で、HAPシステムでmd.global.Accountのグローバルオブジェクトから情報取得可能。
  2. 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の設定方法​

  1. Gaodeオープンプラットフォーム https://lbs.amap.com で開発者アカウント登録(個人・企業どちらも可)
  2. アプリ作成・Key設定。サービスプラットフォームで「Web(JS API)」を選択し、KeyとセキュリティKeyを取得
  3. HAPシステムのプラットフォーム管理 > 連携 > 基本 > マップサービスでAmapタイプ選択しAPI KeyとセキュリティKeyを登録
  4. システム位置情報・マップ機能使用時に異常発生なら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"

注意点:

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

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

  1. クラウドマーケット(例:Tencent Cloud、Alibaba Cloud)でCDNを購入(既存サービスがあれば不要)
  2. アクセラレーション用ドメイン設定とバックエンド(HAPシステムアクセス)を接続
  3. 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.1"