Production Considerations

An image that starts on your machine is not yet an image something else can operate. Whatever runs it in production — an orchestrator, a managed container service, or Compose on a single host — needs four things from the container that development never asked for.

It needs to know whether the application inside is working, not only whether the process is alive. It needs boundaries on memory and CPU so one container cannot starve its neighbours. It needs the logs somewhere it can collect them. And it needs the container to shut down in an orderly way, because containers are replaced routinely rather than exceptionally.

The logging point deserves stating up front, because it changes how you write the application rather than how you run it. Write log lines to standard output and standard error and nothing else. Every container platform captures those two streams and forwards them to wherever logs are kept, so a line written to stdout ends up searchable alongside every other service. A line written to a file inside the container is in a filesystem that disappears with the container, on a host nobody is watching, competing for disk with everything else on the machine.

FROM mcr.microsoft.com/dotnet/aspnet:9.0 AS final
WORKDIR /app
COPY --from=build --chown=appuser:appuser /app/publish .

ENV ASPNETCORE_HTTP_PORTS=8080
EXPOSE 8080
USER appuser

# Ask the application whether it is working. Not whether the process exists.
HEALTHCHECK --interval=30s --timeout=3s --start-period=20s --retries=3 \
  CMD ["dotnet", "/app/Anvi.Employees.Api.dll", "--health-check"]

ENTRYPOINT ["dotnet", "Anvi.Employees.Api.dll"]

• HEALTHCHECK runs a command inside the container on a schedule. Exit code 0 means healthy and 1 means unhealthy; docker ps then shows the status next to the container.
• --interval is how often the check runs, and --timeout is how long a single check may take before it counts as a failure. Keep the timeout well below the interval so checks cannot overlap.
• --start-period is a grace window after start-up during which failures do not count against the container. An application that spends 15 seconds warming up would otherwise be marked unhealthy before it ever had a chance.
• --retries is how many consecutive failures are needed before the status changes. More than one absorbs a single slow response without declaring an outage.
• The command here calls back into the application rather than using curl, because a minimal runtime image has no curl and adding one puts a network tool into production for the sake of a health check. Implementing a --health-check switch that exercises your readiness logic and returns an exit code keeps the dependency inside your own code.
• A health check should test something meaningful and stay cheap. Confirming the application can serve a request and reach its database is useful. Running a report on every interval is a self-inflicted load, and a check that calls three other services turns their problems into your unhealthy status.

services:
  api:
    image: anvi/employees-api:1.5.0
    environment:
      ASPNETCORE_ENVIRONMENT: Production
      ASPNETCORE_HTTP_PORTS: "8080"
      Logging__LogLevel__Default: Information
    ports:
      - "8080:8080"

    # Restart on failure, but stop trying if it fails immediately and forever
    restart: on-failure:5

    # How long to wait after SIGTERM before the process is killed
    stop_grace_period: 30s

    # Collected from stdout and stderr, with a cap so a loop cannot fill the disk
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

    deploy:
      resources:
        limits:
          memory: 512M
          cpus: "0.75"
        reservations:
          memory: 256M

• restart: on-failure:5 restarts the container when it exits non-zero, up to five times. Unlimited restarts hide a crash loop behind a container that looks like it is running; a cap makes the failure visible.
• stop_grace_period is the window between the stop signal and the kill. The default is 10 seconds, which is short for an application finishing a database transaction. Set it slightly longer than your slowest reasonable request, and no longer — the platform waits this long for every replacement.
• The logging block configures Docker's json-file driver, which captures stdout and stderr. max-size and max-file rotate the files and cap total disk use. Without them, one badly behaved loop can fill a host's disk, which takes down every container on that host rather than only yours.
• On a real platform the driver is usually not json-file — logs go to the cloud provider's logging service or a collector. The application does not change either way, which is the point of writing to stdout: the destination is an operational decision made outside your code.
• deploy.resources.limits sets the ceilings from the comparison above. Compose on a single host applies these; a swarm or orchestrator reads the same block. The memory number is a hard stop, so leave headroom above the application's observed peak.
• reservations is a floor rather than a ceiling — the amount the platform sets aside for this service when deciding what fits on a host. It does not restrict the container.
• Deliberately absent: no build section and no secret values. This is a deployment description referencing an image that was built and scanned elsewhere, with configuration and credentials supplied by the environment.