นักเทียบท่าเหมาะกับเคสที่ใช้ของฉันหรือไม่

บริษัท ของฉันมีระบบที่เราขายซึ่งประกอบด้วยมินิคอมพิวเตอร์ "Smartbox" ที่ใช้งาน Ubuntu 12.04 กล่องนี้เรียกใช้แอปพลิเคชัน Django รวมถึงกระบวนการพุ่งพรวดที่แตกต่างกันจำนวนหนึ่งที่เกี่ยวข้อง ไม่มาก เรามีกล่องเหล่านี้หลายพันกล่องบนสนาม เราจัดการการขึ้นต่อกันของแพ็คเกจการลงทะเบียนกระบวนการ ฯลฯ ผ่านแพคเกจเดบิตที่มีระดับความสำเร็จที่แตกต่างกัน

เราต้องการวิธีที่จะผลักดันการอัปเดตให้กับผู้ใช้ของเราอย่างมีประสิทธิภาพและรวดเร็ว นอกจากนี้เรายังต้องการบางสิ่งบางอย่างเมื่อเราอัพเกรดระบบปฏิบัติการ (เราเกินกำหนดสำหรับการอัพเกรด Ubuntu อย่างที่คุณบอก) เราสามารถรู้สึกปลอดภัยเกี่ยวกับแพ็คเกจของเรา "เพิ่งใช้งานได้"

ฉันไม่รู้อะไรเกี่ยวกับนักเทียบท่า แต่เมื่อฉันได้ยินปัญหาของเราเป็นครั้งแรก (ฉันเป็นคนจ้างใหม่) นักเทียบท่าเป็นความคิดแรกของฉัน แต่ยิ่งฉันคิดเกี่ยวกับมันมากขึ้นฉันก็รู้สึกว่ามันอาจจะไม่ใช่เพราะกล่องเหล่านี้เป็นของเราที่เราควบคุมระบบปฏิบัติการซึ่งเป็นส่วนสำคัญของคุณค่าของ Docker หรือฉันเข้าใจ ดังนั้นถ้าเรารู้ว่ากล่องของเราจะเป็น Ubuntu เสมอและโดยพื้นฐานแล้วเรามีแอพ Django บวกกับกระบวนการบางอย่างที่จะเรียกใช้ Docker ดีกว่าแพ็คเกจ deb หรือไม่?

TL; DR: นักเทียบท่าเทียบกับแพ็คเกจ deb สำหรับอุปกรณ์แบบกระจายที่มักจะเรียกใช้ Ubuntu ดังนั้นความเป็นอิสระของแพลตฟอร์มจึงไม่สำคัญ

ฉันไม่แน่ใจ 100% ว่าฉันเข้าใจคำถามนี้ แต่ดูเหมือนว่าโซลูชัน Docker จะต้องเปลี่ยนจากการมีอุปกรณ์ (ทางกายภาพ?) ที่มีระบบปฏิบัติการและแอปของคุณติดตั้งไว้ในนั้นไปยังอุปกรณ์ที่มีระบบปฏิบัติการและ นักเทียบท่ากับมันใช้คอนเทนเนอร์เดียวกับแอปของคุณ แต่ไม่ได้เพิ่มความจำเป็นในการอัปเดตระบบปฏิบัติการในโฮสต์และเพิ่มเลเยอร์ของความซับซ้อน (และการอัปเดตเพิ่มเติมเพื่อโต้แย้งเนื่องจากคุณจะต้องรักษา Docker และแพตช์ระบบปฏิบัติการไว้) โดยไม่มีประโยชน์ชัดเจน เท่าที่พื้นที่เฉพาะที่กล่าวถึงในคำถามมีความกังวล

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

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

ก่อนอื่นคุณจะได้รับการทำซ้ำ คุณสามารถสร้าง Dockerfile แก้จุดบกพร่องในคอนเทนเนอร์บนเครื่องนักพัฒนาของคุณทำการทดสอบบนเซิร์ฟเวอร์รวมอย่างต่อเนื่องและจากนั้นในผลิตภัณฑ์ขั้นสุดท้ายของคุณและคุณรู้ว่ามันจะทำงานเหมือนกันในสภาพแวดล้อมเหล่านั้นทั้งหมด ไม่ลืมการพึ่งพาที่นักพัฒนาติดตั้งไว้ในเครื่อง นักพัฒนาของคุณไม่จำเป็นต้องใช้ Ubuntu ที่โต๊ะทำงาน สิ่งสำคัญที่ทำให้เรา Arch ผู้ใช้ Linux มีความสุข :-)

ประการที่สองสำหรับสถานการณ์การอัพเกรดของคุณคุณสามารถดึงหลาย ๆ เวอร์ชันไปยังเครื่องได้ในคราวเดียว หากคุณทำdocker pull myapp:2.0ในขณะที่1.0ทำงานคุณสามารถสลับไปยัง2.0อย่างรวดเร็วมาก เร็วกว่าการอัพเกรดระบบปฏิบัติการปกติมาก หากคุณใช้ orchestrator ที่มี microservices หลายอินสแตนซ์คุณยังสามารถทำการอัพเกรดที่ไม่รบกวนการบริการได้เลย

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

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

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

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

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

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

ในขณะที่มี Docker ภูมิภาคที่ทับซ้อนกันเล็ก ๆ และระบบบรรจุภัณฑ์ Debian เป็นหลักแก้ปัญหาที่แตกต่างกันสองอย่าง :

• ระบบบรรจุภัณฑ์ Debian ถูกสร้างขึ้นเพื่อติดตั้งซอฟต์แวร์บนโฮสต์และอัปเกรดได้ง่ายที่สุด สามารถจัดการการพึ่งพาที่ซับซ้อนและรูปแบบข้อ จำกัด ระหว่างส่วนประกอบซอฟต์แวร์เช่น“ ซอฟต์แวร์ X เวอร์ชั่น A ต้องใช้ซอฟต์แวร์ Y ที่ติดตั้งเวอร์ชัน B หรือใหม่กว่า” หรือ“ ไม่ควรติดตั้งซอฟต์แวร์ X ด้วยซอฟต์แวร์ Z version C”

• ระบบนักเทียบท่าเข้าใจง่ายในการอธิบายและปรับใช้บริการโดยเฉพาะอย่างยิ่งบริการไมโครอาจเป็นไปได้ที่โฮสต์หลายแห่ง - เช่น Docker Swarm หรือคลัสเตอร์ Kubernetes

ปัญหาทั้งสองนี้เป็นมุมฉากซึ่งหมายความว่าเมื่อได้รับปัญหาการปรับใช้เพื่อแก้ปัญหาหนึ่งสามารถใช้หนึ่งในนั้นทั้งสองอย่างหรืออาจจะไม่มีเลยซึ่งเป็นส่วนหนึ่งของการแก้ปัญหา เมื่อใช้ทั้งคู่แพ็กเกจ Debian จะใช้ในการผลิตอิมเมจ Docker และ Dockerfile ของคุณ (สูตรที่ใช้ในการเตรียมอิมเมจ Docker ที่อธิบาย "ระบบเสมือนจริง" ที่วิ่งในคอนเทนเนอร์) จะลงทะเบียนที่เก็บ Debian ของคุณเป็นหลัก แหล่งที่มาของระบบบรรจุภัณฑ์ Debian และติดตั้งแพ็คเกจของคุณ

จากสิ่งนี้ในใจฉันคิดว่าสิ่งที่คุณกำลังมองหาคือการนำรูปแบบเซิร์ฟเวอร์ที่ไม่เปลี่ยนรูปแบบมาใช้. การพัฒนาเมื่อเร็ว ๆ นี้ในเทคโนโลยีคลาวด์ทำให้สามารถอัพเกรดซอฟต์แวร์ได้โดยไม่ต้องใช้ระบบอัพเกรดซอฟต์แวร์แบบคลาสสิกจากระบบซอฟต์แวร์แพ็กเกจ (เช่นระบบบรรจุภัณฑ์ Debian) แต่เพียงแค่เปลี่ยนเซิร์ฟเวอร์เต็มทันที (บางคนทำสิ่งนี้มาก่อนการพัฒนานี้โดยมีสาม OS-s บนเซิร์ฟเวอร์สองตัวเลือกที่จะใช้ในการเรียกใช้อุปกรณ์และ mini-OS โดยเฉพาะเพื่อทำการเปลี่ยนอุปกรณ์ในขณะที่ไม่ซับซ้อนเกินไปดูเหมือนว่าจะยังคงเป็น โพรง.) เทคนิคนี้อาจเป็นที่สนใจสำหรับคุณเพราะถ้าคุณเคยใช้ในการอัพเกรดซอฟต์แวร์บนเซิร์ฟเวอร์ของคุณโดยใช้ตัวจัดการแพคเกจสถานะสุดท้ายของเซิร์ฟเวอร์ขึ้นอยู่กับ "ประวัติการอัพเกรด" ของเซิร์ฟเวอร์ - โดยเฉพาะอย่างยิ่งหากเกิดข้อผิดพลาดใน กระบวนการอัพเกรด ความแตกต่างนี้ไม่ดี

เรามีกล่องเหล่านี้หลายพันกล่องบนสนาม เราจัดการการขึ้นต่อกันของแพ็คเกจการลงทะเบียนกระบวนการ ฯลฯ ผ่านแพคเกจเดบิตที่มีระดับความสำเร็จที่แตกต่างกัน

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

ขณะนี้มีตัวเลือกมากมายในการใช้รูปแบบเซิร์ฟเวอร์ที่ไม่เปลี่ยนรูปแบบตัวเลือกยอดนิยมสองตัวเลือกคือการใช้อิมเมจ Docker, อิมเมจหรือใช้ "อิมเมจต้นแบบอินสแตนซ์" จากผู้ให้บริการคลาวด์ของคุณ . กรณีการใช้งานของคุณห้ามการใช้เทคนิคคลาวด์ดังนั้นฉันจะถือว่าภาพ Docker เป็นตัวเลือกที่มีสิทธิ์เท่านั้น (เพื่อประโยชน์ในการสำเร็จเป็นไปได้อย่างแน่นอนที่จะใช้วิธีการอื่นเช่นการใช้ Virtual Box หรือโซลูชัน virtualisation ที่คล้ายกันเป็นทางเลือกแทน Docker)

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

ทีนี้เพื่อพิจารณาปัญหาที่เป็นรูปธรรมที่คุณอธิบายลองสมมติว่าใช้รูปแบบเซิร์ฟเวอร์ที่ไม่เปลี่ยนรูปได้กับ Docker นั้นเป็นสิ่งที่คุณต้องการ เนื่องจากระบบนักเทียบท่าและระบบบรรจุภัณฑ์ของเดเบียนนั้นเป็นส่วนเสริมแทนที่จะเป็นเอกสิทธิ์เฉพาะด้านร่วมกัน (แนะนำภายใน) เรายังคงต้องตอบคำถามหากคุณควรเตรียมแพ็คเกจ Debian สำหรับซอฟต์แวร์ของคุณ

ความเกี่ยวข้องของการใช้แพ็คเกจ Debian เพื่อติดตั้งซอฟต์แวร์ของคุณ (ในอิมเมจ Docker หรือบนโฮสต์) อยู่ในความซับซ้อนของปัญหาการกำหนดเวอร์ชันที่คุณต้องแก้ไข หากคุณเรียกใช้ซอฟต์แวร์หลายรุ่นในเวลาเดียวกันจำเป็นต้องปรับลดรุ่นเป็นครั้งคราวและมีข้อกำหนดรุ่นที่ซับซ้อนที่คุณต้องจัดทำเอกสารอย่างรอบคอบการมีแพ็คเกจ Debian เป็นสิ่งที่ไม่ควรพลาด มิฉะนั้นขั้นตอนนี้สามารถข้ามได้ - แต่เนื่องจากคุณได้พยายามสร้างและปรับใช้แพ็กเกจเหล่านี้แล้วจึงไม่มีคุณค่าที่แท้จริงสำหรับการทำงานของคุณ ดังนั้นฉันขอแนะนำให้ผลิตแพ็คเกจ Debian ของคุณต่อไป

ฉันคิดว่ามันอาจเป็นตัวเลือกที่ดี (จำเป็นต้องทำการทดสอบเพิ่มเติม)

คุณสามารถระบุ URL ที่มีแท็ก / เวอร์ชั่นทั้งหมดของคอนเทนเนอร์ที่คุณสร้างขึ้นและลูกค้าจะอ่าน URL นั้นเพื่อดูว่ามีคอนเทนเนอร์เวอร์ชันใหม่หรือไม่

คุณสามารถจัดเก็บไฟล์ส่วนบุคคล / การตั้งค่าในท้องถิ่นและคุณจะไม่สูญเสียข้อมูลนั้นในการอัพเกรดและคุณจะมั่นใจได้ว่าสิ่งที่คุณทำและทดสอบจะใช้ได้กับทุกคนในลักษณะเดียวกัน

แม้คุณสามารถให้ผู้ใช้มีความเป็นไปได้ที่จะเลือกรุ่นที่มีจากที่พวกเขาต้องการใช้ (ถ้าคุณต้องการให้โอกาสนั้น)

มันจะเป็นเช่น "" อัปเกรดหนึ่งแพ็คเกจเท่านั้น "" พูดถึงเรียกเฉพาะเวอร์ชันใหม่ของคอนเทนเนอร์ซึ่งดีกว่ามากที่จัดการกับแพ็คเกจเดเบียน;)

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

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