Introdução
A aplicação de relatórios já tem configuração somente leitura, mas ainda executa como root. Como responsável pela manutenção, escolha o usuário preparado preservando a geração real de documentos.
Este ambiente independente inclui seu próprio contêiner e dados. Você examinará UID e propriedade da saída, editará o formato de inicialização já praticado e recriará e testará o serviço. Conclua primeiro Proteger a configuração montada.
Conhecer o usuário da aplicação
Nesta etapa, estabeleça o comportamento normal e diferencie o usuário de manutenção do usuário do processo do contêiner. O novo ambiente já tem configuração somente leitura, mas o gerador ainda executa como root.
Use Maintenance, que começa em /home/labex/project/report-desk. Ele administra somente o contêiner preparado report-renderer. Se necessário, volte com cd /home/labex/project/report-desk. sudo docker exec pede ao Docker para executar um comando no alvo. id mostra os identificadores numéricos de usuário (UID) e grupo (GID):
sudo docker exec report-renderer id
uid=0(root) gid=0(root) groups=0(root)
UID 0 é root neste contêiner e tem mais autoridade sobre os arquivos acessíveis do que a aplicação precisa. O root do contêiner não administra uma VM independente: os contêineres compartilham o kernel do host. O exercício reduz o acesso a arquivos, não todos os riscos possíveis.
A identidade preparada é UID/GID 1200:1200. IDs numéricos funcionam sem adicionar uma conta nomeada à imagem. O proprietário do diretório do host deve permitir a escrita desse usuário. ls -ldn lista o próprio diretório (-d), permissões detalhadas (-l) e IDs numéricos (-n):
ls -ldn output
Encontre drwxr-xr-x e proprietário/grupo 1200 1200. O proprietário tem rwx: leitura, escrita e travessia do diretório. Os demais têm r-x: leitura e travessia, sem escrita. O ambiente preparou o diretório para a identidade prevista.
Gere um documento inicial com o POST já praticado. curl -fsS relata falhas HTTP e -X POST solicita a ação empresarial:
curl -fsS -X POST http://localhost:8090/render/baseline
{"saved": "/output/baseline.json", "total": 37, "uid": 0}
O relatório funciona, mas UID 0 ainda o produziu. Abra Document Desk para ver o documento armazenado; a página lista arquivos reais de saída.
Selecionar a identidade preparada
Nesta etapa, mude a identidade na declaração de inicialização mantendo o acesso necessário ao sistema de arquivos. cat mostra o script:
cat launch.sh
sudo autoriza a administração do host. Separadamente, --user determina usuário e grupo da aplicação no contêiner. 0:0 significa UID 0 e GID 0; 1200:1200 seleciona a identidade preparada. Mantenha a porta 8090, a imagem e ambos os caminhos de montagem. A linha da configuração já contém dst=/config,readonly; a saída deve continuar gravável.
Abra o editor de terminal:
nano launch.sh
Use as setas para substituir somente --user 0:0 por --user 1200:1200. Salve com Ctrl+O, Enter e saia com Ctrl+X. Mostre o arquivo novamente:
cat launch.sh
A linha do usuário deve ser:
--user 1200:1200 \
Mudar a declaração não atualiza o processo ativo. Antes de recriar, estabeleça explicitamente a propriedade prevista da saída. chown define proprietário e grupo numéricos; exige sudo porque diferem do usuário de manutenção do host. Afeta somente o diretório, não todos os arquivos existentes:
sudo chown 1200:1200 output
Não torne tudo somente leitura: gerar documentos requer gravar a saída. Não conceda escrita a todos para contornar a propriedade; o proprietário preparado pode escrever com as permissões atuais 755.
Recriar e preservar o resultado empresarial
Nesta etapa, aplique a nova identidade e teste a saída normal e a proteção das entradas. Como antes, remova somente o contêiner alvo e inicie sua substituição:
sudo docker rm -f report-renderer
bash launch.sh
Se a inicialização falhar, corrija launch.sh com nano, remova o alvo que falhou com o mesmo comando e execute o script novamente. Os dados do host permanecem. Confira a identidade ativa:
sudo docker exec report-renderer id
uid=1200 gid=1200 groups=1200
Aguarde um momento pela inicialização e gere o documento final:
curl -fsS -X POST http://localhost:8090/render/final
{"saved": "/output/final.json", "total": 37, "uid": 1200}
Permission denied geralmente indica proprietário incorreto do diretório ou um final.json criado anteriormente por root. Corrija o diretório com sudo chown 1200:1200 output. Se existir um arquivo final antigo, sudo rm output/final.json remove somente esse documento gerado; solicite-o novamente. Read-only file system para /output indica que você restringiu a saída por engano: corrija a declaração e recrie o contêiner.
Examine o arquivo gerado. ls -ln mostra a propriedade numérica, e cat mostra o conteúdo:
ls -ln output/final.json
cat output/final.json
Encontre proprietário 1200, "uid": 1200, total 37 e Report for Harbor Books: 37 orders. Atualize Document Desk para ver o arquivo. Por fim, confirme que a configuração continua protegida:
sudo docker exec report-renderer touch /config/probe.txt
touch: /config/probe.txt: Read-only file system
Essa falha é esperada. A identidade não root e a montagem somente leitura resolvem problemas diferentes: escolher UID reduz a autoridade do processo, enquanto a montagem impede escritas na configuração até pelo root do contêiner. O gerador continua realizando sua tarefa real.
Resumo
Você separou o acesso de manutenção do host da identidade da aplicação, selecionou UID/GID 1200 e preservou o diretório de saída. O processo e o documento recém-gerado agora usam UID 1200, enquanto as escritas na configuração continuam recusadas.
