ติดตั้ง Collabora CODE บนสถาปัตยกรรม ARM64 ด้วยอิมเมจที่ถูกต้อง

คอนเทนเนอร์ Collabora CODE ที่หยุดทำงานทันทีบนโฮสต์ ARM64 มักเกิดจากการใช้แพลตฟอร์มรูปภาพที่ไม่ถูกต้อง แต่ ARM64 นั้นไม่ได้ไม่ได้รับการสนับสนุนโดยเนื้อแท้ เริ่มต้นด้วยการตรวจสอบบิตของโฮสต์ รายการแสดงรายละเอียด (manifest) ของแท็กรูปภาพที่ใช้ และการตั้งค่าแพลตฟอร์มใดๆ ของ Compose ก่อนที่จะเปลี่ยนแปลงสิทธิ์หรือสร้างรูปภาพใหม่ จากการตรวจสอบเมื่อวันที่ 10 ตุลาคม 2026 รูปภาพ CODE อย่างเป็นทางการมีเวอร์ชันสำหรับ ARM64 ด้วย โดย Docker Hub จะแสดงแท็26.04.4.2.1กสำหรับ ARM64 ไว้linux/arm64

1. ระบุสถาปัตยกรรมของโฮสต์และข้อผิดพลาดในการเริ่มต้นระบบอย่างแม่นยำ

เรียกใช้คำสั่งเหล่านี้บนโฮสต์ Docker ไม่ใช่ภายในคอนเทนเนอร์ Collabora ที่หยุดทำงานแล้ว เปลี่ยนcollaboraชื่อบริการ Compose ของคุณหากใช้ชื่ออื่น:

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

โดยทั่วไปแล้ว โฮสต์ Linux ARM 64 บิตจะรายงานข้อมูลaarch64จากuname -mค่าเช่นarmv7lมักจะระบุแพลตฟอร์มเคอร์เนล ARM 32 บิต ซึ่งแตกต่างจากlinux/arm64ป้ายกำกับสถาปัตยกรรมของ Docker อาจใช้การสะกดที่แตกต่างกัน ดังนั้นควรเปรียบเทียบประเภทโฮสต์ การกำหนดค่า Compose และไฟล์ manifest ของอิมเมจ แทนที่จะจับคู่สตริงใดสตริงหนึ่งโดยอัตโนมัติ

อ่านข้อความแสดงข้อผิดพลาดร้ายแรงข้อแรกและสถานะการออกจากโปรแกรม “No matching manifest for linux/arm64” หมายความว่าแท็กที่เลือกไม่มีตัวเลือกที่ตรงกันสำหรับแพลตฟอร์มที่ร้องขอ “Exec format error” บ่งชี้ถึงความไม่ตรงกันของสถาปัตยกรรมหรือการบังคับใช้แพลตฟอร์มภายนอกโดยชัดเจน ข้อผิดพลาดด้านสิทธิ์หรือการหยุดทำงานเนื่องจากหน่วยความจำไม่เพียงพอมีสาเหตุที่แตกต่างกัน อย่าถือว่าการวนลูปการเริ่มต้นใหม่ทุกครั้งเป็นความล้มเหลวในการเข้ากันได้กับ ARM

2. ตรวจสอบว่าแท็กดังกล่าวเผยแพร่ภาพ ARM64 หรือไม่

ตรวจสอบแท็กในรีจิสทรี ก่อนทำการเปลี่ยนแปลงโฮสต์:

docker buildx imagetools inspect collabora/code:26.04.4.2.1

มองหาlinux/arm64ในรายการแพลตฟอร์ม ในวันที่ 10 ตุลาคม 2026 รายการแท็กอย่างเป็นทางการของ Docker Hubแสดงแพลตฟอร์มสำหรับทั้งสองlatestแบบหน้า CODE26.04.4.2.1ของ Collabora ระบุว่า x86-64, ppc64 และ arm64 เป็นสถาปัตยกรรมโฮสต์ที่รองรับ แท็กที่มีเวอร์ชันจะช่วยให้ตรวจสอบปัญหาได้ง่ายขึ้น แท็กและไฟล์ Manifest อาจมีการเปลี่ยนแปลง ดังนั้นควรตรวจสอบเวอร์ชันที่แน่นอนที่คุณวางแผนจะใช้งานแทนที่จะคิดว่าแท็กเก่าทุกแท็กมีสถาปัตยกรรมเดียวกัน

Docker จะเลือกตัวเลือกที่ตรงกันโดยอัตโนมัติเมื่อแท็กเป็นแบบหลายแพลตฟอร์มและไม่มีการเปลี่ยนแปลงการกำหนดค่าเป้าหมายคำสั่งตรวจสอบอิมเมจ ของ Docker จะแสดงแพลตฟอร์มที่เผยแพร่สำหรับอิมเมจรีจิสทรี

3. ลบการตั้งค่า AMD64 override ออก แล้วดึงเวอร์ชันเนทีฟมาใช้

ตรวจสอบบริการ Compose ที่ได้รับการแก้ไขแล้ว รวมถึงไฟล์ override เพื่อหาการบังคับplatform: linux/amd64ตัวแปร Docker CLI DOCKER_DEFAULT_PLATFORMยังสามารถตั้งค่าแพลตฟอร์มเริ่มต้นสำหรับคำสั่งที่ยอมรับแฟล็กแพลตฟอร์มได้platformฟิลด์ของ Compose จะเลือกเป้าหมายระบบปฏิบัติการและสถาปัตยกรรมอย่างชัดเจน ดังนั้นให้ลบ override ที่ไม่ถูกต้องออกหรือตั้งค่าเป็น ARM64 หากคุณมี ให้jqตรวจสอบการตั้งค่าที่รวมกันโดยไม่ต้องพิมพ์ค่าสภาพแวดล้อมที่ไม่เกี่ยวข้อง: docker compose config --format json | jq '.services.collabora | {image, platform}'เอกสารอ้างอิงบริการ Composeกำหนดฟิลด์นี้ไว้DOCKER_DEFAULT_PLATFORMมีการบันทึกไว้ใน เอกสารอ้างอิง Docker CLI

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

นี่คือส่วนหนึ่ง: ผสานบรรทัดรูปภาพและแพลตฟอร์มเข้ากับบริการที่มีอยู่ของคุณ และคงการตั้งค่าที่จำเป็นไว้ หาก Docker เลือก manifest ARM64 ดั้งเดิมได้อย่างถูกต้องแล้วplatformบรรทัดนี้จะเป็นตัวเลือก แทนที่collaboraในคำสั่งด้านล่างหากบริการ Compose ของคุณมีชื่ออื่น

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

ใช้แท็กที่ตรึงไว้ตามที่แสดง หรือใช้เวอร์ชันอื่นที่คุณเพิ่งตรวจสอบไฟล์ Manifest แล้วlatest-arm64แท็กนี้ยังแสดงอยู่ใน Docker Hub ด้วย แต่เนื้อหาจะเปลี่ยนแปลงไปตามการเปลี่ยนแปลงของเวอร์ชัน การตรึงเวอร์ชันจะทำให้การย้อนกลับและการเปรียบเทียบในภายหลังคาดการณ์ได้ง่ายขึ้น หลีกเลี่ยงการบังคับใช้linux/amd64การจำลองเป็นวิธีแก้ไขแรกเมื่อมีอิมเมจ ARM64 ดั้งเดิมให้ใช้งาน การจำลองจะเพิ่มภาระและทำให้การวินิจฉัยการเริ่มต้นระบบไม่ตรงไปตรงมา

4. วินิจฉัยความล้มเหลวที่ไม่เกี่ยวข้องกับสถาปัตยกรรม จากนั้นตรวจสอบการเริ่มต้นระบบ

หากอิมเมจดั้งเดิมยังคงอยู่ ให้ใช้บันทึกและสถานะแทนการขยายสิทธิ์ของคอนเทนเนอร์:

ใช้ชื่อหรือรหัสคอนเทนเนอร์ที่แสดง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ผ่าน URL ของ Collabora ที่กำหนดค่าไว้และเปิดเอกสารทดสอบ ตรวจสอบรายการแท็กของรีจิสทรีอีกครั้งก่อนการอัปเกรด เนื่องจากเวอร์ชันที่มีอยู่และไฟล์แสดงรายการแพลตฟอร์มอาจเปลี่ยนแปลงได้