Docker 기본 풀 변경은 네트워크 번호를 다시 매기지 않습니다

default-address-pools를 바꾼다고 이미 있는 네트워크의 번호가 다시 매겨지지는 않으며, 그렇게 기대하는 것이야말로 신중한 계획을 갑작스러운 장애로 바꾸는 길입니다. 이 설정은 데몬이 새 구성으로 다시 시작된 뒤에 만들어지는 네트워크의 자동 할당을 관장합니다. 이미 실행 중인 모든 것은 그 서브넷이 네트워크의 저장된 정의 일부이기 때문에 부여받은 서브넷을 유지합니다. 이 속설이 편리한 이유는 한 번의 수정으로 모든 중복이 해결된다고 암시하기 때문이고, 실제로는 정말로 비어 있는 대역을 고른 뒤 비어 있지 않은 네트워크를 이전하는 두 단계 작업입니다.

속설: 풀을 한 번 바꾸면 중복이 해결된다

속설에는 특정한 모양이 있습니다. 누군가 Docker의 기본 풀을 바꿀 수 있다는 글을 읽고 그것을 바꾸고 데몬을 다시 시작한 뒤 컨테이너 네트워크가 더 이상 사무실 VPN과 충돌하지 않는다고 결론짓습니다. 예전 네트워크는 여전히 남아 있고, 여전히 연결되어 있으며, 충돌하는 주소를 여전히 들고 있습니다.

달라진 것은 할당기의 앞으로의 동작이며, 그것은 정말로 유용하고 정말로 제한적입니다. 명시적 --subnet 없이 만든 새 네트워크는 새 풀에서 잘려 나오지만, 기존 네트워크는 애초에 그 풀에 있지 않았습니다. 재시작은 네트워크를 다시 만들지 않고 컨테이너를 그 사이로 옮기지도 않습니다. 변경 뒤에도 증상이 남는다면 변경은 실제로 적용된 것이고 진단이 불완전했던 것입니다.

기본 대역과 할당 접두사

구성에는 혼동하기 쉬운 두 필드가 있습니다. base는 할당기가 잘라 내는 대역이고, size는 할당되는 각 네트워크의 접두사 길이여서 10.10.0.0/16 기반에 크기 24를 주면 그 /16 안에서 /24를 나눠 줍니다. 역할을 뒤집으면 의도하지 않은 할당 패턴이 생기며, 보통 하나의 거대한 네트워크나 고갈된 풀이 됩니다.

풀은 예약이지 증명이 아닙니다. Docker는 호스트 라우팅 테이블에서 보이는 충돌은 피하지만, 아직 연결하지 않은 VPN은 볼 수 없습니다.

그 한계가 의도적으로 고르는 이유의 전부입니다. 비교할 대역은 호스트가 도달해야 하는 대역으로, 사무실 LAN, 기업 VPN의 내부 서브넷, 랩이나 스테이징 접두사, 그리고 같은 오버레이에 있는 다른 컨테이너 호스트입니다. 머릿속 목록은 중요한 하나를 반드시 빠뜨리므로 데몬을 건드리기 전에 CIDR로 적어 두십시오. 그다음 어느 것과도 겹치지 않는 기반을 고르고, 목록을 배포와 함께 보관해 다음 사람이 기억으로 같은 작업을 반복하지 않게 하십시오.

고르기 전에 목록을 만드십시오

먼저 있는 것을 목록으로 만드십시오. docker network ls는 네트워크를 나열하고, docker network inspect bridge -f '{{.IPAM.Config}}'는 특정 네트워크가 쓰는 서브넷을 출력합니다. Compose 프로젝트는 자기 네트워크를 만들고 compose 파일의 명시적 --subnet은 풀을 완전히 우회하므로 사용자 정의 네트워크마다 반복하십시오.

그 마지막 지점이 이전 뒤에도 살아남습니다. 풀을 바꿔도 동료가 compose 파일에 172.18.0.0/16을 고정하는 것을 막지 못하며, 충돌은 다른 작성자와 함께 돌아옵니다.

이미 있는 것을 이전하기

기존 네트워크를 이전하는 것은 별개의 지원되는 작업입니다. 영향을 받는 각 네트워크는 새 서브넷으로 다시 만들어야 하며, 그것은 그 네트워크를 쓰는 컨테이너를 분리했다가 다시 연결한다는 뜻이고, 네트워크를 다시 만들면 컨테이너 연결이 옮겨지는 것이 아니라 제거됩니다. 볼륨과 구성을 보존하고, 다시 만드는 일을 데이터 초기화가 아니라 배포로 다루십시오. 다시 만든 네트워크의 컨테이너는 계획했든 아니든 다시 시작되므로 작업은 유지보수 창에서 하십시오.

문서화된 데몬 구성과 재시작 절차를 따르고 중단을 조율하십시오. 데몬이 하나인 호스트에서 systemctl restart docker는 재시작 정책에 따라 컨테이너를 다시 시작하며, 이는 나중이 아니라 미리 알아 둘 만한 동작입니다.

그다음 변경이 고쳐야 했던 두 가지를 검증하십시오. docker network inspect로 새 서브넷을 살펴 선택한 기반 안에 있는지 확인하고, 이어서 ip route get 10.20.30.40으로 대표적인 VPN 목적지로 가는 경로를 확인해 브리지가 아니라 기대한 곳으로 가는지 확인하십시오. 다른 주소 체계로 다시 만든 네트워크는 애플리케이션 버그처럼 보이는 방식으로 이름 해석을 깨뜨릴 수 있으므로 서비스 검색과 컨테이너 간 통신도 시험하십시오.

그 뒤에도 깨지는 것

오래 남는 것은 기록입니다. 할당 목록, 고른 기반과 크기, 다시 만든 네트워크를 배포와 같은 곳에 보관하십시오.

대역이 사설이라고 해서 재사용이 안전해지는 것은 아닙니다. 10.0.0.0/8은 사설이면서 동시에 경로 어딘가에서 이미 쓰이고 있을 가능성이 가장 큰 대역이므로, 답은 한 블록에 대한 선호가 아니라 구체적인 예약입니다. Docker 네트워크 문서는 자동 서브넷 할당과 풀 필드를 설명합니다. 대역은 단정해 보이는지가 아니라 도달해야 하는 대상에 따라 고르십시오.