bytelyst/learning_ai_common_plat
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(devops): record live ollama DNS and HTTPS status

Browse Source
This commit is contained in:
root 2026-03-31 10:17:39 +00:00
parent b1db0d583d
commit 66ddcaaaa6
3 changed files with 50 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
docs/devops/single_azure_vm/docker/DEPLOYMENT_STATUS_2026-03-29.md
View File

@ -21,6 +21,9 @@ The VM moved forward after the original snapshot:
- live Mission Control and inventory now cover the VM-hosted product web apps and other browser-facing VM surfaces
- `llmlab-dashboard` is treated as internal VM tooling, while `localmemgpt-web` is intended to be Vercel-hosted rather than part of the VM web surface
- live verification confirmed a request for `productId=valkey-check-2` created the key `extraction:product-rate-limit:29582406:valkey-check-2` in Valkey with value `1`
- GoDaddy DNS now points `api`, `gitea`, `admin`, `tracker`, `llmlab`, and `ollama` at `187.124.159.82`
- Caddy is the active VM ingress on `80/443` with valid Let's Encrypt certificates for all six hostnames
- `ollama.bytelyst.com/api/version` returns `200` and serves Ollama `0.18.0` over HTTPS
### What is working
@ -132,12 +135,21 @@ This was verified with host-context curls against `http://127.0.0.1:<port>/healt
- mailpit
- loki
- grafana
- gateway
- caddy
- platform-service
- extraction-service
- mcp-server
- all 10 product backends
### Healthy internal web and ingress surfaces
- `admin.bytelyst.com`
- `tracker.bytelyst.com`
- `gitea.bytelyst.com`
- `llmlab.bytelyst.com`
- `ollama.bytelyst.com`
- `api.bytelyst.com`
### Present but not yet added to the active VM stack
- Prometheus

8
docs/devops/single_azure_vm/docker/README.md
View File

@ -296,6 +296,13 @@ All optional — defaults work for most setups:
- Public backend access is intended to flow through Caddy on `https://api.bytelyst.com`, not direct backend port exposure.
- The gateway config lives at `/opt/bytelyst/Caddyfile` and is mounted into the `caddy` container.
- Current validated public VM hostnames are:
- `https://api.bytelyst.com`
- `https://gitea.bytelyst.com`
- `https://admin.bytelyst.com`
- `https://tracker.bytelyst.com`
- `https://llmlab.bytelyst.com`
- `https://ollama.bytelyst.com`
- Backend routes are path-based and strip their prefixes before proxying:
- `/platform/*` → `platform-service:4003`
- `/extraction/*` → `extraction-service:4005`
@ -311,6 +318,7 @@ All optional — defaults work for most setups:
- `/actiontrail/*` → `actiontrail-backend:4018`
- `/localmemgpt/*` → `localmemgpt-backend:4019`
- Keep backend ports closed publicly once DNS and NSG rules are aligned. Docker-internal service discovery remains unchanged.
- `ollama.bytelyst.com` reverse proxies to the host Ollama listener on `172.17.0.1:11434`; keep it restricted to trusted cross-VM or internal clients.
## Known Limitations

43
docs/devops/vercel/GODADDY_DNS_SETUP_BYTELYST.md
View File

@ -68,24 +68,26 @@ pnpm dns:godaddy:bytelyst -- --ip <Azure VM public IP> --validate
## Current Status
Status as of `2026-03-31 09:41:09 UTC`:
Status as of `2026-03-31 10:12:25 UTC`:
- GoDaddy `A` records were updated for `api`, `gitea`, `admin`, `tracker`, `llmlab`, and `ollama`
- all six hostnames should resolve publicly to `187.124.159.82`
- the VM now serves `80` and `443` through the `caddy` container
- Let's Encrypt certificates were issued successfully for the existing public app hostnames, and `ollama` can be added through the same Caddy path
- Let's Encrypt certificates were issued successfully for all six hostnames, including `ollama.bytelyst.com`
- live HTTPS verification from inside the VM-level Caddy path returned:
- `api.bytelyst.com` -> `HTTP/1.1 200 OK`
- `gitea.bytelyst.com` -> `HTTP/1.1 200 OK`
- `admin.bytelyst.com` -> `HTTP/1.1 200 OK`
- `tracker.bytelyst.com` -> `HTTP/1.1 200 OK`
- `llmlab.bytelyst.com` -> `HTTP/1.1 200 OK`
- `ollama.bytelyst.com/api/version` -> `HTTP/2 200`
- `ollama.bytelyst.com/api/version` body -> `{"version":"0.18.0"}`
Interpretation:
- DNS cutover is complete
- the VM-side HTTPS gateway issue is fixed
- remaining work, if any, is app-specific hardening rather than DNS or TLS bring-up
- remaining work, if any, is app-specific hardening and access-control tightening rather than DNS or TLS bring-up
## Preconditions
@ -153,14 +155,15 @@ Expected result:
## Next Action For Codex On The VM
Delegate the remaining work to the Codex session running inside the Azure VM. The immediate goal is to make `443` work and ensure the hostnames are actually configured in Caddy.
The original VM handoff in this section has already been completed. Use this only if records drift or the VM ingress needs to be rebuilt.
Recommended handoff summary:
- DNS is already correct for `api.bytelyst.com`, `gitea.bytelyst.com`, `admin.bytelyst.com`, `tracker.bytelyst.com`, and `llmlab.bytelyst.com`
- all five names point to `187.124.159.82`
- DNS is already correct for `api.bytelyst.com`, `gitea.bytelyst.com`, `admin.bytelyst.com`, `tracker.bytelyst.com`, `llmlab.bytelyst.com`, and `ollama.bytelyst.com`
- all six names point to `187.124.159.82`
- Caddy is already serving valid TLS for all six names
- do not spend time redoing GoDaddy changes unless records drift
- focus on `/opt/bytelyst/Caddyfile`, the `caddy` container, and Azure NSG rules for `443`
- focus future work on access control and client integration rather than basic DNS/TLS bring-up
Run these on the VM:
@ -192,6 +195,7 @@ The live Caddy config should cover at least these hostnames:
- `admin.bytelyst.com`
- `tracker.bytelyst.com`
- `llmlab.bytelyst.com`
- `ollama.bytelyst.com`
Expected proxy targets:
@ -203,6 +207,7 @@ Expected proxy targets:
- `admin.bytelyst.com` -> `admin-web:3001`
- `tracker.bytelyst.com` -> `tracker-web:3003`
- `llmlab.bytelyst.com` -> `llmlab-dashboard:3075`
- `ollama.bytelyst.com` -> `172.17.0.1:11434`
If the file is missing host blocks, update it and reload Caddy:
@ -225,6 +230,7 @@ curl -vk https://gitea.bytelyst.com
curl -vk https://admin.bytelyst.com
curl -vk https://tracker.bytelyst.com
curl -vk https://llmlab.bytelyst.com
curl -vk https://ollama.bytelyst.com/api/version
```
Ready-to-paste prompt for the Codex session running inside the VM:
@ -238,10 +244,15 @@ Known-good DNS state as of 2026-03-31:
- admin.bytelyst.com -> 187.124.159.82
- tracker.bytelyst.com -> 187.124.159.82
- llmlab.bytelyst.com -> 187.124.159.82
- ollama.bytelyst.com -> 187.124.159.82
Known current failure:
- HTTP on port 80 responds, but returns 404
- HTTPS on port 443 times out for all four hostnames
Known-good HTTPS state:
- https://api.bytelyst.com/platform/health -> 200
- https://gitea.bytelyst.com -> 200
- https://admin.bytelyst.com -> 200
- https://tracker.bytelyst.com -> 200
- https://llmlab.bytelyst.com -> 200
- https://ollama.bytelyst.com/api/version -> 200 with {"version":"0.18.0"}
Your task:
1. Inspect the live VM deployment under /opt/bytelyst
@ -263,6 +274,7 @@ Your task:
- admin.bytelyst.com -> admin-web:3001
- tracker.bytelyst.com -> tracker-web:3003
- llmlab.bytelyst.com -> llmlab-dashboard:3075
- ollama.bytelyst.com -> 172.17.0.1:11434
7. Reload Caddy
8. Verify:
- curl -vk https://api.bytelyst.com/platform/health
@ -270,6 +282,7 @@ Your task:
- curl -vk https://admin.bytelyst.com
- curl -vk https://tracker.bytelyst.com
- curl -vk https://llmlab.bytelyst.com
- curl -vk https://ollama.bytelyst.com/api/version
Run these first:
@ -284,6 +297,7 @@ curl -sI http://localhost:3003 | head -5
curl -sI http://localhost:3300 | head -5
curl -sI http://localhost:4003/health | head -5
curl -sI http://localhost:3075 | head -5
curl -s http://127.0.0.1:11434/api/version
If /opt/bytelyst/Caddyfile is missing host blocks, fix it there and reload:
@ -299,7 +313,7 @@ When done, report:
- what was wrong
- what file(s) you changed
- exact verification results for all four public hostnames
- exact verification results for all five public hostnames
- exact verification results for all six public hostnames
```
## Troubleshooting
@ -320,10 +334,11 @@ docker ps --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}' | grep -E 'caddy|
docker logs caddy --tail 100
```
Likely root causes for the current state:
Likely root causes if this breaks again:
- the live `/opt/bytelyst/Caddyfile` only included `api.bytelyst.com`
- `gitea`, `admin`, `tracker`, and `llmlab` host blocks had not been added on the VM
- `ollama.bytelyst.com` was added after initial DNS cutover and needed a second ACME retry after DNS propagation
- the legacy Traefik `gateway` container was still holding port `80`
- the `caddy` container was defined in compose but not running, so nothing was bound to `443`
@ -339,5 +354,5 @@ Use this section to record real DNS cutovers:
| Date | Operator | Change | Result |
| ------------ | -------- | ---------------------------------------------------------------------------------------------------- | -------------------- |
| `2026-03-31` | Codex | Created GoDaddy-specific DNS runbook for `bytelyst.com` | Document added |
| `2026-03-31` | Codex | Updated GoDaddy `A` records for `api`, `gitea`, `admin`, `tracker`, and `llmlab` to `187.124.159.82` | DNS cutover complete |
| `2026-03-31` | Codex | Verified DNS propagation and recorded VM-side HTTPS follow-up steps | VM action pending |
| `2026-03-31` | Codex | Updated GoDaddy `A` records for `api`, `gitea`, `admin`, `tracker`, `llmlab`, and `ollama` to `187.124.159.82` | DNS cutover complete |
| `2026-03-31` | Codex | Restarted Caddy after `ollama` DNS propagation and verified live HTTPS for `ollama.bytelyst.com/api/version` | HTTPS fixed |