Meta tags:
description=Build a containerized ASP.NET Core Web API with a production-ready multi-stage Dockerfile, non-root security baseline, environment-based config, health checks, image hygiene with .dockerignore, and a repeatable build-tag-push ship workflow for Docker Hub, GHCR, and Azure Container Apps.;
keywords=Dockerize ASP.NET Core, multi-stage Dockerfile .NET, ASP.NET Core Docker production, Docker health check .NET, non-root Docker container, .dockerignore .NET, docker run ASP.NET Core, ship .NET container, GHCR push .NET, Azure Container Apps .NET, Docker build .NET 8, containerize ASP.NET Core API;

Headings (most frequently used words):

the, net, asp, core, docker, stage, images, build, health, multi, production, layer, and, container, in, what, dockerfile, non, root, file, endpoint, instruction, image, dockerignore, push, vs, why, check, for, workflow, you, of, folder, layout, user, tags, cloud, deployment, notes, api, containers, should, them, ports, using, how, without, healthcheck, base, use, does, resilience, polly, dockerizing, builds, clean, ready, ship, ll, table, contents, project, setup, concepts, every, developer, needs, once, run, lean, permission, baseline, configuration, via, environment, variables, checks, application, hygiene, caching, pinned, shipping, registry, common, questions, related, tutorials, target, todo, domain, registries, pin, port, mapping, host, complete, understanding, cache, strategy, built, config, layering, works, appsettings, json, structure, values, custom, database, connectivity, pinning, reproducibility, tag, repeatable, github, actions, automated, instead, single, running, as, actually, protect, against, alpine, or, slim, do, pass, secrets, to, baking, into, is, difference, between, my, matter, if, zero, downtime, v8, security, practice,

Text of the page (most frequently used words):
the (191), docker (89), and (85), build (55), image (53), for (50), run (50), container (44), net (41), #health (39), app (37), copy (36), from (36), dotnet (36), api (35), with (35), root (31), stage (30), 8080 (28), todo (27), this (26), kubernetes (26), not (26), layer (25), production (25), your (25), asp (24), core (24), check (24), non (24), user (24), dockerfile (24), push (24), use (23), secrets (23), env (22), images (22), that (21), publish (21), you (21), restore (20), healthcheck (19), microsoft (18), aspnet (18), ghcr (18), cache (17), file (17), running (16), multi (16), compose (16), are (16), only (16), dockerizedtodoapi (16), registry (15), every (15), tags (15), before (14), version (14), port (14), com (14), what (13), final (13), dockerignore (13), new (13), deployment (13), mcr (13), json (13), containers (12), local (12), files (12), environment (12), tag (12), inside (11), context (11), time (11), using (11), endpoint (11), instruction (11), ready (11), never (11), default (11), application (11), sha (11), name (11), curl (11), uses (10), into (10), runtime (10), packages (10), latest (10), database (10), without (9), runs (9), ports (9), group (9), yourusername (9), github (9), read (9), 5000 (9), workflow (9), chown (9), appsettings (9), add (9), readiness (8), layers (8), how (8), via (8), base (8), process (8), single (8), when (8), can (8), todos (8), verify (8), ship (8), digest (8), project (8), healthy (8), return (8), false (8), http (7), history (7), secret (7), builds (7), all (7), git (7), does (7), development (7), variables (7), built (7), native (7), cannot (7), system (7), set (7), manifest (7), mode (7), ownership (7), csproj (7), must (7), config (7), host (7), todoitem (7), int (7), _store (7), results (7), daemon (6), steps (6), separate (6), bin (6), different (6), probe (6), apps (6), alpine (6), instead (6), install (6), baseline (6), sdk (6), output (6), will (6), pod (6), correct (6), always (6), because (6), aspnetcore_environment (6), connectionstrings__defaultconnection (6), connection (6), cloud (6), setup (6), needed (6), source (6), status (6), returns (6), healthcheckresult (6), var (6), checks (6), configuration (6), dll (6), locked (6), lock (6), item (6), resilience (5), containerized (5), after (5), liveness (5), deployments (5), has (5), they (5), its (5), most (5), condition (5), key (5), size (5), dependency (5), any (5), available (5), write (5), bind (5), each (5), pull (5), than (5), spec (5), value (5), clean (5), inspect (5), hub (5), data (5), approach (5), appuser (5), pinned (5), need (5), unhealthy (5), localhost (5), public (5), expose (5), once (5), tutorials (4), polly (4), tutorial (4), security (4), probes (4), two (4), folder (4), changed (4), obj (4), why (4), tells (4), own (4), prevents (4), depends_on (4), azure (4), them (4), which (4), debian (4), but (4), have (4), should (4), 200 (4), common (4), same (4), cached (4), create (4), string (4), live (4), notes (4), password (4), type (4), yml (4), section (4), change (4), package (4), apt (4), reproducibility (4), pin (4), test (4), complete (4), start (4), cmd (4), values (4), databasehealthcheck (4), builder (4), program (4), keys (4), committed (4), first (4), needs (4), linux (4), update (4), uid (4), workdir (4), entrypoint (4), home (4), generate (4), useapphost (4), todoendpoints (4), updated (4), minimal (4), back (3), safe (3), error (3), these (3), directly (3), sends (3), just (3), including (3), large (3), serve (3), load (3), standalone (3), starting (3), dependencies (3), between (3), part (3), pass (3), gitignored (3), block (3), based (3), compatibility (3), slim (3), means (3), below (3), 1024 (3), podsecurity (3), entire (3), nuget (3), tooling (3), node (3), pulled (3), creation (3), immutable (3), imagepullpolicy (3), one (3), commit (3), makes (3), abc1234 (3), vars (3), server (3), template (3), main (3), actions (3), login (3), action (3), username (3), metadata (3), meta (3), outputs (3), deterministic (3), format (3), three (3), pattern (3), invalidates (3), rarely (3), specific (3), get (3), practical (3), developer (3), hygiene (3), service (3), configured (3), period (3), exit (3), dev (3), cancellationtoken (3), defaultconnection (3), connectivity (3), real (3), custom (3), maphealthchecks (3), more (3), writes (3), defaults (3), signing (3), aspnetcore_http_ports (3), structure (3), registries (3), privilege (3), filesystem (3), fail (3), permission (3), 1654 (3), exec (3), appgroup (3), executable (3), wrapper (3), locally (3), models (3), endpoints (3), static (3), idx (3), layout (3), dockerizing (3), next (2), zero (2), downtime (2), previous (2), jwt (2), ships (2), containerization (2), rollout (2), here (2), controls (2), lands (2), everything (2), significant (2), invalidation (2), since (2), last (2), expensive (2), orchestrators (2), used (2), balancers (2), ignored (2), mechanism (2), valuable (2), workflows (2), where (2), dependent (2), their (2), service_healthy (2), difference (2), managed (2), musl (2), libc (2), glibc (2), applications (2), exist (2), recommended (2), around (2), 200mb (2), critical (2), requires (2), thorough (2), command (2), highest (2), limits (2), blast (2), radius (2), clusters (2), admission (2), policy (2), regardless (2), level (2), restricted (2), actually (2), published (2), typically (2), smaller (2), faster (2), already (2), code (2), deploy (2), setting (2), mutable (2), remote (2), trivial (2), exactly (2), kubectl (2), containerapp (2), resource (2), target (2), secretref (2), conn (2), min (2), replicas (2), max (2), containerport (2), livenessprobe (2), httpget (2), path (2), initialdelayseconds (2), periodseconds (2), readinessprobe (2), branches (2), pull_request (2), image_name (2), ubuntu (2), contents (2), github_token (2), automatically (2), labels (2), gha (2), head (2), access (2), terminal (2), shipping (2), count (2), combine (2), commands (2), combined (2), instructions (2), possible (2), creates (2), copying (2), additional (2), producing (2), avoids (2), receive (2), patched (2), strict (2), sha256 (2), controlled (2), maximum (2), look (2), line (2), artifacts (2), ide (2), debug (2), sending (2), important (2), projects (2), tests (2), documentation (2), reduces (2), contains (2), reuse (2), caching (2), until (2), startup (2), race (2), through (2), replace (2), interval (2), 30s (2), timeout (2), failed (2), 15s (2), failures (2), retries (2), wget (2), flag (2), class (2), async (2), task (2), connstr (2), reachable (2), exception (2), webapplication (2), many (2), addhealthchecks (2), addcheck (2), self (2), traffic (2), maptodoendpoints (2), healthcheckoptions (2), predicate (2), both (2), mounts (2), like (2), strings (2), true (2), warning (2), aspnetcore (2), connectionstrings (2), https (2), domain (2), provider (2), stack (2), jwt__signingkey (2), layering (2), works (2), appear (2), private (2), piece (2), mount (2), writable (2), processes (2), created (2), named (2), switch (2), gid (2), point (2), directory (2), outside (2), still (2), cause (2), confusion (2), reproducible (2), release (2), changes (2), seconds (2), demonstrates (2), multiple (2), earlier (2), stages (2), forward (2), lean (2), variable (2), also (2), mapping (2), produces (2), times (2), shared (2), containerizing (2), concepts (2), broken (2), debugging (2), logic (2), mapget (2), notfound (2), nocontent (2), checked (2), tree (2), webapi (2), expected (2), end (2), 2026 (2), authentication, rate, limiting, cors, handling, securing, practice, retry, pipelines, circuit, breakers, bulkheads, clients, reliability, graceful, shutdown, patterns, introduced, related, begins, costs, transfer, repos, treats, reaches, enters, matter, operate, put, become, visible, objects, mounted, identity, vault, references, arrive, baking, primary, historically, had, issues, certain, globalization, bookworm, strong, edge, cases, viable, testing, vulnerability, allows, arbitrary, execution, privileges, directories, privileged, requirement, enforcing, sensible, enforcement, protect, against, copies, compiler, msbuild, hundreds, megabytes, separates, 800mb, 1gb, 250mb, attack, surface, pulls, cheaper, storage, questions, caches, continue, force, fresh, tagged, guarantees, identical, ifnotpresent, reschedule, may, currently, resolved, auditable, trace, exact, rollbacks, incidents, easier, diagnose, restart, ingress, external, referenced, prod, yaml, abbreviated, sections, apiversion, kind, valuefrom, secretkeyref, snippets, repository, jobs, permissions, required, checkout, log, actor, extract, owner, repo, raw, enable, is_default_branch, event_name, automated, traceable, export, rev, parse, short, prompts, authenticate, personal, token, scope, echo, stdin, succeeded, repeatable, place, reference, covers, destinations, anti, combining, reduce, per, keep, grouped, frequently, installs, occasionally, granular, don, unrelated, indiscriminately, duplicates, effectively, doubling, applied, duplication, shown, rebuild, regularly, obtain, inspection, fixes, dependabot, renovate, another, propose, updates, pinning, typical, drops, under, 1mb, runner, savings, compound, across, team, xxkb, measure, exclusion, gitignore, gitattributes, editor, vscode, suo, enter, pfx, docs, readme, changelog, modules, frontend, assets, present, node_modules, themselves, informational, slightly, fast, nothing, practices, achieve, order, maximises, wait, reports, won, passes, preventing, refused, falls, necessarily, service_started, manages, evaluated, itself, rely, availability, management, define, pointing, respectively, appears, conditions, often, 10s, long, considered, grace, consecutive, includes, include, apk, alternatively, tool, monitor, collect, null, state, none, iconfiguration, ihealthcheck, checkhealthasync, healthcheckcontext, try, getconnectionstring, isnullorempty, degraded, open, query, reachability, simulated, await, delay, simulate, catch, createbuilder, args, register, services, alive, reach, restarts, stops, 503, unavailable, otherwise, registration, there, distinct, semantics, rather, exposing, shows, closely, mimics, particularly, useful, working, moving, addkeyperfile, permanently, anyone, who, inspects, even, overwrite, sensitive, passwords, dotnet_running_in_container, my_secret, bakes, logging, loglevel, issuer, audience, signingkey, allowedhosts, double, underscore, hierarchy, separator, precedence, permanent, queryable, varies, environments, arrives, deploying, cluster, profile, enforced, pods, allow, escalation, satisfies, requirements, volumes, paths, protection, explicit, tmp, emptydir, securitycontext, readonlyrootfilesystem, binding, configure, listen, restriction, map, was, previously, denied, pre, simplest, efficient, whoami, shortcut, owned, users, range, 1000, footprint, addgroup, adduser, ingroup, disabled, ensures, subsequent, isolation, enforce, step, alongside, launch, adds, unnecessary, bytes, omit, specifically, entry, refusing, resolve, versions, behaviour, resulting, control, clear, message, naive, downloads, scratch, unless, warm, result, editing, rebuilding, takes, compounds, significantly, impact, understanding, strategy, src, recommends, lib, lists, silent, show, annotated, defining, ends, discarded, copied, aligns, upgrading, flags, official, listens, internally, maps, host_port, container_port, routes, 5001, 8081, interface, secure, accessible, other, machines, 127, avoid, floating, supported, major, minor, channel, receives, rebuilt, obtained, variants, jammy, belong, mean, distinction, matters, artifact, goes, deployed, gets, top, duplicated, disk, layered, snapshot, blueprint, instance, stored, acr, 101, mental, model, gaps, confirm, starts, responds, correctly, writing, harder, record, title, bool, iscomplete, readonly, list, void, mapgroup, withtags, firstordefault, mappost, mapput, findindex, mapdelete, removeall, entering, supply, registered, included, framework, sql, healthchecks, sqlserver, touching, started, press, ctrl, shut, down, scaffold, simple, enough, focus, mirrors, would, table, plus, logs, misbehaving, poisoning, ordering, injection, full, preserved, dedicated, replaces, optimised, then, repeat, folders, larger, ever, intermediate, july, march, hands, skip, content,

Text of the page (random words):
configuration defaults like aspnetcore_http_ports 8080 or dotnet_running_in_container true never use env for passwords api keys connection strings or signing secrets docker compose secrets block for local development for local multi container development with docker compose the secrets block mounts secret values as files at run secrets name rather than environment variables asp net core can read these using addkeyperfile run secrets in your configuration builder this approach avoids exposing secrets in docker inspect output which shows environment variables and more closely mimics how kubernetes mounts secrets as files it is particularly useful when working with docker compose before moving to kubernetes health checks application endpoint docker instruction there are two distinct health check layers in a containerized asp net core application they serve different orchestrators and have different semantics both are needed for a complete production setup layer 1 asp net core health check endpoint program cs health check registration endpoint copy var builder webapplication createbuilder args register health checks add as many as needed builder services addhealthchecks built in always returns healthy use for liveness is the process alive addcheck self healthcheckresult healthy process is running custom check can we reach the database use for readiness is the app ready to serve traffic addcheck databasehealthcheck database tags readiness var app builder build app maptodoendpoints liveness probe kubernetes restarts the pod if this returns unhealthy returns 200 ok with status healthy app maphealthchecks health live new healthcheckoptions predicate _ false only the always healthy self check readiness probe kubernetes stops sending traffic if this returns unhealthy returns 200 ok when all readiness checks pass 503 service unavailable otherwise app maphealthchecks health ready new healthcheckoptions predicate check check tags contains readiness combined endpoint used by docker healthcheck and load balancers app maphealthchecks health app run custom health check database connectivity health databasehealthcheck cs copy public class databasehealthcheck iconfiguration config ihealthcheck public async task healthcheckresult checkhealthasync healthcheckcontext context cancellationtoken cancellationtoken default try var connstr config getconnectionstring defaultconnection if string isnullorempty connstr return healthcheckresult degraded connection string is not configured open a connection and run a trivial query to verify reachability simulated connectivity check replace with real db check for production await task delay 10 cancellationtoken simulate async check return healthcheckresult healthy database is reachable return healthcheckresult healthy database is reachable catch exception ex return healthcheckresult unhealthy database connectivity check failed exception ex layer 2 docker healthcheck instruction dockerfile healthcheck instruction what each flag does copy healthcheck tells the docker daemon how to probe the container status appears in docker ps docker inspect and compose depends_on conditions healthcheck interval 30s how often docker runs the check timeout 10s how long before the check is considered failed start period 15s grace period on startup before failures count retries 3 consecutive failures before container unhealthy cmd curl f http localhost 8080 health exit 1 curl must be available in the base image aspnet 8 0 debian includes curl verify with docker run rm aspnet 8 0 which curl aspnet 8 0 alpine does not include curl use wget or install it run apk add no cache curl alternatively use the dotnet health check tool no curl dependency healthcheck cmd dotnet monitor collect output dev null wget qo http localhost 8080 health exit 1 check container health status docker inspect format state health status container id possible values starting healthy unhealthy none the docker healthcheck does not replace kubernetes probes when running on kubernetes the docker healthcheck instruction is ignored kubernetes manages liveness and readiness through its own probe mechanism configured in the pod spec the docker healthcheck is only evaluated by the docker daemon itself standalone docker run or docker compose do not rely on it for production availability management on kubernetes define livenessprobe and readinessprobe in your kubernetes deployment manifest pointing to health live and health ready respectively docker compose depends_on uses healthcheck status in a docker compose yml setting depends_on condition service_healthy makes compose wait until the dependency container reports a healthy docker healthcheck status before starting the dependent service this is valuable for local development your api container won t start until the database container passes its health check preventing the connection refused on startup race condition without healthcheck in the database image the condition falls back to service_started container running not necessarily ready and the race condition returns image hygiene dockerignore layer caching pinned tags a clean image is deterministic fast to build and contains nothing it does not need to run three practices achieve this a thorough dockerignore a layer order that maximises cache reuse and pinned base image tags the dockerignore file dockerignore complete file for asp net core projects copy build output the single most important exclusion without this every dotnet build invalidates all copy layers in docker bin obj git history never needed in an image can be large git gitignore gitattributes ide and editor files vs vscode user suo test projects not needed in production images tests test tests csproj secret files critical these must never enter the build context env env secrets json appsettings local json pfx key ci cd and documentation github docs readme md changelog md md node modules if frontend assets present node_modules docker files themselves informational reduces build context size slightly dockerfile docker compose dockerignore measure your build context before and after run docker build no cache 2 1 head 5 and look for the line sending build context to docker daemon x xxkb without a dockerignore a typical net project sends 50 200mb of build artifacts and ide files with a correct dockerignore it drops to under 1mb the difference in build time on a remote docker daemon or ci runner is significant and the cache invalidation savings not re running expensive restore steps because a bin debug file changed compound across every developer on the team pinning base images for reproducibility dockerfile pinned tags with sha digest for maximum reproducibility copy practical default rebuild regularly to receive patched net 8 images from mcr microsoft com dotnet aspnet 8 0 as final strict reproducibility pin an immutable registry digest obtain the digest from your registry or image inspection tooling from mcr microsoft com dotnet aspnet 8 0 sha256 manifest digest as final a digest pin will not receive security fixes automatically use dependabot renovate or another controlled process to propose and test digest updates copy chown avoids a separate run chown layer each run instruction creates a new image layer running run chown r appuser app after copying files creates an additional layer that duplicates all the file data with new ownership metadata effectively doubling the layer size for large publish outputs use copy chown app app from publish publish instead the ownership is applied as part of the copy instruction in a single layer producing a smaller image without the duplication this is the approach shown in section 4 don t combine unrelated run commands indiscriminately a common docker anti pattern is combining every run into a single layer to reduce layer count docker s layer cache is per instruction if you combine apt get install curl with your user creation and ownership commands into one run a change to any part of that combined command invalidates the entire cached layer and re runs everything keep run instructions grouped by how frequently they change os package installs rarely user creation rarely application specific setup occasionally separate them so the cache is as granular as possible shipping the image registry push cloud deployment notes with a production ready dockerfile in place the ship workflow is three steps build with a deterministic tag push to a registry and reference the tag in your deployment this section covers that workflow for docker hub ghcr and the two most common cloud destinations build tag and push the repeatable workflow terminal build tag push to docker hub and ghcr copy build use a git sha as the version tag for deterministic traceable deployments export version git rev parse short head docker build t my todo api version t my todo api latest f dockerfile verify the image is clean check size and layers docker image inspect my todo api version format size docker history my todo api version push to docker hub docker login prompts for username password docker tag my todo api version yourusername todo api version docker push yourusername todo api version docker push yourusername todo api latest push to github container registry ghcr authenticate with a github personal access token write packages scope echo github_token docker login ghcr io u username password stdin docker tag my todo api version ghcr io yourusername todo api version docker push ghcr io yourusername todo api version pull and run from ghcr to verify the push succeeded docker pull ghcr io yourusername todo api version docker run rm p 5000 8080 e aspnetcore_environment production e connectionstrings__defaultconnection data source data todos db ghcr io yourusername todo api version github actions automated build and push github workflows docker push yml ci build and push to ghcr copy name build and push docker image on push branches main pull_request branches main env registry ghcr io image_name github repository jobs build and push runs on ubuntu latest permissions contents read packages write required to push to ghcr steps uses actions checkout v4 name log in to ghcr uses docker login action v3 with registry env registry username github actor password secrets github_token automatically available no setup needed name extract docker metadata id meta uses docker metadata action v5 with images env registry env image_name tags type sha ghcr io owner repo sha abc1234 type raw value latest enable is_default_branch name build and push uses docker build push action v6 with context push github event_name pull_request tags steps meta outputs tags labels steps meta outputs labels cache from type gha github actions cache for docker layers cache to type gha mode max cloud deployment notes azure container apps kubernetes deployment snippets copy azure container apps az containerapp create name todo api resource group my rg environment my env image ghcr io yourusername todo api sha abc1234 target port 8080 ingress external env vars aspnetcore_environment production connectionstrings__defaultconnection secretref db conn min replicas 1 max replicas 5 secrets are managed by container apps referenced via secretref az containerapp secret set name todo api resource group my rg secrets db conn server prod db database todos kubernetes deployment manifest kubernetes deployment yaml abbreviated key sections apiversion apps v1 kind deployment spec template spec containers name todo api image ghcr io yourusername todo api sha abc1234 ports containerport 8080 env name aspnetcore_environment value production name connectionstrings__defaultconnection valuefrom secretkeyref name todo api secrets key db connection string livenessprobe uses asp net core health live endpoint httpget path health live port 8080 initialdelayseconds 15 periodseconds 30 readinessprobe uses asp net core health ready endpoint httpget path health ready port 8080 initialdelayseconds 5 periodseconds 10 tag with git sha not just latest in every deployment using latest in a kubernetes deployment manifest means every kubectl rollout restart or pod reschedule may pull a different image than the one currently running because latest is resolved at pull time not at deploy time tag every production deployment with the git commit sha this makes deployments auditable you can trace an image back to the exact commit that built it rollbacks trivial kubectl set image to the previous sha and incidents easier to diagnose the tag in your pod spec tells you exactly what code is running set imagepullpolicy always when using mutable tags kubernetes caches images on each node if you push a new image to the same latest tag and kubernetes has already pulled it the node will continue using the cached version and your new code will not deploy set imagepullpolicy always to force a fresh pull on every pod creation this is the correct setting when using mutable tags when using immutable sha tagged images imagepullpolicy ifnotpresent is safe and faster the sha guarantees the cached image is identical to the remote common questions why use a multi stage dockerfile for asp net core instead of a single stage a single stage build copies the entire sdk into your final image the c compiler msbuild nuget cache and hundreds of megabytes of build tooling your running application never uses a multi stage build separates the sdk stage restore build publish from the runtime stage only the published output lands in the final image a single stage image is typically 800mb 1gb a multi stage image using aspnet 8 0 is around 200 250mb a smaller attack surface faster pulls and cheaper registry storage what does running a docker container as non root actually protect against running as root inside a container means any vulnerability that allows arbitrary command execution runs with the highest privileges available inside that container a non root user limits the blast radius the process cannot write to system directories cannot install packages and cannot bind to privileged ports below 1024 on kubernetes a non root user is a requirement for clusters enforcing the restricted podsecurity admission policy and a sensible baseline for all clusters regardless of enforcement level should i use alpine or slim base images for production asp net core containers alpine images use musl libc instead of glibc which most net applications are built for microsoft s primary net images are debian based glibc alpine based net images exist but have historically had compatibility issues with certain native dependencies and globalization packages the recommended default is aspnet 8 0 debian bookworm slim around 200mb with strong compatibility if image size is critical and your app has no native dependency edge cases aspnet 8 0 alpine is viable but requires thorough testing before production how do i pass secrets to a docker container without baking them into the image never use env or copy to put secrets into an image they becom...