Deploying Containerized Applications

Table of Contents

1. Course Overview
2. Deploying with Docker Compose
   • 2.1 Choosing a Container Platform
   • 2.2 Running with Scripts
   • 2.3 Understanding Docker Compose
   • 2.4 Modeling and Running with Docker Compose
   • 2.5 Environment-based Configuration
   • 2.6 Scaling with Docker Compose
   • 2.7 Docker Compose Limitations
3. Orchestration with Docker Swarm
   • 3.1 Understanding Container Orchestration
   • 3.2 Deploying to Docker Swarm
   • 3.3 Configuration in the Cluster
   • 3.4 Scaling and Reliability in Swarm
4. Kubernetes
   • 4.1 Kubernetes Cluster Architecture
   • 4.2 Modeling with Pods, Deployments and Services
   • 4.3 Deploying to Kubernetes
   • 4.4 ConfigMaps and Secrets
   • 4.5 ReplicaSets, Scaling and Updates
5. Cloud Container Services
   • 5.1 Azure Kubernetes Service (AKS)
   • 5.2 Azure Container Instances (ACI)
   • 5.3 AWS Elastic Container Service (ECS)
6. Reference Tables
7. Essential Commands

1. Course Overview

Demo Application: Wired Brain Coffee

Throughout the course, a distributed application called Wired Brain Coffee is used. It is composed of several services:

Course Philosophy

Containers are built on open standards (image format, runtime API), popularized by Docker. The fundamental advantage is portability: the same image can run on local Docker, Docker Swarm, Kubernetes, AKS, ACI, or ECS without modifying source code.

Learning Path

flowchart LR
    A[Docker CLI Scripts] --> B[Docker Compose\nSingle Server]
    B --> C[Docker Swarm\nMulti-node Cluster]
    C --> D[Kubernetes\nAdvanced Orchestration]
    D --> E[AKS\nAzure Kubernetes Service]
    D --> F[ACI\nAzure Container Instances]
    D --> G[ECS\nAWS Elastic Container Service]

    style A fill:#f0f0f0
    style B fill:#dce8f7
    style C fill:#c3d9f0
    style D fill:#a0c4e8
    style E fill:#7db0df
    style F fill:#7db0df
    style G fill:#7db0df

2. Deploying with Docker Compose

2.1 Choosing a Container Platform

Three main themes guide the choice of a platform:

2.2 Running with Scripts

Before Docker Compose, the classic approach was to use PowerShell/Bash scripts to manually create Docker resources. This is the imperative approach:

# Imperative approach — fragile and hard to maintain
docker network create app-net

docker run -d --name products-db `
  --network app-net `
  -e POSTGRES_PASSWORD=secret123 `
  psdockerrun/products-db

docker run -d --name products-api `
  --network app-net `
  -p 8081:80 `
  psdockerrun/products-api

docker run -d --name stock-api `
  --network app-net `
  -p 8082:8080 `
  psdockerrun/stock-api

docker run -d --name web `
  --network app-net `
  -p 8080:80 `
  psdockerrun/web

Problems with this approach:

• Not idempotent (error if the network already exists)
• Configuration scattered across docker run commands
• Difficult to maintain and evolve

2.3 Understanding Docker Compose

Docker Compose consists of two parts:

1. The specification: a YAML modeling language to describe all application components, their configurations and connections
2. The CLI tool: docker compose (or docker-compose) to deploy the application from the specification

The approach is declarative: you describe the desired final state and Compose handles getting there.

flowchart TD
    A[Source Code\n.git/] --> D[Git Repo]
    B[Dockerfiles\nImages] --> D
    C[docker-compose.yml\nSpecification] --> D
    D --> E[git clone + docker compose up]
    E --> F[Application Deployed]

2.4 Modeling and Running with Docker Compose

Base docker-compose.yml file

# Module 2 — Demo 2: Wired Brain Coffee Application with Docker Compose
services:

  products-db:
    image: psdockerrun/products-db
    ports:
      - "5432:5432"
    environment:
      - POSTGRES_PASSWORD=secret123
    networks:
      - app-net

  products-api:
    image: psdockerrun/products-api
    ports:
      - "8081:80"
    networks:
      - app-net
    depends_on:
      - products-db

  stock-api:
    image: psdockerrun/stock-api
    ports:
      - "8082:8080"
    networks:
      - app-net
    depends_on:
      - products-db

  web:
    image: psdockerrun/web
    ports:
      - "8080:80"
    networks:
      - app-net
    depends_on:
      - products-api
      - stock-api

networks:
  app-net:

Essential Commands

# Start the application (desired state)
docker compose up -d

# View running containers
docker compose ps

# View logs
docker compose logs --follow web

# Stop and remove resources
docker compose down

2.5 Environment-based Configuration

With Docker Compose, you can separate sensitive configuration data (secrets) from non-sensitive data (configs), using configs and secrets external to the Compose file.

# Module 2 — Demo 2: With configs and secrets (Docker Swarm compatible)
version: "3.7"

services:
  products-api:
    image: psdockerrun/products-api
    ports:
      - "8081:80"
    configs:
      - source: products-api-config
        target: /app/config/application.properties
    secrets:
      - source: products-api-dbconfig
        target: /app/config/db/application.properties
    networks:
      - app-net
    depends_on:
      - products-db

  web:
    image: psdockerrun/web
    ports:
      - "8080:80"
    environment:
      - Environment=TEST
    configs:
      - source: web-logging
        target: /app/config/logging.json
    secrets:
      - source: web-api
        target: /app/secrets/api.json
    networks:
      - app-net

networks:
  app-net:
    name: app-net-test

configs:
  products-api-config:
    external: true
  web-logging:
    external: true

secrets:
  products-db-password:
    external: true
  products-api-dbconfig:
    external: true
  web-api:
    external: true

2.6 Scaling with Docker Compose

To allow a service to scale, you must not specify a fixed source port (Docker will assign a random port):

services:
  stock-api:
    image: psdockerrun/stock-api
    ports:
      - "8080"      # Target port only — Docker assigns a random source port
    networks:
      - app-net
    scale: 3        # Start 3 replicas

# Scale on the fly
docker compose up -d --scale stock-api=3

2.7 Docker Compose Limitations

3. Orchestration with Docker Swarm

3.1 Understanding Container Orchestration

A container orchestrator manages a cluster of machines (nodes), each with a Docker runtime, to run containers in a distributed manner.

flowchart TB
    subgraph "Control Plane (Managers)"
        M1[Manager 1\nControl Plane] 
        M2[Manager 2\nControl Plane]
        DB[(Shared\nDistributed DB)]
        M1 <--> DB
        M2 <--> DB
    end
    subgraph "Worker Nodes"
        W1[Worker 1\nDocker Runtime]
        W2[Worker 2\nDocker Runtime]
        W3[Worker 3\nDocker Runtime]
    end
    M1 -->|"Work + Health"| W1
    M1 -->|"Work + Health"| W2
    M1 -->|"Work + Health"| W3
    W1 -->|Heartbeat| M1
    W2 -->|Heartbeat| M1
    W3 -->|Heartbeat| M1

Advantages of orchestration:

• Run many containers across multiple machines
• Self-healing: automatic replacement of failing containers
• Scaling across the entire cluster
• Rolling updates without service interruption
• Networking managed by the cluster (ingress network)

3.2 Deploying to Docker Swarm

Initialize the Swarm

# A single node becomes the manager (control plane)
docker swarm init

# Join the cluster from another node (using the provided token)
docker swarm join --token <TOKEN> <MANAGER_IP>:2377

# List cluster nodes
docker node ls

Deploy an Application (Stack)

Docker Swarm uses the same Docker Compose format to deploy stacks:

# Deploy the "wiredbrain" stack from the Compose file
docker stack deploy -c docker-compose.yml wiredbrain

# List active stacks
docker stack ls

# List containers (tasks) in the stack
docker stack ps wiredbrain

# List services
docker service ls

# View containers of a specific service
docker service ps wiredbrain_stock-api

3.3 Configuration in the Cluster

Docker Swarm provides two objects for storing configuration:

# Create a config object from a file
docker config create products-api-config ./config/application.properties
docker config create web-logging ./config/logging.json

# Create a secret from a file
docker secret create products-db-password ./secrets/pg-password.txt
docker secret create products-api-dbconfig ./secrets/db-config.properties

# List configs and secrets
docker config ls
docker secret ls

docker-compose.yml for Docker Swarm with configs/secrets

version: "3.7"

services:
  products-db:
    image: psdockerrun/products-db
    environment:
      - POSTGRES_PASSWORD_FILE=/secrets/pg-password
    secrets:
      - source: products-db-password
        target: /secrets/pg-password
        mode: 0400
    networks:
      - app-net

  products-api:
    image: psdockerrun/products-api
    configs:
      - source: products-api-config
        target: /app/config/application.properties
    secrets:
      - source: products-api-dbconfig
        target: /app/config/db/application.properties
    networks:
      - app-net
    depends_on:
      - products-db

configs:
  products-api-config:
    external: true
  web-logging:
    external: true

secrets:
  products-db-password:
    external: true
  products-api-dbconfig:
    external: true

3.4 Scaling and Reliability in Swarm

Configure replicas in the Compose file

services:
  stock-api:
    image: psdockerrun/stock-api
    ports:
      - "8082:8080"
    networks:
      - app-net
    deploy:
      replicas: 2          # Number of containers to run
      update_config:
        parallelism: 1     # Update one container at a time
        delay: 10s
      restart_policy:
        condition: on-failure

Self-healing demonstration

# Find the stock-api container ID
docker container ls --filter name=wiredbrain_stock-api -q

# Simulate a failure (kill the process inside the container)
docker container ls --filter name=wiredbrain_stock-api -q | xargs docker exec kill 1

# Swarm detects the failure and automatically recreates the container
docker service ps wiredbrain_stock-api

Rolling Update in Swarm

# Update the image of a service (rolling update)
docker service update --image psdockerrun/web:v2 wiredbrain_web

# View rollout status
docker service ps wiredbrain_web

4. Kubernetes

4.1 Kubernetes Cluster Architecture

Kubernetes (K8s) is the most popular container orchestrator. Its architecture is similar to Docker Swarm but with more complexity and power.

flowchart TB
    subgraph "Control Plane"
        API[API Server\nkube-apiserver]
        ETCD[(etcd\nDistributed DB)]
        SCHED[Scheduler]
        CM[Controller\nManager]
        API <--> ETCD
        API <--> SCHED
        API <--> CM
    end
    subgraph "Worker Node 1"
        K1[kubelet]
        CR1[Container Runtime\ncontainerd]
        P1[Pod A\nContainer]
        P2[Pod B\nContainer]
        K1 --> CR1
        CR1 --> P1
        CR1 --> P2
    end
    subgraph "Worker Node 2"
        K2[kubelet]
        CR2[Container Runtime]
        P3[Pod C\nContainer]
        K2 --> CR2
        CR2 --> P3
    end
    kubectl([kubectl\nCLI]) -->|API calls| API
    API --> K1
    API --> K2

Interacting with Kubernetes:

• Everything goes through the API Server
• The kubectl CLI tool sends requests to the API
• The desired state is stored in etcd (distributed database)
• The Controller Manager ensures the actual state matches the desired state

4.2 Modeling with Pods, Deployments and Services

flowchart LR
    subgraph "Kubernetes Resources"
        SVC[Service\nNetworking / DNS]
        DEP[Deployment\nLifecycle Management]
        RS[ReplicaSet\nReplica Count]
        POD1[Pod\nContainer]
        POD2[Pod\nContainer]
        POD3[Pod\nContainer]
    end
    SVC -->|label selector| POD1
    SVC --> POD2
    SVC --> POD3
    DEP --> RS
    RS --> POD1
    RS --> POD2
    RS --> POD3
    EXT[External Traffic] --> SVC

4.3 Deploying to Kubernetes

Prerequisites

# Verify the cluster is operational
kubectl get nodes

# View all namespaces
kubectl get namespaces

Service for the database (ClusterIP — internal only)

# products-db-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: products-db
spec:
  ports:
    - port: 5432
      targetPort: 5432
  selector:
    app: products-db
  type: ClusterIP          # Accessible only from within the cluster

Deployment for the database

# products-db-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: products-db
spec:
  selector:
    matchLabels:
      app: products-db
  template:
    metadata:
      labels:
        app: products-db
    spec:
      containers:
        - name: db
          image: psdockerrun/products-db
          env:
            - name: POSTGRES_PASSWORD
              value: secret123

Service and Deployment for the web front-end (LoadBalancer — externally exposed)

# web.yaml — Service (LoadBalancer) + Deployment combined
apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  ports:
    - port: 8080
      targetPort: 80
  selector:
    app: web
  type: LoadBalancer       # Exposes an external IP (cloud) or localhost (Docker Desktop)
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: psdockerrun/web

Apply the manifests

# Apply a single file
kubectl apply -f products-db-service.yaml

# Apply all files in a folder
kubectl apply -f ./wiredbrain/

# Verify created resources
kubectl get all

# View details of a Pod
kubectl describe pod <pod-name>

# Access a Pod (local port-forwarding)
kubectl port-forward pod/<pod-name> 8080:80

4.4 ConfigMaps and Secrets

Namespace for isolation

# namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: wb-test

ConfigMap (non-sensitive data)

apiVersion: v1
kind: ConfigMap
metadata:
  name: products-api-config
  namespace: wb-test
data:
  application.properties: |
    server.port=80
    spring.datasource.url=jdbc:postgresql://products-db:5432/postgres
    logging.level.root=WARN

Secret (sensitive data — base64 encoded)

apiVersion: v1
kind: Secret
metadata:
  name: web-api
  namespace: wb-test
type: Opaque
stringData:
  api.json: |
    {
      "ProductsApi": "http://products-api",
      "StockApi": "http://stock-api"
    }

# Create a secret imperatively (without exposing data in the repo)
kubectl create secret generic web-api \
  --from-file=api.json=./secrets/api.json \
  --namespace wb-test

Deployment with ConfigMap and Secret mounted as volumes

# web.yaml — with ConfigMap and Secret, namespace wb-test
apiVersion: v1
kind: Service
metadata:
  name: web
  namespace: wb-test
spec:
  ports:
    - port: 8081
      targetPort: 80
  selector:
    app: web
  type: LoadBalancer
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  namespace: wb-test
spec:
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: psdockerrun/web
          env:
            - name: Environment
              value: TEST
          volumeMounts:
            - name: logging-config
              mountPath: "/app/config"
              readOnly: true
            - name: api-config
              mountPath: "/app/secrets"
              readOnly: true
      volumes:
        - name: logging-config
          configMap:
            name: web-logging      # ConfigMap mounted as a folder
        - name: api-config
          secret:
            secretName: web-api    # Secret mounted as a folder

4.5 ReplicaSets, Scaling and Updates

Deployment with replicas and rolling update

# web.yaml — with 3 replicas, namespace wb-test-2
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  namespace: wb-test-2
spec:
  replicas: 3              # Kubernetes always guarantees 3 active Pods
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: psdockerrun/web
          env:
            - name: Environment
              value: TEST
            - name: Debug__ShowHost
              value: "true"
          volumeMounts:
            - name: logging-config
              mountPath: "/app/config"
              readOnly: true
            - name: api-config
              mountPath: "/app/secrets"
              readOnly: true
      volumes:
        - name: logging-config
          configMap:
            name: web-logging
        - name: api-config
          secret:
            secretName: web-api

Deployment management commands

# View rollout status
kubectl rollout status deployment/web -n wb-test

# Deployment version history
kubectl rollout history deployment/web

# Roll back to the previous version
kubectl rollout undo deployment/web

# Roll back to a specific version
kubectl rollout undo deployment/web --to-revision=2

# Update the image (rolling update)
kubectl set image deployment/web web=psdockerrun/web:v2

Rolling update mechanism

sequenceDiagram
    participant Dev as Developer
    participant K8s as Kubernetes API
    participant RS1 as ReplicaSet v1\n(3 Pods)
    participant RS2 as ReplicaSet v2\n(0 Pods)

    Dev->>K8s: kubectl apply -f web.yaml (image v2)
    K8s->>RS2: Create new ReplicaSet
    loop Rolling Update
        RS2->>RS2: Start Pod v2 (healthy?)
        K8s->>RS1: Scale down Pod v1
    end
    Note over RS1,RS2: RS1: 0 Pods, RS2: 3 Pods
    K8s-->>Dev: Rollout complete

• Any change to spec.template (image, env vars, volumes) creates a new ReplicaSet
• The Deployment ramps up the new RS and scales down the old one to 0
• On failure, the rollout is paused — the new RS remains with 1 failing Pod

5. Cloud Container Services

Comparative Architecture

flowchart LR
    subgraph "On-Premise / Self-managed"
        A[Docker Compose\nSingle Server] 
        B[Docker Swarm\nDIY Cluster]
        C[Kubernetes\nDIY Cluster]
    end
    subgraph "Managed Cloud"
        D[AKS\nAzure Kubernetes Service]
        E[ACI\nAzure Container Instances]
        F[ECS\nAWS Elastic Container Service]
    end
    
    A --> B --> C
    C --> D
    C --> E
    C --> F

5.1 Azure Kubernetes Service (AKS)

AKS is a fully managed Kubernetes service by Azure. The control plane is invisible — Azure handles it. You use the same tools and YAML manifests as standard Kubernetes.

Creating the AKS cluster

# Create an AKS cluster via Azure CLI
az aks create \
  --resource-group myResourceGroup \
  --name ps-docker-run \
  --kubernetes-version 1.28.0 \
  --node-count 3 \
  --generate-ssh-keys

# Retrieve credentials for kubectl
az aks get-credentials \
  --resource-group myResourceGroup \
  --name ps-docker-run

# Verify the connection
kubectl get nodes

Integration with Azure Database for PostgreSQL

# Create a managed PostgreSQL server
az postgres server create \
  --resource-group myResourceGroup \
  --name wiredbraincoffee-db \
  --location eastus \
  --admin-user psadmin \
  --admin-password <PASSWORD> \
  --sku-name GP_Gen5_2

# Create the application database
az postgres db create \
  --resource-group myResourceGroup \
  --server-name wiredbraincoffee-db \
  --name wiredbrain

AKS key points

Manifest with resource requests (best practice)

containers:
  - name: web
    image: psdockerrun/web
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

5.2 Azure Container Instances (ACI)

ACI is a serverless container service — no VMs, no cluster, no control plane to manage. You deploy directly from the Docker CLI.

ACI deployment flow

flowchart LR
    LC[Local Docker CLI] -->|docker login azure| AZ[Azure Auth]
    AZ -->|docker context create aci| CTX[ACI Context]
    CTX -->|docker context use acimycontext| SW[Switch Context]
    SW -->|docker compose up| ACI[Azure Container Instances\nContainer Group]
    ACI -->|Auto public IP| USER[Users]

ACI configuration and deployment

# Log in to Azure with Docker
docker login azure

# Create an ACI context
docker context create aci acimycontext \
  --resource-group myResourceGroup \
  --location eastus

# Switch to the ACI context
docker context use acimycontext
# or via environment variable
export DOCKER_CONTEXT=acimycontext

# Deploy with docker compose (not docker-compose!)
docker compose up

# View running containers in ACI
docker ps

# View logs
docker logs <container-name>

Simplified docker-compose.yml for ACI

# ACI manages networking between containers — no need to define networks
version: '3.9'

services:
  products-api:
    image: psdockerrun/products-api
    secrets:
      - source: products-api-config
        target: /app/config/application.properties

  stock-api:
    image: psdockerrun/stock-api
    env_file:
      - ./secrets/stock-api.env

  web:
    image: psdockerrun/web
    ports:
      - "80:80"            # ACI automatically creates the public IP
    environment:
      Environment: ''
      Logging__LogLevel__Default: 'Warning'
    secrets:
      - source: web-api
        target: /app/secrets/api.json
    depends_on:
      - products-api
      - stock-api

secrets:
  products-api-config:
    file: ./secrets/application.properties
  web-api:
    file: ./secrets/api.json

5.3 AWS Elastic Container Service (ECS)

ECS is the AWS equivalent of ACI — a managed container service that integrates with the AWS ecosystem (RDS, Secrets Manager, IAM, etc.).

ECS context configuration

# Required AWS environment variables
export AWS_ACCESS_KEY_ID=<your-access-key>
export AWS_SECRET_ACCESS_KEY=<your-secret-key>
export AWS_DEFAULT_REGION=us-east-1

# Create an ECS context
docker context create ecs aws \
  --from-env   # Reads credentials from environment variables

# List all available contexts
docker context ls

# Use the ECS context
export DOCKER_CONTEXT=aws

Managing secrets with AWS Secrets Manager

# Create a secret in AWS Secrets Manager via docker CLI
docker secret create products-api-config \
  ./secrets/application.properties

# Secrets are stored in AWS Secrets Manager
# Referenced in the Compose file via their ARN or name

# Deploy the application
docker compose up

# View services
docker compose ps

# Read logs
docker compose logs web

ECS vs ACI differences

6. Reference Tables

Platform Comparison

Kubernetes Service Types

Configuration Objects

7. Essential Commands

Docker Compose

docker compose up -d                    # Start in background
docker compose down                     # Stop and remove
docker compose ps                       # List containers
docker compose logs --follow <service>  # Follow logs
docker compose up -d --scale <svc>=3   # Scale a service
docker compose pull                     # Update images

Docker Swarm

docker swarm init                               # Initialize the Swarm
docker swarm join --token <TOKEN> <IP>:2377    # Join the Swarm
docker node ls                                  # List nodes
docker stack deploy -c compose.yml <stack>     # Deploy a stack
docker stack ls                                 # List stacks
docker stack ps <stack>                         # Stack containers
docker service ls                               # List services
docker service ps <service>                     # Service tasks
docker service update --image <img> <svc>      # Update a service
docker config create <name> <file>             # Create a config
docker secret create <name> <file>             # Create a secret

kubectl (Kubernetes)

# Resource management
kubectl apply -f <file.yaml>             # Create/update a resource
kubectl delete -f <file.yaml>            # Delete a resource
kubectl get <resource>                   # List resources
kubectl describe <resource> <name>       # Resource details

# Namespace navigation
kubectl get all -n <namespace>           # All resources in a namespace
kubectl config set-context --current --namespace=<ns>  # Default namespace

# Debugging
kubectl logs <pod>                       # Pod logs
kubectl logs <pod> -f                    # Follow logs
kubectl exec -it <pod> -- /bin/sh        # Shell into a Pod
kubectl port-forward pod/<pod> 8080:80  # Local port forwarding

# Rollouts
kubectl rollout status deployment/<name>  # Rollout status
kubectl rollout history deployment/<name> # History
kubectl rollout undo deployment/<name>    # Rollback

# Scaling
kubectl scale deployment/<name> --replicas=3   # Manual scaling

Docker Context (cloud)

docker context ls                          # List contexts
docker context use <context>               # Switch context
export DOCKER_CONTEXT=<context>            # Switch via env var
docker login azure                         # Log in to Azure
docker context create aci <name> ...       # Create ACI context
docker context create ecs <name> ...       # Create ECS context

Appendix: Wired Brain Coffee Application Architecture

flowchart TB
    USER([User\nBrowser]) -->|HTTP :8080| WEB

    subgraph "Wired Brain Coffee Application"
        WEB[web\npsdockerrun/web\n.NET]
        PAPI[products-api\npsdockerrun/products-api\nJava]
        SAPI[stock-api\npsdockerrun/stock-api\nGo]
        DB[(products-db\npsdockerrun/products-db\nPostgreSQL)]
    end

    WEB -->|:8081| PAPI
    WEB -->|:8082| SAPI
    PAPI --> DB
    SAPI --> DB

flowchart LR
    subgraph "CI/CD Pipeline with Registry"
        SC[Source Code\nGit Repository]
        BUILD[Build\nDocker Image]
        TEST[Automated\nTests]
        REG[Container Registry\nDocker Hub / ACR / ECR]
        DEPLOY[Deploy\nKubernetes / Swarm / ACI]
    end

    SC -->|git push| BUILD
    BUILD --> TEST
    TEST -->|docker push| REG
    REG -->|kubectl apply\ndocker stack deploy\ndocker compose up| DEPLOY

Search Terms

deploying · containerized · applications · docker · containerization · containers · kubernetes · compose · deployment · swarm · aci · configuration · container · service · aks · application · architecture · azure · cluster · commands · database · docker-compose.yml · ecs · rolling