รีวิว Arcane สำหรับ Docker: พร้อมมาแทนที่ Portainer แล้วหรือยัง?

Arcane ปล่อยการควบคุมการเข้าถึงตามบทบาทแบบเต็มรูปแบบเมื่อวันที่ 7 มิถุนายน 2026 ในรุ่น v2.0.0 และยังสแกนอิมเมจของคุณเพื่อหาช่องโหว่ที่รู้จักตามตารางเวลาที่คุณกำหนดเองได้ ทั้งสองอย่างนี้ยังไม่มีในตอนที่ Brandon Lee เผยแพร่บทความความประทับใจแรกเกี่ยวกับ Arcane เมื่อวันที่ 29 ธันวาคม 2025 ซึ่งเป็นเวลากว่าห้าเดือนเล็กน้อยก่อนรุ่นที่มี RBAC

ช่องว่างนี้คือส่วนที่น่าอึดอัดของทุกรีวิว Arcane สำหรับ Docker ในตอนนี้ เครื่องมือนี้มาถึง v2.10.2 แล้ว ซึ่งออกเมื่อวันที่ 5 กันยายน 2026 ไม่ถึงสองสัปดาห์หลังจาก v2.9.0 รุ่น v2.10.0 ได้แก้ปัญหาไดเรกทอรีโคลนของ GitOps รั่วไหลที่จะพูดถึงด้านล่าง และเพิ่มขั้นตอนทดลอง Convert to Compose สำหรับคอนเทนเนอร์ที่กำลังทำงานอยู่ รายการฟีเจอร์ที่เขียนไว้ก่อนหน้าเพียงไม่กี่วันก็กลายเป็นการอธิบายผลิตภัณฑ์คนละตัวไปแล้ว

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

Arcane ใน v2.10.2 เป็นตัวแทน Portainer ที่ใช้งานได้จริงสำหรับผู้ดูแลระบบที่เหมาะสม มันมาพร้อม RBAC เต็มรูปแบบ, single sign-on แบบ OIDC, การสแกนช่องโหว่ด้วย Trivy และการ deploy ซ้ำแบบ GitOps โดยไม่มีค่าใช้จ่ายและไม่จำกัดจำนวนโหนด ส่วน Portainer เก็บลำดับชั้นบทบาทแบบนี้ไว้ใน Business Edition เมื่อเกินสามโหนด 4 จาก 5 สิ่งที่ฉุดรั้งมันไว้คืออายุที่ยังน้อย ไม่ใช่ความสามารถ

• ย้ายมาเมื่อคุณเกินโหนดที่สามของ Portainer และต้องการบทบาทที่กำหนดขอบเขตว่าใครแตะอะไรได้บ้าง คุณจะได้บทบาทในตัวหกแบบ บทบาทกำหนดเอง การมอบหมายตามแต่ละสภาพแวดล้อม และการจับคู่ group claim ของ OIDC โดยไม่ต้องจ่ายและไม่มีการนับโควตา
• การสแกนช่องโหว่มีมาให้ในตัว Arcane รัน Trivy ซึ่งเป็นตัวสแกนอิมเมจแบบโอเพนซอร์สตามตาราง cron และเก็บผลลัพธ์แยกตามอิมเมจ
• Portainer Business Edition ใช้ฟรีได้ถึงสามโหนดโดยไม่จำกัดฟีเจอร์ ต่ำกว่าเส้นนี้คุณมี RBAC และ SSO อยู่แล้ว ดังนั้นข้อโต้แย้งเรื่องการเข้าถึงฟรีของ Arcane จึงอ่อนลงมาก
• ยังไม่มีการนำเข้า stack ของ Portainer โดยตรง v2.10.0 สามารถแปลงคอนเทนเนอร์ที่กำลังทำงานอยู่เป็นโปรเจกต์ Compose ได้ในระดับทดลอง ซึ่งช่วยลดงานที่ต้องทำเองลงบ้าง แต่คุณยังต้องตรวจ YAML ที่สร้างขึ้นและวางแผนการตัดย้าย เพราะชื่อและพอร์ตที่เปิดออกไปอาจชนกันตราบใดที่ตัวต้นฉบับยังทำงานอยู่ สำรองข้อมูล volume ก่อน
• เสริมความปลอดภัยให้ ENCRYPTION_KEY ก่อนขึ้น production และตั้งค่า APP_URL ให้ถูกต้อง ENCRYPTION_KEY ยังมีค่าเริ่มต้นสำหรับการพัฒนาอยู่ และการเข้าสู่ระบบด้วย passkey จะไม่ทำงานจนกว่า APP_URL จะชี้ไปยังชื่อโฮสต์ HTTPS ที่ผู้ใช้เข้าจริง JWT_SECRET ไม่ได้ใช้แล้ว ตามเอกสารการติดตั้งฉบับปัจจุบัน
• บั๊ก GitOps ที่ทำให้ดิสก์เต็มซึ่งถูกรายงานใน v2.8.0 และ v2.9.0 ได้รับการแก้ไขแล้วใน v2.10.0 การแก้ไขนี้จะล้างไดเรกทอรีชั่วคราวของการโคลน Git ที่ตกค้างแทนที่จะปล่อยให้สะสมบนโฮสต์ของตัวจัดการ
• ยังไม่มี LDAP การเชื่อมต่อระบบยืนยันตัวตนรองรับเฉพาะ OIDC

การประเมินนี้จัดทำอย่างไร: นี่คือรีวิวจากหลักฐาน ไม่ใช่การทดสอบใช้งานจริง ไม่มีผู้สนับสนุน ไม่มีค่าตอบแทน ไม่มีผลิตภัณฑ์ที่ได้รับมา และไม่มีการติดต่อกับผู้ดูแลโปรเจกต์ ทุกข้อกล่าวอ้างเรื่องความสามารถได้ตรวจสอบกับเอกสารและบันทึกรุ่นปัจจุบันของ Arcane และทุกข้อกล่าวอ้างเรื่องความน่าเชื่อถือสืบย้อนได้ถึง issue ที่ระบุวันที่ในระบบติดตามสาธารณะของโปรเจกต์ หรือผู้ดูแลระบบที่ระบุชื่อซึ่งเขียนถึงการติดตั้งของตัวเอง ไม่มีใครในทีมรัน Arcane เพื่อเขียนบทความนี้ ดังนั้นในจุดที่ข้อจำกัดนี้มีผลต่อการประเมิน (ความรู้สึกในการใช้อินเทอร์เฟซ การรับมือกับโหลดต่อเนื่อง) บทความจะบอกตรง ๆ แทนการเดา

Arcane ให้อะไรฟรีที่ Portainer ไม่ให้?

หลัก ๆ คือสิ่งเดียว: การควบคุมการเข้าถึงตามบทบาทแบบเต็มรูปแบบ Portainer CE ให้การจัดการผู้ใช้ขั้นพื้นฐาน ส่วนลำดับชั้นบทบาทอยู่ใน Business Edition Arcane ให้สิ่งนี้ฟรีไม่ว่าจะมีกี่โหนด พร้อมกับการสแกน Trivy, การ deploy ซ้ำแบบ GitOps, การรองรับ Swarm, การเข้าสู่ระบบด้วย passkey, agent ระยะไกล และการสำรองข้อมูลไปยัง S3 ที่เพิ่มเข้ามาใน v2.9.0

RBAC คือส่วนที่ควรพิจารณาอย่างละเอียด เพราะคำว่า "มี RBAC" ครอบคลุมสิ่งที่แตกต่างกันมาก เอกสารการควบคุมการเข้าถึงของ Arcane อธิบายบทบาทในตัวที่แก้ไขไม่ได้หกแบบ: Admin, Editor, No-Shell Editor, Deployer, Monitor และ Viewer คุณสามารถโคลนบทบาทใดก็ได้ไปเป็นบทบาทกำหนดเองและติ๊กสิทธิ์ทีละรายการ ซึ่งอยู่ในรูปแบบ <resource>:<action> เช่น containers:startการมอบหมายเป็นได้ทั้งแบบทั่วทั้งระบบหรือแยกตามสภาพแวดล้อม และผู้ใช้หนึ่งคนถือได้หลายบทบาทพร้อมกัน เอกสารยกตัวอย่างไว้ตรง ๆ ว่า: เป็น Editor บน prod และเป็น Viewer บน staging.

ส่วนที่สำคัญสำหรับการนำ SSO มาใช้คือ การมอบหมายบทบาทสามารถขับเคลื่อนจากผู้ให้บริการยืนยันตัวตนได้โดยตรง: "ทุกครั้งที่เข้าสู่ระบบ Arcane จะอ่าน group claim ของผู้ใช้และซิงก์การมอบหมายที่มาจาก OIDC ใหม่" และผู้ใช้ที่อยู่ในหลายกลุ่มที่จับคู่ไว้จะได้รับสิทธิ์รวมของทุกกลุ่ม นี่คือโมเดลสิทธิ์ที่ Portainer CE ไม่เคยมี

การสแกนช่องโหว่คือส่วนที่สอง เอกสารการสแกนของ Arcane ระบุว่า "การสแกนเป็นแบบเลือกเปิดใช้ ทำงานตามตาราง cron และผลลัพธ์จะถูกเก็บแยกตามอิมเมจ" โดยผลลัพธ์จะแสดงใน UI ค่าเริ่มต้นคือทุกวันตอนเที่ยงคืน trivyIgnoreUnfixed จะกรองผลลัพธ์ให้เหลือเฉพาะช่องโหว่ที่มีวิธีแก้แล้ว และ Trivy มาในอิมเมจเครื่องมือที่ล็อกเวอร์ชันไว้ ดังนั้นการอัปเดตตัวสแกนจึงไม่ใช่ภาระของคุณ

ทีนี้มาถึงน้ำหนักฝั่งตรงข้าม และมันหนักไม่น้อย หน้าเปรียบเทียบ CE กับ BE ของ Portainer เอง ระบุว่า Business Edition "ฟรีตลอดไปสำหรับไม่เกิน 3 โหนด ไม่มีช่วงทดลอง ไม่ต้องใช้บัตรเครดิต ไม่จำกัดฟีเจอร์" นั่นคือชุดฟีเจอร์ BE แบบเต็ม: RBAC พร้อมลำดับชั้นบทบาทของตัวเอง, OIDC, บันทึกการตรวจสอบพร้อมส่งออกไป Syslog และ GitOps ขั้นสูง ข้อกำหนดของโปรแกรม Take 3 ออกไลเซนส์หนึ่งปีที่ต่ออายุได้ทุกปีโดยไม่มีค่าใช้จ่าย ตราบใดที่คุณยังมีสามโหนดหรือน้อยกว่า

ดังนั้นการคำนวณของแพ็กเกจฟรีจะเริ่มเข้าข้าง Arcane ก็ต่อเมื่อถึงโหนดที่สี่ ต่ำกว่านั้นไม่มีกำแพงจ่ายเงินอยู่เลย Arcane ยังมีอะไรให้อยู่บ้างที่หนึ่งหรือสองโหนด: ไม่ต้องมีคีย์ไลเซนส์ ไม่ต้องจำวันต่ออายุ และเป็นโปรเจกต์ที่คุณ fork ได้ แต่นั่นไม่ใช่ข้อโต้แย้งเดียวกับ "RBAC ต้องเสียเงิน"

Arcane เป็นหนึ่งในสี่เครื่องมือที่แข่งขันชิงตำแหน่งแทน Portainer อย่างจริงจัง และอีกสามตัวแยกกันไปตามแนวทางที่ต่างออกไป

อ่าน

ทางเลือกแทน Portainer: คู่มือเลือกใช้ Dockge, Arcane, Dockhand และ Komodo ตามกรณีใช้งาน

ตอนนี้ Arcane เชื่อถือได้แค่ไหน?

ดีกว่าที่เห็นใน v2.9.0 แต่ยังอายุน้อย ประวัติบั๊กของ Arcane อ่านแล้วเหมือนโปรเจกต์ที่กระตือรือร้นและแก้ปัญหาอยู่ตลอด และบั๊ก GitOps ร้ายแรงที่ทำให้ดิสก์เต็มซึ่งถูกรายงานใน v2.8.0 และ v2.9.0 ได้รับการแก้ไขใน v2.10.0 เมื่อวันที่ 31 สิงหาคม 2026

ผู้ดูแลระบบรายหนึ่งรายงานเมื่อวันที่ 26 สิงหาคม 2026 ว่า การซิงก์ GitOps ทำให้ไดเรกทอรีโคลนรั่วไหล: "gitops-<N> ไดเรกทอรีโคลนสะสมประมาณ 1,000 รายการต่อวัน (~9 GB/วัน) และไม่เคยถูกล้าง จนสุดท้ายดิสก์เต็ม" หกวันของสภาพแบบนั้นรวมได้ประมาณ 6,467 ไดเรกทอรีและ 40 GB เมื่อดิสก์เต็ม ตัวจัดการก็เขียนลงฐานข้อมูล SQLite ไม่ได้อีกต่อไปและเข้าสู่วงจรรีสตาร์ตซ้ำ ๆ จนนับได้ 389 ครั้ง และดึงการเชื่อมต่อของ edge agent กับการเรียก API ล่มตามไปด้วย issue นี้ปิดแล้ว และ v2.10.0 มาพร้อมการแก้ไขที่ล้างไดเรกทอรีชั่วคราวของการโคลน Git ที่ตกค้าง

หากคุณยังใช้ v2.8.0 หรือ v2.9.0 อยู่: อัปเกรดก่อนที่จะพึ่งพาการซิงก์ GitOps ถี่ ๆ การแก้ไขปัญหาโคลนรั่วไหลมาใน v2.10.0

ประวัติที่เก่ากว่านั้นน่าให้กำลังใจมากกว่า อาการค้างหลังอัปเดตระหว่าง 2.0 กับ 2.0.1 ได้รับการแก้ไขแล้ว บั๊กที่ "Update Projects" ไปกระทบทุกคอนเทนเนอร์ บนโฮสต์แทนที่จะเป็นเฉพาะของโปรเจกต์ที่เลือก ถูกปิดด้วย PR แก้ไข #2289 ที่ merge แล้ว การ polling อิมเมจที่ไม่ทำงานเงียบ ๆ ใน v1.13.2 ได้รับการแก้ไขใน v1.14.0 สามบั๊ก สามการแก้ไข

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

มุมมองของผมยังคงเป็นว่านี่คือปัญหาเรื่องอายุ ไม่ใช่ปัญหาเรื่องความสามารถ การออกรุ่นเร็วคือเหตุผลที่ช่องว่างเรื่อง RBAC และการสแกนถูกปิดลงได้ และก็เป็นเหตุผลเดียวกับที่ v2.10.0 ต้องแก้ข้อบกพร่องร้ายแรงของ GitOps ไม่ถึงสัปดาห์หลัง v2.9.0 โค้ดใหม่คือที่ที่ความเสี่ยงอยู่ และการรับมันมาใช้เป็นทางเลือก

การย้ายจาก Portainer มีต้นทุนจริง ๆ เท่าไร?

คร่าว ๆ คือช่วงหยุดให้บริการหนึ่งช่วงกับการเก็บกวาดด้วยมืออีกเล็กน้อย Arcane ยังไม่มีการนำเข้า stack ของ Portainer โดยตรง แต่ v2.10.0 เพิ่มการทำงานทดลอง Convert to Compose สำหรับคอนเทนเนอร์ที่กำลังทำงานอยู่ มันจะสร้างไฟล์ Compose ขณะที่ตัวต้นฉบับยังทำงานต่อ ซึ่งตัดงานสร้าง YAML ใหม่ออกไปได้ส่วนหนึ่ง คุณยังต้องตรวจ bind mount, เครือข่าย, ค่าสภาพแวดล้อม และการตัดย้ายเอง ชื่อและพอร์ตที่เปิดออกไปอาจชนกันจนกว่าตัวต้นฉบับจะถูกหยุด ดังนั้นนี่ไม่ใช่ปุ่มย้ายแบบไม่มีดาวน์ไทม์

ก่อน v2.10.0 บอร์ดของโปรเจกต์เองสะท้อนเส้นทางที่ต้องทำเองทั้งหมด ผู้ดูแลระบบรายหนึ่งที่มีคอนเทนเนอร์มากกว่า 80 ตัวบนห้าเซิร์ฟเวอร์ ถามว่าย้ายแบบสด ๆ ได้หรือไม่ โดยไม่ต้องปิดบริการที่เปิดสู่เว็บก่อน คำตอบจากคนที่ทำมาแล้วคือ: "คุณจะไม่มีทางเลือกนอกจากลบคอนเทนเนอร์ที่มีอยู่ (และ stack ของ Portainer ไปด้วย) แล้วสร้างใหม่ตั้งแต่ต้นใน Arcane" ลำดับของเขาคือ ปิดอย่างเรียบร้อย สำรองข้อมูล ลบ คัดลอกข้อมูลข้ามไป สร้างใหม่และ deploy ใหม่

ในทางปฏิบัติ: สำรอง volume ก่อนแตะอะไรทั้งนั้น และกำหนดช่วงบำรุงรักษาให้ยาวตามทั้งจำนวน stack ที่คุณรันและปริมาณข้อมูลที่ต้องย้าย การสร้างคอนเทนเนอร์ใหม่มักเป็นส่วนที่เร็ว ส่วนการคัดลอก volume ขนาดใหญ่และการนำบริการที่พึ่งพากันกลับมาตามลำดับที่ถูกต้องอาจยืดเวลาออกไป หมายเหตุเรื่องคำศัพท์ระหว่างวางแผน: สิ่งที่ Portainer เรียกว่า stack นั้น Arcane เรียกว่าโปรเจกต์

ต้นทุนด้านเวลาเกิดขึ้นแม้ในระดับ homelab Moises Aguirre ซึ่งเขียนเมื่อวันที่ 28 กุมภาพันธ์ 2026 เกี่ยวกับ การย้าย homelab ออกจาก Portainerเรียกมันว่า "งานเต็มสุดสัปดาห์ (และการเผชิญหน้ากับปีศาจของตัวเอง)" และปีศาจที่ว่าก็คือความหละหลวมของเขาเอง: เขาต้องตรวจสอบทุกคอนเทนเนอร์ที่รันอยู่และเขียน YAML ให้บริการที่ก่อนหน้านี้ "แค่คลิกให้มันเกิดขึ้นมา" นั่นคือประสบการณ์ของเขามากกว่าจะเป็นกฎ แต่รูปแบบเดียวกันเกิดขึ้นกับคนอื่นได้

มีสิ่งหนึ่งที่ควรจับให้ได้ก่อนย้ายไฟล์ Compose ข้ามมา บันทึกรุ่นของ v2.7.0 จำกัดแหล่งที่มาของการแปลงค่าตัวแปรให้เหลือสี่แหล่ง: ตัวแปรส่วนกลางของคุณใน .env.globalไฟล์ .env ของโปรเจกต์เอง ค่าเริ่มต้นที่เขียนไว้ในไฟล์ compose เอง และเขตเวลากับ locale จากสภาพแวดล้อมของ Arcane ผลที่ระบุไว้คือโปรเจกต์ที่ deploy ผ่าน Arcane จะแปลงค่าตัวแปรแบบเดียวกับที่ docker compose up ทำในไดเรกทอรีโปรเจกต์ นั่นเป็นพฤติกรรมที่ถูกต้องกว่า แต่ก็หมายความว่าอะไรก็ตามที่เคยรับค่ามาเงียบ ๆ จากสภาพแวดล้อมคอนเทนเนอร์ของตัวจัดการเอง ตอนนี้จะกลายเป็นค่าอื่นหรือไม่มีค่าเลย และมันจะเป็นแบบนั้นโดยไม่แจ้งเตือนอะไรทั้งสิ้น

ไม่มีอะไรในนี้ที่เป็นข้อบกพร่องของผลิตภัณฑ์ มันคือต้นทุนครั้งเดียวที่คาดการณ์ได้พอจะวางแผนล่วงหน้า ซึ่งเป็นสิ่งสำคัญที่สุดที่คุณต้องการจากการย้ายระบบ

พัฒนาบน Linux VPS พร้อมสิทธิ์รูท, NVMe และพลัง AMD EPYC

ดูแพ็กเกจ Linux

ต้องเสริมความปลอดภัยอะไรบ้างก่อนขึ้น production?

คีย์เข้ารหัสหนึ่งตัว URL สาธารณะ และ TLS Arcane สร้างบัญชีผู้ดูแลระบบเริ่มต้นเมื่อรันครั้งแรกและบังคับเปลี่ยนรหัสผ่านเมื่อเข้าสู่ระบบครั้งแรก ซึ่งเป็นค่าเริ่มต้นที่สมเหตุสมผล มีสองค่าที่ต้องตั้งให้ถูกก่อนขึ้น production ค่าแรกคือ ENCRYPTION_KEYค่าที่สองคือ APP_URL.

เอกสารอ้างอิงตัวแปรสภาพแวดล้อม ยังระบุ ENCRYPTION_KEY ด้วยค่าเริ่มต้นเป็น arcane-dev-key-32-characters!!!ขณะที่เอกสารการติดตั้งบอกให้คุณกำหนดค่าเฉพาะขนาด 32 ไบต์ เปลี่ยนมันก่อนขึ้น production อีกอย่างที่เปลี่ยนไปคือ ตอนนี้เอกสารการติดตั้งระบุว่า JWT_SECRET ไม่ได้ใช้แล้ว Arcane สร้างคีย์สำหรับลงนามเซสชันเองแล้ว การปล่อย JWT_SECRET ตั้งค่าทิ้งไว้จะมีเพียงคำเตือนตอนเริ่มทำงาน ดังนั้นให้ลบออกจากสภาพแวดล้อม เอกสารการติดตั้ง ระบุว่า ENCRYPTION_KEY "ต้องมีความยาว 32 ไบต์ (แบบดิบ base64 หรือ hex)"

สุขอนามัยของเวอร์ชันก็อยู่ในรายการตรวจสอบนั้นด้วย Arcane เผยแพร่ประกาศด้านความปลอดภัยหลายฉบับในปี 2026 ประกาศระดับความรุนแรงสูงฉบับหนึ่งที่เผยแพร่เมื่อวันที่ 29 กรกฎาคม 2026 ระบุว่ารุ่นก่อน v2.5.0 ได้รับผลกระทบ และเปิดให้สิทธิ์ users:update ที่ถูกมอบหมายรีเซ็ตรหัสผ่านของผู้ดูแลระบบได้ ประกาศระบุ v2.6.0 เป็นรุ่นที่แก้ไขแล้ว ดังนั้น v2.10.0 จึงไม่ได้รับผลกระทบ แต่นี่คือเหตุผลที่จับต้องได้ว่าไม่ควรปล่อยระบบ production ค้างอยู่บนแท็กเก่า

APP_URL มีค่าเริ่มต้นเป็น http://localhost:3552และค่านี้มีผลในเชิงการทำงานที่มากกว่าแค่สุขอนามัย การเข้าสู่ระบบด้วย passkey และ MFA ด้วย passkey ต่างทำงานบน WebAuthn และ เอกสาร passkey ของ Arcane ระบุชัดเจนว่า: "เบราว์เซอร์จะเปิด WebAuthn API ให้ใช้เฉพาะในบริบทที่ปลอดภัยเท่านั้น ดังนั้น passkey จึงต้องใช้ HTTPS (หรือ localhost)" รหัสประจำตัวของ relying party มาจาก APP_URLpasskey จะผูกกับชื่อโฮสต์นั้น และถ้า APP_URL ไม่มีชื่อโฮสต์ บริการ passkey จะไม่เริ่มทำงาน บน HTTP ธรรมดา Arcane จะซ่อนตัวควบคุม passkey ไปทั้งหมด หาก deploy บน IP เปล่ากับพอร์ต ฟีเจอร์ยืนยันตัวตนตัวชูโรงของ v2 ก็จะไม่ปรากฏ เอกสารบอกไว้ตรง ๆ ว่า: "ตั้งค่า APP_URL เป็น URL ที่ผู้ใช้ของคุณเข้าจริงผ่าน HTTPS ก่อนที่ใครจะลงทะเบียน passkey"

agent ระยะไกลเป็นตัวกำหนดว่าคุณต้องเปิดอะไรบ้าง เอกสารเรื่องสภาพแวดล้อมของ Arcane ระบุว่าในโหมดตรง "Manager จะเชื่อมต่อไปยัง Agent ผ่าน TCP 3553" ดังนั้นพอร์ตนั้นต้องเข้าถึงได้จากภายนอกบนโฮสต์ระยะไกล ส่วนในโหมด edge "Agent จะเชื่อมต่อออกไปหา Manager" และไม่ต้องเปิดพอร์ตขาเข้าเลย

เกินกว่านั้นผมขอชี้ทางมากกว่าแสร้งว่ารู้ Arcane เผยแพร่ คู่มือการตั้งค่า socket proxy ซึ่งตั้งอยู่บนสมมติฐานว่าการ mount socket โดยตรง "ทำให้ Arcane เข้าถึง Docker ได้เต็มรูปแบบ" และ proxy จะจำกัดให้เหลือเฉพาะการเรียก API ที่จำเป็น นี่คือความเสี่ยงเดียวกับที่ทำให้ การแยก socket ของ Docker ออกมาเป็นเรื่องคุ้มค่า ในทุกที่ และคุ้มค่าที่จะทำที่นี่เช่นกัน ผมอ่านเอกสารเหล่านี้แบบที่ผู้ deploy อ่าน ไม่ใช่การตรวจสอบกลไก token

Arcane ยังทำอะไรไม่ได้บ้าง?

เมื่อเทียบกับเอกสารปัจจุบันของ Arcane ยังมีช่องว่างอยู่สองข้อ: ไม่มี LDAP และไม่มีตัวเรียกดูระบบไฟล์ของตัวคอนเทนเนอร์เองแบบทั่วไป ส่วนช่องว่างอื่น ๆ หลายข้อที่เคยมีก่อน v2 ถูกปิดไปแล้ว

ไม่มี LDAP เอกสาร single sign-on ของ Arcane ครอบคลุม OIDC และ OIDC เท่านั้น และทั้งเอกสารนี้กับหน้าการควบคุมการเข้าถึงต่างไม่กล่าวถึง LDAP หรือ Active Directory เลย Business Edition ของ Portainerในทางกลับกัน ผสานกับ "Active Directory, LDAP และผู้ให้บริการยืนยันตัวตนที่รองรับ OIDC" หากองค์กรของคุณยืนยันตัวตนกับไดเรกทอรีที่ไม่มีชั้น OIDC อยู่ข้างหน้า นี่คือทางตัน ไม่ใช่สิ่งที่หาทางอ้อมได้

ไม่มีตัวเรียกดูไฟล์ทั่วไปภายในคอนเทนเนอร์ มุมมองคอนเทนเนอร์ของ Arcane แสดงการตั้งค่า, mount, log และซอร์ส Compose แต่ไม่มีตัวเรียกดูระบบไฟล์ของตัวคอนเทนเนอร์เอง ตอนนี้มี Volume Workspace ที่เรียกดูและแก้ไขไฟล์ภายใน volume ของ Docker ได้แล้ว ดังนั้นช่องว่างที่เหลือจึงแคบกว่าคำอธิบายเดิมที่ว่า "ไม่มีตัวเรียกดูไฟล์"

การแก้ไขความเข้าใจเหล่านี้ควรพูดให้ชัด เพราะคำอธิบาย Arcane ว่า "ไม่มี RBAC ไม่มีการสแกนช่องโหว่" ไม่เป็นจริงอีกต่อไป RBAC มาพร้อมกับ v2.0.0 เมื่อวันที่ 7 มิถุนายน 2026และการสแกน Trivy มีเอกสารรองรับและทำงานตามตารางเวลา การบันทึกกิจกรรมก็พัฒนาไปเช่นกัน: เอกสารกิจกรรมของ Arcane อธิบาย Activity Center ที่ครอบคลุมการ pull, การ build, การกระทำในวงจรชีวิต, การสแกน และการ prune พร้อมกับบันทึกเหตุการณ์ที่ระบุระดับความรุนแรง ประเภท เวลา และผู้ใช้ที่เป็นผู้กระทำแต่ละรายการในกรณีที่ Arcane ระบุที่มาได้ ส่วนจะส่งออกไป Syslog แบบที่ระดับ Business ของ Portainer ทำได้หรือไม่ เอกสารไม่ได้ให้คำตอบ

สิ่งที่ความเร็วในการออกรุ่นแก้ไม่ได้คืออายุ repository ของ Arcane ถูกสร้างขึ้นในเดือนเมษายน 2025 ส่วน Portainer มีคำตอบใน Stack Overflow, คู่มือจากบุคคลที่สาม และการเชื่อมต่อต่าง ๆ ที่สะสมมาหลายปีหนุนหลัง และเมื่อคุณเจอเรื่องแปลก ๆ ตอนห้าทุ่ม ความต่างตรงนั้นแหละที่คุณจะรู้สึกได้

ใครควรย้ายมา Arcane และใครไม่ควร?

ย้ายมา Arcane หากคุณเกินสามโหนดบน Portainer และต้องการการเข้าถึงแบบหลายผู้ใช้ที่กำหนดขอบเขตได้ พร้อม Compose ที่ติดตามด้วย git โดยไม่ต้องคุยเรื่องไลเซนส์ อยู่ที่เดิมหากคุณมีสามโหนดหรือน้อยกว่า การนับจำนวนโฮสต์ตอบคำถามส่วนใหญ่ได้เร็วกว่ารายการฟีเจอร์ใด ๆ

สามกลุ่มที่ Arcane เป็นคำตอบชัดเจน:

• ผู้ดูแลระบบที่เกินเพดานสามโหนดของ Portainer และต้องการการเข้าถึงแบบกำหนดขอบเขต เกินสามโหนดไป ความสามารถเหล่านั้นมีราคาที่ Portainer แต่ฟรีที่ Arcane และบทบาทก็ละเอียดพอจะให้ใครสักคนเป็น Deployer ในสภาพแวดล้อมหนึ่งและเป็น Viewer ในที่อื่นทั้งหมด
• ผู้ดูแลระบบที่ต้องการให้ไฟล์ Compose เป็นแหล่งความจริงเพียงหนึ่งเดียว หากสิ่งที่ผลักดันการย้ายคือการที่นิยามของ stack อยู่ในฐานข้อมูลแทนที่จะอยู่ใน repo นั่นคือความเหมาะสมเชิงโครงสร้าง ไม่ใช่ความชอบส่วนตัว สุดสัปดาห์ของการย้ายส่วนใหญ่หมดไปกับการเขียนสิ่งที่คุณรันอยู่แล้วให้เป็นลายลักษณ์อักษร ซึ่งเป็นงานที่คุณติดค้างอยู่แล้ว
• ผู้ดูแลระบบที่รวมหลายโฮสต์เข้าด้วยกัน รวมถึงโฮสต์ที่อยู่หลัง NAT agent ในโหมด edge ไม่ต้องเปิดพอร์ตขาเข้าฝั่งระยะไกล คลัสเตอร์ Swarm จัดการได้จากโหนด manager และสภาพแวดล้อมระยะไกลไม่มีค่าใช้จ่าย

สองกลุ่มที่ไม่ใช่:

• ใครก็ตามที่มีสามโหนดหรือน้อยกว่า Business Edition ฟรีในขนาดนั้นพร้อมชุดฟีเจอร์เต็ม ดังนั้นการย้ายจึงเป็นการใช้ช่วงหยุดให้บริการและสุดสัปดาห์หนึ่งไปเพื่อให้ได้ความสามารถที่คุณมีอยู่แล้ว ในฐานะทางเลือกแทน Portainer Arcane ทำได้ดี แต่นั่นก็ยังไม่ใช่เหตุผลที่จะย้าย
• ใครก็ตามที่ต้องใช้ LDAP หรือหยุด stack ไม่ได้ ไม่มีการยืนยันตัวตนผ่านไดเรกทอรี และการย้ายยังต้องมีการตัดย้ายตามแผน ทั้งสองข้อไม่มีทางอ้อมที่ฉลาดพอ

มีเงื่อนไขหนึ่งข้อพ่วงมากับบทสรุปนี้ หากการ deploy ซ้ำแบบ GitOps คือเหตุผลหลักที่คุณย้าย ให้ใช้ v2.10.0 ขึ้นไป บั๊กที่ทำให้ดิสก์เต็มซึ่งถูกรายงานใน v2.8.0 และ v2.9.0 ได้รับการแก้ไขแล้วในรุ่นนั้น

อ่าน

วิธีติดตั้ง Docker บน VPS: คู่มือครอบคลุมการใช้ VPS สำหรับ Containerization🗂️

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