Docker, CI/CD & Git

#Containers and VMs: what is isolated?

Packaging an application with its runtime and dependencies in a known image reduces environment drift. A container is an isolated process sharing the host kernel; a VM has its own guest OS and kernel. Linux containers on Windows normally run inside a Linux VM rather than directly on the Windows kernel.

A container is not a complete security sandbox, backup system or orchestrator. Do not enable privileged mode merely to work around a permission error; identify the required mount and user.

#Images, layers, volumes and networks

An image is an immutable layered template; a container adds an ephemeral writable layer. A tag is a mutable name, while a digest identifies content. Layers support sharing and build caching, but deleting a secret in a later layer does not remove it from an earlier one.

These Bash commands require Docker and a local store-api:study image whose application listens on port 8080.

docker network create store-backend                 # (1)
docker volume create store-data                     # (2)
docker run -d --name store-api --network store-backend \
  -p 127.0.0.1:8080:8080 store-api:study              # (3)
docker logs store-api
docker inspect store-api
docker stats --no-stream store-api

A bind mount maps a host path; Docker manages a volume. Neither replaces backups and restore drills. Send logs to stdout and stderr rather than files in the writable layer.

#A multi-stage ASP.NET Core 10 Dockerfile

Shipping the SDK adds size and attack surface without helping runtime execution. This example assumes one Store.Api.csproj at the build-context root, without project references or central package files. For a larger solution, copy all referenced project and restore configuration files before restoring. Exclude bin, obj, .git and secret files through .dockerignore.

FROM mcr.microsoft.com/dotnet/sdk:10.0-noble AS build
WORKDIR /src
COPY Store.Api.csproj ./
RUN dotnet restore Store.Api.csproj                         # (1)
COPY . .
RUN dotnet publish Store.Api.csproj -c Release --no-restore \
    -o /out /p:UseAppHost=false                             # (2)

FROM mcr.microsoft.com/dotnet/aspnet:10.0-noble-chiseled-extra
WORKDIR /app
COPY --from=build /out/ ./
USER $APP_UID                                              # (3)
ENV ASPNETCORE_HTTP_PORTS=8080
EXPOSE 8080
ENTRYPOINT ["dotnet", "Store.Api.dll"]                      # (4)

Chiseled images omit a shell and package manager; the extra variant includes globalization dependencies such as ICU and tzdata. Do not add a curl or CMD-SHELL health check without the executable. Use an external probe. For real releases, pin base images by digest and schedule scanning and updates; version tags here aid readability. See chiseled documentation.

#SDK container publishing without a Dockerfile

If an application image only needs published output on a base image, the SDK can build it without a Dockerfile. This Bash example uses the previous ASP.NET Core project, .NET 10 SDK and a local Docker daemon.

dotnet publish Store.Api.csproj -c Release --os linux --arch x64 \
  /t:PublishContainer \
  -p:ContainerRepository=store-api \
  -p:ContainerImageTag=study \
  -p:ContainerBaseImage=mcr.microsoft.com/dotnet/aspnet:10.0-noble-chiseled-extra

PublishContainer creates the image; ContainerRepository names it and ContainerImageTag labels it. SDK publishing can also produce archives or publish to a registry through its configuration; not every output requires a daemon. Check ports, user and architecture rather than assuming Dockerfile equivalence.

Both approaches still need scanning, secrets outside images and immutable artifact identities. See SDK container publishing.

#Compose: readiness is more than process startup

A running database container may not yet accept connections. This local-development example uses the previous Dockerfile and an application configured with the Npgsql EF provider. Set DB_PASSWORD in the environment first and keep its value out of Git.

services:
  api:
    build: .
    ports: ["127.0.0.1:8080:8080"]
    environment:
      ConnectionStrings__Default: >-
        Host=db;Database=store;Username=store;Password=${DB_PASSWORD:?Set DB_PASSWORD}
    depends_on:
      db:
        condition: service_healthy # (1)
  db:
    image: postgres:17
    environment:
      POSTGRES_DB: store
      POSTGRES_USER: store
      POSTGRES_PASSWORD: ${DB_PASSWORD:?Set DB_PASSWORD}
    volumes: ["pgdata:/var/lib/postgresql/data"] # (2)
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U store -d store"] # (3)
      interval: 5s
      timeout: 3s
      retries: 10
      start_period: 10s
volumes:
  pgdata:

Run docker compose up --build -d and inspect logs. The API needs a readiness endpoint for required dependencies and bounded retries for transient failures. Environment variables suit this local example; inject production secrets from a secret store. See Compose startup order.

#CI/CD: build once and promote the same artifact

CI integrates small changes with automated builds and tests. Continuous delivery keeps a release ready for approved deployment; continuous deployment automatically deploys every passing change. This GitHub Actions example assumes a root solution, tests configured for dotnet test and a root Dockerfile. Action tags aid readability; pin reviewed full commit SHAs in an operational pipeline.

The CD jobs assume existing staging and production Container Apps in single-revision mode, configured to pull the image from GHCR; private packages need separate registry credentials. Define AZURE_CLIENT_ID, AZURE_TENANT_ID, AZURE_SUBSCRIPTION_ID, RESOURCE_GROUP, APP_NAME and HEALTH_URL in each GitHub environment. Configure environment-specific OIDC federation, limited deployment permissions and required production reviewers. This example does not provision infrastructure or run migrations; apply compatible changes through a separate step before rollout.

name: ci-cd
on:
  pull_request:
  push:
    branches: [main]
permissions:
  contents: read
concurrency:
  group: release-${{ github.ref }}
  cancel-in-progress: false
jobs:
  verify:
    runs-on: ubuntu-24.04
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-dotnet@v4
        with:
          dotnet-version: '10.0.x'
      - run: dotnet restore
      - run: dotnet build -c Release --no-restore -warnaserror
      - run: dotnet test -c Release --no-build # (1)
  image:
    needs: verify
    if: github.event_name == 'push'
    runs-on: ubuntu-24.04
    outputs:
      image: ${{ steps.publish.outputs.image }}
    permissions:
      contents: read
      packages: write
    env:
      GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      GH_USER: ${{ github.actor }}
      REPOSITORY: ${{ github.repository }}
      REVISION: ${{ github.sha }}
    steps:
      - uses: actions/checkout@v4
      - name: Build and push
        id: publish
        shell: bash
        run: |
          image="ghcr.io/${REPOSITORY,,}:$REVISION" # (2)
          printf '%s' "$GH_TOKEN" | docker login ghcr.io \
            -u "$GH_USER" --password-stdin
          docker build --pull -t "$image" .
          docker push "$image" # (3)
          digest=$(docker inspect --format='{{index .RepoDigests 0}}' "$image")
          echo "image=$digest" >> "$GITHUB_OUTPUT"
  deploy-staging:
    needs: image
    runs-on: ubuntu-24.04
    environment: staging # (4)
    concurrency: deploy-staging
    permissions:
      contents: read
      id-token: write
    env:
      IMAGE: ${{ needs.image.outputs.image }}
      GROUP: ${{ vars.RESOURCE_GROUP }}
      APP: ${{ vars.APP_NAME }}
      HEALTH_URL: ${{ vars.HEALTH_URL }}
    steps:
      - uses: azure/login@v2
        with:
          client-id: ${{ vars.AZURE_CLIENT_ID }}
          tenant-id: ${{ vars.AZURE_TENANT_ID }}
          subscription-id: ${{ vars.AZURE_SUBSCRIPTION_ID }}
      - run: az extension add --name containerapp --upgrade
      - run: az containerapp update -g "$GROUP" -n "$APP" --image "$IMAGE"
      - run: curl --fail --retry 5 --retry-connrefused "$HEALTH_URL" # (5)
  deploy-production:
    needs: [image, deploy-staging]
    runs-on: ubuntu-24.04
    environment: production # (6)
    concurrency: deploy-production
    permissions:
      contents: read
      id-token: write
    env:
      IMAGE: ${{ needs.image.outputs.image }}
      GROUP: ${{ vars.RESOURCE_GROUP }}
      APP: ${{ vars.APP_NAME }}
      HEALTH_URL: ${{ vars.HEALTH_URL }}
    steps:
      - uses: azure/login@v2
        with:
          client-id: ${{ vars.AZURE_CLIENT_ID }}
          tenant-id: ${{ vars.AZURE_TENANT_ID }}
          subscription-id: ${{ vars.AZURE_SUBSCRIPTION_ID }}
      - run: az extension add --name containerapp --upgrade
      - run: az containerapp update -g "$GROUP" -n "$APP" --image "$IMAGE"
      - run: curl --fail --retry 5 --retry-connrefused "$HEALTH_URL"

Workflow concurrency serializes releases for the same ref so older and newer rollouts cannot overlap. Add image and dependency scanning according to team policy, and update actions and base images regularly. A vulnerability report is only a gate if a policy fails the job. See GitHub Actions security.

#Promotion and deployment strategies

Rebuilding for each environment gives production something different from the tested artifact. Keep configuration and secrets outside it, promote the same image digest, and record version, configuration and migration status.

1. Start new instances and pass readiness, not merely process startup.
2. Shift traffic gradually and observe errors, tail latency and business outcomes.
3. During shutdown, remove an instance from routing and allow requests to finish.
4. If metrics regress, stop rollout or return to a compatible version.

Rolling back an image does not reverse database changes or refund a payment. Define data and external-side-effect recovery before deployment.

#Database migrations without service interruption

During a rolling deployment, old and new code share one schema. Dropping or directly renaming a column can immediately break old instances. Use expand, migrate and contract instead of one destructive change.

1. Expand: add a nullable column or a suitable default; assess DDL locks and cost on the real engine.
2. Deploy code compatible with both schemas. If dual-writing, keep updates consistent and plan for partial failures.
3. Backfill in small resumable batches while monitoring latency and locks.
4. Switch reads after validating data completeness; wait for all old instances and the rollback window to expire.
5. Contract: remove the old structure in a later release with tested backup and restore procedures.

Run migrations through a single dedicated job with appropriate permissions rather than every replica at startup. An idempotent script does not guarantee speed or absence of locks. Test with realistic data volumes and do not assume a Down migration safely restores deleted data.

#Kubernetes: desired state and health probes

Kubernetes reconciles desired state across a cluster; it does not repair business bugs. A Pod is a scheduling unit with containers sharing a network namespace. A Deployment manages replicas and rollouts; a Service provides stable discovery and routes to ready endpoints. Ingress defines HTTP routing and needs a controller. ConfigMaps hold configuration; Secrets hold sensitive values, but base64 is not encryption.

This fragment belongs inside a Deployment's Pod template. Replace the image with your release and implement the named endpoints.

containers:
  - name: api
    image: registry.example.com/store-api:release-1
    ports:
      - containerPort: 8080
    resources:
      requests: { cpu: "250m", memory: "256Mi" } # (1)
      limits: { cpu: "1", memory: "512Mi" }
    startupProbe:
      httpGet: { path: /health/live, port: 8080 }
      failureThreshold: 30
      periodSeconds: 2
    readinessProbe:
      httpGet: { path: /health/ready, port: 8080 } # (2)
    livenessProbe:
      httpGet: { path: /health/live, port: 8080 } # (3)

Do not make liveness depend on every external service and create restart storms during database outages. HPA changes replicas from metrics; it does not automatically expand database capacity. Use Kubernetes when its operational capabilities are needed; a managed container platform may be simpler.

#Git: understandable history and reversible decisions

Git records snapshots and relationships between commits. Merge combines histories and may fast-forward without a merge commit. Rebase recreates commits on a new base, changing their identities. Avoid rewriting shared history without explicit coordination.

These Bash commands assume a practice repository; adapt refs to the situation. Reset moves a branch pointer and may alter the index and working tree depending on mode. Do not use it to undo a published main commit.

git switch -c feature/order-limits
git rebase main                  # (1) replay this private branch
git revert HEAD                  # (2) create a new inverse commit
git bisect start
git bisect bad
git bisect good v1.0.0            # (3) known-good tag must exist
# Test each selected revision; mark it with git bisect good or bad.
git bisect reset

Conventional commits such as feat(orders): add booking limit and fix(payments): reject duplicate capture express intent and support automation. Useful messages and PRs matter more than prefixes alone. Protect main with review and CI.

#IIS and Linux with Nginx

Understand the hosting chain to diagnose 502 responses and redirect loops. On Windows, install the appropriate ASP.NET Core Hosting Bundle after IIS and use an application pool configured for No Managed Code. The ASP.NET Core Module hosts in-process inside w3wp or forwards to Kestrel out-of-process; identity permissions and the published web.config matter.

On Linux, supervise dotnet through systemd or a container orchestrator, with Nginx handling TLS and routing in front of Kestrel. This fragment belongs inside an Nginx server block for local HTTP; public deployment also needs TLS configuration.

location / {
    proxy_pass http://127.0.0.1:5000; # (1)
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme; # (2)
}

If Nginx and Kestrel run in separate containers, loopback cannot connect them; use service DNS on a private network. WebSockets need additional upgrade configuration. Persist and securely share Data Protection keys when replicas or deployments must preserve login cookies. See the official Nginx guide.