#Caddie

Si vous possédez déjà un nom de domaine et souhaitez configurer HTTPS dès que possible, alors nb proxy caddy est généralement la méthode de saisie la plus simple.

Plutôt que de gérer vous-même la configuration du certificat de Nginx, Caddy ressemble davantage au raccourci par défaut pour « parcourir d'abord la couche d'entrée ».

#Quand est-il plus approprié d'utiliser Caddy ?

De manière générale, Caddy est prioritaire dans les situations suivantes :

• Vous possédez déjà un nom de domaine et souhaitez accéder au HTTPS au plus vite
• Vous ne souhaitez pas conserver vous-même trop de détails sur les certificats et les TLS
• Tout ce dont vous avez besoin est une couche d'entrée simple et stable

Si vous avez déjà utilisé Nginx pour gérer de nombreux sites sur le serveur, ou si vous devez ultérieurement appliquer des règles de mise en cache, de contrôle d'accès et de personnalisation plus lourdes, il sera alors plus simple de continuer à regarder Nginx.

#Suivez d'abord ces trois commandes.

Si vous souhaitez simplement exécuter la couche d'entrée Caddy en premier, il suffit de retenir ces trois commandes par défaut :

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

Si Caddy a été installé localement, remplacez simplement la première entrée par nb proxy caddy use local.

Dans la plupart des scénarios, il suffit d'exécuter d'abord use, puis generate et enfin reload. Pour d'autres détails et plus de commandes, consultez les chapitres suivants ou la référence CLI.

#Étape 1 : Choisissez comment exécuter Caddy vous-même

Si Caddy est déjà installé sur la machine actuelle, utilisez simplement use local.

Si vous souhaitez utiliser la version Docker de Caddy, utilisez use docker.

Le local / docker fait ici référence à la façon dont Caddy lui-même fonctionne.

Utilisation de la version Docker de Caddy :

nb proxy caddy use docker

Utilisation d'une installation locale de Caddy :

nb proxy caddy use local

Si vous oubliez ultérieurement quelle méthode est actuellement sélectionnée, vous pouvez exécuter :

nb proxy caddy current

#Étape 2 : Exécuter generate

generate est utilisé pour générer la configuration de Caddy en fonction de l'environnement spécifié. La façon la plus courante de l'écrire est la suivante :

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

Si vous souhaitez également spécifier le port d'entrée, vous pouvez également l'écrire ensemble :

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

La signification des paramètres ici est :

• --env : spécifiez pour quel environnement CLI générer la configuration.
• --host : Spécifiez le nom de domaine pour l'accès externe
• --port : Spécifiez le port d'entrée du proxy

Pour Caddy, --host est particulièrement important. Dans un environnement formel, essayez de transmettre par défaut un nom de domaine résolu au serveur actuel, afin que l'accès HTTPS soit plus naturel.

Si la commande indique qu'il manque appPort à env, exécutez d'abord :

nb env update test2 --app-port 56575

Si vous modifiez ultérieurement des configurations telles que app-port et app-public-path qui affecteront les résultats du proxy, n'oubliez pas de réexécuter generate.

#Étape 3 : Exécuter reload

Après avoir généré la configuration, exécutez directement :

nb proxy caddy reload

Dans la plupart des scénarios, utilisez simplement cette commande directement. S'il n'est pas encore en cours d'exécution, le démarrage sera d'abord traité en interne ; s'il est déjà en cours d'exécution, il sera rechargé selon la dernière configuration.

#Quels fichiers la CLI conservera-t-elle ?

En prenant test2 comme exemple, les commandes liées à Caddy conservent généralement ces fichiers et répertoires :

dans:

• NB_CLI_ROOT/.nocobase/proxy/caddy/... Les fichiers suivants sont des fichiers auxiliaires d'agent gérés par CLI
• NB_CLI_ROOT/test2/storage/... Voici les ressources statiques et les répertoires de téléchargement de l'application.
• nocobase.caddy est un fichier d'entrée au niveau du fournisseur et n'a généralement pas besoin d'être modifié manuellement.
• app.caddy est la configuration complète du site Caddy d'un certain environnement. La réexécution de generate écrasera l'intégralité de

:::avertissement

Si vous souhaitez compenser la configuration au niveau du site Caddy, telle que des en-têtes supplémentaires, des stratégies d'authentification, de limitation de vitesse ou de compression, vous pouvez d'abord ajuster en fonction de app.caddy ; cependant, sachez que les réexécutions ultérieures de generate écraseront ce fichier.

:::

#Configuration manuscrite : que faire sans CLI

Si votre application n'est pas hébergée par CLI ou si vous souhaitez explicitement conserver vous-même la configuration complète de Caddy, vous pouvez également l'écrire à la main.

Cependant, pour NocoBase, l'entrée de l'environnement de production n'est généralement pas un simple reverse_proxy. En plus de transmettre les requêtes API à l'application backend, une configuration Caddy complète et fonctionnelle doit généralement également gérer le répertoire de téléchargement, les ressources statiques frontales, le routage .well-known, WebSocket et la page de secours SPA.

En prenant test2 comme exemple, les répertoires clés liés à Caddy incluent généralement :

• Répertoire des pages de secours SPA : NB_CLI_ROOT/.nocobase/proxy/caddy/test2/public
• Répertoire de produits de build front-end : NB_CLI_ROOT/test2/storage/dist-client
• Répertoire de téléchargement : NB_CLI_ROOT/test2/storage/uploads

En d’autres termes, la configuration manuscrite doit généralement couvrir au moins les types d’entrées suivants :

• v : rediriger /v vers /v/
• uploads : exposer le répertoire de téléchargement
• dist : exposer le répertoire du produit de build front-end
• oauth well-known : gérer les chemins de découverte OAuth
• openid well-known : gérer les chemins de découverte OpenID
• api : transmettre la requête /api/ à l'application backend
• ws : transmettre les requêtes WebSocket à l'application backend
• spa v2 : fournit une page d'entrée et de retour frontale pour /v/
• spa v1 : fournit une page d'entrée et de retour frontale pour /

Par conséquent, une configuration Caddy complète n’est généralement pas simplement écrite de la manière générale suivante :

your-domain.com {
  reverse_proxy 127.0.0.1:13000
}

Pour une application hébergée par CLI comme test2, une structure plus proche d'un déploiement réel ressemblerait généralement à ceci :

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

Il y a également deux points clés ici :

• NB_CLI_ROOT/.nocobase/proxy/caddy/... Ce qui suit est le répertoire des pages de restauration SPA géré par CLI
• NB_CLI_ROOT/test2/storage/... Ce qui suit est l'utilisation de votre propre répertoire de produits de construction et de votre répertoire de téléchargement

Si votre application utilise le déploiement de sous-chemins ou si les ressources frontales, le répertoire de téléchargement et la couche d'entrée ne sont pas dans la même perspective de chemin, la configuration manuscrite sera plus sujette aux erreurs. Dans ce scénario, il est généralement plus recommandé d'exécuter :

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

Effectuez ensuite des ajustements en fonction des résultats générés.

Si vous souhaitez laisser la CLI vous aider à parcourir les chemins et les itinéraires en premier, la structure générée sera généralement :

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

dans:

• nocobase.caddy est responsable de l'unification de import */app.caddy
• test2/app.caddy est la configuration complète du site de cet environnement test2
• public/index-v1.html et public/index-v2.html sont des pages de secours SPA générées par la CLI

Une approche plus prudente est généralement la suivante :

1. Laissez d'abord la CLI générer la configuration du Caddy
2. Confirmez la structure de routage et le chemin réel en fonction des résultats générés.
3. Effectuez ensuite des ajustements manuels en fonction de votre nom de domaine, de votre mode d'exécution et du chemin de montage.

Il est généralement moins probable que des détails liés aux WebSockets, aux ressources statiques, aux répertoires de téléchargement, aux routes .well-known ou aux pages de secours SPA soient manqués plutôt que d'écrire manuellement une configuration à partir de zéro.

#Vérifier et recharger la configuration

Si vous écrivez ou ajustez manuellement la configuration du Caddy, vérifiez-la d'abord après avoir apporté les modifications, puis rechargez :

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

Si vous n'utilisez pas systemd pour gérer Caddy, vous pouvez utiliser vos propres méthodes de démarrage et de rechargement à la place.

Si vous gérez la couche d'entrée via nb proxy caddy, il est généralement préférable d'utiliser :

nb proxy caddy reload

Si vous souhaitez voir le pilote actuel, le chemin total du fichier d'entrée, le répertoire racine d'exécution et les informations sur le conteneur ou le binaire local, vous pouvez exécuter :

nb proxy caddy info

Si vous souhaitez simplement confirmer rapidement s'il est en cours d'exécution, vous pouvez exécuter :

nb proxy caddy status

#Instructions communes

• nb proxy caddy generate est destiné aux applications installées par nb init
• Si vous disposez déjà d'un nom de domaine qui peut être résolu normalement sur le serveur, Caddy est souvent le moyen le plus rapide d'obtenir HTTPS.
• Si vous modifiez par la suite des configurations telles que app-port et app-public-path qui affecteront les résultats du proxy, pensez à réexécuter generate

#Liens connexes

• Proxy inverse de l'environnement de production
• Nginx
• Installer à l'aide de CLI (recommandé)
• Configuration de l'application avec .env
• Référence de commande nb proxy caddy