Introducción
La configuración del generador ya es de solo lectura, pero la aplicación sigue ejecutándose como root. Como responsable de mantenimiento, seleccionarás el usuario preparado sin perder la generación real de documentos.
Este entorno independiente incluye su propio contenedor y datos. Examinarás el UID y la propiedad de la salida, editarás el formato de inicio ya practicado, y recrearás y probarás el servicio. Completa primero Proteger la configuración montada.
Conocer al usuario de la aplicación
En este paso establecerás el comportamiento normal y distinguirás al usuario de mantenimiento del usuario del proceso del contenedor. Este entorno nuevo ya tiene configuración de solo lectura, pero el generador aún funciona como root.
Usa Maintenance, que empieza en /home/labex/project/report-desk. Solo administra el contenedor preparado report-renderer. Si es necesario, vuelve con cd /home/labex/project/report-desk. sudo docker exec pide a Docker ejecutar un comando dentro del objetivo. id muestra los identificadores numéricos de usuario (UID) y grupo (GID):
sudo docker exec report-renderer id
uid=0(root) gid=0(root) groups=0(root)
UID 0 es root dentro de este contenedor. Tiene más autoridad sobre los archivos accesibles de la necesaria. El root del contenedor no administra una VM independiente: los contenedores comparten el núcleo del host. El ejercicio reduce el acceso a archivos, no todos los riesgos posibles.
La identidad preparada es UID/GID 1200:1200. Los identificadores numéricos funcionan sin añadir una cuenta con nombre a la imagen. El propietario del directorio del host debe permitirle escribir. ls -ldn enumera el directorio mismo (-d), permisos detallados (-l) e identificadores numéricos (-n):
ls -ldn output
Busca drwxr-xr-x y propietario/grupo 1200 1200. El propietario tiene rwx: lectura, escritura y recorrido del directorio. Los demás tienen r-x: lectura y recorrido, sin escritura. El entorno preparó el directorio para la identidad prevista.
Genera una referencia con el POST ya practicado. curl -fsS informa de errores HTTP y -X POST solicita la acción empresarial:
curl -fsS -X POST http://localhost:8090/render/baseline
{"saved": "/output/baseline.json", "total": 37, "uid": 0}
El informe funciona, pero lo produjo UID 0. Abre Document Desk para ver el documento guardado; la página enumera archivos reales de salida.
Seleccionar la identidad preparada
En este paso cambiarás la identidad en la declaración de inicio conservando el acceso necesario al sistema de archivos. cat muestra el script:
cat launch.sh
sudo autoriza la administración del host. Por separado, --user determina el usuario y grupo de la aplicación del contenedor. 0:0 significa UID 0 y GID 0. Cambiarlo a 1200:1200 selecciona la identidad preparada. Conserva el puerto 8090, la imagen y ambas rutas de montaje. La línea de configuración ya contiene dst=/config,readonly; la salida debe seguir siendo escribible.
Abre el editor de terminal:
nano launch.sh
Usa las flechas para reemplazar solo --user 0:0 por --user 1200:1200. Guarda con Ctrl+O, Enter y sal con Ctrl+X. Muestra el archivo otra vez:
cat launch.sh
La línea de usuario debe ser:
--user 1200:1200 \
Cambiar la declaración no actualiza el proceso activo. Antes de recrearlo, establece explícitamente la propiedad prevista de la salida. chown establece propietario y grupo numéricos; requiere sudo porque difieren del usuario del host. Solo afecta al directorio, no a todos sus archivos existentes:
sudo chown 1200:1200 output
No hagas todo de solo lectura: generar documentos requiere escribir salida. Tampoco otorgues escritura a todos para eludir la propiedad; el propietario preparado puede escribir con los permisos actuales 755.
Recrear y conservar el resultado empresarial
En este paso aplicarás la identidad nueva y probarás salida normal y entradas protegidas. Como antes, elimina solo el contenedor objetivo e inicia su reemplazo:
sudo docker rm -f report-renderer
bash launch.sh
Si falla el inicio, corrige launch.sh con nano, elimina el objetivo fallido con el mismo comando y vuelve a ejecutar el script. Los datos del host permanecen. Comprueba la identidad activa:
sudo docker exec report-renderer id
uid=1200 gid=1200 groups=1200
Espera un momento al inicio y genera el documento final:
curl -fsS -X POST http://localhost:8090/render/final
{"saved": "/output/final.json", "total": 37, "uid": 1200}
Permission denied suele indicar un propietario incorrecto del directorio o un final.json creado anteriormente por root. Corrige el directorio con sudo chown 1200:1200 output. Si existe un archivo final antiguo, sudo rm output/final.json elimina solo ese documento generado; solicítalo otra vez. Read-only file system para /output indica que restringiste por error la salida: corrige la declaración y recrea el contenedor.
Examina el archivo generado. ls -ln muestra la propiedad numérica y cat su contenido:
ls -ln output/final.json
cat output/final.json
Busca propietario 1200, "uid": 1200, total 37 y Report for Harbor Books: 37 orders. Actualiza Document Desk para ver el archivo. Confirma finalmente que la protección de configuración continúa:
sudo docker exec report-renderer touch /config/probe.txt
touch: /config/probe.txt: Read-only file system
Este fallo es esperado. La identidad no root y el montaje de solo lectura resuelven problemas distintos: seleccionar UID reduce la autoridad del proceso, mientras el montaje bloquea escrituras incluso para root dentro del contenedor. El generador sigue realizando su tarea real.
Resumen
Separaste el acceso de mantenimiento del host de la identidad de la aplicación, seleccionaste UID/GID 1200 y conservaste su directorio de salida. El proceso y el documento recién generado usan ahora UID 1200, mientras las escrituras de configuración siguen rechazándose.
