APRENDER. PRATICAR. EVOLUIR.Definir o ambiente que vais reproduzir
Num projeto fictício de automação de batch, o autor consegue trabalhar no seu contentor, mas RUN precisa de preparar outra instância. O laboratório começa com uma imagem Python já disponível e acrescenta apenas um utilizador learner e um ficheiro de demonstração. A configuração versionável define a imagem, a montagem do projeto, a pasta aberta, os utilizadores, duas variáveis públicas e os passos de ciclo de vida. Antes de executar, prevê quais ficheiros estarão no host, quais pertencerão apenas à instância e quais já estão na imagem. Regista a identidade da imagem resolvida, além do nome da tag. Uma tag reutilizada pode apontar para outro conteúdo. O exercício usa a CLI Dev Containers 0.89.0; a existência de resultados da CLI não equivale a testar a interface gráfica do VS Code.
Localizar a escrita antes de escolher a recuperação
O projeto é montado em /workspace. O autor cria input.txt no host; a ferramenta lê esse conteúdo e escreve output.txt, que aparece também no host. Fora da montagem, cria manual-helper.txt em /home/learner. Após parar e arrancar a mesma instância, ambos permanecem. Ao remover e recriar o contentor, output.txt continua na pasta partilhada e manual-helper.txt desaparece. Para RUN, estas observações justificam duas ações diferentes: proteger alterações do workspace e transformar preparação manual em passos repetíveis. Parar e arrancar não é um teste de reconstrução. Também não basta mover o helper para outro caminho da camada gravável. Se o ficheiro é necessário, a definição do ambiente deve explicar como volta a existir. O exemplo usa um ficheiro de demonstração, não uma instalação real de uma ferramenta.
Separar identidade e ambiente dos processos
A configuração do exercício escolhe containerUser=root e remoteUser=learner para tornar a diferença observável. A CLI executa Python com UID 1001; um docker exec sem seleção de utilizador observa UID 0. A variável DR_CONTAINER_FLAG aparece nos dois processos. DR_REMOTE_FLAG, definida em remoteEnv, aparece apenas no processo das ferramentas. Estes valores são públicos e não contêm credenciais. Num diagnóstico, começa por identificar quem iniciou o processo e qual contexto recebeu. Uma tarefa funcionar no terminal não comprova o ambiente de um processo de arranque. Também não demonstra become num nó gerido: este laboratório não executa Ansible nem SSH. Num host Linux real, verifica IDs numéricos e permissões do bind mount; o resultado no Docker Desktop macOS não comprova um mapeamento idêntico noutra plataforma.
Distinguir arranque, criação e configuração efetiva
Os marcadores tornam o ciclo de vida visível. Na criação inicial, postCreateCommand acrescenta uma linha a created.txt e postStartCommand outra a started.txt. No arranque seguinte da mesma instância, apenas o marcador de arranque ganha nova linha. InitializeCommand escreve host-init.txt no host e não deve ser confundido com preparação interna da imagem. Depois, o exercício muda containerEnv de initial para revised e reutiliza a instância: o processo continua a receber initial. Só a recriação fornece revised e volta a executar o passo de criação. Ao aprovar uma alteração, compara ficheiro de configuração, identidade da instância e observação do valor efetivo. Um hook que prepara dependências pode falhar enquanto o contentor fica ativo; o critério de aceitação deve incluir a preparação concluída e os comandos que o projeto realmente usa.
Interpretar montagens e ausências de ficheiros
Uma sonda só de leitura consegue ler a referência, mas a escrita de forbidden.txt falha. Confirmar RW=false orienta a solução: escolhe um destino de resultados com escrita permitida, sem tornar gravável a referência. Outra sonda monta o projeto em /opt/dr-fixture, onde a imagem já continha base.txt. O ficheiro deixa de aparecer; num contentor sem essa montagem volta a ser lido. A montagem ocultou conteúdo, sem o apagar da imagem. Por isso, antes de reinstalar uma ferramenta aparentemente ausente, inspeciona os destinos das montagens. Com um daemon remoto, a origem tem de existir no lado do daemon; uma pasta apenas no portátil não é transferida por um bind mount. Esta parte remota é uma análise de configuração baseada na documentação, não uma operação executada pelo laboratório local.
Passagem a RUN com critérios executáveis
O ensaio completo foi repetido: 26 verificações por execução, com a CLI 0.89.0, Docker Engine 29.1.3 e Python 3.13.16 dentro do contentor. Os recursos próprios foram removidos no final. Entrega a RUN a revisão do projeto, identificação da imagem, montagem esperada, utilizador, dependências e comandos de aceitação. Pede ao destinatário que prepare uma instância nova e explique qualquer diferença. Se o play correr depois numa EE distinta, inspeciona também essa imagem e as collections que ela contém. A aprovação do dev container não prova acesso aos nós, funcionamento de serviços ou persistência RHEL após reboot. O aluno deve conseguir justificar cada ficheiro preservado ou perdido e reconstruir o ambiente sem depender do estado acumulado do autor. Este exercício original não reproduz tarefas oficiais EX294.
OBSERVAÇÕES
CLI exec: UID=1001; cwd=/workspace
docker exec: UID=0
remoteEnv: apenas nas ferramentas
stop/start: helper manual permanece
recriação: helper desaparece; output.txt permanece
containerEnv: initial -> recriação -> revised
readonly: escrita rejeitada
mount em /opt/dr-fixture: base.txt ocultoO helper manual permanece após stop/start, mas desaparece numa instância nova; output.txt persiste porque pertence ao bind mount.
Armadilhas comuns
Confundir reinício com recriação, remoteUser com todos os processos, containerEnv editado com valor efetivo ou montagem com cópia automática para um daemon remoto.
Tópicos relacionados: Git e revisão executada · Roles e collections · Acesso aos nós geridos
Aceita o ambiente a partir de uma recriação observada, identificando onde vive cada dependência e efeito.
Referência: Dev Container metadata reference · EX294 current objectives inspected 2026-09-30; RHCE in Ansible framework effective 2026-05-11; booking product version not publicly pinned