Docker and Docker Compose Command Guide

Introduction

Docker is a platform for developing, shipping, and running applications in containers. Containers are lightweight, standalone packages that include everything needed to run a software application - code, runtime, system tools, libraries, and settings. This makes applications portable and ensures they run consistently across different environments.

Docker Commands

Image Management

# Download an image from Docker Hub
docker pull <image>

# List all local images
docker images

# Remove an image
docker rmi <image>

# Build an image from a Dockerfile
docker build -t <name> .

Container Management

# List running containers
docker ps

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

# Create and start a container
docker run <image>

# Run container in detached mode
docker run -d <image>

# Map port 8080 on host to 80 in container
docker run -p 8080:80 <image>

# Stop a running container
docker stop <container>

# Remove a container
docker rm <container>

# View container logs
docker logs <container>

# Enter a running container
docker exec -it <container> bash

System Commands

# Remove unused data
docker system prune

# Show Docker disk usage
docker system df

Docker Compose Commands

Docker Compose is a tool for defining and running multi-container Docker applications. Here are the essential commands:

Basic Operations

# Create and start all containers
docker-compose up

# Start in detached mode
docker-compose up -d

# Stop and remove containers
docker-compose down

# List containers
docker-compose ps

# View output from containers
docker-compose logs

Build Commands

# Build all services
docker-compose build

# Pull all images
docker-compose pull

Service Management

# Start services
docker-compose start

# Stop services
docker-compose stop

# Restart services
docker-compose restart

# Run command in service
docker-compose exec <service> bash

Configuration

# Validate and view composed configuration
docker-compose config

Example Docker Compose Configuration

Below is a sample Docker Compose configuration for a Python web application:

# docker-compose.yml
version: '3'
services:
  web:
    build: .
    ports:
      - "5000:5000"
    volumes:
      - .:/app
    environment:
      - FLASK_ENV=development
  db:
    image: postgres:13
    environment:
      - POSTGRES_DB=myapp
      - POSTGRES_USER=user
      - POSTGRES_PASSWORD=password

Common Use Cases

Running a Web Application

# Build and start the application
docker-compose up --build

# View logs
docker-compose logs -f web

# Stop the application
docker-compose down

Container Management

# Restart a specific service
docker-compose restart web

# Scale a service
docker-compose up -d --scale web=3

# View container status
docker-compose ps

Development Workflow

# Start containers in development mode
docker-compose -f docker-compose.dev.yml up

# Run tests in container
docker-compose exec web python -m pytest

# View application logs
docker-compose logs -f

Best Practices

1. Always use version control for your Docker and Docker Compose files
2. Keep images small by using multi-stage builds
3. Use environment variables for configuration
4. Tag your images appropriately
5. Use volumes for persistent data
6. Clean up unused containers and images regularly

Troubleshooting

Common commands for troubleshooting:

# Check container logs
docker-compose logs <service>

# Inspect container
docker inspect <container>

# View resource usage
docker stats

# Check network
docker network ls

Interview angle

• “Container versus VM?” - a container shares the host kernel and isolates via namespaces and cgroups, so it starts in milliseconds and costs megabytes. A VM virtualises hardware with its own kernel: stronger isolation, far heavier.
• “What actually provides the isolation?” - Linux namespaces (pid, net, mount, user, uts, ipc) for visibility and cgroups for resource limits. Containers are a packaging convention over kernel features, not a technology of their own.
• “Is a container a security boundary?” - weaker than a VM, because the kernel is shared. A kernel exploit escapes. For hostile multi-tenancy use VMs or a sandboxed runtime; run as non-root and drop capabilities regardless.