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

Otwórz Monitor aktywności lub Menedżer zadań, uruchom mały kontener, a Docker Desktop wciąż może stać się najgłośniejszą rzeczą na maszynie. W zgłoszeniu Docker Desktop z lutego 2026 rokuużytkownik zgłosił, że com.docker.backend.exe wspinał się do 100% CPU po uruchomieniu kontenerów, a potem trwał nawet po ich zatrzymaniu.

Jest inny ruch: zdejmij demona z laptopa całkowicie. Trzymaj lokalnie tylko Docker CLI, uruchom Docker Engine na VPS z Linuxem i skieruj docker context na niego przez SSH. Twoje polecenie docker build się nie zmienia. Kompilacja po prostu wykonuje się gdzie indziej, na natywnym Linuksie bez warstwy VM, gdzie pasmo VPS ściąga obrazy bazowe zamiast twojego kawiarnianego Wi-Fi, i bez licencji Docker Desktop do śledzenia.

Oto pełna konfiguracja dla tej ścieżki: wymagania wstępne, dokładne polecenia docker context , kompilacje wieloarchitekturowe ze zdalnym sterownikiem buildx, jak dobrać rozmiar maszyny i gdzie zdalne podejście jest złym wyborem.

TL;DR

• Problem: Docker Desktop wlecze lokalną VM, przepycha wejście-wyjście plików przez warstwę wirtualizacji i wymaga płatnej subskrypcji do profesjonalnego użytku w większych organizacjach, w tym firmach poza limitami darmowego poziomu Dockera.
• Rozwiązanie: usuń Docker Desktop. Uruchom Docker Engine na VPS z Linuxem, utwórz docker context który wskazuje na niego przez SSH, i twoje lokalne polecenie docker build wykonuje się na VPS, podczas gdy twój CLI jedynie orkiestruje.
• Rama kosztowa: jeden skromny VPS zastępuje licencję na stanowisko i daje ci natywną szybkość kompilacji Linuksa. Cały zespół może dzielić jedną maszynę kompilacyjną zamiast płacić za każdego programistę.
• Uczciwe zastrzeżenia: VPS musi być osiągalny (żadnej kompilacji w samolocie), a potrzebujesz dyscypliny z .dockerignore żeby nie przesyłać wielogigabajtowego kontekstu kompilacji przy każdym przebiegu.

Wymagania wstępne: czego będziesz potrzebować

Przed pierwszym poleceniem ustaw to w szeregu. Nic tu egzotycznego, jeśli już używasz Dockera na co dzień.

• A Linux VPS z dostępem root lub sudo. Ubuntu 22.04/24.04 lub Debian 12/13 wszystkie działają dobrze.
• Docker Engine na VPS. docker context przez SSH potrzebuje Docker Engine 18.09 lub nowszego na zdalnym hoście, zgodnie z dokumentacją context Dockera.
• Docker CLI 19.03 lub nowszy lokalnie. To klient, który rozumie polecenie najwyższego poziomu context polecenie.
• An Para kluczy SSH. Tylko uwierzytelnianie kluczem: uwierzytelnianie hasłem nie jest wspierane dla docker context połączeń SSH.
• Zdalny zdalny użytkownik w grupie docker grupa, żeby mógł rozmawiać z gniazdem demona bez sudo przy każdym wywołaniu.

Ile naprawdę kosztuje cię Docker Desktop

Koszty nie są tajemnicą. Lądują w trzech miejscach, a ten, kto tu dotarł szukając, poczuł co najmniej jeden z nich. Nazwanie ich dokładnie jest sednem. Ból już znasz.

Pamięć i narzut VM. Docker Desktop wciąż oznacza lokalną VM z Linuxem. dokumentacja ustawień Dockera mówi, że Docker Desktop może ograniczyć, ile pamięci używa VM Docker Desktop, co jest cichą częścią problemu: w pętli wciąż jest VM. Dokładny ślad zmienia się w zależności od systemu operacyjnego i projektu, ale tryby awarii są realne. zgłoszenie Docker for Windows raportuje, że Docker Desktop zjada wiele gigabajtów RAM bez żadnego działającego kontenera, a zgłoszenie WSL2 opisuje kompilacje Dockera zostawiające niezwolnioną pamięć po zakończeniu kontenerów. Sednem nie jest to, że każda maszyna bezczynnie stoi na tej samej liczbie. Sednem jest to, że Docker Desktop trzyma narzut lokalnej VM wewnątrz twojej pętli developerskiej.

Szybkość kompilacji i wejścia-wyjścia plików. Montowania bind i operacje na plikach przekraczające granicę VM są wolniejsze niż natywny dostęp do systemu plików Linuksa. dokumentacja znanych problemów Dockera uznaje koszt systemu plików wirtualizacji. Benchmarki społeczności rutynowo raportują coś w okolicach 3-10x wolniej dla montowań bind przez warstwę VM. Ta druga liczba to doświadczenie społeczności, a nie benchmark opublikowany przez Dockera, ale kierunku nie kwestionuje nikt, kto widział, jak kompilacja pełznie na Macu.

Licencjonowanie. Od zmiany z 2021 roku Docker Desktop wymaga płatnej subskrypcji dla firm powyżej 250 pracowników lub powyżej 10 mln $ przychodu. Bieżące poziomy na stronie cennika Dockera to Personal ($0), Pro ($11/mo lub $9 rocznie), Team ($16/mo lub $15 rocznie) i Business ($24/mo). Poziom Team wzrósł z $9 do $15 rocznie w grudniu 2024 roku, skok, który zamienia cichą pozycję w rozmowę z zaopatrzeniem, i to jest ta część, która naprawdę piecze, gdy pomnożysz ją przez trzydzieści stanowisk.

Alternatywy i rozwidlenie lokalne kontra zdalne

Niemal każda alternatywa dla Docker Desktop, którą znajdziesz, wymienia jednego lokalnego demona na innego lokalnego demona. To jest prawdziwa oś, którą warto zauważyć: wybór, nad którym większość się męczy, leży między narzędziami lokalnymi, podczas gdy ciekawsze rozwidlenie to lokalne kontra zdalne. Tylko zdalna ścieżka usuwa VM z twojej maszyny.

Oto krajobraz, obok siebie.

Kilka z nich zasługuje na zdanie szczerości:

• OrbStack naprawdę rozwiązuje problem zasobów na Macu dla samotnego programisty. Deklaruje ~300 MB w spoczynku i do 10x szybszy start kontenerów (strona OrbStack), obie liczby to dane dostawcy, a nie niezależne benchmarki. Jeśli jesteś programistą tylko na Macu, który nie chce zarządzać zdalną infrastrukturą, OrbStack to lepszy wybór, a jego komercyjny poziom $8/mo (cennik OrbStack) schodzi poniżej poziomu Team Docker Desktop. Haczyk: jest tylko na Maca, a licencja komercyjna przywraca dokładnie to, przed czym próbowałeś uciec.
• Colima jest darmowy i stawia CLI na pierwszym miejscu, ale jego chropowatości „nie bezpośredni zamiennik” są dobrze udokumentowane, i niektóre zespoły lądują z powrotem na Docker Desktop po tym, jak migracja utknie.
• Podman Desktop oraz Rancher Desktop oba są darmowe i wieloplatformowe. Żaden nie jest cichym zamiennikiem, a zgodność Podmana z Compose idzie przez jego gniazdo zgodne z Dockerem.
• Docker Offload to własna zarządzana usługa Dockera do zdalnej kompilacji/uruchamiania, ale nie jest czystym wyjściem z Docker Desktop. Bieżąca dokumentacja Dockera wymienia ją jako wymagającą Docker Desktop 4.68 lub nowszego, subskrypcji Docker Business i subskrypcji Docker Offload. Uruchamia obciążenia na zarządzanych przez Dockera hostach w chmurze, ale każdy użytkownik dostaje jedną sesję Offload naraz, bezczynne sesje kończą się po 5-minutowym okresie karencji, a środowisko jest efemeryczne, więc kontenery, obrazy i wolumeny znikają, gdy sesja się kończy. To w porządku, jeśli chcesz zarządzanej zdalnej mocy wewnątrz Docker Desktop. To nie to samo, co trwały builder VPS z twoją własną pamięcią podręczną, dyskiem, dostępem root i bez zależności od Desktop.

Pozostanie na miejscu wciąż jest racjonalne w jednym przypadku: pojedyncza osoba poniżej progu darmowego bez bólu szybkości kompilacji nie ma powodu, by cokolwiek zmieniać. Wszyscy inni mają rozwidlenie do podjęcia.

Kluczowy wniosek z sekcji: Decyzja, która się liczy, nie dotyczy tego, które lokalne narzędzie wybrać. Dotyczy tego, czy w ogóle trzymasz demona na swoim laptopie.

Jak docker context działa przez SSH

Aby budować obrazy Docker na zdalnym serwerze przez SSH, uruchom Docker Engine na tym serwerze, utwórz docker context wskazujący na niego za pomocą docker context create name --docker "host=ssh://user@host", potem uruchom docker context use name. Potem twoje zwykłe polecenie docker build wykonuje się na zdalnym hoście, a lokalny CLI tylko wysyła instrukcje, podczas gdy demon wykonuje pracę.

Kontekst to nazwany, przełączalny cel dla Docker CLI. Zamiast żonglować zmiennymi środowiskowymi DOCKER_HOST albo ręcznie stawiać tunel SSH za każdym razem, definiujesz zdalne raz i przełączasz się na nie jak zmieniasz katalog. Kompilacja wykonuje się w całości na zdalnym hoście: pobieranie obrazów bazowych korzysta z łącza wysyłającego VPS, warstwy cache'ują się na dysku VPS, a praca CPU dzieje się na rdzeniach VPS. Jedyne kroki wrażliwe na opóźnienia to początkowe uzgadnianie SSH i przesłanie twojego kontekstu kompilacji. Wszystko po tym jest zdalne.

Konfiguracja twojej maszyny kompilacyjnej VPS

Cała konfiguracja to cztery krótkie polecenia plus blok konfiguracji SSH. Pokażę oczekiwane wyjście tam, gdzie pomoże ci to potwierdzić, że każdy krok wypalił.

Krok 1: Dostarcz Docker Engine na VPS z Linuxem. Zainicjuj maszynę i zainstaluj Docker Engine (18.09+ na zdalnym to dolny próg dla context SSH; twój lokalny CLI potrzebuje 19.03+). Jeśli wolisz nie uruchamiać instalacji sam, wdroż VPS, który już go dostarcza (więcej o tym poniżej). Zdalny użytkownik musi być w grupie docker:

sudo usermod -aG docker $USER

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

Krok 2: Skonfiguruj uwierzytelnianie kluczem SSH i alias konfiguracji. Uwierzytelnianie kluczem jest obowiązkowe. Nadaj hostowi krótki alias w ~/.ssh/config żeby nie przepisywać IP i ścieżki klucza:

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

Krok 3: Utwórz kontekst. Skieruj go na zdalnego demona przez SSH. Użyj pełnej formy:

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

Albo, używając aliasu konfiguracji SSH z kroku 2:

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

Krok 4: Zweryfikuj. Wylistuj swoje konteksty i sprawdź, czy zdalny silnik odpowiada:

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

Jeśli to wypisze wersję serwera zdalnego demona, twój CLI rozmawia z VPS.

Krok 5: Przełącz i buduj. Uczyń VPS aktywnym celem, potem buduj jak zwykle:

docker context use my-vps

docker build -t myapp .

Ta kompilacja wykonuje się na VPS. Wolisz nie przełączać globalnie? Wyceluj w pojedyncze polecenie:

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

Albo ustaw to dla sesji powłoki:

export DOCKER_CONTEXT=my-vps

Gdy zechcesz odzyskać lokalnego demona swojego laptopa (jeśli jakiegoś zachowałeś), przełącz się do domu:

docker context use default

Porada: pilnuj swojego .dockerignore. Kontekst kompilacji jest przesyłany na zdalny host przed startem kompilacji. Zabłąkany katalog node_modules or .git oznacza, że wysyłasz gigabajty po łączu przy każdym przebiegu, a zdalna ścieżka będzie się wydawać wolniejsza niż lokalna bez żadnego dobrego powodu. Ciasny .dockerignore to jedna rzecz, która najbardziej wpływa na to, czy zdalna ścieżka wydaje się szybka: wyklucz zależności, artefakty kompilacji i metadane VCS, a przesyłanie staje się błędem zaokrąglenia.

Kompilacje wieloarchitekturowe ze zdalnym sterownikiem buildx

Utwórz builder buildx, który uruchamia BuildKit wewnątrz kontenera na zdalnym hoście Docker, potem buduj wobec niego:

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 .

Zdalny --load flaga jest ważna dla lokalnej konsumpcji na jednej platformie: ze sterownikiem docker-container driver, zbudowane obrazy nie pojawiają się automatycznie na twojej lokalnej liście obrazów. Jeśli budujesz prawdziwy obraz wieloplatformowy, zamiast tego wypchnij go do rejestru:

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

To rozróżnienie jest ważne. Zdalną kompilację na jednej platformie można wczytać z powrotem do twojego lokalnego magazynu obrazów. Obraz wieloplatformowy zwykle jest wypychany do rejestru, ponieważ to lista manifestów z osobnymi wariantami dla każdej docelowej architektury. Ta sekcja jest opcjonalna: jeśli wszystkie twoje obrazy są jednoarchitekturowe, konfiguracja kontekstu powyżej to cała robota.

Dobór rozmiaru i zabezpieczanie maszyny kompilacyjnej

Dwa pytania decydują, czy ta maszyna dobrze ci służy: jak dużą ją zrobić i jak trzymać demona zamkniętego. Kompilacje Dockera są ograniczone przez CPU, więc logika doboru rozmiaru dotyczy głównie rdzeni i wystarczającego RAM, by uniknąć swapowania. Logika bezpieczeństwa dotyczy głównie nieudostępniania demona nikomu poza tobą.

Na jaki rozmiar ją ustawić

Nadaj jej ogólne specyfikacje. Możesz je odwzorować na to, co oferuje twój dostawca.

• Dolna granica (jeden programista, lekkie kompilacje): 2 vCPU / 4 GB RAM / ~120 GB NVMe. This is the minimum that works, not what I'd reach for.
• Co bym naprawdę wdrożył (dla większości zespołów): 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.
• Zespół albo ciężkie CI: 8 vCPU / 16-24 GB RAM for several developers sharing one box or big multi-stage Dockerfiles.

Ponieważ kompilacje są ograniczone przez CPU, rdzenie o wysokiej częstotliwości (zoptymalizowane pod CPU) kupują ci szybszą iterację bardziej niż dodatkowy RAM poza progiem swapowania. Plany z GPU są tu nieistotne, ponieważ kompilacje obrazów nie dotykają GPU. A wybór centrum danych wpływa tylko na responsywność SSH i czas przesyłania kontekstu, a nie na szybkość kompilacji: kompilacja wykonuje się na VPS niezależnie od tego, gdzie siedzisz, więc wybierz lokalizację blisko siebie dla żwawego uzgadniania i idź dalej.

Zabezpieczanie zdalnego demona

Konfiguracja powyżej już wymusza właściwą wartość domyślną: uwierzytelnianie kluczem SSH, żaden port demona nieudostępniony do sieci. Trzymaj tak. W chwili, gdy udostępnisz BuildKit lub demona poza SSH (surowy punkt końcowy TCP, otwarty port BuildKit), stajesz się celem. wątek na Hacker News o wolnych kompilacjach, który jako pierwszy podniósł pomysł zdalnego VPS, ostrzegał też o atakach kryptokopania na udostępnione punkty końcowe BuildKit. Nieuwierzytelniony demon kompilacji w otwartym internecie to darmowy bufet obliczeniowy.

Porada: nie udostępniaj demona. Jeśli wystarcza ci samo SSH (wystarcza dla większości jednomaszynowych konfiguracji), nigdy nie otwieraj portu TCP demona . Jeśli naprawdę potrzebujesz dostępu TCP, postaw przed nim wzajemny TLS (mTLS), żeby łączyć mogli się tylko klienci z ważnym certyfikatem. Tylko SSH albo mTLS: nie ma akceptowalnej trzeciej opcji dla maszyny kompilacyjnej osiągalnej z internetu.

Gdy maszyna już stoi, to serwer Linux ogólnego przeznaczenia, i jest jeszcze mnóstwo innych rzeczy wartych uruchomienia na nim. Nasz przewodnik po samodzielnie hostowanym stosie dla indie hackerów to rozsądna kolejna lektura o tym, co jeszcze zasługuje na miejsce na twoim VPS.

Jeśli wolisz pominąć instalację Docker Engine i przejść wprost do docker context create, nasza aplikacja Docker z marketplace wdraża VPS z już skonfigurowanymi Docker Engine, Compose V2 i buildx. Jedno kliknięcie i maszyna jest gotowa do SSH, więc przejście powyżej zaczyna się od kroku 2 zamiast kroku 1.

Często zadawane pytania

Czy mogę uruchamiać kompilacje Docker na zdalnym serwerze i używać swojego lokalnego CLI?

Tak. Uruchom Docker Engine na zdalnym hoście, utwórz docker context wskazujący na niego przez SSH, i przełącz się na ten kontekst. Twoje lokalne polecenie docker build wykonuje się wtedy na zdalnym serwerze, podczas gdy CLI na twojej maszynie tylko orkiestruje, bez potrzeby lokalnego demona.

Jaka jest różnica między docker context a DOCKER_HOST?

A docker context to nazwany, przełączalny, trwały cel, który definiujesz raz i wybierasz za pomocą docker context use. DOCKER_HOST to pojedyncza zmienna środowiskowa, którą ustawiasz i usuwasz ręcznie dla każdej powłoki. Kontekst to nowoczesny zamiennik starego podejścia „tunel plus zmienna środowiskowa”.

Czy docker compose działa ze zdalnym kontekstem?

Tak. Compose V2 respektuje aktywny kontekst Docker, więc polecenia docker compose wykonują się wobec hosta, na który wskazuje kontekst. Usługi i wszelkie kompilacje obrazów wykonują się na zdalnym hoście, tak samo jak zwykłe docker build.

Czym jest Docker Offload i czy jest darmowy?

Docker Offload to własna zarządzana usługa Dockera do zdalnej kompilacji/uruchamiania, przenosząca pracę z kontenerami na zarządzane przez Dockera hosty w chmurze, zachowując przy tym przepływ pracy Docker Desktop. Bieżąca dokumentacja Dockera wymienia ją jako wymagającą Docker Desktop 4.68 lub nowszego, plus subskrypcje Docker Business i Docker Offload. Jest też oparta na sesjach: każdy użytkownik dostaje jedną sesję Offload naraz, bezczynne sesje kończą się po 5-minutowym okresie karencji, a zdalne środowisko jest efemeryczne.

Jak powstrzymać Docker Desktop przed używaniem tak dużej ilości pamięci?

Strojenie limitów zasobów Docker Desktop jedynie zmniejsza ślad, który nigdy nie schodzi do zera, ponieważ VM zawsze ma podłogę. Ścieżka, która naprawdę usuwa koszt pamięci, to całkowite usunięcie lokalnego demona: uruchom Docker Engine na VPS i połącz się przez docker context przez SSH, żeby na twojej maszynie nie działało nic poza CLI.

Czy mogę zrobić to z Podmanem zamiast tego?

Możesz. Podman jest dostępny jako silnik zgodny z Dockerem, i docker context może wskazywać na zdalny host Podman, ale to wymaga, by Podman udostępnił swoje gniazdo zgodne z Dockerem przez SSH. Przepływ poleceń jest ten sam. Konfiguracja po stronie zdalnej się różni.