Umgebungsvariablen
Wie richte ich Umgebungsvariablen ein?
Installation über Git-Quellcode oder create-nocobase-app
Legen Sie Umgebungsvariablen in der .env-Datei im Stammverzeichnis Ihres Projekts fest. Nachdem Sie die Umgebungsvariablen geändert haben, müssen Sie den Anwendungsprozess beenden und die Anwendung neu starten.
Installation über Docker
Bearbeiten Sie die docker-compose.yml-Konfiguration und legen Sie die Umgebungsvariablen im Parameter environment fest. Beispiel:
Sie können auch env_file verwenden, um Umgebungsvariablen in einer .env-Datei zu definieren. Beispiel:
Nachdem Sie die Umgebungsvariablen geändert haben, müssen Sie den App-Container neu erstellen:
Globale Umgebungsvariablen
TZ
Dient zum Festlegen der Zeitzone der Anwendung. Standardmäßig wird die Zeitzone des Betriebssystems verwendet.
https://en.wikipedia.org/wiki/List_of_tz_database_time_zones
Zeitbezogene Operationen werden gemäß dieser Zeitzone verarbeitet. Eine Änderung von TZ kann Datumswerte in der Datenbank beeinflussen. Weitere Details finden Sie unter „Datum & Uhrzeit Übersicht“.
APP_ENV
Die Anwendungsumgebung. Der Standardwert ist development. Verfügbare Optionen sind:
productionProduktionsumgebungdevelopmentEntwicklungsumgebung
APP_KEY
Der geheime Schlüssel der Anwendung, der unter anderem zur Generierung von Benutzer-Tokens verwendet wird. Ändern Sie ihn zu Ihrem eigenen Anwendungsschlüssel und stellen Sie sicher, dass er nicht nach außen gelangt.
Wenn der APP_KEY geändert wird, werden alte Tokens ungültig.
APP_PORT
Der Port der Anwendung. Der Standardwert ist 13000.
API_BASE_PATH
Das Präfix der NocoBase API-Adresse. Der Standardwert ist /api/.
API_BASE_URL
Die Basis-URL, die das Frontend für den Zugriff auf die NocoBase-API verwendet. Standardmäßig leer, was bedeutet, dass ${APP_PUBLIC_PATH}api/ derselben Origin verwendet wird.
Setzen Sie diesen Wert nur auf die vollständige API-Adresse, wenn Seiten und API-Dienst unterschiedliche Origins haben (abweichendes Protokoll, Domain oder Port):
NocoBase verwendet Cookies, um den Anmeldestatus und den Zugriff auf stabile Datei-URLs zu autorisieren. Wenn API_BASE_URL auf eine andere Origin als die Seiten zeigt:
- Der Ursprung der Seiten muss zu
CORS_ORIGIN_WHITELISThinzugefügt werden. Andernfalls ignoriert der BrowserSet-Cookiein API-Antworten, das Anmelde-Cookie wird nicht gespeichert und Cookie-abhängige Funktionen wie Dateivorschau und Download schlagen mit403fehl. - Cookies werden pro
hostnamegespeichert. Wenn Seiten und API vollständig unterschiedliche Domains verwenden, senden Aufrufe stabiler/files/-URLs über die Seitendomain nicht das Anmelde-Cookie mit, das unter der API-Domain gespeichert wurde. Dadurch schlägt der Dateizugriff weiterhin fehl.
Es ist empfehlenswert, Seiten und API per Reverse-Proxy unter derselben Origin bereitzustellen und API_BASE_URL leer zu lassen.
CORS_ORIGIN_WHITELIST
Whitelist von Origins, die ursprungsübergreifend mit Anmeldeinformationen (Cookies) auf die API zugreifen dürfen. Mehrere Origins werden durch Kommas getrennt. Standardmäßig leer.
- Wenn nichts konfiguriert ist, gelten nur Requests derselben Origin als vertrauenswürdig. Ursprungsübergreifende Requests können die API weiterhin anonym aufrufen, der Browser darf dafür jedoch keine Cookies lesen oder schreiben.
- Wenn konfiguriert, erhalten Origins in der Whitelist einen exakt zurückgegebenen
Access-Control-Allow-Origin-Header sowieAccess-Control-Allow-Credentials: true, sodass der Browser bei ursprungsübergreifenden Requests Anmelde-Cookies senden und speichern kann. - Die Anmelde-API prüft
OriginundRefererder Anfrage. Ursprungsübergreifende Anmelde-Requests von Origins außerhalb der Whitelist werden mit403abgelehnt.
CLUSTER_MODE
v1.6.0+
Der Multi-Core- (Cluster-) Startmodus der Anwendung. Wenn diese Variable konfiguriert ist, wird sie als Parameter -i <instances> an den pm2 start-Befehl übergeben. Die Optionen stimmen mit dem pm2 -i-Parameter überein (siehe PM2: Cluster Mode) und umfassen:
max: Verwendet die maximale Anzahl an CPU-Kernen-1: Verwendet die maximale Anzahl an CPU-Kernen minus eins<number>: Gibt die Anzahl der Kerne an
Der Standardwert ist leer, was bedeutet, dass der Modus nicht aktiviert ist.
Dieser Modus erfordert die Verwendung von Plugins, die mit dem Cluster-Modus zusammenhängen. Andernfalls kann es zu unerwarteten Problemen mit der Funktionalität der Anwendung kommen.
Weitere Informationen finden Sie unter: Cluster-Modus.
PLUGIN_PACKAGE_PREFIX
Das Präfix für den Paketnamen des Plugins. Der Standardwert ist @nocobase/plugin-,@nocobase/preset-.
Wenn Sie beispielsweise das hello Plugin zu Ihrem my-nocobase-app-Projekt hinzufügen, lautet der vollständige Paketname des Plugins @my-nocobase-app/plugin-hello.
PLUGIN_PACKAGE_PREFIX kann wie folgt konfiguriert werden:
Die Zuordnung zwischen Plugin-Namen und Paketnamen ist dann wie folgt:
- Der Paketname des
usersPlugins ist@nocobase/plugin-users - Der Paketname des
nocobasePlugins ist@nocobase/preset-nocobase - Der Paketname des
helloPlugins ist@my-nocobase-app/plugin-hello
DB_DIALECT
Der Datenbanktyp. Verfügbare Optionen sind:
mariadbmysqlpostgres
DB_HOST
Der Datenbank-Host (erforderlich bei Verwendung von MySQL- oder PostgreSQL-Datenbanken).
Der Standardwert ist localhost.
DB_PORT
Der Datenbank-Port (erforderlich bei Verwendung von MySQL- oder PostgreSQL-Datenbanken).
- Der Standard-Port für MySQL und MariaDB ist 3306
- Der Standard-Port für PostgreSQL ist 5432
DB_DATABASE
Der Datenbankname (erforderlich bei Verwendung von MySQL- oder PostgreSQL-Datenbanken).
DB_USER
Der Datenbank-Benutzer (erforderlich bei Verwendung von MySQL- oder PostgreSQL-Datenbanken).
DB_PASSWORD
Das Datenbank-Passwort (erforderlich bei Verwendung von MySQL- oder PostgreSQL-Datenbanken).
DB_TABLE_PREFIX
Das Präfix für Datenbanktabellen.
DB_UNDERSCORED
Gibt an, ob Datenbanktabellen- und Feldnamen in den Snake-Case-Stil konvertiert werden sollen. Der Standardwert ist false. Wenn Sie eine MySQL- (MariaDB-) Datenbank verwenden und lower_case_table_names=1 gesetzt ist, muss DB_UNDERSCORED auf true gesetzt werden.
Wenn DB_UNDERSCORED=true ist, stimmen die tatsächlichen Tabellen- und Feldnamen in der Datenbank nicht mit denen überein, die in der Benutzeroberfläche angezeigt werden. Zum Beispiel wird orderDetails in der Datenbank als order_details gespeichert.
DB_LOGGING
Der Schalter für die Datenbankprotokollierung. Der Standardwert ist off. Verfügbare Optionen sind:
onAktiviertoffDeaktiviert
DB_POOL_MAX
Die maximale Anzahl von Verbindungen im Datenbank-Verbindungspool. Der Standardwert ist 5.
DB_POOL_MIN
Die minimale Anzahl von Verbindungen im Datenbank-Verbindungspool. Der Standardwert ist 0.
DB_POOL_IDLE
Die maximale Leerlaufzeit, in Millisekunden, die eine Verbindung im Datenbank-Verbindungspool haben kann, bevor sie freigegeben wird. Der Standardwert ist 10000 (10 Sekunden).
DB_POOL_ACQUIRE
Die maximale Wartezeit, in Millisekunden, die der Pool versucht, eine Verbindung herzustellen, bevor ein Fehler ausgelöst wird. Der Standardwert ist 60000 (60 Sekunden).
DB_POOL_EVICT
Das Zeitintervall, in Millisekunden, nach dem der Verbindungspool inaktive Verbindungen entfernt. Der Standardwert ist 1000 (1 Sekunde).
DB_POOL_MAX_USES
Die Anzahl der Verwendungen einer Verbindung, bevor sie verworfen und ersetzt wird. Der Standardwert ist 0 (unbegrenzt).
LOGGER_TRANSPORT
Die Methode zur Protokollausgabe. Mehrere Werte werden durch Kommas getrennt. Der Standardwert in der Entwicklungsumgebung ist console, in der Produktionsumgebung console,dailyRotateFile. Optionen:
console-console.logfile- Ausgabe in eine DateidailyRotateFile- Ausgabe in täglich rotierende Dateien
LOGGER_LEVEL
Die Protokoll-Ausgabestufe. Der Standardwert in der Entwicklungsumgebung ist debug, in der Produktionsumgebung info. Optionen:
errorwarninfodebugtrace
Die Protokollausgabestufe der Datenbank ist debug. Ob diese ausgegeben wird, wird von DB_LOGGING gesteuert und ist unabhängig von LOGGER_LEVEL.
LOGGER_MAX_FILES
Die maximale Anzahl der aufzubewahrenden Protokolldateien.
- Wenn
LOGGER_TRANSPORTauffilegesetzt ist, beträgt der Standardwert10. - Wenn
LOGGER_TRANSPORTaufdailyRotateFilegesetzt ist, wird[n]dfür die Anzahl der Tage verwendet. Der Standardwert ist14d.
LOGGER_MAX_SIZE
Protokollrotation nach Größe.
- Wenn
LOGGER_TRANSPORTauffilegesetzt ist, ist die EinheitByte. Der Standardwert ist20971520 (20 * 1024 * 1024). - Wenn
LOGGER_TRANSPORTaufdailyRotateFilegesetzt ist, können Sie[n]k,[n]m,[n]gverwenden. Standardmäßig nicht konfiguriert.
LOGGER_FORMAT
Das Format der Protokollausgabe. Der Standardwert in der Entwicklungsumgebung ist console, in der Produktionsumgebung json. Optionen:
consolejsonlogfmtdelimiter
Referenz: Protokollformat
CACHE_DEFAULT_STORE
Der eindeutige Bezeichner für die Caching-Methode, der den Standard-Cache des Servers angibt. Der Standardwert ist memory. Integrierte Optionen sind:
memoryredis
CACHE_MEMORY_MAX
Die maximale Anzahl von Elementen im Speicher-Cache. Der Standardwert ist 2000.
CACHE_REDIS_URL
Die Redis-Verbindungs-URL, optional. Beispiel: redis://localhost:6379
TELEMETRY_ENABLED
Aktiviert die Erfassung von Telemetriedaten. Der Standardwert ist off.
TELEMETRY_METRIC_READER
Die aktivierten Metrik-Kollektoren für die Überwachung. Der Standardwert ist console. Andere Werte sollten sich auf die Namen beziehen, die von den entsprechenden Plugin-Kollektoren registriert wurden, z. B. prometheus. Mehrere Werte werden durch Kommas getrennt.
TELEMETRY_TRACE_PROCESSOR
Die aktivierten Trace-Datenprozessoren. Der Standardwert ist console. Andere Werte sollten sich auf die Namen beziehen, die von den entsprechenden Plugin-Prozessoren registriert wurden. Mehrere Werte werden durch Kommas getrennt.
SERVER_REQUEST_WHITELIST
Whitelist der erlaubten Ziele für ausgehende HTTP-Anfragen, die vom NocoBase-Server initiiert werden. Kommagetrennte Liste aus exakten IPs, CIDR-Bereichen, exakten Hostnamen und einstufigen Platzhalter-Subdomains.
Gilt für: Workflow-Knoten „HTTP-Anfrage", Aktionsschaltflächen für benutzerdefinierte Anfragen, AI-Dienste und andere serverseitige Anfragen. Relative Pfade (Aufrufe der NocoBase-API selbst) sind nicht betroffen.
Nicht konfiguriert: Alle ausgehenden http / https-Anfragen bleiben aus Kompatibilitätsgründen erlaubt. Wenn das Ziel jedoch eine Loopback-, private, link-local- oder Metadata-Adresse ist oder eine Domain auf eine solche Adresse auflöst, schreibt der Server eine Warnung ins Log.
Konfiguriert: Die ursprüngliche Anfrage und jedes Weiterleitungsziel müssen der Whitelist entsprechen. Bei fehlender Übereinstimmung erzeugt NocoBase einen Fehler, bevor die nächste Anfrage gesendet wird. Zukünftige Versionen können das Standardverhalten schrittweise verschärfen. Wenn deine Bereitstellung interne Dienste erreichen muss, konfiguriere vorab eine explizite Whitelist.
Unterstützte Formate:
Wenn eine Domain in der Whitelist konfiguriert ist, verwendet die Whitelist-Prüfung den Host in der Request-URL. Mit anderen Worten: Nach der Konfiguration von internal.example.com gilt dieses Ziel als explizit erlaubt, auch wenn die Domain auf 127.0.0.1 oder eine private Adresse auflöst.
Experimentelle Umgebungsvariablen
APPEND_PRESET_LOCAL_PLUGINS
Dient zum Anhängen vordefinierter, nicht aktivierter Plugins. Der Wert ist der Paketname (der name-Parameter in package.json), wobei mehrere Plugins durch Kommas getrennt werden.
- Stellen Sie sicher, dass das Plugin lokal heruntergeladen wurde und im Verzeichnis
node_modulesgefunden werden kann. Weitere Details finden Sie unter Plugin-Organisation. - Nachdem Sie die Umgebungsvariable hinzugefügt haben, wird das Plugin auf der Plugin-Manager-Seite erst nach einer Erstinstallation (
nocobase install) oder einem Upgrade (nocobase upgrade) angezeigt.
APPEND_PRESET_BUILT_IN_PLUGINS
Dient zum Anhängen integrierter Plugins, die standardmäßig installiert werden. Der Wert ist der Paketname (der name-Parameter in package.json), wobei mehrere Plugins durch Kommas getrennt werden.
- Stellen Sie sicher, dass das Plugin lokal heruntergeladen wurde und im Verzeichnis
node_modulesgefunden werden kann. Weitere Details finden Sie unter Plugin-Organisation. - Nachdem Sie die Umgebungsvariable hinzugefügt haben, wird das Plugin bei der Erstinstallation (
nocobase install) oder einem Upgrade (nocobase upgrade) automatisch installiert oder aktualisiert.
Temporäre Umgebungsvariablen
Die Installation von NocoBase kann durch das Setzen temporärer Umgebungsvariablen unterstützt werden, zum Beispiel:
INIT_APP_LANG
Die Sprache während der Installation. Der Standardwert ist en-US. Verfügbare Optionen sind:
en-USzh-CN
INIT_ROOT_EMAIL
Die E-Mail-Adresse des Root-Benutzers.
INIT_ROOT_PASSWORD
Das Passwort des Root-Benutzers.
INIT_ROOT_NICKNAME
Der Spitzname des Root-Benutzers.

