เริ่มเมื่อวันที่ 10 สิงหาคมใน Slurm ซึ่งเราวิเคราะห์อย่างสมบูรณ์ - ตั้งแต่นามธรรมพื้นฐานไปจนถึงพารามิเตอร์เครือข่าย
ในบทความนี้เราจะพูดถึงประวัติของ Docker และบทคัดย่อหลัก: Image, Cli, Dockerfile การบรรยายนี้มีไว้สำหรับผู้เริ่มต้น ดังนั้นจึงไม่น่าจะน่าสนใจสำหรับผู้ใช้ที่มีประสบการณ์ จะไม่มีเลือด ไส้ติ่ง หรือการแช่ลึก พื้นฐานสุดๆ.
นักเทียบท่าคืออะไร
มาดูคำจำกัดความของ Docker จาก Wikipedia กัน
Docker เป็นซอฟต์แวร์สำหรับการปรับใช้และการจัดการแอปพลิเคชันในสภาพแวดล้อมแบบคอนเทนเนอร์โดยอัตโนมัติ
ไม่มีสิ่งใดที่ชัดเจนจากคำจำกัดความนี้ ยังไม่ชัดเจนว่า "ในสภาพแวดล้อมที่รองรับการบรรจุคอนเทนเนอร์" หมายถึงอะไร เพื่อหาคำตอบ เรามาย้อนเวลากลับไปกันเถอะ เรามาเริ่มกันที่ยุคที่ผมเรียกตามอัตภาพว่า “ยุคเสาหิน”
ยุคเสาหิน
ยุคเสาหินคือช่วงต้นทศวรรษ 2000 เมื่อแอปพลิเคชันทั้งหมดเป็นแบบเสาหินและมีการพึ่งพามากมาย การพัฒนาใช้เวลานาน ในเวลาเดียวกัน มีเซิร์ฟเวอร์ไม่มากนัก เราทุกคนรู้จักชื่อและเฝ้าติดตามพวกเขา มีการเปรียบเทียบที่ตลกเช่นนี้:
สัตว์เลี้ยงเป็นสัตว์เลี้ยงในบ้าน ในยุคหินใหญ่ เราปฏิบัติต่อเซิร์ฟเวอร์ของเราเหมือนสัตว์เลี้ยง ได้รับการดูแลเอาใจใส่เป็นอย่างดี และพัดพาฝุ่นละอองออกไป และเพื่อการจัดการทรัพยากรที่ดีขึ้น เราใช้การจำลองเสมือน: เรานำเซิร์ฟเวอร์มาและตัดออกเป็นเครื่องเสมือนหลายเครื่อง ดังนั้นจึงรับประกันการแยกสภาพแวดล้อม
ระบบเสมือนจริงที่ใช้ไฮเปอร์ไวเซอร์
ทุกคนคงเคยได้ยินเกี่ยวกับระบบเสมือนจริง: VMware, VirtualBox, Hyper-V, Qemu KVM ฯลฯ พวกเขาให้การแยกแอปพลิเคชันและการจัดการทรัพยากร แต่ก็มีข้อเสียเช่นกัน หากต้องการทำเวอร์ช่วลไลเซชั่น คุณต้องมีไฮเปอร์ไวเซอร์ และไฮเปอร์ไวเซอร์ก็เป็นค่าใช้จ่ายด้านทรัพยากร และเครื่องเสมือนนั้นมักจะเป็นยักษ์ใหญ่ทั้งหมด - อิมเมจขนาดใหญ่ที่มีระบบปฏิบัติการ, Nginx, Apache และอาจเป็น MySQL รูปภาพมีขนาดใหญ่และเครื่องเสมือนใช้งานไม่สะดวก ส่งผลให้การทำงานกับเครื่องเสมือนอาจช้าลง เพื่อแก้ไขปัญหานี้ ระบบเสมือนจริงจึงถูกสร้างขึ้นในระดับเคอร์เนล
ระบบเสมือนจริงระดับเคอร์เนล
การจำลองเสมือนระดับเคอร์เนลรองรับโดยระบบ OpenVZ, Systemd-nspawn, LXC ตัวอย่างที่ชัดเจนของการจำลองเสมือนคือ LXC (Linux Containers)
LXC คือระบบการจำลองเสมือนระดับระบบปฏิบัติการสำหรับการรันอินสแตนซ์ที่แยกได้หลายอินสแตนซ์ของระบบปฏิบัติการ Linux บนโหนดเดียว LXC ไม่ได้ใช้เครื่องเสมือน แต่สร้างสภาพแวดล้อมเสมือนจริงด้วยพื้นที่กระบวนการและสแต็กเครือข่ายของตัวเอง
โดยพื้นฐานแล้ว LXC สร้างคอนเทนเนอร์ ความแตกต่างระหว่างเครื่องเสมือนและคอนเทนเนอร์คืออะไร?
คอนเทนเนอร์ไม่เหมาะสำหรับการแยกกระบวนการ: พบช่องโหว่ในระบบเวอร์ช่วลไลเซชั่นที่ระดับเคอร์เนลซึ่งทำให้สามารถหลบหนีจากคอนเทนเนอร์ไปยังโฮสต์ได้ ดังนั้น หากคุณต้องการแยกบางสิ่งออก ควรใช้เครื่องเสมือนจะดีกว่า
ความแตกต่างระหว่างการจำลองเสมือนและคอนเทนเนอร์สามารถดูได้ในแผนภาพ
มีไฮเปอร์ไวเซอร์ฮาร์ดแวร์ ไฮเปอร์ไวเซอร์ที่ด้านบนของระบบปฏิบัติการ และคอนเทนเนอร์
ไฮเปอร์ไวเซอร์ของฮาร์ดแวร์นั้นยอดเยี่ยมหากคุณต้องการแยกบางสิ่งออกจากกัน เนื่องจากสามารถแยกได้ที่ระดับเพจหน่วยความจำและโปรเซสเซอร์
มีไฮเปอร์ไวเซอร์เป็นโปรแกรมและมีคอนเทนเนอร์และเราจะพูดถึงพวกเขาเพิ่มเติม ระบบคอนเทนเนอร์ไม่มีไฮเปอร์ไวเซอร์ แต่มี Container Engine ที่สร้างและจัดการคอนเทนเนอร์ สิ่งนี้มีน้ำหนักเบากว่า ดังนั้นเนื่องจากการทำงานกับแกนกลางจึงมีค่าใช้จ่ายน้อยลงหรือไม่มีเลย
สิ่งที่ใช้สำหรับการบรรจุคอนเทนเนอร์ในระดับเคอร์เนล
เทคโนโลยีหลักที่ช่วยให้คุณสามารถสร้างคอนเทนเนอร์ที่แยกได้จากกระบวนการอื่นคือ เนมสเปซและกลุ่มควบคุม
เนมสเปซ: PID, ระบบเครือข่าย, เมาท์และผู้ใช้ ยังมีอีกมากมาย แต่เพื่อความสะดวกในการทำความเข้าใจ เราจะเน้นไปที่สิ่งเหล่านี้
PID Namespace จำกัดกระบวนการ ตัวอย่างเช่น เมื่อเราสร้าง PID Namespace และวางกระบวนการไว้ที่นั่น กระบวนการนั้นจะกลายเป็น PID 1 โดยปกติในระบบ PID 1 จะเป็น systemd หรือ init ดังนั้นเมื่อเราวางกระบวนการในเนมสเปซใหม่ กระบวนการนั้นจะได้รับ PID 1 ด้วย
Networking Namespace ช่วยให้คุณสามารถจำกัด/แยกเครือข่าย และวางอินเทอร์เฟซของคุณเองไว้ภายในได้ Mount เป็นข้อจำกัดของระบบไฟล์ ผู้ใช้—ข้อจำกัดสำหรับผู้ใช้
กลุ่มควบคุม: หน่วยความจำ, CPU, IOPS, เครือข่าย - รวมการตั้งค่าประมาณ 12 รายการ มิฉะนั้นจะเรียกว่า Cgroups (“C-groups”)
กลุ่มควบคุมจัดการทรัพยากรสำหรับคอนเทนเนอร์ ผ่านกลุ่มควบคุมเราสามารถพูดได้ว่าคอนเทนเนอร์ไม่ควรใช้ทรัพยากรเกินจำนวนที่กำหนด
เพื่อให้การทำงานของคอนเทนเนอร์ทำงานได้อย่างเต็มที่ มีการใช้เทคโนโลยีเพิ่มเติม ได้แก่ ความสามารถ การคัดลอกเมื่อเขียน และอื่นๆ
ความสามารถคือการที่เราบอกกระบวนการว่าอะไรทำได้และทำไม่ได้ ในระดับเคอร์เนล สิ่งเหล่านี้เป็นเพียงบิตแมปที่มีพารามิเตอร์มากมาย ตัวอย่างเช่น ผู้ใช้รูทมีสิทธิ์เต็มที่และสามารถทำทุกอย่างได้ เซิร์ฟเวอร์เวลาสามารถเปลี่ยนเวลาของระบบได้: มีความสามารถบน Time Capsule เท่านี้ก็เรียบร้อย การใช้สิทธิพิเศษทำให้คุณสามารถกำหนดค่าข้อจำกัดสำหรับกระบวนการได้อย่างยืดหยุ่น และด้วยเหตุนี้จึงเป็นการปกป้องตัวคุณเอง
ระบบ Copy-on-write ช่วยให้เราสามารถทำงานกับอิมเมจ Docker และใช้งานได้อย่างมีประสิทธิภาพมากขึ้น
ขณะนี้ Docker มีปัญหาความเข้ากันได้กับ Cgroups v2 ดังนั้นบทความนี้จึงเน้นไปที่ Cgroups v1 โดยเฉพาะ
แต่ขอกลับไปสู่ประวัติศาสตร์
เมื่อระบบการจำลองเสมือนปรากฏขึ้นในระดับเคอร์เนล ระบบก็เริ่มมีการใช้งานอย่างแข็งขัน ค่าใช้จ่ายบนไฮเปอร์ไวเซอร์หายไป แต่ปัญหายังคงอยู่:
- รูปภาพขนาดใหญ่: พวกเขาผลักดันระบบปฏิบัติการ, ไลบรารี, ซอฟต์แวร์ต่าง ๆ จำนวนมากลงใน OpenVZ เดียวกันและในที่สุดรูปภาพก็ยังมีขนาดค่อนข้างใหญ่
- ไม่มีมาตรฐานปกติสำหรับการบรรจุและการจัดส่ง ดังนั้นปัญหาการพึ่งพายังคงอยู่ มีสถานการณ์ที่โค้ดสองชิ้นใช้ไลบรารีเดียวกัน แต่มีเวอร์ชันต่างกัน อาจมีความขัดแย้งระหว่างพวกเขา
เพื่อแก้ไขปัญหาทั้งหมดนี้ ยุคต่อไปได้มาถึงแล้ว
ยุคตู้คอนเทนเนอร์
เมื่อยุคของคอนเทนเนอร์มาถึง ปรัชญาในการทำงานกับคอนเทนเนอร์ก็เปลี่ยนไป:
- หนึ่งกระบวนการ - หนึ่งคอนเทนเนอร์
- เราส่งมอบการพึ่งพาทั้งหมดที่กระบวนการต้องการไปยังคอนเทนเนอร์ สิ่งนี้จำเป็นต้องตัดเสาหินออกเป็นไมโครเซอร์วิส
- ยิ่งรูปภาพเล็กลงก็ยิ่งดี - มีช่องโหว่ที่เป็นไปได้น้อยลง รูปภาพจะเผยแพร่เร็วขึ้น และอื่นๆ
- อินสแตนซ์กลายเป็นเพียงชั่วคราว
จำสิ่งที่ฉันพูดเกี่ยวกับสัตว์เลี้ยงกับวัวได้ไหม? ก่อนหน้านี้ตัวอย่างก็เหมือนกับสัตว์เลี้ยง แต่ตอนนี้กลายเป็นเหมือนวัวควาย ก่อนหน้านี้มีเสาหิน - แอปพลิเคชันเดียว ตอนนี้เป็น 100 ไมโครเซอร์วิส 100 คอนเทนเนอร์ คอนเทนเนอร์บางตัวอาจมีแบบจำลอง 2-3 อัน มันมีความสำคัญน้อยลงสำหรับเราในการควบคุมทุกคอนเทนเนอร์ สิ่งที่สำคัญกว่าสำหรับเราคือความพร้อมใช้งานของบริการ: สิ่งที่ชุดคอนเทนเนอร์นี้ทำ การเปลี่ยนแปลงแนวทางการติดตามผลนี้
ในปี 2014-2015 Docker มีความเจริญรุ่งเรือง - เทคโนโลยีที่เราจะพูดถึงในตอนนี้
นักเทียบท่าเปลี่ยนปรัชญาและบรรจุภัณฑ์แอปพลิเคชันมาตรฐาน การใช้ Docker ทำให้เราสามารถจัดแพคเกจแอปพลิเคชัน ส่งไปยังพื้นที่เก็บข้อมูล ดาวน์โหลดจากที่นั่น และปรับใช้ได้
เราใส่ทุกสิ่งที่เราต้องการลงในคอนเทนเนอร์ Docker ดังนั้นปัญหาการพึ่งพาจึงได้รับการแก้ไข นักเทียบท่ารับประกันความสามารถในการทำซ้ำ ฉันคิดว่าหลายๆ คนต้องเผชิญกับความไม่สามารถทำซ้ำได้ ทุกอย่างได้ผลสำหรับคุณ คุณผลักดันมันไปสู่การผลิต และที่นั่นมันจะหยุดทำงาน ด้วย Docker ปัญหานี้จะหายไป หากคอนเทนเนอร์ Docker ของคุณเริ่มทำงานและทำสิ่งที่จำเป็นต้องทำ มีความเป็นไปได้สูงที่คอนเทนเนอร์จะเริ่มใช้งานจริงและทำเช่นเดียวกันที่นั่น
การพูดนอกเรื่องเกี่ยวกับค่าใช้จ่าย
มีข้อพิพาทเกี่ยวกับค่าโสหุ้ยอยู่เสมอ บางคนเชื่อว่า Docker ไม่มีภาระเพิ่มเติม เนื่องจากใช้เคอร์เนล Linux และกระบวนการทั้งหมดที่จำเป็นสำหรับการบรรจุคอนเทนเนอร์ เช่น “ถ้าคุณบอกว่า Docker โอเวอร์เฮด เคอร์เนล Linux ก็โอเวอร์เฮด”
ในทางกลับกัน หากคุณมองให้ลึกลงไป มีหลายสิ่งใน Docker ที่สามารถพูดได้ว่าอยู่เหนือศีรษะ
อย่างแรกคือเนมสเปซ PID เมื่อเราวางกระบวนการในเนมสเปซ กระบวนการนั้นจะถูกกำหนด PID 1 ในเวลาเดียวกัน กระบวนการนี้มี PID อื่นซึ่งอยู่บนเนมสเปซโฮสต์ นอกคอนเทนเนอร์ ตัวอย่างเช่น เราเปิดตัว Nginx ในคอนเทนเนอร์ ซึ่งกลายเป็น PID 1 (กระบวนการหลัก) และบนโฮสต์นั้นมี PID 12623 และเป็นการยากที่จะบอกว่ามีค่าใช้จ่ายเท่าใด
สิ่งที่สองคือ Cgroups ลองใช้ Cgroups ตามหน่วยความจำนั่นคือความสามารถในการจำกัดหน่วยความจำของคอนเทนเนอร์ เมื่อเปิดใช้งาน ตัวนับและบัญชีหน่วยความจำจะถูกเปิดใช้งาน: เคอร์เนลจำเป็นต้องเข้าใจว่ามีการจัดสรรเพจจำนวนเท่าใดและจำนวนเพจที่ยังว่างสำหรับคอนเทนเนอร์นี้ นี่อาจเป็นค่าใช้จ่าย แต่ฉันไม่เคยเห็นการศึกษาที่ชัดเจนเกี่ยวกับผลกระทบต่อประสิทธิภาพการทำงาน และตัวฉันเองไม่ได้สังเกตว่าแอปพลิเคชันที่ทำงานใน Docker ประสบกับประสิทธิภาพที่ลดลงอย่างมาก
และอีกหนึ่งหมายเหตุเกี่ยวกับประสิทธิภาพ พารามิเตอร์เคอร์เนลบางตัวถูกส่งผ่านจากโฮสต์ไปยังคอนเทนเนอร์ โดยเฉพาะพารามิเตอร์เครือข่ายบางตัว ดังนั้น หากคุณต้องการเรียกใช้สิ่งที่มีประสิทธิภาพสูงใน Docker เช่น สิ่งที่จะใช้เครือข่าย อย่างน้อยที่สุดคุณก็จำเป็นต้องปรับพารามิเตอร์เหล่านี้ ตัวอย่างเช่น nf_conntrack บางตัว
เกี่ยวกับแนวคิดนักเทียบท่า
นักเทียบท่าประกอบด้วยองค์ประกอบหลายอย่าง:
- Docker Daemon เป็น Container Engine เดียวกัน เปิดตัวคอนเทนเนอร์
- Docker CII เป็นยูทิลิตี้การจัดการ Docker
- Dockerfile - คำแนะนำในการสร้างอิมเมจ
- รูปภาพ — รูปภาพที่ใช้เปิดคอนเทนเนอร์
- ภาชนะ
- รีจิสทรีนักเทียบท่าเป็นที่เก็บรูปภาพ
แผนผังมีลักษณะดังนี้:
Docker daemon ทำงานบน Docker_host และเปิดตัวคอนเทนเนอร์ มีไคลเอนต์ที่ส่งคำสั่ง: สร้างอิมเมจ, ดาวน์โหลดอิมเมจ, เปิดคอนเทนเนอร์ Docker daemon ไปที่รีจิสทรีและดำเนินการ ไคลเอ็นต์ Docker สามารถเข้าถึงได้ทั้งภายในเครื่อง (ไปยังซ็อกเก็ต Unix) และผ่าน TCP จากโฮสต์ระยะไกล
เรามาดูแต่ละองค์ประกอบกัน
นักเทียบท่าเดมอน - นี่คือส่วนของเซิร์ฟเวอร์ ซึ่งทำงานบนเครื่องโฮสต์: ดาวน์โหลดอิมเมจและเปิดใช้คอนเทนเนอร์จากอิมเมจ สร้างเครือข่ายระหว่างคอนเทนเนอร์ รวบรวมบันทึก เมื่อเราพูดว่า "สร้างภาพ" ปีศาจก็ทำอย่างนั้นเช่นกัน
นักเทียบท่า CLI — ส่วนไคลเอ็นต์ Docker ซึ่งเป็นยูทิลิตี้คอนโซลสำหรับการทำงานกับ daemon ฉันขอย้ำอีกครั้งว่ามันสามารถทำงานได้ไม่เพียงแต่ในพื้นที่เท่านั้น แต่ยังทำงานผ่านเครือข่ายด้วย
คำสั่งพื้นฐาน:
docker ps - แสดงคอนเทนเนอร์ที่กำลังทำงานบนโฮสต์ Docker
ภาพนักเทียบท่า - แสดงภาพที่ดาวน์โหลดในเครื่อง
ค้นหานักเทียบท่า <> - ค้นหารูปภาพในรีจิสทรี
docker pull <> - ดาวน์โหลดอิมเมจจากรีจิสตรีไปยังเครื่อง
สร้างนักเทียบท่า < > - รวบรวมภาพ
docker run <> - เปิดคอนเทนเนอร์
นักเทียบท่า rm <> - ถอดคอนเทนเนอร์ออก
บันทึกนักเทียบท่า <> - บันทึกคอนเทนเนอร์
docker start/stop/restart <> - ทำงานกับคอนเทนเนอร์
หากคุณเชี่ยวชาญคำสั่งเหล่านี้และมั่นใจในการใช้งาน ให้ถือว่าตัวเองมีความเชี่ยวชาญ 70% ใน Docker ในระดับผู้ใช้
ไฟล์นักเทียบท่า - คำแนะนำในการสร้างภาพ เกือบทุกคำสั่งคำสั่งจะเป็นเลเยอร์ใหม่ ลองดูตัวอย่าง
นี่คือลักษณะของ Dockerfile: คำสั่งทางด้านซ้าย อาร์กิวเมนต์ทางด้านขวา แต่ละคำสั่งที่อยู่ที่นี่ (และโดยทั่วไปจะเขียนใน Dockerfile) จะสร้างเลเยอร์ใหม่ใน Image
แม้จะมองทางด้านซ้ายก็สามารถเข้าใจได้อย่างคร่าว ๆ ว่ากำลังเกิดอะไรขึ้น เราพูดว่า: "สร้างโฟลเดอร์ให้เรา" - นี่คือหนึ่งเลเยอร์ “ทำให้โฟลเดอร์ใช้งานได้” เป็นอีกเลเยอร์หนึ่งและอื่นๆ เลเยอร์เค้กทำให้ชีวิตง่ายขึ้น หากฉันสร้าง Dockerfile อื่นและเปลี่ยนแปลงบางอย่างในบรรทัดสุดท้าย - ฉันเรียกใช้อย่างอื่นที่ไม่ใช่ "python" "main.py" หรือติดตั้งการขึ้นต่อกันจากไฟล์อื่น - จากนั้นเลเยอร์ก่อนหน้าจะถูกนำมาใช้ซ้ำเป็นแคช
ภาพ - นี่คือบรรจุภัณฑ์คอนเทนเนอร์ โดยเปิดตัวคอนเทนเนอร์จากรูปภาพ หากเราดู Docker จากมุมมองของผู้จัดการแพ็คเกจ (ราวกับว่าเรากำลังทำงานกับแพ็คเกจ deb หรือ rpm) ดังนั้นอิมเมจก็จะเป็นแพ็คเกจ rpm โดยพื้นฐานแล้ว ด้วยการติดตั้ง yum เราสามารถติดตั้งแอปพลิเคชัน ลบออก ค้นหาในพื้นที่เก็บข้อมูล และดาวน์โหลดได้ คล้ายกันที่นี่: คอนเทนเนอร์ถูกเปิดใช้งานจากอิมเมจ คอนเทนเนอร์จะถูกจัดเก็บไว้ในรีจิสทรี Docker (คล้ายกับ yum ในพื้นที่เก็บข้อมูล) และแต่ละอิมเมจมีแฮช SHA-256 ชื่อ และแท็ก
อิมเมจถูกสร้างขึ้นตามคำแนะนำจาก Dockerfile แต่ละคำสั่งจาก Dockerfile จะสร้างเลเยอร์ใหม่ สามารถใช้ซ้ำได้หลายชั้น
รีจิสทรีนักเทียบท่า เป็นที่เก็บอิมเมจ Docker เช่นเดียวกับระบบปฏิบัติการ Docker มีรีจิสทรีมาตรฐานสาธารณะ - dockerhub แต่คุณสามารถสร้างพื้นที่เก็บข้อมูลของคุณเอง รีจิสทรี Docker ของคุณเองได้
ภาชนะ - สิ่งที่เปิดตัวจากภาพ เราสร้างอิมเมจตามคำแนะนำจาก Dockerfile จากนั้นจึงเปิดใช้งานจากอิมเมจนี้ คอนเทนเนอร์นี้แยกออกจากคอนเทนเนอร์อื่น และต้องมีทุกสิ่งที่จำเป็นสำหรับแอปพลิเคชันจึงจะทำงาน ในกรณีนี้หนึ่งคอนเทนเนอร์ - หนึ่งกระบวนการ มันเกิดขึ้นที่คุณต้องทำสองกระบวนการ แต่นี่ค่อนข้างตรงกันข้ามกับอุดมการณ์นักเทียบท่า
ข้อกำหนด "หนึ่งคอนเทนเนอร์ หนึ่งกระบวนการ" เกี่ยวข้องกับ PID Namespace เมื่อกระบวนการที่มี PID 1 เริ่มต้นในเนมสเปซ ถ้ามันหยุดทำงานกะทันหัน คอนเทนเนอร์ทั้งหมดก็จะตายเช่นกัน หากสองกระบวนการทำงานอยู่ที่นั่น กระบวนการหนึ่งยังมีชีวิตอยู่และอีกกระบวนการหนึ่งตายไปแล้ว คอนเทนเนอร์ก็จะยังคงอยู่ต่อไป แต่นี่เป็นคำถามเกี่ยวกับแนวทางปฏิบัติที่ดีที่สุด เราจะพูดถึงสิ่งเหล่านั้นในเอกสารอื่นๆ
หากต้องการศึกษาคุณสมบัติและโปรแกรมเต็มของหลักสูตรโดยละเอียด โปรดไปที่ลิงก์: “'
ผู้แต่ง: Marcel Ibraev ผู้ดูแลระบบ Kubernetes ที่ได้รับการรับรอง วิศวกรฝึกหัดที่ Southbridge วิทยากรและผู้พัฒนาหลักสูตร Slurm
ที่มา: will.com