NocoBase Documentation

#Кэдди

Если у вас уже есть доменное имя и вы хотите как можно скорее настроить HTTPS, то nb proxy caddy обычно является наиболее простым способом входа.

Вместо того, чтобы самостоятельно поддерживать конфигурацию сертификата Nginx, Caddy больше похож на ярлык по умолчанию, позволяющий «сначала пройти через входной уровень».

Когда уместнее использовать Caddy?

Вообще говоря, Caddy имеет приоритет в следующих ситуациях:

У вас уже есть доменное имя и вы хотите получить доступ к HTTPS как можно скорее.
Вы не хотите хранить слишком много сертификатов и данных TLS самостоятельно.
Все, что вам нужно, это простой и стабильный входной слой.

Если вы уже использовали Nginx для управления многими сайтами на сервере или вам нужно будет позже выполнить более сложные правила кэширования, контроля доступа и настройки, то будет проще продолжить просмотр Nginx.

Сначала выполните эти три команды.

Если вы просто хотите сначала запустить входной уровень Caddy, достаточно запомнить эти три команды по умолчанию:

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.

Использование версии Caddy для Docker:

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`	Резервная страница SPA v1
`NB_CLI_ROOT/.nocobase/proxy/caddy/test2/public/index-v2.html`	Резервная страница SPA v2
`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
}

Для приложения, размещаемого через CLI, такого как test2, структура, более близкая к реальному развертыванию, обычно выглядит следующим образом:

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

Здесь также есть два ключевых момента:

NB_CLI_ROOT/.nocobase/proxy/caddy/... Ниже приведен каталог страниц отката SPA, поддерживаемый CLI.
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 — это резервные страницы SPA, созданные с помощью CLI.

Обычно более разумный подход:

Сначала позвольте CLI сгенерировать конфигурацию Caddy.
Подтвердите структуру маршрутизации и фактический путь на основе сгенерированных результатов.
Затем вручную выполните настройки в соответствии с вашим доменным именем, режимом работы и путем монтирования.

Обычно при этом меньше шансов пропустить детали, связанные с WebSockets, статическими ресурсами, каталогами загрузки, маршрутами .well-known или резервными страницами SPA, чем при написании конфигурации вручную с нуля.

Проверьте и перезагрузите конфигурацию

Если вы пишете или вручную настраиваете конфигурацию Caddy, сначала проверьте ее после внесения изменений, а затем перезагрузите:

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

Если вы не используете systemd для управления Caddy, вместо этого вы можете использовать свои собственные методы запуска и перезагрузки.

Если вы управляете входным уровнем через 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?

#Сначала выполните эти три команды.

#Шаг 1. Выберите способ запуска Caddy самостоятельно

#Шаг 2: Выполните generate

#Шаг 3: Выполните reload

#Какие файлы будет поддерживать CLI?

#Проверьте и перезагрузите конфигурацию

#Общие инструкции

#Ссылки по теме