Docs: Docker mesh observability and sensitive-source isolation example

[SeCuReDmE-main-dev]

Issue: Docker Mesh Observability And Sensitive-Source Isolation Example

1. Summary

I would like to propose a documentation/example contribution for Docker-based CodeProject.AI Server mesh deployments.

The idea is to show a conservative pattern for running multiple CodeProject.AI Server containers with a shared mesh network, named per-server volumes, explicit TCP/UDP 32168 mappings, KnownMeshHostnames, Docker labels, and optional metadata-only observability.

This is intended as docs/example work only. It does not propose server behavior changes.

2. Context

CodeProject.AI Server is useful for local AI processing because requests can stay on the user's own machines. The Server Mesh feature is a strong fit for multi-machine or multi-container setups, but Docker networking and observability can be hard to reason about.

3. Problem

Docker mesh users need clearer guidance for:

• exposing TCP and UDP 32168;
• using KnownMeshHostnames when broadcast discovery is unreliable;
• separating persistent module state by server;
• identifying containers and workloads through Docker labels;
• collecting safe operational metadata without logging raw images, OCR text, request bodies, or secrets.

4. Proposed Contribution

Add one docs/example page covering:

• a three-server Docker Compose mesh example;
• named volumes for each server;
• one shared mesh network;
• one private network per workload;
• Docker labels for block identity;
• optional external observability on a separate network;
• sensitive-source logging guidance.

5. Why This Fits The Project

The existing project already supports local REST APIs, modules, Docker usage, and Server Mesh. This proposal only documents a safer deployment pattern around those existing primitives.

6. Educational / Technical Foundation

The page explains the request path:

application -> CodeProject.AI REST API -> route / queue -> analysis module -> result

And the mesh path:

client -> server A -> local module or forwarded mesh request -> server B/C -> result

It also explains why raw AI inputs can be sensitive even when they are images.

7. Implementation Shape

The first PR would be docs-only:

• one Markdown page under docs/;
• no source code changes;
• no module changes;
• no new dependencies;
• no default telemetry.

8. Validation Plan

The example is validated locally with:

docker compose config --quiet

Local endpoint checks:

http://localhost:33168 -> HTTP 200
http://localhost:33268 -> HTTP 200
http://localhost:33368 -> HTTP 200

9. Known Results

The local study-case mesh validated:

• Compose config passes;
• three CodeProject.AI Server containers respond;
• TCP and UDP 32168 are mapped;
• observability runs on a separate Docker network;
• no runtime source changes are needed.

10. Risks And Non-Goals

Non-goals:

• no CodeProject.AI Server behavior change;
• no Datadog or monitoring vendor requirement;
• no raw image or OCR logging;
• no module API change;
• no mesh routing change.

11. Maintainer Ask

Would maintainers be open to a docs-only PR for this Docker mesh observability and sensitive-source isolation example?

If yes, I can keep the first PR limited to the Docker mesh page and move optional observability details to a later follow-up if preferred.

12. Proposed PR Link

Pending.

13. References

• Server Mesh docs: https://codeproject.github.io/codeproject.ai/features/mesh.html
• Running in Docker docs: https://codeproject.github.io/codeproject.ai/install/running_in_docker.html
• CodeProject.AI API Reference: https://codeproject.github.io/codeproject.ai/api/api_reference.html