تحظى Docker بشعبية كبيرة الآن ، ويبدو أن تكنولوجيا الحاويات في كل مكان ، لكن هذا في الواقع سوء فهم. لا تفونت بفقاعة الضجيج. هذه المقالة تخلص من الضجيج وتسرد بشكل عقلاني سوء الفهم الحالي الخمسة للرسوم من منظور مبرمجي Java لمساعدتك على فهم مزايا Docker ومشاكلها بشكل أفضل.
إذا وضعنا جانباً الضجيج من وسائل الإعلام والمصنعين ، كيف يمكننا استخدام Docker بشكل أفضل وأكثر عقلانية؟
اجتذب Docker الكثير من الاهتمام مؤخرًا ، والأسباب واضحة. كيفية تسليم الكود بنجاح قد أزعجت الجميع دائمًا. تقنية الحاويات التقليدية هي فوضوية بين العديد من الاحتياجات والقوالب. يمكن أن يقوم Docker بإنشاء حاويات ببساطة وبشكل متكرر. يتيح استخدام Docker توصيل التعليمات البرمجية بشكل أسرع وأكثر من الحاويات الأخرى. Duang ، Docker شائع! هناك أيضا بعض سوء الفهم وسوء الفهم. لا تثق بالآخرين ليقولوا إن Docker سهل الاستخدام أم لا. إن التفكير في Docker بشكل عقلاني وشامل من قبل نفسك سيساعدك حقًا على فهم ما إذا كنت بحاجة إليها حقًا.
يسرد هذا المقال خمسة قراءات مخصصة Docker الرئيسية من منظور Java. لكن أولاً قدم بعض المعرفة الأساسية. لفهم Docker بشكل أفضل ، استشرنا Avishai Ish-shalom من عدد قليل من الذين يتمتعون بخبرة واسعة في Docker وأيضًا منظم مؤتمر Devops Days. لقد أدرجنا هذه سوء الفهم معه.
سوء فهم رئيسي
1. Docker هو جهاز افتراضي خفيف الوزن
هذا هو سوء الفهم الرئيسي عندما تكون Docker المبتدئين. هذا سوء الفهم أمر مفهوم ، فإن Docker يشبه إلى حد ما الجهاز الظاهري. حتى أن بعض الأشخاص يقارنون الفرق بين Docker و Virtual Machines على موقع Docker. ومع ذلك ، فإن Docker ليس في الواقع جهاز افتراضي خفيف الوزن ، ولكن حاوية Linux محسّنة (LXC). Docker والأجهزة الافتراضية مختلفة تمامًا. إذا كنت تستخدم حاويات Docker كأجهزة افتراضية خفيفة الوزن ، فسوف تواجه العديد من المشكلات.
قبل استخدام Docker ، يجب أن تفهم أن هناك العديد من الاختلافات الأساسية بين حاويات Docker والأجهزة الافتراضية.
عزل الموارد: لا يمكن لـ Docker الوصول إلى مستوى عزل الموارد الذي يمكن أن يوفره الجهاز الظاهري. موارد الجهاز الظاهري معزولة للغاية ، وقد احتاج Docker إلى مشاركة بعض الموارد منذ إنشائها. لا يمكن عزل هذه الموارد وحمايتها بواسطة Docker ، مثل Page Cache و Kernel Entropy Pool. (ملاحظة: إن تجمع إنتروبيا kernel مثير للاهتمام ، فهو يجمع ويخزن البتات العشوائية التي تم إنشاؤها بواسطة عمليات النظام. سيستخدم الجهاز هذا التجمع عندما يحتاج إلى عشوائي ، مثل متعلق كلمة المرور). إذا كانت حاوية Docker تشغل هذه الموارد المشتركة ، فلا يمكن للعمليات الأخرى الانتظار إلا قبل إصدار هذه الموارد.
النفقات العامة: يعرف معظم الناس أن وحدة المعالجة المركزية وذاكرة الوصول إلى الجهاز الظاهري يمكن أن توفر أداءً يشبه الآلة المادية ، ولكن هناك الكثير من النفقات العامة الإضافية IO. نظرًا لأنه تم التخلي عن نظام التشغيل الضيف للأجهزة الافتراضية ، فإن حزمة Docker أصغر وتتطلب أقل من الأجهزة الافتراضية. ولكن هذا لا يعني أن Docker ليس لديه مشاكل علوية. لا تزال حاويات Docker بحاجة إلى الانتباه إلى النفقات العامة IO ، لكنها ليست خطيرة مثل الأجهزة الافتراضية.
استخدام kernel: حاويات Docker والأجهزة الافتراضية تختلف تمامًا في استخدام النواة. كل جهاز افتراضي يستخدم نواة واحدة. حاويات Docker تشترك في النواة بين جميع الحاويات. تجلب النواة المشتركة بعض مكاسب الكفاءة ، ولكن على حساب التوافر والتوافر العالي. إذا حدث تحطم kernel في جهاز افتراضي ، فسيتأثر الجهاز الظاهري فقط على هذا النواة. إذا تعطلت نواة حاوية Docker ، فستتأثر جميع الحاويات.
2. Docker يجعل التطبيقات قابلة للتطوير
نظرًا لأن Docker يمكنه نشر رمز على خوادم متعددة في وقت قصير جدًا ، فمن الطبيعي أن يعتقد بعض الأشخاص أن Docker يمكن أن يجعل التطبيق نفسه قابل للتطوير. لسوء الحظ ، هذا خطأ. الكود هو حجر الزاوية في التطبيق ، ولا يعيد Docker كتابة الرمز. لا تزال قابلية التوسع في التطبيق تعتمد على المبرمج. لا يؤدي استخدام Docker تلقائيًا إلى جعل الرمز الخاص بك سهلاً لتوسيع نطاقه ، فهو يسهل النشر عبر الخوادم.
3. يستخدم Docker على نطاق واسع في بيئات الإنتاج
نظرًا لأن Docker على قدم وساق ، يعتقد الكثير من الناس أنه يمكن استخدام Docker على نطاق واسع في بيئات الإنتاج. في الواقع ، هذا ليس صحيحا. لاحظ أن Docker لا تزال تقنية جديدة للغاية وغير ناضجة ومتنامية ، مما يعني أنه لا يزال هناك العديد من الأخطاء والميزات المزعجة التي يجب تحسينها. صحيح أنك مهتم بالتقنيات الجديدة ، ولكن من الأفضل معرفة سيناريوهات الاستخدام الصحيحة وما الذي يجب إيلاء الاهتمام به. الآن ، من السهل تطبيق Docker على بيئات التطوير. يمكن أن يؤدي استخدام Docker بسهولة إلى إنشاء العديد من البيئات المختلفة (على الأقل ، يمنح الناس شعورًا بأنهم يمكنهم إنشاء بيئات مختلفة) ، وهو أمر مفيد للغاية للتطوير.
في بيئات الإنتاج ، يحد عدم نضج Docker وعدم النقص أيضًا من سيناريوهات الاستخدام. على سبيل المثال ، لا يدعم Docker مراقبة الشبكات والموارد مباشرة لآلات متعددة ، مما يجعل من المستحيل تقريبًا استخدامه في بيئات الإنتاج. بالطبع ، هناك العديد من المجالات المحتملة ، مثل نشر الحزمة نفسها مباشرة من بيئة التطوير إلى بيئة الإنتاج. هناك أيضًا بعض ميزات وقت تشغيل Docker والتي تعد أيضًا مفيدة لبيئات الإنتاج. ولكن بشكل عام ، في بيئة الإنتاج ، لا توجد حاليًا مزايا أكثر من المزايا. هذا لا يعني أنه لا يمكن تطبيقه بنجاح على بيئة الإنتاج ، ولكن الآن لا يمكن توقع أن تنضج وكمال في وقت واحد.
4. Docker هو المتقاطع
سوء فهم آخر هو أن Docker يعمل على أي نظام تشغيل وبيئة. قد يأتي هذا من تشبيه الحاويات لتحميل البضائع وتفريغها ، ولكن العلاقة بين البرمجيات وأنظمة التشغيل ليست بسيطة ومباشرة مثل موقف السفينة.
في الواقع ، Docker هي مجرد تقنية على Linux. بالإضافة إلى ذلك ، يعتمد Docker على ميزات kernel محددة ويجب أن يكون لديها أحدث إصدار من kernel. استنادًا إلى الاختلافات بين OPS المختلفة ، إذا لم تستخدم أدنى الميزات الشائعة عبر OSS ، فسوف تواجه العديد من المشكلات المزعجة. قد يكون لهذه المشكلات حدوث 1 ٪ فقط ، ولكن عندما تنشر على خوادم متعددة ، فإن 1 ٪ قاتلة أيضًا.
على الرغم من أن Docker يعمل فقط على Linux ، إلا أنه يمكن استخدامه أيضًا على OS X أو Windows. سيتم استخدام Boot2Docker جهاز Linux Virtual على جهاز OS X أو Windows ، بحيث يمكن تشغيل Docker في هذا الجهاز الظاهري.
5. Docker يعزز أمان التطبيق
إنه أيضًا سوء فهم أن Docker يمكنه تحسين أمان الكود وعملية التسليم. هذا هو أيضًا الفرق بين حاوية حقيقية وحاوية على البرنامج. Docker هي تقنية حاويات تضيف طرق التزامن. ومع ذلك ، فإن حاويات Linux لديها بعض نقاط الضعف الأمنية التي قد تتعرض للهجوم. لا يضيف Docker أي طبقات أو بقع أمان إلى هذه الثغرات الأمنية. إنه ليس قميصًا بنطلونًا يمكنه حماية التطبيقات.
من منظور جافا
بدأ بعض مطوري Java في استخدام Docker. تجعل بعض ميزات Docker من السهل علينا بناء سياقات قابلة للتطوير. على عكس Uber-Jar ، يمكن أن يساعدك Docker في حزم جميع تبعياتك (بما في ذلك JVM) في صورة جاهزة للإصدار. هذا هو أيضا الشيء الأكثر روعة عن دوكر للمطورين. ومع ذلك ، فإن هذا سيجلب أيضًا بعض المخاطر الخفية. بشكل عام ، يحتاج المبرمجون إلى مراقبته بطرق مختلفة ورمز بشكل تفاعلي ، وتصحيحه ، وتوصيله ، وضبطه ... إذا كنت تستخدم Docker ، فسيتطلب ذلك عملًا إضافيًا.
على سبيل المثال ، نريد استخدام JConsole ، والذي يعتمد على وظائف JMX ، لأن JMX يحتاج إلى شبكات لاستخدام RMI. ليس من المباشر للغاية إذا كنت تستخدم Docker ، وتحتاج إلى بعض المهارات لفتح المنفذ المطلوب. اكتشفنا في البداية أن المشكلة هي أنه عندما أردنا إنشاء طلب Docker لـ Takipi ، كان علينا تشغيل برنامج خلفية خارج JVM في الحاوية. حل مفصل على جيثب.
مشكلة خطيرة أخرى هي أن ضبط أداء حاويات Docker أمر صعب للغاية. عند استخدام الحاويات ، لا تعرف مقدار الذاكرة التي ستخصصها كل حاوية. إذا كان لديك 20 حاوية ، فسيتم تخصيص الذاكرة لهم بطرق غير متأكدة. إذا كنت تخطط لضبط الكومة باستخدام المعلمة -xmx ، فهذا أمر صعب لأن معالجة JVM في حاوية Docker تعتمد على القدرة على الحصول على الذاكرة المخصصة للحاوية تلقائيًا. يكاد يكون ضبط الأداء مستحيلًا إذا كنت لا تعرف مقدار الذاكرة المخصصة.
ختاماً
Docker هي تقنية مثيرة للاهتمام للغاية ولديها بعض سيناريوهات الاستخدام الحقيقية والفعالة. كتقنية ناشئة ، يستغرق الأمر أيضًا الكثير من الوقت لحل الميزات المفقودة والأخطاء المعروفة. ومع ذلك ، هناك بالفعل الكثير من الضجيج في هذا المجال الآن. لكن تذكر أن الضجيج ليس نجاحًا ~
شكرا لك على القراءة ، آمل أن تساعدك. شكرا لك على دعمك لهذا الموقع!