เหตุผลที่เราทำเทมเพลต YAML (2019)

 (leebriggs.co.uk)
2 คะแนน โดย GN⁺ 2024-01-24 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

คำถามเกี่ยวกับการใช้เทมเพลต YAML

  • ตั้งคำถามว่าการใช้เทมเพลต YAML เริ่มถูกยอมรับว่าเป็นเรื่องปกติตั้งแต่เมื่อไร และมันถูกยอมรับได้อย่างไร
  • นำเสนอเกี่ยวกับความจำเป็นของการจัดการคอนฟิก Kubernetes และโซลูชัน kr8 ที่ cfgmgmtcamp 2019
  • ระหว่างการบรรยายได้ตั้งข้อสงสัยเกี่ยวกับเทมเพลต YAML จนเกิดการถกเถียงอย่างคึกคักทั้งออนไลน์และในงานประชุม

ปัญหาด้านคอนฟิก

  • เมื่อแอปพลิเคชันและโครงสร้างพื้นฐานเติบโตเกินระดับหนึ่ง ก็จะต้องเผชิญกับปัญหาความซับซ้อนของคอนฟิก
  • คอนฟิกของแอปพลิเคชันที่นำไปใช้งานในสภาพแวดล้อมต่าง ๆ (development, staging, production) หรือภูมิภาคต่าง ๆ (ยุโรป, อเมริกาเหนือ) อาจแตกต่างกัน
  • ผู้ดูแลระบบหรือวิศวกร DevOps เข้าใจดีถึงความซับซ้อนของการจัดการคอนฟิก และแต่ละเครื่องมือต่างก็ใช้ YAML เพื่อแก้ปัญหานี้

เรากำลังถอยหลังหรือไม่?

  • เมื่อความต้องการของอุตสาหกรรมเปลี่ยนไปพร้อมกับ cloud computing เครื่องมือใหม่ ๆ ก็เกิดขึ้น
  • เครื่องมืออย่าง CloudFormation และ Helm เป็นเครื่องมือด้านคอนฟิกที่ยอดเยี่ยม แต่ผู้เขียนเชื่อว่าอุตสาหกรรมโดยรวมได้ทำพลาดไปตอนออกแบบเทมเพลต YAML
  • อธิบายโดยยกตัวอย่าง Helm chart ที่รับพารามิเตอร์แบบกำหนดเองจากผู้ใช้

Helm chart

  • Helm chart รับพารามิเตอร์ภายนอกผ่านไฟล์ values.yaml แล้วเรนเดอร์ chart
  • อธิบายความซับซ้อนที่เริ่มจากพารามิเตอร์สตริงแบบง่าย ไปจนถึงการจัดการฟิลด์ทางเลือก อาร์เรย์ และแมป
  • ชี้ให้เห็นถึงข้อกำหนดเรื่องช่องว่างที่เข้มงวดของ YAML และข้อจำกัดของระบบเทมเพลต

JSON, Jsonnet & YAML

  • YAML เป็น superset ของ JSON และการแปลงระหว่างสองรูปแบบนี้ทำได้ง่าย
  • Jsonnet เป็นภาษาสำหรับทำเทมเพลตข้อมูลที่มีจุดประสงค์เพื่อสร้างคอนฟิก JSON

แนวคิดแบบสาวกของ Jsonnet

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

Kr8

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

ความเห็นของ GN⁺

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

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-01-24
ความคิดเห็นใน Hacker News

  • มีคนบ่นเรื่องไฟล์คอนฟิก YAML กันมาก และแม้แต่ใน GitHub Actions ก็ถูกมองว่าเป็นส่วนที่แย่ที่สุด อีกทั้งยังให้ความรู้สึกคล้ายกันกับภาษาเขียนคอนฟิกแบบปิดอื่น ๆ (HCL, ASL เป็นต้น) แม้ declarative API จะดี แต่ก็มีความต้องการให้สามารถสร้าง declaration แบบเป็นโปรแกรมได้

  • การประกาศและสร้างคอนฟิกด้วยโค้ดให้ประสบการณ์ที่ดีกว่า AWS CDK เข้าใจจุดนี้อย่างแม่นยำ และทำให้สามารถเขียนนิยามเชิงประกาศของคอนฟิกและโครงสร้างพื้นฐานคลาวด์ได้ด้วยภาษาที่ type-safe พร้อมการรองรับจาก IDE

  • เห็นด้วยว่าการทำ YAML templating เป็นเรื่องไม่สมเหตุสมผล และเมื่อจำเป็นต้องมีลอจิกที่ซับซ้อน ก็ควรใช้ภาษาโปรแกรมจริงเพื่อสร้าง YAML/JSON เป็นต้น ซึ่งช่วยแก้ปัญหาได้หลายอย่าง

  • มีการพูดถึง Kubernetes ว่าแม้ Kubernetes API จะค่อนข้างเข้าใจง่ายและมี JSON schema ที่นิยามไว้อย่างดี แต่ผู้คนกลับต้องเสียเวลาอย่างมากไปกับการเรียนรู้วิธีใช้ Helm chart ขณะที่ Jsonnet, Ksonnet, Nu, CUE ไม่ได้รับความนิยมมากนัก และดูเหมือนว่าคนส่วนใหญ่จะใช้ Kustomize ที่มีมาใน kubectl

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

  • ใน CI/CD มีกรณีที่ YAML ถูกใช้แทบจะเหมือนภาษาโปรแกรม ซึ่งทั้งยืดยาวมาก ไม่เป็นธรรมชาติ และถูกมองว่าเป็นภาษาเฉพาะของเวนเดอร์ที่นิยามไว้ไม่ชัดเจน

  • มีคนเสียดายที่ Helm เป็นฝ่ายชนะ การทำงานกับ Helm chart นั้นลำบากมาก ตัวแก้ไขก็ช่วยอะไรไม่ได้ และต้องจัดข้อมูลทุกอย่างให้เยื้องถูกต้องด้วย 'indent 4' มีการคาดการณ์ว่า Helm จะนำไปสู่จุดจบของ Kubernetes

  • มีปรัชญาส่วนตัวว่าไม่ควรใช้ string interpolation เพื่อสร้างโค้ดที่เครื่องต้องอ่าน เพราะปัญหาอย่าง SQL injection และ cross-site scripting จะยังคงเกิดขึ้นต่อไป และยังยืนยันว่าไม่ควรใช้ไฟล์เทมเพลตเพื่อสร้าง HTML

  • มีความเห็นว่าคนที่เลือก YAML ดูเหมือนจะไม่ตระหนักถึงปัญหา มีความขัดแย้งโดยตรงระหว่างรูปแบบการแสดงข้อมูลที่ยึดมนุษย์เป็นศูนย์กลางกับรูปแบบที่ยึดคอมพิวเตอร์เป็นศูนย์กลาง และ YAML กับ JSON ก็เป็นรูปแบบข้อมูลคนละแบบกันจริง ๆ

  • มีคนบอกว่าชอบ YAML แต่ก็สบถกับมันทุกวันเวลาทำงานกับ Helm chart แม้จะไม่ชอบ Helm แต่เพราะทุกคนใช้ จึงยังต้องใช้ต่อไป

  • กำลังพิจารณาย้ายไปใช้ cuelang และคิดว่ามันออกแบบมาได้ดีกว่า Jsonnet Kubernetes มีความสามารถในการปรับสถานะอยู่แล้ว ดังนั้นถ้าเพิ่มความสามารถในการลบเข้าไปก็เพียงพอ