NocoBase Documentation

＃キャディー

すでにドメイン名を持っていて、できるだけ早く HTTPS を構成したい場合は、通常、nb proxy caddy が最も安心な入力方法です。

Caddy は、Nginx の証明書構成を自分で管理するのではなく、「最初にエントリー層を実行する」ためのデフォルトのショートカットのようなものです。

Caddy を使用するのが適切なのはどのような場合ですか?

一般的に、次の場合はキャディが優先されます。

すでにドメイン名を持っており、できるだけ早く HTTPS にアクセスしたい場合
あまりにも多くの証明書と TLS の詳細を自分で管理したくない
必要なのはシンプルで安定した入口層だけです

すでに Nginx を使用してサーバー上の多くのサイトを管理している場合、または後でさらに大規模なキャッシュ、アクセス制御、およびカスタマイズルールを実行する必要がある場合は、引き続き Nginx を確認する方がスムーズです。

まず、次の 3 つのコマンドに従います。

最初に Caddy エントリレイヤーを実行したいだけの場合は、デフォルトで次の 3 つのコマンドを覚えておくだけで十分です。

nb proxy caddy use docker
nb proxy caddy generate --env test2 --host c.local.nocobase.com
nb proxy caddy reload

Caddy がローカルにインストールされている場合は、最初のエントリを nb proxy caddy use local に変更するだけです。

ほとんどのシナリオでは、最初に use、次に generate、最後に reload を実行するだけで十分です。その他の詳細とその他のコマンドについては、次の章または CLI リファレンスを参照してください。

ステップ 1: Caddy を自分で実行する方法を選択する

現在のマシンに Caddy がすでにインストールされている場合は、use local を使用してください。

Caddy の Docker バージョンを使用する場合は、use docker を使用します。

ここでの local / docker は Caddy 自体の動作方法を指します。

Docker バージョンの Caddy を使用する場合:

nb proxy caddy use docker

Caddy のローカルインストールを使用する場合:

nb proxy caddy use local

後で現在どのメソッドが選択されているかを忘れた場合は、次のコマンドを実行できます。

nb proxy caddy current

ステップ 2: `generate` を実行する

generate は、指定された環境に従って Caddy 構成を生成するために使用されます。最も一般的な書き方は次のとおりです。

nb proxy caddy generate --env test2 --host c.local.nocobase.com

エントリポートも指定したい場合は、それを一緒に記述することもできます。

nb proxy caddy generate --env test2 --host c.local.nocobase.com --port 8080

ここでのパラメータの意味は次のとおりです。

--env: 構成を生成する CLI 環境を指定します
--host: 外部アクセス用のドメイン名を指定します
--port: プロキシエントリポートを指定します

キャディにとって、--host は特に重要です。正式な環境では、HTTPS アクセスがより自然になるように、デフォルトで解決されたドメイン名を現在のサーバーに渡すようにしてください。

env に appPort が欠落しているというコマンドプロンプトが表示された場合は、最初に次のコマンドを実行します。

nb env update test2 --app-port 56575

後でプロキシの結果に影響する app-port や app-public-path などの構成を変更する場合は、必ず generate を再実行してください。

ステップ 3: `reload` を実行する

構成を生成した後、次を直接実行します。

nb proxy caddy reload

ほとんどのシナリオでは、このコマンドを直接使用します。まだ実行されていない場合、起動は最初に内部で処理されます。すでに実行されている場合は、最新の構成に従って再ロードされます。

CLI はどのファイルを維持しますか?

test2 を例にとると、Caddy 関連のコマンドは通常、次のファイルとディレクトリを維持します。

パス	関数
`NB_CLI_ROOT/.nocobase/proxy/caddy/test2/app.caddy`	CLI によって生成される完全なサイト構成
`NB_CLI_ROOT/.nocobase/proxy/caddy/nocobase.caddy`	Caddy 一般エントリファイル。すべての環境の `app.caddy` のインポートを担当します。
`NB_CLI_ROOT/.nocobase/proxy/caddy/test2/public/index-v1.html`	v1 SPA フォールバックページ
`NB_CLI_ROOT/.nocobase/proxy/caddy/test2/public/index-v2.html`	v2 SPA フォールバックページ
`NB_CLI_ROOT/test2/storage/dist-client`	現在使用されているフロントエンドビルド製品ディレクトリ
`NB_CLI_ROOT/test2/storage/uploads`	現在のアプリケーションのアップロードディレクトリ

で：

NB_CLI_ROOT/.nocobase/proxy/caddy/... 以下は、CLI によって維持されるエージェント補助ファイルです。
NB_CLI_ROOT/test2/storage/... 以下は、アプリケーション独自の静的リソースとアップロードディレクトリです。
nocobase.caddy はプロバイダーレベルのエントリファイルであり、通常は手動で変更する必要はありません。
app.caddy は、特定の環境の完全な Caddy サイト構成です。 generate を再実行すると、全体が上書きされます。

:::警告メモ

追加のヘッダー、認証、速度制限、圧縮戦略など、Caddy のサイトレベルの構成を補いたい場合は、まず app.caddy に基づいて調整できます。ただし、その後 generate を再実行すると、このファイルが上書きされることに注意してください。

:::

手書き設定: CLI を使用しない場合の対処方法

アプリケーションが CLI でホストされていない場合、または完全な Caddy 構成を自分で明示的に保守したい場合は、手動で作成することもできます。

ただし、NocoBase の場合、運用環境エントリは通常、単なる reverse_proxy ではありません。 API リクエストをバックエンドアプリケーションに転送することに加えて、完全で機能する Caddy 構成では通常、アップロードディレクトリ、フロントエンド静的リソース、.well-known ルーティング、WebSocket、および SPA フォールバックページも処理する必要があります。

test2 を例に挙げると、通常、Caddy に関連する主要なディレクトリには次のものが含まれます。

SPA フォールバックページディレクトリ: NB_CLI_ROOT/.nocobase/proxy/caddy/test2/public
フロントエンドビルド製品ディレクトリ: NB_CLI_ROOT/test2/storage/dist-client
アップロードディレクトリ: NB_CLI_ROOT/test2/storage/uploads

つまり、手書きの設定では通常、少なくとも次の種類のエントリをカバーする必要があります。

v: /v を /v/ にリダイレクトします
uploads: アップロードディレクトリを公開する
dist: フロントエンドビルド製品ディレクトリを公開します
oauth well-known: OAuth 検出パスの処理
openid well-known: OpenID 検出パスの処理
api: /api/ リクエストをバックエンドアプリケーションに転送します
ws: WebSocket リクエストをバックエンドアプリケーションに転送します。
spa v2: /v/ のフロントエンドのエントリとリターンページを提供します
spa v1: / のフロントエンドエントリとリターンページを提供します。

したがって、完全な Caddy 構成は通常、次のような一般的な方法で記述するだけでは済みません。

your-domain.com {
  reverse_proxy 127.0.0.1:13000
}

test2 のような CLI でホストされるアプリケーションの場合、実際のデプロイメントに近い構造は通常次のようになります。

c.local.nocobase.com {
    encode zstd gzip

    handle /v {
        redir * /v/ 302
    }

    handle_path /storage/uploads/* {
        root * NB_CLI_ROOT/test2/storage/uploads
        header Cache-Control public
        header X-Content-Type-Options nosniff
        file_server
    }

    handle_path /dist/* {
        root * NB_CLI_ROOT/test2/storage/dist-client
        header Cache-Control public
        file_server
    }

    @oauth path_regexp oauth ^/\\.well-known/oauth-authorization-server/(.+)$
    handle @oauth {
        rewrite * /{re.oauth.1}/.well-known/oauth-authorization-server
        reverse_proxy host.docker.internal:56575
    }

    @openid path_regexp openid ^/\\.well-known/openid-configuration/(.+)$
    handle @openid {
        rewrite * /{re.openid.1}/.well-known/openid-configuration
        reverse_proxy host.docker.internal:56575
    }

    handle /api/* {
        reverse_proxy host.docker.internal:56575
    }

    handle /ws {
        reverse_proxy host.docker.internal:56575
    }

    handle_path /v/* {
        root * NB_CLI_ROOT/.nocobase/proxy/caddy/test2/public
        header Cache-Control "no-store, no-cache, must-revalidate"
        header X-Robots-Tag "noindex, nofollow"
        try_files {path} /index-v2.html
        file_server
    }

    handle_path /* {
        root * NB_CLI_ROOT/.nocobase/proxy/caddy/test2/public
        header Cache-Control "no-store, no-cache, must-revalidate"
        header X-Robots-Tag "noindex, nofollow"
        try_files {path} /index-v1.html
        file_server
    }
}

ここでも重要なポイントが 2 つあります。

NB_CLI_ROOT/.nocobase/proxy/caddy/... 以下は、CLI によって維持される SPA ロールバックページのディレクトリです。
NB_CLI_ROOT/test2/storage/... 以下は、独自のビルド製品ディレクトリとアップロードディレクトリの使用方法です。

アプリケーションがサブパスデプロイメントを使用している場合、またはフロントエンドリソース、アップロードディレクトリ、およびエントリ層が同じパスパースペクティブにない場合、手書きの構成はエラーが発生しやすくなります。このシナリオでは、通常は以下を実行することをお勧めします。

nb proxy caddy generate --env test2 --host c.local.nocobase.com

次に、生成された結果に基づいて調整を行います。

CLI を使用してパスとルートを最初に実行できるようにする場合、通常、生成される構造は次のようになります。

NB_CLI_ROOT/.nocobase/proxy/caddy/nocobase.caddy
NB_CLI_ROOT/.nocobase/proxy/caddy/test2/app.caddy
NB_CLI_ROOT/.nocobase/proxy/caddy/test2/public/index-v1.html
NB_CLI_ROOT/.nocobase/proxy/caddy/test2/public/index-v2.html
NB_CLI_ROOT/test2/storage/dist-client
NB_CLI_ROOT/test2/storage/uploads

で：

nocobase.caddy は import */app.caddy を統合する責任があります
test2/app.caddy は、この環境 test2 の完全なサイト構成です。
public/index-v1.html および public/index-v2.html は CLI で生成された SPA フォールバックページです

通常、より賢明なアプローチは次のとおりです。

まず、CLI で Caddy 構成を生成します。
生成された結果に基づいて、ルーティング構造と実際のパスを確認します。
次に、ドメイン名、実行モード、マウントパスに従って手動で調整します。

通常、この方法では、構成を最初から手書きするよりも、WebSocket、静的リソース、アップロードディレクトリ、.well-known ルート、または SPA フォールバックページに関連する詳細を見逃す可能性が低くなります。

設定を確認してリロードする

Caddy 構成を作成するか手動で調整する場合は、変更を加えた後に最初に検証してからリロードします。

caddy validate --config /etc/caddy/Caddyfile
systemctl reload caddy

Caddy の管理に systemd を使用していない場合は、代わりに独自の起動メソッドとリロードメソッドを使用できます。

nb proxy caddy を通じてエントリー層を管理する場合、通常は以下を使用することをお勧めします。

nb proxy caddy reload

現在のドライバー、合計エントリーファイルパス、ランタイムルートディレクトリ、コンテナーまたはローカルバイナリ情報を確認したい場合は、次のコマンドを実行できます。

nb proxy caddy info

実行中かどうかをすぐに確認したい場合は、次のコマンドを実行できます。

nb proxy caddy status

共通の指示

nb proxy caddy generate は、nb init によってインストールされたアプリケーション用です
サーバーに通常どおり解決できるドメイン名をすでに持っている場合は、多くの場合、Caddy が HTTPS を取得する最速の方法です。
その後、プロキシの結果に影響する app-port や app-public-path などの構成を変更する場合は、必ず generate を再実行してください。

#Caddy を使用するのが適切なのはどのような場合ですか?

#まず、次の 3 つのコマンドに従います。

#ステップ 1: Caddy を自分で実行する方法を選択する

#ステップ 2: generate を実行する

#ステップ 3: reload を実行する

#CLI はどのファイルを維持しますか?

#手書き設定: CLI を使用しない場合の対処方法

#設定を確認してリロードする

#共通の指示

#関連リンク