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 (
0644por 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:
| Campo | Sustituye | Ejemplo |
|---|---|---|
| Startup Command (ENTRYPOINT) | El ENTRYPOINT de la imagen | docker-entrypoint.sh |
| Arguments (CMD) | El CMD de la imagen, que se pasa al entrypoint | npm 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;
1000es un núcleo,500medio. 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):
{
"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.