หลักการ UNIX ของ Ken Thompson ที่อยู่เบื้องหลังคอนเทนเนอร์และระบบปฏิบัติการคลาวด์

ทำไม Ken Thompson และ UNIX ยังคงมีความสำคัญ

Ken Thompson ไม่ได้ตั้งใจสร้าง “ระบบปฏิบัติการที่คงทนตลอดไป” แต่ร่วมกับ Dennis Ritchie และทีมที่ Bell Labs เขาต้องการระบบเล็ก ๆ ที่ใช้งานได้ง่าย ที่นักพัฒนาจะเข้าใจ ปรับปรุง และย้ายข้ามเครื่องได้ UNIX ถูกหล่อหลอมด้วยเป้าหมายเชิงปฏิบัติ: ทำให้แกนหลักเรียบง่าย ให้เครื่องมือทำงานร่วมกันได้ดี และหลีกเลี่ยงการล็อกผู้ใช้ไว้กับรูปแบบคอมพิวเตอร์หนึ่งเครื่อง

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

• จะเชื่อมต่อส่วนประกอบอย่างไรโดยไม่ให้เกิดความยุ่งเหยิง?
• จะแยกงานอย่างปลอดภัยได้อย่างไร?
• จะเปลี่ยนส่วนหนึ่งโดยไม่ทำลายส่วนนั้นทั้งหมดได้อย่างไร?

หลักการชนะคุณสมบัติ

ฟีเจอร์เฉพาะของ UNIX อาจวิวัฒน์ (หรือตกยุค) แต่หลักการออกแบบยังคงมีประโยชน์เพราะมันอธิบาย วิธีการสร้างระบบ:

• เน้นเครื่องมือเล็ก ๆ ที่มุ่งทำงานเดียวให้ดี แทนโปรแกรมยักษ์แบบ all-in-one
• ใช้อินเทอร์เฟซเรียบง่ายเพื่อให้ส่วนต่าง ๆ สามารถรวมกันได้
• รักษาขอบเขตให้ชัดเจน (ระหว่างผู้ใช้ กระบวนการ และสิทธิ์)

แนวคิดเหล่านี้ปรากฏอยู่ทั่วไป—ตั้งแต่ความเข้ากันได้กับ Linux และ POSIX ไปจนถึงรันไทม์คอนเทนเนอร์ที่พึ่งพาการแยกกระบวนการ, namespaces และเทคนิคไฟล์ซิสเต็ม

บทนำของบทความนี้จะพาไปทางไหน

เราจะเชื่อมแนวคิดยุค Thompson ของ UNIX กับสิ่งที่คุณเจอวันนี้:

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

ควรคาดหวังอะไร

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

คุณยังสามารถเลื่อนไปที่ /blog/how-unix-ideas-show-up-in-containers เมื่อคุณพร้อมได้

ประวัติย่อเชิงปฏิบัติของ UNIX

UNIX ไม่ได้เริ่มด้วยกลยุทธ์แพลตฟอร์มใหญ่โต แต่มันเกิดจากระบบเล็ก ๆ ที่ใช้งานได้จริง สร้างโดย Ken Thompson (กับผลงานสำคัญของ Dennis Ritchie และคนอื่น ๆ ที่ Bell Labs) ที่ให้ความสำคัญกับความชัดเจน ความเรียบง่าย และการทำงานที่เป็นประโยชน์

ไทม์ไลน์สั้น ๆ (ส่วนที่สำคัญ)

• 1969–1971: UNIX แรกเริ่มถูกสร้างบนฮาร์ดแวร์ระดับจำกัด จุดประสงค์คือสภาพแวดล้อมที่สะดวกสำหรับการเขียนและรันโปรแกรม ไม่ใช่การทดแทน mainframe
• 1973: UNIX ถูกเขียนใหม่เป็น C นี่คือจุดเปลี่ยนที่ทำให้ UNIX เคลื่อนย้ายข้ามเครื่องได้ง่ายขึ้นมาก
• ปลายทศวรรษ 1970–1980: UNIX แพร่หลายเข้าในมหาวิทยาลัยและผู้จำหน่าย เกิดระบบ “คล้าย UNIX” หลายตัวที่มีการปรับแต่งของตนเอง
• ตั้งแต่ทศวรรษ 1990 เป็นต้นมา: ความพยายามด้านมาตรฐาน (เช่น POSIX) ช่วยรักษาพฤติกรรมหลักให้สอดคล้องกัน แม้ว่าการใช้งานจะต่างกันไป

“ระบบปฏิบัติการพกพา” หมายถึงอะไรในสมัยนั้น—และทำไมถึงสำคัญ

ในวันแรก ๆ ระบบปฏิบัติการมักผูกติดกับรุ่นของเครื่อง ถ้าคุณเปลี่ยนฮาร์ดแวร์ คุณก็ต้องเปลี่ยน OS (และบ่อยครั้งซอฟต์แวร์) ด้วย

ระบบปฏิบัติการพกพา หมายถึงสิ่งที่เป็นประโยชน์: แนวคิดและโค้ดส่วนใหญ่สามารถรันบนเครื่องต่าง ๆ ได้โดยไม่ต้องเขียนใหม่มาก การเขียน UNIX ด้วย C ลดการพึ่งพา CPU ใด CPU หนึ่ง และทำให้เป็นไปได้ที่ผู้อื่นจะนำ UNIX ไปใช้และปรับแต่งได้จริง

UNIX คือครอบครัวของแนวคิด ไม่ใช่สินค้าหนึ่งตัว

เมื่อคนพูดว่า “UNIX” พวกเขาอาจหมายถึงเวอร์ชันดั้งเดิมของ Bell Labs, เวอร์ชันเชิงพาณิชย์, หรือระบบสมัยใหม่ที่คล้าย UNIX (เช่น Linux หรือ BSD) เส้นใยร่วมกันไม่ใช่แบรนด์เดียว แต่เป็นชุดการตัดสินใจด้านการออกแบบและอินเทอร์เฟซที่ใช้ร่วมกัน

นี่แหละที่ทำให้ POSIX สำคัญ: มาตรฐานนี้รวบรวมพฤติกรรม UNIX หลายอย่าง (คำสั่ง, การเรียกระบบ, ข้อตกลง) ช่วยให้ซอฟต์แวร์ยังคงเข้ากันได้ข้ามระบบต่าง ๆ แม้ว่าการใช้งานพื้นฐานจะแตกต่างกัน

เครื่องมือเล็ก ๆ ที่ประกอบกันได้: แนวคิดหลักของ UNIX

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

ทำไม “ขนาดเล็ก” เป็นข้อได้เปรียบเชิงปฏิบัติ

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

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

แบบจำลองทางความคิด: การประกอบชนะความซับซ้อน

คิดว่าเครื่องมือ UNIX เหมือนบล็อก LEGO แต่ละบล็อกเรียบง่าย พลังอยู่ที่วิธีการเชื่อมต่อกัน

ตัวอย่างคลาสสิกคือการประมวลผลข้อความ ที่คุณแปลงข้อมูลทีละขั้นตอน:

cat access.log | grep " 500 " | sort | uniq -c | sort -nr | head

แม้คุณจะไม่จำคำสั่งทั้งหมด แต่แนวคิดชัดเจน: เริ่มจากข้อมูล กรอง สรุป แล้วแสดงผลสูงสุด

สิ่งนี้สะท้อนในระบบสมัยใหม่ (แม้จะไม่เหมือนกันทั้งหมด)

ไมโครเซอร์วิสไม่ใช่ “เครื่องมือ UNIX บนเครือข่าย” และการบังคับให้เทียบแบบนั้นอาจทำให้เข้าใจผิด แต่สัญชาตญาณพื้นฐานคุ้นเคย: รักษาส่วนประกอบให้มุ่งหน้าที่ชัดเจน กำหนดขอบเขตชัด และประกอบระบบใหญ่จากชิ้นเล็กที่พัฒนาได้อย่างอิสระ

ท่อและสตรีมมาตรฐาน: สร้างระบบที่ใหญ่ขึ้น

UNIX ได้พลังจากข้อสอดคล้องง่าย ๆ: โปรแกรมควรอ่านอินพุตจากที่หนึ่งและเขียนเอาต์พุตไปยังอีกที่ในวิธีที่คาดเดาได้ ข้อสอดคล้องนี้ทำให้รวมเครื่องมือเล็ก ๆ เป็น “ระบบ” ที่ใหญ่ขึ้นได้โดยไม่ต้องเขียนใหม่

ท่อ อธิบายแบบธรรมดา

ท่อ เชื่อมเอาต์พุตของคำสั่งหนึ่งเข้ากับอินพุตของอีกคำสั่งหนึ่ง คิดเหมือนการส่งโน้ตต่อกัน: เครื่องมือตัวหนึ่งผลิตข้อความ เครื่องมือต่อมาบริโภคมัน

เครื่องมือ UNIX มักใช้ช่องทางมาตรฐานสามช่อง:

• Standard input (stdin): ที่โปรแกรมอ่านจาก (มักเป็นคีย์บอร์ดหรือโปรแกรมอื่น)
• Standard output (stdout): ที่โปรแกรมเขียนผลลัพธ์ปกติ
• Standard error (stderr): ที่โปรแกรมเขียนคำเตือนและข้อผิดพลาด

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

ทำไมสิ่งนี้จึงนำไปสู่การนำกลับมาใช้และการอัตโนมัติได้

ท่อส่งเสริมให้เครื่องมือมีขนาดเล็กและมุ่งหน้าที่ หากโปรแกรมสามารถรับ stdin และส่ง stdout มันจะนำกลับมาใช้ได้ในหลายบริบท: การใช้งานแบบโต้ตอบ งานแบตช์ งานตามเวลา และสคริปต์ นี่คือเหตุผลว่าทำไมระบบที่คล้าย UNIX จึงเหมาะกับการเขียนสคริปต์: การอัตโนมัติมักคือ “เชื่อมชิ้นส่วนเหล่านี้”

ความคล้ายสมัยใหม่ที่คุณคุ้นเคย

• สตรีมล็อก: การ tail โลก์และกรองมัน (ท้องถิ่นหรือบนแพลตฟอร์ม) สะท้อนการส่งข้อความผ่านตัวกรอง
• ETL pipelines: extract → transform → load คือการประกอบทีละขั้น แม้ว่าข้อมูลจะเป็น JSON แทนข้อความธรรมดา
• สคริปต์เชื่อม: shell, Python หรือขั้นตอน CI มักมีหน้าที่เชื่อมเครื่องมือ—แนวคิดท่อและสตรีมเดิม ๆ

การประกอบนี้เป็นเส้นตรงจาก UNIX ยุคแรกสู่การประกอบเวิร์กโฟลว์คลาวด์ปัจจุบัน

“ทุกอย่างคือไฟล์”: อินเทอร์เฟซเรียบง่ายที่มีผลกว้าง

UNIX ทำให้เรียบง่ายอย่างกล้าหาญ: ให้ทรัพยากรต่าง ๆ ทำตัวเหมือนไฟล์ ไม่ใช่เพราะไฟล์บนดิสก์กับคีย์บอร์ดเหมือนกัน แต่เพราะการให้พวกมันมี อินเทอร์เฟซร่วมกัน (open, read, write, close) ทำให้ระบบเข้าใจง่ายและอัตโนมัติง่าย

ตัวอย่างที่เป็นรูปธรรมที่คุณอาจเคยใช้

• อุปกรณ์: เทอร์มินัล ดิสก์ หรือตัวสร้างเลขสุ่มอาจปรากฏใน /dev/. การอ่านจาก /dev/urandom ให้ความรู้สึกเหมือนอ่านไฟล์ แม้ว่าจริง ๆ แล้วเป็นไดรเวอร์อุปกรณ์ที่ผลิตไบต์
• ซ็อกเก็ตและท่อ: การเชื่อมต่อเครือข่ายและการสื่อสารระหว่างกระบวนการสามารถเปิดเผยผ่านตัวบ่งชี้ไฟล์ โปรแกรมของคุณเขียนไบต์ ระบบปฏิบัติการจัดเส้นทางให้
• คอนฟิก: ไฟล์คอนฟิกเป็นข้อความล้วน ทำให้ใช้เครื่องมือเดียวกันได้ทุกที่: แก้ไขด้วย editor, ตรวจด้วยสคริปต์, ติดตามการเปลี่ยนแปลงใน Git
• ล็อก: ล็อกมักเป็นไฟล์ที่เพิ่มต่อท้าย ทำให้หมุน, grep, tail, เก็บถาวร และส่งได้ง่าย

ทำไมเรื่องนี้สำคัญ: เครื่องมือเรียบและพฤติกรรมที่คาดหวังได้

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

นี่ยังส่งเสริมความเสถียร ทีมสามารถสร้างสคริปต์และนิสัยปฏิบัติการรอบปริมณฑลพื้นฐานไม่กี่อย่าง (สตรีมอ่าน/เขียน, เส้นทางไฟล์, สิทธิ์) และเชื่อว่าพื้นฐานเหล่านี้จะไม่เปลี่ยนทุกครั้งที่เทคโนโลยีพื้นฐานเปลี่ยน

การเชื่อมโยงกับคลาวด์: โลก์และโทรเมทรีแบบ /proc

การปฏิบัติการคลาวด์สมัยใหม่ยังยึดแนวคิดนี้ไว้ โลก์คอนเทนเนอร์มักถูกปฏิบัติเป็นสตรีมที่สามารถ tail และส่งต่อได้ Linux's /proc เปิดเผยโทรเมทรีของกระบวนการและระบบเป็นไฟล์ ดังนั้นเอเยนต์การมอนิเตอร์สามารถ “อ่าน” CPU, หน่วยความจำ และสถิติของกระบวนการเหมือนข้อความธรรมดา อินเทอร์เฟซรูปแบบไฟล์นี้ทำให้การสังเกตและการอัตโนมัติจับต้องได้แม้ในสเกลใหญ่

สิทธิ์และ least privilege: ความปลอดภัยที่ปรับขนาดได้

โมเดลสิทธิ์ของ UNIX ดูเรียบง่าย: ทุกไฟล์ (และทรัพยากรบางอย่างที่ทำหน้าที่เหมือนไฟล์) มี เจ้าของ, กลุ่ม, และชุด สิทธิ์ สำหรับสามกลุ่ม—ผู้ใช้, กลุ่ม, และ ผู้อื่น ด้วยเพียงบิตอ่าน/เขียน/รัน UNIX สร้างภาษาร่วมสำหรับใครทำอะไรได้บ้าง

พื้นฐาน: ความเป็นเจ้าของ + กฎง่าย ๆ

ถ้าคุณเคยเห็นอย่าง -rwxr-x--- คุณได้เห็นโมเดลทั้งหมดในบรรทัดเดียว:

• เจ้าของ (user): ปกติคือบัญชีที่สร้างหรือ “เป็นเจ้าของ” ไฟล์
• กลุ่ม: การรวมชื่อของผู้ใช้ที่แชร์การเข้าถึง
• ผู้อื่น: ทุกคนที่เหลือในระบบ

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

least privilege อธิบายแบบง่าย

Least privilege คือการให้บุคคล กระบวนการ หรือบริการ เฉพาะ สิทธิ์ที่ต้องใช้เท่านั้น ในทางปฏิบัติ มักหมายถึง:

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

แผนที่สู่ระบบสมัยใหม่

แพลตฟอร์มคลาวด์และรันไทม์คอนเทนเนอร์สะท้อนแนวคิดเดียวกันด้วยเครื่องมือที่ต่างออกไป:

• บัญชีบริการ (service accounts) คล้ายผู้ใช้ UNIX สำหรับงานมากกว่ามนุษย์
• นโยบาย/บทบาท IAM ทำหน้าที่เป็นระบบสิทธิ์ที่ละเอียดมากกว่าแค่บิต rwx
• สิทธิ์รันไทม์ (เช่น ไฟล์ที่คอนเทนเนอร์เขียนได้หรือการเข้าถึงอุปกรณ์โฮสต์) เป็นเวอร์ชันบริบทการรันของ least privilege

คำเตือนที่สำคัญ

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

กระบวนการเป็นแนวคิดชั้นหนึ่ง

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

โปรแกรม vs กระบวนการ (อุปมาในชีวิตประจำวัน)

โปรแกรม เหมือน การ์ดสูตรอาหาร: บอกวิธีทำ

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

ทำไมการแยกกระบวนการจึงปรับปรุงความน่าเชื่อถือ

ระบบ UNIX ออกแบบให้แต่ละกระบวนการมี “ฟอง” ของการรัน: หน่วยความจำของตัวเอง มุมมองไฟล์เปิดของตัวเอง และขอบเขตชัดเจนเกี่ยวกับสิ่งที่แตะต้องได้

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

บนระบบที่แชร์ การแยกยังสนับสนุนการแชร์ทรัพยากรที่ปลอดภัย: OS สามารถบังคับขีดจำกัด (เช่น เวลา CPU หรืิอหน่วยความจำ) และป้องกันไม่ให้กระบวนการหนึ่งวิ่งไม่หยุดจนทำให้คนอื่นอด

สัญญาณและการควบคุมงาน (เหมือน “เคาะที่ไหล่”)

UNIX ยังให้ สัญญาณ (signals) ซึ่งเป็นวิธีเบา ๆ ที่ระบบหรือคุณจะส่งข้อความถึงกระบวนการ คิดว่าเป็นการเคาะที่ไหล่:

• “กรุณาหยุด” (terminate)
• “พักสักครู่” (suspend)
• “โหลดคอนฟิกใหม่” (common สำหรับบริการที่รันยาว)

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

จากแล็ปท็อปหนึ่งเครื่องสู่การทำงานหลายงานบนเซิร์ฟเวอร์เดียว

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

อินเทอร์เฟซที่เสถียร: เหตุผลลับที่ทำให้ UNIX คงทน

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

“อินเทอร์เฟซเสถียร” คืออะไรจริง ๆ

อินเทอร์เฟซคือข้อตกลงระหว่างโปรแกรมกับระบบ: “ถ้าคุณขอ X คุณจะได้รับ Y” UNIX รักษาข้อตกลงหลักไว้ให้คงที่ (กระบวนการ, ตัวบ่งชี้ไฟล์, ท่อ, สิทธิ์) ซึ่งให้แนวทางให้แนวคิดใหม่เติบโตขึ้นโดยไม่ทำลายซอฟต์แวร์เก่า

API vs ABI (อธิบายง่าย ๆ)

คนมักพูดถึง “ความเข้ากันได้ของ API” แต่มีสองชั้น:

• API (Application Programming Interface): สิ่งที่ซอร์สโค้ดคาดหวัง ถ้าชื่อฟังก์ชัน อาร์กิวเมนต์ หรือพฤติกรรมเปลี่ยน โค้ดของคุณอาจคอมไพล์ไม่ได้หรือทำงานต่างไป
• ABI (Application Binary Interface): สิ่งที่ไบนารีคอมไพล์คาดหวัง ถ้าข้อตกลงการเรียก ฟอร์แมตไบนารี หรือสัญลักษณ์ไลบรารีเปลี่ยน โปรแกรมที่เคยรันอาจไม่เริ่มต้นแม้ซอร์สจะยังโอเค

ความเสถียรของ ABI เป็นเหตุผลสำคัญที่ระบบนิเวศอยู่ได้นาน: มันปกป้องโปรแกรมที่คอมไพล์แล้ว

POSIX: ความพกพาเป็นนโยบาย

POSIX เป็นความพยายามมาตรฐานที่รวบรวม user-space แบบ UNIX-like: การเรียกระบบ, ยูทิลิตี้, พฤติกรรมเชลล์ และข้อตกลง มันไม่ทำให้ทุกระบบเหมือนกัน แต่สร้างพื้นที่ทับซ้อนใหญ่ที่ซอฟต์แวร์สามารถสร้างและใช้ได้ข้าม Linux, BSDs และระบบที่สืบทอดมาจาก UNIX อื่น ๆ

ทำไมสิ่งนี้สำคัญต่อคอนเทนเนอร์

อิมเมจคอนเทนเนอร์พึ่งพาพฤติกรรม UNIX-like ที่เสถียร หลายอิมเมจสมมติว่า:

• โครงสร้างระบบไฟล์และโมเดลสิทธิ์ที่คาดเดาได้
• ยูทิลิตี้และเชลล์ทั่วไปทำงานอย่างคุ้นเคย
• สตรีมมาตรฐาน (stdin/stdout/stderr) และสัญญาณกระบวนการทำงานสอดคล้องกัน

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