Moby: 도커 스웜 모드 : 127.0.0.1의 포트는 0.0.0.0에 노출됩니다.

예, 그러면 오류가 출력됩니다. 서비스 (기본적으로)는 "ingress"네트워크를 사용하여 "게시"하고 IP 주소 지정을 지원하지 않습니다. 어떤 _node_가 끝날지 예측할 수 없기 때문입니다 (따라서 어떤 IP 주소를 사용할 수 있는지 알 수 없습니다. .0.1 가능). 이 문제는 https://github.com/docker/docker/issues/26696 기능을 추적하고 있으며이 "에픽"은 서비스 https://github.com/docker/docker/issues에서 지원하지 않는 다른 옵션을 추적합니다. / 25303)

여기서 버그는 docker가 자동으로 옵션을 무시하는 대신 오류를 생성해야한다는 것입니다. 이 최소한의 docker-compose 파일을 사용하여 재현 가능합니다.

version: "3.2"
services:
  mongodb:
    image: nginx:alpine
    ports:
      - "127.0.0.1:27017:80"

핑 @dnephin @vdemeester

@ fer2d2 스웜 모드에서 무언가를 게시하면 ( ports 대해 stack deploy ), ingress 네트워크에 게시되므로 공개됩니다. 돌아 다니는 몇 가지 방법이 있지만 kind/bug 를 넣는 이유는이 표기법이있는 포트 (예 : host:port:port 로 stack deploy 를 수행 할 때 적어도 사람들에게 경고해야하기 때문입니다 host:port:port ).

이 문제를 해결하려면 몇 가지 방법이 있습니다.

• 먼저 mongo 포트를 공개 하려는 경우에만 게시해야합니다. 그렇지 않으면 docker의 이름 검색 번들을 통해 사용할 수 있습니다 (동일한 네트워크의 다른 컨테이너 / 서비스는 mongo 통해 연결할 수 있습니다.
• ingress 아닌 호스트에 게시하려는 경우 (Swarm public이 아니라 실행중인 호스트에서만, swarm 모드없이 동일한 방식으로) 포트 확장 구문 을 사용해야

    ports:
      - mode: host
        target: 80
        published: 9005

docker run -p 80:9005 … 와 동일하게 수행하므로 0.0.0.0 바인딩하지만 호스트로 제한됩니다.

그러나 @thaJeztah가 말했듯이 "여기서 버그는 docker가 옵션을 조용히 무시하는 대신 오류를 생성해야한다는 것입니다."👼

/ cc @mavenugo @aboch 특정 IP에 실제로 바인딩 할 수있는 방법이 있는지 확인하려면? (노드의 IP가 다르기 때문에 달성하기가 정말 까다 롭습니다.)

@vdemeester 이 표기법을 사용하여 localhost 를 호스트 대상으로 지정할 수 있습니까?

    ports:
      - mode: host
        target: 127.0.0.1:80
        published: 9005

포트 구성을 위한 확장 형식이므로 제대로 작동해야합니다.

미리 감사드립니다

긴 구문에서 대상과 게시가 모두 정수 유형으로 적용되는 것 같습니다.

SSH 터널을 통해 일부 서비스에 연결하는 경우 이것이 바람직한 동작이 아니라고 생각합니다. 당신이 127.0.0.1에서의 MySQL이나 MongoDB의 서버를 가지고 SSH 터널을 통해 연결하고자 할 경우 예를 들어, 도커 떼와 함께 당신은 0.0.0.0에 데이터베이스 포트를 노출하거나 내부를 실행 SSH와 사용자 정의 데이터베이스 컨테이너 (모두 옵션을 만들어야합니다 매우 안전하지 않음).

이 제한 (특정 인터페이스 바인딩)으로 인해 사용할 수없는 SQL Workbench 또는 Robomongo와 같이 SSH 터널을 사용하는 많은 데이터베이스 클라이언트가 있습니다.

ssh 터널을 통해 Mongobooster를 docker swarm과 연결하려고 시도하는 @ fer2d2 와 동일한 문제가 있습니다. 우리가 찾은 유일한 해결책은 27017 포트를 열고 사용자와 암호로 데이터베이스를 보호하는 것입니다.

어떤 소식이라도?

+1

+1

긴 형식의 포트 매핑을 위해 ip_ address : port 쌍을 허용하는 또 다른 사용 사례는 애니 캐스트 주소 또는 루프백과 연관 될 수있는 다른 주소입니다. 이는 루프백 네트워크에서만 볼 수 있다는 점에서 127.0.0.1 주소와 유사합니다. 이 속성을 가진 노드로 제한된 서비스는 포트 변환을위한 iptables 규칙을 피하면서 포트 충돌을 피하기 위해 애니 캐스트 주소에서만 포트를 노출하려고 할 수 있습니다.

다음을 지정할 때 옵션이 될 수 있습니까?

placement:
        constraints:
          - node.id ==

건배

+1

+1

+1

나 자신을 위해이 문제를 해결했습니다.

iptables -I DOCKER-USER -i eth0 -j DROP
iptables -I DOCKER-USER -m state --state RELATED,ESTABLISHED -j ACCEPT

도커는 이러한 규칙을 건드리지 않습니다. 자신의 것을 추가하십시오
-A DOCKER-USER -j RETURN
결과적으로 포트는 0.0.0.0에서 수신하지만 외부 인터페이스 eth0에서 액세스 할 수 없습니다.

이 동작은 "기본적으로 보안"에 위배되며 문서에 메모를하는 것만으로는 충분하지 않습니다. 지금은 오류가 발생합니다.

또한 모드 : 인 그레스 / 호스트와 관련이 있습니다 (이 두 가지 문제는 논의에서 혼동되는 것 같습니다). 서비스가 모든 노드의 로컬 주소에 바인딩되는 것을 중지해야하는 수신 모드에 대해서는 아무 것도 없지만 외부 주소에는 연결되지 않습니다. 따라서 127.xxx가 허용되어야합니다. (비 스웜 모드에서 (도커 실행 사용) 127.0.0.2:80 및 127.0.0.3:80 등에 바인딩합니다. 개발중인 여러 서버를 로컬로 테스트합니다.).

다른 문제는 수신 모드가 기본값이라는 것입니다. 이것은 예상치 못한 일이며 보안 문제도 발생합니다. 방금 포트가 127.0.0.3:80으로 바인드 된 네트워크의 사설 부분에있는 것으로 제한된 노드에서 서비스를 시작하려고했습니다. 그런 다음 공용 노드의 공용 인터페이스에도 바인딩되었습니다. (즉, IP 주소를 조용히 무시하고 수신 모드를 조용히 사용하며 내 데이터가 공개됩니다.)

사용 사례

• 나에게 영향을 준 사용 사례 (확실히 실제)
  
  
  
  • 1 포트가 다른 노드에서 사용 중이므로 특정 노드의 포트에 바인딩합니다. 이를 위해 호스트 모드를 사용할 수 있지만 기본값은 놀랍습니다.
  
  
  • 2 다른 노드에는 공용 인터페이스가 있으므로 특정 노드의 포트에 바인딩합니다. 이를 위해 호스트 모드를 사용할 수 있지만 기본값은 "기본적으로 보안"위반입니다 .
  
  
  • 3 다른 호스트에 표시되는 것을 원하지 않으므로 기본적으로 "기본적으로 보안"을 위반 하므로 로컬로 바인딩합니다.
  
  
  • 4 개발 머신에 많은 항목이 있고이 포트에서 127.0.0.1이 사용 중이므로 127.0.0.3에 바인딩합니다. 그리고 /etc/hosts 를 사용하여 각 도메인 이름이 다른 컨테이너로 전송되도록합니다. docker run 에서는 작동하지만 compose에서는 작동하지 않습니다.
  
  
• 기타 사용 사례
  
  
  
  • 내부 네트워크이므로 특정 인터페이스 (예 : 192.168.0.x)에 바인딩합니다. 기본값은 "기본적으로 보안"위반입니다.
  
  
  • 특정 특정 노드에 바인딩하되이 노드에서 실행되도록 서비스를 제한하지 않습니다. 이것은 1 또는 2와 유사한 사용 사례이지만 제약 조건을 사용하지 않습니다. 트래픽은 떼를 통해 라우팅됩니다.
  
  

요약하자면

• IP 주소를 무시하고 0.0.0.0에 바인딩하는 것과 기본 수신 모드는 모두 "기본적으로 보안"을 위반합니다. IP-Address가 지정되고 문서가 업데이트되면 오류가 발생해야합니다. 모드가 지정되지 않은 경우 (기본값 없음) 오류가 발생하고 문서가 업데이트됩니다. (이것은 모드 문제를 해결하고 갑작스러운 보안 문제를 막습니다.)
• 그런 다음 호스트 모드에서 IP 주소에 대한 지원을 추가 할 수 있습니다.
• 수신 모드에서 로컬 주소 127.xxx로 제한되는 IP 주소에 대한 지원이 추가 될 수 있습니다. (다른 로컬 주소, 예를 들어 127.0.0.2 및 127.0.0.3은 다른 것으로 취급해야합니다 (단지 OS로 전달됨)).

로컬 주소에 바인딩 허용은 제한된 노드에 유용합니다. 특정 주소에 바인딩 허용, 제한된 노드에 대해 작동하거나 떼를 통해 노드 중 하나의 주소 중 하나로 라우팅됩니다 (수신 모드 만 가능). 이 라우팅은 이미 완료되었습니다.

@ richard-delorenzi Moby는 현재 호스트 IP도 허용하지 않습니다. 따라서 기능 요청 외부에서 이것은 클라이언트 측 문제처럼 들립니다. 특히 compose yaml이 Docker CLI에서 번역되는 방식입니다.

인 그레스가 작동하는 방식은 꽤 잘 문서화되어 있지만 이것이 CLI에서 좋지 않은 동작이라는 데 동의합니다.

+1

+1

+1

내가 사용하는 일종의 해결 방법이 있습니다. 독립 실행 형 컨테이너를 실행하고 'core'라는 네트워크에 연결합니다.이 네트워크는 떼 안에서 실행되는 모든 백엔드 서비스 (mongo, elasticsearch, influxdb 등)에서 사용됩니다.

작성 파일에서이 작업을 수행하는 방법을 볼 수 없으므로 다음과 같이 독립 실행 형 컨테이너를 실행하고 있습니다.

docker run --name kibana --rm -d -v /var/lib/kibana:/usr/share/kibana/config -p 127.0.0.1:5601:5601 --network core docker.elastic.co/kibana/kibana:6.1.2

docker run --name chronograf --rm -d -v /var/lib/chronograf:/var/lib/chronograf -p 127.0.0.1:8888:8888 --network core chronograf:1.4 chronograf --influxdb-url=http://influxdb:8086

이를 시작한 후 docker ps는 새 컨테이너가 127.0.0.1에 바인딩 된 것으로 표시합니다. 아멘. 그런 다음 보안 액세스를 위해 다음과 같이 로컬 워크 스테이션에서 도커 호스트로 터널링 할 수 있습니다.

ssh -i my_ssh_key.pem [email protected]  -L 8888:localhost:8888  -L 5601:localhost:5601 -N

내 브라우저에서 http : // localhost : 8888 또는 http : // localhost : 5601에 연결할 수 있습니다.

나를 위해 작동합니다.

UNIX 소켓이 127.0.0.1 TCP / IP 소켓을 대체 할 수있는 경우 여기 에서 fluent-bit에 대해 구현 한 가능한 해결 방법을 사용할 수

mode 다른 옵션을 추가하면 도움이 될 수 있습니다. 같은 뭔가 local 이외에 host 및 ingress .

"사용 가능한 보안 : Moby는 사용성을 손상시키지 않고 보안 기본값을 제공합니다."라는 문구를 제거하십시오. moby readme 파일에 있습니다. 이것은 확실히 잘못된 광고입니다. @ richard-delorenzi의 의견을 참조하십시오.

서비스는 기본적으로 포트를 게시하지 않으므로 포트를 게시하도록 지정하지 않으면 액세스 할 수 없습니다. 특정 IP 주소에 대한 바인딩은 현재 지원되지 않습니다. 서비스에 액세스 할 수 없어야하는 경우 포트를 게시하지 말고 내부 (오버레이) 네트워크를 사용하여 서비스에 연결하십시오.

IP 주소 바인딩에 대한 지원 추가는 https://github.com/moby/moby/issues/26696 에서 설명하지만 구현하기가 간단하지는 않습니다 (비 "localhost"IP 주소 고려).

스택을 배포 할 때 경고가 추가되었습니다.

docker stack deploy -c- test <<'EOF'
version: '3'
services:
  web:
    image: nginx:alpine
    ports:
      - "127.0.0.1:8080:80"
EOF

WARN[0000] ignoring IP-address (127.0.0.1:8080:80/tcp) service will listen on '0.0.0.0' 
Creating network test_default
Creating service test_web

지정된 IP 주소로 서비스를 배포하려고하면 오류와 함께 배포에 실패합니다.

docker service create -p 127.0.0.1:9090:80 nginx:alpine
invalid argument "127.0.0.1:9090:80" for "-p, --publish" flag: hostip is not supported
See 'docker service create --help'.

@dalu 시스템이 인터넷에 노출되어 있고 Docker에게 클러스터에 서비스를 노출하라고 지시 한 경우 예상이 다른 이유가 무엇인지 잘 모르겠습니다.

확실히 개발과 실제 배포에 어려움을 겪는이 구성 형식은 심각한 타협이 있습니다.

헉헉

시스템이 인터넷에 노출되고 Docker에 클러스터에서 서비스를 노출하도록 지시 한 경우 예상이 다른 이유가 무엇인지 모르겠습니다.

아니. 누군가가 127.0.0.1 또는 10.0.0.0과 같은 비 공용 IP에 바인딩하면 왜 공개적으로 액세스 할 수 있어야합니까? 사실 정답입니다.

특정 IP 주소에 대한 바인딩은 현재 지원되지 않습니다.

달루

그러나 공개적으로 만 액세스 할 수 있어야합니다. 그리고 그것이 여기에서 모든 거래입니다.
기본적으로 안전하지 않으며 의미론으로 수정을 회피합니다.
이 문제는 적절한 해결책없이 거의 2 년 동안 열려 있습니다.

swarm을 사용할 수 없기 때문에 swarm에서 kubernetes로 전환하고 있습니다. 이 전환이 매우 비용이 많이 들지만이 결정에 전적으로 만족합니다.

@Bessonv 문자 그대로 "나는 이것을 무시하고 있습니다"라고 말합니다.

문제는 compose 형식이 dev 환경 용으로 설계되었으며 클러스터 배포를 지원하도록 푸시되었다는 것입니다. "도커 스택"은 오류가 발생해야하지만 사람들은 하나의 compose 파일을 사용하여 모두를 지배 할 수 있기를 원합니다.

헉헉
이 설명이 마음에 들지 않습니다. 마지막으로 작성 형식은 원하는 상태에 대한 설명입니다. 단일 머신 (구성)과 클러스터 (스웜) 사이에 약간의 차이를 갖는 것은 완전히 괜찮습니다. 제 관점에서는 작곡을 지원할 필요가 전혀 없습니다. 특히 스웜 모드 활성화가 너무 쉽기 때문에. 그러나 이것은 떼를 고정해야합니다.

문제는 전혀 무리가 아니며 작성 형식 + docker cli의 구현에서 100 %입니다.
스택은 현재 100 % 클라이언트 측 구현입니다.

스택 내부에서 데이터베이스, redis 등과 같은 내부 서비스에 대한 포트를 명시 적으로 노출 할 필요가 없다는 것을 발견했습니다. 내부 서비스 의 ports 구성을 생략하고 이름으로 참조하는 것만으로도

스택 내부의 db 서비스 예

services:
  db:
    image: postgres:11-alpine
  networks:
    - backend

... 다음과 같이 기본 포트로 Django app 서비스에서 사용할 수 있습니다.

DATABASES = {
    'default': env.db(default='postgres://user:pass<strong i="13">@db</strong>:5432/catalog'),
}

따라서이 경우 공개 서비스 만 명시 적으로 노출하면 이는 기본적으로 보안 된 것처럼 보입니다.

문제는 전혀 무리가 아니며 작성 형식 + docker cli의 구현에서 100 %입니다.
스택은 현재 100 % 클라이언트 측 구현입니다.

뭐든간에 : 나는 (이 문제 때문에) 스택 사용을 중단했고 더 이상 신경 쓰지 않습니다. 도서관을 비난하고, 도커를 비난하고, 내 고양이를 비난하십시오.

Docker를 직접 사용하거나 compose를 사용할 때이 문제를 보지 못했습니다.

이 접근 방식이 도움이 될 수 있습니다 (스웜의 모든 노드에서 실행되어야 함).

1. 무리를 떠나다
2. 네트워크 docker_gwbridge 제거
3. 추가 옵션 com.docker.network.bridge.host_binding_ipv4 = IP를 사용하여 네트워크 docker_gwbridge를 다시 만듭니다.
4. 다시 무리에 합류
   "호스트"모드로 게시 된 포트에서 작동합니다. 모드없이 "호스트"수신 네트워크는 다른 드라이버 및 범위 "swarm"과 함께 사용됩니다.

끔찍한 해결책 :

$ mv /usr/bin/docker-proxy /usr/bin/docker-proxy-original
$ cat << 'EOF' > /usr/bin/docker-proxy
#!/bin/sh
exec /usr/bin/docker-proxy-original `echo $* | sed s/0.0.0.0/127.0.0.1/g`
EOF
$ chmod 755 /usr/bin/docker-proxy
$ service docker restart

@jsmouret 최신 도커 릴리스에서 도커 프록시를 찾을 수도 없습니다. 유산인가? 아니면 이름이 다른가요?

상황에 따라 다릅니다 ...

$ apt-file search docker-proxy
docker-ce: /usr/bin/docker-proxy
docker.io: /usr/sbin/docker-proxy

이 동작은 어떻게 든 문서화되어야한다 문서 .
현재는 짧은 포트 매핑에서 호스트를 무시합니다. 그리고 조용히 작동하지 않습니다.

또 다른 이상한 점은 긴 구문 스키마에서 호스트를 설정할 수 없다는 것입니다.

이 동작은 문서에 어떻게 든 문서화되어야합니다.

나는 동의한다; 그 페이지 어딘가에 언급되었다고 생각했지만 찾을 수 없습니다. 문서 저장소에서 문제를 자유롭게여십시오. https://github.com/docker/docker.github.io/issues

현재는 짧은 포트 매핑에서 호스트를 무시합니다. 그리고 조용히 작동하지 않습니다.

어떤 버전의 도커를 사용하고 있습니까? 경고 ( docker stack deploy 사용시) 또는 _error _ ( docker service create 사용시)를 인쇄해야합니다. https://github.com/moby/moby/issues/32299#issuecomment -472793444 참조

어떤 버전의 도커를 사용하고 있습니까? 경고 (도커 스택 배포 사용시) 또는 오류 (도커 서비스 생성 사용시)를 인쇄해야합니다.

어, 내 잘못 인 것 같아요. 콘솔에서 스택을 배포하려고 할 때 실제로 수행합니다.
이전에는 포 테이너 UI를 통해 수행했으며 오류나 경고가 표시되지 않았습니다.

거의 2 년 동안 Docker 개발자 중 일부는 해당 기능이 있어야 할 때 유효하고 매우 유용한 사용 사례 하나를 무시한다는 점에 정말 실망했습니다. . 현재 그 시나리오는 불가능합니다.

실행 가능하고 깨끗한 솔루션은 데이터베이스와 동일한 도커 네트워크에 연결된 두 번째 컨테이너에서 SSH 서버를 실행하는 것입니다. 그런 다음 SSH 포트를 호스트 (물론 22와 다른 포트로)에 게시 할 수 있으므로 SSH 컨테이너를 통해 데이터베이스로 전달할 수 있습니다.

@nartamonov 프로토콜 자체가 안전하지 않으면 수신에서 안전하게 수행 할 수있는 방법을 알 수 없습니다.
안전하게 액세스하는 방법은 암호화 된 데이터 플레인 (과도한 네트워크의 경우 --opt encrypted )을 통해 해당 네트워크에 연결해야하는 도구로 컨테이너를 가동하는 것입니다.

다른 관련없는 부작용이있을 수 있지만 "iptables": false 에서 /etc/docker/daemon.json "iptables": false 를 설정하면 해결 방법으로도 트릭을 사용할 수 있습니다. 덜 극적인 솔루션은

어느 쪽이든 3 년 후에 더 많은 지원을 받고 싶습니다.

이 접근 방식이 도움이 될 수 있습니다 (스웜의 모든 노드에서 실행되어야 함).

1. leave swarm

2. remove network docker_gwbridge

3. recreate network docker_gwbridge with additional option com.docker.network.bridge.host_binding_ipv4=IP

4. join swarm back
   Works for ports published in mode "host". Without mode "host" ingress network is used with other driver and scope "swarm".

안녕하세요.
내가 착각하지 않으면 게시 된 모든 포트가 주어진 기본 IP 주소에 바인딩됩니까? 당신은 단지 몇 가지 서비스 중 일부 포트에 바인딩 된 인터페이스를 제약 조건 싶다면이 가능한 해결되지 않습니다, 분명히합니다.

해결 방법을보고하고 싶습니다.

사용 사례 :
swarm의 일부 서비스는 모든 인터페이스 또는 최소한 공용 인터페이스에서 수신해야합니다.이 컨테이너는 역방향 프록시입니다.
이러한 스웜 노드에는 모든 노드에 데이터베이스 인스턴스가 있으며 다음과 같이 정의 된 스웜 네트워크를 사용합니다.

docker network create --scope swarm NETWORK_NAME --attachable -d overlay

데이터베이스 연결이 필요한 웹 서비스는 물론 해당 NETWORK_NAME 에 조인되어야합니다.

관리 목적으로 때로는 데이터베이스에 직접 연결해야합니다.

해결책:
모든 네트워크에서 노출되어야하는 서비스 (예에서는 역방향 프록시) ports: ['SOMEPORT:ANOTHERPORT'] 서비스 정의에

다른 모든 서비스는 호스트에 쌍을 이루는 docker non-swarm 컨테이너가 있어야합니다.
스웜이 아닌 컨테이너는 NETWORK_NAME/nodeXYZ:port 에있는 포트를 localhost

mongodb의 예 :

docker run --rm -it --net=NETWORK_NAME -d --name expose-mongo -p 127.0.0.1:27017:47017 alpine/socat tcp-listen:47017,fork,reuseaddr tcp-connect:mongo01:27017

단점 : 모든 스웜 노드에 대해 스웜이 아닌 컨테이너가 있어야하므로 많은 노드가있는 경우 ansible / heavy 스크립팅을 채택하지 않는 한 정말 지루합니다.

@ fer2d2가 언급 한 "SSH 터널을 통해 일부 서비스에 연결하는 경우"문제에 대한 내 해결 방법은 다음과 같은 Dockerfile과 함께 ssh 서비스를 추가하는 것입니다.

FROM alpine

RUN apk add --no-cache openssh
RUN mkdir ~/.ssh
RUN ssh-keygen -A
RUN echo "root:root" | chpasswd
RUN echo 'PasswordAuthentication no' >> /etc/ssh/sshd_config
RUN echo 'Port 22' >> /etc/ssh/sshd_config
RUN echo -e " \
Match User root \n\
  AllowTcpForwarding yes\n\
  X11Forwarding no\n\
  AllowAgentForwarding no\n\
  ForceCommand /bin/false\n\
" >> /etc/ssh/sshd_config

EXPOSE 22
CMD /usr/sbin/sshd -D -e "$@"

그런 다음 docker-compose.yml에서 :

...
  db:
    image: mysql:5.6
    environment:
      MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD:?err}
      MYSQL_ROOT_HOST: '%'
    volumes:
      - "./mysql:/var/lib/mysql"
    deploy:
      placement:
        constraints: [node.role == manager]

  sshd:
    image: maxisme/sshd:latest
    volumes:
      - "~/.ssh:/root/.ssh"
    ports:
      - "2223:22"
    deploy:
      placement:
        constraints: [node.role == manager]

내 authorized_keys를 ~/.ssh 폴더에 추가 한 다음 db 호스트 이름을 사용하여 2223 포트를 통해 내 데이터베이스로 ssh 프록시 점프를 할 수 있습니다.

실행 가능하고 깨끗한 솔루션은 데이터베이스와 동일한 도커 네트워크에 연결된 두 번째 컨테이너에서 SSH 서버를 실행하는 것입니다. 그런 다음 SSH 포트를 호스트 (물론 22와 다른 포트로)에 게시 할 수 있으므로 SSH 컨테이너를 통해 데이터베이스로 전달할 수 있습니다.

유효한

이 기능이 중요한 또 다른 예입니다.
plesk가 설치된 서버가 있고 plesk에는 이미 구성이 있지만 docker swarm 서비스를 가리 키기 위해 다른 구성을 추가 할 수 있습니다. 이 plesk 서버는 스웜 노드입니다.
plesk를 사용하여 포트에 proxy_pass하고 싶습니다. 컨테이너가 오버레이 네트워크에 있지만 세계와 통신하려면 외부 포트가 필요하기 때문에이 포트를 게시해야합니다.

따라서 proxypass는 127.0.0.1과 같은 로컬 인터페이스를 가리켜 야합니다. someport
떼의 컨테이너는 로컬 호스트에만 포트를 게시해야합니다.

이러한 방식으로 컨테이너 포트는 프록시 패스를 통해서만 액세스 할 수 있으며 세계에서 직접 액세스 할 수 없습니다.

@maxisme 해결 방법이 authorized_keys 소유권을 어떻게 관리합니까? OS X에서 그것은 나를 위해 작동하지만 (마운트는 root 속합니다) 프로덕션 Linux 시스템에서는 다음을 얻습니다.

Authentication refused: bad ownership or modes for file /root/.ssh/authorized_keys
Connection closed by authenticating user root 85.145.195.174 port 60535 [preauth]

볼륨은 root 가 아닌 호스트 사용자의 UID에 속하며 SSHD는 작업을 거부합니다. 해결 방법 😬의 해결 방법은 다음과 같이 configs 를 사용하는 것입니다.

services:
  sshd:
    image: [...]/sshd:${version}
    configs:
      # FIXME: It would be much better to use a bind volume for this, as it
      # would always be in sync with the host configuration. So revoking a key
      # in the host machine would automatically revoke it in the container. But
      # I can't figure out how to give the volume right ownership. It keeps UID
      # from the host which doesn't align with the container user.
      - source: authorized_keys
        target: /root/.ssh/authorized_keys
        mode: 0600

configs:
  authorized_keys:
    file: ~/.ssh/authorized_keys

컨테이너가 배포 될 호스트를 모르기 때문에 특정 호스트 IP 주소에 바인딩하도록 서비스에 지시 할 수 없다는 사실을 이해합니다.

그러나 종종 호스트에는 북쪽 및 남쪽 경계 인터페이스가 있습니다. 스웜 포트가 모든 스웜 호스트의 노스 바운드 인터페이스에만 바인딩되도록 할 수 있습니다.

서비스를 바인딩하려는 모든 인터페이스의 인터페이스 이름이 동일한 경우 (예 : eth0), swarm 포트를 바인딩 할 인터페이스 이름을 지정하는 옵션을 제공하는 것이 좋습니다 (서비스 포트 섹션에서).

    nginx:
      image: nvbeta/swarm_nginx
      networks:
        - demonet1
      ports:
        - "eth0:8088:80"

swarm 노드에서 eth0을 사용할 수없는 경우 지정된 포트는 어떤 인터페이스에도 바인딩되지 않습니다.

@ tad-lispy 컨테이너 사용자의 uid 및 gid를 호스트의 볼륨 소유자와 동일하게 변경할 수 있어야합니다.
linuxserver 이미지는 환경 변수를 설정하여이를 지원합니다 (https://hub.docker.com/r/linuxserver/openssh-server, User / Group Identifiers ).