รีวิว Doco CD: GitOps สำหรับ Docker Compose โดยไม่ต้องแบกภาระ Kubernetes

ทุกครั้งที่ push ก็ต้องทำพิธีกรรมเดิม: SSH เข้าไป ดึงโค้ดจาก repo สั่งให้ Compose stack กลับมาทำงาน ภาวนาว่าไม่มีอะไรพัง แล้วพยายามนึกว่ารัน migration ไปแล้วหรือยัง ลูปแบบทำมือนี้ใช้ได้จนถึงวันที่คุณต้องการการดีพลอยที่ทำซ้ำได้ บันทึกที่ชัดเจนว่าอะไรกำลังรันอยู่ หรือการกู้คืนจากการเบี่ยงเบนของสถานะ

Doco CD คือคำตอบตรง ๆ ข้อหนึ่ง มันเป็นเซอร์วิสเล็ก ๆ ที่เขียนด้วย Go คอยเฝ้าดู Git repo ของคุณและนำการเปลี่ยนแปลงของ Compose ไปใช้เมื่อคุณ push จะใช้ webhook หรือ polling ก็แล้วแต่คุณ ArgoCD และ Flux ทำแบบนี้ให้ Kubernetes แต่ Doco CD ข้าม Kubernetes ไปเลย เพราะไม่ต้องมี control plane

รีวิวนี้ครอบคลุมว่า Doco CD ทำอะไรได้ ทำอะไรไม่ได้ และเทียบกับ Komodo โหมด GitOps ของ Portainer, Dokploy และสคริปต์ GitHub Actions + SSH ธรรมดาแล้วเป็นอย่างไร เมื่ออ่านจบคุณจะรู้ว่ามันเหมาะกับระบบของคุณหรือไม่ และถ้าไม่ ควรเลือกอะไรแทน

TL;DR (สรุปย่อ)

• Doco CD คือเอเจนต์ GitOps ขนาดจิ๋วที่ออกแบบมาเพื่อ Compose โดยเฉพาะ: มันเฝ้าดู Git repo (GitHub, GitLab, Gitea, Forgejo และอื่น ๆ) แล้วปรับ stack ของคุณให้ตรงกันเมื่อมีอะไรเปลี่ยน
• การรองรับผู้ให้บริการ secret ภายนอกในตัว บวกกับการเข้ารหัสด้วย SOPS คือจุดที่ทำให้มันต่างจากการเขียนสคริปต์ดีพลอยเอง
• ตาม README ของมันเอง มันวางตัวเป็น "ทางเลือกง่าย ๆ แทน Portainer หรือ ArgoCD สำหรับ Docker" ซึ่งเป็นการวางกรอบที่ค่อนข้างตรง
• ข้อจำกัดจริง: มีเจ้าของโค้ดคนเดียว, ยังเป็นเวอร์ชันก่อน 1.0, ไม่มี UI สำหรับจัดการเครื่องหลายตัว และสถานะ reconciliation ที่จะสร้างใหม่ก็ต่อเมื่อมีการ poll หรือ webhook ครั้งถัดไป
• เลือกมันเมื่อคุณดูแลโฮสต์ Compose หนึ่งหรือไม่กี่เครื่อง และอยากให้ Git เป็นแหล่งความจริงโดยไม่ต้องมี UI เลือก Komodo ถ้ามีเครื่องจำนวนมาก เลือก Portainer ถ้าอยากได้ UI เลือก Dokploy ถ้าอยากได้ความรู้สึกแบบ PaaS หรือเลือก GitHub Actions + SSH เมื่อมันคือบริการเดียวบนเครื่องเดียวจริง ๆ

ช่องว่างที่ Doco CD พยายามเติมเต็ม

ในปี 2026 คนที่ใช้ Docker Compose ต้องเจอกับพื้นที่ตรงกลางที่แปลกประหลาด เครื่องมือ GitOps รายใหญ่อย่าง Argo CD และ Flux มุ่งไปที่ Kubernetes ส่วนโมเดลของ Watchtower ที่คอยสอบถาม registry ก็ตอบสนองต่อการเปลี่ยนอิมเมจ แทนที่จะนำสถานะ Compose ที่มีเวอร์ชันมาใช้จริง รีโพซิทอรี ของ Watchtower ถูกเก็บเข้าคลังเมื่อวันที่ 17 ธันวาคม 2025 และตอนนี้ระบุว่าโครงการไม่ได้รับการดูแลอีกต่อไป

GitHub Actions บวกกับขั้นตอนดีพลอยผ่าน SSH ก็ใช้งานได้ สำหรับบริการเดียวบนเครื่องเดียวนี่คือทางเลือกที่ถูกต้อง ปัญหาจะโผล่มาเมื่อคุณเพิ่มเครื่องที่สอง หรือ stack ที่สอง หรืออยากรู้ว่าตอนนี้ดีพลอย commit ไหนอยู่ คุณยังได้ log ของเวิร์กโฟลว์ แต่ไม่ได้การ reconcile แบบเนทีฟของ Compose ไม่ได้การกู้คืนจากการเบี่ยงเบน และไม่ได้มุมมองถาวรว่าเครื่องยังตรงกับ repo อยู่หรือไม่

คำโฆษณาของ Doco CD ที่ยกมาตรงจาก READMEคือ "ทางเลือกง่าย ๆ แทน Portainer หรือ ArgoCD สำหรับ Docker" การวางกรอบแบบนี้แหละคือประเด็น: เล็ก เป็นเนทีฟกับ Compose ไม่มี Kubernetes ไม่มี UI ให้ต้องดูแล ไม่มี control plane ส่วนกลางให้ต้องคอยประคบประหงม ถ้าคุณไม่ได้ใช้ K8s และไม่เคยอยากใช้ นี่คือหมวดหมู่ที่คุณตามหาอยู่

Doco CD ทำงานอย่างไรจริง ๆ

Doco CD คือไบนารี Go ไฟล์เดียวที่รันอยู่ในคอนเทนเนอร์ Docker คอยเฝ้าดู Git repository และนำการเปลี่ยนแปลงของ Compose ไปใช้เมื่อสถานะของ repo เปลี่ยน นั่นคือแนวคิดทั้งหมด ส่วนที่น่าสนใจอยู่ที่ค่าเริ่มต้นและการเชื่อมต่อกับระบบอื่น

ทริกเกอร์ มีสองโหมด: webhook หรือ polling แบบ webhook เกือบจะทันทีแต่ต้องเปิดพอร์ต หรือพูดตามความเป็นจริงคือต้องมี reverse proxy อยู่หน้า Doco CD ส่วน polling คือการดึงข้อมูลเป็นระยะ: ช้ากว่านิดหน่อยแต่ไม่ต้องเปิดพอร์ตขาเข้า polling เป็นค่าเริ่มต้นที่ง่ายกว่า และตาม เอกสารทางการ ทั้งสองแบบเป็นตัวเลือกชั้นหนึ่งเท่ากัน เลือกโดยดูว่าเครื่องของคุณมี endpoint สาธารณะที่เข้าถึงได้หรือไม่ และคุณต้องการให้ดีพลอยเร็วแค่ไหน

การตั้งค่าต่อ repo ไฟล์ .doco-cd.yaml (หรือ .doco-cd.yml) จะวางอยู่ที่รากของ repo ข้าง ๆ ไฟล์ Compose ของคุณ ฟิลด์เดียวที่จำเป็นคือชื่อของการดีพลอย ตัวอย่างการตั้งค่าขั้นต่ำมีหน้าตาแบบนี้:

# .doco-cd.yaml
name: my-stack
# Everything below is optional. These are the defaults.
timeout: 180          # seconds
remove_orphans: true
prune_images: true
force_recreate: false

นั่นคือค่าเริ่มต้นตามเอกสาร: หมดเวลาที่ 180 วินาที, ลบคอนเทนเนอร์กำพร้า, ล้างอิมเมจที่ไม่ใช้ และไม่บังคับสร้างใหม่

การค้นหาอัตโนมัติ เมื่อเปิดการค้นหาอัตโนมัติ Doco CD จะไล่หาไฟล์ Compose ในไดเรกทอรีย่อย ทำให้ repo เดียวเก็บได้หลาย stack นอกจากนี้ยังรองรับการตั้งค่าดีพลอยหลายชุดในไฟล์เดียว โดยเขียนเป็นเอกสาร YAML คั่นด้วยบรรทัดขีดสามขีด ค่าเริ่มต้นของการล้างข้อมูลนั้นค่อนข้างระมัดระวัง และควรอ่านให้ดีก่อนจะพึ่งพามัน:

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

ผู้ให้บริการ Git ที่รองรับ รองรับ GitHub, GitLab, Gitea, Forgejo, Gogs และ Azure DevOps โดย Azure DevOps เป็นข้อยกเว้นสำหรับ webhook เพราะไม่รองรับ Azure Service Hooks ส่วนการรองรับ Gitea และ Forgejo จะสำคัญถ้าคุณโฮสต์ระบบจัดการโค้ดของตัวเอง

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

การปรับสถานะให้ตรงกัน ค่าเริ่มต้นคือจำกัดการรีสตาร์ต 5 ครั้งภายในกรอบเวลา 300 วินาที เพื่อกัน health check ที่ไม่นิ่งไม่ให้วนไม่รู้จบ repo เดียวกันแต่คนละ ref จะรันตามลำดับ ส่วน repo เดียวกันและ ref เดียวกันจะรันขนานกัน จุดหลังนี้ละเอียดอ่อนแต่มีประโยชน์: การดีพลอย ref เดิมหลายครั้งจะไม่ต้องต่อคิวรอกัน

ผู้ให้บริการ secret ภายนอกที่มีมาให้ในตัว นี่คือเหตุผลที่หนักแน่นที่สุดข้อหนึ่งที่จะเลือก Doco CD แทนสคริปต์ดีพลอยธรรมดา: มันรองรับ AWS Secrets Manager, Bitwarden Secrets Manager, Bitwarden Vault / Vaultwarden, 1Password, 1Password Connect, Infisical, OpenBao และ Webhook นอกจากนี้ยังรองรับการเข้ารหัสด้วย SOPS สำหรับข้อมูลดีพลอยที่อ่อนไหว ทำให้คุณมีทางออกที่สะอาดกว่าในการเลิกเก็บไฟล์ env แบบข้อความธรรมดาไว้ใน Git โดยไม่ต้องสร้างกระบวนการดึงค่า secret ทั้งหมดเอง

ส่วนที่เหลือ Doco CD ให้เมตริกแบบ Prometheus, การตั้งเวลางาน, การแจ้งเตือน, อิมเมจคอนเทนเนอร์แบบ distroless และสัญญาอนุญาต Apache-2.0 ตาม ประวัติการออกเวอร์ชันณ วันที่ 20 สิงหาคม 2026 เวอร์ชันเสถียรล่าสุดคือ v0.109.2 และรุ่นพรีรีลีสใหม่ที่สุดคือ v0.110.0-rc.1

งานของ Doco CD จบลงตรงที่ "นำ manifest ไปใช้" จากนั้นก็เป็น Docker ธรรมดา คำสั่งดูล็อกของ Compose เอง คือสิ่งที่คุณจะใช้ตรวจดูว่ามีอะไรกำลังรันอยู่

เคล็ดลับเรื่อง secret ถ้า repo ส่วนตัวของคุณยังมีไฟล์ env แบบข้อความธรรมดาอยู่ ให้จัดลำดับความสำคัญไปที่ผู้ให้บริการ secret ภายนอกของ Doco CD หรือการรองรับ SOPS เป้าหมายนั้นง่ายมาก: เอาความลับแบบข้อความธรรมดาออกจาก Git แต่ยังให้การดีพลอยดึงค่าตอนรันไทม์ได้อยู่

จุดที่ Doco CD ยังไม่ดีพอ

ทุกเครื่องมือมีข้อจำกัด และข้อจำกัดของ Doco CD ก็ควรรู้ไว้ก่อนที่คุณจะทุ่มทั้งสุดสัปดาห์ไปกับการติดตั้งมัน

เจ้าของโค้ดคนเดียว ไฟล์ CODEOWNERS ของรีโพซิทอรี กำหนดทุกพาธให้กับ kimdre การออกเวอร์ชันยังคงถี่อยู่ แต่การกำกับดูแลกระจุกอยู่ที่คนคนเดียว

ยังไม่ถึงเวอร์ชัน 1.0 Doco CD ยังใช้การกำหนดเวอร์ชันแบบ 0.x อยู่ ดังนั้นควรตรึงเวอร์ชันที่ทดสอบแล้วและอ่านบันทึกการอัปเกรดก่อนนำไปใช้จริง อิสชู GitHub #851 ที่ปิดไปแล้ว แสดงให้เห็นเหตุผล: Docker v29 บังคับให้โครงการต้องเลิกใช้โมดูล Go ของ Docker ที่เลิกสนับสนุนแล้ว

ไม่มีเชลล์อยู่ในคอนเทนเนอร์ของ Doco CD ด้วยเหตุผลด้านความปลอดภัย Doco CD ไม่ให้สภาพแวดล้อมเชลล์และไม่รันสคริปต์ใด ๆ บนเครื่องโฮสต์ งานก่อนและหลังการดีพลอยจึงต้องทำผ่าน init container, sidecar หรือ lifecycle hook ของ Compose ซึ่งเพิ่มงานตั้งค่าเมื่อเทียบกับเครื่องมือที่สั่งรันสคริปต์ดีพลอยได้ตรง ๆ

สถานะหายเมื่อรีสตาร์ต สถานะ reconciliation ถูกเก็บไว้ในหน่วยความจำ เมื่อ Doco CD รีสตาร์ต สถานะนั้นจะถูกสร้างใหม่ก็ต่อเมื่อมีการ poll หรือ webhook ครั้งถัดไป ช่องว่างจึงขึ้นอยู่กับช่วงเวลาที่คุณตั้ง poll หรือว่าจะมี webhook เข้ามาอีกเมื่อไร

ไม่มี UI สำหรับจัดการเครื่องหลายตัว การใช้งานหลายเครื่องไม่จำเป็นต้องมีเอเจนต์ประจำแต่ละเครื่องอีกต่อไป ตั้งแต่ v0.102.0 การตั้งค่าดีพลอยสามารถชี้ไปยัง Docker context ระยะไกลได้ รวมถึง SSH context ด้วย และ repository เดียวสามารถกำหนดปลายทางการดีพลอยได้หลายจุด การรัน Doco CD หนึ่งอินสแตนซ์ต่อหนึ่งเครื่องยังใช้ได้อยู่ แต่ตอนนี้อินสแตนซ์กลางเพียงตัวเดียวก็ดีพลอยไปยังเครื่อง Docker ระยะไกลได้แล้ว สิ่งที่ Doco CD ยังขาดคือ UI จัดการเครื่องหลายตัวแบบที่ Komodo มี และรายการเครื่องแบบรวมศูนย์

การใช้ RAM และ CPU ไม่ได้ระบุเป็นตัวเลขไว้ในเอกสาร เอกสารทางการอธิบายความต้องการทรัพยากรว่า "เล็กจิ๋ว" แต่ไม่ได้เผยแพร่ตัวเลขอ้างอิงใด ๆ ให้เลือกขนาด VPS ตามแอปพลิเคชันที่จะรันบนนั้น เผื่อพื้นที่สำหรับการทำงานไว้ และตรวจวัดการใช้งานจริงของ Doco CD ในสภาพแวดล้อมของคุณเอง

เคล็ดลับเรื่องหลายเครื่อง ใช้ Docker context และปลายทางการดีพลอยแยกกันต่อหนึ่งเครื่อง จำกัดการเข้าถึงผ่าน SSH และทำให้ secret ของ webhook หรือ API ไม่ซ้ำกัน ถ้าคุณชอบแบบเอเจนต์แยกกัน การรัน Doco CD หนึ่งอินสแตนซ์ต่อหนึ่งเครื่องก็ยังใช้ได้อยู่

Doco CD เทียบกับทางเลือกอื่น

เครื่องมืออีกสี่ตัวที่ผมจะใส่ไว้ในลิสต์สั้น ๆ ล้วนพยายามแก้โจทย์ "ดีพลอย Compose อัตโนมัติจาก Git" เหมือนกัน แต่ด้วยการแลกได้แลกเสียที่ต่างกันมาก คำถามไม่ใช่ว่าจะทำหรือไม่ เพราะคุณตัดสินใจไปแล้ว คำถามคือเครื่องมือรูปแบบไหนเหมาะกับระบบของคุณ นี่คือการเทียบกันแบบเคียงข้าง

ขอสรุปสั้น ๆ ของแต่ละตัว เพราะตารางบอกรูปร่าง ส่วนคำอธิบายบอกเหตุผล:

Komodo ทางเลือกจริงจังสำหรับงานหลายเครื่อง มีบริการ Core ส่วนกลางบวกกับเอเจนต์ Periphery บนทุกเครื่อง มี UI เดียวที่มองเห็นทั้งหมด มีการ build ที่ขับเคลื่อนด้วย Git นอกเหนือจากการดีพลอย และรองรับ Docker Swarm การติดตั้งหนักกว่า เพราะคุณต้องรันฐานข้อมูลและ control plane ด้วย แต่นี่คือรูปแบบที่ถูกต้องถ้าคุณมีเครื่องจำนวนมาก Komodo เหมาะกว่าเมื่อการควบคุมเครื่องแบบรวมศูนย์เป็นเรื่องสำคัญ

Portainer (CE หรือ BE) พร้อม GitOps อินเทอร์เฟซกราฟิกเต็มรูปแบบวางอยู่บนการซิงก์กับ Git เป็นตัวเลือกที่ถูกต้องเมื่อทีมอยากจัดการคอนเทนเนอร์แบบคลิกได้ควบคู่ไปกับ CD ถ้ายังไงก็จะมีคนเข้าไปดูล็อกและรีสตาร์ตคอนเทนเนอร์ใน UI อยู่แล้ว ก็ให้ CD อยู่ที่เดียวกันเสียเลย กินทรัพยากรมากกว่า Doco CD ส่วน OIDC/SSO และ RBAC แบบละเอียดถูกกั้นไว้ใน Business Edition ที่ต้องเสียเงิน คู่มือทางเลือกแทน Portainer ของเรา ครอบคลุมภาพรวมของการจัดการ Docker ที่กว้างกว่านี้

Dokploy สไตล์ PaaS มีความเห็นชัดเจนว่าควรทำอย่างไร ดีพลอยอัตโนมัติเมื่อ push มี UI เว็บให้ทุกอย่าง และตั้ง Traefik พร้อม URL ที่สะอาดให้ตั้งแต่แกะกล่อง เหมาะกับทีมที่อยากได้ความรู้สึกแบบ Heroku และยอมแลกความยืดหยุ่นดิบ ๆ ของ Compose ถ้าคุณแพ้ YAML นี่คือทางที่เบาที่สุดสู่ "git push แล้วแอปก็ขึ้น"

GitHub Actions + SSH ไม่ต้องเพิ่มโครงสร้างพื้นฐานใด ๆ งานดีพลอยอยู่ในเวิร์กโฟลว์ที่คุณมีอยู่แล้ว คุณได้ log ของเวิร์กโฟลว์ แต่ไม่ได้การ reconcile แบบเนทีฟของ Compose ไม่ได้การกู้คืนจากการเบี่ยงเบน และไม่ได้มุมมองสถานะเครื่องแบบถาวร เว้นแต่คุณจะสร้างชิ้นส่วนเหล่านั้นเอง ใช้ได้ดีกับบริการเดียวบนเครื่องเดียว แต่จะพังทันทีที่คุณเพิ่มปลายทางที่สอง หรืออยากรู้ว่าอะไรรันอยู่ที่ไหนโดยไม่ต้อง SSH เข้าไป สำหรับผู้อ่านกลุ่มที่ต้องการอะไรง่าย ๆ ที่สุด GitHub Actions + SSH ยังคงเป็นคำตอบที่ถูกต้อง

ยังมีผู้เล่นหน้าใหม่ชื่อ stackd ที่วางตัวด้วยถ้อยคำคล้าย ๆ กันว่า "GitOps โดยไม่ต้องเสียภาษี Kubernetes" ควรรู้ไว้ว่าหมวดหมู่นี้ยังคึกคัก แต่ยังไม่ถึงขั้นควรโยนหัวก้อยเลือกมันแทน Doco CD ในตอนนี้

อ่าน

Coolify vs Dokploy: การเปรียบเทียบอย่างละเอียดสำหรับ PaaS แบบ Self-Hosted บน VPS

เมื่อไรที่ Doco CD คือตัวเลือกที่ถูกต้อง (และเมื่อไรที่ไม่ใช่)

เลือก Doco CD เมื่อ:

• คุณดูแลโฮสต์ Docker Compose หนึ่งหรือไม่กี่เครื่อง และอยากให้ Git เป็นแหล่งความจริง
• คุณอยากแก้ YAML ในเอดิเตอร์มากกว่าจะไล่คลิกใน UI
• คุณอยากได้การรองรับผู้ให้บริการ secret ภายนอกและการเข้ารหัสด้วย SOPS โดยไม่ต้องสร้างกระบวนการทั้งหมดเอง
• คุณรับได้กับโครงการที่มีผู้ดูแลคนเดียว ยังไม่ถึง 1.0 แต่พัฒนาอย่างต่อเนื่อง

Komodo เลือกมันเมื่อคุณดูแลเครื่องจำนวนมากและต้องการควบคุมแบบรวมศูนย์ หรือเมื่อคุณต้องการทั้ง build ที่ขับเคลื่อนด้วย Git ไม่ใช่แค่การดีพลอย ภายใต้ร่มเดียวกัน

Portainer (CE หรือ BE) เลือกมันเมื่อทีมอยากได้ UI สำหรับงานคอนเทนเนอร์ประจำวันควบคู่ไปกับ CD คือเมื่อชั้นภาพนี่แหละคือเหตุผลจริง ๆ ที่คุณกำลังพิจารณาเครื่องมือตัวนี้

Dokploy เลือกมันเมื่อคุณอยากได้ประสบการณ์ดีพลอยแบบ PaaS และไม่ต้องการควบคุม Compose แบบดิบ ๆ

GitHub Actions + SSH อยู่กับมันต่อไปเมื่อมีบริการเดียวบนเครื่องเดียว และคุณไม่ต้องการ reconciliation หรือการกู้คืนจากการเบี่ยงเบน

สำหรับคนที่อยู่ตรงกลางระหว่างยุคหลัง Watchtower กับก่อน Kubernetes นั้น Doco CD เป็นตัวเลือกเบา ๆ ที่แข็งแรง ความเห็นของผมคือ สำหรับ homelab ใหม่หรือ SaaS เล็ก ๆ ผมจะเริ่มด้วย Doco CD ตราบใดที่การทำงานแบบ Git มาก่อนและไม่มี UI ยังเหมาะอยู่ แล้วค่อยย้ายไป Komodo เมื่อรายการเครื่องแบบรวมศูนย์ สิทธิ์การเข้าถึง และการมองเห็นภาพรวมกลายเป็นข้อกำหนดจริง ๆ

ไม่ว่าคุณจะเลือกเครื่องมือตัวไหน ก็ควรรันมันบน Linux VPS ที่มีขนาดเหมาะกับภาระงาน Compose ที่มันจะต้องแบก Linux VPS ของ Cloudzy เป็นบ้านที่เหมาะสำหรับงานนี้ พร้อมสิทธิ์ root มาให้ตั้งแต่ต้น และถ้าคุณอยากข้ามพิธีกรรม apt ก็สามารถ ดีพลอย Docker ได้ในคลิกเดียว จากมาร์เก็ตเพลสของเรา

มาร์เก็ตเพลสของเรายังมีอิมเมจแบบคลิกเดียวสำหรับ Giteaซึ่ง Doco CD เชื่อมต่อด้วยได้ในตัว และยังมีอิมเมจสำหรับ Komodo ด้วย รวมถึง Portainerเผื่อคุณตัดสินใจว่าตัวใดตัวหนึ่งในนั้นคือรูปแบบที่คุณอยากได้มากกว่า

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

Doco CD พร้อมใช้งานจริงหรือยัง?

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

จะจัดการหลายเครื่องด้วย Doco CD ได้อย่างไร?

ให้ใช้ Docker context และปลายทางการดีพลอยแยกกันสำหรับแต่ละเครื่อง Doco CD อินสแตนซ์เดียวสามารถดีพลอยไปยังเครื่อง Docker ระยะไกลหลายเครื่องผ่าน SSH หรือ TCP ได้ ส่วนการรันหนึ่งอินสแตนซ์ต่อหนึ่งเครื่องก็ยังเป็นโมเดลการแยกส่วนที่เลือกใช้ได้ ถ้าคุณต้องการรายการเครื่องแบบรวมศูนย์ สิทธิ์การเข้าถึง และการมองเห็นภาพรวม ให้เลือก Komodo

โหมด webhook กับโหมด polling ต่างกันอย่างไร?

โหมด webhook จะดีพลอยแทบจะทันทีเมื่อมีการ push เข้า Git แต่ต้องมีพอร์ตที่เข้าถึงได้จากอินเทอร์เน็ต หรือมี reverse proxy อยู่หน้า Doco CD ส่วนโหมด polling จะตรวจ repo ตามตารางเวลา ทำให้ดีพลอยช้าลงเล็กน้อยแต่ไม่ต้องเปิดพอร์ตใด ๆ polling เป็นค่าเริ่มต้นที่ง่ายกว่า ส่วน webhook คุ้มค่าเมื่อคุณ push บ่อยหรือต้องการวงจรป้อนกลับที่รวดเร็ว

Doco CD เทียบกับ Komodo แล้วเป็นอย่างไร?

Doco CD เบากว่าและไม่มี UI อีกทั้งจัดการหลายเครื่องได้ผ่าน Docker context ระยะไกล ส่วน Komodo ใช้บริการ Core ส่วนกลางบวกเอเจนต์ Periphery แล้วเพิ่ม UI สำหรับดูภาพรวมและ build ที่ขับเคลื่อนด้วย Git เข้ามา เลือก Doco CD ถ้าอยากดีพลอย Compose แบบไม่มี UI เลือก Komodo เมื่อการควบคุมแบบรวมศูนย์เป็นเรื่องสำคัญ

Doco CD ใช้แทน Watchtower ได้ไหม?

สำหรับกรณีใช้งานที่ผู้ใช้ Watchtower ส่วนใหญ่ต้องการจริง ๆ คือ "ดีพลอยสิ่งที่อยู่ใน Git เมื่อ Git เปลี่ยน" คำตอบคือใช่ นั่นคือสิ่งที่ Doco CD ทำ แต่สำหรับโมเดลตามตัวอักษรของ Watchtower คือคอยถาม registry แล้วดึงอิมเมจเมื่อมีแท็กใหม่ คำตอบคือไม่ เพราะ Doco CD ถูกกระตุ้นด้วย Git ไม่ใช่ registry โมเดลที่กระตุ้นด้วย Git นั้นปลอดภัยกว่าและตรวจสอบย้อนหลังได้ดีกว่าสำหรับอะไรก็ตามที่เกินระดับบริการเล่น ๆ