Uruchomienie kodu Collabora na architekturze ARM64 z poprawnym obrazem

Kontener Collabora CODE, który natychmiast działa na hoście ARM64, często korzysta z niewłaściwej platformy obrazów, ale sam ARM64 nie jest z natury nieobsługiwany. Przed zmianą uprawnień lub przebudową obrazu należy sprawdzić bitowość hosta, opublikowany manifest konkretnego znacznika obrazu oraz wszelkie nadpisania platformy Compose. Zgodnie z informacjami z 10 października 2026 r., oficjalny obraz CODE zawiera kompilacje ARM64; Docker Hub wymienia znacznik 26.04.4.2.1dla linux/arm64.

1. Zidentyfikuj architekturę hosta i dokładny błąd uruchamiania

Uruchom te polecenia na hoście Dockera, a nie w zatrzymanym kontenerze Collabora. Zastąp je, collaborajeśli usługa Compose używa innej nazwy:

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

64-bitowy host ARM Linux zazwyczaj raportuje aarch64z uname -m. Wartość taka jak armv7lzazwyczaj identyfikuje 32-bitową platformę jądra ARM, która różni się od linux/arm64. Etykieta architektury Dockera może mieć inną pisownię, dlatego należy porównać typ hosta, konfigurację Compose i manifest obrazu, zamiast mechanicznie dopasowywać jeden ciąg znaków.

Przeczytaj pierwszy komunikat krytyczny i stan wyjścia. Komunikat „Brak pasującego manifestu dla systemu Linux/arm64” oznacza, że ​​wybrany tag nie ma pasującego wariantu dla żądanej platformy. Komunikat „Błąd formatu pliku wykonywalnego” sugeruje niezgodność architektury lub jawne wymuszenie obcej platformy. Błąd uprawnień lub zamknięcie z powodu braku pamięci ma inną przyczynę; nie traktuj każdej pętli restartu jako błędu zgodności z ARM.

2. Sprawdź, czy tag publikuje obraz ARM64

Przed zmianą hosta sprawdź tag w rejestrze:

docker buildx imagetools inspect collabora/code:26.04.4.2.1

Szukaj linux/arm64na liście platform. 10 października 2026 roku oficjalna lista tagów Docker Hub pokazała, że ​​platforma jest obsługiwana zarówno przez platformę, latestjak i . Strona CODE26.04.4.2.1 Collabora identyfikuje x86-64, ppc64 i arm64 jako obsługiwane architektury hosta. Tag z wersjonowaniem jest łatwiejszy do odtworzenia podczas rozwiązywania problemów. Tagi i manifesty mogą ulec zmianie, dlatego sprawdź dokładną wersję, którą planujesz wdrożyć, zamiast zakładać, że każdy tag historyczny ma te same architektury.

Docker automatycznie wybiera pasujący wariant, gdy tag jest wieloplatformowy i żadne nadpisanie nie zmienia celu. Polecenie inspekcji obrazu Dockera wyświetla platformy opublikowane dla obrazu rejestru.

3. Usuń nadpisanie AMD64 i pobierz natywną odmianę

Sprawdź rozwiązaną usługę Compose, w tym pliki nadrzędne, pod kątem wymuszonego platform: linux/amd64. Zmienna Docker CLI DOCKER_DEFAULT_PLATFORMmoże również ustawić domyślną platformę dla poleceń akceptujących flagę platformy. platformPole Compose jawnie wybiera docelowy system operacyjny i architekturę, więc usuń nieprawidłowe nadpisanie lub ustaw je na ARM64. Jeśli masz jq, sprawdź scalone ustawienia bez wyświetlania niepowiązanych wartości środowiskowych: docker compose config --format json | jq '.services.collabora | {image, platform}'. To pole jest zdefiniowane w dokumentacji usługi ComposeDOCKER_DEFAULT_PLATFORM . Jest to udokumentowane w dokumentacji Docker CLI .

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

Oto fragment: scal wiersze obrazu i platformy z istniejącą usługą i zachowaj wymagane ustawienia. Jeśli Docker poprawnie wybiera natywny manifest ARM64, wiersz platformjest opcjonalny. Zastąp go collaboraw poniższych poleceniach, jeśli usługa Compose ma inną nazwę.

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

Użyj przypiętego tagu, jak pokazano, lub innego wydania, którego manifest właśnie zweryfikowałeś. latest-arm64Tag jest również wymieniony w Docker Hub, ale jego zawartość zmienia się wraz ze zmianami w wydaniach. Przypięcie wersji sprawia, że ​​wycofanie i późniejsze porównanie są bardziej przewidywalne. Unikaj wymuszania linux/amd64niedostatecznej emulacji jako pierwszej poprawki, gdy dostępny jest natywny obraz ARM64; emulacja powoduje dodatkowe obciążenie i sprawia, że ​​diagnostyka uruchamiania jest mniej bezpośrednia.

4. Zdiagnozuj awarie niezwiązane z architekturą, a następnie sprawdź uruchomienie

Jeśli obraz natywny nadal istnieje, zamiast rozszerzać uprawnienia kontenera, skorzystaj z dziennika i stanu:

Użyj nazwy kontenera lub identyfikatora wyświetlonego przez , docker compose ps -aaby sprawdzić jego stan wyjścia:

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

Docker dokumentuje inspekcje kontenerów i logi kontenerów dla tych sprawdzeń. Nie usuwaj trwałych woluminów ani nie nadawaj całemu kontenerowi uprawnień tylko po to, aby przetestować problem z architekturą.

Sprawdź pobrany obraz i działającą usługę

Sprawdź, czy obraz lokalny zgłasza architekturę docelową:

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

Wartość oczekiwana to linux/arm64. Następnie sprawdź docker compose ps -astabilność działania i przejrzyj najnowsze logi pod kątem krytycznych błędów uruchamiania. Po połączeniu kontenera z platformą pamięci masowej lub odwrotnym serwerem proxy, wyślij żądanie /hosting/discoveryza pośrednictwem skonfigurowanego adresu URL Collabora i otwórz dokument testowy. Przed aktualizacjami sprawdź ponownie listę tagów rejestru, ponieważ dostępne wersje i manifesty platformy mogą ulec zmianie.