스택을 새 프로젝트 이름으로 다시 생성한 후 Compose 네트워크 별칭이 더 이상 확인되지 않는 이유는 무엇인가요?

서비스가 다른 프로젝트 범위 네트워크에 연결되거나 별칭이 더 이상 해당 네트워크에 연결되지 않으면, 컨테이너를 다시 만든 후 Compose 별칭이 더 이상 확인되지 않을 수 있습니다.

Docker 별칭은 전역 이름이 아니라 네트워크 범위에 적용됩니다. 스택을 새 디렉터리, 명시적인 프로젝트 이름, Portainer 스택 이름 또는 Compose 프로젝트로 다시 만들면 새 기본 네트워크가 생성될 수 있으며, 다른 앱은 이전 네트워크에 남아 있을 수 있습니다. 서비스는 정상 상태이고 게시된 포트로 접근할 수 있더라도, 호출자와 대상이 더 이상 동일한 네트워크를 공유하지 않거나 리버스 프록시가 다른 네트워크 연결을 선택하면 내부 별칭은 작동하지 않습니다.

이전 및 현재 Compose 프로젝트 이름 비교

이전 및 현재 프로젝트 이름, 작업 디렉터리, 스택 이름, 네트워크 이름과 컨테이너 레이블을 기록합니다. 컨테이너를 다시 만든 후 호출자 서비스와 대상 서비스를 비교합니다.

Docker Compose는 프로젝트 이름을 사용해 리소스를 그룹화하고 이름을 지정합니다. 프로젝트 이름 우선순위를 확인하면 디렉터리나 배포 이름을 변경할 때 기존 프로젝트 네트워크를 재사용하는 대신 새 네트워크가 생성될 수 있는 이유를 알 수 있습니다.

호출자가 oldproject_default에 연결된 상태로 남아 있고 대상이 newproject_default에 연결되면, 기존 별칭에는 공유 DNS 범위가 없습니다.

정확히 공유되는 네트워크에서 별칭 확인

두 컨테이너를 검사하고 연결된 모든 네트워크, 엔드포인트, IPv4 또는 IPv6 주소와 별칭을 나열합니다. 호출자 컨테이너 내부에서 DNS를 테스트합니다.

Compose 사양에서는 별칭을 네트워크 범위 이름으로 정의하므로, 한 네트워크에 선언된 별칭이 다른 네트워크 연결에 자동으로 존재하지는 않습니다.

서비스가 실제로 공유하는 네트워크에 별칭 선언을 배치합니다. 신중하게 구성한 서비스 검색을 대신하기 위해 container_name에 의존하지 마세요.

외부 네트워크 이름 및 배포 변수 확인

논리적인 Compose 네트워크 키와 명시적인 외부 name을 비교합니다. 배포 중 사용되는 환경 변수 치환과 스택 UI 변수를 확인합니다.

Portainer 문서에서는 스택이 기존 Docker 네트워크를 사용할 수 있다고 설명합니다. 독립적으로 배포된 스택이 서로를 확인해야 하는 경우 동일한 네트워크를 일관되게 선택해야 합니다.

모든 스택이 실제로 동일한 네트워크 이름을 참조할 때에만 외부 네트워크가 프로젝트 접두사 변경을 방지합니다. 오타가 있으면 서비스의 게시된 포트를 변경하지 않고도 다른 네트워크를 생성하거나 선택할 수 있습니다.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

호출자가 캐시된 주소가 아닌 Docker DNS를 사용하는지 확인

호출자에서 새로 조회를 실행하고, 리졸버 구성을 검사한 다음 필요한 경우 DNS를 캐시하는 프로세스만 다시 시작합니다. 이름 확인 결과를 직접적인 서비스 이름 조회 결과와 비교합니다.

Linux 네트워크 네임스페이스 모델은 네트워크 리소스를 격리하므로, 호스트에서 DNS가 성공했다고 해서 호출자 컨테이너가 대상 컨테이너의 Docker 네트워크를 공유한다는 뜻은 아닙니다.

대상의 현재 컨테이너 IP를 /etc/hosts에 추가하지 마세요. 컨테이너를 다시 만들면 다른 주소가 할당될 수 있어 또 다른 오래된 종속성이 남게 됩니다.

리버스 프록시가 사용하는 네트워크 확인

프록시와 애플리케이션의 네트워크 연결, 프로바이더 레이블 및 백엔드 라우팅에 선택된 네트워크를 검사합니다. 프록시 컨테이너에서 별칭을 테스트합니다.

Traefik의 Docker 프로바이더는 백엔드 연결에 사용할 Docker 네트워크를 지정할 수 있습니다.

프록시가 여러 네트워크에 연결되어 있으면 컨테이너를 다시 만든 후 자동 선택 결과가 달라질 수 있습니다. 의도한 공유 네트워크를 명시적으로 설정하고 실제 이름을 안정적으로 유지하세요.

잘못된 네트워크를 삭제하지 않고 오래된 엔드포인트 제거

이전 네트워크와 새 네트워크에 연결된 컨테이너를 나열합니다. 고아 엔드포인트, 중지된 컨테이너와 이전 프로젝트 네트워크에 여전히 의존하는 활성 서비스를 식별합니다.

Red Hat의 컨테이너 네트워킹 가이드에서는 사용자 정의 컨테이너 네트워크 연결을 애플리케이션 파일 내용이 아니라 컨테이너 런타임 상태의 일부로 설명합니다.

활성 스택에서 사용하지 않는다는 사실을 확인한 후에만 이전 네트워크를 제거합니다. 두 네트워크를 모두 삭제하고 모든 항목을 한꺼번에 다시 만들면 어떤 연결이 잘못되었는지 보여 주는 증거가 사라집니다.

서비스 하나를 다시 만들고 모든 호출자에서 DNS 확인

프로젝트 이름 또는 외부 네트워크를 표준화하고 영향을 받은 서비스만 다시 만든 다음, 각 종속 컨테이너에서 서비스 이름과 별칭을 테스트합니다.

ZimaSpace의 컨테이너 런타임 종속성 문서에서는 인접한 원칙을 설명합니다. 호스트 수준의 연결 테스트만으로는 컨테이너의 네임스페이스와 서비스 검색 경로를 검증할 수 없습니다.

스택을 다시 만들고 재부팅한 후, 하드코딩된 IP 주소 없이 의도한 모든 호출자에서 별칭이 현재 엔드포인트로 확인되면 문제가 해결된 것입니다.

자주 묻는 질문

Docker 네트워크 별칭은 전역으로 적용되나요?

아니요. 별칭은 구성된 네트워크에만 존재하며 해당 네트워크를 공유하는 컨테이너만 사용할 수 있습니다.

Compose 폴더 이름을 변경하면 DNS가 손상될 수 있나요?

예. 폴더 이름은 기본 프로젝트 이름에 영향을 줄 수 있으며, 프로젝트 이름이나 외부 네트워크 이름을 고정하지 않으면 생성되는 네트워크 이름에도 영향을 줍니다.

DNS를 안정적으로 유지하려면 container_name을 사용해야 하나요?

대부분의 경우 그렇지 않습니다. 안정적인 서비스 이름과 명시적인 공유 네트워크를 사용하면 Compose 확장 기능을 유지하고 전역 이름 충돌을 방지할 수 있습니다.