عند نشر التطبيقات على الخوادم ، عادة ما يكون هناك فصل بين ما يحزمه التطبيق مع نفسه وما يتوقعه من النظام الأساسي (نظام التشغيل والحزم المثبتة) لتقديمه. نقطة واحدة من هذا هو أنه يمكن تحديث النظام الأساسي بشكل مستقل عن التطبيق. وهذا مفيد على سبيل المثال عندما تحتاج التحديثات الأمنية ليتم تطبيقها على وجه السرعة إلى الحزم التي تقدمها منصة دون إعادة بناء التطبيق بأكمله.
تقليديا تم تطبيق تحديثات الأمان ببساطة عن طريق تنفيذ أمر إدارة الحزم لتثبيت إصدارات محدثة من الحزم على نظام التشغيل (على سبيل المثال "تحديث يم" على ريل). ولكن مع ظهور تكنولوجيا الحاويات مثل عامل الميناء حيث صور الحاويات حزمة أساسا كل من التطبيق و المنصة, ما هي الطريقة الأساسية للحفاظ على نظام مع حاويات محدثة? كل من المضيف والحاويات لديها مجموعات خاصة بها ومستقلة من الحزم التي تحتاج إلى تحديث وتحديث على المضيف لن تقوم بتحديث أي حزم داخل الحاويات. مع الافراج عن ريل 7 حيث حاويات عامل الميناء هي واردة بشكل خاص ، سيكون من المثير للاهتمام أن نسمع ما طريقة ريدهات الموصى بها للتعامل مع التحديثات الأمنية للحاويات هو.
أفكار حول عدد قليل من الخيارات:
لن يؤدي السماح لمدير الحزم بتحديث الحزم على المضيف إلى تحديث الحزم داخل الحاويات.
يبدو أن الحاجة إلى إعادة إنشاء جميع صور الحاوية لتطبيق التحديثات تؤدي إلى كسر الفصل بين التطبيق والنظام الأساسي (يتطلب تحديث النظام الأساسي الوصول إلى عملية إنشاء التطبيق التي تنشئ صور عامل الإرساء).
يبدو تشغيل الأوامر اليدوية داخل كل حاوية قيد التشغيل مرهقا وتتعرض التغييرات لخطر الكتابة فوقها في المرة التالية التي يتم فيها تحديث الحاويات من القطع الأثرية لإصدار التطبيق.
من المفترض أن تكون الحاويات خفيفة الوزن وقابلة للتبديل. إذا كانت الحاوية الخاصة بك بها مشكلة أمان ، فأنت تقوم بإعادة إنشاء إصدار من الحاوية التي تم تصحيحها ونشر الحاوية الجديدة. (العديد من الحاويات تستخدم صورة قاعدة القياسية التي تستخدم أدوات إدارة الحزمة القياسية مثل الرابطة بين الحصول على تثبيت تبعياتها ، وإعادة بناء سحب التحديثات من المستودعات)
في حين يمكنك التصحيح داخل الحاويات ، وهذا لن مقياس جيدا.
بادئ ذي بدء ، لن تكون العديد من تحديثاتك التي قمت بتشغيلها تقليديا في الماضي داخل الحاوية نفسها. يجب أن تكون الحاوية مجموعة فرعية خفيفة الوزن وصغيرة إلى حد ما من نظام الملفات الكامل الذي اعتدت على رؤيته في الماضي. الحزم التي يجب عليك تحديثها ستكون تلك التي هي جزء من دوكيرفيل الخاص بك ، وبما أن لديك دوكيرفيل ، يجب أن تكون قادرا على تتبع تلك الحزم ومعرفات الحاويات التي تحتاج إلى تحديثات. واجهة المستخدم كلودشتاين التي سيتم إصدارها قريبا بتتبع هذه المكونات دوكيرفيل بالنسبة لك بحيث يمكن للمرء أن بناء مخطط التحديث الذي يناسب أفضل لحاوياتها. نأمل أن يساعد هذا
فالكو, ما سير العمل الذي انتهى به الأمر? أنا تشغيل حاويات طويلة الأجل(استضافة فب-سغي ، على سبيل المثال) وما وجدته حتى الآن هو: دوكر سحب ديبيان/جيسي لتحديث الصورة ، ثم إعادة بناء صورة (ق) القائمة ، ثم إيقاف الحاويات وتشغيلها مرة أخرى (مع الصورة الجديدة). الصور التي أقوم بإنشائها لها نفس اسم الصور السابقة، لذلك يتم البدء عبر البرنامج النصي. ثم أقوم بإزالة الصور" غير المسماة". وسأكون ممتنا بالتأكيد سير عمل أفضل.
سؤال مثير للاهتمام. أتساءل عن ذلك بنفسي. إذا كان لديك 20 تطبيقا يعمل على مضيف عامل ميناء واحد، فيجب عليك ترقية الصور الأساسية وإعادة البناء وإعادة التشغيل! 20 تطبيقا ولا تعرف حتى ما إذا كان التحديث الأمني قد أثر عليهم جميعا ، أو على واحد منهم فقط. يجب عليك إعادة بناء الصورة لقول أباتشي عندما يتأثر التحديث الأمني فقط ليبنغ على سبيل المثال. لذلك ينتهي بك الأمر مع عمليات إعادة البناء وإعادة التشغيل غير الضرورية…
ميها: هذا يبدو مشابها لما انتهى به الأمر. أساسا باستمرار تحديث وإعادة بناء جميع الصور كجزء من صنع الإصدارات الجديدة. وإعادة تشغيل الحاويات باستخدام الصور الجديدة.