VPN 설정은 컨테이너를 다시 만들 때 마운트한 경우에만 살아남습니다

실행 중인 컨테이너 안에서 WireGuard 설정을 편집하고 잘 동작해도, 다음 이미지 업데이트가 그것을 지웁니다. 설정이 잘못된 것은 아니었습니다. 그 파일은 컨테이너의 쓰기 가능 계층에 있었고, 그 계층은 해당 컨테이너 인스턴스에만 존재합니다. 중요한 비교는 어떤 도구를 쓰느냐가 아니라, 배포가 어떤 입력을 선언하느냐입니다. 직접 편집한 모든 것은 배포가 모르는 입력입니다.

두 가지 상태, 하나는 일회용

컨테이너에는 런타임 변경을 위한 쓰기 가능 계층이 있고, 그 계층은 컨테이너가 교체될 때 버려집니다. 그것은 설정 저장소도 아니고 백업도 아닙니다. 이미지와 선언된 입력이 실행되는 것의 전체 정의입니다.

VPN 파일 중 무엇이 선언된 입력이고 무엇이 우연인지 물어보세요:

docker diff wg-vpn
docker inspect --format '{{json .Mounts}}' wg-vpn

diff는 쓰기 가능 계층에서 무엇이 바뀌었는지 나열하고, 그것은 정확히 사라질 것들의 집합입니다. 마운트 목록은 무엇이 남는지 보여 줍니다. 둘을 비교하면 무언가를 잃기 전에 답이 나옵니다.

bind 마운트, 이름 있는 볼륨, 시크릿: 각각이 지키는 것

셋 모두 VPN 프로필을 담을 수 있고, 누가 읽을 수 있는지와 교체 시 무슨 일이 일어나는지가 다릅니다.

bind 마운트는 호스트 경로를 대응시키므로, 파일은 그 경로만큼 보호되고 호스트 권한이 허용하는 만큼 보입니다. 이름 있는 볼륨은 런타임이 관리하고 컨테이너를 제거해도 남으므로, 배포가 소유한 상태에 더 안전한 기본값이 됩니다. 시크릿 메커니즘은 이미지나 환경 변수에 두고 싶지 않은 자료를 위한 것입니다.

모든 환경 변수와 호스트 파일은 동등한 보호가 아니므로 그렇게 취급하지 마세요.

컨테이너 안에서 편집하는 것이 함정

함정은 도구가 아니라 편집의 방향입니다. 실행 중인 컨테이너 안에서 한 변경은 배포에 보이지 않으므로, 다음 재생성은 그것을 조용히 되돌리고 증상은 이미지의 회귀처럼 보입니다. 진단을 위해 거기서 변경해야 한다면 즉시 밖으로 복사해 선언된 입력에 넣으세요. 그런 다음 배포가 그것을 재현한다는 것을 증명하기 위해 다시 만드세요.

프로필은 개인 키와 계정 자료를 담을 수 있어, 그 파일의 백업은 파일 복사가 아니라 비밀 취급 작업이 됩니다. 소유권과 읽기 접근을 컨테이너의 실제 프로세스로 제한하고, 권한 오류를 없애려고 호스트 디렉터리를 넓히지 마세요.

그 확장이 컨테이너의 편의를 호스트의 노출로 바꾸는 길입니다.

의도적으로 다시 만들고, 그다음 네 가지를 확인하세요

이미지 버전, 필요한 장치와 기능, 네트워크 연결, 영속 입력을 기록하세요. 장치와 기능 목록은 VPN 컨테이너에 특히 중요합니다. 터널에는 네트워크 장치와 그것을 설정할 권한이 필요하기 때문입니다.

생성된 런타임 상태 중 저장이 아니라 재구성해야 할 것을 확인하세요. 터널이 첫 시작 때 생성한 키는 상태이며, 그것을 유지할지 다시 생성할지는 이전 공개 키를 아는 모든 피어에 영향을 주는 결정입니다.

통제된 재생성 후 아이덴티티, 라우팅, DNS, 필요한 실패 차단을 확인하세요. 오류 없이 시작하는 프로세스는 그 네 가지 중 어느 것도 증명하지 않습니다. 터널이 올라와 있을 때 확인하고, 멈춘 뒤 다시 확인하세요. 실패 차단은 터널이 사라질 때만 드러나기 때문입니다.

컨테이너 밖에 복구 사본을 두세요

컨테이너와 독립적으로 존재하는 복구 사본을 두고, 문서화된 절차로 복원을 시험하세요. 시험하지 않은 VPN 프로필 백업은 희망일 뿐이며, 특히 복원 경로가 컨테이너 프로세스에 필요한 권한을 포함할 때 그렇습니다.

VPN을 소유한 컨테이너가 교체되면, 그 네트워크 스택을 공유하는 애플리케이션을 런타임이 지원하는 수명 주기 안에서 조정하세요.

그 조정이 재시작과 중단의 차이입니다. 배포는 설정이 어디서 오는지 설명해야 하고, 볼륨 문서는 런타임이 실제로 무엇을 영속화하는지 확인하는 곳입니다.