Docker의 pool 중복 오류는 VPN 경로 문제가 아니다

Docker는 이 주소 공간에서 pool이 다른 pool과 겹친다는 메시지와 함께 네트워크 생성을 거부하고, 누군가는 VPN 경로가 원인임에 틀림없다고 단정한다. 그럴 수 없다. 이 오류는 pool이 할당되는 동안, 패킷 하나도 존재하기 전에 발생하며, 수동 커널 경로는 그것에 아무런 영향을 주지 않는다. VPN은 한 단계 뒤에 중요해진다. 이미 주소를 가진 컨테이너가 경로가 나타난 뒤 도달할 수 없게 될 때다. 두 문제, 두 가지 증거, 그리고 둘을 섞으면 어느 쪽도 고치지 못하는 변경이 된다.

비슷해 보이는 두 오류

할당 오류는 산술적이다. Docker는 요청한 서브넷을 이미 관리하는 서브넷과 비교해 교집합을 찾고 거부한다. 아직 아무것도 실행되지 않으므로 경로도, 컨테이너도, 조사할 트래픽도 없다.

런타임 증상은 도달 가능성의 문제다. 어제 응답하던 컨테이너가 지금은 응답하지 않고, 호스트의 라우팅 테이블에서 무언가 바뀌었다. 컨테이너는 여전히 자기 주소를 유지한다. 문제는 그 주소가 어느 경로를 택하는가다.

둘 다 주소 계획의 문제다. 그중 하나만 Docker의 문제다.

먼저 할당된 pool을 읽어라

네트워크를 나열하고 교차할 수 있는 것을 살펴라. 서브넷은 IPAM 구성에 있고, 연결된 컨테이너는 따로 나열된다.

docker network ls
docker network inspect EXISTING_NETWORK

그 서브넷을 새 네트워크가 요청하는 pool과 비교하고, Compose가 프로젝트마다 자체 기본 네트워크를 만든다는 점을 기억하라. 잊고 있던 프로젝트와의 충돌은 데몬과의 충돌과 똑같이 보인다.

서비스의 정적 ipv4_address는 한 컨테이너의 주소이며 pool 정의가 아니다. 그것을 바꿔도 중복은 사라지지 않는다. 중복은 컨테이너 사이가 아니라 네트워크 서브넷 사이에서 생기기 때문이다. Docker의 network-create 참조 는 일반 브리지 할당에 겹치지 않는 서브넷을 요구하고, 하나를 명시적으로 고르는 방법을 문서화한다.

VPN을 견디는 프리픽스를 골라라

당면한 충돌과 미래의 경로는 같은 선택으로 결정되니 한 번에 결정하라. 후보 범위를 LAN, 호스트가 도달할 수 있는 모든 VPN 대상, 사용 중인 다른 overlay와 비교하라.

Docker를 만족시키면서 원격 네트워크와 충돌하는 프리픽스는 깨끗하게 시작하고 터널이 올라가는 순간 도달 불가능해지는 컨테이너를 준다. 이것이 이 글의 두 번째 오류이며, 나중에 진단하는 것보다 지금 피하는 편이 훨씬 쉽다.

고른 범위는 다음 프로젝트가 읽을 수 있는 곳에 적어 두라. 할당된 프리픽스의 한 줄 대장은 설명 없는 일주일의 타임아웃보다 싸다.

네트워크를 의도적으로 폐기하거나 변경하라

새 Compose 네트워크라면 네트워크의 IPAM 구성에 사용하지 않는 프리픽스를 설정하라. 기존 프로젝트라면 재번호 매기기를 계획하라. 고정 주소, 의존 서비스, 네트워크 재생성 단계를 모두 고려해야 한다. YAML을 편집해도 실행 중인 네트워크의 번호가 다시 매겨지지 않기 때문이다.

폐기된 네트워크가 충돌하는 할당을 소유한다면, 제거하기 전에 누가 연결되어 있는지 확인하라. docker network rm은 활성 엔드포인트가 있는 동안 거부하고, docker stop은 네트워크 이름이 아니라 컨테이너 이름이나 ID를 받는다. 컨테이너를 멈춰도 pool을 보유한 네트워크 정의는 사라지지 않는다.

광범위한 prune은 진단 도구가 아니다. 무관한 프로젝트까지 닿아, 막 모으려던 증거를 파괴한다.

기본 pool은 다음 할당에만 도움이 된다

데몬의 기본 주소 pool 설정은 예약한 범위 밖에 향후 자동 할당을 유지함으로써 개선한다. 그것은 이미 존재하는 네트워크를 소급해 재주소 지정하지 않으며, 다른 명시적 서브넷과 겹치는 명시적 서브넷도 해결하지 않는다.

그 설정은 자체 재시작을 동반하는 별개의 계획된 변경으로 다루고, 한 프로젝트의 수리의 일부로 삼지 마라. 둘을 섞으면 데몬 재시작이 무관한 조사 한가운데에 떨어진다. 자체 시간 창에 예약하라. 그런 다음 새 자동 할당이 실제로 예약한 범위 밖에 떨어지는지 확인하라.

생성이 성공하면 실제로 실행 중인 서브넷을 검증하고, VPN을 의도한 상태로 둔 채 실제 애플리케이션 요청을 한 번 하라. pool이 유효한데도 접근이 계속 실패한다면 남은 작업은 경로 선택, 필터링, 반환 경로다. 그것은 런타임 조사이며, 할당 오류를 소급해 무의미하게 만들지 않는다.

작업 순서는 할당된 pool을 읽고, Docker와 VPN 대상 둘 다를 피하는 프리픽스를 고르고, 네트워크를 의도적으로 다시 만들고, 터널을 올린 상태에서 요청 하나를 시험하는 것이다.