Docker Run to Compose Converter: แปลงคำสั่ง docker run เป็น Compose YAML ได้ในไม่กี่วินาที

แทบทุก README ของโปรเจกต์มีบรรทัดที่นักพัฒนาจำกันได้ขึ้นใจ: คำสั่ง docker run ตัวเดียวที่ตามด้วย flag ครืดยาวเป็นหางว่าว — port ที่ publish, volume ที่ mount, environment variable และ restart policy README บอกให้รัน one-liner นั้น แต่ทีมของคุณไม่รัน container แบบ ad-hoc ทุกอย่างต้องผ่าน Compose เพื่อให้ review ได้และแชร์กันได้ Docker Run to Compose Converter ปิดช่องว่างนี้: วางคำสั่งลงไป แล้ว service block ที่พร้อมใช้ในรูป docker-compose.yml ก็ปรากฏใน browser ของคุณทันที

ตัวเครื่องมือ parse คำสั่งเหมือน shell จริง ๆ — รวมถึง quote และการต่อบรรทัดด้วย backslash — แล้วแมปทุก flag ที่จำได้ไปยัง key ที่ถูกต้องของ Compose ส่วน flag ที่ไม่มีตัวตรง ๆ จะกลับมาเป็นคำเตือนที่อ่านรู้เรื่อง ไม่ใช่หายเงียบ ๆ ทุกอย่างประมวลผลฝั่ง client ล้วน ๆ ชื่อ image ภายในและค่า configuration ต่าง ๆ จึงไม่เคยออกจากเครื่องคุณ บทความนี้จะพาดูว่าทำไมการแปลงนี้ถึงคุ้ม แต่ละ flag ไปอยู่ตรงไหนใน YAML และมีจุดไหนที่ควรเช็กก่อน commit

ทำไมต้องใช้ Docker Run to Compose Converter?

• ตัดภาษีพิมพ์ซ้ำทิ้ง การแปลงคำสั่งยี่สิบ flag ด้วยมือต้องจำทั้งชื่อ key ของ Compose, การย่อหน้า และ syntax แบบ list ตัว converter จัดการส่วนกลไกให้ในไม่กี่วินาที
• README พูดภาษา docker run แต่ทีมพูดภาษา Compose quick start ส่วนใหญ่เขียนเป็น one-liner การแปลงมันทำให้คุณรับเครื่องมือใหม่มาใช้โดยไม่ต้องทำลายธรรมเนียม "หนึ่งไฟล์ หนึ่ง stack" ของทีม
• ผลลัพธ์ตรงต้นฉบับและอ่านออก ทุกค่าลงใน key มาตรฐานที่มนุษย์จะเขียนเอง — ports, volumes, environment, networks, restart — ไม่ใช่ YAML กึกก้องจากเครื่องที่อ่านไม่รู้เรื่อง
• เตือนเป็นคำ ไม่ใช่เซอร์ไพรส์ flag ที่ไม่มีคู่ตรงใน Compose อย่าง --publish-all หรือ --rm จะกลายเป็น note ให้ตรวจสอบ ไม่ใช่ข้อมูลหายไปเงียบ ๆ
• ข้อมูลไม่หลุดออกจากเครื่อง การ parse เกิดขึ้นใน browser ด้วย JavaScript ชื่อ registry ภายใน, host path และ secret จึงอยู่กับเครื่องคุณ

ฟีเจอร์หลัก

• Tokenize แบบ shell จริง ค่าที่มี quote, short flag ที่รวมกันอย่าง -it และการต่อบรรทัดด้วย backslash ถูกอ่านเหมือนที่ shell ของคุณอ่าน
• เกินหกตัวหลัก label, user, working directory, hostname, flag ของ healthcheck, DNS และ device ก็ถูกแมปด้วยเช่นกัน

วิธีใช้งาน

1. วางคำสั่ง คัดลอกคำสั่ง docker run เต็มบรรทัด — หรือคำสั่งหลายบรรทัดที่ต่อด้วย backslash — ลงในช่อง input รองรับทั้ง docker create และคำสั่งที่นำหน้าด้วย sudo
2. ดู YAML ปรากฏ การแปลงทำงานสด ๆ: พอคำสั่ง parse ผ่าน service block ก็แสดงในช่องผลลัพธ์ทันที
3. อ่าน service ที่ได้ เทียบ image, ชื่อ service, port, volume, environment และ restart policy กับสิ่งที่คุณตั้งใจ
4. อ่านคำเตือน อะไรที่เครื่องมือแมปได้ไม่ครบจะขึ้นเป็น note ให้ตรวจสอบ เก็บส่วนนั้นก่อนใช้งานจริง
5. Copy หรือ download วาง YAML ลงไฟล์ Compose ที่มีอยู่ หรือดาวน์โหลดเป็น docker-compose.yml แล้วรัน docker compose config เพื่อ validate

ทุก flag มีบ้านใน YAML

คุณค่าของเครื่องมือนี้อยู่ที่ mapping ที่ใช้ทุกครั้งที่แปลง หก flag นี้ครอบคลุมคำสั่งจริงส่วนใหญ่:

ทุกอย่างที่พิมพ์ต่อท้ายชื่อ image คือ command ของ container และเครื่องมือจะแนบไว้เป็น command ของ service ส่วน --entrypoint ที่ระบุชัดจะกลายเป็น key entrypoint สำหรับ flag แบบ interactive ก็แปลตรง ๆ: -i กลายเป็น stdin_open: true และ -t กลายเป็น tty: true

มีสามจุดที่ควรเช็กก่อน commit:

• path แบบ relative ของ bind mount ใน docker run path host แบบ relative อิงกับ directory ปัจจุบันของ shell แต่ใน Compose มันอิงกับตำแหน่งของไฟล์ compose ปรับ ./ ให้เหมาะถ้าคำสั่งเดิมเขียนไว้รันจากที่อื่น
• การอ้างอิง environment file -e VAR แบบไม่ใส่ค่าจะไปรับค่าจาก shell ตอนรัน ซึ่งไฟล์ Compose แบบ static ทำแทนไม่ได้ ใส่ค่าตรง ๆ ใช้ ${VAR} คู่กับไฟล์ .env หรือย้ายไปไว้ใต้ env_file
• ค่าที่มี quote shell ตัด quote ออกก่อนเครื่องมือจะเห็นข้อความ ดังนั้น -e MSG="hello world" ควรมาเป็นค่าเดียวที่มีช่องว่างครบ ลอนดูผลลัพธ์สักนิดว่าอะไรไม่หลุด spacing ไป

คำสั่งนี้ หน้าตาประมาณ quick start ของเครื่องมือ monitoring ทั่วไป:

docker run -d \
  --name metrics \
  -p 9100:9100 \
  -v /proc:/host/proc:ro \
  -e NODE_ID=web-01 \
  --network monitoring \
  --restart unless-stopped \
  quay.io/prometheus/node-exporter:v1.8.1

กลายเป็น service block นี้:

services:
  metrics:
    image: quay.io/prometheus/node-exporter:v1.8.1
    container_name: metrics
    ports:
      - '9100:9100'
    volumes:
      - '/proc:/host/proc:ro'
    environment:
      - NODE_ID=web-01
    networks:
      - monitoring
    restart: unless-stopped

เติม networks: ระดับบนสุดเข้าไปอีกนิด one-liner เดิมก็กลายเป็น service ที่ version ได้และ review ได้แล้ว

กรณีการใช้งานจริง

เริ่มใช้ Compose กับการพัฒนาบนเครื่อง

คุณกำลังสตาร์ท database ด้วยการพิมพ์ docker run ยาว ๆ จากโน้ตทุกครั้ง แปลงครั้งเดียว เซฟ service ไว้ในไฟล์ compose ของโปรเจกต์ แล้ว docker compose up -d จะกลายเป็นคำสั่งเดียวที่ทุกคนในทีมต้องรู้

ประกอบ stack หลาย service จาก one-liner ใน README

โปรเจกต์ side project ทั่วไปต้องมี web app, queue และ search engine — แต่ละตัวก็ document ไว้เป็น one-liner ของตัวเอง แปลงทีละตัว วาง service ทั้งหมดลงไฟล์เดียว แล้วทั้ง stack ก็สตาร์ทด้วยคำสั่งเดียว ส่วนคำเตือนราย service จะชี้ให้เห็นว่าอะไรยังต้องเก็บต่อ เช่น network ที่ใช้ร่วมกัน

มาตรฐานเดียวกันทั้งทีม

พอแต่ละคนต่อ container เอง ความต่างเล็ก ๆ ก็เริ่มงอก: คนหนึ่ง mount config แบบ read-write อีกคนลืมตั้ง restart policy คำสั่งชุดเดียวที่ผ่านการเห็นชอบ แปลงแล้ว commit เข้าไป ทำให้ทั้งทีมได้ configuration ชุดเดียวกัน และ pull request ก็บอกด้วยว่าเปลี่ยนเมื่อไร

จดบันทึก infrastructure ไปพร้อมกัน

ไฟล์ compose คือเอกสารที่รันได้ แปลงคำสั่งเบื้องหลังเครื่องมือภายในทุกครั้งที่ deploy แล้วไฟล์นั้นจะทำหน้าที่สองเป็นบันทึกว่าอะไรรันอยู่ตรงไหน ผ่าน port ไหน ใช้ volume อะไร แม่นกว่าหน้า wiki ที่ไม่ได้แตะมาสามเดือนแน่นอน

แนวปฏิบัติที่ดี

• ตรวจ volume path ทุกเส้น bind mount แบบ relative resolve ต่างจากเดิมภายใต้ Compose และ host path ก็ต่างกันตามเครื่อง เช็กทุก entry ก่อนแชร์ไฟล์
• ย้าย secret ไปไฟล์ env อะไรที่หน้าตาเหมือน password, token หรือ connection string ควรอยู่ใน .env ที่ถูก git-ignore แล้วอ้างด้วย ${VAR} — ไม่ใช่อยู่ในไฟล์ compose ที่ commit ขึ้น repo
• Pin เวอร์ชัน image quick start มักใช้ :latest เปลี่ยนเป็น tag ชัด ๆ ตอนแปลงเลย เพื่อให้ docker compose up ได้ผลเหมือนเดิมในเดือนหน้า
• Validate ด้วย docker compose config หนึ่งคำสั่งยืนยันได้ว่า YAML parse ผ่านและโครงสร้าง service เรียบร้อยก่อนใครจะเอาไปรัน
• ประกาศ network อย่างตั้งใจ --network ที่แมปมาต้องมีนิยามระดับบนสุดรองรับ ตัดสินใจเลยว่า service จะแชร์ network เดียวหรือแยกขาดจากกัน
• Commit ไฟล์และ review การเปลี่ยนแปลงผ่าน pull request Compose คือแหล่งความจริงที่ version ได้ ให้ถือว่าการแก้ไฟล์นี้เท่ากับการแก้โค้ดทั่วไป

เริ่มแปลง one-liner ของคุณวันนี้

ถ้าทีมคุณใช้ชีวิตอยู่กับ Compose README one-liner เส้นเดียวก็ไม่ควรทำลายแบบแผนนั้น วางคำสั่ง docker run เส้นถัดไปที่เจอลงใน Docker Run to Compose Converter อ่าน service ที่แมปได้ แล้ว commit ไฟล์ compose ที่ทุกคนในทีมนำไปใช้และพัฒนาต่อได้

Related Tools You Might Like:

• Docker Compose to Kubernetes Converter — ต่อจาก service ใน Compose ที่คุณดูแลแล้ว สู่ starter Kubernetes manifests
• YAML Formatter — จัดรูปแบบและตรวจไฟล์ compose ที่รวมกันแล้วก่อน commit
• Nginx Log Analyzer — วิเคราะห์ access log ของ container ที่เพิ่งประกอบเข้า stack ไปสด ๆ

ขอให้ทุก one-liner ของคุณกลายเป็น infrastructure ที่ทั้งทีมอ่านออกตั้งแต่บรรทัดแรก

คำถามที่พบบ่อย

ถ: คำสั่งของฉันถูกอัปโหลดขึ้น server ไหม?

ตอบ: ไม่ การ parse และการสร้าง YAML ทำงานใน browser ของคุณล้วน ๆ ชื่อ image, host path และค่า environment ต่าง ๆ ไม่เคยออกจากเครื่อง

ถ: รองรับคำสั่ง docker run แบบหลายบรรทัดไหม?

ตอบ: รองรับ คำสั่งที่ต่อบรรทัดด้วย backslash จะถูก tokenize เหมือนที่ shell อ่าน คัดลอกจากเอกสารหรือ shell history มาวางได้เลย

ถ: flag ที่เครื่องมือจำไม่ได้จะเป็นอย่างไร?

ตอบ: ไม่มีอะไรหายแบบเงียบ ๆ ทุก flag ที่แมปไม่ได้จะกลายเป็นคำเตือนภาษาคนที่บอกว่าส่วนไหนต้องเก็บด้วยมือใน YAML ฉบับสุดท้าย

ถ: ทำไม -e ที่ไม่ใส่ค่าถึงขึ้นคำเตือน?

ตอบ: -e VAR แบบไม่มีค่าจะรับค่าจาก shell ตอนรัน ซึ่งไฟล์ Compose แบบ static สื่อสารไม่ได้ ให้ใส่ค่าตรง ๆ ใช้ ${VAR} หรือย้ายไปใช้ env_file แทน