Tilt - จัดการสภาพแวดล้อมการพัฒนาด้วยโค้ด

• เครื่องมืออัตโนมัติสำหรับสภาพแวดล้อมการพัฒนาแบบโอเพนซอร์สฟรีสำหรับ การพัฒนาไมโครเซอร์วิส บน Kubernetes
• ทำงานอัตโนมัติตามลำดับ แก้ไขโค้ด → เฝ้าดูไฟล์ → สร้างอิมเมจ → อัปเดตการดีพลอย ทำให้สามารถเปิดทั้งสภาพแวดล้อมได้ด้วยคำสั่ง tilt up
• แม้จะมี Kubernetes เป็นศูนย์กลาง แต่ก็รองรับเวิร์กโฟลว์ที่ใช้ docker-compose หรือ คำสั่งบนเครื่องโลคัล ด้วย
• ถูก Docker เข้าซื้อกิจการในปี 2022 แต่ยังคงพัฒนาและดูแลต่อในฐานะโครงการโอเพนซอร์สอิสระ
• มีเป้าหมายเพื่อ การจัดการสภาพแวดล้อมการพัฒนาสมัยใหม่แบบบูรณาการ เพื่อรับมือกับความซับซ้อนของไมโครเซอร์วิส

---

Tilt คืออะไร

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

ทีมแบบไหนที่ควรใช้ Tilt

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

ทำไมจึงมี Kubernetes เป็นศูนย์กลาง

• Kubernetes มอบ บล็อกมาตรฐานสำหรับการรันเซิร์ฟเวอร์ เช่น คอนเทนเนอร์ พ็อด และเซอร์วิส
• หากใช้มาตรฐานนี้ในสภาพแวดล้อมการพัฒนาด้วย ก็จะช่วยลดความต่างระหว่างสภาพแวดล้อมจริงกับสภาพแวดล้อมพัฒนาได้
• นอกจาก Kubernetes แล้ว Tilt ยังรองรับ docker-compose และคำสั่งบนเครื่องโลคัล แต่คาดว่าในท้ายที่สุดจะมุ่งไปรวมศูนย์ที่ Kubernetes

การพัฒนาและอนาคตของ Tilt

• เดิมที Tilt เป็นสตาร์ตอัปอิสระ ก่อนจะถูก Docker เข้าซื้อกิจการในปี 2022
• ปัจจุบันยังคงเป็นโอเพนซอร์ส และกำลังปรับปรุงให้ทำงานร่วมกับ Docker Compose และ Docker Desktop ได้ดียิ่งขึ้น
• ยังมีการพัฒนาโครงการใหม่ ๆ อยู่ด้วย และพยายามขยายแนวคิดของ Tilt ไปสู่ระบบนิเวศนักพัฒนาที่กว้างขึ้น

ความหมายของชื่อ

• "Tilt" ได้แรงบันดาลใจจาก เรื่องราวที่ดอนกิโฆเต้พุ่งเข้าชนกังหันลม
• ชื่อเดโมแอปคือ Servantes ซึ่งอ้างอิงถึงเซร์บันเตส ผู้ประพันธ์ดอนกิโฆเต้

[GN⁺]

ความคิดเห็นบน Hacker News

• น่าสนใจที่ได้เห็นหัวข้อนี้ที่นี่ ฉันใช้ Tilt มาหลายปีแล้ว แต่ดูเหมือนว่าหลังจากถูก Docker เข้าซื้อไป ความเร็วในการพัฒนาจะช้าลง

  • Tilt ช่วยสร้างสภาพแวดล้อมสำหรับการพัฒนาในเครื่อง ทำให้บริการทำงานได้เหมือนกันทั้งในโปรดักชัน การทดสอบ และการพัฒนา
  • โค้ดของบริการเรียบง่ายขึ้นมากและคุณภาพก็ดีขึ้น
  • โดยเฉพาะส่วนที่จัดการกับ CRD ยังควรปรับปรุง (ไม่มีวิธีระบุว่า k8s_yaml พึ่งพา CRD ทำให้การเรียก tilt up พังบ่อย)
  • เวลาเริ่มโปรเจ็กต์ใหม่ สิ่งแรกที่ทำคือทำให้ tilt up ใช้งานได้
  • สิ่งที่เคยใช้ทดสอบมีทั้งตัวเก็บข้อมูลบนพื้นฐาน eBPF สำหรับความปลอดภัยและ observability, data pipeline, การพัฒนา Helm chart, Kubernetes controller เป็นต้น
  • มีความยืดหยุ่นสูงและทรงพลังกับงานพัฒนาหลากหลายแบบ

• คำโฆษณานี้สำหรับฉันค่อนข้างขำ

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

• ต้องมีการประนีประนอมระหว่างความเร็วกับความแม่นยำอยู่เสมอ

  • ถ้าพยายามรักษาสภาพแวดล้อม integration แบบโลคัลไว้ มันจะช้ามากและมีต้นทุนสูง
  • ปัญหาไม่ใช่ Kubernetes เอง แต่คือเมื่อ dependency เพิ่มขึ้น การพยายามรันสำเนาของทั้งโลกไว้ในเครื่องโลคัลจะยิ่งช้าลงเรื่อยๆ
  • ฉันชอบสภาพแวดล้อมพัฒนาแบบเร็วและกระชับโดยใช้สิ่งอย่าง docker-compose ซึ่งสามารถ mock dependency บางส่วนเพื่อรักษาความเร็วได้ เมื่อการทดสอบบนโลคัลผ่านแล้ว สภาพแวดล้อมอื่นค่อยใช้ Kubernetes

• ฉันคิดว่า "สภาพแวดล้อมสำหรับการพัฒนา" ควรเป็นการรันทดสอบโดยตรงด้วยเครื่องมือเนทีฟของภาษา เช่น cargo test, bundle exec rspec เป็นต้น

  • ถ้าต้องรัน VM ที่รัน Kubernetes แล้วให้ VM นั้นไปรัน Docker container เพื่อรันทดสอบอีกที ฉันคงหงุดหงิดมาก
  • การทำเรื่องนี้ให้ถูกต้องและเชื่อถือได้ยังต้องใช้ความพยายามอีกมาก ถ้าเป้าหมายคือไม่ใช้ Docker ก็อาจต้องทำงานเพิ่มขึ้นอีก (ซึ่งจำเป็นถ้าจะรันแบบเนทีฟบน macOS)
  • ดูเหมือนจะมีเครื่องมือจำนวนมากในสายนี้ ฉันอยากให้พวกมันไม่เรียกตัวเองว่าเครื่องมือสำหรับ "สภาพแวดล้อมสำหรับการพัฒนา" เพราะมันใกล้เคียงกับเครื่องมือสำหรับ "ดีพลอยแอปลงบนเครื่องโลคัล" มากกว่า

• อดพูดถึง nix-shell ไม่ได้: ลิงก์ nix-shell

• ถ้าอยากเห็น Tilt ใช้งานจริง เราใช้มันในคลังโอเพนซอร์สของ Chroma เพื่อรันฐานข้อมูลเวอร์ชันกระจายสำหรับการพัฒนาและ CI เจ๋งมาก — แค่โคลนแล้วรัน tilt up ก็ใช้งานได้เลย

  • ลิงก์ Chroma

• การตั้งค่าสภาพแวดล้อมโลคัลไม่เคยเป็นปัญหา

  • การดีพลอยแบบคลัสเตอร์เดียวง่ายมาก
  • ปัญหาคือบริการที่เราดูแลในโปรดักชันถูกดีพลอยข้ามหลายรีเจียน (หรือหลาย k8s cluster)
  • ปัญหาจริงคือการดีบักแอปพลิเคชันแบบกระจาย

• Tilt เทียบกับ skaffold dev เป็นอย่างไร? เราใช้ skaffold สำหรับจุดประสงค์นั้น ใช้มันเพื่อพัฒนาในคลัสเตอร์

• เมื่อไม่นานมานี้ฉันลองใช้ Tilt อยู่พักหนึ่ง เคยลอง Tilt, Garden และอาจมีตัวอื่นอีกสองสามตัว แล้วสุดท้ายก็มาลงตัวกับ DevSpace

  • ถ้าจำไม่ผิด มันเข้ากับโครงสร้างพื้นฐานโปรดักชันที่มีอยู่ได้ดีที่สุด ไม่จำเป็นต้องเขียนทุกอย่างใหม่ในอีกแบบหนึ่ง
  • กล่าวคือ มันเข้ากันได้ดีกับการตั้งค่า kustomize+k8s ที่มีอยู่ เพิ่ม port forwarding และการซิงก์ไฟล์อย่างรวดเร็วไปยัง container ที่กำลังรันอยู่ นั่นคือทั้งหมดที่ฉันต้องการจริงๆ ฉันไม่ชอบการต้อง build image ใหม่ทุกครั้งที่มีการเปลี่ยนแปลง

• นี่โดยแก่นแล้วไม่ใช่ dev container หรอกหรือ?