تاريخ مشكلة ترحيل تخزين عامل الإرساء (جذر عامل الإرساء)

منذ ما لا يزيد عن يومين، تقرر على أحد الخوادم نقل وحدة تخزين عامل الإرساء (الدليل حيث يقوم عامل الإرساء بتخزين جميع ملفات الحاويات والصور) إلى قسم منفصل، والذي
كان لديه قدرة أكبر. بدت المهمة تافهة ولا تنبئ بالمتاعب..

هيا بنا نبدأ:

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 - تم رفض الإذن. أعجن صدغي بأصابعي وأحاول تحليل الوضع... كيف يكون هذا ممكنا؟ لم تتغير صورة Docker. لقد قمنا للتو بنقل الدليل. لقد كان يعمل دائمًا، وهنا هو لك... من أجل التجربة، ذهبت إلى الحاوية بيدي وقمت بتغيير الحقوق إلى هذا الدليل، كان هناك الجذر، الجذر 755، أعطى الجذر، الجذر 777. وبدأ كل شيء... بدأت فكرة في رأسي - نوع من الهراء... فكرت، حسنًا، ربما لم آخذ شيئًا ما في الاعتبار...

قررت أننا وقعنا في حب حقوق الوصول إلى الملفات أثناء النقل. أوقفنا التطبيق، برنامج docker الخفي، وحذفنا الدليل الجديد ونسخنا الدليل /var/lib/docker باستخدام rsync -a.

أعتقد أن كل شيء على ما يرام الآن، فلنرفع تطبيق Docker.

آآند...بقيت المشكلة...رفت عيني. لقد هرعت إلى وحدة التحكم في جهازي الظاهري، حيث أجريت اختبارات مختلفة، وحصلت على صورة nginx هذه، وتسلقت داخل الحاوية، وهنا حقوق الدليل /var/tmp هي الجذر، الجذر 777. وهذا هو، نفس ما اضطررت إلى ضبطه يدويًا. لكن الصور متطابقة!

تم استخدام نظام الملفات xfs في كل مكان.

قارنت باستخدام الأمر

docker inspect my-nginx:12345

جميع التجزئات متطابقة، كلها واحدة لواحدة. سواء على الخادم أو على جهازي الظاهري. لقد قمت بحذف صورة nginx المحلية وسحبتها مرة أخرى من السجل، والتي توجد على نفس الجهاز لعدة أسباب. والمشكلة هي نفسها... الآن عيني الثانية ترتعش.

لم أعد أتذكر الأفكار التي كانت تدور في رأسي، إلى جانب الصراخ "آآآآآآ" وأشياء أخرى. كانت الساعة الرابعة صباحًا، وتم استخدام كود مصدر Docker لفهم مبدأ تجزئة طبقات الصورة. فتحت العلبة الثالثة من مشروب الطاقة. وفي النهاية اتضح لي أن التجزئة تأخذ بعين الاعتبار الملف ومحتوياته فقط، ولكن لا حقوق الوصول! وهذا يعني أن حقوقنا قد ضاعت بطريقة غامضة، وتم تعطيل selinux، ولم يتم استخدام ACL، ولم يعد هناك جزء لاصق.

لقد قمت بحذف الصورة المحلية، وحذفت الصورة أيضًا من سجل عامل الإرساء ودفعتها مرة أخرى. وعمل كل شيء. اتضح أنه أثناء النقل فقدت الحقوق، سواء داخل الصورة المحلية أو داخل الصورة الموجودة في التسجيل. كما قلت من قبل، لعدد من الأسباب كان موجودا على نفس السيارة. ونتيجة لذلك، في دليل واحد /var/lib/docker.

وتوقع السؤال عما إذا كانوا يحاولون إعادة نظرة عامل الإرساء إلى الدليل القديم - لا، لم يحاولوا، للأسف، الظروف لم تسمح بذلك. نعم، وأردت حقًا معرفة ذلك.

بعد كتابة هذا المقال يبدو لي حل المشكلة واضحا، لكن وقت التحليل لم يكن يبدو كذلك. بصراحة بحثت في جوجل ولم أجد مثل هذه المواقف.

النتيجة: لقد قمت بحل المشكلة، وما زلت لا أفهم السبب =(

إذا كان أي شخص يعرف، على الأرجح، لديه رؤية حول الأسباب المحتملة لهذه المشكلة، سأكون سعيدًا للغاية لسماع رأيك في التعليقات!

المصدر: www.habr.com