Cockpit อินเทอร์เฟซกราฟิกบนเว็บสำหรับเซิร์ฟเวอร์
(cockpit-project.org)- Cockpit เป็นอินเทอร์เฟซกราฟิกสำหรับจัดการเซิร์ฟเวอร์ Linux ผ่านเบราว์เซอร์ ช่วยให้ทั้งผู้เริ่มต้นและผู้ดูแลระบบมืออาชีพตรวจสอบสถานะและจัดการระบบแต่ละเครื่องได้อย่างรวดเร็ว
- ใช้ API และคำสั่งของระบบ แบบเดียวกับบรรทัดคำสั่ง จึงสามารถใช้ Cockpit, CLI, Ansible และเครื่องมือจัดการเซิร์ฟเวอร์เดิมร่วมกันได้โดยไม่ทำให้เวิร์กโฟลว์การดูแลระบบขัดแย้งกัน
- สามารถจัดการเครือข่าย, ไฟร์วอลล์, สตอเรจ RAID·LUKS, virtual machine, container, log, ฮาร์ดแวร์, update, performance, บัญชีผู้ใช้, บริการ systemd และ remote terminal ได้จากหน้าจอเดียว
- การยืนยันตัวตนพื้นฐานอิงตาม การล็อกอินและสิทธิ์ของผู้ใช้ปกติ ของระบบ รองรับ single-sign-on และวิธีการยืนยันตัวตนอื่น ๆ และจะรันผ่าน systemd socket activation เฉพาะเมื่อจำเป็นเท่านั้น
- หลังติดตั้งบน Linux distribution หลัก ๆ แล้ว สามารถใช้งานได้โดยเชื่อมต่อไปยัง พอร์ต 9090 ของเซิร์ฟเวอร์จากเบราว์เซอร์บนระบบปฏิบัติการต่าง ๆ รวมถึง Windows, MacOS และ Android
การจัดการเซิร์ฟเวอร์รายเครื่องผ่านเบราว์เซอร์
- Cockpit เป็นอินเทอร์เฟซกราฟิกแบบเว็บรวมศูนย์ที่สร้างมาสำหรับเซิร์ฟเวอร์
- กลุ่มผู้ใช้เป้าหมายมีความหลากหลาย
- ผู้เริ่มต้นใช้งาน Linux รวมถึงผู้ดูแลระบบ Windows
- ผู้ใช้ที่คุ้นเคยกับ Linux แต่ต้องการจัดการเซิร์ฟเวอร์ให้ง่ายขึ้นในรูปแบบกราฟิก
- ผู้ดูแลระบบมืออาชีพที่ใช้เครื่องมืออื่นเป็นหลัก แต่ต้องการดูภาพรวมของระบบแต่ละเครื่อง
- ออกแบบมาเพื่อให้จัดการระบบเดียวกันได้หลายวิธี มากกว่าการแทนที่วิธีดูแลระบบเดิม
- ใช้ Cockpit ร่วมกับ ยูทิลิตีบรรทัดคำสั่ง ได้
- ยังใช้ Ansible และเครื่องมือเดิมอื่น ๆ ต่อไปได้
- มี terminal ในตัว ซึ่งมีประโยชน์เมื่อเชื่อมต่อจากอุปกรณ์ที่ไม่ใช่ Linux
- แม้ไม่ต้องจำคำสั่ง Linux ก็สามารถดูสถานะเซิร์ฟเวอร์ในเว็บเบราว์เซอร์และทำงานด้วยเมาส์ได้
- เริ่ม container
- จัดการสตอเรจ
- ตั้งค่าเครือข่าย
- ตรวจสอบ log
- Cockpit สามารถมองได้เหมือน “อินเทอร์เฟซเดสก์ท็อป” แบบกราฟิกสำหรับเซิร์ฟเวอร์แต่ละเครื่อง
การยืนยันตัวตน การผสานรวม และการขยายความสามารถ
- Cockpit ใช้ API ที่มีอยู่แล้วในระบบ และไม่สร้างระบบย่อยใหม่หรือเพิ่มชั้นเครื่องมือของตัวเอง
- โดยค่าเริ่มต้นจะใช้ การล็อกอินและสิทธิ์ของผู้ใช้ปกติของระบบ
- การล็อกอินทั้งเครือข่ายรองรับผ่าน single-sign-on และเทคนิค การยืนยันตัวตน อื่น ๆ
- เมื่อไม่ได้ใช้งาน จะไม่รันอยู่เบื้องหลังตลอดเวลา แต่จะรันเมื่อจำเป็นผ่าน systemd socket activation
- งานที่ทำได้บนโฮสต์ Cockpit แต่ละเครื่องมีดังนี้
- ตรวจสอบและเปลี่ยนการตั้งค่าเครือข่าย
- ตั้งค่าไฟร์วอลล์
- จัดการสตอเรจ รวมถึงพาร์ทิชัน RAID และ LUKS
- สร้างและจัดการ virtual machine
- ดาวน์โหลดและรัน container
- สำรวจและค้นหา system log
- ตรวจสอบฮาร์ดแวร์ของระบบ
- อัปเกรดซอฟต์แวร์
- ตรวจสอบประสิทธิภาพ
- จัดการบัญชีผู้ใช้
- ตรวจสอบและโต้ตอบกับบริการที่อิงบน systemd
- ใช้ terminal ของเซิร์ฟเวอร์ระยะไกลจากเว็บเบราว์เซอร์ในเครื่อง
- สลับระหว่าง เซิร์ฟเวอร์ Cockpit หลายเครื่อง
- ขยายฟังก์ชันด้วยการติดตั้ง แอปและ add-on
- เขียน โมดูลแบบกำหนดเอง
- ใช้สำหรับแก้ปัญหาได้ด้วย
- วินิจฉัยปัญหาเครือข่าย
- ตรวจพบและรับมือกับ virtual machine ที่ทำงานผิดปกติ
- ตรวจสอบ log ของ SELinux และแก้ไขการละเมิดทั่วไปได้ด้วยการคลิกครั้งเดียว
- ตรวจสอบเมตริกโดยละเอียดที่เชื่อมโยง CPU load, การใช้หน่วยความจำ, กิจกรรมเครือข่าย และประสิทธิภาพสตอเรจกับ system journal
- รองรับ แอปพลิเคชันแบบเลือกติดตั้งและของบุคคลที่สาม
- ทดสอบและปรับการออกแบบผ่านการวิจัยด้าน usability และการเปลี่ยนแปลงโค้ดทั้งหมดต้องผ่านการทดสอบก่อน merge
- ใช้งานได้ฟรีและเผยแพร่ภายใต้ GNU LGPL
การติดตั้งและการเชื่อมต่อ
- ติดตั้งได้บน distribution หลัก ๆ และหลังรันแล้วสามารถเข้าถึงได้จากเว็บเบราว์เซอร์หลักบนระบบปฏิบัติการใดก็ได้
- รวมถึง Windows, MacOS และ Android
- หลัง ติดตั้งและเปิดใช้งาน ให้เชื่อมต่อไปยัง พอร์ต 9090 ของเซิร์ฟเวอร์
- จากเบราว์เซอร์บนเครื่องเดียวกัน สามารถเข้าได้ที่
https://localhost:9090/
- Cockpit มีรอบการออกรุ่นตามเวลา โดยเวอร์ชันใหม่จะออกทุก 2 สัปดาห์
2 ความคิดเห็น
Cockpit - เว็บอินเทอร์เฟซแบบรวมบนเว็บสำหรับจัดการเซิร์ฟเวอร์ Linux
ความคิดเห็นจาก Hacker News
การด่าว่าอินเทอร์เฟซจัดการแบบกราฟิกแล้วชอบแต่ command line นั้นค่อนข้างเป็นท่าทีแบบ เห็นแต่ต้นไม้ไม่เห็นป่า
การดูแลเซิร์ฟเวอร์ด้วยการคลิกไม่ใช่วิธีที่ดี แต่พูดตรง ๆ แล้ว
sshในฐานะวิธีปฏิบัติการก็ไม่ต่างกันสถานะของเซิร์ฟเวอร์ production จริงควรทำซ้ำได้ตั้งแต่ต้น และหลังจากติดตั้ง OS เพิ่มซอฟต์แวร์ และปรับใช้การตั้งค่าแล้วก็ควรปล่อยไว้ไม่ไปแตะ
ไม่ว่าจะเป็น
sshหรือ Cockpit ถ้าเข้าไปจัดการโดยตรงก็มีโอกาสสูงที่จะทำอะไรพังเหตุผลเดียวที่ควรเข้าเซิร์ฟเวอร์โดยตรงคือเมื่อทำงานเชิงสำรวจ และตอนนั้นความเหนือกว่าระหว่าง GUI กับ command line ก็ไม่ได้ชัดเจนขนาดนั้น
GUI มี discoverability และการมองเห็นที่ดีกว่า จึงช่วยได้ในขั้นทดลองเพื่อหาวิธีตั้งค่า
ต้องอธิบายว่าทำไมสถานะเซิร์ฟเวอร์ถึงต้องทำซ้ำได้ตั้งแต่ต้น, “ตั้งแต่ต้น” หมายถึงอะไร, และทำไมการคลิกถึงใช้ไม่ได้
จะบอกว่าสถานะเซิร์ฟเวอร์ถูกเก็บครบถ้วนด้วยแค่การติดตั้ง OS เพิ่มซอฟต์แวร์ และปรับใช้การตั้งค่าก็คงยาก
ระดับแพตช์ของซอฟต์แวร์ ข้อมูลแอปพลิเคชัน และข้อมูลผู้ใช้ก็เป็นส่วนหนึ่งของสถานะเซิร์ฟเวอร์ด้วย
สถานะของเซิร์ฟเวอร์ production สามารถทำซ้ำได้อย่างแม่นยำด้วยการกู้คืนจากแบ็กอัป และการแบ็กอัป/กู้คืนก็เข้ากันได้ดีกับการจัดการแบบคลิก ทั้งยังอาจเร็วและน่าเชื่อถือกว่าการติดตั้ง OS ใหม่กับสคริปต์ตั้งค่า
หากเป็นเซิร์ฟเวอร์ที่เก็บข้อมูลแบบ non-volatile หลัง deploy เซิร์ฟเวอร์ใหม่แล้วก็ยังต้องมี ระบบแบ็กอัป อยู่ดีเพื่อกู้คืนข้อมูลผู้ใช้
ไม่ใช่ทุกคนจะรันเว็บแพลตฟอร์มขนาดใหญ่บนแพลตฟอร์ม orchestration
อย่างไรก็ตาม แม้จะเป็นเซิร์ฟเวอร์แบบสัตว์เลี้ยง ก็ควรรู้วิธีกู้คืนหรือสร้างใหม่ ไม่เช่นนั้นก็เท่ากับไม่มีแผน disaster recovery ที่เหมาะสม
ใน homelab ใช้ Ansible ตั้งค่า Raspberry Pi อยู่ ส่วนการติดตั้ง OS ดูเหมือนทำได้ด้วยการคัดลอกอิมเมจลง boot media แบบ bit-for-bit แล้วปรับค่าบางอย่าง
ผมชอบทำงานในเทอร์มินัล แต่คิดว่าเรื่อง visualization นั้น GUI ดีกว่าอย่างไม่มีข้อถกเถียงด้วยซ้ำ
จุดเจ๋งของโปรเจกต์นี้คือใช้ systemd socket activation จึงไม่จำเป็นต้องมี server process ที่รันตลอดเวลา
เมื่อไม่ได้ใช้ Cockpit ก็ไม่เปลืองทรัพยากร และการเข้าหน้าก็แทบเหมือนกับการรันเครื่องมือ command line แล้วปิดไป
การออกแบบสวยงามจริง ๆ
inetdของ BSD4.3 แล้วรายละเอียดการทำงานต่างกัน แต่ไอเดียใหญ่เหมือนกัน และครั้งหนึ่งเคยได้รับความนิยม ก่อนจะตกยุคไปโดยไม่มีเหตุผลพิเศษ
server process ที่ดีควร idle เมื่อไม่มีอะไรเกิดขึ้น และใช้หน่วยความจำจริงน้อยมากจน swap out ได้ง่าย
ถ้าเซิร์ฟเวอร์บางตัวโดยลักษณะงานต้องใช้หน่วยความจำมากอยู่แล้ว ก็คงไม่อยากให้การเริ่มแบบ on-demand ทำให้เกิด memory pressure เป็นครั้งคราว
อย่างไรก็ตาม มันช่วยเรื่องประสิทธิภาพการบูต เพราะหลีกเลี่ยงปัญหาที่ต้องรอให้บริการเริ่มตอนบูตได้ง่ายขึ้น
จนกว่าจะมีคนเชื่อมต่อผ่าน SSH กระบวนการ
sshdจะยังไม่เริ่มhttps://discourse.ubuntu.com/t/sshd-now-uses-socket-based-ac...
ยิ่งดูข้างในก็ยิ่งเจอฟีเจอร์เจ๋งและมีประโยชน์ออกมาเรื่อย ๆ
เหมาะที่จะติดตั้งไว้บน Raspberry Pi เครื่องเล็ก ๆ
มีประโยชน์มากเวลาที่ไม่ได้อยู่หน้าเทอร์มินัล แต่อยากกวาดดูสถานะ หรือในสถานการณ์ที่มีแค่เว็บเบราว์เซอร์ ก็สามารถเชื่อมต่อ SSH ผ่านเว็บเซิร์ฟเวอร์ได้แทบเหมือน native แล้วรัน
curl ...etc...ในพรอมป์คำสั่งจริงได้อยากรู้ว่า systemd socket activation หมายถึงจะถูกใช้เฉพาะตอนเว็บไคลเอนต์ของผู้ใช้ปลายทางส่งคำขอ REST/GQL อย่างการดู log เท่านั้นหรือเปล่า
“porcelain” มีคุณค่า
เคยเห็นสตาร์ทอัปที่มี backend สำเร็จรูปอยู่แล้ว แต่ไม่สามารถผลักดันการพัฒนาผลิตภัณฑ์ไปถึง UI/UX ได้จนต้องพับไป
ที่บริษัทหนึ่ง ผมแสดงให้เห็นว่า backend ที่เป็น container orchestrator แบบ custom ทั้งหมดสามารถแทนที่ด้วย AWS Lambda และ ECS ได้ภายในสุดสัปดาห์เดียว แต่เครื่องมือ UI/UX และ workflow จะใช้เวลานานกว่านั้นมาก
แต่ถึงอย่างนั้นก็ยังเสียเงินและเวลาไปกับการสร้าง “คลัสเตอร์แบบใหม่ที่ใช้ Raft” ต่อไป
ระหว่างนั้นผมได้รับงาน “เพิ่ม batch processing” และเพราะใช้งาน Go อยู่แล้ว จึงต่อ Nomad เข้าไปภายในแล้วผ่านไปได้
การได้ทำงานใน ทีมที่ปล่อยฟีเจอร์ออกสู่ผู้ใช้ ไม่ใช่แค่เทคโนโลยีเพื่อเทคโนโลยี เป็นเรื่องดี
https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Po...
เครื่องมือทุกตัวในสายนี้ควรมีแบนเนอร์ขนาดยักษ์ว่า “พื้นที่ดิสก์ไม่พอ”
แม้แต่คนที่ดีบักเซิร์ฟเวอร์ บางทีก็ไม่ถือว่านี่เป็นความรู้พื้นฐานอย่างน่าประหลาด
ปี 2022, 81 ความคิดเห็น: https://news.ycombinator.com/item?id=31439811
ปี 2021, 128 ความคิดเห็น: https://news.ycombinator.com/item?id=26197510
ปี 2018, 149 ความคิดเห็น: https://news.ycombinator.com/item?id=16445612
คงไม่น่าจะใช้สิ่งนี้
มันเพิ่มพอร์ตที่เปิดอยู่หนึ่งพอร์ต เพิ่มพื้นผิวโจมตีอีกจุดให้บอตที่สแกนช่องโหว่ไม่หยุด และเพิ่มบริการอีกตัวที่ต้องคอยอัปเดตให้เป็นเวอร์ชันล่าสุดตลอดเวลา
แต่ก็น่าจะช่วยให้ Linux server เข้าถึงได้ง่ายขึ้น
โดยเฉพาะมีประโยชน์กับคนที่ย้ายจาก shared hosting แบบ PHP ไปเป็น VPS เต็มรูปแบบ แต่ไม่ได้มีความรู้เรื่องเซิร์ฟเวอร์มากนัก และต้องการอะไรอย่าง cPanel หรือ DirectAdmin
ไม่แน่ใจว่าทั้งสองอย่างต่างกันอย่างไร
เป็น RHCE ตัวจริง แต่เธรดนี้ให้ความรู้สึกเหมือนเป็น click farm ฝั่ง Red Hat จนบรรยากาศเชิงบวกดูประดิษฐ์มาก
Cockpit ก็พอใช้ได้ แต่โดยพื้นฐานแล้วใกล้เคียงกับ Windows Server Manager เวอร์ชันของ Red Hat และมีความเป็นไปได้สูงว่าได้รับอิทธิพลโดยตรงจาก Server Manager
ตลอดหลายปีที่ผ่านมา ความเร็วในการพัฒนาและปรับปรุงก็ช้าจนทรมาน
คนที่คุ้นกับ SSH session จะไม่ใช้ Cockpit ยกเว้นประมาณตอนสร้าง VM ใหม่ และการเอาไปเทียบกับ Proxmox นั้นไม่สมเหตุสมผล
มันไม่มีแม้แต่หนึ่งในสี่ของฟีเจอร์ UI ของ Proxmox และฟีเจอร์จัดการ VM ก็เพิ่งเข้ามาค่อนข้างไม่นาน อีกทั้งเพราะความหน่วงและข้อจำกัดจากการผ่านเบราว์เซอร์ Virtual Machine Manager ก็ยังดีกว่าอยู่ดี
มีหลายอย่างที่ทำด้วย Cockpit ไม่ได้ และต่อไปก็ยังมีอีกหลายอย่างที่จะทำไม่ได้
มันใกล้เคียงกับเครื่องมือสำหรับคนที่อยากคลิก ใช้ลูป Bash
for/whileไม่เป็น ไม่เข้าใจการ chain pipe และไม่ชอบvimพูดอีกอย่างคือมันคือ webmin สำหรับ Red Hat แม้จะดูเท่อยู่บ้าง แต่เก่าเกินไป พัฒนาช้า และถูกอวยเกินจริง จนไม่เคยใช้เลยนอกจากสิ่งที่จำเป็นสำหรับการสอบ certification
ดังนั้นมันก็เป็นคำพูดที่ถูกอยู่เหมือนกัน
ถ้ากังวลเรื่องการใช้ในทางที่ผิด ให้ส่งอีเมลไปที่ hn@ycombinator.com แล้วเขาจะดูข้อมูลให้
https://news.ycombinator.com/newsguidelines.html
ผมรันกล้อง Raspberry Pi หลายตัวที่ติดโมดูลกล้องดีกว่าเดิมไว้ดูสัตว์เลี้ยงตอนครอบครัวเดินทาง
สตรีมกล้อง RTSP รันเป็น systemd unit บนแต่ละเครื่อง และ healthcheck ที่ตรวจว่ามีการสตรีมแพ็กเก็ตอยู่หรือไม่ก็แยกเป็น systemd unit อีกตัว
กล้องแต่ละตัวได้รับ IP ส่วนตัวบนเครือข่าย ZeroTier ที่ผมดูแลอยู่
Cockpit จะทำงานเฉพาะเวลาที่ต้องใช้ จึงไม่มีเหตุผลที่จะไม่ติดตั้งไว้เพื่อการดูแลระบบ
บางครั้งกล้องตัวหนึ่งเริ่มส่งออกมาแต่เฟรมว่าง ๆ และการจัดการผ่านเว็บอินเทอร์เฟซ Cockpit บนมือถือย่อมดีกว่ามากเมื่อเทียบกับการต้องไปหาคีย์บอร์ดตอนพักร้อน เข้า SSH แล้วรีสตาร์ต stream unit
จะทำ healthcheck สำหรับตรวจจับเฟรมว่างก็ได้ แต่สำหรับเรื่องที่เกิดแค่ไม่กี่ครั้งต่อปี การรีสตาร์ตจาก Cockpit ง่ายกว่าการเขียนสิ่งนั้นมาก
เข้าถึงได้จากทุกแพลตฟอร์มรวมถึง iPad และแทบไม่ต้องตั้งค่าอะไรนอกจากติดตั้งแพ็กเกจและเพิ่ม certificate
ใช้ Cockpit แทน Proxmox บน Debian server ที่รัน VM เพราะมันรุกรานระบบน้อยกว่ามาก และเครื่องเหล่านั้นยังทำงานอื่นอย่าง Docker container ด้วย
ใช้เพื่อจุดประสงค์นี้มาตั้งแต่ราวปี 2019
หน้าสถิติก็มีประโยชน์ แต่คงไม่ติดตั้งเพราะแค่สิ่งนั้นอย่างเดียว
แทบไม่มีตัวเลือกอื่นที่ดูแลรักษาดี ซึ่งทำให้สร้าง libvirt VM บนเครื่องเดี่ยวจากเว็บเบราว์เซอร์ได้ โดยไม่เข้าครอบงำทั้งระบบ
ใช้ได้กับ NetworkManager เท่านั้น แต่พอการตั้งค่าเครือข่ายสำหรับ VM ซับซ้อนขึ้นนิดหน่อย ปกติก็ต้องปิด NetworkManager ทำให้ Cockpit แทบใช้ไม่ได้จริง
สำหรับคนที่อยากจัดการ VM ด้วย GUI, virt-manager ทรงพลังกว่ามาก
[1] https://virt-manager.org/
คุณภาพอยู่ระดับ “พอใช้ได้”
อาจใช้ได้กับงานเฉพาะทางเล็ก ๆ บางอย่าง แต่ถ้ารัน homeserver ผมจะหลีกเลี่ยง
ปลั๊กอินอินเทอร์เฟซ file server ของ Cockpit เก่าและไม่ดี
ไม่ค่อยแน่ใจว่าจะเอาไปใช้กับอะไร การมอนิเตอร์ง่าย ๆ อาจพอทำได้ แต่ในฐานะเครื่องมือจัดการถือว่าไม่ค่อยดี
ไม่เข้าใจว่าทำไม Red Hat ถึงผลักดันโปรเจกต์นี้ และมันไม่มี use case ที่ใช้งานจริงมากนัก
การแสดงรายการ systemd service ไม่ได้ช่วยมากไปกว่าการดูทั้งหมดจากเอาต์พุตบน command line
เมื่อโฮสต์ NAS เอง ผมมองว่า Cockpit ดีกว่า OMV มาก
OMV มีปลั๊กอิน Docker ที่รองรับ Compose จึงไม่ต้องมี Docker GUI แยกอย่าง Portainer และการแชร์ SMB กับไคลเอนต์ Windows ก็ดูจะเสถียรกว่า
มี GUI และแนวทางที่เป็นมิตรกับมือใหม่ ทำให้แชร์ให้ผู้ใช้อื่นใช้ได้ง่าย และยังมีฟีเจอร์ที่รวมมาให้พื้นฐานอย่าง fail2ban กับ WireGuard
Cockpit เป็นพลเมืองชั้นหนึ่งบนดิสโทร EL/Fedora และรองรับ Podman แต่ไม่ใช่ Docker อีกทั้งยังไม่รองรับ Compose/Quadlet
มีฟีเจอร์ทรงพลังอย่างการจัดการ VM และเทอร์มินัล แต่มีบั๊กเกี่ยวกับ Samba
ตอนนี้ใช้ OMV สำหรับแชร์ไฟล์ในเครือข่ายภายในและรันคอนเทนเนอร์ Docker อยู่ไม่กี่ตัว
ใช้งานได้ดี แต่ไม่ได้ใช้ 90% ของฟีเจอร์
สำหรับคนที่สงสัย ดูจาก https://github.com/cockpit-project/cockpit แล้ว Cockpit เขียนด้วยหลายภาษา โดยมี C มากที่สุด ตามด้วย JavaScript และ Python
src/cockpitน่าจะเป็นลอจิกแบ็กเอนด์หลัก และเป็น Pythonบริดจ์ใหม่เขียนด้วย Python และเมื่อถึงเวลา ก็อยากเขียนเว็บเซิร์ฟเวอร์ใหม่ด้วยแนวทางที่ทันสมัยกว่า
เรื่องอย่างมี dependency อะไรบ้าง ต้องกังวลกับช่องโหว่ของไลบรารี logging หรือ Curl หรือไม่ ก็สำคัญเช่นกัน
การดูว่าผลิตภัณฑ์เขียนด้วยสแต็กเดียวที่ชัดเจน หรือผสมหลายเทคโนโลยีเข้าด้วยกัน ก็น่าสนใจเหมือนกัน