Stop Running Docker Desktop: Offload Your Builds to a VPS Instead

افتح مراقب النشاط أو مدير المهام، وشغّل حاوية صغيرة، ومع ذلك قد يصبح Docker Desktop أعلى شيء ضجيجاً على الجهاز. في مشكلة Docker Desktop في فبراير 2026، أبلغ مستخدم أن com.docker.backend.exe استخدام المعالج صعد إلى 100% بعد تشغيل الحاويات، ثم استمر حتى بعد إيقاف الحاويات.

ثمة خطوة مختلفة: انزع الخفيّة عن حاسوبك المحمول كلياً. أبقِ Docker CLI محلياً فقط، وشغّل Docker Engine على VPS بنظام Linux، ووجّه docker context إليه عبر SSH. أمر docker build لديك لا يتغير. يُنفَّذ البناء ببساطة في مكان آخر، على Linux أصلي بلا طبقة VM، حيث يسحب عرض نطاق الـ VPS الصور الأساسية بدلاً من واي فاي المقهى، وبلا رخصة Docker Desktop تتعقّبها.

هذا هو الإعداد الكامل لذلك المسار: المتطلبات المسبقة، أوامر docker context الدقيقة، وبناءات متعددة المعماريات بمشغّل buildx بعيد، وكيف تحدّد حجم الجهاز، وأين يكون النهج البعيد الخيار الخطأ.

الخلاصة السريعة

• المشكلة: يحمل Docker Desktop معه VM محلية، ويدفع دخل/خرج الملفات عبر طبقة مُحاكاة افتراضية، و يتطلب اشتراكاً مدفوعاً للاستخدام المهني في المؤسسات الأكبر، بما فيها الشركات التي تتجاوز حدود المستوى المجاني في Docker.
• الحل: احذف Docker Desktop. شغّل Docker Engine على VPS بنظام Linux، وأنشئ docker context يشير إليه عبر SSH، فيعمل أمر docker build المحلي لديك على الـ VPS بينما يكتفي CLI لديك بالتنسيق.
• إطار التكلفة: VPS متواضع واحد يحل محل ترخيص لكل مقعد ويمنحك سرعة بناء Linux الأصلي. يمكن لفريق كامل أن يتشارك صندوق بناء واحداً بدلاً من الدفع لكل مطوّر.
• التحفظات الصادقة: يجب أن يكون الـ VPS قابلاً للوصول (لا بناء في طائرة)، وتحتاج إلى انضباط مع .dockerignore كي لا ترفع سياق بناء بحجم غيغابايتات في كل تشغيل.

المتطلبات المسبقة: ما ستحتاجه

قبل الأمر الأول، رتّب هذه الأشياء. لا شيء هنا غريب إن كنت تستخدم Docker يومياً بالفعل.

• A Linux VPS بصلاحية root أو sudo. Ubuntu 22.04/24.04 أو Debian 12/13 كلها تعمل جيداً.
• Docker Engine على الـ VPS. docker context عبر SSH يحتاج إلى Docker Engine 18.09 أو أحدث على المضيف البعيد، وفق توثيق context الخاص بـ Docker..
• Docker CLI 19.03 أو أحدث محلياً. هذا هو العميل الذي يفهم الأمر ذا المستوى الأعلى context الأمر.
• An زوج مفاتيح SSH. مصادقة قائمة على المفتاح فقط: مصادقة كلمة المرور غير مدعومة لـ docker context اتصالات SSH.
• المستخدم المستخدم البعيد في مجموعة docker docker مجموعة، كي يتمكن من التحدث إلى مقبس الخفيّة دون sudo في كل نداء.

ما الذي يكلّفك إياه Docker Desktop فعلاً

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

الذاكرة وعبء الـ VM. لا يزال Docker Desktop يعني VM محلية بنظام Linux. توثيق إعدادات Docker يقول إن Docker Desktop يستطيع تحديد مقدار الذاكرة التي تستخدمها VM الخاصة بـ Docker Desktop، وهذا هو الجزء الصامت من المشكلة: لا يزال هناك VM داخل الحلقة. البصمة الدقيقة تتفاوت بحسب نظام التشغيل والمشروع، لكن أنماط الفشل حقيقية. مشكلة Docker for Windows تُبلّغ أن Docker Desktop يستهلك عدة غيغابايت من RAM دون أي حاوية قيد التشغيل، و مشكلة WSL2 تصف بناءات Docker التي تترك الذاكرة غير محرّرة بعد انتهاء الحاويات. المقصد ليس أن كل جهاز يخمُل عند الرقم نفسه. المقصد أن Docker Desktop يُبقي عبء الـ VM المحلية داخل حلقة تطويرك.

سرعة البناء ودخل/خرج الملفات. عمليات الربط (bind mounts) وعمليات الملفات التي تعبر حدود الـ VM أبطأ من الوصول الأصلي إلى نظام ملفات Linux. توثيق المشكلات المعروفة الخاص بـ Docker يقرّ بتكلفة نظام ملفات المُحاكاة الافتراضية. تُبلّغ معايير المجتمع روتينياً بشيء في حدود 3-10x أبطأ لعمليات الربط عبر طبقة الـ VM. ذلك الرقم الثاني تجربة مجتمع، لا معيار نشره Docker، لكن الاتجاه لا يجادل فيه أحد رأى بناءً يزحف على Mac.

الترخيص. منذ تغيير 2021، يتطلب Docker Desktop اشتراكاً مدفوعاً للشركات التي تتجاوز 250 موظفاً أو تزيد إيراداتها عن 10 ملايين دولار. المستويات الحالية على صفحة تسعير Docker هي Personal ($0) وPro ($11/mo أو $9 سنوياً) وTeam ($16/mo أو $15 سنوياً) وBusiness ($24/mo). ارتفع مستوى Team من $9 إلى $15 سنوياً في ديسمبر 2024، قفزة تحوّل بنداً صامتاً إلى محادثة مع المشتريات، وهو الجزء الذي يوجع فعلاً حين تضربه في ثلاثين مقعداً.

البدائل، وتشعّب المحلي مقابل البعيد

يكاد كل بديل لـ Docker Desktop ستجده يستبدل خفيّة محلية بأخرى محلية. ذلك هو المحور الحقيقي الذي ينبغي ملاحظته: الاختيار الذي يحتار فيه معظم الناس هو بين الأدوات المحلية، بينما التشعّب الأكثر إثارة هو المحلي مقابل البعيد. المسار البعيد وحده هو ما يزيل الـ VM عن جهازك.

إليك المشهد، جنباً إلى جنب.

القليل من هذه يستحق جملة صدق:

• OrbStack يحل فعلاً مشكلة موارد Mac لمطوّر منفرد. يدّعي نحو 300 MB خاملاً وبدء حاويات أسرع حتى 10x (موقع OrbStack)، وكلاهما رقما مورّد، لا معيارين مستقلين. إن كنت مطوّراً على Mac فقط لا يريد إدارة بنية تحتية بعيدة، فإن OrbStack هو الخيار الأفضل، ومستواه التجاري $8/mo (تسعير OrbStack) يهبط دون مستوى Team في Docker Desktop. المأزق: إنه لـ Mac فقط، والترخيص التجاري يعيد بالضبط الشيء الذي كنت تحاول الهرب منه.
• Colima مجاني ويضع CLI أولاً، لكن حوافّه الخشنة "ليس بديلاً مباشراً" موثّقة جيداً، وبعض الفرق تعود إلى Docker Desktop بعد أن تتعثّر هجرة.
• Podman Desktop و Rancher Desktop كلاهما مجاني وعابر للمنصات. لا أحد منهما بديل صامت، وتوافق Podman مع Compose يمر عبر مقبسه المتوافق مع Docker.
• Docker Offload هي خدمة Docker المُدارة الخاصة للبناء/التشغيل عن بُعد، لكنها ليست خروجاً نظيفاً من Docker Desktop. توثيق Docker الحالي يدرجها كخدمة تتطلب Docker Desktop 4.68 أو أحدث، واشتراك Docker Business، واشتراك Docker Offload. تشغّل أحمال العمل على مضيفات سحابية يديرها Docker، لكن كل مستخدم يحصل على جلسة Offload واحدة في كل مرة، وتنتهي الجلسات الخاملة بعد مهلة سماح مدتها 5 دقائق، والبيئة زائلة، لذا تختفي الحاويات والصور والوحدات التخزينية حين تنتهي الجلسة. لا بأس بذلك إن أردت سعة بعيدة مُدارة داخل Docker Desktop. لكنه ليس كباني VPS دائم بذاكرتك المؤقتة وقرصك ووصول root الخاص بك ودون اعتماد على Desktop.

البقاء في مكانك لا يزال منطقياً في حالة واحدة: فرد دون عتبة المجاني وبلا ألم في سرعة البناء لا سبب له لتغيير أي شيء. أما البقية جميعاً فأمامهم تشعّب عليهم أن يسلكوه.

الخلاصة الأساسية للقسم: القرار المهم ليس أي أداة محلية تختار. بل هو ما إذا كنت ستُبقي خفيّة على حاسوبك المحمول أصلاً.

كيف يعمل docker context عبر SSH

لبناء صور Docker على خادم بعيد عبر SSH، شغّل Docker Engine على ذلك الخادم، وأنشئ docker context يشير إليه بـ docker context create name --docker "host=ssh://user@host"، ثم شغّل docker context use name. بعد ذلك يُنفَّذ أمر docker build العادي لديك على المضيف البعيد، ويكتفي CLI المحلي بإرسال التعليمات بينما تقوم الخفيّة بالعمل.

السياق هدف مُسمّى قابل للتبديل لـ Docker CLI. بدلاً من مناورة متغيرات البيئة DOCKER_HOST أو نصب نفق SSH يدوياً في كل مرة، تُعرّف البعيد مرة واحدة وتنتقل إليه كما تغيّر دليلاً. يُنفَّذ البناء بالكامل على المضيف البعيد: سحب الصور الأساسية يستخدم رابط الرفع الخاص بالـ VPS، وتُخزَّن الطبقات مؤقتاً على قرص الـ VPS، ويجري عمل المعالج على أنوية الـ VPS. الخطوتان الوحيدتان الحساستان للكمون هما مصافحة SSH الأولية ورفع سياق البناء لديك. كل ما بعد ذلك بعيد.

إعداد صندوق بناء VPS لديك

الإعداد كله أربعة أوامر قصيرة إضافةً إلى كتلة إعداد SSH. سأعرض الخرج المتوقع حيث يساعدك على تأكيد أن كل خطوة استقرت.

الخطوة 1: أوصِل Docker Engine إلى VPS بنظام Linux. جهّز الجهاز وثبّت Docker Engine (18.09+ على البعيد هو الحد الأدنى لـ context SSH؛ يحتاج CLI المحلي لديك إلى 19.03+). إن كنت تفضّل ألا تشغّل التثبيت بنفسك، فانشر VPS يأتي به بالفعل (المزيد أدناه). يجب أن يكون المستخدم البعيد في مجموعة docker:

sudo usermod -aG docker $USER

# log out and back in for the group change to take effect

الخطوة 2: أعدّ مصادقة مفتاح SSH واسماً مستعاراً في الإعداد. المصادقة القائمة على المفتاح إلزامية. امنح المضيف اسماً مستعاراً قصيراً في ~/.ssh/config كي لا تعيد كتابة الـ IP ومسار المفتاح:

# ~/.ssh/config
Host my-vps
  HostName 1.2.3.4
  User ubuntu
  IdentityFile ~/.ssh/id_ed25519
  IdentitiesOnly yes

الخطوة 3: أنشئ السياق. وجّهه إلى الخفيّة البعيدة عبر SSH. استخدم الصيغة الموسّعة:

docker context create my-vps --docker "host=ssh://[email protected]"

أو باستخدام الاسم المستعار لإعداد SSH من الخطوة 2:

docker context create my-vps --docker "host=ssh://my-vps"

الخطوة 4: تحقّق. اسرد سياقاتك وتحقّق من أن المحرك البعيد يستجيب:

docker context ls

NAME        DESCRIPTION                               DOCKER ENDPOINT
default *   Current DOCKER_HOST based configuration   unix:///var/run/docker.sock
my-vps                                                ssh://my-vps

docker --context=my-vps version

إن طبع ذلك إصدار خادم الخفيّة البعيدة، فإن CLI لديك يتحدث إلى الـ VPS.

الخطوة 5: بدّل وابنِ. اجعل الـ VPS الهدف النشط، ثم ابنِ كالمعتاد:

docker context use my-vps

docker build -t myapp .

ذلك البناء يُنفَّذ على الـ VPS. تفضّل ألا تبدّل عالمياً؟ استهدف أمراً واحداً:

docker --context=my-vps build -t myapp .

أو اضبطه لجلسة الصدفة:

export DOCKER_CONTEXT=my-vps

حين تريد استعادة الخفيّة المحلية لحاسوبك المحمول (إن أبقيت واحدة)، بدّل إلى المنزل:

docker context use default

نصيحة احترافية: انتبه إلى .dockerignoreلديك. يُرفَع سياق البناء إلى المضيف البعيد قبل أن يبدأ البناء. دليل node_modules or .git تائه يعني أنك ترسل غيغابايتات عبر السلك في كل تشغيل، وستشعر أن المسار البعيد أبطأ من المحلي دون أي سبب وجيه. .dockerignore محكم هو الشيء الأكثر تأثيراً في ما إذا كان المسار البعيد يبدو سريعاً: استثنِ التبعيات ومخرجات البناء وبيانات VCS الوصفية، فيصير الرفع خطأ تقريب.

بناءات متعددة المعماريات بمشغّل buildx بعيد

أنشئ باني buildx يشغّل BuildKit داخل حاوية على مضيف Docker البعيد، ثم ابنِ تجاهه:

docker buildx create --name remote-builder \
  --driver docker-container \
  --use \
  ssh://ubuntu@your-vps-ip

docker buildx inspect --bootstrap

docker buildx build \
  --builder remote-builder \
  --platform linux/amd64 \
  -t myapp:latest \
  --load .

المستخدم --load الراية مهمة للاستهلاك المحلي أحادي المنصة: مع مشغّل docker-container driver, لا تظهر الصور المبنية تلقائياً في قائمة صورك المحلية. إن كنت تبني صورة حقيقية متعددة المنصات، فادفعها بدلاً من ذلك إلى registry:

docker buildx build \
  --builder remote-builder \
  --platform linux/amd64,linux/arm64 \
  -t registry.example.com/myapp:latest \
  --push .

ذلك التمييز مهم. يمكن تحميل بناء بعيد أحادي المنصة عائداً إلى مخزن صورك المحلي. عادةً ما تُدفَع صورة متعددة المنصات إلى registry، لأنها قائمة بيان (manifest) بمتغيرات منفصلة لكل معمارية هدف. هذا القسم اختياري: إن كانت كل صورك أحادية المعمارية، فإن إعداد السياق أعلاه هو العمل كله.

تحديد حجم صندوق البناء وتأمينه

سؤالان يقرّران ما إذا كان هذا الصندوق يخدمك جيداً: كم تجعله كبيراً، وكيف تُبقي الخفيّة موصدة. بناءات Docker مقيّدة بالمعالج، لذا منطق تحديد الحجم غالباً عن الأنوية وعن RAM كافية لتجنّب التبديل. منطق الأمان غالباً عن عدم كشف الخفيّة لأحد سواك.

على أي حجم تضبطه

امنحه مواصفات عامة. يمكنك تعيينها على أي شيء يقدّمه مزوّدك.

• الحد الأدنى (مطوّر واحد، بناءات خفيفة): 2 vCPU / 4 GB RAM / ~120 GB NVMe. This is the minimum that works, not what I'd reach for.
• ما سأنشره فعلاً (لمعظم الفرق): 4 vCPU / 8-12 GB RAM / 240-300 GB NVMe. Four vCPUs stop your parallel build steps from serializing, 8-12 GB handles concurrent builds without touching swap, and the NVMe headroom keeps a healthy layer cache.
• فريق أو CI ثقيل: 8 vCPU / 16-24 GB RAM for several developers sharing one box or big multi-stage Dockerfiles.

لأن البناءات مقيّدة بالمعالج، فإن الأنوية عالية التردد (المحسّنة للمعالج) تشتري لك تكراراً أسرع أكثر مما تفعل RAM إضافية بعد عتبة التبديل. خطط GPU غير ذات صلة هنا، لأن بناءات الصور لا تمسّ GPU. واختيار مركز البيانات يؤثر فقط في استجابة SSH وزمن رفع السياق، لا في سرعة البناء: يُنفَّذ البناء على الـ VPS أينما جلست، لذا اختر موقعاً قريباً منك لمصافحة رشيقة وامضِ قُدماً.

تأمين الخفيّة البعيدة

الإعداد أعلاه يفرض السلوك الافتراضي الصحيح مسبقاً: مصادقة مفتاح SSH، ولا منفذ خفيّة مكشوف للشبكة. أبقِه كذلك. في اللحظة التي تكشف فيها BuildKit أو الخفيّة خارج SSH (نقطة نهاية TCP خام، منفذ BuildKit مفتوح)، تصبح هدفاً. نقاش Hacker News حول البناءات البطيئة الذي أثار فكرة الـ VPS البعيد أولاً حذّر أيضاً من هجمات تعدين العملات المشفّرة على نقاط نهاية BuildKit المكشوفة. خفيّة بناء غير مُصادَق عليها على الإنترنت المفتوح هي بوفيه حوسبة مجاني.

نصيحة احترافية: لا تكشف الخفيّة. إن كان SSH وحده كافياً لك (وهو كافٍ لمعظم إعدادات الصندوق الواحد)، فلا تفتح أبداً منفذ TCP للخفيّة . إن كنت تحتاج فعلاً إلى وصول TCP، فضع أمامه TLS متبادلاً (mTLS) كي لا يتصل إلا العملاء الحاملون لشهادة صالحة. SSH وحده أو mTLS: لا يوجد خيار ثالث مقبول لصندوق بناء قابل للوصول من الإنترنت.

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

إن كنت تفضّل تخطّي تثبيت Docker Engine والذهاب مباشرةً إلى docker context create، فإن تطبيق Docker في السوق لدينا ينشر VPS بـ Docker Engine وCompose V2 وbuildx مُعدّة مسبقاً. نقرة واحدة ويصبح الصندوق جاهزاً لـ SSH، فتبدأ الجولة أعلاه من الخطوة 2 بدلاً من الخطوة 1.

الأسئلة الشائعة

هل يمكنني تشغيل بناءات Docker على خادم بعيد واستخدام CLI المحلي لدي؟

نعم. شغّل Docker Engine على المضيف البعيد، وأنشئ docker context يشير إليه عبر SSH، وبدّل إلى ذلك السياق. عندها يُنفَّذ أمر docker build المحلي لديك على الخادم البعيد بينما يكتفي CLI على جهازك بالتنسيق، دون الحاجة إلى أي خفيّة محلية.

ما الفرق بين docker context وDOCKER_HOST؟

A docker context هدف مُسمّى قابل للتبديل ودائم تعرّفه مرة واحدة وتختاره بـ docker context use. DOCKER_HOST متغير بيئة واحد تضبطه وتلغيه يدوياً لكل صدفة. السياق هو البديل الحديث للنهج القديم "نفق زائد متغير بيئة".

هل يعمل docker compose مع سياق بعيد؟

نعم. يحترم Compose V2 سياق Docker النشط، لذا تُنفَّذ أوامر docker compose تجاه المضيف الذي يشير إليه السياق. تُنفَّذ الخدمات وأي بناءات صور على المضيف البعيد، تماماً مثل docker build.

ما هو Docker Offload وهل هو مجاني؟

Docker Offload هي خدمة Docker المُدارة الخاصة للبناء/التشغيل عن بُعد، لنقل عمل الحاويات إلى مضيفات سحابية يديرها Docker مع الحفاظ على سير عمل Docker Desktop. توثيق Docker الحالي يدرجها كخدمة تتطلب Docker Desktop 4.68 أو أحدث، إضافةً إلى اشتراكي Docker Business وDocker Offload، وهي أيضاً قائمة على الجلسات: كل مستخدم يحصل على جلسة Offload واحدة في كل مرة، وتنتهي الجلسات الخاملة بعد مهلة سماح مدتها 5 دقائق، والبيئة البعيدة زائلة.

كيف أمنع Docker Desktop من استخدام هذا القدر من الذاكرة؟

ضبط حدود موارد Docker Desktop لا يفعل سوى تقليص بصمة لا تصل أبداً إلى الصفر، لأن الـ VM لها دائماً أرضية. المسار الذي يزيل تكلفة الذاكرة فعلاً هو إزالة الخفيّة المحلية كلياً: شغّل Docker Engine على VPS واتصل عبر docker context بـ SSH، كي لا يعمل على جهازك سوى CLI.

هل يمكنني فعل هذا بـ Podman بدلاً من ذلك؟

يمكنك. Podman متاح كمحرك متوافق مع Docker، و docker context يمكنه أن يشير إلى مضيف Podman بعيد، لكن ذلك يتطلب أن يكشف Podman مقبسه المتوافق مع Docker عبر SSH. تدفّق الأوامر هو نفسه. الإعداد على الجانب البعيد يختلف.