دوكر ببساطة، ولماذا نحتاجه أصلًا

دوكر أداة تجمع برنامجك داخل حاويات معزولة ليعمل في أي بيئة دون مشاكل. وهذا التعريف لا يعني شيئًا لمن لم يواجه المشكلة بعد، فلنبدأ من المشكلة.

المشكلة أولًا #

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

وهذا ما يحله دوكر بالضبط: يأخذ برنامجك ويضعه في بيئة معزولة فيها كل ما يحتاج إليه ليعمل: إصدار Node الصحيح، وإصدار قاعدة البيانات الصحيح، والمكتبات. فيعمل بالطريقة نفسها في كل مكان ترفعه إليه.

ثلاثة أجزاء، كل واحد فوق الذي قبله #

• Dockerfile: الملف الذي تكتب فيه التعليمات، ليعرف دوكر كيف يشغّل برنامجك، وما الإصدارات والمكتبات التي يستخدمها.

• Image: نسخة مجمّدة من برنامجك، تنشأ حين تبني الـ Dockerfile.

• Container: النسخة التي تعمل فعلًا. الحاويات سريعة وخفيفة ومعزولة على مستوى التطبيق.

ما الفرق بينه وبين الآلة الافتراضية؟ #

العزل في دوكر على مستوى التطبيق: يعزل الملفات التي يحتاج إليها برنامجك، لكنه يظل يستخدم نظام الخادم الأساسي نفسه ولا يبني نظامًا جديدًا في كل مرة. أما الآلة الافتراضية فعزلها على مستوى العتاد، وتحتاج إلى نظام وذاكرة ومساحة خاصة بها.

ولهذا يعتمد المبرمجون على دوكر في نشر برامجهم بدل الآلات الافتراضية.