Docker and Containers Explained

"It works on my machine" is one of the oldest frustrations in software. Code that runs perfectly on a developer's laptop fails on the server because of a different library version, a missing package or a changed setting. Docker containers solve this by packaging an application together with everything it needs to run, so the same package behaves the same way on a laptop, a test server and production. This article explains the core ideas, shows real commands, and covers when containers are, and are not, worth the effort.

What is a container?

A container is an isolated process running on a host operating system, with its own view of the file system, network and process list. To the application inside, it looks like it has a small machine to itself. In reality it shares the host's Linux kernel with other containers, which makes containers far lighter than virtual machines.

Docker is the tool that made containers popular and easy to use. It is not the only one; Podman, containerd and others implement the same open standards from the Open Container Initiative, so images built with Docker run elsewhere too.

Containers vs virtual machines

The two are not rivals. In practice most containers in the cloud run inside virtual machines.

The key Docker terms

• Image: a read-only template containing the application, runtime and libraries. Think of it as a recipe already baked into a box.
• Container: a running instance of an image. You can run many containers from one image.
• Dockerfile: a text file with the instructions to build an image.
• Registry: a place to store and share images, such as Docker Hub, GitHub Container Registry, or private registries from AWS, Azure and Google Cloud.
• Volume: storage that lives outside the container, so data survives when the container is replaced.

Docker containers in practice

Running an existing image

With Docker installed, this single command downloads the official Nginx image and runs it, mapping port 8080 on your machine to port 80 in the container:

docker run -d --name web -p 8080:80 nginx:stable

Useful everyday commands:

docker ps                 # list running containers
docker logs -f web        # follow a container's output
docker exec -it web sh    # open a shell inside it
docker stop web && docker rm web

Building your own image

A simple Dockerfile for a Node.js application:

FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
USER node
EXPOSE 3000
CMD ["node", "server.js"]

Build and run it with docker build -t myapp:1.0 . and docker run -d -p 3000:3000 myapp:1.0. Copying the package files and installing dependencies before copying the rest of the code lets Docker cache that slow step between builds. The USER node line avoids running the app as root inside the container, a simple and worthwhile security habit.

Running several services with Compose

Real applications usually need more than one piece: an app, a database, perhaps a cache. Docker Compose describes them in one file:

services:
  app:
    build: .
    ports:
      - "3000:3000"
    environment:
      DATABASE_URL: postgres://app:secret@db:5432/app
    depends_on:
      - db
  db:
    image: postgres:16
    environment:
      POSTGRES_USER: app
      POSTGRES_PASSWORD: secret
      POSTGRES_DB: app
    volumes:
      - dbdata:/var/lib/postgresql/data
volumes:
  dbdata:

docker compose up -d starts everything; a new developer can have the whole stack running in minutes. In production, keep real passwords out of the file and use secrets or environment files with restricted permissions.

Why businesses adopt containers

• Consistency: the image tested is exactly the image deployed.
• Faster onboarding: new developers run one command instead of following a long setup document.
• Portability: images run on any Linux host and on every major cloud's container services, reducing lock-in.
• Density: several isolated applications can share one server without conflicting library versions.
• Simpler rollbacks: deploying the previous image tag returns you to a known state.

When containers add little

A standard WordPress site on managed hosting, or a single small application that rarely changes, may not benefit much. Containers also bring their own learning curve: image updates, registry management, logging and persistent storage all need thought. Remember that data written inside a container disappears when it is removed unless you use volumes, and that images need rebuilding regularly to pick up security fixes in their base layers.

From one server to orchestration

Running a few containers on one server with Compose is perfectly reasonable for many businesses. When you need many servers, automatic restarts across machines, rolling updates and scaling, an orchestrator such as Kubernetes, or a managed service like Amazon ECS, Azure Container Apps or Google Cloud Run, takes over. Do not jump to Kubernetes before you need it; it brings significant operational complexity. The official Docker getting started guide is a good next step for hands-on learning. For packaging and hosting your own applications this way, see our web application development and cloud solutions pages.

Key takeaways

• Docker containers package an application with its dependencies so it runs the same everywhere.
• Containers share the host kernel, making them lighter and faster to start than virtual machines.
• Images are built from Dockerfiles; Compose runs multi-service stacks from one file.
• Use volumes for data, run as non-root, rebuild images for security updates, and adopt orchestration only when scale demands it.