56 lines
5.2 KiB
Markdown
56 lines
5.2 KiB
Markdown
# Task Plan
|
|
|
|
## Checklist
|
|
|
|
- [x] Inspect the published managed-portal installer and release manifest under `root@10.8.0.1:/var/www/html/ai_deploy`.
|
|
- [x] Confirm the registry tags currently published for `managed-portal`, `managed-portal-web`, `people-flow-project`, and `store-dwell-alert`.
|
|
- [x] Prepare `10.8.0.14` for an installer-aligned rollout of the four-service managed-portal stack.
|
|
- [x] Recreate the four target containers on `10.8.0.14` using the published release version and corresponding Compose layout.
|
|
- [x] Verify the running stack on `10.8.0.14` uses the published registry images and the installer-managed Compose project.
|
|
|
|
## Scope And Risks
|
|
|
|
- Scope: use the published managed-portal release artifacts on `10.8.0.1` as the source of truth for image names, tags, and Compose topology.
|
|
- Scope: update the four-service managed-portal group on `10.8.0.14`: `managed-portal`, `managed-portal-web`, `people-flow-project`, and `store-dwell-alert`.
|
|
- Scope: keep unrelated stacks, especially the `iot-main` video-recognition project, untouched.
|
|
- Risk: the current four containers on `10.8.0.14` are not managed by one Compose project, so installer-based recreation will conflict on fixed container names unless the old containers are replaced cleanly.
|
|
- Risk: the published installer seeds config, data, outputs, and weights under `/opt/managed-portal-releases`; switching to it changes the runtime paths from the current ad hoc directories.
|
|
- Risk: service recreation causes a brief interruption for the portal and both child-service APIs.
|
|
|
|
## Validation Intent
|
|
|
|
- Read the published installer and `release-manifest.env` to confirm the exact release version and image references.
|
|
- Verify the registry exposes the four target tags before rollout.
|
|
- Use the installer-aligned Compose files and environment from the published bundle, not a hand-built local variant.
|
|
- Confirm the final containers are recreated from the published registry images and are running under the installer-managed release directory.
|
|
|
|
## Review
|
|
|
|
- Status: complete.
|
|
- Result:
|
|
- Confirmed the published managed-portal installer source of truth is `root@10.8.0.1:/var/www/html/ai_deploy/install-managed-portal-20260519-f3f40b5-11.sh`.
|
|
- Confirmed the published registry images in `release-manifest.env` are:
|
|
- `ota.zhengxinshipin.com:5443/managed-portal:20260519-f3f40b5-11`
|
|
- `ota.zhengxinshipin.com:5443/managed-portal-web:20260519-f3f40b5-11`
|
|
- `ota.zhengxinshipin.com:5443/people-flow-project:20260519-f3f40b5-11`
|
|
- `ota.zhengxinshipin.com:5443/store-dwell-alert:20260519-f3f40b5-11`
|
|
- Confirmed all four image tags exist in the registry on `10.8.0.14`.
|
|
- Extracted the published release bundle to `/opt/managed-portal-releases/managed-portal-20260519-f3f40b5-11`.
|
|
- Generated `/opt/managed-portal-releases/managed-portal-20260519-f3f40b5-11/deploy/managed-portal.runtime.env` from the published release, while keeping the host-specific data and output directories on `10.8.0.14`.
|
|
- Replaced the ad hoc `managed-portal`, `managed-portal-web`, `people-flow-project`, and `store-dwell-alert` containers with the installer-managed Compose project under `/opt/managed-portal-releases/managed-portal-20260519-f3f40b5-11/deploy/docker-compose.ota-release.yml`.
|
|
- Migrated `store-dwell-alert` to a schema-compatible config under `/opt/managed-portal-releases/managed-portal-20260519-f3f40b5-11/managed/store_dwell_alert/config/local.yaml` while preserving the current `192.168.0.5` RTSP source.
|
|
- Kept the current people-flow config/output/weights directories, but removed `gpus: all` from the release Compose file because the host currently fails `nvidia-container-cli` startup with an NVML driver/library mismatch. The new image falls back to CPU at runtime and still reports healthy.
|
|
- Verification:
|
|
- Published release manifest from `10.8.0.1` resolves to the four `20260519-f3f40b5-11` image tags above.
|
|
- Registry presence checks from `10.8.0.14` succeeded for all four image tags via `docker manifest inspect`.
|
|
- `sudo docker compose --env-file /opt/managed-portal-releases/managed-portal-20260519-f3f40b5-11/deploy/managed-portal.runtime.env -f /opt/managed-portal-releases/managed-portal-20260519-f3f40b5-11/deploy/docker-compose.ota-release.yml ps` showed:
|
|
- `managed-portal` -> `ota.zhengxinshipin.com:5443/managed-portal:20260519-f3f40b5-11`, `Up`
|
|
- `managed-portal-web` -> `ota.zhengxinshipin.com:5443/managed-portal-web:20260519-f3f40b5-11`, `Up`
|
|
- `people-flow-project` -> `ota.zhengxinshipin.com:5443/people-flow-project:20260519-f3f40b5-11`, `Up (healthy)`
|
|
- `store-dwell-alert` -> `ota.zhengxinshipin.com:5443/store-dwell-alert:20260519-f3f40b5-11`, `Up (healthy)`
|
|
- `sudo docker inspect` confirmed the four containers use the published registry image references; `people-flow-project` and `store-dwell-alert` report healthy.
|
|
- `curl -fsS http://127.0.0.1:13000` succeeded.
|
|
- `curl -fsS http://127.0.0.1:13000/api/managed-services` returned both managed services with `status: "running"`.
|
|
- `curl -fsS http://127.0.0.1:13000/api/managed-services/store_dwell_alert` returned the `192.168.0.5` RTSP source and `status: "running"`.
|
|
- `curl -fsS http://127.0.0.1:13000/api/managed-services/people_flow_project` returned the `192.168.0.4` RTSP source and `status: "running"`.
|