لم تعد هندسة الواجهات الأمامية الحديثة تشبه ما كانت عليه قبل عقد من الزمان. فأنت لا تكتفي بكتابة HTML و CSS فحسب؛ بل إن المشروع النموذجي الآن يأتي مع بيئة تشغيل Node.js محددة، وإصدار مثبت من مدير الحزم، ومجموعة متشابكة من أدوات البناء، ومسارات نشر تتوقع أن يكون كل شيء متوافقاً تماماً. وفي مكان ما بين أول أمر npm install وعملية بناء الإنتاج النهائية، تتسلل اختلافات صغيرة. زميل لك يستخدم Node 20، بينما تستخدم أنت Node 18. أداة CLI عالمية على جهازك تخفي نقصاً في التبعيات على جهازه. ثم تأتي العبارة التي لا يريد أحد سماعها: "إنه يعمل على جهازي".
يستحق Docker مكانه في مجموعة أدوات الواجهات الأمامية الخاصة بك لأنه يزيل حالة عدم اليقين تلك. فهو يقوم بتجميع تطبيقك مع بيئة التشغيل الدقيقة، ومكتبات النظام، والتبعيات التي يحتاجها. وسواء كنت تبرمج على Windows، أو تقوم بالشحن من macOS، أو تنشر على مثيل سحابي يعمل بنظام Linux، فإن السلوك سيبقى متطابقاً.
لماذا يجب على مطوري الواجهات الأمامية الاهتمام
إن نقاط الألم التي يحلها Docker ليست مجرد مفاهيم مجردة، بل تظهر في كل سبرينت (sprint).
تستهلك تعارضات الإصدارات الكثير من الوقت. مشروع قديم لأحد العملاء يتطلب Node 18، ومشروعك الجانبي يتطلب Node 20، وعملك في شركة ناشئة جديدة يتطلب Node 22. بدون الحاويات، ستدير هذا الأمر عبر أدوات إدارة الإصدارات، وهذا يعمل حتى يتوقف عن العمل. فقد يؤدي عدم تطابق بسيط في إصدار npm إلى تغيير كيفية حل التبعيات النظيرة (peer dependencies)، مما يتركك مع عملية بناء معطلة تعمل بشكل جيد لدى شخص آخر. عندما تعلن إحدى أطر العمل عن إصدار جديد، لا ينبغي أن تكون حلقة التغذية الراجعة عبارة عن ساعتين من إعادة التثبيت، بل يجب أن تكون مجرد تغيير في ملف واحد وإعادة تشغيل الحاوية.
تُعد الحزم العالمية (Global packages) مصدراً آخر للاحتكاك الصامت. قد يكون لديك Angular CLI أو Expo أو Prisma مثبتة عالمياً منذ ستة أشهر، بينما يقوم مطور جديد بتثبيت نفس الأداة حديثاً ويحصل على إصدار مختلف. فجأة، تظهر في سكربتات البناء تحذيرات لا تظهر في أي مكان آخر. يحل Docker هذه المشكلة من خلال إبقاء كل شيء محلياً بالمشروع؛ حيث تحدد إصدار Node في ملف Dockerfile الخاص بك، وتُثبت التبعيات داخل الحاوية، معزولة عن نظام التشغيل المضيف. قد يكون جهازك المحمول يعمل بنظام macOS أو Windows أو Ubuntu، لكن التطبيق سيرى نفس البيئة تماماً في كل مرة.
من الصعب تجاهل فوائد عملية التهيئة (Onboarding). لا يحتاج الموظفون الجدد إلى ملف readme مكون من ثلاث صفحات يغطي تثبيتات Homebrew، وأسماء nvm المستعارة، وإصلاحات الأذونات العالمية. كل ما عليهم فعله هو تثبيت Docker، واستنساخ المستودع (repository)، وتشغيل أمر واحد. الإعداد الذي كان يستغرق فترة بعد الظهر يتقلص الآن إلى دقائق. وعندما ينتقلون إلى مشاريع أخرى، لا يتبقى أي أثر؛ لا أدوات عالمية يتيمة، ولا أدوات إدارة إصدارات تتصارع على أولوية المسار (PATH). يظل جهازهم المحلي نظيفاً.
الصور والحاويات: الأساسيات
إذا كان Docker جديداً بالنسبة لك، فإن المصطلحات أبسط مما تبدو عليه. صورة Docker (Docker image) هي بمثابة مخطط (blueprint)؛ فهي تحتوي على كود المصدر الخاص بك، وبيئة تشغيل Node.js، وملف القفل (lockfile)، وكل تبعية مطلوبة لتشغيل التطبيق. أما الحاوية (container) فهي نسخة حية تم إنشاؤها من تلك الصورة. فكر في الصورة كأنها وصفة طعام، وفي الحاوية كأنها الوجبة الفعلية. يمكنك خبز نفس الكعكة مائة مرة من وصفة واحدة، ويمكنك تشغيل حاويات متطابقة من صورة واحدة دون القلق بشأن ما هو مثبت على الكمبيوتر المضيف.
ملف Dockerfile عملي
دعونا نلقي نظرة على نقطة بداية ملموسة. إذا كنت