Docker Bake 101: เลิกใช้ Bash Script ย้ายมาสตรีมบิวด์ด้วย HCL
เจาะลึก Docker Bake ตอนแรกจากซีรีส์คู่มือปฏิบัติจริง เปลี่ยนสคริปต์ Bash ยาว 200 บรรทัดมาเป็นการบิวด์แบบ Declarative พร้อมตัวโค้ดและคำสั่งใช้งาน
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- Docker Bake เป็นเครื่องมือออร์เคสตรทานการบิวด์แบบ Declarative ช่วยจัดการหลายอิมเมจพร้อมกัน
- แก้ปัญหา Bash script แตกต่างกันข้ามระบบปฏิบัติการ เช่น macOS ที่ยังติด Bash 3.2
- ซีรีส์คู่มือนี้มีที่มาจากทักษะการบรรยายในงานประชุมฝรั่งเศสและโมร็อกโก
- โค้ดตัวอย่างทั้งหมดเชื่อมโยงกับ GitHub repository ของผู้เขียนให้ทดลองรันได้ทันที
ซีรีส์คู่มือ Docker Bake ในทางปฏิบัติ ตอนที่ 1 นี้จะพาไปทำความรู้จักกับพื้นฐานสำคัญว่า Bake คืออะไร ทำไมจึงเกิดขึ้น และฟีเจอร์เด่นที่ทำให้คุ้มค่าต่อการใช้งาน โดยในตอนต่อไปจะพูดถึงการบูรณาการเข้ากับระบบ CI/CD ไม่ว่าจะเป็น Cloud Build, GitHub Actions, GitLab CI และ Dagger สำหรับเนื้อหาในบทความนี้ถอดบทเรียนมาจากการบรรยายของผู้เขียนที่เดินสายพูดคุยในงานประชุมทั่วฝรั่งเศสและโมร็อกโก เช่น DevLille, DevFest Toulouse, DevFest Lyon, Devoxx Morocco และ Cloud Native Days France ซึ่งมักจะได้ยินผู้เข้าร่วมงานอุทานเสมอว่าไม่เคยรู้มาก่อนว่า Bake ทำสิ่งเหล่านี้ได้ หรือกำลังเขียนสคริปต์ Bash ยาวกว่า 200 บรรทัดเพื่อทำหน้าที่เดียวกันพอดี
สำหรับผู้ที่ชื่นชอบรูปแบบวิดีโอ ผู้เขียนได้บันทึกการบรรยายในงาน Cloud Native Days France เป็นภาษาฝรั่งเศสไว้แล้ว และจะมีวิดีโอภาคภาษาอังกฤษตามมาบนช่อง YouTube ในเร็วๆ นี้ ส่วนผู้อ่านที่ต้องการศึกษาตามอัธยาศัยพร้อมกับโค้ดสนิปเป็ตที่สามารถคัดลอกไปวางได้ทันที บทความนี้พร้อมให้คุณใช้งานแล้ว โดยโค้ดตัวอย่างทั้งหมดอ้างอิงมาจาก repository ส่วนตัว ซึ่งแต่ละหัวข้อจะมีลิงก์ตรงไปยังไฟล์ที่เกี่ยวข้องเพื่อให้รันตัวอย่างตามได้จริง
ตัวอย่างคำสั่งพื้นฐานสำหรับการใช้งาน Docker Bake มีดังนี้:
- บิวด์และพับบลิชอิมเมจในเครื่อง:
docker buildx bake -f vars.hcl -f docker-bake-app-and-infra.hcl --push - ตรวจสอบค่าที่ถูกอินเทอร์โพเลตในคอนฟิก:
docker buildx bake -f vars.hcl -f docker-bake-app-and-infra.hcl --print - รันการตรวจสอบลินเทอร์และเทสต์:
docker compose -f compose_lint_and_test.yaml up
การทำความเข้าใจสถาปัตยกรรม 3 ชั้นของเครื่องมือ Docker ช่วยให้เห็นภาพชัดเจนขึ้นว่า BuildKit เปรียบเสมือนเครื่องยนต์เบื้องหลังที่คอยจัดการขนานงานและแคช, Buildx ทำหน้าที่เป็น CLI ปลั๊กอินเชื่อมต่ออินเทอร์เฟซ, และ Bake ทำหน้าที่เป็นตัวจัดการออร์เคสตราภาพรวม การเปลี่ยนผ่านจาก Bash มาเป็น HCL จึงช่วยลดความซับซ้อนและตัดปัญหาความแตกต่างของเวอร์ชันเชลล์ในแต่ละระบบปฏิบัติการได้อย่างเด็ดขาด
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
ก่อนจะเริ่มต้นใช้งานไฟล์ HCL จำเป็นต้องทำความเข้าใจลำดับชั้นของเครื่องมือทั้งสามตัวที่มักถูกเรียกปะปนกัน ได้แก่ BuildKit ซึ่งเป็นเอนจินการบิวด์สมัยใหม่ที่เข้ามาแทนที่ระบบเก่าและเป็นค่าเริ่มต้นใน Docker Engine 23+, Buildx ซึ่งเป็นปลั๊กอิน CLI ที่ช่วยให้ใช้งานฟีเจอร์ของ BuildKit ได้ง่ายขึ้นผ่านคำสั่งอย่าง docker buildx build และตัวสุดท้ายคือ Bake ซึ่งเป็นคำสั่งย่อยของ Buildx ทำหน้าที่จัดการบิวด์หลายตัวพร้อมกันในรูปแบบ Declarative คล้ายกับ Docker Compose แต่เน้นไปที่งานบิวด์แทนที่จะเป็นการรันคอนเทนเนอร์
ในแง่ของการติดตั้ง หากผู้ใช้งานติดตั้ง Docker Desktop ในช่วงไม่กี่ปีที่ผ่านมาหรือใช้ Linux ที่รัน Docker Engine 23+ ตัว Buildx และ BuildKit จะถูกติดตั้งมาให้อย่างเสร็จสรรพพร้อมใช้งาน รวมถึงคำสั่ง Bake ที่พ่วงมาด้วยทันทีโดยไม่ต้องติดตั้งอะไรเพิ่มเติม ยกเว้นกรณีที่ใช้งานเวอร์ชันที่เก่ามากๆ เท่านั้น
เพื่อทำความเข้าใจว่าทำไม Bakeอาคารถือกำเนิดขึ้น ลองพิจารณาปัญหาความยุ่งยากเมื่อต้องบิวด์และพับบลิชอิมเมจสองตัว ได้แก่ แอปพลิเคชันและอินฟาเรด ที่รองรับหลายสถาปัตยกรรม (amd64 และ arm64) พร้อมกับระบบการรับรอง SBOM เมื่อเขียนด้วย Bash ธรรมดา มักจะต้องพึ่งพาลูปคำสั่งและอาร์เรย์เชื่อมโยง ซึ่งจำเป็นต้องใช้ Bash เวอร์ชัน 4 ขึ้นไป ทว่าระบบปฏิบัติการอย่าง macOS ยังคงกำหนดค่าเริ่มต้นเป็น Bash 3.2 ส่งผลให้สคริปต์เกิดความล้มเหลวแบบเงียบๆ บนเครื่อง Mac รุ่นใหม่ เว้นแต่ผู้พัฒนาจะทำการติดตั้ง Bash เวอร์ชันใหม่ผ่าน Homebrew ด้วยตนเอง กลายเป็นปัญหาคลาสสิกที่ว่าใช้งานได้บนเครื่องฉันคนเดียว (Works on my machine)
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น