Skip to main content
Systemplane es el plano de control para la configuración en tiempo de ejecución que comparten las aplicaciones de Lerian. Lo exponen para que puedas inspeccionar y cambiar ajustes operativos en un servicio en ejecución, sin reiniciarlo. En entornos financieros regulados, detener un servicio para aplicar un cambio de configuración es a la vez un riesgo de cumplimiento y una interrupción operativa. Con Systemplane, ajustas los valores que un servicio admite de forma segura mientras sigue atendiendo tráfico. Esta es la misma superficie de administración en cada aplicación que la monta. Cada producto documenta sus propias claves configurables, pero las rutas, las formas de solicitud y respuesta, y el modelo de autorización descritos aquí son comunes a todas ellas.

​
Qué es Systemplane

Systemplane no es un servicio independiente. Cada aplicación monta el mismo conjunto de rutas en su propio host y puerto HTTP, bajo un prefijo de ruta específico de la aplicación. Systemplane no tiene host ni puerto propios, ni un puerto de administración dedicado. El prefijo canónico documentado aquí es /system, pero varía según la aplicación (consulta la tabla de aplicabilidad más abajo). Las aplicaciones registran las rutas mediante código, y ningún generador de código las produce. Por eso no aparecen en la referencia de API generada de cada producto. Esta referencia documenta la superficie de forma manual para que puedas operarla de manera consistente entre productos. Toda la superficie está deshabilitada de forma predeterminada. Una aplicación la sirve solo cuando activas el ajuste SYSTEMPLANE_ENABLED. De lo contrario, la aplicación se ejecuta en modo de solo variables de entorno y no monta estas rutas.

​
Namespaces

La configuración vive en namespaces, cada uno con entradas planas con clave de tipo cadena. Los rieles y los plugins usan tres namespaces canónicos: Algunas aplicaciones registran un único namespace con el nombre de la aplicación en lugar de estos tres. Matcher, por ejemplo, mantiene todas sus claves bajo un único namespace matcher. El valor de cada entrada no tiene tipo en la capa de transporte. Cada clave registrada acepta su propio escalar, objeto o arreglo JSON, y su propio validador del lado del servidor revisa el valor. No todos los ajustes se pueden cambiar en tiempo de ejecución. La aplicación lee los ajustes de solo arranque una vez, al iniciar. Estos ajustes no aparecen en Systemplane y todavía requieren un reinicio para cambiar.

​
Endpoints

Todas las rutas son relativas al prefijo de la aplicación (predeterminado /system).
/system/-/catalog nombra una ruta de metadatos reservada. La aplicación la sirve antes que las rutas de namespace. El segmento - no es un namespace real, y no puedes usarlo como tal. Los errores usan un envelope plano {"code": <int>, "title": "<string>", "message": "<string>"}.

​
Autenticación y permisos

La autorización es deny-all de forma predeterminada. Una aplicación sirve la superficie solo después de que configures un autorizador. Sin un autorizador, la aplicación deniega cada solicitud. Cuando habilitas la autenticación, la aplicación aplica control de acceso basado en roles por namespace, sobre una identidad válida con ámbito de plataforma (no de tenant). Las lecturas requieren el permiso de lectura del namespace y las escrituras requieren el permiso de escritura correspondiente: La acción de lectura cubre GET. La acción de escritura cubre PUT y DELETE. Los endpoints de descubrimiento del catálogo requieren permiso de lectura para al menos un namespace.
Las cadenas de permiso exactas pueden variar según la aplicación. Matcher, que usa un único namespace, protege toda su superficie con el permiso system-runtime-config:admin (recurso system-runtime-config, acción admin) en lugar de las cadenas por namespace anteriores. Revisa la documentación propia del producto para conocer su modelo de autorización.
Los tokens son JWT de tipo bearer que emite el Access Manager de la plataforma. Los llamadores automatizados obtienen uno mediante el flujo de client-credentials.
Cuando una aplicación habilita la superficie de catálogo, GET /system/-/catalog lista cada clave que registra. La ruta de detalle GET /system/-/catalog/{namespace}/{key} devuelve el contrato de escritura completo de una clave. El contrato cubre su tipo, ámbito de tenant, clase de tiempo de ejecución, política de redacción, esquema JSON, reglas de validación, ejemplos válidos, valor predeterminado y la ruta PUT correspondiente. Usa el catálogo para saber qué expone un servicio antes de cambiar algo. El catálogo describe el contrato de escritura. Para leer el valor configurado actual, llama a GET /system/{namespace}/{key}.

​
Qué productos exponen Systemplane

Systemplane es opcional por producto. La siguiente tabla enumera los productos que lo montan. Para cada producto indica el prefijo de ruta, el puerto HTTP predeterminado y si el producto también sirve la superficie de descubrimiento del catálogo. El prefijo y el puerto son valores predeterminados. Un despliegue puede sobrescribirlos.
Los productos que no aparecen aquí no montan Systemplane. Los configuras solo mediante variables de entorno.