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

เปิด Activity Monitor หรือ Task Manager เริ่มคอนเทนเนอร์เล็ก ๆ แล้ว Docker Desktop ก็ยังกลายเป็นสิ่งที่ส่งเสียงดังที่สุดบนเครื่องได้ ใน issue Docker Desktop เดือนกุมภาพันธ์ 2026 ผู้ใช้รายหนึ่งรายงานว่า com.docker.backend.exe ไต่ขึ้นไปถึง 100% CPU หลังจากคอนเทนเนอร์เริ่มทำงาน แล้วก็ทำงานต่อแม้หลังจากหยุดคอนเทนเนอร์แล้ว

มีอีกทางเลือกหนึ่ง: เอา daemon ออกจากแล็ปท็อปของคุณทั้งหมด เก็บเฉพาะ Docker CLI ไว้แบบโลคัล รัน Docker Engine บน Linux VPS และชี้ docker context ไปที่มันผ่าน SSH คำสั่ง docker build ของคุณไม่เปลี่ยน บิลด์เพียงแค่ทำงานที่อื่น บน Linux เนทีฟที่ไม่มีเลเยอร์ VM โดยแบนด์วิดท์ของ VPS ดึงอิมเมจฐานแทนที่จะเป็น Wi-Fi ร้านกาแฟของคุณ และไม่มีลิขสิทธิ์ Docker Desktop ให้ต้องตามติด

นี่คือการตั้งค่าครบถ้วนสำหรับเส้นทางนั้น: ข้อกำหนดเบื้องต้น คำสั่ง docker context ที่แน่นอน บิลด์แบบหลายสถาปัตยกรรมด้วยไดรเวอร์ buildx ระยะไกล วิธีกำหนดขนาดเครื่อง และจุดที่แนวทางระยะไกลเป็นตัวเลือกที่ผิด

TL;DR (สรุปย่อ)

• ปัญหา: Docker Desktop แบก VM แบบโลคัลไว้ ผลักดัน I/O ของไฟล์ผ่านเลเยอร์เวอร์ชวลไลเซชัน และ ต้องมีการสมัครสมาชิกแบบเสียเงิน สำหรับการใช้งานระดับมืออาชีพในองค์กรที่ใหญ่ขึ้น รวมถึงบริษัทที่เกินขีดจำกัดระดับฟรีของ Docker
• ทางแก้: เอา Docker Desktop ออก รัน Docker Engine บน Linux VPS สร้าง 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 กลุ่ม เพื่อให้มันคุยกับซ็อกเก็ตของ daemon ได้โดยไม่ต้องใช้ sudo ในทุกครั้งที่เรียก

Docker Desktop ทำให้คุณเสียอะไรไปจริง ๆ

ต้นทุนไม่ใช่ปริศนา มันตกลงที่สามจุด และคนที่ค้นหาทางมาถึงนี่ได้สัมผัสอย่างน้อยหนึ่งในนั้น การเรียกชื่อมันอย่างแม่นยำคือประเด็น ความเจ็บปวดนั้นคุณรู้จักอยู่แล้ว

หน่วยความจำและโอเวอร์เฮดของ VM Docker Desktop ยังหมายถึง VM Linux แบบโลคัล เอกสารการตั้งค่าของ Docker บอกว่า Docker Desktop สามารถจำกัดได้ว่า VM ของ Docker Desktop ใช้หน่วยความจำเท่าไร ซึ่งเป็นส่วนที่เงียบของปัญหา: ในลูปยังมี VM อยู่ รอยเท้าที่แน่นอนแปรผันตามระบบปฏิบัติการและโปรเจกต์ แต่โหมดความล้มเหลวนั้นมีจริง issue Docker for Windows รายงานว่า Docker Desktop กิน RAM หลายกิกะไบต์โดยไม่มีคอนเทนเนอร์ทำงานเลย และ issue WSL2 อธิบายว่าบิลด์ Docker ทิ้งหน่วยความจำที่ไม่ถูกปล่อยไว้หลังจากคอนเทนเนอร์สิ้นสุด ประเด็นไม่ได้อยู่ที่ว่าทุกเครื่องเดินเบาอยู่ที่ตัวเลขเดียวกัน แต่อยู่ที่ว่า Docker Desktop เก็บโอเวอร์เฮดของ VM แบบโลคัลไว้ในลูปการพัฒนาของคุณ

ความเร็วในการบิลด์และ I/O ของไฟล์ bind mount และการดำเนินการไฟล์ที่ข้ามขอบเขต VM ช้ากว่าการเข้าถึงระบบไฟล์ Linux เนทีฟ เอกสารปัญหาที่ทราบแล้วของ Docker ยอมรับต้นทุนของระบบไฟล์เวอร์ชวลไลเซชัน เบนช์มาร์กจากชุมชนรายงานเป็นประจำว่าราว 3-10x ช้ากว่าสำหรับ bind mount ผ่านเลเยอร์ 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 ที่คุณจะเจอ ล้วนแลก daemon โลคัลตัวหนึ่งกับ daemon โลคัลอีกตัวหนึ่ง นั่นคือแกนที่แท้จริงที่ควรสังเกต: ตัวเลือกที่คนส่วนใหญ่ครุ่นคิดอยู่ระหว่างเครื่องมือโลคัล ในขณะที่ทางแยกที่น่าสนใจกว่าคือโลคัลกับระยะไกล มีเพียงเส้นทางระยะไกลเท่านั้นที่เอา VM ออกจากเครื่องของคุณ

นี่คือภูมิทัศน์แบบเทียบเคียงกัน

บางตัวในนี้สมควรได้รับหนึ่งประโยคแห่งความซื่อสัตย์:

• OrbStack แก้ปัญหาทรัพยากรบน Mac ได้จริงสำหรับนักพัฒนาเดี่ยว มันอ้าง ~300 MB ตอนเดินเบาและการเริ่มคอนเทนเนอร์เร็วขึ้นถึง 10x (เว็บไซต์ OrbStack) ทั้งคู่เป็นตัวเลขของผู้ขาย ไม่ใช่เบนช์มาร์กอิสระ หากคุณเป็นนักพัฒนาบน Mac เท่านั้นที่ไม่อยากจัดการโครงสร้างพื้นฐานระยะไกล OrbStack คือตัวเลือกที่ดีกว่า และระดับเชิงพาณิชย์ $8/mo ของมัน (ราคา OrbStack) ต่ำกว่าระดับ Team ของ Docker Desktop จุดสะดุด: มันใช้ได้กับ Mac เท่านั้น และลิขสิทธิ์เชิงพาณิชย์นำสิ่งที่คุณพยายามหนีมากลับมาเป๊ะ ๆ
• Colima ฟรีและเน้น CLI เป็นหลัก แต่ความหยาบ "ไม่ใช่ตัวแทนโดยตรง" ของมันมีการบันทึกไว้อย่างดี และบางทีมก็กลับไปที่ Docker Desktop หลังจากการย้ายข้อมูลติดขัด
• Podman Desktop และ Rancher Desktop ทั้งคู่ฟรีและข้ามแพลตฟอร์ม ไม่มีตัวไหนเป็นตัวแทนแบบเงียบ ๆ และความเข้ากันได้กับ Compose ของ Podman ทำงานผ่านซ็อกเก็ตที่เข้ากันได้กับ Docker ของมัน
• Docker Offload คือบริการบิลด์/รันระยะไกลแบบมีการจัดการของ Docker เอง แต่ไม่ใช่การออกจาก Docker Desktop ที่สะอาดหมดจด เอกสาร Docker ปัจจุบันระบุว่ามันต้องใช้ Docker Desktop 4.68 หรือใหม่กว่า การสมัครสมาชิก Docker Business และการสมัครสมาชิก Docker Offload มันรันภาระงานบนโฮสต์คลาวด์ที่ Docker จัดการ แต่ผู้ใช้แต่ละคนได้หนึ่งเซสชัน Offload ในแต่ละครั้ง เซสชันที่ว่างจะสิ้นสุดหลังช่วงผ่อนผัน 5 นาที และสภาพแวดล้อมเป็นแบบชั่วคราว ดังนั้นคอนเทนเนอร์ อิมเมจ และวอลุ่มจะหายไปเมื่อเซสชันสิ้นสุด นั่นก็โอเคหากคุณต้องการกำลังระยะไกลแบบมีการจัดการภายใน Docker Desktop มันไม่เหมือนกับตัวบิลด์ VPS ที่คงอยู่ถาวรพร้อมแคช ดิสก์ สิทธิ์ root ของคุณเอง และไม่มีการพึ่งพา Desktop

การอยู่กับที่ยังสมเหตุสมผลในกรณีเดียว: บุคคลหนึ่งที่อยู่ต่ำกว่าเกณฑ์ฟรีโดยไม่มีความเจ็บปวดเรื่องความเร็วบิลด์ ไม่มีเหตุผลที่จะเปลี่ยนอะไรเลย ทุกคนที่เหลือมีทางแยกที่ต้องตัดสินใจ

ข้อสรุปสำคัญของหัวข้อนี้: การตัดสินใจที่สำคัญไม่ใช่ว่าจะเลือกเครื่องมือโลคัลตัวไหน แต่อยู่ที่ว่าคุณจะเก็บ daemon ไว้บนแล็ปท็อปของคุณเลยหรือไม่

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 โลคัลเพียงแค่ส่งคำสั่งในขณะที่ daemon ทำงาน

context คือเป้าหมายที่มีชื่อและสลับได้สำหรับ Docker CLI แทนที่จะเล่นกลกับตัวแปรสภาพแวดล้อม DOCKER_HOST หรือตั้งอุโมงค์ SSH ด้วยมือทุกครั้ง คุณกำหนดปลายทางระยะไกลครั้งเดียวและสลับไปที่มันเหมือนเปลี่ยนไดเรกทอรี บิลด์ทำงานทั้งหมดบนโฮสต์ระยะไกล: การดึงอิมเมจฐานใช้อัปลิงก์ของ VPS เลเยอร์แคชอยู่บนดิสก์ของ VPS และงาน CPU เกิดขึ้นบนคอร์ของ VPS ขั้นตอนเดียวที่ไวต่อความหน่วงคือ SSH handshake เริ่มต้นและการอัปโหลดคอนเท็กซ์บิลด์ของคุณ ทุกอย่างหลังจากนั้นเป็นระยะไกล

การตั้งค่ากล่องบิลด์ VPS ของคุณ

การตั้งค่าทั้งหมดคือสี่คำสั่งสั้น ๆ บวกบล็อกการตั้งค่า SSH ผมจะแสดงเอาต์พุตที่คาดหวังในจุดที่มันช่วยให้คุณยืนยันว่าแต่ละขั้นตอนลงตัว

ขั้นตอนที่ 1: นำ Docker Engine ขึ้นบน Linux VPS จัดเตรียมเครื่องและติดตั้ง 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: สร้าง context ชี้มันไปที่ daemon ระยะไกลผ่าน SSH ใช้รูปแบบเต็ม:

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

หรือใช้นามแฝงการตั้งค่า SSH จากขั้นตอนที่ 2:

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

ขั้นตอนที่ 4: ยืนยัน ลิสต์ context ของคุณและตรวจสอบว่าเอนจินระยะไกลตอบกลับ:

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

หากมันพิมพ์เวอร์ชันเซิร์ฟเวอร์ของ daemon ระยะไกลออกมา แสดงว่า 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

เมื่อคุณอยากได้ daemon โลคัลของแล็ปท็อปคืน (หากคุณเก็บไว้ตัวหนึ่ง) ให้สลับกลับบ้าน:

docker context use default

เคล็ดลับ: ใส่ใจ .dockerignoreของคุณ คอนเท็กซ์บิลด์จะถูกอัปโหลดไปยังโฮสต์ระยะไกลก่อนที่บิลด์จะเริ่ม ไดเรกทอรี node_modules or .git ที่หลงมาหมายความว่าคุณส่งข้อมูลหลายกิกะไบต์ไปตามสายในทุกครั้งที่รัน และเส้นทางระยะไกลจะรู้สึกช้ากว่าโลคัลโดยไม่มีเหตุผลอันดี .dockerignore ที่รัดกุมคือสิ่งเดียวที่ส่งผลมากที่สุดว่าเส้นทางระยะไกลรู้สึกเร็วหรือไม่: ยกเว้น dependency อาร์ติแฟกต์บิลด์ และเมทาดาทา VCS แล้วการอัปโหลดจะกลายเป็นข้อผิดพลาดปัดเศษ

บิลด์แบบหลายสถาปัตยกรรมด้วยไดรเวอร์ buildx ระยะไกล

สร้าง buildx builder ที่รัน 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, อิมเมจที่บิลด์แล้วจะไม่ปรากฏในลิสต์อิมเมจโลคัลของคุณโดยอัตโนมัติ หากคุณกำลังบิลด์อิมเมจหลายแพลตฟอร์มจริง ๆ ให้ push ไปยัง registry แทน:

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

ความแตกต่างนั้นสำคัญ บิลด์ระยะไกลบนแพลตฟอร์มเดียวสามารถโหลดกลับเข้าที่จัดเก็บอิมเมจโลคัลของคุณได้ อิมเมจหลายแพลตฟอร์มมักถูก push ไปยัง registry เพราะมันคือ manifest list ที่มีเวอร์ชันแยกสำหรับแต่ละสถาปัตยกรรมเป้าหมาย หัวข้อนี้เป็นทางเลือก: หากอิมเมจทั้งหมดของคุณเป็นสถาปัตยกรรมเดียว การตั้งค่า context ข้างต้นคืองานทั้งหมด

การกำหนดขนาดและการรักษาความปลอดภัยกล่องบิลด์

สองคำถามตัดสินว่ากล่องนี้รับใช้คุณได้ดีหรือไม่: คุณทำมันใหญ่แค่ไหน และคุณล็อก daemon ไว้อย่างไร บิลด์ Docker ผูกกับ CPU ดังนั้นตรรกะการกำหนดขนาดจึงส่วนใหญ่เกี่ยวกับคอร์และ RAM ที่เพียงพอเพื่อเลี่ยง swap ตรรกะความปลอดภัยส่วนใหญ่เกี่ยวกับการไม่เปิดเผย daemon ให้ใครนอกจากคุณ

ควรตั้งขนาดเท่าไร

ให้สเปกทั่วไปกับมัน คุณสามารถแมปมันเข้ากับอะไรก็ตามที่ผู้ให้บริการของคุณเสนอ

• ขั้นต่ำ (นักพัฒนาคนเดียว บิลด์เบา): 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.

เนื่องจากบิลด์ผูกกับ CPU คอร์ความถี่สูง (ปรับให้เหมาะกับ CPU) ซื้อการวนซ้ำที่เร็วขึ้นให้คุณมากกว่า RAM ที่เพิ่มเลยเกณฑ์ swap แผน GPU ไม่เกี่ยวข้องตรงนี้ เพราะบิลด์อิมเมจไม่แตะ GPU และการเลือกดาต้าเซ็นเตอร์ส่งผลเฉพาะต่อการตอบสนองของ SSH และเวลาอัปโหลด context เท่านั้น ไม่ใช่ความเร็วบิลด์: บิลด์ทำงานบน VPS ไม่ว่าคุณจะนั่งอยู่ที่ไหน ดังนั้นเลือกตำแหน่งใกล้คุณเพื่อ handshake ที่ว่องไวแล้วเดินหน้าต่อ

การรักษาความปลอดภัย daemon ระยะไกล

การตั้งค่าข้างต้นบังคับค่าเริ่มต้นที่ถูกต้องอยู่แล้ว: การยืนยันตัวตนด้วยกุญแจ SSH ไม่มีพอร์ต daemon ที่เปิดเผยต่อเครือข่าย จงรักษามันไว้แบบนั้น ในวินาทีที่คุณเปิดเผย BuildKit หรือ daemon เกินขอบเขต SSH (เอนด์พอยต์ TCP ดิบ พอร์ต BuildKit ที่เปิด) คุณก็กลายเป็นเป้าหมาย กระทู้ Hacker News เดียวกัน เรื่องบิลด์ช้าที่หยิบยกไอเดีย VPS ระยะไกลขึ้นมาเป็นครั้งแรก ก็เตือนเรื่องการโจมตีขุดคริปโตบนเอนด์พอยต์ BuildKit ที่เปิดเผยด้วย daemon บิลด์ที่ไม่มีการยืนยันตัวตนบนอินเทอร์เน็ตแบบเปิดคือบุฟเฟต์การประมวลผลฟรี

เคล็ดลับ: อย่าเปิดเผย daemon หากแค่ SSH เพียงพอสำหรับคุณ (เพียงพอสำหรับการตั้งค่าเครื่องเดียวส่วนใหญ่) อย่าเปิดพอร์ต TCP ของ daemon เลย หากคุณต้องการการเข้าถึง TCP จริง ๆ ให้วาง TLS แบบสองทาง (mTLS) ไว้ด้านหน้ามัน เพื่อให้เฉพาะไคลเอนต์ที่มีใบรับรองที่ถูกต้องเท่านั้นที่เชื่อมต่อได้ SSH เท่านั้นหรือ mTLS: ไม่มีตัวเลือกที่สามที่ยอมรับได้สำหรับกล่องบิลด์ที่เข้าถึงได้จากอินเทอร์เน็ต

เมื่อกล่องทำงานแล้ว มันคือเซิร์ฟเวอร์ Linux อเนกประสงค์ และยังมีอีกมากมายที่คุ้มค่าที่จะรันบนมัน คู่มือสแตก self-hosted สำหรับ indie hacker ของเรา เป็นสิ่งที่ควรอ่านต่อไปที่สมเหตุสมผลเกี่ยวกับอะไรอีกที่คู่ควรได้ที่ทางบน VPS ของคุณ

หากคุณอยากข้ามการติดตั้ง Docker Engine และไปที่ docker context createโดยตรง แอป Docker จากมาร์เก็ตเพลสของเรา ดีพลอย VPS ที่มี Docker Engine, Compose V2 และ buildx กำหนดค่าไว้แล้ว คลิกเดียวและกล่องก็พร้อม SSH ดังนั้นการเดินผ่านข้างต้นจึงเริ่มที่ขั้นตอนที่ 2 แทนที่จะเป็นขั้นตอนที่ 1

คำถามที่พบบ่อย

ฉันสามารถรันบิลด์ Docker บนเซิร์ฟเวอร์ระยะไกลและใช้ CLI โลคัลของฉันได้ไหม?

ได้ รัน Docker Engine บนโฮสต์ระยะไกล สร้าง docker context ที่ชี้ไปที่มันผ่าน SSH แล้วสลับไปที่ context นั้น คำสั่ง docker build โลคัลของคุณจะทำงานบนเซิร์ฟเวอร์ระยะไกล ในขณะที่ CLI บนเครื่องของคุณเพียงแค่ประสานงาน โดยไม่ต้องมี daemon โลคัล

ความแตกต่างระหว่าง docker context กับ DOCKER_HOST คืออะไร?

A docker context คือเป้าหมายที่มีชื่อ สลับได้ และคงอยู่ถาวร ซึ่งคุณกำหนดครั้งเดียวและเลือกด้วย docker context use. DOCKER_HOST คือตัวแปรสภาพแวดล้อมตัวเดียวที่คุณตั้งและยกเลิกด้วยมือสำหรับแต่ละเชลล์ context คือตัวแทนสมัยใหม่ของแนวทางเก่า "อุโมงค์บวกตัวแปรสภาพแวดล้อม"

docker compose ทำงานกับ context ระยะไกลไหม?

ได้ Compose V2 เคารพ context Docker ที่ใช้งานอยู่ ดังนั้นคำสั่ง docker compose จะทำงานกับโฮสต์ที่ context ชี้ไป บริการและบิลด์อิมเมจใด ๆ จะทำงานบนโฮสต์ระยะไกล เช่นเดียวกับ 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 มีพื้นเสมอ เส้นทางที่กำจัดต้นทุนหน่วยความจำได้จริงคือการเอา daemon โลคัลออกทั้งหมด: รัน Docker Engine บน VPS และเชื่อมต่อผ่าน docker context ทาง SSH เพื่อให้ไม่มีอะไรทำงานบนเครื่องของคุณนอกจาก CLI

ฉันทำสิ่งนี้ด้วย Podman แทนได้ไหม?

ได้ Podman มีให้ใช้ในฐานะเอนจินที่เข้ากันได้กับ Docker และ docker context สามารถชี้ไปที่โฮสต์ Podman ระยะไกลได้ แต่นั่นต้องให้ Podman เปิดเผยซ็อกเก็ตที่เข้ากันได้กับ Docker ของมันผ่าน SSH โฟลว์คำสั่งเหมือนกัน การตั้งค่าฝั่งระยะไกลต่างกัน