ที่เก็บข้อมูล OpenTF เปิดให้สาธารณะแล้ว

 (github.com/opentffoundation)
1 คะแนน โดย GN⁺ 2023-09-06 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • OpenTofu เป็นเครื่องมือ OSS สำหรับสร้าง เปลี่ยนแปลง และจัดการเวอร์ชันของโครงสร้างพื้นฐานได้อย่างปลอดภัยและมีประสิทธิภาพ
  • สามารถจัดการได้ทั้งผู้ให้บริการยอดนิยมที่มีอยู่เดิมและโซลูชันแบบปรับแต่งภายในองค์กร
  • ใช้แนวทาง Infrastructure as Code ในการอธิบายโครงสร้างพื้นฐานด้วยไวยากรณ์การตั้งค่าระดับสูง ทำให้สามารถจัดการเวอร์ชัน แชร์ และนำพิมพ์เขียวของดาต้าเซ็นเตอร์กลับมาใช้ซ้ำได้เหมือนโค้ด
  • มีขั้นตอน planning ที่สร้างแผนการทำงานก่อนเรียก apply เพื่อให้ตรวจสอบล่วงหน้าได้ว่า OpenTofu จะดำเนินการอะไรกับโครงสร้างพื้นฐาน
  • สร้าง Resource Graph ของทรัพยากรทั้งหมด และทำให้การสร้างหรือแก้ไขทรัพยากรที่ไม่มีการพึ่งพากันทำงานแบบขนานได้ เพื่อเพิ่มการมองเห็นความสัมพันธ์การพึ่งพาของโครงสร้างพื้นฐาน
  • สามารถนำชุดการเปลี่ยนแปลงที่ซับซ้อนไปใช้ได้โดยมีการแทรกแซงจากมนุษย์น้อยที่สุด และตรวจสอบได้จากแผนการทำงานและกราฟทรัพยากรว่าจะเปลี่ยนอะไรและตามลำดับใด
  • มี Nightly Builds สำหรับทดสอบการเปลี่ยนแปลงล่าสุดของ main โดยเป็นบิลด์เชิงทดลองและไม่ได้มีไว้สำหรับใช้งานในโปรดักชัน
  • ช่องโหว่ด้านความปลอดภัยหรือช่องโหว่ที่อาจเกิดขึ้นให้รายงานตาม Security Policy
  • มีการบล็อกการเข้าถึงรีจิสทรีจากบางประเทศต้นทาง โดยรายละเอียดเป็นไปตาม Registry Inclusion Policy
  • ใบอนุญาตคือ Mozilla Public License v2.0

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

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

 
GN⁺ 2023-09-06
ความคิดเห็นบน Hacker News

  • ตามที่มีคนขอกันเข้ามามาก ในที่สุดเราก็ เปิดเผย repository ต่อสาธารณะ แล้ว และจากนี้ไปจะพัฒนาต่อแบบเปิดเผย
    ใช้เวลาสักหน่อย แต่ดูรายละเอียดได้ในประกาศ: https://opentf.org/fork
    ขอบคุณสำหรับการสนับสนุนที่ผ่านมา และหวังว่าจะมาร่วมอภิปรายหรือมีส่วนร่วมใน repository กัน
    วิธีการมีส่วนร่วมที่คุยกันค่อนข้างมากบน HN ก็ได้ข้อสรุปว่าจะใช้ DCO: https://developercertificate.org
    ถ้ามีคำถามก็ยินดีตอบ ผมทำงานที่ Spacelift และรับหน้าที่ Technical Lead ชั่วคราวของ OpenTF Project จนกว่าจะเปลี่ยนไปเป็นการนำโดยคณะกรรมการ

  • ผมมองว่ากระบวนการทั้งหมดนี้ค่อนข้างเท่ HashiCorp รู้ดีว่าไลเซนส์ไม่ได้ผูกกับ “โปรเจกต์” เอง แต่ผูกกับ เวอร์ชันของโปรเจกต์ และใช้เรื่องนี้เพื่อเพิ่มรายได้จากผลิตภัณฑ์สำหรับองค์กรให้ได้สูงสุด
    ชุมชนก็รู้เช่นกันว่าเมื่อผูกไลเซนส์กับเวอร์ชันใดเวอร์ชันหนึ่งแล้วจะย้อนกลับไม่ได้ และก็รู้ด้วยว่าถ้า fork จากจุดที่ไลเซนส์นั้นถูกใช้ แล้วสร้างโปรเจกต์ “ใหม่” ของตัวเองตามแต่ละเวอร์ชัน ก็ยังคงทำให้เป็นโอเพนซอร์สต่อไปได้
    น่าสนใจว่าจะพัฒนาต่อไปอย่างไร และน่าจะกลายเป็นกรณีศึกษาด้าน ไลเซนส์ซอฟต์แวร์ ในอนาคต รอดูว่า OpenTF จะเป็นอย่างไรในระยะยาว

    • ในแง่ผลกระทบต่อชุมชนและการตอบสนอง ดูใกล้เคียงกับการแยกตัวของ Hudson กับ Jenkins มากที่สุด แม้ประเด็นไลเซนส์จะแตกต่างกัน: https://en.wikipedia.org/wiki/Hudson_(software)
      รู้สึกว่าเรื่องแบบนี้แทบจะมี Oracle เข้ามาเกี่ยวด้วยเสมอ แต่กับ Terraform กลับไม่ใช่ น่าแปลก :D
    • ไม่มีเหตุผลต้องแยกความแตกต่างระหว่าง “ไลเซนส์ที่ผูกกับเวอร์ชันของโปรเจกต์” กับ “ไลเซนส์ที่ผูกกับตัวโปรเจกต์เอง” HashiCorp มีสิทธิ์เปลี่ยนไลเซนส์สำหรับอนาคต และใครก็ตามก็มีสิทธิ์ใช้เวอร์ชันเดิมต่อหรือ fork ได้ นี่แหละคือสิ่งที่เกิดขึ้นจริง
    • ในเชิงประวัติศาสตร์ การดู codebase ของ Hudson/Jenkins ก็อาจน่าสนใจเช่นกัน

  • มีการบอกว่า “กำลังปรึกษาผู้เชี่ยวชาญด้านกฎหมายหลายคนเกี่ยวกับชื่อ และ OpenTF ก็อาจไม่ใช่ชื่อสุดท้าย เพราะการใช้ ‘TF’”
    น่าสนใจที่แค่มี TF อยู่ในชื่อก็อาจเป็นปัญหาได้
    ที่มา: https://github.com/opentffoundation/opentf/issues/273#issuecomment-1706947318

    • เพิ่งรู้ว่าประเด็นที่อาจเป็นปัญหาที่นี่คือ wordmark
      ดูรายละเอียดได้ที่ https://en.wikipedia.org/wiki/Wordmark
      เป็นผู้ก่อตั้ง env0 และร่วมเป็นผู้นำ initiative ของ OpenTF
    • ตั้งแต่แรกผมคิดว่าควรใช้ xenoform แทน terraform เช่น OpenXenoform กับคำสั่ง xf อะไรทำนองนั้น
    • ด้วยเหตุผลคล้ายกัน YP เลยกลายเป็น NIS
      https://en.wikipedia.org/wiki/Network_Information_Service

  • อยากขอสองอย่าง อย่างแรก อยากให้มี แพ็กเกจ registry แบบสแตนด์อโลน สำหรับทั้ง module และ provider เท่าที่รู้มีแค่ Artifactory แต่ในสภาพแวดล้อมที่ใช้ Nexus อยู่ ก็ไม่อยากต้องรันซอฟต์แวร์ repository ขนาดใหญ่อีกตัว
    อย่างที่สองก็เกี่ยวกัน คืออยากให้ fork provider module ได้ง่ายขึ้น วิธีแบบตอนนี้ที่ build ในเครื่องแล้ว copy binary ให้เพื่อนร่วมงานด้วยมือ หรือรอให้ PR ได้รับการยอมรับ โดยเฉพาะเมื่อ upstream บังคับให้เซ็น CLA นั้นไม่ค่อยดี

    • ช่วยอธิบายคำขอข้อแรกเพิ่มเติมได้ไหม ถ้าหมายถึงอยากได้ binary แบบ self-contained ที่รัน registry สำหรับ provider/module ส่วนตัวได้ ก็มีโปรเจกต์โอเพนซอร์สอยู่หลายตัว และเราก็เคยทำ proof of concept สำหรับวิธีกระจาย provider ผ่าน OCI registry อย่าง DockerHub หรือ GitHub Container Registry ด้วย
      OCI registry ค่อนข้างเหมาะกับ use case นี้: https://twitter.com/opentforg/status/1696913055576387599
      proof of concept นี้จะตามมาด้วย RFC สาธารณะในเร็ว ๆ นี้
      ส่วนคำขอข้อที่สอง อยากรู้ว่ามี workflow ในอุดมคติแบบไหนอยู่ในใจหรือไม่
      ผมทำงานที่ Spacelift และรับหน้าที่ Technical Lead ชั่วคราวของ OpenTF Project จนกว่าจะเปลี่ยนไปเป็นการนำโดยคณะกรรมการ

  • ควรใช้ชื่อ “terrafork” ไปเลย

    • OpenCorp ก็น่าจะได้เหมือนกัน เพราะ Terraform ก็เป็นแค่ผลิตภัณฑ์หนึ่งเท่านั้น: https://news.ycombinator.com/item?id=37393844

  • ดูดี กำลังรอ https://github.com/opentffoundation/roadmap/issues/8 เพื่อจะได้ลองทดสอบ
    build จาก source ได้ก็จริง แต่ถ้าเป็นไปได้ก็อยากใช้ release build

  • ลองกวาดตาดูคร่าว ๆ แล้วเอกสารดูยอดเยี่ยม จากมุมคนที่เคยแตะโครงสร้างภายในของ Terraform มาบ้าง นี่ดูเป็นการปรับปรุงที่ใหญ่พอสมควรสำหรับนักพัฒนาที่จะมาทำงานกับ codebase นี้
    มี ภาพรวมทั้งหมด ที่ดีสำหรับการเริ่มต้น ทำได้ดีมาก

    • ไม่แน่ใจว่าหมายถึงเอกสารไหนกันแน่ แต่เอกสารส่วนใหญ่แทบไม่ได้เปลี่ยนจาก repository ต้นฉบับ นอกจากส่วนที่เกี่ยวกับเครื่องหมายการค้า
      ถ้าเอกสารดีขึ้น เครดิตควรเป็นของนักพัฒนา Terraform Core
      ผมทำงานที่ Spacelift และรับหน้าที่ Technical Lead ชั่วคราวของ OpenTF Project จนกว่าจะเปลี่ยนไปเป็นการนำโดยคณะกรรมการ

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

    • แน่นอนว่าเป็นข้อถกเถียงด้านดีไซน์ที่เล็กน้อยมาก แต่ก็ดูเหมือนโลโก้ TensorFlow จนแวบแรกผมนึกว่าเป็นกลุ่มที่แยกโปรเจกต์ออกจาก Google

  • มีใครมี diff ไหมว่า codebase นี้ต่างจาก commit ของ Terraform ที่เป็นไลเซนส์สุดท้ายที่ “ยังใช้ต่อได้” อย่างไร
    ผมยังไม่ค่อยเข้าใจว่าจริง ๆ แล้วต้องเปลี่ยนอะไรบ้างเพราะข้อถกเถียงและการเปลี่ยนแปลงไลเซนส์ใหม่

  • โลโก้บนหน้า GitHub ดูเหมือนควรปรับปรุงเมื่ออยู่บนพื้นหลังมืด โดยเฉพาะ ตัวอักษรสีเข้ม ที่มีเส้นขอบสว่างขึ้นมา ดูเหมือน alpha bleeding และยังมีรอยหยักอยู่