이 문제는 2024~2025년 ZimaOS 앱 모델에서 실제로 존재했습니다. latest로 앱을 설치하면 설치 시점에 해당 태그가 확인되지만, 이후 ZimaOS는 같은 태그 뒤에서 레지스트리 내용이 변경되어도 자동으로 따라가지 않고 확인된 버전을 유지했습니다. Zima-Giorgio는 이러한 동작이 안정성을 위한 의도적인 설계라고 설명했으며, 앱 업그레이드를 강제로 진행하면 앱이 손상될 수 있다고 거듭 경고했습니다.
그 이후 두 가지가 변경되었습니다. 첫째, ZimaOS 1.7에서는 전용 설치 앱 관리 페이지와 업데이트 상태를 포함한 App Store 2.0이 도입되었습니다. 둘째, Docker의 작동 방식도 여전히 중요합니다. 레지스트리의 latest 태그가 이동했다는 이유만으로 실행 중인 컨테이너가 새 이미지로 자동 변경되지는 않습니다. 업데이트하려면 변경된 이미지를 확인하고 가져온 다음 컨테이너 또는 스택을 다시 생성해야 합니다.
기존 ZimaOS 설계에서는 태그를 확인한 뒤 버전을 고정했습니다
Giorgio는 latest가 앱을 설치할 때 적용된 후 ZimaOS가 해당 버전을 안정적으로 유지한다고 설명했습니다. 이는 사용자가 모르는 사이 업스트림 이미지가 변경되어 예기치 않게 문제가 발생하는 일을 줄이기 위한 설계였습니다.
이후 커뮤니티에서는 develop과 같은 문제를 겪었으며, 이는 latest뿐 아니라 이름이 지정된 변경 가능 태그에도 적용될 가능성이 높습니다.
Docker에서 latest는 결코 “실행 중인 컨테이너 자동 업데이트”를 의미하지 않습니다
변경 가능한 태그는 레지스트리를 가리키는 포인터일 뿐입니다. 내일 example/app:latest가 새 이미지를 가리키도록 변경되어도, 이미 생성된 컨테이너는 업데이트 절차를 통해 이미지를 가져오고 컨테이너를 다시 생성하기 전까지 기존 이미지를 계속 사용합니다.
따라서 ZimaOS 외부에서도 “latest”와 “자동 업데이트”는 서로 별개의 개념입니다.
원문에서는 수동 버전 태그 지정을 해결 방법으로 사용했습니다
CogZog는 Immich의 태그를 게시된 버전 번호로 직접 변경한 뒤 앱이 v1.132.3으로 업데이트되었다고 보고했습니다. 이후 Giorgio는 특정 버전이 필요한 사용자는 앱 버전 필드를 편집하고 저장할 수 있다고 말했습니다.
이는 커뮤니티 또는 사용자 수준의 해결 방법일 뿐, 모든 앱을 무조건 최신 업스트림 이미지로 업데이트해도 안전하다는 의미는 아닙니다.
여러 컨테이너로 구성된 앱은 이미지 하나만 업데이트하면 문제가 발생할 수 있습니다
Immich가 좋은 예입니다. 서버, 머신 러닝, 데이터베이스, 캐시 구성 요소에는 서로 맞물린 마이그레이션 요구 사항이 있을 수 있습니다. 앱의 업스트림 릴리스 및 마이그레이션 안내를 따르지 않고 태그 하나만 수정하면 호환되지 않는 혼합 스택이 만들어질 수 있습니다.
ZimaOS 1.7에서는 설치 앱의 명시적인 업데이트 관리 기능이 추가되었습니다
현재 ZimaOS App Store는 하나의 관리 페이지에서 설치된 앱과 각 앱의 상태 및 업데이트 가능 여부를 보여 줍니다. App Store 2.0 패키지에는 패키지 변경 사항을 감지하는 데 사용되는 버전 메타데이터와 콘텐츠 해시도 포함됩니다.
현재 App Store 업데이트 환경을 참조하세요.
Store 앱과 사용자 지정 Compose의 업데이트 책임자는 서로 다릅니다
App Store 패키지의 경우 테스트된 패키지 업데이트를 언제 게시할지는 스토어 관리자가 결정합니다. 사용자 지정 Compose 스택에서는 사용자가 관리자입니다. 이미지 태그 또는 다이제스트를 결정하고, 업스트림 릴리스 노트를 읽고, 새 이미지를 가져온 다음 스택을 다시 생성해야 합니다.
스토어가 사용자 지정 Compose 파일을 수정하거나 사용자 지정 데이터베이스를 자동으로 마이그레이션해 줄 것이라고 기대하지 마세요.
중요한 서비스에는 명시적인 버전 고정이 더 안전한 경우가 많습니다
데이터베이스, 사진 관리 도구, 자동화 시스템 및 기타 상태 저장 앱의 경우, 테스트된 버전 태그 또는 다이제스트를 사용하고 계획된 업그레이드 시간을 정하면 롤백을 계획하고 호환성을 깨뜨릴 수 있는 변경 사항을 확인할 시간을 확보할 수 있습니다.
일회성으로 사용하거나 상태를 저장하지 않는 도구라면 가져오기 및 재생성 시점을 직접 관리하는 조건에서 변경 가능한 태그를 따라가도 괜찮을 수 있습니다.
Docker 태그 업데이트 FAQ
원문의 사용자가 Docker의 latest를 완전히 잘못 이해한 것인가요?
아니요. 기존 설계에서 ZimaOS가 확인된 앱 버전을 실제로 고정한 것은 맞습니다. 다만 Docker 자체에서도 실행 중인 컨테이너를 업데이트하려면 이미지를 가져오고 컨테이너를 다시 생성해야 합니다.
현재 ZimaOS에 앱 업데이트 관리 페이지가 있나요?
예. App Store 2.0에서는 설치 앱의 업데이트 상태와 관리 기능이 추가되었습니다.
모든 앱이 항상 latest를 자동으로 따라가야 하나요?
아니요. 변경 가능한 태그를 통한 업데이트는 특히 상태 저장 앱이나 여러 컨테이너로 구성된 애플리케이션에서 호환성을 깨뜨리는 변경을 일으킬 수 있습니다.
