Docker on kenji.blog

خطوات بناء بيئة تطوير محلية قابلة لإعادة الإنتاج باستخدام Docker

Sun, 13 Sep 2026 01:00:00 +0900

1. مقدمة: التخلص من مشكلة “إنها تعمل على جهازي”

في مجال تطوير البرمجيات، لطالما كانت مشكلة “إنها تعمل على جهازي (It works on my machine)” الناتجة عن اختلاف البيئات بين المطورين سبباً في إهدار الكثير من الوقت في العديد من المشاريع. فالاختلافات في أنظمة التشغيل، وإصدارات اللغات المثبتة، واعتماديات المكتبات، وتعارض الأدوات المثبتة عالمياً، تجعل البيئة المحلية دائماً عرضة لـ “عدم يقين الحالة”.

الحل الجذري لهذه التحديات يكمن في تقنية الحاويات مثل Docker، ونموذج البنية التحتية ككود (IaC). من خلال تحويل بيئة التطوير المحلية إلى حاويات، يمكن تحقيق العزل على مستوى نظام التشغيل، مما يسمح بإدارة إصدارات البيئة نفسها جنباً إلى جنب مع قاعدة الكود.

في هذا المقال، سنشرح بالتفصيل وبشكل شامل الخطوات اللازمة لبناء “بيئة تطوير محلية قابلة لإعادة الإنتاج بحيث تكون متطابقة تماماً بغض النظر عمن يقوم بتشغيلها، أو متى، أو على أي جهاز” باستخدام Docker، و Docker Compose، و VSCode DevContainers. كما سنتناول الآليات التقنية العميقة الكامنة وراءها، مع دمج وجهات نظر رياضية.

2. التوافق بين البنية التحتية ككود (IaC) وتقنية الحاويات

مبادئ IaC وتطبيقها على البيئة المحلية

البنية التحتية ككود (IaC) هي نهج لإدارة وتجهيز إعدادات البنية التحتية من خلال ملفات تعريف قابلة للقراءة آلياً، بدلاً من العمليات اليدوية. تشمل المبادئ الأساسية لـ IaC العناصر التالية:

النهج التعريفي (Declarative Approach): تحديد “ما يجب أن تكون عليه الحالة النهائية” بدلاً من “كيفية تغيير الحالة”.
الاستقواء (Idempotency): ضمان الحصول على نفس النتيجة (الحالة) دائماً بغض النظر عن عدد مرات تشغيل السكربت.
التحكم في الإصدارات (Version Control): حفظ حالة البنية التحتية ككود في أنظمة التحكم في الإصدارات (VCS) مثل Git، مما يتيح تتبع سجل التغييرات والمراجعة من قبل النظراء.

تطبيق IaC في بيئة التطوير المحلية يعني كتابة “الحالة المثالية” لبيئة التطوير ككود باستخدام ملفات مثل Dockerfile، و docker-compose.yml، و devcontainer.json. وهذا يحقق تجربة تأهيل (Onboarding) سلسة للأعضاء الجدد في الفريق، حيث يمكنهم بدء التطوير فوراً بمجرد استنساخ المستودع وتشغيل أمر واحد.

ميزات النواة (Kernel) التي تدعم تقنية الحاويات

تختلف تقنية الحاويات عن المحاكاة الافتراضية القائمة على الهايبرفايزر (مثل الأجهزة الافتراضية VM)، حيث إنها تقنية محاكاة افتراضية خفيفة الوزن تقوم بعزل العمليات (Isolation) مع مشاركة نواة نظام التشغيل المضيف. ولتحقيق ذلك، يتم استخدام الميزات التالية من نواة Linux بشكل أساسي:

مساحات الأسماء (Namespaces): توفر عرضاً مستقلاً لموارد النظام (مثل PID، والشبكة، ونقاط التركيب (Mount points)، والمستخدمين) لكل عملية.
مجموعات التحكم (Cgroups - Control Groups): تقوم بتقييد وتخصيص الموارد المادية (مثل المعالج CPU، والذاكرة، وإدخال/إخراج القرص I/O) التي يمكن للعملية استخدامها.
نظام ملفات الاتحاد (UnionFS - Union File System): تقنية تقوم بدمج عدة أشجار أدلة (طبقات) بشكل شفاف لتبدو كنظام ملفات واحد. تعتمد طبقات صور Docker على هذه التقنية.

دعونا ننظر في النموذج الرياضي لتقييد الموارد. بفرض أن السعة الإجمالية لذاكرة الجهاز المضيف هي $M_{\text{total}}$، وحد الذاكرة لكل حاوية من الحاويات الـ $n$ التي تعمل على المضيف هو $m_i$. فإن الشرط الضروري لعمل النظام باستقرار، مع أخذ الذاكرة الأساسية $M_{\text{os}}$ التي يستهلكها نظام التشغيل المضيف والعمليات الأخرى في الاعتبار، يمكن التعبير عنه بالمتراجحة التالية:

$$ \sum_{i=1}^{n} m_i \le M_{\text{total}} - M_{\text{os}} $$

من خلال الاستخدام الصارم لـ Cgroups لتعريف $m_i$ لكل حاوية، يمكننا منع انهيار الحاويات الأخرى أو النظام المضيف بأكمله بواسطة OOM (Out Of Memory) Killer عندما تتسبب حاوية معينة في تسرب للذاكرة.

3. التصميم الفعال لـ Dockerfile: إتقان البناء متعدد الطبقات (Multi-stage Build)

الخطوة الأولى نحو بيئة قابلة لإعادة الإنتاج هي تصميم Dockerfile الذي يحدد بيئة تشغيل التطبيق. هنا، باستخدام Python (FastAPI) كمثال، سنشرح أفضل الممارسات لكتابة Dockerfile آمن وخفيف الوزن بالاستفادة من البناء متعدد الطبقات (Multi-stage Build).

البناء متعدد الطبقات هو تقنية تستخدم تعليمات FROM متعددة داخل Dockerfile واحد لفصل بيئة البناء (التي تحتوي على بيئة ثقيلة مثل المترجمات وأدوات التطوير) عن بيئة التشغيل (بيئة خفيفة الوزن تحتوي فقط على المخرجات الضرورية).

مثال عملي لـ Dockerfile لتطبيق Python FastAPI

الكود أدناه هو مثال متقدم لـ Dockerfile يجمع بين إدارة الاعتماديات باستخدام Poetry والبناء متعدد الطبقات.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52


# ---------------------------------------------------------
# Stage 1: Builder (بيئة البناء)
# ---------------------------------------------------------
FROM python:3.11-slim AS builder

# إعداد متغيرات البيئة الضرورية
ENV PYTHONUNBUFFERED=1 \
 PYTHONDONTWRITEBYTECODE=1 \
 POETRY_VERSION=1.6.1 \
 POETRY_HOME="/opt/poetry" \
 POETRY_VIRTUALENVS_IN_PROJECT=true \
 POETRY_NO_INTERACTION=1

# تثبيت الحزم المعتمدة
RUN apt-get update && apt-get install -y --no-install-recommends \
 curl build-essential && \
 curl -sSL https://install.python-poetry.org | python3 - && \
 apt-get clean && rm -rf /var/lib/apt/lists/*

ENV PATH="$POETRY_HOME/bin:$PATH"

WORKDIR /app

# نسخ ملفات الاعتماديات وتثبيتها
COPY pyproject.toml poetry.lock ./
RUN poetry install --no-root --only main

# ---------------------------------------------------------
# Stage 2: Runtime (بيئة التشغيل)
# ---------------------------------------------------------
FROM python:3.11-slim AS runtime

ENV PYTHONUNBUFFERED=1 \
 PYTHONDONTWRITEBYTECODE=1 \
 PATH="/app/.venv/bin:$PATH"

# إنشاء مستخدم غير متميز بحد أدنى من الصلاحيات
RUN groupadd -r appuser && useradd -r -g appuser appuser

WORKDIR /app

# نسخ البيئة الافتراضية (الاعتماديات) فقط من بيئة البناء
COPY --from=builder --chown=appuser:appuser /app/.venv /app/.venv

# نسخ كود التطبيق
COPY --chown=appuser:appuser ./src /app/src

# التبديل إلى المستخدم غير المتميز
USER appuser

# الأمر الافتراضي عند تشغيل الحاوية
ENTRYPOINT ["uvicorn", "src.main:app", "--host", "0.0.0.0", "--port", "8000"]

التقييم الرياضي لحجم الصورة بسبب البناء متعدد الطبقات

لنفترض أن حجم الصورة عند بنائها في مرحلة واحدة هو $S_{\text{single}}$، وحجم الصورة عند تطبيق البناء متعدد الطبقات هو $S_{\text{multi}}$. يتم حساب معدل تقليل الحجم $R$ على النحو التالي:

$$ R = \left( 1 - \frac{S_{\text{multi}}}{S_{\text{single}}} \right) \times 100 \ (\%) $$

على سبيل المثال، لنفترض أن $S_{\text{single}}$ يحتوي على الصورة الأساسية لنظام التشغيل (حوالي 110 ميجابايت)، وحزم التطوير (مثل gcc حوالي 150 ميجابايت)، وبرنامج Poetry (حوالي 40 ميجابايت)، والمكتبات المعتمدة للمشروع (حوالي 80 ميجابايت)، والكود المصدري (حوالي 5 ميجابايت)، ليصبح المجموع 385 ميجابايت. في المقابل، في $S_{\text{multi}}$، يتم نسخ المكتبات المعتمدة (80 ميجابايت) والكود المصدري (5 ميجابايت) فقط إلى الصورة الأساسية (110 ميجابايت)، ليصبح المجموع 195 ميجابايت.

$$ R = \left( 1 - \frac{195}{385} \right) \times 100 \approx 49.35\% $$

بهذه الطريقة، من خلال اعتماد البناء متعدد الطبقات، يمكن تقليل حجم الصورة إلى النصف تقريباً. هذا الانخفاض في الحجم يؤدي مباشرة إلى تسريع وقت السحب (Pull) من السجل (Registry)، وتوفير مساحة القرص، وتحسين الأمان من خلال تقليص مساحة الهجوم (Attack Surface).

4. تنسيق حاويات متعددة باستخدام Docker Compose

في تطوير تطبيقات الويب الحديثة، من الشائع استخدام بنية الخدمات المصغرة (Microservices Architecture) حيث تتعاون مكونات متعددة مثل خوادم الويب، وقواعد البيانات، وخوادم التخزين المؤقت (Cache). نستخدم docker-compose.yml لإدارة هذه المكونات بشكل مركزي في البيئة المحلية.

في هذا المثال، سنقوم ببناء نظام محلي يتكون من 3 طبقات: “الويب (FastAPI)"، و “قاعدة البيانات (PostgreSQL)"، و “التخزين المؤقت (Redis)”.

مخطط البنية (Mermaid)

يوضح المخطط التالي العلاقة بين الحاويات، والشبكة، ووحدات التخزين (Volumes) على الجهاز المحلي.

graph TD
User["الجهاز المضيف (المتصفح/curl)"] -->|Localhost:8000| Web["حاوية FastAPI للويب"]
subgraph "شبكة Docker Bridge (app-network)"
Web -->|Port 5432| DB["حاوية PostgreSQL"]
Web -->|Port 6379| Redis["حاوية Redis"]
end
DB --> Volume1["وحدة تخزين مسماة (postgres_data)"]
Redis --> Volume2["وحدة تخزين مسماة (redis_data)"]
HostDir["كود المصدر في المضيف (./src)"] -.->|Bind Mount| Web

تنفيذ وشرح تفصيلي لـ docker-compose.yml

فيما يلي مثال على docker-compose.yml متين وقابل للاستخدام في بيئات التطوير العملية.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63


version: '3.8'

services:
 web:
 build:
 context: .
 target: runtime
 container_name: dev_web
 ports:
 - "8000:8000"
 volumes:
 - ./src:/app/src:ro  # تركيب كود المضيف بصلاحية القراءة فقط (لإعادة التحميل السريع)
 environment:
 - DATABASE_URL=postgresql://postgres:${POSTGRES_PASSWORD}@db:5432/${POSTGRES_DB}
 - REDIS_URL=redis://redis:6379/0
 env_file:
 - .env
 depends_on:
 db:
 condition: service_healthy
 redis:
 condition: service_started
 networks:
 - app-network
 command: ["uvicorn", "src.main:app", "--host", "0.0.0.0", "--port", "8000", "--reload"]

 db:
 image: postgres:15-alpine
 container_name: dev_db
 ports:
 - "5432:5432"
 environment:
 POSTGRES_USER: postgres
 POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
 POSTGRES_DB: ${POSTGRES_DB}
 volumes:
 - postgres_data:/var/lib/postgresql/data
 networks:
 - app-network
 healthcheck:
 test: ["CMD-SHELL", "pg_isready -U postgres -d ${POSTGRES_DB}"]
 interval: 5s
 timeout: 5s
 retries: 5

 redis:
 image: redis:7-alpine
 container_name: dev_redis
 ports:
 - "6379:6379"
 volumes:
 - redis_data:/data
 networks:
 - app-network
 command: ["redis-server", "--appendonly", "yes"]

volumes:
 postgres_data:
 redis_data:

networks:
 app-network:
 driver: bridge

وحدات التخزين (Volumes) والاحتفاظ بالبيانات

تعتبر الحاويات من حيث المبدأ “عديمة الحالة (Stateless)” و “قصيرة العمر (Ephemeral)”. عند تدمير الحاوية، تضيع البيانات الموجودة بداخلها. للحفاظ على بيانات قاعدة البيانات أو التخزين المؤقت، يجب تركيب (Mount) مساحة من نظام ملفات الجهاز المضيف داخل الحاوية.

تركيب الربط (Bind Mount): يندرج تحت ذلك ./src:/app/src:ro في خدمة web المذكورة أعلاه. يقوم بتعيين دليل معين على المضيف مباشرة داخل الحاوية. يُستخدم لعكس تعديلات الكود المحلية على الفور في الحاوية (إعادة التحميل السريع). من منظور الأمان، يُعتبر إضافة خيار :ro (Read-Only) ممارسة مثلى لمنع الحاوية من تعديل كود المصدر الموجود على المضيف.
وحدة التخزين المسماة (Named Volume): يندرج تحت ذلك postgres_data و redis_data. هي مساحات تديرها Docker داخلياً (مثل /var/lib/docker/volumes/)، وتتميز بأداء إدخال/إخراج أفضل من تركيب الربط، وتستوعب اختلافات نظام الملفات بين أنظمة التشغيل المختلفة. يجب استخدامها دائماً لحفظ بيانات قواعد البيانات.

الشبكات (Networking) واكتشاف الخدمات

بشكل افتراضي، يقوم Docker Compose بإنشاء شبكة Bridge خاصة لكل مشروع. هذه هي app-network المذكورة أعلاه. يمكن للحاويات التي تنتمي إلى نفس الشبكة تحليل الأسماء (DNS Resolution) لبعضها البعض باستخدام “اسم الخدمة (مثل: db, redis)” كاسم مضيف بدلاً من عنوان IP. على سبيل المثال، من حاوية الويب، يمكن الوصول إلى قاعدة البيانات باستخدام عنوان URL postgresql://postgres:password@db:5432/mydb. يتيح ذلك التبديل السلس لوجهة الاتصال بين البيئة المحلية وبيئة الإنتاج باستخدام متغيرات البيئة دون تعديل كود البنية التحتية.

فحص الصحة (Healthcheck) والتحكم في ترتيب بدء التشغيل

يتحكم توجيه depends_on في ترتيب بدء تشغيل الحاويات، ولكن بمجرد تحديد depends_on فقط، ستبدأ حاوية الويب بمجرد “بدء تشغيل” حاوية قاعدة البيانات. في الواقع، قد تستغرق عملية تهيئة قاعدة البيانات (بدء عملية PostgreSQL وتجهيز الجداول) بضع ثوانٍ، مما قد يؤدي إلى حدوث خطأ عند محاولة حاوية الويب الاتصال بها. لتجنب ذلك، يمكن تعريف healthcheck واستخدام condition: service_healthy، مما يسمح بالتأكد من “استعداد قاعدة البيانات لاستقبال طلبات الاتصال” قبل بدء تشغيل حاوية الويب.

5. إدارة متغيرات البيئة والأمان (.env)

يعتبر تشفير المعلومات الحساسة مثل كلمات مرور قاعدة البيانات ومفاتيح API برمجياً (Hardcoding) داخل docker-compose.yml ممارسة سيئة يجب تجنبها تماماً. بدلاً من ذلك، نستخدم ملف متغيرات البيئة .env لحقن هذه القيم.

قم بإنشاء ملف .env في جذر المشروع.

1
2
3
4


# ملف .env (يجب إضافته إلى .gitignore لاستبعاده من إدارة Git)
POSTGRES_PASSWORD=supersecretpassword
POSTGRES_DB=devdb
API_SECRET_KEY=dev_secret_key_12345

بشكل افتراضي، يقرأ Docker Compose ملف .env الموجود في دليل التنفيذ، ويستبدل العناصر النائبة بالشكل ${VAR_NAME} في ملف YAML. تتيح هذه الطريقة إدارة إعدادات مختلفة للبيئات المتعددة مثل البيئة المحلية، وبيئة الاختبار (Staging)، وبيئة الإنتاج (Production) بشكل آمن دون تغيير كود البنية التحتية.

6. تجربة التطوير القصوى باستخدام VSCode DevContainers

حتى الآن، قمنا ببناء بيئة خلفية (Backend) متينة باستخدام Docker. ولكن يمكننا اتخاذ خطوة أبعد من ذلك. من خلال استخدام ميزة VSCode DevContainers (Remote - Containers)، يصبح من الممكن تشغيل الواجهة الخلفية للمحرر (VSCode) نفسه داخل الحاوية.

بهذا، لم يعد من الضروري تثبيت Python أو Node.js على الجهاز المحلي، ويمكن تحديد كل شيء بدءاً من أدوات الفحص (Linter مثل flake8/eslint) وأدوات التنسيق (Formatter مثل black/prettier) وصولاً إلى إضافات بيئة التطوير المتكاملة (IDE) داخل قاعدة الكود لمشاركتها مع جميع أعضاء الفريق.

إعداد devcontainer.json

قم بإنشاء دليل .devcontainer في جذر المشروع، وضع بداخله ملف التكوين.

.devcontainer/devcontainer.json:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


{
 "name": "Python FastAPI Dev Environment",
 "dockerComposeFile": ["../docker-compose.yml"],
 "service": "web",
 "workspaceFolder": "/app",
 "customizations": {
 "vscode": {
 "settings": {
 "python.defaultInterpreterPath": "/app/.venv/bin/python",
 "python.formatting.provider": "black",
 "editor.formatOnSave": true
 },
 "extensions": [
 "ms-python.python",
 "ms-python.vscode-pylance",
 "ms-python.black-formatter",
 "tamasfe.even-better-toml"
 ]
 }
 },
 "forwardPorts": [8000, 5432, 6379],
 "remoteUser": "appuser",
 "postCreateCommand": "poetry install"
}

بمجرد تضمين هذا الملف في المستودع، عند فتح المشروع في VSCode، ستظهر رسالة “Reopen in Container”. وبنقرة واحدة، سيتم تشغيل جميع الحاويات اللازمة، وتثبيت الإضافات، لتكون جاهزاً لبدء البرمجة على الفور. إنها تجربة سحرية حقاً.

7. تسلسل معالجة الطلبات ونمذجة الأداء

سنراجع دورة حياة معالجة الطلب لتطبيق الويب في بيئة التطوير المحلية المبنية من خلال مخطط التسلسل (Sequence Diagram)، وسنحلل النموذج الرياضي لأدائها.

مخطط التسلسل (تدفق الطلب)

sequenceDiagram
participant Client as "المتصفح / VSCode"
participant Web as "FastAPI (ويب)"
participant Redis as "تخزين Redis المؤقت"
participant DB as "PostgreSQL"
Client->>Web: "GET /api/users/123"
activate Web
Web->>Redis: "التحقق من التخزين المؤقت للمستخدم:123"
activate Redis
alt "إصابة التخزين المؤقت Cache Hit (البيانات موجودة)"
Redis-->>Web: "إرجاع بيانات المستخدم المخزنة"
Web-->>Client: "200 OK (استجابة سريعة)"
else "خطأ التخزين المؤقت Cache Miss (البيانات غير موجودة)"
Redis-->>Web: "فارغ Null (غير موجود)"
deactivate Redis
Web->>DB: "SELECT * FROM users WHERE id = 123"
activate DB
DB-->>Web: "إرجاع صف من قاعدة البيانات"
deactivate DB
Web->>Redis: "تعيين بيانات user:123 (فترة الصلاحية TTL: 60 ثانية)"
activate Redis
Redis-->>Web: "موافق OK"
deactivate Redis
Web-->>Client: "200 OK (استجابة قياسية)"
end
deactivate Web

النموذج الرياضي لتأخير المعالجة (Latency)

سنقوم بنمذجة متوسط وقت معالجة الطلب $T_{\text{total}}$ رياضياً في النظام المذكور أعلاه. نعرّف تأخير (Latency) كل عملية على النحو التالي:

$T_{\text{net}}$: تأخير الشبكة بين العميل وحاوية الويب
$T_{\text{app}}$: وقت المعالجة الخالص من جانب التطبيق (مثل التسلسل Serialization)
$T_{\text{cache}}$: الوقت المستغرق في القراءة/الكتابة من وإلى Redis
$T_{\text{db}}$: الوقت المستغرق لتنفيذ الاستعلام على PostgreSQL
$p_{\text{miss}}$: معدل فشل التخزين المؤقت (Cache Miss Rate) ($0 \le p_{\text{miss}} \le 1$)

عندئذٍ، يتم تمثيل متوسط وقت الاستجابة من خلال معادلة القيمة المتوقعة التالية:

$$ T_{\text{total}} = T_{\text{net}} + T_{\text{app}} + T_{\text{cache}} + p_{\text{miss}} \times (T_{\text{db}} + T_{\text{cache\_write}}) $$

في بيئة التطوير المحلية (داخل Docker)، يكون $T_{\text{net}}$ قريباً جداً من 0، ولكن ما يستحق الانتباه هو أداء الإدخال/الإخراج (I/O) أثناء تركيب الربط (Bind Mount). خاصة عند استخدام Docker Desktop على أنظمة Windows أو macOS، يميل $T_{\text{app}}$ (وقت قراءة الكود وما إلى ذلك) إلى التضخم بسبب العبء الإضافي لمشاركة الملفات بين نظام التشغيل المضيف والجهاز الافتراضي (الحاوية). للتغلب على عنق الزجاجة هذا، يوصى بشدة باستخدام DevContainers المذكورة أعلاه لوضع كود المصدر بالكامل داخل وحدة تخزين مسماة (Named Volume)، أو استخدام بنية يعمل فيها محرك Docker أصلياً على بيئة WSL2 (Windows Subsystem for Linux 2).

8. تحسين أداء بناء Docker: استراتيجية التخزين المؤقت للطبقات (Layer Cache)

يتغير وقت البناء بشكل كبير اعتماداً على ما إذا كنت تفهم آلية “التخزين المؤقت للطبقات” عند كتابة Dockerfile. تقوم Docker بإنشاء فرق لنظام الملفات (طبقة) لكل تعليمة في Dockerfile (مثل FROM، و RUN، و COPY)، وتحتفظ بها كنسخة مخبأة. عند إعادة البناء، يتم إعادة استخدام النسخ المخبأة للطبقات التي لم تتغير.

المبدأ الأساسي هو “كتابة التعليمات بالترتيب من الأقل تغييراً إلى الأكثر تغييراً”.

دعونا ننمذج تأثير تغيير كود المصدر على وقت البناء. ليكن إجمالي وقت البناء هو $T_{\text{build}}$، ووقت تنفيذ كل خطوة هو $T_{\text{layer}_i}$، ووجود أو عدم وجود إصابة للنسخة المخبأة (Cache Hit) هو قيمة منطقية $c_i \in \{0, 1\}$ (حيث 1 تعني إصابة النسخة المخبأة).

$$ T_{\text{build}} = T_{\text{init}} + \sum_{i=1}^{n} (1 - c_i) \times T_{\text{layer}_i} $$

بمجرد حدوث خطأ في النسخة المخبأة (Cache Miss) ($c_k = 0$) في الطبقة $k$، يتم إبطال التخزين المؤقت ($c_j = 0$) في جميع الطبقات اللاحقة $j > k$.

1
2
3
4


# مثال سيء (نسخ كود المصدر أولاً)
COPY ./src /app/src
COPY pyproject.toml poetry.lock ./
RUN poetry install

في الحالة أعلاه، يؤدي تعديل سطر واحد فقط من الكود إلى فشل النسخة المخبأة لأمر COPY الأول، مما يتسبب في تنفيذ RUN poetry install الذي يستغرق وقتاً طويلاً في كل مرة.

1
2
3
4


# مثال جيد (حل الاعتماديات أولاً)
COPY pyproject.toml poetry.lock ./
RUN poetry install
COPY ./src /app/src

بكتابتها بهذه الطريقة، حتى لو قمت بتغيير كود المصدر، يظل التخزين المؤقت لطبقة poetry install فعالاً ($c_i = 1$)، مما يقلل وقت البناء بشكل كبير من عدة دقائق إلى بضع ثوانٍ.

9. استكشاف الأخطاء وإصلاحها ونصائح (Tips)

فيما يلي بعض المشاكل الشائعة والحلول عند تشغيل البيئة المحلية.

خطأ تعارض المنافذ إذا ظهر خطأ مثل Bind for 0.0.0.0:8000 failed: port is already allocated، فهذا يعني أن عملية أخرى على الجهاز المحلي تستخدم هذا المنفذ. يمكن تجنب ذلك بتغيير رقم المنفذ على الجانب المضيف إلى شيء مثل ports: - "8080:8000".
نفاد مساحة القرص مع استخدام Docker لفترات طويلة، تتراكم الصور ووحدات التخزين غير المستخدمة (Dangling Images / Volumes)، مما قد يستهلك عشرات الجيجابايت من مساحة القرص. يُنصح بتنظيف النظام دورياً باستخدام الأمر التالي.
1

docker system prune -a --volumes
مشكلة صلاحيات الملفات عند استخدام تركيب الربط (Bind Mount) في بيئة Linux، قد يصبح المالك (Owner) للملفات المنشأة داخل الحاوية هو root، مما يمنع تحريرها من الجانب المضيف. يمكن حل هذه المشكلة عن طريق إنشاء مستخدم غير متميز داخل Dockerfile ومطابقة المعرف الخاص به (UID/GID) (مثل 1000:1000) مع الخاص بنظام التشغيل المضيف.

10. الخاتمة: كيف يساهم التكرار وقابلية إعادة الإنتاج في تحسين سرعة التطوير

من خلال الجمع بين Docker، و Docker Compose، و VSCode DevContainers، يمكننا تحقيق بيئة تطوير محلية قوية “تكون متطابقة تماماً بغض النظر عمن يقوم بإعدادها”.

إن جلب نموذج IaC إلى البيئة المحلية لا يقتصر فقط على تقليل وقت الإعداد الأولي؛ بل يزيل القلق بشأن تغييرات إعدادات البنية التحتية، ويسهل تجربة تقنيات جديدة، ويتيح الانتقال السلس إلى خطوط أنابيب التكامل المستمر والتسليم المستمر (CI/CD)، مما يؤدي إلى تحسين سرعة وجودة دورة التطوير بأكملها بشكل كبير.

ندعوك لتطبيق أفضل الممارسات التي شرحناها في هذا المقال، مثل تحسين حجم الصورة باستخدام البناء متعدد الطبقات، والتحكم في الاعتماديات من خلال فحوصات الصحة، وكتابة Dockerfile مع مراعاة التخزين المؤقت للطبقات، لتوفير أفضل تجربة تطوير (DX: Developer Experience) في مشاريعك الخاصة.

الدليل الشامل لإعداد بيئة التطوير لنظام WSL2 (نظام ويندوز الفرعي لنظام لينكس)

Sat, 12 Sep 2026 23:00:00 +0900

يوفر “WSL2” (نظام ويندوز الفرعي لنظام لينكس 2)، والذي يقدم بيئة تطوير أصلية للينكس على ويندوز، أداة لا غنى عنها في تطوير البرمجيات الحديثة. ومع ذلك، هناك فرق شاسع في الأداء وتجربة التطوير بين الاستمرار في استخدامه في حالته الافتراضية، وبين فهم بنيته المعمارية وإجراء الضبط المناسب.

في هذه المقالة، سنشرح بالتفصيل الشامل (بأكثر من 10,000 حرف) جميع الخطوات اللازمة لبناء “بيئة التطوير المطلوبة (المثالية)” التي يبحث عنها المهندسون المحترفون. بدءًا من شرح البنية المعمارية التي تشكل أساس WSL2، وصولاً إلى الإعدادات اللازمة لاستخراج أقصى أداء، وبناء بيئة طرفية (Terminal) مريحة، والتكامل السلس مع Docker و VS Code، وإعدادات الشبكة المتقدمة.

1. بنية WSL2 وتطورها عن WSL1

لاستخراج كامل إمكانات WSL2، من المهم أولاً فهم بنيته الداخلية. تختلف المقاربة المستخدمة لتشغيل ثنائيات لينكس على ويندوز بشكل جذري بين الإصدار الأول (WSL1) و WSL2.

WSL1: طبقة ترجمة استدعاءات النظام (System Calls)

اعتمد WSL1 على آلية تترجم استدعاءات نظام لينكس إلى واجهة برمجة تطبيقات ويندوز (NT API) في الوقت الفعلي (Real-time). وبما أن هذا لم يستخدم جهازًا افتراضيًا (VM)، كان يتمتع بميزة أن العبء على الموارد كان ضئيلًا جدًا. ومع ذلك، كان من الصعب محاكاة استدعاءات النظام المعقدة بشكل كامل، مثل عمليات الإدخال والإخراج (I/O) لنظام الملفات، مما أدى إلى انخفاض مروع في الأداء، خاصة في العمليات التي تتعامل مع عدد كبير من الملفات الصغيرة، مثل npm install في Node.js أو عمليات مستودع Git.

WSL2: جهاز افتراضي (VM) للمرافق خفيف الوزن ونواة لينكس كاملة

في WSL2، تم تجديد البنية المعمارية، وأصبحت نواة لينكس حقيقية، تم بناؤها بواسطة Microsoft، تعمل مباشرة على “جهاز افتراضي للمرافق خفيف الوزن” يستخدم مجموعة فرعية من بنية Hyper-V. هذا يضمن توافقًا بنسبة 100% مع استدعاءات النظام، ومن خلال استخدام قرص افتراضي (VHDX) يستخدم نظام ملفات ext4 الأصلي للينكس، تم تحسين أداء إدخال/إخراج الملفات بشكل كبير مقارنة بـ WSL1.

يوضح مخطط Mermaid التالي الاختلافات الهيكلية بين WSL1 و WSL2.

flowchart TD
subgraph "بيئة نظام تشغيل ويندوز"
A["نواة Windows NT"]
A --> F["نظام ملفات NTFS (محرك C:)"]
end
subgraph "بنية WSL2"
B["مراقب الأجهزة الافتراضية Hyper-V"]
B --> C["جهاز افتراضي (VM) للمرافق خفيف الوزن"]
C --> D["نواة لينكس (Microsoft)"]
D --> E["مساحة مستخدم Ubuntu (glibc, bash, إلخ)"]
D --> G["قرص افتراضي ext4 (.vhdx)"]
end
A -.->|"مشاركة ملفات شبكة بروتوكول Plan 9 (9P)"| D
style B fill:#f9f,stroke:#333,stroke-width:2px
style D fill:#bbf,stroke:#333,stroke-width:2px

الدرس المهم المستفاد من هذا الهيكل هو أن “الوصول إلى الملفات الموجودة على جانب لينكس (داخل VHDX) سريع للغاية، ولكن الوصول إلى الملفات الموجودة على جانب ويندوز (/mnt/c/) بطيء جدًا لأنه يمر عبر بروتوكول 9P”. يجب وضع الشيفرة المصدرية (Source code) للمشروع دائمًا ضمن الدليل الرئيسي (~) على جانب WSL.

2. التحليل الرياضي للأداء: لماذا يعتبر WSL2 سريعًا؟

دعونا نقيم تحسين أداء WSL2 بشكل كمي باستخدام نموذج رياضي. في تطوير البرمجيات، واحدة من أكثر العمليات استهلاكًا للوقت هي تلك التي تتضمن عمليات إدخال/إخراج (I/O) لعدد كبير من الملفات (مثل: تثبيت المكتبات أو البناء).

يتم التعبير عن وقت التنفيذ الإجمالي للعملية $T_{total}$ بمجموع وقت الحوسبة بواسطة وحدة المعالجة المركزية $T_{compute}$ ووقت إدخال/إخراج القرص $T_{io}$.

$$ T_{total} = T_{compute} + T_{io} $$

في حالة WSL1، يتم تكبد عبء لتحويل عمليات جانب لينكس إلى عمليات NTFS، لذلك يتم نمذجة وقت الإدخال/الإخراج على النحو التالي. هنا، $n$ هو عدد عمليات الملفات، و $t_{ntfs\_syscall}$ هو وقت تنفيذ استدعاء النظام على جانب ويندوز، و $t_{trans}$ هو عبء طبقة الترجمة.

$$ T_{wsl1\_io} = \sum_{i=1}^{n} (t_{ntfs\_syscall_i} + t_{trans_i}) $$

من ناحية أخرى، في حالة WSL2، تُصدر النواة (Kernel) عمليات الإدخال/الإخراج مباشرة إلى نظام ملفات ext4، لذلك يكون العبء عبارة عن تأخير طفيف جداً بسبب المحاكاة الافتراضية $t_{virt}$ فقط.

$$ T_{wsl2\_io} = \sum_{i=1}^{n} (t_{ext4_i} + t_{virt_i}) $$

في أنظمة الملفات العامة، بما أن $t_{ext4} \ll t_{ntfs\_syscall} + t_{trans}$، فإنه عندما يكون $n$ كبيرًا جدًا (إجراء عشرات الآلاف إلى مئات الآلاف من عمليات الملفات)، يتسع الفارق في وقت الإدخال/الإخراج بين WSL1 و WSL2 بشكل أُسّي.

بالإضافة إلى ذلك، إذا كانت نسبة عبء حساب وحدة المعالجة المركزية (CPU) في البيئة الافتراضية هي $\rho$، فإن المحاكاة الافتراضية الحديثة المدعومة بالأجهزة (Intel VT-x / AMD-V) ستبقيها عند حوالي $\rho \approx 0.01 \sim 0.03$ (1 إلى 3٪). وبالتالي، حتى في مهام الحساب البحتة، يتم تحقيق أداء بنسبة $97\% \sim 99\%$، وهو ما يمكن مقارنته ببيئة لينكس الأصلية (Native).

3. التثبيت وبناء الأساس

على أنظمة التشغيل Windows 10/11، أصبح تثبيت WSL2 بسيطًا للغاية. افتح PowerShell بصلاحيات المسؤول وقم بتنفيذ الأمر التالي.

1
2
3
4
5
6


# سيتم تثبيت WSL2 و Ubuntu بشكل افتراضي
wsl --install

# لتحديد توزيعة معينة
# يمكن التحقق منها باستخدام wsl --list --online
wsl --install -d Ubuntu-24.04

بعد التثبيت وإعادة التشغيل، سيُطلب منك إعداد اسم مستخدم UNIX وكلمة مرور عند بدء التشغيل لأول مرة. هذا المستخدم مستقل عن مستخدم ويندوز ويكون صالحًا فقط داخل WSL.

إذا كنت تستخدم WSL1 بالفعل، فقم بالتحويل إلى WSL2 باستخدام الأوامر التالية.

1
2
3
4
5


# تحويل توزيعة موجودة إلى WSL2
wsl --set-version Ubuntu 2

# تعيين WSL2 كإصدار افتراضي للتوزيعات التي ستضاف مستقبلاً
wsl --set-default-version 2

4. أسرار التحكم في الموارد: .wslconfig و wsl.conf

أحد أكبر فخاخ WSL2 هو “الاستهلاك غير المحدود للذاكرة (تضخم عملية Vmmem)”. نظرًا لأن WSL2 يستخدم ذاكرة التخزين المؤقت للصفحات (Page cache) الخاصة بنواة لينكس، فإنه سيستهلك ذاكرة المضيف (ويندوز) بلا حدود في كل مرة يتم فيها إجراء إدخال/إخراج (I/O). لمنع ذلك، من الضروري تقييد الموارد باستخدام ملفات الإعدادات.

تنقسم ملفات إعدادات WSL2 إلى قسمين: .wslconfig الذي يؤثر على نظام ويندوز بأكمله، و wsl.conf الذي يؤثر على التوزيعة الفردية من الداخل.

4.1. .wslconfig (جانب ويندوز)

قم بإنشاء ملف في مجلد ملف تعريف مستخدم ويندوز الخاص بك (C:\Users\<اسم المستخدم>\.wslconfig) للتحكم في تخصيص الموارد للجهاز الافتراضي (VM).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


# C:\Users\<اسم المستخدم>\.wslconfig
[wsl2]
# أقصى قدر من الذاكرة المخصصة للجهاز الافتراضي. يوصى بنسبة 50% إلى 75% من إجمالي ذاكرة المضيف
memory=16GB

# عدد نوى وحدة المعالجة المركزية (CPU) المراد استخدامها (إذا تم حذفها، يتم استخدام جميع النوى)
processors=8

# حجم ملف التبادل (Swap file)
swap=8GB

# وجهة حفظ ملف التبادل (إذا كنت ترغب في توفير مساحة على محرك الأقراص C)
# swapfile=D:\\wsl\\swap.vhdx

# تمكين إعادة توجيه localhost (للوصول إلى WSL من جانب ويندوز باستخدام localhost)
localhostForwarding=true

# تحرير الذاكرة تلقائيًا (نظام التشغيل Windows 11 فقط)
# يحرر ذاكرة التخزين المؤقت للصفحات ديناميكيًا ويمنع تضخم Vmmem
autoMemoryReclaim=dropcache

[experimental]
# ميزات الشبكات المتقدمة المتاحة في Windows 11 إصدار 22H2 وما بعده
# يتيح هذا دعم IPv6 ومشاركة نفس عنوان IP بين WSL وويندوز
networkingMode=mirrored
dnsTunneling=true
firewall=true
autoProxy=true

4.2. wsl.conf (جانب لينكس)

قم بتحرير /etc/wsl.conf داخل WSL للتحكم في السلوك الخاص بالتوزيعة.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


# /etc/wsl.conf (تم التحرير داخل WSL)
[network]
# تعطيل إنشاء ملف /etc/resolv.conf التلقائي عند بدء تشغيل WSL
# مفيد عندما تريد إعداد DNS خاص بك (مثال: 8.8.8.8)
generateResolvConf=false

# تعيين اسم مضيف (hostname) مخصص
hostname=WSL-DevNode

[automount]
# الإعدادات عند تركيب محركات أقراص ويندوز (Mounting)
enabled=true
options="metadata,uid=1000,gid=1000,umask=022"
# تغيير نقطة تركيب محرك الأقراص C من /mnt/c إلى /c (لتقصير المسار)
root=/

[boot]
# تمكين systemd (في WSL إصدار 0.67.6 وما بعده)
# يتيح هذا لـ snap والبرامج الخفية (daemons) المتنوعة (مثل Docker) العمل محليًا
systemd=true

[user]
# المستخدم الذي سيتم تسجيل الدخول به افتراضيًا
default=kenji

لتطبيق هذه الإعدادات، تحتاج إلى تشغيل wsl --shutdown في PowerShell لإيقاف تشغيل جهاز WSL الافتراضي بالكامل قبل إعادة تشغيله.

5. بيئة الطرفية المطلوبة: Zsh + Powerlevel10k

لن تتحسن إنتاجيتك مع بقاء bash الافتراضي. سنقوم ببناء أقوى موجه أوامر (Prompt) من خلال الجمع بين Zsh، الذي يتميز بوظائف إكمال قوية وإمكانيات رؤية واضحة، مع السمة (Theme) فائقة السرعة “Powerlevel10k”.

5.1. تثبيت وإعداد Windows Terminal

قم بتثبيت “Windows Terminal” من متجر Microsoft. افتح إعدادات JSON (settings.json)، واضبط ملف التعريف (Profile) الافتراضي على WSL (Ubuntu)، وقم بتغيير الخط إلى خط Nerd مخصص للتطوير (مثال: HackGen Console NF أو MesloLGS NF).

5.2. تثبيت Zsh و Oh My Zsh

قم بتنفيذ الأوامر التالية في محطة طرفية لـ WSL.

1
2
3
4
5
6


# تحديث الحزم وتثبيت Zsh
sudo apt update && sudo apt upgrade -y
sudo apt install -y zsh git curl

# تنفيذ برنامج نصي (Script) لتثبيت Oh My Zsh
sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

5.3. تقديم Powerlevel10k والإضافات (Plugins)

قم بتثبيت الإضافات لتعزيز Zsh (تسليط الضوء على بناء الجملة والإكمال التلقائي للإدخال) وسمة Powerlevel10k.

1
2
3
4
5
6
7
8


# Powerlevel10k
git clone --depth=1 https://github.com/romkatv/powerlevel10k.git ${ZSH_CUSTOM:-$HOME/.oh-my-zsh/custom}/themes/powerlevel10k

# zsh-autosuggestions
git clone https://github.com/zsh-users/zsh-autosuggestions ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-autosuggestions

# zsh-syntax-highlighting
git clone https://github.com/zsh-users/zsh-syntax-highlighting.git ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-syntax-highlighting

قم بتحرير ~/.zshrc وتمكين السمة والإضافات.

1
2
3
4
5


# التغييرات في ~/.zshrc
ZSH_THEME="powerlevel10k/powerlevel10k"

# أضفه إلى مصفوفة الإضافات (plugins)
plugins=(git zsh-autosuggestions zsh-syntax-highlighting)

عندما تقوم بالحفظ وتشغيل source ~/.zshrc، سيبدأ معالج إعداد Powerlevel10k (p10k configure). اتبع التعليمات التي تظهر على الشاشة لتخصيص موجه الأوامر (Prompt) حسب رغبتك (نمط الموجه، وجود الرموز من عدمها، المعلومات التي سيتم عرضها، إلخ). سيتم عرض أسماء فروع Git وحالتها، وإصدار Node.js، ووقت تنفيذ الأوامر، وما إلى ذلك في الوقت الفعلي، مما يؤدي إلى زيادة كفاءة التطوير بشكل كبير.

6. VS Code Remote - تكامل سلس مع WSL

عند التطوير في WSL2، توفر إضافة “Remote - WSL” آلية للوصول السلس إلى الملفات داخل WSL من بيئة التطوير المتكاملة (Visual Studio Code) المثبتة على جانب ويندوز.

شرح البنية المعمارية

يوضح مخطط التسلسل (Sequence diagram) التالي كيف يتصل VS Code مع WSL2.

sequenceDiagram
autonumber
participant U as "المطور"
participant V as "واجهة مستخدم VS Code (ويندوز)"
participant S as "خادم VS Code (WSL2)"
participant F as "نظام ملفات ext4 (WSL2)"
U->>V: "كتابة `code .` في محطة WSL"
V->>S: "إنشاء اتصال RPC عبر Vsock"
Note over V,S: الاتصال باستخدام مآخذ Hyper-V بدلاً من TCP/IP
S->>F: "قراءة الملفات المصدرية / تشغيل أداة التحقق (Linter)"
F-->>S: "إرجاع البيانات والتحليل"
S-->>V: "بث نتائج خادم اللغة (Language Server) إلى واجهة المستخدم"
V-->>U: "عرض تمييز بناء الجملة (syntax highlighting) والأخطاء"

يعمل VS Code على جانب ويندوز كمجرد “عميل خفيف (واجهة مستخدم)"، وتتم معالجة جميع المهام الثقيلة مثل خادم اللغة (Language Server)، والمصحح (Debugger)، وتنفيذ المحطة الطرفية بواسطة “خادم VS Code” على جانب WSL. يتيح لك ذلك الحفاظ على نظافة البيئة الخاصة بك من خلال استخدام جانب WSL فقط، دون تثبيت Node.js أو Python على جانب ويندوز.

إعدادات VS Code الأساسية

من “الإضافات” (Extensions) في VS Code، قم بتثبيت “WSL” (ms-vscode-remote.remote-wsl). بعد ذلك، ببساطة انتقل إلى دليل المشروع في محطة WSL وقم بتنفيذ code .، وسيتم تشغيل VS Code على جانب ويندوز مع فتح ذلك الدليل.

ملاحظة هامة (مشكلة رمز نهاية السطر (Line Ending)): رموز نهاية السطر تختلف بين ويندوز ولينكس (ويندوز يستخدم CRLF، ولينكس يستخدم LF). عند التطوير على WSL، تأكد من توحيد إعداد core.autocrlf في Git وإعداد الملف الافتراضي في VS Code إلى LF. سيؤدي الفشل في القيام بذلك إلى التسبب في أخطاء غامضة عند تشغيل نصوص الصدفة (Shell scripts) أو حاويات Docker.

1
2


# إعداد رمز نهاية السطر (Line Ending) لـ Git في WSL
git config --global core.autocrlf input

أضف الإعدادات التالية إلى settings.json الخاص بـ VS Code (الإعدادات عن بُعد).

1
2
3
4


{
 "files.eol": "\n",
 "terminal.integrated.defaultProfile.linux": "zsh"
}

7. تحسين Docker Desktop وتكامله مع WSL2

هناك طريقتان رئيسيتان لاستخدام Docker في بيئة WSL2.

تثبيت Docker Desktop لنظام ويندوز وتمكين ميزة تكامل WSL2.
تثبيت محرك Docker الأصلي (Docker Engine) مباشرة داخل WSL2 (مثل Ubuntu).

النهج 1: Docker Desktop (موصى به)

يُوصى بهذا النهج غالبًا لأنه يسهل الإدارة عبر واجهة المستخدم الرسومية (GUI) والوصول الشفاف إلى الحاويات (Containers) بين ويندوز و WSL. تحقق من التالي في إعدادات Docker Desktop (Settings).

في General -> ضع علامة اختيار على Use the WSL 2 based engine.
في Resources -> WSL Integration -> ضع علامة اختيار على Enable integration with my default WSL distro، وقم بتشغيل مفتاح التبديل للتوزيعة التي تستخدمها (Ubuntu).

يسمح لك ذلك بتنفيذ أوامر docker مباشرة من محطة WSL2، ويتم الاتصال ببرنامج Docker الخفي (Daemon) من خلال أجهزة افتراضية خفيفة الوزن مخصصة يديرها Docker Desktop (docker-desktop و docker-desktop-data).

النهج 2: التثبيت المباشر لمحرك Docker الأصلي (Native Docker Engine)

إذا كان هناك قيود على شبكة الشركة (مثل تجنب الإصدار المدفوع من Docker Desktop) أو كنت ترغب في تقليل عبء الأداء إلى أدنى حد ممكن، فقم بتمكين systemd في /etc/wsl.conf وقم بتثبيت Docker كخادم Ubuntu نقي.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


# مقتطف من خطوات التثبيت الرسمية لـ Docker في WSL2 Ubuntu مع تفعيل systemd
sudo apt-get update
sudo apt-get install ca-certificates curl gnupg
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

# إضافة المستودع (Repository)
echo \
 "deb [arch="$(dpkg --print-architecture)" signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
 "$(. /etc/os-release && echo "$VERSION_CODENAME")" stable" | \
 sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

# إضافة المستخدم الحالي إلى مجموعة docker (للتشغيل بدون sudo)
sudo usermod -aG docker $USER

بعد إعادة التشغيل، سيعمل systemctl start docker تمامًا كما هو الحال في بيئة لينكس الأصلية، مما يوفر أداءً عاليًا.

8. تكامل مفاتيح SSH: المصادقة السلسة بين ويندوز و WSL

تعد إدارة مفاتيح SSH المنفصلة على ويندوز و WSL لاستنساخ Git (Git clone) عبر SSH أو الاتصال بخوادم عن بُعد عبر SSH مهمة شاقة جدًا. لتحقيق التوازن بين الأمان والراحة، سنقوم بإعداد جسر (Bridge) لوكيل SSH (SSH Agent) الذي يعمل على جانب ويندوز (أو مدير كلمات مرور مثل 1Password) إلى جانب WSL.

هنا، سنشرح الطريقة الأكثر أمانًا وحداثة باستخدام ميزة وكيل SSH في 1Password أو وكيل مصادقة OpenSSH في ويندوز (OpenSSH Authentication Agent)، وإعادة توجيهها إلى مقبس نطاق UNIX (UNIX domain socket) الخاص بـ WSL2 باستخدام npiperelay أو socat.

إعادة توجيه المقبس (Socket Forwarding) لوكيل ssh-agent

عادة، يجب تحويل وكيل SSH المقدم كأنبوب مسمى (Named Pipe) في ويندوز إلى ملف مقبس (Socket file) على جانب WSL. من السهل استخدام wsl-ssh-agent أو الميزات المقدمة من 1Password.

من شاشة إعدادات 1Password، قم بتمكين “Developer” (المطور) -> “Use SSH agent” (استخدام وكيل SSH). بعد ذلك، أضف الإعدادات التالية إلى ~/.zshrc أو ~/.bashrc على جانب WSL لربط المقبس (Socket bind) تلقائيًا عند تسجيل الدخول.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# إضافة إلى ~/.zshrc (مثال عند استخدام وكيل SSH الخاص بـ 1Password)
export SSH_AUTH_SOCK=$HOME/.ssh/agent.sock
# إذا لم يكن المقبس موجودًا عند بدء تشغيل WSL، أو إذا لم تكن العملية مرتبطة (bind)، فاستخدم socat و npiperelay لإعادة التوجيه (forward)
ALREADY_RUNNING=$(ps -aux | grep "[n]piperelay.exe -ei -s //./pipe/openssh-ssh-agent" | wc -l)
if [ $ALREADY_RUNNING -eq 0 ]; then
 if [ -S $SSH_AUTH_SOCK ]; then
 rm $SSH_AUTH_SOCK
 fi
 # تشغيل socat في الخلفية وتوصيل الأنبوب المسمى (Named Pipe) لجانب ويندوز بمقبس UNIX لجانب WSL
 (setsid socat UNIX-LISTEN:$SSH_AUTH_SOCK,fork EXEC:"npiperelay.exe -ei -s //./pipe/openssh-ssh-agent",nofork &) >/dev/null 2>&1
fi

※يتطلب هذا تثبيت npiperelay.exe وإضافته إلى المسار (Path) على جانب ويندوز مسبقًا.

بمجرد اكتمال هذا الإعداد، عند تشغيل ssh-add -l من محطة WSL، سيتم عرض قائمة بالمفاتيح العامة (Public keys) المسجلة في 1Password أو على جانب ويندوز. يتيح لك هذا اجتياز المصادقة بأمان دون الحاجة إلى نسخ ملفات المفاتيح الخاصة (Private keys) إلى WSL.

9. الصيانة: تحسين (ضغط) ملفات VHDX المتضخمة

أحد أكبر عيوب WSL2 هو أن “حجم ملف القرص الافتراضي على جانب ويندوز (.vhdx) لا يتقلص تلقائيًا حتى لو قمت بحذف صور Docker أو الملفات”. إذا واصلت التطوير لفترة طويلة، سيتضخم ملف ext4.vhdx إلى عشرات أو مئات الجيجابايت.

لتحرير مساحة على القرص، يجب عليك تحسين (Compact) ملف VHDX من جانب ويندوز بانتظام.

أولاً، قم بإيقاف تشغيل WSL بالكامل.
1

wsl --shutdown
افتح PowerShell بصلاحيات المسؤول، وقم بتنفيذ أمر diskpart أدناه، أو أمر Optimize-VHD من وحدة Hyper-V (يمكن استخدام الأخير فقط إذا تم تمكين Hyper-V).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# إذا كانت وحدة Hyper-V متاحة
Optimize-VHD -Path "$env:LOCALAPPDATA\Packages\CanonicalGroupLimited.Ubuntu_79rhkp1fndgsc\LocalState\ext4.vhdx" -Mode Full

# في حالة استخدام diskpart
diskpart
# أدخل بشكل تفاعلي داخل الموجه التالي
DISKPART> select vdisk file="C:\Users\<اسم المستخدم>\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu_79rhkp1fndgsc\LocalState\ext4.vhdx"
DISKPART> attach vdisk readonly
DISKPART> compact vdisk
DISKPART> detach vdisk
DISKPART> exit

من خلال إجراء هذه العملية بانتظام، يمكنك استعادة المساحة المستهلكة بلا داعٍ على محرك الأقراص C.

10. خاتمة

لقد تجاوز WSL2 تمامًا إطار كونه مجرد “لينكس إضافي يعمل على ويندوز”، وتطور ليصبح منصة تطوير قوية لا تقل أهمية عن نظام MacOS أو أجهزة لينكس الأصلية (Native)، بل وربما تتفوق عليها.

من خلال تطبيق جميع الإعدادات الموضحة في هذا الدليل (تحسين الموارد باستخدام .wslconfig، وتحسين المحطة الطرفية (Terminal) باستخدام Zsh + Powerlevel10k، والوصول الشفاف باستخدام VS Code Remote، بالإضافة إلى دمج SSH وصيانة VHDX)، ستحصل على “بيئة تطوير مطلوبة” خالية من التوتر، سريعة، وآمنة.

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