Docker组合，启动userland代理时出错:侦听tcp 0.0.0.0:22: bind: address已在使用

Question

我正试着在macOS (Big ) (docker-compose up -d)上安装并运行一个与对接者一起运行的D1图像。我在virtualBox驱动程序中使用virtualBox。

但是，在启动容器时，我会得到以下错误：

ERROR: for web  Cannot start service web: driver failed programming external connectivity on endpoint gitlab-docker_web_1 (236233cf090b94f98e2e82c2fa795bc7f6f5ff38e2ea14f3649e87313a21d196): Error starting userland proxy: listen tcp 0.0.0.0:22: bind: address already in use
ERROR: Encountered errors while bringing up the project.

问题是，我无法在主机上的端口22上找到任何运行。

> sudo lsof -i :22
>

什么都不回。运行netstat -l | grep 22以查找侦听端口，我也没有看到任何内容：

tcp4       0      0  byrons-mac-pro.l.61179 229.26.211.130.b.https ESTABLISHED
tcp4       0      0  byrons-mac-pro.l.60764 108.177.122.108.imaps  ESTABLISHED
tcp4       0      0  byrons-mac-pro.l.60761 108.177.122.108.imaps  ESTABLISHED
tcp4       0      0  byrons-mac-pro.l.60760 108.177.122.108.imaps  ESTABLISHED
tcp4       0      0  byrons-mac-pro.l.60759 108.177.122.108.imaps  ESTABLISHED
tcp4       0      0  byrons-mac-pro.l.60758 108.177.122.108.imaps  ESTABLISHED
tcp4       0      0  byrons-mac-pro.l.60755 108.177.122.108.imaps  ESTABLISHED
tcp4       0      0  byrons-mac-pro.l.60754 108.177.122.108.imaps  ESTABLISHED
tcp4       0      0  byrons-mac-pro.l.54147 yi-in-f188.1e100.5228  ESTABLISHED
tcp4       0      0  byrons-mac-pro.l.49743 104.22.52.136.https    ESTABLISHED
tcp4       0      0  byrons-mac-pro.l.49734 yv-in-f188.1e100.5228  ESTABLISHED
tcp4       0      0  byrons-mac-pro.l.49556 108.177.122.95.https   ESTABLISHED
tcp4       0      0  byrons-mac-pro.l.49173 17.57.144.150.5223     ESTABLISHED
tcp4       0      0  byrons-mac-pro.l.61183 52.96.122.50.https     TIME_WAIT
tcp4       0      0  byrons-mac-pro.l.61182 52.96.122.50.https     TIME_WAIT
udp4       0      0  byrons-mac-pro.l.56826 108.177.122.139.https
c0fd8701c6b3232b stream      0      0                0 c0fd8701c6b32263                0                0
c0fd8701c6b32263 stream      0      0                0 c0fd8701c6b3232b                0                0
c0fd8701b7e36583 stream      0      0 c0fd8701b9bb407b                0                0                0 /var/folders/yt/c5z_l8554mq_fc3f0c5tpw600000gn/T/dotnet-diagnostic-2202-1621045110-socket
c0fd8701add5cb63 stream      0      0                0 c0fd8701add5ca9b                0                0 /var/folders/yt/c5z_l8554mq_fc3f0c5tpw600000gn/T/vscode-ipc-a70bbba5-ec65-4f40-861a-0bc122628a75.sock
c0fd8701a9b0232b dgram       0      0                0 c0fd8701a9b02263 c0fd8701a9b02263                0
c0fd8701a9b02263 dgram       0      0                0 c0fd8701a9b0232b c0fd8701a9b0232b                0

我有点困惑。这是我的docker-compose.yml：

web:
  image: "gitlab/gitlab-ce:latest"
  restart: always
  hostname: "byrons-mac-pro.lan"
  environment:
    GITLAB_OMNIBUS_CONFIG: |
      external_url 'http://byrons-mac-pro.lan'
      gitlab_rails['smtp_enable'] = true
      gitlab_rails['smtp_address'] = 'smtp.gmail.com'
      gitlab_rails['smtp_port'] = 587
      gitlab_rails['smtp_user_name'] = 'remove@cantellyou.com'
      gitlab_rails['smtp_password'] = '.........................'
      gitlab_rails['smtp_domain'] = 'smtp.gmail.com'
      gitlab_rails['smtp_authentication'] = 'login'
      gitlab_rails['smtp_enable_starttls_auto'] = true
      gitlab_rails['smtp_tls'] = false
      gitlab_rails['smtp_openssl_verify_mode'] = 'peer' # Can be: 'none', 'peer', 'client_once', 'fail_if_no_peer_cert', see http://api.rubyonrails.org/classes/ActionMailer/Base.html
      puma['worker_processes'] = 2
      sidekiq['max_concurrency'] = 10
      prometheus_monitoring['enable'] = false
  ports:
    - "80:80"
    - "443:443"
    - "22:22"
  volumes:
    - "$GITLAB_HOME/config:/etc/gitlab"
    - "$GITLAB_HOME/logs:/var/log/gitlab"
    - "$GITLAB_HOME/data:/var/opt/gitlab"

Answer 1

这是一个奇怪的事实，macOS没有本机docker，因此所有(？)实现有一个后台虚拟机，其中运行着Linux内核和dockerd (我认为这一点从您目前所知道的docker-machine中是显而易见的，但是.我想不会)。几乎可以肯定的是，这台机器正在监听22，因为大多数人实际上确实希望访问该虚拟机以进行故障排除。

我比一般人更有信心，您可以自定义docker-machine启动的虚拟机，并要求它将ssh绑定到:2222 (类似于这)，或者“欺骗”和docker-machine ssh systemctl stop sshd.service类型的东西，从而释放ssh端口，但从那时起，docker-machine ssh甚至docker-machine stop也可能无法像您预期的那样工作。