리버스 프록시 백엔드용 전용 Docker 네트워크 설정 방법

에바 왕

IceWhale author

에바 왕 는 기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

How to Set Up a Dedicated Docker Network for Reverse-Proxy Backends - Zima Store Online

리버스 프록시와 각 HTTP 백엔드를 하나의 공유 사용자 정의 네트워크에 연결하고, 데이터베이스는 비공개 앱 네트워크에 유지하세요.

프록시가 사용자 정의 브리지에서 Compose 서비스 이름을 확인할 수 있다면 모든 백엔드 포트를 NAS 호스트에 게시할 필요가 없습니다. 두 네트워크 패턴을 사용하면 프록시가 웹 백엔드로 이동하는 경로를 제어하면서 데이터베이스는 해당 애플리케이션에서만 연결할 수 있습니다. 네트워크 소유권을 정의하고, 모호한 별칭을 피하며, 어떤 서비스에 아웃바운드 액세스가 필요한지 결정하고, 호스트 포트가 닫힌 상태인지 확인하세요.

의도한 연결 가능성 매트릭스 작성

모든 연결을 나열하세요. 클라이언트에서 프록시로, 프록시에서 백엔드로, 백엔드에서 데이터베이스로, 백엔드에서 외부 API로, 관리자에서 유지 관리 엔드포인트로의 연결을 포함합니다. 프로토콜, 포트, DNS 이름, 그리고 경로가 호스트를 통과하는지 표시하세요.

일반적으로 포트 80과 443을 게시해야 하는 것은 리버스 프록시뿐입니다. 백엔드는 호스트 ports 매핑 없이 Docker 네트워크에 애플리케이션 포트를 노출합니다. 명시적인 관리 경로가 필요한 경우가 아니라면 데이터베이스는 앱 비공개 네트워크에만 연결하세요.

안정적이고 고유한 서비스 이름 또는 네트워크 별칭을 선택하세요. Docker DNS는 공유 사용자 정의 네트워크에서 서비스를 확인하지만, 여러 Compose 프로젝트가 동일한 프록시 네트워크에 연결될 때 web 같은 일반적인 별칭은 충돌할 수 있습니다.

공유 프록시 네트워크와 비공개 앱 네트워크 생성

프록시 네트워크를 한 번 생성하고 각 애플리케이션 프로젝트에서 외부 네트워크로 표시한 다음, 프록시와 의도한 백엔드를 연결하세요. 이렇게 하면 개별 Compose 프로젝트를 다시 생성해도 네트워크 ID가 안정적으로 유지됩니다.

각 앱에 대해 별도의 기본 네트워크 또는 이름이 지정된 비공개 네트워크를 정의하고 백엔드와 데이터베이스를 연결하세요. 백엔드는 프록시 트래픽과 비공개 상태 사이를 제어하는 브리지가 됩니다. 프록시는 데이터베이스 네트워크에 연결하지 않아야 합니다.

Compose 네트워크 정의 문서에서는 Compose의 외부 네트워크와 서비스 연결을 설명합니다. 외부 네트워크는 앱 스택 외부에서 수명 주기를 관리하는 것으로 간주하세요. 배포 시 Compose가 네트워크를 생성하거나 삭제할 것이라고 가정하지 말고 네트워크가 존재하는지 확인해야 합니다.

networks:
  proxy:
    external: true
  app-private:
    internal: true
services:
  web:
    networks: [proxy, app-private]
  db:
    networks: [app-private]

불필요한 호스트 포트 제거 및 이그레스 검토

프록시 경로가 작동하면 백엔드의 호스트 포트 게시를 제거하세요. expose 선언은 컨테이너 포트를 문서화할 수 있지만 방화벽은 아닙니다. 어떤 컨테이너가 연결할 수 있는지는 네트워크 소속에 따라 결정됩니다.

구성원이 실제로 외부 경로를 필요로 하지 않는 네트워크에만 internal: true 사용을 고려하세요. ID 공급자, 웹훅, 패키지 서비스 또는 원격 API를 호출하는 백엔드는 내부 전용 네트워크에서 작동하지 않을 수 있습니다. 애플리케이션 설계상 필요한 경우 이그레스가 가능한 두 번째 네트워크를 사용하세요.

자동 프록시 검색에 사용되는 Docker 소켓을 보호하세요. 읽기 전용 바인드 마운트는 실수로 인한 쓰기를 줄이지만 소켓을 안전하게 만들지는 않습니다. 제한된 소켓 프록시 또는 정적 구성이 더 좁은 제어 범위를 제공합니다.

-15% OFF

ZimaBoard 2 - 당신의 큰 아이디어를 위한 미니 홈 서버

Single board computer zimaboard2

서비스 DNS, 포트 노출 및 격리 확인

프록시 컨테이너에서 백엔드 서비스 이름을 확인하고 컨테이너 포트의 상태 엔드포인트에 요청을 보내세요. 관련 없는 컨테이너에서 해당 컨테이너가 의도적으로 프록시 네트워크에 연결된 경우가 아니라면 이름 또는 연결을 사용할 수 없는지 확인하세요.

다른 LAN 장치에서 NAS 호스트를 스캔하여 프록시 포트만 열려 있는지 확인하세요. 그런 다음 공용 호스트 이름을 통해 TLS, 전달된 헤더, WebSocket 업그레이드, 대용량 업로드 및 애플리케이션 리디렉션을 테스트하세요. 홈 서버 서비스 맵에는 홈 서버의 서비스 맵 일부로 프록시 네트워크가 기록되어 있어야 합니다.

진단을 위해서만 이전 포트 매핑을 복원하고, 영구적인 숨은 종속성으로 사용하지 마세요. 프록시에 데이터베이스에 대한 직접 액세스가 필요하거나, 별칭이 잘못된 프로젝트로 라우팅되거나, 호스트 포트를 제거했을 때 문서화되지 않은 통합이 중단되면 중지하세요.