เหตุใดจึงแนะนำให้เรียกใช้กระบวนการเดียวเท่านั้นในคอนเทนเนอร์

ในการโพสต์บล็อกจำนวนมากและความคิดเห็นทั่วไปมีคำพูดที่ว่า "กระบวนการเดียวต่อคอนเทนเนอร์"

ทำไมกฎนี้ถึงมีอยู่? ทำไมไม่เรียกใช้ ntp, nginx, uwsgi และกระบวนการอื่น ๆ ในคอนเทนเนอร์เดียวที่ต้องมีกระบวนการทั้งหมดเพื่อให้ทำงานได้?

โพสต์บล็อกที่กล่าวถึงกฎนี้:

• "Single-process-per-container เป็นรูปแบบการออกแบบที่แนะนำสำหรับแอปพลิเคชัน Docker"
• "นักเทียบท่าใช้สำหรับสร้างคอนเทนเนอร์แบบกระบวนการเดียวหรือบริการเดียวเท่านั้น"
• "ดีกว่าที่จะใช้หนึ่งกระบวนการต่อคอนเทนเนอร์"
• "เรียกใช้บริการเดียวเป็นคอนเทนเนอร์"
• "หนึ่งกระบวนการต่อตู้คอนเทนเนอร์"
• "หนึ่งกระบวนการต่อคอนเทนเนอร์"

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

• การขยายภาชนะบรรจุในแนวนอนนั้นง่ายกว่ามากหากแยกภาชนะบรรจุเป็นฟังก์ชันเดียว ต้องการคอนเทนเนอร์อาปาเช่อื่นหรือไม่ หมุนขึ้นหนึ่งที่อื่น อย่างไรก็ตามถ้าคอนเทนเนอร์อาปาเช่ของฉันมี DB, cron และชิ้นส่วนอื่น ๆ ของฉันอยู่ด้วย
• การมีฟังก์ชั่นเดียวต่อคอนเทนเนอร์ช่วยให้สามารถนำคอนเทนเนอร์กลับมาใช้ใหม่ได้อย่างง่ายดายสำหรับโครงการหรือวัตถุประสงค์อื่น ๆ
• นอกจากนี้ยังทำให้สามารถพกพาและคาดการณ์ได้มากขึ้นสำหรับ devs ที่จะดึงส่วนประกอบจากการผลิตไปจนถึงการแก้ไขปัญหาในเครื่องแทนที่จะเป็นสภาพแวดล้อมแอปพลิเคชันทั้งหมด
• การติดตั้ง / อัปเกรด (ทั้งระบบปฏิบัติการและแอปพลิเคชัน) สามารถทำได้ในลักษณะที่แยกและควบคุมได้มากขึ้น การเล่นกลหลายบิตและบ็อบในภาชนะของคุณไม่เพียง แต่สร้างภาพที่ใหญ่ขึ้นเท่านั้น แต่ยังเชื่อมโยงส่วนประกอบเหล่านี้เข้าด้วยกัน เหตุใดจึงต้องปิดแอปพลิเคชัน X และ Y เพื่ออัปเกรด Z
  • ข้างต้นถือเป็นจริงสำหรับการปรับใช้รหัสและการย้อนกลับ
• ฟังก์ชันแบ่งออกเป็นหลายคอนเทนเนอร์ช่วยให้มีความยืดหยุ่นมากขึ้นจากมุมมองด้านความปลอดภัยและการแยก คุณอาจต้องการแยกบริการ (หรือต้องการ) ในระดับเครือข่ายไม่ว่าจะเป็นทางกายภาพหรือภายในเครือข่ายซ้อนทับเพื่อรักษาท่าทางความปลอดภัยที่แข็งแกร่งหรือปฏิบัติตามสิ่งต่างๆเช่น PCI
• ปัจจัยเล็ก ๆ น้อย ๆ อื่น ๆ เช่นการจัดการกับ stdout / stderr และการส่งบันทึกไปยังบันทึกภาชนะเก็บภาชนะเป็นชั่วคราวที่สุด

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

มีการฆ่าภาชนะ "สองกระบวนการ" ไม่กี่วันที่ผ่านมามีบางจุดปวดสำหรับฉันซึ่งทำให้ฉันใช้สองภาชนะแทนสคริปต์หลามซึ่งเริ่มสองกระบวนการ:

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

คำแนะนำมาจากเป้าหมายและการออกแบบการจำลองเสมือนระดับระบบปฏิบัติการ

ตู้คอนเทนเนอร์ได้รับการออกแบบมาเพื่อแยกกระบวนการสำหรับผู้อื่นโดยให้userpaceและระบบไฟล์ของตัวเอง
นี่คือวิวัฒนาการเชิงตรรกะchrootซึ่งได้จัดทำระบบไฟล์แยกขั้นตอนต่อไปคือการแยกกระบวนการจากคนอื่น ๆ เพื่อหลีกเลี่ยงการเขียนทับหน่วยความจำและอนุญาตให้ใช้ทรัพยากรเดียวกัน (เช่นพอร์ต TCP 8080 เช่นจากหลายกระบวนการโดยไม่มีความขัดแย้ง

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

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

นี่คือรายการที่ไม่ครบถ้วนสมบูรณ์ของการปรับแต่ง / ข้อผิดพลาดอย่างหนักที่ฉันสามารถนึกได้:

• การจัดการบันทึก

  ไม่ว่าจะเป็นโวลุ่มที่เมานต์หรือ interleaved บน stdout ทำให้การจัดการบางอย่าง หากใช้ปริมาณที่เมานต์คอนเทนเนอร์ของคุณควรมี "สถานที่" ของตัวเองบนโฮสต์หรือคอนเทนเนอร์สองตัวเดียวกันจะต่อสู้เพื่อทรัพยากรเดียวกัน เมื่อ interleaving บน stdout เพื่อใช้ประโยชน์จากdocker logsมันสามารถกลายเป็นฝันร้ายสำหรับการวิเคราะห์หากไม่สามารถระบุแหล่งที่มาได้อย่างง่ายดาย

• ระวังกระบวนการซอมบี้

  หากหนึ่งในกระบวนการของคุณในคอนเทนเนอร์ล้มเหลว supervisord อาจไม่สามารถล้างค่า childs ในสถานะ zombie และโฮสต์ init จะไม่ได้รับสืบทอด เมื่อคุณหมดจำนวนของ pids ที่มีอยู่ (2 ^ 22 ดังนั้นประมาณ 4 ล้าน) สิ่งต่าง ๆ จะล้มเหลว

• แยกความกังวล

  หากคุณเรียกใช้สองสิ่งที่แยกกันเช่นเซิร์ฟเวอร์ apache และ logstash ภายในคอนเทนเนอร์เดียวกันซึ่งอาจช่วยให้การจัดการบันทึกง่ายขึ้น แต่คุณต้องปิด apache เพื่ออัปเดต logstash (ในความเป็นจริงคุณควรใช้ไดรเวอร์การบันทึกของ Docker) มันจะเป็นการหยุดที่สง่างามที่รอให้เซสชันปัจจุบันสิ้นสุดหรือไม่? หากเป็นการหยุดที่สง่างามอาจใช้เวลานานและใช้เวลานานในการหมุนเวอร์ชั่นใหม่ หากคุณทำการฆ่าคุณจะส่งผลกระทบต่อผู้ใช้สำหรับผู้จัดส่งบันทึกและควรหลีกเลี่ยง IMHO

ในที่สุดเมื่อคุณมีกระบวนการหลายขั้นตอนที่คุณกำลังสร้างระบบปฏิบัติการขึ้นใหม่และในกรณีนี้การใช้การจำลองเสมือนสำหรับฮาร์ดแวร์จะให้เสียงที่สอดคล้องกับความต้องการนี้มากขึ้น

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

มีหลายกรณีที่ต้องใช้หลายกระบวนการในคอนเทนเนอร์เดียวตราบใดที่ทั้งสองกระบวนการสนับสนุนฟังก์ชันโมดูลาร์เดียว

กระบวนการที่ฉันจะเรียกว่าเป็นบริการที่นี่1 บริการ ~ 1 บริการถ้าบริการใด ๆ ของฉันล้มเหลวฉันจะหมุนตู้คอนเทนเนอร์นั้นตามลำดับและภายในไม่กี่วินาทีทุกอย่างจะกลับมาอีกครั้ง ดังนั้นจะไม่มีการอ้างอิงใด ๆ ระหว่างบริการ วิธีปฏิบัติที่ดีที่สุดคือให้มีขนาดตู้คอนเทนเนอร์ของคุณน้อยกว่า 200 MB และสูงสุด 500 MB (ยกเว้นตู้คอนเทนเนอร์ที่เป็น Windows มากกว่า 2 GB) มิฉะนั้นจะมีลักษณะคล้ายกับเครื่องเสมือนไม่ใช่แค่ประสิทธิภาพเพียงพอ นอกจากนี้ยังคำนึงถึงพารามิเตอร์บางประการเช่นการปรับขนาดฉันจะทำให้บริการของฉันมีความยืดหยุ่นการปรับใช้อัตโนมัติ ฯลฯ ได้อย่างไร

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