แผนกไอทีควรเลือกการกระจาย Linux แบบมาตรฐานอย่างไร

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

สมมติว่าเราพยายามเลือกการกระจาย Linux เพื่อสร้างมาตรฐานบน (เพราะเรามีความสนใจในการรักษาสภาพแวดล้อมของเราให้เป็นเนื้อเดียวกันมากที่สุด) เกณฑ์ใดบ้างที่สำคัญและคุณจะทำการตัดสินใจอย่างไรเกี่ยวกับการกระจายที่แตกต่างกัน

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

1. ประวัติศาสตร์ - เห็นได้ชัดว่าระบบอย่าง RedHat และ Debian นั้นใช้เวลานานมาก เช่นนี้สุภาษิต "ถ้ามันยังไม่พังไม่สามารถแก้ไขได้" สามารถใช้สำหรับสิ่งเหล่านี้ได้ การอัพเกรดจะง่ายขึ้นหากซอฟต์แวร์รองรับ distro
2. ความคุ้นเคย - คล้ายกับประวัติศาสตร์อย่างไรก็ตามเราทุกคนมีรายการโปรดของเรา ฉันตัดฟันของฉันบน Debian และย้ายไปที่ Ubuntu (การตัดสินใจที่ยากลำบากในเวลานั้นเพราะฉันมักจะผูกพันกับชุมชน) ในทางกลับกันมันเป็นความเจ็บปวดที่ต้องจำไว้ว่าต้องทำสิ่งต่าง ๆ ในสถานที่ที่แตกต่างกันหลายสิบแห่ง (ไม่พูดถึงคนที่สร้างรอยขีดข่วน)
3. การสนับสนุน - ฉันย้ายไปที่ Ubuntu เพราะฉันชื่นชมสิ่งที่พวกเขาทำเท่าที่เสนอให้การสนับสนุนที่จ่ายเงิน นั่นคือจุดขายหากลูกค้ามีความกังวลเกี่ยวกับการใช้ระบบระยะยาว คล้ายกับแนวทางของ RedHat (แต่ขณะนี้ RPM กำลังเกิดขึ้น) เรามีเซิร์ฟเวอร์ RedHat จำนวนมากด้วยเหตุนี้
4. การพึ่งพา - ซอฟต์แวร์บางตัวใช้งานง่ายกว่าใน distros บางตัวเนื่องจากแพ็คเกจที่ขึ้นต่อกันนั้นหาได้ง่ายกว่าหรือสามารถสร้างได้ ตัวอย่างของสิ่งนี้จะเป็น oVirt บน RedHat ไม่มีแพ็คเกจสำหรับซอฟต์แวร์บางตัวใน distros บางตัว และคุณสามารถคอมไพล์มันได้ แต่ทำไมคุณถึงจะทำถ้าหีบห่ออยู่ที่นั่นบน distro อื่น?
5. Granularity - Distros เช่น Gentoo ให้การควบคุมที่ละเอียดยิ่งขึ้นเกี่ยวกับการกำหนดเวอร์ชันและการสลับที่ละเอียดของซอฟต์แวร์ Distros อื่น ๆ มี "การตรึง" ในรูปแบบต่าง ๆ แต่ก็ยังไม่สามารถควบคุมได้หรือเชื่อถือได้
6. การผูก - ในขณะที่มีความเป็นไปได้ในการรวบรวมจากแหล่งที่มาของ distros ส่วนใหญ่ distros บางตัวจะดีกว่าตัวอื่น สิ่งนี้อาจมีผลกระทบถ้าโครงการของคุณแก้ไขไลบรารีที่มีอยู่สำหรับการใช้งานที่ขยายเพิ่ม
7. ความน่ารัก - ความเพี้ยนบางอย่างดูดีกว่า ทุกคนรู้ดีว่ามันเป็นขุย (และคุณอาจหลีกเลี่ยงที่จะทำมันในฐานะที่เป็นเว็บแอพในวันนี้) แต่ลูกค้าบางคนรู้สึกประทับใจกับสิ่งนี้และเราทุกคนรู้
8. Stability - ซอฟต์แวร์ distros "เสถียร" บางรุ่นเมื่อเทียบกับ "การทดสอบ", "การทดลอง" ฯลฯ อาจมีความหมายมากถ้าคุณรู้ว่ารุ่นที่คุณกำลังสร้างจะมีความมั่นคงในที่สุด คุณอาจพัฒนาโดย "ทดลอง" โดยรู้ว่าเมื่อโครงการของคุณเสร็จสิ้นโครงการจะถึง "เสถียร" และเชื่อถือได้
9. การจัดการบรรจุภัณฑ์ - หากคุณกำลังพัฒนาบางสิ่งบางอย่างเป็นประจำทุกวันและกำลังจะออกไปสู่เครื่องจักรจำนวน 1,000 เครื่องในการเข้าชมครั้งเดียวคุณอาจต้องการสิ่งที่ทำให้การสร้างบำรุงรักษาและติดตามพัสดุข้ามระบบเหล่านั้นเป็นเรื่องง่าย
10. ความสอดคล้อง - นี่เป็นอาร์กิวเมนต์สำหรับdistro เดียวกันมากกว่า เกิดข้อผิดพลาดน้อยลง (และมีข้อผิดพลาดด้านความปลอดภัยน้อยลง) เมื่อผู้คนสามารถมุ่งเน้นไปที่ distro เดียวเมื่อเทียบกับหลาย ๆ
11. กำหนดการวางจำหน่ายที่คาดการณ์ได้ - หากคุณต้องการให้แน่ใจว่าซอฟต์แวร์ของคุณยังคงรองรับอยู่การอัพเกรดตามแผนจะมอบความมั่นคงบางประเภท
12. ความปลอดภัย - distros บางแห่งมีทีมรักษาความปลอดภัยที่มีหน้าที่ตอบสนองต่อความเสี่ยงด้านความปลอดภัยของแท้ในแพ็คเกจที่ได้รับอนุมัติ

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

ฉันจะแบ่งปันประสบการณ์การทำงานเป็นนักเทคโนโลยีในสาขาที่แตกต่างกัน ...

(ข้อควรระวัง: นี่เป็นเรื่องราวเกี่ยวกับ Red Hat และวิธีที่ฉันเติบโตมาอย่างมืออาชีพ)

ฉันเริ่มทำงานกับ Linux อย่างมืออาชีพในปี 2000-2002 นี้เป็นช่วงการยอมรับกว้างของ Red Hat และรุ่น Red Hat มืออาชีพ (6.x, 7.x 8.0) สิ่งเหล่านี้สามารถดาวน์โหลดได้ฟรีรวมถึงชุดบรรจุกล่อง พวกเขาสามารถพบได้ง่ายในร้านค้าปลีกคอมพิวเตอร์

สำหรับฉันแล้วสิ่งนี้มีประโยชน์ในการดึงดูดผู้ใช้งานอดิเรกและผู้ใช้ตามบ้านด้วยผลิตภัณฑ์เดียวกับที่เริ่มปรากฏให้เห็นในองค์กร งานของฉันในตอนนี้คือการย้ายระบบเซิร์ฟเวอร์ลูกค้าจาก Unices เชิงพาณิชย์ (HP-UX, AIX และ SCO) ไปยังแพลตฟอร์ม Red Hat

ประหยัดค่าใช้จ่ายเป็นกอบเป็นกำ! การแทนที่เซิร์ฟเวอร์ $ 100k + HP9000 PA-RISC ด้วยเซิร์ฟเวอร์ Compaq ProLiant Intel ราคา $ 40k เป็นสิ่งที่ได้รับรางวัลด้านต้นทุนและประสิทธิภาพอย่างแน่นอน

ดังนั้นทำไม Red Hat

Red Hat เป็นรายแรกในตลาดที่ได้รับการสนับสนุนทางธุรกิจผู้ขายและฮาร์ดแวร์ที่สำคัญ การเห็นผู้ค้าแอพพลิเคชั่นขนาดใหญ่ใช้ Red Hat เป็นแพลตฟอร์มเป้าหมายปิดการขาย ผู้ใช้งานอดิเรกอย่างฉันสามารถถ่ายโอนทักษะที่ได้รับจากที่บ้านกับสภาพแวดล้อมการทำงานของเราได้อย่างง่ายดาย ชุมชนกำลังเติบโต Slashdot , FreshmeatและLAMP stackปกครอง! เป็นเวลาที่ดีสำหรับ Linux

ในตอนนี้ฉันมีหน้าที่รับผิดชอบในการพัฒนาและประเมินผลการกระจาย Linux ซึ่งเป็นแพลตฟอร์มสำหรับโซลูชันซอฟต์แวร์ ERP ที่เป็นกรรมสิทธิ์ ฉันติดกับ Red Hat บ่อยครั้งที่ฉันจะลอง distro อื่น ( Mandrake , SuSE , Debian , Gentoo ) แต่จะพบปัญหาเกี่ยวกับบรรจุภัณฑ์การสนับสนุนฮาร์ดแวร์ (เซิร์ฟเวอร์หรืออุปกรณ์ต่อพ่วง) ชุมชน(ขนาดของ)หรือผู้ทำลายข้อตกลงอื่น ๆ

ตัวอย่าง: ผมใช้ฮาร์ดแวร์ Compaq / HP ProLiant แต่งตัวด้วยDigi ขยายตัวอนุกรมการ์ด PCI-Xและซอฟต์แวร์แฟกซ์ผลิต Esker VSIfax สองหลังมีเพียงไดร์เวอร์ที่รองรับระบบปฏิบัติการ Red Hat ในบางกรณีซอฟต์แวร์จะถูกส่งในรูปแบบไบนารีหรือ RPM เท่านั้นทำให้ไม่สามารถใช้งานได้กับสายพันธุ์อื่น ๆ ของ Linux

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

ฮันนีมูน Red Hat สิ้นสุดลงในปีพ. ศ. 2546 โดยมีการยกเลิกซอฟต์แวร์รุ่นมืออาชีพ Red Hat Enterprise Linuxเป็นสิ่งทดแทนและมาพร้อมกับกระเป๋าสัมภาระ ... ค่าใช้จ่าย (แบบจำลองการสมัครสมาชิกที่มีราคาแพง) การเข้าถึง (ลดฐานผู้ใช้และชุมชน) และความสับสนทั่วไปเกี่ยวกับอนาคต ...

ฉันเริ่มมองหาทางเลือกใหม่ประเมิน Gentoo, Debian และ SuSE ฉันไม่สามารถรับการสนับสนุนที่ถูกต้องในส่วนประกอบทั้งหมดของสแต็คเทคโนโลยีของเรา ฉันถูกบังคับให้ติดกับระบบนิเวศของ Red Hat ... เนื่องจากการเปลี่ยนแปลงค่าใช้จ่ายที่เกี่ยวข้องกับ Red Hat Enterprise Linux ฉันจึงลงเอยด้วยการใช้ Red Hat 8.0 ที่ได้รับการแก้ไขอย่างมากในช่วงหลายปีที่ผ่านมา มันไม่ได้จนกว่าโคลน RHEL จะครบกำหนด ( Whitebox Linuxและต่อมาCentOS ) ที่ฉันเตรียมการย้ายจริงออกไปจากมาตรฐานของฉัน

ข้อได้เปรียบที่สำคัญของสัญญาซื้อขายล่วงหน้าของ Red Hat คือและเข้ากันได้เป็นไบนารีกับรุ่น RHEL จ่าย มันเป็นไปได้ที่จะทำการแปลงในสถานที่ระหว่าง RHEL และ CentOS และในทางกลับกัน ฉันยังคงทำงานกับระบบที่เหมือน RHEL ต่อไปจนกว่าฉันจะก้าวไปสู่อาชีพการงานต่อไป ...

ต่อมาฉันพบว่าตัวเองอยู่ในอุตสาหกรรมการค้าทางการเงินความถี่สูงซึ่งฉันต้องรับผิดชอบด้านการวิจัยและพัฒนาและวิศวกรรมลีนุกซ์สำหรับระบบการซื้อขายอัตโนมัติที่สำคัญ ความสำคัญในโลกนี้คือความเร็วโดยการทดสอบและปรับจูนอย่างระมัดระวัง การสนับสนุนฮาร์ดแวร์เป็นกุญแจสำคัญอีกครั้ง ฉันมีเฉพาะการ์ดเครือข่าย , ฮาร์ดแวร์เฉพาะฮาร์ดแวร์เซิร์ฟเวอร์หรือไลบรารีแอปพลิเคชันที่ได้รับการรับรองสำหรับระบบ RHEL หรือ RHEL เท่านั้น แม้ในกรณีที่สิ่งต่าง ๆ สามารถรวบรวมสำหรับตัวแปร Linux อื่น ๆ ปัจจัยชุมชนก็เกิดขึ้น เมื่อฉันมาถึงจุดที่ฉันต้องการค้นคว้าปัญหาบ่อยครั้งที่มีปัญหาที่สามารถตรวจสอบบันทึกหรือความคิดเห็นในรายงาน Red Hat Bugzilla หรือบางครั้งฉันก็แค่ส่ง patch หรือร้องขอรุ่นถัดไป .

ขณะที่ผมเริ่มที่จะเจาะเข้าไปในเครือข่าย latency ต่ำและการปรับแต่งเคอร์เนลผมเริ่มที่จะผ่าหุ้นเมล็ด RHEL และRHEL MRG เรียลไทม์เมล็ด ฉันสังเกตเห็นว่ามันทำงานได้มากแค่ไหนในการวางจำหน่าย ... 200+ patch ไปยังเคอร์เนล vanilla kernel.org อ่านความคิดเห็นและส่งบันทึก คุณอาจมีสิ่งเล็ก ๆ เช่นการsysctlเปิดเผยพารามิเตอร์หรือใช้ค่าเริ่มต้นที่มีสติ Red Hat จ่ายให้ผู้คนทำการทดสอบและแก้ไขปัญหาเหล่านี้ ผมไม่ได้เห็นความมุ่งมั่นเดียวกันจากลินุกซ์อื่น ๆ ... เพิ่มความจริงที่ว่าแพลตฟอร์มองค์กรที่มีการรับประกันว่าจะมีการรักษาความปลอดภัยจริง bugfix และการสนับสนุนสำหรับการย้ายกลับปี

ดังนั้นในที่สุดฉันก็ย้ายไปที่ บริษัท ทางการเงินอื่นที่เกือบจะเป็น Gentoo บนเซิร์ฟเวอร์และเดสก์ท็อป ... มันเป็นหายนะสำหรับฉัน มาจากโลกของ Red Hat และ CentOS ฉันพบปัญหาความมั่นคงและการจัดการกับ Gentoo setup การควบคุมเวอร์ชันเป็นปัญหาที่ใหญ่ที่สุด แต่การสนับสนุนจากชุมชนลดน้อยลงและขาดการทดสอบที่แท้จริง ฉันเริ่มแนะนำ RHEL สู่สิ่งแวดล้อมเพราะซอฟต์แวร์บุคคลที่สามบางตัวของเราจำเป็นต้องใช้ ...

แต่มีปัญหา ... นักพัฒนาของฉันคุ้นเคยกับ Gentoo และมีเส้นทางการอัพเกรดที่ค่อนข้างง่ายสำหรับไลบรารีหลักและเวอร์ชันแอปพลิเคชัน พวกเขาไม่สามารถปรับตัวให้มีเวอร์ชันหลักคงที่ซึ่ง Red Hat Enterprise Linux เป็นมาตรฐาน กระบวนการพัฒนาและวางจำหน่ายมีคำถามว่าทำไม GLIBC 2.7 จึงไม่สามารถนำกราฟต์ลงใน RHEL 5.xหรือทำไมคอมไพเลอร์หรือไลบรารี่รุ่นใดรุ่นหนึ่งถึงไม่สามารถใช้งานได้ เมื่อบอกว่าการอัพเกรดระหว่างรุ่นใหญ่ของ RHEL / CentOS นั้นจำเป็นต้องมีการสร้างใหม่อย่างเต็มรูปแบบพวกเขาสูญเสียความมั่นใจอย่างมากในการแก้ปัญหา

เมื่อมาถึงจุดนี้ฉันรู้ว่า Red Hat เดินช้าเกินไปสำหรับนักพัฒนาที่ต้องการตกเลือด / เป็นผู้นำ RHEL 6.x เป็นอัพเกรดที่จำเป็นมากและยินดีต้อนรับ แต่รูปแบบนี้ก็เห็นได้ชัดอีกครั้งผมเริ่มการสัมภาษณ์ผู้ที่เพิ่งเริ่มต้นและ บริษัท ที่สมัครเป็นสมาชิกหลักการ DevOps

วันนี้ ...
จำนวนนักพัฒนาและผู้ใช้งานระบบลินุกซ์ที่เพิ่มขึ้นมาจากสภาพแวดล้อมที่ไม่ใช่ Red Hat, Non-SuSE, non-enterprise Linux

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

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

ฉันเห็นโฆษณาตำแหน่งงานวันนี้สำหรับตำแหน่งวิศวกร DevOps Linux ที่อายุน้อยมากที่อ่าน:

ต้องมีความเชี่ยวชาญสำหรับผู้เชี่ยวชาญด้านการกระจาย Linux ที่ใช้ Debian (Ubuntu และรุ่นต่างๆโอเค Red Hat ที่พอใช้ได้แต่ไม่ต้องการ)

ดังนั้นฉันคิดว่ามันใช้งานได้ทั้งสองวิธี ... ฉันเดินออกไปจากโอกาสในการทำงานเพราะเซิร์ฟเวอร์ 800 CentOS ที่ฉันกำลังจัดการอยู่นั้นถูกกำหนดให้เปลี่ยนเป็น Ubuntu แน่นอนว่า Linux คือ Linux ... แต่ฉันไม่รู้สึกว่าฉันจะมีประสิทธิภาพเท่าที่ฉันจะเป็นได้ ... ฉันคลุกคลีกับการติดตั้ง Debian และหวังว่า distro ที่ใช้ RPM นั้นใช้งานอยู่ ฉันมีข้อโต้แย้งที่ร้อนแรงเกี่ยวกับข้อดีของแพลตฟอร์มต่าง ๆ (มักจะวาง Gentoo ที่ด้านล่างของรายการ)

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

นักพัฒนาที่มีความสามารถควรทำงานในสภาพแวดล้อมแบบ RHEL หรือแบบ Debian ได้ และแพลตฟอร์มการพัฒนาควรสะท้อนสภาพแวดล้อมการผลิต คุณไปจากที่นั่น ...