Caros companheiros Faulters de servidor!
Eu tropecei em um problema que me confunde MUITO e você é minha única ajuda! Longa história curta: 1. Eu tenho um conjunto de playbooks ansible para configurar servidores 2. Estes livros didáticos são testados e verificados em relação ao Google Cloud e DigitalOcean 3. Esta semana, o playbook que inicia contêineres docker em servidores começou a falhar nas instâncias mais recentes do Google Compute (eu-west4-a) e somente lá - instâncias de computação antigas se comportam como esperado, bem como instâncias em outros ISPs
Ansible falha com o seguinte erro:
fatal: [example_hostname]: FAILED! => {"changed": false,
"msg": "Error starting container b57a81e7e1a39da89f91c6d6439b51cf4078f87f5a6997a7dcdd7098f84a7485:
500 Server Error: Internal Server Error (\"OCI runtime create failed:
container_linux.go:348: starting container process caused \"process_linux.go:402:
container init caused \\"invalid argument\\"\": unknown\")"}
Quando o contêiner é iniciado pela execução do docker (com os mesmos parâmetros que no playbook ansible), o contêiner é iniciado com êxito. Também não é o caso com apenas uma das imagens - nenhum contêiner pode ser iniciado via ansible. Ao mesmo tempo, iniciá-los pelo docker executado diretamente no servidor funciona bem.
O daemon do Docker falha com o seguinte erro:
time="2018-07-25T11:54:10.809711044+02:00" level=debug msg="Calling GET /_ping"
time="2018-07-25T11:54:10.810917212+02:00" level=debug msg="Calling POST /v1.38/containers/node_exporter/restart"
time="2018-07-25T11:54:10.813468661+02:00" level=debug msg="container mounted via layerStore: &{/var/lib/docker/overlay2/a11e836fe1015928ca1181298f0934a8ee70c122e4eb1e09635b2d31c11eb3b1/merged 0x55808cfe7620 0x55808cfe7620}"
time="2018-07-25T11:54:10.813897061+02:00" level=debug msg="container mounted via layerStore: &{/var/lib/docker/overlay2/a11e836fe1015928ca1181298f0934a8ee70c122e4eb1e09635b2d31c11eb3b1/merged 0x55808cfe7620 0x55808cfe7620}"
time="2018-07-25T11:54:10.820720679+02:00" level=debug msg="EnableService a31ae80856cef0bc72298b68660739e04bc710cd815ce2a746d7276065464ab0 START"
time="2018-07-25T11:54:10.821163095+02:00" level=debug msg="EnableService a31ae80856cef0bc72298b68660739e04bc710cd815ce2a746d7276065464ab0 DONE"
time="2018-07-25T11:54:10.826647553+02:00" level=debug msg="bundle dir created" bundle=/var/run/docker/containerd/a31ae80856cef0bc72298b68660739e04bc710cd815ce2a746d7276065464ab0 module=libcontainerd namespace=moby root=/var/lib/docker/overlay2/a11e836fe1015928ca1181298f0934a8ee70c122e4eb1e09635b2d31c11eb3b1/merged
time="2018-07-25T11:54:10+02:00" level=debug msg="event published" ns=moby topic="/containers/create" type=containerd.events.ContainerCreate
time="2018-07-25T11:54:10+02:00" level=info msg="shim docker-containerd-shim started" address="/containerd-shim/moby/a31ae80856cef0bc72298b68660739e04bc710cd815ce2a746d7276065464ab0/shim.sock" debug=true pid=7576
time="2018-07-25T11:54:10+02:00" level=debug msg="registering ttrpc server"
time="2018-07-25T11:54:10+02:00" level=debug msg="serving api on unix socket" socket="[inherited from parent]"
time="2018-07-25T11:54:10+02:00" level=info msg="shim reaped" id=a31ae80856cef0bc72298b68660739e04bc710cd815ce2a746d7276065464ab0
time="2018-07-25T11:54:10.870453438+02:00" level=error msg="stream copy error: reading from a closed fifo"
time="2018-07-25T11:54:10.870900093+02:00" level=error msg="stream copy error: reading from a closed fifo"
time="2018-07-25T11:54:10+02:00" level=debug msg="event published" ns=moby topic="/containers/delete" type=containerd.events.ContainerDelete
time="2018-07-25T11:54:10.883501549+02:00" level=error msg="a31ae80856cef0bc72298b68660739e04bc710cd815ce2a746d7276065464ab0 cleanup: failed to delete container from containerd: no such container"
time="2018-07-25T11:54:10.885529863+02:00" level=debug msg="FIXME: Got an API for which error does not match any expected type!!!: Cannot restart container node_exporter: OCI runtime create failed: container_linux.go:348: starting container process caused \"process_linux.go:402: container init caused \\"invalid argument\\"\": unknown" error_type="*errors.errorString" module=api
time="2018-07-25T11:54:10.885962960+02:00" level=error msg="Handler for POST /v1.38/containers/node_exporter/restart returned error: Cannot restart container node_exporter: OCI runtime create failed: container_linux.go:348: starting container process caused \"process_linux.go:402: container init caused \\"invalid argument\\"\": unknown"
time="2018-07-25T11:54:10.886356247+02:00" level=debug msg="FIXME: Got an API for which error does not match any expected type!!!: Cannot restart container node_exporter: OCI runtime create failed: container_linux.go:348: starting container process caused \"process_linux.go:402: container init caused \\"invalid argument\\"\": unknown" error_type="*errors.errorString" module=api
Nenhum desses quando executado por meio do docker é executado. Originalmente pensado para ser um problema relacionado ao ansible ou python, mas ter instalado o mesmo conjunto de pacotes e bibliotecas em exatamente as mesmas versões me fez olhar para frente. Então, em última análise, o que me permite começar a contêineres portuários via ansible novamente está sendo emitido ...
apt purge -y google-compute-engine google-compute-engine-oslogin
Depois que esses pacotes acabarem e a instância for reinicializada, tudo funcionará perfeitamente !!! Verificando com outros servidores do GCE, as versões atuais desses pacotes são:
ii google-compute-engine 2.8.3-1 all Google Compute Engine guest environment.
ii google-compute-engine-oslogin 1.3.0-1+deb9 amd64 Google Compute Engine OS Login
De outra instância em que tudo funciona como esperado:
ii google-compute-engine 2.7.6-1 all Google Compute Engine guest environment.
ii google-compute-engine-oslogin 1.1.5-1+deb9 amd64 Google Compute Engine OS Login
Eu não posso rebaixar esses pacotes, pois eles aparentemente não estão mais presentes no repo.
Agora, em relação ao OSLogin - não estou usando esse recurso, e explicitamente bloqueando-o através de metadados de instância (enable-oslogin = FALSE) não altera nada. A única "solução" confiável para esse problema é remover pacotes - mas, como é um intervalo "súbito", não parece adequado.
Além de remover esses pacotes (e reinicializar, o SSHd restart provavelmente seria suficiente). Executando
/usr/bin/google_oslogin_control deactivate
Também não corrige nada (mesmo após a reinicialização da VM inteira). Eu fiquei sem ideias sobre o que verificar e o que observar - eu sinto que remover os pacotes não é realmente o caminho a seguir, já que eles estão presentes em outras VMs e parece uma mudança recente de comportamento em algum lugar. Eu não posso identificar onde.
Qualquer tipo de resposta é bem-vinda e apreciada!
A partir do rastreador de problemas do Google: link
A causa desse problema foi o nome do host longo (50 caracteres no meu caso) - a redução resolveu o problema e permitiu que os contêineres fossem iniciados. Convido todos os interessados a analisar a questão do Google para obter mais detalhes.