היסטוריה של בעיית הגירה של אחסון docker (שורש docker)

לפני לא יותר מיומיים, הוחלט באחד השרתים להעביר את אחסון docker (הספרייה שבה מאחסן docker את כל קבצי הקונטיינר והתמונה) למקטע נפרד, אשר
היה בעל יכולת גדולה יותר. המשימה נראתה טריוויאלית ולא ניבאה צרות...

תחילת העבודה:

1. עצור והרוג את כל המיכלים של האפליקציה שלנו:

docker-compose down

אם יש הרבה מיכלים והם בהרכבים שונים, אתה יכול לעשות זאת:

docker rm -f $(docker ps -q)

2. עצור את דמון הדוקר:

systemctl stop docker

3. העבר את הספרייה למיקום הרצוי:

cp -r /var/lib/docker /docker/data/storage

4. אנו אומרים לדמון הדוקר לחפש בספרייה החדשה. ישנן מספר אפשרויות: או להשתמש בדגל -g כדי לכוון את הדמון לנתיב חדש, או בתצורות systemd, שבהן השתמשנו. או קישור סימלי. אני לא אפרט יותר מדי על זה, זה באינטרנט. מלא מדריכים להעברת Docker root למיקום חדש.

5. הפעל את דמון הדוקר וודא שהוא נראה במקום הנכון:

systemctl status docker

באחד מקווי הפלט עלינו לראות:

├─19493 /usr/bin/dockerd --data-root=/docker/data/storage

וידאנו שהאפשרות הועברה לדמון, עכשיו בואו נבדוק אם היא החלה אותה (תודה inkvizitor68sl)!

docker info | awk '/Root Dir/ {print $NF}' 

6. בואו נתחיל את היישום שלנו:

docker-compose up -d

7. בדוק

והנה מתחיל הכיף, DBMS, MQ, הכל בסדר! מסד הנתונים שלם, הכל עובד... חוץ מ-nginx. יש לנו בניית nginx משלנו עם Kerberos וקורטיזניות. וצפייה ביומני המאגר ציינה שהוא לא יכול לכתוב ל-/var/tmp - ההרשאה נדחתה. אני לשה את הרקות באצבעותיי ומנסה לנתח את המצב... איך זה אפשרי? תמונת Docker לא השתנתה. הרגע העברנו את הספרייה. זה תמיד עבד, והנה זה בשבילכם... לצורך הניסוי, נכנסתי עם הידיים למיכל ושיניתי את הזכויות למדריך הזה, היו שורש, שורש 755, נתן שורש, שורש 777. והכל התחיל... התחילה להישמע מחשבה בראשי - איזו שטות... חשבתי, טוב, אולי לא לקחתי בחשבון משהו...

החלטתי שהתאהבנו בזכויות הגישה לקבצים במהלך ההעברה. עצרנו את היישום, הדמון docker, מחקנו את הספרייה החדשה והעתקנו את ספריית /var/lib/docer באמצעות rsync -a.

אני חושב שהכל בסדר עכשיו, בואו נעלה את אפליקציית Docker.

אה... הבעיה נשארה... העין שלי התעוותה. מיהרתי לקונסולה של המחשב הוירטואלי שלי, שם אני מריץ בדיקות שונות, הייתה לי תמונת nginx זו, וטיפסתי בתוך הקונטיינר, וכאן הזכויות לספריית /var/tmp הן root, root 777. כלומר, כמו שהייתי צריך להגדיר ידנית. אבל התמונות זהות!

מערכת הקבצים xfs הייתה בשימוש בכל מקום.

השוויתי באמצעות הפקודה

docker inspect my-nginx:12345

כל הגיבובים זהים, כולם אחד לאחד. גם בשרת וגם במכונה הוירטואלית שלי. מחקתי את תמונת ה-nginx המקומית ושלפתי אותה שוב מהרישום, אשר ממספר סיבות נמצא באותו מחשב. והבעיה זהה... עכשיו העין השנייה שלי מתעוותת.

אני כבר לא זוכר אילו מחשבות היו בראשי, חוץ מלצעוק "AAAAAAAAAA" ודברים אחרים. השעה הייתה 4 לפנות בוקר, וקוד המקור של Docker שימש להבנת העיקרון של גיבוב שכבות תמונה. פתח את פחית משקה האנרגיה השלישית. ובסוף התחוור לי ש-hashing רק לוקח בחשבון את הקובץ, את התוכן שלו, אבל לא זכויות גישה! כלומר, בדרך מסתורית כלשהי הזכויות שלנו אבדו, selinux מושבת, לא נעשה שימוש ב-acl, ואין קטע דביק.

מחקתי את התמונה המקומית, מחקתי גם את התמונה מה-docer registry ודחפתי אותה שוב. והכל עבד. מסתבר שבמהלך ההעברה אבדו הזכויות, הן בתוך התמונה המקומית והן בתוך התמונה המונחת ברישום. כפי שכבר אמרתי, מכמה סיבות הוא היה ממוקם על אותה מכונית. וכתוצאה מכך, בספרייה אחת /var/lib/docer.

ולצפות לשאלה אם ניסו להחזיר את מבטו של הדוקר למדריך הישן - לא, הם לא ניסו, אבוי, הנסיבות לא אפשרו זאת. כן, ובאמת רציתי להבין את זה.

לאחר כתיבת מאמר זה, הפתרון לבעיה נראה לי מובן מאליו, אך בזמן הניתוח זה לא נראה כך. בכנות, חיפשתי בגוגל ולא מצאתי מצבים דומים.

תוצאה: פתרתי את הבעיה, אני עדיין לא מבין את הסיבה =(

אם למישהו יודע, מנחש, היה חזון לגבי הגורמים האפשריים לבעיה זו, אשמח מאוד לשמוע מכם בתגובות!

מקור: www.habr.com