Manifests
Cada Workload que creas en SleakOps se despliega en Kubernetes a través de un conjunto de manifiestos — los recursos Deployment, Service, Ingress, PodDisruptionBudget y HorizontalPodAutoscaler que SleakOps genera para él. La funcionalidad de Manifests convierte esos recursos en ciudadanos de primera clase: puedes inspeccionar cada uno, personalizar su YAML, deshabilitarlo o agregar tus propios manifiestos extra — por Workload o compartidos a nivel del Project.
Manifests está disponible desde SleakOps 3.0.0 y se habilita por compañía. Si no ves el toggle Advanced en los formularios de tus Workloads ni la sección Manifests en la Chart Configuration de tu Project, consulta con tu contacto de SleakOps.
Manifests también es un prerrequisito para importar un Project desde un release de Helm existente.
Dónde encontrarlos
Los manifiestos viven en dos lugares:
- Por Workload — abre cualquier Workload (WebService, Worker, CronJob o Hook) y cambia el toggle de vista de Form a Advanced. La vista Advanced tiene dos tabs: Manifests (el grafo de recursos) y Values (ver Values).
- Por Project — ve a Project → Settings → Chart Configuration. La sección Manifests lista todos los Workloads y manifiestos del Project, y administra el project bucket compartido.
La vista Form sigue siendo la fuente de verdad de la configuración de tu Workload: un submit actualiza todos los manifiestos generados. La vista Advanced es donde inspeccionas y personalizas lo que se despliega.
El grafo de manifiestos
El tab Manifests muestra los recursos del Workload como un grafo, donde las aristas representan las relaciones entre ellos:
Cada nodo muestra el nombre del manifiesto, su Kind (o el host resuelto, en los Ingress) y su origen:
| Origen | Badge | Significado |
|---|---|---|
| Managed | Managed | Generado y mantenido al día por SleakOps. Las actualizaciones del template base se aplican solas. |
| Customized | Customized | Editaste su YAML. SleakOps nunca sobreescribe tu copia — ver actualizaciones del template base. |
| Custom | Custom | Un manifiesto que agregaste tú. No tiene template base de SleakOps. |
El origen Custom también se muestra como "user added" en el header del editor y en la toolbar del Workload — es lo mismo, con distinta etiqueta según dónde lo mires.
Los manifiestos deshabilitados muestran un badge Disabled y sus aristas se dibujan punteadas. Una línea de resumen arriba del grafo cuenta los manifiestos por origen (N manifests · X customized · Y user-added · Z disabled), junto con una leyenda de puntos de color.
Puedes arrastrar los nodos para acomodar el grafo — las posiciones se guardan por Workload, y Reset layout restaura el orden automático. Arrastrar nodos es una acción de layout — se actualiza al instante pero nunca registra un cambio pendiente ni dispara un deployment, sin importar el switch Deploy?. Las aristas no se pueden dibujar ni re-vincular en el grafo: las dependencias de un manifiesto solo se definen con Depends on al agregarlo.
Debajo del grafo, la franja Project-shared manifests muestra los manifiestos del project bucket que se despliegan junto a todos los Workloads, con un acceso Manage → a la Chart Configuration del Project y un botón Add to project que abre el diálogo de alta con el scope Project bucket preseleccionado.
Ingress por dominio
Cada dominio o alias que agregas a un WebService obtiene su propio nodo ingress-<slug> en el grafo, separado del nodo de la URL predeterminada del Workload — vas a ver un manifiesto Ingress por host, no uno solo compartido.
Borrar un manifiesto de ingress de un dominio puntual solo quita el ruteo de ese host: SleakOps no lo vuelve a crear automáticamente. Agrega un manifiesto nuevo (o vuelve a agregar el dominio) si necesitas ese host de nuevo.
Agregar un dominio cuyo host mapea al mismo nombre de Ingress de Kubernetes que otro host existente del Workload se rechaza al guardar el dominio — api.acme.com y api-acme.com colapsan al mismo nombre; elige uno que difiera en algo más que puntos o guiones. Los nombres de los nodos de manifiesto nunca chocan: un slug repetido simplemente recibe el id del dominio como sufijo.
Editar un manifiesto
Haz clic en cualquier nodo para abrir el editor. El header muestra el kind del manifiesto, su origen, un switch Enabled, un botón de copiado y Delete (requiere rol Admin — ver ¿Quién puede editar manifiestos?).
El tab YAML es donde editas el template; su toolbar muestra la versión del template base de la que salió el manifiesto (base vX, o no catalog base para un manifiesto que agregaste tú). Pueden aparecer dos tipos de placeholders:
- Las variables
<< form >>se resuelven antes de Helm, con los valores del formulario de tu Workload (nombre, namespace, command, healthcheck, etc.). - Las expresiones
{{ .Values }}quedan para Helm en el momento del deploy (replicas, resources, tag de imagen — todo lo que viene de Values).
El panel Variables de la derecha lista todo lo disponible: haz clic en una entrada para insertarla en el cursor, o arrástrala al editor. Arrastrar una variable sobre el editor muestra una vista previa del cursor en vivo, indicando dónde va a caer antes de soltarla.
El editor valida mientras escribes y lista los problemas debajo del YAML, con un badge Template valid / N errors en la toolbar. El chequeo en vivo no deshabilita Save: SleakOps vuelve a validar al guardar y rechaza un template que todavía tenga errores, mostrándolos en el mismo panel. El chequeo en vivo marca:
- Variables desconocidas, no declaradas en el contexto del Workload.
- Expresiones bloqueadas por el sandbox de templates.
- Quitar el label protegido
sleakops.com/managed. - Un
namespacedistinto al del entorno del Project — se muestra como warning mientras escribes, pero el guardado se rechaza: el namespace siempre es el del entorno.
Guardar tu primera edición estructural convierte un manifiesto managed en customized. Si el switch Deploy? de la toolbar del grafo está apagado, el guardado queda registrado como un cambio pendiente; si está prendido, se dispara un deployment al instante (las ediciones hechas desde la Chart Configuration siempre quedan pendientes — ver Desplegar tus cambios).
Preview
El tab Preview renderiza el template con las variables actuales del formulario y muestra exactamente lo que se le entregará a Helm:
Los badges sobre la salida confirman cuántas variables << form >> se resolvieron, si quedan expresiones {{ .Values }} para el deploy, y que los invariantes protegidos están presentes.
Si el template no renderiza, el tab Preview reemplaza su salida con una card "Template failed to render — nothing will deploy", listando los errores con su número de línea y un acceso Fix in YAML — esto es distinto de los badges que solo marcan expresiones {{ .Values }} sin resolver, que sí renderizan bien.
Agregar un manifiesto
Usa Add manifest (en la toolbar del grafo del Workload, o en el project bucket de la Chart Configuration) — o Add to project en la franja Project-shared manifests del Workload — para desplegar recursos más allá de los generados (requiere rol Admin — ver ¿Quién puede editar manifiestos?):
| Campo | Descripción |
|---|---|
| Scope | This workload (se despliega con el Workload, con variables << form >> disponibles) o Project bucket (compartido, se despliega con cada release). |
| Kind | ConfigMap, Secret, ServiceAccount, NetworkPolicy, PersistentVolumeClaim, CronJob — o Custom… para cualquier otro kind, incluidos CRDs. |
| Name | El nombre del manifiesto; se refleja en el metadata.name del template. |
| Depends on | Opcional. Dibuja las aristas del grafo desde este manifiesto hacia los seleccionados. |
| Template | El YAML del manifiesto. Se genera un stub inicial según el Kind elegido. |
Create manifest permanece deshabilitado hasta completar Kind, Name y Template. Mientras no hayas editado el stub a mano, escribir un Name lo refleja en vivo en el metadata.name del template y cambiar el Kind regenera el stub para el nuevo Kind; una vez que editas el template a mano, ninguno de los dos lo modifica.
Ten en cuenta:
- Los kinds cluster-scoped se rechazan — en la práctica, un manifiesto sin
namespaceen su metadata se rechaza como "cluster-scoped"; defínelo explícitamente, igual al del entorno del Project. SleakOps solo verifica si el campo está presente, no si el kind es realmente cluster-scoped en Kubernetes. - Los kinds custom requieren su CRD instalado en el cluster — por ejemplo, un
ScaledObjectde Keda necesita el Addon de Keda. SleakOps no valida esto al guardar el manifiesto; solo aparece como un error de Helm la próxima vez que el manifiesto se despliega.
El project bucket
Los manifiestos agregados con scope Project bucket no están atados a ningún Workload: se despliegan con cada release del Project. Los habitantes típicos son NetworkPolicies, ConfigMaps compartidos y ServiceAccounts. Se administran desde Project → Settings → Chart Configuration → Manifests:
El project bucket vive en la Chart Configuration, que se habilita por compañía. Si la card Chart Configuration no aparece en Project → Settings, la franja Project-shared manifests del Workload muestra "No shared manifests in this project yet." aunque el Project tenga alguno — pide a tu contacto de SleakOps que habilite la Chart Configuration para tu compañía.
El Explorer al inicio de la sección lista cada Workload del Project con sus manifiestos, y el project bucket al final. Hacer clic en un Workload abre su vista Advanced, y hacer clic en un manifiesto abre el editor ahí mismo.
El filtro busca tanto por nombre como por kind. Un Workload sin coincidencias se colapsa de la lista en vez de mostrar una lane vacía; si no hay coincidencias en ningún lado (incluido el bucket), vas a ver un mensaje "No manifests match". Los tipos de Workload que todavía no tienen una vista Advanced dedicada se muestran como filas deshabilitadas.
El editor libre de Templates de la Chart Configuration ya no existe: los recursos custom se agregan como manifiestos, y la sección debajo de Manifests ahora es Extends Values, que solo contiene los values globales del Project. Los Extra Templates que tenía un Project se migraron a manifiestos automáticamente — ver Extra Templates.
Actualizaciones del template base
Cuando personalizas un manifiesto, tu copia queda fijada: SleakOps nunca la sobreescribe, incluso cuando el template base del que salió recibe mejoras. Cuando existe una versión base más nueva, el editor muestra un badge update available y un banner ("Base template vN available — your copy is customized from vM. It will not be overwritten.") con un botón View diff. Cierra el banner con × para conservar tu versión tal como está.
View diff abre el tab YAML en modo comparación: tu manifiesto (todavía editable) a la izquierda, y la base de SleakOps de solo lectura a la derecha.
- Las líneas rojas son las líneas de tu copia que difieren de la base.
- Las líneas verdes son las líneas de la base que difieren de tu copia — incluido lo que agrega la base nueva.
El modo comparación tiene dos acciones en la toolbar del YAML: Exit compare y — solo para manifiestos customized — Reset to base, que descarta tus ediciones estructurales, restaura el último template base de SleakOps y vuelve el manifiesto a managed. Los valores del formulario no se ven afectados — solo rellenan variables. El reset solo está disponible desde el modo comparación; no hay botón de reset en el header del editor.
No necesitas esperar a que aparezca el banner de actualización disponible para compararte contra la base — todo manifiesto con un template base (managed o customized) tiene un botón Compare with base en la toolbar del tab YAML que abre el mismo modo comparación.
Deshabilitar y borrar
- Deshabilitar (el switch Enabled): el manifiesto se saltea en el próximo deploy pero conserva su configuración. Si el recurso ya estaba desplegado, el próximo deploy lo quita del cluster.
- Delete: el manifiesto deja de desplegarse y SleakOps no lo vuelve a crear en futuros seeds ni actualizaciones del template base. Puedes agregar un manifiesto equivalente más adelante.
Cambiar el schema de networking de un WebService a Internal deshabilita automáticamente todos sus manifiestos de ingress — vas a ver aparecer el badge Disabled sin tocar nada. Volver a Public o Private solo reactiva los manifiestos de ingress que este cambio automático deshabilitó; si habías deshabilitado uno a mano antes de pasar a Internal, sigue deshabilitado y tienes que reactivarlo tú mismo.
Borrar o resetear pide confirmación primero: el diálogo detalla la consecuencia (el manifiesto no se vuelve a crear en futuros seeds; un reset descarta tus ediciones estructurales) y su botón de confirmación queda etiquetado con la acción — Delete manifest / Reset to base.
Desplegar tus cambios
Todos los cambios de contenido hechos desde el tab Manifests de un Workload — incluidas las ediciones a manifiestos del project bucket abiertos desde su franja Project-shared manifests — respetan el switch Deploy? de la toolbar:
- Prendido — se dispara un deployment después de cada guardado.
- Apagado — los cambios se acumulan como cambios pendientes y se despliegan cuando los publicas.
Los cambios hechos desde la sección Manifests de Project → Settings → Chart Configuration (agregar, editar, deshabilitar o borrar un manifiesto ahí) siempre se registran como cambios pendientes: esa sección no tiene un switch Deploy? propio, y el switch Deploy? del pie de la página solo aplica a Apply changes del editor de Values.
Las acciones de layout del grafo — ver El grafo de manifiestos — nunca pasan por este switch.
FAQs
¿Puedo modificar los templates que genera SleakOps?
Sí. Abre la vista Advanced del Workload, haz clic en el manifiesto y edita su YAML. Tu copia pasa a customized y SleakOps nunca la sobreescribe.
¿Qué pasa con mis Extra Templates existentes?
Se migraron a manifiestos automáticamente, un manifiesto por documento YAML: un documento que redefine un recurso que SleakOps ya genera para un Workload pasó a ser la personalización de ese manifiesto del Workload, y todo otro documento pasó a ser un manifiesto del project bucket. El editor libre de Templates ya no existe — agrega y edita esos recursos como manifiestos. Ver Extra Templates para más detalle.
¿Puedo desplegar recursos de un CRD?
Sí — elige Custom… como Kind al agregar un manifiesto y define el apiVersion/kind del CRD. El manifiesto se guarda igual; el CRD debe estar instalado en el cluster (por ejemplo, el ScaledObject de Keda requiere el Addon de Keda); si no, el deploy falla con el error correspondiente de Helm.
¿Por qué no puedo cambiar el namespace de un manifiesto?
Cada entorno del Project se despliega en su propio Namespace de Kubernetes. Los manifiestos siempre se despliegan en el namespace del entorno — un valor distinto se rechaza para mantener los entornos aislados.
¿Cuál es la diferencia entre deshabilitar y borrar un manifiesto?
Deshabilitar conserva el manifiesto y su configuración pero lo saltea al desplegar — vuelve a prender el switch para reincluirlo. Borrar lo quita definitivamente: SleakOps no lo recrea en futuras actualizaciones, aunque siempre puedes agregar un manifiesto nuevo con el mismo contenido.
¿Quién puede editar manifiestos?
Los viewers ven el grafo y el YAML en modo solo lectura; renderizar un Preview requiere al menos el rol Editor. Los editors además pueden arrastrar nodos para reorganizar el grafo, pero no pueden crear, editar, deshabilitar, borrar ni resetear un manifiesto — esas acciones requieren el rol Admin.