Skip to main content

Operational Notes

Debugging a failed request​

  1. Check Worker logs — CF Dashboard → Workers & Pages → admin-gateway-dev → Logs, or wrangler tail --env dev. Look for non-2xx responses or missing header errors.
  2. Check cf-proxy logs on the VM — SSH via IAP: gcloud compute ssh gateway-<id> --tunnel-through-iap --zone europe-west1-b. Then: sudo journalctl -u cf-proxy -f. Log fields: method, path, host, status, latency_ms.
  3. Check cloudflared status — sudo journalctl -u cloudflared -f. The tunnel must show Connection registered entries. If not, check UDP 7844 egress (Cloud NAT health).
  4. Verify routes.json — cat /etc/cf-proxy/routes.json. If a hostname is missing, the startup script didn't write it — check Terraform apply output.
  5. Check Cloud Run logs — gcloud logging read 'resource.type="cloud_run_revision" AND resource.labels.service_name="svc-access"' --limit 50 --format json --project eigenoid-dev.

VM replacement​

The MIG handles this automatically when the instance template changes. If you need to force a replacement manually:

gcloud compute instance-groups managed recreate-instances gateway-mig-dev \
  --instances=<instance-name> \
  --zone=europe-west1-b \
  --project=eigenoid-dev
bash

After recreation, allow up to 5 minutes for the VM to boot, download cloudflared, connect the tunnel, and pass the health check.

Adding a new environment (qa, prd)​

The gateway is environment-parameterized via var.iac_environment. All resource names include the env suffix. To stand up a new environment, run Terraflow promote for iac-api-gateway targeting the new environment — no code changes required.