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";
    }
    }

    この設定は、https://<ドメイン>/app2 へのアクセス時に指定したページを読み込むよう Nginx に指示します。

  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)をホスト名として自動解決します。

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

一部の外部システム(例:企業微信)では、ルートドメイン下に特定の検証ファイルを配置する必要があります。
例えば、ルートディレクトリに 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 の拡張性と柔軟な統合能力を大幅に向上させ、企業の多様なシナリオ展開およびカスタマイズニーズに適しています。