두 홈 서버 간 Docker 이름 지정 볼륨 마이그레이션 워크플로우

에바 왕 는 기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

안전한 접근 방식은 일시 중지된 아카이브 또는 명확히 식별된 대상 볼륨으로 동기화된 복사본을 만든 뒤 체크섬과 애플리케이션 검증을 수행하는 과정을 단일 명령이 아닌 관찰 가능한 게이트의 연속으로 취급하는 것입니다.

Docker Compose를 실행하는 두 대의 Linux 홈 서버에서는 실행 중이거나 잘못된 이름의 볼륨을 복사하지 않고 상태 저장 컨테이너를 다른 호스트로 이동해야 한다는 점이 실질적인 위험입니다. 현재 식별 정보와 복구 지점을 기록하고, 가장 덜 침습적인 판별부터 시작하며, 다른 변수를 변경하기 전에 통과 및 실패 결과를 해석하고, 스토리지가 불안정해지거나 복구 가능한 유일한 복사본이 노출될 상황에서는 중단하세요. 아래 워크플로는 원래 워크로드가 성공하거나 증거가 에스컬레이션 경계에 도달한 후에만 끝납니다.

소스 및 대상 볼륨 계약 식별

소스 컨테이너 이미지 다이제스트, Compose 프로젝트 이름, 서비스, 볼륨 키, 실제 Docker 볼륨 이름, 마운트 대상, 볼륨 드라이버 및 애플리케이션 버전을 기록하세요. docker inspect 및 docker volume inspect를 사용하고, YAML 레이블만으로 실제 물리적 경로를 추정하지 마세요.

Compose는 일반적으로 프로젝트 이름을 명명된 볼륨 앞에 붙입니다. 단, 명시적 이름이나 외부 볼륨을 사용하는 경우는 예외입니다. 대상에서는 Compose 구성을 렌더링하고 의도한 빈 볼륨을 명시적으로 생성하여, 마이그레이션 데이터가 한 볼륨에 들어간 동안 서비스가 다른 볼륨을 시작하는 일이 없도록 하세요.

볼륨에 데이터베이스가 포함되어 있다면 기본적으로 데이터베이스의 네이티브 덤프 또는 지원되는 백업을 이식 가능한 주요 복구 경로로 사용하고, 볼륨 복사본은 동일한 버전에서의 복구 지점으로 취급하세요. 드라이버가 원격이거나, 소스 스토리지가 불안정하거나, 범위에 포함되지 않은 추가 볼륨에 애플리케이션 상태가 분산되어 있다면 중단하세요.

쓰기 작업 일시 중지 및 메타데이터 보존 복사본 생성

애플리케이션을 유지 관리 모드로 전환하고 백그라운드 작업을 중지한 다음 애플리케이션과 데이터베이스를 정상적으로 중지하세요. 어떤 컨테이너도 해당 볼륨을 읽기-쓰기로 마운트하지 않는지 확인하세요. 임시 컨테이너를 통해 아카이브를 생성하거나 숫자 소유권, 권한, 심볼릭 링크, 필요한 경우 확장 속성 및 스파스 파일을 보존하는 제어된 파일 시스템 복사를 사용하세요.

rsync를 사용한 Docker 볼륨 마이그레이션에 관한 독립 가이드는 rsync로 Docker 볼륨 데이터를 이동하는 방법을 보여 줍니다. 중요한 경계는 소스가 일시 중지된 상태여야 하며, 복사 명령은 데몬이 사용 중인 Docker 내부 디렉터리를 맹목적으로 조작하는 것이 아니라 식별된 볼륨 콘텐츠에서 작동해야 한다는 점입니다.

파일 수, 총 바이트 수, 대표 해시 및 아카이브 체크섬이 포함된 매니페스트를 생성하세요. 소스 볼륨과 네이티브 백업은 변경하지 않고 보관하며, 전송 아티팩트가 대상 호스트에서 읽을 수 있을 때만 복사 단계를 통과한 것으로 간주하세요.

명시적 대상 볼륨으로 복원

대상 파일 시스템 용량, inode 가용성, UID 및 GID 요구 사항, 동일한 애플리케이션 이미지 버전을 확인하세요. 최상위 디렉터리 구조를 평탄화하지 않고 빈 대상 볼륨에 아카이브를 복원한 다음 소유권, 개수, 크기 및 선택한 해시를 비교하세요.

명명된 볼륨 마이그레이션 실패 사례에 관한 커뮤니티 토론은 Docker 볼륨 내부에서 파일을 직접 교체할 경우 실패하거나 혼란스러운 상태가 남을 수 있는 이유를 보여 줍니다. 런타임을 사용해 볼륨을 헬퍼 컨테이너에 마운트하고 해당 제어된 인터페이스를 통해 복원하세요.

먼저 대체 포트를 사용하고 프로덕션 피어에 접근하지 않는 폐기 가능한 서비스 복사본만 연결하세요. 애플리케이션에서 스키마 업그레이드나 손상된 상태를 보고하면 중단하고, 버전 호환성 문제를 해결한 후 변경하지 않은 아티팩트에서 볼륨을 다시 복원하세요.

전환 및 롤백 호스트 유지

애플리케이션보다 먼저 종속 서비스를 시작하고, 로그, 로그인, 최근 레코드, 첨부 파일, 예약 작업 및 폐기 가능한 쓰기 작업을 확인하세요. 대상 스택을 다시 시작하고 동일한 이름의 볼륨이 다시 연결되는지 확인하세요. 이러한 검사가 통과한 후에만 프록시 또는 DNS를 업데이트하세요.

일관된 컨테이너 데이터 백업에 관한 관련 ZimaSpace 문서는 복사에 성공했는데도 대상이 비어 있는 상태로 시작하는 경우에 도움이 됩니다. 데이터를 다시 복사하기 전에 런타임 마운트 소스와 의도한 볼륨을 비교하세요. 잘못된 대상에 반복해서 복사하면 혼란만 커집니다.

대상에서 새 백업과 복원 테스트가 성공할 때까지 소스 애플리케이션은 중지된 상태로 유지하고 기존 볼륨은 읽기 전용으로 보존하세요. 대상에서 새로운 쓰기가 수락되지 않은 경우에만 변경하지 않은 소스로 트래픽을 되돌려 롤백하세요. 그렇지 않으면 중단하고 데이터를 신중하게 조정하세요.

지원 및 팁

더 읽어보기

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.