كيف قمنا بتحديث البنية التحتية في Xoxoday

1. مقدمة

إلقاء نظرة على البنية التحتية في الأيام القليلة الأولى من عملي في Xoxoday، أدركت بسرعة أن البنية التحتية كانت وليدة نسبيا. كانت النهايات السائبة المتعددة التي لاحظتها مؤشرات محتملة للديون الفنية ، بالمعنى الدقيق للكلمة من حيث إعداد البنية التحتية. تضمنت النهايات السائبة التصميم والهندسة المعمارية والأدوات والمراقبة والتسجيل ، إلى جانب العمليات والممارسات المختلفة.

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

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

أخيرا ، هناك مطلب حاسم آخر ينشأ بسبب أسباب تتعلق بالخصوصية والامتثال الأمني وهو أن معظم العملاء يهتمون بموقع البيانات. التوقع المعتاد هو أن البيانات موجودة ولا تغادر البلد أو المنطقة المطلوبة.

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

ومن ثم ، بعد بعض الدراسة المتأنية ، أدركنا بسرعة أننا بحاجة إلى الحصول على أفضل عمليات وممارسات أتمتة البنية التحتية جنبا إلى جنب مع مجموعة من التقنيات الحديثة المستندة إلى السحابة للانتقال إلى السحابة الأصلية وتقديم أفضل خدمة وتجربة لمستخدمينا.

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

2. الحاجة إلى الأتمتة

كانت أتمتة الخدمة في السحابة موضوعا ساخنا في السنوات القليلة الماضية ، مما أدى إلى ظهور العديد من الأدوات والتقنيات الممتازة. كانت احتياجاتنا مدفوعة عادة بطبيعة العمل ومتطلباته. بالنسبة لنا ، كانت العوامل التالية حاسمة:

• التوفر العالي
• التحجيم التلقائي
• الشفاء الذاتي

بالإضافة إلى ذلك ، توفر الأتمتة الفرصة لتحقيق البنية التحتية كرمز ، مما يسمح لنا بالتفاعل مع البنية التحتية مع الاستفادة من المزايا الرائعة لأنظمة التحكم في الإصدار.

كان هذا نقلة نوعية كبيرة لأنه سمح لنا بالنظر بشكل استباقي إلى البنية التحتية وتقليل التفاعلات التفاعلية (الحتمية). لقد جعل عمليات التراجع أسهل وساعدنا على تتبع التغييرات عبر البنية التحتية بكفاءة. أيضا ، تعني الأتمتة أن فرق DevOps لدينا يمكن أن ترتاح في سلام في ساعات غريبة.

فائدة إضافية أخرى للأتمتة هي أنها تفتح طرقا مختلفة لتحديث وتحسين إنتاجية المطورين. سنلقي نظرة أعمق على هذا الموضوع بالذات في القسم التالي حول التسليم المستمر.

3. التكامل المستمر والتسليم والنشر

يمكن أن تكون عمليات الإطلاق كابوسا مؤلما إذا لم تكن خطوط الأنابيب والأدوات والإرشادات المناسبة في مكانها الصحيح. هذا يعني أن العمود الفقري الحاسم ل DevOps كان خطوط أنابيب CI / CD التي ساعدتنا في اختبار التعليمات البرمجية الخاصة بنا ودمجها وبنائها ونشرها في الإنتاج.

كنا نهدف إلى أن نكون قادرين على إجراء عمليات نشر إنتاج متعددة في يوم واحد والقيام بهذه عمليات النشر بسلاسة. إذا تعطلت ، أردنا التراجع عن التحديثات بسلاسة وسرعة.

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

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

بدءا من الممارسة الراسخة المتمثلة في وجود بيئات متعددة ، سمح لنا باختبار وفحص مجموعة الميزات الخاصة بنا قبل نشرها في الإنتاج. بمجرد الانتهاء من العمل على ميزاتهم أو أخطاءهم أو تحسيناتهم الخاصة ، فتح مطورونا طلب سحب إلى فرع "dev" على git.

بمجرد الموافقة على العلاقات العامة ، تم دمج الالتزامات في فرع التطوير. لقد قدمنا آلية تشغيل يدوية لنشر فرع التطوير للمطورين. (التي سوف نستكشفها لاحقا)

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

بمجرد اختبار قاعدة الشفرة ، وموافقة فريق ضمان الجودة عليها ، تم دمج الالتزامات بشكل أكبر في فرع "التدريج أو uat". من هنا ، تم نشر قاعدة التعليمات البرمجية (تم تشغيلها يدويا) إلى بيئة التدريج ، والتي سعينا جاهدين لإبقائها قريبة من الإنتاج قدر الإمكان.

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

قمنا بمسح وتحليل أفضل الأدوات الممكنة ل CI / CD ، وأخيرا ، استقرنا مع Github Actions. باختصار ، زودتنا Github Actions ببيئة متكاملة تعمل بشكل جيد مع سير عمل GitHub ولديها الحد الأدنى من الإعداد لفرق المطورين.

إلى جانب التكامل الوثيق ، فقد زودنا أيضا بأحدث آليات CI / CD. إنه فائق السرعة وبأسعار معقولة وسهل التكوين والتخصيص. وكان لديه بناء جملة سهل للغاية قائم على YAML لتحديد الوظائف مما يسمح لنا بالالتزام بتعريف CI / CD مع قاعدة الشفرة وتتبعها بذهول git.

أ. التكامل المستمر

لقد استكشفنا بعض الطرق لتشغيل الإصدارات تلقائيا ولكننا سرعان ما أدركنا أنه من الأفضل السماح للمطورين بالتحكم في وقت البناء. قد يكون هناك العديد من الأسباب لصالح أو ضد النشر التلقائي والنشر اليدوي.

من الأفضل مواءمة توقعات الفرق والتفاف هذا القرار بناء على الراحة ، لأن الكثير من الأتمتة له مخاطر محتملة.

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

إذا تركنا جانبا اختبارات الوحدة والاختبارات الوظيفية التي أجراها المطورون في التزاماتهم ، فلنركز على جانب البنية التحتية للأشياء في CI / CD الخاص بنا. تتم مصادقة مهمة الإنشاء ، بمجرد تشغيلها ، بشكل أساسي باستخدام ECR ، وتدير ذاكرة التخزين المؤقت للصورة ، وتشغل أمر إنشاء عامل الإرساء لإنشاء صورة حاوية.

يتم دفع صورة الحاوية هذه إلى مستودع ECR المعني. إنه إعداد بسيط ولكنه قوي ومرن للغاية لأنه يسمح لنا بتسليم الزناد للمطورين أثناء أتمتة العملية بأكملها.

ب. عمليات النشر المستمرة

كان لدينا مشغل يدوي تم توفيره للمطورين لنشر أحدث الإصدارات على البيئات المعنية. استخدمنا علامات صور Docker للتمييز بين صور الحاوية لفرع git الفردي والبيئة.

تعمل خدماتنا المصغرة على Kubernetes. تقوم مهمة النشر النموذجية بما يلي:

1. تحديث ملفات التكوين والمتغيرات: نقوم بحذف configmaps الموجودة وإعادة إنشائها لأن Kubernetes لا يقوم بتحديث configmap موجود. يتم تخصيص ملفات التكوين الخاصة بنا في مستودع git خاص، ويتم تخزين المعلومات الحساسة على AWS Secrets Manager. وبالتالي ، يسمح لنا git بتتبع ملفات التكوين مما يسهل علينا حذف وإعادة إنشاء configmaps في kubernetes.
2. تحديث النشر والخدمة على Kubernetes (في حالة وجود تغييرات على ملفات Yaml)
3. وأخيرا ، قم بنشر طرح kubernetes لأن Kubernetes لا يقوم تلقائيا بتحديث عمليات النشر / البودات فقط لإجراء تغييرات على ملفات التكوين (configmaps).

كنا نستخدم الموارد التالية من مجتمع إجراءات GitHub لمساعدتنا على الاتصال والمصادقة والتواصل بسهولة مع EKS/ECR & Docker.

• إلغاء عمليات التشغيل السابقة
• تكوين بيانات اعتماد AWS
• تسجيل الدخول إلى AWS ECR
• إعداد عامل ميناء بيلدكس
• الخروج مستودع آخر
• Kubectl AWS EKS Access

4. الهندسة المعمارية

استخدمنا AWS لتلبية احتياجات البنية التحتية لدينا. توفر لنا AWS نظاما بيئيا غنيا من الخدمات التي تعمل بكفاءة على تشغيل وإدارة أسطولنا من الخدمات المصغرة والبرامج الخلفية والوسيطة ذات الصلة.

تعمل هذه الخدمات المصغرة فوق Kubernetes التي تديرها AWS EKS. يوفر لنا عرض AWS EKS الكثير من الوقت والجهد الذي Xoxoday بخلاف ذلك ، ستنفق على إدارة دورة حياة مجموعة Kubernetes نفسها. يتيح لنا ذلك الاستفادة من النظام البيئي السحابي الأصلي مع التركيز على خدماتنا والعمل عليها.

يجلب Kubernetes حوالي عقد من الخبرة من إدارة البنية التحتية العالمية ل Google. يوفر لنا ميزات مختلفة. على سبيل المثال لا الحصر: الإصلاح الذاتي ، والقياس التلقائي ، والتوافر العالي مع تعزيز وزيادة الكفاءة التي نستخدم بها بنيتنا التحتية الأساسية. نستخدم الدخول لعرض خدماتنا للعالم الخارجي عبر مزيج من موازنات التطبيقات والتحميل الكلاسيكية وأتمتة إدخال DNS route53.

تتصل هذه الخدمات بالواجهة الخلفية الخاصة بنا، والتي تتم استضافتها في مزيج من خدمات AWS المدارة مثل Kafka المدارة وRDS ومثيلات EC2 المستضافة ذاتيا. نحن نستفيد بشكل كبير من Terraform للإعداد الآلي ل EKS، وهو مزيج فريد من قوالب Terraform وAWS Launch لإنتاج مثيلات EC2 وإدارتها تلقائيا.

بالإضافة إلى ذلك ، يتم استخدام SaltStack للمناورات المعقدة لإدارة الإعداد الآلي لأسطول مثيلات EC2. يسمح لنا بإدارة وتحديث وصيانة نظام التشغيل والخدمات التي تعمل في الأعلى تلقائيا. يحتوي SaltStack على مجموعة ميزات قوية وبنية مصممة ببراعة ومرنة وقابلة للتوصيل. ثم نقوم تلقائيا بتوفير الخدمات وأخذ إعدادات الواجهة الخلفية التي تم تكوينها حديثا (عناوين IP وما إلى ذلك) وملء ملفات تكوين kubernetes وتحديث خرائط التكوين ونشرها في البيئة.

يتيح لنا ذلك تكوين وإعادة تكوين الخدمات عديمة الحالة التي تعمل في بيئة Kubernetes ليتم توفيرها وتكوينها تلقائيا مع التغييرات الديناميكية في إعداد الواجهة الخلفية. يتم تخزين صور الحاويات الخاصة بنا على AWS ECR لأنها توفر لنا خدمة رائعة أخرى تتكامل بسلاسة مع مجموعة التقنيات والهندسة المعمارية الخاصة بنا.

5. التسجيل والمراقبة والتنبيه و APM

سنكون عميانا إذا لم يكن لدينا آليات التغذية الراجعة المناسبة لفهم ما يجري في بنيتنا التحتية ، خاصة إذا كنا نتحدث عن سيناريو Polycloud.

أ. البحث المرن / بطلاقة / كيبانا

نحن نستخدم مكدس EFK الفريد لمخاوفنا المتعلقة بالتسجيل. يتيح لنا ذلك إنشاء مجموعة ديناميكية من الخدمات المصغرة التي تعمل عبر الحاويات والأجهزة الظاهرية والحفاظ عليها مع الاحتفاظ بالسجلات في خط أنابيب مركزي.

يتيح لنا ذلك الوصول إلى السجلات للمثيلات / الحاويات التي تم إتلافها لأسباب مختلفة. وهذا يسهل علينا الوصول بشكل معقول ومعالجة مخاوف متعددة في الإنتاج. فيما يلي بديل بحث مرن آخر لتذهب إليه.

ب. جرافانا / بروميثيوس

تتيح لنا لوحة معلومات Grafana ، جنبا إلى جنب مع قاعدة بيانات السلاسل الزمنية بروميثيوس ، الاحتفاظ بتفاصيل مختلفة حول بنيتنا التحتية مثل وحدة المعالجة المركزية / ذاكرة الوصول العشوائي / التخزين ، إلخ. ويبقينا على اطلاع دائم بالحالة الحالية للبنية التحتية في الوقت الفعلي تقريبا.

يتيح لنا ذلك تنفيذ آليات التنبيه ، مما يسهل على فريق DevOps لدينا التعامل مع الحوادث في بنيتنا التحتية. على الرغم من كل الاستعدادات وأفضل ما في الهندسة المعمارية والتصميم ، لا يزال من الممكن كسر الأشياء. تسمح أنظمة Grafana Prometheus ، جنبا إلى جنب مع Alertmanager ، بتخفيف الحوادث في الإنتاج.

بالإضافة إلى ذلك ، تستفيد هذه المجموعة من إدارة برمجة التطبيقات ، والتي توفر لنا مجموعة غنية من المقاييس التي تمنحنا رؤى مهمة حول المنتجات واستخدامها والمزيد.

6. تعطيل بيئات المطورين

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

ومن ثم ، كان علينا أن نكون مبدعين ونعود إلى المياه العميقة لعالم السحابة الأصلية لإيجاد حل ممكن. لقد رأينا الكثيرين ، على سبيل المثال لا الحصر:

- التواجد عن بعد

- سكافولد

- كوبيفود

في الوقت الحاضر ، المفضل لدينا والأكثر فائدة لتلبية احتياجاتنا هو Kubefwd ، لكننا قد نستكشف الأدوات الأخرى في المستقبل. يسمح لنا Kubefwd بجعل خدمات Kubernetes قابلة للوصول على محطة العمل المحلية باستخدام نفس DNS كما لو كان جهاز المطور المحلي موجودا داخل مجموعة Kubernetes!

وهذا يعني زيادة مذهلة في الإنتاجية تجعل المطورين أكثر كفاءة مع تحسين التجربة الإجمالية وتقليل الوقت نفسه للحصول على ميزة في العالم.

7. خاتمة

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

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

يتيح لنا هذا الإعداد تكرار مجموعتنا الكاملة من الخدمات والواجهة الأمامية والخلفية بسهولة وإعداد نفسه تلقائيا في غضون بضع دقائق. سيمكننا ذلك من إنشاء بيئات إنتاج ذرية متعددة ومستقلة ، وتعديلها باستخدام خطوط أنابيب CI / CD الخاصة بنا وإدارة الإعداد المعقد وصيانته تلقائيا بسهولة.

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

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

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