Exécuter les images Archestack

Archestack, ce sont deux images de conteneur et une base de données PostgreSQL. Chaque manière de le faire tourner, d'un ordinateur portable à un cluster Kubernetes, démarre les deux mêmes images avec des paramètres différents. Cette page dit ce qu'elles sont, ce que toute installation doit leur fournir, et quelle manière de les faire tourner convient où. Chaque paramètre que les images acceptent figure dans Paramètres des images.

Les images

Chaque release porte sa version comme tag, par exemple 1.0.42, et la plus récente porte aussi latest. En production, faites tourner un numéro de version : vous savez ainsi ce qui tourne et pouvez faire passer cette même version du test à la production. L'API et l'image web d'une même release vont ensemble.

Ce que toute installation leur fournit

1. PostgreSQL 16, avec un utilisateur autorisé à créer des bases de données. L'API crée ses propres bases de données au premier démarrage, puis une paire pour chaque espace de travail, il n'y a donc rien à préparer. Donnez à PostgreSQL 1 Go de mémoire partagée (--shm-size 1g dans Docker) : ses statistiques grandissent avec chaque base de données, et la valeur par défaut est épuisée vers un millier d'espaces de travail.
2. Deux dossiers qui survivent à un redémarrage, /files pour les fichiers envoyés et /backups pour les sauvegardes. Sans eux, les fichiers envoyés disparaissent à la mise à jour suivante.
3. Une route vers chaque image. Le navigateur charge l'image web et appelle l'API sous /api, avec les mises à jour en direct par un WebSocket sous /hubs. Les deux peuvent partager une adresse, comme le font les kits de démarrage, ou l'API reçoit une adresse qui lui est propre :

   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

   Sous un chemin d'un nom d'hôte, comme https://apps.example.com/archestack/, les deux images reçoivent ce chemin (BASE_PATH et Http__PathBase).
4. Un premier admin. Réglez Identity__InitialAdminEmail et Identity__InitialAdminPassword, ou ouvrez le builder juste après le premier démarrage et créez-y l'admin. Tant que personne ne l'a fait, la première personne qui atteint le builder devient l'admin, ne laissez donc pas une installation toute neuve ouverte sur internet.
5. Le temps de démarrer. L'API ne répond à /health avec {"status":"ok"} qu'une fois chaque base de données migrée. Un premier démarrage prend une minute ou deux, et plus longtemps avec de nombreux espaces de travail : vérifiez donc la disponibilité sur /health et laissez au démarrage assez de temps.

Les manières de les faire tourner

Quelle que soit celle que vous choisissez, vos applications y arrivent de la même manière : depuis le dépôt, par un pipeline.

Essayer avec docker run

Trois conteneurs sur un réseau Docker : PostgreSQL, l'API sur le port 8080 et le builder sur le port 8081. Choisissez votre propre mot de passe à la place de 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

Ouvrez http://localhost:8081 dès que http://localhost:8080/health répond, et créez le premier admin. Le builder et l'application publiée (/app) sont tous deux sur ce port, et l'API sur 8080 répond directement au navigateur. Pour tout retirer :

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

C'est pour essayer. Un serveur a besoin de redémarrages, de mises à jour, de certificats et de sauvegardes copiées hors de la machine, ce que met en place Héberger avec Docker.

Autres plateformes de conteneurs

Azure Container Apps, Amazon ECS, Google Cloud Run et les plateformes similaires font tourner les mêmes images. Vérifiez ces points avant d'en choisir une :

• La base de données. Utilisez le PostgreSQL 16 managé de la plateforme (Azure Database for PostgreSQL, Amazon RDS, Cloud SQL), avec un utilisateur autorisé à créer des bases de données. Ne faites pas tourner PostgreSQL lui-même sur un partage de fichiers réseau.
• Un volume pour /files et /backups, comme Azure Files, Amazon EFS ou Filestore. Avec plus d'une instance de l'API, chaque instance monte le même.
• Au moins une instance de l'API toujours en marche. Les événements planifiés, la boîte d'envoi des mails et les sauvegardes tournent dans l'API, si bien qu'une plateforme qui descend à zéro les arrête. Réglez le minimum sur une instance, et sur Cloud Run gardez le CPU alloué en dehors des requêtes.
• Des WebSockets vers /hubs pour les mises à jour en direct. Une connexion que la plateforme coupe est rouverte, mais un délai d'inactivité très court fait arriver les mises à jour en retard.
• Des requêtes volumineuses. Les imports de packages et les envois de fichiers peuvent être volumineux : autorisez des corps de requête d'au moins 100 Mo et des requêtes qui durent quelques minutes.
• Plus d'une instance de l'API fonctionne sans sticky sessions : elles partagent leur état par PostgreSQL. Chacune a besoin pour cela d'une connexion directe à celui-ci, donc avec un pooler de connexions comme PgBouncer entre les deux, réglez ConnectionStrings__Cluster sur PostgreSQL lui-même.

Pour aller plus loin

Paramètres des images liste chaque paramètre des deux images. Capacité et dimensionnement dit ce qu'une installation peut servir, et Espaces de travail et hébergement comment les espaces de travail se la partagent.