재배포 후 Compose 스택이 비어 있는 새 이름 지정 볼륨을 연결하는 이유는 무엇인가요?

Compose 스택은 재배포 과정에서 프로젝트 범위의 볼륨 이름이 변경되거나 원래 볼륨을 찾지 못하면 새 빈 이름 지정 볼륨을 연결할 수 있습니다.

기존 데이터는 다른 Docker 볼륨에 여전히 존재하지만, 재생성된 서비스가 동일한 컨테이너 경로에 새로 생성된 볼륨을 마운트할 수 있습니다. 일반적인 원인으로는 변경된 스택 또는 프로젝트 이름, 이름이 바뀐 볼륨 키, 볼륨 삭제 명령을 통한 제거, external 선언의 손실, 다른 관리자를 통한 배포, 현재 다르게 해석되는 명시적 볼륨 이름 등이 있습니다. 데이터를 복원하거나 앱을 초기화하기 전에 마운트된 볼륨과 고아 후보 볼륨을 모두 확인하세요.

새 컨테이너에 마운트된 정확한 볼륨 확인

실행 중인 컨테이너의 마운트를 검사하고 볼륨 이름, 드라이버, 마운트 지점, 레이블, 생성 시간, 컨테이너 대상 경로, 읽기-쓰기 모드를 기록하세요. 재배포 전 기록과 비교합니다.

Ubuntu의 docker volume inspect 명령은 볼륨 식별 정보를 보여주므로 새 빈 볼륨과 비슷한 이름을 가진 기존 미마운트 볼륨을 구분할 수 있습니다.

원래 볼륨을 찾기 전에는 새 볼륨에 데이터를 복사하지 마세요. 앱을 시작하면 새 데이터베이스가 생성되어 대상 볼륨이 의도적으로 초기화된 것처럼 보일 수 있습니다.

Compose 프로젝트 이름 변경 여부 확인

이전 프로젝트 이름과 새 프로젝트 이름, 스택 이름, Compose 디렉터리, -p 옵션, COMPOSE_PROJECT_NAME, 최상위 name:, 배포 관리자를 비교하세요.

Docker 설명에 따르면 Compose는 일반적으로 명시적 이름이나 external 볼륨 조회가 설정되지 않은 경우 볼륨 이름을 프로젝트 이름과 볼륨 키의 조합으로 범위 지정합니다.

따라서 동일한 Compose 파일을 다른 디렉터리로 옮기면 서비스와 볼륨 키가 같더라도 두 번째 프로젝트와 두 번째 볼륨이 생성될 수 있습니다.

안정적인 이름과 External 볼륨 설정 확인

재배포 전후의 최상위 볼륨 정의를 비교하세요. name:, external:, 드라이버 옵션, 보간 변수, 예상 볼륨의 존재 여부를 확인합니다.

Microsoft의 Docker Compose 튜토리얼은 이름 지정 볼륨이 컨테이너 교체와 독립적으로 유지된다고 설명합니다. 따라서 새 빈 상태가 나타났다면 일반적으로 다른 볼륨 식별자가 연결되었거나 기존 볼륨이 삭제된 것입니다.

볼륨의 수명 주기를 의도적으로 스택 외부에서 관리할 때만 external로 표시하세요. 외부 볼륨이 없으면 Compose가 대체 볼륨을 자동으로 생성하지 않고 명확하게 실패해야 합니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

정리 작업으로 기존 볼륨이 삭제되었는지 확인

배포 로그, 스크립트, UI 작업, 정리 작업, 볼륨 삭제 명령을 검토하세요. 볼륨 생성 시간과 재배포 시점을 비교합니다.

Red Hat은 컨테이너가 관리하는 이름 지정 볼륨이 컨테이너의 쓰기 가능 계층과 별도의 저장 위치를 사용한다고 설명합니다. 따라서 컨테이너를 제거하는 것과 이름 지정 볼륨을 제거하는 것은 서로 다른 수명 주기 이벤트입니다.

기존 볼륨이 없다면 자동 시작을 중지하고 검증된 백업에서만 복원하세요. 빈 대체 볼륨에 복구 가능한 삭제 계층이 들어 있다고 가정하지 마세요.

스택 관리자 식별자와 배포 방식 비교

스택이 CLI, Portainer, NAS 앱 스토어, Git 배포 또는 다른 자동화 도구로 실행되었는지 기록하세요. 해당 관리자가 저장한 스택 이름과 환경 값을 비교합니다.

Portainer는 배포 시 설명적인 스택 이름을 요구하며, 이 관리자에서 제어하는 식별자는 수동 Compose 명령에서 사용하는 디렉터리 기반 프로젝트 이름과 다를 수 있습니다.

따라서 수동 긴급 시작으로 다른 프로젝트 접두사 아래에 리소스가 생성될 수 있습니다. 배포 담당자를 하나로 정하고 해당 담당자가 생성하는 확인된 볼륨 이름을 문서화하세요.

새 볼륨 마운트 아래에 숨겨진 데이터인지 확인

컨테이너를 중지하고, 이름 지정 볼륨을 연결하지 않은 상태에서 일회성 테스트로 이미지 또는 바인드 경로를 검사하세요. 볼륨이 마운트되기 전에 시작 과정에서 컨테이너 계층에 데이터를 기록했는지 확인합니다.

Linux mount 매뉴얼은 마운트가 기존 디렉터리 콘텐츠를 숨긴다고 설명합니다. 따라서 새 빈 볼륨이 이미지 또는 쓰기 가능 계층에 생성된 파일을 덮어 가리면 데이터가 사라진 것처럼 보일 수 있습니다.

숨겨진 계층과 기존 영구 볼륨을 무작정 병합하지 마세요. 어떤 상태를 기준으로 삼을지 확인하고 애플리케이션에서 지원하는 복구 방법을 사용하세요.

통제된 테스트로 기존 볼륨 다시 연결

스택을 중지하고 두 후보 볼륨을 모두 백업한 다음, 기존 볼륨을 일회성 컨테이너 또는 임시 서비스 경로에 연결하여 애플리케이션 파일, 데이터베이스 식별 정보, 소유권, 타임스탬프를 확인하세요.

ZimaSpace의 마운트를 손상시키지 않고 컨테이너 데이터를 이동하는 방법 가이드는 관련 경로 매핑 절차를 제공합니다. 이 문서에서는 프로젝트 범위의 이름 지정 볼륨 식별자에 초점을 맞춥니다.

의도한 기존 볼륨이 안정적인 명시적 이름 또는 external 이름으로 마운트되고, 반복적인 재배포에서도 다른 빈 후보 볼륨이 생성되지 않고 해당 볼륨이 재사용되면 문제가 해결된 것입니다.

자주 묻는 질문

빈 이름 지정 볼륨은 기존 데이터가 삭제되었다는 뜻인가요?

반드시 그렇지는 않습니다. 새 컨테이너가 다른 빈 볼륨을 사용하는 동안 기존 볼륨이 다른 프로젝트 접두사나 명시적 이름으로 여전히 존재할 수 있습니다.

Compose 폴더 이름을 변경하면 새 볼륨이 생성될 수 있나요?

예. 프로젝트 이름을 고정하지 않으면 Compose가 프로젝트 디렉터리에서 이름을 파생하여 접두사가 다른 리소스를 생성할 수 있습니다.

중요한 볼륨을 external로 표시해야 하나요?

External 볼륨을 사용하면 스택 제거 작업이 해당 볼륨의 수명 주기를 관리하지 못하게 할 수 있지만, 별도의 생성, 이름 지정, 백업, 배포 확인이 필요합니다.