Entornos de una app

Cada recurso de una app pertenece a un entorno. La página de un entorno contiene lo que comparten sus recursos: los nodos que pueden usar, las variables y los secretos que recibe cada carga de trabajo, el mantenimiento de todas sus Routes y la promoción desde otro entorno o hacia él. Ábrela desde la pestaña Overview o desde el bloque Environments de la pestaña Settings de la app.

Nodos permitidos

Un entorno solo crea recursos en los nodos que permite. Un entorno nuevo no permite ninguno. Usa Allow node en la página del entorno para añadir un nodo; la pestaña Nodes de la app muestra los nodos permitidos de cada entorno.

La regla se aplica en todas partes, no solo en la consola: la REST API, MCP y el asistente de IA se niegan a crear un contenedor, un deployment, un proyecto Compose, una base de datos gestionada, un almacenamiento gestionado, una Route o un proyecto de Pages del entorno en un nodo que este no permite, y lo mismo ocurre con la migración, Workload Availability y la restauración de una copia de seguridad en una base de datos nueva. Cuando el entorno no permite ningún nodo del tipo necesario, la petición se rechaza con “no allowed node”; cuando indica un nodo que no está permitido, con “node not allowed”.

Se puede quitar un nodo de la lista en cualquier momento. La confirmación muestra cuántos recursos del entorno se ejecutan allí; siguen funcionando, pero ya no se pueden crear recursos nuevos en ese nodo.

Variables y secretos

El bloque Variables define valores que recibe cada contenedor, deployment y servicio de Compose del entorno. Los Secrets son lo mismo, pero de solo escritura: después de guardarlos, solo se muestran sus claves y la hora en que cambiaron. Ambos se cifran en reposo. Un entorno admite hasta 200 claves, cada valor de hasta 32 KiB, y una clave es o una variable o un secreto, no ambas cosas. Los proyectos de Pages no reciben variables.

Cuando una clave está definida en varios sitios, gana el valor más específico, de menor a mayor prioridad:

1. el propio ENV de la imagen;
2. las variables del entorno;
3. los secretos del entorno;
4. las variables de entorno propias del recurso (o las variables del proyecto Compose);
5. los secretos propios del recurso.

La pestaña Environment de un contenedor marca las claves que proceden del entorno. Los valores del entorno nunca se copian en los ajustes propios del recurso, así que cambiarlos después cambia lo que recibe el recurso. Un servicio de Compose recibe todas las claves del entorno que no define él mismo; los valores no se escriben en el archivo Compose.

Save, o Save and recreate

Las cargas de trabajo en ejecución no se reinician cuando cambias los valores del entorno. Tras Save, el aviso indica cuántas cargas de trabajo recibirán los valores nuevos en su próxima recreación o despliegue.

Para aplicarlos ya, usa More → Save and recreate N workloads. Recrea las cargas de trabajo una a una: los contenedores se recrean, los deployments pasan por su despliegue normal y los proyectos Compose se aplican. El diálogo muestra el progreso de cada carga de trabajo y se detiene en el primer fallo, que indica; las cargas de trabajo posteriores no se tocan.

Una carga de trabajo que pasa a otro entorno recibe los valores del nuevo entorno en su próxima recreación, y se eliminan las claves del entorno anterior. Una carga de trabajo que se saca de la app pierde las claves del entorno en su próxima recreación.

Mantenimiento

Maintenance, en la página del entorno, pone a la vez en mantenimiento todas las Routes del entorno: devuelven la página de mantenimiento (HTTP 503) hasta que lo desactivas. Se conserva el ajuste de mantenimiento propio de cada Route, que vuelve a aplicarse después. El bloque muestra Off, Maintenance o cuántas Routes tienen activado su propio mantenimiento mientras el interruptor del entorno está desactivado.

Maintenance for the whole app, en la pestaña Settings de la app, hace lo mismo para todas las Routes de todos los entornos y prevalece sobre el interruptor de cada entorno; la página del entorno muestra entonces Overridden by the app. Al desactivarlo se restaura el estado propio de cada entorno.

Solo se ven afectadas las Routes que reenvían a un upstream, igual que con el interruptor propio de la Route. La página de una Route muestra de dónde viene su mantenimiento.

Código de acceso de mantenimiento

Para dejar pasar a una persona mientras las Routes están en mantenimiento, abre el menú de acciones del entorno (o de la app) y elige Create Maintenance Access Code. El código es válido durante 5 minutos y abre una vez cada Route de ese entorno (o de toda la app) que esté en mantenimiento. Compártelo solo con la persona que necesita el acceso. Las Routes deben ejecutarse en un nodo de ingress que admita códigos de acceso, y un código nunca funciona mientras la app está aislada. Consulta Listas de acceso y mantenimiento para ver cómo se introduce un código.

Promover

El bloque Promote ejecuta en otro entorno exactamente lo que se ejecuta en este, sin volver a construir nada. Es la forma de llevar un staging probado a production.

1. En la página del entorno de origen, elige Promote to <environment>. Con más de dos entornos, selecciona primero el destino.
2. El paso 1 enumera lo que se ejecuta en el origen y cómo se compara con el destino: Same, Changed o Not promotable con el motivo. Desactiva lo que no deba promoverse.
3. El paso 2 muestra lo que ocurre en el destino con cada elemento.
4. Confirma. Los elementos se ejecutan uno tras otro; un fallo no detiene a los demás. El diálogo muestra el progreso de cada uno.

Lo que se promueve:

• Contenedores y deployments: la imagen por su digest, de modo que el destino ejecuta exactamente la misma imagen, byte a byte. Un deployment usa su despliegue normal. Una imagen construida desde Git se promueve como el mismo artefacto de build, sin un build nuevo.
• Proyectos Compose: el archivo Compose de la revisión de origen, con la imagen de cada servicio fijada al digest que se ejecuta en el origen. El destino conserva sus propias variables y secretos.
• Proyectos de Pages: el despliegue activo del origen se copia en el proyecto de destino y pasa a estar activo allí.

Las bases de datos, el almacenamiento, sus datos y su esquema nunca se promueven.

Los recursos se emparejan por nombre: el mismo nombre, o el nombre de origen sin un -<environment> final (shop-api-staging en staging se empareja con shop-api en production). Un recurso de origen sin pareja aparece como inexistente en el destino. Una pareja de tipos distintos, como un deployment y un contenedor, no se puede promover.

La vista previa se vuelve a comprobar al confirmar; si algo ha cambiado entretanto, Opfield te pide que la revises de nuevo. Cada promoción queda registrada en la pestaña Activity de la app con lo que cambió, y el bloque Promote del entorno muestra cuándo se promovió algo a él por última vez.

Permisos

Gestionar los nodos permitidos, las variables, los secretos, el mantenimiento y los códigos de acceso requiere el rol Developer en el entorno (apps:env:manage). Promover requiere el rol Deployer en el entorno de destino (apps:promote). El mantenimiento de toda la app requiere el rol Operator en la app. La propia página del entorno requiere apps:view en el entorno; un usuario que solo ve el entorno a través de sus recursos vuelve a la página de la app. Consulta Permisos de las apps.