Eseguire le immagini di Archestack

Archestack è due immagini container e un database PostgreSQL. Ogni modo di eseguirlo, da un portatile a un cluster Kubernetes, avvia le stesse due immagini con impostazioni diverse. Questa pagina spiega cosa sono, cosa deve fornire loro ogni installazione e quale modo di eseguirle va bene dove. Tutte le impostazioni che le immagini accettano sono in Impostazioni delle immagini.

Le immagini

Ogni release ha come tag la sua versione, per esempio 1.0.42, e la più recente è anche latest. In produzione esegui un numero di versione, così sai cosa gira e puoi portare quella stessa versione dal test alla produzione. L'API e l'immagine web di una release vanno insieme.

Cosa ogni installazione fornisce loro

1. PostgreSQL 16, con un utente che può creare database. L'API crea i propri database al primo avvio e poi una coppia per ogni workspace, quindi non c'è nulla da preparare. Dai a PostgreSQL 1 GB di memoria condivisa (--shm-size 1g in Docker): le sue statistiche crescono con ogni database, e il valore predefinito si esaurisce intorno ai mille workspace.
2. Due cartelle che sopravvivono a un riavvio, /files per gli upload e /backups per i backup. Senza di esse, gli upload spariscono al prossimo aggiornamento.
3. Una strada verso ogni immagine. Il browser carica l'immagine web e chiama l'API sotto /api, con gli aggiornamenti in tempo reale su un WebSocket sotto /hubs. Entrambe possono condividere un solo indirizzo, come fanno gli starter kit, oppure l'API ha un indirizzo tutto suo:

   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

   Sotto un percorso di un hostname, per esempio https://apps.example.com/archestack/, a entrambe le immagini viene indicato il percorso (BASE_PATH e Http__PathBase).
4. Un primo admin. Imposta Identity__InitialAdminEmail e Identity__InitialAdminPassword, oppure apri il builder subito dopo il primo avvio e crea lì l'admin. Finché nessuno lo fa, chi raggiunge per primo il builder diventa admin, quindi non lasciare una nuova installazione aperta su internet.
5. Il tempo per avviarsi. L'API risponde a /health con {"status":"ok"} solo quando ogni database è migrato. Un primo avvio richiede un minuto o due, e di più con molti workspace, quindi verifica che sia pronta su /health e lascia all'avvio tempo a sufficienza.

I modi per eseguirle

Qualunque sia la tua scelta, le tue applicazioni ci arrivano allo stesso modo: dal repository, tramite una pipeline.

Provarlo con docker run

Tre container su una rete Docker: PostgreSQL, l'API sulla porta 8080 e il builder sulla porta 8081. Scegli una password tua al posto di 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

Apri http://localhost:8081 quando http://localhost:8080/health risponde, e crea il primo admin. Il builder e l'app pubblicata (/app) sono entrambi su quella porta, e l'API sulla 8080 risponde direttamente al browser. Per rimuovere tutto di nuovo:

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

Serve per provare. Un server ha bisogno di riavvii, aggiornamenti, certificati e backup portati fuori dalla macchina, ed è ciò che configura Hosting con Docker.

Altre piattaforme container

Azure Container Apps, Amazon ECS, Google Cloud Run e piattaforme simili eseguono le stesse immagini. Verifica questi punti prima di sceglierne una:

• Il database. Usa il PostgreSQL 16 gestito della piattaforma (Azure Database for PostgreSQL, Amazon RDS, Cloud SQL), con un utente che può creare database. Non eseguire PostgreSQL stesso su una condivisione di rete.
• Un volume per /files e /backups, come Azure Files, Amazon EFS o Filestore. Con più di un'istanza dell'API, ogni istanza monta lo stesso volume.
• Almeno un'istanza dell'API sempre in esecuzione. Eventi pianificati, la coda della posta in uscita e i backup girano dentro l'API, quindi una piattaforma che scala a zero li ferma. Imposta il minimo a un'istanza e, su Cloud Run, tieni la CPU allocata anche fuori dalle richieste.
• WebSocket verso /hubs per gli aggiornamenti in tempo reale. Una connessione che la piattaforma interrompe viene riaperta, ma un timeout di inattività molto breve fa arrivare gli aggiornamenti in ritardo.
• Richieste grandi. Import di pacchetti e upload di file possono essere grandi: consenti body di richiesta di almeno 100 MB e richieste che durano qualche minuto.
• Più di un'istanza dell'API funziona senza sticky session: condividono il loro stato tramite PostgreSQL. Per questo ognuna ha bisogno di una connessione diretta a PostgreSQL, quindi con un connection pooler come PgBouncer in mezzo imposta ConnectionStrings__Cluster su PostgreSQL stesso.

Dove andare dopo

Impostazioni delle immagini elenca tutte le impostazioni di entrambe le immagini. Capacità e dimensionamento dice quanto carico regge un'installazione, e Workspace e hosting come i workspace se la condividono.