ثمانية مكونات أساسية للبنية التحتية، مع توضيح وظيفة كل مكون، وأشهر الأدوات المستخدمة فيه، وكيف تتكامل هذه المكونات لتوفير تطبيقات موثوقة وقابلة للتوسع.
1. المستودعات (Repositories): تخزين وإدارة مكونات البرمجيات
المستودع هو مكان مركزي لتخزين الملفات البرمجية أو مكونات التطبيقات وإدارة إصداراتها. ويختلف نوع المستودع بحسب طبيعة المحتوى الذي يحتفظ به.
هناك نوعان رئيسيان:
أ. مستودع الكود المصدري (Source Code Repository)
يُستخدم لتخزين الكود البرمجي، وملفات الإعدادات، والتوثيق، وتعريفات البنية التحتية. كما يتيح تتبع التعديلات، والعمل الجماعي، ومراجعة الأكواد، والرجوع إلى الإصدارات السابقة.
أمثلة:
- GitHub - GitLab
ب. سجل صور الحاويات (Container Image Registry)
يُستخدم لتخزين صور الحاويات (Container Images) التي تحتوي على التطبيق ومكتباته واعتمادياته، بحيث يمكن تنزيلها وتشغيلها لاحقًا.
أمثلة:
- "AWS Elastic Container Registry (ECR)" (https://aws.amazon.com/ecr/) - "Docker Hub" (https://hub.docker.com/)
كيف تعمل هذه المكونات معًا؟
يقوم المطور برفع الكود إلى GitHub، ثم تتولى عملية CI/CD بناء التطبيق وتجهيزه داخل صورة Docker، وبعد ذلك تُرفع الصورة إلى سجل الحاويات مثل AWS ECR، لتقوم منصة التشغيل بتنزيلها وتشغيل التطبيق.
الفرق الأساسي: يُستخدم GitHub أساسًا لإدارة الكود المصدري، بينما يُستخدم ECR وDocker Hub لتخزين صور الحاويات. هذه الخدمات تكمل بعضها بعضًا ولا تؤدي الوظيفة نفسها.
2. Kubernetes: إدارة وتشغيل الحاويات
Kubernetes هي منصة مفتوحة المصدر لتنسيق وإدارة الحاويات (Container Orchestration). تعمل على أتمتة نشر التطبيقات الموجودة داخل الحاويات، وتوسيعها، وإدارة اتصالها، والتعامل مع الأعطال عبر مجموعة من الأجهزة.
بدلًا من إدارة كل نسخة من التطبيق يدويًا، يحدد الفريق الحالة المطلوبة للتطبيق، وتتولى Kubernetes العمل على الحفاظ عليها.
أهم الوظائف:
- النشر (Deployment): تشغيل العدد المطلوب من نسخ التطبيق. - التعافي التلقائي (Self-healing): إعادة تشغيل الحاويات المتعطلة ومحاولة استبدال النسخ غير السليمة. - التوسع (Scaling): زيادة أو تقليل عدد النسخ وفقًا للإعدادات أو حجم العمل. - اكتشاف الخدمات والشبكات (Service Discovery & Networking): تمكين مكونات التطبيق من التواصل مع بعضها. - التحديث التدريجي (Rolling Updates): نشر إصدارات جديدة مع الحد من انقطاع الخدمة.
أشهر خدمات Kubernetes المُدارة سحابيًا:
- "Amazon EKS" (https://aws.amazon.com/eks/) — من Amazon Web Services. - "Google GKE" (https://cloud.google.com/kubernetes-engine) — من Google Cloud. - "Azure AKS" (https://azure.microsoft.com/products/kubernetes-service) — من Microsoft Azure.
مثال عملي: إذا كان التطبيق يحتاج إلى تشغيل ثلاث نسخ منه، يمكن لـ Kubernetes الحفاظ على العدد المطلوب، ومحاولة إنشاء نسخة بديلة إذا تعطلت إحداها.
من المهم فهم أن Kubernetes ليست حاوية بحد ذاتها، بل منصة تدير أحمال العمل التي تعمل داخل الحاويات باستخدام بيئات تشغيل متوافقة.
3. الحاويات (Containers): تجهيز التطبيقات وتشغيلها
الحاوية هي بيئة تشغيل معزولة نسبيًا تحتوي على التطبيق ومكتباته واعتمادياته اللازمة للعمل. وتشارك الحاويات نواة نظام التشغيل الخاص بالجهاز المضيف، مع توفير مستوى من العزل بين العمليات.
تساعد الحاويات في تقليل المشكلة الشائعة التي تجعل التطبيق يعمل على جهاز المطور، لكنه يتصرف بصورة مختلفة في بيئة الاختبار أو الإنتاج.
أهم التقنيات:
- Docker: مجموعة أدوات شائعة لبناء صور الحاويات وتجهيزها وتشغيلها. - containerd: بيئة تشغيل مسؤولة عن إدارة دورة حياة الحاويات، بما يشمل التعامل مع الصور وتشغيل الحاويات وإيقافها.
تمر دورة العمل المعتادة ببناء صورة الحاوية، وتخزينها في سجل الحاويات، ثم تشغيل نسخة منها على الجهاز المضيف.
مثال: يمكن تجهيز واجهة برمجية مبنية باستخدام Node.js داخل صورة حاوية تحتوي على اعتمادياتها. بعد ذلك، يمكن تشغيل الصورة نفسها في بيئة التطوير والاختبار والإنتاج.
الفرق بين صورة الحاوية والحاوية نفسها
- Container Image: القالب الذي يحتوي على التطبيق واعتمادياته. - Container: نسخة قيد التشغيل من صورة الحاوية. - Container Runtime: البيئة التي تتولى تشغيل الحاويات وإدارة دورة حياتها.
Docker وcontainerd تقنيتان مترابطتان، لكن لكل منهما دور مختلف داخل منظومة الحاويات.
4. خادم الويب والوكيل العكسي (Web Server & Reverse Proxy)
يستقبل خادم الويب طلبات HTTP أو HTTPS ويرسل الاستجابات المناسبة. ويمكن إعداده أيضًا ليعمل كوكيل عكسي (Reverse Proxy)، بحيث يستقبل الطلبات ويوجهها إلى خدمات التطبيق الداخلية.
أشهر التقنيات:
- Apache HTTP Server: خادم ويب واسع الاستخدام، يتميز بمرونته ودعمه لمجموعة كبيرة من الإضافات. - NGINX: يُستخدم لتقديم الملفات الثابتة، وتوجيه الطلبات، وتوزيع الأحمال، والتعامل مع أعداد كبيرة من الاتصالات. - Envoy: وكيل شبكي يدعم الاتصال بين الخدمات، والمراقبة، وإدارة حركة المرور المتقدمة. - Traefik: وكيل عكسي وموجّه لحركة المرور يتكامل مع منصات مثل Docker وKubernetes.
أهم المسؤوليات:
- إدارة اتصالات HTTPS وإنهاء التشفير عند النقطة المحددة في التصميم. - توجيه الطلبات إلى التطبيق المناسب. - توزيع حركة المرور بين عدة نسخ من التطبيق. - تقديم الملفات الثابتة مثل الصور وملفات CSS وJavaScript. - تطبيق قواعد التوجيه، والمهل الزمنية، وضوابط حركة المرور.
مثال عملي: عندما يرسل المستخدم طلبًا إلى "api.example.com"، يمكن أن يستقبله وكيل عكسي ثم يوجهه إلى واجهة API المناسبة التي تعمل داخل إحدى الحاويات.
تتداخل وظائف هذه الأدوات في بعض الجوانب، لكنها ليست متطابقة. ويعتمد الاختيار على تصميم النظام، وحجم حركة المرور، ومتطلبات التشغيل.
5. الخادم المضيف (Host): توفير موارد الحوسبة
الخادم المضيف هو البيئة التي توفر موارد الحوسبة اللازمة لتشغيل التطبيقات وبرامج البنية التحتية. وقد يكون خادمًا فعليًا أو جهازًا افتراضيًا (Virtual Machine).
تشمل الموارد الأساسية:
- CPU: لتنفيذ العمليات والحسابات. - Memory (RAM): لتشغيل التطبيقات والاحتفاظ بالبيانات المؤقتة أثناء التنفيذ. - Network Interfaces: للاتصال بالشبكات والخدمات الأخرى. - Disk Storage: لتخزين ملفات نظام التشغيل وبيانات التطبيقات والملفات المؤقتة.
أشهر مزودي البنية التحتية السحابية:
- "Amazon EC2" (https://aws.amazon.com/ec2/) — لتشغيل الأجهزة الافتراضية على AWS. - "Google Compute Engine" (https://cloud.google.com/compute) — لتشغيل الأجهزة الافتراضية على Google Cloud. - "DigitalOcean" (https://www.digitalocean.com/) — لتوفير موارد الحوسبة السحابية، بما فيها الأجهزة الافتراضية المعروفة باسم Droplets.
في بيئة Kubernetes، توفر العُقد العاملة (Worker Nodes) موارد الحوسبة التي تُشغّل وحدات التطبيق المعروفة باسم Pods. وقد تكون هذه العقد أجهزة افتراضية يديرها مزود الخدمة السحابية.
مثال: يمكن لشركة تشغيل حاويات تطبيقها على أجهزة Amazon EC2 افتراضية، ضمن مجموعة Kubernetes تتم إدارتها بواسطة Amazon EKS.
الفرق الأساسي: الخادم المضيف يوفر موارد الحوسبة، بينما تتولى Kubernetes تنسيق تشغيل أحمال العمل عبر مجموعة من العقد.
6. نظام أسماء النطاقات (DNS): ربط أسماء النطاقات بالخدمات
يعمل نظام أسماء النطاقات (Domain Name System) على تحويل أسماء النطاقات إلى سجلات تساعد الأجهزة على تحديد وجهة الاتصال بالخدمة المطلوبة.
بدلًا من مطالبة المستخدم بحفظ عنوان IP، يتيح DNS الوصول إلى التطبيق باستخدام اسم واضح مثل "example.com".
من أشهر مزودي خدمات DNS وتسجيل النطاقات:
- "GoDaddy" (https://www.godaddy.com/) - "Namecheap" (https://www.namecheap.com/) - "Cloudflare" (https://www.cloudflare.com/)
تشمل الخدمات المرتبطة بـ DNS:
- تسجيل أسماء النطاقات. - إدارة سجلات DNS. - توجيه أسماء النطاقات إلى عناوين IP أو أسماء مضيفين أخرى. - توجيه حركة المرور وفقًا للسياسات أو حالة الخدمات، بحسب إمكانات المزود.
أشهر أنواع سجلات DNS
- A: يربط اسم المضيف بعنوان IPv4. - AAAA: يربط اسم المضيف بعنوان IPv6. - CNAME: يربط اسم مضيف باسم مضيف آخر. - MX: يحدد خوادم البريد الإلكتروني الخاصة بالنطاق. - TXT: يخزن معلومات نصية تُستخدم في التحقق من الملكية وأغراض أخرى.
مثال عملي: عندما يفتح المستخدم "app.example.com"، يساعد DNS المتصفح في تحديد وجهة الاتصال بالشبكة. بعد ذلك، يتصل المتصفح بالوجهة باستخدام HTTP أو HTTPS.
من المهم التمييز بين DNS والاستضافة: DNS لا يشغّل التطبيق ولا يستضيفه، بل يساعد المستخدمين والأجهزة في الوصول إلى وجهته.
7. خط أنابيب CI/CD: أتمتة تسليم البرمجيات
يشير CI/CD إلى التكامل المستمر والتسليم المستمر أو النشر المستمر (Continuous Integration / Continuous Delivery or Deployment).
تهدف هذه الممارسات إلى أتمتة خطوات التحقق من الكود، وبناء التطبيق، واختباره، وتجهيزه للإصدار، ونشره عند الحاجة.
بدون CI/CD، قد تعتمد الفرق على خطوات يدوية تستغرق وقتًا أطول، ويصعب تكرارها بدقة، وتكون أكثر عرضة للأخطاء البشرية.
أشهر الأدوات:
- "GitHub Actions" (https://github.com/features/actions) - "GitLab CI/CD" (https://docs.gitlab.com/ci/) - "Jenkins" (https://www.jenkins.io/)
مراحل خط أنابيب CI/CD
1. تعديل الكود: يرفع المطور التغييرات إلى مستودع الكود المصدري. 2. التحقق: تعمل الفحوصات الآلية واختبارات الكود. 3. البناء (Build): يتم تجميع التطبيق أو تجهيزه للتشغيل. 4. إنشاء صورة الحاوية: تُبنى صورة الحاوية إذا كان التطبيق يعتمد على الحاويات. 5. النشر في السجل: تُرفع الصورة إلى سجل الحاويات. 6. النشر (Deployment): يتم إصدار النسخة الجديدة في البيئة المستهدفة. 7. التحقق بعد النشر: تُنفذ فحوصات الصحة والاختبارات الآلية للتأكد من عمل التطبيق.
مثال عملي: يمكن إعداد سير عمل باستخدام GitHub Actions للتحقق من الكود، وبناء صورة Docker، ورفعها إلى AWS ECR، ثم بدء عملية نشر على Amazon EKS.
لا يعني وجود CI/CD أن كل تغيير يجب أن يصل مباشرة إلى بيئة الإنتاج. يمكن إضافة موافقات يدوية، وبيئات اختبار، ونشر تدريجي، وخطط للرجوع إلى إصدار سابق لتقليل المخاطر.
8. المراقبة والسجلات والنسخ الاحتياطي والتخزين
تضم هذه المجموعة عدة مسؤوليات مختلفة. تساعد المراقبة والسجلات في فهم حالة النظام واكتشاف المشكلات، بينما يحافظ التخزين والنسخ الاحتياطي على البيانات ويساعدان في استعادتها عند الحاجة.
8.1 المراقبة وقابلية الملاحظة (Monitoring & Observability)
تتابع المراقبة مؤشرات الأداء وصحة النظام. أما قابلية الملاحظة، فتجمع بين المقاييس والسجلات وآثار الطلبات (Traces) والمعلومات السياقية، لتسهيل فهم السلوك غير المتوقع والتحقيق في أسبابه.
أشهر الأدوات:
- Prometheus: لجمع المقاييس الزمنية وتخزينها. - Grafana: لعرض البيانات في لوحات متابعة، ودعم التنبيهات. - ELK Stack: تتكون من Elasticsearch وLogstash وKibana، وتُستخدم لجمع السجلات ومعالجتها والبحث فيها وعرضها. - Datadog: منصة للمراقبة وقابلية الملاحظة تغطي البنية التحتية والتطبيقات والسجلات وغيرها من بيانات التشغيل.
أهم المؤشرات التي يمكن مراقبتها:
- استهلاك المعالج والذاكرة. - زمن الاستجابة ومعدلات الأخطاء. - مدى توفر التطبيق. - أداء قواعد البيانات. - حالات فشل النشر وإعادة تشغيل الحاويات.
مثال عملي: إذا ارتفع زمن استجابة API بعد نشر إصدار جديد، يمكن للفريق استخدام لوحات المتابعة والسجلات للتحقيق في ما إذا كانت المشكلة ناتجة عن التطبيق أو قاعدة البيانات أو البنية التحتية.
المراقبة وحدها لا تصلح كل الأعطال تلقائيًا؛ إذ تحتاج الفرق أيضًا إلى تحديد عتبات التنبيه المناسبة، وتوزيع المسؤوليات، ووضع إجراءات واضحة للتعامل مع الحوادث.
8.2 إدارة التخزين والنسخ الاحتياطي (Storage & Backup)
تُستخدم خدمات التخزين للاحتفاظ ببيانات التطبيق والملفات والنسخ الاحتياطية وغيرها من المعلومات الدائمة. أما أدوات النسخ الاحتياطي، فتساعد على استعادة البيانات وحالة النظام بعد الحذف غير المقصود أو الأعطال أو الحوادث الأخرى.
من التقنيات ذات الصلة:
- "Amazon S3" (https://aws.amazon.com/s3/) — خدمة تخزين كائني للملفات والنسخ الاحتياطية والسجلات وبيانات أخرى. - "Velero" (https://velero.io/) — أداة لنسخ موارد Kubernetes احتياطيًا واستعادتها، مع إمكانية التعامل مع بيانات وحدات التخزين الدائمة المدعومة عند إعدادها بصورة مناسبة.
التخزين ليس هو النسخ الاحتياطي. وجود البيانات داخل خدمة تخزين لا يعني بالضرورة وجود خطة نسخ احتياطي كاملة وقابلة للاستعادة.
ينبغي أن تحدد خطة النسخ الاحتياطي الجيدة:
- البيانات والموارد المطلوب حمايتها. - معدل إنشاء النسخ الاحتياطية. - مدة الاحتفاظ بالنسخ. - مكان تخزين النسخ، ومدى استقلالها عن البيئة الأساسية. - الأشخاص والأنظمة المسموح لها بالوصول إلى النسخ أو حذفها. - دورية اختبار الاستعادة والتأكد من نجاحها.
في بيئات Kubernetes، يمكن استخدام Velero لحماية موارد المجموعة وبيانات التخزين الدائم المدعومة، بينما يمكن استخدام Amazon S3 وجهةً للنسخ الاحتياطية بحسب إعدادات النظام.
مثال عملي: ينشئ الفريق نسخًا احتياطية من موارد Kubernetes وبيانات التخزين الدائم إلى وجهة مناسبة، ثم يجري اختبارات استعادة دورية للتأكد من إمكانية إعادة تشغيل التطبيق بعد وقوع عطل.
كيف تعمل هذه المكونات معًا؟
لنفترض أننا نبني منصة SaaS باستخدام خدمات AWS وKubernetes.
تمر دورة العمل النموذجية بالمراحل التالية:
1. GitHub: يخزن المطورون الكود المصدري للتطبيق. 2. CI/CD: يتحقق من الكود ويشغّل الاختبارات ويبني صورة الحاوية. 3. Amazon ECR: يستقبل صورة الحاوية ويحفظ إصدارها. 4. Amazon EKS: يدير تشغيل أحمال العمل داخل الحاويات على عقد الحوسبة. 5. Web Server / Reverse Proxy: يستقبل الطلبات ويوجهها إلى الخدمات المناسبة. 6. DNS: يساعد المستخدمين على الوصول إلى نقطة الاتصال العامة للتطبيق. 7. Prometheus وGrafana وأدوات السجلات: تتابع أداء النظام وتساعد على اكتشاف الأخطاء والتحقيق فيها. 8. Amazon S3 وVelero: يساهمان في تخزين البيانات المناسبة وإنشاء نسخ احتياطية من موارد النظام والبيانات المدعومة.
تختلف البنية الفعلية من تطبيق إلى آخر. فبعض التطبيقات لا تحتاج إلى Kubernetes أصلًا، ويمكن تشغيلها على منصات تطبيقات مُدارة، أو باستخدام الحوسبة دون خوادم (Serverless)، أو من خلال أجهزة افتراضية أبسط.
الهدف ليس استخدام أكبر عدد من الأدوات، بل اختيار المكونات التي تلبي احتياجات التطبيق بأقل تعقيد ممكن.
الخاتمة
البنية التحتية ليست مجرد مجموعة أدوات منفصلة، بل منظومة مترابطة يؤدي كل مكون فيها دورًا محددًا في تشغيل البرمجيات وإدارتها.
إن فهم الفرق بين مستودعات الكود وسجلات صور الحاويات، وبين الحاويات ومنصات التنسيق، وبين الخوادم المضيفة ومجموعات Kubernetes، وبين DNS وخوادم الويب، وبين التخزين والنسخ الاحتياطي، يساعد على اتخاذ قرارات تقنية أفضل وبناء أنظمة أكثر موثوقية.
القاعدة الأهم: أفضل بنية تحتية ليست الأكثر تعقيدًا، بل أبسط بنية تحقق متطلبات التطبيق من حيث الاعتمادية، والأمان، وقابلية التوسع، وسهولة الصيانة، والتكلفة.
سواء كنت مطورًا، أو مهندس DevOps، أو مدير منتج، فإن فهم هذه المكونات يمنحك رؤية أوضح لكيفية انتقال المنتج من مجرد كود برمجي إلى خدمة رقمية تعمل ويعتمد عليها المستخدمون.
