Apple Containerization เมื่อ Apple อยากทำ Container ซะเอง

จากงาน WWDC 25 ที่ผ่านมา นอกจากจะมีการเปิดตัวของพวก OS ต่าง ๆ อย่าง iOS และ iPad 26 ก็ยังมีการเปิดตัวเครื่องมือสำหรับนักพัฒนาใหม่มากมาย วันนี้เราจะมาเล่าถึงตัวที่เราสนใจมาก ๆ คือ Containerization Framework ว่ามันแตกต่างจาก Container ที่เราใช้งานกันมาอย่างไร

Container คืออะไร ?

สำหรับใครที่ยังไม่คุ้นเคยกับ Concept ของการใช้ Container ขอปูพื้นฐานคร่าว ๆ ก่อนดีกว่า

ปกติ เวลาเราจะรันโปรแกรมสักตัว เราก็จะรันบนเครื่องของเราไปเลย ซึ่งมันจะประกอบด้วย Hardware ที่ลง OS แล้วค่อยเอา Runtime ของเรามารันทับ แต่ปัญหามีอยู่ว่า หากเราต้องการ Environment สำหรับการรันที่เฉพาะ การจะต้องมานั่ง Setup ใหม่ ก็น่าจะเป็นเรื่องที่ปวดหัวแน่นอน ไหนจะต้องติดตั้ง Dependencies อีกมหาศาล ยังไม่นับว่า หากเราต้องการ Isolate Environment ออกมา เราอาจจะต้องติดตั้งโดยการใช้ Virtual Machine ที่จะต้องลง OS แยก ทำให้กิน Resource หนักมากกว่าเดิมซะอีก

Container เกิดขึ้นมา โดยใช้หลักการว่า นักพัฒนาสามารถ Pack Application และ Dependencies ต่าง ๆ เก็บเอาไว้เป็นก้อน ๆ นึง เรียกว่า Image ที่เราสามารถเอามันไปรันอยู่ในเครื่องแบบไหนก็ได้ที่มี Container Service ติดตั้งเอาไว้ ทำให้เราสามารถ ติดตั้ง และจัดการ Environment ต่าง ๆ ได้ง่ายมากกว่าเดิม และกิน Resource น้อยลงกว่าเดิม อยากใช้งานอะไร เราก็แค่เรียก Image นั้น ๆ ออกมาสร้างเป็น Container ก็เรียบร้อยแล้ว นั่นคือภาพที่เราเห็นกันตอนใช้

ถ้าเรามองให้ลึกเข้าไปอีก ภาพที่เราเห็นกันเวลาเรารัน Container คือ เราจะมี OS ขึ้นไป แล้วเป็น Container Engine แล้วค่อยตามด้วย Filesystem ที่แยกออกมา และค่อยเป็น Application อีกทีนึง ข้อดีเมื่อเทียบกับการใช้ VM คือ เราสามารถแยก Environment ได้เหมือนกัน แต่เราไม่ต้องเสีย Resource ไปกับ Guest OS ที่เพิ่มขึ้นเรื่อย ๆ เมื่อเราเพิ่ม Application ขึ้นไปเรื่อย ๆ ทำให้การใช้ Container นั้นดูเป็นทางเลือกที่จำนวนการเพิ่มขึ้นของ Resource ไม่มากเท่าการใช้ VM แน่นอน

ซึ่งภาพที่เรามองกันจริง ๆ เราอาจจะมองว่า Container มันเป็นอะไรที่วิเศษมาก ๆ แต่จริง ๆ แล้วการมีตัวตนของมันเรียบง่ายกว่านั้นเยอะมาก เพราะมันเป็นเพียงแค่ Process อันนึงเท่านั้น แต่เป็น Process พิเศษที่เหมือนโดนใส่หน้ากากเข้าไปอีกที ทำให้ตัวมันมองไม่เห็น System จริง ๆ พูดง่าย ๆ กว่านั้นคือ โดน chroot ใส่เลย

เราสามารถพิสูจน์เรื่องนี้ได้ง่ายมาก เพียงแค่เรารัน Container นึงขึ้นมา แล้วลอง top ดู เราจะเห็น Process ภายใน Container รันอยู่ในเครื่องของเราเฉยเลย แต่ถ้าเราทดสอบวิธีเดียวกันบน macOS และ Windows เราจะไม่เห็นเลย

นั่นเป็นเพราะ ในความเป็นจริงฝั่ง Container ในฝั่ง macOS และ Windows มันไม่ได้ทำงานแบบนั้น แต่มันจะมี Hypervisor เพื่อรัน Linux VM แล้วค่อยรัน Container Engine อีกทีนึง ทำให้เราไม่สามารถทำเหมือนที่เราทดลองในฝั่ง Linux ได้นั่นเอง ถ้าเราลองไปดูใน Settings ของ Docker ตรงส่วนของ General เลื่อนลงมา เราจะเห็นตรง Virtual Machine Option อยู่ ค่าพื้นฐาน ณ​ วันที่เขียนฝั่ง macOS จะใช้ Apple Virtualisation Framework ที่เป็น Hypervisor ของ Apple เอง ที่เดี๋ยวเราจะพูดถึงกันอีกที

Design Principle

ก่อนอื่นเลย เราจะต้องทำความเข้าใจกับ Design Principle ของการออกแบบ Containerlization Framework ของ Apple กันก่อน เพราะมันจะลิงค์ไปหาว่า ทำไมเขาถึงต้อง Design มันออกมาในลักษณะแบบนี้

Apple บอกว่า เขา Design โดยให้ความสำคัญกับ 3 เรื่อง คือ Secure, Private และ Performant

เรื่องแรกคือ Secure ฝั่ง Apple บอกว่า เขาต้องการให้การใช้งาน Container มันปลอดภัยได้ Isolated Environment ที่ดีเทียบเท่ากับการใช้ Virutal Machine กับต้องการจัดการให้ลดการเรียกใช้ทั้ง Core Utilities และ Dynamic Utilities จากภายนอก เน้นรวมศูนย์ไปเลย เพื่อลดขั้นตอนการ Update ส่งผลโดยตรงต่อการลด Attack Surface และ Maintenance Cost ลงไปได้

เรื่องที่ 2 คือ Private เป็นอีกเรื่องที่สำคัญ คือ จะมีการควบคุมการเข้าถึงไฟล์ในระดับ Container ไปเลยว่า Container ไหนจะเข้าถึงไฟล์ในระบบจริง ๆ ได้มากน้อยแต่ไหน

และสุดท้ายคือ Performant คือ ไม่ว่ามันจะปลอดภัย หรือ Private แค่ไหน ประสิทธิภาพในการทำงานที่ดี และเรียก Resource ไม่หนัก ก็เป็นเรื่องสำคัญด้วยเช่นกัน

Security Perspective

ความปลอดภัยเป็นประเด็นที่ Apple ให้ความสำคัญกับ Container Framework ตัวนี้สูงมาก ๆ อย่างแรกคือ Apple เลือกที่จะแยก VM ใส่แต่ละ Container โดยตรง แทนที่จะใช้ VM เดียวรันทุก Container เลย ด้วยการออกแบบลักษณะนี้ ทำให้สามารถลด Attack Surface และที่สำคัญมาก ๆ คือ ลดความเสี่ยงที่อาจจะเกิดขึ้นเกี่ยวกับการใช้ Kernel ตัวเดียวกันหมด ที่ทำให้ หากมีช่องโหว่บน 1 Container ก็คือเสี่ยงแตกกันหมดได้เลย และที่สำคัญที่สุดคือ หากเราไม่รัน Container เลย เราจะไม่เสีย Resource อะไรทั้งสิ้น แตกต่างจาก Docker และ Podman บน macOS และ Windows ที่ต้องรัน Linux VM ทิ้งไว้ แม้จะไม่มี Container กำลังทำงานอยู่เลย

แต่ปัญหาของการออกแบบลักษณะนี้คือ แล้วมันจะต่างอะไรกับการใช้งาน VM แบบเมื่อก่อนละ เรื่องนี้ Apple บอกว่า Hypervisor ที่รันจะใช้ Apple Virtualisation Framework บวกกับ Lightweight Linux ที่ทำให้ตัวมันกิน Overhead Resource ที่น้อยมาก ๆ และใช้เวลาในการ Start ที่สั้นอย่างไม่น่าเชื่อ เรากำลังพูดกันถึงระดับไม่ถึงวินาทีเท่านั้นเอง

ดังนั้นด้วยการออกแบบลักษณะนี้ จึงทำให้ ระบบนี้มีความปลอดภัยและความเป็นส่วนตัวในการทำงานที่สูงมาก ๆ เวลาเราจะ Deploy งานที่มี Sensitive Information เราก็จะได้สบายใจขึ้นไปอีกระดับหนึ่งได้ด้วย

Privacy Perspective

ในฝั่งของ Privacy เองถือว่าเป็นอีก Feature ที่ถูกให้ความสำคัญไม่แพ้กัน ก่อนหน้านี้ หากเราต้องการ Mount File เข้าไปใน Container หลักการคือ มันจะทำการสร้างอุโมงอันนึงที่คิดภาพว่ามันคือการ Link ก็ได้ ระหว่าง Filesystem เครื่องเราเอง กับ VM ที่ใช้รัน Container ขึ้นมา ซึ่งถ้าเรามีหลาย Container และหลาย Directory ที่แชร์เข้าไป นั่นแปลว่า ใน VM ที่ใช้รัน Container จะมีอุโมงต่อหลายอันมาก ๆ นั่นคือ มันมีความเสี่ยงที่ทำให้ Container ที่ไม่ได้รับอนุญาติสามารถเข้าถึง Link ส่วนที่เราไม่ต้องการได้

แต่ด้วยลักษณะการ Implement ที่ Apple ทำ ที่เลือกใช้ 1 Container 1 VM นั่นทำให้ เวลาเรา Link Directory หรือ File เข้าไป เราจะ Link มันตรงไปที่ VM ที่มี Container ที่เราต้องการโดยตรงเลย

Performant Perspective

เรื่อง Performance ก็เป็นอีกเรื่องที่ทำให้เราค่อนข้างถูกใจ Container Framework มาก ๆ อย่างแรกคือ Framework นี้ถูกเขียนด้วยภาษา Swift ทำให้ตัวของมันถูกเขียนมาได้ค่อนข้าง Optimise เข้ากับ Apple Silicon ได้เป็นอย่างดีมาก ๆ

อย่างแรกที่มันเริ่ดมาก ๆ คือ พอแต่ละ Container รันอยู่ภายใน VM ของตัวเอง นั่นทำให้ มันจะมี IP Address เป็นของตัวเอง แปลว่าเราไม่จำเป็นต้องมานั่ง Map Port อีกต่อไปแล้ว การออกแบบนี้ จะทำให้การตั้งค่า และการจัดการต่าง ๆ ทำได้ง่ายกว่าเดิมมาก ๆ ที่สำคัญคือ จากที่เราต้องวิ่งถึง L7 บน OSI Layer เราสามารถทำงานบน L3 แทนได้เลย ทำให้การเชื่อมต่อมีประสิทธิภาพสูงกว่า โดยเฉพาะใน Application ที่ต้องอาศัยการเชื่อมต่อด้วย Bandwidth สูง ๆ

นอกจากนั้น Filesystem บน Container มันเป็น Filesystem จริง ๆ เพราะจากเดิมที่เราจะใช้การ Link มันเข้ากับ Filesystem เดิมที่อยู่ใน VM แต่ Apple ไม่ทำแบบนั้น เขาเลือกใช้วิธีการ Expose Block Device ออกมา เพื่อให้เราได้ Performance ในการทำงานที่ดีกว่าเดิม เร็วมากกว่าเดิม และมัน Format เป็น EXT4 Filesystem เพื่อให้ Linux สามารถเข้าถึงได้

The Missing Pieces

Feature สำหรับการทำงานกับ Container หลัก ๆ ณ วันนี้ Apple ใส่เข้ามาหมดแล้วละ แต่ยังมีหลาย ๆ จุดที่ยังไม่ได้เติมเข้ามา ณ วันที่เขียน เช่น Compose ที่มีในทั้ง Docker และ Podman ในชื่อ Docker Compose และ Podman Compose ตามลำดับ

ที่เป็น Feature สำหรับให้เรา Define เข้าไปว่า ใน Project เราต้องการเรียก Container อะไรบ้าง เช่นจะต้องมี Database อย่าง MySQL ระบบ Backend อย่าง Go Runtime, Frontend อย่าง React ที่เรียก Node เป็นต้น โดยเราสามาถรเรียกได้ในคำสั่งเดียวง่าย ๆ ตอนนี้ถ้าจะใช้งาน เราจำเป็นต้องเรียกทีละ Container ด้วยมืออยู่ ก็หวังว่าอนาคตจะใส่ Feature นี้เข้ามา

สรุป มันจะเข้ามาแทน Docker หรือ Podman ได้มั้ย ?

ถามว่า Containerisation Framework มันจะเข้ามาแทน Docker หรือ Podman ได้มั้ย ส่วนตัวเรายังมองว่า ไม่ขนาดนั้นนะ เพราะอย่างน้อย ณ วันนี้ตัว Hypervisor ยังใช้ Virtualization Framework ของตัวเองที่รันบน macOS อยู่เลย ดังนั้นการจะ Port ไปใช้งานบน OS อื่นที่ต้องหา Hypervisor มาแทน มันไม่น่าจะเป็นทางที่ Apple อยากทำสักเท่าไหร่ และอีกอย่าง Containerization นี้ มันก็ทำงานอยู่บนมาตรฐาน OCI ที่ทุกคนใช้อยู่แล้ว ดังนั้น เราเลยมองว่า Containerization Framework น่าจะเป็นเพียงอีกหนึ่งทางเลือกเพิ่มขึ้นมาสำหรับการรัน Container บน macOS เท่านั้นเอง แต่ต้องยอมรับจริง ๆ ว่า Concept ที่ Apple เลือกใช้ในการ Implement เป็นอะไรที่น่าสนใจมาก ๆ โดยเฉพาะการตอบโจทย์ในแง่ความปลอดภัยด้วยการ Isolate VM ออกมาสำหรับแต่ละ Container แต่สามารถสร้าง Container ใหม่ออกมาได้ภายในไม่ถึงวินาที แต่เราก็ต้องรอดูกันต่อไป เพราะ ณ วันที่เขียน หลาย ๆ Feature ยังไม่สามารถใช้งานได้ หรือยังไม่สามารถใช้งานได้สมบูรณ์