السلام عليكم يا جماعة الخير، معكم أخوكم أبو عمر.
خليني أحكيلكم قصة صارت معي قبل كم سنة، قصة يمكن كثير منكم عاشها. كنا شغالين على مشروع كبير شوي، فيه تحليل بيانات بالبايثون، وواجهة خلفية بـ Node.js، وقاعدة بيانات PostgreSQL، وشوية مكتبات غريبة عجيبة مكتوبة بلغة C++ عشان السرعة. فريقنا كان خليط: أنا على لينكس، وزميلي أحمد على ماك، وانضم إلنا شب جديد اسمه “سامر” شغال على ويندوز.
أول يوم لسامر، أعطيناه صلاحية الدخول للمشروع على Git، وحكيناله “يلا يا بطل، نزّل المشروع وشغّله”. يا ريتنا ما حكيناها! اللي كان المفروض ياخذ ساعة ساعتين، أخذ مع سامر ثلاث أيام كاملة. ثلاث أيام من الجحيم التقني، صدقوني. مرة نسخة البايثون غلط، ومرة الـ node-gyp على ويندوز عامل مشاكل عشان يترجم مكتبة الـ C++، ومرة تعريفات قاعدة البيانات مش زابطة معه. كل شوي يبعتلنا على Slack: “يا شباب، مش راضي يشتغل!”، “طلعتلي هاي الرسالة الغريبة!”، “عندي نسخة X وهو بده نسخة Y!”.
قضينا ساعات معه على Zoom، نشارك الشاشة ونحاول نحل المشاكل وحدة ورا وحدة. كل ما نحل مشكلة، تطلع عشرة غيرها. بالنهاية، وبعد ما شعره قرب يشيّب وهو لسا ما كتب سطر كود واحد، زبطت الأمور. بس السؤال اللي ضل يطن في راسي: “معقول في 2020s لسا بنعاني من هاي المشكلة؟ معقول كل مبرمج جديد بده ينضم إلنا لازم يمر بهاد الموال؟”. من هنا، بلشت رحلة البحث عن حل جذري، حل ينهي عبارة “بس شغالة على جهازي!” للأبد. والحل كان اسمه: Dev Containers.
ما هي “حاويات التطوير” (Dev Containers)؟ ببساطة شديدة
قبل ما ندخل في التفاصيل التقنية المعقدة، تخيل معي السيناريو التالي: بدل ما تعطي المبرمج الجديد قائمة طويلة من التعليمات (نزّل بايثون نسخة 3.9.7 بالضبط، بعدين نزّل Node.js نسخة 16.13.2، واوعك تنزل غيرها، وبعدين نصّب هاي المكتبات…)، بتعطيه “صندوق سحري” جاهز. هذا الصندوق فيه كل شي بيحتاجه المشروع: نظام التشغيل المناسب، اللغات بالإصدارات الصحيحة، المكتبات، الإعدادات، وحتى إضافات محرر الأكواد (VS Code extensions) اللي الفريق متفق عليها.
هذا “الصندوق السحري” هو بالضبط ما نسميه حاوية التطوير (Dev Container).
تقنياً، هي عبارة عن حاوية دوكر (Docker Container) تم إعدادها وتجهيزها خصيصاً لتكون بيئة تطوير متكاملة. أنت لا تقوم فقط بتشغيل تطبيقك داخل الحاوية، بل أنت تقوم بالتطوير والكتابة والبرمجة داخلها مباشرة من خلال محرر الأكواد المفضل لديك مثل VS Code.
الفكرة عبقرية في بساطتها: بدلاً من أن يتكيف جهازك مع المشروع، نحن ننشئ بيئة مثالية ومعزولة للمشروع، ونضعها في حاوية، ثم ندخل نحن كمطورين إلى هذه الحاوية لنعمل.
وداعاً لعبارة “لكنها تعمل على جهازي!”: كيف تحل Dev Containers المشكلة؟
قد تبدو الفكرة جميلة نظرياً، ولكن كيف تترجم إلى فوائد عملية على أرض الواقع؟
1. توحيد بيئة العمل (Consistency)
هذه هي الفائدة الأكبر. كل فرد في الفريق، سواء كان يستخدم Windows, macOS, أو Linux، سيحصل على نفس بيئة العمل تماماً. نفس إصدار نظام التشغيل (عادةً توزيعة لينكس خفيفة)، نفس إصدارات اللغات (Python, Node, Go, Rust)، نفس المكتبات، ونفس الأدوات. هذا يقضي تماماً على المشاكل التي تنشأ من اختلافات أنظمة التشغيل.
نصيحة من أبو عمر: هذه الميزة وحدها كفيلة بتوفير عشرات، بل مئات الساعات من وقت الفريق على المدى الطويل. الوقت الذي كنت تقضيه في حل مشاكل البيئة، ستقضيه الآن في كتابة الكود وحل مشاكل حقيقية في المنتج.
2. السرعة في الإعداد (Rapid Onboarding)
تذكرون قصة سامر والثلاثة أيام؟ مع Dev Containers، يصبح إعداد المشروع لمبرمج جديد كالتالي:
git clone <رابط المشروع>- يفتح المشروع في VS Code.
- محرر الأكواد يكتشف وجود إعدادات الحاوية ويسأله: “هل تريد إعادة فتح المشروع في الحاوية؟”.
- يضغط “Reopen in Container”.
- ينتظر بضع دقائق بينما يتم بناء الحاوية لأول مرة… وهذا كل شيء!
خلال دقائق، يحصل المبرمج الجديد على بيئة عمل متطابقة 100% مع بيئة عمل باقي الفريق، جاهزة لكتابة أول سطر كود. لا إحباط، لا تضييع للوقت، وإنتاجية من اليوم الأول.
3. العزل والنظافة (Isolation)
كل مشروع يعمل في حاويته الخاصة المعزولة تماماً عن نظام التشغيل الأساسي وعن المشاريع الأخرى. هل لديك مشروع قديم يحتاج Python 2.7 ومشروع جديد يحتاج Python 3.11؟ لا مشكلة على الإطلاق. كل مشروع يعيش في عالمه الخاص دون أن يؤثر على الآخر.
هذا يعني أن جهازك الشخصي (الـ Host) يبقى نظيفاً. لن تضطر لتثبيت عشرات الإصدارات المختلفة من Node.js أو Ruby أو غيرها وتلويث نظامك بحزم ومكتبات قد لا تستخدمها إلا لمشروع واحد.
يلا نشتغل عملي: كيف تبدأ مع Dev Containers في VS Code؟
الكلام النظري جميل، لكن خلينا نشوف كيف نطبق هذا الكلام عملياً. العملية أسهل بكثير مما تتخيل.
المتطلبات الأساسية
قبل أن تبدأ، تأكد من أن لديك الأدوات التالية مثبتة على جهازك:
- Visual Studio Code: محرر الأكواد الشهير من مايكروسوفت.
- Docker Desktop: البرنامج الذي يدير الحاويات على جهازك (يعمل على Windows, macOS, و Linux).
- إضافة Dev Containers: ابحث عنها في متجر إضافات VS Code باسم
ms-vscode-remote.remote-containersوقم بتثبيتها.
الخطوة الأولى: إضافة إعدادات الحاوية لمشروعك
افتح مشروعك الحالي في VS Code. الآن، اتبع الخطوات التالية:
- اضغط على
F1أوCtrl+Shift+Pلفتح لوحة الأوامر (Command Palette). - اكتب وابحث عن:
Dev Containers: Add Development Container Configuration Files... - سيظهر لك معالج (wizard) يقترح عليك مجموعة كبيرة من القوالب الجاهزة (Node.js, Python, Go, Rust, 등). اختر القالب الأنسب لمشروعك. مثلاً، إذا كان مشروعك Node.js، اختر “Node.js & TypeScript”.
- سيطلب منك تحديد إصدار اللغة، وربما بعض الأدوات الإضافية (مثل إضافة قواعد بيانات).
- بعد الانتهاء، سيقوم VS Code بإنشاء مجلد جديد في مشروعك اسمه
.devcontainerوبداخله ملف (أو ملفان) أهمهمdevcontainer.json.
تشريح ملف devcontainer.json
هذا الملف هو العقل المدبر لكل شيء. هو الذي يخبر VS Code و Docker كيف يبنيان بيئة التطوير الخاصة بك. لنلقِ نظرة على مثال بسيط لمشروع Node.js:
{
// اسم وصفي للحاوية
"name": "My Node.js Project",
// الصورة (Image) التي ستبنى عليها الحاوية. يمكن استخدام صور جاهزة أو ملف Dockerfile خاص
"image": "mcr.microsoft.com/devcontainers/typescript-node:18-bullseye",
// إعدادات خاصة بـ VS Code داخل الحاوية
"settings": {
"terminal.integrated.shell.linux": "/bin/bash"
},
// الإضافات (Extensions) التي تريد تثبيتها تلقائياً داخل الحاوية
"extensions": [
"dbaeumer.vscode-eslint",
"esbenp.prettier-vscode",
"orta.vscode-jest"
],
// توجيه المنافذ (Ports) من الحاوية إلى جهازك. مثلاً، لو تطبيقك يعمل على منفذ 3000
"forwardPorts": [3000],
// أمر يتم تنفيذه بعد إنشاء الحاوية (مثالي لتثبيت الاعتماديات)
"postCreateCommand": "npm install",
// المستخدم الذي سيتم تشغيل الأوامر به داخل الحاوية
"remoteUser": "node"
}
كما ترى، الملف مقروء وواضح جداً. أنت تحدد كل تفاصيل بيئتك في ملف واحد، تضعه مع الكود في Git، وكل من يقوم بتحميل المشروع يحصل على نفس الإعدادات تماماً.
ما بعد الأساسيات: نصائح من الخنادق
بعد فترة من استخدام Dev Containers، ستكتشف بعض الميزات المتقدمة التي ستجعل حياتك أسهل.
استخدام Docker Compose لبيئات معقدة
ماذا لو كان مشروعك لا يعتمد فقط على لغة برمجة، بل يحتاج أيضاً قاعدة بيانات مثل PostgreSQL وخادم Caching مثل Redis؟ هنا يأتي دور Docker Compose.
يمكنك تعديل ملف devcontainer.json ليشير إلى ملف docker-compose.yml. سيقوم VS Code حينها بتشغيل كل الخدمات المعرفة في ملف Compose، ويقوم بربط محرر الأكواد بالخدمة التي تحددها كبيئة تطوير.
مثال في devcontainer.json:
{
"name": "My App with Postgres",
"dockerComposeFile": "docker-compose.yml",
"service": "app", // اسم الخدمة في ملف Compose التي تمثل بيئة التطوير
"workspaceFolder": "/workspace",
...
}
وفي ملف docker-compose.yml، تقوم بتعريف خدمة التطبيق (app) وخدمة قاعدة البيانات (db).
مشاركة إعدادات Git
من أجمل الميزات هي أن VS Code يقوم تلقائياً بمشاركة إعدادات Git من جهازك (Host) إلى داخل الحاوية. هذا يعني أنك عندما تقوم بعمل commit أو push من الطرفية (terminal) داخل الحاوية، سيتم ذلك باستخدام حسابك واسمك وبريدك الإلكتروني الصحيحين دون أي إعدادات إضافية. تفصيلة صغيرة لكنها توفر الكثير من العناء.
الخلاصة: هل تستحق Dev Containers كل هذا العناء؟
قد يكون هناك منحنى تعلم بسيط في البداية، وقد يستهلك Docker بعضاً من موارد جهازك. لكن بالمقارنة مع الوقت الضائع، والإحباط، ومشاكل الإنتاجية التي يحلها، فالجواب هو: نعم، وبكل تأكيد!
التحول إلى Dev Containers هو استثمار في إنتاجية فريقك وسلامك النفسي كمطور. هو نقلة نوعية من “كل واحد يدبر حاله” إلى “لدينا بيئة واحدة، موحدة، وموثوقة للجميع”.
نصيحتي الأخيرة لك: لا تنتظر حتى ينضم عضو جديد لفريقك وتعيشوا كابوس الإعداد من جديد. ابدأ اليوم. اختر مشروعاً صغيراً، جرب إضافة إعدادات Dev Container له، وشاهد السحر بنفسك. جربوها يا جماعة، ومش رح تندموا. وعد من أبو عمر! 😉
