마이크로서비스가 시작되면 자동으로 IP와 포트를 서비스 등록 센터에 보고합니다. 하지만 서비스는 도커 컨테이너에서 실행되며, 등록된 IP는 172로 시작하는 도커 내부 IP가 됩니다. 이 주소는 다른 머신에서 접근할 수 없습니다.
이 경우 서비스 등록 주소를 호스트의 주소와 포트로 수동으로 변경해야 하나요?
----- 업데이트 -----
Docker 버전 1.12 이후에는 엔진에 스웜 모드가 있습니다. 테스트 후 스웜 오버레이 네트워크를 사용하면 호스트 간 통신 문제를 해결할 수 있습니다. 적합할까요?
docker swarm이 제공하는 오버레이 네트워크는 호스트 간에 컨테이너 내 네트워크 통신을 제공할 수 있습니다. 로컬 컨테이너는 시작 시 네트워크를 지정하여 내부 네트워크를 형성할 수 있습니다. 그러면 etcd를 사용하여 nginx를 swarm 호스트에 호스트 모드로 배포할 수 있습니다. 및 consul 동적 서비스 검색의 목적을 달성하기 위해 동적으로 서비스를 등록하고 nginx의 역방향 프록시 구성을 업데이트할 때까지 기다립니다.
그러나 오버레이는 현재 모든 호스트 간 통신 방법 중 성능 손실이 60%에 달해 가장 큰 성능 손실을 보이고 있습니다. 누군가 인터넷에서 테스트를 했으니 확인해 보세요. 따라서 현재로서는 프로덕션 환경에서는 여전히 쿠버네티스나 메소스를 고려해야 합니다
저는 네트워킹에 대해 잘 모릅니다. Google Docker 교차 호스트 통신을 통해 몇 가지 해결책을 찾아보세요.
호스트를 사용하여 내부 DNS 추가
여러 가지 아이디어가 있습니다.
1. 서비스 시작 시 호스트 장치가 IP를 보고합니다
2. 서비스 시작 시 호스트 IP 정보를 컨테이너 환경 변수에 삽입합니다
3. 요청을 등록할 때 네트워크 계층에서 IP를 가져옵니다
컨테이너는 동적이기 때문에 IP 주소는 일반적으로 무작위로 할당됩니다. 컨테이너 스케줄링 시스템을 사용하여 일부 컨테이너를 자동으로 시작한 후 서비스 등록을 통해 이러한 컨테이너의 액세스 주소를 서비스 등록 센터에 기록할 수 있습니다. 이러한 방식으로 외부 서비스가 이러한 컨테이너에 액세스하려는 경우 서비스 검색을 통해 이러한 컨테이너에 액세스할 수 있습니다
매우 간단하고 다양한 크로스 호스트 도커 네트워크 통신 솔루션입니다.
Kubernetes는 플란넬을 사용합니다.
다른 방법을 고려해 볼 수도 있습니다
1. kubernetes와 같은 서비스 조정 도구 사용(docker에 상당한 변경)
2. consul과 같은 등록 센터 사용(등록 센터 코드에 상당한 변경)
마이크로서비스가 spring cloud를 사용한다면 이 문제를 완벽하게 해결할 수 있는 두 번째 옵션을 더 권장합니다