วิวัฒนาการของเครื่องมือนำส่งหรือแนวคิดเกี่ยวกับ Docker, deb, jar และอื่นๆ

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

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

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

ดังนั้น ในสมัยก่อน... วิธีการส่งเทปที่เร็วที่สุดที่ฉันพบคือเทปคาสเซ็ตต์จากเครื่องบันทึกเทป ผมมีคอมพิวเตอร์ BK-0010.01...

ยุคแห่งเครื่องคิดเลข

ไม่ มีช่วงเวลาก่อนหน้านี้ด้วยซ้ำ มีเครื่องคิดเลขด้วย MK-61 и MK-52.

ดังนั้นเมื่อฉันมี MK-61จากนั้นวิธีถ่ายโอนโปรแกรมคือกระดาษธรรมดาในกล่องที่เขียนโปรแกรมซึ่งหากจำเป็นให้เขียนลงในเครื่องคิดเลขเพื่อรันโปรแกรมด้วยตนเอง หากคุณต้องการเล่น (ใช่แล้ว แม้แต่เครื่องคิดเลขสำหรับคนโบราณก็มีเกม) คุณนั่งลงแล้วเข้าสู่โปรแกรมลงในเครื่องคิดเลข โดยธรรมชาติแล้วเมื่อปิดเครื่องคิดเลข โปรแกรมก็จะหายไปจากการลืมเลือน นอกเหนือจากรหัสเครื่องคิดเลขที่เขียนลงบนกระดาษเป็นการส่วนตัวแล้ว รายการดังกล่าวยังได้รับการตีพิมพ์ในนิตยสาร "Radio" และ "Technology for Youth" และยังได้รับการตีพิมพ์ในหนังสือในยุคนั้นด้วย

การปรับเปลี่ยนครั้งต่อไปคือเครื่องคิดเลข MK-52แต่ก็มีรูปลักษณ์ของการจัดเก็บข้อมูลแบบไม่ลบเลือนอยู่แล้ว ตอนนี้ไม่จำเป็นต้องป้อนเกมหรือโปรแกรมด้วยตนเอง แต่หลังจากทำการผ่านปุ่มเวทย์มนตร์แล้วมันก็โหลดเอง

ขนาดของโปรแกรมที่ใหญ่ที่สุดในเครื่องคิดเลขคือ 105 ขั้นตอนและขนาดของหน่วยความจำถาวรใน MK-52 คือ 512 ขั้นตอน

อย่างไรก็ตามหากมีแฟน ๆ ของเครื่องคิดเลขเหล่านี้ที่กำลังอ่านบทความนี้ในกระบวนการเขียนบทความฉันพบทั้งโปรแกรมจำลองเครื่องคิดเลขสำหรับ Android และโปรแกรมสำหรับมัน เดินหน้าสู่อดีต!

• โปรแกรมจำลอง MK-61 สำหรับ Android
• แค็ตตาล็อกโปรแกรมสำหรับ MK-61

การพูดนอกเรื่องสั้น ๆ เกี่ยวกับ MK-52 (จากวิกิพีเดีย)

MK-52 บินขึ้นสู่อวกาศบนยานอวกาศ Soyuz TM-7 ควรจะใช้ในการคำนวณวิถีการลงจอดในกรณีที่คอมพิวเตอร์ออนบอร์ดล้มเหลว

ตั้งแต่ปี 52 เป็นต้นมา MK-1988 พร้อมหน่วยขยายหน่วยความจำ Elektronika-Astro ได้ถูกส่งไปยังกองทัพเรือโดยเป็นส่วนหนึ่งของชุดคอมพิวเตอร์นำทาง

คอมพิวเตอร์ส่วนบุคคลเครื่องแรก

ย้อนเวลากลับไป BK-0010. ชัดเจนว่าที่นั่นมีหน่วยความจำเพิ่มมากขึ้น และการพิมพ์โค้ดจากกระดาษก็ไม่ใช่ทางเลือกอีกต่อไป (แม้ว่าในตอนแรกฉันจะทำแบบนั้น เพราะไม่มีสื่ออื่นเลย) เทปเสียงสำหรับเครื่องบันทึกเทปกลายเป็นวิธีการหลักในการจัดเก็บและส่งมอบซอฟต์แวร์

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

การเกิดขึ้นของสื่อจัดเก็บข้อมูลขนาดใหญ่ที่เชื่อถือได้

ต่อมามีฟลอปปีดิสก์ปรากฏขึ้น กระบวนการคัดลอกง่ายขึ้นและความน่าเชื่อถือเพิ่มขึ้น
แต่สถานการณ์จะเปลี่ยนไปอย่างมากก็ต่อเมื่อมีการจัดเก็บข้อมูลในเครื่องขนาดใหญ่เพียงพอปรากฏในรูปแบบของ HDD

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

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

ในเวลานั้น การมีอยู่ของ Linux ยังไม่เปิดกว้างสำหรับฉัน ฉันอาศัยอยู่ในโลกของ MS DOS และต่อมาคือ Windows และเขียนใน Borland Pascal และ Delphi ซึ่งบางครั้งก็มุ่งไปที่ C++ หลายๆ คนใช้ InstallShield เพื่อส่งสินค้าในสมัยนั้น ru.wikipedia.org/wiki/InstallShieldซึ่งค่อนข้างประสบความสำเร็จในการแก้ไขงานที่ได้รับมอบหมายทั้งหมดในการปรับใช้และกำหนดค่าซอฟต์แวร์

ยุคอินเตอร์เน็ต

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

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

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

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

ในเวลาเดียวกัน การส่งมอบเว็บไซต์อย่างง่ายใน PHP ทำได้ด้วยวิธีดั้งเดิม เพียงแค่คัดลอกไฟล์ที่แก้ไขแล้วผ่าน FTP ไปยังเครื่องเป้าหมาย บางครั้งก็ไม่เป็นเช่นนั้น - โค้ดได้รับการแก้ไขแล้วบนเซิร์ฟเวอร์ผลิตภัณฑ์ และจะยิ่งเก๋เป็นพิเศษหากมีข้อมูลสำรองอยู่ที่ไหนสักแห่ง

แพ็คเกจ RPM และ DEB

ในทางกลับกัน ด้วยการพัฒนาของอินเทอร์เน็ต ระบบที่คล้าย UNIX เริ่มได้รับความนิยมมากขึ้นเรื่อยๆ โดยเฉพาะอย่างยิ่ง ตอนนั้นเองที่ฉันค้นพบ RedHat Linux 6 ประมาณปี 2000 โดยปกติแล้วยังมีวิธีการบางอย่างในการส่งมอบซอฟต์แวร์ ตามวิกิพีเดีย RPM ในฐานะผู้จัดการแพ็คเกจหลักปรากฏแล้วในปี 1995 ในเวอร์ชันของ RedHat Linux 2.0 และตั้งแต่นั้นมาจนถึงทุกวันนี้ ระบบได้ถูกส่งมอบในรูปแบบของแพ็คเกจ RPM และค่อนข้างประสบความสำเร็จในการมีอยู่และพัฒนา

การจำหน่ายตระกูล Debian ดำเนินไปตามเส้นทางที่คล้ายกันและดำเนินการจัดส่งในรูปแบบของแพ็คเกจ deb ซึ่งยังคงไม่เปลี่ยนแปลงมาจนถึงทุกวันนี้

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

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

เป็นที่น่าสังเกตว่าในปัจจุบันมีการเคลื่อนไหวบางอย่างในการย้ายออกจาก deb และเปลี่ยนไปใช้แพ็คเกจ snap แต่จะเพิ่มเติมในภายหลัง

ดังนั้น นักพัฒนาระบบคลาวด์รุ่นใหม่ที่ไม่รู้จักทั้ง DEB และ RPM ก็ค่อยๆ เติบโต ได้รับประสบการณ์ ผลิตภัณฑ์มีความซับซ้อนมากขึ้น และจำเป็นต้องใช้วิธีการจัดส่งที่สมเหตุสมผลมากกว่า FTP, สคริปต์ทุบตี และงานฝีมือของนักเรียนที่คล้ายกัน
และนี่คือจุดที่ Docker เข้ามามีบทบาท ซึ่งเป็นการผสมผสานระหว่างการจำลองเสมือน การจำกัดทรัพยากร และวิธีการจัดส่ง ตอนนี้มันทันสมัยและอ่อนเยาว์ แต่มันจำเป็นสำหรับทุกสิ่งหรือเปล่า? นี่คือยาครอบจักรวาลใช่ไหม?

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

ฉันจะพยายามแบ่งปันประสบการณ์ของฉันเกี่ยวกับวิธีที่เราใช้ Docker และผลที่ตามมา

สคริปต์ที่เขียนขึ้นเอง

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

แต่สคริปต์มีข้อเสียหลายประการ:

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

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

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

นักเทียบท่า

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

เราพบความไม่สะดวกอะไรบ้าง?

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

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

ตามที่แสดงในทางปฏิบัติแล้ว ในความเป็นจริงสิ่งนี้ไม่จำเป็น แพคเกจ deb ก็เพียงพอแล้วใน 90% ของกรณี

เมื่อใดที่ deb เก่าที่ดีจะล้มเหลว และเมื่อใดที่เราต้องการนักเทียบท่าจริงๆ

สำหรับเรา นี่คือการปรับใช้บริการใน python ไลบรารีจำนวนมากที่จำเป็นสำหรับการเรียนรู้ของเครื่องและไม่รวมอยู่ในการกระจายมาตรฐานของระบบปฏิบัติการ (และมีอะไรผิดปกติในเวอร์ชัน), การแฮ็กด้วยการตั้งค่า, ความต้องการเวอร์ชันที่แตกต่างกันสำหรับบริการต่าง ๆ ที่อาศัยอยู่ในระบบโฮสต์เดียวกัน นี่เป็นวิธีเดียวที่สมเหตุสมผลในการส่งมอบส่วนผสมนิวเคลียร์นี้คือนักเทียบท่า ความเข้มข้นของแรงงานในการประกอบคอนเทนเนอร์นักเทียบท่านั้นต่ำกว่าแนวคิดในการบรรจุทั้งหมดลงในแพ็คเกจ deb ที่แยกจากกันโดยมีการพึ่งพาและในความเป็นจริงไม่มีใครมีสติที่ถูกต้องจะทำสิ่งนี้

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

สแน็ปแพ็คเกจ

กลับไปที่แพ็คเกจ snap กันเถอะ ปรากฏอย่างเป็นทางการครั้งแรกใน Ubuntu 16.04 ต่างจากแพ็คเกจ deb และแพ็คเกจ rpm ทั่วไป snap มีการขึ้นต่อกันทั้งหมด ในอีกด้านหนึ่ง สิ่งนี้ช่วยให้คุณหลีกเลี่ยงข้อขัดแย้งของไลบรารี ในทางกลับกัน แพ็คเกจที่ได้จะมีขนาดใหญ่กว่า นอกจากนี้ สิ่งนี้ยังส่งผลต่อความปลอดภัยของระบบด้วย: ในกรณีของการจัดส่งแบบ snap การเปลี่ยนแปลงทั้งหมดในไลบรารีที่รวมไว้จะต้องได้รับการตรวจสอบโดยนักพัฒนาที่สร้างแพ็คเกจ โดยทั่วไปแล้วไม่ใช่ทุกสิ่งจะเรียบง่ายนักและความสุขที่เป็นสากลไม่ได้มาจากการใช้มัน อย่างไรก็ตาม นี่เป็นทางเลือกที่สมเหตุสมผลหากใช้ Docker เดียวกันเป็นเครื่องมือบรรจุภัณฑ์เท่านั้น ไม่ใช่สำหรับการจำลองเสมือน

ด้วยเหตุนี้ ตอนนี้เราจึงใช้ทั้งแพ็คเกจ deb และคอนเทนเนอร์นักเทียบท่าในการรวมกันที่สมเหตุสมผล ซึ่งบางที ในบางกรณี เราจะแทนที่ด้วยแพ็คเกจแบบ snap

เฉพาะผู้ใช้ที่ลงทะเบียนเท่านั้นที่สามารถเข้าร่วมในการสำรวจได้ เข้าสู่ระบบ, โปรด.

ใช้อะไรจัดส่งคะ?

• สคริปต์ที่เขียนขึ้นเอง

• คัดลอกด้วยตนเองไปยัง FTP

• แพ็คเกจ deb

• แพ็คเกจรอบต่อนาที

• สแน็ปแพ็คเกจ

• นักเทียบท่า-รูปภาพ

• อิมเมจเครื่องเสมือน

• โคลน HDD ทั้งหมด

• หุ่นเชิด

• เบิ้ล

• อื่น ๆ

ผู้ใช้ 109 คนโหวต ผู้ใช้ 32 รายงดออกเสียง

ที่มา: will.com