المقدمة

إذا كان Cloud حل مشكلة البنية التحتية... ليه ظهر Docker؟ 🐳

في المقال اللي فات اتكلمنا إن الـ Cloud خلّى إنشاء البنية التحتية أسرع وأسهل.

لكن رغم كده...

كان لسه فيه مشكلة بتواجه كل فرق التطوير تقريبًا.

تخيل إن مطور خلص Feature جديدة، وجربها على جهازه.

كل حاجة شغالة.

لما الكود راح لبيئة الاختبار...

بدأت المشاكل تظهر.

ولما وصل للإنتاج...

الموضوع بقى أسوأ.

والجملة اللي كانت بتتكرر في كل فريق تقريبًا:

"بس هو شغال عندي!"

المشكلة غالبًا مكانتش في الكود.

  • كانت في بيئة التشغيل.
  • نسخة Python مختلفة.
  • مكتبة ناقصة.
  • إعدادات نظام مختلفة.
  • متغيرات بيئة (Environment Variables) مختلفة.
  • أو حتى اختلاف في نظام التشغيل نفسه.

هنا ظهرت فكرة الـ Containers.

الفكرة ببساطة هي:

بدل ما تنقل الكود فقط...

انقل معاه كل البيئة اللي محتاجها علشان يشتغل.

  • التطبيق.
  • المكتبات.
  • الاعتماديات (Dependencies).
  • الإعدادات.

بحيث يشتغل بنفس الطريقة أينما تم تشغيله.

لكن لازم نوضح نقطة مهمة.

Docker لم يخترع فكرة الـ Containers.

تقنيات الـ Containers كانت موجودة بالفعل في أنظمة التشغيل، خاصة Linux.

لكن Docker قدّم تجربة استخدام سهلة وموحدة، وسهّل بناء الصور (Images)، ومشاركتها، وتشغيلها، وده كان أحد الأسباب الرئيسية لانتشاره الواسع.

وده أدى لميزة كبيرة جدًا.

بدل ما المطور يقول:

"اشتغل عندي."

بقى يقدر يقول:

"شغّل نفس الـ Image."

وبالتالي تقل الاختلافات بين بيئة التطوير والاختبار والإنتاج.

💡 الخلاصة

Docker لم يظهر لأنه "أفضل من الـ Virtual Machines".

ولا لأنه اخترع الـ Containers.

ظهر لأنه جعل تشغيل التطبيقات في بيئات متسقة أسهل، وساعد على توحيد طريقة بناء وتشغيل ونقل التطبيقات.

لكن مع الوقت... ظهر تحدٍ جديد.

لو عندك 5 Containers فالأمر بسيط.

لكن ماذا لو أصبح عندك 500 أو 5000 Container؟

مين هيديرهم؟

وده بالضبط سبب ظهور Kubernetes...و هو موضوع البوست القادم.