Remediați problema cu pornirea nereușită a containerului CODE Collabora pe arhitectura ARM64

Dacă un container Collabora Online Development Edition (CODE) se închide imediat pe o mașină ARM64, începeți cu compatibilitatea arhitecturii înainte de a modifica setările de rețea, certificate sau WOPI. Începând cu 7 octombrie 2026, collabora/codedepozitul oficial listează linux/arm64variantele native pentru versiunile curente, inclusiv latesteticheta curentă și versiunea 26.04.4.2.1. Aceasta înseamnă că o gazdă ARM64 modernă nu are nevoie în mod normal de emulare x86 doar pentru a rula CODE. Cel mai util flux de lucru pentru începători este să confirmați arhitectura gazdei, să inspectați eticheta exactă a imaginii, să eliminați orice setare AMD64 forțată, să extrageți o imagine compatibilă cu ARM64 și abia apoi să depanați configurația la nivel de aplicație.

Acest ghid se concentrează pe eșecul de pornire în sine. Nu presupune că fiecare problemă ARM64 are aceeași cauză. Dacă containerul pornește cu succes, dar Nextcloud, ownCloud sau o altă gazdă WOPI nu se poate conecta la acesta, acesta este un alt nivel de depanare.

Ce trebuie să știi înainte de a schimba ceva

ARM64 este o arhitectură de procesor ARM pe 64 de biți. Linux o raportează în mod obișnuit ca aarch64, în timp ce Docker etichetează de obicei aceeași țintă ca linux/arm64. AMD64 , numită și x86-64, este o arhitectură de procesor diferită. O imagine de container conține fișiere binare construite pentru una sau mai multe arhitecturi; Docker poate selecta automat varianta corectă numai atunci când eticheta imaginii oferă un manifest compatibil.

O imagine multi-platformă este o singură etichetă de imagine al cărei manifest de registry indică spre versiuni separate de imagini pentru arhitecturi precum AMD64 și ARM64. Docker documentează faptul că, atunci când este extrasă o imagine multi-platformă, aceasta selectează automat varianta corespunzătoare pentru gazdă. Consultați documentația Docker pentru imagini multi-platformă pentru comportamentul de bază.

Pentru CODE-ul Collabora în mod specific, verificați lista oficială de etichete collabora/code de pe Docker Hub, în ​​loc să vă bazați pe un tutorial vechi. Când acest articol a fost verificat pe 7 octombrie 2026 latestși a fost 26.04.4.2.1inclus linux/arm64, a fost listată și o etichetă dedicată latest-arm64. Versiunile mai vechi fixate pot diferi, așa că eticheta pe care o implementați efectiv contează mai mult decât o afirmație generală conform căreia „Collabora acceptă ARM”.

Pregătiți o sesiune de depanare în siguranță

• Păstrați o copie a comenzii curente docker-compose.ymlsau a celei de implementare.
• Înregistrați eticheta exactă a imaginii Collabora pe care o utilizați.
• Nu ștergeți datele aplicației sau configurația reverse proxy doar pentru a diagnostica o nepotrivire de arhitectură.
• Dacă aceasta este o implementare de producție, testați mai întâi o etichetă de înlocuire într-o fereastră de întreținere sau pe o gazdă de testare.

Rezultatul țintă este simplu: Docker ar trebui să extragă o imagine ARM64, containerul ar trebui să rămână în funcțiune în loc să se închidă imediat, iar jurnalele sale ar trebui să progreseze la pornirea normală Collabora, în loc să eșueze cu o eroare de arhitectură.

Pasul 1: Confirmați arhitectura gazdei și a Docker-ului

Executați aceste verificări pe mașina care rulează efectiv containerul Collabora:

uname -m
docker info --format '{{.Architecture}}'
docker version

Pe o gazdă ARM Linux nativă pe 64 de biți, uname -mreturnează de obicei aarch64, în timp ce Docker ar trebui să raporteze arm64. Aceste nume se referă la aceeași familie de arhitectură în acest context.

Dacă Docker raportează AMD64 chiar dacă mașina fizică este ARM64, determinați dacă utilizați un context Docker la distanță, o mașină virtuală sau Docker Desktop cu un backend diferit. Remediați această ambiguitate înainte de a continua. În caz contrar, este posibil să inspectați un sistem în timp ce implementați pe altul.

Ce eroare indică o nepotrivire de arhitectură?

Semnalele tipice includ exec format error, un mesaj de registry care indică existența no matching manifest for linux/arm64sau un serviciu Compose configurat explicit cu platform: linux/amd64. Aceste mesaje reprezintă o dovadă mai puternică a unei nepotriviri de platformă decât mesajul generic „container exited”.

Pasul 2: Inspectați eticheta exactă a imaginii Collabora înainte de a o extrage

Nu presupuneți că fiecare etichetă istorică are aceeași platformă de suport ca cea actuală latest. Verificați metadatele din registry pentru etichetă în implementarea dvs.:

docker buildx imagetools inspect collabora/code:latest

Documentația buildx imagetools inspect din Docker explică modul în care această comandă afișează platformele conținute într-o imagine de registry. De asemenea, puteți utiliza docker manifest inspect; documentele Docker acea comandă în referința sa de inspecție a manifestului .

Dacă linux/arm64apare , puteți utiliza eticheta multi-platformă și puteți lăsa Docker să selecteze imaginea corectă. Pentru un test explicit de depanare, depozitul oficial listează și latest-arm64. Pentru implementările de producție de lungă durată, o etichetă cu versiune exactă pe care ați testat-o ​​este de obicei mai ușor de reprodus decât latest, deoarece latestse mută pe măsură ce sunt publicate noi versiuni.

Dacă eticheta fixată nu include ARM64, aveți trei opțiuni:

Pasul 3: Eliminați o suprascriere accidentală AMD64 și trageți cu atenție

O eroare frecventă nu este imaginea Collabora în sine, ci un fișier de implementare care forțează platforma greșită. Docker Compose definește platformsistemul de operare țintă și arhitectura utilizată pentru a selecta varianta de imagine. Referința serviciului Compose din Docker arată valori precum linux/arm64/v8.

Pe o gazdă ARM64, această setare este suspectă:

services:
  collabora:
    image: collabora/code:latest
    platform: linux/amd64

Dacă nu aveți nevoie de emulare, eliminați acea linie și lăsați Docker să aleagă varianta nativă a gazdei. Alternativ, specificați platform: linux/arm64când doriți în mod deliberat ca arhitectura să fie explicită.

Apoi eliminați doar containerul defect și extrageți din nou imaginea. Nu ștergeți datele persistente decât dacă aveți un motiv separat pentru a face acest lucru:

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

Dacă utilizați eticheta de arhitectură dedicată pentru o rulare de diagnosticare, înlocuiți-o cu collabora/code:latest-arm64. După ce confirmați că implementarea funcționează, luați în considerare fixarea unei versiuni exacte, cum ar fi o etichetă 26.04.x ​​testată, în loc să lăsați un sistem de producție pe o etichetă mobilă.

Pasul 4: Verificați dacă CODE pornește înainte de a depana integrarea

După recrearea containerului, verificați starea și jurnalele:

docker compose ps
docker compose logs --tail=100 collabora

Pentru o implementare cu un singur container, comenzile echivalente sunt docker ps -ași docker logs --tail=100 <container-name>.

Primul criteriu de succes este ca containerul să rămână activ și să nu mai dea greș cu o eroare de format manifest sau executabil. Abia după aceea ar trebui să treceți la accesibilitatea portului 9980, setările proxy invers, TLS, gazdele WOPI permise sau integrarea aplicațiilor. Documentația oficială CODE Docker de la Collabora este locul potrivit pentru a verifica parametrii actuali de implementare.

Greșeli frecvente de evitat pentru începători

Instalarea QEMU înainte de verificarea imaginii oficiale

Emularea poate fi utilă atunci când există software doar pentru o altă arhitectură CPU, dar imaginile CODE Collabora actuale includ variante ARM64. Adăugarea emulării mai întâi poate ascunde problema reală și poate adăuga o altă componentă mobilă. Preferați ARM64 nativ atunci când versiunea CODE necesară îl oferă.

Presupunând că „cea mai recentă” și o etichetă veche fixată sunt echivalente

Disponibilitatea platformei este atașată unei anumite etichete de imagine și unui manifest. O etichetă curentă poate accepta ARM64, în timp ce o versiune mai veche nu. Verificați referința exactă în fișierul Compose.

Platformă forțată: linux/amd64 deoarece un ghid vechi îl folosea

Asta poate face ca o gazdă ARM64 să extragă varianta x86-64 chiar și atunci când există o imagine ARM64 nativă. Eliminați suprascrierea, cu excepția cazului în care aveți un motiv deliberat și testat pentru emulare.

Modificarea setărilor WOPI, SSL sau proxy înainte ca procesul să poată fi executat

Se întâmplă ceva exec format errorînainte ca Collabora să poată procesa în mod semnificativ majoritatea configurațiilor la nivel de aplicație. Mai întâi, corectați selecția arhitecturii. Depanarea rețelei și a problemelor WOPI vor avea loc ulterior.

Ștergerea volumelor în timpul diagnosticării

Neconcordanțele de arhitectură nu necesită, în mod normal, distrugerea datelor persistente. Mențineți domeniul de aplicare al remedierii restrâns, astfel încât revenirea la versiunea inițială să rămână ușoară.

Ce se întâmplă dacă imaginea ARM64 încă există?

Dacă manifestul include în mod clar linux/arm64acea variantă și Docker o extrage, arhitectura nu mai este explicația principală. În acel moment, capturați:

• docker compose pssaudocker ps -a
• ultimele 100-200 de linii de jurnal
• eticheta CODE exactă
• versiunile dvs. Docker Engine și Compose
• părțile nesecrete ale definiției serviciului Compose

Apoi investigați permisiunile, căile montate, profilurile de securitate, presiunea memoriei, conflictele de porturi, certificatele sau configurația WOPI conform mesajului de jurnal real. Evitați schimbarea repetată a arhitecturilor odată ce ați verificat că imaginea care rulează este ARM64.

O cale practică de decizie

1. Dacă gazda nu este ARM64, nu mai utilizați o corecție specifică ARM64 și diagnosticați platforma reală.
2. Dacă gazda este ARM64, dar eticheta CODE aleasă nu are un manifest ARM64, treceți la o etichetă nativă acceptată sau alegeți în mod deliberat o strategie de găzduire diferită.
3. Dacă eticheta acceptă ARM64, dar Compose impune AMD64, eliminați sau corectați setarea platform.
4. Dacă imaginea ARM64 corectă încă există, tratați-o ca pe o problemă normală de pornire Collabora și urmați jurnalele în loc să continuați să dați vina pe arhitectura procesorului.

Concluzie

Pe un sistem ARM64 modern, soluția preferată nu este de obicei emularea. După cum s-a verificat pe 7 octombrie 2026, etichetele oficiale actuale Collabora CODE includ imagini ARM64 native. Confirmați aarch64/ arm64pe gazdă, inspectați manifestul exact al imaginii, eliminați referințele AMD64 învechite sau forțate, reintroduceți imaginea compatibilă cu ARM64 și verificați dacă containerul continuă să ruleze. Această secvență face depanarea ușor de utilizat pentru începători și previne modificările SSL, proxy sau WOPI fără legătură să ascundă o nepotrivire de bază a platformei.