เมื่อสองสามวันที่ผ่านมา มีการตัดสินใจในเซิร์ฟเวอร์ตัวใดตัวหนึ่งให้ย้ายที่เก็บข้อมูลนักเทียบท่า (ไดเร็กทอรีที่นักเทียบท่าเก็บไฟล์คอนเทนเนอร์และไฟล์รูปภาพทั้งหมด) ไปยังส่วนที่แยกต่างหาก ซึ่ง
มีความจุมากขึ้น งานดูเหมือนเล็กน้อยและไม่ได้บอกปัญหาล่วงหน้า...
มาเริ่มกันเลย:
1. หยุดและฆ่าคอนเทนเนอร์ทั้งหมดของแอปพลิเคชันของเรา:
docker-compose downหากมีภาชนะจำนวนมากและมีองค์ประกอบต่างกัน คุณสามารถทำได้:
docker rm -f $(docker ps -q)2. หยุดนักเทียบท่าดีมอน:
systemctl stop docker3. ย้ายไดเร็กทอรีไปยังตำแหน่งที่ต้องการ:
cp -r /var/lib/docker /docker/data/storage4. เราบอกให้ docker daemon ค้นหาในไดเร็กทอรีใหม่ มีหลายตัวเลือก: ใช้แฟล็ก -g เพื่อชี้ daemon ไปยังเส้นทางใหม่ หรือใช้การกำหนดค่า systemd ซึ่งเราใช้ หรือซิมลิงค์ ฉันจะไม่ลงรายละเอียดมากเกินไปเกี่ยวกับเรื่องนี้ มันอยู่บนอินเทอร์เน็ต คู่มือการย้าย docker root ไปยังตำแหน่งใหม่
5. เริ่ม docker daemon และตรวจสอบให้แน่ใจว่าอยู่ในตำแหน่งที่ถูกต้อง:
systemctl status dockerในบรรทัดเอาต์พุตบรรทัดใดบรรทัดหนึ่งเราควรเห็น:
├─19493 /usr/bin/dockerd --data-root=/docker/data/storageเราทำให้แน่ใจว่าตัวเลือกนั้นถูกส่งไปที่ daemon แล้ว ตอนนี้เรามาตรวจสอบว่ามันใช้งานได้หรือไม่ (ขอบคุณ )!
docker info | awk '/Root Dir/ {print $NF}' 6. มาเริ่มแอปพลิเคชันของเรากัน:
docker-compose up -d7. ตรวจสอบ
และความสนุกก็เริ่มต้นขึ้น DBMS, MQ ทุกอย่างเรียบร้อยดี! ฐานข้อมูลไม่เสียหาย ทุกอย่างทำงานได้... ยกเว้น nginx เรามี nginx build ของเราเองพร้อมกับ Kerberos และโสเภณี และการดูบันทึกของคอนเทนเนอร์ระบุว่าไม่สามารถเขียนไปที่ /var/tmp - Permission ถูกปฏิเสธ ฉันนวดขมับด้วยมือแล้วพยายามวิเคราะห์สถานการณ์... เป็นไปได้อย่างไร? รูปภาพนักเทียบท่าไม่เปลี่ยนแปลง เราเพิ่งย้ายไดเร็กทอรี มันได้ผลเสมอและนี่คือเพื่อคุณ... เพื่อประโยชน์ในการทดลองฉันเข้าไปในคอนเทนเนอร์ด้วยมือของฉันและเปลี่ยนสิทธิ์ในไดเร็กทอรีนี้มีอยู่ รูท, รูท 755, ให้ รูท, รูท 777. และทุกอย่างเริ่มต้นขึ้น... ความคิดเริ่มดังขึ้นในหัวของฉัน - เรื่องไร้สาระบางอย่าง... ฉันคิดว่าบางทีฉันอาจจะไม่ได้คำนึงถึงบางสิ่งบางอย่าง...
ฉันตัดสินใจว่าเราหลงรักสิทธิ์การเข้าถึงไฟล์ระหว่างการถ่ายโอน เราหยุดแอปพลิเคชัน docker daemon ลบไดเร็กทอรีใหม่และคัดลอกไดเร็กทอรี /var/lib/docker โดยใช้ rsync -a.
ฉันคิดว่าทุกอย่างเรียบร้อยดีแล้ว มายกระดับแอปพลิเคชัน Docker กันดีกว่า
อ่า... ปัญหายังคงอยู่... ตาของฉันกระตุก ฉันรีบไปที่คอนโซลของเครื่องเสมือนของฉัน ซึ่งฉันทำการทดสอบต่างๆ ฉันมีอิมเมจ nginx นี้ และฉันก็ปีนเข้าไปในคอนเทนเนอร์ และนี่คือสิทธิ์ในไดเร็กทอรี /var/tmp คือ root, root 777 นั่นคือ เช่นเดียวกับที่ฉันต้องตั้งค่าด้วยตนเอง แต่ภาพเหมือนกัน!
ระบบไฟล์ xfs ถูกใช้ทุกที่
ฉันเปรียบเทียบโดยใช้คำสั่ง
docker inspect my-nginx:12345แฮชทั้งหมดเหมือนกันทั้งหมดแบบหนึ่งต่อหนึ่ง ทั้งบนเซิร์ฟเวอร์และบนเครื่องเสมือนของฉัน ฉันลบอิมเมจ nginx ในเครื่องแล้วดึงมันอีกครั้งจากรีจิสตรี ซึ่งด้วยเหตุผลหลายประการจึงอยู่ในเครื่องเดียวกัน แล้วปัญหาก็เหมือนเดิม...ตอนนี้ตาอีกข้างกระตุกแล้ว
ฉันจำไม่ได้อีกแล้วว่าคิดอะไรอยู่ในหัว นอกจากตะโกนว่า “อ๊ายยยยย” และอื่นๆ อีกมากมาย เป็นเวลาตี 4 และใช้ซอร์สโค้ด Docker เพื่อทำความเข้าใจหลักการของการแฮชเลเยอร์รูปภาพ เปิดเครื่องดื่มชูกำลังกระป๋องที่สาม และในท้ายที่สุดฉันก็เข้าใจได้ว่าการแฮชจะคำนึงถึงไฟล์และเนื้อหาของมันเท่านั้น ไม่ใช่สิทธิ์การเข้าถึง! นั่นคือสิทธิ์ของเราสูญเสียไปในทางลึกลับ selinux ถูกปิดใช้งาน ไม่ได้ใช้ acl และไม่มีบิตเหนียว
ฉันลบอิมเมจในเครื่องแล้ว ลบอิมเมจออกจากรีจิสทรีนักเทียบท่าด้วยแล้วดันอีกครั้ง และทุกอย่างได้ผล ปรากฎว่าในระหว่างการถ่ายโอนสิทธิ์หายไปทั้งภายในรูปภาพในเครื่องและภายในรูปภาพที่อยู่ในรีจิสทรี อย่างที่ฉันบอกไปแล้วด้วยเหตุผลหลายประการว่าทำไมมันถึงอยู่บนรถคันเดียวกัน และเป็นผลให้อยู่ในไดเร็กทอรีเดียว /var/lib/docker
และคาดการณ์คำถามว่าพวกเขาพยายามที่จะคืนสายตาของนักเทียบท่าไปยังไดเร็กทอรีเก่าหรือไม่ - ไม่พวกเขาไม่ได้ลอง แต่อนิจจาสถานการณ์ไม่เอื้ออำนวย ใช่ และฉันอยากจะคิดออกจริงๆ
หลังจากเขียนบทความนี้ ดูเหมือนว่าวิธีแก้ปัญหาจะชัดเจนสำหรับฉัน แต่ในขณะที่วิเคราะห์ดูเหมือนจะไม่เป็นเช่นนั้น จริงๆ แล้วฉัน Googled และไม่พบสถานการณ์ที่คล้ายกัน
ผลลัพธ์: ฉันแก้ไขปัญหาแล้ว แต่ยังไม่เข้าใจเหตุผล =(
หากใครรู้เดามีวิสัยทัศน์เกี่ยวกับสาเหตุที่เป็นไปได้ของปัญหานี้ฉันยินดีอย่างยิ่งที่ได้รับฟังจากคุณในความคิดเห็น!
ที่มา: will.com