Como faço para expor a API docker sobre TCP?

Estou usando portainer e não consigo gerenciar endpoints remotos. Tentei usar a linha de comando para me conectar a nós Docker remotos, mas recebi uma mensagem Cannot connect to the Docker daemon at tcp://<remote_ip>:<port>. Is the docker daemon running?.

Sim, eles estão correndo. Eu me adicionei ao grupo docker e posso acessar o docker inserindo sshing nos nós. No entanto, não consigo acessar nenhum nó do docker remotamente.

Eu modifiquei /etc/default para adicionar / descomentar DOCKER_OPTS="--dns 8.8.8.8 --dns 8.8.4.4 -H tcp://0.0.0.0:2375 -H unix:///var/run/docker.sock"

Eu também modifiquei /etc/init.d/docker e /etc/init/docker.conf incluir DOCKER_OPTS="-H tcp://0.0.0.0:2375 -H unix:///var/run/docker.sock".

Reiniciei o serviço docker, desconectei e fiz login várias vezes no processo, mas ainda não consigo me conectar ao nó remoto. Não consigo nem me conectar ao nó local passando o IP.

O que perdi? Qual configuração em qual arquivo expõe a API sobre TCP?

user@hostname:~$ docker -H tcp://<REMOTE_IP>:2375 infoCannot connect to the Docker daemon at tcp://<REMOTE_IP>:2375. Is the docker daemon running?user@hostname:~$ docker -H tcp://127.0.0.1:2375 infoCannot connect to the Docker daemon at tcp://127.0.0.1:2375. Is the docker daemon running?user@hostname:~$ docker -H tcp://<LOCAL_IP>:2375 infoCannot connect to the Docker daemon at tcp://<LOCAL_IP>:2375. Is the docker daemon running?user@hostname:~$

Editar:Execucao ps aux | grep -i docker retorna isso -

root      3581  0.1  0.2 596800 41540 ?        Ssl  04:17   0:35 /usr/bin/dockerd -H fd://root      3588  0.0  0.0 653576 14492 ?        Ssl  04:17   0:18 docker-containerd -l unix:///var/run/docker/libcontainerd/docker-containerd.sock --metrics-interval=0 --start-timeout 2m --state-dir /var/run/docker/libcontainerd/containerd --shim docker-containerd-shim --runtime docker-runc

Encontrei uma solução graças a O post de Ivan Krizsan.

Eu tive que editar /lib/systemd/system/docker.service no meu sistema Ubuntu 16.04.2 LTS para modificar a linha

ExecStart=/usr/bin/docker daemon -H fd:// -H tcp://0.0.0.0:

entao

sudo systemctl daemon-reloadsudo systemctl restart docker.service

e tudo funcionou : -). O próximo passo é descobrir como proteger o formulário daemon do docker que está sendo sequestrado.

O diretório/etc / default é onde os mantenedores de distribuição colocam seus arquivos de configuração. Se você instalar o docker diretamente dos repositórios do Docker, esse diretório não será usado.

O diretório/lib / systemd é onde os pacotes instalarão seus arquivos systemd e substituirão quaisquer alterações na atualização. Se você usar isso, suas alterações serão perdidas.

Para fazer suas próprias alterações em um arquivo de unidade systemd que persistem, você pode criar um arquivo de unidade em /etc/systemd/system/docker.servico.d/, por exemplo, aqui está meu padrão / etc / systemd / system / docker.servico.D / Substituir.conf:

[Service]ExecStart=ExecStart=/usr/bin/dockerd

Isso substitui simplesmente unsets todos os sinalizadores de linha de comando para o daemon dockerd do systemd. Uma vez feito isso, você pode substituir todas as configurações de /etc / docker / daemon.json que é usado pelo docker e, dependendo da configuração, pode ser recarregado sem reiniciar o daemon. Por exemplo, aqui está um exemplo /etc/docker/daemon.json:

{"debug": false,"experimental": true,"hosts": ["fd://", "tcp://0.0.0.0:2376"],"labels": ["foo=bar", "fez=baz"],"log-driver": "json-file","log-opts": {"max-size": "10m", "max-file": "3"},"storage-driver": "overlay2","tlscacert": "/etc/docker/certs/ca.pem","tlscert": "/etc/docker/certs/host-cert.pem","tlskey": "/etc/docker/certs/host-key.pem","tlsverify": true}

Para seus propósitos, você só precisa da linha para definir os hosts.

Uma parte extremamente importante do arquivo de configuração acima são as configurações TLS. Se você não configurar TLS mútuos entre cliente e servidor e abrir o docker para ouvir na rede, estará executando o equivalente a um servidor telnet aberto com logins raiz permitidos sem uma senha. Se você preferir ssh sobre telnet, ou se você preferir ter uma senha para sua conta raiz, então você deve configurar TLS. As portas da API do docker são frequentemente verificadas na internet e você encontrará malware instalado em seu host em pouco tempo se pular esta etapa de configuração.

Detalhes completos sobre como configurar as chaves TLS para cliente e servidor podem ser encontrados em:https://docs.docker.com/engine/security/https/


Observe que, com as versões 18.09 e superiores do docker no cliente (tanto onde você executa seu comando quanto o nó remoto), você pode usar o ssh em vez de configurar o TLS. Isso envolve o uso de um DOCKER_HOST valor do ssh://user@host. Por exemplo.

docker -H ssh://user@host container ls

Há uma documentação oficial descreve como Configure onde o daemon do Docker escuta as conexões.

systemd vs daemon.json

Configurando o Docker para ouvir conexões usando o arquivo de unidade systemd e o daemon.o arquivo json causa um conflito que impede o início do Docker.

Configurando o acesso remoto com o arquivo da unidade systemd

  1. Use o comando sudo systemctl edit docker.serviço para abrir um arquivo de substituição para docker.serviço em um editor de texto.

  2. Adicione ou modifique as seguintes linhas, substituindo seus próprios valores.

    [Service]ExecStart=ExecStart=/usr/bin/dockerd -H fd:// -H tcp://127.0.0.1:2375
  3. Salve o arquivo.

  4. Recarregue a configuração systemctl.

    $ sudo systemctl daemon-reload
  5. Reinicie O Docker.

    $ sudo systemctl restart docker.service
  6. Verifique se a alteração foi honrada revisando a saída do netstat para confirmar se o dockerd está ouvindo na porta configurada.

    $ sudo netstat -lntp | grep dockerdtcp        0      0 127.0.0.1:2375          0.0.0.0:*               LISTEN      3758/dockerd

Configurando o acesso remoto com daemon.json

  1. Defina a matriz hosts no/etc/docker / daemon.json para se conectar ao soquete UNIX e um endereço IP, da seguinte forma:

    {"hosts": ["unix:///var/run/docker.sock", "tcp://127.0.0.1:2375"]}

    Configurando o Docker para ouvir conexões usando o arquivo de unidade systemd e o daemon.o arquivo json causa um conflito que impede o início do Docker.

    1. Adicione ou modifique as seguintes linhas, substituindo seus próprios valores.

      [Service]ExecStart=ExecStart=/usr/bin/dockerd
    2. Salve o arquivo.

    3. Recarregue a configuração systemctl.

      $ sudo systemctl daemon-reload
  2. Reinicie O Docker.

  3. Verifique se a alteração foi honrada revisando a saída do netstat para confirmar se o dockerd está ouvindo na porta configurada.

    $ sudo netstat -lntp | grep dockerdtcp        0      0 127.0.0.1:2375          0.0.0.0:*               LISTEN      3758/dockerd

O cliente Docker honrará o DOCKER_HOST variável de ambiente para definir o -H sinalizar para o cliente. Use um dos seguintes comandos:

$ docker -H tcp://127.0.0.1:2375 ps

ou

$ export DOCKER_HOST="tcp://127.0.0.1:2375"$ docker ps

Se você não quiser reconfigurar e reiniciar o daemon do docker, basta conectar o soquete unix a um soquete TCP usando ncat (do nmap pacote):

ncat -lknvp 2375 -c "ncat -U /var/run/docker.sock"

Como alternativa, você pode usar socat ou outras ferramentas.

Para aqueles que procuram esta resposta no contexto do Ubuntu server 20.04 que usa ENCAIXAR:

Este comentário github questão deve dar-lhe o contexto que você precisa. No meu caso, não encontrei o conjunto de variáveis de ambiente $SNAP_DATA, então tive que procurar todo o daemon.arquivos json no sistema e usou aquele com o /var prefixo

$ sudo find / -name daemon.json

No meu caso, tinha duas entradas não relacionadas, então acabei de adicionar a minha:

{  [.....]  "hosts": ["unix:///var/run/docker.sock", "tcp://0.0.0.0:2375"]}

O IP acima determina de onde será acessível, e a porta pode ser qualquer porta que você deseja expor. No meu caso particular, não consegui fazê-lo funcionar com um IP específico, em vez disso, tive que usar 0.0.0.0, caso contrário, ele falharia com o seguinte erro ao reiniciar:

aufs aufs_fill_super:918:mount[3724]: no argoverlayfs: missing 'lowerdir'aufs aufs_fill_super:918:mount[3772]: no argoverlayfs: missing 'lowerdir'aufs aufs_fill_super:918:mount[3820]: no argoverlayfs: missing 'lowerdir'

Estranho o suficiente, ao usar 0.0.0.0, ele realmente cospe um par das linhas de erro acima, mas funciona depois. No meu caso, como esta é uma VM, isso é aceitável para mim.

Tentei coisas semelhantes e suspeitei que os arquivos / etc / default / docker,/etc/init / docker.conf e/etc / init.d / docker são simplesmente ignorados no Ubuntu 16.04 com uma instalação do docker-ce, alguém pode confirmar? Acho que quando executo “service docker status” o que realmente acontece é “systemctl status docker”, todo um outro sistema de gerenciamento.

O 2375 está ouvindo? “ss-ntl”

Não. Não há nada ouvindo em 2375. E não consigo descobrir qual configuração em qual arquivo afeta isso. Incluí a saída de ‘ps aux’ na minha resposta, se isso ajudar.