コミュニティソリューション

最新版を使用するZimaOSのDockerアプリが自動更新されなかった理由:過去のタグ固定とApp Store 2.0

A December 2024-May 2025 thread where apps installed with latest or develop were effectively resolved to a fixed version. Zima-Giorgio said the design favored stability and warned that manually forcing upgrades could break apps. Users confirmed manual version-tag edits could update apps, while the underlying named-tag refresh issue remained unresolved in the thread.

元の問題は、2024~2025年のZimaOSアプリモデルでは実際に存在していました。latestでアプリをインストールすると、インストール時点でそのタグが解決されますが、ZimaOSはその後、同じタグに対するレジストリの変更を自動的に追従するのではなく、解決済みのバージョンを保持していました。Zima-Giorgioは、この動作は安定性のために意図されたものだと説明し、アプリのアップグレードを強制すると動作しなくなる可能性があると繰り返し警告していました。

それ以降、2つの点が変わりました。まず、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は後に、特定のバージョンが必要なユーザーは、アプリのバージョン欄を編集して保存できると述べました。

これはコミュニティまたはユーザーレベルの回避策であり、すべてのアプリを無条件に最新の上流イメージへ更新しても安全だという証拠ではありません。

複数コンテナのアプリでは、1つのイメージだけを更新すると壊れる可能性がある

Immichはその好例です。サーバー、機械学習、データベース、キャッシュの各コンポーネントには、連携した移行要件がある場合があります。アプリの上流リリースおよび移行手順に従わずに1つのタグだけを編集すると、互換性のない混在スタックが生じる可能性があります。

ZimaOS 1.7では、インストール済みアプリの更新管理機能が明示的に追加された

現在のZimaOS App Storeでは、インストール済みアプリが1つの管理ページに表示され、ステータスや更新の有無を確認できます。App Store 2.0のパッケージには、パッケージの変更を検出するためのバージョンメタデータとコンテンツハッシュも含まれています。

現在のApp Storeの更新機能をご覧ください。

StoreアプリとカスタムComposeでは、更新を管理する主体が異なる

App Storeパッケージでは、テスト済みパッケージの更新をいつ公開するかをストアのメンテナーが決定します。カスタムComposeスタックでは、あなた自身がメンテナーです。イメージのタグまたはダイジェストを決め、上流のリリースノートを確認し、新しいイメージをプルして、スタックを再作成します。

ストアがカスタムComposeファイルを書き換えたり、カスタムデータベースを自動的に移行したりすることは期待しないでください。

重要なサービスでは、明示的なバージョン固定のほうが安全な場合が多い

データベース、写真管理、オートメーションシステムなどの状態を保持するアプリでは、テスト済みのバージョンタグまたはダイジェストを使用し、計画的なアップグレード期間を設けることで、ロールバックの計画を立て、破壊的変更を読む時間を確保できます。

使い捨て可能またはステートレスなツールでは、プルと再作成を実行するタイミングを自分で管理できる限り、変更可能なタグを追従しても問題ない場合があります。

Dockerのタグ更新に関するよくある質問

元のユーザーはDockerのlatestを完全に誤解していたのでしょうか?

いいえ。過去の設計では、ZimaOSが解決済みのアプリバージョンを実際に固定していました。ただしDocker自体も、実行中のコンテナを更新するにはイメージのプルと再作成を必要とします。

現在のZimaOSにはアプリ更新の管理ページがありますか?

はい。App Store 2.0では、インストール済みアプリの更新ステータスと管理機能が追加されました。

すべてのアプリを常にlatestに自動追従させるべきですか?

いいえ。変更可能なタグの更新では、特に状態を保持するアプリや複数コンテナのアプリで、破壊的変更が発生する可能性があります。