في شركة كبيرة ، غالبًا ما يكون من الصعب للغاية تنسيق تخصيص الموارد لمهام العمل. All Agile ينقض على جدار اتفاق مدته ثلاثة أسابيع مع IS بشأن بنية تحتية جديدة. لذلك ، غالبًا ما نتلقى طلبات لنقل البنية التحتية إلى حاويات من أجل طرح التغييرات مرة كل ثلاثة أشهر ، وعندما يحتاجها العمل. في الوقت نفسه ، يطلبون تكوين / تنفيذ Kubernetes كأداة التنسيق الأكثر شعبية ، رغم أنه ، كما تبين الممارسة ، من بين 10 مشاريع ، هناك حاجة إلى ثلاثة كحد أقصى. ولكن في الواقع ، من المفيد استخدام Kubernetes ، ولكن OpenShift ، أو العمل معها ليس في البنية التحتية الخاصة بك ، ولكن في سحابة عامة ، على سبيل المثال. سأحاول التحدث عن حالات العمل الحقيقية التي قررناها ، وسأصف الاختلافات الرئيسية بين Kubernetes و OpenShift. وكذلك حول كيفية تقليص تنسيق أمن المعلومات إلى 30 دقيقة ، وظل الجميع على قيد الحياة.
كان لدينا العديد من التطبيقات المثيرة للاهتمام التي نجحنا في حل المشكلات المتراكمة للعميل. على سبيل المثال ، جاءت إلينا شركة بيع بالتجزئة كانت بحاجة إلى طرح رقائق جديدة باستمرار. المنافسة وحشية! ولهم فقط البنية التحتية للتنمية في كل مرة يستغرق من ستة إلى عشرة أيام ، مما يسبب التوقف. يعد حل المشكلة عن طريق شراء أجهزة جديدة للاختبار والتطوير أمرًا مكلفًا والطريق إلى أي مكان. نتيجة لذلك ، نقلنا البنية التحتية لتكنولوجيا المعلومات إلى الحاوية الافتراضية. نتيجة لذلك ، تم تخفيض الحمل بنسبة 40٪ بفضل الحاويات ، ويتم الآن إعداد البنية التحتية للتطوير الجديد من ساعة إلى أربع ساعات. المكافأة هي المدخرات ، حيث يمكن أن تستمر جميع العمليات على أساس القدرات الحالية دون شراء قدرات جديدة.
ماذا سنفعل مع أمن المعلومات؟
IB هم أشخاص ضروريون للغاية. غالبًا ما يبتعدون كثيرًا عن متطلباتهم الداخلية للمشروعات ، ولكن هذا أفضل بكثير من رؤية يوم ما أن المتسللين الرومانيين قد أحاطوا بخادم SFTP الخارجي.
ولكن هناك مشكلة معهم. إذا اعتبرنا العملية التجارية بمثابة ناقل ، فغالبًا ما يصبح تقسيمها هو عنق الزجاجة الذي يعتمد عليه الجميع. من ناحية ، يتحملون مسؤولية جميع المخاطر المرتبطة بالأمان ، من ناحية أخرى ، فهم ببساطة لا يستطيعون إدارة ماديًا يدويًا لعرض الشفرة وكل تفاصيل بنية المنتج الجديد.
الوضع مشابه جدًا لأجهزة الأمن في المناطق التي بها تدفق كبير من الناس. يمكننا ترتيب فحص شامل لكل راكب في قطار الأنفاق ، مع وضعه على الماسحات الضوئية ، والتواء الجيوب وفحص الهاتف. نتيجة لذلك ، ومع ذلك ، بدلاً من الأمان ، ستحصل على انهيار كامل للنقل وشلل في النظام. الخيار الوحيد في هذا الموقف هو تنظيم أنظمة آلية تستجيب ، على سبيل المثال ، للأفراد ، أو تحدد هوية الأشخاص المطلوبين أو تتفاعل مع بعض السلوكيات غير الطبيعية.
في السياق الخاص بنا ، يتم تنظيم مثل هذه الأنظمة الآلية بشكل صحيح عمليات CI / CD مع محللات الأكواد في المراحل الوسيطة ، مثل حلول JFrog Xray for Artifactory ، ومكسرات Kubernetes / OpenShift المشدودة بشكل صحيح ، والتي لا تسمح بمناهج غير آمنة مثل إطلاق حاوية من مستخدم الجذر. الآن نحن نعد حلاً محاصرًا من شأنه توفير كل هذا.
الهدف هو الانتقال من مفهوم "لن يذهب إلى البيع حتى ننظر" إلى "إذا لم تكن هناك اعتراضات ، فسيتم نشره تلقائيًا." لا يوجد أي نقطة في الأتمتة إذا ظلت العمليات التنظيمية على حالها.
في أحد المشاريع ، تمكنا من تقليل وقت فشل IS إلى 30 دقيقة. بمعنى آخر ، إذا لم يرفض "حارس الأمن" الإجراء خلال نصف ساعة ، فسيتم الاتفاق عليه تلقائيًا ، ويتم إدخال التغييرات في الإنتاج. نحاول الآن تحقيق مهلة 60 دقيقة لجميع المنسقين في المشروع دون المساس بالأمن.
ما هو الفرق بين أنظمة إدارة الحاويات؟
Kubernetes و OpenShift هما الحلان الأساسيان لتنسيق الحاويات. دعنا نحلل الاختلافات والمزايا الرئيسية للشركة.
انفتاحKubernetes هو منتج مفتوح بالكامل ويمكن نشره بشكل مستقل وتقديم الخدمات إما بمفرده أو بدعم خارجي. استقر الوضع في سوق العمل بالفعل بشكل أو بآخر ، ولم يعد العثور على خبراء في هذا الموضوع يمثل مشكلة.
OpenShift هو منتج شبه مغلق مع نظام ترخيص متطور من RedHat. في الواقع ، يحتوي على Kubernetes ، ولكنه يحتوي على مجموعة من الارتباطات الإضافية التي تعمل على تبسيط العديد من المهام. يوفر البائع الدعم الكامل المدفوع لمنتجه.
هنا يعتمد الخيار على ما يناسبك - الدعم من قِبل المتخصصين أو البائع.
منصةتعمل Kubernetes على أي نظام Linux تقريبًا ومعظم مزودي الخدمات السحابية.
لا يعمل OpenShift في أي مكان باستثناء RHEL و Red Hat Atomic و Red Hat CoreOS. هناك إصدار مجتمع - OKD ، لكنه مرتبط بإحكام بالتوزيعات. الاستثناء الوحيد هو أنه يمكن تثبيته على CentOS. وتذكر أن Red Hat رسميًا لا يضمن الدعم المدفوع.
سياسات الأمنيحتوي OpenShift خارج الصندوق على إعدادات أمان أكثر إحكاما. هذه ميزة إضافية عند نشر البنية التحتية من نقطة الصفر ، ولكنها قد تكون مشكلة بسبب عدم توافق بعض الصور مع السياسيين. على سبيل المثال ، في OpenShift ، يُمنع تشغيل الحاوية من الجذر ، والتي تقطع التوافق مع الصور القديمة. من ناحية أخرى ، فإن هذا النهج ، جنبًا إلى جنب مع التكامل المريح مع AD ، والتسجيل المريح على أساس مكدس EFK (ElasticSearch ، Fluentd ، Kibana) يمنحنا الأمان خارج الصندوق المطلوب لتفريغ وحدة IS.
يمكن أيضًا الانتهاء من Kubernetes إلى هذا المستوى ، لكنه سيتطلب الكثير من الجهد والوقت من جانب المهندسين.
قوالبتعد قوالب OpenShift أقل مرونة من مخططات Kubernetes Helm. نظرًا لسياسات الأمان الأكثر صرامة ، لا يمكن لـ Red Hat توفير مرونة مخططات Helm في الوقت الحالي. ومع ذلك ، في OpenShift 4 ، استقر الموقف بفضل
المشغل المتكامل.
وجود قوالب مصممة تصميما جيدا خارج الصندوق يجعل الحياة أسهل بكثير. في الواقع ، هذا هو خيار مدير الحزم لبناء الخدمات المختلفة وتكوينها.
أحد الأوامر الشرطية "helm install prometheus-operator" ينشر نظامًا معقدًا إلى حد ما ، والذي يستغرق وقتًا طويلاً لنشر نفسه. Kubernetes تقود الطريق.
استنتاجات عامةمثل معظم المنتجات ، يعتبر Red Hat OpenShift حلاً أكثر محاصرة ، ولكنه أكثر صرامة من الناحية المعمارية. يتطلب موظفين أقل احمرارًا وأكثر خبرة للعمل. سيناريوهات النشر أكثر ملاءمة ، والتكامل الممتاز مع حلول CI / CD ، على وجه الخصوص ، مع جنكينز. يعد OpenShift أمرًا رائعًا للشركات التي يسهل دفعها لدعم المنتج النهائي بدلاً من توظيف متخصصين.
بالنسبة للشركات ذات الاختصاصيين الأقوياء في هذا المجال ، قد تكون Kubernetes حلاً أكثر مرونة وإثارة للاهتمام. قد يكون أيضًا مناسبًا للشركات الصغيرة نسبيًا التي تريد الادخار على تراخيص Red Hat ، لكن ليس لديها مهام معقدة تتطلب خبراء مؤهلين تأهيلا عاليا.
حالات حقيقية
سأحاول توضيح كيف ساعدت تقنيات تعبئة الحاويات في حل مشكلات الأعمال ، وحفظ التراخيص وضمان تجانس الأحمال القصوى خلال غارات المستخدمين الجماعية.
دراسة حالة: التجارة الإلكترونية
المشكلةكان لدى العميل أكثر من 100 خدمة نشطة تدير مؤسسة VMware السحابية. وكل هذه الحديقة واجهت عدة مشاكل مختلفة:
- 12 خدمة تتطلب موارد وغير ذات هامش تدور على برنامج VMware ، وتستهلك ميزانية تصل إلى حوالي 408،000 دولار في السنة.
- بدأت ثلاث خدمات (بوابة وتطبيقان للهاتف المحمول) في التطور بشكل نشط: على مدار سبعة أشهر ، زادت كمية الموارد اللازمة للعمل 4.5 مرة وتستمر في النمو.
- تحتوي العديد من خدمات العملاء على ذروة الأحمال ، حيث تحتاج الموارد من ستة إلى سبع مرات أكثر من الأوقات العادية. وفقًا لذلك ، تم تخصيص المعدات لتشغيلها الصحيح ، والتي كانت تستخدم في معظم الوقت بأقل من 15 ٪.
بالإضافة إلى كل هذا ، لدى العميل رغبة في الابتعاد عن الربط إلى بائع افتراضي واحد.
قرارناالحل الأول والأبسط: ننقل الخدمات بالقمم إلى
سحابة CROC العامة . مع الفواتير للموارد المستهلكة. كل شيء بسيط وممل قدر الإمكان. يعد الانتقال من برنامج VMware الخاص بشخص ما إلى KVM أحد أكثر الحالات شيوعًا للمهندسين السحابيين.
نظرًا لأن العميل قد قام بالفعل بشراء الأجهزة الخاصة بالتدريج ، فقد كان علينا فقط حساب التراخيص. بالنسبة للمضيفين الجدد من VMware ، يكلفون حوالي 2،100،000 دولار ، وهو ما لم يناسب العميل كثيرًا. اقترحنا نقل بعض الخدمات إلى KVM تشغيل OpenStack. ومن أجل عدم الضياع ، أدمج إدارة كلتا البنى التحتية بواسطة CloudForms (وفي الوقت نفسه OpenShift).
نتيجة لذلك ، تلقى العميل الكتف الثاني من سحابة خاصة بناءً على OpenStack ، والتي أغلقت سؤال البائع. عن طريق نقل بعض الخدمات كثيفة الاستخدام للموارد إلى كتف جديد ، اتضح أن ذلك يقلل من تكلفة تراخيص VMware (لقد أصبح دعم 24 × 7 من CROC أرخص).
القضية: التجزئة
المشكلةخلال التدقيق ، اتضح أن هناك شيئًا فظيعًا يحدث مع العميل فيما يتعلق بتخصيص البنية التحتية. المشاريع - أكثر من 250 ، وفرق التطوير - أكثر من 150 ، نصف حاوية في Kubernetes. يتم شراء الموارد لكل مشروع جديد وتظل مخصصة له دون القدرة على الاختيار ، حتى لو لم يتم استخدامها. لا يوجد أي فاتورة على الإطلاق ، لا توجد بوابة واحدة. تكاليف ضخمة لبيئات الاختبار وما قبل الإنتاج ، لأنها تدور أيضًا على برنامج VMware.
في الوقت نفسه ، لا يرغب العميل في التبديل بالكامل إلى نظام أساسي جديد ويريد تجميع كل شيء تحت بوابة إدارة واحدة. علاوة على ذلك ، فإن "كل شيء" ليس VMware فحسب ، بل هو أيضًا PaaS والحاويات وفواتير واحدة.
قرارنانتيجةً لذلك ، تبين أن الحل داخلها يتراكم ، لكن في الخارج ، يبدو كل شيء بسيطًا للغاية.
الدليل الذي يحدد المستخدم فيه معلمات الجهاز الظاهري والدائرة اللازمة: DevTest ، PreProd ، Prod. ثم تختار CloudForms مكان نشر المورد المطلوب: على VMware أو على OpenShift. ما زلنا نعمل على إعداد فواتير واحدة ، نظرًا لأن حل VMware + OpenShift المختلط صعب للغاية.
في الواقع ، وبهذه الطريقة نضع الأمور في نصابها الصحيح في البنية التحتية ، ونفصل الأنقاض التي تراكمت على العميل.
الحالة: الصناعة
المشكلةيستغرق نسخ VMs إلى بيئات مختلفة (Test و Dev و Prod و Preprod) أكثر من ثلاثة أيام ويتطلب التنفيذ اليدوي لـ 15 عملية مختلفة ، تستغرق كل منها مدة تصل إلى 30 دقيقة. أظهرت مراجعة أعمق أنه في وقت سابق استغرق الأمر أسبوعين لتخصيص الموارد لمشروع جديد ، وكان هناك 10-20 طلبًا شهريًا. يوجد الآن أكثر من عشرة طلبات للحصول على موارد في اليوم ، الأمر الذي أدى إلى الانهيار دون التشغيل التلقائي.
قرارنافي الواقع ، يحتاج العميل إلى نقل البنية التحتية لتكنولوجيا المعلومات إلى نموذج خدمة ، وإعادة إنشاء وأتمتة عملية إجراء تغييرات على البنية التحتية ، وإنشاء بوابة للخدمة الذاتية ، وملء كتالوج الخدمة وتنفيذ بيئة لإدارة التطبيقات في حاويات. لقد قمنا تلقائيًا بعملية نسخ VM ، لكن الأمر استغرق الكثير من الوقت: 40-60 دقيقة ، وهذا لا يناسب العميل. نتيجة لذلك ، اقترحنا التبديل إلى الحاويات ، مما قلل من وقت النسخ إلى ثلاث إلى خمس دقائق.
النتائج
لا تعتبر خدمات الحاوية والميكروسكولز من رموز الشفرة السيئة التي سيتم كتابتها بالقدم اليسرى وتطير فورًا إلى الإنتاج. على العكس من ذلك ، هذا مفهوم كامل ، يتضمن مجموعة من التحسينات بسبب الأتمتة العميقة لجميع العمليات:
- يصبح رمز أنظف: linter ، محلل الرمز ، الاختبار الآلي.
- أصبحت الشفرة والعمارة أكثر أمانًا: أدوات الأمان ذات القدرات الواسعة ، حتى الحظر التلقائي لنشر الشفرة غير الآمنة.
- أصبحت الخدمات أكثر مرونة ومتحركة: دورات التطوير أصبحت قصيرة للغاية وتستجيب بسرعة للتغييرات.
- القياس التلقائي تحت الحمل: لم يعد المورد الخاص بك يتراجع خلال ساعة الذروة ، وفقد المبيعات والعملاء.
- تخصيص بسيط للموارد لمشروعات جديدة ، وتقليل الوقت المستغرق في التنسيق.
- في كثير من الأحيان ، يمكن أن يقلل نقل الحاويات بشكل كبير من الوقت إلى السوق.
وأحيانًا لا تكون هناك حاجة للحاويات على الإطلاق ، ويمكن حل المشكلة عن طريق الانتقال إلى سحابة خارجية. ولكن من أجل اتخاذ قرار ، على أي حال ، نحن بحاجة إلى تدقيق خارجي جيد وتحليل ما يحدث. باختصار ، تعتبر الحاويات مجرد أداة من أدوات حل المشكلات التجارية ، وإن كانت رائعة للغاية.