Skip to main content

フロントエンドカスタム静的リソースマウントガイド

本ドキュメントでは、SERVICEME NEXT 製品のフロントエンドサービスを通じて、カスタムページ、個別開発フロントエンドプロジェクト、または外部サービスのリバースプロキシをマウントする方法について説明します。


設定概要

serviceme-frontend の Docker イメージには、カスタム Nginx 設定 および 静的リソースホスティング 用に2つのマウント可能なディレクトリが用意されています:

  • /etc/nginx/custom_conf:カスタム Nginx 設定ディレクトリ。このディレクトリ内の設定ファイルは自動的に Nginx のコア server 設定ブロックにマージされます。
  • /usr/share/nginx/static:静的リソースディレクトリ。カスタムウェブページ、ファイル、またはフロントエンドビルド成果物のホスティングに使用します。

上記ディレクトリをコンテナ起動時にマウントすることで、フロントエンドサービスの内容や挙動を柔軟に拡張できます。


カスタム HTML ページのマウント

単独の HTML ページ(例:static/app2/index.html)をホスティングする場合、以下の手順で操作します:

  1. カスタム設定ファイル custom.conf を作成し、以下の内容を記述します:

    location /app2 {
    root /usr/share/nginx/static/;
    index index.html index.htm index.shtml;
    try_files $uri $uri/ /index.html;

    if ($request_filename ~* .*\.html$) {
    add_header Cache-Control "no-cache, no-store";
    }
    }

    この設定は、Nginx が https://<ドメイン>/app2 アクセス時に指定ページをロードするよう指示します。

  2. Docker コンテナを起動します:

    Linux / macOS 環境:

    docker run -p 80:80 \
    -e SML_BACKEND_URL=https://dev.next.serviceme.com/webapi/ \
    -e SML_KNOWLEDGE_BACKEND_URL=https://dev.next.serviceme.com/knowledge-webapi/ \
    -v ./custom.conf:/etc/nginx/custom_conf/custom.conf \
    -v ./static:/usr/share/nginx/static \
    servicemerelease.azurecr.io/serviceme-frontend:4.0.0-rc.2-build.5

    Windows 環境:

    docker run -p 80:80 `
    -e SML_BACKEND_URL=https://dev.next.serviceme.com/webapi/ `
    -e SML_KNOWLEDGE_BACKEND_URL=https://dev.next.serviceme.com/knowledge-webapi/ `
    -v ${PWD}\custom.conf:/etc/nginx/custom_conf/custom.conf `
    -v ${PWD}\static:/usr/share/nginx/static `
    servicemerelease.azurecr.io/serviceme-frontend:4.0.0-rc.2-build.5
  3. 起動後、http://localhost/app2 にアクセスしてホスティングページを確認できます。


個別開発フロントエンドプロジェクトのマウント

この方法は、React、Vue、Angular、Vite など技術スタックを問わず、カスタム開発されたフロントエンドプロジェクトのマウントをサポートします。
デプロイ前に、プロジェクトの ビルドパス(base) および ルートディレクトリ(basename) を正しく設定してください。

1. Vite プロジェクトを例に

localhost/app1 パスにデプロイする場合、vite.config.ts に以下を追加します:

import { defineConfig } from "vite";
import react from "@vitejs/plugin-react";

export default defineConfig({
plugins: [react()],
base: "/app1/", // ビルドルートパスを指定
});

2. React Router のルートディレクトリ設定

createBrowserRouter(routes, {
basename: import.meta.env.BASE_URL
});

これにより、アプリケーションが指定サブパスで正常にロードされます。
ビルド完了後、成果物を static/app1/ ディレクトリに配置し、前述の方法でコンテナを起動すればアクセス可能です。


外部サービスのリバースプロキシ

Nginx 設定は標準的なリバースプロキシをサポートします。
例えば、/app3 パスを外部サイトにプロキシする場合:

location /app3 {
proxy_pass https://example.com/;
}

この設定は、外部ウェブページ、ドキュメント、またはサードパーティシステムの埋め込みに利用できます。


個別開発バックエンドサービスのリバースプロキシ

フロントエンドパス下で内部コンテナサービス(カスタムデリバリーバックエンドなど)にアクセスする場合、以下の設定を使用できます:

location /custom-backend/ {
proxy_pass http://serviceme_elc/;
proxy_connect_timeout 240s;
proxy_read_timeout 240s;
proxy_send_timeout 240s;
proxy_buffering off;
}

注意:

  • フロントエンドコンテナとバックエンドコンテナは同一 Docker ネットワーク上にある必要があります。
  • Docker はコンテナ名(例:serviceme_elc)を自動的にホスト名として解決します。

指定静的ファイルのマウント

一部の外部システム(例:WeChat Work など)との連携時、ルートドメイン直下に特定の検証ファイルを配置する必要があります。
例えば、ルートディレクトリに WW_verify_asD8saBGs.txt ファイルをマウントする場合、以下の設定を使用します:

location = /WW_verify_asD8saBGs.txt {
root /usr/share/nginx/static/;
}

このファイルを ./static/ ディレクトリに配置し、設定ファイルと静的ディレクトリをマウントします:

docker run \
-v ./custom.conf:/etc/nginx/custom_conf/custom.conf \
-v ./static:/usr/share/nginx/static \
servicemerelease.azurecr.io/serviceme-frontend:4.0.0-rc.2-build.5

製品静的リソースの上書き

カスタム Nginx 設定は製品デフォルト設定より優先されるため、組み込み静的リソースの上書きが可能です。
例えば、製品の PWA マニフェストやアイコンをカスタマイズする場合:

location ~* ^/(manifest.webmanifest|customer-logo.svg)$ {
root /usr/share/nginx/static/;
}

./static ディレクトリにカスタムファイルを配置します。例:

manifest.webmanifest

{
"$schema": "https://json.schemastore.org/web-manifest-combined.json",
"name": "SERVICEME-カスタム",
"short_name": "SERVICEME",
"start_url": "/",
"display": "standalone",
"background_color": "#ffffff",
"theme_color": "#ffffff",
"lang": "en",
"scope": "./",
"description": "テスト版設定",
"icons": [
{
"src": "/customer-logo.svg",
"sizes": "any",
"type": "image/svg+xml"
}
]
}

まとめ

上記の方法により、管理者は製品のコアコードを変更せずに以下の機能を実現できます:

  • カスタムウェブページや静的リソースの迅速なマウント
  • 独立したフロントエンドプロジェクトのデプロイ
  • 外部または内部サービスのリバースプロキシ
  • 製品デフォルトリソースファイルの上書き

この仕組みにより、SERVICEME NEXT の拡張性と柔軟な統合能力が大幅に向上し、企業の多様なシナリオでの導入やカスタマイズ要件に対応できます。