Die Archestack-Images betreiben

Archestack besteht aus zwei Container-Images und einer PostgreSQL-Datenbank. Jeder Weg, es zu betreiben, vom Laptop bis zum Kubernetes-Cluster, startet dieselben zwei Images mit anderen Einstellungen. Diese Seite sagt, was sie sind, was jedes Setup ihnen geben muss und welcher Weg wo passt. Jede Einstellung, die die Images annehmen, steht unter Einstellungen der Images.

Die Images

Jedes Release trägt seine Version als Tag, etwa 1.0.42, und das neueste ist zusätzlich latest. Betreibe in Produktion eine Versionsnummer, damit du weißt, was läuft, und dieselbe Version von Test bis Produktion mitnehmen kannst. Die API und das Web-Image eines Releases gehören zusammen.

Was jedes Setup ihnen gibt

1. PostgreSQL 16, mit einem Benutzer, der Datenbanken anlegen darf. Die API legt beim ersten Start ihre eigenen Datenbanken an und danach ein Paar für jeden Workspace, es gibt also nichts vorzubereiten. Gib PostgreSQL 1 GB Shared Memory (--shm-size 1g in Docker): Seine Statistiken wachsen mit jeder Datenbank, und der Standardwert reicht nur bis etwa tausend Workspaces.
2. Zwei Ordner, die einen Neustart überstehen, /files für Uploads und /backups für Backups. Ohne sie verschwinden Uploads beim nächsten Update.
3. Ein Weg zu jedem Image. Der Browser lädt das Web-Image und ruft die API unter /api auf, mit Live-Updates über einen WebSocket unter /hubs. Beide können sich eine Adresse teilen, wie es die Starter-Kits tun, oder die API bekommt eine eigene:

   One address (the kits do this)          Two addresses
   
   https://apps.example.com                https://editor.example.com  ->  omnicore-web
     /api/...   ->  omnicore-api :8080     https://api.example.com     ->  omnicore-api
     /hubs/...  ->  omnicore-api :8080
     /...       ->  omnicore-web :80       VITE_API_URL=https://api.example.com
   
   VITE_API_URL empty

   Unter einem Pfad eines Hostnamens, etwa https://apps.example.com/archestack/, wird beiden Images der Pfad mitgeteilt (BASE_PATH und Http__PathBase).
4. Ein erster Admin. Setze entweder Identity__InitialAdminEmail und Identity__InitialAdminPassword, oder öffne den Builder direkt nach dem ersten Start und lege den Admin dort an. Bis das jemand tut, wird Admin, wer den Builder als Erstes erreicht, lass eine frische Installation also nicht offen im Internet stehen.
5. Zeit zum Starten. Die API antwortet auf /health erst dann mit {"status":"ok"}, wenn jede Datenbank migriert ist. Ein erster Start dauert ein bis zwei Minuten, mit vielen Workspaces länger, prüfe die Bereitschaft also über /health und gib dem Start genug Zeit.

Die Wege, sie zu betreiben

Welchen du auch wählst, deine Anwendungen kommen auf demselben Weg hinein: aus dem Repository, über eine Pipeline.

Mit docker run ausprobieren

Drei Container in einem Docker-Netzwerk: PostgreSQL, die API auf Port 8080 und der Builder auf Port 8081. Wähle ein eigenes Passwort statt change-me.

# Archestack on this machine with plain docker run: the builder on http://localhost:8081
docker network create archestack
docker volume create archestack-postgres

docker run -d --name archestack-postgres --network archestack --shm-size 1g \
  -e POSTGRES_USER=archestack -e POSTGRES_PASSWORD=change-me -e POSTGRES_DB=postgres \
  -v archestack-postgres:/var/lib/postgresql/data postgres:16

docker run -d --name archestack-api --network archestack -p 8080:8080 \
  -e ASPNETCORE_URLS=http://+:8080 \
  -e "ConnectionStrings__DefaultConnection=Host=archestack-postgres;Database=omnicore-db;Username=archestack;Password=change-me" \
  -e "ConnectionStrings__Core=Host=archestack-postgres;Database=omnicore-core;Username=archestack;Password=change-me" \
  -e "ConnectionStrings__Identity=Host=archestack-postgres;Database=omnicore-identity;Username=archestack;Password=change-me" \
  -e ConnectionStrings__Keycloak= \
  -e Database__CreateMissing=true \
  -e Identity__Provider=Builtin -e Identity__AppBaseUrl=http://localhost:8081 \
  -e Files__Directory=/files -e Backup__Directory=/backups \
  -v archestack-files:/files -v archestack-backups:/backups \
  nickpeelman/omnicore-api:latest

docker run -d --name archestack-web --network archestack -p 8081:80 \
  -e VITE_API_URL=http://localhost:8080 -e VITE_UI_MODE=dashboard \
  -e API_INTERNAL_URL=http://archestack-api:8080 \
  nickpeelman/omnicore-web:latest

Öffne http://localhost:8081, sobald http://localhost:8080/health antwortet, und lege den ersten Admin an. Der Builder und die veröffentlichte App (/app) liegen beide auf diesem Port, und die API auf 8080 antwortet dem Browser direkt. So entfernst du es wieder:

docker rm -f archestack-web archestack-api archestack-postgres
docker network rm archestack
# Everything you made is in the volumes; this deletes it:
docker volume rm archestack-postgres archestack-files archestack-backups

Das ist zum Ausprobieren. Ein Server braucht Neustarts, Updates, Zertifikate und Backups, die vom Rechner weggebracht werden, und all das richtet Hosting mit Docker ein.

Andere Container-Plattformen

Azure Container Apps, Amazon ECS, Google Cloud Run und ähnliche Plattformen betreiben dieselben Images. Prüfe Folgendes, bevor du dich für eine entscheidest:

• Die Datenbank. Nimm das verwaltete PostgreSQL 16 der Plattform (Azure Database for PostgreSQL, Amazon RDS, Cloud SQL), mit einem Benutzer, der Datenbanken anlegen darf. Betreibe PostgreSQL selbst nicht auf einer Netzwerkfreigabe.
• Ein Volume für /files und /backups, etwa Azure Files, Amazon EFS oder Filestore. Mit mehr als einer API-Instanz bindet jede Instanz dasselbe ein.
• Mindestens eine API-Instanz, die immer läuft. Geplante Ereignisse, der Mail-Ausgang und Backups laufen in der API, eine Plattform, die auf null herunterskaliert, hält sie also an. Setze das Minimum auf eine Instanz, und lass auf Cloud Run die CPU auch außerhalb von Anfragen zugeteilt.
• WebSockets zu /hubs für Live-Updates. Eine Verbindung, die die Plattform trennt, wird wieder geöffnet, aber ein sehr kurzer Leerlauf-Timeout lässt Updates verspätet ankommen.
• Große Anfragen. Paketimporte und Datei-Uploads können groß sein: Erlaube Anfrage-Bodys von mindestens 100 MB und Anfragen, die ein paar Minuten dauern.
• Mehr als eine API-Instanz funktioniert ohne Sticky Sessions: Die Instanzen teilen ihren Zustand über PostgreSQL. Jede braucht dafür eine direkte Verbindung dorthin, setze also bei einem Connection Pooler wie PgBouncer dazwischen ConnectionStrings__Cluster auf PostgreSQL selbst.

Wie es weitergeht

Einstellungen der Images führt jede Einstellung beider Images auf. Kapazität und Dimensionierung sagt, wie viel eine Installation bedient, und Workspaces und Hosting, wie Workspaces sie sich teilen.