لقد استسلمت أخيرًا لرحمة الحاويات ووجدت أنها تحل الكثير من المشاكل ولها مزايا كثيرة:
- الحاويات غير قابلة للتغيير: نظام التشغيل والمكتبات والمجلدات والتطبيقات - نظرًا لأن كل هذا يتم تخزينه مباشرة في الحاوية ، فأنت متأكد بنسبة 100٪ من أن الصورة التي تم اختبارها في ضمان الجودة ستنتقل دائمًا إلى الإنتاج. وستعمل بنفس الطريقة تمامًا.
- حاويات خفيفة الوزن: الحاوية لا تهدر الذاكرة. بدلاً من مئات الميغابايتات والجيجابايت ، تحتاج الحاوية فقط إلى ذاكرة للعملية الرئيسية.
- الحاويات سريعة: تبدأ الحاوية بسرعة عملية لينكس العادية. ليس دقائق ، ولكن ثواني حرفيا.
ومع ذلك ، لا يزال العديد يعتقدون أن الحاويات هي آلات افتراضية ، وينسون أهم ممتلكاتهم ...
حاويات سريعة الزوال
التخلص هو السبب في أنه يجب عليك تغيير نهجك في كيفية التعامل مع الحاويات.
وإليك ما لا يجب فعله بأي حال حتى لا تفقد مزايا الحاويات:1. لا حاجة لتخزين البيانات داخل الحاوية. خلال دورة الحياة ، يمكن تعليق الحاويات وتدميرها واستبدالها. إذا كان التطبيق يعمل في حاوية ، فيجب أن يتغير الإصدار 1.0 من هذا التطبيق بسهولة إلى الإصدار 1.1 دون فقدان البيانات وغيرها من المشاكل. لذلك ، إذا كنت تريد حفظ البيانات ، فيجب كتابتها عن ذلك. ومع ذلك ، فأنت بحاجة إلى التأكد من أن الحاويتين لا تكتبان في نفس المكان حتى لا تتلف البيانات. لذا ، تحقق من أن التطبيقات تكتب البيانات بشكل صحيح إلى التخزين المشترك.
2. لا حاجة لتقسيم تسليم التطبيق. يعتقد بعض الناس أن الحاوية هي نفس الآلة الافتراضية. ويعتقد معظمهم أنه يجب نشر التطبيقات في الحاويات الموجودة. في الواقع ، هذا ممكن أيضًا ، خاصة في مرحلة التطوير ، عندما يكون هناك تصحيح ونشر مستمر. ولكن يجب عليهم إدخال القرص المضغوط للتسليم المستمر للتحويل إلى قسم ضمان الجودة أو الإنتاج فقط كجزء من صورتهم الخاصة. تذكر: الحاويات لا تتزعزع.
3. لا حاجة لإنشاء صور كبيرة. من الصعب توزيع صورة كبيرة. لذلك ، يجب أن تتضمن الصورة فقط الملفات والمكتبات اللازمة حقًا لبدء عملية التطبيق. لا حاجة لتثبيت حزم غير ضرورية أو تشغيل التحديثات (تحديث يوم) ، التي تنشئ طبقة جديدة في الصورة وتكتب الكثير من الملفات إليها.
4. لا تستخدم حاويات طبقة واحدة. لاستخدام أنظمة الملفات متعددة الطبقات (متعددة المستويات) بشكل فعال ، قم دائمًا بإنشاء طبقات منفصلة لنظام التشغيل ، لتعريف اسم المستخدم ، للتكوين ، وأخيرًا ، للتطبيق نفسه. لذلك سيكون من الأسهل إعادة إنشاء الصور وحفظها وتوزيعها.
5. لا حاجة لإنشاء صور من الحاويات قيد التشغيل. بمعنى آخر ، لا تستخدم أمر الالتزام docker لإنشاء صورة ، لأن هذه الصور لن تكون قابلة للتكرار. بدلاً من ذلك ، استخدم دائمًا ملف Dockerfile أو أدوات S2I أخرى (المصدر إلى الصورة) التي توفر إمكانية إعادة الإنتاج. بالإضافة إلى ذلك ، في Dockerfile ، يمكنك بسهولة تتبع التغييرات إذا قمت بتخزينها في مستودع المصدر (git).
6. لا حاجة لاستخدام أحدث علامة فقط. هذه العلامة هي شيء مثل SNAPSHOT لمستخدمي Maven. نظرًا لطبيعة نظام ملفات الحاوية متعدد الطبقات ، فإن العلامات مفيدة جدًا. ومع ذلك ، قد تتوقع مفاجأة غير سارة ، على سبيل المثال ، بعد انقطاع لمدة أشهر ، عندما تقرر جمع صورة وتجد فجأة أن التطبيق لم يعد يبدأ لأن الطبقة الأصلية (من لغة Dockerfile) تم استبدالها بإصدار جديد لا يدعم التوافق مع الإصدارات السابقة. أو لأنه تم استرداد النسخة الخاطئة من ذاكرة التخزين المؤقت للبناء التي كنت تنتظرها. بالإضافة إلى ذلك ، يجب أيضًا تجنب العلامة الأخيرة عند نشر الحاويات في الإنتاج ، حيث لن تتمكن من تتبع إصدار الصورة الذي يتم إطلاقه.
7. لا حاجة لتنفيذ أكثر من عملية في الحاوية. تعتبر الحاويات مناسبة بشكل مثالي لعملية واحدة (http daemon daemon ، خادم التطبيقات ، DBMS). خلاف ذلك ، قد تواجه جميع أنواع المشاكل ، مثل الحفر في السجلات أو تحديث العمليات بشكل منفصل.
8. لا حاجة لتخزين بيانات الاعتماد في صورة - استخدم متغيرات البيئة لذلك. لا تصف أي تسجيلات دخول وكلمات مرور في الصورة. بدلاً من ذلك ، استخدم متغيرات البيئة لسحب البيانات ذات الصلة من مصادر خارج الحاوية. تعد صورة Postgres مثالاً رائعًا على كيفية القيام بذلك بشكل صحيح.
9. لا حاجة لتشغيل العمليات كجذر. "بشكل افتراضي ، تعمل حاويات عامل الميناء كجذر. (...) ومع ذلك ، مع تطور التكنولوجيا ، قد تظهر خيارات بدء تشغيل افتراضية أخرى أكثر أمانًا. في ظل الظروف الحالية ، يمكن اعتبار متطلب الجذر تهديدًا وقد لا يتم توفيره في جميع البيئات. لتحديد مستخدم بخلاف الجذر ، سيتم تشغيل الحاوية نيابة عنه ، يتم استخدام توجيه المستخدم "(مقتطف من إرشادات مؤلفي صورة Docker)
10. لا حاجة للاعتماد على عناوين IP. تحتوي كل حاوية على عنوان IP الداخلي الخاص بها ، والذي يمكن تغييره بعد إعادة تشغيل الحاوية. إذا كان التطبيق أو الخدمة الصغيرة بحاجة إلى الاتصال بحاوية أخرى ، فاستخدم متغيرات البيئة لنقل اسم المضيف المطلوب إلى رقم المنفذ من حاوية إلى أخرى.
هل تتذكر؟ الآن يمكنك استخدامه بأمان. ويمكن العثور على نصائح عملية لاستخدام الحاويات على مدونتنا.