# Klonen und starten. Für den ersten Blick auf das System — kein .NET SDK, kein # Node, keine Vorbereitung auf dem Rechner. # # git clone # cd callora # git clone custom/static-plugins/ # optional, siehe unten # docker compose -f docker-compose.standalone.yml up --build # # Admin unter http://localhost:5000/admin # # Der Unterschied zu docker-compose.yml in einem Satz: Dort liegt das Repo im # Mount und dotnet watch baut bei jeder Änderung neu; hier wird einmal alles ins # Image gebaut. Wer entwickelt, will die andere Datei — eine Änderung an der # Quelle erreicht diesen Stack erst nach `up --build`. # # GEKLONTE PLUGINS werden mitgebaut, ohne dass sie hier aufgezählt wären. Das # Dockerfile ruft scripts/dev-build.sh, und das findet jede registry.json unter # custom/ — dieselbe Suche, die auch der Host beim Start macht. Beide Ordner # werden gescannt: # # custom/static-plugins/ mitgelieferte Plugins (Communication, Composer) # custom/plugins/ installierte / zugekaufte (VideoConference) # # Die Ladereihenfolge hängt NICHT am Ordner. Sie entsteht aus einer topologischen # Sortierung über Capabilities (PluginActivationPlanner): Wer eine Capability # per `requiresCapabilities` fordert, startet nach dem, der sie unter # `capabilities` bereitstellt. Ein Foundation-Plugin funktioniert deshalb auch # unter custom/plugins/. Der Tier aus dem Ordner ist nur ein Tie-Breaker unter # Plugins, die die Topologie ohnehin gleichzeitig erlaubt. # # Kein Coturn hier, anders als im Dev-Stack: Ein echtes ICE-Relay braucht eine # öffentlich erreichbare Adresse und die Entscheidung, welche das ist. Wer # VideoConference mit echtem TURN ausprobieren will, nimmt docker-compose.yml. name: callora-standalone services: callora-backend: build: context: . target: standalone args: # Als BUILD-Argument, nicht als Umgebungsvariable weiter unten: MinVer wirkt # beim Kompilieren. Zur Laufzeit gesetzt käme der Wert zu spät, der Host trüge # weiter 0.1.0-preview.0 und lehnte jedes Plugin ab — sichtbar nur als # "requires '>=0.9.0-0', but the host provides …" im Startprotokoll. CALLORA_VERSION: ${CALLORA_VERSION:-0.9.0} restart: unless-stopped depends_on: postgres: condition: service_healthy ports: - "${CALLORA_PORT:-5000}:5000" environment: # Muss gesetzt sein. Der Host prüft beim Start, ob unsichere Dev-Defaults # außerhalb von Development aktiv sind, und bricht fail-closed ab — # AllowUnsignedPlugins weiter unten ist genau so einer. Ohne diese Zeile # gilt der ASP.NET-Default Production und der Stack startet nicht. ASPNETCORE_ENVIRONMENT: Development ASPNETCORE_URLS: http://0.0.0.0:5000 CalloraHosting__AutoBootstrapModules: "true" CalloraHosting__AutoLoadPlugins: "true" CalloraHosting__AutoActivateInstalledPlugins: "true" CalloraHosting__StaticPluginDirectory: custom/static-plugins CalloraHosting__PluginDirectory: custom/plugins BackendHost__DatabaseConnectionString: Host=postgres;Port=5432;Database=${POSTGRES_DB:-callora_host};Username=${POSTGRES_USER:-callora};Password=${POSTGRES_PASSWORD:-callora} # Lokal ohne Signatur: Die geklonten Plugins sind frisch gebaut und nicht # signiert. In einer Distribution ist dieser Wert false und jedes Plugin # muss von einem vertrauten Schlüssel signiert sein. BackendHost__AllowUnsignedPlugins: "true" BackendHost__RequireApiKeyAuthentication: "true" BackendHost__ApiKeys__0: ${CALLORA_API_KEY:-callora-local-dev-key-change-me} BackendHost__AdminShellBaseUrl: /admin/ BackendHost__WorkspaceShellBaseUrl: / BackendHost__PluginAssetBaseUrl: /plugin-assets postgres: image: postgres:16 restart: unless-stopped ports: - "${POSTGRES_PORT:-5432}:5432" environment: POSTGRES_DB: ${POSTGRES_DB:-callora_host} POSTGRES_USER: ${POSTGRES_USER:-callora} POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:-callora} healthcheck: test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER:-callora} -d ${POSTGRES_DB:-callora_host}"] interval: 5s timeout: 5s retries: 20 volumes: - callora-standalone-data:/var/lib/postgresql/data volumes: callora-standalone-data: