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

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

ฉันได้รับแนวคิดนี้จากการอ่านบล็อกนี้ที่นี่ซึ่งทำให้ข้อโต้แย้งที่ดีสำหรับการใช้แพคเกจ deb สำหรับแอพพลิเคชั่นที่มีอยู่แล้ว ประเด็นหลักจากบล็อกนี้ที่น่าสนใจสำหรับเราคือปัญหาของการรักษาระบบนิเวศของนักเทียบท่า (การแชร์พอร์ต, การอนุญาต, การโฮสต์ของ Docker Images ฯลฯ )

ดูเหมือนว่า "dep-packages เป็นคอนเทนเนอร์ดั้งเดิม" เหมาะสมสำหรับบริการขนาดเล็กที่ไม่ต้องกังวลเกี่ยวกับความขัดแย้งของพอร์ตและการพึ่งพาทั้งหมดได้รับการดูแลภายในสภาพแวดล้อมเสมือน

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

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

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

apt-key add - <<EOF
-----BEGIN PGP PUBLIC KEY BLOCK-----
<YOUR RELEASE OFFICER PGP KEY GOES HERE>
EOF

cat >> /etc/apt/sources.list <<EOF
deb https://my.organisation.org/repo debian-jessie main
apt-get update -y
apt-get upgrade -y
EOF

และDockerfileตามแนวของ

ADD apt_setup.sh /root
RUN sh -ex /root/apt_setup.sh && rm /root/apt_setup.sh
RUN apt-get install -y my-node-js-package

(ในสถานการณ์ของคุณโดยเฉพาะapt_setup.shจะมีความซับซ้อนมากขึ้นเพิ่มที่เก็บnodesourceและแพคเกจผู้ช่วยบางอย่างเช่นapt-transport-https .)

ดังนั้นจึงเป็นไปได้ที่จะใช้แพ็คเกจ DebianและDockerพร้อมกันอย่างไรก็ตาม ...

ลำไส้ของฉัน […] กำลังบอกฉันว่าถ้าแพ็คเกจ deb เหมาะสมดีมันจะเป็นเรื่องธรรมดามากขึ้น

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

ระบบบรรจุภัณฑ์ "เป็นทางการ" จากการจัดจำหน่ายที่กำหนดเป็นเพียงความเป็นไปได้ในหมู่ผู้อื่นในการติดตั้งซอฟต์แวร์ในสภาพแวดล้อมการคำนวณบางอย่าง มีแหล่งข้อมูลอื่น ๆ มากมายเช่นผู้จัดการแพคเกจเฉพาะชุมชนเช่นnpmหรือopam,ต้นไม้พอร์ตเช่นpkgsrcและการแจกจ่ายซอร์สโค้ดธรรมดา จากมุมมองนี้มันเป็นเรื่องง่ายที่จะเข้าใจความสำเร็จของนักเทียบท่าในฐานะระบบบรรจุภัณฑ์เฉพาะกิจ :

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

• หางมี“ในตัว” (ค่าใช้จ่าย) ให้บริการโฮสติ้งสิ่งของมันผลิตที่หาง Hub

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

ข้อสรุป

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

ใช่มีข้อเสียคือ

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

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

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

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

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

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

ผู้พัฒนาที่สร้างแพ็คเกจและไม่เข้าใจความผิดพลาดและความซับซ้อนในการกลายพันธุ์นั้นประสบปัญหามากมาย

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

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

พูดคุยเกี่ยวกับชิ้นส่วนบรรจุภัณฑ์ภาพของ Docker โดยเฉพาะไม่ใช่ตัวรันไทม์ของคอนเทนเนอร์มีบิตเล็กน้อย ที่ใหญ่ที่สุดคือรูปภาพของนักเทียบท่าเป็นเหมือน chroot ซึ่งหมายความว่าคุณถูกป้องกันโดยไม่ตั้งใจโดยขึ้นอยู่กับสถานะของระบบที่ใช้ร่วมกันเนื่องจากไฟล์ทุกไฟล์ที่ใช้งานจะต้องรวมอยู่ในภาพอย่างชัดเจนในขณะที่แพ็คเกจระบบอาจรับลิงก์แบบไดนามิก คาดหวังหรือรับพันมากขึ้นกับแพคเกจอื่น ๆ สิ่งนี้สามารถเกิดขึ้นกับการพึ่งพา C ที่ซับซ้อนซึ่งการโหลดโดยที่คุณไม่รู้ตัวอย่างเช่น OpenSSL นอกจากนี้การใช้แพ็กเกจ deb ไม่ทำซ้ำบิตที่แชร์กันในระบบจัดเก็บข้อมูลของ Docker สำหรับบางอย่างนี้อาจเป็นสิ่งที่ดีประสิทธิภาพ I / O ที่ดีขึ้นและชิ้นส่วนที่เคลื่อนไหวน้อยลง แต่สำหรับบางคนอาจเป็นปัญหา