ambiser
/
openvidu
mirror of https://github.com/OpenVidu/openvidu.git
9
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
openvidu/openvidu-deployment/pro/elastic/gcp/DOC-CHANGES-elastic-hardeni...

3.6 KiB
Raw Blame History

Doc changes for elastic-hardening (OpenVidu Elastic, GCP)

Target docs repo: openvidu.io, branch next Docs affected: docs/docs/self-hosting/elastic/gcp/*.md

Context

Hardening of pro/elastic/gcp/tf-gpc-openvidu-elastic.tf (deployment repo, branch elastic-hardening). Almost all changes are internal robustness improvements to the Terraform bootstrap scripts and resource graph: explicit depends_on on the enabled Google APIs, robust installer download (download-to-file with retries instead of sh <(curl ...)), bounded readiness/secret gates on master and media nodes, a fixed and de-duplicated install-completion marker so reboots take the restart path, a reboot guard on media nodes, and set +x around secret-handling blocks so credentials are not written to the serial console.

One change adds new infrastructure behavior (see "Optional note for admin.md").

Impact on the docs: essentially none

No user-facing surface changes. Specifically:

  • Parameters: unchanged. No input variable added, removed, or renamed. The parameters table in install.md needs no structural edit (but see the stale default-value fix below).
  • Outputs: unchanged. output.tf is untouched; the Outputs / connection section in install.md is identical.
  • Install / upgrade flow: unchanged (install.md, upgrade.md). No screenshots need to be retaken.

Deployment time ("7 to 12 minutes") — REMAINS VALID, no edit

install.md states around lines 236 and 295:

Wait around 7 to 12 minutes for the nodes to install OpenVidu.

The hardening changes are robustness-only and do not lengthen the happy-path install. The bounded waits are failure upper bounds (master readiness 240x5s = 20 min; media secret wait 180x10s = 30 min), not expected durations — on a healthy deploy the gates pass as soon as the node is ready, exactly as before. Leave both sentences unchanged.

Required fix: stale default instance types

Independent of the hardening, install.md documents default instance types that no longer match variables.tf. The Terraform defaults are e2-standard-4 for both node types (variables.tf: masterNodeInstanceType, mediaNodeInstanceType), but the parameters table still lists e2-standard-2.

  • install.md ~line 179 (row masterNodeInstanceType): <td>"e2-standard-2"</td> -> <td>"e2-standard-4"</td>
  • install.md ~line 185 (row mediaNodeInstanceType): <td>"e2-standard-2"</td> -> <td>"e2-standard-4"</td>

Optional note for admin.md (media node auto-healing)

The hardening adds a Managed Instance Group auto-healing policy for Media Nodes: a regional TCP health check on port 7880 (check interval 30s, timeout 10s, healthy threshold 2, unhealthy threshold 5) with initial_delay_sec = 600. The MIG now recreates a Media Node whose LiveKit HTTP port stops accepting TCP connections. This is new observable behavior, so it is worth a short note.

Suggested placement: the "Media Nodes Autoscaling Configuration" section (around line 118) or a new subsection just after it, e.g.:

Media Node auto-healing

Media Nodes are additionally protected by an auto-healing policy on the Managed Instance Group. A TCP health check probes each Media Node on port 7880; if a node stops accepting connections it is recreated automatically. The check is intentionally conservative (TCP-only, with a 10-minute initial delay so a node can finish installing before it becomes eligible for health checks) because recreating a Media Node terminates the live WebRTC sessions running on it.

Include this only if change 7 (auto-healing) ships in the release the docs describe. It is a behavior addition, not a parameter or output change.