Naprawa kontenera Collabora CODE, który nie uruchamia się na architekturze ARM64
Jeśli kontener Collabora Online Development Edition (CODE) zostanie natychmiast zamknięty na maszynie ARM64, należy rozpocząć od zapewnienia zgodności architektury przed zmianą ustawień sieciowych, certyfikatów lub WOPI. Oficjalne collabora/coderepozytorium z 7 października 2026 roku zawiera listę natywnych linux/arm64wariantów dla bieżących wydań, w tym dla bieżącego latesttagu i wersji 26.04.4.2.1. Oznacza to, że nowoczesny host ARM64 zazwyczaj nie potrzebuje emulacji x86 do uruchomienia CODE. Najbardziej przydatnym procesem dla początkujących jest potwierdzenie architektury hosta, sprawdzenie dokładnego tagu obrazu, usunięcie wszelkich wymuszonych ustawień AMD64, pobranie obrazu obsługującego ARM64, a dopiero potem rozwiązanie problemów z konfiguracją na poziomie aplikacji.
Ten poradnik koncentruje się na samym błędzie uruchamiania. Nie zakłada, że każdy problem z ARM64 ma tę samą przyczynę. Jeśli kontener uruchamia się pomyślnie, ale NextCloud, ownCloud lub inny host WOPI nie może się z nim połączyć, jest to inny poziom rozwiązywania problemów.
Co musisz wiedzieć, zanim cokolwiek zmienisz
ARM64 to 64-bitowa architektura procesora ARM. Linux zazwyczaj zgłasza ją jako aarch64, podczas gdy Docker zazwyczaj oznacza ten sam cel jako linux/arm64. AMD64 , nazywany również x86-64, to inna architektura procesora. Obraz kontenera zawiera pliki binarne zbudowane dla jednej lub więcej architektur; Docker może automatycznie wybrać odpowiedni wariant tylko wtedy, gdy znacznik obrazu zawiera zgodny manifest.
Obraz wieloplatformowy to pojedynczy znacznik obrazu, którego manifest rejestru wskazuje na oddzielne kompilacje obrazu dla architektur takich jak AMD64 i ARM64. Docker dokumentuje, że po pobraniu obrazu wieloplatformowego automatycznie wybiera pasujący wariant dla hosta. Szczegółowe informacje na temat działania tego mechanizmu można znaleźć w dokumentacji obrazu wieloplatformowego Dockera.
W przypadku Collabora CODE, zamiast polegać na starym samouczku, sprawdź oficjalną listę tagów collabora/code w Docker Hublatest . Ten artykuł został sprawdzony 7 października 2026 roku i 26.04.4.2.1dodany do niego linux/arm64, a także podano dedykowany latest-arm64tag. Starsze, przypięte wersje mogą się różnić, więc tag, który faktycznie wdrożysz, ma większe znaczenie niż ogólne stwierdzenie, że „Collabora obsługuje ARM”.
Przygotuj bezpieczną sesję rozwiązywania problemów
Zapisz dokładny tag obrazu Collabora, którego używasz.
Nie usuwaj danych aplikacji ani konfiguracji odwrotnego serwera proxy tylko po to, aby zdiagnozować niezgodność architektury.
Jeśli jest to wdrożenie produkcyjne, należy najpierw przetestować znacznik zastępczy w oknie konserwacyjnym lub na hoście przejściowym.
Efekt końcowy jest prosty: Docker powinien pobrać obraz ARM64, kontener powinien pozostać uruchomiony zamiast od razu się zamknąć, a jego logi powinny przejść do normalnego uruchomienia Collabora zamiast kończyć się błędem architektury.
Krok 1: Potwierdź hosta i architekturę Dockera
Uruchom te sprawdzenia na komputerze, na którym faktycznie działa kontener Collabora:
uname -m
docker info --format '{{.Architecture}}'
docker version
Na natywnym 64-bitowym hoście ARM Linux uname -mzazwyczaj zwraca aarch64, podczas gdy Docker powinien zgłosić arm64. W tym kontekście te nazwy odnoszą się do tej samej rodziny architektur.
Najpierw sprawdź system operacyjny i architekturę demona Dockera. Natywny host ARM64 zazwyczaj pojawia się jako aarch64 w Linuksie i arm64 w Dockerze.
Jeśli Docker zgłasza AMD64, mimo że maszyna fizyczna ma architekturę ARM64, sprawdź, czy używasz zdalnego kontekstu Dockera, maszyny wirtualnej, czy Docker Desktop z innym zapleczem. Rozwiąż tę niejasność przed kontynuowaniem. W przeciwnym razie możesz sprawdzić jeden system podczas wdrażania na innym.
Jaki błąd wskazuje na niezgodność architektury?
Typowe sygnały obejmują exec format error, komunikat rejestru o istnieniu no matching manifest for linux/arm64, lub usługę Compose jawnie skonfigurowaną z platform: linux/amd64. Te komunikaty stanowią silniejszy dowód niezgodności platformy niż ogólne dane wyjściowe „kontener zakończony”.
Krok 2: Przed pobraniem sprawdź dokładny tag obrazu Collabora
Nie zakładaj, że każdy historyczny tag ma takie samo wsparcie platformy jak dzisiejszy latest. Sprawdź metadane rejestru dla tagu w swoim wdrożeniu:
Dokumentacja narzędzia Docker buildx imagetools inspect wyjaśnia, jak to polecenie wyświetla platformy zawarte w obrazie rejestru. Można również użyć docker manifest inspect; Dokumenty Dockera dotyczące tego polecenia znajdują się w jego dokumentacji dotyczącej inspekcji manifestu .
Sprawdź manifest obrazu i poszukaj konkretnie linux/arm64. Obecne oficjalne tagi CODE mogą być wieloplatformowe, ale starszy, przypięty tag może nie być.
Jeśli linux/arm64się pojawi, możesz użyć znacznika wieloplatformowego i pozwolić Dockerowi wybrać właściwy obraz. Do bezpośredniego testu rozwiązywania problemów, oficjalne repozytorium również zawiera znacznik latest-arm64. W przypadku długotrwałych wdrożeń produkcyjnych, dokładnie przetestowany znacznik wersji jest zazwyczaj łatwiejszy do odtworzenia niż znacznik latest, ponieważ latestjest on przesuwany wraz z publikacją nowych wersji.
Jeśli przypięty tag nie zawiera ARM64, masz trzy możliwości:
Wybór
Najlepiej pasuje
Kompromis
Przejdź do bieżącego natywnego znacznika ARM64 CODE
Większość serwerów ARM64 i laboratoriów domowych
Musisz sprawdzić zgodność wydania i ustawienia integracji
Pozostań przy starej wersji, korzystając z emulacji AMD64
Krótkoterminowe testy zgodności
Dodatkowa złożoność i możliwe obciążenie wydajności; nie jest to preferowane rozwiązanie, gdy istnieje obraz natywny
Zachowaj starą wersję na hoście AMD64
Ścisłe przypinanie wersji, w których ryzyko aktualizacji jest niedopuszczalne
Wymaga innego sprzętu lub innej pojemności maszyny wirtualnej
Krok 3: Usuń przypadkowe nadpisanie AMD64 i wyczyść je
Częstą awarią nie jest sam obraz Collabora, ale plik wdrożenia, który wymusza niewłaściwą platformę. Docker Compose definiuje się platformjako docelowy system operacyjny i architekturę użytą do wyboru wariantu obrazu. Dokumentacja usługi Docker Compose zawiera wartości takie jak linux/arm64/v8.
Jeśli nie potrzebujesz emulacji, usuń ten wiersz i pozwól Dockerowi wybrać wariant natywny dla hosta. Możesz też określić, platform: linux/arm64kiedy celowo chcesz, aby architektura była jawna.
Błąd formatu execu stanowi wyraźną wskazówkę, że wybrano plik binarny AMD64 w systemie ARM64 bez odpowiedniej ścieżki emulacji.
Następnie usuń tylko uszkodzony kontener i ponownie pobierz obraz. Nie usuwaj trwałych danych, chyba że masz ku temu konkretny powód:
docker compose down
docker image rm collabora/code:latest 2>/dev/null || true
docker pull --platform linux/arm64 collabora/code:latest
docker compose up -d
Jeśli używasz dedykowanego znacznika architektury do uruchomienia diagnostycznego, zastąp go znacznikiem collabora/code:latest-arm64. Po potwierdzeniu, że wdrożenie działa, rozważ przypięcie dokładnego wydania, takiego jak przetestowany znacznik 26.04.x, zamiast pozostawiać system produkcyjny z ruchomym znacznikiem.
Krok 4: Sprawdź, czy CODE uruchamia się przed rozwiązywaniem problemów z integracją
Po ponownym utworzeniu kontenera sprawdź stan i logi:
W przypadku wdrożenia pojedynczego kontenera równoważne polecenia to docker ps -ai docker logs --tail=100 <container-name>.
Poprawiona usługa Compose nie powinna wymuszać linux/amd64 na hoście ARM64. Pozwól na automatyczne rozwiązanie tagu wieloplatformowego lub jawne wybranie linux/arm64 w razie potrzeby.
Pierwszym kryterium sukcesu jest to, że kontener pozostaje aktywny i nie zgłasza już błędu manifestu lub formatu pliku wykonywalnego. Dopiero potem należy przejść do kwestii dostępności portu 9980, ustawień odwrotnego proxy, protokołu TLS, dozwolonych hostów WOPI lub integracji aplikacji. Oficjalna dokumentacja CODE Docker firmy Collabora to właściwe miejsce do weryfikacji bieżących parametrów wdrożenia.
Typowe błędy początkujących, których należy unikać
Instalacja QEMU przed sprawdzeniem oficjalnego obrazu
Emulacja może być przydatna, gdy oprogramowanie istnieje tylko dla innej architektury procesora, ale obecne obrazy Collabora CODE zawierają warianty ARM64. Dodanie emulacji w pierwszej kolejności może ukryć prawdziwy problem i dodać kolejny ruchomy element. Wybierz natywny ARM64, jeśli wymagana wersja CODE go zapewnia.
Zakładając, że „najnowszy” i stary przypięty tag są równoważne
Dostępność platformy jest powiązana z konkretnym tagiem obrazu i manifestem. Aktualny tag może obsługiwać ARM64, podczas gdy starsza wersja nie. Sprawdź dokładne odniesienie w pliku Compose.
Wymuszanie platformy: linux/amd64, ponieważ stary przewodnik jej używał
Może to spowodować, że host ARM64 pobierze wariant x86-64, nawet jeśli istnieje natywny obraz ARM64. Usuń nadpisanie, chyba że masz celowy i sprawdzony powód emulacji.
Zmiana ustawień WOPI, SSL lub proxy przed wykonaniem procesu
Błąd exec format errorwystępuje, zanim Collabora będzie w stanie sensownie przetworzyć większość konfiguracji na poziomie aplikacji. Najpierw popraw wybór architektury. Rozwiązywanie problemów z siecią i WOPI zajmiemy się później.
Usuwanie woluminów podczas diagnostyki
Niezgodności architektoniczne zazwyczaj nie wymagają niszczenia trwałych danych. Zakres naprawy powinien być wąski, aby łatwo było przywrócić poprzednią wersję.
A co jeśli obraz ARM64 nadal istnieje?
Jeśli manifest wyraźnie zawiera linux/arm64ten wariant i Docker go pobiera, architektura nie jest już głównym wyjaśnieniem. W tym momencie przechwyć:
docker compose psLubdocker ps -a
ostatnie 100-200 linii dziennika
dokładny znacznik CODE
Twoje wersje Docker Engine i Compose
nietajne części definicji usługi Compose
Następnie sprawdź uprawnienia, zamontowane ścieżki, profile zabezpieczeń, obciążenie pamięci, konflikty portów, certyfikaty lub konfigurację WOPI zgodnie z rzeczywistym komunikatem w dzienniku. Unikaj wielokrotnego przełączania architektur po upewnieniu się, że obraz działa w architekturze ARM64.
Praktyczna ścieżka decyzyjna
Jeśli host nie jest ARM64, należy zaprzestać stosowania rozwiązania przeznaczonego specjalnie dla ARM64 i zdiagnozować prawdziwą platformę.
Jeśli host jest ARM64, ale wybrany znacznik CODE nie ma manifestu ARM64, przejdź na obsługiwany znacznik natywny lub celowo wybierz inną strategię hostingu.
Jeśli tag obsługuje ARM64, ale Compose wymusza AMD64, usuń lub popraw to platformustawienie.
Jeśli nadal istnieje poprawny obraz ARM64, potraktuj to jako normalny problem z uruchamianiem Collabora i śledź dzienniki, zamiast nadal obwiniać architekturę procesora.
Podsumowanie
W nowoczesnym systemie ARM64 preferowanym rozwiązaniem zazwyczaj nie jest emulacja. Zgodnie z weryfikacją z 7 października 2026 r., aktualne oficjalne tagi Collabora CODE zawierają natywne obrazy ARM64. Potwierdź aarch64/ arm64na hoście, sprawdź dokładny manifest obrazu, usuń nieaktualne lub wymuszone odniesienia do AMD64, ponownie pobierz obraz zgodny z ARM64 i sprawdź, czy kontener nadal działa. Ta sekwencja sprawia, że rozwiązywanie problemów jest przyjazne dla początkujących i zapobiega zamaskowaniu podstawowej niezgodności platformy przez niezwiązane z tym zmiany SSL, proxy lub WOPI.