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

Mở Activity Monitor hoặc Task Manager, khởi chạy một container nhỏ, và Docker Desktop vẫn có thể trở thành thứ ồn ào nhất trên máy. Trong một issue Docker Desktop vào tháng 2 năm 2026, một người dùng báo cáo rằng com.docker.backend.exe leo lên 100% CPU sau khi các container khởi động, rồi tiếp tục ngay cả sau khi các container đã dừng.

Có một nước đi khác: đưa daemon ra khỏi laptop của bạn hoàn toàn. Chỉ giữ Docker CLI cục bộ, chạy Docker Engine trên một VPS Linux, và trỏ docker context vào nó qua SSH. Lệnh docker build của bạn không thay đổi. Bản build chỉ đơn giản chạy ở nơi khác, trên Linux gốc không có lớp VM, với băng thông của VPS kéo các image cơ sở thay vì Wi-Fi quán cà phê của bạn, và không có giấy phép Docker Desktop nào để theo dõi.

Đây là toàn bộ thiết lập cho con đường đó: điều kiện tiên quyết, các lệnh docker context chính xác, các bản build đa kiến trúc với một driver buildx từ xa, cách định cỡ máy, và nơi cách tiếp cận từ xa là lựa chọn sai.

Tóm tắt nhanh

• Vấn đề: Docker Desktop mang theo một VM cục bộ, đẩy I/O tệp qua một lớp ảo hóa, và yêu cầu một gói đăng ký trả phí cho việc dùng chuyên nghiệp ở các tổ chức lớn hơn, bao gồm các công ty vượt quá giới hạn bậc miễn phí của Docker.
• Cách khắc phục: gỡ Docker Desktop. Chạy Docker Engine trên một VPS Linux, tạo một docker context trỏ vào nó qua SSH, và lệnh docker build cục bộ của bạn chạy trên VPS trong khi CLI của bạn chỉ điều phối.
• Khung chi phí: một VPS khiêm tốn thay thế một giấy phép theo chỗ ngồi và cho bạn tốc độ build Linux gốc. Cả một đội có thể chia sẻ một hộp build duy nhất thay vì trả tiền theo từng nhà phát triển.
• Những lưu ý trung thực: VPS phải truy cập được (không build trên máy bay), và bạn cần kỷ luật với .dockerignore để không tải lên một ngữ cảnh build nhiều gigabyte ở mỗi lần chạy.

Điều kiện tiên quyết: những gì bạn sẽ cần

Trước lệnh đầu tiên, hãy chuẩn bị những thứ này. Không có gì kỳ lạ ở đây nếu bạn đã dùng Docker hằng ngày.

• A Linux VPS với quyền root hoặc sudo. Ubuntu 22.04/24.04 hoặc Debian 12/13 đều chạy tốt.
• Docker Engine trên VPS. docker context qua SSH cần Docker Engine 18.09 trở lên trên host từ xa, theo tài liệu context của Docker.
• Docker CLI 19.03 trở lên cục bộ. Đó là client hiểu lệnh cấp cao nhất context lệnh.
• An Một cặp khóa SSH. Chỉ xác thực bằng khóa: xác thực bằng mật khẩu không được hỗ trợ cho docker context các kết nối SSH.
• Người người dùng từ xa trong nhóm docker nhóm, để nó có thể trò chuyện với socket daemon mà không cần sudo ở mỗi lệnh gọi.

Docker Desktop thực sự khiến bạn tốn kém những gì

Chi phí không phải là điều bí ẩn. Chúng rơi vào ba chỗ, và người đã tìm đường đến đây đã cảm nhận ít nhất một trong số đó. Gọi tên chúng chính xác mới là điểm mấu chốt. Cơn đau thì bạn đã biết.

Bộ nhớ và chi phí VM. Docker Desktop vẫn có nghĩa là một VM Linux cục bộ. tài liệu cài đặt của Docker nói rằng Docker Desktop có thể giới hạn dung lượng bộ nhớ mà VM Docker Desktop dùng, đó là phần thầm lặng của vấn đề: vẫn có một VM trong vòng lặp. Dấu chân chính xác thay đổi theo hệ điều hành và dự án, nhưng các chế độ hỏng là có thật. Một issue Docker for Windows báo cáo rằng Docker Desktop ngốn nhiều gigabyte RAM khi không có container nào đang chạy, và một issue WSL2 mô tả các bản build Docker để lại bộ nhớ chưa được giải phóng sau khi các container kết thúc. Điểm mấu chốt không phải là mọi máy đều nghỉ ở cùng một con số. Mà là Docker Desktop giữ chi phí VM cục bộ ngay bên trong vòng lặp phát triển của bạn.

Tốc độ build và I/O tệp. Các bind mount và thao tác tệp vượt qua ranh giới VM chậm hơn truy cập hệ thống tệp Linux gốc. tài liệu về các vấn đề đã biết của Docker thừa nhận chi phí của hệ thống tệp ảo hóa. Các benchmark cộng đồng thường xuyên báo cáo một mức nào đó trong khoảng 3-10x chậm hơn cho bind mount qua lớp VM. Con số thứ hai đó là kinh nghiệm cộng đồng, không phải benchmark do Docker công bố, nhưng hướng đi thì không ai từng nhìn một bản build bò lê trên Mac lại tranh cãi.

Bản quyền. Kể từ thay đổi năm 2021, Docker Desktop yêu cầu một gói đăng ký trả phí cho các công ty trên 250 nhân viên hoặc trên 10 triệu $ doanh thu. Các bậc hiện tại trên trang giá của Docker là Personal ($0), Pro ($11/mo hoặc $9 mỗi năm), Team ($16/mo hoặc $15 mỗi năm) và Business ($24/mo). Bậc Team đã tăng từ $9 lên $15 mỗi năm vào tháng 12 năm 2024, một cú nhảy biến một khoản mục thầm lặng thành một cuộc trao đổi mua sắm, và đó là phần thực sự rát khi bạn nhân nó lên với ba mươi chỗ ngồi.

Các lựa chọn thay thế và ngã rẽ cục bộ so với từ xa

Gần như mọi lựa chọn thay thế Docker Desktop mà bạn sẽ tìm thấy đều đổi một daemon cục bộ này lấy một daemon cục bộ khác. Đó mới là trục thực sự cần chú ý: lựa chọn mà đa số người day dứt là giữa các công cụ cục bộ, trong khi ngã rẽ thú vị hơn là cục bộ so với từ xa. Chỉ con đường từ xa mới lấy VM ra khỏi máy của bạn.

Đây là bức tranh, đặt cạnh nhau.

Một vài trong số này xứng đáng có một câu trung thực:

• OrbStack thực sự khắc phục vấn đề tài nguyên trên Mac cho một nhà phát triển đơn lẻ. Nó tuyên bố ~300 MB nghỉ và khởi động container nhanh hơn tới 10x (trang OrbStack), cả hai đều là con số của nhà cung cấp, không phải benchmark độc lập. Nếu bạn là nhà phát triển chỉ dùng Mac không muốn quản lý hạ tầng từ xa, OrbStack là lựa chọn tốt hơn, và bậc thương mại $8/mo của nó (giá OrbStack) rẻ hơn bậc Team của Docker Desktop. Điểm bắt: nó chỉ dành cho Mac, và giấy phép thương mại mang trở lại đúng thứ mà bạn đã cố trốn khỏi.
• Colima miễn phí và ưu tiên CLI, nhưng các góc gồ ghề "không phải thay thế trực tiếp" của nó được ghi chép rõ, và một số đội quay lại Docker Desktop sau khi một cuộc di chuyển bị kẹt.
• Podman Desktop và Rancher Desktop cả hai đều miễn phí và đa nền tảng. Cả hai đều không phải thay thế thầm lặng, và tính tương thích Compose của Podman đi qua socket tương thích Docker của nó.
• Docker Offload là dịch vụ build/chạy từ xa được quản lý của chính Docker, nhưng không phải một lối thoát sạch khỏi Docker Desktop. Tài liệu Docker hiện tại liệt kê nó như một thứ yêu cầu Docker Desktop 4.68 trở lên, một gói đăng ký Docker Business và một gói đăng ký Docker Offload. Nó chạy khối lượng công việc trên các host đám mây do Docker quản lý, nhưng mỗi người dùng nhận một phiên Offload tại một thời điểm, các phiên nghỉ kết thúc sau thời gian ân hạn 5 phút, và môi trường là tạm thời, nên container, image và volume biến mất khi phiên kết thúc. Điều đó ổn nếu bạn muốn dung lượng từ xa được quản lý bên trong Docker Desktop. Nó không giống một builder VPS bền bỉ với cache, đĩa, quyền root của riêng bạn và không phụ thuộc Desktop.

Đứng yên vẫn hợp lý trong một trường hợp: một cá nhân dưới ngưỡng miễn phí không có nỗi đau về tốc độ build thì không có lý do gì để thay đổi bất cứ điều gì. Mọi người khác đều có một ngã rẽ phải chọn.

Điểm chính của phần này: Quyết định quan trọng không phải là chọn công cụ cục bộ nào. Mà là liệu bạn có giữ một daemon trên laptop của mình hay không.

docker context hoạt động qua SSH như thế nào

Để build image Docker trên một máy chủ từ xa qua SSH, hãy chạy Docker Engine trên máy chủ đó, tạo một docker context trỏ vào nó bằng docker context create name --docker "host=ssh://user@host", rồi chạy docker context use name. Sau đó lệnh docker build thông thường của bạn chạy trên host từ xa, và CLI cục bộ chỉ gửi chỉ dẫn trong khi daemon làm việc.

Một ngữ cảnh là một đích có tên, có thể chuyển đổi cho Docker CLI. Thay vì tung hứng các biến môi trường DOCKER_HOST hay tự dựng một đường hầm SSH mỗi lần, bạn định nghĩa cái từ xa một lần và chuyển sang nó như đổi thư mục. Bản build chạy hoàn toàn trên host từ xa: việc kéo image cơ sở dùng đường lên của VPS, các lớp được cache trên đĩa của VPS, và công việc CPU diễn ra trên các nhân của VPS. Các bước duy nhất nhạy với độ trễ là cái bắt tay SSH ban đầu và việc tải lên ngữ cảnh build của bạn. Mọi thứ sau đó là từ xa.

Thiết lập hộp build VPS của bạn

Toàn bộ thiết lập là bốn lệnh ngắn cộng một khối cấu hình SSH. Tôi sẽ cho thấy đầu ra mong đợi ở nơi nó giúp bạn xác nhận từng bước đã ổn.

Bước 1: Đưa Docker Engine lên một VPS Linux. Cấp phát máy và cài Docker Engine (18.09+ ở phía từ xa là mức tối thiểu cho context SSH; CLI cục bộ của bạn cần 19.03+). Nếu bạn không muốn tự chạy phần cài đặt, hãy triển khai một VPS đã kèm sẵn (chi tiết bên dưới). Người dùng từ xa phải nằm trong nhóm docker:

sudo usermod -aG docker $USER

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

Bước 2: Thiết lập xác thực khóa SSH và một bí danh cấu hình. Xác thực bằng khóa là bắt buộc. Hãy đặt cho host một bí danh ngắn trong ~/.ssh/config để bạn không phải gõ lại IP và đường dẫn khóa:

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

Bước 3: Tạo ngữ cảnh. Trỏ nó vào daemon từ xa qua SSH. Dùng dạng đầy đủ:

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

Hoặc, dùng bí danh cấu hình SSH từ Bước 2:

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

Bước 4: Xác minh. Liệt kê các ngữ cảnh của bạn và kiểm tra xem engine từ xa có trả lời không:

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

Nếu nó in ra phiên bản máy chủ của daemon từ xa, CLI của bạn đang trò chuyện với VPS.

Bước 5: Chuyển và build. Đặt VPS làm đích đang hoạt động, rồi build như bình thường:

docker context use my-vps

docker build -t myapp .

Bản build đó chạy trên VPS. Không muốn chuyển toàn cục? Hãy nhắm vào một lệnh duy nhất:

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

Hoặc đặt nó cho phiên shell:

export DOCKER_CONTEXT=my-vps

Khi bạn muốn daemon cục bộ của laptop trở lại (nếu bạn đã giữ một cái), hãy chuyển về nhà:

docker context use default

Mẹo chuyên nghiệp: để ý .dockerignorecủa bạn. Ngữ cảnh build được tải lên host từ xa trước khi build bắt đầu. Một thư mục node_modules or .git lạc lối nghĩa là bạn gửi hàng gigabyte qua đường truyền ở mỗi lần chạy, và con đường từ xa sẽ cảm thấy chậm hơn cục bộ mà chẳng vì lý do gì hay. Một .dockerignore chặt chẽ là điều ảnh hưởng nhiều nhất đến việc con đường từ xa có cảm thấy nhanh hay không: loại trừ các phụ thuộc, artefact build và metadata VCS, và việc tải lên trở thành một sai số làm tròn.

Các bản build đa kiến trúc với một driver buildx từ xa

Tạo một builder buildx chạy BuildKit bên trong một container trên host Docker từ xa, rồi build đối với nó:

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 .

Người --load cờ quan trọng cho việc dùng cục bộ một nền tảng: với driver docker-container driver, các image đã build không tự động xuất hiện trong danh sách image cục bộ của bạn. Nếu bạn build một image đa nền tảng thật sự, thay vào đó hãy đẩy nó lên một registry:

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

Sự phân biệt đó quan trọng. Một bản build từ xa một nền tảng có thể được tải trở lại vào kho image cục bộ của bạn. Một image đa nền tảng thường được đẩy lên một registry, vì nó là một danh sách manifest với các biến thể riêng cho từng kiến trúc đích. Phần này là tùy chọn: nếu tất cả image của bạn là một-kiến-trúc, thiết lập ngữ cảnh ở trên là toàn bộ công việc.

Định cỡ và bảo mật hộp build

Hai câu hỏi quyết định liệu hộp này có phục vụ bạn tốt hay không: bạn làm nó lớn cỡ nào, và bạn giữ daemon khóa chặt ra sao. Các bản build Docker bị ràng buộc CPU, nên logic định cỡ chủ yếu là về nhân và đủ RAM để tránh swap. Logic bảo mật chủ yếu là về việc không phơi bày daemon cho ai khác ngoài bạn.

Đặt nó ở kích cỡ nào

Hãy cho nó thông số kỹ thuật chung. Bạn có thể ánh xạ chúng sang bất cứ thứ gì nhà cung cấp của bạn có.

• Sàn (một nhà phát triển, build nhẹ): 2 vCPU / 4 GB RAM / ~120 GB NVMe. This is the minimum that works, not what I'd reach for.
• Thứ mà tôi thực sự sẽ triển khai (đa số đội): 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.
• Đội hoặc CI nặng: 8 vCPU / 16-24 GB RAM for several developers sharing one box or big multi-stage Dockerfiles.

Vì các bản build bị ràng buộc CPU, các nhân tần số cao (tối ưu cho CPU) mua cho bạn lần lặp nhanh hơn nhiều hơn là RAM thêm vượt quá ngưỡng swap. Các gói GPU không liên quan ở đây, vì build image không chạm tới GPU. Và lựa chọn trung tâm dữ liệu chỉ ảnh hưởng đến độ nhạy của SSH và thời gian tải ngữ cảnh, không ảnh hưởng tốc độ build: bản build chạy trên VPS bất kể bạn ngồi ở đâu, nên hãy chọn một vị trí gần bạn để có cái bắt tay nhanh nhẹn và đi tiếp.

Bảo mật daemon từ xa

Thiết lập ở trên đã buộc mặc định đúng: xác thực khóa SSH, không cổng daemon nào phơi ra mạng. Hãy giữ vậy. Khoảnh khắc bạn phơi bày BuildKit hay daemon vượt ra ngoài SSH (một điểm cuối TCP thô, một cổng BuildKit mở), bạn trở thành mục tiêu. luồng thảo luận trên Hacker News về các bản build chậm đã lần đầu nêu ý tưởng VPS từ xa cũng cảnh báo về các cuộc tấn công đào tiền mã hóa trên các điểm cuối BuildKit bị phơi bày. Một daemon build không xác thực trên internet mở là một bữa tiệc điện toán miễn phí.

Mẹo chuyên nghiệp: đừng phơi bày daemon. Nếu chỉ-SSH là đủ với bạn (đủ với đa số thiết lập một-hộp), đừng bao giờ mở một cổng TCP của daemon . Nếu bạn thực sự cần truy cập TCP, hãy đặt TLS tương hỗ (mTLS) ở phía trước để chỉ các client có chứng chỉ hợp lệ mới kết nối được. Chỉ-SSH hoặc mTLS: không có lựa chọn thứ ba chấp nhận được cho một hộp build có thể truy cập từ internet.

Một khi hộp đã chạy, nó là một máy chủ Linux đa dụng, và còn nhiều thứ khác đáng chạy trên nó. hướng dẫn ngăn xếp self-hosted cho indie hacker của chúng tôi là một bài đọc tiếp theo hợp lý về những gì khác xứng đáng có một chỗ trên VPS của bạn.

Nếu bạn muốn bỏ qua phần cài Docker Engine và đi thẳng tới docker context create, ứng dụng Docker marketplace của chúng tôi triển khai một VPS với Docker Engine, Compose V2 và buildx đã được cấu hình sẵn. Một cú nhấp và hộp đã sẵn sàng SSH, nên phần hướng dẫn ở trên bắt đầu từ Bước 2 thay vì Bước 1.

Câu hỏi thường gặp

Tôi có thể chạy các bản build Docker trên một máy chủ từ xa và dùng CLI cục bộ của mình không?

Có. Chạy Docker Engine trên host từ xa, tạo một docker context trỏ vào nó qua SSH, và chuyển sang ngữ cảnh đó. Lệnh docker build cục bộ của bạn khi đó chạy trên máy chủ từ xa trong khi CLI trên máy của bạn chỉ điều phối, không cần daemon cục bộ nào.

Khác biệt giữa docker context và DOCKER_HOST là gì?

A docker context là một đích có tên, có thể chuyển đổi, bền bỉ mà bạn định nghĩa một lần và chọn với docker context use. DOCKER_HOST là một biến môi trường duy nhất mà bạn đặt và gỡ thủ công cho từng shell. Ngữ cảnh là bản thay thế hiện đại cho cách tiếp cận đường-hầm-cộng-biến-môi-trường cũ.

docker compose có hoạt động với một ngữ cảnh từ xa không?

Có. Compose V2 tôn trọng ngữ cảnh Docker đang hoạt động, nên các lệnh docker compose chạy đối với host mà ngữ cảnh trỏ tới. Các dịch vụ và bất kỳ bản build image nào đều chạy trên host từ xa, giống như một docker build.

Docker Offload là gì và nó có miễn phí không?

Docker Offload là dịch vụ build/chạy từ xa được quản lý của chính Docker để chuyển công việc container sang các host đám mây do Docker quản lý trong khi vẫn giữ quy trình Docker Desktop. Tài liệu Docker hiện tại liệt kê nó như một thứ yêu cầu Docker Desktop 4.68 trở lên, cộng thêm các gói đăng ký Docker Business và Docker Offload. Nó cũng dựa trên phiên: mỗi người dùng nhận một phiên Offload tại một thời điểm, các phiên nghỉ kết thúc sau thời gian ân hạn 5 phút, và môi trường từ xa là tạm thời.

Làm thế nào để ngăn Docker Desktop dùng quá nhiều bộ nhớ?

Tinh chỉnh các giới hạn tài nguyên của Docker Desktop chỉ thu nhỏ một dấu chân không bao giờ về không, vì VM luôn có một mức sàn. Con đường thực sự loại bỏ chi phí bộ nhớ là gỡ bỏ daemon cục bộ hoàn toàn: chạy Docker Engine trên một VPS và kết nối qua docker context bằng SSH, để trên máy của bạn không có gì chạy ngoài CLI.

Tôi có thể làm điều này với Podman thay thế không?

Bạn có thể. Podman có sẵn như một engine tương thích Docker, và docker context có thể trỏ tới một host Podman từ xa, nhưng điều đó yêu cầu Podman phơi bày socket tương thích Docker của nó qua SSH. Luồng lệnh là như nhau. Thiết lập ở phía từ xa thì khác.