Ejecutar las imágenes de Archestack

Archestack son dos imágenes de contenedor y una base de datos PostgreSQL. Cualquier forma de ejecutarlo, desde un portátil hasta un clúster de Kubernetes, arranca las mismas dos imágenes con ajustes distintos. Esta página explica qué son, qué tiene que darles cualquier instalación y qué forma de ejecutarlas encaja en cada caso. Todos los ajustes que aceptan las imágenes están en Ajustes de las imágenes.

Las imágenes

Cada release lleva como etiqueta su versión, como 1.0.42, y la más reciente también es latest. En producción ejecuta un número de versión, para saber qué se ejecuta y poder llevar esa misma versión de pruebas a producción. La imagen de la API y la imagen web de una misma release van juntas.

Lo que les da cualquier instalación

1. PostgreSQL 16, con un usuario que pueda crear bases de datos. La API crea sus propias bases de datos en el primer arranque y después un par por cada espacio de trabajo, así que no hay nada que preparar. Da a PostgreSQL 1 GB de memoria compartida (--shm-size 1g en Docker): sus estadísticas crecen con cada base de datos, y el valor por defecto se agota hacia los mil espacios de trabajo.
2. Dos carpetas que sobrevivan a un reinicio, /files para los archivos subidos y /backups para las copias de seguridad. Sin ellas, los archivos subidos desaparecen en la siguiente actualización.
3. Una ruta hacia cada imagen. El navegador carga la imagen web y llama a la API bajo /api, con las actualizaciones en vivo por un WebSocket bajo /hubs. Ambas pueden compartir una dirección, como hacen los kits de inicio, o la API recibe una dirección propia:

   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

   Bajo una ruta de un nombre de host, como https://apps.example.com/archestack/, ambas imágenes reciben la ruta (BASE_PATH y Http__PathBase).
4. Un primer administrador. Define Identity__InitialAdminEmail e Identity__InitialAdminPassword, o abre el builder justo después del primer arranque y crea allí el administrador. Hasta que alguien lo haga, quien llegue primero al builder se convierte en administrador, así que no dejes una instalación recién hecha abierta en internet.
5. Tiempo para arrancar. La API responde a /health con {"status":"ok"} solo cuando todas las bases de datos están migradas. Un primer arranque tarda un minuto o dos, y más con muchos espacios de trabajo, así que comprueba en /health si está lista y da al arranque tiempo suficiente.

Las formas de ejecutarlas

Elijas la que elijas, tus aplicaciones llegan a ella del mismo modo: desde el repositorio, a través de un pipeline.

Probarlo con docker run

Tres contenedores en una misma red de Docker: PostgreSQL, la API en el puerto 8080 y el builder en el puerto 8081. Elige una contraseña propia en lugar 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

Abre http://localhost:8081 cuando http://localhost:8080/health responda, y crea el primer administrador. El builder y la aplicación publicada (/app) están ambos en ese puerto, y la API en el 8080 responde directamente al navegador. Para quitarlo de nuevo:

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

Esto es para probar. Un servidor necesita reinicios, actualizaciones, certificados y copias de seguridad guardadas fuera de la máquina, que es lo que configura Alojamiento con Docker.

Otras plataformas de contenedores

Azure Container Apps, Amazon ECS, Google Cloud Run y plataformas similares ejecutan las mismas imágenes. Comprueba esto antes de elegir una:

• La base de datos. Usa el PostgreSQL 16 gestionado de la plataforma (Azure Database for PostgreSQL, Amazon RDS, Cloud SQL), con un usuario que pueda crear bases de datos. No ejecutes el propio PostgreSQL sobre un recurso compartido de red.
• Un volumen para /files y /backups, como Azure Files, Amazon EFS o Filestore. Con más de una instancia de la API, todas las instancias montan el mismo.
• Al menos una instancia de la API siempre en marcha. Los scheduled events, la bandeja de salida del correo y las copias de seguridad se ejecutan dentro de la API, así que una plataforma que escala a cero los detiene. Fija el mínimo en una instancia y, en Cloud Run, mantén la CPU asignada también fuera de las peticiones.
• WebSockets hacia /hubs para las actualizaciones en vivo. Una conexión que la plataforma corta se vuelve a abrir, pero un tiempo de inactividad muy corto hace que las actualizaciones lleguen tarde.
• Peticiones grandes. Las importaciones de paquetes y las subidas de archivos pueden ser grandes: permite cuerpos de petición de al menos 100 MB y peticiones que tarden unos minutos.
• Más de una instancia de la API funciona sin sesiones persistentes: comparten su estado a través de PostgreSQL. Para ello cada una necesita una conexión directa a él, así que con un pooler de conexiones como PgBouncer en medio, apunta ConnectionStrings__Cluster al propio PostgreSQL.

Hacia dónde va esto a continuación

Ajustes de las imágenes enumera todos los ajustes de ambas imágenes. Capacidad y dimensionamiento indica a cuántas personas sirve una instalación, y Espacios de trabajo y alojamiento, cómo la comparten los espacios de trabajo.