جزء من السبب وراء شهرة الحاويات هو أنها تتيح منهج “الإنشاء مرة واحدة، والتشغيل في أي مكان” لنشر التطبيق. باستخدام الحاويات، يمكن تشغيل نفس صورة التطبيق في أي بيئة تقريبًا. لا يتعين على المطورين إعادة ترجمة التطبيق أو إعادة حزمه لدعم بيئات متعددة.
ومع ذلك، هذا لا يعني أن عملية نشر التطبيق المعبأ في حاوية عبر بيئات مختلفة هي في الواقع نفسها. على العكس من ذلك، يمكن أن يكون الأمر مختلفًا تمامًا اعتمادًا على عوامل مثل السحابة التي تستضيف تطبيقك وما إذا كنت تديره باستخدام Kubernetes أو حل تنسيق بديل.
هذه الاختلافات الخاصة بالبيئة في إدارة الحاويات تستحق التوضيح لأنها غالبًا ما يتم تجاهلها في المحادثات حول الحاويات. من السهل أن تضيع في جاذبية شعار “البناء مرة واحدة، والتشغيل في أي مكان”، دون التقدير الكامل لمدى اختلاف تجربة نشر الحاويات فعليًا بين البيئات.
لهذا السبب، أود أن أستعرض الطرق الأساسية التي يمكن من خلالها أن يكون نشر الحاويات وإدارتها مختلفًا تمامًا اعتمادًا على البيئة وخدمة التنسيق التي تستخدمها. لا تجعل أي من هذه الاختلافات أحد أنواع البيئة “أفضل” لاستضافة الحاويات من نوع آخر، ولكن من المهم أن تضعها في الاعتبار عند تقييم المهارات والأدوات التي سيحتاجها فريقك لدعم التطبيقات الموجودة في حاويات في البيئة التي تختارها لنشرها.
المبادئ التي تنطبق على جميع عمليات النشر القائمة على الحاويات
قبل مناقشة الاختلافات الخاصة بالبيئة فيما يتعلق بالحاويات، فلنتحدث عن جوانب نشر الحاويات التي تكون هي نفسها بغض النظر عن المكان الذي تختاره لتشغيل التطبيقات الموجودة في حاويات.
أحد الثوابت عبر البيئات هو مبادئ الأمان. يجب عليك دائمًا تبني ممارسات مثل الامتياز الأقل (مما يعني منح الحاويات الوصول فقط إلى الموارد التي تحتاجها، وليس أكثر) للتخفيف من المخاطر. يجب عليك أيضًا فرض التشفير على البيانات غير النشطة وكذلك البيانات المتحركة.
يتم أيضًا توحيد شبكات الحاويات بشكل عام عبر البيئات، على الأقل فيما يتعلق بالاتصالات بين الحاويات. (كما هو موضح أدناه، يمكن أن تكون تكوينات شبكة الحاوية مختلفة عندما يتعلق الأمر بتعريض منافذ الحاوية للشبكات الخارجية، وفي هذه الحالة يتم تشغيل أدوات الشبكات وعمليات التكامل الخاصة بالمنسق.)
سيتعين عليك أيضًا دائمًا إدارة الأدوات والخدمات الإضافية. بغض النظر عن المكان الذي تنشر فيه الحاويات، ستحتاج إلى التفكير في توفير البنية التحتية لاستضافتها، ونشر خدمة التنسيق، وموازنة حمل الشبكة، وما إلى ذلك. يمكن أن تختلف الأدوات الدقيقة التي تستخدمها لهذه المهام عبر البيئات، ولكن المهام نفسها هي نفسها بشكل أساسي.
كيف تختلف الحاويات عبر السحب
الآن، دعنا نتحدث عن الاختلافات في إدارة الحاويات بين البيئات، بدءًا من كيفية تأثير السحابة التي تختارها لاستضافة حاوياتك على طريقة إدارتك لها.
بشكل عام، لا توجد اختلافات كبيرة بين السحابات العامة الرئيسية – Amazon Web Services، وMicrosoft Azure، وGoogle Cloud Platform (GCP) – فيما يتعلق بإدارة الحاويات. ومع ذلك، تقدم كل سحابة خدمات مختلفة لخدمات تنسيق الحاويات.
على سبيل المثال، تقدم AWS كلاً من منسق الحاوية الخاص، والذي يسمى Elastic Container Service (ECS)، بالإضافة إلى منسق يستند إلى Kubernetes يسمى Elastic Kubernetes Service (EKS). من جانبهما، يقدم Azure وGCP في المقام الأول التنسيق المستند إلى Kubernetes فقط (على الرغم من أن Azure يدعم عمليات تكامل محدودة مع بعض المنسقين الآخرين، مثل Swarm، عبر مثيلات حاوية Azure). وهذا يعني أن الخدمة التي تستخدمها لإدارة حاوياتك قد تختلف اعتمادًا على السحابة التي تستضيفها.
تختلف أدوات وتكوينات أمان الحاويات بين السحابة أيضًا. تختلف أدوات إدارة الهوية والوصول (IAM) لكل موفر، مما يتطلب سياسات وتعريفات مختلفة للأدوار. وبالمثل، إذا قمت بتكوين الحاويات لتولي موارد سحابية محددة – مثل البيانات الموجودة داخل حاوية تخزين Amazon S3 أو إشعارات SNS – فستعمل فقط مع النظام الأساسي السحابي الذي يوفر تلك الموارد. لكلا السببين، لا يمكنك رفع ونقل سياسات أمان الحاوية من سحابة إلى أخرى. تحتاج إلى إجراء بعض عمليات إعادة البناء لترحيل تطبيقك بين السحاب.
وبالمثل، إذا كنت تستخدم خدمات المراقبة والتنبيه المضمنة لدى موفر الخدمة السحابية (مثل Amazon CloudWatch أو Azure Monitor)، فستختلف أدوات وعمليات المراقبة والمراقبة بين السحابات. وهذا صحيح بشكل خاص إذا قمت بتضمين وكلاء مراقبة خاصين بالسحابة داخل الحاويات مباشرةً، وفي هذه الحالة سيتعين عليك تحديث الوكلاء لإعادة استضافة الحاويات على سحابة مختلفة دون تعطيل سير عمل المراقبة والتنبيه.
إدارة حاويات التأثير في Kubernetes
إذا اخترت استخدام Kubernetes لإدارة الحاويات – وهو ما قد ترغب أو لا ترغب في القيام به، اعتمادًا على الاحتياجات الفريدة لتطبيقك – فستكون تجربتك أيضًا مختلفة في النواحي الرئيسية مقارنة بمعظم الأساليب الأخرى لتنسيق الحاويات. وذلك لأن Kubernetes يتبنى نهجًا فريدًا نسبيًا لإدارة التكوين وإدارة البيئة والمزيد.
على سبيل المثال، نظرًا لأن Kubernetes لديه منهجه الخاص في التعامل مع الأسرار، فستحتاج إلى إدارة كلمات المرور ومفاتيح التشفير والأسرار الأخرى للحاويات التي تعمل على Kubernetes بشكل مختلف عما تفعله في البيئات الأخرى.
يبدو تكامل الشبكة أيضًا مختلفًا بالنسبة لعمليات النشر المستندة إلى Kubernetes. يدعم كوبيرنيتيس طرق متعددة (مثل ClusterIP وNodePort) لتعريض الحاويات للشبكات العامة، ولكنها جميعًا تعتمد على مفاهيم وأدوات فريدة لـ Kubernetes. لا يمكنك أخذ تكوين الشبكة الذي قمت بإنشائه لـ Docker Swarm، على سبيل المثال، وتطبيقه على مجموعة Kubernetes.
وكمثال آخر، تستخدم معظم الفرق أدوات إدارة البيئة المصممة خصيصًا لـ Kubernetes، مثل Helm، لإدارة البيئة. يأتي Kubernetes أيضًا مع أداة الإدارة الخاصة به، kubectl.
لكل هذه الأسباب، يتطلب العمل مع Kubernetes خبرة متخصصة – لدرجة أنه من الشائع اليوم رؤية المؤسسات تقوم ببناء فرق هندسة الأنظمة الأساسية المخصصة لـ Kubernetes. على الرغم من أن المبادئ الكامنة وراء إدارة الحاويات في Kubernetes قد تكون هي نفسها المتبعة مع المنسقين الآخرين، إلا أن الأدوات والممارسات التي تحتاجها لتنفيذها في Kubernetes مختلفة تمامًا.
الخلاصة: البناء مرة واحدة، والتكوين عدة مرات
نظرًا للاختلافات الكبيرة التي يمكن أن تؤثر على إدارة الحاويات في أنواع مختلفة من البيئات، فمن التبسيط بعض الشيء التفكير في الحاويات كحل يحرر المطورين ومهندسي تكنولوجيا المعلومات من الاضطرار إلى التفكير في البيئات المضيفة.
صحيح أنه يمكنك عادةً نشر نفس صورة الحاوية في أي مكان. لكن تكوينات وأدوات الأمان والشبكات والمراقبة التي تستخدمها يمكن أن تبدو مختلفة تمامًا داخل السحابات ومنسقي الحاويات المختلفين. يمكنك إنشاء تطبيقك مرة واحدة، ولكن لا تفترض أنه سيتعين عليك تكوينه مرة واحدة فقط إذا كنت تريد نشره عبر بيئات متعددة.
