من أول commit
لحد خدمة شغّالة.

١. قصة المشروع في دقيقة

ده معمل DevOps على ثلاث آلات افتراضية تشغّل Kubernetes. فيه تطبيقان صغيران، واحد بـGo وواحد بـNode.js. المطور يغيّر الكود ويرفعه إلى GitHub. GitHub Actions يفحص ويبني صورة حاوية، يختبرها، وينشرها في registry. بعد كده يسجل tag الصورة الجديدة في إعدادات Helm داخل Git. Argo CD يلاحظ التغيير ويطلب من Kubernetes تشغيل النسخة المطلوبة.

Traefik يستقبل طلبات HTTPS ويوصلها للتطبيق. MetalLB يعطي خدمة الدخول عنوانًا ثابتًا. Cilium يدير شبكة الـPods والسياسات. Longhorn يوفر أقراصًا دائمة. Prometheus يجمع المقاييس وGrafana تعرضها.

جولة في ملفات المشروع: أفتح إيه وليه؟

ابدأ من الملفات اللي ترسم الصورة العامة، ثم انزل للتفاصيل. أسماء المجلدات هنا مرتبطة بمسؤولية واضحة:

٢. شكل المنصة ومين مسؤول عن إيه

السهم هنا يوضح الاعتماد: Actions تنشر الصورة وتحدّث tag في Git. Argo CD يقرأ الحالة من Git ويصالحها مع الكلاستر. المستخدم يصل عبر عنوان الخدمة في MetalLB، ثم Traefik يختار الوجهة حسب اسم النطاق.

GitHub Actions: كل Workflow له وظيفة

١. automate-build-apps.yml

يعمل عند تغيير ملفات التطبيق على main أو تشغيل يدوي. يبني التطبيقين، يشغلهما محليًا داخل Runner، يختبر /healthz و/metrics، ويفحص الصورة بـTrivy. بعد نجاح ذلك ينشر الصور بوسم commit ويضيف إثبات provenance. آخر Job يحدّث image tags في Helm values؛ Actions لا تنفذ kubectl على الكلاستر.

٢. platform-validation.yml

يعمل على تغييرات ملفات المنصة في Pull Request أو push. يفحص تنسيق وصحة Terraform، Helm lint، YAML وبنية الشبكة، Bash syntax، manifests بعد render مع Kubernetes schemas، ثم الأسرار وتهيئة IaC عبر Gitleaks وTrivy. النجاح هنا يعني أن الملفات اجتازت هذه الفحوصات، وليس أنها جُربت على كل سيناريو فشل حي.

٣. post-deployment-check.yml

يعمل بعد نجاح بناء وترقية التطبيقات أو يدويًا. يشغل scripts/check-deployment.sh ليتأكد من health وmetrics والروابط العامة، ويفحص Prometheus targets عندما يكون السر المطلوب مضبوطًا.

غيّرت كود التطبيق؟      automate-build-apps
غيّرت إعداد المنصة؟     platform-validation
نجح نشر التطبيق؟        post-deployment-check

Helm وArgo CD: من القالب إلى الحالة الحية

Argo CD app الخاصة بـGo تستخدم نفس المسار charts/ مع القيم العامة وvalues-go.yaml. تطبيق Node يستخدم القيم العامة وvalues-node.yaml. Helm يدمج القيم بالترتيب ثم يملأ القوالب.

القوالب تصف الموارد التي يحتاجها التطبيق: ServiceAccount وConfigMap وDeployment وService وHPA وPDB وIngress وCertificate وServiceMonitor وPrometheusRule. هذا يقلل اختلاف النسختين ويحافظ على نقاط ضبط مشتركة.

Argo CD يعرض الفرق بين Git والحالة الفعلية. Synced تعني أن الحالة مطابقة للمصدر في Git، وHealthy تعني أن فحوص الموارد تقول إنها سليمة. قد تكون App Synced لكن غير Healthy إذا فشل Pod readiness.

٣. رحلة تغيير حقيقي من commit إلى Pod

1. تعدّل ملفًا مثل nodejs/server.js وتعمل commit.
2. GitHub Actions يشغّل workflow بناء التطبيق: compile/build ثم smoke test ثم فحص الصورة.
3. تنشر الصورة بوسم مرتبط بالـcommit، فيسهل معرفة مصدر النسخة.
4. الـworkflow يحدّث ملف قيم Helm بالوسم الجديد ويرفع commit الترقية إلى Git.
5. Argo CD يلاحظ commit القيم ويعيد render للـchart.
6. Kubernetes ينشئ Pods من الصورة الجديدة، ويتابع readiness. أثناء التحديث يراقب عدد النسخ الجاهزة.
7. فحص ما بعد النشر يتأكد من health والـmetrics والـroutes العامة.

git commit → GitHub Actions → image: sha-<commit>
            → charts/values-node.yaml → Argo CD → Deployment → Pods

٤. Kubernetes من غير تعقيد

تخيّل إنك بتقول للنظام: «عايز 3 نسخ من التطبيق، بالصورة دي، وكل نسخة لازم تعدّي فحص الجاهزية». الـDeployment يسجل الوصف. الـScheduler يختار عُقدًا، والـkubelet على كل عقدة يطلب من container runtime تشغيل الـPod. لو نسخة وقعت، Kubernetes يحاول يرجّع العدد المطلوب.

جوا الكلاستر: مين بياخد القرار ومين يشغّل الحاوية؟

كل عقدة في المعمل بتشغّل control plane وworkloads. مكونات Kubernetes بتتواصل عبر الـAPI server، ومش كل مكون يشغّل التطبيق بنفسه:

لو عقدة توقفت، الـcontrol plane يلاحظ غيابها، ثم يحاول الـDeployment تشغيل Pods بديلة على العقد المتاحة. ده لا يعني إن كل عطل يتحل فورًا: افحص سعة العقد، volume health، readiness، وسياسات التوزيع.

kubectl get nodes -o wide
kubectl get pods -A -o wide
kubectl get --raw=/readyz

الشبكة من داخل الكلاستر: Cilium وNetworkPolicy

Cilium هو CNI: يخصص عناوين للـPods ويوصل حركتها، ويطبّق سياسات شبكة. إعداد المعمل يستخدم Cluster Pool لعناوين الـPods وVXLAN لنقل الحركة بين العقد. Cilium هنا لا يستبدل kube-proxy؛ إعداد kube-proxy replacement معطّل.

سياسة application-traffic تختار تطبيقَي Go وNode في namespace default. تسمح بالدخول من namespaces محددة على منافذ التطبيقات، وتسمح بالخروج إلى DNS وإلى التطبيقين على المنافذ المطلوبة. السياسة محددة النطاق؛ لا تعتبر جدارًا ناريًا لكل موارد الكلاستر.

kubectl get networkpolicy -A
kubectl -n kube-system get pods -l k8s-app=cilium
kubectl -n default get pods --show-labels

وقت التحقيق، قارن labels التي تختار الـPods، ومصدر الاتصال، والمنفذ، وراجع Hubble عند الحاجة. لو الخدمة لا تصل للتطبيق، افحص endpoints أولًا؛ بعدها policy وCilium flow.

٥. الشبكة والدخول للتطبيق

عنوان MetalLB 66.11.126.179 عنوان خدمة دخول مشترك؛ ليس عنوان Node. Traefik يستقبل على هذا العنوان ويوجه حسب hostname مثل go.murabba.net. الشهادة يطلبها cert-manager من Let's Encrypt، ثم Traefik ينهي اتصال TLS ويوصل HTTP للخدمة الداخلية.

Cilium يوفر شبكة الـPods وسياسات الشبكة. VXLAN ينقل حركة الـPods بين العُقد. NetworkPolicy تسمح أو تمنع الاتصال وفق المصدر والوجهة والمنفذ.

٦. التخزين: PVC وLonghorn والنسخ الاحتياطي

الـcontainer ممكن يتبدل؛ الملفات داخله ليست مكانًا دائمًا لبيانات التطبيق. التطبيق يطلب مساحة عبر PVC. StorageClass يحدد طريقة إنشاء المساحة، وLonghorn يربطها بقرص دائم موزع على عُقد الكلاستر.

اختبار الاستعادة يعني استرجاع نسخة إلى volume منفصل، ثم فحص محتواها. وجود backup job وحده لا يثبت إن الاستعادة سليمة. نسخة etcd تحمي حالة Kubernetes، أما Longhorn فيحمي بيانات PVC؛ كل واحد يغطي شيئًا مختلفًا.

kubectl get pvc -A
kubectl -n longhorn-system get volumes.longhorn.io
kubectl -n longhorn-system get recurringjobs.longhorn.io

من /metrics إلى التنبيه: خط المراقبة كاملًا

التطبيق لا يرسل كل مقياس إلى Prometheus بنفسه. Prometheus يكتشف الهدف من ServiceMonitor، ويتصل بعنوان الخدمة ويقرأ metrics دوريًا. قواعد Prometheus تراقب المقاييس، وAlertmanager يرسل التنبيه إذا تحققت شروط القاعدة.

لو ظهر TargetDown اسأل بالترتيب: هل الـPods Ready؟ هل الخدمة لها endpoints؟ هل الـServiceMonitor يطابق labels المطلوبة؟ هل المنفذ والمسار صحيحان؟ وهل NetworkPolicy تسمح بالاتصال؟

kubectl -n default get servicemonitor
kubectl -n default get svc,endpointslices
kubectl -n monitoring get pods

HTTP 200 على التطبيق لا يثبت أن Prometheus يسحبه. افحص Targets نفسها، واستخدم Basic Auth عند التحقق من endpoint المحمي.

٧. المراقبة والتنبيه

التطبيقان يعرضان health وmetrics. Prometheus يقرأ metrics عبر ServiceMonitor، ويقيّم قواعد التنبيه. Alertmanager يرسل التنبيه إلى الوجهة المضبوطة. Grafana تعرض الرسوم والـdashboards.

لو ظهر TargetDown، فالمعنى إن Prometheus لم ينجح في scrape هدف خلال المدة المحددة. افحص حالة الـPod ثم Service وServiceMonitor والـEndpoint والمنفذ والسياسات. التنبيه دليل يحتاج تحقيق، وليس تشخيصًا نهائيًا.

٨. التشغيل اليومي والتصحيح

ابدأ من الحالة العامة، ثم ضيّق نطاق المشكلة. لا تغيّر عدة طبقات مرة واحدة.

kubectl get nodes
kubectl get pods -A -o wide
kubectl -n argocd get applications
kubectl get events -A --sort-by=.lastTimestamp
kubectl -n default describe pod <pod-name>
kubectl -n default logs deploy/<deployment-name>

لو الـPod في Pending افحص الموارد والـPVC والقيود. لو CrashLoopBackOff افحص logs وسبب الخروج. لو كل شيء Ready والرابط لا يفتح، راجع DNS وTraefik وTLS والـService endpoints.

السكربتات: متى أستخدم كل واحد؟

bash scripts/validate-platform.sh
bash -n scripts/*.sh
bash scripts/render-platform.sh
helm lint charts -f charts/values-node.yaml

كل سكربت له مدخلات وافتراضات. اقرأه قبل التنفيذ، خصوصًا سكربتات تجهيز الأقراص أو تغيير اتصال kubelet.

الأمان في التطبيق والـCI

إعدادات Helm تضبط الحاويات بحيث تعمل كمستخدم غير root، تمنع تصعيد الصلاحيات، تجعل root filesystem للقراءة فقط، وتسقط Linux capabilities غير اللازمة. كما تحدد requests وlimits حتى لا يستهلك التطبيق موارد بلا حدود.

في GitHub Actions، Trivy يفحص صور التطبيق بحثًا عن ثغرات عالية وخطيرة، ويفحص إعدادات IaC. Gitleaks يبحث عن أسرار مكشوفة في Git. إثبات provenance يربط صورة الـRegistry بعملية البناء ومصدرها.

Sealed Secrets يسمح بحفظ نسخة مشفرة من بيانات Secret في Git. pub-cert.pem شهادة عامة للتشفير؛ المفتاح الخاص داخل الكلاستر هو الذي يفك التشفير. لو اتسربت كلمة مرور، دوّرها أولًا في النظام الذي يستخدمها، وحدّث النسخة المشفرة وسر GitHub Actions إن كان يستخدمها، ثم افحص الوصول. حذف القيمة من commit لا يلغي تسريبها.

kubeseal --cert pub-cert.pem --format yaml
kubectl get sealedsecrets -A
kubectl get secrets -A

٩. الأسرار والوصول

القيم الحساسة لا توضع كنص واضح في Git. Sealed Secrets يحول Kubernetes Secret إلى ملف مشفّر يمكن حفظه في المستودع؛ المتحكم داخل الكلاستر يفكّه بالمفتاح الخاص الذي لا يخرج منه. الشهادة العامة pub-cert.pem تستخدم للتشفير، وليست المفتاح الخاص.

أقل صلاحية لازمة، تدوير كلمات المرور، فحص صور الحاويات، وصحة صلاحيات GitHub Actions كلها أجزاء من الحماية. Basic Auth الخاص بـPrometheus يضيف حاجز دخول، لكنه لا يعوض إدارة الشبكة أو تحديث المكونات.

١٠. قاموس سريع

أسئلة مقابلة ومراجعة

جاوب بصوتك قبل ما تفتح الإجابة. اشرح السبب، ثم قل أين ستتحقق من الكلام في الملفات أو الكلاستر.

أسئلة أعمق للمراجعة

١٢. نص فيديو افتتاحي (دقيقتان)

«في المشروع ده هوريكم إزاي تغيير صغير في كود تطبيق بيوصل لحد ما يبقى شغال على Kubernetes. عندنا تطبيق Go وتطبيق Node.js على كلاستر من ثلاث عُقد. أول ما أرفع التغيير، GitHub Actions يبني صورة ويفحصها. بعد نجاح البناء يتسجل tag الصورة في إعدادات Helm داخل Git. Argo CD يتابع Git ويطبّق الحالة على الكلاستر. Kubernetes يحدّث النسخ، وTraefik يستقبل الزيارات الخارجية. Prometheus يراقب المقاييس، وLonghorn يحافظ على بيانات الـPVC ويبعث نسخًا احتياطية إلى مساحة خارجية. في الدروس هنمشي مع كل جزء، وهنشوف أوامر الفحص وإزاي نعرف مكان المشكلة بدل ما نخمن.»

للفيديو التالي: سجّل شاشة workflow ناجحًا، ثم أظهر commit تحديث الصورة وحالة Argo CD، وبعدها افتح التطبيق ومسار health. اخفِ أي tokens أو كلمات مرور أو مفاتيح قبل التسجيل.

خطة مذاكرة عملية على ٧ جلسات

1. الصورة العامة: اشرح قصة المشروع وارسم مسار الطلب ومسار النشر من الذاكرة.
2. التطبيق: افتح Go وNode، قارن endpoints وDockerfiles، وحدد ما الذي يختبره smoke test.
3. البناء: اقرأ build workflow، وحدد أين تُبنى الصورة ومتى تُنشر ومتى يفشل النشر.
4. Helm وGitOps: غيّر قيمة في ذهنك، توقع الـmanifest الناتج، ثم اشرح دور Argo CD.
5. الشبكة: اتبع طلب HTTPS من DNS حتى Pod، وارسم أين ينتهي TLS.
6. التخزين والمراقبة: اشرح فرق PVC والنسخة والـbackup، وتتبع Alert واحد من Prometheus.
7. التشغيل: تدرب على قراءة حالة Pod وEvents وArgo Application، ثم اشرح خطة تصحيح مرتبة.

تمرين صغير لكل تغيير

قبل ما تغيّر أي ملف، قل: من يملكه؟ ما النتيجة المتوقعة؟ ما الاختبار الذي يثبتها؟ وكيف أرجع لو فشلت؟ بعد التنفيذ قارن التوقع بالنتيجة.

أفكار حلقات فيديو للتدريب

1. جولة المنصة: العقد، الشبكة، GitOps، التطبيقات، التخزين، المراقبة.
2. من commit إلى deployment: أظهر workflow ناجحًا ثم image tag وArgo sync.
3. DNS وHTTPS: تتبع hostname إلى Traefik ثم Service وPod، واشرح شهادة cert-manager.
4. Persistent storage: PVC وLonghorn replicas والنسخ الخارجية ثم معنى restore test.
5. تنبيه TargetDown: ابدأ بالهدف، افحص endpoints والسياسات، ووضح السبب والنتيجة.
6. كيف نجهز VM جديدة؟ اقرأ السكربتات واشرح ما الذي تفعله وما الذي يتطلب خطوة منفصلة.

في تسجيل الشاشة أخفِ الأسرار والـtokens وملفات kubeconfig. اعرض اسم المورد وحالته، وليس قيمة السر.

لو حصل عطل: ترتيب الاستجابة

1. حدد النطاق: تطبيق واحد، monitoring، شبكة، تخزين، أم الكلاستر كله؟
2. راجع آخر تغيير في Git وحالة Argo CD: هل التطبيق Synced وHealthy؟
3. افحص العقد والـPods والـevents قبل تعديل أي شيء.
4. للتطبيق افحص `describe` و`logs --previous` وimage tag وprobes والموارد وConfigMaps/Secrets.
5. لرابط عام افحص DNS ثم Ingress/TLS ثم Service/Endpoints ثم Pod.
6. إذا بدأ العطل بعد تغيير واضح، أصلح المصدر في Git أو اعمل revert للـcommit، ثم راقب Argo CD والـrollout.
7. بعد استعادة الخدمة، سجّل السبب والتغيير ومدة الأثر والفحص الذي اكتشف المشكلة.

kubectl get applications -n argocd
kubectl get nodes
kubectl get pods -A -o wide
kubectl get events -A --sort-by=.lastTimestamp
kubectl rollout status deployment/nodejs -n default

لو المشكلة في شهادة: افحص Certificate وCertificateRequest وOrder وChallenge وأحداث cert-manager، ثم DNS والـHTTP-01 route. لو مشكلة node pressure: راجع Conditions والموارد والـPods المنتظرة والـPVC.

معمل تفاعلي: رابط التطبيق بيرجع 502

الحالة: node.murabba.net فتح صفحة من Traefik تقول إن الخدمة غير متاحة. تطبيق Node موجود، لكن المستخدم مش واصل له.

اختار أول مسار فحص منطقي:

kubectl get ingress -A
kubectl -n default get svc nodejs
kubectl -n default get endpointslice -l kubernetes.io/service-name=nodejs
kubectl -n default get pods -l app.kubernetes.io/instance=nodejs -o wide

لو الـIngress موجود والـService موجود لكن لا توجد endpoints، فالمشكلة غالبًا في selector أو أن الـPods غير جاهزة. لو توجد endpoints، افحص logs والـport الذي يسمع عليه التطبيق.

معمل تفاعلي: Pod في CrashLoopBackOff

الحالة: الـDeployment يطلب 3 نسخ، وواحدة تدخل في حلقة إعادة تشغيل. ما أول دليل تجمعه؟

kubectl -n default get pods -o wide
kubectl -n default describe pod <pod-name>
kubectl -n default logs <pod-name> --previous
kubectl -n default get events --sort-by=.lastTimestamp

استعادة البيانات: خطوات آمنة وواضحة

1. حدد ما الذي تريد استعادته: ملفات PVC أم حالة Kubernetes أم الاثنين.
2. لملفات التطبيق، حدد volume والنسخة المناسبة من Longhorn وتحقق أن النسخة ظهرت من هدف SMB/CIFS.
3. استعدها إلى volume منفصل للاختبار، ثم افحص الملفات والصلاحيات وشغّل التطبيق عليها عند الحاجة.
4. بعد التأكد، قرر كيف تربط النسخة المستعادة بالتطبيق. احتفظ بالـvolume الأصلي حتى تنتهي المقارنة.
5. لاسترجاع حالة control plane استخدم نسخة etcd التي تطابق إصدار Kubernetes وإجراء الاستعادة المناسب.

الـStorageClass الافتراضية تحفظ ثلاث replicas مع hard node anti-affinity وRetain. النسخ اليومية الخارجية تحتفظ بآخر سبع نسخ لكل volume. اتصال SMB 3.1.1 مشفر أثناء النقل، لكن تشفير التخزين على خادم النسخ الاحتياطي غير مثبت؛ لذلك لا تفترض أن البيانات مشفرة وهي ساكنة.

kubectl get pvc -A
kubectl -n longhorn-system get recurringjobs.longhorn.io
kubectl -n longhorn-system get volumes.longhorn.io

معمل تفاعلي: هل عندي نسخة احتياطية أقدر أرجعها؟

الحالة: volume عليه ثلاث replicas، وعقدة Kubernetes تعطلت. هل ده يثبت إن عندك backup خارجي صالح؟

kubectl -n longhorn-system get recurringjobs.longhorn.io
kubectl -n longhorn-system get backups.longhorn.io
kubectl get pvc -A

قبل استعادة بيانات تطبيق: حدد الـPVC الصحيح، راجع حجم النسخة وتاريخها، استعد إلى volume منفصل، افحص الملفات، وبعدها قرر كيف تربطه بالتطبيق. لا تخلط ملفات التطبيق مع etcd snapshot؛ كل نسخة تغطي طبقة مختلفة.

مين يملك المورد؟ Terraform أم Argo CD؟

قاعدة التشغيل هنا: لكل مورد مصدر ملكية واحد واضح. Terraform يدير مجموعة مختارة من إصدارات المنصة، بينما Argo CD يدير التطبيقات والموارد الموجودة تحت تطبيقاته.

لو غيرت حقلًا يدويًا في مورد يملكه Argo CD، غالبًا سترى فرقًا وقد يرجع Argo CD القيمة. لو عدّلت إصدار Helm يملكه Terraform، راجع Terraform state والخطة. اسأل «مين المالك؟» قبل «أي أمر أشغّل؟».

قائمة تدريب تحفظ تقدمك على جهازك

علّم الخطوات التي نفذتها بنفسك. التقدم يُحفظ في المتصفح على نفس الجهاز.

تمرين: Pod عالق في Pending

الموقف: نسخة جديدة لا تبدأ، وحالتها Pending. اختر أول دليل:

kubectl -n default describe pod <pod-name>
kubectl describe nodes
kubectl get pvc -A

تمرين: شهادة HTTPS لم تصبح Ready

الموقف: Ingress موجود، لكن المتصفح يحذر من الشهادة أو Certificate ما زالت غير جاهزة.

kubectl get certificate,certificaterequest,order,challenge -A
kubectl describe certificate <name> -n <namespace>
kubectl -n cert-manager get events --sort-by=.lastTimestamp

تمرين: TargetDown في Prometheus

الموقف: تنبيه يقول إن هدف Longhorn أو التطبيق Down. اختر فحصًا يحدد أين انقطع مسار الـscrape:

تمرين: التطبيق Unhealthy بعد ترقية صورة

الموقف: Actions نجحت، لكن Argo CD يعرض التطبيق Unhealthy بعد الترقية. ما الخطوة المناسبة؟

اختبار ختامي: هل تقدر تشرح المنصة؟

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

تدريب الشرح بصوتك

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

1. ارسم الطلب من اسم النطاق حتى Pod.
2. احكِ رحلة commit إلى صورة جديدة ثم Argo CD rollout.
3. اشرح الفرق بين PVC replica وbackup، ثم خطوات تجربة الاستعادة.
4. حلّل تنبيه TargetDown بخطوات تحقق، من غير ما تبدأ بإعادة التشغيل.