مقدمة: “يا أبو عمر، المشروع مش راضي يشتغل عندي!”
قبل كم سنة، انضم لفريقنا شب جديد، خلينا نسميه “سائد”، مبرمج شاطر ومتحمس وعين الله عليه. المشروع اللي كان لازم يشتغل عليه كان شوي معقد: جزء مكتوب بلغة Python مع مكتبات تعلم آلة، وجزء ثاني Node.js للواجهة الخلفية، وقاعدة بيانات PostgreSQL بإصدار معين بالزبط، وكمان Redis للكاش. باختصار، “كوكتيل” تقنيات محترم.
أعطينا سائد ملف الـ README اللي طوله كيلومتر، واللي فيه قائمة تعليمات من 37 خطوة لإعداد بيئة التطوير. قضى سائد أول يوم وهو يحاول يثبّت كل شي. ثاني يوم، طلعله خطأ غريب في مكتبة من مكتبات بايثون لأنه نسخة الـ C++ compiler على جهازه الماك كانت مختلفة عن نسختنا على لينكس. ثالث يوم، اكتشفنا إنه نسخة Node.js اللي نزلها أحدث من اللي بنستخدمها والمشروع “انضرب”.
بعد ثلاث أيام من الإحباط واللف والدوران، وإجا سائد عندي على المكتب وحكالي بنبرة يأس: “يا أبو عمر، والله تعبت، المشروع مش راضي يشتغل عندي بالمرة! كل شوي بيطلعلي قصة شكل!”. وقتها، كل الفريق ضيّع ساعات وهو يحاول يساعده، والإنتاجية نزلت للأرض. كلنا كنا بنعرف هاي المعاناة، وكلنا قلنا أو سمعنا الجملة المشؤومة: “غريبة… لكنه يعمل على جهازي!”.
هذا الموقف، اللي تكرر كثيرًا، كان هو القشة التي قصمت ظهر البعير. كان لازم نلاقي حل جذري لهذه الفوضى. وهنا بدأت رحلتنا مع ما يُعرف بـ “حاويات التطوير” أو Dev Containers.
شو القصة؟ ما هو أصل المشكلة؟
مشكلة “It works on my machine” هي عرض لمرض أعمق في عالم تطوير البرمجيات. كل مبرمج عنده جهاز بإعدادات مختلفة:
- أنظمة تشغيل مختلفة: واحد بشتغل على Windows، والثاني على macOS، والثالث على توزيعة لينكس معينة.
- إصدارات مختلفة من اللغات والمكتبات: هل تستخدم Python 3.9.1 أم 3.9.2؟ هل نسخة Node.js هي 16.13.0 أم 16.14.0؟ هذه الفروقات البسيطة ممكن تسبب مشاكل كبيرة.
- متغيرات البيئة (Environment Variables): مفاتيح الـ API، وسلاسل الاتصال بقواعد البيانات، كلها تختلف من جهاز لآخر.
- الخدمات المعتمد عليها: مثل قواعد البيانات (PostgreSQL, MySQL, MongoDB) أو خدمات التخزين المؤقت (Redis). هل إصدار قاعدة البيانات على جهازك هو نفس الإصدار على السيرفر؟
الطريقة التقليدية كانت تعتمد على توثيق كل هذه التفاصيل في ملف README.md، وتأمل أن يتبع الجميع التعليمات بحذافيرها. ولكن كما نعلم، الأمل ليس استراتيجية جيدة في هندسة البرمجيات.
الحل السحري: حاويات التطوير (Dev Containers)
تخيل معي لو أنك تستطيع أن تضع مشروعك بالكامل، بكل لغاته ومكتباته وقواعد بياناته وإعداداته، داخل “صندوق” أو “حاوية” معزولة. أي شخص يريد العمل على المشروع، كل ما عليه فعله هو فتح هذا الصندوق، وسيجد بيئة عمل متطابقة 100% وجاهزة للانطلاق، بغض النظر عن نظام التشغيل الذي يستخدمه.
هذا بالضبط ما تفعله حاويات التطوير. هي عبارة عن بيئات تطوير تعمل داخل حاويات Docker، ومدمجة بشكل عبقري مع محرر الأكواد المفضل لدى الكثيرين: Visual Studio Code.
ببساطة، بدلًا من تثبيت الأدوات على جهازك، أنت تقوم بتعريفها في ملفات بسيطة، وVS Code بالتعاون مع Docker يبني لك بيئة معزولة ونظيفة وجاهزة خلال دقائق.
كيف تعمل هذه التقنية؟
تعتمد الفكرة على ثلاث مكونات أساسية:
- Docker: هي التقنية التي تسمح لنا بإنشاء وتشغيل “الحاويات”. الحاوية هي نسخة خفيفة ومعزولة من نظام تشغيل (عادة لينكس) تحتوي على كل ما يحتاجه تطبيقك ليعمل.
- محرر VS Code: محرر الأكواد الشهير من مايكروسوفت.
- إضافة (Remote – Containers): هي الإضافة التي تربط بين VS Code و Docker، وتسمح لك بفتح مجلد مشروعك “داخل” الحاوية، وكأنك تبرمج على جهازك مباشرة.
عندما تفتح مشروعًا مُعدًا لاستخدام Dev Containers، تقوم الإضافة بقراءة ملفات الإعدادات، وبناء صورة Docker (إذا لم تكن موجودة)، ثم تشغيل حاوية منها، وتوصيل VS Code بها. والنتيجة؟ محرر الأكواد يعمل على جهازك، ولكن الـ Terminal وكل أوامر اللغة والمترجمات تعمل داخل الحاوية المعزولة. زي الحلاوة!
لنطبق عمليًا: إعداد مشروع Python بسيط
كلام النظريات حلو، بس خلينا نشوف الموضوع بشكل عملي. لنفترض أن لدينا مشروع Python بسيط ونريد إعداده باستخدام Dev Containers.
الخطوة 0: المتطلبات الأساسية
قبل أن نبدأ، تأكد من تثبيت الآتي على جهازك:
- Docker Desktop (يعمل على Windows, Mac, و Linux).
- Visual Studio Code.
- إضافة Remote – Containers من داخل VS Code.
الخطوة 1: إنشاء مجلد الإعدادات
في جذر مشروعك، قم بإنشاء مجلد جديد باسم .devcontainer.
الخطوة 2: إنشاء ملف `devcontainer.json`
داخل مجلد .devcontainer، أنشئ ملفًا جديدًا باسم devcontainer.json. هذا الملف هو العقل المدبر، هو الذي يخبر VS Code بكيفية بناء بيئة التطوير. ألصق فيه الكود التالي:
{
"name": "My Python Project",
"build": {
"dockerfile": "Dockerfile"
},
"customizations": {
"vscode": {
"settings": {
"python.defaultInterpreterPath": "/usr/local/bin/python"
},
"extensions": [
"ms-python.python",
"ms-python.vscode-pylance"
]
}
},
"forwardPorts": [8000],
"postCreateCommand": "pip install -r requirements.txt"
}
شرح سريع للملف:
name: اسم سيظهر في VS Code لتمييز الحاوية.build.dockerfile: يخبر VS Code أن يستخدم ملفًا اسمهDockerfileلبناء البيئة.customizations.vscode.extensions: قائمة بالإضافات التي تريد تثبيتها تلقائيًا داخل الحاوية (هنا نثبت إضافة Python الرسمية). هذا يضمن أن كل الفريق يستخدم نفس الأدوات.forwardPorts: إذا كان تطبيقك يعمل على منفذ معين (مثل 8000)، هذا الإعداد سيقوم تلقائيًا بتوجيهه من الحاوية إلى جهازك.postCreateCommand: أمر يتم تنفيذه مرة واحدة فقط بعد إنشاء الحاوية. هنا نستخدمه لتثبيت مكتبات Python من ملفrequirements.txt.
الخطوة 3: إنشاء ملف `Dockerfile`
بجانب ملف devcontainer.json (أي داخل مجلد .devcontainer)، أنشئ ملفًا آخر باسم Dockerfile. هذا الملف يحتوي على التعليمات الفعلية لبناء بيئة اللينكس الخاصة بنا.
# ابدأ من صورة بايثون رسمية بإصدار محدد
FROM python:3.10-slim
# تعيين مجلد العمل داخل الحاوية
WORKDIR /app
# انسخ ملف المتطلبات إلى مجلد العمل
# نقوم بنسخ هذا الملف أولاً للاستفادة من التخزين المؤقت في Docker
COPY requirements.txt .
# باقي الكود سيتم تحميله بواسطة VS Code تلقائيًا
الخطوة 4: السحر يبدأ الآن!
الآن، افتح مشروعك في VS Code. سيلاحظ المحرر وجود مجلد .devcontainer وسيعرض لك إشعارًا في الزاوية اليمنى السفلية يسألك: “Folder contains a Dev Container configuration file. Reopen to develop in a container?”.
اضغط على الزر الأخضر “Reopen in Container”.
شاهد السحر يحدث: VS Code سيقوم ببناء صورة Docker (قد يستغرق هذا بعض الوقت في المرة الأولى)، ثم يشغل الحاوية، ويثبت الإضافات، وينفذ أمر postCreateCommand. بعد لحظات، سيعاد فتح VS Code وهو متصل بالكامل بالحاوية. إذا فتحت الـ Terminal المدمج (Ctrl+`)، ستجد نفسك داخل نظام لينكس، مع تثبيت Python 3.10 وكل المكتبات المطلوبة. جاهز للعمل!
هلأ، لو انضم “سائد” جديد للفريق، كل ما عليه فعله هو عمل `git clone` للمشروع، وفتحه في VS Code، والضغط على “Reopen in Container”. خلال دقائق، سيكون لديه بيئة عمل متطابقة 100% لبيئة عمل باقي الفريق. لا مزيد من الأيام الضائعة! 😉
نصائح من خبرة أبو عمر
بعد استخدامنا لهذه التقنية لسنوات، جمعت لكم بعض النصائح العملية:
- ابدأ بالقوالب الجاهزة: VS Code يوفر قوالب جاهزة لأغلب اللغات والمنصات (Node.js, Python, Go, Rust, …). عند إنشاء ملف
devcontainer.jsonلأول مرة، استخدم الأمر `Remote-Containers: Add Development Container Configuration Files…` من لوحة الأوامر (Ctrl+Shift+P) واختر القالب المناسب. هذا يوفر عليك الكثير من الوقت. - استخدم Docker Compose لخدمات متعددة: إذا كان مشروعك يحتاج قاعدة بيانات وخادم Redis (مثل قصة سائد)، فاستخدام ملف
docker-compose.ymlهو الحل الأمثل. يمكنك تعريف كل خدماتك في هذا الملف، وربطها بحاوية التطوير بسهولة. - لا تضع الأسرار في الكود: لا تكتب مفاتيح API أو كلمات المرور في ملفات الإعدادات. استخدم ملفات
.envالتي يتم تجاهلها بواسطة Git، وقم بتحميلها في الحاوية. - حسّن بناء الـ Dockerfile: ترتيب الأوامر في
Dockerfileمهم جدًا لسرعة البناء. ضع الأوامر التي تتغير بشكل نادر في الأعلى (مثل تثبيت الأدوات الأساسية)، والأوامر التي تتغير باستمرار (مثل نسخ كود المشروع) في الأسفل للاستفادة من الـ Caching.
الخلاصة يا جماعة الخير 🚀
التحول إلى “حاويات التطوير” ليس مجرد تغيير في أداة، بل هو تغيير في عقلية وثقافة الفريق بأكمله. هو استثمار قليل في البداية مقابل توفير هائل في الوقت والجهد وتقليل لا نهائي لمشاكل الإعداد على المدى الطويل.
لقد أنقذتنا هذه التقنية من جحيم “لكنه يعمل على جهازي”، وحولت عملية انضمام المطورين الجدد من كابوس يستمر لأيام إلى عملية سلسة تتم في دقائق. لم نعد نضيع وقتنا في حل مشاكل البيئات المختلفة، بل أصبحنا نركز على ما يهم حقًا: كتابة كود نظيف وبناء منتجات رائعة.
نصيحتي الأخيرة لك: لا تخف من استثمار الوقت في تعلم أدوات تحسن إنتاجيتك وإنتاجية فريقك. المبرمج المحترف لا يكتب الكود فقط، بل يبني ويصقل أدواته التي تساعده على الكتابة بشكل أفضل وأسرع. جربوا Dev Containers، وأنا أضمن لكم أنكم لن تنظروا إلى الوراء أبدًا.
