من خطأ بنسبة 13% في الطلبات خلال الجمعة السوداء إلى عدم وجود أي توقفات في الخدمة: لقد وفرنا 60% من تكاليف الخوادم بفضل النشر المعتمد على الحاويات.

في العام الماضي ، انفجرت واجهة تحليل العنوان لدينا مباشرة - 13٪ من الطلبات تقارير 429 ، وتلقى مكتب الخلفية لخدمة العملاء أكثر من 300 شكوى من التجار ، واستغرق 3 من الطرف الخلفي 24 ساعة لتحمل الذروة.في ذلك الوقت ، كانت خدمتنا تعمل على خادمين سحابيين ثابتين ، حيث اعتمدت القدرة على التوسع على تغيير التكوين يدويًا ، ومرة الذروة في حركة المرور في حالات جديدة.

دعونا نوضح أولاً ما هو النشر المحاط بالحاويات (Containerized Deployment).

ببساطة، يتم تجميع كودك، ومكتبات الاعتمادات، وملفات الإعدادات في حاوية موحدة تتراوح أحجامها بين عدة ميغابايت وعدة مئات من الميغابايت، بحيث يكون بيئة التشغيل متطابقة بنسبة 100٪ بغض النظر عن الخادم الذي يتم تشغيل البرنامج عليه. كان حجم صورة خدمة تحليل العناوين التي قمنا بتجميعها في البداية كبيرًا.187MB،عملية السحب وبدء التشغيل لا تستغرق أكثر من 10 ثوانٍ.

المكاسب الأساسية الثلاثة التي حققناها بالفعل

• التوسعة والتقليص التلقائيين كانا حقًا مفيدين للغاية: في هذا العام، زادت الزيارات خلال عطلة الجمعة السوداء ثلاث مرات، فقام النظام تلقائيًا بتشغيل 27 مثيلًا للحاويات، وبعد انخفاض الذروة تم تقليل عددها تلقائيًا إلى 3 مثيلات، دون أي تدخل يدوي، وانخفض معدل الأخطاء إلى أقل من 0.1%.
• الخطأ المتعلق بعدم توافق البيئات قد اختفى تمامًا: المشكلات الغامضة التي كانت تعمل بشكل صحيح عند التشغيل المحلي ولكن تتسبب في أخطاء فور النشر على الخادم، والتي كانت تمثل 40% من إجمالي أخطائنا، لم تعد تظهر بعد نقل النظام إلى الحاويات.
• تم تخفيض تكلفة الخوادم بنسبة النصف مباشرة: في السابق، كنا نستأجر 8 خوادم عالية الأداء طوال العام لتحمل الأحمال القصوى، وكان معدل الاستخدام الفعلي لا يتجاوز 15٪، أما الآن فندفع فقط مقابل الاستخدام الفعلي، مما يوفر لنا 60٪ من نفقات الخوادم سنويًا.

لا تنظر فقط إلى الجوانب الإيجابية، لقد وقعنا في العديد من المشاكل بالفعل.

عندما كنا على الحاوية في محاولة لتوفير المشاكل، والسجلات، والملفات المؤقتة في الحاوية، والنتيجة هي تدمير تلقائيا في حالة واحدة، 3 أيام من سجل الطلب اختفى مباشرة، واستغرق إعادة البيانات يومين كاملين.مرة أخرى المرآة معبأة الكثير من الاعتماد عديمة الفائدة، وارتفع وقت التشغيل من 10 ثانية إلى دقيقتين، عندما جاء تدفق المفاجئ، فإنه لم يحق الوقت لتوسيع السعة، وكاد أن يعطل مرة أخرى.

أسهل الأمور التي يمكن تجاهلها هي مشكلات الصلاحيات: في البداية، منحنا الحاويات صلاحيات الروت (root)، ولاحقًا استغلت برامج التعدين هذه الصلاحيات واستهلكت 30% من موارد وحدة المعالجة المركزية (CPU)، ولم نكتشف ذلك إلا بعد مرور أسبوع من خلال أنظمة المراقبة.

فكر جيدًا أولاً فيما إذا كنت بحاجة حقًا إلى استخدامه أم لا.

إذا كنتم فريقًا صغيرًا من عدد قليل من الأشخاص تعملون على أداة داخلية تتميز بتقلبات حركة المرور المنخفضة جدًا، ولديكم خدمتين فقط، فلا داعي على الإطلاق لبذل جهد إضافي؛ من الأسهل بكثير استئجار خادم لتشغيل الأداة.

لكن إذا كان هناك تقلبات كبيرة في حركة المرور على خدمتك، أو كنت بحاجة إلى إطلاق تحديثات بشكل متكرر، أو كانت بيئات التطوير المختلفة داخل الفريق تتعارض مع بعضها البعض، أو كنت تشعر بالأسف بسبب إهدار موارد الخوادم غير المستغلة، فإن نشر التطبيقات باستخدام الحاويات (Containerization) يستحق بالتأكيد أن تخصص له أسبوعًا من وقتك لتجربته.

ثلاث نصائح محددة للمبتدئين

• لا تبدأ مباشرة بتعاملك مع مجموعات K8S؛ استخدم أولاً Docker Compose لتنفيذ عمليات النشر على جهاز واحد، واستوعب جيداً المنطق المتعلق بالتعبئة (packing)، التشغيل (running)، وتثبيت السجلات (logging). لقد اتبعنا هذا الأسلوب خلال الأشهر الثلاثة الماضية، وكان كافياً تماماً.
• تم تعبئة الصورة الأولى وفقًا لـ “مبدأ الحد الأدنى”， حيث تم تضمين فقط المكتبات الضرورية للتشغيل، واستخدام صورة أساسية من Alpine لتقليل الحجم بأكثر من النصف.
• يجب أن يتم تخزين جميع البيانات والسجلات الناتجة على محركات التخزين الخارجية للحاوية، ولا يجوز أبدًا أن توجد داخل الحاوية نفسها. هذه القاعدة مكتوبة في بداية معايير التشغيل الخاصة بفريقكم.

أسئلة شائعة وإجابات عليها

س: لا يوجد أحد في فريقنا يفهم الحاويات (containers)، هل سيكون تكلفة التعلم مرتفعة جدًا؟
الجواب: بالنسبة للاستخدام الأساسي، يمكنك تشغيل أول خدمة في غضون يومين عن طريق قراءة الوثائق التوجيهية الرسمية. أما بالنسبة لإعدادات المجموعات (الكلاسترات) الأكثر تعقيدًا، فيمكنك تعلمها عندما تحتاج إليها، ولن يكون هناك أي تأخير.

س: هل سيكون من الصعب نقل الخدمات الحالية إلى الحاويات؟
تم نقل جميع خدماتنا الثلاث الخلفية في غضون أسبوع، وقد استغرق معظم الوقت تنظيم الاعتمادات (الاعتمادات المطلوبة لتشغيل الخدمات)، بينما لم يستغرق كتابة ملف Dockerfile أكثر من يوم واحد.