วาง ONLYOFFICE Docs ไว้หลัง HAProxy โดยไม่ทำให้การแก้ไขเอกสารหยุดชะงัก

ใช้งาน ONLYOFFICE Docs ผ่าน HAProxy โดยการยุติ HTTPS ที่พร็อกซี ส่งต่อโฮสต์และรูปแบบเดิม และอนุญาตการเชื่อมต่อ WebSocket ที่มีอายุการใช้งานยาวนาน เริ่มต้นด้วย Document Server ที่ทำงานได้อย่างสมบูรณ์หนึ่งเครื่อง เพิ่มแบ็กเอนด์เพิ่มเติมเฉพาะเมื่อการใช้งาน ONLYOFFICE ของคุณได้รับการกำหนดค่าสำหรับการทำงานแบบหลายโหนดที่รองรับ ไม่ใช่เพียงเพราะ HAProxy สามารถกระจายคำขอได้

HAProxy สามารถกระจายโหลดให้กับเซิร์ฟเวอร์เอกสารอิสระสองเครื่องได้หรือไม่?

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

สำหรับการติดตั้งแบบเซิร์ฟเวอร์เดี่ยวทั่วไป ให้ใช้เฉพาะdocs1ในส่วนแบ็กเอนด์ด้านล่างเท่านั้น สำหรับสองโหนด ให้ตรวจสอบสถาปัตยกรรมคลัสเตอร์ รุ่นที่รองรับ การพึ่งพาที่ใช้ร่วมกัน ความเข้ากันได้ของเวอร์ชัน และการกำหนดค่า JWT กับเอกสารการใช้งาน ONLYOFFICE หรือฝ่ายสนับสนุนของผู้จำหน่ายก่อน ตัวอย่างที่อยู่ — 10.0.10.21และ10.0.10.22— เป็นเพียงที่อยู่ IP ส่วนตัวที่ใช้เป็นตัวอย่าง ไม่ใช่โฮสต์ที่ค้นพบ

อะไรบ้างที่ต้องใช้งานได้ก่อนที่คุณจะแก้ไข HAProxy?

ชื่อสาธารณะdocs.example.comควรชี้ไปยังปลายทาง HAProxy ของคุณ HAProxy ต้องการพอร์ต TCP ขาเข้า 80 และ 443 และการเข้าถึงเครือข่ายส่วนตัวไปยัง Document Server แต่ละตัวบนพอร์ต 80 แอปพลิเคชันการจัดการเอกสารของคุณต้องสามารถเข้าถึงที่อยู่ Docs สาธารณะได้ ในขณะที่ ONLYOFFICE ต้องสามารถดึงเอกสารและส่งการเรียกกลับไปยังแอปพลิเคชันได้ รักษาความเป็นส่วนตัวของ HTTP ฝั่งแบ็กเอนด์ เข้ารหัสการเชื่อมต่อแบ็กเอนด์แยกต่างหากหากมีการข้ามเครือข่ายที่ไม่น่าเชื่อถือ

1. ตรวจสอบเซิร์ฟเวอร์เอกสารแต่ละตัวจากโฮสต์พร็อกซีเรียกใช้คำสั่งcurl -i http://10.0.10.21/healthcheckและหากมี ให้เรียก ใช้ curl -i http://10.0.10.22/healthcheckคำสั่ง โดยปกติแล้ว เอนด์พอยต์ตรวจสอบสถานะการทำงานจะส่งคืน HTTP 200 พร้อมเนื้อหาเป็นtrueหากสิ่งใดสิ่งหนึ่งล้มเหลว ให้ตรวจสอบการกำหนดเส้นทาง ไฟร์วอลล์ หรือสถานะของเซิร์ฟเวอร์ก่อนกำหนดค่าการปรับสมดุล
2. ยืนยันรหัสลับ JWT ที่แน่นอนเซิร์ฟเวอร์เอกสารและตัวเชื่อมต่อต้องเห็นพ้องกันเกี่ยวกับรหัสลับโทเค็น สำหรับการติดตั้ง Docker เอกสาร ONLYOFFICE ได้ระบุJWT_SECRETตัวแปรสภาพแวดล้อมไว้ ตั้งแต่ Docs 7.2 เป็นต้นไป การพึ่งพารหัสลับที่สร้างขึ้นโดยอัตโนมัติอาจทำให้เกิดความล้มเหลวในการทำงานร่วมกันหลังจากสร้างใหม่หรือรีสตาร์ท ในการใช้งานแบบหลายโหนดที่รองรับ ให้จัดเรียงรหัสลับระหว่างโหนดให้สอดคล้องกับสถาปัตยกรรมของผู้จำหน่าย

การตรวจสอบเหล่านี้เป็นไปตาม คำแนะนำการติดตั้ง Dockerและคำแนะนำการกำหนดค่า JWTของผู้จำหน่ายอย่าปิดใช้งาน JWT เพียงเพื่อแก้ไขปัญหาข้อผิดพลาดของพร็อกซี

วิธีการตั้งค่า HTTPS และส่งต่อส่วนหัวที่ถูกต้องทำอย่างไร?

ขั้นตอนที่ 1: เตรียมใบรับรอง

ขอรับใบรับรองที่เชื่อถือได้ซึ่งครอบคลุมถึงdocs.example.com... ในตัวอย่าง Linux นี้ HAProxy จะอ่านไฟล์ PEM ที่มีห่วงโซ่ใบรับรองตามด้วยคีย์ส่วนตัว หากมีใบรับรองอยู่แล้วที่อื่น ให้แทนที่ด้วยเส้นทางเหล่านั้น จำกัดการเข้าถึงไฟล์ PEM ที่รวมกันแล้ว และจัดการให้สร้างใหม่เมื่อใบรับรองได้รับการต่ออายุ

sudo install -d -m 700 /etc/haproxy/certs
sudo sh -c 'umask 077; cat /etc/letsencrypt/live/docs.example.com/fullchain.pem /etc/letsencrypt/live/docs.example.com/privkey.pem > /etc/haproxy/certs/docs.example.com.pem'

ขั้นตอนที่ 2: เพิ่มส่วนหน้า (frontend) และส่วนหลัง (backend)

สำรองข้อมูลการตั้งค่าที่มีอยู่ของคุณ/etc/haproxy/haproxy.cfgและปรับใช้ส่วนต่อไปนี้แทนที่จะแทนที่การบันทึกข้อมูลหรือการตั้งค่าบริการเฉพาะของแต่ละระบบปฏิบัติการโดยไม่ตรวจสอบให้ดีเสียก่อน นี่คือตัวอย่างการกำหนดค่าสำหรับ HAProxy รุ่นใหม่ โดยจะยอมรับเฉพาะ HTTP สำหรับการเปลี่ยนเส้นทาง ยุติ HTTPS บนพอร์ต 443 ส่งต่อโฮสต์สาธารณะและรูปแบบ และตรวจสอบเอนด์พอยต์สถานะสุขภาพของแอปพลิเคชัน

global
    log /dev/log local0

defaults
    mode http
    log global
    option httplog
    option forwardfor
    timeout connect 5s
    timeout client 60s
    timeout server 60s
    timeout tunnel 1h

frontend docs_http
    bind :80
    http-request redirect scheme https code 301

frontend docs_https
    bind :443 ssl crt /etc/haproxy/certs/docs.example.com.pem
    http-request set-header X-Forwarded-Proto https
    http-request set-header X-Forwarded-Host %[req.hdr(Host)]
    default_backend docs_nodes

backend docs_nodes
    option http-server-close
    balance roundrobin
    cookie SERVERID insert indirect nocache
    option httpchk GET /healthcheck
    http-check expect string true
    server docs1 10.0.10.21:80 check cookie docs1
    server docs2 10.0.10.22:80 check cookie docs2

ลบdocs2เส้นนั้นออก เว้นแต่ว่าโหนดที่สองพร้อมใช้งานอย่างแท้จริง คุกกี้แบบคงสถานะจะช่วยให้คำขอ HTTP ครั้งถัดไปส่งกลับไปยังโหนดที่เลือกไว้ HAProxy จัดการการอัปเกรด HTTP WebSocket โดยไม่ต้องเขียน URL ใหม่เป็นพิเศษtimeout tunnel 1hอนุญาตให้การเชื่อมต่อที่อัปเกรดแล้วซึ่งไม่ได้ใช้งานเปิดอยู่ได้นานกว่าคำขอทั่วไปเอกสารประกอบ HAProxy WebSocketอธิบายพฤติกรรมนี้

การตั้งค่าX-Forwarded-Protoนี้httpsถูกต้องแล้ว เนื่องจากส่วนหน้า (frontend) นี้จะยุติการเชื่อมต่อ HTTPS สาธารณะ อย่าเชื่อถือแผนการส่งต่อ (forwarding scheme) หรือโฮสต์ที่ลูกค้าจัดหามาโดยพลการ ณ ขอบเครือข่ายที่เชื่อมต่อกับอินเทอร์เน็ตเอกสารประกอบการใช้งานพร็อกซี ONLYOFFICEระบุไว้อย่างชัดเจนX-Forwarded-Protoว่าX-Forwarded-Hostให้คงบริบทของ URL ภายนอกไว้

คุณควรทำการรีโหลดและทดสอบตัวจัดการโหลดอย่างไร?

ขั้นตอนที่ 3: ตรวจสอบความถูกต้องก่อนเปลี่ยนเส้นทางการรับส่งข้อมูล

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

sudo haproxy -c -f /etc/haproxy/haproxy.cfg
sudo systemctl reload haproxy
curl -i https://docs.example.com/healthcheck

การตอบสนองการตรวจสอบสุขภาพสาธารณะควรแสดง HTTP 200 trueเมื่อแบ็กเอนด์ทำงานได้อย่างปกติ HAProxy ใช้ คำสั่ง option httpchk`and` http-check expectเพื่อลบโหนดที่ล้มเหลวออกจากการหมุนเวียนคำขอใหม่ โปรดดูข้อมูลอ้างอิงการตรวจสอบสุขภาพการตรวจสอบผ่านไม่ได้หมายความว่าการแก้ไขเอกสารหรือการส่งข้อความเรียกกลับทำงานได้

ขั้นตอนที่ 4: ยืนยันการแก้ไข การเชื่อมต่อ WebSockets และการบันทึก

เปิดเอกสารผ่านแอปพลิเคชันที่ผสานรวมอยู่ เช่น ระบบจัดการเอกสารที่เชื่อมต่อกับ ONLYOFFICE Docs ในเครื่องมือสำหรับนักพัฒนาของเบราว์เซอร์ ให้ใช้แผงเครือข่ายเพื่อตรวจสอบการเชื่อมต่อ WebSocket: การเชื่อมต่อการอัปเกรดควรสำเร็จ โดยทั่วไปจะมีสถานะ HTTP 101 Switching Protocolsทำการแก้ไขเล็กน้อย ปิดตัวแก้ไข เปิดเอกสารอีกครั้ง และยืนยันว่าการเปลี่ยนแปลงได้รับการบันทึกแล้ว สำหรับการใช้งานแบบสองโหนดที่ได้รับการสนับสนุนอย่างถูกต้อง ให้ทดสอบผู้ร่วมงานคนที่สองและการทดสอบการใช้งานโหนดเดียวในระหว่างช่วงเวลาการบำรุงรักษาด้วย

หากการตรวจสอบสุขภาพสาธารณะทำงานได้ แต่โปรแกรมแก้ไขเอกสารทำงานผิดปกติหรือตัดการเชื่อมต่อ ให้ตรวจสอบคำเตือนเกี่ยวกับเนื้อหาผสม การทำงานล้มเหลวของ WebSocket ความไม่ตรงกันของ JWT และตรวจสอบว่าแอปพลิเคชันเอกสารสามารถเข้าถึง URL ของ Docs ที่ประกาศไว้ได้หรือไม่ หากเอกสารเปิดได้แต่ไม่บันทึก ให้ตรวจสอบความสามารถในการเข้าถึงการเรียกกลับจาก Document Server ไปยังแอปพลิเคชันต้นทาง แทนที่จะเปลี่ยนนโยบาย round-robin ของ HAProxy เซสชัน WebSocket ที่ใช้งานอยู่ซึ่งถูกขัดจังหวะอาจยังคงต้องมีการเชื่อมต่อไคลเอ็นต์ใหม่ การตรวจสอบสุขภาพของแบ็กเอนด์ไม่ได้รับประกันการแก้ไขที่ราบรื่นในกรณีที่ระบบล้มเหลว

การตรวจสอบขั้นสุดท้าย:ทั้งจุดสิ้นสุดด้านสาธารณสุขและการทดสอบแก้ไขและเปิดใหม่จริงควรผ่าน เก็บเฉพาะโหนดที่ได้รับการตรวจสอบและรองรับไว้ในระบบหมุนเวียน ยืนยันว่าการต่ออายุใบรับรองโหลด PEM ที่ถูกต้อง และตรวจสอบบันทึก HAProxy สำหรับการตอบสนอง 502/503 ซ้ำๆ หรือการตัดการเชื่อมต่อ WebSocket ที่ไม่คาดคิด