Die Unit las bisher nur p2.env. Auf Prod steht die Datenbankverbindung
schon in ~/.config/wurzelwerk/database.env und gehoert Phase 1 mit; die
Unit liest jetzt beide, database.env zuerst. p2.env kann DATABASE_URL
ueberschreiben, falls database.env auf 127.0.0.1 zeigt - aus dem
Container heraus laeuft das ins Leere, dort muss
host.containers.internal stehen.
deploy/INBETRIEBNAHME.md haelt die Reihenfolge fest. Zwei Schritte darin
sind nicht offensichtlich und beide teuer, wenn man sie auslaesst:
lexikon.py --laden akteure.py liest aus den Tabellen, nicht aus den
JSON-Dateien. Ohne diesen Schritt laeuft Modul 4
durch und loest nichts auf, ohne zu scheitern.
Erstbestand von Hand Der erste Lauf laedt 2,2 GB Modellgewichte und
kodiert den gesamten Korpus, ~17 min je 5000
Items. Aus dem Timer heraus liefe er in
TimeoutStartSec=1800.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NupWEBPzsyohVPG47HsTz8
18 lines
785 B
Bash
18 lines
785 B
Bash
# Nach ~/.config/wurzelwerk/p2.env kopieren und ausfuellen. chmod 600.
|
|
# Enthaelt Zugangsdaten und gehoert nicht ins Repo.
|
|
|
|
# Die Datenbankverbindung steht auf Prod bereits in
|
|
# ~/.config/wurzelwerk/database.env; die Unit liest beide Dateien. Hier nur
|
|
# setzen, wenn Phase 2 eine andere braucht - etwa weil database.env auf
|
|
# 127.0.0.1 zeigt, was aus dem Container heraus ins Leere laeuft.
|
|
#
|
|
# DATABASE_URL=postgresql://wurzelwerk:PASSWORT@host.containers.internal:5432/wurzelwerk
|
|
|
|
# Threadzahl. Geht in die coder_version ein - eine Aenderung erzeugt einen
|
|
# neuen Vektorbestand. Prod hat 16 Threads, 4 laeuft ueberall.
|
|
OMP_NUM_THREADS=4
|
|
|
|
# Nach dem ersten Lauf auf 1 setzen: dann geht das Modell nie wieder ins Netz,
|
|
# sondern nur noch ins Volume wurzelwerk-modelle.
|
|
HF_HUB_OFFLINE=0
|