น้อง Mac Mini ออฟฟิศใครมีปัญหาบ้าง

แก้ปัญหาน้อง Mac Mini ความหวังหมู่บ้าน

จาก CI แบบลูกทุ่ง สู่ลูกกรุงได้ยังไง แต่ก็ยังไม่ลูกกรุงอยู่ดี

จาก session “Mobile CI: From Garage Hacks to Enterprise Tracks” โดยคุณ Kajornsak Peerapathananont (Staff Software Engineer, Fastwork) และคุณ Verachad Wongsawangtham (Lead Software Engineer, Fastwork) จากงาน Mobile Native Thailand Meetup # 3

.

🔵 ทำไมเราต้องมี CI?

CI (Continuous Integration) คือ ทำให้ workflow integrate ได้อย่างเนียน ๆ

- safeguard repo ของเราให้ปลอดภัย ก่อนจะ merge เข้ามา ซึ่ง "ถ้า merge code โดยไม่ มี test เท่ากับบาป"

- ทำอะไรบางอย่างเป็น sehedule หรือมองว่าอะไรที่รันอยู่ในเครื่องนี้ก็เป็น CI หมดเลย เย้

- build app และ distribute ขึ้น Firebase หรือ submit ส่ง store ซึ่งมันเป็น CD (Continuous Delivery/Deployment) แฮร่

หน้าที่ของ CI หลัก ๆ คือ

- Build: code ที่อยู่ใน repo ต้อง build ได้ ก่อนที่จะ merge เข้าไป

- Test: confirm ว่า test case ที่มีอยู่จะไม่พัง ถ้าพังเราจะไม่ให้ merge เข้าไป

- Deploy: build app แล้วเอาแอพขึ้นไปที่ไหนก็ได้

แบบลูกทุ่ง แน่นอนว่าเครื่องที่รันน้านนน Mac Mini ถูกใช้โดยทุกคน ไม่ว่าจะเป็นเรื่องใดก็ตาม และ setup โดยลงโปรแกรมที่จำเป็นเข้าไป เช่น Xcode, Android Studio, fastlane, GitHub, GitLab, Python, Ruby

และเครื่องนี้เป็นความหวังหมู่บ้าน ที่ตั้งอยู่กลางออฟฟิศ ทำทุกอย่างให้เรา ถ้าพังขึ้นมา 🤔

การทำงาน คือพอมีคนเปิด MR/PR จะมี trigger มาที่ Runner ทำงานตามที่เราสั่งในการ Build และ Test พอทำงานเสร็จก็จะส่งผลลัพธ์กลับไป ซึ่งบางที่ mobile developer ดูแล บางที่ DevOps ดูแล

แต่ถ้าวันนึงมี 20+ MR/PR งานก็จะไปโหลดที่น้อง Mac Mini ความหวังหมู่บ้าน ไฟอาจจะลุกได้ ดังนั้นเราจะต้อง scale เนอะ แล้ว scale ยังไงดี?

วิธีแรก เพิ่มแบบ horizontal ใช้เงินซื้อเครื่องเพิ่มไปเล้ยยยยย แล้ว install แบบเดียวกันลงไป แต่ maintain ยาก หรือซื้อ Mac Studio เป็นการเพิ่มแบบ vertical แต่ก็แพงมากเช่นกัน แล้วอะไรดีกว่า? Mac Mini ทำ paralell ได้ดีกว่า เพิ่มเงินซื้อเครื่องตัวท้อปไปอาจจะไม่ได้ช่วยอะไรน้า จริง ๆ ขึ้นอยู่กับสิ่งที่เราจะทำ และ budget ด้วย

ปัญหา mac mini ความหวังหมู่บ้าน คือ

- cache เยอะ มีทั้งดี ที่ reuse ได้ และที่ไม่ดี คืออะไรที่ควรจะเปลี่ยนแต่ดันไม่เปลี่ยน ทำให้ output ไม่ถูกต้อง

- แชร์ state แล้วไปเก็บใน Mac Mini แต่ลืมเปลี่ยน อาจจะทำให้พังได้

- repo เมื่อนานมาแล้ว pull มาเรื่อย ๆ ขนาดใหญ่ขึ้น cache ก็เยอะขึ้น

- maintain ยาก ต้องไปนั่งหน้าเครื่องเพื่อแก้

- และอีกมากมาย

ถ้ามีปัญหา กด restart เครื่องแล้วเป็นการ clear cache แต่ต้องมากด restart น้องใหม่เรื่อย ๆ

.

🔵 แล้วของ Fastwork ล่ะ?

Plan → Build → Deliver

ปกติทีม product และ mobile จะทำในส่วน plan และ build ส่วน deliver ก็จะเป็นหน้าที่ของ Mac Mini ใช้ Github Action ในการทำ CI/CD

Fastwork จาก freelance platform จะเป็น Everything store service platform เช่น หาคนถ่ายรูปสื่อ เช่ารถ ดังนั้น scale ธุรกิจ เปลี่ยนจาก freelance platform เป็น structure business จากเดิมที่มีทีมเดียวที่เป็น platform team เปลี่ยนเป็นแบ่งตาม business squad ภายใน marketplace

แต่ CI/CD เดิมไม่ตอบโจทย์ ทุกคนเข้ามาส่ง MR/PR อย่างล้มหลาม แล้ว Fastwork ใช้ Flutter ซึ่ง build ทั้ง iOS และ Android แล้วมีแอพที่เวียดนาม Fastlance ด้วย เลยเกิดปัญหาคอขวดขึ้นมา

เรามองหาปัญหา ว่ามี Runner 1 ตัวช้าไป ไม่ work ตัว Github Action scale ได้ แต่เรามี Mac Mini แค่ตัวเดียว และถ้าความหวังอยู่บ้านยัง share stage กัน เก็บ cache เก็บ artifact ใด ๆ แล้วคิด goal ว่าเราอยากไปทางไหน เราอยากมี Runner เพิ่มมากขึ้น และต้อง setup ได้ง่ายด้วย เพราะใช้เวลา 30 นาที ต่อการ setup 1 ครั้ง

🎯 Goals

- Reusable setup template for Mac: สร้าง setup template ถ้ามีเครื่องมาใหม่ สามารถใช้ตัวนี้ได้เลย ไม่ต้อง setup เพิ่ม

- Parallelization: รันแบบ parallel หรือทำพร้อมกันได้

- Ephemeral Runner: รันแบบ clean state คือ Runner ที่เป็น zero state มีแค่สิ่งที่เรา setup ไว้

- Cose Efficiency: มี cost ประมาณนึง แต่อยากจะ optimize ให้ดีที่สุด

🧰 Tools

Tart: เป็น Virtualization tool บน Apple Silicon พัฒนาโดย Cirrus มัน work on-top Virtualization framework ที่ช่วยเราสร้าง image container ตัวนึง เอาไปใส่ใน docker hub พวกนี้ได้ คือ สร้าง Image ตัวนึงที่แชร์ให้กับ Runner ทุกตัวได้ ดังนั้นมัน solve เรื่องสร้าง setup template ได้

Tartelet เป็น Orchestration Tool ที่เหมือนเป็นแอพนึงมาลงใน Mac Mini เอามา self host Github Action Runner และมัน work on-tip Tart อีกทีนึง ข้อดี ไม่ต้อง setup ด้วยมือ ใส่ config แล้วมันช่วยทำให้เอง

การทำงาน เมื่อมี Job เข้ามา Tarlet จะ Spawn VM ขึ้นมาทำงาน (สูงสุด 2 VM ต่อ 1 Mac Mini) เมื่อ Job เสร็จ VM จะ ลบตัวเองทิ้ง ทำให้ได้ Clean State ทำให้ solve ปัญหาที่เหลือได้

สรุปคือเราจะได้ Mac Mini เครื่องนึง ที่รัน Runner ได้ 2 ตัวแบบ parallel ได้ แต่ cost อาจจะไม่จบถ้ามีการเพิ่มเครื่องเพื่อให้เพียงพอในการใช้งาน และทีมมองว่ายัง optimize ได้ไม่สุด แต่ก็ตอบโจทย์กับทีมปัจจุบันอยู่

แต่หลาย ๆ บริษัทจะใช้วิธีเปิด VM บน Mac Mini นะ

.

🔵 Orchestration: to-do list

- Host OS update: host version ต้องสูงกว่า VM

- Network: setup จัดการ network ให้พอดีกับเครื่อง

- Self-recovery: ถ้า mac หายไป เอางานไปให้ตัวอื่นได้ไหม ให้มัน balance กัน

- Workloads management: ทำ device farm ได้ด้วย

- VM management: ทำครั้งหนึ่งเหนื่อย

- Performance tuning: บาง module ใช้ resource มากกว่านั้น

แล้วจะ maintain ยังไงต่อ?

- Machine Provisioning: ยังคงลูกทุ่งอยู่ ใช้ i2cssh เป็น plug-in iterm access ได้หลายเครื่อง หรือใช้ Mobile Device Management (MDM) เวลาซื้อจากทาง Apple เข้ามี Apple Business Manager (ABM) เข้าระบบ MDM ที่เรามีอยู่ได้เลย register ตัวเอง รัน script ได้ทันที แบบไม่ต้องเปิดหน้าจอคอม

- Runner Provisioning: ตัว VM ใช้ Tart สร้าง

.

🔵 XX-Engineer = DevOps

DevOps รู้จักแต่ Kubernetes (K8s) ข้อดีคือ

- Self healing: ถ้า VM หายไป ก็จะสร้างอันใหม่ให้ครบจำนวนให้เรา

- Scalability

- Resource utilization

แต่ K8s เขา require Linux kernel และ Mac ไม่ใช้ Linux แต่มี tool ที่ชื่อว่า kubelet เหมือนเป็น tool สื่อสารเข้า K8s ได้

มุมมอง K8s มอง Mac Mini เป็น node และมี pod เพิ่มได้แค่ 2 (นับตัวเอง 1) ถ้ามีอันไหนพังก็จะสร้าง pod ใหม่ที่ node อื่นที่ว่างอยู่

ถ้ามุม mobile คือ deploy Image เข้าไป รับ event จากตัว git แล้วไป spon pod มาให้ เพื่อเอา VM ไปรันในนั้น

ข้อควรระวัง E2E Test เราสามารถทำให้มัน parallel ได้ด้วย Test Runner เช่น Marathon เอา device ทั้งหมด connect เข้าเครื่อง แล้วมันจะรัน test ให้เอง ไม่งั้นมันจะกระจุกอยู่ที่เดียวและใช้เวลารันเทสนาน

ส่วน Android เขารักกับ Linux เอาไปทำ concept K8s ได้ด้วย Tart นะ

#รอบรู้ไอที #เรื่องราววันนี้ #สตอรี่ของฉัน #รวมเรื่องไอที #developer