Collabora CODEをARM64上で正しいイメージを使って実行しましょう

Collabora CODE コンテナが ARM64 ホスト上で即座に終了する場合、多くの場合、間違ったイメージ プラットフォームを使用していますが、ARM64 自体は本来サポートされていないわけではありません。権限を変更したりイメージを再構築したりする前に、ホストのビット数、イメージ タグの公開マニフェスト、および Compose プラットフォームのオーバーライドを確認してください。2026 年 10 月 10 日現在、公式の CODE イメージには ARM64 ビルドが含まれています。Docker Hub に26.04.4.2.1は のタグがリストされていますlinux/arm64。

1. ホストアーキテクチャと正確な起動エラーを特定する

これらのコマンドは、停止した Collabora コンテナ内ではなく、Docker ホスト上で実行してください。Composecollaboraサービスが別の名前を使用している場合は、以下の箇所を置き換えてください。

uname -m
docker info --format '{{.Architecture}}'
docker compose ps -a
docker compose logs --tail=100 collabora

64 ビット ARM Linux ホストは通常​​、aarch64からレポートしますuname -m。 のような値はarmv7l通常 32 ビット ARM カーネル プラットフォームを識別し、 とは異なりますlinux/arm64。Docker のアーキテクチャ ラベルは別のスペルを使用している場合があるため、1 つの文字列を機械的に照合するのではなく、ホスト タイプ、Compose 構成、およびイメージ マニフェストを比較してください。

最初の致命的なエラーメッセージと終了状態を確認してください。「linux/arm64 に一致するマニフェストがありません」は、選択したタグに要求されたプラットフォームに一致するバリアントがないことを意味します。「実行フォーマットエラー」は、アーキテクチャの不一致、または明示的に強制された別のプラットフォームを示唆しています。権限エラーやメモリ不足による強制終了は別の原因によるものです。再起動ループが発生するたびに、ARM 互換性の問題として扱わないでください。

2. タグがARM64イメージを公開していることを確認します。

ホストを変更する前に、レジストリ内のタグを確認してください。

docker buildx imagetools inspect collabora/code:26.04.4.2.1

linux/arm64プラットフォーム一覧でを探してください。2026 年 10 月 10 日の公式 Docker Hub タグ一覧でlatestは、との両方のプラットフォームが と表示されていました26.04.4.2.1。 Collabora のCODE ページでは、サポートされているホスト アーキテクチャとして x86-64、ppc64、arm64 が識別されています。 バージョン付きタグは、トラブルシューティング中に再現しやすくなっています。 タグとマニフェストは変更される可能性があるため、過去のすべてのタグが同じアーキテクチャを持っていると想定するのではなく、デプロイ予定の正確なバージョンを確認してください。

タグがマルチプラットフォームで、オーバーライドによってターゲットが変更されていない場合、Docker は一致するバリアントを自動的に選択します。Docker のイメージ検査コマンドは、レジストリイメージに対して公開されているプラ​​ットフォームを表示します。

3. AMD64 オーバーライドを削除し、ネイティブバリアントを取り出す

解決済みの Compose サービス (オーバーライド ファイルを含む) で強制 がないか確認してくださいplatform: linux/amd64。Docker CLI 変数では、DOCKER_DEFAULT_PLATFORMプラットフォーム フラグを受け入れるコマンドのデフォルト プラットフォームを設定することもできます。Compose のplatformフィールドは、ターゲットのオペレーティングシステムとアーキテクチャを明示的に選択するため、誤ったオーバーライドを削除するか、ARM64 に設定してください。 がある場合はjq、無関係な環境値を出力せずにマージされた設定を検査します。Composedocker compose config --format json | jq '.services.collabora | {image, platform}'サービスリファレンスでこのフィールドが定義されています。Docker CLI リファレンスDOCKER_DEFAULT_PLATFORMでドキュメント化されています。

services:
  collabora:
    image: collabora/code:26.04.4.2.1
    platform: linux/arm64

これは抜粋です。イメージとプラットフォームの行を既存のサービスにマージし、必要な設定を保持します。Dockerが既にネイティブARM64マニフェストを正しく選択している場合は、このplatform行は省略可能です。Composecollaboraサービスに別の名前がある場合は、以下のコマンドで置き換えてください。

docker compose pull collabora
docker compose up -d --force-recreate collabora

表示されている固定タグを使用するか、マニフェストを確認した別のリリースを使用してください。latest-arm64タグはDocker Hubにも表示されますが、リリースが変更されると内容も変わります。バージョンを固定することで、ロールバックや後々の比較がより予測しやすくなります。linux/amd64ネイティブのARM64イメージが利用可能な場合は、最初の修正としてエミュレーションを強制的に使用することは避けてください。エミュレーションはオーバーヘッドを増やし、起動時の診断を難しくします。

4. アーキテクチャ以外の障害を診断し、起動を確認する

ネイティブイメージがまだ存在する場合は、コンテナの権限を拡大する代わりに、ログと状態を使用します。

コンテナ名またはIDを使用して、docker compose ps -a終了状態を検査します。

docker inspect --format 'status={{.State.Status}} exit={{.State.ExitCode}} oom={{.State.OOMKilled}} error={{.State.Error}}' CONTAINER

Dockerは、これらのチェックのためにコンテナの検査手順とコンテナログを文書化しています。アーキテクチャ上の問題をテストするためだけに、永続ボリュームを削除したり、コンテナ全体に特権権限を与えたりしないでください。

プルしたイメージと実行中のサービスを確認してください。

ローカルイメージがターゲットアーキテクチャを報告していることを確認してください。

docker image inspect collabora/code:26.04.4.2.1 --format '{{.Os}}/{{.Architecture}}'

期待値は ですlinux/arm64。次に、docker compose ps -a安定した実行状態を確認し、最新のログで致命的な起動エラーがないか確認してください。コンテナがストレージプラットフォームまたはリバースプロキシに接続されたら、/hosting/discovery設定済みの Collabora URL を介してリクエストを送信し、テストドキュメントを開きます。利用可能なバージョンとプラットフォームマニフェストは変更される可能性があるため、アップグレード前にレジストリのタグリストを再確認してください。