การติดตั้งในระบบปิด (Air-gapped install)
แพลตฟอร์มนี้ได้รับการออกแบบมาให้สามารถทำงานได้โดยไม่ต้องมีการเชื่อมต่อเครือข่ายขาออกไปยังอินเทอร์เน็ต (no internet egress) คอนเทนเนอร์อิมเมจทั้งหมดที่จำเป็นต้องใช้งานสามารถคัดลอก (mirror) ไปยัง registry ภายในของคุณเองได้ ส่วนการเชื่อมต่อ TLS สามารถใช้ใบรับรองแบบลงนามด้วยตนเอง (self-signed) จาก CA ภายในองค์กร และระบบจัดการตัวตนจะทำงานอยู่ภายในเครือข่ายของคุณเท่านั้น หน้านี้จะครอบคลุมรายละเอียดการตั้งค่าเฉพาะสำหรับการติดตั้งในระบบปิด
เอกสารนี้เหมาะสำหรับใคร
วิศวกรแพลตฟอร์ม (platform engineer) ที่ต้องติดตั้งระบบลงในสภาพแวดล้อมที่ตัดการเชื่อมต่อจากอินเทอร์เน็ต หรือสภาพแวดล้อมที่มีการควบคุมเครือข่ายขาออกอย่างเข้มงวด เช่น กลุ่มธุรกิจภายใต้การควบคุมตามกฎหมาย หรือศูนย์ข้อมูลภายในองค์กร (on-prem data center)
1. การทำสำเนาคอนเทนเนอร์อิมเมจ (Mirror images)
อิมเมจทั้งหมด ได้แก่ gateway, control plane, console, ฐานข้อมูล, ระบบระบุตัวตน, ระบบตรวจสอบสถานะการทำงาน และปลั๊กอินในตัว จะถูกระบุเวอร์ชันที่แน่นอนไว้เสมอ โปรดทำสำเนาอิมเมจเหล่านี้ไปยัง registry ของคุณ จากนั้นกำหนดค่าใน chart ให้ดาวน์โหลดอิมเมจจากแหล่งดังกล่าวแทน
global:
registry: registry.internal/opsta-ai-gateway # registry ของคุณสำหรับเก็บอิมเมจที่พัฒนาโดย Opsta
imageMirror: registry.internal/mirror # registry ภายในสำหรับทำสำเนาอิมเมจภายนอก
imageMirrorFlatten: true # ปรับโครงสร้างชื่ออิมเมจให้อยู่ในระดับชั้นเดียวร่วมกัน
imagePullSecrets:
- name: internal-registryแนะนำการทำโครงสร้างแบบแบนเพื่อหลีกเลี่ยงจำนวน repository ที่มากเกินไป
การกำหนดค่า imageMirrorFlatten: true จะปรับเขียนชื่ออิมเมจต้นทางทั้งหมดให้อยู่ในรูปแบบ <imageMirror>/<leaf>:<tag> เพื่อให้คุณไม่ต้องสร้าง repository ย่อยจำนวนมากใน Harbor, ECR หรือ Artifactory โดยตัว chart จะคอยแปลงตำแหน่งอิมเมจให้คุณโดยอัตโนมัติ คุณจึงไม่จำเป็นต้องแก้ไข manifest ใด ๆ เอง
คุณสามารถตรวจสอบรายการอิมเมจและเวอร์ชันที่ผ่านการทดสอบแล้วได้ในคอมโพเนนต์เมทริกซ์ (component matrix) ของ chart ดูรายละเอียดเพิ่มเติมได้ที่ การอัปเกรดระบบ และ เอกสารอ้างอิงการกำหนดค่า โปรดทำสำเนาอิมเมจทั้งหมดตามชุดเวอร์ชันผลิตภัณฑ์ที่คุณกำลังจะติดตั้ง เนื่องจากเป็นชุดอิมเมจที่ผ่านการทดสอบการทำงานร่วมกันมาเรียบร้อยแล้ว
2. การใช้งาน TLS แบบลงนามด้วยตนเองหรือผ่าน CA ภายในองค์กร
เนื่องจากผู้ให้บริการ ACME สาธารณะจะไม่สามารถเข้าถึงได้ในสภาพแวดล้อมระบบปิด โปรดใช้แหล่งใบรับรองที่คุณควบคุมจัดการได้เองดังนี้
tls:
mode: selfsigned # cert-manager จะออกใบรับรอง wildcard แบบลงนามด้วยตนเองให้หรือกำหนดค่า tls.mode: provided พร้อมกับระบุใบรับรอง wildcard จาก CA ภายในองค์กรของคุณ ซึ่งแอปพลิเคชันหรือไคลเอนต์ยอมรับความน่าเชื่อถืออยู่แล้ว ดูรายละเอียดเพิ่มเติมได้ที่ TLS และโดเมน
3. ใช้ Operator เดิมที่มีอยู่แล้วบนคลัสเตอร์
หากคลัสเตอร์ของคุณมีการเปิดใช้งาน cert-manager, Redis operator หรือ CloudNativePG อยู่ก่อนแล้ว คุณสามารถระบุให้ใช้งานระบบเดิมดังกล่าวแทนการติดตั้งใหม่ซ้ำซ้อนได้ ดูรายละเอียดเพิ่มเติมได้ที่ การใช้งาน operator เดิมบนคลัสเตอร์ ซึ่งจะช่วยลดจำนวนอิมเมจที่ต้องทำสำเนาลงด้วย
4. ระบบจัดการตัวตนทำงานอยู่ภายในเครือข่าย
Keycloak จะทำงานอยู่ภายในคลัสเตอร์เพื่อทำหน้าที่เป็นระบบเชื่อมต่อตัวตน ทำให้ทราฟฟิกของการลงชื่อเข้าใช้งานไม่มีการส่งออกนอกเครือข่ายของคุณ โดยแต่ละองค์กรจะเชื่อมต่อ IdP ของตนเข้ากับ Keycloak ผ่านเครือข่ายภายในองค์กร ดูรายละเอียดเพิ่มเติมได้ที่ SSO และ IdP ทั้งนี้โปรดหลีกเลี่ยงการใช้งานโหมด SSO แบบ google ในระบบปิด และให้เชื่อมต่อกับผู้ให้บริการ OIDC หรือ SAML ภายในองค์กรแทน
5. ระบบตรวจสอบสถานะการทำงานติดตั้งภายในระบบตัวเอง
ชุดซอฟต์แวร์ระบบตรวจสอบสถานะการทำงาน (observability stack) ทั้งข้อมูลชี้วัด ล็อก และประวัติการทำงานจะทำงานอยู่ภายในคลัสเตอร์ทั้งหมดโดยไม่มีการส่งออกไปยังระบบคลาวด์ภายนอก ในโหมด HA โปรดตั้งค่าให้ชี้ไปยังที่จัดเก็บข้อมูลแบบวัตถุ (object storage) ภายในเครือข่ายของคุณเอง ดูรายละเอียดเพิ่มเติมได้ที่ ระบบตรวจสอบสถานะการทำงานของแพลตฟอร์ม
ข้อมูลที่ไม่มีวันหลุดออกนอกคลัสเตอร์
- เนื้อหาการร้องขอและการตอบกลับของ LLM: gateway จะทำหน้าที่รับส่งต่อ (proxy) ข้อมูลไปยังผู้ให้บริการต้นทางที่คุณเป็นผู้กำหนดไว้เท่านั้น
- ข้อมูลวัดระยะไกล (Telemetry): ข้อมูลชี้วัด ล็อก และประวัติการทำงานของระบบ
- ข้อมูลตัวตน: ข้อมูลการเข้าสู่ระบบและโทเค็นความปลอดภัย
- ค่ากำหนดและประวัติการทำงาน: ซึ่งจะจัดเก็บไว้ในฐานข้อมูล PostgreSQL ของคุณเอง
ดูรายละเอียดเพิ่มเติมได้ที่คู่มือ ความเป็นเอกราชของข้อมูล สำหรับข้อแถลงฉบับเต็ม