في موعد لا يتجاوز يومين قبل ذلك ، تقرر على أحد الخوادم نقل وحدة تخزين عامل الرصيف (الدليل حيث يقوم عامل التخزين بتخزين جميع ملفات الحاويات والصور) إلى قسم منفصل ، والذي
تمتلك المزيد من القدرات. يبدو أن المهمة تافهة ولم تنذر بالمتاعب ...
البدء:
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 ، التي استخدمناها. حسنا ، أو الارتباط. لن أرسمها كثيرًا ، فالإنترنت
مليء بالأدلة الموجودة على نقل جذر عامل ميناء إلى موقع جديد.
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 - تم رفض الإذن. أمد أصابعي بالويسكي وأحاول تحليل الموقف ... كيف يتم ذلك؟ صورة عامل الميناء لم تتغير. لقد انتقلنا للتو الدليل. لقد نجحت دائمًا ، وهنا من أجلك ... من أجل التجربة ، ذهبت إلى الحاوية مع الأقلام وقمت بتغيير حقوق هذا الدليل ، كان هناك
الجذر ، الجذر 755 ، أعطى
الجذر ، الجذر 777 . وبدأ كل شيء ... فكر في رأسي - نوع من الهراء ... ظننت ، حسنًا ، ربما لم أضع شيئًا في الاعتبار ...
قررت أننا أحبنا حقوق الوصول إلى الملفات أثناء النقل. لقد أوقفوا التطبيق ، وهو البرنامج الخفي لرسو السفن ، وقاموا بحذف الدليل الجديد وعملوا نسخة من دليل / var / lib / docker باستخدام
rsync -a بالفعل.
أعتقد الآن أن كل شيء على ما يرام ، نحن نرفع عامل الميناء ، التطبيق.
ثالثا ... المشكلة لا تزال ... عيني رفت. هرعت إلى وحدة التحكم الخاصة بجهازي الافتراضي ، حيث أقوم بإجراء اختبارات مختلفة ، وصورت صورة nginx هذه ، وتسلقت داخل الحاوية ، وهنا حقوق الجذر 777 الموجودة في الدليل / var / tmp ، وهي نفس الحقوق التي اضطررت لإعدادها بيدي . لكن الصور متطابقة!
تستخدم في كل مكان FS XFS.قارنت من خلال الأمر
docker inspect my-nginx:12345
جميع التجزئة متطابقة ، كل واحد إلى واحد. سواء على الخادم وعلى virtualka بلدي. قمت بحذف صورة nginx المحلية وذاكرة التخزين المؤقت مرة أخرى مع السجل ، والتي لعدة أسباب موجودة على نفس الجهاز. والمشكلة هي نفسها ... الآن عيني الثانية رفت.
لا أتذكر الأفكار التي كانت في رأسي ، إلى جانب صرخات "AAAAAAA" وأشياء أخرى. في الشارع الساعة الرابعة صباحًا ، استخدمت مصادر عامل الميناء لفهم مبدأ تجزئة طبقات الصورة. فتح العلبة الثالثة للطاقة. وفي النهاية ، بدا لي أن التجزئة لا يأخذ سوى في الحسبان الملف ، ومحتوياته ، ولكن
ليس حق الوصول ! هذا هو ، بطريقة غامضة ، تعرض الإنسان للضرب ، وتم تعطيل سيلينو ، ولا يتم استخدام دوري أبطال آسيا ، كما أن اللزجة غير موجودة.
لقد حذفت الصورة المحلية ، وحذفت الصورة أيضًا من سجل عامل ميناء وبدأتها مرة أخرى. وانها عملت. اتضح أنه أثناء النقل ، تعرضت الحقوق للضرب ، سواء داخل الصورة المحلية أو داخل الصورة الموجودة في السجل. كما قلت ، لعدد من الأسباب ، كانت موجودة على نفس السيارة. ونتيجة لذلك في دليل واحد / var / lib / docker.
واستباقًا لمسألة ما إذا كانوا حاولوا إرجاع نظرة عامل الميناء إلى الكتالوج القديم - لا ، لم يسمحوا ، للأسف ، لم تسمح الظروف. نعم ، وأردت حقًا معرفة ذلك.
بعد كتابة هذا المقال ، يبدو حل المشكلة واضحًا بالنسبة لي ، لكن في وقت التحليل لم يكن الأمر كذلك. أنا googled بصراحة ، ولم تجد حالات مماثلة.
خلاصة القول: لقد حلت المشكلة ، لم أفهم السبب = (
إذا كان شخص ما يعرف / يخمن / كان لديه رؤية حول الأسباب المحتملة لهذه المشكلة - سأكون سعيدًا جدًا لرؤيتك في التعليقات!