المقدمة

بعد ما اتعلمت Kubernetes، كنت فاكرة إني بقيت أقدر أبني أي Infrastructure.

لكن مع أول مشروع حقيقي، اكتشفت إن فيه سؤال مهم نسيت أسأله...

مين هيجهز البيئة اللي Kubernetes هيشتغل عليها؟

قبل ما تنشر أول Application على Kubernetes، غالبًا هتحتاج:

  • شبكة (VPC أو Virtual Network)
  • Subnets
  • Security Groups أو Firewalls
  • Load Balancer
  • Kubernetes Cluster
  • Compute Nodes
  • IAM Roles & Policies
  • قواعد بيانات
  • Storage
  • DNS

كل ده لازم يكون موجود قبل ما Kubernetes يبدأ يدير التطبيقات.

هنا ظهر مفهوم Infrastructure as Code (IaC(

بدل ما تنشئ الموارد يدويًا من خلال الـ Console...

تكتب البنية التحتية في ملفات Code.

وده بالضبط اللي بتقدمه أدوات زي Terraform.

فبدل ما تقول:

"أنشئلي Server."

أنت بتوصف:

  • شكل الشبكة.
  • عدد الخوادم.
  • قواعد الأمان.
  • موازن الأحمال.
  • قواعد البيانات.
  • وكل مكونات البنية التحتية.

ثم تترك الأداة تنشئها بالطريقة اللي وصفتها.

لكن فيه نقطة مهمة جدًا...

Terraform لا يدير التطبيقات.

Kubernetes لا يبني البنية التحتية.

كل واحد ليه مسؤولية مختلفة.

Terraform مسؤول عن Provisioning Infrastructure.

أما Kubernetes فمسؤول عن Orchestrating Containerized Applications فوق هذه البنية التحتية.

ليه بقى Infrastructure as Code يعتبر نقلة كبيرة؟

لأن البنية التحتية بقت:

✅ قابلة للمراجعة (Code Review)

✅ محفوظة في Git

✅ يمكن إعادة إنشائها بنفس الشكل في أي وقت

✅ تقلل الأخطاء الناتجة عن الإعداد اليدوي

وده أحد أهم مبادئ DevOps:

إذا كان بالإمكان كتابة شيء في Code... فمن الأفضل ألا يُدار يدويًا.

💡 الخلاصة

Terraform وKubernetes مش منافسين.

هما بيشتغلوا في مستويين مختلفين.

Terraform يبني البيئة.

Kubernetes يدير التطبيقات داخلها.

ولما يشتغلوا مع بعض...

تحصل على بنية تحتية قابلة للتكرار، وتطبيقات قابلة للإدارة والتوسع.

🚀 في المقال القادم...

إذا كانت البنية التحتية بقت Code...

ليه احتجنا CI/CD؟ وهل الهدف فعلًا هو سرعة الـ Deployment؟