Скачать или смотреть Environment management & Kubernetes network policy بالعربي - GitOps and k8s ch3.1

Review for chapter 3 from #gitops and #Kubernetes book in #arabic
https://www.manning.com/books/gitops-...

Reviewed and Introduced by Mohammed Ragab
  / rgbdev  

#kubernetes #gitops #devops #arabic
#deployment
#Environment management and #Kubernetes #network #policy

Environment management

فى الفصل دا بتكلم عن ال
environments وازاى نديرها وازى هنستخدم Kubernetes كأداة عشان نعبر بيها عنهم ونحقق الفصل بينهم فى البداية خلونا نتكلم عن انواع ال environments دى فى ال software development اى تطبيق بيحتاج يمر بمراحل ما قبل ال live او ال production ودا زى مثلا اختبار التطبيق بصور مختلفة المراحل دى بتختلف حسب حجم التطبيق وحسب ال process الى التطبيق ماشى بيها لكن لو هنتكلم فى ال optimal case هيكون عندنا الأنواع دى لكن خلينا نوضح الأول ال environment بتتكون من ايه

الكود ودى تعليمات لل machines عشان تنفذ مهمة معينة
ال runtime dependencies احيانا كتير الكود بيحتاج ليها عشان يتنفذ زى مثلا لو كاتب كود ب nodejs فانت محتاج Nodejs runtime
ال configurations ودى ممكن تكون زى مثلا ال connection string مع داتا بيس او URL ل external service ال system بتاعك بيكلمها الخ
فى حالة Kubernetes كل ال code وال runtime معمول لها packing فى container image والى بتسهل عملية ال run and deploy ليها فى اى مكان وال configuration فى الحالة دى ممكن تكون environment variables والتي تقدر تغيرها من environment للتانية بسهولة وبكدا التطبيق يقدر ي connect لل correct depencies بشكل منفصل لكل environment والى هنتكلم عنه بعد شوية .

انواع ال
environments

ال QA : ودى ال environment الى يختبر فيها كل code change على ال hardware والداتا وكذلك كل ال production dependencies عشان اتأكد ان ال service شغالة بشكل كويس
ال E2E : لو كل ال tests عدت من مرحلة ال QA بتترقى عشان تدخل مرحلة اسمها ال E2E ودى ال stable environment لل pre-releases المختلفة من ال services التانية عشان نعمل test لل integration بين ال services وال QA وال e2e دول بنسميهم pre-production عشان مفيش اى real data or traffic عليهم
ال stage : بعد ما نتأكد من مرحلة ال QA وال e2e كدا بئا فيه عندنا release جاهز لل production طيب هل نطلعه production على طول لأ بندخله مرحلة ال stage دى بتكون ليها access على ال production dependencies الفعلية عشان نتأكد ان ال dependencies دى شغالة كويس مع ال release الجديدة زى مثلا ال db schema update لكن ال traffic على ال environment دى بيكون من ال test بس فلذلك لو حصل اى مشكلة مش هت impact ال real end user لكن عشان هى كمان configured انها تستخدم ال production dependencies لازم ناخد بالنا واحنا بنعمل test عليها عشان منضربش اى production data

ال production : لما ال test يعدى من ال stage كدا خلاص احنا جاهزين نطلع على ال live production

كل ابلكشن بيكون له بعض ال properties والى بتكون مرتبطة بال environment بشكل منعزل عن باقى ال environments التانية زى مثلا ال connection للداتا بيس او ال distributed caching وطبعا كل environemnt بيكون ليها netoworking policy خاص بيها لل ingress وال egress عشان ت block الترافيك الغير سليم زى مثلا غلطة فى الكونكشن سترنج تخلى ال pre-production تعمل اتصال مع ال production db وكذلك كمان ال access control مش كل المبرمجين او فريق العمل له اكسيس على كل ال environments ودا طبعا بيساعد فى تقليل الاخطاء البشرية قدر الامكان .

ال environment داخل Kubernetes والى استخدمنا فيها ال namespace عشان نعبر بيها عنها وال dependencies بتاعتنا جوا نفس ال namespace وحاطين ال Network policy عشان نكترول الى داخل والى خارج وكمان ال RBAC ودى Role-based access control فى Kubernetes عشان اقدر احط roles للأكسس للمستخدم على مستوى organization بتاعتى زى انى ادى يوزر اكسس على نيم سبيس وواحدة تانية لأ

كمان ال network policy اقدر اعمل blocking بأكتر من شكل سواء عن طريق ال IP او عن طريق ال namespace زى مثلا محدش يقدر يأكسس ال db الى فى النيم سبيس الفلانية غير من جوا ال namespace دى او namespaces محددة او pods محددة فإحنا نقدر نعمل ال restriction ب 3 طرق
1- بعض ال pods والبعض الاخر مش مسموح
2- ال namespaces المسموح ليها
3- ال Ip blocking
ودا على مستوى ال ingress وال egress لكن يعنى ايه Ingress ويعنى ايه egress
ال ingress : يعنى دا ال communication الى جاى من external traffic لل apps بتاعتك
ال egress : العكس وهو ان ال traffic الى بيعمله ال apps بتاعتك للحاجات الى برا فانت هنا تقدر تمنع الأبلكشن بتاعك يكلم حاجة برا زى مثلا ال qa app ميكملش ال prod db والعكس

زى ما هو موضح لما نستخدم pod or namespace based بنستخدم ال selector واحنا وضحنا ال selector قبل كدا فى الفيديوهات الى فاتت لكن لو استخدمها Ip based بيتم عن طريق ال CIDR range
ملاحظة : دا Network policy plugin بتحتاج انك تستخدم Kubernetes network بتسبورت ال
network policy plugin وتقدر تطلع على انواع ال networks من هنا
Installing Addons | Kubernetes
https://kubernetes.io/docs/concepts/c...