💪🏻 🍁 🔷 إصلاح المشاكل في Docker. يبدو ، ما علاقة GIT بها؟ 🏫 🏑 💠

Docker تحت Windows هي مغامرة مستمرة. ثم يحتاج إلى تحديث نظام التشغيل ، وإلا فلن يتم تثبيت أحدث الإصدارات ، ثم ينسى كيفية الاتصال بالشبكة. بشكل عام ، كل يوم منه أخبار. لا يتعلق "الضبط والنسيان" Docker Desktop لنظام Windows. خاصة عندما لا يتم استخدامه تمامًا كما يوصي مطوروه. ولسبب ما لا يوافقون على ربط النوافذ الخارجية بمحركات أقراص الشبكة كمحلية. وهم لا يوافقون على الوصول إلى مجلدات الشبكة الموجودة أيضًا على الجهاز المضيف. يكتبون أن هذا هو رعب رعب من وجهة نظر أمنية ، ويطلبون جميع أنواع المفاتيح مثل: لأمر التحميل للعمل في الحاوية ، وما إلى ذلك.

cap_add:
- SYS_ADMIN
- DAC_READ_SEARCH

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

لذا أفتح تعليماتي وأتخذ إجراءً. إعادة تشغيل الحاويات لا يساعد. أقوم بإعادة التشغيل من خلال إنشاء عامل الميناء مع إعادة إنشاء البنية التحتية - لا يساعد. أقوم بإعادة ضبط إعدادات Docker على إعدادات المصنع ، واستعادة إعدادات الجهاز الظاهري ، وإعادة تحميل الصور ، والتشغيل من خلال إنشاء Docker - مرة أخرى ، كل شيء كما كان من قبل - لا يرى الشبكة. بتعبير أدق ، فإنه لا يتصل بكرات الشبكة ، على الرغم من أن الأمر ping من الحاوية إلى خادم SMB أمر طبيعي. النقطة الأخيرة هي إعادة تشغيل الخادم وإعادة تثبيت Docker ، أثناء التخطي ، لأنني حقًا لا أريد إعادة تشغيل الخادم. على هذا الأمر انتهى.

حسنًا ، سأنتقل إلى جهازي المنزلي ، هنا لدي أيضًا Docker لنظام التشغيل Windows ، ولكن إصدارًا أحدث قليلاً. أتحقق من ذلك. نفس البيض:

لا يوجد اتصال ، ولكن انتظر!

بلى. حسنًا ، أعتقد حقًا أن Docker نشر التحديث بنوع من الأمان والآن لا تبدأ نصوصاتي النصية بسبب هذا؟ الفحص الأخير هو إزالة Docker تمامًا من الجهاز وإعادة تثبيته. يجب أن يكون هذا أكثر برودة من إعادة الضبط على إعدادات المصنع. أقوم بعمل القائمة الكاملة من الخطوة السابقة ، فقط بالإضافة إلى ذلك ، أعيد أيضًا تشغيل سيارتي بحيث تكون ساخرة تمامًا. أضع Docker من نقطة الصفر ، وقم بتحميل الصور ، وأطلق Docker-compose - eprst! لم تشاهد جميع الخدمات كرة الشبكة وتستمر في كتابة "خطأ التثبيت (22): وسيطة غير صالحة" عند التحميل.

أحاول تشغيل النص البرمجي سطرًا بسطر من سطر الأوامر: الاتصال بالحاوية وتشغيل الأوامر بدوره ورؤية أن كل شيء متصل ويعمل مثل بحاجة ل:

mkdir -p $SMB_MOUNT_POINT
mount -t cifs $SMB_SHARE $SMB_MOUNT_POINT -o user=$SMB_USER,password=$SMB_PASSWORD,vers=2.0
ls $SMB_MOUNT_POINT

أي ، ما هذا ، نوع من الهراء مع معلمات تمرير إلى البرنامج النصي عند بدء الحاوية؟

نحن نبحث عن المزيد من الأفكار. جميع الخيارات مع إعادة تشغيل عامل الميناء هي ضحلة ، وهناك خيارات مع تغييرات محتملة في الصورة الأصلية. تم إنشاء صورتي بناءً على openjdk: 8-jdk-alpine ، ولم يتم تحديد إصدار محدد ، لذلك يمكن لأي تحسينات أمنية أن تكسر نصاتي . ربما قاموا بتغيير شيء ما في OpenJDK أو شركة تابعة لـ Alpine؟

أتحقق من سجلات المشروع ، أحاول تحديد openjdk الأقدم: 8-jdk-alpine-3.8 ، openjdk: 8-jdk-alpine-3.7 ، إلخ. - في كل مرة أقوم فيها بإعادة بناء الحاوية ، تحقق - كل شيء كما كان من قبل.

عليك اللعنة! ربما ما زلت أغير شيئًا في جمعي؟ التفريغ من نسخة GIT'a من المشروع قبل شهر ، وجمع - نفس الثغرات. قبل ثلاثة أشهر - ما زالت المشكلة قائمة. كيف ذلك؟ ما الذي تغير؟ مكفول تكوين عامل الميناء حاليًا ، ولم يتغير تكوين الصورة أيضًا ، ومصادر المشروع هي نفسها (يحفظ GIT كل شيء). لا توجد معجزات - عليك أن تفهم أين ظهرت التغييرات مع ذلك. في همز ، أقوم بتشغيل أوامر الاتصال يدويًا بالكرات - لذلك حتى إعادة التشغيل ، ستعمل الخدمات بشكل جيد وتذهب إلى النوم. الصباح أحكم من المساء.

لا يوجد اتصال ، ولكن انتظر!

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

الرسالة "خطأ في التحميل (22): وسيطة غير صالحة" ليست مفيدة للغاية. أجد أن هناك مفتاح سحري للباش الذي يعرض به معلومات تصحيح الأخطاء عند تنفيذ البرامج النصية.

بدء تصحيح الأخطاء داخل sh:

/ # sh -x /entry-point.sh
' echo 'Mount //<private_ip>/Exchange/Pipeline to /pipeline
Mount //<private_ip>/Exchange/Pipeline to /pipeline
' mkdir -p '/pipeline
' mount -t cifs //<private_ip>/Exchange/Pipeline /pipeline -o 'user=<private_user>,password=<private_password>,vers=2.0
mount error(22): Invalid argument
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
mount: mounting //<private_ip>/Exchange/Pipeline on /pipeline failed: Invalid argument
' ls '/pipeline
+ exec

وهنا تظهر لحظات غريبة - يبدأ السطر بعلامات اقتباس ، ثم علامات الاقتباس في النهاية ... من أين علامات الاقتباس؟

فكرة - هل يمكن أن يكون الإطلاق باستخدام باش حقيقي أكثر إفادة؟

التثبيت في حاوية BASH:

apk add bash

أبدأ التصحيح:

/ # bash -x /entry-point.sh
' echo 'Mount //<private_ip>/Exchange/Pipeline to /pipeline
Mount //<private_ip>/Exchange/Pipeline to /pipeline
+ mkdir -p $'/pipeline\r'
+ mount -t cifs //<private_ip>/Exchange/Pipeline /pipeline -o $'user=<private_user>,password=<private_password>,vers=2.0\r'
mount error(22): Invalid argument
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
mount: mounting //<private_ip>/Exchange/Pipeline on /pipeline failed: Invalid argument
+ ls $'/pipeline\r'
+ exec

اللعنة ، يبدو أنه عندما يبدأ الخط بعلامة زائد - إنه جيد ، ولكن ظهر نوع من الخيارات \ r و $ '...'.

قمنا بتعيين Midnight Commander لتجربة وسائل الراحة apk add mcوفتح البرنامج النصي للتحرير ، وهناك:

أبا! ^ M في نهاية كل سطر. حسنًا ، حسنًا ، انظر إلى المشروع المحلي - ماذا عن نهايات الخط ؟؟؟؟ CRLF. نحن نعمل تحت Windows ، ولكن.

التغيير في ملف CRLF المحدد هذا إلى LF (عاش Notepad ++!) ، واجمع المشروع - بنغو! وهي تعمل كما يجب.

لماذا كان الأمر على ما يرام من قبل ، ولكن الآن كل شيء طار؟ ألقي نظرة على الالتزامات - لم تكن هناك تغييرات. ثم أتذكر أنه يمكن لـ GIT تحرير خطوط التغذية على الطايرملفات نصية. وفي اليوم الآخر قمت بتوصيل مستودع جديد ، وربما قمت بتحميل جميع الملفات من هناك مع التحويل إلى CRLF.

نتيجة لذلك ، نضيف ملف .gitattributes إلى المشروع ، للإشارة إلى أنه في ملفات منفصلة من الضروري حفظ نهاية أحرف السطر كما هو الحال في UNIX:

# Set the default behavior, in case people don't have core.autocrlf set.
* text=auto

# Declare files that will always have LF line endings on checkout.
*.sh text eol=lf

الأخلاق - في بعض الأحيان لا يقع الجاني في دائرة المشتبه بهم الأوليين.

ملاحظة

بعد التحديث إلى أحدث إصدار من Docker Desktop لنظام Windows 2.2.0.3 ، توقف كل شيء عن العمل. هذه المرة ، دخلت على الفور داخل الحاويات ، وبدأت في تصحيح الأخطاء. اتضح أن عنوان IP 10.0.75.1 للوصول إلى الجهاز المضيف توقف عن العمل ، وتمت إزالة DockerNat الآن من النظام ، ولا يحتوي الجهاز الظاهري DockerDesktopVM حتى على محول شبكة خارجي ، أي التواصل معها لا يمر عبر شبكة قياسية ، ولكن بطريقة مختلفة. وللوصول إلى المضيف ، يجب عليك استخدام host.docker.internal . زملاء المطورين وكتب ذلك

تمت إزالة DockerNAT من Docker Desktop 2.2.0.0 لأن استخدام عنوان IP للاتصال من المضيف إلى الحاوية ليس ميزة مدعومة. للاتصال من الحاوية إلى المضيف ، يجب عليك استخدام اسم DNS الخاص host.docker.internal.

حسنًا ، لقد قمت بإصلاح التكوينات الخاصة ببيئة الاختبار ، وتم التقاط قاعدة البيانات ، وتم اختبار الاتصال من الحاوية إلى host.docker.internal ، ولكن محركات أقراص الشبكة غير متصلة. أحاول تشغيل التحميل يدويًا من shell ، وأحصل على الخطأ المألوف "خطأ التثبيت (22): وسيطة غير صالحة". أزيل

الحجج بدوره - أنا فقط أركض "mount -t cifs //host.docker.internal/playground / pipeline" - يبدو أنه يعمل ، ولكنه يطرق من المستخدم الجذر.

إضافة مستخدم: mount -t cifs //host.docker.internal/playground / pipeline -o user = smbuser - يطلب كلمة مرور ويتصل!

تعمل النسخة الكاملة أيضًا:

mount -t cifs //host.docker.internal/playground /pipeline -o user=smbuser,password=smbpassword

لكن " mount -t cifs //host.docker.internal/playground / pipeline -o user = smbuser، password = smbpassword، vers = 2.0 " لا يحرث.

أغير المعلمة الأخيرة إلى Vers = 2.1 - هتاف ، يعمل!

يبدو أن Docker في أحدث إصدار قامت بتنفيذها الخاص لخادم SMB مع لعبة ورق ، ولكن بدون دعم 2.0. هراء ، بالطبع ، مقارنة بأخبار أخرى.

كل الخير والقوة والمثابرة!

تم أخذ الرسم التوضيحي للمقال من blog.eduonix.com/software-development/learn-debug-docker-containers

إصلاح المشاكل في Docker. يبدو ، ما علاقة GIT بها؟

ملاحظة

More articles: