ชุมชนนักพัฒนาคอนเทนเนอร์กำลังพูดถึงเครื่องมือใหม่ที่เรียกว่า dockerfmt ซึ่งมีเป้าหมายในการสร้างมาตรฐานและปรับปรุงการจัดรูปแบบ Dockerfile เครื่องมือนี้สร้างขึ้นบนพาร์เซอร์ภายในของ buildkit เพื่อนำความสามารถในการจัดรูปแบบอัตโนมัติมาสู่ Dockerfile เช่นเดียวกับที่นักพัฒนาคาดหวังในภาษาโปรแกรมมิ่งอื่นๆ
การจัดรูปแบบ Dockerfile สมัยใหม่พร้อมข้อจำกัด
dockerfmt นำเสนอคุณสมบัติที่เป็นประโยชน์หลายประการสำหรับนักพัฒนาที่ทำงานกับการกำหนดคอนเทนเนอร์ รวมถึงการจัดรูปแบบขั้นตอน RUN ด้วย mvdan/sh การรองรับ heredocs พื้นฐาน และการจัดการความคิดเห็นแบบอินไลน์ในขั้นตอนการรัน เครื่องมือนี้มีตัวเลือกคำสั่งสำหรับตรวจสอบการจัดรูปแบบ การเขียนผลลัพธ์ที่จัดรูปแบบแล้วกลับไปยังไฟล์ การควบคุมการเยื้อง และการตรวจสอบให้แน่ใจว่าไฟล์จบลงด้วยบรรทัดว่าง อย่างไรก็ตาม สมาชิกในชุมชนได้ชี้ให้เห็นถึงข้อจำกัดหลายประการที่อาจส่งผลต่อการนำไปใช้ ตามเอกสารประกอบ พาร์เซอร์ RUN ไม่รองรับการจัดกลุ่มหรือเครื่องหมายอัฒภาค (semicolons) ในคำสั่ง ไม่มีการตัดบรรทัดสำหรับคำสั่ง JSON ที่ยาว และไม่รองรับคำสั่ง #escape=X
สมาชิกชุมชนคนหนึ่งได้เน้นย้ำข้อจำกัดเหล่านี้ โดยระบุว่า:
ผมอยู่ในกลุ่มที่ใช้ RUN set -e ;\ export DEBIAN_FRONTEND=noninteractive ;\ ฯลฯ - ดังนั้นเครื่องมือนี้คงไม่เหมาะกับผม
คุณสมบัติหลักของ dockerfmt
- จัดรูปแบบขั้นตอน RUN ด้วย mvdan/sh
- รองรับ heredocs พื้นฐาน
- รองรับการแสดงความคิดเห็นแบบอินไลน์ในขั้นตอน run
- มี JS bindings พร้อมใช้งาน
ข้อจำกัด
- ตัวแยกวิเคราะห์ RUN ไม่รองรับการจัดกลุ่มหรือเครื่องหมายอัฒภาค (semicolons) ในคำสั่ง
- ไม่มีการตัดบรรทัดสำหรับคำสั่ง JSON ที่ยาว
- ไม่รองรับคำสั่ง escape=X
ตัวเลือกคำสั่ง
-c, --check: ตรวจสอบว่าไฟล์ถูกจัดรูปแบบแล้วหรือไม่-w, --write: เขียนผลลัพธ์ที่จัดรูปแบบแล้วกลับไปยังไฟล์-1, --indent uint: จำนวนช่องว่างสำหรับการเยื้อง (ค่าเริ่มต้น 4)-n, --newline: จบไฟล์ด้วยบรรทัดว่างท้าย
ระบบนิเวศของเครื่องมือสร้างคอนเทนเนอร์ที่เติบโตขึ้น
การสนทนาเกี่ยวกับ dockerfmt ได้ขยายไปสู่การสนทนาที่กว้างขึ้นเกี่ยวกับระบบนิเวศการสร้างอิมเมจคอนเทนเนอร์ สมาชิกชุมชนได้ถกเถียงถึงข้อดีของการใช้ Dockerfiles ต่อไปเทียบกับทางเลือกอื่นๆ เช่น Podman, Buildah, buildpacks, Nix, kaniko, ko, bazel และ apko ทางเลือกแต่ละอย่างมีข้อแลกเปลี่ยนที่แตกต่างกันเมื่อเทียบกับ Dockerfiles แบบดั้งเดิม ตัวอย่างเช่น Buildah ถูกเน้นย้ำว่าให้เครื่องมือที่คุ้นเคย (RUN, ADD ฯลฯ) แต่อยู่ในสภาพแวดล้อมเชลล์ที่มีประสิทธิภาพมากกว่า แม้ว่าจะแลกมาด้วยการสูญเสียการแคชเลเยอร์อัตโนมัติ
การนำไปใช้และการบูรณาการในชุมชน
เครื่องมือนี้ได้รับความนิยมบ้างแล้วในชุมชนนักพัฒนา ผู้แสดงความคิดเห็นคนหนึ่งกล่าวถึงการบูรณาการ dockerfmt เข้ากับเครื่องมือตรวจสอบโค้ดและจัดรูปแบบสากลที่เรียกว่า Qlty CLI โดยระบุว่าการเพิ่มปลั๊กอินใช้เวลาเพียงประมาณสิบนาที การบูรณาการอย่างรวดเร็วนี้แสดงให้เห็นว่า dockerfmt มี API ที่ตรงไปตรงมาซึ่งทำให้ผู้สร้างเครื่องมือเข้าถึงได้ง่าย
ผู้ใช้บางคนชี้ให้เห็นถึงความขัดแย้งที่โปรเจกต์ dockerfmt เองไม่มี Dockerfile ทำให้นักพัฒนาทดสอบเครื่องมือในสภาพแวดล้อมคอนเทนเนอร์ได้ยาก ผู้ดูแลโปรเจกต์ได้ตอบสนองต่อข้อเสนอแนะนี้ โดยสัญญาว่าจะเผยแพร่ไบนารีเวอร์ชัน Docker ในเร็วๆ นี้
เมื่อการสร้างโค้ดอัตโนมัติผ่าน LLMs กลายเป็นเรื่องปกติมากขึ้น เครื่องมืออย่าง dockerfmt อาจมีความสำคัญมากขึ้นในการรักษาโค้ดให้สะอาดและสอดคล้องกันในโปรเจกต์ต่างๆ การสร้างมาตรฐานการจัดรูปแบบในทุกภาษาและไฟล์การกำหนดค่าช่วยให้ diffs สะอาดและทำให้ฐานโค้ดดูแลรักษาได้ง่ายขึ้น โดยเฉพาะในสภาพแวดล้อมการทำงานร่วมกัน
อ้างอิง: dockerfmt