Running Manex.Web in Docker#

Multi-stage Dockerfile at the repo root builds src/Manex.Web into a minimal aspnet:8.0 runtime image. The image runs as the non-root app user and exposes port 8080.

Build#

docker build -t manex-web:local .

Run#

Supply the same connection string + JWT signing key you use for local dev via environment variables (double-underscore = configuration section separator):

docker run --rm -p 8080:8080 \
  -e ConnectionStrings__eManEx="Server=host.docker.internal,1433;Database=BcomMX_01_04;User Id=sa;Password=Cube2!DevPwd;TrustServerCertificate=true" \
  -e Jwt__SigningKey="<32+ char dev signing key>" \
  -e Jwt__Issuer="cube2-backend-local" \
  -e Jwt__Audience="cube2-backend-local" \
  -e MachineKey__ValidationKey="<hex>" \
  -e MachineKey__DecryptionKey="<hex>" \
  manex-web:local

Health endpoints#

Two endpoints, mapped in Program.cs:

PathPurposeContainer use
/healthLiveness — process is upDocker HEALTHCHECK, k8s liveness
/readyReadiness — SQL Server is reachablek8s readiness / load-balancer

/health returns 200 as long as the ASP.NET Core host is running. /ready returns 503 while SQL is unreachable so the LB won’t send traffic to a container that can’t answer.

Notes#

  • User: image runs as app (uid 1654) — non-root by default in the official dotnet/aspnet:8.0 base image.
  • Secrets: .dockerignore excludes appsettings.Development.json, .env*, and secrets.json — nothing local ever ends up in a layer.
  • Deploy pipeline: BFC-37 (blocked on ops — Azure Container Apps vs. App Service vs. self-hosted decision).