Saltar al contenido

Ajustes del servicio ​

La pestaña Settings de un servicio reúne cómo se compila y se ejecuta. Save guarda el cambio, que se aplica en el siguiente despliegue, así que haz clic en Redeploy cuando estés listo. Las variables tienen su propia pestaña (Variables de entorno), igual que los dominios y los puertos (Networking).

Nombre, nombre de host e ID ​

  • Service Name se muestra en la consola. Cambiarlo no afecta a nada de lo que se ejecuta.
  • Private hostname es el nombre con el que los demás servicios del proyecto llegan a este, <hostname>.zenavo.internal (Red privada). Letras minúsculas, dígitos y guiones, empezando por una letra. El cambio se aplica en el siguiente despliegue; actualiza lo que use la dirección anterior.
  • Service ID es permanente y nunca se reutiliza: lo usan los volúmenes, los registros y las rutas de la API. Cópialo desde aquí para la API o la CLI.

Archivos de configuración ​

Configs → Open Config Editor monta archivos en el contenedor, como una configuración de Nginx o un archivo de ajustes JSON, sin cambiar la imagen. Para cada archivo indica:

  • Mount path, la ruta completa del archivo en el contenedor, por ejemplo /etc/nginx/conf.d/default.conf.
  • Mode, sus permisos en octal (0644 por defecto).
  • El contenido.
  • Replace ${VARIABLE} references with the service's variables, para rellenar valores de las Variables de entorno al desplegar, de modo que los secretos se queden en Variables.

Los archivos de configuración se guardan cifrados, como las variables, y se escriben en el servidor como Secrets de Kubernetes. En el contenedor son de solo lectura: para los archivos que la aplicación cambia y debe conservar, usa un volumen.

Origen y compilación ​

En los servicios que compila Zenavo, las secciones Source y Build contienen el repositorio y la rama, Root directory, Dockerfile, Auto deploy, Watch paths, Build arguments y zbpack options. Consulta GitHub, Plan de compilación y Directorio local. Un servicio que ejecuta una imagen de Docker muestra la imagen y no tiene nada que compilar.

Comando de arranque ​

Sustituye lo que ejecuta el contenedor sin cambiar la imagen:

CampoSustituyeEjemplo
Startup Command (ENTRYPOINT)El ENTRYPOINT de la imagendocker-entrypoint.sh
Arguments (CMD)El CMD de la imagen, que se pasa al entrypointnpm run start:prod

Deja un campo vacío para usar el valor de la imagen. Los valores se ejecutan directamente, no en un shell: entrecomilla las partes con espacios y, para &&, | o $VARIABLES, escribe sh -c "…", por ejemplo sh -c "npx prisma migrate deploy && node server.js".

Comprobación de salud y límite de fallos ​

Health Check decide cuándo una instancia nueva está lista para recibir tráfico; consulta Comprobaciones de salud.

Automatic Restart After Crashes Attempts es el límite de fallos: cuántas veces puede reiniciarse una instancia antes de que se suspenda el servicio. -1 (por defecto) reinicia indefinidamente; 0 suspende tras el primer fallo. Un servicio suspendido envía la notificación Service suspended.

Límites de recursos ​

Por defecto, un servicio puede usar toda la CPU y la memoria del servidor. Para que un servicio no deje sin recursos a los demás del mismo servidor, fija un límite por instancia:

  • CPU (m): milinúcleos; 1000 es un núcleo, 500 medio. Un servicio en su límite se ralentiza, no se detiene.
  • Memory (Mi): mebibytes. Un servicio que lo supera se detiene y se reinicia (sin memoria), lo que cuenta para su límite de fallos.

Deja un campo vacío para no poner límite. Fija la memoria con buen margen sobre lo que el servicio usa normalmente: la pestaña Usage del servicio lo muestra (Métricas).

Réplicas ​

Replicas ejecuta varias instancias de un servicio, hasta 20, en el servidor del proyecto. El tráfico se reparte entre las instancias listas, y los despliegues las sustituyen de una en una, así que el servicio sigue respondiendo si una instancia falla o se sustituye.

  • Las réplicas se ejecutan en el mismo servidor, así que protegen frente a un proceso caído, no frente a la caída del servidor.
  • Un servicio con un volumen no puede tener más de una réplica, porque el volumen no se puede compartir entre instancias.
  • Cada réplica tiene los límites de recursos de arriba y su propia memoria: guarda las sesiones, las subidas y las cachés en una base de datos, Redis o almacenamiento de objetos, no en el proceso.

Suspender y eliminar ​

En Danger Zone:

  • Suspend Service lo detiene; no se puede acceder a él hasta que hagas Resume Service. La configuración, los dominios y los volúmenes se mantienen. Consulta Reversiones y suspensión.
  • Delete Service lo quita del proyecto después de escribir su nombre. Se detiene en el siguiente despliegue (Deploy all en los Settings del proyecto). Sus volúmenes se quedan en el servidor hasta que se elimina el proyecto. Los servicios que dependían de él dejan de esperar a que arranque.

En el manifiesto ​

Los mismos ajustes son campos del servicio en el manifiesto del proyecto (Settings → Advanced → Edit JSON, o la API):

json
{
  "name": "web",
  "hostname": "web",
  "entrypoint": ["docker-entrypoint.sh"],
  "command": ["npm", "run", "start:prod"],
  "configs": [{ "path": "/app/config.json", "content": "{\"apiUrl\": \"${API_URL}\"}", "mode": 420, "envsubst": true }],
  "crash_limit": 5,
  "cpus": 0.5,
  "memory_mb": 512,
  "replicas": 2
}

En JSON, mode va en decimal (420 es 0644); cpus va en núcleos.

Sin relación con Zeabur.