network_mode: service:vpn와 사라진 db 호스트 이름

VPN 네임스페이스를 공유하는 것은 토폴로지 선택입니다. db가 자기 주소를 유지하고 vpn이 그 네트워크에 합류하거나, 아니면 모든 것이 loopback에서 응답합니다.

앱에 network_mode: service:vpn을 추가하고 스택을 다시 시작하면 db이 더 이상 확인되지 않아 앱이 죽습니다. compose 파일에서 이름이 바뀐 것은 없으므로 뻔한 용의자는 DNS와 데이터베이스입니다. 실제 변화는 더 작고 이상한데, 앱이 그 이름이 존재하는 Compose 네트워크의 구성원이기를 그만둔 것입니다. 데이터베이스가 어느 네임스페이스에서 응답해야 하는지 결정하기 전까지는 모든 호스트 이름 수정이 추측입니다.

db 호스트 이름이 더 이상 확인되지 않는 이유

network_mode을 사용하는 서비스는 Compose 네트워크에서 자체 주소가 없고 지정한 서비스의 네임스페이스를 빌려옵니다. 그 네임스페이스는 자체 인터페이스, 경로, 포트 공간, 리졸버를 가져오며 앱의 backend 네트워크 연결을 대체합니다. db이라는 이름은 결코 추상적이지 않았고, 그 네트워크에 존재하며 내장 DNS를 통해 확인되었습니다. 연결을 제거하면 이름이 확인될 곳이 없습니다.

호스트가 아니라 컨테이너 안에서 확인하십시오. 앱에서는 실패하지만 데이터베이스 컨테이너에서는 성공하는 조회라면 이름은 정상이고 구성원 자격이 잘못된 것입니다. 그 결과는 수정 위치를 앱의 리졸버 설정이 아니라 compose 토폴로지로 옮깁니다.

파일을 편집하기 전의 세 가지 질문

각 질문이 토폴로지를 좁히므로 순서대로 답하십시오. 데이터베이스는 무엇에 응답해야 합니까, 다른 컨테이너가 쓰는 호스트 이름입니까, 아니면 loopback의 앱뿐입니까. 앱이 호스트로 포트를 게시해야 합니까, 그렇다면 어느 서비스가 소유합니까. 데이터베이스는 호스트나 다른 머신에서 접근 가능해야 합니까, 아니면 터널 내부에서만 가능합니까.

데이터베이스에 자체 이름이 필요하고 앱이 아무것도 게시하지 않는다면 별도의 연결에 두십시오. 앱이 포트를 게시해야 하고 모든 것이 터널을 통과한다면 데이터베이스를 VPN 네임스페이스에 넣고 loopback을 사용하십시오. 둘을 섞으면 깔끔하게 시작하고 연결 시점에 실패하는 스택이 됩니다.

데이터베이스는 있는 자리에 두십시오

더 작은 변경은 네임스페이스 소유자를 이미 데이터베이스가 있는 네트워크에 연결합니다. 앱은 vpn 스택을 공유하므로 그 연결을 물려받고, db은 이전과 똑같이 확인됩니다.

services:
  vpn:
    networks:
      - backend
  app:
    network_mode: service:vpn
  db:
    networks:
      - backend
networks:
  backend:

앱에 networks도 추가하지 마십시오. Compose는 같은 서비스에서 network_mode과 함께 그 속성을 거부하며, 오류는 그 조합이 아니라 파일을 가리킵니다. VPN 클라이언트가 자기 네임스페이스 안에서 backend 대상을 필터링한다면, 공유 연결이 경로를 제공하더라도 그 필터를 무효화하지 않으므로 지원되는 로컬 네트워크 정책도 조정하십시오.

데이터베이스를 네임스페이스로 옮기십시오

더 큰 변경은 데이터베이스를 같은 네임스페이스에 두고 앱을 실제 포트로 127.0.0.1을 가리키게 합니다. 서로 다른 컨테이너에서 시작했다는 이유만으로 두 프로세스가 같은 주소와 포트를 함께 바인딩할 수는 없으므로, wildcard 주소에서도 수신하는 데이터베이스는 그렇게 하는 다른 무엇과 충돌합니다. 옮기기 전에 수신자를 확인하십시오.

게시된 포트는 네임스페이스를 소유한 서비스에 속합니다. 앱에 ports을 추가하는 것은 network_mode과 함께 거부되며, 별도의 앱 주소를 만들어내는 것은 존재하지 않는 인터페이스를 설명하는 것입니다.

준비 상태, 차단, 리졸버

depends_on은 컨테이너 시작 순서를 정할 뿐, 터널이 살아 있다는 증거가 아니며 터널이 끊길 때 트래픽을 막지도 않습니다. 도달 가능성, 터널 준비 상태, 장애 차단을 세 가지 별개의 요구 사항으로 다루십시오. 첫 번째만 충족하는 스택은 좋은 날에는 수동 테스트를 통과하고 나쁜 날에는 누출됩니다. 세 답을 compose 파일 옆, 다음 사람이 볼 곳에 적어 두십시오.

네임스페이스 공유는 앱이 VPN 컨테이너의 리졸버를 물려받는다는 뜻이기도 하며, 터널이 DNS 서버를 밀어 넣을 때는 도움이 되고 그렇지 않을 때는 혼란을 줍니다. 호스트 리졸버가 적용된다고 가정하지 말고 네임스페이스에 실제로 무엇이 있는지 확인하십시오. Compose 서비스 참조는 network_mode, ports, 의존성 동작을 한곳에 문서화하며 network_mode 서비스에 자체 주소가 없는 이유도 설명합니다.

관련 글