ค่อยๆ จัด CI/CD ใน Homelab ให้เข้ากับงานที่ทำ

อย่างที่น่าจะรู้ว่าแอดเองก็ทำงานอยู่ในสายพัฒนาระบบ และงานส่วนใหญ่ก็วนเวียนอยู่กับเว็บไซต์ แอปมือถือ รวมถึง API ที่แต่ละระบบต้องใช้ แล้วช่วงหลังที่มี AI เข้ามาเกี่ยวข้องมากขึ้น แอดก็ได้มีส่วนร่วมกับงานพัฒนา workflow เพิ่มขึ้นด้วย ทั้ง script และ pipeline ต่างๆ เพื่อรองรับความต้องการของลูกค้าที่เริ่มปรับการทำงานตามแนวทาง AI transformation กันมากขึ้น

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

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

ที่ผ่านมาแอดเลยได้ลองเครื่องมือ CI/CD อยู่หลายแบบ อย่างบางงานที่เป็นเว็บก็ใช้ Vercel แล้วสะดวกดี เพราะเมื่อเชื่อมกับ repo และตั้งค่าที่จำเป็นไว้แล้ว ก็ให้มันจัดการบิ้วและ deploy ต่อได้ เวลาส่งงานแก้จึงไม่ต้องกลับมาทำขั้นตอนเดิมด้วยตัวเองทุกครั้ง และยังตามดูผลของงานที่ส่งขึ้นไปได้จากที่เดียว

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

เมื่อระบบเดียวมีทั้งหน้าบ้าน หลังบ้าน และ API

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

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

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

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

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

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

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

ช่วงแรกเลยเริ่มจาก GitLab

GitLab เป็นตัวที่แอดเลือกใช้ในช่วงแรก เพราะมีเครื่องมือที่ต้องใช้อยู่ด้วยกันหลายอย่าง ตั้งแต่ version control, Merge Request, CI/CD ไปจนถึง environment พอเก็บโค้ดอยู่ที่นั่นแล้ว ก็สามารถเริ่มจัดขั้นตอนบิ้วและ deploy ต่อในโปรเจกต์เดียวกันได้เลย

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

โลโก้จาก GitLab

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

แต่เรื่องที่ทำให้เริ่มคิดต่อคือ runner ที่ใช้บิ้วครับ เพราะแผนฟรีของ GitLab.com มีโควตาสำหรับ runner ที่ GitLab ให้ใช้ 400 compute minutes ต่อเดือน ซึ่งแอดรู้สึกว่าน้อยไปหน่อย แล้วยังมีเรื่องบิ้วช้าที่ติดใจอยู่ด้วย พอจะเอามาใช้กับงานที่ต้องบิ้วหลายส่วนและหลาย environment ก็เลยเริ่มสนใจว่าจะเอางานส่วนนี้มารันบนเครื่องของตัวเองดีไหม (โควตา compute minutes ของ GitLab)

ทางเลือกแรกที่เคยคิดไว้คือรัน self-hosted runner เอง เพราะยังเก็บวิธีทำงานบน GitLab ไว้ได้ แล้วเปลี่ยนให้เครื่องของเรารับงานมาบิ้วแทน ถ้าจะเริ่มใช้เครื่องใน Homelab กับงานนี้ ก็ดูเป็นจุดที่เริ่มลองได้โดยยังไม่ต้องเปลี่ยนเครื่องมือทั้งหมด

แต่พอคิดว่าจะเตรียมงานบิ้วบนเครื่องของเราเอง ก็ต้องกลับมาดูสิ่งที่งานเหล่านั้นต้องใช้ด้วย โดยเฉพาะ env ของแต่ละโปรเจกต์ ซึ่งยังเป็นอีกส่วนที่อยากจัดให้ลงตัวกว่านี้

มี Vault อยู่แล้ว ก็อยากให้ดูแลค่าจากที่เดียว

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

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

ยิ่งเป็นงาน Next.js ก็มีค่าบางส่วนที่ต้องใช้ตั้งแต่ตอนบิ้ว อย่าง NEXT_PUBLIC_ ที่จะถูกใส่ลงใน JavaScript ฝั่งเบราว์เซอร์ตอน build พอได้ชิ้นงานออกมาแล้ว การไปเปลี่ยน env ตอนรันอย่างเดียวก็ไม่ได้เปลี่ยนค่าที่ใส่ไว้ในชิ้นงานนั้น จึงต้องเตรียมให้ถูกตั้งแต่ขั้นตอนก่อนหน้า (การใช้ environment variables ใน Next.js)

ตรงนี้เองที่ยังติดใจอยู่กับการต้องตั้งค่าบางอย่างไว้ฝั่ง GitLab ทั้งๆ ที่มี Vault ให้จัดการอยู่แล้ว เพราะถ้าจะจัดงานบิ้วใหม่ ก็อยากให้ขั้นตอนดึงค่าจาก Vault เข้ามาอยู่ในวิธีทำงานเดียวกันไปเลย จะได้ดูต่อกันได้ว่างานกำลังเตรียมค่าอะไร แล้วนำไปใช้ในขั้นตอนไหน

จากที่เคยคิดเพียงว่าจะลง runner เอง แอดเลยเริ่มมองหา CI ตัวอื่นด้วย และเลือก Tekton ไว้สำหรับงานฝั่งนี้ โดยตั้งใจให้งานบิ้วรันบน Kubernetes แล้วจัดขั้นตอนดึงโค้ด เตรียมค่า ทดสอบ และบิ้วอิมเมจต่อกัน ส่วนการยืนยันตัวตนและอ่านค่าจาก Vault ก็ต้องต่อเข้าไปในขั้นตอนที่จำเป็นต้องใช้ (Tasks และ Pipelines ของ Tekton)

โลโก้จาก Tekton

ระหว่างจัดส่วนนี้ GitLab ก็ยังใช้เก็บโค้ดและทำ Merge Request ต่อได้ก่อน แล้วค่อยแยกงาน CI ออกมาลองให้จบ แต่พอเริ่มคิดถึงการแยกหน้าที่กันแบบนี้ ก็เลยมีคำถามต่อว่า ถ้าวันหนึ่งอยากย้ายออกจาก GitLab มากกว่านี้ จะยังเหลืออะไรที่ต้องกลับมาใช้ที่เดิมอีกบ้าง

งานบิ้วย้ายได้ แต่อิมเมจก็ต้องมีที่ไป

ส่วนหนึ่งที่ตามมาคือ Container Registry เพราะหลังจากบิ้วอิมเมจเสร็จ ก็ต้องมีที่เก็บให้ระบบปลายทางเข้ามาดึงไปใช้ ถ้ายังส่งอิมเมจกลับไปเก็บใน registry ของ GitLab ฝั่ง deploy ก็ยังต้องกลับมาดึงของจากที่นั่นอยู่ดี

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

Harbor เลยเข้ามาจากเหตุผลนี้ ให้มี registry สำหรับเก็บอิมเมจแยกออกมา งาน CI บิ้วเสร็จก็ส่งมาที่นี่ แล้วให้ระบบที่จะรันแอปดึงจากที่นี่ไปใช้ ซึ่งถ้าภายหลังเปลี่ยนที่เก็บโค้ด ก็ยังใช้ registry เดิมต่อได้ โดยปรับการเชื่อมต่อของงานบิ้วให้ส่งอิมเมจมาที่เดิม (Harbor)

โลโก้จาก Harbor

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

แล้วแต่ละ environment จะรันรุ่นไหน

ตรงนี้แอดเลือก Argo CD มาดูแลฝั่ง deploy โดยเก็บไฟล์ที่กำหนดว่าแต่ละ environment ควรรันอะไรไว้ใน Git แล้วให้ Argo CD อ่านมาเทียบกับสถานะใน Kubernetes ถ้าจะเปลี่ยนรุ่นของแอป ก็แก้ค่าของ environment ที่ต้องการก่อน แล้วจึง sync การเปลี่ยนแปลงเข้าไป (การทำงานของ Argo CD)

อย่างกรณีที่มี API รุ่นใหม่ให้ลองบน dev ก็เปลี่ยนเฉพาะฝั่ง dev ได้ โดยที่ UAT ยังใช้รุ่นที่กำลังตรวจงานต่อไป ส่วน production ก็อยู่กับรุ่นที่ปล่อยใช้งานแล้ว พอพร้อมจะขยับชุดไหนจึงค่อยอัปเดตไฟล์ของชุดนั้น ทำให้มีที่ระบุชัดว่าแต่ละ environment ควรอยู่ในสถานะใด

โลโก้จาก Argo CD

งาน CI จึงต้องส่งต่อข้อมูลให้ถึงส่วนนี้ด้วย หลังจากบิ้วและส่งอิมเมจเข้า Harbor แล้ว ยังต้องอัปเดตไฟล์สำหรับ deploy ให้ชี้ไปยังอิมเมจที่ต้องการ จากนั้น Argo CD จึงจะเห็นว่ามีอะไรเปลี่ยน ส่วนจังหวะไหนจะให้ sync อัตโนมัติ หรือจังหวะไหนต้องรอตรวจสอบก่อน ก็ค่อยกำหนดให้เข้ากับวิธีส่งงานของแต่ละ environment อีกที

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

สรุป

พอมองรวมกัน การจัด CI/CD ใน Homelab ชุดนี้ก็เริ่มจากความต้องการดูแลงานที่มีหลายส่วนและหลาย environment ให้สะดวกขึ้น โดยค่อยๆ แยกเรื่องบิ้ว การเตรียมค่า การเก็บอิมเมจ และการ deploy ออกจากกัน แต่ยังต้องตามต่อได้ว่าโค้ดที่แก้ถูกส่งไปเป็นแอปรุ่นไหน และทำงานร่วมกับส่วนอื่นในชุดนั้นได้หรือเปล่า พอมีข้อมูลเหล่านี้อยู่ครบ เวลาจะส่งงานขึ้น dev, UAT หรือ production ก็วางแผนได้ว่าต้องอัปเดตอะไรไปด้วยกัน ส่วนจำนวน replica และทรัพยากรที่ใช้ก็ปรับให้เหมาะกับงานของแต่ละชุด พร้อมกับเก็บประวัติไว้ให้กลับมาตรวจสอบได้ครับ