O Docker no Windows é uma aventura contínua. Então ele precisa atualizar o sistema operacional, caso contrário, as versões mais recentes não estão instaladas, então ele esquece como se conectar à rede. Em geral, todos os dias dele notícias. "Definir e esquecer" não é sobre o Docker Desktop para Windows. Especialmente quando não é usado exatamente como recomendado pelos desenvolvedores. E, por algum motivo, eles não aprovam a conexão de janelas externas a unidades de rede como locais. E eles não aprovam o acesso a pastas de rede que também estão localizadas na máquina host. Eles escrevem que isso é horror-horror do ponto de vista da segurança, exigem todos os tipos de chaves, como: para que o comando mount funcione no contêiner, e assim por diante.cap_add:
- SYS_ADMIN
- DAC_READ_SEARCHEm geral, quando mais uma vez depois que os contêineres foram carregados no servidor do cliente, os serviços pararam de ver unidades de rede, não fiquei particularmente surpreso. Isso já aconteceu e até mesmo uma instrução passo a passo foi escrita para o grupo de suporte, como e o que reiniciar quando as configurações de rede do docker quebrarem.Então eu abro minhas instruções e tomo uma ação. Reiniciar contêineres não ajuda. Eu reinicio através do docker-compor com recreação de uma infraestrutura - não ajuda. Eu redefinir as configurações do Docker para as configurações de fábrica, restaurar as configurações da máquina virtual, recarregar as imagens, executar o docker-compose - novamente, tudo está como antes - ele não vê a rede. Mais precisamente, ele não se conecta às esferas da rede, embora o ping do contêiner para o servidor SMB seja normal. O último ponto é reiniciar o servidor e reinstalar o Docker enquanto pulo, porque realmente não quero reiniciar o servidor. Nesta instrução terminou.Ok, estou indo para a minha máquina doméstica, aqui também tenho o Docker para Windows, mas uma versão um pouco mais nova. Eu verifico. Os mesmos ovos:
Sim. Bem, realmente, acho que o Docker acumulou a atualização com algum tipo de segurança e agora meus scripts não iniciam por causa disso? A última verificação é remover completamente o Docker da máquina e reinstalá-lo. Isso deve ser mais frio do que redefinir as configurações de fábrica. Estou fazendo a lista inteira da etapa anterior. Além disso, também estou reiniciando meu carro para que seja completamente irônico. Coloquei o Docker do zero, carregue imagens, inicie o docker-compose - eprst! Todos os serviços não viram a bola na rede e continuam a escrever "erro de montagem (22): argumento inválido" ao carregar.Tento executar o script linha por linha a partir da linha de comando: conectar ao contêiner, executar comandos alternadamente e ver se tudo se conecta e funciona como preciso:mkdir -p $SMB_MOUNT_POINT
mount -t cifs $SMB_SHARE $SMB_MOUNT_POINT -o user=$SMB_USER,password=$SMB_PASSWORD,vers=2.0
ls $SMB_MOUNT_POINT
Ou seja, o que é isso, algum tipo de porcaria com a passagem de parâmetros para o script quando o contêiner é iniciado?Estamos à procura de mais ideias. Todas as opções com uma reinicialização do docker são rasas, existem opções com possíveis alterações na imagem pai. Minha imagem é criada com base em openjdk: 8-jdk-alpine , nenhuma versão específica é especificada; portanto, quaisquer melhorias na segurança podem interromper meus scripts. Talvez eles mudaram algo no OpenJDK ou uma subsidiária da Alpine?Verifico os logs do projeto, tento selecionar o openjdk mais antigo: 8-jdk-alpine-3.8, openjdk: 8-jdk-alpine-3.7, etc. - toda vez que eu reconstruo o contêiner, verifique - tudo está como antes.Droga! Talvez eu ainda tenha mudado alguma coisa na minha montagem? Descarregando da versão GIT'a do projeto há um mês, coletando - as mesmas falhas. Três meses atrás - o problema ainda está lá. Como assim? O que mudou? A configuração da janela de encaixe está atualmente garantida para funcionar, a configuração da imagem também não mudou, as fontes do projeto são as mesmas (o GIT salva tudo). Não há milagres - você precisa entender onde as mudanças apareceram. No prod, inicio manualmente os comandos de conexão nas bolas - até que o reinício os serviços funcionem bem e durmam. A manhã é mais sábia que a noite.Não há conexão, mas você espera!
Na manhã seguinte, surge a idéia - que provavelmente é hora de descobrir e o que realmente o script não gosta na execução.A mensagem “erro de montagem (22): argumento inválido” não é muito informativa. Acho que existe uma chave mágica para o bash com o qual ele exibe informações de depuração ao executar scripts.Comece a depurar dentro de sh:/
' echo 'Mount //<private_ip>/Exchange/Pipeline to /pipeline
Mount //<private_ip>/Exchange/Pipeline to /pipeline
' mkdir -p '/pipeline
' mount -t cifs //<private_ip>/Exchange/Pipeline /pipeline -o 'user=<private_user>,password=<private_password>,vers=2.0
mount error(22): Invalid argument
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
mount: mounting //<private_ip>/Exchange/Pipeline on /pipeline failed: Invalid argument
' ls '/pipeline
+ exec
E aqui aparecem alguns momentos estranhos - a linha começa com aspas, depois as aspas no final ... De onde são as aspas?Idéia - o lançamento usando o bash real pode ser mais informativo?Instale no contêiner BASH:apk add bash
Eu começo a depurar:/
' echo 'Mount //<private_ip>/Exchange/Pipeline to /pipeline
Mount //<private_ip>/Exchange/Pipeline to /pipeline
+ mkdir -p $'/pipeline\r'
+ mount -t cifs //<private_ip>/Exchange/Pipeline /pipeline -o $'user=<private_user>,password=<private_password>,vers=2.0\r'
mount error(22): Invalid argument
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
mount: mounting //<private_ip>/Exchange/Pipeline on /pipeline failed: Invalid argument
+ ls $'/pipeline\r'
+ exec
Porra, parece que quando a linha começa com um plus - é bom, mas algum tipo de \ r e $ '...' apareceu .Definimos o Midnight Commander para experimentar as comodidades apk add mce abrir o script para edição, e lá:
Oppa! ^ M no final de cada linha. Bem, veja o projeto local - e as terminações da linha ???? CRLF. No entanto, trabalhamos no Windows.Mude este arquivo CRLF específico para LF (viva o Notepad ++!), Colete o projeto - bingo! Funciona como deveria.Por que estava tudo bem antes, mas agora tudo voou? Eu olho para os commits - não houve alterações. E então eu lembro que o GIT pode editar feeds de linha rapidamentearquivos de texto. No outro dia, conectei um novo repositório e, possivelmente, carreguei todos os arquivos de lá com a conversão para o CRLF.Como resultado, adicionamos o arquivo .gitattributes ao projeto , indicando que em arquivos separados é necessário salvar os caracteres de final de linha, como no UNIX:# Set the default behavior, in case people don't have core.autocrlf set.
* text=auto
# Declare files that will always have LF line endings on checkout.
*.sh text eol=lf
Moralidade - às vezes o culpado nem se enquadra no círculo de suspeitos iniciais.
P.S
Após a atualização para a versão mais recente do Docker Desktop for Windows 2.2.0.3, tudo parou de funcionar. Dessa vez, entrei imediatamente nos contêineres e comecei a depurar. Verificou-se que o endereço IP 10.0.75.1 para acessar a máquina host parou de funcionar, o DockerNat agora foi removido do sistema e a máquina virtual DockerDesktopVM nem sequer possui um adaptador de rede externo, ou seja, a comunicação com ele não passa por uma rede padrão, mas de alguma forma diferente. E para acessar o host, você deve usar host.docker.internal . Colegas desenvolvedores e escreveu queO DockerNAT foi removido do Docker Desktop 2.2.0.0, pois o uso de um endereço IP para se comunicar do host com um contêiner não é um recurso suportado. Para se comunicar de um contêiner para o host, você deve usar o nome DNS especial host.docker.internal.
Ok, corrigi as configurações do ambiente de teste, o banco de dados foi capturado, o ping do contêiner para o host.docker.internal passa, mas as unidades de rede não estão conectadas. Eu tento executar o mount manualmente a partir do shell e recebo o erro familiar "mount error (22): argumento inválido".Eu removo os argumentos por sua vez - apenas executei "mount -t cifs //host.docker.internal/playground / pipeline" - parece funcionar, mas está atrapalhando o usuário root.Adicionar usuário: mount -t cifs //host.docker.internal/playground / pipeline -o user = smbuser - solicita uma senha e se conecta!A versão completa também funciona:mount -t cifs //host.docker.internal/playground /pipeline -o user=smbuser,password=smbpassword
mas " mount -t cifs //host.docker.internal/playground / pipeline -o usuário = smbuser, senha = smbpassword, vers = 2.0 " não funciona.Eu mudo o último parâmetro para vers = 2.1 - saúde, funciona!Parece que a versão mais recente do Docker fez sua própria implementação do servidor SMB com blackjack, mas sem suporte para 2.0. Bobagem, é claro, em comparação com outras notícias.Toda bondade, força e perseverança!A ilustração do artigo foi retirada de blog.eduonix.com/software-development/learn-debug-docker-containers