Docker – Complete Tutorial

1. Prerequisites

Before we dive into Docker, let's make sure you understand some fundamental computing concepts. Even if you're a complete beginner, this section will get you up to speed.

What is an Operating System (OS)?

Think of your computer as a house. The hardware (CPU, RAM, disk) is the house's structure. The Operating System is like the building management — it controls who can use the electricity, water (resources), and ensures everything runs smoothly.

An OS is software that sits between your hardware and your applications. Examples: Linux macOS Windows

What is a Process?

When you open a program (like Chrome or a Python script), the OS creates a process — a running instance of that program. Each process gets its own allocated memory and CPU time. If you open two Chrome windows, those are two processes.

What is a Network Port?

Imagine your computer is a large apartment building. Its IP address is the building's street address. A port is the apartment number — it tells incoming data which specific application to reach.

There are 65,535 possible ports. Common examples:

What is a Server?

A server is simply a program (or machine) that provides services to other programs (called clients). When you visit google.com, your browser (client) sends a request; Google's server responds with the webpage. A server is always listening on a port for incoming requests.

What are Environment Variables?

Environment variables are key-value pairs stored in the OS environment that applications can read. They let you configure applications without changing their code — for example, setting a database password or API key.

# Setting an environment variable (Linux/macOS)
export DATABASE_URL="postgres://localhost:5432/mydb"
export PORT=3000

# Reading it in a program (Python example)
import os
db = os.getenv("DATABASE_URL")   # reads the value

2. What is Docker?

Docker solves one of software's oldest headaches — "it works on my machine." Let's understand the problem and how Docker elegantly fixes it.

The Problem Docker Solves

Imagine you build a web app on your laptop. It uses Python 3.11, a specific version of a database driver, and a particular Linux library. Everything works perfectly.

Then you hand it to a colleague. Their machine has Python 3.9, a different library version — and nothing works. You've encountered the classic "works on my machine" problem.

Docker's Solution: The Shipping Container Analogy

Before the 1960s, shipping goods internationally was chaotic. Different ships had different-sized cargo holds, and loading/unloading was manual and slow. Then the standardized shipping container was invented — a uniform box that fits on any ship, truck, or train, regardless of what's inside.

Docker does the same thing for software. A Docker container packages your application and all its dependencies into a single, portable unit that runs identically everywhere.

Key Facts About Docker

What Can You Do With Docker?

• Package an application with all its dependencies
• Run the same app consistently across dev, test, and prod environments
• Spin up a database with one command (no installation needed)
• Run multiple isolated services on a single machine
• Scale applications horizontally with ease
• Enable microservices architecture

3. Containers vs Virtual Machines

Before Docker, the standard way to isolate applications was with Virtual Machines. Understanding the difference helps you appreciate why containers are so revolutionary.

Virtual Machines (VMs) Explained

A Virtual Machine is a software emulation of a complete computer. It uses a program called a hypervisor (like VMware, VirtualBox, or Hyper-V) to simulate hardware. Inside the VM, a full OS boots up — just like on a physical computer.

Think of it like building an entire house inside another house. Each VM has its own walls, plumbing, electricity — completely separate from the host, but wasteful of space and resources.

Containers Explained

A container is much lighter. Instead of running a full OS, it shares the host's kernel and uses Linux namespaces to create an isolated environment. Think of it like renting a single room — you share the building's infrastructure (plumbing, electricity/kernel) but your room is private and isolated.

Side-by-Side Comparison

How Linux Namespaces Enable Isolation

Linux namespaces are the magic behind containers. They give each container its own isolated view of the system:

How cgroups Control Resources

cgroups (control groups) let Docker limit and monitor how much CPU, memory, disk I/O, and network a container can use. This prevents one container from consuming all system resources and starving others.

# Limit a container to 512MB RAM and 50% of 1 CPU core
docker run --memory="512m" --cpus="0.5" nginx

# This uses cgroups under the hood to enforce these limits

4. Installing Docker

Let's get Docker running on your machine. The easiest way for most developers is Docker Desktop, which bundles everything you need.

Docker Desktop (Mac, Windows, Linux)

Docker Desktop is a GUI application that includes Docker Engine, Docker CLI, Docker Compose, and more. It's the recommended way to run Docker on a developer machine.

Installation on macOS

1. Go to docker.com/products/docker-desktop and download the macOS installer (choose Intel or Apple Silicon)
2. Open the downloaded .dmg file and drag Docker to your Applications folder
3. Launch Docker from Applications — a whale icon appears in the menu bar
4. Wait for Docker to start (the whale stops animating)
5. Open Terminal and verify: docker version

Installation on Linux (Ubuntu/Debian)

# Step 1: Update packages and install prerequisites
sudo apt-get update
sudo apt-get install -y ca-certificates curl gnupg

# Step 2: Add Docker's official GPG key
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

# Step 3: Set up the repository
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \
  https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# Step 4: Install Docker Engine
sudo apt-get update
sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin

# Step 5: Run Docker without sudo (optional but recommended)
sudo usermod -aG docker $USER
newgrp docker

Installation on Windows

1. Enable WSL 2 (Windows Subsystem for Linux) — Docker Desktop uses it for Linux containers
2. Download Docker Desktop installer from docker.com
3. Run the installer and follow the prompts
4. Restart your computer when prompted
5. Launch Docker Desktop from the Start menu

Verifying the Installation

# Check Docker version (client and server info)
docker version
# Output shows Client version, Server (daemon) version, API version, etc.

# Check Docker system info (resources, containers, images count)
docker info
# Output shows: containers running/stopped, images, storage driver, OS, CPUs, memory

# The classic Hello World test
docker run hello-world
# Docker pulls a tiny test image, runs it, prints a success message, then exits

The docker run hello-world command does several things automatically:

1. Checks if the hello-world image is locally available
2. Doesn't find it, so pulls it from Docker Hub (the default registry)
3. Creates a container from the image
4. Runs the container — it prints a message and exits

Understanding: docker version vs docker info

5. Docker Architecture

Understanding Docker's architecture helps you know what's happening behind the scenes every time you type a Docker command.

The Three Main Components

Docker uses a client-server architecture. The three main components are:

How a docker run Command Works Step by Step

1. You type docker run nginx in the terminal
2. The Docker client parses the command and sends a REST API request to the Docker daemon via the Unix socket (/var/run/docker.sock)
3. The daemon checks if the nginx image exists locally
4. Image not found → daemon sends a pull request to Docker Hub (registry)
5. The image layers are downloaded and stored locally
6. The daemon creates a new container from the image
7. The container starts running — nginx is now serving requests

The Docker Socket

The Docker daemon listens on a Unix socket at /var/run/docker.sock. This is how the CLI communicates with it. When you mount this socket into a container, that container can control Docker on the host — a powerful but security-sensitive pattern.

# See all Docker objects and system info
docker info

# The daemon is a systemd service on Linux
sudo systemctl status docker

# You can also communicate via TCP (for remote Docker)
# DOCKER_HOST=tcp://192.168.1.10:2376 docker ps

6. Docker Images

A Docker image is like a recipe or blueprint. It contains everything needed to run an application — code, runtime, libraries, config files — but it's not running yet.

What is a Docker Image?

Think of a Docker image as a snapshot of a filesystem. It's read-only — you can't modify it. When you want to run it, Docker creates a container from it (like making a cake from a recipe — the recipe doesn't change, but each cake is a new instance).

Images are described by a name and a tag: name:tag — e.g., nginx:1.25 or python:3.11-slim.

The Layer System

Docker images are composed of read-only layers stacked on top of each other. Each layer represents a change: adding files, installing software, modifying config. This system is very efficient — if two images share common base layers, those layers are stored only once on disk.

Essential Image Commands

Pulling an Image

# Pull the latest nginx image from Docker Hub
docker pull nginx
# Docker pulls it as: nginx:latest  (default tag)

# Pull a specific version (tag)
docker pull nginx:1.25-alpine
# alpine = a very small Linux distro, great for small images

# Pull an image from a specific registry (not Docker Hub)
docker pull gcr.io/google-containers/pause:3.9

How it works: Docker checks if you have the image locally. If not, it contacts the registry, downloads each layer individually (in parallel), and assembles the image locally. Downloaded layers are cached — if another image shares a layer, it won't be re-downloaded.

Listing Images

# List all locally available images
docker images
# or equivalently:
docker image ls

# Output columns:
# REPOSITORY   TAG       IMAGE ID      CREATED       SIZE
# nginx        latest    a6bd71f48f68  2 weeks ago   187MB
# ubuntu       22.04     174c8c134b2a  5 weeks ago   77.8MB

# Show all images including intermediate layers
docker images -a

# Filter images by name
docker images nginx

Inspecting an Image

# Get detailed JSON metadata about an image
docker inspect nginx

# This shows: layers, environment variables, exposed ports,
# architecture, OS, creation date, entrypoint, etc.

# Show image layer history
docker history nginx
# Output shows each layer, its size, and the command that created it

Removing Images

# Remove a specific image
docker rmi nginx
# or:
docker image rm nginx

# Force remove (even if containers use it)
docker rmi -f nginx

# Remove all unused images (not used by any container)
docker image prune

# Remove ALL images (careful!)
docker image prune -a

Image Tags Explained

Tags are labels attached to images to distinguish versions. Format: repository:tag

7. Docker Containers

A container is a running instance of an image. This is where your application actually lives and executes. Let's master all the essential container operations.

Container Lifecycle

Running a Container: docker run

docker run is the most important Docker command. It creates and starts a container in one step.

# Basic: run nginx web server
docker run nginx
# Pulls nginx:latest if not local, creates & starts a container
# (runs in FOREGROUND — use Ctrl+C to stop)

# Run in detached (background) mode with -d
docker run -d nginx
# Returns the container ID immediately, runs in background

# Run with a custom name
docker run -d --name my-nginx nginx

# Map host port 8080 to container port 80
docker run -d -p 8080:80 --name web nginx
# Now visit http://localhost:8080 to see nginx

# Set environment variables
docker run -d -e MYSQL_ROOT_PASSWORD=secret --name db mysql:8

# Run an interactive terminal (e.g., explore Ubuntu)
docker run -it ubuntu bash
# -i = interactive (keep stdin open)
# -t = allocate a pseudo-TTY (terminal)
# bash = command to run inside the container

Anatomy of docker run -d -p 8080:80 --name web nginx

Managing Running Containers

# List running containers
docker ps

# List ALL containers (including stopped)
docker ps -a

# Stop a running container (graceful - sends SIGTERM, waits 10s, then SIGKILL)
docker stop web

# Forcefully kill a container immediately (sends SIGKILL)
docker kill web

# Start a stopped container
docker start web

# Restart a container
docker restart web

# Remove a stopped container
docker rm web

# Remove a running container (force)
docker rm -f web

# Remove ALL stopped containers
docker container prune

Interacting with Running Containers

# Open a shell inside a running container
docker exec -it web bash
# -i = interactive, -t = terminal, bash = shell command

# Run a single command inside a container
docker exec web ls /etc/nginx/

# View container logs (stdout + stderr)
docker logs web

# Follow logs in real-time (like tail -f)
docker logs -f web

# Show last 50 lines
docker logs --tail 50 web

# View real-time resource usage (CPU, memory, network, disk)
docker stats

# View container processes
docker top web

# Copy files from container to host
docker cp web:/etc/nginx/nginx.conf ./nginx.conf

# Copy files from host to container
docker cp ./nginx.conf web:/etc/nginx/nginx.conf

8. Dockerfile

A Dockerfile is a text script with instructions to build a custom Docker image. It's how you tell Docker exactly how to package your application.

What is a Dockerfile?

Think of a Dockerfile as a recipe for building a Docker image. Each instruction in the file creates a new layer in the image. Docker reads the file top-to-bottom and executes each instruction sequentially during the build.

All Dockerfile Instructions Explained

FROM — Set Base Image

FROM node:18-alpine
# Every Dockerfile MUST start with FROM (except multi-stage)
# node:18-alpine means Node.js version 18 on Alpine Linux (small ~50MB)
# vs node:18 which is ~900MB on Debian

WORKDIR — Set Working Directory

WORKDIR /app
# Sets /app as the working directory for all subsequent instructions
# Creates the directory if it doesn't exist
# Better than: RUN mkdir /app && cd /app (which doesn't persist)

COPY — Copy Files from Host

COPY package*.json ./
# Copies package.json and package-lock.json from build context (host) to /app

COPY . .
# Copies everything from build context to /app
# (use .dockerignore to exclude node_modules, .git, etc.)

RUN — Execute Commands During Build

RUN npm install
# Executes during IMAGE BUILD, creates a new layer
# Good for: installing packages, compiling code, setting up config

RUN apt-get update && apt-get install -y curl vim && rm -rf /var/lib/apt/lists/*
# Combine multiple commands with && to create ONE layer (more efficient)
# rm -rf cleans up apt cache to reduce image size

ENV — Set Environment Variables

ENV NODE_ENV=production
ENV PORT=3000
# Available during build AND runtime
# Can be overridden at runtime: docker run -e NODE_ENV=development

EXPOSE — Document Port

EXPOSE 3000
# DOCUMENTS that the container listens on port 3000
# Does NOT actually publish the port (that's -p at runtime)
# It's informational and used by orchestration tools

CMD — Default Command

CMD ["node", "server.js"]
# The default command that runs when a container starts
# Can be OVERRIDDEN at runtime: docker run myapp npm test
# Use JSON array form (exec form) — preferred over shell form

ENTRYPOINT — Set Main Executable

ENTRYPOINT ["node"]
CMD ["server.js"]
# ENTRYPOINT: the fixed executable (harder to override)
# CMD: default arguments to ENTRYPOINT (easily overridden)
# Combined: runs "node server.js" by default
# Override: docker run myapp other-file.js  → runs "node other-file.js"

ADD vs COPY

COPY src/ /app/src/    # Preferred: simple, predictable

ADD archive.tar.gz /app/  # ADD can auto-extract tar archives
ADD http://example.com/file.txt /app/  # ADD can download URLs
# Rule of thumb: prefer COPY unless you need ADD's extra features

Complete Example: Dockerizing a Node.js App

# Stage 1: Use official Node.js Alpine image as base
FROM node:18-alpine

# Set working directory inside the container
WORKDIR /app

# Copy dependency files first (layer caching optimization!)
# If package.json hasn't changed, Docker reuses the cached layer
COPY package*.json ./

# Install dependencies
RUN npm ci --only=production

# Copy remaining application source code
COPY . .

# Declare the port our app listens on (documentation)
EXPOSE 3000

# Set NODE_ENV to production
ENV NODE_ENV=production

# Command to run when container starts
CMD ["node", "server.js"]

Building the Image

# Build image from Dockerfile in current directory
# -t = tag (name:version)  .  = build context (current directory)
docker build -t myapp:1.0 .

# Build with a different Dockerfile location
docker build -t myapp:1.0 -f docker/Dockerfile.prod .

# Build with build arguments (values passed at build time)
docker build -t myapp:1.0 --build-arg API_URL=https://api.prod.com .

# After building, run it
docker run -d -p 3000:3000 --name myapp myapp:1.0

The .dockerignore File

Just like .gitignore excludes files from git, .dockerignore excludes files from the build context. This speeds up builds and prevents accidentally copying secrets into images.

node_modules/
.git/
.env
*.log
.DS_Store
README.md
*.test.js

Multi-Stage Builds

Multi-stage builds let you use multiple FROM statements. Each stage can copy artifacts from previous stages. This is great for compiled languages — compile in one stage, copy only the binary to the final small image.

# Stage 1: Build (has all build tools)
FROM golang:1.21 AS builder
WORKDIR /app
COPY . .
RUN go build -o myserver .

# Stage 2: Run (only has the tiny binary)
FROM alpine:3.18
WORKDIR /app
COPY --from=builder /app/myserver .
EXPOSE 8080
CMD ["./myserver"]
# Result: ~15MB image instead of ~1GB (no Go compiler needed at runtime!)

9. Docker Volumes

Containers are ephemeral — data inside them disappears when they're removed. Volumes are the solution, providing persistent storage that outlives any container.

Why Volumes?

Imagine running a database inside a container. The database stores its files in the container's filesystem. If you remove the container (to update the database version, for example), all your data is gone. That's a disaster.

Docker Volumes solve this by storing data on the host filesystem (or network storage) outside the container. The container can be deleted and recreated, but the volume — and your data — persists.

Three Types of Docker Storage

Named Volumes — The Recommended Way

Named volumes are managed entirely by Docker. Docker decides where on the host to store them (usually /var/lib/docker/volumes/). They're portable — they can be backed up, migrated, and shared between containers.

# Create a named volume
docker volume create mydata

# Use it when running a container
# -v volume_name:container_path
docker run -d \
  --name postgres-db \
  -e POSTGRES_PASSWORD=secret \
  -v mydata:/var/lib/postgresql/data \
  postgres:15

# The database files are stored in the 'mydata' volume
# Delete and recreate the container — data persists!
docker rm -f postgres-db
docker run -d --name postgres-db -v mydata:/var/lib/postgresql/data postgres:15
# ✅ Data is still there!

# List all volumes
docker volume ls

# Inspect a volume (shows where it's stored on host)
docker volume inspect mydata

# Remove a volume (DATA IS DELETED!)
docker volume rm mydata

# Remove all unused volumes
docker volume prune

Bind Mounts — Mount a Host Directory

Bind mounts link a specific directory on your host to a path inside the container. Changes on either side are immediately reflected on the other side. Perfect for development — edit code on your host, see changes immediately in the container.

# Mount current host directory to /app in container
# $(pwd) = print working directory (current directory)
docker run -d \
  -p 3000:3000 \
  -v $(pwd):/app \
  node:18-alpine \
  node server.js
# Edit code on your host → changes instantly visible in container

# Read-only bind mount (container can't modify the host files)
docker run -d -v $(pwd)/config:/app/config:ro nginx

tmpfs Mounts — In-Memory Storage

tmpfs mounts store data in the host's RAM. The data is never written to disk — it disappears when the container stops. Useful for sensitive temporary data (like secrets or session tokens) that you don't want written to disk.

# Mount an in-memory filesystem at /tmp inside the container
docker run -d --tmpfs /tmp nginx

# Or using the --mount syntax (more verbose but explicit)
docker run -d \
  --mount type=tmpfs,destination=/tmp,tmpfs-size=100m \
  nginx

Comparison: Volumes vs Bind Mounts

10. Docker Networks

Docker networking allows containers to communicate with each other and with the outside world. Understanding networks is essential for building multi-service applications.

Why Docker Networking?

When you run multiple containers (e.g., a web app + database + cache), they need to talk to each other. Docker networking provides isolated virtual networks where containers can communicate securely.

Network Drivers

Network Drivers Explained

Working with Networks

# List all networks
docker network ls
# Shows: NETWORK ID, NAME, DRIVER, SCOPE
# Default networks: bridge, host, none

# Create a custom bridge network
docker network create mynetwork

# Create with custom subnet
docker network create --subnet=192.168.10.0/24 mynetwork

# Run containers on the same network
docker run -d --name api --network mynetwork myapi-image
docker run -d --name db --network mynetwork postgres:15

# 'api' can reach 'db' by name: postgres://db:5432/mydb
# This works because Docker's embedded DNS resolves container names

# Connect an existing container to a network
docker network connect mynetwork existing-container

# Disconnect a container from a network
docker network disconnect mynetwork existing-container

# Inspect a network (see connected containers and their IPs)
docker network inspect mynetwork

# Remove a network (all containers must be disconnected first)
docker network rm mynetwork

Container-to-Container Communication

On a user-defined bridge network, containers can communicate using their names:

# Create a network
docker network create appnet

# Start a database container
docker run -d --name postgres \
  --network appnet \
  -e POSTGRES_DB=mydb \
  -e POSTGRES_PASSWORD=secret \
  postgres:15

# Start your app — connect to 'postgres' by name
docker run -d --name myapp \
  --network appnet \
  -p 3000:3000 \
  -e DATABASE_URL="postgres://postgres:secret@postgres:5432/mydb" \
  myapp:latest
# 'postgres' in the DATABASE_URL resolves to the postgres container's IP

11. Docker Compose

Managing multiple containers with individual docker run commands gets tedious fast. Docker Compose lets you define a multi-container application in a single YAML file and manage everything with one command.

What is Docker Compose?

Docker Compose is a tool for defining and running multi-container Docker applications. You describe all your services (web app, database, cache, etc.) in a docker-compose.yml file, and then start everything with docker compose up.

Anatomy of a docker-compose.yml

services:
  # Service 1: Our Node.js web app
  web:
    build: .                          # Build from Dockerfile in current dir
    ports:
      - "3000:3000"                   # host:container port mapping
    environment:
      - NODE_ENV=production
      - DATABASE_URL=postgres://db:5432/mydb
    depends_on:
      - db                            # Wait for 'db' to start before 'web'
    networks:
      - appnet
    volumes:
      - ./logs:/app/logs              # Bind mount for logs

  # Service 2: PostgreSQL database
  db:
    image: postgres:15
    environment:
      POSTGRES_DB: mydb
      POSTGRES_PASSWORD: secret
    volumes:
      - dbdata:/var/lib/postgresql/data  # Named volume for persistence
    networks:
      - appnet

  # Service 3: Redis cache
  redis:
    image: redis:7-alpine
    networks:
      - appnet

# Named volumes (persistent data)
volumes:
  dbdata:

# Custom network
networks:
  appnet:
    driver: bridge

Essential Docker Compose Commands

# Start all services (in foreground — shows all logs)
docker compose up

# Start in detached (background) mode
docker compose up -d

# Build images AND start services (force rebuild)
docker compose up --build -d

# Stop all services (keeps containers, volumes, networks)
docker compose stop

# Stop AND remove containers + networks (keeps volumes)
docker compose down

# Stop AND remove EVERYTHING including volumes (⚠️ DATA LOSS!)
docker compose down -v

# View logs for all services
docker compose logs

# Follow logs in real-time
docker compose logs -f

# Follow logs for a specific service
docker compose logs -f web

# List all running services
docker compose ps

# Run a one-off command in a service
docker compose exec web bash
docker compose exec db psql -U postgres

# Scale a service (run multiple instances)
docker compose up --scale web=3 -d

# Rebuild only one service
docker compose up --build web

Environment Variables in Compose

POSTGRES_PASSWORD=supersecret
NODE_ENV=production
API_KEY=abc123

services:
  db:
    image: postgres:15
    environment:
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}  # Read from .env

12. Docker Registry & Docker Hub

Registries are the distribution layer of the Docker ecosystem — they store and serve Docker images. Understanding how to push and pull images is essential for collaboration and deployment.

What is a Docker Registry?

A Docker Registry is a storage system for Docker images. Think of it like GitHub for code — but for container images. You push images to share them, and others pull them to run containers.

Image Naming Convention

The full name of a Docker image is: registry/username/repository:tag

# Official images on Docker Hub (no username prefix)
nginx:latest           # registry: Docker Hub, official image
postgres:15

# User/org images on Docker Hub
myusername/myapp:1.0   # hub.docker.com/r/myusername/myapp

# Images on other registries
gcr.io/myproject/myapp:v2.3      # Google Container Registry
123456789.dkr.ecr.us-east-1.amazonaws.com/myapp:prod  # AWS ECR
ghcr.io/myorg/myapp:latest       # GitHub Container Registry

Working with Docker Hub

# Step 1: Log into Docker Hub
docker login
# Enter your Docker Hub username and password
# Credentials stored in ~/.docker/config.json

# Step 2: Tag your image with your Docker Hub username
docker tag myapp:1.0 yourusername/myapp:1.0
# Now the image is tagged as: yourusername/myapp:1.0

# Step 3: Push to Docker Hub
docker push yourusername/myapp:1.0
# Uploads all layers (only new layers are uploaded)

# Step 4: Anyone can now pull your image
docker pull yourusername/myapp:1.0

# Log out of Docker Hub
docker logout

Running a Private Local Registry

# Start a local registry on port 5000
docker run -d -p 5000:5000 --name registry registry:2

# Tag an image for your local registry
docker tag myapp:1.0 localhost:5000/myapp:1.0

# Push to local registry
docker push localhost:5000/myapp:1.0

# Pull from local registry
docker pull localhost:5000/myapp:1.0

Image Tags & Versioning Best Practices

# Tag the same image with multiple tags
docker tag myapp:1.2.3 myusername/myapp:1.2.3
docker tag myapp:1.2.3 myusername/myapp:1.2
docker tag myapp:1.2.3 myusername/myapp:latest

# Push all tags
docker push myusername/myapp:1.2.3
docker push myusername/myapp:1.2
docker push myusername/myapp:latest

# Or push all tags at once
docker push --all-tags myusername/myapp

Docker Content Trust (DCT)

Docker Content Trust is a security feature that uses digital signatures to verify image authenticity. When enabled, you can only pull images that have been signed — protecting against tampered or malicious images.

# Enable Docker Content Trust (for signing and verification)
export DOCKER_CONTENT_TRUST=1

# Now all push/pull operations require signed images
docker push myusername/myapp:1.0   # Signs the image
docker pull myusername/myapp:1.0   # Verifies the signature