デプロイ関連の問題
再インストール方法
- 実行中のHAPサービスがあれば停止します。managerのルートディレクトリで
bash ./service.sh stopallを実行し、停止されたことを確認します(正常停止時に「stopped」と表示されます)。 - HAPサービスのファイルをバックアップします。
mv /data/hap/ /home/hapbak/を実行します(バックアップの保存先は任意で指定可能です。初回のデプロイ時は不要な場合が多く、rm -rf /data/hap/でも構いません)。 - クリーンアップが完了していることを再度確認します。
docker ps | grep hap、netstat -ntpl | grep 38881、ps -ef | grep 'hap|service.sh' | grep -v grepを各々実行し、出力が空であることを確認します。 bash ./service.sh startでmanagerを再起動し、http://{サーバーIP}:38881にアクセスして再インストールします。
初期化に失敗した場合
cat /data/hap/script/hap.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分でヘルスチェックが行われ、タイムアウト内で応答が返らないとこのエラーとなります。
確認方法:
- HAPページにアクセス可能か確認します。正常に利用できればコアサービスは起動しています。
- マイクロサービスコンテナのログを以下で確認します:
docker logs $(docker ps | grep -E 'hap-community|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 'hap|service.sh' | grep -v grepで該当プロセスが残っていれば全てpidをkillbash ./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/hap/script/volume/data/kafka{,_bak_$(date +%Y%m%d%H%M)}
mv /data/hap/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/hap/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/hap の全ファイルを installDir に移動して再起 動します。
3.6.0未満
インストール済みHAPの場合、/etc/pdcaptain.json を作成し保存先dataDirを指定、サービス停止後/data/hap配下全ファイルを新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" # 複数の場合はカンマ区切り
カスタムストレージコンポーネントを有効化する場合は、対応サービスの接続先も環境変数経由で設定してください。環境変数詳細参照。