Accueil
» BUREAU MS
»
Résolution du problème de démarrage du conteneur Collabora CODE sur l'architecture ARM64
Résolution du problème de démarrage du conteneur Collabora CODE sur l'architecture ARM64
Si un conteneur Collabora Online Development Edition (CODE) s'arrête immédiatement sur une machine ARM64, commencez par vérifier la compatibilité architecturale avant de modifier les paramètres réseau, les certificats ou WOPI. À compter du 7 octobre 2026, le collabora/codedépôt officiel répertorie linux/arm64les variantes natives pour les versions actuelles, y compris l'étiquette actuelle latestet la version 26.04.4.2.1. Cela signifie qu'un hôte ARM64 moderne n'a généralement pas besoin d'émulation x86 pour exécuter CODE. La méthode la plus simple pour les débutants consiste à vérifier l'architecture de l'hôte, à examiner l'étiquette exacte de l'image, à supprimer tout paramètre AMD64 forcé, à télécharger une image compatible ARM64, puis à résoudre les problèmes de configuration au niveau de l'application.
Ce guide se concentre sur l'échec de démarrage lui-même. Il ne part pas du principe que tous les problèmes ARM64 ont la même cause. Si le conteneur démarre correctement mais que Nextcloud, ownCloud ou un autre hôte WOPI ne parvient pas à s'y connecter, le dépannage relève d'un autre domaine.
Ce que vous devez savoir avant de changer quoi que ce soit
ARM64 est une architecture de processeur ARM 64 bits. Linux la désigne généralement par `ARM64` aarch64, tandis que Docker utilise généralement `AMD64` linux/arm64. AMD64 , également appelée x86-64, est une architecture de processeur différente. Une image de conteneur contient des binaires compilés pour une ou plusieurs architectures ; Docker peut sélectionner automatiquement la variante appropriée uniquement si l'étiquette de l'image fournit un manifeste compatible.
Une image multiplateforme est une image unique dont le manifeste de registre pointe vers des versions distinctes pour des architectures telles que AMD64 et ARM64. Docker indique que, lors du téléchargement d'une image multiplateforme, la variante correspondant à l'hôte est sélectionnée automatiquement. Pour plus d'informations sur ce fonctionnement, consultez la documentation Docker relative aux images multiplateformes .
Pour Collabora CODE en particulier, consultez la liste officielle des tags collabora/code sur Docker Hub plutôt que de vous fier à un ancien tutoriel. Lors de la vérification de cet article le 7 octobre 2026, latestune étiquette dédiée était également 26.04.4.2.1présente . Les versions plus anciennes peuvent différer ; par conséquent, l’étiquette que vous déployez réellement est plus importante qu’une simple affirmation comme « Collabora prend en charge ARM ».linux/arm64latest-arm64
Préparez une session de dépannage sécurisée
Conservez une copie de votre docker-compose.ymlcommande actuelle ou de votre commande de déploiement.
Notez la balise d'image Collabora exacte que vous utilisez.
Ne supprimez pas les données de l'application ni la configuration du proxy inverse dans le seul but de diagnostiquer une incompatibilité d'architecture.
S'il s'agit d'un déploiement en production, testez d'abord une étiquette de remplacement pendant une fenêtre de maintenance ou sur un hôte de préproduction.
Le résultat attendu est simple : Docker doit extraire une image ARM64, le conteneur doit rester en cours d’exécution au lieu de s’arrêter immédiatement, et ses journaux doivent indiquer la progression normale du démarrage de Collabora au lieu d’échouer avec une erreur d’architecture.
Étape 1 : Confirmer l’architecture hôte et Docker
Exécutez ces vérifications sur la machine qui exécute le conteneur Collabora :
uname -m
docker info --format '{{.Architecture}}'
docker version
Sur un hôte Linux ARM 64 bits natif, uname -mla commande renvoie généralement aarch64, tandis que Docker devrait renvoyer arm64. Ces noms font référence à la même famille d'architectures dans ce contexte.
Vérifiez d'abord l'architecture du système d'exploitation et du démon Docker. Un hôte ARM64 natif apparaît généralement comme aarch64 sous Linux et comme arm64 dans Docker.
Si Docker indique AMD64 alors que la machine physique est ARM64, vérifiez si vous utilisez un contexte Docker distant, une machine virtuelle ou Docker Desktop avec un autre moteur graphique. Clarifiez cette ambiguïté avant de poursuivre. Sinon, vous risquez d'inspecter un système tout en déployant sur un autre.
Quelle erreur indique une incompatibilité d'architecture ?
Les signaux typiques incluent exec format errorun message du registre indiquant la présence d'un conteneur no matching manifest for linux/arm64ou un service Compose explicitement configuré avec une configuration spécifique platform: linux/amd64. Ces messages constituent une preuve plus solide d'une incompatibilité de plateforme que la sortie générique « conteneur arrêté ».
Étape 2 : Examinez la balise image Collabora exacte avant de la récupérer.
Ne présumez pas que chaque étiquette historique bénéficie de la même prise en charge des plateformes qu'aujourd'hui latest. Consultez les métadonnées du registre pour l'étiquette de votre déploiement :
Examinez le manifeste de l'image et recherchez spécifiquement linux/arm64. Les étiquettes CODE officielles actuelles peuvent être multiplateformes, mais une étiquette plus ancienne et épinglée peut ne pas l'être.
Si linux/arm64une image apparaît, vous pouvez utiliser l'étiquette multiplateforme et laisser Docker sélectionner l'image appropriée. Pour un test de dépannage explicite, le dépôt officiel fournit également une liste d'images latest-arm64. Pour les déploiements en production de longue durée, il est généralement plus facile de reproduire une image avec une version précise que vous avez testée que l'étiquette latest, car latestcette dernière est mise à jour lors de la publication de nouvelles versions.
Si votre étiquette épinglée n'inclut pas ARM64, vous avez trois choix :
Choix
Meilleure adaptation
Compromis
Déplacer vers une balise de code ARM64 native actuelle
La plupart des serveurs ARM64 et des laboratoires domestiques
Vous devez valider la compatibilité de la version et vos paramètres d'intégration.
Restez sur l'ancienne version en utilisant l'émulation AMD64
Tests de compatibilité à court terme
Complexité accrue et possible surcharge de performances ; solution non privilégiée lorsqu'une image native existe.
Conservez l'ancienne version sur un hôte AMD64
Le verrouillage strict des versions lorsque le risque de mise à niveau est inacceptable
Nécessite une capacité matérielle ou de machine virtuelle différente
Étape 3 : Supprimez toute surcharge AMD64 accidentelle et retirez-la proprement.
Une erreur fréquente ne provient pas de l'image Collabora elle-même, mais d'un fichier de déploiement qui force une plateforme incorrecte. Docker Compose définit platformle système d'exploitation cible et l'architecture utilisés pour sélectionner la variante d'image. La documentation du service Docker Compose présente des valeurs telles quelinux/arm64/v8 :
Si l'émulation n'est pas nécessaire, supprimez cette ligne et laissez Docker choisir la variante native de l'hôte. Sinon, spécifiez-la explicitement platform: linux/arm64lorsque vous souhaitez que l'architecture soit clairement définie.
Une erreur de format d'exécution est un indice fort qu'un binaire AMD64 a été sélectionné sur un système ARM64 sans chemin d'émulation approprié.
Supprimez ensuite uniquement le conteneur défaillant et téléchargez à nouveau l'image. Ne supprimez pas les données persistantes, sauf si vous avez une raison particulière de le faire.
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
Si vous utilisez l'étiquette d'architecture dédiée pour un diagnostic, remplacez-la par collabora/code:latest-arm64. Une fois le déploiement validé, il est conseillé de spécifier une version précise, par exemple une étiquette 26.04.x testée, plutôt que de laisser un système de production sur une étiquette variable.
Étape 4 : Vérifiez que CODE démarre avant de procéder au dépannage de l’intégration.
Après avoir recréé le conteneur, vérifiez son état et ses journaux :
Pour un déploiement à conteneur unique, les commandes équivalentes sont docker ps -aet docker logs --tail=100 <container-name>.
Un service Compose corrigé ne devrait pas imposer linux/amd64 sur un hôte ARM64. Laissez la balise multiplateforme se résoudre automatiquement, ou choisissez explicitement linux/arm64 lorsque cela est nécessaire.
Le premier critère de réussite est que le conteneur reste opérationnel et ne rencontre plus d'erreur liée au manifeste ou au format de l'exécutable. Ce n'est qu'après cela que vous pourrez vous pencher sur l'accessibilité du port 9980, les paramètres du proxy inverse, le protocole TLS, les hôtes WOPI autorisés ou l'intégration de l'application. La documentation officielle de Collabora CODE Docker est la source d'information idéale pour vérifier les paramètres de déploiement actuels.
Erreurs courantes à éviter chez les débutants
Installer QEMU avant de vérifier l'image officielle
L'émulation peut s'avérer utile lorsque le logiciel n'existe que pour une autre architecture de processeur, mais les images Collabora CODE actuelles incluent des variantes ARM64. Ajouter l'émulation en premier lieu risque de masquer le véritable problème et complexifie la situation. Privilégiez l'architecture ARM64 native si votre version de CODE le prend en charge.
En supposant que « dernière » et une ancienne étiquette épinglée soient équivalentes
La disponibilité sur une plateforme est associée à une balise d'image et à un manifeste spécifiques. Une balise récente peut prendre en charge ARM64, contrairement à une version plus ancienne. Consultez la référence exacte dans votre fichier Compose.
Plateforme forcée : linux/amd64 car un ancien guide l'utilisait.
Cela peut amener un hôte ARM64 à utiliser la variante x86-64 même si une image ARM64 native existe. Supprimez la substitution, sauf si vous avez une raison valable et testée d'émuler cette configuration.
Modifier les paramètres WOPI, SSL ou proxy avant que le processus puisse s'exécuter
Un exec format errorproblème survient avant que Collabora puisse traiter efficacement la plupart des configurations applicatives. Commencez par corriger le choix de l'architecture. Le dépannage réseau et WOPI interviendra plus tard.
Suppression de volumes pendant le diagnostic
Les incompatibilités d'architecture ne nécessitent généralement pas la suppression des données persistantes. Limitez la portée de la correction afin de faciliter la restauration.
Que se passe-t-il si l'image ARM64 existe toujours ?
Si le manifeste inclut clairement linux/arm64cette variante et que Docker la récupère, l'architecture n'est plus l'explication principale. À ce stade, capturez :
docker compose psoudocker ps -a
les 100 à 200 dernières lignes de journal
la balise CODE exacte
vos versions de Docker Engine et Compose
les parties non secrètes de votre définition de service Compose
Examinez ensuite les permissions, les chemins montés, les profils de sécurité, la charge mémoire, les conflits de ports, les certificats et la configuration WOPI en fonction du message du journal. Évitez de changer d'architecture à répétition une fois que vous avez vérifié que l'image en cours d'exécution est ARM64.
Un chemin de décision pratique
Si l'hôte n'est pas ARM64, cessez d'utiliser un correctif spécifique à ARM64 et diagnostiquez la plateforme réelle.
Si l'hôte est ARM64 mais que la balise CODE choisie ne comporte pas de manifeste ARM64, passez à une balise native prise en charge ou choisissez délibérément une stratégie d'hébergement différente.
Si l'étiquette prend en charge ARM64 mais que Compose force AMD64, supprimez ou corrigez le platformparamètre.
Si l'image ARM64 correcte existe toujours, traitez-la comme un problème de démarrage normal de Collabora et suivez les journaux plutôt que de continuer à incriminer l'architecture du processeur.
En résumé
Sur un système ARM64 moderne, l'émulation n'est généralement pas la solution privilégiée. Comme vérifié le 7 octobre 2026, les étiquettes officielles actuelles de Collabora CODE incluent des images ARM64 natives. Sur l'hôte, vérifiez la présence aarch64de arm64l'image, examinez son manifeste, supprimez les références AMD64 obsolètes ou forcées, téléchargez à nouveau l'image compatible ARM64 et assurez-vous que le conteneur reste en cours d'exécution. Cette procédure simplifie le dépannage pour les débutants et évite que des modifications sans rapport avec le problème (SSL, proxy ou WOPI) ne masquent une incompatibilité de plateforme.