นักเทียบท่าเพิ่มอะไรใน lxc-tools (เครื่องมือ LXC userspace)

398

หากคุณดูที่คุณสมบัติของ Docker นั้นส่วนใหญ่มีให้โดย LXC แล้ว

ดังนั้นนักเทียบท่าจะเพิ่มอะไร? ทำไมฉันถึงต้องใช้ Docker กับ LXC ธรรมดา

docker lxc

550

นักเทียบท่าไม่ใช่การทดแทนสำหรับ lxc "lxc" หมายถึงความสามารถของเคอร์เนล linux (โดยเฉพาะเนมสเปซและกลุ่มควบคุม) ซึ่งอนุญาตกระบวนการแซนด์บ็อกซ์จากกันและควบคุมการจัดสรรทรัพยากร

นอกเหนือจากคุณสมบัติพื้นฐานของเคอร์เนลระดับต่ำแล้ว Docker ยังมีเครื่องมือระดับสูงที่มีฟังก์ชั่นที่ทรงพลังหลายประการ:

การปรับใช้แบบพกพาข้ามเครื่องนักเทียบท่ากำหนดรูปแบบสำหรับการรวมแอปพลิเคชันและการอ้างอิงทั้งหมดลงในวัตถุเดียวซึ่งสามารถถ่ายโอนไปยังเครื่องที่เปิดใช้งานนักเทียบท่าใด ๆ และดำเนินการที่นั่นพร้อมกับการรับประกันว่าสภาพแวดล้อมการดำเนินการที่เปิดเผยกับแอปพลิเคชันจะเหมือนกัน Lxc ใช้กระบวนการ sandboxing ซึ่งเป็นสิ่งจำเป็นก่อนการปรับใช้แบบพกพา แต่เพียงอย่างเดียวนั้นไม่เพียงพอสำหรับการปรับใช้แบบพกพา หากคุณส่งสำเนาของแอปพลิเคชันของคุณที่ติดตั้งในการกำหนดค่า lxc ที่กำหนดเองมันจะไม่ทำงานบนเครื่องของฉันเหมือนกับที่คุณทำเพราะมันเชื่อมโยงกับการกำหนดค่าเฉพาะของเครื่องของคุณ: เครือข่ายการจัดเก็บการบันทึก distro เป็นต้นนักเทียบท่ากำหนดสิ่งที่เป็นนามธรรมสำหรับการตั้งค่าเฉพาะเครื่องเหล่านี้เพื่อให้ภาชนะนักเทียบท่าเดียวกันที่แน่นอนสามารถทำงานได้ - ไม่เปลี่ยนแปลง - บนเครื่องที่แตกต่างกัน
การประยุกต์ใช้เป็นศูนย์กลาง นักเทียบท่าได้รับการปรับให้เหมาะสำหรับการปรับใช้แอปพลิเคชันซึ่งตรงข้ามกับเครื่อง สิ่งนี้สะท้อนให้เห็นใน API ส่วนติดต่อผู้ใช้ปรัชญาการออกแบบและเอกสารประกอบ ในทางตรงกันข้ามสคริปต์ lxc helper มุ่งเน้นไปที่คอนเทนเนอร์เป็นเครื่องจักรที่มีน้ำหนักเบา - โดยทั่วไปเซิร์ฟเวอร์ที่บูตได้เร็วขึ้นและต้องการหน่วยความจำน้อยลง เราคิดว่ามีมากกว่าตู้คอนเทนเนอร์
สร้างโดยอัตโนมัติ นักเทียบท่ามีเครื่องมือสำหรับนักพัฒนาในการรวบรวมภาชนะจากซอร์สโค้ดโดยอัตโนมัติพร้อมการควบคุมแอพพลิเคชั่นอย่างสมบูรณ์สร้างเครื่องมือบรรจุภัณฑ์และอื่น ๆ พวกเขามีอิสระที่จะใช้ make, maven, พ่อครัว, หุ่นเชิด, เกลือ, debian package, rpms tarballs หรือการรวมกันใด ๆ ดังกล่าวข้างต้นโดยไม่คำนึงถึงการกำหนดค่าของเครื่องที่
รุ่น นักเทียบท่ารวมถึงความสามารถเหมือน git สำหรับการติดตามเวอร์ชันที่ต่อเนื่องของคอนเทนเนอร์การตรวจสอบความแตกต่างระหว่างเวอร์ชันการคอมไพล์เวอร์ชันใหม่การย้อนกลับเป็นต้นประวัติยังรวมถึงวิธีการรวมตัวของคอนเทนเนอร์และบุคคล ตลอดทางกลับไปที่ผู้พัฒนาต้นน้ำ นักเทียบท่ายังใช้การอัปโหลดและดาวน์โหลดเพิ่มเติมเช่นเดียวกับ "git pull" ดังนั้นเวอร์ชันใหม่ของคอนเทนเนอร์สามารถถ่ายโอนได้โดยการส่ง diffs เท่านั้น
นำส่วนประกอบกลับมาใช้ใหม่ คอนเทนเนอร์ใด ๆ สามารถใช้เป็น "ภาพฐาน" เพื่อสร้างส่วนประกอบพิเศษเพิ่มเติม ซึ่งสามารถทำได้ด้วยตนเองหรือเป็นส่วนหนึ่งของการสร้างอัตโนมัติ ตัวอย่างเช่นคุณสามารถเตรียมสภาพแวดล้อมของงูใหญ่ที่เหมาะสมที่สุดและใช้เป็นฐานสำหรับ 10 แอปพลิเคชันที่แตกต่างกัน การตั้งค่า postgresql ในอุดมคติของคุณสามารถนำมาใช้ใหม่สำหรับโครงการในอนาคตของคุณทั้งหมด และอื่น ๆ
ที่ใช้ร่วมกัน นักเทียบท่ามีการเข้าถึงรีจิสตรีสาธารณะ ( https://registry.hub.docker.com/ ) ที่มีผู้คนนับพันอัปโหลดคอนเทนเนอร์ที่มีประโยชน์: สิ่งใดก็ตามจาก Redis, couchdb, postgres ไปยัง bouncers irc ไปจนถึงราวแอพเซิร์ฟเวอร์ของแอพ distros ต่างๆ รีจิสตรียังมี "ไลบรารีมาตรฐาน" อย่างเป็นทางการของคอนเทนเนอร์ที่มีประโยชน์ซึ่งดูแลโดยทีมนักเทียบท่า รีจิสตรีเองนั้นเป็นโอเพ่นซอร์สดังนั้นใครก็ตามสามารถปรับใช้รีจิสตรีของตัวเองเพื่อจัดเก็บและถ่ายโอนคอนเทนเนอร์ส่วนตัวสำหรับการปรับใช้เซิร์ฟเวอร์ภายในเช่น
เครื่องมือระบบนิเวศ นักเทียบท่ากำหนด API สำหรับการทำให้เป็นอัตโนมัติและปรับแต่งการสร้างและการปรับใช้ภาชนะ มีเครื่องมือจำนวนมากที่ทำงานร่วมกับนักเทียบท่าเพื่อขยายขีดความสามารถ การปรับใช้ที่เหมือน PaaS (Dokku, Deis, Flynn), orchestration หลายโหนด (มาสโทร, เกลือ, Mesos, openstack nova), แดชบอร์ดการจัดการ (นักเทียบท่า-UI, openstack ขอบฟ้า, อู่ต่อเรือ), การจัดการการกำหนดค่า (เชฟหุ่นกระบอก) (jenkins, strider, travis) ฯลฯ Docker กำลังสร้างตัวเองอย่างรวดเร็วเป็นมาตรฐานสำหรับการใช้เครื่องมือที่ใช้ภาชนะ

ฉันหวังว่านี่จะช่วยได้!

— โซโลมอน Hykes
แหล่งที่มา

3

เมื่อคุณพูดว่า "คอนเทนเนอร์ใด ๆ สามารถใช้เป็นอิมเมจพื้นฐาน" ได้ฉันถือว่าคุณหมายถึงคอนเทนเนอร์ Docker ไม่ใช่คอนเทนเนอร์ LXC ที่สร้างขึ้นโดยอิสระจาก Docker เท่าที่ฉันสามารถบอกได้ว่าไม่มีใครสามารถสร้าง Docker container ได้ตั้งแต่ต้น แต่จะต้องสืบทอดจาก Docker container ตัวอื่นเสมอ (คำถามที่เกี่ยวข้อง: stackoverflow.com/questions/18274088/… )

— Flimm

18

คุณสามารถสร้างคอนเทนเนอร์ใหม่ได้อย่างง่ายดายจาก tarball ใด ๆ ด้วย "นำเข้านักเทียบท่า" ตัวอย่างเช่น: "debootstrap raring ./rootfs; tar -C ./rootfs -c. | docker import flimm / mybase"

— โซโลมอน Hykes

3

นี้ยังคงเป็นจริงในขณะนี้ที่นักเทียบท่ามี libcontainer (ซึ่งไม่ใช่การทดแทน)?

— Garet Claborn

3

@GaretClaborn ใช่เนื่องจาก libcontainer เป็นเพียงห้องสมุดของตัวเองในการเข้าถึงเนมสเปซและกลุ่ม cg ทุกอย่างที่โซโลมอนกล่าวยังคงใช้อยู่

— John Morales

10

คอนเทนเนอร์ Linux เป็นผลมาจากการ จำกัด และแยกกระบวนการโดยใช้ชุดเครื่องมืออำนวยความสะดวกของ Linux: chroot, cgroups, และ namespaces LXC เป็นเครื่องมือ userspace ที่จัดการกับสิ่งอำนวยความสะดวกเหล่านั้น libcontainer เป็นอีกทางเลือกหนึ่งของ LXC ที่จัดการกับสิ่งอำนวยความสะดวกเดียวกันเหล่านั้น นักเทียบท่าใช้ libcontainer เป็นค่าเริ่มต้น แต่สามารถใช้ LXC แทน ที่กล่าวว่า Docker เป็นมากกว่าชั้นความเข้ากันได้ที่ด้านบนของ libcontainer / LXC; มันเพิ่มคุณสมบัติเพิ่มเติมที่คำตอบอื่น ๆ ที่ระบุไว้

— user100464

71

ลองมาดูรายการคุณสมบัติทางเทคนิคของ Dockerและตรวจสอบว่า LXC นั้นเป็นรุ่นใดบ้าง

คุณสมบัติ:

1) การแยกระบบไฟล์ : แต่ละคอนเทนเนอร์กระบวนการทำงานในระบบไฟล์รูทที่แยกจากกันอย่างสมบูรณ์

จัดเตรียมด้วย LXC ธรรมดา

2) การแยกทรัพยากร : ทรัพยากรระบบเช่น cpu และหน่วยความจำสามารถจัดสรรให้แตกต่างกันไปในแต่ละกระบวนการของคอนเทนเนอร์โดยใช้ cgroups

จัดเตรียมด้วย LXC ธรรมดา

3) การแยกเครือข่าย : แต่ละกระบวนการคอนเทนเนอร์จะทำงานในเนมสเปซเครือข่ายของตนเองพร้อมด้วยอินเตอร์เฟสเสมือนและที่อยู่ IP ของตนเอง

จัดเตรียมด้วย LXC ธรรมดา

4) Copy-on-write : ระบบไฟล์รูทสร้างขึ้นโดยใช้ copy-on-write ซึ่งทำให้การปรับใช้รวดเร็วมากหน่วยความจำราคาถูกและดิสก์ราคาถูก

สิ่งนี้จัดทำโดย AUFS ซึ่งเป็นระบบไฟล์รวมที่นักเทียบท่าขึ้นอยู่กับ คุณสามารถตั้งค่า AUFS ด้วยตนเองได้ด้วย LXC แต่นักเทียบท่าใช้มันเป็นมาตรฐาน

5) การบันทึก : สตรีมมาตรฐาน (stdout / stderr / stdin) ของแต่ละคอนเทนเนอร์กระบวนการจะถูกรวบรวมและบันทึกสำหรับการดึงแบบเรียลไทม์หรือแบทช์

นักเทียบท่าให้สิ่งนี้

6) การจัดการการเปลี่ยนแปลง: การเปลี่ยนแปลงระบบไฟล์ของคอนเทนเนอร์สามารถถูกกำหนดเป็นรูปภาพใหม่และนำมาใช้ใหม่เพื่อสร้างคอนเทนเนอร์เพิ่มเติม ไม่ต้องกำหนดค่า templating หรือกำหนดเอง

"Templating หรือการกำหนดค่าด้วยตนเอง" เป็นการอ้างอิงถึง LXC ซึ่งคุณจะต้องเรียนรู้เกี่ยวกับทั้งสองสิ่งนี้ นักเทียบท่าช่วยให้คุณรักษาภาชนะบรรจุในแบบที่คุณคุ้นเคยกับการรักษาเครื่องเสมือนโดยไม่ต้องเรียนรู้เกี่ยวกับการกำหนดค่า LXC

7) Interactive shell : นักเทียบท่าสามารถจัดสรร pseudo-tty และแนบกับอินพุตมาตรฐานของคอนเทนเนอร์ใด ๆ ตัวอย่างเช่นเพื่อรันเชลล์แบบโต้ตอบที่ถูกทิ้งไว้

LXC ได้มอบสิ่งนี้แล้ว

ฉันเพิ่งเริ่มเรียนรู้เกี่ยวกับ LXC และ Docker ดังนั้นฉันจึงยินดีรับการแก้ไขหรือคำตอบที่ดีกว่า

— Flimm
แหล่งที่มา

35

IMHO คำตอบนี้หายไปจากจุด นักเทียบท่าไม่ได้ "ให้" คุณสมบัติเหล่านั้น มันเพียงทำให้พวกเขาใช้งานง่ายเล็กน้อย ถ้าเราต้องการที่จะเป็น nitpicky เราสามารถพูดได้ว่า LXC ไม่ได้แยก: namespacesให้มันและ LXC เป็นเพียงเครื่องมือผู้ใช้สินค้าเพื่อให้พวกเขาใช้งานง่ายกว่าด้วยunshareเครื่องมือพื้นฐาน(หรือโดยตรงclone()syscall) ในทำนองเดียวกันนักเทียบท่าทำให้สิ่งเหล่านั้นใช้งานง่ายขึ้น (และนำคุณสมบัติเพิ่มเติมมากมายบนโต๊ะเช่นความสามารถในการผลัก / ดึงภาพ) 2c ของฉัน

— jpetazzo

6

@jpetazzo: LXC เป็นเรื่องง่ายจริง ๆ แล้ว Docker ทำให้มันง่ายขึ้นได้อย่างไร (นอกเหนือจากการเพิ่มคุณสมบัติอื่น ๆ เช่นการกดและดึงภาพ)

— Flimm

31

@Flimm: ฉันชอบการเปรียบเทียบในฉบับที่ 16 ของนิตยสารผู้ดูแลระบบหน้า38 34: Docker รวม LXC เข้ากับเทคโนโลยีสนับสนุนอื่น ๆ แล้วห่อไว้ในอินเตอร์เฟสบรรทัดคำสั่งที่ใช้งานง่าย ใช้ภาชนะที่เป็นบิตเช่นพยายามที่จะใช้ Git มีคำสั่งเช่นเดียวupdate-indexและread-treeโดยไม่มีเครื่องมือที่คุ้นเคยชอบadd, และcommit mergeนักเทียบท่าแสดงเลเยอร์ "ลายคราม" เหนือ "plumbing" ของ LXC ช่วยให้คุณทำงานกับแนวคิดระดับสูงขึ้นและไม่ต้องกังวลกับรายละเอียดระดับต่ำ

— 0xC0000022L

4

ฉันใช้เกณฑ์มาตรฐาน UnixBench ภายในคอนเทนเนอร์นักเทียบท่าและคอนเทนเนอร์ LXC ใช้ระบบปฏิบัติการเดียวกันและ LXC มีคะแนนดีกว่า การเป็นนักเทียบท่าตาม LXC ฉันรู้สึกสับสนมากเกี่ยวกับผลลัพธ์ของฉัน

— gextra

7

สำหรับฉันดูเหมือนว่าประสิทธิภาพที่ช้ากว่าของ Docker นั้นเกี่ยวข้องกับดิสก์ I / O ดังนั้นอาจเกิดจากการใช้ AUFS

— gextra

16

โพสต์ดังกล่าวข้างต้นและคำตอบอย่างรวดเร็วกลายเป็นวันที่การพัฒนาLXD ยังคงเพิ่ม LXC ใช่ฉันรู้ว่านักเทียบท่ายังไม่หยุดนิ่งเช่นกัน

ตอนนี้ LXD ใช้ที่เก็บสำหรับอิมเมจคอนเทนเนอร์ LXC ซึ่งผู้ใช้สามารถผลัก / ดึงจากเพื่อสนับสนุนหรือนำมาใช้ซ้ำ

REST api to LXCของ LXD ตอนนี้เปิดใช้งานการสร้าง / ปรับใช้ / การจัดการ / ระยะไกลของคอนเทนเนอร์ LXC โดยใช้ไวยากรณ์คำสั่งที่ง่ายมาก

คุณสมบัติที่สำคัญของ LXD คือ:

รักษาความปลอดภัยด้วยการออกแบบ (คอนเทนเนอร์ที่ไม่มีสิทธิใช้งานข้อ จำกัด ทรัพยากรและอื่น ๆ อีกมากมาย)
ปรับขนาดได้ (จากคอนเทนเนอร์บนแล็ปท็อปของคุณไปยังโหนดคำนวณนับพัน)
ใช้งานง่าย (API ที่ง่ายและชัดเจนและประสบการณ์บรรทัดคำสั่งที่คมชัด)
ภาพที่ใช้ (ไม่มีเทมเพลตการกระจายภาพที่ดีและเชื่อถือได้เท่านั้น)

มีNCLXD ปลั๊กอินในขณะนี้สำหรับการอนุญาตให้ OpenStack OpenStackที่จะใช้ในการปรับใช้ LXD / จัดการภาชนะบรรจุ LXC เป็น VMs ใน OpenStack แทนการใช้ KVM, VMware ฯลฯ

อย่างไรก็ตาม NCLXD ยังเปิดใช้งานไฮบริดคลาวด์ของการผสมผสานระหว่าง HW VM แบบดั้งเดิมและ LXC VM

ปลั๊กอิน OpenStack nclxd รายการคุณลักษณะที่รองรับรวมถึง:

stop/start/reboot/terminate container
Attach/detach network interface
Create container snapshot
Rescue/unrescue instance container
Pause/unpause/suspend/resume container
OVS/bridge networking
instance migration
firewall support

ตามเวลาที่อูบุนตู 16.04 ถูกปล่อยออกมาในเดือน เม.ย. 2016 จะได้รับเย็นคุณสมบัติเพิ่มเติมเช่นการสนับสนุนอุปกรณ์ป้องกันการสนับสนุนการถ่ายทอดสดการโยกย้าย

— bmullan
แหล่งที่มา

4

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

นอกเหนือจากนั้น Docker Hub ยังเป็นรีจิสตรีที่มีภาพสาธารณะนับพันภาพซึ่งคุณสามารถค้นหาภาพที่ติดตั้งระบบปฏิบัติการและซอฟต์แวร์อื่น ๆ ดังนั้นคุณสามารถเริ่มต้นที่ดีงามสำหรับใบสมัครของคุณ

— div
แหล่งที่มา

เมื่อคุณพูดว่า "เลเยอร์ในตัว" - ความหมาย - (A) สำเนาของเลเยอร์ฐานดัดแปลงและมุ่งมั่นกับเลเยอร์ "ใหม่" ดังนั้นชั้นฐานถูกตัดการเชื่อมต่อจากชั้นถัดไปหรือไม่ (B) เลเยอร์ฐานเป็น / รวมอยู่ในเลเยอร์ "ใหม่" และเชื่อมโยงแล้ว ดังนั้นการเปลี่ยนแปลงในเลเยอร์พื้นฐานจะสะท้อนไปยังเลเยอร์ "ใหม่" โดยอัตโนมัติ ขออภัยหากคำชี้แจงที่ขอนั้นไร้เดียงสาเกินไป :( Kapil

— Kapil

ภาพนักเทียบท่าถูกสร้างขึ้นในเลเยอร์ หากต้องการใส่คำที่เป็นเม็ดเล็ก ๆ การเปลี่ยนแปลงทั้งหมดจะเกิดขึ้นเมื่อถึงจุดที่มีการมอบหมายเลเยอร์ไว้ในเลเยอร์ของภาพที่ทำจนกระทั่งถึงจุดนั้น การเปลี่ยนแปลงใด ๆ ที่เกิดขึ้นหลังจากนั้นจะถูกเพิ่มในเลเยอร์ถัดไปและเหนือ ดังนั้นเลเยอร์ใหม่จะเชื่อมโยงกับชั้นฐาน ฉันไม่คิดว่าเลเยอร์ใหม่เดียวกันสามารถเพิ่มลงในเลเยอร์ฐานที่แตกต่างกันได้พร้อมกับการเปลี่ยนแปลงเพิ่มเติม อย่างไรก็ตามถ้าเอนทิตีหลายรายการต้องการรักษาความมั่นคงและมีเลเยอร์พื้นฐานเหมือนกันดังนั้นจะต้องมอบเลเยอร์ใหม่ให้กับเอนทิตีเหล่านี้เพื่อให้อยู่ในสถานะเดียวกัน

— div

อย่างไรก็ตามฉันไม่ได้อัปเดตเกี่ยวกับการพัฒนาในปัจจุบันของนักเทียบท่าและอาจมีการเปลี่ยนแปลงในการใช้งานรูปภาพของนักเทียบท่าที่ไม่ได้กล่าวถึงในความคิดเห็นด้านบน

— div

หากต้องการเจาะจงมากขึ้นเลเยอร์จะถูกระบุด้วยลายเซ็น (SHA- บางสิ่งบางอย่างฉันเชื่อว่า) ซึ่งหมายความว่าหากคุณเปลี่ยนเลเยอร์มันเป็นเลเยอร์ที่แตกต่างกัน @Kapil: นั่นหมายความว่าแม้ว่าพฤติกรรมของมันจะใกล้กับตัวเลือกของคุณ (B) แต่คุณไม่สามารถทำการเปลี่ยนแปลงเลเยอร์ฐานได้ (หรือเลเยอร์ใด ๆ สำหรับเรื่องนั้น) ภาพถูกสร้างขึ้นจากรายการของเลเยอร์โดยแต่ละภาพจะถูกนำไปใช้ตามลำดับ สามารถทำความสะอาดเลเยอร์ได้ (และฉันคิดว่ามันจะทำความสะอาดโดยนักเทียบท่าเองโดยอัตโนมัติ) เมื่อไม่ต้องการใช้อีกต่อไป กล่าวคือเมื่อลบรูปภาพอ้างอิงทั้งหมดแล้ว

— codermonkeyfuel

@Kapil: โดยสุจริตคำถามของคุณอาจจะดีที่สุดเป็นคำถามใหม่แทนที่จะเป็นความคิดเห็นในคำถามนี้เนื่องจากเป็นคำถามที่มีประโยชน์สำหรับคนที่จะสามารถค้นหาด้วยตัวเอง หากคุณต้องการถามเป็นคำถามใหม่ฉันจะตอบด้วย

— codermonkeyfuel

0

จะเก็บเงินจำนวนเล็กน้อยนี้จะถูกถามและตอบ ไปแล้วข้างต้น

ฉันจะถอยกลับและตอบมันแตกต่างกันเล็กน้อยตัวเชื่อมต่อเครื่องยนต์เพิ่มการเชื่อมต่อเข้าด้วยกันเป็นหนึ่งในความพิเศษและนี่คือส่วนที่ก่อกวน เมื่อคุณเริ่มใช้งานแอปด้วยการรวมกันของตู้คอนเทนเนอร์ที่ใช้ 'ที่ใดที่หนึ่ง' ในหลาย ๆ ตู้คอนเทนเนอร์มันน่าตื่นเต้นมาก ความแข็งแกร่ง, การขยายในแนวนอน, การทำให้เป็นนามธรรมอย่างสมบูรณ์จากฮาร์ดแวร์ที่อยู่ข้างใต้ฉันสามารถดำเนินการต่อไป ...

มันไม่ใช่แค่นักเทียบท่าที่ให้สิ่งนี้ในความเป็นจริงมาตรฐานพฤตินัย Container Orchestration คือ Kubernetes ที่มาในหลากหลายรสชาติหนึ่งนักเทียบท่า แต่ยัง OpenShift, SuSe, Azure, AWS ...

จากนั้นภายใต้ K8S จะมีเครื่องยนต์คอนเทนเนอร์สำรอง สิ่งที่น่าสนใจคือ Docker และ CRIO ซึ่งเพิ่งถูกสร้างขึ้นไม่น่าไว้วางใจเพื่อใช้เป็นตู้คอนเทนเนอร์สำหรับ Kubernetes แต่ยังไม่สมบูรณ์ การแข่งขันระหว่างสิ่งเหล่านี้ที่ฉันคิดว่าจะเป็นตัวเลือกระยะยาวที่แท้จริงสำหรับเครื่องยนต์คอนเทนเนอร์

— จะ Rothwell
แหล่งที่มา