Docker for Developers: A Practical Getting-Started Guide

Docker solves a problem every developer has hit: "it works on my machine." By packaging your application with its runtime and dependencies into an image, you can run it the same way on your laptop, a CI runner or a production server.

This guide covers the concepts and commands you'll use day to day, then walks through containerising a small Node.js web app. No affiliate links here — just the fundamentals.

Core concepts

• Image — a read-only template with your app, its dependencies and a minimal operating system layer.
• Container — a running instance of an image, isolated from other processes.
• Dockerfile — a text file of instructions for building an image.
• Registry — a place to store and share images, such as Docker Hub or a cloud provider's container registry.
• Volume — persistent storage that outlives a container.

Essential commands

# Run a container from an image (downloads it if needed)
docker run --rm -p 8080:80 nginx
 
# List running containers (add -a to include stopped ones)
docker ps
 
# View logs from a container
docker logs <container-id>
 
# Open a shell inside a running container
docker exec -it <container-id> sh
 
# List local images
docker images
 
# Stop a container
docker stop <container-id>

The -p 8080:80 flag maps port 8080 on your machine to port 80 inside the container, so http://localhost:8080 reaches nginx. The --rm flag removes the container when it stops.

Containerising a small web app

Assume a Node.js app with a package.json, a package-lock.json and a server.js that listens on port 3000.

Write a Dockerfile

# Use a small official Node.js base image
FROM node:22-alpine
 
WORKDIR /app
 
# Install dependencies first so this layer is cached between code changes
COPY package.json package-lock.json ./
RUN npm ci --omit=dev
 
# Copy the rest of the source code
COPY . .
 
# Run as the non-root user provided by the base image
USER node
 
EXPOSE 3000
CMD ["node", "server.js"]

Add a .dockerignore

node_modules
.git
.env
*.log

This keeps your build context small and — importantly — keeps secrets such as .env files out of the image.

Build and run

docker build -t my-app .
docker run --rm -p 3000:3000 my-app

Running multiple services with Docker Compose

Most apps need more than one service — for example, an app plus a database. Docker Compose describes them in one file:

# compose.yaml
services:
  app:
    build: .
    ports:
      - "3000:3000"
    environment:
      DATABASE_URL: postgres://postgres:example@db:5432/postgres
    depends_on:
      - db
 
  db:
    image: postgres:17
    environment:
      POSTGRES_PASSWORD: example
    volumes:
      - db-data:/var/lib/postgresql/data
 
volumes:
  db-data:

docker compose up --build   # start everything
docker compose down         # stop and remove containers (the named volume is kept)

Services can reach each other by name — the app connects to the database at host db. The named volume db-data keeps your data between restarts.

Good habits from day one

• Use small, official base images and pin a major version (for example node:22-alpine, not node:latest).
• Don't run as root inside containers when you can avoid it.
• Never bake secrets into images. Pass them at runtime.
• One concern per container. Run your app and your database in separate containers.
• Rebuild regularly to pick up base-image security updates.

Where to go next

• Deploy your container to a VPS or a container-friendly platform.
• Strengthen the Linux fundamentals that containers build on.
• When you're running many containers across machines, that's the time to learn Kubernetes.