Docker Production Deployment

How to run VIESUS enhancement as a containerized GPU microservice — which interface to containerize and what to plan for in production.

The scenario: A platform runs VIESUS-based enhancement as a containerized microservice on a GPU instance. It must restart automatically, update the license without rebuilding the image, and scale horizontally by adding more GPU instances.

---

Recommended interface

Docker isn't a separate interface — you containerize the interface you already use: the CLI for batch jobs, or the Node.js module for a request-driven service.

This page covers the deployment concerns common to both. For the build details — Dockerfile, Compose, and run commands — see Running the VIESUS CLI in Docker and Running the Node.js module in Docker.

---

How it works

• A GPU-enabled image is built on an NVIDIA CUDA base, with the VIESUS packages and your chosen interface installed.
• The container is run with GPU access via the NVIDIA Container Toolkit, and the GUID is supplied at runtime (environment variable or secret) — never baked into the image.
• A health check lets your orchestrator know when the service is ready, and logs are emitted to stdout for aggregation.
• To scale, run one container per GPU and place a load balancer in front of them.

---

What to consider

Factor	Guidance
GPU access	Requires Docker plus the NVIDIA Container Toolkit on the host.
GUID security	Inject the GUID at runtime via an environment variable or secret; rotating it is just a restart, no rebuild. Never bake it into an image layer.
One GPU per container	Run a single worker per GPU to avoid VRAM contention and out-of-memory errors.
Restart policy	Use auto-restart so the service recovers from rare crashes.
Health checks	Allow a start-up grace period — initialization takes a few seconds — so a healthy container isn't killed prematurely.
Image size	A multi-stage build keeps the runtime image small.
Observability	Aggregate stdout logs and watch GPU utilisation and latency.