동일한 애플리케이션을 두 개 실행하는 것은 Docker Compose 계층에서 가능하지만, Immich처럼 여러 서비스로 구성된 스택에서는 기본 컨테이너 이름과 웹 포트만 변경하는 것으로는 충분하지 않습니다.
각 인스턴스에 별도의 Compose 프로젝트 사용
Docker의 Docker Compose 프로젝트 이름 문서에 따르면, Compose 프로젝트 이름은 서비스 이름을 공유할 수 있는 여러 환경을 격리하도록 설계되었습니다. 수동으로 컨테이너 이름을 변경하는 것을 주요 격리 방식으로 사용하지 말고, 각 인스턴스에 고유한 프로젝트 이름을 지정하세요.
첫 번째 Docker 앱에서는 ZimaOS Compose 계층을 설명하며, ZimaOS의 Portainer는 고급 사용자가 독립적인 스택을 확인하는 데 도움이 될 수 있습니다.
Immich는 단일 컨테이너가 아니라 스택입니다
최신 Immich Docker Compose 구성은 여러 서비스를 사용하며 업로드 스토리지와 데이터베이스 스토리지를 분리합니다. 따라서 두 번째 Immich 인스턴스에는 자체 데이터베이스 데이터, 업로드 경로, 해당되는 경우 캐시 및 모델 데이터, 그리고 충돌할 수 있는 호스트 포트가 각각 필요합니다.
고유해야 하는 항목
- Compose 프로젝트 이름: 서비스, 네트워크, 볼륨 네임스페이스를 격리합니다.
- 게시된 호스트 포트: 두 인스턴스가 동일한 호스트 포트에 바인딩될 수는 없습니다.
- 영구 폴더/볼륨: 서로 독립적인 데이터베이스나 업로드 라이브러리를 동일한 쓰기 가능한 데이터 디렉터리에 연결하지 마세요.
- 환경 변수 참조: 각 스택 내부에서 일관성을 유지하세요.
Immich 스토리지 마이그레이션 문서는 Immich에서 어떤 경로가 영구적으로 유지되는지, 그리고 설치 간에 해당 경로를 함부로 공유해서는 안 되는 이유를 이해하는 데 유용합니다.
필요하지 않다면 하드코딩된 container_name을 피하세요
Compose는 일반적으로 프로젝트 이름과 서비스 이름을 바탕으로 컨테이너 이름을 자동으로 생성할 수 있습니다. container_name을 하드코딩하면 전역 이름 충돌 가능성이 커지고, 중복 스택이 더 불안정해집니다.
결론
올바른 이해 방식은 “이름을 변경한 동일한 앱의 컨테이너 두 개”가 아니라 “서로 격리된 Compose 프로젝트 두 개”입니다. Immich에서는 각 서비스의 영구 상태와 게시된 포트를 모두 격리하세요. 상태를 공유하면 두 번째 스택이 실행되지 않거나 첫 번째 스택에 영향을 줄 수 있습니다.
